Suggestions about Centroid Puzzle

Case number:699969-995055
Topic:General
Opened by:Susume
Status:Open
Type:Suggestion
Opened on:Tuesday, April 30, 2013 - 01:45
Last modified:Saturday, October 19, 2013 - 12:29

The spheres make the backbone very hard to see, but if I turn them off I can't find the matching piece of guide. It would be helpful to have "show stubs" available as a compromise - so we could see backbone and some generic version of the sidechains simultaneously.

(Tue, 04/30/2013 - 01:45  |  33 comments)


alwen's picture
User offline. Last seen 5 days 14 hours ago. Offline
Joined: 10/03/2011

The blobs (they look like ticks, ugh) obscure the structure, but if they are turned off, there is no way to see where they are on the guide.

With this large of a puzzle, when I zoom out so I can see the guide & protein at once, the guide is so far away from the protein that by the time I move my mouse over to adjust a band, the guide blobs have turned back off already. I don't want them to persist forever, but they need to show long enough to be useful.

beta_helix's picture
User offline. Last seen 2 days 5 hours ago. Offline
Joined: 05/09/2008
Groups: None

Thank you both for your suggestions.
We know there are going to be a lot of things that need to be changed for centroid mode, and we'll try to address them as quickly as we can.

Please make sure you have read tamirh's blogpost about centroid puzzles (if you haven't already):
http://fold.it/portal/node/995050

We tried to address the feedbacks we got for the centroid puzzle in devprev (thank you to everyone who reported bugs with that one) but we realize a lot more people will be trying it out now, so we thank you in advance for your patience.

Joined: 11/16/2012

If you execute a GUI script in centroid mode that uses the "shake sidechains" function, the script executes that function for a long time (indefinitely?), doing nothing, until you hit the space bar to stop the function and allow the script to continue. All GUI and LUA functions such as shake sidechains, mutate, etc. should return immediately if executed in centroid mode.

steveB's picture
User offline. Last seen 2 years 48 weeks ago. Offline
Joined: 01/08/2009
Groups: Void Crushers

With the lack of sidechains, the wiggle functions has very little effect on this puzzle. This means that the only way to change a section of the puzzle and gain points is to rebuild, which on a QTTN is counter productive, as you end up diverging from the original shape.

Without an effective wiggle function I can't see that it would be possible to get anywhere near a native structure on a de-novo puzzle using this format.

Agree with the above posts that the bubbles are way too big.

Also would like to add that this puzzle is not that much fun to play either - too few tools to use on it, and no natural feel to the puzzle's movement (if you are lucky enough to get it to move at all).

Bug ?
If you isolate a section of segments by freezing either side of them, and then wiggle these segments, the rest of the protein also moves. Is this a bug, or a feature of the centroid system ?

alwen's picture
User offline. Last seen 5 days 14 hours ago. Offline
Joined: 10/03/2011

I've played with this a little this morning.

I knew local wiggle and wiggle did different things, but this was pretty drastic.

I've saved and uploaded for myself two solutions, CutRebuildBeforeWiggle and CutRebuildAfterWiggle (local wiggle).

Before:
http://fold.it/portal/files/chatimg/irc_343528_1367336294.png

After local wiggle:
http://fold.it/portal/files/chatimg/irc_343528_1367336118.png

Local wiggle destroyed the helix.

bertro's picture
User offline. Last seen 3 weeks 4 days ago. Offline
Joined: 05/02/2011
Groups: Beta Folders

from alwen's comment above:

"I don't want them (guide blobs) to persist forever, but they need to show long enough to be useful."

Suggestion: I would like to add that a way to adjust the ON and OFF timer lengths for showing/hiding the "guide blobs" would be appreciated. Sometimes, I like it short and at other times longer.

Thanks

Susume's picture
User offline. Last seen 8 hours 17 min ago. Offline
Joined: 10/02/2011

Once you add a band to a blob, that blob never disappears even when show sidechains is off - this is standard behavior. Unfortunately, once the band length becomes zero, you can never see the band to click it because the blob covers it up. Even in line view the blobs stay fat and blobby and in the way. One solution might be to make the blobs semi-transparent (or let us turn them into stubs as mentioned earlier).

Joined: 05/03/2009
Groups: Contenders

I'll add a comment to Susume - yes, if you band from the individual segment centroid, the centroid will persist on-screen, so that when you waft a mouse over it, you'll see the corresponding guide shadow, which is helpful.

But, when banding, you're aiming for the middle of the guide segment. The centroids are off-set to the edge of a segment when you 'shift a' in the displaying of them, so that needs to be fixed

