Phil Bradley has done some preliminary work on including explicit waters into rosetta. I will begin by looking at his work with the goal of being able to present it a rosetta code meeting and attempt to include it in protein-protein binding protocols. I anticipate that it won't perform as desired as it currently stands. Assuming I can replicate the functionality Phil has obtained with it, it will probably be too slow and probably not work with minimization (it was designed to work only with rotamer trials). As a rough estimate I expect this evaluation to take 3-6 weeks depending on how promising his code seems.) At this point we will evaluate what I have learned and where we want to go from there. Currently it seems like the possibilities ranging from least intense to most intense are 1) Simply maintain Phil's code because it works well enough 2) Improve Phil's code because the basics are good but optimizing his algorithm will make it practical to use. 3) Recognize situations where Phil's code either does not work well or is not setup to deal with and devise and implement a new algorithm for Explicit waters. If this is the direction the project goes it will still have been useful for me to become familiar with Phil's code. If the new algorithm applies to different situations then we will have a more complete way of modeling waters explicitly. If the new algorithm overlaps with Phil's code a working knowledge of it will allow us to benchmark the approaches and select the one that performs better. Lastly understanding Phil's code will help me get up to speed with the internals of mini and it will help me to control excess code duplication.

Here is my current understanding of Phil's code and a sketch of Brian's idea of another way to model waters explicitly.

Traditionally rotamer trials has two phases: build a rotamer library and then perform a Monte Carlo optimization over that library. Phil's code extends the rotamer library to include water rotamers and then performs the optimization phase as before. To build the original rotamer library, the algorithm pre-computes the pair energy for all possible rotamers for each pair of neighboring residues. Phil's code examines each generated rotamer pair and decides whether a water molecule could mediate the interaction. If it can, the water--modeled as 3 explicit atoms--is included as its own rotamer. There are some details that I don't yet understand. For example, if Phil's code decides to include a water rotamer, is its interaction with all neighboring rotamers pre-computed?

Some reasons why Phil's code may not be adequate:

1. It may be too slow
2. It may be difficult to get it to work with minimization
3. It does not model solvating water molecules (ie that only make one hydrogen bond with the protein)

Brian's idea is to call each position a water molecule could favorably interact with each allowable rotamer in vacuo, a "putative water". Then during the optimization phase maintain a table which maps a putative water to the energy it would contribution if it were actually there. The model then assumes that since sequences obtain the lowest energy confirmation, a putative water exists only if it contributes favorably. For each rotamer substitution the interactions between the old and new rotamers need to be updated. A design decision would need to be made about how to handle clashing putative water molecules and whether or not to model the hydrogen atoms of each water molecule.

-- MatthewOmeara - 05 Sep 2008
to top