Movers (RosettaScripts)

Each mover definition has the following structure

<"mover_name" name="&string" .../>

where "mover_name" belongs to a predefined set of possible movers that the parser recognizes and are listed below, name is a unique identifier for this mover definition and then any number of parameters that the mover needs to be defined.

Table of contents

Mover Documentation Guide

Since RosettaScripts allows you to put Movers together in ways that have not been tried before there are a few things you NEED to answer when documenting your mover:

<MyMover name="&string" bool_option=(1 &bool) int_option=(50 &int) string_option=(&string) real_option=(2.2 &Real) scorefxn=(default_scorefxn &string) task_operations=(&string,&string,&string)/>)

Predefined Movers

The following are defined internally in the parser, and the protocol can use them without defining them explicitly.


Has an empty apply. Will be used as the default mover in <PROTOCOLS> if no mover_name is specified. Can be explicitly specified, with the name "null".

Special Movers

Combining Movers

ParsedProtocol (formerly DockDesign)

This is a special mover that allows making a single compound mover and filter vector (just like protocols). The optional option mode changes the order of operations within the protocol, as defined by the option. If undefined, mode defaults to the historical functionality, which is operation of the Mover/Filter pairs in the defined order.

<ParsedProtocol name=( &string) mode=( &string)>
	<Add mover_name=( null &string) filter_name=( true_filter &string) apply_probabilities=(see below &Real/>


Calling another RosettaScript from within a RosettaScript

<Subroutine name=(&string) xml_fname=(&string)/>

This definition in effect generates a Mover that can then be incorporated into the RosettaScripts PROTOCOLS section. This allows a simplification and modularization of RosettaScripts.

Recursions are allowed but will cause havoc.


Implements a simple IF (filter(pose)) THEN true_mover(pose) ELSE false_mover(pose). true_mover is required, false_mover is not.

<If name=( &string) filter_name=(&string) true_mover_name=(&string) false_mover_name=(null &string)/>

Looping/Monte Carlo Movers


Allows looping over a mover using either iterations or a filter as a stopping condition (the first turns true). By using DockDesign mover above with loop can be useful, e.g., if making certain moves is expensive and then we want to exhaust other, shorter moves.

<LoopOver name=(&string) mover_name=(&string) filter_name=( false_filter &string) iterations=(10 &Integer) drift=(true &bool)/>

drift: true- the state of the pose at the end of the previous iteration will be the starting state for the next iteration. false- the state of the pose at the start of each iteration will be reset to the state when the mover is first called. Note that "falling off the end" of the iteration will revert to the original input pose, even if drift is set to true.

This mover is somewhat deprecated in favor of the more general GenericMonteCarlo mover.


Allows sampling structures by MonteCarlo with a mover. The score evaluation of pose during MC are done by Filters that can do report_sm(), not only ScoreFunctions.
You can choose either format:

1) scoring by Filters

<GenericMonteCarlo name=(&string) mover_name=(&string) filter_name=(&string) trials=(10 &integer) sample_type=(low, &string) temperature=(0, &Real) drift=(1 &bool) recover_low=(1 &bool) boltz_rank=(0 &bool) stopping_condition=(FalseFilter &string) preapply=(1 &bool) adaptive_movers=(0 &bool) adaptation_period=(see below &integer)>
     <AND filter_name=(&string) temperature=(&Real) sample_type=(low, &string) rank=(0 &bool)/>

2) scoring by ScoreFunction

<GenericMonteCarlo name=(&string) mover_name=(&string) scorefxn_name=(&string) trials=(10 &integer) sample_type=(low, &string) temperature=(0, &Real) drift=(1 &bool) recover_low=(1 &bool) stopping_condition=(FalseFilter &string) preapply=(1 &bool)/>

Multiple filters can be defined for an MC mover. These filters are then applied sequentially in the order listed and only if the pose passes the Metropolis criterion for all filters is it accepted. This allows the extension of MC to a multicriterion framework where more than one criterion is optimized, say the total score and the binding energy. See demos/rosetta_scripts/experimental/computational_affinity_maturation_strategy2 for an example. It's recommended to list the computationally expensive filters last, as later filters will only be calculated if the earlier filters all pass.

In the multiple filter case, the filter to be used for the official score of the pose (e.g. for recover_low purposes) can be specified with the rank parameter (this has no effect on the MC accept/reject). If no sub-filters are set with rank=1, the first filter is used for ranking. As a special case, if boltz_rank is set to true, the ranking score is a temperature-weighted sum of all filter values. (This value is equivalent to the effective value optimized by the MC protocol.)

A task can optionally be included for automatic setting of the number of trials in a GenericMonteCarlo run. Without a task input the number of trials is set by the Trials integer input. If a task is included, the number of designable residues will be calculated and the number of trials will be automatically set as task_scaling * (number designable residues). For example, if there are 10 designable residues and task_scaling is 5 (the default) the number of trials will be 50. The task_scaling is set to 5 by default and can be adjusted in the xml with the task_scaling flag. Giving an input task will override any value set by the Trials input. This allows for automation over a number of different input files. Input the task as for any other move, see example xml line below. Note that the input task does not alter the movers/filters contained within the GenericMonteCarlo, it is only used for calculating the number of designable residues.

<GenericMonteCarlo name=(&string) mover_name=(&string) filter_name=(&string) trials=(10 &integer) sample_type=(low, &string) temperature=(0, &Real) drift=(1 &bool) recover_low=(1 &bool) boltz_rank=(0 &bool) stopping_condition=(FalseFilter &string) preapply=(1 &bool) task_operations=(&string,&string,&string) task_scaling=(5 &integer)>


Associated with GenericMonteCarlo. Simply test the MC criterion of the specified GenericMonteCarloMover and save the current pose if accept.

<MonteCarloTest name=(&string) MC_name=(&string)/>

Useful in conjunction with MonteCarloRecover (below) if you're running a trajectory consisting of many different sorts of movers, and would like at each point to decide whether the pose has made an improvement.


Associated with GenericMonteCarlo and MonteCarloTest. Recover a pose from a GenericMonteCarloMover.

<MonteCarloRecover name=(&string) MC_name=(&string) recover_low=(1 &bool)/>

Useful in conjunction with MonteCarloRecover (below) if you're running a trajectory consisting of many different sorts of movers, and would like at each point to decide whether the pose has made an improvement.


This mover takes as input the name of a montecarlo object specified by the user, and calls the reset or recover_low function on it.

<MonteCarloUtil name=(&string) mode=(&string) montecarlo=(&string)/>


This mover performs Metropolis-Hastings Monte Carlo simulations, which can be used to estimate the thermodynamic distribution of conformational states for a given score function, temperature, and set of underlying movers. See the dedicated MetropolisHastings Documentation page for more information.

<MetropolisHastings name=(&string) scorefxn=(score12 &string) temperature=(0.6 &Real) trials=(1000 &Size)>

The MetropolisHastings mover uses submovers to perform the trial moves and optionally record statistics about the simulation after each trial. They can be specified in one of two ways:

  1. Defining the movers within MetropolisHastings:
    <MetropolisHastings ...>
      <Backrub sampling_weight=(1 &Real) .../>
  2. Referencing previously defined movers:
    <Backrub name=backrub .../>
    <MetropolisHastings ...>
      <Add mover_name=backrub sampling_weight=(1 &Real)/>

In either case, the probability that any given submover will be chosen during the simulation can be controlled using the sampling_weight parameter. The sampling weights for all movers are automatically normalized to 1. Submovers used with MetropolisHastings must be subclasses of ThermodynamicMover.

In addition to trial movers, you can also specify a specialized mover that will change the temperature or score function during the simulation. This type of mover is called a TemperatureController. Finally, additional movers that only record simulation statistics after each trial move can also be used, which are known as ThermodynamicObserver modules.

Both the TemperatureController and ThermodynamicObserver modules can be specified in the same two ways as trial movers, with the sampling_weight excluded, for example:

<MetropolisHastings ...>
  <Backrub sampling_weight=(1 &Real) .../>
  <SimulatedTempering temp_low=(0.6 &Real) .../>
  <PDBTrajectoryRecorder stride=(100 &Size) filename=(traj.pdb &string)/>
  <MetricRecorder stride=(100 &Size) filename=(metrics.txt &string)>
    <Torsion rsd=(&string) type=(&string) torsion=(&Size) name=("" &string)/>


Repeatedly applies a sub-mover until the given filter returns a value within the given delta for the given number of cycles

<IteratedConvergence name=(&string) mover=(&string) filter=(&string) delta=(0.1 &real) cycles=(1 &integer) maxcycles=(1000 &integer) />


Repeatedly applies a given mover while ramping the score from a low value to a high value.

<RampingMover name=(&string) start_weight=(&real) end_weight=(&real) outer_cycles=(&real) inner_cycles=(&real) score_type=(&string) ramp_func=(&string) montecarlo=(&string) mover=(&string)/>



This mover reports specified features of each input pose to a relational database. Depending upon which features are used, this can be an effective way of extracting structural information for later analysis.

