I wonder if there's a template/example source code file in Rosetta from which we can build our own type of constraint. For example, when docking B against A, both are helices, A is fixed and one wants to constrain the tilt angle of B with respect to the z-axis, how can I do this besides blind docking followed by post-processing.
RosettaScript seems like a good candidate but it does not have this kind of utility.
And is there a programming guide for Rosetta?
Thanks a lot.
We don't have a guide that is in-depth enough for the question you are asking, and most of the developer's guide stuff we do have isn't public (it's not secret, but it's in a wiki that isn't public). I am very willing to help you write this code, but I suspect you don't need it for what you want to do.
If you want a Rosetta scorefunction constraint, as in something that plugs into the scorefunction and alters the score of a protein, you need to subclass Constraint. The primary constraints machinery lives in core/scoring/constraints. I don't know that it's the simplest example, but certainly the prototypical example is AtomPairConstraint, which constrains the distance between two atoms. Unfortunately the Constraint class is kind of a workhorse and has a hugely overgrown interface - only a handful of these functions need to be implemented for simple use. You'll need to work out how you want to score your interaction, as well as how to calculate derivatives for it if you want it to be minimizable.
If you just want Rosetta to automatically sense and reject conformations that don't fit your needs (this qualifies as "blind docking with post processing", except Rosetta will do it automatically), you can write a Filter that plugs into RosettaScripts. This is simpler but I think not what you want.
Finally, depending on your system, it is probably possible to cleverly use the constraints that already exist to get the behavior you want. You can *probably* use the existing AngleConstraint to constrain the angle you want - just pick atoms ABC such that A and C are near the "upper" termini of your helices, and B is the lower terminus of the other helix. It won't be perfect but it will be very easy.
As you suggested, a filter in RosettaScript can still be very handy, but how do I write this Filter? Is there a Filter that I can modify in order to fit my need? Also, what is the directory for the source code of RosettaScript.
The AngleConstraint can also be a good hit.
Thanks very much for your comment.
The base Filter class, along with most of the simple filters, is in src/protocols/simple_filters.
Looking around at the filters, I found this one that already exists and might suit your needs. It isn't documented in the 3.4 release but as far as I can tell it's present and ought to work.
Filter structures based on the geometry of helix pairings. Relating helix pairing geometry, this filter provides three parameters, dist, cross, and align, and the structures of which parameters are "below" thresholds are filtered.
[HelixPairing name=(&string) blueprint=(&string) helix_pairings=(&string) dist=(15.0&Real) cross=(45.0&Real) align=(25.0&Real) bend=(20.0&Real) output_id=(1&Integer) output_type=(dist&string) /]
helix_pairings: helix pair is described by paired helix indices separated by "-" with orientations (P or A) after dot ".". Ex. 1-2.A means the pairing between the 1st and 2nd helices. The multiple pairings are concatenated with semicolon ";". Ex. 1-2.A;2-3.A;1-3.P
dist: distance between mid points of paired helices
cross: angle between helix vectors. The helix vector is between the centers of C- and N- terminal helix.
align: angle between helix vectors projected onto beta sheet that is defined by the strands immediately followed before the helices. This is calculated only when the strands exists within 6 residues before the helices.
bend: check bend of intra helix. This is not pairing related parameter, but for checking the intra helix bending. Basically, you don't need change this parameter.
output_id: the helix pair id to be output in score file. e.g. 1 means 1-2.A in 1-2.A;2-3.P.
output_type: parameter type to be output in score file, dist, cross, or align.
blueprint: By giving blueprint file, you can forcibly assign secondary structure. See for blueprint
This might be a dumb question, but why all the residues are mutated after I run RosettaScripts. I used the sample script that's accompanying Meiler's tutorial, and the input is also attached.
It's not a dumb question, it's just a nonobvious consequence of the AND-commutativity of the packer. The packer (PackRotamersMover) starts with an assumption that all residues can be mutated, unless you tell it otherwise. You forgot to tell it otherwise. The fastest fix to prevent mutation is to pass -packing::repack_only in your flags file.
Just a note that the command line flag may or may not work in RosettaScripts, depending on whether you have added the InitializeFromCommandline task operation, or if the mover implicitly added it (some do, some don't). While you have the InitializeFromCommandline task operation in your XML, you don't feed it into the PackRotamersMover, and that's one of the movers that doesn't implicitly add InitializeFromCommandline, so my guess is that the flag by itself won't do anything.
You either have to add "task_operations=ifcl" to the PackRotamersMover tag and use -packing::repack_only on the commandline, or alternatively, you can explicitly set your no-design preference with the RestrictToRepacking task operation ( http://www.rosettacommons.org/manuals/archive/rosetta3.4_user_guide/Task... ), and use that in your movers. (Something like "task_operations=ifcl,rtr" would work too).
I saw they created the TaskOperation but didn't check that they actually used it...