choderalab / openmmtools Goto Github PK

Just tried the example and go this warning

/Users/jan-hendrikprinz/anaconda/lib/python2.7/site-packages/simtk/openmm/app/amberinpcrdfile.py:74: DeprecationWarning: loadVelocities and loadBoxVectors have been deprecated. velocities and box information is loaded automatically if the inpcrd file contains them.
  'them.', DeprecationWarning)

Think this is easy to fix. Will do it, once I have a better idea of openmmtools

The new subrandom sampling for LennardJonesFluid ends up producing configurations with so high of an energy that they can cause segfaults.

It's so common to have to minimize the test systems that it may be useful add a TestSystem.minimize() method.

In fact, it may be neat if we could minimize all systems at install time and cache the minimized coordinates...

This is just a reminder to implement the Nesterov minimizer from @rmcgibbo

The box size is currently left as default.

https://github.com/choderalab/openmmtools/blob/master/openmmtools/testsystems.py#L3350

The host-guest systems would be good to add.

Are doctests automatically run via nose?

We should be able to set the temperature for the VVVRIntegrator using a setTemperature() call, as in LangevinIntegrator. This can be done by ensuring these are context parameters.

From openmm/openmm#1042

Paper is here:
http://www.tandfonline.com/doi/abs/10.1080/00268976.2013.844369

The topology is not exposed in the water box test system. It'll be useful to expose it.

This might be useful for helping benchmark systems relevant to Chaya's work.

Is there a way we can better configure or name this package for importing to make more sense?

Perhaps this could be

from openmmutil import testsystems
from openmmtools import testsystems
from choderalab import testsystems
...

Ideas?

The FIRE scheme from

Structural relaxation made simple.
PRL 97:170201, 2006
http://dx.doi.org/10.1103/PhysRevLett.97.170201

seems like it might be an especially simple minimization scheme that can be implemented as a CustomIntegrator.

There seems to be an issue where repeatedly invoking test systems that use the sobol code will die.

For example,

[LSKI1497:choderalab/openmmtools/openmmtools.jchodera] choderaj% python customintegrator-buserror.py
cycle 0
cycle 1
cycle 2
cycle 3
cycle 4
cycle 5
cycle 6
cycle 7
cycle 8
cycle 9
cycle 10
cycle 11
cycle 12
cycle 13
cycle 14
Traceback (most recent call last):
  File "customintegrator-buserror.py", line 209, in <module>
    integrator = openmm.VerletIntegrator(1.0 * unit.femtosecond)
AttributeError: 'module' object has no attribute 'VerletIntegrator'

In particular, it seems odd that we correct for the standard state volume twice:
https://github.com/choderalab/openmmtools/blob/master/openmmtools/testsystems.py#L3497-L3504

Examples might include:

• restrained protein:ligand system

I have no idea what is going on here:
https://travis-ci.org/choderalab/openmmtools#L606-L627

