Author: Steven Lewis (smlewi - at - gmail.com)
Code and documentation by Steven Lewis (smlewi - at - gmail.com). The PI was Brian Kuhlman, (bkuhlman - at - email.unc.edu) .
The executable's source is at Rosetta/main/source/src/apps/public/interface_design/anchored_design/AnchoredDesign.cc.
Most of the code is in the libraries at Rosetta/main/src/protocols/anchored_design/.
There is an integration test at Rosetta/main/main/tests/integration/tests/AnchoredDesign/ which functions as a small demo.
There are more extensive demos with more documentation at Rosetta/demo/protocol_capture/anchored_design
, Rosetta/demo/public/anchored_design
, and Rosetta/demo/public/domain_insertion
, which are online at TODO these three links to the online demos.
This paper describes how the code functions and computational benchmarking of the non-design aspects of the protocol.
This paper describes the generation of a biosensor whose mode of activity is rationalized through the help of AnchoredDesign-derived models.
AnchoredDesign is the main protocol discussed here. This protocol is meant to design interfaces between known target structures and new binding partners, using an "anchor" consisting of residues grafted from a known binding partner of the target onto the new scaffold. The idea is that this will reduce the conformational space we need to search and preclude the docking problem, while still leaving freedom to design the interface as necessary. The anchor should be grafted into a surface loop of the scaffold (see the AnchoredPDBCreator application). Loop remodeling of the anchor loop will move the scaffold with respect to the target, exposing different parts of their surfaces to one another. Loop remodeling of other (unanchored) surface loops is also implemented. This lets us design a new, flexible-backbone interface between new binding partners.
See example runs above for more specific usage. TODO page anchor
AnchoredDesign requires as inputs a starting structure, an anchor specification, and a loops specification ( See Loop modeling application and the loops file). The starting structure needs to have the anchor grafted into the scaffold (see AnchoredPDBCreator application and its documentation), and the anchor needs to be docked properly relative to the target. The anchor/target interaction WILL NOT CHANGE, since it was drawn from a crystal structure. The relationship between the scaffold and rest of the system is treated flexibly; the scaffold does need to be connected to the anchor but it's fine if the scaffold crashes horribly into the target (that will be worked out by the protocol).
Note that the AnchoredDesign protocol respects the start, end, cut, and extended fields of the loops file. It ignores the skip_rate field.
The anchor file specification is a one-line file with three whitespace-delimited values: the chain letter, start, and end residue of the anchor. Like so:
B 442 445
It's going to assume PDBInfo exists, so if you have silent files try numbering from 1.
AnchoredDesign has its own namespace of options, and also supports general Rosetta options (packing, etc.)
AnchoredDesign options
These four boolean options allow deactivation of KIC or CCD loop closure for perturb and refine stages:
AnchoredDesign has a sub-namespace for filtering:
These options activate vicinity sampling in kinematic loop closure. (The default is to use random samples from the Ramachandran distribution for the non-pivot torsions in the loop; these options instead perturb the existing loop slightly). This is almost certainly out-of-date due to the development of Next Generation KIC loop closure.
General options: All packing namespace options loaded by the PackerTask are respected. jd2 namespace options are respected. Anything very low-level, like the database paths, is respected.
PoseMetricCalculator flags include:
This section describes changes for fluorophore modeling experiments (Gulyani A, Vitriol E, Allen R, Wu J, Gremyachinskiy D, Lewis S, Dewar B, Graves LM, Kay BK, Kuhlman B, Elston T, Hahn KM. A biosensor generated via high-throughput screening quantifies cell edge Src dynamics. Nat Chem Biol. 2011 Jun 12;7(7):437-44. doi: 10.1038/nchembio.585. (pubmed link)).
In these experiments, a dye was chemically attached to a loop cysteine. In Rosetta, this was modeled as a noncanonical amino acid (the dye-cysteine conjugate). A few changes need to be made to accomodate a noncanonical amino acid in a flexible loop. These changes mostly focus on replacing the dunbrack and rama terms for that residue:
The code is capable of holding the anchor in place via constraints, rather than rigid locking through the fold tree. It will maintain a rigid anchor in the centroid perturb phase no matter what (I don't trust the centroid scorefunction that much), but it will allow internal backbone movement of the anchor, as well as rigid body movement, in full atom mode. I suggest using tight strong constraints to keep your anchor in place. Use these flags:
AnchoredDesign should produce nstruct worth of result structures. If you used the default JobOutputter, you'll get PDBs with embedded score information and a scorefile summarizing most of the score information.
There are three classes of output tagged to the end of the PDBs and/or in the scorefile:
The scorefunction tells you what Rosetta's standard scorefunctions think is best, and is useful for the first sorting of structures. Generally, only structures in the top few percent by total_score should be further analyzed. Even then, the other scorefunction terms (listed at the end of the PDB and in the score file) should be examined to throw out models that have particularly bad scores in any area - a model that is overall pretty good, but has a bad clash (fa_rep) for one particular residue, may be worth throwing out.
Next, you use the LoopAnalyzerMover output to filter for bad loop closures (which Rosetta's scorefunction detects insufficiently). Read about it here.
Finally, InterfaceAnalyzer puts results at the end of the PDB file as well; read about it here: Documentation for the InterfaceAnalyzer application . Again, throw out models with poor interfaces as determined by InterfaceAnalyzer.
These modes are not suggested for public use.
Rosetta 3.3 is the first release. Benchmarking modes were added for 3.4 (I think?). Various testing options were created by the time of 3.5.
AnchoredPDBCreator: Creates input for this application.
Design applications: other design applications