Rosetta 3.1 Release Manual

RosettaScripts Applications

Metadata This document was written by Sarel Fleishman, Jacob Corn, Eva Strauch, Justin Ashworth, and Spencer Blivens.


The rosetta_scripts is meant to provide an xml-scriptable interface for conducting all of the tasks that interface design developers produce. With such a scriptable interface, it is hoped, it will be possible for non-programmers to 'mix-and-match' different design strategies and apply them to their own needs. It is also hoped that through a common interface, code-sharing between different people will be smoother. Note that at this point, the only movers and filters that are implemented in this application are the ones described below. More will be made available in future releases. At the most abstract level, all of the computations that are needed in interface design fall into two categories: Movers and Filters. Movers change the conformation of the complex by acting on it, e.g., docking/design/minimization, and filters decide whether a given conformation should go on to the subsequent steps. Filters are meant to reduce the amount of computation that is conducted on conformations that show no promise. Then, a rosetta_scripts protocol is merely a sequence of movers and filters.

Skeleton xml format

Copy, paste, fill in, and enjoy

Example xml file

The following simple example will compute ala-scanning values for each residue in the protein interface:
                <interface weights=interface/>
                <AlaScan name=scan partner1=1 partner2=1 scorefxn=interface interface_distance_cutoff=10.0 repeats=5/>
                <Ddg name=ddg confidence=0/>
                <Sasa name=sasa confidence=0/>
                <Docking name=dock fullatom=1 local_refine=1 score_high=soft_rep/>
                <Add mover_name=dock filter_name=scan/>
                <Add filter_name=ddg/>
                <Add filter_name=sasa/>
Rosetta will carry out the order of operations specified in PROTOCOLS, starting with docking (in this case this is all-atom docking using the soft_rep weights). It will then apply alanine scanning, repeated 5 times for better convergence, for every residue on both sides of the interface computing the binding energies using the interface weight set (counting mostly attractive energies). The binding energy (ddg) and surface area (sasa) will also be computed. All of the values will be output in a .report file. Notice that since ddg and sasa are assigned confidence=0, they are not used here as filters that can terminate a trajectory per se, but rather for reporting the values for the complex. An important point is that filters never change the sequence or conformation of the structure, so the ddg and sasa values are reported for the input structure following docking, with the alanine-scanning results ignored.

Example commandline

The following command line would run the above protocol, given that the protocol file name is ala_scan.xml
bin/rosetta_scripts.linuxgccrelease -s < INPUT PDB FILE NAME > -nstruct 20 -jd2:ntrials 100 -database ~/rosetta_database/ -ex1 -ex2 -parser:protocol ala_scan.xml -parser:view
-ntrials meaning how many attempts to do in total, it now means how many attempts to do per output structure that we want to write. So, -nstruct 20 -ntrials 100 means, for each of 20 trajectories, make 100 different write attempts, for a total of 200 potential attempts. Another way of looking at it is: nstruct is the maximum number of structures to output. nstruct x ntrials = the number of times to try. This is important for those cases in which you're actively filtering results rather than outputting decoys with certainty. In the latter case, you wouldn't notice the difference. The parser:view flag may be used with rosetta executables that have been compiled using the extras=graphics switch in the following way (from the Rosetta root directory):
scons mode=release -j3 bin extras=graphics
When running with -parser:view a graphical viewer will open that shows many of the steps in a trajectory. This is extremely useful for making sure that sampling is following the intended trajecotry.

Options in XML Protocol File

This file lists the Movers, Filters, their defaults, meanings and uses as recognized by rosetta_scripts. It is written in an xml format and using many free viewers (e.g., vi) will highlight key xml notations, so long as the file has extension .xml.

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


This section defines scorefunctions that will be used in Filters and Movers. This can be used to define any of the scores defined in the rosetta_database using the following statement:
<"scorefxn_name" weights=(standard &string) patch="&string">
where scorefxn_name will be used in the Movers and Filters sections to use the scorefunction. The name should therefore be unique and not repeat the predefined score names.


This is a section that is used to change the input structure. The most likely use for this is to define constraints to a structure that has been read from disk.


his section defines instances of the TaskOperation class hierarchy. They become available in the DataMap.

TaskOperation classes are used by TaskFactory to configure the behavior of PackerTask when it is generated on-demand for routines that use the "packer" to reorganize/mutate sidechains. When used by certain Movers (at present, the PackerRotamersMover and its subclasses), the TaskOperations control what happens during packing, usually by restriction "masks." A basic example:

  <ReadResfile name=rrf/>
  <ReadResfile name=rrf2 resfile=resfile2/>
  <PreventRepacking name=NotBeingUsedHereButPresenceOkay/>
  <RestrictToRepacking name=rtrp/>
  <OperateOnCertainResidues name=NoPackNonProt>
    <ResidueLacksProperty property=PROTEIN/>
  <PackRotamersMover name=packrot scorefxn=sf task_operations=rrf,NoPackNonProt,rtrp/>
In the rosetta code, the TaskOperation instances are registered with and then later created by a TaskOperationFactory. The factory calls parse_tag() on the base class virtual function, with no result by default. However, some TaskOperation classes (e.g. OperateOnCertainResidues and ReadResfile above) do implement parse_tag, and therefore their behavior can be configured using additional options in the "XML"/Tag definition.

List of current TaskOperation classes in the core library (* indicates use-at-own-risk/not sufficiently tested/still under development):



// ResLvlTaskOperations: as a subtag for special OperateOnCertainResidues TaskOperation (one only)

// ResFilters: as a subtag for special OperateOnCertainResidues TaskOperation (one only)


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.


Each filter definition has the following format:
<"filter_name" name="&string" ... confidence=(1 &Real)/>
where "filter_name" belongs to a predefined set of possible filters 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 filter needs to be defined. If confidence is 1.0, then the filter is evaluated as in predicate logic (T/F). If the value is less than 0.999, then the filter is evaluated as fuzzy, so that it will return True in (1.0 - confidence) fraction of times it is probed. This should be useful for cases in which experimental data are ambiguous or uncertain.

Generated on Tue Apr 20 07:50:05 2010 for Rosetta Projects by  doxygen 1.5.2

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