Rosetta 3.2.1 Release Manual

Documentation for Idealization protocol and application

Phil Bradley (


Documentation last updated 12/2010 by Phil Bradley. The app was written by Mike Tyka. Phil Bradley originally wrote the IdealizeMover which is called internally by the app. The PI is David Baker (

Code and Demo


The old R++ idealizer used atom pair constraints and was kind of slow. This new mini-idealizer uses coordinate constraints and is much faster (especially with the -fast option) and gives better performance as gauged by RMSD between the start and final pdbs. The old idealizer had torsional constraints, which haven't been implemented in this new mini-idealizer; that would probably be a good idea at some point to keep individual backbone torsion angles from getting messed up.


The purpose of this app is to generate a structure with ideal Rosetta bond lengths and angles that is as close as possible to the input structure.


There are two possible protocols. With the -fast option, ideal geometry is inserted all at once throughout the structure, which perturbs the conformation leading to a potentially large RMSD to the input structure. Then Rosetta's minimizer is called to optimize the dihedral angles and reduce the coordinate deviations from the input structure. In the "slow" protocol (i.e., without the -fast option), ideal geometry is inserted at a single residue at a time, and torsion angles nearby the idealized residue are minimized to bring the structure back into agreement with the starting structure. The residues are idealized in a random order, leading to small variations in the output structures if an -nstruct value larger than 1 is used. This could possibly be useful, if a very tight idealized ensemble is desired. In my experience, the -fast protocol usually works fine and is much faster... For both protocols, a virtual residue is appended to the end of the pose, allowing it to float freely in Cartesian space during the gradient-based optimization of the coordinate deviations. This residue is removed at the end.


The idealizer does not handle non-protein (e.g. DNA, RNA, ligand) objects nicely right now. The internal code (in src/protocols/idealize/ and src/protocols/idealize/ can be wrapped easily to handle more complex systems. To idealize multi-chain proteins the input structures need to have FoldTree data and appropriate chain delineations so that the poses that are created by the JobDistributor and passed to the IdealizeMover are not single, continuous protein chains.

Input Files

This app handles all I/O supported by the job distribution system. I've mainly used it with PDB files.


There are three protocol specific options:

-fast -- this triggers the fast protocol.

-atom_pair_constraint_weight -- Sets an optional non-zero weight for atompair constraints. Using atompair constraints results in a significant slow down, but may lead to better preservation of short-range interactions like hydrogen bonds. A reasonable value for this would be ~0.01, but it's worth experimenting with.

-coordinate_constraint_weight -- Can be used to toggle the coordinate constraint weight. Default value is 0.01.


I use the -fast option, which seems to work OK. Watch out for chainbreaks (missing density) in the starting PDB. Check the final RMSDs and visually inspect the aligned starting and final models with PyMOL/RasMOL.

Expected Outputs

The application should generate one or more (depending on the setting of nstruct) idealized structures, with output handled by the job distributor framework. Sanity check: if you re-idealize these output structures, they shouldn't change at all.

Post Processing

At the end of each idealization trajectory the app will write out the RMSD between the final idealized structure and the starting structure. For medium-sized proteins with good geometry I often see values if the range of 0.1 Angstroms. If the final RMSD is approaching 1 Angstrom or above, there may have been something funny. Watch out for chainbreaks in the starting PDB file! To handle these, you would need to set a fold-tree with a cutpoint at the chainbreak, otherwise the app will idealize the break leading to large deviations.

Generated on Sun Mar 6 22:03:06 2011 for Rosetta Projects by  doxygen 1.5.9

© Copyright Rosetta Commons Member Institutions. For more information, see