<ReportToDB name="&string" db="&string" sample_source="&string">
   <feature name="&string" scorefxn=(&string)/>
   <feature name="&string" scorefxn=(&string)/>

You may find this short tutorial on how to do SQL queries on a database once you have generated it.

See the features ( integration test (rosetta/rosetta_tests/integration/tests/features) for a full working example, and the features scientific benchmark for a more extensive usage.


Dumps a pdb. Recommended ONLY for debuggging as you can't change the name of the file during a run. If scorefxn is specified, a scored pdb will be dumped.

<DumpPdb name=(&string) fname=(dump.pdb &string) scorefxn=(&string)/>


Record a trajectory to a multimodel PDB file. Only record models every n times using stride. Append ".gz" to filename to use compression.

<PDBTrajectoryRecorder stride=(100 &Size) filename=(traj.pdb &string) cumulate_jobs=(0 &bool) cumulate_replicas=(0 &bool)/>

If run with MPI, the cumulate_jobs and cumulate_replicas parameters affect the filename where the trajectory is ultimately written. For instance, with the default filename parameter of traj.pdb, input structure name of structname, trajectory number of XXXX, and replica number of YYY, the following names will be generated given the options.


Record a trajectory of snapshots as silent-file.

<SilentTrajectoryRecorder stride=(100 &Size) score_stride=(100 &Size) filename=(traj &string) cumulate_jobs=(0 &bool) cumulate_replicas=(0 &bool)/>

By default, this will actually generate PDB file output. To get silent file output, several additional command line flags are required:

  -out:file:silent <silent filename> -run:intermediate_structures

If used within MetropolisHastings, the current job output name becomes part of the filename. If run with MPI, the cumulate_jobs and cumulate_replicas parameters affect the filename where the trajectory is ultimately written. For instance, with the default filename parameter of traj, input structure name of structname, trajectory number of XXXX, replica number of YYY, and -out:file:silent default.out, the following names will be generated given the options.


Record numeric metrics to a tab-delimited text file. Only record metrics every n times using stride. Append ".gz" to filename to use compression.

Currently only torsion angles can be recorded, specified using the TorsionID. The residue can be indicated using absolute Rosetta number (integer) or with the PDB number and chain (integer followed by character).

<MetricRecorder stride=(100 &Size) filename=(metrics.txt &string) cumulate_jobs=(0 &bool) cumulate_replicas=(0 &bool) prepend_output_name=(0 &bool) >
  <Torsion rsd=(&string) type=(&string) torsion=(&Size) name=("" &string)/>

If used within MetropolisHastings, the current job output name is prepended to filename. If run with MPI, the cumulate_jobs and cumulate_replicas parameters affect the filename where the metrics are ultimately written. For instance, with the default filename parameter of metrics.txt, input structure name of structname, trajectory number of XXXX, and replica number of YYY, the following names will be generated given the options.

If not used within MetropolisHastings, by default the current job output name will not be prepended to the filename, similar to metrics.txt above. If prepend_output_name=1, then it will be prepended following the format, structname_XXXX_metrics.txt.

General Movers

These movers are general and should work in most cases. They are usually not aware of things like interfaces, so may be most appropriate for monomers or basic tasks.



Repacks sidechains with user-supplied options, including TaskOperations

<PackRotamersMover name="&string" scorefxn=(score12 &string) task_operations=(&string,&string,&string)/>


Does minimization over sidechain and/or backbone

<MinMover name="&string" scorefxn=(score12 &string) chi=(&bool) bb=(&bool) jump=(&string) type=(dfpmin_armijo_nonmonotone &string) tolerance=(0.01&Real)>

Note that defaults are as for the MinMover class! Check for the default constructor.


Performs minimization. Accepts TaskOperations via the task_operations option e.g.


to configure which positions are minimized. Options

chi=(&bool) and bb=(&bool)
control sidechain or backbone freedom. Defaults to sidechain minimization. Options scorefxn, jump, type, and tolerance are passed to the underlying MinMover


Packs then minimizes a sidechain before calling MonteCarlo on the change. It can be modified with user supplied ScoreFunction or TaskOperation. It does not do backbone, ridged body minimization.

<MinPackMover name="&string" scorefxn=("score12" &string) task_operations=(&string,&string,&string)/>

It is reccomended to change the weights you are using to the score12minpack weights. These are the standard score12 weights with the reference energies refit for sequence recovery profile when using the MinPackMover. Without these weights you will see a lot of Tryptophan residues on the surface of a protein.


The "off rotamer" sidechain-only moves.

<Sidechain name=(&string) preserve_detailed_balance=(1 &bool) task_operations=(&string,&string,&string) prob_uniform=(0.0 &real) prob_withinrot=(0.0 &real) prob_random_pert_current=(0.0 &real)/>


The "off rotamer" sidechain-only Monte Carlo sampler. For a rather large setup cost, individual moves can be made efficiently.

The underlying mover is still under development/benchmarking, so it may or may not work with backbone flexibility or amino acid identity changes.

<SidechainMC name=(&string) ntrials=(10000 &int) scorefxn=(score12 &string) temperature=(1.0 &real) inherit_scorefxn_temperature=(0 &bool) preserve_detailed_balance=(1 &bool) task_operations=(&string,&string,&string) prob_uniform=(0.0 &real) prob_withinrot=(0.0 &real) prob_random_pert_current=(0.0 &real)/>


This mover goes through each repackable/redesignable position in the pose, taking every permitted rotamer in turn, and evaluating the energy. Each position is then updated to the lowest energy rotamer. It does not consider coordinated changes at multiple residues, and may need several invocations to reach convergence.

In addition to the score function, the mover takes a list of task operations to specify which residues to consider. (See TaskOperations (RosettaScripts).)

<RotamerTrialsMover name="&string" scorefxn=(&string) task_operations=(&string,&string,&string) show_packer_task=(0 &bool) />


This mover goes through each repackable/redesignable position in the pose, taking every permitted rotamer in turn, minimizing it in the context of the current pose, and evaluating the energy. Each position is then updated to the lowest energy minimized rotamer. It does not consider coordinated changes at multiple residues, and may need several invocations to reach convergence.

In addition to the score function, the mover takes a list of task operations to specify which residues to consider. (See TaskOperations (RosettaScripts).)

<RotamerTrialsMinMover name="&string" scorefxn=(&string) task_operations=(&string,&string,&string)/>


This mover will mutate residues to the most-frequently occuring residues in a multiple sequence alignment, while making sure that the new residue scores well in rosetta. It takes a position specific scoring matrix (pssm) as input to determine the most frequently occuring residues at each position. The user defines a packer task of the residues which will be designed. At each of these positions only residues which appear as often or more often (same pssm score or higher) will be allowed in subsequent design. Design is then carried out with the desired score function, optionally adding a residues identity constraint proportional to the pssm score (more frequent residues get a better energy).

<ConsensusDesignMover name="&string" scorefxn=(&string) invert_task=(&bool) sasa_cutoff=(&float) use_seqprof_constraints=(&bool) task_operations=(&string)/>



Some protocols (LoopHashing) require the pose to have ideal bond lengths and angles. Idealize forces these values and then minimizes the pose in a stripped-down energy function (rama, disulf, and proline closure) and in the presence of coordinate constraints. Typically causes movements of 0.1A from original pose, but the scores deteriorate. It is therefore recommended to follow idealization with some refinement.

<Idealize name=(&string) atom_pair_constraint_weight=(0.0&Real) coordinate_constraint_weight=(0.01&Real) fast=(0 &bool) report_CA_rmsd=(1 &bool) ignore_residues_in_csts=(&comma delimited residue list) impose_constraints=(1&bool) constraints_only=(0&bool)/>

impose_constraints & constraints_only can be used intermittently to break the idealize process into two stages: first impose the constraints on a 'realistic' pose without idealizing (constraints_only=1), then mangle the pose and apply idealize again (impose_constraints=0).


Performs the fast relax protocol.

<FastRelax name="&string" scorefxn=(score12 &string) repeats=(8 &int) task_operations=(&string, &string, &string >
   <MoveMap name=(""&string)>
      <Chain number=(&integer) chi=(&bool) bb=(&bool)/>
      <Jump number=(&integer) setting=(&bool)/>
      <Span begin=(&integer) end=(&integer) chi=(&bool) bb=(&bool)/>

Options include:

The MoveMap is initially set to minimize all degrees of freedom. The movemap lines are read in the order in which they are written in the xml file, and can be used to turn on or off dofs. The movemap is parsed only at apply time, so that the foldtree and the kinematic structure of the pose at the time of activation will be respected.



Runs the full (post refactoring) docking protocol with the defaults currently in trunk. This mover is not currently sensitive to symmetry.

<DockingProtocol name="&string" docking_score_low=(interchain_cen &string) docking_score_high=(docking &string) low_res_protocol_only=(0 &bool) docking_local_refine(0 &bool) dock_min=(0 &bool) ignore_default_docking_task=(0 &bool) task_operations=("" comma-separated list) partners=(&string)>


Flexible peptide docking protocol. This tag encompasses 2 closely related protocols:

Basic options:

Note that only one of the 5 can exist in a tag: extra_scoring,ppk_only,pep_refine,lowres_abinitio,min_only.

<FlexPepDock name=(&string) min_only=(&boolean) pep_refine=(&boolean)
 lowres_abinitio=(&boolean) peptide_chain=(&string) receptor_chain=(&string) 
ppk_only=(&boolean) scorefxn=(&string) extra_scoring=(&boolean)/>

Backbone Movement


Sets a given torsion to a specified value.

<SetTorsion name="&string" resnum=(pdb/rosetta numbering) torsion_name=(&string) angle=(&real)/>


Shear style backbone-torsion moves that minimize downstream propagation.

<Shear name="&string" temperature=(0.5 &Real) nmoves=(1 &Integer) angle_max=(6.0 &Real) preserve_detailed_balance=(0 &bool)/>

See Rohl CA, et al. (2004) Methods Enzymol. Protein structure prediction using Rosetta, 383:66


Small-move style backbone-torsion moves that, unlike shear, do not minimize downstream propagation.

<Shear name="&string" temperature=(0.5 &Real) nmoves=(1 &Integer) angle_max=(6.0 &Real) preserve_detailed_balance=(0 &bool)/>

See Rohl CA, et al. (2004) Methods Enzymol. Protein structure prediction using Rosetta, 383:66


Purely local moves using rotations around axes defined by two backbone atoms.

<Backrub name=(&string) pivot_residues=(all residues &string) pivot_atoms=(CA &string) min_atoms=(3 &Size) max_atoms=(34 &Size) max_angle_disp_4=(40/180*pi &Real) max_angle_disp_7=(20/180*pi &Real) max_angle_disp_slope=(-1/3/180*pi &Real) preserve_detailed_balance=(0 &bool) require_mm_bend=(1 &bool)/>



Adds constraints to the pose using the constraints' read-from-file functionality.

<ConstraintSetMover name=(&string) cst_file=(&string)/>

cst_file: the file containing the constraint data. e.g.,:

CoordinateConstraint CA 1 CA 380   27.514  34.934  50.283 HARMONIC 0 1
CoordinateConstraint CA 1 CA 381   24.211  36.849  50.154 HARMONIC 0 1


Add coordinate constraints to all residues that are considered designable by the task_operations. Mean and SD are hardwired to 0,1 at present. If you want to use this, don't forget to make downstream movers aware of coordinate constraints by changing their scorefxn's coordinate_constraint weight.

<TaskAwareCsts name=(&string) task_operations=(&comma-delimited list of task operations)/>

Fragment Insertion


Performs a single fragment insertion move on the pose. Respects the restrictions imposed by the user-supplied MoveMap and underlying kinematics of the pose (i.e. FoldTree). By default, all backbone torsions are movable. The MoveMap parameter is used to specify residues that should remain fixed during the simulation. Insertion positions are chosen in a biased manner in order to have roughly equivalent probability of acceptance at each allowable insertion position. This has traditionally been referred to as "end-biasing." Once an insertion position has been chosen, a Policy object is responsible for choosing from among the possible fragments contained in the fragment file. Currently, two policies are supported-- "uniform" and "smooth." The former chooses uniformly amongst the set of possibilities. The latter chooses the fragment that, if applied, causes minimal distortion to the pose.

In order to be useful, SingleFragmentMover should be paired with a Monte Carlo-based mover. If you're folding from the extended chain, "GenericMonteCarloMover" is a common choice. When folding from a reasonable starting model, "GenericMonteCarloMover" is *not* recommended-- it unilaterally accepts the first move. A simplified version of the ClassicAbinitio protocol is recapitulated in demo/rosetta_scripts/classic_abinitio.xml.

Input is *not* restricted to monomers. Oligomers work fine.

<SingleFragmentMover name=(&string) fragments=(&string) policy=(uniform &string)>
    <Span begin=(&int) end=(&int) chi=(&int) bb=(&int)/>


The following set of movers are aimed at creating and manipulating symmetric poses within RosettaScripts. For the complete symmetry documentation, see the "Symmetry User's Guide" in Rosetta's Doxygen documentation.

Notice that symmetric poses must be scored with symmetric score functions. See the 'symmetric' tag in the RosettaScripts score function documentation.


Given a symmetry definition file that describes configuration and scoring of a symmetric system, this mover "symmetrizes" an asymmetric pose. For example, given the symmetry definition file 'C2.symm':

<SetupForSymmetry name=setup_symm definition=C2.symm/>


The inverse of SetupForSymmetry: given a symmetric pose, make a nonsymmetric pose that contains only the asymmetric unit.

<ExtractAsymmetricUnit name=extract_asu/>


Similar to ExtractAsymmetricUnit: given a symmetric pose, make a nonsymmetric pose that contains the entire system (all monomers). Can be used to run symmetric and asymmetric moves in the same trajectory.

<ExtractAsymmetricPose name=extract_asp/>

SymPackRotamersMover and SymRotamerTrialsMover

The symmetric versions of pack rotamers and rotamer trials movers (they take the same tags as asymmetric versions)

<SymPackRotamersMover name=symm_pack_rot scorefxn=score12_symm task_operations=.../>
<SymRotamerTrialsMover name=symm_rot_trials scorefxn=score12_symm task_operations=.../>


The symmetric version of min mover (they take the same tags as asymmetric version). Notice that to refine symmetric degrees of freedom, all jumps must be allowed to move with the tag 'jump=ALL'.

<SymMinMover name=min1 scorefxn=ramp_rep1 bb=1 chi=1 jump=ALL/>

Example: Symmetric FastRelax

The following RosettaScript runs a protocol similar to Rosetta's symmetric fast relax using the symmetric pack rotamers and symmetric min mover (note that the fastrelax mover respects symmetric poses, this example is merely done to illustrate the symmetric movers).

		<InitializeFromCommandline name=init/>
		<RestrictToRepacking name=restrict/>
		<IncludeCurrent name=keep_curr/>
		<ramp_rep1 weights=score12_full symmetric=1>
			<Reweight scoretype=fa_rep weight=0.0088/>
		<ramp_rep2 weights=score12_full symmetric=1>
			<Reweight scoretype=fa_rep weight=0.11/>
		<ramp_rep3 weights=score12_full symmetric=1>
			<Reweight scoretype=fa_rep weight=0.22/>
		<ramp_rep4 weights=score12_full symmetric=1/>
		<SetupForSymmetry   name=setup_symm definition=C2.symm/>
		<SymPackRotamersMover name=repack1 scorefxn=ramp_rep1 task_operations=init,restrict,keep_curr/>
		<SymPackRotamersMover name=repack2 scorefxn=ramp_rep2 task_operations=init,restrict,keep_curr/>
		<SymPackRotamersMover name=repack3 scorefxn=ramp_rep3 task_operations=init,restrict,keep_curr/>
		<SymPackRotamersMover name=repack4 scorefxn=ramp_rep4 task_operations=init,restrict,keep_curr/>
		<SymMinMover name=min1 scorefxn=ramp_rep1 type=lbfgs_armijo_nonmonotone tolerance=0.01 bb=1 chi=1 jump=ALL/>
		<SymMinMover name=min2 scorefxn=ramp_rep2 type=lbfgs_armijo_nonmonotone tolerance=0.01 bb=1 chi=1 jump=ALL/>
		<SymMinMover name=min3 scorefxn=ramp_rep3 type=lbfgs_armijo_nonmonotone tolerance=0.01 bb=1 chi=1 jump=ALL/>
		<SymMinMover name=min4 scorefxn=ramp_rep4 type=lbfgs_armijo_nonmonotone tolerance=0.00001 bb=1 chi=1 jump=ALL/>
		<ParsedProtocol name=ramp_rep_cycle>
			<Add mover=repack1/>
			<Add mover=min1/>
			<Add mover=repack2/>
			<Add mover=min2/>
			<Add mover=repack3/>
			<Add mover=min3/>
			<Add mover=repack4/>
			<Add mover=min4/>
		<GenericMonteCarlo name=genericMC mover_name=ramp_rep_cycle scorefxn_name=ramp_rep4 temperature=100.0 trials=4/> 
		<Add mover=setup_symm/>
		<Add mover=genericMC/>

Issues with Symmetry and Rosetta Scripts

For the most part, simple movers and filters will handle symmetric poses without modification. More complicated movers may run into some problems. To adopt a complex mover for symmetry, see the section "How to adopt your protocol to use symmetry" in the "Symmetry User's Guide" in Rosetta's Doxygen documentation.

One RosettaScript-specific problem with parsable movers and symmetry has to do with how the scorefunction map is accessed in parse_my_tag. When getting a scorefunction off the data map, the following code WILL NOT WORK WITH SYMMETRY:

scorefxn_ = new ScoreFunction( *data.get< ScoreFunction * >( "scorefxns", sfxn_name ));

This ignores whether 'sfxn_name' is symmetric or not. Instead, use clone to preserve whether or not the scorefunction is symmetric:

scorefxn_ = data.get< ScoreFunction * >( "scorefxns", sfxn_name )->clone();

This often is the problem when a mover gives the following error in a symmetric pose:

ERROR: !core::pose::symmetry::is_symmetric( pose )
ERROR:: Exit from: src/core/scoring/ line: 547

Other Pose Manipulation


Adds a chainbreak at the specified position

<AddChainBreak name=(&string) resnum=(&string) change_foldtree=(1 &bool) find_automatically=(0 &bool) distance_cutoff=(2.5&Real)/>


Wrapper for utility function fold_tree_from_loops. Defines a fold tree based on loop definitions with the fold tree going up to the loop n-term, and the c-term and jumping between. Cutpoints define the kinematics within the loop

<FoldTreeFromLoops name=(&string) loops=(&string)/>

the format for loops is: Start:End:Cut,Start:End:Cut...

and either pdb or rosetta numbering are allowed. The start, end and cut points are computed at apply time so would respect loop length changes.


Changes a loop length without closing it.

<LoopLengthChange name=(&string) loop_start=(&resnum) loop_end=(&resnum) delta=(&int)/>


Convert pose into poly XXX ( XXX can be any amino acid )

<MakePolyX name="&string" aa="&string" keep_pro=(0 &bool)  keep_gly=(1 &bool) keep_disulfide_cys=(0 &bool) />

Options include:


Simple wrapper around the MembraneTopology object in core/scoring. Takes in a membrane span file and inserts the membrane topology into the pose cache. The pose can then be used with a membrane score function.

<MembraneTopology name=(&string) span_file=(&string)/>

Span files have the following structure:


Switches the residue sets (e.g., allatom->centroid, or vice versa).

<SwitchResidueTypeSetMover name="&string" set=(&string)/>

Typically, RosettaScripts assumes that poses are all-atom. In some cases, a centroid pose is needed, e.g., for centroid scoring, and this mover is used in those cases.


<FavorNativeResidue bonus=(1.5 &bool)/>

sets residue_type_constraint to the pose and sets the bonus to 1.5.

Note: The use of this mover is somewhat deprecated in favor of FavorSequenceProfile with "scaling=prob matrix=IDENTITY" or with "scaling=none matrix=MATCH"


<FavorSequenceProfile scaling=("prob" &string) weight=(1 &Real)  pssm=(&string) use_native=(false &bool) use_starting=(false &bool) use_current=(false &bool) pdbname=(&string) matrix=(BLOSUM62 &string) scorefxns=(comma seperated list of &string)/>

Sets residue type constraints on the pose according to the given profile and weight. Set one (and only one) of the following:

You can set how to scale the given values with the "scaling" settings. The default value of "prob" does a per-residue Boltzmann-weighted probability based on the profile score (the unweighted scores for all 20 amino acid identities at any given position sum to -1.0). A setting of "global" does a global linear fixed-zero rescaling such that all (pre-weighted) values fall in the range of -1.0 to 1.0. A setting of "none" does no adjustment of values.

The parameter "weight" can be used to adjust the post-scaling strength of the constraints. (e.g. at a weight=0.2, global-scaled constraint energies fall in the range of -0.2 to 0.2 and prob-weighted IDENTITY-based constraint energies are in the range of -0.2 to 0, both assuming a res_type_constraint=1)

Note that the weight parameter does not affect the value of res_type_constraint in the scorefunction. As the constraints will only be visible with non-zero res_type_constraint values, the parameter scorefxns is a convenience feature to automatically set res_type_constraint to 1 in the listed functions where it is currently turned off.

If a structure is used for input instead of a PSSM, the profile weights used are based off of the given substitution matrix in the database. Current options include:

NOTE: The default behavior of FavorSequenceProfile has changed from previous versions. If you're using a structure as a reference, you'll want to check your weight, scaling and substitution matrix to make sure your energy values are falling in the appropriate range.


Set the temperature (b-)factor column in the PDB based on a filter's per-residue information. Useful for coloring a protein based on some energy. The filter should be ResId-enabled (reports per-residue values) or else an error occurs.

<SetTemperatureFactor name="&string" filter=(&string) scaling=(1.0&Real)/>


Rotate pose over a given axis.

		<RollMover name=(&string) start_res=(&int) stop_res=(&int) min_angle=(&Real) max_angle=(&Real) > 
		       <axis x=(&Real) y=(&Real) z=(&Real) /> 
		       <translate x=(&Real) y=(&Real) z=(&Real) /> 



Remodel and rebuild a protein chain

IMPORTANT NOTE!!!!: Remodel uses an internal system of trajectories controlled by the option -num_trajectory [integer, >= 1]. If num_trajectory > 1 each result is scored with score12 and the pose with lowest energy is handed to the next mover or filter. -num_trajectory 1 is recommended for rosetta_scripts.

		<RemodelMover name=(&string)/> 

Protein Interface Design Movers

These movers are at least somewhat specific to the design of protein-protein interfaces. Attempting to use them with, for example, protein-DNA complexes may result in unexpected behavior.


Multistate design of a protein interface. The target state is the bound (input) complex and the two competitor states are the unbound partners and the unbound, unfolded partners. Uses genetic algorithms to select, mutate and recombine among a population of starting designed sequences. See Havranek & Harbury NSMB 10, 45 for details.

<ProteinInterfaceMS name="&string" generations=(20 &integer) pop_size=(100 &integer) num_packs=(1 &integer) pop_from_ss=(0 &integer) numresults=(1 &integer) fraction_by_recombination=(0.5 &real) mutate_rate=(0.5 &real) boltz_temp=(0.6 &real) anchor_offset=(5.0 &real) checkpoint_prefix=("" &string) gz=(0 &bool) checkpoint_rename=(0 &bool) scorefxn=(score12 &string) unbound=(1 &bool) unfolded=(1&bool) input_is_positive=(1&bool) task_operations=(&comma-delimited list) unbound_for_sequence_profile=(unbound &bool) profile_bump_threshold=(1.0 &Real) compare_to_ground_state=(see below & bool) output_fname_prefix=("" &string)>
   <Positive pdb=(&string) unbound=(0&bool) unfolded=(0&bool)/>
   <Negative pdb=(&string) unbound=(0&bool) unfolded=(0&bool)/>

The input file (-s or -l) is considered as either a positive or negative state (depending on option, input_is_positive). If unbound and unfolded is true in the main option line, then the unbound and the unfolded states are added as competitors. Any number of additional positive and negative states can be added. Unbound and unfolded takes a different meaning for these states: if unbound is checked, the complex will be broken apart and the unbound state will be added. If unfolded is checked, then the unbound and unfolded protein will be added.

unbound_for_sequence_profile: use the unbound structure to generate an ala pose and prune out residues that are not allowed would clash in the monomeric structure. Defaults to true, if unbound is used as a competitor state. profile_bump_threshold: what bump threshold to use above. The difference between the computed bump and the bump in the ala pose is compared to this threshold.

compare_to_ground_state: by default, if you add states to the list using the Positive/Negative tags, then the energies of all additional states are zeroed at their 'best-score' values. This allows the user to override this behaviour. See code for details.

output_fname_prefix: All of the positive/negative states that are defined by the user will be output at the end of the run using this prefix. Each state will have its sequence changed according to the end sequence and then a repacking and scoring of all states will take place according to the input taskfactory.

Rules of thumb for parameter choice. The Fitness F is defined as:

 F = Sum_+( exp(E/T) ) / ( Sum_+( exp(E/T) ) + Sum_-( exp(E/T) ) + Sum_+((E+anchor)/T) )

where Sum_-, and Sum_+ is the sum over the negative and positive states, respectively.

the values for F range from 1 (perfect bias towards +state) to 0 (perfect bias towards -state). The return value from the PartitionAggregateFunction::evaluate method is -F, with values ranging from -1 to 0, correspondingly. You can follow the progress of MSD by looking at the reported fitnesses for variants within a population at each generation. If all of the parameters are set properly (temperature etc.) expect to see a wide range of values in generation 1 (-0.99 - 0), which is gradually replaced by higher-fitness variants. At the end of the simulation, the population will have shifted to -1.0 - -0.5 or so.

For rules of thumb, it's useful to consider a two-state, +/- problem, ignoring the anchor (see below, that's tantamount to setting anchor very high) In this case FITNESS simplifies to:

 F = 1/(exp( (dE)/T ) + 1 )

and the derivative is:

 F' = 1/(T*(exp(-dE/T) + exp(dE/T) + 2)

where dE=E_+ - E_-

A good value for T would then be such where F' is sizable (let's say more than 0.05) at the dE values that you want to achieve between the positive and negative state. Since solving F' for T is not straightforward, you can plot F and F' at different temperatures to identify a reasonable value for T, where F'(dE, T) is above a certain threshold. If you're lazy like me, set T=dE/3. So, if you want to achieve differences of at least 4.5 e.u between positive and negative states, use T=1.5.