CFC

gitwut's picture
User offline. Last seen 37 weeks 6 days ago. Offline
Joined: 05/18/2012
Groups: Contenders

Being able to disable blob view entirely and band in stub view would perfect, if possible. Susume may have been implying this, but I'm not sure. I don't see any advantage to blob view at all. I think QTTN banding to sidechains (stubs) would be much easier and accurate than banding to blobs or segments.

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

Thanks for all of the comments about centroid mode. We know it's very different and we appreciate you guys playing with it and finding issues with it. I'll try and address all of your comments as best I can:

* Stub mode: I think having the spheres show up differently in stub mode is a good idea. Perhaps they will just be smaller, or we might think of a different way of visualizing them. We will do something about this.

* Sidechains on guide: It would be good to have this time in options.txt or as a GUI editable value. We might add something like this.

* AA Coloring: This is kind of separate from centroid mode, but it may help. There was a request to be able to color the backbone based on AA. That change has been implemented and should go out in the next version.

* Shake in scripts: We've fixed this issue. It hasn't made it to the released version yet. It will be in the next update.

* We're looking into if we can add more scoring terms that are compatible with the approximated sidechains to get wiggle to behave closer to what you guys have gotten used to in normal puzzles. Centroid puzzles are inherently different though, so wiggle (and other tools) will always be different.

* We will look into some way of dealing with 0 length bands.

* The amino acid spheres are intentionally offset to the position where the sidechain approximation origin is.

Joined: 09/21/2011
Groups: Void Crushers

When closing cutpoints I normally use local wiggle to get the backbone better But local wiggle is not local anymore. It moves big structures outside the selected piece. Making this kind of puzzle extra extra hard. What I reported as weird behavior is endemic in this puzzle.

Joined: 09/21/2011
Groups: Void Crushers

Clashing score is not shown in the segment scores. Is that an other score component now?

Joined: 09/21/2011
Groups: Void Crushers

Also I dont see any bonding info in the segment scores. Even when bonds are clearly visible.

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

We're looking into the local wiggle issue.

The score terms for clashing are no longer computed in centroid mode. The same with bonding, those score terms don't exist so there is nothing to show.

We will be adding in some new score terms to the centroid puzzles in the future that should cover the bonding issues (but not the clashing terms as those require the full atom mode as of now).

Joined: 12/06/2008
Groups: Contenders

Wiggle doesn't work. Rubber bands don't work. Clashing doesn't work. We're not allowed to touch sidechains. And yet the puzzle is still too complex for most computers to handle.

Total fail.

Throw this idea of centroids in the garbage --- where it belongs --- and give us a real puzzle.

Seriously. This is offensive. You will frustrate countless players into quitting the game. Stop shooting yourself in the foot.

Susume's picture
User offline. Last seen 8 hours 17 min ago. Offline
Joined: 10/02/2011

In a normal puzzle, scoring generally tends to keep helixes intact even if they are changed to loop before rebuilding - for example, DRW changes all to loop by default and chooses rebuilds based on score, and the helixes keep their shape more often than not. In this puzzle, the rebuilds of helices that win the scoring race are often ugly and very un-helix-like - see http://fold.it/portal/files/chatimg/irc_341210_1367633602.png (shared to myself with slightly higher score under name "ugly helices")

You might want to examine the scoring and see if it is really giving you good backbone shapes.

When you check to see if we were able to match the guide, I suggest looking at lower scoring, earlier solutions - my guess is the high scoring ones started out as good matches (and therefore realistic looking proteins) but wandered far from the guide in response to score.

alwen's picture
User offline. Last seen 5 days 14 hours ago. Offline
Joined: 10/03/2011

One major difference in the Centroid puzzle compared to regular guide puzzles:

In a regular guide puzzle, I can use shake to see how close I have my protein's sidechain aas to the guide. Turns out I used that more than I knew to judge how I was matching it.

In the Centroid puzzle, if I'm not hovering over the protein's blob, I can't see the guide blobs. There is no Shake equivalent that turns all the guide blobs on at once the way Shake did.

LociOiling's picture
User offline. Last seen 3 hours 24 min ago. Offline
Joined: 12/27/2012
Groups: Beta Folders

Puzzle 705 seems to call for lots of bands, and banding is difficult. With all the blobs, it's hard to see the target blob on the guide. Then you must rotate the view multiple times to get the band to the right spot. Usually you delete the band a couple of times by accident, and need to Ctrl-z to get it back.

