Dock Design Parser Applications

Metadata This document was written by Sarel Fleishman and edited by Yi liu


The dock_design_parser 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 dock_design steps. Filters are meant to reduce the amount of computation that is conducted on conformations that show no promise. Then, a dock_design protocol is merely a sequence of movers and filters.

The implementation for this behaviour is done by the following components:

Options in XML Protocol File

This file lists the Movers, Filters, their defaults, meanings and uses as recognized by dock_design_parser. It always has an extention named .protocol. You can find a comprehensive sample in pilot/dock_design_parser/dock_design.protocol


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.


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 03:15:03 2010 for Rosetta Projects by  doxygen 1.5.2