Shaky Shake

Case number:845813-675401
Topic:Game: Tools
Opened by:xiando
Opened on:Wednesday, December 10, 2008 - 15:55
Last modified:Tuesday, June 14, 2011 - 22:44

I'd like to suggest that the developers look closely at the shake function. There seems to be a slight problem in the way it does it's job. I've noticed that often times, when shake is executed, it moves side chains into positions which are less suitable than they ought to be.

For instance, I just performed a manual side chain "tweak" (not to be confused with the misnamed function) followed by a shake. I *know that the deviation should not have been nearly ten points, and yet that is exactly what shake delivered, a score 10 pts less than it should have been. CTRL-z and CTRL--b showed that shake had put the side chain into a position one discrete step away from where it should have fallen had the function performed correctly. Manually moving that side chain to it's proper position resolved the issue and the score increased slightly from it's original, instead of dropping 10 pts.

The problem, as I see it, is that this error might deceive or confuse the player from what otherwise might be an improved model.. Since there is no directional indicator to show the trending for a sidechain/residue, it is encumbant on the program to faithfully resolve side chain clashes so the user can accurately visualize the trending in his/her mind. I think I speak for the majority of users in saying that we've come to believe that shake will do it's utmost best to resolve side chain conflicts accurately, but a false ten point drop is not accurate at all, since the clash actually produced a ~0.2 pt increase when the side chain was rotated to completion manually...Perhaps it's a resolution issue, not sure, but either way it'd be nice if you took a look at whatever thresholding/rounding that's being used for the discrete (or otherwise) side chain rotations during shake...

In fact, I find often that shake produces results far below what I expect, ie, I mutter to myself, that makes no sense at all..and then hit ctrl-b, or repeatedly crush the protein to attempt to reclaim the lost points...I now suspect that it may have been unnecessary work on my part owing itself instead to an error in the shake command.

As a suggestion for where to look, 'm not sure if you have a comparing function that examines nearby rotations for their suitability, but it might be of some benefit if it isn't being used...that is

Suppose R = F(x)

where R = the new side chain rotation F(x) is the shake function applied to a given side chain and R is the new rotation index for that side chain.

(ignoring micro rotations for this illustration)

Since you likely have the discrete rotations indexed (or should?), then

then let A= E(R1), B=E(R2), C=E(R3) where R2 and R3 are the i-1 and i+1 rotations of this side chain

Case E
A; R=R1
B; R=R2
C; R=R3

Seems like this or something similar might resolve the problem. A simple check of nearby elements for better fit. And Although it might make shake take just a little longer, I'd personally rather have the delay than to have to manually check every side chain for an accurate shake value...

The problem can be forced by adjusting a side chain to a position in which no points are garnered or lost during subsequent wiggle, then resolve using shake. while it is not every time, Im find that I can cause the problem to occur with alarming regularity


(Wed, 12/10/2008 - 15:55  |  5 comments)

axcho's picture
User offline. Last seen 10 years 2 weeks ago. Offline
Joined: 12/18/2007
Groups: None

Wow, I didn't realize that Shake was less than optimal in that way. Thanks for bringing the problem to our attention. I'll ask about it, and see if we can fix the tool to actually work as it's supposed to.

Joined: 05/19/2008
Groups: None

Yes, shake sometimes lowers the score.

I think we should save that particular state of the puzzle and send it in for evaluation. Stochastic bugs are very difficult to discover otherwise.

Do we have a public method of sending in a particular file for investigation?

xiando's picture
User offline. Last seen 7 years 14 weeks ago. Offline
Joined: 10/19/2008
Groups: Oma Gawd

The problem is easily reproducible in the lab, so I'm not sure any file sends are necessary. Now that I recognize it, I see the error often, but I believe the code can be massaged to avoid the error by use of the technique (or a similar method to) that I outline above. Being a programmatic error, it will occur in every puzzle, not just a "weird" situation.

fwiw, it *appears to occur with more frequency as the puzzle grows more compact. (to assist developers in reproducing error)

admin's picture
User offline. Last seen 40 weeks 3 days ago. Offline
Joined: 11/10/2007
Groups: vi users
Topic: » Game: Tools
Status: Array » Open
Type: Array » Bug

Set details.

Joined: 06/17/2010

Shake is using Monte-Carlo algorithm, it is impossible to calculate all ss positions in "real" time when shake. Should be closed?


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, Boehringer Ingelheim, RosettaCommons