Shaky Shake

[xiando]

Hi,

I'm re-posting this since it appears to have been deleted during the forum switchover… If it has been addressed, please forgive the duplication.
…

I have been noticing that the Shake command is resulting in repositioning that is far less than optimal.

As a "Tweaker", I have a certain reliance on shake doing the post optimization of side chains in as accurate a way possible to ensure that the score is not adversely (and incorrectly) altered.

When Shake resets a side chain to a position that is not an optimal minimization, it both reduces the subsequent score AND worse, it lowers my confidence that my move or thinking was "right", which leads to unnecessary and undeserved self-doubt about the direction in which I am taking the puzzle or my folding technique in general for subsequent work.

I am finding that about half of the time I use shake following a manually forced clash and wiggle, (ie tweaking) the return position of the side chain following shake is at least one discrete rotational position away from its "best" placement.

I believe the problem can be remedied by comparing the Energy of positions to each "side" of the function's nominal output for the affected side chain with that of the nominally calculated position and taking the best value to select its rotation… (that is, if the function output says rotate to discrete rotation phi,, ie rotation index N, then check the N-1 and N+1 rotations to see if they result in a better value…)

Admittedly, there may be a finer issue in the allowed delta phi, but still the general idea should be clear, and I have no real idea of the code specifics, so I have to use generalities…

I believe I speak for most players in saying that I would rather have a more accurate, albeit minimally slower, Shake command than to have the situation described above. It's not going to slow down that much, as shake is relatively fast already and the other two E-calcs and compare should not load the command too heavily, ie add inordinate time to its operation.

thank you

[jas0501]

I think the situation is a bit more compicated. You have detected a sidechain that is off by one. At the time it was evaluated one can assume the the final position was optimal. The rub is any other side chains "in the vicinity" contributes to the positioning. The order of sidechain evaluation will result in different optimal settings for individual sudechains.

I have not a clue as to how it is implemented. The issue of "in the vicinity" is a hard one. If a sidechain has 10 others "in the vicinity" and you want to check the position on either side then there are 2^10 more evaluations for your suspect sidechain, or 4096 possible alternate configs. These numbers may to be spot on but you get the idea. The permutations are immense.

You might consider locking the sidechain and doing a shake to see what the resulting score is. The ripple effect of that particular position could ultimately lower the overall score after a shake. Or it may not.

[axcho]

I had talked with Seth about this a while ago, and he didn't seem to be very familiar with the inner workings of the Shake action either. I agree that the issue is very important. I'll see if I can look at the Shake code and come to any conclusions about it.

[xiando]

It was not always like this…It seem to have become unstable very recently…while I had seen the behavior in the past, it is now routine.

And thank you for adding it to your enormous list of things to do… sorry for the added task but it can't be helped.

[xiando]

Following a minor discussion in chat this evening regarding my hypothesis on this issue, I am posting to clarify what I know about shake, as forwarded by members of the development team in global chat early on in the beta release…My understanding of shake is that it seeks to minimize conflict between side chains. A direct result of "minimizing " conflicts is the inverse of conflict, ie, locally maximized score for the target residue, and associated with the optimized positioning of the side chain for the current deformation.

Since each side chain has N discrete rotations, and discounting any potential non discrete variability (delta-phi) within those discrete values, Shake *should result in a side chain being at its optimum location following the shake command. Therefore, any side chains that when examined manually can be rotated manually to a new discrete position which results in an immediate score increase indicates failure of the shake command.

I would appreciate a comment regarding the issue, from the developers (Seth, Axcho, etc.) responsible for the program's "innards", even if it cannot be addressed at this time.

[xiando]

I realize that things are not as simple as the very basic setup I indicated Jas501, and I am fully aware of the affects of ALL of the side chains upon one another.. As I suggested in the content above.

I am not a clueless newbie, but a seasoned veteran in the use of this application, hold a physics degree, and in tandem with other duties as an electrical engineer have been programming embedded and higher level applications in the commercial and research world professionally for over twenty five years. This is not said without thought or careful examination of the operation.

However, regardless of your protestation, the issue is still valid.

As you say, you have no idea how it was implemented. This is a real issue, and it causes problems not only for me but all users, whether they are observant enough to see it or not.
When a fundamental tool does not work correctly, it negatively affects all users. And Shake is just such a fundamental tool.

Side chain tweaking is also a fundamental tool, used not only in the manner in which I generally *choose to use it, but also for fine tuning of the backbone…There were several puzzles proferred by the developers to that very end during the lead up to CASP8 to teach the method, and they have, among other things, set a precedence that cannot be discounted..

Further, were the situation as simple as you put it, then when a rebuild is performed, or a rotate or optimize, or in fadct any operation was performed, then a subsequent shake should not be expected to produce consistent results, ie side chains moving to predictable locations based on clash minimization…this is imo, a ludricrous stance, as it obviates the usefullness of Shake.

[xiando]

did a manual tweak using #25 Arginine as forcing side chain in puzzle 115. shake brought #25 back two positions from where it should have been…looks like the compare needs to do something wider than just N-1 and N+1

[Rav3n_pl]

Shake can`t check every possible combination (that would take like… forever?).
It uses Mote-Carlo so in some cases not hit in 100% best position.
Closing.