OpenMM 8.4.0

This release adds lots of new features.

• QTBIntegrator implements the adaptive quantum thermal bath algorithm. This is a fast method of adding nuclear quantum effects to a simulation.
• ConstantPotentialForce implements the constant potential algorithm. This is for simulating systems where an electrode is held at a constant potential, for example in capacitors or batteries. At each time step, it automatically solves for the distribution of charges on the electrode.
• TinkerFiles allows creating systems from Tinker input files (.xyz, .key, .prm).
• The lipid21 force field is now supported. It is included as part of amber19-all.xml, allowing lipids to be parameterized.
• OrientationRestraintForce provides a harmonic restraint to prevent molecules or other groups of atoms from rotating.
• RGForce calculates the radius of gyration of a group of atoms. It is mainly intended for use with CustomCVForce.
• ForceField will often give better error messages than before, hopefully making it easier to figure out why it couldn't parameterize a system.

OpenMM 8.3.1

This is a patch release containing the following fixes.

#4980: Fixed bug in computing pressure
#4986: Add function parsing to custom multiparticle force
#4989: Update CHARMM36 2024 and add water models

OpenMM 8.3.0

This release adds a number of new features. Here are the more important ones.

It adds several new or updated force fields. That includes Amber ff19SB, the 2024 version of CHARMM36, and the 2023 version of the CHARMM polar force field. Except when backward compatibility is specifically needed, the new versions are generally preferred over the old ones.

DPDIntegrator is a new integrator for performing Dissipative Particle Dynamics.

CustomVolumeForce is a new force that can depend on the size or shape of the periodic box.

Barostats now have the ability to compute the instantaneous pressure on the system.

This release includes changes to support constant pH. The actual implementation of constant pH is currently in a separate repository, but it requires some changes that are in this release.

When loading PDBx/mmCIF files, it can load the chem_comp_bond records found in recent files to load bonds for heterogens, as well as bond type and bond order information.

OpenMM 8.2.0

This release is a major update with a focus on improving performance.

For the first time in many years, this release introduces a new platform. It is based on AMD's HIP framework. When running on recent AMD GPUs, it delivers roughly double performance compared to the OpenCL platform. (Many thanks to Anton Gorenko for his amazing work on this!)

There also are many other optimizations. Some are low level optimizations that will benefit lots of simulations. Others are narrowly focused on particular features. DrudeSCFIntegrator, CustomHbondForce, and ATMForce are all faster. Energy minimization is often faster. Calling updateParametersInContext() methods to modify parameters is often faster. The overhead of using a reporter to save a trajectory to disk is decreased.

Another major change is that we now support installing OpenMM with pip as well as conda. In many cases, this is a more convenient way of installing. It is particularly important for the HIP platform, since at present it is not possible to distribute software using HIP through conda-forge. See the user guide for instructions on how to install through both mechanisms.

There also are some new features, though most are fairly minor. They include,

• The position of a virtual site is now permitted to depend on another virtual site, a feature required for certain force fields.
• GromacsTopFile supports more types of virtual sites.
• Topology can now store atomic formal charges. When reading a PDB or PDBx/mmCIF file that includes formal charges, they are recorded in the Topology.
• Modeller.addHydrogens() has a new option that lets you specify exactly what hydrogens to add for a residue.

There are a few API improvements. Although minor, they affect very commonly used functions, allowing for slightly less wordy code. When calling Context.getState(), you can omit the word "get" from the arguments specifying what information to retrieve. For example, you can write getState(positions=True, forces=True) instead of getState(getPositions=True, getForces=True). To retrieve the Platform with a certain name, you can call Platform.getPlatform(name) instead of Platform.getPlatformByName(name). The old versions of these APIs are still supported, so existing code will continue to work.

There is one significant change in behavior. Since LangevinMiddleIntegrator was introduced in OpenMM 7.5, the old LangevinIntegrator class has been supported only for backward compatibility. It is never recommended, since it is based on a less accurate discretization of the Langevin equation. Nonetheless, we frequently observe people using it, not realizing there is a better alternative and their results are unnecessarily inaccurate. After four years, the harm caused by this outweighs any remaining benefits of backward compatibility. This release changes LangevinIntegrator to use the same algorithm as LangevinMiddleIntegrator. The two classes are now identical in all respects except name. If for some reason you really want the old discretization, you can still use a CustomIntegrator to recreate it.

OpenMM 8.2.0 beta

This release is a major update with a focus on improving performance.