To make a plot of these functions use MatLab or some webserver, e.g.,

The anchor_offset value is used to set a competitor (negative) state at a certain energy above the best energy of the positive state. This is a computationally cheap assurance that as the specificity changes in favour of the positive state, the stability of the system is not overly compromised. Set anchor_offset to a value that corresponds to the amount of energy that you're willing to forgo in favour of specificity.


Calculate binding energies, buried interface surface areas, packing statistics, and other useful interface metrics for the evaluation of protein interfaces.

<InterfaceAnalyzerMover name="&string" scorefxn=(&string) packstat=(&bool) pack_input=(&bool) pack_separated=(0, &bool) jump=(&int) tracer=(&bool) use_jobname=(&bool) resfile=(&bool) />


Does both centroid and full-atom docking

<Docking name="&string" score_low=(score_docking_low &string) score_high=(score12 &string) fullatom=(0 &bool) local_refine=(0 &bool) jumps=(1 &Integer vector) optimize_fold_tree=(1 &bool) conserve_foldtree=(0 &bool) design=(0 &bool) ignore_default_docking_task=(0 &bool) task_operations=("" comma-separated list)/>


Performs something approximating r++ prepacking (but less rigorously without rotamer-trial minimization) by doing sc minimization and repacking. Separates chains based on jump_num, does prepacking, then reforms the complex. If jump_num=0, then it will NOT separate chains at all.

<Prepack name=(&string) scorefxn=(score12 &string) jump_number=(1 &integer) task_operations=(comma-delimited list) min_bb=(0 &bool)/>


RepackMinimize does the design/repack and minimization steps using different score functions as defined by the protocol. For most purposes, the combination of PackRotamersMover with MinMover provide more flexibility and transparency than RepackMinimize, and are advised.

repack_partner1 (and 2) defines which of the partners to design. If no particular residues are defined, the interface is repacked/designs. If specific residues are defined, then a shell of residues around those target residues are repacked/designed and minimized. repack_non_ala decides whether or not to change positions that are not ala. Useful for designing an ala_pose so that positions that have been changed in previous steps are not redesigned. min_rigid_body minimize rigid body orientation. (as in docking)

<RepackMinimize name="&string" scorefxn_repack=(score12 &string) scorefxn_minimize=(score12 &string) repack_partner1=(1 &bool) repack_partner2=(1 &bool) design_partner1=(0 &bool) design_partner2=(1 &bool) interface_cutoff_distance=(8.0 &Real) repack_non_ala=(1 &bool) minimize_bb=(1 &bool * see below for more details) minimize_rb=(1 &bool) minimize_sc=(1 &bool) optimize_fold_tree=(1 & bool) task_operations=("" &string)>
    <residue pdb_num/res_num, see below/>

If no repack_partner1/2 options are set, you can specify repack=0/1 to control both. Similarly with design_partner1/2 and design=0/1


Same as for RepackMinimize with the addition that a list of target residues to be hbonded can be defined. Within a sphere of 'interface_cutoff_distance' of the target residues,the residues will be set to be designed.The residues that are allowed for design are restricted to hbonding residues according to whether donors (STRKWYQN) or acceptors (EDQNSTY) or both are defined. If residues have been designed that do not, after design, form hbonds to the target residues with energies lower than the hbond_energy, then those are turned to Ala.

<DesignMinimizeHbonds name=(design_minimize_hbonds &string) hbond_weight=(3.0 &float) scorefxn_design=(score12 &string) scorefxn_minimize=score12) donors="design donors? &bool" acceptors="design acceptors? &bool" bb_hbond=(0 &bool) sc_hbond=(1 &bool) hbond_energy=(-0.5 &float) interface_cutoff_distance=(8.0 &float) repack_partner1=(1 &bool) repack_partner2=(1 &bool) design_partner1=(0 &bool) design_partner2=(1 &bool) repack_non_ala=(1 &bool) min_rigid_body=(1 &bool) task_operations=("" &string)>
        <residue pdb_num="pdb residue and chain, e.g., 31B &string"/>
        <residue res_num="serially defined residue number, e.g., 212 &integer"/>


Turns either or both sides of an interface to Alanines (except for prolines and glycines that are left as in input) in a sphere of 'interface_distance_cutoff' around the interface. Useful as a step before design steps that try to optimize a particular part of the interface. The alanines are less likely to 'get in the way' of really good rotamers.

<build_Ala_pose name=(ala_pose &string) partner1=(0 &bool) partner2=(1 &bool) interface_distance_cutoff=(8.0 &float) task_operations=("" &string)/>


To be used after an ala pose was built (and the design moves are done) to retrieve the sidechains from the input pose that were set to Ala by build_Ala_pose. OR, to be used inside mini to recover sidechains after switching residue typesets. By default, sidechains that are different than Ala will not be changed, unless allsc is true. Please note that naming your mover "SARS" is almost certainly bad luck and strongly discouraged.

<SaveAndRetrieveSidechains name=(save_and_retrieve_sidechains &string) allsc=(0 &bool) task_operations=("" &string)/>


Sets up an atom tree for use with subsequent movers. Connects pdb_num on host_chain to the nearest residue on the neighboring chain. Connection is made through connect_to on host_chain pdb_num residue

<AtomTree name=(&string) docking_ft=(0 &bool) pdb_num/res_num=(see above) connect_to=(see below for defaults &string) anchor_res=(pdb numbering) connect_from=(see below) host_chain=(2 &integer) simple_ft=(0&bool)/>


Allows random spin around an axis that is defined by the jump. Works preferentially good in combination with a loopOver or best a GenericMonteCarlo and other movers together. Use SetAtomTree to define the jump atoms.

<SpinMover name=(&string) jump_num=(1 &integer)/>


Produces a set of rotamers from a given residue. Use after AtomTree to generate inverse rotamers of a given residue.

<TryRotamers name=(&string) pdb_num/res_num=(see above) automatic_connection=(1 &bool) jump_num=(1, &Integer) scorefxn=(score12 &string) explosion=(0 &integer) shove=(&comma-separated residue identities)/>

Each pass through TryRotamers will place the next rotamer at the given position. Increase -nstruct settings appropriately to obtain them all. Once all rotamers have been placed, TryRotamers will cause subsequent runs through the protocol with the same settings to fail.


Do backrub-style backbone and sidechain sampling.

<BackrubDD name=(backrub &string) partner1=(0 &bool) partner2=(1 &bool) interface_distance_cutoff=(8.0 &Real) moves=(1000 &integer) sc_move_probability=(0.25 &float) scorefxn=(score12 &string) small_move_probability=(0.0 &float) bbg_move_probability=(0.25 &float) temperature=(0.6 &float) task_operations=("" &string)>
        <residue pdb_num="pdb residue and chain, e.g., 31B &string"/>
        <residue res_num="serially defined residue number, e.g., 212 &integer"/>
        <span begin="pdb or rosetta-indexed number, eg 10 or 12B &string" end="pdb or rosetta-indexed number, e.g., 20 or 30B &string"/>

With the values defined above, backrub will only happen on residues 31B, serial 212, and the serial span 10-20. If no residues and spans are defined then all of the interface residues on the defined partner will be backrubbed by default. Note that setting partner1=1 makes all of partner1 flexible. Adding segments has the effect of adding these spans to the default interface definition Temperature controls the monte-carlo accept temperature. A setting of 0.1 allows only very small moves, where as 0.6 (the default) allows more exploration. Note that small moves and bbg_moves introduce motions that, unlike backrub, are not confined to the region that is being manipulated and can cause downstream structural elements to move as well. This might cause large lever motions if the epitope that is being manipulated is a hinge. To prevent lever effects, all residues in a chain that is allowed to backrub will be subject to small moves. Set small_move_probability=0 and bbg_move_probability=0 to eliminate such motions.

bbg_moves are backbone-Gaussian moves. See The J. Chem. Phys., Vol. 114, pp. 8154-8158.

Note: As of June 29, 2011, this mover was renamed from "Backrub" to "BackrubDD". Scripts run with versions of Rosetta after that date must be updated accordingly.


Removes Hotspot BackboneStub constraints from all but the best_n residues, then reapplies constraints to only those best_n residues with the given cb_force constant. Useful to prune down a hotspot-derived constraint set to avoid getting multiple residues getting frustrated during minimization.

<BestHotspotCst name=(&string) chain_to_design=(2 &integer) best_n=(3 &integer) cb_force=(1.0 &Real)/>

DomainAssembly (Not tested thoroughly)

Do domain-assembly sampling by fragment insertion in a linker region. frag3 and frag9 specify the fragment-file names for 9-mer and 3-mer fragments.

<DomainAssembly name=(&string) linker_start_(pdb_num/res_num, see above) linker_end_(pdb_num/res_num, see above) frag3=(&string) frag9=(&string)/>


Finds loops in the current pose and loads them into the DataMap for use by subsequent movers (eg - LoopRemodel)