Starting a band on a blob, then shift-D to hide all the rest of the (non-banded) blobs, makes banding somewhat doable, but it's still a chore.

I don't see the gain for science in what amounts to a struggle with the user interface. It seems like the interesting question is which segments to band in what order. Lots of folders have proved their ability to create a band from point A to point B despite the difficulty, so lets file that and move on.

Suggestion #1, provide a right-click context menu with a "band to guide" option. In centroid mode, a blob-to-blob band would be sufficient. Fine-tuning is left to the user.

Suggestion #2, make bands a little easier to handle. Eliminate the click-to-delete option, or make it a separate setting. You can still delete the band via its right click context menu or a global "r". If you must keep click-to-delete, make the head of the band larger and give it a safe collar to cut down on accidents.

Suggestion #3, add a note that can be displayed outside of note mode. I'm thinking of something like placemarks in Google Earth, where each placemark can be turned on or off independently. Allow placemarks on the guide as well. The placemarks could reside in a collapsing section of the cookbook.

Suggestion #4, extend the "band to guide" option, offer a "band to placemark". One possibility is to make this a context menu option on an existing band. Creating a short band to start is not a big issue.

Suggestion #5, add a "go to segment" option. Perhaps it could be added to the score box. (Or maybe just as a "g" keyboard shortcut.) As a bonus, display the number of segments in the score box. Perhaps add a toggle which would display numbered placemarks every five or ten segments.

A more powerful user interface seems a reasonable requirement for more complex puzzles.

Joined: 11/16/2012

Working on 709 after 705 is very instructive. Rebuilding a helix (all loops) goes through a similar series of poses in both puzzles. Those same weird (non-helix) poses that gain points for 705 score negative 5 figures (e.g. -30000) points for 709 and are rejected. Rebuild destroyed the helices and sheets in 705 whereas secondary structures are maintained and improved by rebuild in 709. Of course, the problem is not with rebuild which is just an optimizer and is doing its job. The centroid-mode scoring function is creating a bad error surface.

mimi's picture
User offline. Last seen 33 weeks 2 days ago. Offline
Joined: 11/17/2008
Groups: Contenders

I usually do the same as silverberg but in this case with the protein mostly so far from the guide, I aligned the guide to one helix and then by mostly pushing and pulling at CI0 and freezing and rebuilding bits with a few bands I ended up with something close to the guide. I then created the rest of the bands and wiggled the result in whole and part till it reached a stable state.

What I really REALLY wanted was the ability to create zero length bands - which you can't do in GUI

Angus's picture
User offline. Last seen 1 hour 38 min ago. Offline
Joined: 06/04/2008
Groups: Beta Folders

I think everyone should collectively completely ignore these new puzzles. Impossible to work with.

wiggle doesn't work
behavior has no effect
backbone wiggle (Y) doesn't work
of course, no shakes work
can't use Rebuild in GUI recipes, so that's out
can't pull, then wiggle back, just sits there looking stupid

and probably a lot of other issues I can't remember because I'm too pissed off about it.

Joined: 12/07/2011
Groups: None

This centroid puzzle is an entirely new thing.
For us to help science, we should try to handle bigger proteins at the current technology available.
Foldit should not be confined to small proteins.
We should try to evolve our techniques and scripts to make this possible.
I think this will improve with more feed back and with more time.
We should give it a chance.

steveB's picture
User offline. Last seen 2 years 48 weeks ago. Offline
Joined: 01/08/2009
Groups: Void Crushers

A suggestion :

I can see why centroid puzzles are going to be useful, to manipulate large proteins, and I am sure you will get them working well over time, but for now why don't you release smaller puzzles (normal foldit size with max 200 blobs) in centroid format whilst you are ironing out the problems.

jflat06's picture
User offline. Last seen 11 hours 53 min ago. Offline
Joined: 09/29/2010
Groups: Window Group

Thank you all for your feedback.

Centroid mode is a tool from Rosetta that has been empirically shown to be useful in certain situations. With that in mind, we are interested in adapting it for use in Foldit. Doing so isn't trivial - there will be issues both with the code and with player strategies while using the tool.

Running this puzzle has given us insight into a lot of issues that did not present themselves in the developer preview release of centroid mode. We will be working on resolving these issues for the next release.

Joined: 04/15/2012
Groups: Beta Folders

How about working on adding scoring conditions? This would help the wiggle issue, which is huge. Shake sidechains usually does inprove wiggle, though.

beta_helix's picture
User offline. Last seen 2 days 5 hours ago. Offline
Joined: 05/09/2008
Groups: None

