We are pleased to announce the availability of OpenMD version 2.3. In addition to bug fixes and significant performance improvements, there are new features that have been added to the code since the 2.2 release:

New Features:

20% performance improvement

New analysis code: SequentialProps, which can be used to compute time-dependent contact angles for droplets spreading on surfaces.

Selection syntax now allows selection of objects at the molecule-level or particular bonds, bends, torsions, etc.

New post-processing scripts:

vcorr2spectrum – allows easy calculation of vibrational power spectra

stat2dielectric – allows computation of dielectric constants

mdShrink – Skips every n frames of an OpenMD dump file and loads it into new dump file

New modules for StaticProps:

System-wide Multipole Sums (dipole and quadrupole)

Geometric Hydrogen Bond statistics

Tetrahedrality parameters sorted by Z, or prepared for volume rendering

New FCCofR and IcosahedralOfR analyzers for local orientational ordering statistics

We are pleased to announce the availability of OpenMD version 2.2. This is primarily a performance and bug-fix release, but there are some new features that have been added to the code since the 2.1 release:

We are pleased to announce the availability of OpenMD version 2.1. This is primarily a performance and bug-fix release, but there are some new features that have been added to the code since the 2.0 release:

The electrostatics code has been completely re-written and two new real-space methods are available for testing for multipole-multipole interactions (look for upcoming papers on this subject).

We’ve added some spatial analysis tools to StaticProps that can compute properties as a function of the z-axis (in periodic boundaries) or as a function of radius (in non-periodic simulations). These properties include: temperature, density, velocity, angular velocity, and tetrahedral order parameters.

OpenMD now builds on a much wider array of compilers.

New perturbation: Static electric fields can be applied to the simulation.

There’s an interesting issue with of how OpenMD distributes load on parallel (MPI) architectures. At the very beginning of a parallel simulation, the molecules are distributed among the processors using a short Monte Carlo procedure to divide the labor. This ensures that each processor has an approximately equal number of atoms to work with, and that the row- and column- distribution of atoms in the force decomposition is roughly equitable. The Monte Carlo procedure involves the use of a pseudo-random number to make processor assignments. So, if you run the same parallel simulation multiple times, the distribution of atoms on the processors can change from run to run. This shouldn’t be a problem if the MD algorithms are all working as they should, right?

However, one thing that many people forget is a specific limitation of floating point arithmetic. Due to roundoff errors, the associative laws of algebra do not necessarily hold for floating-point numbers. For example, on a computer, the sum

(x+y)+z

can have a different answer than

x+(y+z)

when x = 1030, y = -1030 and z = 1. In the first case, the answer we get is 1, while roundoff might give us 0 for the second expression. The addition-ordering roundoff issue can have effects on a simulation that are somewhat subtle. If you add up the forces on an atom in a different order, the total force might change by a small amount (perhaps 1 part in 1010). When we use this force to move that atom, we’ll be off by a small amount (perhaps 1 part in 109). These small errors can start to make real differences in the microstate of a simulation (i.e. the configuration of the atoms), but shouldn’t alter the macrostate (i.e. the temperature, pressure, etc.).

That said, whenever there’s a random element to the order in which quantities are added up, we can get simulations that are not reproducible. And non-reproducibility is, in general, not good. So, how do we get around this issue in OpenMD? We let the user introduce a static seed for the random number generator that ensures that we always start with exactly the same set of pseudo-random numbers. If we seed the random number generator, then on the same number of processors, we’ll always get the same division of atoms, and we’ll get reproducible simulations.

To use this feature simply add a seed value to your <MetaData> section:

seed = 8675309;

This seed can be any large positive integer (an unsigned long int).

Once the seed is set, you can run on MPI clusters and be reasonably sure of getting reproducible simulations for runs with the same number of processors. However, if you mix runs of different numbers of processors, then the roundoff issue will reappear.

We are pleased to announce the availability of OpenMD version 2.0. This version represents a complete rewrite of the low-level force routines into C++. Here are some features that have been added to the code since the latest release:

The low-level loops, non-bonded interactions, and parallelization have been completely rewritten into C++ and should be faster.

The build system has been converted to CMake, which makes builds approximately 4 times faster than previous versions.

Multiple overlapping non-bonded interactions can be defined explicitly for two atom types.

Users can specify an electric field and we have added an architecture for external perturbations.

OpenMD now uses Gay-Berne strength parameter mixing ideas from Wu et al. [J. Chem. Phys. 135, 155104 (2011)]. This helps get the dissimilar particle mixing behavior to be the same whichever order the two particles come in. This does require that the force field file to specify explicitly the values for epsilon in the cross (X), side-by-side (S), and end-to-end (E) configurations.

There are also a few hundred bugs that have been fixed in this release.

PERFORMANCE: Updated the BlockSnapshotManager to use a specified memory footprint in constructor and not to rely on physmem and residentMem to figure out free memory. DynamicProps is the only program that uses the BlockSnapshotManager, so substantial changes were needed there as well.

Fixed a clang compilation problem

Added the ability to output particle potential in the dump files

Added Momentum correlation function

Imported changes from Vector from development branch.

Added P4 order parameter to the computation done during director axis and P2 computation.

Added support to print Thermal Helfand Moment in the stat file.

Fixed typo in thermo.

Added RNEMD integrator.

Added vector source capability for the P2 order parameter in staticProps.