For the first time in many years, this release introduces a new platform. It is based on AMD's HIP framework. When running on recent AMD GPUs, it delivers roughly double performance compared to the OpenCL platform. (Many thanks to Anton Gorenko for his amazing work on this!)

There also are many other optimizations. Some are low level optimizations that will benefit lots of simulations. Others are narrowly focused on particular features. DrudeSCFIntegrator, CustomHbondForce, and ATMForce are all faster. Energy minimization is often faster. Calling updateParametersInContext() methods to modify parameters is often faster. The overhead of using a reporter to save a trajectory to disk is decreased.

There also are some new features, though most are fairly minor. They include,

• The position of a virtual site is now permitted to depend on another virtual site, a feature required for certain force fields.
• GromacsTopFile supports more types of virtual sites.
• Topology can now store atomic formal charges. When reading a PDB or PDBx/mmCIF file that includes formal charges, they are recorded in the Topology.
• Modeller.addHydrogens() has a new option that lets you specify exactly what hydrogens to add for a residue.

There are a few API improvements. Although minor, they affect very commonly used functions, allowing for slightly less wordy code. When calling Context.getState(), you can omit the word "get" from the arguments specifying what information to retrieve. For example, you can write getState(positions=True, forces=True) instead of getState(getPositions=True, getForces=True). To retrieve the Platform with a certain name, you can call Platform.getPlatform(name) instead of Platform.getPlatformByName(name). The old versions of these APIs are still supported, so existing code will continue to work.

There is one significant change in behavior. Since LangevinMiddleIntegrator was introduced in OpenMM 7.5, the old LangevinIntegrator class has been supported only for backward compatibility. It is never recommended, since it is based on a less accurate discretization of the Langevin equation. Nonetheless, we frequently observe people using it, not realizing there is a better alternative and their results are unnecessarily inaccurate. After four years, the harm caused by this outweighs any remaining benefits of backward compatibility. This release changes LangevinIntegrator to use the same algorithm as LangevinMiddleIntegrator. The two classes are now identical in all respects except name. If for some reason you really want the old discretization, you can still use a CustomIntegrator to recreate it.

OpenMM 8.1.2

This is a patch release containing the following fixes.

#4410: Write DCD version as 24 instead of 21 to fix ability of CHARMM to read DCD trajectories written by OpenMM.
#4461: Fixed memory leak
#4485: Avoid overflow in large XTC files
#4508: Fixed error when using both CustomNonbondedForce and LennardJonesForce
#4531: Allow multiple registrations of the same atom type if definitions identical.

OpenMM 8.1.1

This is a patch release containing the following changes.

#4351: Fixed bug in large blocks optimization with triclinic boxes
#4364: Fixed error in barostat

OpenMM 8.1.0

This release contains many performance improvements, particularly to the CUDA and OpenCL platforms. The largest speedups are for very large systems, in the range of 1 million particles or more, which can now be much faster. Other simulations will also often be faster, though by smaller amounts. Some examples of cases that have been specifically optimized include PME on the OpenCL platform; very small systems (less than 3000 particles) on the CUDA platform; CUDA or OpenCL simulations on Windows; CUDA simulations that are parallelized across multiple GPUs; and CUDA or OpenCL simulations that use CustomHbondForce.

This release adds a new class called ATMForce that implements the Alchemical Transfer Method. This is an efficient, relatively easy to use method for doing alchemical free energy calculations. See https://doi.org/10.1021/acs.jcim.1c01129 for more information.

There is a new XTCReporter class for writing simulation trajectories to XTC files. This is an alternative to DCD for efficiently storing trajectories. It stores coordinates with reduced precision, which leads to significantly smaller files.

When running local energy minimizations, it is now possible to pass a reporter to the minimizer. This allows you to monitor the progress of minimization and optionally to stop it early when custom criteria are met.

The GromacsTopFile class now supports GROMACS files that use GROMOS force fields.

This release adds a new piece of low level infrastructure for use when writing plugins: the CustomCPPForceImpl class. It is used for writing plugins that are implemented entirely in platform-independent C++. This is useful, for example, when writing plugins that interface to other libraries or programs. By using the new mechanism, the amount of code needed for plugins of that sort is dramatically reduced.

One significant feature has been removed: GromacsTopFile can no longer read files that use implicit solvent. GROMACS removed all support for implicit solvent a few years ago, and it had not worked correctly for several years before that. OpenMM continued to support GROMACS files with implicit solvent, but it required you to have an increasingly obsolete version of GROMACS installed on your computer. That support has now been removed.

OpenMM 8.1.0 beta

