Rama map: let us pick which end moves

Case number:845813-2002445
Topic:Game: Tools
Opened by:Susume
Status:Open
Type:Suggestion
Opened on:Wednesday, May 11, 2016 - 21:12
Last modified:Saturday, September 2, 2017 - 21:03

When you move a dot in the rama map, the higher numbered segments always stay still and the lower numbered segments always move. This effectively means you have to work from the end of the protein toward the beginning if you are gradually building a shape. On an ED puzzle, sometimes we have the lower numbered segments placed and want to move only the higher numbered segments. Please let us pick (by freezing one end, or some other means) which end of the protein moves when we move dots in the rama map.

(Wed, 05/11/2016 - 21:12  |  9 comments)


frood66's picture
User offline. Last seen 8 hours 53 min ago. Offline
Joined: 09/20/2011
Groups: Marvin's bunch

This would be very helpful.

bkoep's picture
User offline. Last seen 1 hour 37 min ago. Offline
Joined: 11/15/2012
Groups: None

Thanks for the suggestion! This is a very reasonable request, but is unfortunately a little complicated to implement, for technical reasons. A lot of the underlying code in Foldit relies on a "rooted tree" data structure to model the protein chain. This is efficient, but is built so that changes are only propagated "down" the tree (in this case, towards the protein N-terminus).

I'm not saying that it can't be done, and we'll discuss the issue. I just wanted to share that the only reason we don't immediately fix this is because the solution is not trivial.

tokens's picture
User offline. Last seen 24 weeks 1 day ago. Offline
Joined: 11/28/2011

It's the same issue when one idealizes part of the protein.

Susume's picture
User offline. Last seen 1 week 6 days ago. Offline
Joined: 10/02/2011

This is a problem in contact puzzles too: you have a sheet placed where you want it, you want to use the rama map to shape the loop connecting it to the next sheet or helix, but when you drag a dot in the rama map your carefully placed sheet flies out of position. You have to insert a cut between the sheet and the loop, which means you can't use the rama map to shape the two residues you choose to cut between. The more places you use the rama map, the more cut points you end up with, which means more unidealities to fix later.

When we insert a cut I assume foldit breaks the tree into two trees with different roots. Sometimes foldit seems to reverse one of the trees (i.e. sometimes a portion of the protein is stationary at its N end rather than its C end). I am hopeful you can find a way to give us control over this - I love the direct control the rama map gives and want to use it in more than just design puzzles!

Joined: 02/08/2012
Groups: None

I agree with this. I just noticed this issue on 1285 and I'd have to say it's rather annoying lol.

Susume's picture
User offline. Last seen 1 week 6 days ago. Offline
Joined: 10/02/2011

Found a workaround: If you add a residue at the high-numbered end, the "tree" reverses. Now when you bend the backbone using the rama map, the low-numbered end stays fixed in space, and the high-numbered end moves instead. This makes it possible to build the protein from the beginning instead of the end. Of course this only works on design puzzles.

The code for reversing the "tree" is in there somewhere! If we could just have a button for it....

Susume's picture
User offline. Last seen 1 week 6 days ago. Offline
Joined: 10/02/2011

I am bewildered by the change in which-end-moves that has come out in the new devprev. Up until now, you at least had a 50/50 chance that the end of a section that would stay still would be the end you actually wanted to stay still. Now, either or both ends can move, depending whether the residues you are bending/idealizing/blueprinting are closer to one end or are in the middle of the section you are working on.

If you are working on a loop at the center of a section (with protein ends or cuts on each end of the section), you can bend one residue with rama map and one end of the section will move out of place, and then bend the adjacent residue and the other end of the section moves out of place, so you now have a zero percent chance of the residues you have already carefully placed staying put.

If you have found the end of a protein in an ED puzzle and placed it in the cloud, and you want to use rama map to work along the backbone placing each residue, you have a zero percent chance that the end you placed will stay put, because when you are starting out the placed end is always the short end. One arbitrary rule for which end moves has been replaced with a different arbitrary rule, and it is not better.

I'm glad to see work going into improving this behavior, but the change we actually need has not shown up yet, namely letting the user choose which end stays put.

bkoep's picture
User offline. Last seen 1 hour 37 min ago. Offline
Joined: 11/15/2012
Groups: None

We hear you! The amended behavior in the new devprev is modeled after the behavior of the Pull tool. This was the intended behavior from the start (I know it took us a while to fix), and we like for the tools to share similar conventions by default.

We definitely understand the need to fix the absolute position of particular residues, especially for advanced play, and I think we'll be able to add that feature soon!

Susume's picture
User offline. Last seen 1 week 6 days ago. Offline
Joined: 10/02/2011

In 1422 and 1423, this is now working great - I can freeze a residue in the shorter end and then other end moves. Not sure if you fixed it on purpose, but it's a great improvement!

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