The FoldFromLoops (FFL) protocol is a variant of the grafting protocol.
The protocol is aimed towards the insertion of structural motifs with a high RMSD distance to the insertion region in the target scaffold.
This documentation refers to the full reimplementation of the protocol as Funtional Protein and Design (FunFolDes), integrated as part of RosettaScripts. To learn about the first version of the protocol (FFL) as described in Correia et al., 2014 see apps/fold_from_loops
FunFolDes requires two input structures: one containing the motif or structural segment that we want to keep/transfer into a new protein and the template or the scaffold that will define the structure that will support the motif.
Broadly, the steps that the protocol follows are (M-Mandatory, R-Recommended):
Thanks to the use of the StructFragmentMover, FunFolDes is capable to generate fragments on the fly to guide the ab initio folding. This fragments use mostly structural information (secondary structure and phi/psi angles) in order to guarantee that the conformation of the final designs will be similar to that of the template but also allowing the system to explore conformational variations to better fit the motif.
In FunFolDes, a motif can be composed of one continuous or multiple discontinuous segments, as long as the number of insertion points in the template is the same as the number of expected segments. The different segments will be kept in spatial correlation of each other exactly as they are found in the original motif structure input. This is achieved through the FoldTree definition and breaks in the sequence. Thus, this scenario requires for a loop closure protocol to be applied in order to close the final design. Although any loop closure protocol in Rosetta will do, the NubInitioLoopClosureMover is provided by the protocol. This particular mover is aware of the constraints imposed by FunFolDes and will automatically avoid non-allowed changes in the motif segments.
In multi-segment motifs, the individual segments do not need to be inserted into the template in the same sequence order as they are found in the motif source structure. As a matter of fact, as long as they come from the same structural source, they don't even need to belong to the same protein.
The motif segments don't need to be of the same sequence length as their insertion points. FunFolDes will fix constraints and fragments in order to adapt to the possible length change between the designs and the template.
For binding motifs, the binder can be added to the ab initio process, forcing the conformation of the designs not only to adapt to the motif but also to the binder, thus ensuring that there are no structural segments that can block the motif's function.
Due to the possibility of size change and to help guide the design/relax steps, FunFolDes uses a residue-label system similar to that of MotifGraftMover (plus some others):
|MOTIF||Highlight the motif regions||None in itself|
|TEMPLATE||Marks the residues that come from the template||This residues are allowed bb/chi movement and design|
|HOTSPOT||Residues in the motif that are considered key||This residues can not move or be design|
|COLDSPOT||Residues in the motif that are not key||This residues have chi movement and can be designed|
|FLEXIBLE||Residues in the edges of the motif that are allowed to move||This residues have bb/chi movement but are not allowed to design|
|CONTEXT||Residues belonging to the target binder (if any)||This residues are not allowed to move or design|
The behaviour attached to each of this labels is fixed during the folding process (performed by NubInitioMover) and the loop closure (done by NubInitioLoopClosureMover), but it can be tweaked in any other part of the process by the user.
The FunFolDes protocol adds several remarks to the silent file output in order to facilitate the reload of the data in new scripts while keeping the protocol's conditions. Amongst them: