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

can have a different answer than

when x = 10³⁰, y = -10³⁰ 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 10¹⁰). When we use this force to move that atom, we’ll be off by a small amount (perhaps 1 part in 10⁹). 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:

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.

• 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.
• There’s a new velocity-shearing and scaling (VSS) method for reverse non-equilibrium molecular dynamics (RNEMD).
• We have added a completely new optimization library.
• The selection syntax has been parallelized and now works during parallel simulations.
• New correlation functions:  Selection survival correlation functions.
• New correlation functions: Helfand-moments for thermal conductivity [Viscardy et al. JCP 126, 184513 (2007)]
• 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.

We’re going to assume here that you have already built and installed all of the prerequisites. If you haven’t done that, go install all of the required stuff and come back. We’ll wait.

Now that you’ve got all the stuff you need, you are ready to compile OpenMD on any unix-like operating system (including Mac OS).  We’re going to assume that you know how to use a command line interface and are comfortable with basic unix commands. The commands below are written assuming you are using bash (or the Bourne-Again SHell). Setting environment variables in csh or tcsh is just a little bit different.

• Added the LangevinHull integrator and sample files.
• Added “hull” token to selection syntax
• BUGFIX: Added a check to make sure value matches data type of ForceField parameters
• BUGFIX: We now traverse the base chains for NON-bonded interactions as well as bonded. This allows one to specify Metal – non-Metal interactions based on base types instead of exact matches.
• Matched default Charges for OH and HO (Hydroxyl) to the values from OPLS paper.
• BUGFIX: Changed dumpwriter to synchronize file writing to avoid file descriptor issues on large machines (>1000 nodes).
• Added support for a stress correlation function.
• BUGFIX: fixed a rare cutoff bug in calc_eam_prepair_rho
• Added a staticProps module to compute the length of a nanorod
• 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.

• Fixed a bug on atomic torques for MPI jobs involving directional (Sticky, GayBerne) atoms.
• Added a new NPTsz integrator (similar to NPTxyz, but locks the expansion / contraction of the x and y axes together).

• Fixed a bug in doForces that was causing errors in the total potential
• Added a count option in StaticProps (useful for counting atoms that match selection criteria)

• Fixed a bug with FCFLAGS in the configure script
• Fixed a configure script bug for qhull with C++ compilers
• Fixed a bug with the conserved quantity in NPTxyz
• Performance enhancements in main force loop (replaced slow anint with floor & ceiling) (10-20% speedup!)

• Fixed calls to getCharge for non-charge atoms (triggered by shifted pot / shifted force computations of self-self interactions without point charges on topologically connected molecules).
• gcc 4.4 compatibility in ProgressBar
• Revamped the visitor architecture to allow for easier conversion of internal data structures into xyz files for export and display.
• Added svn revision numbering for banner display.

• Added a Progress bar to print out how long the simulation has remaining.
• Fixed ConvexHull code and added “select hull” as valid selection syntax.
• Fixed over-specificity in md-solvator and fixed installation bug.
• Fixed parameter typo for minimizer.
• Fixed gradients for minimization of rigid bodies
• Added EAM line for Art Voter’s aluminium potential
• Added NaN / INF detectors to DumpWriter and StatWriter
• Added a new correlation function (gofrz) to do slab-segregated g(r) calculations. This computes at g(r) for pairs while requiring the z coordinates of the two sites to be at fixed separations. The data is output in: r, z, g(r,z).
• Fixed a number of bugs in GhostBend and GhostTorsion.
• Fixed a bug in Torsion (and GhostTorsion) triggered by configurations with colinear atoms. The problem was discovered by Brett Donovan. Thanks, Brett!
• Added a new CosineBendType
• Updated the visitor architecture to make it easier to extend
• Updated Dump2XYZ to output velocities, forces, or vectors if requested.

1. Start with a good structure for your molecule. If you are familiar with Avogadro, build the methanol structure (CH₃OH), set up the force field, and optimize the structure. Save the structure as methanol.xyz. Alternatively, download the methanol.xyz structure to your working directory.
2. Use the atom2md program to convert the structure into a format that can be read by OpenMD:
   atom2md -ixyz methanol.xyz

   This command will create an incomplete OpenMD file called methanol.md that must be edited before it can be used.
   

3. OpenMD can use a number of force fields, but in this example, we’ll use the Amber force field. If you are using this force field and are starting from an XYZ file or non-standard PDB file, you must edit the atom types. In the methanol.md file:
   • change the atom typing for the methyl carbon from C3 to CT
   • change the O3 to OH
   • The hydrogens on the carbon should also be changed from HC to H1
   • The hydroxyl hydrogen can be left alone.
4. At this point it is also a good idea to change the name of the molecule to something descriptive (perhaps “methanol”). This should be done in two places; once in the molecule description and another time in the component block.
5. Before the simulation can run, add a forceField line after the component block:
   forceField = "Amber";

   At this stage, you should be able to run OpenMD on the file to check to make sure your hand-crafted atom typing can be matched up with types known by the force field:

   openmd methanol.md

   If there are any problems, correct any unknown atom types, and repeat until you get an error about the “Integrator Factory”.
   

6. Next, we’ll build a lattice of methanol molecules using this initial structure as a starting point. The density of liquid methanol is roughly 0.7918 g cm^-3, so we’ll build a simple box of methanol molecules using the command:
   simpleBuilder -o liquid.md --density=0.7918 --nx=3 --ny=3 --nz=3 methanol.md

   This command creates a new system, liquid.md which contains 108 copies of the methanol molecule arranged in a simple FCC lattice. FCC has 4 molecules in the unit cell, so the total number of molecules = 4 * 3 * 3 * 3 = 108. The molecules are packed at a distance commensurate with their liquid state density.

7. To visualize what the system looks like at this stage, you can run:
   Dump2XYZ -i liquid.md

   to create a file called liquid.xyz. This file can be viewed in VMD, Jmol, or any other chemical structure viewer.

8. Add the following lines below the forceField line of the liquid.md file:
   ensemble = NVT;
   cutoffMethod = "shifted_force";
   electrostaticScreeningMethod = "damped";
   cutoffRadius = 9;
   dampingAlpha = 0.18;
   targetTemp = 300;
   tauThermostat = 1000;
   dt = 1.0;
   runTime = 1e3;
   tempSet = "false";
   sampleTime = 100;
   statusTime = 10;
9. Initial configurations that are created from bare structures typically have no velocity information. To give an initial kick to the atoms (i.e. to sample the velocities from a Maxwell-Boltzmann distribution), you can use the following command:
   thermalizer -o warm.md -t 300 liquid.md

   This creates a new OpenMD file called warm.md which has initial velocity information.

10. At this stage, a simple simulation can be run:
    openmd warm.md

11. This should complete relatively quickly, and should create a warm.stat file as well as a warm.dump file containing the actual trajectory.
12. To view the contents of the trajectory file, you’ll need to convert the dump file into something another program can visualize:
    Dump2XYZ -i warm.dump

    will create a new file warm.xyz that can be viewed in VMD and many other chemical structure viewers.

13. The “End-of-Run” file warm.eor can be re-purposed as the starting point for a new simulation:
    cp warm.eor  equilibration.md

    Edit the equilibration.md file, and change parameters you’d like to change before running openmd on the new file.