Happy Monday, folders!
We are genuinely pleased to announce the return of regularly scheduled developer and science chats. For the rest of 2014, we have currently scheduled chats for the following dates:
August 19 1400-1500 Pacific (or convert to your time zone here).
October 16
December 2 (to get one more in before the holidays)
While we will likely be adding others to our roster as needed (in the event of exciting collaborations and the like), you should definitely get your questions ready for August 19 and post them in the comment thread to this post. We'll be starting our chat with questions on this thread before opening up the floor for more, so make them count!
Is high wiggle power necessary?
Personally I find having to run a second set of settlers is mostly just tedious.
There doesn't seem to be much room to make pose changes and everything takes forever, so it is often really just what you ended up with on medium being walked to death again on high.
It can take a day or more to eek out a few points (after the initial jump) and means you need to run more clients, thereby excludes some players and on the surface doesn't seem to add any science benefit. Just asking, and of course other folder's experiences may be quite different.
On a recent puzzle, I got a ludicrous number of points (> 200) just on medium wiggle, but it took all day, with local wiggle giving < 0.001 points per iteration. The overall shape of the protein didn't seem to change at all. Is ideality doing what it's supposed to, or is it just lowering the score without reflecting changes in the structure?
Another thing that is really frustrating is that I am getting steady points, and I stop it to do something, say, restore SS so that my (imminent) best score isn't all loops. And when I restart wiggle, it just sits there. One good recent change is the iteration counter, because now I know that it's not sitting there thinking, it's sitting there doing nothing. Wiggle, stop, restart = frozen protein. I can get it started again by changing the clash importants but at endgame this doesn't work…I lose points permanently, or work per iteration drops to zero once I bring it back to 1.0.
Just wanted to clarify that on medium you can still successfully change the pose, which is almost impossible in my experience with high wiggle.
In your example you were not changing the pose but you may have been doing a heavily banded contact puzzle which you finally 'released' on medium.
I recall one recent contact puzzle which would not fuse on medium, it required walking on medium and gained the usual number of points when changing from low wiggle.
New contact puzzles are great 'but' - I do find that the visual intensity of the red and green bands is a bit too dominant.
Visually it seems to me to shift the visual focus to the bands rather than the backbone.
Don't know how to fix it or if anyone else agrees - 'can't see the wood for the trees' especially when there are a very large number of contacts.
I would very much like to see some of the following Feedbacks implemented:
http://fold.it/portal/node/996831 have LUA commands to set and get the wiggle power
http://fold.it/portal/node/998063 let players designate models/tracks that are still improving to be automatically shared with scientists when a puzzle ends
http://fold.it/portal/node/997645 let players use arrows to skim through the Notes for each amino acid
http://fold.it/portal/node/996372 have one-directional bands (like bumpers) for Contact Map Puzzles
http://fold.it/portal/node/993966 have LUA commands like band.SetNote and band.GetNote
Thanks again,
Jeff
The ability to open and close cuts in a script has opened up a number of new possibilities. A few functions seem to be missing, however.
First, when deleting a cut, there's no way to tell whether the cut was closed. If the cut ends are too far apart, the cut won't close. As a remedy, structure.DeleteCut() could return true if the cut was deleted, and false otherwise. (Likewise, structure.InsertCut() could return false if a cut is already open….)
Second, there's no way for a script to determine the number of cuts and their location. A call structure.GetCutCount() could return the number of cuts, and structure.IsCut ( segment ) could indicate the presence of a cut. These additions would allow scripts to work with existing cuts.
Third, there should be a way to determine how far apart the cut ends are. A function structure.GetCutLength ( segment ) could return this information, or nil if there is no cut present.
Fourth, as the proposed calls above tend to show, a "cut" pseudo-class might be added, similar to "band". The calls cut.Insert() and cut.Delete() would be included, and structure.InsertCut() and structure.DeleteCut() could be deprecated, but still supported. The new functions could be added to "cut".
These four steps would lead to better solutions. Currently, some high scores get "stuck" with an open cut. The cuts could be easily closed by familiar scripting actions in most cases. At present, a script can't detect the open cut. Manually detecting and correcting this condition means lost hours and missed opportunities.
Selecting all contacts in the contact map tends to result in "too much information" to be useful. Manually selecting individual contacts is time-consuming and error-prone. (It's easy to accidentally select points that are not in contact.)
A script can find contact points and band them. The bands can then guide manually or scripted folding. For manual folding, however, the bands present problems. It's easy to close a band by accident, and bands take up more space than the "selected contact" lines.
A new contactmap function, contactmap.Select ( segment1, segment2 ) would allow a script to select a contact, similar to clicking a cell on the contact map. The function could return boolean, integer to indicate whether the two segments are in contact (false if no contact) and the heat of the contact.
A complementary function, contactmap.Deselect ( segment1, segment2 ) should be included to undo the select. Similarly, contactmap.DeselectAll () might also be useful.
Just for logical consistency, contactmap.SelectAll ( noContact ) might be included, where noContact is boolean, true indicating that only point not already in contact should be selected, and the default false indicating that all contacts should be selected.
A function contactmap.GetDistance ( segment1, segment2 ) might be provided as convenience, although this information is already available to scripts through other calls.
Wishlists are great! (Hopefully you've posted these in the feedback section as well.) Do we have some actual shorter questions we can address too like the high wiggle power and hidden points?
