Devprev: autosaved score loads lower

Case number:954892-994713
Topic:Developer Preview
Opened by:Timo van der Laan
Status:Open
Type:Bug
Opened on:Wednesday, March 13, 2013 - 17:05
Last modified:Friday, March 15, 2013 - 19:23

When I got home today, laptop hangs. Restarted devprev (was already using the new version) and loaded slot 3. The score on that autosave was 11881, but when loaded it loaded as 11841. And I am sure I was running with all the filters on. The scriptlog from that session also showed 11881 as the score I had reached.
Puzzle 682, I shared the quicksave with myself.

(Wed, 03/13/2013 - 17:05  |  7 comments)


Joined: 09/21/2011
Groups: Void Crushers

Doing a small wiggle, 40 pts came back, reloaded the best score, 40 pts loss again. It looks like when loading the core filter is not functioning properly.

Joined: 09/21/2011
Groups: Void Crushers

Same thing happens in main with this solution

beta_helix's picture
User offline. Last seen 1 day 22 hours ago. Offline
Joined: 05/09/2008
Groups: None

thanks again for reporting this, can you save one of these solutions for us?
assigning...

Joined: 09/21/2011
Groups: Void Crushers

I did share the Quicksave 3 solution with myself

tamirh's picture
User offline. Last seen 6 years 9 weeks ago. Offline
Joined: 05/11/2012

Could you let me know if the steps I'm taking are not what you meant. I'm not seeing a bug with the steps I'm taking to repro the issue. It is possible the saved score was out of sync with the pose that was saved...

1) I deleted all of my autosaves for 682.
2) I loaded up the puzzle and tried Restore Very Best to make sure there wasn't anything there, it restores to the initial configuration
3) I loaded in your solution which scores as 11841
4) I Restore Very Best and it stays as 11841
5) I wiggle for a short time and the score changes to 11881 because of the core existence bonus
6) I Restore Very Best and it stays at 11881

I've tried various other actions after loading in your quicksave to see if it changes anything. I've wiggled sidechains, turned the 'disable slow filters' on/off to force Foldit to rescore everything. It doesn't change the core existence bonus. I've checked in the code and it's definitely running through that filter.

For the 11841 score, it is considering these residues as core:
4, 8, 11, 15, 18, 22, 25, 29, 32, 36, 45, 52, 56, 59, 63, 66, 70, 73, 77, 86, 90, 93, 97, 100, 104, 107, 111, 114, 118

For the 11881 score, it is considering the same as core plus 39. The wiggle changes the backbone enough so that one residue goes from not being considered to being considered in the core.

If I'm missing the issue, then could you clarify what you meant by the bug? Thanks

Joined: 09/21/2011
Groups: Void Crushers

If you look at the starting one it says that it's score is 11881. Loading it makes the score 11841.
Just a short wiggle makes it 11881 again and if you stop it immediately (but maybe your computer is faster than mine) and load the best the score is back at 11841 again.
In any case, the score of the quicksave file 11881 is not the score you get when you load it.
I havent seen this behavior at other save files.
Could it be that this is caused by rounding or precision issues that make the loaded file just enough different that the filter does no longer see 39 as being in the core?
In any case changing the priority to 3 as nobody else is reporting this.
(My OS: windows 7 64 bit)

tamirh's picture
User offline. Last seen 6 years 9 weeks ago. Offline
Joined: 05/11/2012

That seems like a reasonable explanation. I will check the actual values of the pre-save and post-save atom positions to see if it's the issue. Thanks.

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