Scripting: get_score() after do_sidechain_snap() frequently returns previous score

Case number:845813-989793
Topic:Game: Tools
Opened by:wld333
Status:Open
Type:Bug
Opened on:Tuesday, May 31, 2011 - 04:16
Last modified:Tuesday, May 31, 2011 - 14:37

I've written a script for examining multiple mutations and sidechain positions for Puzzle 425. The innermost loop of the script repeatedly snaps sidechains into their various positions and then immediately checks the resulting score.

Quite often, it appears that the sidechain snap instruction has not been completed by the time the score is checked. The score in the game window changes, but the score returned to my script (which I've written to the output window to verify) is the same as the score before the sidechain snap. It's definitely not an issue of snapping to the current position. The score is sometimes an improvement (those are the ones I notice, because my script is trying to find those (!) and misses them when this occurs).

Is this possibly a multiple thread issue? I'm fairly new to LUA scripting, so I don't know if there are ways to ensure that one instruction has been completed before the next is executed.

I'd be happy to provide further information if you can tell me what would be most helpful to you.

My apologies if this issue has been raised before. I didn't find anything similar in my search of the feedback database.

Thanks!

(Tue, 05/31/2011 - 04:16  |  4 comments)


Joined: 12/27/2010
Groups: None

I suspect there is just a disconnect between the graphics and the actual position. I have noticed this before in other scripts where the graphics sometimes takes a while to catch up.

cjmarsh's picture
User offline. Last seen 2 years 25 weeks ago. Offline
Joined: 05/21/2011
Groups: Go Science

You could add a break in your logic loop that arbitrarily introduces a delta t, allowing the computations to catch up with your recipe at the expense of speed. Not a great solution, I realize, but it might fix the problem for now. Nice idea for a script btw, how did you implement the location information of the segments?

wld333's picture
User offline. Last seen 7 years 11 weeks ago. Offline
Joined: 02/15/2011
Groups: foldeRNA

It's not just the graphics. It's the numerical score appearing in the game window. For example, I can be on a local max of 7698. Suppose the previous sidechain snap resulted in a score of 7434. I then see a 7701 flash on the game window, but my script again records a 7434. The 7701 never registers, not even as a recent best.

Is the 7701 actually an intermediate score that somehow occurs during the sidechain snap but isn't valid at the end? And why would the ending score in these situations always be exactly what it was for the previous iteration? Can a sidechain snap "fail" silently despite the segment index and position being valid? Developers?

wld333's picture
User offline. Last seen 7 years 11 weeks ago. Offline
Joined: 02/15/2011
Groups: foldeRNA

CJ, thanks for the delta t idea. I had thought about grabbing the score twice to see if that would work.

My script is recursive (ugh!), with a level for each new segment examined. The nice new 100 saveslots are great. I just save each recursion level's best pose with a quicksave to the corresponding slot. Is that what you meant by location information of the segments?

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