Let band.Add work even if all origin, +x, and y atoms are on the same protein segment

Case number:845813-2006317
Topic:Game: Tools
Opened by:jeff101
Status:Open
Type:Suggestion
Opened on:Thursday, December 13, 2018 - 09:35
Last modified:Monday, September 7, 2020 - 14:00
The other day I was debugging a Foldit LUA recipe with lines like below in it:

jn,jca,jc,jo=1,2,3,4 -- backbone atoms N,CA,C,O have atom #'s 1-4 respectively
tryb=band.Add(nmid,nmid,nmid,0.001,0,0,jca,jc,jn)
-- The above uses atoms on residue nmid to set up xyz coordinates for 
-- a band to space. Here, nmid's CA is the origin, nmid's C is along 
-- the +x axis, and nmid's N lies in the xy plane with N having y>0. 
-- The band to space will be from nmid's CA to 0.001 A along the +z axis.
--
-- 12/11/18 You can't have the segment for the origin & +x axis 
-- be the same, even if you're using different atom #'s.

I got a message about needing different segment #'s for the origin and 
+x axis (here both the same, namely nmid), but the atom #'s I chose for 
the origin, +x axis, and y axis were all different (namely, nmid's 
alpha-carbon CA, backbone C, and backbone N). Seems like band.Add was
being a little too picky about when it would work. Shouldn't it be 
enough to specify 3 different non-collinear atoms (like N,CA,C in 
the protein backbone, which generally form an angle around 111 degrees,
making these 3 atoms non-collinear) to set up the xyz coordinates for a 
band to space? Why must all the atoms be on different amino acid segments?

Also, I used the 0.001 A distance along the +z axis because I suspected
band.Add would fail if I used 0 instead. It would be nice if 0 instead 
of 0.001 would let band.Add work here, after all, my goal was to make 
a zero-length band to space.

I was able to work around the case above, but it cost me time and wasn't 
as intuitive or simple as I originally intended. I would appreciate it
if you let band.Add accept a wider variety of inputs.

See http://foldit.wikia.com/wiki/Foldit_Lua_Function_band.Add for details.
(Thu, 12/13/2018 - 09:35  |  4 comments)


jeff101's picture
User offline. Last seen 11 hours 43 min ago. Offline
Joined: 04/20/2012
Groups: Go Science

While the above changes shouldn't hurt any code already written
using band.Add, if you decide to tinker with band.Add, I think
band.Add would be more intuitive if the 3 segment (and atom)
indices were for the origin, +z axis, and x>0 direction. This
way when you use the standard spherical coordinate angles
theta & phi, you know right away which direction the +z axis
(theta=0) is. You also know that varying phi from 0 to 2*pi
(0 to 360 degrees) will rotate around this axis. It is also
easy to have the band direction form a cone around the +z axis
(just fix theta and vary phi from 0 to 2*pi).

Using theta and phi to rotate around the +x axis is doable
(fix phi at pi/2 (90 degrees) and vary theta from 0 to 2*pi),
but making a cone around the +x axis is tricky.

Rotating around the +y axis is also doable (fix phi at 0 and
vary theta from 0 to 2*pi), but making a cone around the +y
axis is tricky.

Of course, changing the input order for band.Add to the origin,
+z axis, and x>0 direction could mean many players would have
to overhaul recipes they have written using band.Add. Would
the change be worth it?

jeff101's picture
User offline. Last seen 11 hours 43 min ago. Offline
Joined: 04/20/2012
Groups: Go Science

Maybe you could have 2 versions of band.Add available:
the original (which one might call band.Addoxy) plus a
new version called band.Addozx. band.Addozx would have
the segment order be origin, +z axis, then x>0 direction.

jeff101's picture
User offline. Last seen 11 hours 43 min ago. Offline
Joined: 04/20/2012
Groups: Go Science
Letting the 3 segment #'s in band.Add be the 
same if the 3 atom #'s are different would help 
in ligand puzzles where we might want to measure
or control the distances between certain parts
of a flexible ligand. It would also help us 
control better the positions of flexible 
sidechains.

A similar request would be to let 
bnum=band.AddBetweenSegments(seg1,seg2,atom1,atom2)
create the band # bnum between 
atom # atom1 on segment # seg1 and 
atom # atom2 on segment # seg2, 
even if seg1 and seg2 are the same.

Yet another request would be to let
dist=structure.GetDistance(seg1,seg2,atom1,atom2)
return the distance dist between 
atom # atom1 on segment # seg1 and
atom # atom2 on segment # seg2.
If seg1==seg2 and atom1==atom2, 
it could return dist=0. 

While we could also use
bnum=band.AddBetweenSegments(seg1,seg2,atom1,atom2)
dist=band.GetLength(bnum)
to return the distance dist, it seems faster to use 
dist=structure.GetDistance(seg1,seg2,atom1,atom2).
jeff101's picture
User offline. Last seen 11 hours 43 min ago. Offline
Joined: 04/20/2012
Groups: Go Science
It would also help to let both
dist=structure.GetDistance(seg1,seg2,atom1,atom2,sym2) 
and
bnum=band.AddBetweenSegments(seg1,seg2,atom1,atom2,sym2)
dist=band.GetLength(bnum)
work intuitively when the sym2 variable is included.
sym2 is the monomer # for atom # atom2 on segment # seg2.

It might even help to add the monomer # sym2 variable to
band.AddToBandEndpoint
so one could do something like below:
bnum1=band.Add(seg1,segx,segy,rho,theta,phi,atom1,atomx,atomy)
bnum2=band.AddToBandEndpoint(seg2,bnum1,atom2,sym2)
Here, band # bnum1 would be from the main monomer's
atom # atom1 on segment # seg1 to a point in space
at rho,theta,phi in spherical coordinates where
seg1 atom1 is at the origin, 
segx atomx is along the +x direction, and
segy atomy is in the xy plane with y>0.
Also, band # bnum2 would be from monomer # sym2's
atom # atom2 on segment # seg2 to the space-end
of band # bnum1.
Sitemap

Developed by: UW Center for Game Science, UW Institute for Protein Design, Northeastern University, Vanderbilt University Meiler Lab, UC Davis
Supported by: DARPA, NSF, NIH, HHMI, Amazon, Microsoft, Adobe, RosettaCommons