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