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
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
-- 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)

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?

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.

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 

A similar request would be to let 
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
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
to return the distance dist, it seems faster to use 
Joined: 04/20/2012
Groups: Go Science
It would also help to let both
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
so one could do something like below:
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.

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