OpenMDMolecular Dynamics in the Open2016-09-17T00:42:17Zhttp://openmd.org/feed/atom/WordPressSuzanne Neidharthttp://openmd.org/?p=5502016-08-11T18:33:18Z2016-08-11T18:30:15ZThis example will walk you through how to build an icosahedral gold nanoparticle and equilibrate the system to 250K.

Here we will be building an icosahedra with 8 shells (layers of gold atoms). Icosahedra are experimentally interesting due to the 20 exposed (111) facets, which have a lower surface energy than exhibited by the spherical particles.

where file.omd is the name of your icosahedra, 8 is the number of shells (in this example), 4.08 is the lattice constant in Angstroms for the metal (4.08 is the correct value for gold), and the skeletal OpenMD file above is called gold.omd

To make sure this icosahedra is the right size for your purposes; use Dump2XYZ to create an xyz file:

Dump2XYZ -i file.omd

and view the file in VMD or Jmol (where you might want to measure the diameter of the particle).

To run the icosahedra in a Langevin Hull and heat the system, we’ll start by inserting the following excerpt after the forceFieldFileName in file.omd.

Before we can equilibrate the system, the atoms need initial velocities, which we can set using the thermalizer command.

thermalizer -t 5 -o file-5K.omd file.omd

where -t is followed by the desired temperature in Kelvin, and -o is followed by the output file name.

To relax the particle at 5K, we’ll run the simulation described in file-5K.omd using the openmd command:

openmd file-5K.omd

To ensure that the temperature of the system has reached 5K, we can use xmgrace to view the stat file:

xmgrace -nxy file-5K.stat

In a typical stat file, set 3 (the fourth column) contains the information about the temperature of the system. You can view only the temperature for the trajectory by double clicking any line and bringing up the Set Appearance box. All the sets are initially displayed; turn off the sets you don’t want to see by highlighting and right clicking the set to click the Hide option.

The “end of run” file that has been relaxed can then be copied to a new simulation that will be heated to 100K.

cp file-5K.eor file-100K.omd

Then change the targetTemp from 5 to 100.

We’ll continue the procedure of copying the .eor file to a new .omd file and increasing the temperature until we’ve reached 250K. Temperature increases of 50 – 100K and simulation times of 100 – 200 ps are reasonable. Heating the system in intervals is relatively effective in keeping the geometry of the particle stable.

]]>0Dan Gezelterhttp://www.nd.edu/~gezelterhttp://openmd.org/?p=5332016-07-28T20:39:37Z2016-07-28T20:39:17ZWe are pleased to announce the availability of OpenMD version 2.4. In addition to bug fixes and performance improvements, there are new features that have been added to the code since the 2.3 release:

New Features:

Added Mie potentials for non-bonded interactions

We now have an initial implementation of fluctuating-density EAM models

A new omd2omd utility replaces the md2md script. omd2omd is able to do box repeats and translations without splitting up individual molecules.

Added a normalization option to vcorr2spectrum

All of the analysis programs (StaticProps, DynamicProps, SequentialProps) now provide revision and meta-data in their output files

Added arithmetic mixing rule option to GB (Gay-Berne) potentials.

Added support for selecting Bonds, Bends, Torsions, Inversions, and Molecules in parallel environments.

Added “potentialSelection” keyword for reporting Potential Energy for a selection in a stat file.

Added an option to use force field files with or without the scaled bond and bend force constants (e.g. Amber and Charmm use k (r-r0)2 while TraPPE and OpenMD default to k/2 * (r-r0)2).

]]>0Dan Gezelterhttp://www.nd.edu/~gezelterhttp://openmd.org/?p=5022015-03-20T19:16:06Z2015-03-20T19:16:06ZWe 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

]]>0Dan Gezelterhttp://www.nd.edu/~gezelterhttp://openmd.org/?p=4672014-04-17T20:44:54Z2014-04-17T20:28:02ZWe 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:

]]>0Dan Gezelterhttp://www.nd.edu/~gezelterhttp://openmd.org/?p=4532013-11-14T02:36:33Z2013-11-14T02:36:33ZWe 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.

New electrostatic method: single-processor implementation of a multipolar Ewald sum.

New correlation function: COH(z,t), which is a spatially-resolved OH bond time correlation function for water.

Significant performance boost over 2.0

]]>0Kelsey Stockerhttp://openmd.org/?p=2772016-08-03T15:05:19Z2013-06-13T18:32:31ZIn this example, we’ll build a gold nanoparticle and equilibrate it to a temperature of 300K. In future posts, we’ll add ligands and solvent to this structure. Here’s a sneak preview of the nanoparticle we’ll make here:

Start with an input .omd file for the metal of your choice. We’ll be creating gold.omd for this example.

NanoparticleBuilder carves a nanoparticle of our chosen radius out of a perfect gold crystal. We need to give the atoms some initial velocities before we start equilibrating. We’ll start it out at 5K:

thermalizer -t 5 NP15.omd -o NP15_5K.omd

For the first step in the equilibration we need to let the gold lattice structurally relax. NP15_5K.omd can now be run:

openmd NP15_5K.omd

Running the simulation will create several new files. NP15_5K.dump contains the trajectory of the simulation. Statistics such as temperature, pressure, and energy will be recorded in the NP15_5K.stat file and can be viewed using:

xmgrace -nxy NP15_5K.stat

The end-of-run file NP15_5K.eor stores the last configuration of the simulation. We’ll copy it to a new .omd file.

cp NP15_5K.eor NP15_100K.omd

To continue with the equilibration we need to change the targetTemp of NP15_100K.omd. We’ll increase it to 100 and run the NP15_100K.omd file.

We’ll continue the procedure of copying the .eor file to a new .omd file and increasing the temperature until we’ve reached 300K. Temperature increases of 50 – 100K and simulation times of 100 – 200 ps are reasonable.

]]>33Dan Gezelterhttp://www.nd.edu/~gezelterhttp://openmd.org/?p=2572013-02-22T18:27:05Z2013-02-22T18:27:05ZThere’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.

]]>0Dan Gezelterhttp://www.nd.edu/~gezelterhttp://openmd.net/?p=2332013-01-21T21:16:32Z2013-01-15T21:50:00ZWe 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.

]]>0Dan Gezelterhttp://www.nd.edu/~gezelterhttp://openmd.net/?p=1982016-08-04T14:23:46Z2012-10-07T18:50:37ZOpenMD is written in C++. Compiling is the process of turning this C++ code into instructions that the computer’s processor can understand.

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.

Basic build procedure

The most important thing to do is to download the latest release of the OpenMD code:

Have a coffee while the magic happens. If you have a multi-processor machine and would prefer an espresso, try a parallel build instead:

make -j 4

And finally, as root (or using sudo) you should install it:

umask 0022; sudo make install

Local build

With the right sort of environment variable magic (see below), you can actually use OpenMD straight from the build folder. But life is a bit easier if you install it somewhere, either system-wide or locally.

By default, OpenMD is installed in /usr/local on a Unix-like system. This requires root access (or sudo). Even if you do have root access, you may not want to overwrite an existing installation or you may want to avoid conflicts with a version of OpenMD installed by your package manager.

The solution to all of these problems is to do a local install into a directory somewhere in your home folder. An additional advantage of a local install is that if you ever want to uninstall it, all you need to do is delete the installation directory; removing the files from a global install is more work.

To configure cmake to install into ~/Tools/openmd-install, for example, you would do the following:

cmake ../openmd-2.4.1 -DCMAKE_INSTALL_PREFIX=~/Tools/openmd-install

Then you can run make and make install without needing root access:

make && make install

Troubleshooting build problems

CMake caches some variables from run-to-run. How can I wipe the cache to start from scratch?Delete CMakeCache.txt in the build directory. This is also a very useful file to look into if you have any problems.

What environment variables affect how OpenMD finds force field and data files?FORCE_PARAM_PATH – This environment variable is used by OpenMD to find the location of the data files used for force fields and atom sizes, etc. If you get errors about not being able to find some .txt files, then you should set this to the name of the folder containing files such as Amber.frc and element.txt. These are typically installed to /usr/local/openmd/forceFields

CMake honors user umask settings for creating directories. To get predictable results please set umask explicitly before running the make install command.

Advanced build options

How do I do a debug build?-DCMAKE_BUILD_TYPE=Debug does a debug build (gcc -g).
To revert to a regular build use -DCMAKE_BUILD_TYPE=Release.

How do I see what commands cmake is using to build?
Run Make as follows:

VERBOSE=1 make

How do I build the Doxygen documentation?If CMake found the “doxygen” program in your PATH, an optional build target called “doc” is created. If the Doxygen executable was not on the PATH, you will need to specify its location with -DDOXYGEN_EXECUTABLE=wherever. To build the documentation, type:

make doc

]]>3Dan Gezelterhttp://www.nd.edu/~gezelterhttp://openmd.net/?p=1782012-01-18T20:09:00Z2012-01-18T20:09:00ZWe are pleased to announce the release of OpenMD version 1.1.5. This version is a bugfix release, and is recommended for all users of OpenMD. New things include:

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.