In certain puzzles, cutpoints are added to specific locations as constraints, to ensure that two neighboring residues have the proper distance between them. Now, given that freestyle folding puzzles start with an extended configuration, it would be really helpful if we could add our own cutpoints so that smaller segments of the protein could be manipulated separately.
==> Why is this necessary? Currently, there is no way to change the backbone configuration without affecting the rest of the protein unless one freezes off certain segments. But if segments are frozen, the endpoints would be fixed, and thus certain manipulations would be impossible (e.g. straightening a helix). The solution? Cut the protein into pieces, fold the smaller pieces separately, and then glue them back together. Of course, the cutpoints need to suffer from a backbone score penalty modified by distance, and another behavior tab for backbone score would be needed so that the pieces would not come back together in undesired ways until the folder wants to glue them back.
Here, here! Anyone else frustrated trying to rebuild a helix that's in the middle of a freestyle puzzle?
The idea of changing small separate pieces is good, but if my old computer can handle it?
Sounds like a great enhancement to me!
I generally give up on the freestyle puzzles because of this issue, and just let them roll up into the best scoring yarn-ball I can come up with.
Sounds like a great enhancement to me!
I generally give up on the freestyle puzzles because of this issue, and just let them roll up into the best scoring yarn-ball I can come up with.
Sounds like a great enhancement to me!
I generally give up on the freestyle puzzles because of this issue, and just let them roll up into the best scoring yarn-ball I can come up with.
Brick:
Uh, you've just triple-posted. ;-)
As for the yarn ball– sadly, that is my current structure in 212. It does score higher than a giant helix…
Crashguard:
As far as I know, proteins with cut-points in them should not be a problem for older computers if they are already able to handle the recent large puzzles (i.e. those with >150 protein segments with ligands or DNA). After all, this change should only affect the continuity between residues.
For example, if residue #14 is connected to residue #15 (which is the default case), then changing the configuration (e.g. phi and psi angles– see http://en.wikipedia.org/wiki/Dihedral_angle ) of residue #14 would move everything downstream unless the endpoints are fixed. If a cut-point is inserted between #14 and #15, however, then changing the figuration of #14 would hold #15 in place while creating a gap between the two residues. While the gap is undesirable, this way of manipulation small segments has the advantage of keeping the configuration of everything downstream relatively intact (assuming that a subsequent wiggle is sufficient to close the gap)– which has many practical uses.
==> Bottom line: the technical complexity of representing proteins with cut points should not be higher than existing puzzles with multiple pieces (whether they might be proteins, DNA, or other ligands).
**FoldIt developers: Please correct my assertions above if they're wrong– I'm writing this based on my limited knowledge of how Rosetta works (cf. fold trees, which ensures that changes to the configuration of a residue would not propagate outside a small area). Now, I do realize that implementing the ability to manually do loop modeling (which would involve defining the endpoints of fold trees and location of cut point *plus a change in the score function) can take quite a while, and that I only know the technical details because I had worked with Rosetta 3.0 in the past (i.e. this is probably not public knowledge even to those who have the background in biochemistry).
…Hence, I'll drop the priority of this project down to a 5 for the time being. (After all, the scores from freestyle puzzles seem to indicate that some of the top folders are able to reconstruct entire proteins from scratch even without the ability to cut them into smaller pieces– so I guess the problem is me rather than the program?)
Sorry about the triple posting. The web site just returned a blank white page after I clicked "Save". I just did a reload a couple of times until a page appeared (with 3 posts) ;(
great idea that we have talked about implementing many times…
sadly, other things always end up getting higher on the priority todo list.
Look there: http://fold.it/portal/node/990194
It is (was?) implemented in standalone client.