<LoopFinder name="&string" interface=(1 &Size) ch1=(0 &bool) ch2=(1 &bool) min_length=(3 &Integer)
 max_length=(1000 &Integer) iface_cutoff=(8.0 &Real) resnum/pdb_num=(see above) 
CA_CA_distance=(15.0 &Real) mingap=(1 &Size)/>


Perturbs and/or refines a set of user-defined loops. Useful to sample a variety of loop conformations.

<LoopRemodel name="&string" auto_loops=(0 &bool) loop_start_(pdb_num/res_num, see above) loop_end_(pdb_num/res_num, see above) hurry=(0 &bool) cycles=(10 &Size) protocol=(ccd &string) perturb_score=(score4L &string) refine_score=(score12 &string) perturb=(0 &bool) refine=(1 &bool) design=(0 &bool)/>


Perturbs and/or refines a set of loops from a loop file. Also takes in fragment libraries from command line (-loops:frag_sizes , -loops:frag_files). Has kinematic, ccd and automatic protocols.

<LoopMoverFromCommandLine name="&string" loop_file=("loop.loops" &string) protocol=(ccd &string) perturb_score=(score4L &string) refine_score=(score12 &string) perturb=(0 &bool) refine=(1 &bool)/>

For protocol="automatic" (Based on Loop Modeling Application and LoopRemodel):

<LoopMoverFromCommandLine name="&string" loop_file=("loop.loops" &string) protocol=automatic perturb_score=(score4L &string) refine_score=(score12 &string) perturb=(0 &bool) refine=(no &string) remodel=(quick_ccd &string) relax=(no, &string) intermedrelax=(no &string)/>


Introduces a disulfide bond into the interface. The best-scoring position for the disulfide bond is selected from among the residues listed in targets. This could be quite time-consuming, so specifying a small number of residues in targets is suggested.

If no targets are specified on either interface partner, all residues on that partner are considered when searching for a disulfide. Thus including only a single residue for targets results in a disulfide from that residue to the best position across the interface from it, and omitting the targets param altogether finds the best disulfide over the whole interface.

Disulfide bonds created by this mover, if any, are guaranteed to pass a DisulfideFilter.

<DisulfideMover name="&string" targets=(&string)/>


Change a single residue to a different type. For instance, mutate Arg31 to an Asp.

<MutateResidue name=(&string) target=(&string) new_res=(&string) />


Test a design mover for its recapitulation of the native sequence. Similar to SequenceRecovery filter below, except that this mover encompasses a design mover more specifically.

<InterfaceRecapitulation name=(&string) mover_name=(&string)/>

The specified mover needs to be derived from either DesignRepackMover or PackRotamersMover base class and to to have the packer task show which residues have been designed. The mover then computes how many residues were allowed to be designed and the number of residues that have changed and produces the sequence recapitulation rate. The pose at parse-time is used for the comparison.

VLB (aka Variable Length Build)

Under development! All kudos to Andrew Ban of the Schief lab for making the Insert, delete, and rebuild segments of variable length. This mover will ONLY work with non-overlapping segments!

IMPORTANT NOTE!!!!: VLB uses its own internal tracking of ntrials! This allows VLB to cache fragments between ntrials, saving a very significant amount of time. But each ntrial trajectory will also get ntrials extra internal VLB apply calls. For example, "-jd2:ntrials 5" will cause a maximum of 25 VLB runs (5 for each ntrial). Success of a VLB move will break out of this internal loop, allowing the trajectory to proceed as normal.

<VLB name=(&string) scorefxn=(string)>
Default scorefxn is score4L. If you use another scorefxn, make sure the chainbreak weight is > 0. Do not use a full atom scorefxn with VLB!

There are several move types available to VLB, each with its own options. The most popular movers will probably be SegmentRebuild and SegmentInsert.

<SegmentInsert left=(&integer) right=(&integer) ss=(&string) aa=(&string) pdb=(&string) side=(&string) keep_bb_torsions=(&bool)/> 

Insert a pdb into an existing pose. To perform a pure insertion without replacing any residues within a region, use an interval with a zero as the left endpoint.
e.g. [0, insert_after_this_residue].
If inserting before the first residue the Pose then interval = [0,0].  If inserting after the last residue of the Pose then interval = [0, last_residue]. 

*ss = secondary structure specifying the flanking regions, with a character '^' specifying where the insert is to be placed. Default is L^L.
*aa = amino acids specifying the flanking regions, with a character '^' specifying insert.
*keep_bb_torsions = attempt to keep the a few torsions from around the insert. This should be false for pure insertions. (default false)
*side = specifies insertion on its N-side ("N"), C-side ("C") or decide randomly between the two (default "RANDOM"). Random is only random on parsing, not per ntrial

<SegmentRebuild left=(&integer) right=(&integer) ss=(&string) aa=(&string)/> 
Instruction to rebuild a segment. Can also be used to insert a segment, by specifying secondary structure longer than the original segment.
Very touchy. Watch out.
<SegmentSwap left=(&integer) right=(&integer) pdb=(&string)/> instruction to swap a segment with an external pdb
<Bridge left=(&integer) right=(&integer) ss=(&string) aa=(&string)/> connect two contiguous but disjoint sections of a
                       Pose into one continuous section
<ConnectRight left=(&integer) right=(&integer) pdb=(&string)/> instruction to connect one PDB onto the right side of another
<GrowLeft pos=(&integer) ss=(&string) aa=(&string)/> Use this for n-side insertions, but typically not n-terminal
			extensions unless necessary.  It does not automatically cover the
			additional residue on the right endpoint that needs to move during
			n-terminal extensions due to invalid phi torsion.  For that case,
			use the SegmentRebuild class replacing the n-terminal residue with
			desired length+1.
<GrowRight pos=(&integer) ss=(&string) aa=(&string)/> instruction to create a c-side extension

For more information, see the various BuildInstructions in src/protocols/forge/build/

Computational 'affinity maturation' movers (highly experimental)

These movers are meant to take an existing complex and improve it by subtly changing all relevant degrees of freedom while optimizing the interactions of key sidechains with the target. The basic idea is to carry out iterations of relax and design of the binder, designing a large sphere of residues around the interface (to get second/third shell effects).

We start by generating high affinity residue interactions between the design and the target. The foldtree of the design is cut such that each target residue has a cut N- and C-terminally to it, and jumps are introduced from the target protein to the target residues on the design, and then the system is allowed to relax. This produces deformed designs with high-affinity interactions to the target surface. We then use the coordinates of the target residues to generate harmonic coordinate restraints and send this to a second cycle of relax, this time without deforming the backbone of the design. Example scripts are available in demo/rosetta_scripts/computational_affinity_maturation/


Introduce a random mutation in a position allowed to redesign to an allowed residue identity. Control the residues and the target identities through task_operations. The protein will be repacked according to task_operations and scorefxn to accommodate the mutated amino acid. The mover can work with symmetry poses; simply use SetupForSymmetry and run. It will figure out that it needs to do symmetric packing for itself.

This can be used in conjunction with GenericMonteCarlo to generate trajectories of affinity maturation.

<RandomMutation name=(&string) task_operations=(&string comma-separated taskoperations) scorefxn=(score12 &string)/>


This mover will first attempt isolated/independent mutations defined in the input task operation, score/filter them all, rank them by score, then attempt to combine them, starting with the best scoring single mutation, accepting the mutation only if the filter score decreases, and working down the list to the end.



<GreedyOptMutationMover name=(&string) task_operations=(&string comma-separated taskoperations) filter=(&string) scorefxn=(score12 &string) relax_mover=(&string) sample_type=(low &string) dump_pdb=(0 &bool) stopping_condition=("" &string)/>


Creates a disjointed foldtree where each selected residue has cuts N- and C-terminally to it.

<HotspotDisjointedFoldTree name=(&string) ddG_threshold=(1.0 &Real) resnums=("" comma-delimited list of residues &string) scorefxn=(score12 &string) chain=(2 &Integer) radius=(8.0 &Real)/>


Adds harmonic constraints to sidechain atoms of target residues (to be used in conjunction with HotspotDisjointedFoldTree). Save the log files as those would be necessary for the next stage in affinity maturation.

<AddSidechainConstraintsToHotspots name=(&string) chain=(2 &Integer) coord_sdev=(1.0 &Real) resnums=(comma-delimited list of residue numbers)/>

Placement and Placement-associated Movers & Filters

The placement method has been described in:

Fleishman, SJ, Whitehead TA, et al. Science 332, 816-821. (2011) and JMB 413:1047

The objective of the placement methods are to help in the task of generating hot-spot based designs of protein binders. The starting point for all of them are a protein target (typically chain A), libraries of hot-spot residues, and a scaffold protein.

A few keywords used throughout the following section have special meaning and are briefly explained here.

