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 14 hours 28 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 14 hours 28 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