CHARMM's OpenMM barostat did not have anisotropic capability in release c37b2. The version under development a year ago worked exactly as Peter said. The CHARMM user forum could give you a better answer about its current status.

The 5.1 beta does not have those const modifiers, so at the moment our plugin has one version for the 5.1 beta and one for the head of the svn trunk. I'd like to find a way to make the same plugin source compatible with either 5.0 or 5.1 at compile time. If that isn't possible, we'll probably have t...

Revision 3739 adds const modifiers to some API methods: Force::createImpl ForceImpl::getOwner If you are implementing "MyForce" in a plugin, this requires similar changes to: MyForce::createImpl MyForceImpl::MyForceImpl MyForceImpl::getOwner MyForceImpl::owner This won't be part of release 5.1, will...

This appears to correspond to SVN r3734.

Aha, I see the new Context::setVelocitiesToTemperature. That's worth mentioning in the release notes.

The attached patch adds a testArgonBox function to each of four variable timestep integrator tests. It passes with r3565 but fails with r3564 under the conditions Prof. Brooks described on Jan 7.

r3565 does not throw the OpenMMExceptions we were getting from our variable timestep CHARMM test script on either CUDA or OpenCL.

Here is a unit test illustrating the problem Prof. Brooks described on the Reference platform.

I agree with the suggested fix but would substitute OpenMM_False for 0.

I didn't realize that OpenMM 4.0 had been released. It's right there on the Downloads page but not mentioned on the News page or the openmm-news mailing list.