I mentioned this in the other feedback about Puzzle 705: http://fold.it/portal/node/995054#comment-22960

but I really want to apologize about this puzzle, since clearly it was not ready for primetime.

We really thought that we had addressed the main concerns from the feedback we got when we posted it in devprev:
http://fold.it/portal/node/994916
but clearly there was a lot more to address than just the bugs in the above thread (or why the clashing importance acts differently, which we tried to explain in the blogpost: http://fold.it/portal/node/995050)

Just to let you know that we will NOT be posting round 2 of 705 anytime soon, as we work to address your centroid suggestions.

I also think it's important that in the future we somehow transition more smoothly between a very novel puzzle posted in devprev and when that puzzle finally makes its debut in main.
Maybe it should be worth fewer points and not have any categories so that more players will try it (compared to devprev), but nobody will feel like "I have to play this horrendous puzzle or my ranking will go down".
As steveB suggested above, perhaps we should post a smaller centroid puzzle at first (once we address the many issues that have come up, of course).
This was actually the motivation for posting this first centroid puzzle as a Hand-Folding Puzzle. To be able to catch and address the basic bugs before uncovering the Lua bugs (that will certainly arise). It wasn't to make this puzzle even harder than it already was!

We thank you again for your patience with this puzzle and your understanding, and do apologize for how this went down.

Joined: 09/21/2011
Groups: Void Crushers

(Hope this helps) My experience on 705.
Wiggle almost never worked, however sometimes it did.Using cut to position parts of the protein failed, because later joining the cut proved to be not working. Wiggle of just the cut parts (when open) moved big parts of the protein.
Rebuilding a joined part did not work well because of the big negative backbone.
Bands. Either it did nothing or it moved the protein violently. Quake made just a pile of the protein. Bands to space worked oke with wiggle if there were enough bands.
Rebuilding with bands worked normally (just about the only thing that did).
The score function had weird effects. Because bonds have no scoring effect strange positions were scoring well. See what I did to the big helixes: http://fold.it/portal/files/chatimg/irc_308854_1368093615.png
Also that clashing is not counted while the drawing makes clashes visible is strange.
Finally: negative backbone scores came in pairs. Selecting the segments and wiggle had no effect. Making a cut and wiggle repaired the negative backbone scores. Making cuts anywhere and wiggle the 2 segments also gained sometimes, while closed wiggle did nothing.

For this size of puzzles either the tools must be specially designed, or maybe it is possible to just locally recompute the score if local changes are made (with an special function to recompute the real total) might make these big ones playable with the normal sidechains.

Susume's picture
User offline. Last seen 8 hours 17 min ago. Offline
Joined: 10/02/2011

Bump: still very much want stubs available instead of spheres - the spheres get in the way of seeing through the protein, seeing the center of the residue, seeing short rubber bands, seeing whether you have banded the backbone or the sidechain - but we need them turned on to find landmarks on the guide. The spheres have a place on the backbone and a direction, which should be enough to describe a stub. Please give us stubs as an option.

frood66's picture
User offline. Last seen 37 min 4 sec ago. Offline
Joined: 09/20/2011
Groups: Marvin's bunch

so far as I can see the blobs are only occlusive and of no benefit to play whatsoever

alwen's picture
User offline. Last seen 5 days 14 hours ago. Offline
Joined: 10/03/2011

This seems to be working better this time around.

It's hard to get used to working without Shake and Wiggle Sidechains.

I have to repeat my earlier comment: there is still no way to show all the blobs on the guide at once the way Shake shows all the guide sidechains. The only way to see how well I've matched is to run my cursor over them one by one.

If the intent is to handle bigger and bigger proteins, that's more and more blobs to check one by one. That doesn't seem very efficient from a play standpoint.

And this is just an appearance comment: Sometimes the way the protein redraws now is creepy! Sort of a weird slithery wormy look. Ack!

brow42's picture
User offline. Last seen 1 week 4 days ago. Offline
Joined: 09/19/2011
Groups: None

Of course, the idea is to handle bigger and bigger proteins WITHOUT a guide.

jflat06's picture
User offline. Last seen 11 hours 53 min ago. Offline
Joined: 09/29/2010
Groups: Window Group

I agree with the centroid spheres obscuring too much. We can look into adding a stub-mode.

frood66's picture
User offline. Last seen 37 min 4 sec ago. Offline
Joined: 09/20/2011
Groups: Marvin's bunch

A stub mode would be great - can we please have 'show all' too so that we can actually see what the aas are? I'm just about fed up with tabbing :(

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