Hotspot residue-libraries can be read once by the SetupHotspotConstraintsMover. In this mover you can decide how many hotspot residues will be kept in memory for a given run. This number of residues will be chosen randomly from the residues that were read. In this way, you can read arbitrarily large hotspot residue libraries, but each trajectory will only iterate over a smaller set.


This is a special mover associated with PlaceSimultaneously, below. It carries out the auctioning of residues on the scaffold to hotspot sets without actually designing the scaffold. If pairing is unsuccessful Auction will report failure.

<Auction name=( &string) host_chain=(2 &integer) max_cb_dist=(3.0 &Real) cb_force=(0.5 &Real)>
     <Add stubfile=(&string)/>

Note that none of the options, except for name, needs to be set up by the user if PlaceSimultaneously is notified of it. If PlaceSimultaneously is notified of this Auction mover, PlaceSimultaneously will set all of these options.


Map out the residues that might serve as a hotspot region on a target. This requires massive user guidance. Each hot-spot residue should be roughly placed by the user (at least as backbone) against the target. Each hot-spot residue should have a different chain ID. The method iterates over all allowed residue identities and all allowed rotamers for each residue. Tests its filters and for the subset that pass selects the lowest-energy residue by score12. Once the first hot-spot residue is identified it iterates over the next and so on until all hot-spot residues are placed. The output contains one file per residue identity combination.

<MapHotspot name="&string" clash_check=(0 &bool) file_name_prefix=(map_hs &string)>
     <Add jump=(&integer) explosion=(0 &integer) filter_name=(true_filter & string) allowed_aas=("ADEFIKLMNQRSTVWY" &string) scorefxn_minimize=(score12 &string) mover_name=(null &string)/>


This is a special mover associated with PlaceSimultaneously, below. It carries out the rigid-body minimization towards all of the stubsets.

<PlacementMinimization name=( &string) minimize_rb=(1 &bool) host_chain=(2 &integer) optimize_foldtree=(0 &bool) cb_force=(0.5 &Real)>
    <Add stubfile=(&string)/>


Remodels loops using kinematic loop closure, including insertion and deletion of residues. Handles hotspot constraint application through these sequence changes.

<PlaceOnLoop name=( &string) host_chain=(2 &integer) loop_begin=(&integer) loop_end=(&integer) minimize_toward_stub=(1&bool) stubfile=(&string) score_high=(score12 &string) score_low=(score4L&string) closing_attempts=(100&integer) shorten_by=(&comma-delimited list of integers) lengthen_by=(&comma-delimited list of integers)/>

currently only minimize_toward_stub is avaible. closing attempts: how many kinematic-loop closure cycles to use. shorten_by, lengthen_by: by how many residues to change the loop. No change is also added by default.

At each try, a random choice of loop change will be picked and attempted. If the loop cannot close, failure will be reported.

Demonstrated in JMB 413:1047


Hotspot-based sidechain placement. This is the main workhorse of the hot-spot centric method for protein-binder design. A paper describing the method and a benchmark will be published soon. The "stub" (hot-spot residue) is chosen at random from the provided stub set. To minimize towards the stub (during placement), the user can define a series of movers (StubMinimize tag) that can be combined with a weight. The weight determines the strength of the backbone stub constraints that will influence the mover it is paired with. Finally, a series of user-defined design movers (DesignMovers tag) are made and the result is filtered according to final_filter. There are two main ways to use PlaceStub:

  1. PlaceStub (default). Move the stub so that it's on top of the current scaffold position, then move forward to try to recover the original stub position.
  2. PlaceScaffold. Move the scaffold so that it's on top of the stub. You'll keep the wonderful hotspot interactions, but suffer from lever effects on the scaffold side. PlaceScaffold can be used as a replacement for docking by deactivating the "triage_positions" option.
<PlaceStub name=(&string) place_scaffold=(0 &bool) triage_positions=(1 &bool) chain_to_design=(2 &integer) score_threshold=(0.0 &Real) allowed_host_res=(&string) stubfile=(&string) minimize_rb=(0 &bool) after_placement_filter=(true_filter &string) final_filter=(true_filter &string) max_cb_dist=(4.0 &Real) hurry=(1 &bool) add_constraints=(1 &bool) stub_energy_threshold=(1.0 &Real) leave_coord_csts=(0 &bool) post_placement_sdev=(1.0 &Real)>
        <Add mover_name=(&string) bb_cst_weight=(10, &Real)/>
        <Add mover_name=(&string) use_constraints=(1 &bool) coord_cst_std=(0.5 &Real)/>
        <Add mover_name=(&string)/>

The available tracers are:

Submovers: Submovers are used to determine what moves are used following stub placement. For example, once a stub has been selected, a StubMinimize mover can try to optimize the current pose towards that stub. A DesignMover can be used to design the pose around that stub. Using DesignMover submovers within PlaceStub (instead of RepackMinimize movers outside PlaceStub) allows one to have a "memory" of which stub has been used. In this way, a DesignMover can fail a filter without causing the trajectory to completely reset. Instead, the outer PlaceStub mover will select another stub, and the trajectory will continue.
There are two types of sub movers that can be called within the mover.

  1. StubMinimize
    Without defining this submover, the protocol will simply perform a rigid body minimization as well as sc minimization of previous placed stubs in order to minimize towards the stub. Otherwise, a series of previously defined movers can be added, such as backrub, that will be applied for the stub minimization step. Before and after the list of stub minimize movers, there will be a rigid body minimization and a sc minimization of previously placed stubs. The bb_cst_weight determines how strong the constraints are that are derived from the stubs.
    • mover_name: a user previously defined design or minimize mover.
    • bb_cst_weight: determines the strength of the constraints derived from the stubs. This value is a weight on the cb_force, so larger values are stronger constraints.

    Valid/sensible StubMinimize movers are:

    • BackrubDD
    • LoopRemodel
  2. DesignMovers
    Design movers are typically used once the stubs are placed to fill up the remaining interface, since placestub does not actually introduce any further design other than stub placement.
    • mover_name: a user previously defined design or minimize mover.
    • use_constraints: whether we should use coordinate constraints during this design mover
    • coord_cst_std: the std of the coordinate constraint for this mover. The coord constraints are harmonic, and the force constant, k=1/std. The smaller the std, the stronger the constraint

    Valid/sensible DesignMovers are:

    • RepackMinimize
  3. NotifyMovers
  4. Movers placed in this section will be notified not to repack the PlaceStub-placed residues. This is not necessary if placement movers are used in a nested (recursive) fashion, as the placement movers automatically notify movers nested in them of the hot-spot residues. Essentially, you want to make the downstream movers (you list under this section) aware about the placement decisions in this upstream mover. These movers will not be run at in this placestub, but will be subsequently aware of placed residues for subsequent use. Useful for running design moves after placestub is done, e.g., in loops. Put task awareness only in the deepest placestub mover (if PlaceStub is nested), where the final decisions about which residues harbour hot-spot residues is made. </UL>


Places hotspot residues simultaneously on a scaffold, rather than iteratively as in PlaceStub. It is faster therefore allowing more backbone sampling, and should be useful in placing more than 2 hotspots.

<PlaceSimultaneously name=(&string) chain_to_design=(2 &Integer) repack_non_ala=(1 &bool) optimize_fold_tree=(1 &bool) after_placement_filter=(true_filter &string) auction=(&string) stub_score_filter=(&string)/>
        <Add mover_name=(null_mover &string) use_constraints=(1 &bool) coord_cst_std=(0.5 &Real)/>
     <StubSets explosion=(0 &integer) stub_energy_threshold=(1.0 &Real)  max_cb_dist=(3.0 &Real) cb_force=(0.5 &Real)>
        <Add stubfile=(& string) filter_name=(&string)/>
     <StubMinimize min_repeats_before_placement=(0&Integer) min_repeats_after_placement=(1&Integer)>
       <Add mover_name=(null_mover &string) bb_cst_weight=(10.0 &Real)/>
       <Add mover_name=(&string)/>

Most of the options are similar to PlaceStub above. Differences are mentioned below:

rb_stub_minimization, auction and stub_score_filter allow the user to specify the first moves and filtering steps of PlaceSimultaneously before PlaceSimultaneously is called proper. In this way, a configuration can be quickly triaged if it isn't compatible with placement (through Auction's filtering). If the configuration passes these filters and movers then PlaceSimultaneously can be run within loops of docking and placement, until a design is identified that produces reasonable ddg and sasa.


This is actually a filter (and should go under FILTERS), but it is tightly associated with the placement movers, so it's placed here. A special filter that is associated with PlaceSimultaneouslyMover. It checks whether in the current configuration the scaffold is 'feeling' any of the hotspot stub constraints. This is useful for quick triaging of hopeless configuration.

<StubScore name=(&string) chain_to_design=(2 &integer) cb_force=(0.5 &Real)>
     <Add stubfile=(&string)/>

Note that none of the flags of this filter need to be set if PlaceSimultaneously is notified of it. In that case, PlaceSimultaneously will set this StubScore filter's internal data to match its own.


