Rosetta 3.1 Release Manual |
Mini is capable of describing all these types of symmetries. The only restriction is that all repeating units in the system must have a chemically identical environment. The smallest repeating unit with this property is the assymmetric unit of the system. The assymetric unit is typically identical to a subunit.
1) Generate a symmetry definition file.
2) If necessary modify symmetry definition file. This typically involves changing the set_dof lines.
3) Add symmetry related flags.
4) Make sure you use the binary silent files format if you output silent files.
usage: make_symmdef_file.pl [options] example: make_symmdef_file.pl -m NCS -a A -i B C -r 12.0 -p mystructure.pdb example: make_symmdef_file.pl -m HELIX -a A -b B -i G -r 12.0 -p mystructure.pdb example: make_symmdef_file.pl -m CRYST -r 12.0 -c 42.4 41.2 88.6 90.0 90.0 90.0 -s P 1 21 1 -p mystructure.pdb common options: -m (NCS|CRYST|HELIX|PSEUDO) : [default NCS] which symmetric mode to run NCS: generate noncrystallographic (point) symmetries from multiple chains in a PDB file CRYST: generate crystallographic symmetry (fixed unit cell) from the CRYST1 line in a PDB file HELIX: generate helical/fiber symmetry from multiple chains in a PDB file PSEUDO: (EXPERIMENTAL) generate pseudo-symmetric system -p <string> : Input PDB file (one of -b or -p _must_ be given) -r <real> : [default 10.0] the max CA-CA distance between two interacting chains -f : [default false] enable fast distance checking (recommended for large systems) NCS-specific options: -a <char> : [default A] the chain ID of the main chain -i <char> : [default B] the chain IDs of one chain in each symmetric subcomplex CRYST-specific options: -c <real>x6 : override the unit cell parameters in the PDB with these values -s <string> : override the spacegroup in the PDB with these values -k <real> : (EXPERIMENTAL) Approximate the protein as a ball of this radius (only if no '-p'!) HELIX-specific options: -a <char> : [default A] the chain ID of the main chain -b <char> : [default B] the chain ID of the next chain along the fiber/helix -i <char> : the chain ID of a chain in -a's point symmetry group -t <real> : [default 2] the number of helical turns to generate along the -b direction -c <char> : (EXPERIMENTAL) the chain ID of the symm chain perpindicular to the -b chain (simple 2D symmetry) -u <real> : (EXPERIMENTAL) [default 1] the number of repeats to generate along the -c direction PSEUDO-specific options: -a <char> : [default A] the chain ID of the main chain
The script currently recognizes three different symmetry types: noncrystallographic (point) symmetries, crystallographic symmetry, and helical symmetry. A fourth (experimental) option, "pseudo-symmetry," models a nonsymmetric system using the symmetry machinery to attempt to reduce the conformational space (and running time) of the search at the cost of some accuracy. The first three of these options are discussed in some detail below
NCS mode
A sample command script (to generate D3 symmetry, with chains A, B, and C forming the upper ring and chains D,E, and F forming the lower):
make_symmdef_file.pl -m NCS -p D3.pdb -a A -i B E -r 12 > D3.symm
Several files are generated:
CRYST mode
Sample command script (using the CRYST1 line in the PDB file):
make_symmdef_file.pl -m CRYST -p p65.pdb > p65.symm
Several files are generated:
The input PDB (to Rosetta) in this case is simply 'p65.pdb', the input file sent to the script.
HELIX mode
Sample command script (with chains A, C, E, ... tracing up the helical axis and B, D, F, ... forming C2 symmetries up the axis):
make_symmdef_file.pl -m HELIX -p fiber.pdb -a A -b C -i B -r 12 -t 5 > fiber.symm
Several files are generated:
A total of 5 turns of the helix (-t 5) are generated.
Alternately, a helical twist can be forced by appending :n to the helical chain. For example, the command script:
make_symmdef_file.pl -m HELIX -p fiber2.pdb -a A -b B:3 > fiber2.symm
Unsupported symmetries
The following symmetry types are currently unsupported by the script:
Read in my_symdef_file symmetry definition file.
-symmetry:initialize_rigid_body_dofs
If you want to initialize the rigid body placement according to the symmmetry definition file.
-symmetry:perturb_rigid_body_dofs ANGSTROMS DEGREES
If you want to apply a rigid body perturbation to the initial rigid body conformation. The values overrrides the SymDof data?
Score app: src/apps/public/score.cc
Symmetric Docking: contact author
Fold and dock: contact author
Relax protocols: see src/apps/public/relax.cc
Rosetta uses virtual residues (VTRs) to encode the subunit coordinate frames. VRT residues have an origin, X and Y coordinate. Each subunit is connected through a rigid body jump to such virtuals. For a dimer the simplest setup involves having two VRT residues, where the coordinates of one VRT residue is related by a twofold rotation to another. For more complex symmetries it is common to have additional layers of virtual residues that are sometimes connected by jumps to other virtual residues where each virtual residue encodes a coordinate frame. The setup is generally a tree structure of virtual residues and at the top of the is rooting residue that specifies the coordinate of the whole symmetrical assembly in the cartesian coordinate frame. This root coordinate system allows you to for exampe to fit the assembly into an electron density or a membrane.
Some of the VRT residues have special status: they are masters. The masters control their slave virtuals. If a jump from a master is applied, the same jump gets applied to its slaves. Only jumps from masters can be applied. This work is done by the set_jump functions in the SymmetricConformation class which replicate jumps from masters to slaves.
The coordinates of the virtual residues is specified in a symmetry definition file. The parsing of symmetry definitions is done by the SymmData class. The information in the SymmData class is then used to insert VRT residues into the symmetrical conformation when a symmetrical pose is constructed. The SymmData object is also used to initialize the SymmetryInfo class that is stored in the SymmetricConformation class. SymmetryInfo stores all the information about symmetry that a pose carries around.
Even if you only need a smaller number of subunits to score the complex you may have to explicitly represent a larger number of assymetric units for minimization and packing. The rule is this: The scoring subunit has to have all its interacting neighbors present. This is the smallest system that can be explicitly modeled.
symmetry_name my_pdb_P_1_21_1
a string describing the symmetry of the system. This can be anything.
E = 2*VRT_0_0_0_0_base + 1*(VRT_0_0_0_0_base:VRT_0_0_0_1_base) + 3*(VRT_0_0_0_0_base:VRT_0_n1_0_0_base) + 4*(VRT_0_0_0_0_base:VRT_1_0_0_0_base)
E line: This is how to tell rosetta how to score the structure. In this example, the subunit that is connected to the virtual residue VRT_0_0_0_0_base is the scoring subunit and internal energies in this subunit is multiplied with 2 to get the total energy. The add intermolecular energies from the VRT_0_0_0_0_base connected subunit to subunits connected to VRT_0_0_0_1_base, VRT_0_n1_0_0_base and VRT_1_0_0_0_base with factors of 1,3 and 4, respectively.
anchor_residue 29
The subunit jump is anchored at residue 29.
virtual_coordinates_start
xyz VRT_0_0_0_0 1.000,0.000,0.000 0.000,1.000,0.000 -1.363,24.921,7.618
xyz VRT_0_0_0_0_base 1.000,0.000,0.000 0.000,1.000,0.000 -2.363,23.921,6.618
xyz VRT_0_0_0_1 1.000,0.000,0.000 0.000,1.000,0.000 -12.385,24.921,43.670
xyz VRT_0_0_0_1_base 1.000,0.000,0.000 0.000,1.000,0.000 -13.385,23.921,42.670
xyz VRT_0_0_0_n1 1.000,0.000,0.000 0.000,1.000,0.000 9.660,24.921,-28.435
xyz VRT_0_0_0_n1_base 1.000,0.000,0.000 0.000,1.000,0.000 8.660,23.921,-29.435
xyz VRT_0_n1_0_0 1.000,0.000,0.000 0.000,1.000,0.000 -32.063,24.921,7.618
xyz VRT_0_n1_0_0_base 1.000,0.000,0.000 0.000,1.000,0.000 -33.063,23.921,6.618
xyz VRT_0_1_0_0 1.000,0.000,0.000 0.000,1.000,0.000 29.337,24.921,7.618
xyz VRT_0_1_0_0_base 1.000,0.000,0.000 0.000,1.000,0.000 28.337,23.921,6.618
xyz VRT_1_0_0_0 -1.000,0.000,0.000 0.000,1.000,0.000 1.363,42.471,-7.618
xyz VRT_1_0_0_0_base -1.000,0.000,0.000 0.000,1.000,0.000 2.363,41.471,-6.618
xyz VRT_1_0_n1_0 -1.000,0.000,0.000 0.000,1.000,0.000 1.363,7.371,-7.618
xyz VRT_1_0_n1_0_base -1.000,0.000,0.000 0.000,1.000,0.000 2.363,6.371,-6.618
xyz VRT_1_0_0_1 -1.000,0.000,0.000 0.000,1.000,0.000 -9.660,42.471,28.435
xyz VRT_1_0_0_1_base -1.000,0.000,0.000 0.000,1.000,0.000 -8.660,41.471,29.435
xyz VRT_1_0_n1_1 -1.000,0.000,0.000 0.000,1.000,0.000 -9.660,7.371,28.435
xyz VRT_1_0_n1_1_base -1.000,0.000,0.000 0.000,1.000,0.000 -8.660,6.371,29.435
virtual_coordinates_stop
Define the coordinates of the virtual residues. There are three triples ( X, Y and ORIGIN ) that each have three coordinates describing units vectors( for X and Y ) and a center ( ORIGIN ). You can use ane unique name for theses virtuals.
connect_virtual JUMP_0_0_0_0_to_subunit VRT_0_0_0_0_base SUBUNIT
connect_virtual JUMP_0_0_0_1_to_subunit VRT_0_0_0_1_base SUBUNIT
connect_virtual JUMP_0_0_0_n1_to_subunit VRT_0_0_0_n1_base SUBUNIT
connect_virtual JUMP_0_n1_0_0_to_subunit VRT_0_n1_0_0_base SUBUNIT
connect_virtual JUMP_0_1_0_0_to_subunit VRT_0_1_0_0_base SUBUNIT
connect_virtual JUMP_1_0_0_0_to_subunit VRT_1_0_0_0_base SUBUNIT
connect_virtual JUMP_1_0_n1_0_to_subunit VRT_1_0_n1_0_base SUBUNIT
connect_virtual JUMP_1_0_0_1_to_subunit VRT_1_0_0_1_base SUBUNIT
connect_virtual JUMP_1_0_n1_1_to_subunit VRT_1_0_n1_1_base SUBUNIT
connect_virtual JUMP_0_0_0_0_to_com VRT_0_0_0_0 VRT_0_0_0_0_base
connect_virtual JUMP_0_0_0_1_to_com VRT_0_0_0_1 VRT_0_0_0_1_base
connect_virtual JUMP_0_0_0_n1_to_com VRT_0_0_0_n1 VRT_0_0_0_n1_base
connect_virtual JUMP_0_n1_0_0_to_com VRT_0_n1_0_0 VRT_0_n1_0_0_base
connect_virtual statements encode the jumps in the system. For example,
connect_virtual JUMP_0_0_0_0_to_com VRT_0_0_0_0 VRT_0_0_0_0_base
means that virtuals JUMP_0_0_0_0_to_com and VRT_0_0_0_0_base should be connected by a jump. We name this jump JUMP_0_0_0_0_to_com. Any string can be chosen for this name. If the second jump is SUBUNIT then it means that a jump from a virtual to a subunit is specified.
set_dof JUMP_0_0_0_0_to_com x z
set_dof JUMP_0_0_0_0_to_subunit angle_x angle_y angle_z
set_dof statements specifify which degrees of freedom are allowed for a particular jump. They are x,y,z for translations and angle_x, angle_y, angle_z for rotations. The set_dof should only be set for the master jump. If a jump does not have a set_dof statement associated with it then by default the jump is unmovable. Observe that the movers that perturb jumps must be sensitive to dof SymDof data, is stored in SymmetryInfo, in order for these dof restrictions to be used. You can still manually set dofs of jumps that should not move in order to maintain symmetry if you set jumps manually!
You can also encode the initial placement of subunits by modifying this line. For example:
set_dof JUMP_0_0_0_0_to_com x(20) z(10:20)
means that x should be set to 20 angstrom and z should be randomly chosen in the range 10-20. For angles:
set_dof JUMP_0_0_0_0_to_subunit angle_x(360) angle_y(360) angle_z(360)
means that the rotation should be completely randomized. You can also encode rigid body perturbation sizes:
set_dof JUMP_0_0_0_0_to_com x(20:5) z(10:20)
Here, that that perturbations along the x-direction should be gaussian with size 5. In order for this to be used in rosetta the protocol that you are using must be using SymDof objects in their movers. Below the section on how to run with symmetry explains how to make this happen.
set_jump_group JUMPGROUP1 JUMP_0_0_0_0_to_subunit JUMP_0_0_0_1_to_subunit JUMP_0_0_0_n1_to_subunit JUMP_0_n1_0_0_to_subunit JUMP_0_1_0_0_to_subunit JUMP_1_0_0_0_to_subunit JUMP_1_0_n1_0_to_subunit JUMP_1_0_0_1_to_subunit JUMP_1_0_n1_1_to_subunit
These statements tell rosetta which jumps are involved in master/slave relationships. The first jump in the jumpgroup is the master. The name of the jump group can be chosen freely.
If you run a denovo case where you don't have an input symmetrical structure you might want to generate a symmetry definition by hand. There is an additional format that can be used to build virtual residues through the specification of rotation and translation operations. For example:
symmetry_name c3
subunits 3
recenter
number_of_interfaces 1
E = 3*VRT1 + 3*(VRT1:VRT2)
anchor_residue 17
virtual_transforms_start
start -1,0,0 0,1,0 0,0,0
rot Rz 3
virtual_transforms_stop
connect_virtual JUMP1 VRT1 VRT2
connect_virtual JUMP2 VRT2 VRT3
set_dof BASEJUMP x(50) angle_x angle_y angle_z
Observe that we don't give the names of VRT residues they are automatically assigned to VRT1, VRT2,...etc. Jumpgroups are automatically calculated as well. There is automatically jumps added between virtuals.
recenter
Tells rosetta to recenter the input subunit so that the CA of the anchor residue is at the origin (0,0,0).
virtual_transforms_start
Virtual residues will be specified through rotation and translation operations instead of hard coded coordinates.
virtual_transforms_start consecutive
the consecutive keywords signals that for every virtual that is placed all the transformations between virtual_transforms_start and virtual_transforms_stop will be applied. The default is that
start -1,0,0 0,1,0 0,0,0
is the position of the first virtual residue in the system (unit vectors of X, Y and coordinate of ORGIN). The first transform(s) will be applied to this virtual to generate the second.
rot Rz 3
apply 3 fold rotation around the absolute z-axis. ( you can use Rx, Ry and Rz ). You can also say:
rot Rz_angle 120
which means that a 120 degree rotation should be applied.
trans 4,5,2
encodes a translation operation, the three numbers specifies a translation vector.
Setting up a symmetric pose Call SetupForSymmetryMover (src/protocols/moves/symmetry/SetupForSymmetryMover.cc) at the beginning of the protocol before any conformational changes occur to the pose. This takes a monomeric input pose and make a symmetric oligomer base on the symmetry_definition file.
Scoring Use ScoreFunctionOP or ScoreFunctionCOP instead of ScoreFunction because the symmetrical scorefunction (SymmetricScoreFunction) is derived out of ScoreFunction. This will be automatic if using the ScoreFunctionFactory. ScoreFunctionFactory checks if a symmetry definition file has been defined as an option and makes a SymmetricScoreFunction in that case.
Packing and RotamerTrials If the pose is symmetric then use symmetric versions of the PackRotamersMover and RotamerTrialsMover (src/protocols/moves/SymPackRotamerMover.cc and src/protocols/moves/SymRotamerTrialsMover)
Minimizing If the pose is symmetric then use symmetric versions of the MinimizeMover (src/protocols/moves/SymMinimizeMover.cc)
FoldTree manipulation If you modify the foldtree in the protocol make sure that the symmetric structure is properly updated. Simplest idea is to work on a monomer and then call SetupForSymmetryMover to regenerate the symmetrical oligomer.
Degrees of freedom Only the degrees of freedom of one assymetric unit should be allowed to move. This will by automatic in most symmetry-aware movers but it is safest to explicitly only setup the dofs for the master subunit. You can find out from the SymmetryInfo what the master residues/jumps are.
Perturbing rigid body What dofs are allowed to move and how much are controlled by the set_dof statements in the input symmetry defintion. A SymmDof object is stored in SymmetryInfo. You can grab what jumps are allowed to move from the SymmDof object. However, there are a range of RigidBodyMovers sensitive to Symdof data. These are found in src/protocols/moves/RigidBodyMover.cc. The safest is to use those, or if they do not solve your problem, add others in the same mold at the same location. Beware that there is nothing preventing you to move a jump that destroys the symmetry, so make sure to use the information SymmetryInfo and SymmDof when you make a jump move that is not internal to a monomer.
Calculating rms Having many eqivavelent chains leads to problems in calculating rms of more than two chains because the order of chains in the output structure is arbitrary. This is mostly a problem for denovo predicitions. In other cases, the chain order is probably not changed during the simulation. To get a proper rms one has to test all different chain orderings and calculate rms for all of them. CA_rmsd_symmetric does this trick for you (src/core/scoring/rms_util.cc). There is also a PoseEvaluator for it. Beware that there is a combinatorial explosion lurking behind this command so don't use this for very large number of chains!
Useful code
In src/core/conformation/symmetry/util.cc there are a number of convinence functions for working with symmetrical poses. A typical operation when working with symmetry is to find out whether it is symmetrical the function core::conformation::symmetry::is_symmetric( pose ) will answer this question. You can ask a Conformation, Scorefunction and Energies object the same questions.
Another common operation is to grab a pointer to a SymmetricConformation and SymmetryInfo:
SymmetricConformation const & SymmConf ( dynamic_cast<SymmetricConformation const &>( pose.conformation()) ); SymmetryInfo const & symm_info( SymmConf.Symmetry_Info() );
SymmetryInfo contains everything you need to know about the symmetry of the conformation: master/slave relationships (chi_clones, bb_clones and jump_clones etc), Movable Dofs (SymmDofs) etc.