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:Saturday, December 15, 2018 - 07:21
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  |  2 comments)


jeff101's picture
User offline. Last seen 5 hours 17 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 5 hours 17 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.

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