Getting Started

Build Documentation

Rosetta Basics

Application Documentation

Scripting Interfaces

Development Documentation

Internal Documentation

How to Write Documentation

FAQ

Glossary

Options list

Reference

Biorxiv: https://www.biorxiv.org/content/10.1101/618603v2

Overview

The ExplicitWaterMover is a special-purpose mover (exposed through the RosettaScripts application) intended to be used in conjunction with the beta_nov16 potential function. It, when used in conjunction with the packer, allows the modeling of explicit water molecules during a packing/design trajectory.

The ExplicitWaterMover is to be called prior to packing, using the same task operation as packing. It generates potential sites where water might bind to any allowed rotamer. Then, a subsequent packing call is used to bring waters out of solvent at these positions.

In the simplest case, it is used as follows: 

  <MOVERS>
    <ExplicitWaterMover name="solvate" mode="replace" gen_fixed="0" scorefxn="beta" task_operations="mytaskops" />
    <PackRotamersMover name="pack" scorefxn="beta" task_operations="mytaskops"/>
  </MOVERS>
 <PROTOCOLS>
    <Add mover="solvate"/>
    <Add mover="pack"/>
 </PROTOCOLS>

Options

There are two important options controlling the behavior:

  • mode - one of remove, append, replace, or eval. This describes the behavior of the mover:
    • replace (default) - remove all waters, generate new water placements
    • append - keep existing waters, and generate additional water placements
    • remove - remove all waters from the pose
    • eval - compare the water placement of the input pose to that specified with -in:file:native or with the tag native
  • gen_fixed - this option describes whether or not water placements should be generated for positions that are not allowed to pack in the input packertask. Note that this might generate waters far away from the residues to be packed (e.g., for interface design, waters may be placed far from the interface)

There are several other options controlling protocol behavior, that should not be changed except by experts. The protocol itself is run in several stages:

  1. Waters are generated by considering every allowed rotamer and placing "ideal" waters at each polar group
  2. The set is pruned by eliminating points that only interact with ONE sidechain polar (sites interacting with one backbone polar are kept)
  3. Sidechain-coordinated sites are clustered in space and grouped into "rotamers" (backbone sites are clustered by coordinating polar)
  4. Many short packing trajectories are run using a "point water potential" that only considers the position of the water O.
  5. The set is: a) pruned to sites that are occupied by a water some fraction of the time, b) clustered, and c) pruned to clusters that are occupied at least some fraction of the time.

Several "expert" options control these five steps:

  • lkb_overlap_dist - In step 2, the overlap distance of sidechain "water sites" necessary to generate a water
  • lkb_clust_rad - In step 3, the redundancy cutoff for overlapping sidechain groups
  • lkb_rotset_radius - In step 3, the "rotameric" cutoff for lkb groups (that is the distance cutoff for which two point waters are considered rotamers of a single water)
  • dwell_cutoff - In step 5a, the dwell-time cutoff for waters (before clustering)
  • clust_radius - In step 5b, the radius of clustering
  • clust_cutoff - In step 5c, the dwell cutoff for water clusters

Notes

If no task operation is provided, waters will only be generated against the fixed input pose (gen_fixed will always be assumed true)

This mover was previously called WaterBoxMover -- this was changed to ExplicitWaterMover on 10/23/2019 to be more descriptive