The code is at
rosetta/rosetta_source/src/apps/public/interface_design/anchored_design/AnchoredDesign.cc; there's an integration test at
rosetta/rosetta_tests/integration/tests/AnchoredDesign/. There is a more extensive demo with more documentation at rosetta/rosetta_demos/AnchoredDesign, or in the demo section of the release.
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 Documentation for 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 rosetta/rosetta_tests/integration/tests/AnchoredDesign/ for example usage.
AnchoredDesign requires as inputs a starting structure, an anchor specification, and a loops specification (Documentation for the loop modeling application). The starting structure needs to have the anchor grafted into the scaffold (see Documentation for 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 loop 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.)
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)
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 the fluorophore modeling experiments (
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). LoopAnalyzerMover tags this output to the end of the PDB. The second line is long column titles, and the third is short versions to make visualization easier. Each row represents one residue. Totals for all loops for some terms are collected at the bottom.
LoopAnalyzerMover: unweighted bonded terms and angles (in degrees) position phi_angle psi_angle omega_angle peptide_bond_C-N_distance rama_score omega_score dunbrack_score peptide_bond_score chainbreak_score pos phi_ang psi_ang omega_ang pbnd_dst rama omega_sc dbrack pbnd_sc cbreak 17 -106.8 175.8 178.2 1.322 0.998 0.0342 7.01 -2.68 0.0182 18 -82.33 64.67 -178.5 1.329 0.211 0.0217 3.11 -3.42 0.0203 19 -83.63 149.4 177.2 1.329 -1.07 0.0795 0 -3.43 0.584 20 -75.25 171.1 -178.7 1.329 -0.264 0.0161 0.348 -3.43 0.0151 21 -58.53 -42.95 174.6 1.329 -0.58 0.294 0 -3.43 2.7 22 -76.02 159.9 -179.8 1.326 -0.811 0.000404 0.97 -3.45 0.0424 23 -72.63 130.1 179.4 1.325 -1.29 0.00372 0.24 -3.46 0.0281 24 -94.91 116.5 179.8 1.323 -1.21 0.00028 0.721 -3.45 0.0694 25 -65.42 150.7 179.4 1.335 -1.58 0.004 0 -3.32 1.38 26 -64.68 147.9 179.1 1.323 -1.45 0.0079 1.61 -3.32 0.211 27 -56.44 -66.68 -180 1.329 1.34 8.08e-30 7.87 -3.43 2.37e-05 28 -124.4 -56.48 177.6 1.329 2.08 0.0568 0.608 -3.43 0.0533 29 -124.1 28.78 -177.7 1.264 0.341 0.0542 2.39 2.65 2.07 30 81.57 -134.3 -176.4 1.329 20 0.126 5.06 2.65 0.128 31 -112.9 147.2 172.7 1.318 -0.744 0.538 0.534 -3.35 1.38 total_rama 15.9674 total_omega 1.23676 total_peptide_bond -38.3223 total_chainbreak 8.70689 total rama+omega+peptide bond+chainbreak -12.4113 LAM_total -12.4113
In this particular example, position 29 is clearly problematic: the peptide bond distance is too short, as reported by the pbnd_dst, pbnd_sc, and cbreak columns. You can also see that position 30 has an awful ramachandran score. Good structures will have no fields out of range of the lower scores in this example.
Finally, InterfaceAnalyzer puts results at the end of the PDB file as well; read about it here: Documentation for InterfaceAnalyzer application. Again, throw out models with poor interfaces as determined by InterfaceAnalyzer.
Rosetta 3.3 is the first release.