More about the Blueprint Tool
Foldit players posed several great questions about the Blueprint tool for our last Science chat, but we didn’t have time to answer all of them. We're long overdue for an in-depth explanation about the Blueprint tool, but it seems that players are finding the tool useful and we'd like to share more about it's mechanics. In particular, we hope this blog post can shed some light on the following question:
It has been pointed out that removing Blueprint tool constraints towards the end allows for substantial score improvement. Why is this, as it seems counterintuitive? – gitwut
Before I answer this question, I’d like to offer a little more background on the Blueprint tool:
There are two motivations behind the Blueprint tool: The first is simply to make “ideal loops” more accessible to players. The Ideal Loop Filter has helped Foldit designs tremendously, and the recent top-scoring designs have all had excellent loops. However, it seemed that players were required to do a lot of work in order to satisfy that filter. Hopefully, the Blueprint tool has made it easier (especially for beginners) to satisfy the Ideal Loop Filter.
The second motivation for developing the Blueprint tool is to provide an alternative design process. Some of us suspect that bad Foldit backbones are the result of aggressive loop building in middle- or late-game strategies. For example, suppose you're designing a protein and decide to form the loops last: by the time you build loops, you may have already cemented your helices and sheets into place and optimized the core packing of your protein, and as a result the backbone does not have a lot flexibility for rebuilding loops. The endpoints of two neighboring beta strands may be positioned such that there is no stable loop to bridge them. Aggressively using Rebuild/Remix to force a loop between incompatible endpoints is akin to hammering a square peg into a round hole. It will be impossible to close the loop without compromising the geometry of the backbone. We had hoped the Blueprint tool could be used early in the design process to quickly construct a "healthy" rough draft of a design, which could be gradually optimized without compromising the backbone geometry.
BuildingBlock Torsion Constraints
To answer gitwut's question, BuildingBlocks include torsion constraints. Torsion constraints force a residue to a certain region of the Ramachandran Map—much like Rubber Bands (which represent distance constraints) force two residues to be a certain distance from one another. When constraints are present, Wiggling a solution will not produce points as quickly, but the solution will try to follow the constraints. Broadly speaking, constraints allow us to redirect Wiggle toward a desired result, usually sacrificing short-term gains to find an ultimately better model.
Placing a BuildingBlock loop onto the Blueprint Panel introduces torsion constraints to the loop residues (likewise, removing the BuildingBlock removes the constraints). The torsion constraints are intended to preserve the BuildingBlock loop while a player develops the rest of his or her design. Constraints are needed in this case because the Foldit energy function does not necessarily favor the BuildingBlock loops. In fact, we don't fully understand why the BuildingBlock loops are so prevalent in natural proteins. These loops may be favored for reasons that are not explicitly modeled in Foldit—like folding kinetics, or more complex entropic effects. (In contrast, helices and sheets are naturally stabilized by hydrogen bond forces, which are captured by the Foldit energy function.) Without the torsion constraints, Wiggle is prone to obliterate the BuildingBlock loop in favor of more short-sighted energy gains. We intended that players might keep the constraints around to preserve the BuildingBlock loops until a design-in-progress has settled into a mature fold—only then removing the constraints for late-game refinement.
To make things even more complicated, note that we've manually adjusted how BuildingBlocks are applied through the Blueprint Panel. That is, when you drag a BuildingBlock onto the Blueprint Panel and the protein backbone snaps into place, this initial "adjusted" form is only a rough approximation of the loop's optimal form. When you Wiggle the loop, the torsion constraints will drag the backbone to its optimal shape, which may be slightly different from initial adjusted shape (this is particularly noticeable for β-hairpins BuildingBlocks). This is because the BuildingBlock loops are derived from native proteins, which never have perfectly ideal helices and sheets. If you were to apply the optimal BuildingBlock loops to Foldit's ideal beta strands, the ideal beta strands would not align to form hydrogen bonds (Figure A, above). In order to make the tool more user-friendly, we adjusted the optimal BuildingBlocks so that the hairpin loops would be compatible with Foldit's ideal sheets. Thus, a BuildingBlock hairpin will initially snap two ideal strands into perfect alignment (Figure B); and subsequent Wiggling will allow the beta strands to flex slightly, so that the BuildingBlock loop can relax into its optimal form (Figure C).
As an aside, some astute Foldit players have noticed that the BuildingBlocks collection is missing a BAAB β-hairpin, which is a stable loop frequently found in nature. As it turns out, this loop induces significant deformation of the adjacent beta strands. As much as we tried, we were unable to adjust the BAAB BuildingBlock so that it would be reasonably compatible with Foldit's ideal beta strands, and that particular loop was omitted from the BuildingBlocks collection.( Posted by bkoep 70 565 | Mon, 01/30/2017 - 20:33 | 9 comments )