choderalab / brokenyank Goto Github PK

After the dust settles, we should run everything through pyflakes. It finds a few issues in repex.py.

We don't need to do this until closer to the release, however.

At some point, we should look into plugging accelerated MD into our repex code. This could be useful for general enhanced sampling.

The current AMD code is built using a CustomIntegrator, so it might be tricky to reframe it as a HREX potential.

It's also worth thinking about how to best combine multidimensional replica change. We currently have alchemical HREX, AMD, and temperature. I imagine we might want to combine these in the near future.

It would be useful if YANK was able to parameterize System objects using the OpenMM app ForceField module. This would allow us to access multiple forcefields, instead of having to go through AmberTools LEaP externally.

To do this, a few things need to happen:

• To allow arbitrary PDB files to be parameterized, we probably need to use the new pdbfixer module.
• We would then use the app Modeller to add explicit solvent
• Most critically, we need a way to deal with small molecules. Perhaps these could still be parameterized by AmberTools antechamber and those parameters used to write an XML parameter repository readable by ForceField?

Some requirements get imported at file headers, while others get imported in the heat of things.

My preference would be:

1. Move as many imports to the header as possible
2. Follow a recipe for handing whatever delayed imports we need.

Here's an example of how Robert has handled this. I'm not sure if his approach is optimal, but it's something. https://github.com/rmcgibbo/mdtraj/issues/47

The "Cuda" platform should be renamed to "CUDA". (Line 38)

platform = simtk.openmm.Platform.getPlatformByName("Cuda")

should be

platform = simtk.openmm.Platform.getPlatformByName("CUDA")

In [4]: mm.Platform.getPlatform(1).getName()
Out[4]: 'CUDA'

[kyleb@node012 ~]$ python ~/src/yank/src/test_repex_mpi.py
Creating test systems...
Traceback (most recent call last):
File "/home/kyleb/src/yank/src/test_repex_mpi.py", line 29, in
platform = simtk.openmm.Platform.getPlatformByName("Cuda")
File "/home/kyleb/opt/lib/python2.7/site-packages/simtk/openmm/openmm.py", line 10637, in getPlatformByName
return _openmm.Platform_getPlatformByName(*args)
Exception: There is no registered Platform called "Cuda"

I've tried this on two different systems (cluster and desktop) now. I'm finding that Yank hangs when creating the second cached context object. Have you seen anything like this before?

[kyleb@node013 ~]$ mpirun -np 6 ~/src/yank/src/test_repex_mpi.py 
Creating test systems...
Selecting MPI communicator and selecting a GPU device...
Creating test systems...
Selecting MPI communicator and selecting a GPU device...
Creating test systems...
Selecting MPI communicator and selecting a GPU device...
Creating test systems...
Selecting MPI communicator and selecting a GPU device...
Creating test systems...
Selecting MPI communicator and selecting a GPU device...
Creating test systems...
Selecting MPI communicator and selecting a GPU device...
node 'node013' deviceid 1 / 6, MPI rank 1 / 6
node 'node013' deviceid 4 / 6, MPI rank 4 / 6
node 'node013' deviceid 5 / 6, MPI rank 5 / 6
node 'node013' deviceid 3 / 6, MPI rank 3 / 6
node 'node013' deviceid 2 / 6, MPI rank 2 / 6
node 'node013' deviceid 0 / 6, MPI rank 0 / 6
Initialized node 0 / 6
Please cite the following:

        Friedrichs MS, Eastman P, Vaidyanathan V, Houston M, LeGrand S, Beberg AL, Ensign DL, Bruns CM, and Pande VS. Accelerating molecular dynamic simulations on graphics processing units. J. Comput. Chem. 30:864, 2009. DOI: 10.1002/jcc.21209
        Eastman P and Pande VS. OpenMM: A hardware-independent framework for molecular simulations. Comput. Sci. Eng. 12:34, 2010. DOI: 10.1109/MCSE.2010.27
        Eastman P and Pande VS. Efficient nonbonded interactions for molecular dynamics on a graphics processing unit. J. Comput. Chem. 31:1268, 2010. DOI: 10.1002/jcc.21413
        Eastman P and Pande VS. Constant constraint matrix approximation: A robust, parallelizable constraint method for molecular simulations. J. Chem. Theor. Comput. 6:434, 2010. DOI: 10.1021/ct900463w
        Chodera JD and Shirts MR. Replica exchange and expanded ensemble simulations as Gibbs sampling: Simple improvements for enhanced mixing. J. Chem. Phys., in press. arXiv: 1105.5749
Creating and caching Context objects...
Node 0 / 6 creating Context for state 0...
Initialized node 4 / 6
Initialized node 2 / 6Node 4 / 6 creating Context for state 4...

Node 2 / 6 creating Context for state 2...
Initialized node 3 / 6
Node 3 / 6 creating Context for state 3...
Initialized node 5 / 6Initialized node 1 / 6
Node 1 / 6 creating Context for state 1...

Node 5 / 6 creating Context for state 5...
Node 0 / 6: Using platform CUDA
Node 3 / 6: Using platform CUDA
Node 4 / 6: Using platform CUDA
Node 2 / 6: Using platform CUDA
Node 1 / 6: Using platform CUDA
Node 5 / 6: Using platform CUDA
Node 0 / 6: Context creation took 34.206 s
Note 0 / 6: Context creation done.  Waiting for MPI barrier...

By using the new feature of CustomNonbondedForce in OpenMM to restrict the computation of interactions to specific pairs of atom groups, we can potentially speed up execution by a factor of two.

Several laboratories would like to use YANK for computing free energy differences upon protein mutations, either for peptide ligands or protein targets.

This functionality would require a way to modify OpenMM topologies to allow alchemical transformation of protein sidechains from one residue identity to another.

The stuff in pyopenmm is pretty questionable. We should move the needed features to a separate repo and provide some sort of testing / quality control / docs.

Currently, alchemical intermediate creation required ~4 s per intermediate, which adds up to several minutes for many replicas. Profile this code and see if can be sped up.

See if we can create groups of alchemical intermediates in which a global Context parameter can select the intermediate, rather than needing to create separate System objects for each intermediate.

If MBar is set up correctly as a python package, it should be possible to have Yank automatically install mbar when installing via pip.

I'm not sure if this is preferable to bundling mbar inside yank, but it could be.

For explicit solvent, the size of our NCFiles are probably going to be problematic to many users--a lot of clusters have quotas in the ~10-100GB range.

In the distant past, I had an issue where the NCFile would fill up my space allocation on a cluster. The writing would raise and error and produce an unreadable NCFile.

Once the online analysis feature is complete, it could make sense to have "multiple" output frequencies. For example, you might not want to store all coordinates with every RE iteration. The idea is that with online analysis, you can throw away a lot more information and save coordinates less often.

Here are some ideas:

[] Ouput solvent, protein, and ligand at different frequencies
[] Write conformations every nth RE iteration

I'm envisioning this working somewhat like Peter's Reporter objects.

Obviously, this is low priority, but I think it might be useful for some people.

Because only CPU MPI processes run the vacuum and solvent simulations, no processes will be allocated if all MPI processes are GPU processes.

We should consider support for GROMOS forcefields in a future release.

GROMOS forcefields are not currently available in OpenMM, but could be added (likely requiring permission from the GROMOS maintainer):
http://www.gromos.net/page.pl?page=contact

Small molecules could be parameterized with Alan Mark's ATb automated topology builder:
http://compbio.biosci.uq.edu.au/atb/index.py?tab=home_tab