This mover is useful for reporting the total or per-residue ddgs in cases where you don't want to use the ddG filter for some reason. (also, the ddg filter can't currently do per-residue ddgs). Ddg scores are reported as string-real pairs in the job. The total ddg score has the tag "ddg" and the each pre residue ddg has the tag "residue_ddg_n" where n is the residue number.

<ddG name=(&string) jump=(1 &integer) symmetry=(0 &bool) per_residue_ddg=(0 &bool) repack=(0 bool&) scorefxn=("score12" &string) />


Calculate and output contact maps for each calculated structure

<ContactMap name="&string" region1=( &string) region2=( &string) ligand=( &string)  distance_cutoff=( 10.0 &Real)  prefix=("contact_map_" &string) reset_count=("true" &string) models_per_file=(1 &int) row_format=("false" &string) / >
       - region1: region definition for region1 of  ContactMap in format '<start>-<end>' or '<chainID>'  defaults to 1-<n_residue()>
       - region2: region definition for region2 of  ContactMap
       - ligand: sequence position or chainID of ligand - all non-hydrogen atoms of the corresponding residue will be mapped against the CB atoms of region1(ignored if region2-tag is specified)
       - distance_cutoff: Maximum distance of two atoms so contacts count will be increased
       - prefix: Prefix for output_filenames
       - reset_count:  flag whether the count will be reset to 0 after the ContactMap was output to a file. if set to false, the same file will be updated every 'models_per_file'
                                  structures (only applies for n_struct>1 when called with the Scripter)
       - models_per_file: defines after how many structures an output file should be generated  (no file will be created if equal to 0 or greater than n_struct !)
       - row_format: flag if output should be in row format rather than the default matrix format

Ligand-centric Movers

Ligand docking

These movers replace the executable for ligand docking and provide greater flexibility to the user in customizing the docking protocol. An example XML file for ligand docking is found here (link forthcoming). The movers below are listed in the order found in the old executable.


<StartFrom name="&string" chain="&string"/>
   <Coordinates x=(&float) y=(&float) z=(&float)/>

Provide a list of XYZ coordinates. One starting coordinate will be chosen at random and the specified chain will be recentered at this location.


<Translate name="&string" chain="&string" distribution=[uniform|gaussian] angstroms=(&float) cycles=(&int)/>

The Translate mover is for performing a course random movement of a small molecule in xyz-space. This movement can be anywhere within a sphere of radius specified by "angstroms". The chain to move should match that found in the PDB file (a 1-letter code). "cycles" specifies the number of attempts to make such a movement without landing on top of another molecule. The first random move that does not produce a positive repulsive score is accepted. The random move can be chosen from a uniform or gaussian distribution. This mover uses an attractive-repulsive grid for lightning fast score lookup.


<Rotate name="&string" chain="&string" distribution=[uniform|gaussian] degrees=(&int) cycles=(&int)/>

The Rotate mover is for performing a course random rotation throughout all rotational degrees of freedom. Usually 360 is chosen for "degrees" and 1000 is chosen for "cycles". Rotate accumulates poses that pass an attractive and repulsive filter, and are different enough from each other (based on an RMSD filter). From this collection of diverse poses, 1 pose is chosen at random. "cycles" represents the maximum # of attempts to find diverse poses with acceptable attractive and repulsive scores. If a sufficient # of poses are accumulated early on, less rotations then specified by "cycles" will occur. This mover uses an attractive-repulsive grid for lightning fast score lookup.


<SlideTogether name="&string" chain="&string"/>

The initial translation and rotation may move the ligand to a spot too far away from the protein for docking. Thus, after an initial low resolution translation and rotation of the ligand it is necessary to move the small molecule and protein into close proximity. If this is not done then high resolution docking will be useless. Simply specify which chain to move. This mover then moves the small molecule toward the protein 2 angstroms at a time until the two clash (evidenced by repulsive score). It then backs up the small molecule. This is repeated with decreasing step sizes, 1A, 0.5A, 0.25A, 0.125A.


<HighResDocker name="&string" repack_every_Nth=(&int) scorefxn="string" movemap_builder="&string" />

The high res docker performs cycles of rotamer trials or repacking, coupled with small perturbations of the ligand(s). The "movemap_builder" describes which side-chain and backbone degrees of freedom exist. The Monte Carlo mover is used to decide whether to accept the result of each cycle. Ligand and backbone flexibility as well as which ligands to dock are described by LIGAND_AREAS provided to INTERFACE_BUILDERS, which are used to build the movemap according the the XML option.


<FinalMinimizer name="&string" scorefxn="&string" movemap_builder=&string/>

Do a gradient based minimization of the final docked pose. The "movemap_builder" makes a movemap that will describe which side-chain and backbone degrees of freedom exist.


<InterfaceScoreCalculator name=(string) chains=(comma separated chars) scorefxn=(string) native=(string)/>

InterfaceScoreCalculator calculates a myriad of ligand specific scores and appends them to the output file. After scoring the complex the ligand is moved 1000 Å away from the protein. The model is then scored again. An interface score is calculated for each score term by subtracting separated energy from complex energy. If a native structure is specified, 4 additional score terms are calculated:

  1. ligand_centroid_travel. The distance between the native ligand and the ligand in our docked model.
  2. ligand_radious_of_gyration. An outstretched conformation would have a high radius of gyration. Ligands tend to bind in outstretched conformations.
  3. ligand_rms_no_super. RMSD between the native ligand and the docked ligand.
  4. ligand_rms_with_super. RMSD between the native ligand and the docked ligand after aligning the two in XYZ space. This is useful for evaluating how much ligand flexibility was sampled.

Enzyme design


EnzRepackMinimize, similar in spirit to RepackMinimize mover, does the design/repack followed by minimization of a protein-ligand (or TS model) interface with enzyme design style constraints (if present, see AddOrRemoveMatchCsts mover) using specified score functions and minimization dofs. Only design/repack or minimization can be done by setting appropriate tags. A shell of residues around the ligand are repacked/designed and/or minimized. If constrained optimization or cst_opt is specified, ligand neighbors are converted to Ala, minimization performed, and original neighbor sidechains are placed back.

<EnzRepackMinimize name="&string" scorefxn_repack=(score12 &string) scorefxn_minimize=(score12 &string) cst_opt=(0 &bool) repack_only=(0 &bool) design=(0 &bool) fix_catalytic=(0 &bool) minimize_rb=(1 &bool) minimize_bb=(0 &bool) minimize_sc=(1 &bool) minimize_lig=(0 & bool) min_in_stages=(0 &bool) backrub=(0 &bool) cycles=(1 &integer)/>


Add or remove enzyme-design style pairwise (residue-residue) geometric constraints to/from the pose. A cstfile specifies these geometric constraints, which can be supplied in the flags file (-enzdes:cstfile) or in the mover tag (see below).

The "-run:preserve_header" option should be supplied on the command line to allow the parser to read constraint specifications in the pdb's REMARK lines. (The "-enzdes:parser_read_cloud_pdb" also needs to be specified for the parser to read the matcher's CloudPDB default output format.)

<AddOrRemoveMatchCsts name="&string" cst_instruction=( "void", "&string") cstfile="&string" keep_covalent=(0 &bool) accept_blocks_missing_header=(0 &bool) fail_on_constraints_missing=(1 &bool)/>


PredesignPerturbMover randomly perturbs a ligand in a protein active site. The input protein will be transformed to a polyalanine context for residues surrounding the ligand. A number of random rotation+translation moves are made and then accepted/rejected based on the Boltzmann criteria with a modified (no attractive) score function (enzdes_polyA_min.wts).

PredesignPerturbMover currently will perturb only the last ligand in the pose (the last jump).

<PredesignPerturbMover name=(&string) trans_magnitude=(0.1 &real) rot_magnitude=(2.0 &real) dock_trials=(100 &integer) />

Ligand design

These movers work in conjunction with ligand docking movers. An example XML file for ligand design is found here (link forthcoming). These movers presuppose the user has created or acquired a fragment library. Fragments have incomplete connections as specified in their params files. Combinatorial chemistry is the degenerate case in which a core fragment has several connection points and all library fragments have only one connection point.


<GrowLigand name="&string" chain="&string"/>

Randomly connects a fragment from the library to the growing ligand. The connection point for connector atom1 must specify that it connects to atoms of connector atom2's type, and visa versa.


<AddHydrogens name="&string" chain="&string"/>

Saturates the incomplete connections with H. Currently the length of these created H-bonds is incorrect. H-bonds will be the same length as the length of a bond between connector atoms 1 and 2 should be.

DNA interface Design Movers


<DnaInterfacePacker name=(&string) scorefxn=(&string) task_operations=(&string,&string,&string) binding=(0, &bool) base_only=(false, &bool) minimize=(0, &bool) probe_specificity=(0, &bool) reversion_scan=(false, &bool)/>

Currently Undocumented

The following Movers are available through RosettaScripts, but are not currently documented. See the code (particularly the respective parse_my_tag() and apply() functions) for details. (Some may be undocumented as they are experimental/not fully functional.)