This release contains many performance improvements, particularly to the CUDA and OpenCL platforms. The largest speedups are for very large systems, in the range of 1 million particles or more, which can now be much faster. Other simulations will also often be faster, though by smaller amounts. Some examples of cases that have been specifically optimized include PME on the OpenCL platform; very small systems (less than 3000 particles) on the CUDA platform; CUDA or OpenCL simulations on Windows; CUDA simulations that are parallelized across multiple GPUs; and CUDA or OpenCL simulations that use CustomHbondForce.

This release adds a new class called ATMForce that implements the Alchemical Transfer Method. This is an efficient, relatively easy to use method for doing alchemical free energy calculations. See https://doi.org/10.1021/acs.jcim.1c01129 for more information.

There is a new XTCReporter class for writing simulation trajectories to XTC files. This is an alternative to DCD for efficiently storing trajectories. It stores coordinates with reduced precision, which leads to significantly smaller files.

When running local energy minimizations, it is now possible to pass a reporter to the minimizer. This allows you to monitor the progress of minimization and optionally to stop it early when custom criteria are met.

The GromacsTopFile class now supports GROMACS files that use GROMOS force fields.

This release adds a new piece of low level infrastructure for use when writing plugins: the CustomCPPForceImpl class. It is used for writing plugins that are implemented entirely in platform-independent C++. This is useful, for example, when writing plugins that interface to other libraries or programs. By using the new mechanism, the amount of code needed for plugins of that sort is dramatically reduced.

One significant feature has been removed: GromacsTopFile can no longer read files that use implicit solvent. GROMACS removed all support for implicit solvent a few years ago, and it had not worked correctly for several years before that. OpenMM continued to support GROMACS files with implicit solvent, but it required you to have an increasingly obsolete version of GROMACS installed on your computer. That support has now been removed.

OpenMM 8.0.0

A major focus of this release is on better supporting machine learning potentials. Many of the changes are internal ones that are not directly visible, but are needed by the OpenMM-Torch and OpenMM-ML plugins.

There are many optimizations to the CPU platform. You should see some improvement in most situations, but in certain cases it's especially dramatic.

• Custom forces are much faster than before on ARM CPUs. Previously it only supported JIT compilation of custom expressions on x86. On other architectures they needed to be evaluated with an interpreter, which was much slower. JIT compilation is now supported on ARM as well.

• CustomNonbondedForce should be much faster in most cases. Previously the JIT compiler was only able to produce scalar code that evaluated a single interaction at a time. It now can produce vectorized code, allowing the expression to be evaluated for multiple interactions at once.

• NonbondedForce is also much faster when the nonbonded method is NoCutoff. Previously the code for computing interactions with a cutoff was vectorized, but without a cutoff it was not. That code is now vectorized also, leading to large speedups.

• Previously we used FFTW to compute FFTs. We switched to PocketFFT, which in our internal testing is usually faster. This should improve the performance of PME on the CPU platform.

There also are a number of optimizations that affect other platforms as well. Some apply only to very specific situations. For example, recomputing the long range correction coefficient for CustomNonbondedForce is much faster.

CustomNonbondedForce now supports per-particle computed values, similar to CustomGBForce. You provide an expression that gets evaluated for each particle, and the result can be used in the energy expression. This can improve performance a lot in some cases, by only computing intermediate quantities once per particle instead of once per interaction.

When building solvent boxes, Modeller.addSolvent() has a new boxShape option for building non-rectangular boxes (rhombic dodecahedron or truncated octahedron). This makes it much easier to build non-rectangular boxes without needing to compute box vectors yourself.

As part of that feature, addSolvent() has changed how it interprets the "padding" option. It now makes a rigorous guarantee that no atom will be closer than the padding distance to any atom of any periodic copy. Previously it didn't guarantee that, and the amount of solvent it added could be either more or less than what was required. The new behavior should be better and closer to what you expect in almost all cases. Just be aware that it has changed. This may impact existing workflows that build solvent boxes.

The OpenCL platform now has improved support for low end GPUs that don't support 64 bit atomic operations. That includes, for example, the embedded GPUs found in Intel and Apple processors. Previusly there were certain Forces that couldn't be used on those GPUs, such as CustomManyParticleForce and AmoebaMultipoleForce. All Forces are now fully supported on those processors. In addition, performance on them will often be better than before.

When simulating a system with Drude particles, the temperature reported by StateDataReporter was previously a weighted average of the system temperature and Drude temperature, which tended to confuse people. It now reports the system temperature, and should match the value specified in the integrator.