We could probably speed things along greatly (and discover race conditions like openmm/openmm#946) by using multiprocessing to run on the available platforms simultaneously or otherwise interleave test system execution.

This would come in very handy for our purposes. If at least in some systems we could get an openmm.Topology() object or mdtraj.Topology() object that would be great. Maybe we can add an extended TestSystem like

class ExtendedTestSystem(TestSystem):

    def __init__(self, args, topology):
        super(ExtendedTestSystem, self).__init__(args)
        self.topology = topology

This might make it easier to analyze results later. Any ideas?

Mention @dwhswenson here to get his opinion.

Is this something you can take a look at, @kyleabeauchamp?

The AMBER folks have just put out an article on their approach to HMR.

They compute a number of equilibrium static physical properties (phi/psi distribution, rotamer populations, pKas, RMSD distributions, etc.) and a kinetic property (rotamer transition rates) to show that the static properties are mostly undisturbed despite the timestep increase for HMR calculations.

Interestingly, they omitted some simple-to-compute properties that may be especially sensitive to timestep, such as liquid densities, enthalpies of vaporization, and pressures at fixed volume.

There are two follow-up questions we could easily tackle using tools in openmmtools:

1. They don't actually concretely show that sampling is faster by computing correlation times (though Fig 14 is suggestive evidence it speeds up convergence of pKa calculations)
2. They don't have some figure of merit that allows a comparison between different timesteps or HMR schemes to allow someone to compare which is "better" or even "acceptable".

Issue #1 is simple to fix---we could just compute integrated autocorrelation functions to directly show that phase space really is sampled more quickly despite the mass repartitioning.

Issue #2 also has a ready solution, using Eq. 6 of this work; see results for flexible and rigid waterboxes plotted in Fig 2:
http://dx.doi.org/10.1103/PhysRevX.3.011007

This number---the steady state nonequilibrium free energy---is essentially a measure of how far the system is driven from the desired equilibrium distribution for any symplectic integration scheme we sandwich inside a VVVR integrator (such as VV, VV with HMR, MTS, etc.).

I even have scripts for this sitting around that could be adapted to use openmmtools.integrators and openmmtools.testsystems if this was of interest for putting out a paper on approaches to HMR.

I actually wonder (given previous suggestions from @kyleabeauchamp) if HMR + MTS would work even better. And using Metropolization (e.g. MTS GHMC + HMR) might be a no-brainer if we ever get the speed issues with CustomIntegrator figured out.

Also, I'm thrilled to see Bennett's paper on HMR get a shout-out!

It might be cute to use classes instead of functions, so that we can use inheritance to do further customizations. This is not unprecedented, as Peter's RESPA integrator does this.

This would also let us write decorators that calculate various convergence statistics for monitoring. Also, we could use member functions to help with tuning various mcmc parameters.

It would be useful to have the standard JAC benchmark systems in openmmtools.testsystems, with the DHFR system likely being most valuable.

The AMBER version of the input files is available here, but the prmtop files are unfortunately only available in the "old" prmtop format:
http://ambermd.org/Amber14_Benchmark_Suite.tar.bz2

I believe the current AMBER prmtop loader only reads the "new" prmtop file formats, so we would need to either convert these to new format (using ParmEd from @swails?), upgrade the prmtop reader to read the "old" style files, or find the CHARMM version of these files and try out the CHARMM loader.

See discussion at openmm/openmm#441

We should use test generators instead of the current scheme of looping over systems.

It would be nice to add a few test systems here:

• two Lennard-Jones particles with and without opposite charges
• two water molecules
• an artificial binding site made of Lennard-Jones atoms
• one water molecule in a box of water molecules
• a host-guest system

It would be useful if we could easily query the openmmtools.testsystems module for useful subsets of systems, such as:

• all testsystems of any kind
• main test representatives (e.g. WaterBox, but not DischargedWaterBox)
• all alchemical test systems
• weird corner cases that are non representative of real use cases
• systems that are typical of real use cases
• systems that will be "fast" or "easily computable"
• systems with analytical properties

There's a lot of stuff in there now, but not all of it is applicable to every kind of test battery.

I just had to reinstall Anaconda from scratch. Completely new user. Newest Anaconda and installed openmmtools. It installs using conda but importing fails

import openmmtools with

---------------------------------------------------------------------------
ImportError                               Traceback (most recent call last)
<ipython-input-5-113cf65ec230> in <module>()
----> 1 import openmmtools

/Users/jan-hendrikprinz/anaconda/lib/python2.7/site-packages/openmmtools-0.9.0-py2.7.egg/openmmtools/__init__.py in <module>()
      7 
      8 # Define global version.
----> 9 from openmmtools import version
     10 __version__ = version.version
     11 

ImportError: cannot import name version

Apparently the newest build did not get uploaded to binstar. In the after_success the {PACKAGENAME} seemed to be empty which results in the binstar command not being able to find the package. Has there been some changes recently?

We currently call this tests-nose/, but our other projects mainly use tests/.

We might consider adding some of the long-range electrostatics methods described in this Chris Fennell paper here for convenience. This was mentioned in openmm/openmm#942

I wonder if we want to put the integrators here? Right now, we have lots of really useful integrators that are hidden in various repositories.

Also, I wonder if we should add a GHMC RESPA integrator and a simple function to auto-tune the timesteps to provide a reasonable acceptance rate. That could be really useful in a lot of applications.

These are much more sensitive than average properties.

There seems to be an issue with nose-exclude required for install:
https://travis-ci.org/choderalab/openmm-testsystems/jobs/38391317#L386-L411

This is important for ensuring same energies across Platforms.

See openmm/openmm#1108

Maybe @bas-rustenburg can help with this?

Is there an easy way to build this and push this online somewhere?

1. Extra chance HMC
2. RESPA HMC
3. Non-uniform step size HMC
4. GHMC with n_steps parameter

I have working or half-working branches for most of these, which I can PR as we find time for this. Longer term, it would be great to actually combine all these methods into a single custom integrator--all these methods are "stackable" with one another.

We've seen some issues with FAH on NVIDIA cards, so would be useful to add an explicit test system for this very large (270K atom) project.

A simple search for flexibleConstraints in testsystems suggests that this parameter is never actually used anywhere--it's present only in the constructor function header and nowhere else.

Something is wrong with travis, so I need to do a trivial direct commit to debug.

The Amber14 benchmark suite can be found here:
http://ambermd.org/Amber14_Benchmark_Suite.tar.bz2

Something is wrong with these examples, since the hydrogens have sigma = 0. These examples no longer have their provenance information either, so they should just be regenerated.

https://github.com/warner/python-versioneer

openmmtools has in the run section in meta.yml

• nose
• setuptools

this causes unnecessary installation of these packages (I think) when using conda install.
I assume that just removing will break the tests in travis. So not sure what the best strategy is.
This is not really urgent.

My crude experiments suggest that, for a 4500 atom system, the GHMC integrator is 3 or 4 times slower than Langevin.

Given this slowdown, most users would be more inclined to just reduce their timestep and stick with Langevin. A faster implementation of GHMC might help with that.

Just a reminder to myself to roll a new release and update conda build

See discussion in #40

The idea comes from this thread from @jhprinz:

Another idea I had is, if instead of having test systems, we would also have test simulators which are like a test system, but without the actual topology/protein. E.g. only a simulation with a VVVRIntegrator, PME, barostat defined by some options? This way we can use it to restart a simulation without storing the system object. So a testsimulation contains a factory for a full simulation given some parameters and a topology. These could then partially be used in the testsystems? Just an idea...