+<P>The LAMMPS-ICMS "version" is the date when it was released, such as 1 May
2010. LAMMPS is updated continuously. Whenever we fix a bug or add a
-feature, we release it immediately, and post a notice on <a class="reference external" href="http://lammps.sandia.gov/bug.html">this page of the WWW site</a>. Each dated copy of LAMMPS contains all the
+feature, we release it immediately, and post a notice on <A HREF = "http://lammps.sandia.gov/bug.html">this page of
+the WWW site</A>. Each dated copy of LAMMPS contains all the
features and bug-fixes up to and including that version date. The
version date is printed to the screen and logfile every time you run
LAMMPS. It is also in the file src/version.h and in the LAMMPS
directory name created when you unpack a tarball, and at the top of
-the first page of the manual (this page).</p>
+the first page of the manual (this page).
+</P>
-<p>LAMMPS-ICMS is an experimental variant of LAMMPS with additional
+<P>LAMMPS-ICMS is an experimental variant of LAMMPS with additional
features made available for testing before they will be submitted
for inclusion into the official LAMMPS tree. The source code is
based on the official LAMMPS svn repository mirror at the Institute
for Computational Molecular Science at Temple University and generally
kept up-to-date as much as possible. Sometimes, e.g. when additional
development work is needed to adapt the upstream changes into
LAMMPS-ICMS it can take longer until synchronization; and occasionally,
e.g. in case of the rewrite of the multi-threading support, the
development will be halted except for important bugfixes until
all features of LAMMPS-ICMS fully compatible with the upstream
version or replaced by alternate implementations.
-</p>
-<ul class="simple">
-<li>If you browse the HTML doc pages on the LAMMPS WWW site, they always
-describe the most current version of LAMMPS.</li>
-<li>If you browse the HTML doc pages included in your tarball, they
-describe the version you have.</li>
-<li>The <a class="reference external" href="Manual.pdf">PDF file</a> on the WWW site or in the tarball is updated
-about once per month. This is because it is large, and we don’t want
-it to be part of every patch.</li>
-<li>There is also a <a class="reference external" href="Developer.pdf">Developer.pdf</a> file in the doc
+</P>
+
+<UL><LI>If you browse the HTML doc pages on the LAMMPS WWW site, they always
+describe the most current version of LAMMPS.
+
+<LI>If you browse the HTML doc pages included in your tarball, they
+describe the version you have.
+
+<LI>The <A HREF = "Manual.pdf">PDF file</A> on the WWW site or in the tarball is updated
+about once per month. This is because it is large, and we don't want
+it to be part of every patch.
+
+<LI>There is also a <A HREF = "Developer.pdf">Developer.pdf</A> file in the doc
directory, which describes the internal structure and algorithms of
-LAMMPS.</li>
-</ul>
-<p>LAMMPS stands for Large-scale Atomic/Molecular Massively Parallel
-Simulator.</p>
-<p>LAMMPS is a classical molecular dynamics simulation code designed to
+LAMMPS.
+</UL>
+<P>LAMMPS stands for Large-scale Atomic/Molecular Massively Parallel
+Simulator.
+</P>
+<P>LAMMPS is a classical molecular dynamics simulation code designed to
run efficiently on parallel computers. It was developed at Sandia
National Laboratories, a US Department of Energy facility, with
funding from the DOE. It is an open-source code, distributed freely
-under the terms of the GNU Public License (GPL).</p>
-<p>The primary developers of LAMMPS are <a class="reference external" href="http://www.sandia.gov/~sjplimp">Steve Plimpton</a>, Aidan
+under the terms of the GNU Public License (GPL).
+</P>
+<P>The primary developers of LAMMPS are <A HREF = "http://www.sandia.gov/~sjplimp">Steve Plimpton</A>, Aidan
Thompson, and Paul Crozier who can be contacted at
-sjplimp,athomps,pscrozi at sandia.gov. The <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW Site</a> at
-<a class="reference external" href="http://lammps.sandia.gov">http://lammps.sandia.gov</a> has more information about the code and its
-uses.</p>
-<hr class="docutils" />
-<p>The LAMMPS documentation is organized into the following sections. If
+sjplimp,athomps,pscrozi at sandia.gov. The <A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> at
+http://lammps.sandia.gov has more information about the code and its
+uses.
+</P>
+
+
+
+
+<HR>
+
+<P>The LAMMPS documentation is organized into the following sections. If
you find errors or omissions in this manual or have suggestions for
useful information to add, please send an email to the developers so
-we can improve the LAMMPS documentation.</p>
-<p>Once you are familiar with LAMMPS, you may want to bookmark <a class="reference internal" href="Section_commands.html#comm"><span>this page</span></a> at Section_commands.html#comm since
-it gives quick access to documentation for all LAMMPS commands.</p>
-<p><a class="reference external" href="Manual.pdf">PDF file</a> of the entire manual, generated by
-<li class="toctree-l2"><a class="reference internal" href="Section_start.html#what-s-in-the-lammps-distribution">2.1. What’s in the LAMMPS distribution</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_start.html#making-lammps">2.2. Making LAMMPS</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_start.html#making-lammps-with-optional-packages">2.3. Making LAMMPS with optional packages</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_start.html#building-lammps-via-the-make-py-script">2.4. Building LAMMPS via the Make.py script</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_start.html#building-lammps-as-a-library">2.5. Building LAMMPS as a library</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_accelerate.html#general-strategies">5.2. General strategies</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_accelerate.html#packages-with-optimized-styles">5.3. Packages with optimized styles</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_accelerate.html#comparison-of-various-accelerator-packages">5.4. Comparison of various accelerator packages</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#tip3p-water-model">6.7. TIP3P water model</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#tip4p-water-model">6.8. TIP4P water model</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#spc-water-model">6.9. SPC water model</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#coupling-lammps-to-other-codes">6.10. Coupling LAMMPS to other codes</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#calculating-a-diffusion-coefficient">6.22. Calculating a diffusion coefficient</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#using-chunks-to-calculate-system-properties">6.23. Using chunks to calculate system properties</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#setting-parameters-for-the-kspace-style-pppm-disp-command">6.24. Setting parameters for the <code class="docutils literal"><span class="pre">kspace_style</span> <span class="pre">pppm/disp</span></code> command</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_modify.html#submitting-new-features-for-inclusion-in-lammps">10.15. Submitting new features for inclusion in LAMMPS</a></li>
-</ul>
-</li>
-<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a><ul>
-<li class="toctree-l2"><a class="reference internal" href="Section_python.html#overview-of-running-lammps-from-python">11.1. Overview of running LAMMPS from Python</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_python.html#overview-of-using-python-from-a-lammps-script">11.2. Overview of using Python from a LAMMPS script</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_python.html#building-lammps-as-a-shared-library">11.3. Building LAMMPS as a shared library</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_python.html#installing-the-python-wrapper-into-python">11.4. Installing the Python wrapper into Python</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_python.html#extending-python-with-mpi-to-run-in-parallel">11.5. Extending Python with MPI to run in parallel</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_python.html#testing-the-python-lammps-interface">11.6. Testing the Python-LAMMPS interface</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_python.html#using-lammps-from-python">11.7. Using LAMMPS from Python</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_python.html#example-python-scripts-that-use-lammps">11.8. Example Python scripts that use LAMMPS</a></li>
- Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<a class="reference internal" href="if.html"><em>if</em></a>, and <a class="reference internal" href="python.html"><em>python</em></a> commands for examples.</p>
<p>A “#” or “$” character that is between quotes will not be treated as a
comment indicator in (2) or substituted for as a variable in (3).</p>
<div class="admonition warning">
<p class="first admonition-title">Warning</p>
<p class="last">If the argument is itself a command that requires a
quoted argument (e.g. using a <a class="reference internal" href="print.html"><em>print</em></a> command as part of an
<a class="reference internal" href="if.html"><em>if</em></a> or <a class="reference internal" href="run.html"><em>run every</em></a> command), then single, double, or
triple quotes can be nested in the usual manner. See the doc pages
for those commands for examples. Only one of level of nesting is
allowed, but that should be sufficient for most use cases.</p>
</div>
<hr class="docutils" />
</div>
<div class="section" id="input-script-structure">
<span id="cmd-3"></span><h2>3.3. Input script structure<a class="headerlink" href="#input-script-structure" title="Permalink to this headline">¶</a></h2>
<p>This section describes the structure of a typical LAMMPS input script.
The “examples” directory in the LAMMPS distribution contains many
sample input scripts; the corresponding problems are discussed in
<a class="reference internal" href="Section_example.html"><em>Section_example</em></a>, and animated on the <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW Site</a>.</p>
<p>A LAMMPS input script typically has 4 parts:</p>
<ol class="arabic simple">
<li>Initialization</li>
<li>Atom definition</li>
<li>Settings</li>
<li>Run a simulation</li>
</ol>
<p>The last 2 parts can be repeated as many times as desired. I.e. run a
simulation, change some settings, run some more, etc. Each of the 4
parts is now described in more detail. Remember that almost all the
commands need only be used if a non-default value is desired.</p>
<ol class="arabic simple">
<li>Initialization</li>
</ol>
<p>Set parameters that need to be defined before atoms are created or
read-in from a file.</p>
<p>The relevant commands are <a class="reference internal" href="units.html"><em>units</em></a>,
<p>Fixes impose a variety of boundary conditions, time integration, and
diagnostic options. The <a class="reference internal" href="fix.html"><em>fix</em></a> command comes in many flavors.</p>
<p>Various computations can be specified for execution during a
simulation using the <a class="reference internal" href="compute.html"><em>compute</em></a>,
<a class="reference internal" href="compute_modify.html"><em>compute_modify</em></a>, and <a class="reference internal" href="variable.html"><em>variable</em></a>
commands.</p>
<p>Output options are set by the <a class="reference internal" href="thermo.html"><em>thermo</em></a>, <a class="reference internal" href="dump.html"><em>dump</em></a>,
and <a class="reference internal" href="restart.html"><em>restart</em></a> commands.</p>
<ol class="arabic simple" start="4">
<li>Run a simulation</li>
</ol>
<p>A molecular dynamics simulation is run using the <a class="reference internal" href="run.html"><em>run</em></a>
command. Energy minimization (molecular statics) is performed using
the <a class="reference internal" href="minimize.html"><em>minimize</em></a> command. A parallel tempering
(replica-exchange) simulation can be run using the
<span id="cmd-4"></span><h2>3.4. Commands listed by category<a class="headerlink" href="#commands-listed-by-category" title="Permalink to this headline">¶</a></h2>
<p>This section lists all LAMMPS commands, grouped by category. The
<a class="reference internal" href="#cmd-5"><span>next section</span></a> lists the same commands alphabetically. Note
that some style options for some commands are part of specific LAMMPS
packages, which means they cannot be used unless the package was
included when LAMMPS was built. Not all packages are included in a
default LAMMPS build. These dependencies are listed as Restrictions
<span id="comm"></span><span id="cmd-5"></span><h2>3.5. Individual commands<a class="headerlink" href="#individual-commands" title="Permalink to this headline">¶</a></h2>
<p>This section lists all LAMMPS commands alphabetically, with a separate
listing below of styles within certain commands. The <a class="reference internal" href="#cmd-4"><span>previous section</span></a> lists the same commands, grouped by category. Note
that some style options for some commands are part of specific LAMMPS
packages, which means they cannot be used unless the package was
included when LAMMPS was built. Not all packages are included in a
default LAMMPS build. These dependencies are listed as Restrictions
<h2>3.7. Compute styles<a class="headerlink" href="#compute-styles" title="Permalink to this headline">¶</a></h2>
<p>See the <a class="reference internal" href="compute.html"><em>compute</em></a> command for one-line descriptions of
each style or click on the style itself for a full description. Some
of the styles have accelerated versions, which can be used if LAMMPS
is built with the <a class="reference internal" href="Section_accelerate.html"><em>appropriate accelerated package</em></a>. This is indicated by additional
letters in parenthesis: c = USER-CUDA, g = GPU, i = USER-INTEL, k =
<h2>3.8. Pair_style potentials<a class="headerlink" href="#pair-style-potentials" title="Permalink to this headline">¶</a></h2>
<p>See the <a class="reference internal" href="pair_style.html"><em>pair_style</em></a> command for an overview of pair
potentials. Click on the style itself for a full description. Many
of the styles have accelerated versions, which can be used if LAMMPS
is built with the <a class="reference internal" href="Section_accelerate.html"><em>appropriate accelerated package</em></a>. This is indicated by additional
letters in parenthesis: c = USER-CUDA, g = GPU, i = USER-INTEL, k =
<h2>3.9. Bond_style potentials<a class="headerlink" href="#bond-style-potentials" title="Permalink to this headline">¶</a></h2>
<p>See the <a class="reference internal" href="bond_style.html"><em>bond_style</em></a> command for an overview of bond
potentials. Click on the style itself for a full description. Some
of the styles have accelerated versions, which can be used if LAMMPS
is built with the <a class="reference internal" href="Section_accelerate.html"><em>appropriate accelerated package</em></a>. This is indicated by additional
letters in parenthesis: c = USER-CUDA, g = GPU, i = USER-INTEL, k =
<h2>3.10. Angle_style potentials<a class="headerlink" href="#angle-style-potentials" title="Permalink to this headline">¶</a></h2>
<p>See the <a class="reference internal" href="angle_style.html"><em>angle_style</em></a> command for an overview of
angle potentials. Click on the style itself for a full description.
Some of the styles have accelerated versions, which can be used if
LAMMPS is built with the <a class="reference internal" href="Section_accelerate.html"><em>appropriate accelerated package</em></a>. This is indicated by additional
letters in parenthesis: c = USER-CUDA, g = GPU, i = USER-INTEL, k =
<h2>3.11. Dihedral_style potentials<a class="headerlink" href="#dihedral-style-potentials" title="Permalink to this headline">¶</a></h2>
<p>See the <a class="reference internal" href="dihedral_style.html"><em>dihedral_style</em></a> command for an overview
of dihedral potentials. Click on the style itself for a full
description. Some of the styles have accelerated versions, which can
be used if LAMMPS is built with the <a class="reference internal" href="Section_accelerate.html"><em>appropriate accelerated package</em></a>. This is indicated by additional
letters in parenthesis: c = USER-CUDA, g = GPU, i = USER-INTEL, k =
<h2>3.12. Improper_style potentials<a class="headerlink" href="#improper-style-potentials" title="Permalink to this headline">¶</a></h2>
<p>See the <a class="reference internal" href="improper_style.html"><em>improper_style</em></a> command for an overview
of improper potentials. Click on the style itself for a full
description. Some of the styles have accelerated versions, which can
be used if LAMMPS is built with the <a class="reference internal" href="Section_accelerate.html"><em>appropriate accelerated package</em></a>. This is indicated by additional
letters in parenthesis: c = USER-CUDA, g = GPU, i = USER-INTEL, k =
<h2>3.13. Kspace solvers<a class="headerlink" href="#kspace-solvers" title="Permalink to this headline">¶</a></h2>
<p>See the <a class="reference internal" href="kspace_style.html"><em>kspace_style</em></a> command for an overview of
Kspace solvers. Click on the style itself for a full description.
Some of the styles have accelerated versions, which can be used if
LAMMPS is built with the <a class="reference internal" href="Section_accelerate.html"><em>appropriate accelerated package</em></a>. This is indicated by additional
letters in parenthesis: c = USER-CUDA, g = GPU, i = USER-INTEL, k =
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>The “Authors” column lists a name(s) if a specific person is
responible for creating and maintaining the package.</p>
<p>(1) The FLD package was created by Amit Kumar and Michael Bybee from
Jonathan Higdon’s group at UIUC.</p>
<p>(2) The OPT package was created by James Fischer (High Performance
Technologies), David Richie, and Vincent Natoli (Stone Ridge
Technolgy).</p>
<p>(3) The KIM package was created by Valeriu Smirichinski, Ryan Elliott,
and Ellad Tadmor (U Minn).</p>
<p>(4) The KOKKOS package was created primarily by Christian Trott
(Sandia). It uses the Kokkos library which was developed by Carter
Edwards, Christian, and collaborators at Sandia.</p>
<p>The “Doc page” column links to either a portion of the
<a class="reference internal" href="Section_howto.html"><em>Section_howto</em></a> of the manual, or an input script
command implemented as part of the package.</p>
<p>The “Example” column is a sub-directory in the examples directory of
the distribution which has an input script that uses the package.
E.g. “peptide” refers to the examples/peptide directory.</p>
<p>The “Library” column lists an external library which must be built
first and which LAMMPS links to when it is built. If it is listed as
lib/package, then the code for the library is under the lib directory
of the LAMMPS distribution. See the lib/package/README file for info
on how to build the library. If it is not listed as lib/package, then
it is a third-party library not included in the LAMMPS distribution.
See the src/package/README or src/package/Makefile.lammps file for
info on where to download the library. <a class="reference internal" href="Section_start.html#start-3-3"><span>Section start</span></a> of the manual also gives details
on how to build LAMMPS with both kinds of auxiliary libraries.</p>
</div>
<div class="section" id="user-packages">
<span id="pkg-2"></span><h2>4.2. User packages<a class="headerlink" href="#user-packages" title="Permalink to this headline">¶</a></h2>
<p>The current list of user-contributed packages is as follows:</p>
<table border="1" class="docutils">
<colgroup>
<col width="8%" />
<col width="21%" />
<col width="22%" />
<col width="25%" />
<col width="8%" />
<col width="10%" />
<col width="6%" />
</colgroup>
<tbody valign="top">
<tr class="row-odd"><td>Package</td>
<td>Description</td>
<td>Author(s)</td>
<td>Doc page</td>
<td>Example</td>
<td>Pic/movie</td>
<td>Library</td>
</tr>
<tr class="row-even"><td>USER-ATC</td>
<td>atom-to-continuum coupling</td>
<td>Jones & Templeton & Zimmerman (1)</td>
<p>The person who created this package is Agilio Padua at Universite
Blaise Pascal Clermont-Ferrand (agilio.padua at univ-bpclermont.fr)
Contact him directly if you have questions.</p>
</div>
<hr class="docutils" />
+<div class="section" id="user-h5md-package">
+<h2>4.12. USER-H5MD package<a class="headerlink" href="#user-h5md-package" title="Permalink to this headline">¶</a></h2>
+<p>This package contains a <a class="reference internal" href="dump_h5md.html"><em>dump h5md</em></a> command for
+performing a dump of atom properties in HDF5 format. <a class="reference external" href="http://www.hdfgroup.org/HDF5/">HDF5 files</a> are binary, portable and self-describing and can be
+examined and used by a variety of auxiliary tools. The output HDF5
+files are structured in a format called H5MD, which was designed to
+store molecular data, and can be used and produced by various MD and
+MD-related codes. The <code class="xref doc docutils literal"><span class="pre">dump</span> <span class="pre">h5md</span></code> command gives a
+citation to a paper describing the format.</p>
+<p>The person who created this package and the underlying H5MD format is
+Pierre de Buyl at KU Leuven (see <a class="reference external" href="http://pdebuyl.be">http://pdebuyl.be</a>). Contact him
+directly if you have questions.</p>
+</div>
+<hr class="docutils" />
<div class="section" id="user-intel-package">
-<h2>4.12. USER-INTEL package<a class="headerlink" href="#user-intel-package" title="Permalink to this headline">¶</a></h2>
+<h2>4.13. USER-INTEL package<a class="headerlink" href="#user-intel-package" title="Permalink to this headline">¶</a></h2>
<p>This package provides options for performing neighbor list and
non-bonded force calculations in single, mixed, or double precision
and also a capability for accelerating calculations with an
Intel(R) Xeon Phi(TM) coprocessor.</p>
<p>See this section of the manual to get started:</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<li class="toctree-l2"><a class="reference internal" href="#what-s-in-the-lammps-distribution">2.1. What’s in the LAMMPS distribution</a></li>
<li class="toctree-l2"><a class="reference internal" href="#making-lammps">2.2. Making LAMMPS</a></li>
<li class="toctree-l2"><a class="reference internal" href="#making-lammps-with-optional-packages">2.3. Making LAMMPS with optional packages</a></li>
<li class="toctree-l2"><a class="reference internal" href="#building-lammps-via-the-make-py-script">2.4. Building LAMMPS via the Make.py script</a></li>
<li class="toctree-l2"><a class="reference internal" href="#building-lammps-as-a-library">2.5. Building LAMMPS as a library</a><ul>
<li class="toctree-l3"><a class="reference internal" href="#additional-requirement-for-using-a-shared-library">2.5.3. <strong>Additional requirement for using a shared library:</strong></a></li>
<li class="toctree-l3"><a class="reference internal" href="#calling-the-lammps-library">2.5.4. <strong>Calling the LAMMPS library:</strong></a></li>
<span id="start-1"></span><h2>2.1. What’s in the LAMMPS distribution<a class="headerlink" href="#what-s-in-the-lammps-distribution" title="Permalink to this headline">¶</a></h2>
<p>When you download a LAMMPS tarball you will need to unzip and untar
the downloaded file with the following commands, after placing the
<p>This will create a LAMMPS directory containing two files and several
sub-directories:</p>
<table border="1" class="docutils">
<colgroup>
<col width="21%" />
<col width="79%" />
</colgroup>
<tbody valign="top">
<tr class="row-odd"><td>README</td>
<td>text file</td>
</tr>
<tr class="row-even"><td>LICENSE</td>
<td>the GNU General Public License (GPL)</td>
</tr>
<tr class="row-odd"><td>bench</td>
<td>benchmark problems</td>
</tr>
<tr class="row-even"><td>doc</td>
<td>documentation</td>
</tr>
<tr class="row-odd"><td>examples</td>
<td>simple test problems</td>
</tr>
<tr class="row-even"><td>potentials</td>
<td>embedded atom method (EAM) potential files</td>
</tr>
<tr class="row-odd"><td>src</td>
<td>source files</td>
</tr>
<tr class="row-even"><td>tools</td>
<td>pre- and post-processing tools</td>
</tr>
</tbody>
</table>
<p>Note that the <a class="reference external" href="download">download page</a> also has links to download
Windows exectubles and installers, as well as pre-built executables
for a few specific Linux distributions. It also has instructions for
how to download/install LAMMPS for Macs (via Homebrew), and to
download and update LAMMPS from SVN and Git repositories, which gives
you the same files that are in the download tarball.</p>
<p>The Windows and Linux executables for serial or parallel only include
certain packages and bug-fixes/upgrades listed on <a class="reference external" href="http://lammps.sandia.gov/bug.html">this page</a> up to a certain date, as
stated on the download page. If you want an executable with
non-included packages or that is more current, then you’ll need to
build LAMMPS yourself, as discussed in the next section.</p>
<p>Skip to the <a class="reference internal" href="#start-6"><span>Running LAMMPS</span></a> sections for info on how to
launch a LAMMPS Windows executable on a Windows box.</p>
<hr class="docutils" />
</div>
<div class="section" id="making-lammps">
<span id="start-2"></span><h2>2.2. Making LAMMPS<a class="headerlink" href="#making-lammps" title="Permalink to this headline">¶</a></h2>
<p>This section has the following sub-sections:</p>
<ul class="simple">
<li><a class="reference internal" href="#start-2-1"><span>Read this first</span></a></li>
<li><a class="reference internal" href="#start-2-2"><span>Steps to build a LAMMPS executable</span></a></li>
<li><a class="reference internal" href="#start-2-3"><span>Common errors that can occur when making LAMMPS</span></a></li>
This gives preference to a file you have created/edited and put in
src/MAKE/MINE.</p>
<p>Note that on a multi-processor or multi-core platform you can launch a
parallel make, by using the “-j” switch with the make command, which
will build LAMMPS more quickly.</p>
<p>If you get no errors and an executable like lmp_mpi or lmp_g++_serial
or lmp_mac is produced, then you’re done; it’s your lucky day.</p>
<p>Note that by default only a few of LAMMPS optional packages are
installed. To build LAMMPS with optional packages, see <a class="reference internal" href="#start-3"><span>this section</span></a> below.</p>
<p><strong>Step 1</strong></p>
<p>If Step 0 did not work, you will need to create a low-level Makefile
for your machine, like Makefile.foo. You should make a copy of an
existing Makefile.* in src/MAKE or one of its sub-directories as a
starting point. The only portions of the file you need to edit are
the first line, the “compiler/linker settings” section, and the
“LAMMPS-specific settings” section. When it works, put the edited
file in src/MAKE/MINE and it will not be altered by any future LAMMPS
updates.</p>
<p><strong>Step 2</strong></p>
<p>Change the first line of Makefile.foo to list the word “foo” after the
“#”, and whatever other options it will set. This is the line you
will see if you just type “make”.</p>
<p><strong>Step 3</strong></p>
<p>The “compiler/linker settings” section lists compiler and linker
settings for your C++ compiler, including optimization flags. You can
use g++, the open-source GNU compiler, which is available on all Unix
systems. You can also use mpicxx which will typically be available if
MPI is installed on your system, though you should check which actual
compiler it wraps. Vendor compilers often produce faster code. On
boxes with Intel CPUs, we suggest using the Intel icc compiler, which
can be downloaded from <a class="reference external" href="http://www.intel.com/software/products/noncom">Intel’s compiler site</a>.</p>
<p>If building a C++ code on your machine requires additional libraries,
then you should list them as part of the LIB variable. You should
not need to do this if you use mpicxx.</p>
<p>The DEPFLAGS setting is what triggers the C++ compiler to create a
dependency list for a source file. This speeds re-compilation when
source (<em>.cpp) or header (</em>.h) files are edited. Some compilers do
not support dependency file creation, or may use a different switch
than -D. GNU g++ and Intel icc works with -D. If your compiler can’t
create dependency files, then you’ll need to create a Makefile.foo
patterned after Makefile.storm, which uses different rules that do not
involve dependency files. Note that when you build LAMMPS for the
first time on a new platform, a long list of <a href="#id1"><span class="problematic" id="id2">*</span></a>.d files will be printed
out rapidly. This is not an error; it is the Makefile doing its
normal creation of dependencies.</p>
<p><strong>Step 4</strong></p>
<p>The “system-specific settings” section has several parts. Note that
if you change any -D setting in this section, you should do a full
re-compile, after typing “make clean” (which will describe different
clean options).</p>
<p>The LMP_INC variable is used to include options that turn on ifdefs
within the LAMMPS code. The options that are currently recogized are:</p>
<ul class="simple">
<li>-DLAMMPS_GZIP</li>
<li>-DLAMMPS_JPEG</li>
<li>-DLAMMPS_PNG</li>
<li>-DLAMMPS_FFMPEG</li>
<li>-DLAMMPS_MEMALIGN</li>
<li>-DLAMMPS_XDR</li>
<li>-DLAMMPS_SMALLBIG</li>
<li>-DLAMMPS_BIGBIG</li>
<li>-DLAMMPS_SMALLSMALL</li>
<li>-DLAMMPS_LONGLONG_TO_LONG</li>
<li>-DPACK_ARRAY</li>
<li>-DPACK_POINTER</li>
<li>-DPACK_MEMCPY</li>
</ul>
<p>The read_data and dump commands will read/write gzipped files if you
compile with -DLAMMPS_GZIP. It requires that your machine supports
-the “popen” function in the standard runtime library and that a gzip
+the “popen()” function in the standard runtime library and that a gzip
executable can be found by LAMMPS during a run.</p>
+<div class="admonition warning">
+<p class="first admonition-title">Warning</p>
+<p class="last">on some clusters with high-speed networks, using the
+fork() library calls (required by popen()) can interfere with the fast
+communication library and lead to simulations using compressed output
+or input to hang or crash. For selected operations, compressed file
+I/O is also available using a compression library instead, which are
+provided in the COMPRESS package. From more details about compiling
+LAMMPS with packages, please see below.</p>
+</div>
<p>If you use -DLAMMPS_JPEG, the <a class="reference internal" href="dump_image.html"><em>dump image</em></a> command
will be able to write out JPEG image files. For JPEG files, you must
also link LAMMPS with a JPEG library, as described below. If you use
-DLAMMPS_PNG, the <a class="reference internal" href="dump.html"><em>dump image</em></a> command will be able to write
out PNG image files. For PNG files, you must also link LAMMPS with a
PNG library, as described below. If neither of those two defines are
used, LAMMPS will only be able to write out uncompressed PPM image
files.</p>
<p>If you use -DLAMMPS_FFMPEG, the <a class="reference internal" href="dump_image.html"><em>dump movie</em></a> command
will be available to support on-the-fly generation of rendered movies
the need to store intermediate image files. It requires that your
machines supports the “popen” function in the standard runtime library
and that an FFmpeg executable can be found by LAMMPS during the run.</p>
+<div class="admonition warning">
+<p class="first admonition-title">Warning</p>
+<p class="last">Similar to the note above, this option can conflict
+with high-speed networks, because it uses popen().</p>
+</div>
<p>Using -DLAMMPS_MEMALIGN=<bytes> enables the use of the
posix_memalign() call instead of malloc() when large chunks or memory
are allocated by LAMMPS. This can help to make more efficient use of
vector instructions of modern CPUS, since dynamically allocated memory
has to be aligned on larger than default byte boundaries (e.g. 16
bytes instead of 8 bytes on x86 type platforms) for optimal
performance.</p>
<p>If you use -DLAMMPS_XDR, the build will include XDR compatibility
files for doing particle dumps in XTC format. This is only necessary
if your platform does have its own XDR files available. See the
Restrictions section of the <a class="reference internal" href="dump.html"><em>dump</em></a> command for details.</p>
<p>Use at most one of the -DLAMMPS_SMALLBIG, -DLAMMPS_BIGBIG, -D-
DLAMMPS_SMALLSMALL settings. The default is -DLAMMPS_SMALLBIG. These
settings refer to use of 4-byte (small) vs 8-byte (big) integers
within LAMMPS, as specified in src/lmptype.h. The only reason to use
the BIGBIG setting is to enable simulation of huge molecular systems
(which store bond topology info) with more than 2 billion atoms, or to
track the image flags of moving atoms that wrap around a periodic box
more than 512 times. Normally, the only reason to use SMALLSMALL is
if your machine does not support 64-bit integers, though you can use
SMALLSMALL setting if you are running in serial or on a desktop
machine or small cluster where you will never run large systems or for
long time (more than 2 billion atoms, more than 2 billion timesteps).
See the <a class="reference internal" href="#start-2-4"><span>Additional build tips</span></a> section below for more
details on these settings.</p>
<p>Note that two packages, USER-ATC and USER-CUDA are not currently
compatible with -DLAMMPS_BIGBIG. Also the GPU package requires the
lib/gpu library to be compiled with the same setting, or the link will
fail.</p>
<p>The -DLAMMPS_LONGLONG_TO_LONG setting may be needed if your system or
MPI version does not recognize “long long” data types. In this case a
“long” data type is likely already 64-bits, in which case this setting
will convert to that data type.</p>
<p>Using one of the -DPACK_ARRAY, -DPACK_POINTER, and -DPACK_MEMCPY
options can make for faster parallel FFTs (in the PPPM solver) on some
platforms. The -DPACK_ARRAY setting is the default. See the
<a class="reference internal" href="kspace_style.html"><em>kspace_style</em></a> command for info about PPPM. See
Step 6 below for info about building LAMMPS with an FFT library.</p>
<p><strong>Step 5</strong></p>
<p>The 3 MPI variables are used to specify an MPI library to build LAMMPS
with. Note that you do not need to set these if you use the MPI
compiler mpicxx for your CC and LINK setting in the section above.
The MPI wrapper knows where to find the needed files.</p>
<p>If you want LAMMPS to run in parallel, you must have an MPI library
installed on your platform. If MPI is installed on your system in the
usual place (under /usr/local), you also may not need to specify these
3 variables, assuming /usr/local is in your path. On some large
parallel machines which use “modules” for their compile/link
environements, you may simply need to include the correct module in
your build environment, before building LAMMPS. Or the parallel
machine may have a vendor-provided MPI which the compiler has no
trouble finding.</p>
<p>Failing this, these 3 variables can be used to specify where the mpi.h
file (MPI_INC) and the MPI library file (MPI_PATH) are found and the
name of the library file (MPI_LIB).</p>
<p>If you are installing MPI yourself, we recommend Argonne’s MPICH2
or OpenMPI. MPICH can be downloaded from the <a class="reference external" href="http://www.mcs.anl.gov/research/projects/mpich2/">Argonne MPI site</a>. OpenMPI can
be downloaded from the <a class="reference external" href="http://www.open-mpi.org">OpenMPI site</a>.
Other MPI packages should also work. If you are running on a big
parallel platform, your system people or the vendor should have
already installed a version of MPI, which is likely to be faster
than a self-installed MPICH or OpenMPI, so find out how to build
and link with it. If you use MPICH or OpenMPI, you will have to
configure and build it for your platform. The MPI configure script
should have compiler options to enable you to use the same compiler
you are using for the LAMMPS build, which can avoid problems that can
arise when linking LAMMPS to the MPI library.</p>
<p>If you just want to run LAMMPS on a single processor, you can use the
dummy MPI library provided in src/STUBS, since you don’t need a true
MPI library installed on your system. See src/MAKE/Makefile.serial
for how to specify the 3 MPI variables in this case. You will also
need to build the STUBS library for your platform before making LAMMPS
itself. Note that if you are building with src/MAKE/Makefile.serial,
e.g. by typing “make serial”, then the STUBS library is built for you.</p>
<p>To build the STUBS library from the src directory, type “make
mpi-stubs”, or from the src/STUBS dir, type “make”. This should
create a libmpi_stubs.a file suitable for linking to LAMMPS. If the
build fails, you will need to edit the STUBS/Makefile for your
platform.</p>
<p>The file STUBS/mpi.c provides a CPU timer function called MPI_Wtime()
that calls gettimeofday() . If your system doesn’t support
gettimeofday() , you’ll need to insert code to call another timer.
Note that the ANSI-standard function clock() rolls over after an hour
or so, and is therefore insufficient for timing long LAMMPS
simulations.</p>
<p><strong>Step 6</strong></p>
<p>The 3 FFT variables allow you to specify an FFT library which LAMMPS
uses (for performing 1d FFTs) when running the particle-particle
particle-mesh (PPPM) option for long-range Coulombics via the
ACML, and T3E. For backward compatability, using -DFFT_FFTW will use
the FFTW2 library. Using -DFFT_NONE will use the KISS library
described above.</p>
<p>You may also need to set the FFT_INC, FFT_PATH, and FFT_LIB variables,
so the compiler and linker can find the needed FFT header and library
files. Note that on some large parallel machines which use “modules”
for their compile/link environements, you may simply need to include
the correct module in your build environment. Or the parallel machine
may have a vendor-provided FFT library which the compiler has no
trouble finding.</p>
<p>FFTW is a fast, portable library that should also work on any
platform. You can download it from
<a class="reference external" href="http://www.fftw.org">www.fftw.org</a>. Both the legacy version 2.1.X and
the newer 3.X versions are supported as -DFFT_FFTW2 or -DFFT_FFTW3.
Building FFTW for your box should be as simple as ./configure; make.
Note that on some platforms FFTW2 has been pre-installed, and uses
renamed files indicating the precision it was compiled with,
e.g. sfftw.h, or dfftw.h instead of fftw.h. In this case, you can
specify an additional define variable for FFT_INC called -DFFTW_SIZE,
which will select the correct include file. In this case, for FFT_LIB
you must also manually specify the correct library, namely -lsfftw or
-ldfftw.</p>
<p>The FFT_INC variable also allows for a -DFFT_SINGLE setting that will
use single-precision FFTs with PPPM, which can speed-up long-range
calulations, particularly in parallel or on GPUs. Fourier transform
and related PPPM operations are somewhat insensitive to floating point
truncation errors and thus do not always need to be performed in
double precision. Using the -DFFT_SINGLE setting trades off a little
accuracy for reduced memory use and parallel communication costs for
transposing 3d FFT data. Note that single precision FFTs have only
been tested with the FFTW3, FFTW2, MKL, and KISS FFT options.</p>
<p><strong>Step 7</strong></p>
<p>The 3 JPG variables allow you to specify a JPEG and/or PNG library
which LAMMPS uses when writing out JPEG or PNG files via the <a class="reference internal" href="dump_image.html"><em>dump image</em></a> command. These can be left blank if you do not
use the -DLAMMPS_JPEG or -DLAMMPS_PNG switches discussed above in Step
4, since in that case JPEG/PNG output will be disabled.</p>
<p>A standard JPEG library usually goes by the name libjpeg.a or
libjpeg.so and has an associated header file jpeglib.h. Whichever
JPEG library you have on your platform, you’ll need to set the
appropriate JPG_INC, JPG_PATH, and JPG_LIB variables, so that the
compiler and linker can find it.</p>
<p>A standard PNG library usually goes by the name libpng.a or libpng.so
and has an associated header file png.h. Whichever PNG library you
have on your platform, you’ll need to set the appropriate JPG_INC,
JPG_PATH, and JPG_LIB variables, so that the compiler and linker can
find it.</p>
<p>As before, if these header and library files are in the usual place on
your machine, you may not need to set these variables.</p>
<p><strong>Step 8</strong></p>
<p>Note that by default only a few of LAMMPS optional packages are
installed. To build LAMMPS with optional packages, see <a class="reference internal" href="#start-3"><span>this section</span></a> below, before proceeding to Step 9.</p>
<p><strong>Step 9</strong></p>
<p>That’s it. Once you have a correct Makefile.foo, and you have
pre-built any other needed libraries (e.g. MPI, FFT, etc) all you need
to do from the src directory is type something like this:</p>
<p>You can make LAMMPS for multiple platforms from the same src
directory. Each target creates its own object sub-directory called
Obj_target where it stores the system-specific <a href="#id3"><span class="problematic" id="id4">*</span></a>.o files.</p>
<ol class="arabic simple" start="2">
<li>Cleaning up.</li>
</ol>
<p>Typing “make clean-all” or “make clean-machine” will delete <a href="#id5"><span class="problematic" id="id6">*</span></a>.o object
files created when LAMMPS is built, for either all builds or for a
particular machine.</p>
<p>(3) Changing the LAMMPS size limits via -DLAMMPS_SMALLBIG or
-DLAMMPS_BIGBIG or -DLAMMPS_SMALLSMALL</p>
<p>As explained above, any of these 3 settings can be specified on the
LMP_INC line in your low-level src/MAKE/Makefile.foo.</p>
<p>The default is -DLAMMPS_SMALLBIG which allows for systems with up to
2^63 atoms and 2^63 timesteps (about 9e18). The atom limit is for
atomic systems which do not store bond topology info and thus do not
require atom IDs. If you use atom IDs for atomic systems (which is
the default) or if you use a molecular model, which stores bond
topology info and thus requires atom IDs, the limit is 2^31 atoms
(about 2 billion). This is because the IDs are stored in 32-bit
integers.</p>
<p>Likewise, with this setting, the 3 image flags for each atom (see the
<a class="reference internal" href="dump.html"><em>dump</em></a> doc page for a discussion) are stored in a 32-bit
integer, which means the atoms can only wrap around a periodic box (in
each dimension) at most 512 times. If atoms move through the periodic
box more than this many times, the image flags will “roll over”,
e.g. from 511 to -512, which can cause diagnostics like the
mean-squared displacement, as calculated by the <a class="reference internal" href="compute_msd.html"><em>compute msd</em></a> command, to be faulty.</p>
<p>To allow for larger atomic systems with atom IDs or larger molecular
systems or larger image flags, compile with -DLAMMPS_BIGBIG. This
stores atom IDs and image flags in 64-bit integers. This enables
atomic or molecular systems with atom IDS of up to 2^63 atoms (about
9e18). And image flags will not “roll over” until they reach 2^20 =
1048576.</p>
<p>If your system does not support 8-byte integers, you will need to
compile with the -DLAMMPS_SMALLSMALL setting. This will restrict the
total number of atoms (for atomic or molecular systems) and timesteps
to 2^31 (about 2 billion). Image flags will roll over at 2^9 = 512.</p>
<p>Note that in src/lmptype.h there are definitions of all these data
types as well as the MPI data types associated with them. The MPI
types need to be consistent with the associated C data types, or else
LAMMPS will generate a run-time error. As far as we know, the
settings defined in src/lmptype.h are portable and work on every
current system.</p>
<p>In all cases, the size of problem that can be run on a per-processor
basis is limited by 4-byte integer storage to 2^31 atoms per processor
(about 2 billion). This should not normally be a limitation since such
a problem would have a huge per-processor memory footprint due to
neighbor lists and would run very slowly in terms of CPU secs/timestep.</p>
<hr class="docutils" />
<p id="start-2-5"><strong>*Building for a Mac:*</strong></p>
<p>OS X is BSD Unix, so it should just work. See the
src/MAKE/MACHINES/Makefile.mac and Makefile.mac_mpi files.</p>
<hr class="docutils" />
<p id="start-2-6"><strong>*Building for Windows:*</strong></p>
<p>The LAMMPS download page has an option to download both a serial and
parallel pre-built Windows executable. See the <a class="reference internal" href="#start-6"><span>Running LAMMPS</span></a> section for instructions on running these executables
on a Windows box.</p>
<p>The pre-built executables hosted on the <a class="reference external" href="http://lammps.sandia.gov/download.html">LAMMPS download page</a> are built with a subset
of the available packages; see the download page for the list. These
are single executable files. No examples or documentation in
included. You will need to download the full source code package to
obtain those.</p>
<p>As an alternative, you can download “daily builds” (and some older
<span id="start-3"></span><h2>2.3. Making LAMMPS with optional packages<a class="headerlink" href="#making-lammps-with-optional-packages" title="Permalink to this headline">¶</a></h2>
<p>This section has the following sub-sections:</p>
<p>to run your executable with the optional <a class="reference internal" href="#start-7"><span>-h command-line switch</span></a> for “help”, which will list the styles and commands
known to your executable.</p>
<p>There are two kinds of packages in LAMMPS, standard and user packages.
More information about the contents of standard and user packages is
given in <a class="reference internal" href="Section_packages.html"><em>Section_packages</em></a> of the manual. The
difference between standard and user packages is as follows:</p>
<p>Standard packages are supported by the LAMMPS developers and are
written in a syntax and style consistent with the rest of LAMMPS.
This means we will answer questions about them, debug and fix them if
necessary, and keep them compatible with future changes to LAMMPS.</p>
<p>User packages have been contributed by users, and always begin with
the user prefix. If they are a single command (single file), they are
typically in the user-misc package. Otherwise, they are a a set of
files grouped together which add a specific functionality to the code.</p>
<p>User packages don’t necessarily meet the requirements of the standard
packages. If you have problems using a feature provided in a user
package, you will likely need to contact the contributor directly to
get help. Information on how to submit additions you make to LAMMPS
as a user-contributed package is given in <a class="reference internal" href="Section_modify.html#mod-15"><span>this section</span></a> of the documentation.</p>
<p>Some packages (both standard and user) require additional libraries.
<p>Here is a brief summary of what Makefile.machine changes are needed.
Note that the Make.py tool, described in the next <a class="reference internal" href="#start-4"><span>Section 2.4</span></a> can automatically add the needed info to an existing
machine Makefile, using simple command-line arguments.</p>
<p>In src/MAKE/OPTIONS see the following Makefiles for examples of the
changes described below:</p>
<ul class="simple">
<li>Makefile.intel_cpu</li>
<li>Makefile.intel_phi</li>
<li>Makefile.kokkos_omp</li>
<li>Makefile.kokkos_cuda</li>
<li>Makefile.kokkos_phi</li>
<li>Makefile.omp</li>
</ul>
<p>For the USER-INTEL package, you have 2 choices when building. You can
build with CPU or Phi support. The latter uses Xeon Phi chips in
“offload” mode. Each of these modes requires additional settings in
your Makefile.machine for CCFLAGS and LINKFLAGS.</p>
<span id="start-4"></span><h2>2.4. Building LAMMPS via the Make.py script<a class="headerlink" href="#building-lammps-via-the-make-py-script" title="Permalink to this headline">¶</a></h2>
<p>The src directory includes a Make.py script, written in Python, which
can be used to automate various steps of the build process. It is
particularly useful for working with the accelerator packages, as well
as other packages which require auxiliary libraries to be built.</p>
<p>The goal of the Make.py tool is to allow any complex multi-step LAMMPS
build to be performed as a single Make.py command. And you can
archive the commands, so they can be re-invoked later via the -r
(redo) switch. If you find some LAMMPS build procedure that can’t be
done in a single Make.py command, let the developers know, and we’ll
see if we can augment the tool.</p>
<p>You can run Make.py from the src directory by typing either:</p>
<span id="start-5"></span><h2>2.5. Building LAMMPS as a library<a class="headerlink" href="#building-lammps-as-a-library" title="Permalink to this headline">¶</a></h2>
<p>LAMMPS can be built as either a static or shared library, which can
then be called from another application or a scripting language. See
<a class="reference internal" href="Section_howto.html#howto-10"><span>this section</span></a> for more info on coupling
LAMMPS to other codes. See <a class="reference internal" href="Section_python.html"><em>this section</em></a> for
more info on wrapping and running LAMMPS from Python.</p>
<div class="section" id="static-library">
<h3>2.5.1. <strong>Static library:</strong><a class="headerlink" href="#static-library" title="Permalink to this headline">¶</a></h3>
<p>To build LAMMPS as a static library (<a href="#id7"><span class="problematic" id="id8">*</span></a>.a file on Linux), type</p>
relocation R_X86_64_32 against `__pthread_key_create' can not be used
when making a shared object; recompile with -fPIC
../../lib/colvars/libcolvars.a: error adding symbols: Bad value
</pre></div>
</div>
<p>As an example, here is how to build and install the <a class="reference external" href="http://www-unix.mcs.anl.gov/mpi">MPICH library</a>, a popular open-source version of MPI, distributed by
Argonne National Labs, as a shared library in the default
<h3>2.5.3. <strong>Additional requirement for using a shared library:</strong><a class="headerlink" href="#additional-requirement-for-using-a-shared-library" title="Permalink to this headline">¶</a></h3>
<p>The operating system finds shared libraries to load at run-time using
the environment variable LD_LIBRARY_PATH. So you may wish to copy the
file src/liblammps.so or src/liblammps_g++.so (for example) to a place
the system can find it by default, such as /usr/local/lib, or you may
wish to add the LAMMPS src directory to LD_LIBRARY_PATH, so that the
current version of the shared library is always available to programs
that use it.</p>
<p>For the csh or tcsh shells, you would add something like this to your
<h3>2.5.4. <strong>Calling the LAMMPS library:</strong><a class="headerlink" href="#calling-the-lammps-library" title="Permalink to this headline">¶</a></h3>
<p>Either flavor of library (static or shared) allows one or more LAMMPS
objects to be instantiated from the calling program.</p>
<p>When used from a C++ program, all of LAMMPS is wrapped in a LAMMPS_NS
namespace; you can safely use any of its classes and methods from
within the calling code, as needed.</p>
<p>When used from a C or Fortran program or a scripting language like
Python, the library has a simple function-style interface, provided in
src/library.cpp and src/library.h.</p>
<p>See the sample codes in examples/COUPLE/simple for examples of C++ and
C and Fortran codes that invoke LAMMPS thru its library interface.
There are other examples as well in the COUPLE directory which are
discussed in <a class="reference internal" href="Section_howto.html#howto-10"><span>Section_howto 10</span></a> of the
manual. See <a class="reference internal" href="Section_python.html"><em>Section_python</em></a> of the manual for a
description of the Python wrapper provided with LAMMPS that operates
through the LAMMPS library interface.</p>
<p>The files src/library.cpp and library.h define the C-style API for
using LAMMPS as a library. See <a class="reference internal" href="Section_howto.html#howto-19"><span>Section_howto 19</span></a> of the manual for a description of the
interface and how to extend it for your needs.</p>
<hr class="docutils" />
</div>
</div>
<div class="section" id="running-lammps">
<span id="start-6"></span><h2>2.6. Running LAMMPS<a class="headerlink" href="#running-lammps" title="Permalink to this headline">¶</a></h2>
<p>By default, LAMMPS runs by reading commands from standard input. Thus
if you run the LAMMPS executable by itself, e.g.</p>
<li>You’ll need to use the mpiexec.exe and smpd.exe files from the MPICH2
package. Put them in same directory (or path) as the LAMMPS Windows
executable.</li>
<li>Get a command prompt by going to Start->Run... ,
then typing “cmd”.</li>
<li>Move to the directory where you have saved lmp_win_mpi.exe
(e.g. by typing: cd “Documents”).</li>
<li>Then type something like this: “mpiexec -localonly 4 lmp_win_mpi -in
in.lj”, replacing in.lj with the name of your LAMMPS input script.</li>
<li>Note that you may need to provide smpd with a passphrase (it doesn’t
matter what you type).</li>
<li>In this mode, output may not immediately show up on the screen, so if
your input script takes a long time to execute, you may need to be
patient before the output shows up. :l Alternatively, you can still
use this executable to run on a single processor by typing something
like: “lmp_win_mpi -in in.lj”.</li>
</ul>
<hr class="docutils" />
<p>The screen output from LAMMPS is described in the next section. As it
runs, LAMMPS also writes a log.lammps file with the same information.</p>
<p>Note that this sequence of commands copies the LAMMPS executable
(lmp_linux) to the directory with the input files. This may not be
necessary, but some versions of MPI reset the working directory to
where the executable is, rather than leave it as the directory where
you launch mpirun from (if you launch lmp_linux on its own and not
under mpirun). If that happens, LAMMPS will look for additional input
files and write its output files to the executable directory, rather
than your working directory, which is probably not what you want.</p>
<p>If LAMMPS encounters errors in the input script or while running a
simulation it will print an ERROR message and stop or a WARNING
message and continue. See <a class="reference internal" href="Section_errors.html"><em>Section_errors</em></a> for a
discussion of the various kinds of errors LAMMPS can or can’t detect,
a list of all ERROR and WARNING messages, and what to do about them.</p>
<p>LAMMPS can run a problem on any number of processors, including a
single processor. In theory you should get identical answers on any
number of processors and on any machine. In practice, numerical
round-off can cause slight differences and eventual divergence of
molecular dynamics phase space trajectories.</p>
<p>LAMMPS can run as large a problem as will fit in the physical memory
of one or more processors. If you run out of memory, you must run on
more processors or setup a smaller problem.</p>
<hr class="docutils" />
</div>
<div class="section" id="command-line-options">
<span id="start-7"></span><h2>2.7. Command-line options<a class="headerlink" href="#command-line-options" title="Permalink to this headline">¶</a></h2>
<p>At run time, LAMMPS recognizes several optional command-line switches
which may be used in any order. Either the full word or a one-or-two
letter abbreviation can be used:</p>
<ul class="simple">
<li>-c or -cuda</li>
<li>-e or -echo</li>
<li>-h or -help</li>
<li>-i or -in</li>
<li>-k or -kokkos</li>
<li>-l or -log</li>
<li>-nc or -nocite</li>
<li>-pk or -package</li>
<li>-p or -partition</li>
<li>-pl or -plog</li>
<li>-ps or -pscreen</li>
<li>-r or -restart</li>
<li>-ro or -reorder</li>
<li>-sc or -screen</li>
<li>-sf or -suffix</li>
<li>-v or -var</li>
</ul>
<p>For example, lmp_ibm might be launched as follows:</p>
<p>Use variants of various styles if they exist. The specified style can
be <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em>. These refer to
optional packages that LAMMPS can be built with, as described above in
<a class="reference internal" href="#start-3"><span>Section 2.3</span></a>. The “cuda” style corresponds to the USER-CUDA
package, the “gpu” style to the GPU package, the “intel” style to the
USER-INTEL package, the “kk” style to the KOKKOS package, the “opt”
style to the OPT package, and the “omp” style to the USER-OMP package.</p>
<p>Along with the “-package” command-line switch, this is a convenient
mechanism for invoking accelerator packages and their options without
having to edit an input script.</p>
<p>As an example, all of the packages provide a <a class="reference internal" href="pair_lj.html"><em>pair_style lj/cut</em></a> variant, with style names lj/cut/cuda,
lj/cut/gpu, lj/cut/intel, lj/cut/kk, lj/cut/omp, and lj/cut/opt. A
variant style can be specified explicitly in your input script,
e.g. pair_style lj/cut/gpu. If the -suffix switch is used the
specified suffix (cuda,gpu,intel,kk,omp,opt) is automatically appended
<a class="reference internal" href="compute.html"><em>compute</em></a>, or <a class="reference internal" href="run_style.html"><em>run</em></a> style. If the variant
version does not exist, the standard version is created.</p>
<p>For the GPU package, using this command-line switch also invokes the
default GPU settings, as if the command “package gpu 1” were used at
the top of your input script. These settings can be changed by using
the “-package gpu” command-line switch or the <a class="reference internal" href="package.html"><em>package gpu</em></a> command in your script.</p>
<p>For the USER-INTEL package, using this command-line switch also
invokes the default USER-INTEL settings, as if the command “package
intel 1” were used at the top of your input script. These settings
can be changed by using the “-package intel” command-line switch or
the <a class="reference internal" href="package.html"><em>package intel</em></a> command in your script. If the
USER-OMP package is also installed, the intel suffix will make the omp
suffix a second choice, if a requested style is not available in the
USER-INTEL package. It will also invoke the default USER-OMP
settings, as if the command “package omp 0” were used at the top of
your input script. These settings can be changed by using the
“-package omp” command-line switch or the <a class="reference internal" href="package.html"><em>package omp</em></a>
command in your script.</p>
<p>For the KOKKOS package, using this command-line switch also invokes
the default KOKKOS settings, as if the command “package kokkos” were
used at the top of your input script. These settings can be changed
by using the “-package kokkos” command-line switch or the <a class="reference internal" href="package.html"><em>package kokkos</em></a> command in your script.</p>
<p>For the OMP package, using this command-line switch also invokes the
default OMP settings, as if the command “package omp 0” were used at
the top of your input script. These settings can be changed by using
the “-package omp” command-line switch or the <a class="reference internal" href="package.html"><em>package omp</em></a> command in your script.</p>
<p>The <a class="reference internal" href="suffix.html"><em>suffix</em></a> command can also be used within an input
script to set a suffix, or to turn off or back on any suffix setting
made via the command line.</p>
<div class="highlight-python"><div class="highlight"><pre>-var name value1 value2 ...
</pre></div>
</div>
<p>Specify a variable that will be defined for substitution purposes when
the input script is read. This switch can be used multiple times to
define multiple variables. “Name” is the variable name which can be a
single character (referenced as $x in the input script) or a full
string (referenced as ${abc}). An <a class="reference internal" href="variable.html"><em>index-style variable</em></a> will be created and populated with the
subsequent values, e.g. a set of filenames. Using this command-line
option is equivalent to putting the line “variable name index value1
value2 ...” at the beginning of the input script. Defining an index
variable as a command-line argument overrides any setting for the same
index variable in the input script, since index variables cannot be
re-defined. See the <a class="reference internal" href="variable.html"><em>variable</em></a> command for more info on
defining index and other kinds of variables and <a class="reference internal" href="Section_commands.html#cmd-2"><span>this section</span></a> for more info on using variables
in input scripts.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Currently, the command-line parser looks for arguments that
start with “-” to indicate new switches. Thus you cannot specify
multiple variable values if any of they start with a “-”, e.g. a
negative numeric value. It is OK if the first value1 starts with a
“-”, since it is automatically skipped.</p>
</div>
<hr class="docutils" />
</div>
<div class="section" id="lammps-screen-output">
<span id="start-8"></span><h2>2.8. LAMMPS screen output<a class="headerlink" href="#lammps-screen-output" title="Permalink to this headline">¶</a></h2>
<p>As LAMMPS reads an input script, it prints information to both the
screen and a log file about significant actions it takes to setup a
simulation. When the simulation is ready to begin, LAMMPS performs
various initializations and prints the amount of memory (in MBytes per
processor) that the simulation requires. It also prints details of
the initial thermodynamic state of the system. During the run itself,
thermodynamic information is printed periodically, every few
timesteps. When the run concludes, LAMMPS prints the final
thermodynamic state and a total run time for the simulation. It then
appends statistics about the CPU time and storage requirements for the
simulation. An example set of statistics is shown here:</p>
<div class="highlight-python"><div class="highlight"><pre>Loop time of 49.002 on 2 procs for 2004 atoms
</pre></div>
</div>
<div class="highlight-python"><div class="highlight"><pre>Pair time (%) = 35.0495 (71.5267)
Bond time (%) = 0.092046 (0.187841)
Kspce time (%) = 6.42073 (13.103)
Neigh time (%) = 2.73485 (5.5811)
Comm time (%) = 1.50291 (3.06703)
Outpt time (%) = 0.013799 (0.0281601)
Other time (%) = 2.13669 (4.36041)
</pre></div>
</div>
<div class="highlight-python"><div class="highlight"><pre>Nlocal: 1002 ave, 1015 max, 989 min
Histogram: 1 0 0 0 0 0 0 0 0 1
Nghost: 8720 ave, 8724 max, 8716 min
Histogram: 1 0 0 0 0 0 0 0 0 1
Neighs: 354141 ave, 361422 max, 346860 min
Histogram: 1 0 0 0 0 0 0 0 0 1
</pre></div>
</div>
<div class="highlight-python"><div class="highlight"><pre>Total # of neighbors = 708282
Ave neighs/atom = 353.434
Ave special neighs/atom = 2.34032
Number of reneighborings = 42
Dangerous reneighborings = 2
</pre></div>
</div>
<p>The first section gives the breakdown of the CPU run time (in seconds)
into major categories. The second section lists the number of owned
atoms (Nlocal), ghost atoms (Nghost), and pair-wise neighbors stored
per processor. The max and min values give the spread of these values
across processors with a 10-bin histogram showing the distribution.
The total number of histogram counts is equal to the number of
processors.</p>
<p>The last section gives aggregate statistics for pair-wise neighbors
and special neighbors that LAMMPS keeps track of (see the
<a class="reference internal" href="special_bonds.html"><em>special_bonds</em></a> command). The number of times
neighbor lists were rebuilt during the run is given as well as the
number of potentially “dangerous” rebuilds. If atom movement
triggered neighbor list rebuilding (see the
<a class="reference internal" href="neigh_modify.html"><em>neigh_modify</em></a> command), then dangerous
reneighborings are those that were triggered on the first timestep
atom movement was checked for. If this count is non-zero you may wish
to reduce the delay factor to insure no force interactions are missed
by atoms moving beyond the neighbor skin distance before a rebuild
takes place.</p>
<p>If an energy minimization was performed via the
<a class="reference internal" href="minimize.html"><em>minimize</em></a> command, additional information is printed,
<span id="start-9"></span><h2>2.9. Tips for users of previous LAMMPS versions<a class="headerlink" href="#tips-for-users-of-previous-lammps-versions" title="Permalink to this headline">¶</a></h2>
<p>The current C++ began with a complete rewrite of LAMMPS 2001, which
was written in F90. Features of earlier versions of LAMMPS are listed
in <a class="reference internal" href="Section_history.html"><em>Section_history</em></a>. The F90 and F77 versions
(2001 and 99) are also freely distributed as open-source codes; check
the <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW Site</a> for distribution information if you prefer
those versions. The 99 and 2001 versions are no longer under active
development; they do not have all the features of C++ LAMMPS.</p>
<p>If you are a previous user of LAMMPS 2001, these are the most
significant changes you will notice in C++ LAMMPS:</p>
<p>(1) The names and arguments of many input script commands have
changed. All commands are now a single word (e.g. read_data instead
of read data).</p>
<p>(2) All the functionality of LAMMPS 2001 is included in C++ LAMMPS,
but you may need to specify the relevant commands in different ways.</p>
<p>(3) The format of the data file can be streamlined for some problems.
See the <a class="reference internal" href="read_data.html"><em>read_data</em></a> command for details. The data file
section “Nonbond Coeff” has been renamed to “Pair Coeff” in C++ LAMMPS.</p>
<p>(4) Binary restart files written by LAMMPS 2001 cannot be read by C++
LAMMPS with a <a class="reference internal" href="read_restart.html"><em>read_restart</em></a> command. This is
because they were output by F90 which writes in a different binary
format than C or C++ writes or reads. Use the <em>restart2data</em> tool
provided with LAMMPS 2001 to convert the 2001 restart file to a text
data file. Then edit the data file as necessary before using the C++
LAMMPS <a class="reference internal" href="read_data.html"><em>read_data</em></a> command to read it in.</p>
<p>(5) There are numerous small numerical changes in C++ LAMMPS that mean
you will not get identical answers when comparing to a 2001 run.
However, your initial thermodynamic energy and MD trajectory should be
close if you have setup the problem for both codes the same.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<TR><TD >Build specific auxiliary libs</TD><TD > Make.py -a lib-atc lib-meam</TD></TR>
<TR><TD >Build libs for all installed packages</TD><TD > Make.py -p cuda gpu -gpu mode=double arch=31 -a lib-all</TD></TR>
<TR><TD >Create a Makefile from scratch with compiler and MPI settings</TD><TD > Make.py -m none -cc g++ -mpi mpich -a file</TD></TR>
<TR><TD >Augment Makefile.serial with settings for installed packages</TD><TD > Make.py -p intel -intel cpu -m serial -a file</TD></TR>
<TR><TD >Add JPG and FFTW support to Makefile.mpi</TD><TD > Make.py -m mpi -jpg -fft fftw -a file</TD></TR>
<TR><TD >Build LAMMPS with a parallel make using Makefile.mpi</TD><TD > Make.py -j 16 -m mpi -a exe</TD></TR>
<TR><TD >Build LAMMPS and libs it needs using Makefile.serial with accelerator settings</TD><TD > Make.py -p gpu intel -intel cpu -a lib-all file serial
</TD></TR></TABLE></DIV>
<P>The bench and examples directories give Make.py commands that can be
used to build LAMMPS with the various packages and options needed to
run all the benchmark and example input scripts. See these files for
more details:
</P>
<UL><LI>bench/README
<LI>bench/FERMI/README
<LI>bench/KEPLER/README
<LI>bench/PHI/README
<LI>examples/README
<LI>examples/accelerate/README
<LI>examples/accelerate/make.list
</UL>
<P>All of the Make.py options and syntax help can be accessed by using
the "-h" switch.
</P>
<P>E.g. typing "Make.py -h" gives
</P>
<PRE>Syntax: Make.py switch args ...
switches can be listed in any order
help switch:
-h prints help and syntax for all other specified switches
switch for actions:
-a lib-all, lib-dir, clean, file, exe or machine
list one or more actions, in any order
machine is a Makefile.machine suffix, must be last if used
<LI>group-ID = ID of the group of atoms to be dumped
-<LI>style = <I>atom</I> or <I>atom/mpiio</I> or <I>cfg</I> or <I>cfg/mpiio</I> or <I>dcd</I> or <I>xtc</I> or <I>xyz</I> or <I>xyz/mpiio</I> or <I>image</I> or <I>movie</I> or <I>molfile</I> or <I>local</I> or <I>custom</I> or <I>custom/mpiio</I>
+<LI>style = <I>atom</I> or <I>atom/gz</I> or <I>atom/mpiio</I> or <I>cfg</I> or <I>cfg/gz</I> or <I>cfg/mpiio</I> or <I>dcd</I> or <I>xtc</I> or <I>xyz</I> or <I>xyz/gz</I> or <I>xyz/mpiio</I> or <I>h5md</I> or <I>image</I> or <I>movie</I> or <I>molfile</I> or <I>local</I> or <I>custom</I> or <I>custom/gz</I> or <I>custom/mpiio</I>
<LI>N = dump every this many timesteps
<LI>file = name of file to write dump info to
<LI>args = list of arguments for a particular style
<PRE> <I>atom</I> args = none
+ <I>atom/gz</I> args = none
<I>atom/mpiio</I> args = none
<I>cfg</I> args = same as <I>custom</I> args, see below
+ <I>cfg/gz</I> args = same as <I>custom</I> args, see below
<I>cfg/mpiio</I> args = same as <I>custom</I> args, see below
+<LI>group-ID = ID of the group of atoms to be imaged
+
+<LI>h5md = style of dump command (other styles <I>atom</I> or <I>cfg</I> or <I>dcd</I> or <I>xtc</I> or <I>xyz</I> or <I>local</I> or <I>custom</I> are discussed on the <A HREF = "dump.html">dump</A> doc page)
+
+<LI>N = dump every this many timesteps
+
+<LI>file.h5 = name of file to write to
+
+<LI>args = list of data elements to dump, with their dump "subintervals".
+At least one element must be given and image may only be present if
+position is specified first.
+
+<PRE> position options
+ image
+ velocity options
+ force options
+ species options
+ file_from ID: do not open a new file, re-use the already opened file from dump ID
+ box value = <I>yes</I> or <I>no</I>
+ create_group value = <I>yes</I> or <I>no</I>
+ author value = quoted string
+</PRE>
+<P>For the elements <I>position</I>, <I>velocity</I>, <I>force</I> and <I>species</I>, one
+may specify a sub-interval to write the data only every N_element
+iterations of the dump (i.e. every N*N_element time steps). This is
+specified by the option
+</P>
+<PRE> every N_element
+</PRE>
+<P>that follows directly the element declaration.
+</P>
+
+</UL>
+<P><B>Examples:</B>
+</P>
+<PRE>dump h5md1 all h5md 100 dump_h5md.h5 position image
+dump h5md1 all h5md 100 dump_h5md.h5 position velocity every 10
+dump h5md1 all h5md 100 dump_h5md.h5 velocity author "John Doe"
+</PRE>
+<P><B>Description:</B>
+</P>
+<P>Dump a snapshot of atom coordinates every N timesteps in the
+<A HREF = "http://www.hdfgroup.org/HDF5/">HDF5</A> based <A HREF = "http://nongnu.org/h5md/">H5MD</A> file format <A HREF = "#h5md_cpc">(de Buyl)</A>.
+HDF5 files are binary, portable and self-describing. This dump style
+will write only one file, on the root node.
+</P>
+<P>Several dumps may write to the same file, by using file_from and
+referring to a previously defined dump. Several groups may also be
+stored within the same file by defining several dumps. A dump that
+refers (via <I>file_from</I>) to an already open dump ID and that concerns
+another particle group must specify <I>create_group yes</I>.
+</P>
+
+
+<P>Each data element is written every N*N_element steps. For <I>image</I>, no
+subinterval is needed as it must be present at the same interval as
+<I>position</I>. <I>image</I> must be given after <I>position</I> in any case. The
+box information (edges in each dimension) is stored at the same
+interval than the <I>position</I> element, if present. Else it is stored
+every N steps.
+</P>
+<P>IMPORTANT NOTE: Because periodic boundary conditions are enforced only
+on timesteps when neighbor lists are rebuilt, the coordinates of an
+atom written to a dump file may be slightly outside the simulation
+box.
+</P>
+<P><B>Use from write_dump:</B>
+</P>
+<P>It is possible to use this dump style with the
+<A HREF = "write_dump.html">write_dump</A> command. In this case, the subintervals
+must not be set at all. The write_dump command can be used either to
+create a new file or to add current data to an existing dump file by
+using the <I>file_from</I> keyword.
+</P>
+<P>Typically, the <I>species</I> data is fixed. The following two commands
+store the position data every 100 timesteps, with the image data, and
+store once the species data in the same file.
+</P>
+<PRE>dump h5md1 all h5md 100 dump.h5 position image
+write_dump all h5md dump.h5 file_from h5md1 species
+</PRE>
+<HR>
+
+<P><B>Restrictions:</B>
+</P>
+<P>The number of atoms per snapshot cannot change with the h5md style.
+The position data is stored wrapped (box boundaries not enforced, see
+note above). Only orthogonal domains are currently supported. This is
+a limitation of the present dump h5md command and not of H5MD itself.
+</P>
+<P>The <I>h5md</I> dump style is part of the USER-H5MD package. It is only
+enabled if LAMMPS was built with that package. See the <A HREF = "Section_start.html#start_3">Making
+LAMMPS</A> section for more info. It also
+requires (i) building the ch5md library provided with LAMMPS (See the
+<A HREF = "Section_start.html#start_3">Making LAMMPS</A> section for more info.) and
+(ii) having the <A HREF = "http://www.hdfgroup.org/HDF5/">HDF5</A> library installed (C bindings are
+sufficient) on your system. The library ch5md is compiled with the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<span id="index-0"></span><h1>dump command<a class="headerlink" href="#dump-command" title="Permalink to this headline">¶</a></h1>
</div>
+<div class="section" id="dump-h5md-command">
+<h1><a class="reference internal" href="dump_h5md.html"><em>dump h5md</em></a> command<a class="headerlink" href="#dump-h5md-command" title="Permalink to this headline">¶</a></h1>
+</div>
<div class="section" id="dump-image-command">
<h1><a class="reference internal" href="dump_image.html"><em>dump image</em></a> command<a class="headerlink" href="#dump-image-command" title="Permalink to this headline">¶</a></h1>
</div>
<div class="section" id="dump-movie-command">
<h1><a class="reference internal" href="dump_image.html"><em>dump movie</em></a> command<a class="headerlink" href="#dump-movie-command" title="Permalink to this headline">¶</a></h1>
</div>
<div class="section" id="dump-molfile-command">
<h1><a class="reference internal" href="dump_molfile.html"><em>dump molfile</em></a> command<a class="headerlink" href="#dump-molfile-command" title="Permalink to this headline">¶</a></h1>
<div class="section" id="syntax">
<h2>Syntax<a class="headerlink" href="#syntax" title="Permalink to this headline">¶</a></h2>
<div class="highlight-python"><div class="highlight"><pre>dump ID group-ID style N file args
</pre></div>
</div>
<ul class="simple">
<li>ID = user-assigned name for the dump</li>
<li>group-ID = ID of the group of atoms to be dumped</li>
-<li>style = <em>atom</em> or <em>atom/mpiio</em> or <em>cfg</em> or <em>cfg/mpiio</em> or <em>dcd</em> or <em>xtc</em> or <em>xyz</em> or <em>xyz/mpiio</em> or <em>image</em> or <em>movie</em> or <em>molfile</em> or <em>local</em> or <em>custom</em> or <em>custom/mpiio</em></li>
+<li>style = <em>atom</em> or <em>atom/gz</em> or <em>atom/mpiio</em> or <em>cfg</em> or <em>cfg/gz</em> or <em>cfg/mpiio</em> or <em>dcd</em> or <em>xtc</em> or <em>xyz</em> or <em>xyz/gz</em> or <em>xyz/mpiio</em> or <em>h5md</em> or <em>image</em> or <em>movie</em> or <em>molfile</em> or <em>local</em> or <em>custom</em> or <em>custom/gz</em> or <em>custom/mpiio</em></li>
<li>N = dump every this many timesteps</li>
<li>file = name of file to write dump info to</li>
<li>args = list of arguments for a particular style</li>
</ul>
<pre class="literal-block">
<em>atom</em> args = none
+<em>atom/gz</em> args = none
<em>atom/mpiio</em> args = none
<em>cfg</em> args = same as <em>custom</em> args, see below
+<em>cfg/gz</em> args = same as <em>custom</em> args, see below
<em>cfg/mpiio</em> args = same as <em>custom</em> args, see below
possible attributes = index, c_ID, c_ID[N], f_ID, f_ID[N]
index = enumeration of local values
c_ID = local vector calculated by a compute with ID
c_ID[N] = Nth column of local array calculated by a compute with ID
f_ID = local vector calculated by a fix with ID
f_ID[N] = Nth column of local array calculated by a fix with ID
</pre>
<pre class="literal-block">
-<em>custom</em> or <em>custom/mpiio</em> args = list of atom attributes
+<em>custom</em> or <em>custom/gz</em> or <em>custom/mpiio</em> args = list of atom attributes
possible attributes = id, mol, proc, procp1, type, element, mass,
x, y, z, xs, ys, zs, xu, yu, zu,
xsu, ysu, zsu, ix, iy, iz,
vx, vy, vz, fx, fy, fz,
q, mux, muy, muz, mu,
radius, diameter, omegax, omegay, omegaz,
angmomx, angmomy, angmomz, tqx, tqy, tqz,
c_ID, c_ID[N], f_ID, f_ID[N], v_name
</pre>
<pre class="literal-block">
id = atom ID
mol = molecule ID
proc = ID of processor that owns atom
procp1 = ID+1 of processor that owns atom
type = atom type
element = name of atom element, as defined by <a class="reference internal" href="dump_modify.html"><em>dump_modify</em></a> command
mass = atom mass
x,y,z = unscaled atom coordinates
xs,ys,zs = scaled atom coordinates
xu,yu,zu = unwrapped atom coordinates
xsu,ysu,zsu = scaled unwrapped atom coordinates
ix,iy,iz = box image that the atom is in
vx,vy,vz = atom velocities
fx,fy,fz = forces on atoms
q = atom charge
mux,muy,muz = orientation of dipole moment of atom
mu = magnitude of dipole moment of atom
radius,diameter = radius,diameter of spherical particle
omegax,omegay,omegaz = angular velocity of spherical particle
angmomx,angmomy,angmomz = angular momentum of aspherical particle
tqx,tqy,tqz = torque on finite-size particles
c_ID = per-atom vector calculated by a compute with ID
c_ID[N] = Nth column of per-atom array calculated by a compute with ID
f_ID = per-atom vector calculated by a fix with ID
f_ID[N] = Nth column of per-atom array calculated by a fix with ID
v_name = per-atom vector calculated by an atom-style variable with name
d_name = per-atom floating point vector with name, managed by fix property/atom
i_name = per-atom integer vector with name, managed by fix property/atom
</pre>
</div>
<div class="section" id="examples">
<h2>Examples<a class="headerlink" href="#examples" title="Permalink to this headline">¶</a></h2>
<div class="highlight-python"><div class="highlight"><pre>dump myDump all atom 100 dump.atom
dump myDump all atom/mpiio 100 dump.atom.mpiio
+dump myDump all atom/gz 100 dump.atom.gz
dump 2 subgroup atom 50 dump.run.bin
dump 2 subgroup atom 50 dump.run.mpiio.bin
dump 4a all custom 100 dump.myforce.* id type x y vx fx
dump 4b flow custom 100 dump.%.myforce id type c_myF[3] v_ke
dump 2 inner cfg 10 dump.snap.*.cfg mass type xs ys zs vx vy vz
dump snap all cfg 100 dump.config.*.cfg mass type xs ys zs id type c_Stress[2]
dump 1 all xtc 1000 file.xtc
</pre></div>
</div>
</div>
<div class="section" id="description">
<h2>Description<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
<p>Dump a snapshot of atom quantities to one or more files every N
timesteps in one of several styles. The <em>image</em> and <em>movie</em> styles are
the exception: the <em>image</em> style renders a JPG, PNG, or PPM image file
of the atom configuration every N timesteps while the <em>movie</em> style
combines and compresses them into a movie file; both are discussed in
detail on the <a class="reference internal" href="dump_image.html"><em>dump image</em></a> doc page. The timesteps on
which dump output is written can also be controlled by a variable.
See the <a class="reference internal" href="dump_modify.html"><em>dump_modify every</em></a> command.</p>
<p>Only information for atoms in the specified group is dumped. The
<a class="reference internal" href="dump_modify.html"><em>dump_modify thresh and region</em></a> commands can also
alter what atoms are included. Not all styles support all these
options; see details below.</p>
<p>As described below, the filename determines the kind of output (text
or binary or gzipped, one big file or one per timestep, one big file
or multiple smaller files).</p>
<div class="admonition warning">
<p class="first admonition-title">Warning</p>
<p class="last">Because periodic boundary conditions are enforced only
on timesteps when neighbor lists are rebuilt, the coordinates of an
atom written to a dump file may be slightly outside the simulation
box.</p>
</div>
<div class="admonition warning">
<p class="first admonition-title">Warning</p>
<p class="last">Unless the <a class="reference internal" href="dump_modify.html"><em>dump_modify sort</em></a> option
is invoked, the lines of atom information written to dump files
(typically one line per atom) will be in an indeterminate order for
each snapshot. This is even true when running on a single processor,
if the <a class="reference internal" href="atom_modify.html"><em>atom_modify sort</em></a> option is on, which it is
by default. In this case atoms are re-ordered periodically during a
simulation, due to spatial sorting. It is also true when running in
parallel, because data for a single snapshot is collected from
multiple processors, each of which owns a subset of the atoms.</p>
</div>
<p>For the <em>atom</em>, <em>custom</em>, <em>cfg</em>, and <em>local</em> styles, sorting is off by
default. For the <em>dcd</em>, <em>xtc</em>, <em>xyz</em>, and <em>molfile</em> styles, sorting by
atom ID is on by default. See the <a class="reference internal" href="dump_modify.html"><em>dump_modify</em></a> doc
page for details.</p>
+<p>The <em>atom/gz</em>, <em>cfg/gz</em>, <em>custom/gz</em>, and <em>xyz/gz</em> styles are identical
+in command syntax to the corresponding styles without “gz”, however,
+they generate compressed files using the zlib library. Thus the filename
+suffix ”.gz” is mandatory. This is an alternative approach to writing
+compressed files via a pipe, as done by the regular dump styles, which
+may be required on clusters where the interface to the high-speed network
+disallows using the fork() library call (which is needed for a pipe).
+For the remainder of this doc page, you should thus consider the <em>atom</em>
+and <em>atom/gz</em> styles (etc) to be inter-changeable, with the exception
+of the required filename suffix.</p>
<p>As explained below, the <em>atom/mpiio</em>, <em>cfg/mpiio</em>, <em>custom/mpiio</em>, and
<em>xyz/mpiio</em> styles are identical in command syntax and in the format
of the dump files they create, to the corresponding styles without
“mpiio”, except the single dump file they produce is written in
parallel via the MPI-IO library. For the remainder of this doc page,
you should thus consider the <em>atom</em> and <em>atom/mpiio</em> styles (etc) to
be inter-changeable. The one exception is how the filename is
specified for the MPI-IO styles, as explained below.</p>
<hr class="docutils" />
<p>The <em>style</em> keyword determines what atom quantities are written to the
file and in what format. Settings made via the
<a class="reference internal" href="dump_modify.html"><em>dump_modify</em></a> command can also alter the format of
individual values and the file itself.</p>
<p>The <em>atom</em>, <em>local</em>, and <em>custom</em> styles create files in a simple text
format that is self-explanatory when viewing a dump file. Many of the
LAMMPS <a class="reference internal" href="Section_tools.html"><em>post-processing tools</em></a>, including
<a class="reference external" href="http://www.sandia.gov/~sjplimp/pizza.html">Pizza.py</a>, work with this
format, as does the <a class="reference internal" href="rerun.html"><em>rerun</em></a> command.</p>
<p>For post-processing purposes the <em>atom</em>, <em>local</em>, and <em>custom</em> text
files are self-describing in the following sense.</p>
<p>The dimensions of the simulation box are included in each snapshot.
For an orthogonal simulation box this information is is formatted as:</p>
<div class="highlight-python"><div class="highlight"><pre>ITEM: BOX BOUNDS xx yy zz
xlo xhi
ylo yhi
zlo zhi
</pre></div>
</div>
<p>where xlo,xhi are the maximum extents of the simulation box in the
x-dimension, and similarly for y and z. The “xx yy zz” represent 6
characters that encode the style of boundary for each of the 6
simulation box boundaries (xlo,xhi and ylo,yhi and zlo,zhi). Each of
the 6 characters is either p = periodic, f = fixed, s = shrink wrap,
or m = shrink wrapped with a minimum value. See the
<a class="reference internal" href="boundary.html"><em>boundary</em></a> command for details.</p>
<p>For triclinic simulation boxes (non-orthogonal), an orthogonal
bounding box which encloses the triclinic simulation box is output,
along with the 3 tilt factors (xy, xz, yz) of the triclinic box,
formatted as follows:</p>
<div class="highlight-python"><div class="highlight"><pre>ITEM: BOX BOUNDS xy xz yz xx yy zz
xlo_bound xhi_bound xy
ylo_bound yhi_bound xz
zlo_bound zhi_bound yz
</pre></div>
</div>
<p>The presence of the text “xy xz yz” in the ITEM line indicates that
the 3 tilt factors will be included on each of the 3 following lines.
This bounding box is convenient for many visualization programs. The
meaning of the 6 character flags for “xx yy zz” is the same as above.</p>
<p>Note that the first two numbers on each line are now xlo_bound instead
of xlo, etc, since they repesent a bounding box. See <a class="reference internal" href="Section_howto.html#howto-12"><span>this section</span></a> of the doc pages for a geometric
description of triclinic boxes, as defined by LAMMPS, simple formulas
for how the 6 bounding box extents (xlo_bound,xhi_bound,etc) are
calculated from the triclinic parameters, and how to transform those
parameters to and from other commonly used triclinic representations.</p>
<p>The “ITEM: ATOMS” line in each snapshot lists column descriptors for
the per-atom lines that follow. For example, the descriptors would be
“id type xs ys zs” for the default <em>atom</em> style, and would be the atom
attributes you specify in the dump command for the <em>custom</em> style.</p>
<p>For style <em>atom</em>, atom coordinates are written to the file, along with
the atom ID and atom type. By default, atom coords are written in a
scaled format (from 0 to 1). I.e. an x value of 0.25 means the atom
is at a location 1/4 of the distance from xlo to xhi of the box
boundaries. The format can be changed to unscaled coords via the
<a class="reference internal" href="dump_modify.html"><em>dump_modify</em></a> settings. Image flags can also be
added for each atom via dump_modify.</p>
<p>Style <em>custom</em> allows you to specify a list of atom attributes to be
written to the dump file for each atom. Possible attributes are
listed above and will appear in the order specified. You cannot
specify a quantity that is not defined for a particular simulation -
such as <em>q</em> for atom style <em>bond</em>, since that atom style doesn’t
assign charges. Dumps occur at the very end of a timestep, so atom
attributes will include effects due to fixes that are applied during
the timestep. An explanation of the possible dump custom attributes
is given below.</p>
<p>For style <em>local</em>, local output generated by <a class="reference internal" href="compute.html"><em>computes</em></a>
and <a class="reference internal" href="fix.html"><em>fixes</em></a> is used to generate lines of output that is
written to the dump file. This local data is typically calculated by
each processor based on the atoms it owns, but there may be zero or
more entities per atom, e.g. a list of bond distances. An explanation
of the possible dump local attributes is given below. Note that by
using input from the <a class="reference internal" href="compute_property_local.html"><em>compute property/local</em></a> command with dump local,
it is possible to generate information on bonds, angles, etc that can
be cut and pasted directly into a data file read by the
The precision used in XTC files can be adjusted via the
<a class="reference internal" href="dump_modify.html"><em>dump_modify</em></a> command. The default value of 1000
means that coordinates are stored to 1/1000 nanometer accuracy. XTC
files are portable binary files written in the NFS XDR data format,
so that any machine which supports XDR should be able to read them.
The number of atoms per snapshot cannot change with the <em>xtc</em> style.
The <em>unwrap</em> option of the <a class="reference internal" href="dump_modify.html"><em>dump_modify</em></a> command allows
XTC coordinates to be written “unwrapped” by the image flags for each
atom. Unwrapped means that if the atom has passed thru a periodic
boundary one or more times, the value is printed for what the
coordinate would be if it had not been wrapped back into the periodic
box. Note that these coordinates may thus be far outside the box size
stored with the snapshot.</p>
<p>The <em>xyz</em> style writes XYZ files, which is a simple text-based
coordinate format that many codes can read. Specifically it has
a line with the number of atoms, then a comment line that is
usually ignored followed by one line per atom with the atom type
and the x-, y-, and z-coordinate of that atom. You can use the
<a class="reference internal" href="dump_modify.html"><em>dump_modify element</em></a> option to change the output
from using the (numerical) atom type to an element name (or some
other label). This will help many visualization programs to guess
bonds and colors.</p>
<p>Note that <em>atom</em>, <em>custom</em>, <em>dcd</em>, <em>xtc</em>, and <em>xyz</em> style dump files
can be read directly by <a class="reference external" href="http://www.ks.uiuc.edu/Research/vmd">VMD</a>, a
popular molecular viewing program. See <a class="reference internal" href="Section_tools.html#vmd"><span>Section tools</span></a> of the manual and the
tools/lmp2vmd/README.txt file for more information about support in
VMD for reading and visualizing LAMMPS dump files.</p>
<hr class="docutils" />
<p>Dumps are performed on timesteps that are a multiple of N (including
timestep 0) and on the last timestep of a minimization if the
minimization converges. Note that this means a dump will not be
performed on the initial timestep after the dump command is invoked,
if the current timestep is not a multiple of N. This behavior can be
changed via the <a class="reference internal" href="dump_modify.html"><em>dump_modify first</em></a> command, which
can also be useful if the dump command is invoked after a minimization
ended on an arbitrary timestep. N can be changed between runs by
using the <a class="reference internal" href="dump_modify.html"><em>dump_modify every</em></a> command (not allowed
for <em>dcd</em> style). The <a class="reference internal" href="dump_modify.html"><em>dump_modify every</em></a> command
also allows a variable to be used to determine the sequence of
timesteps on which dump files are written. In this mode a dump on the
first timestep of a run will also not be written unless the
<a class="reference internal" href="dump_modify.html"><em>dump_modify first</em></a> command is used.</p>
<p>The specified filename determines how the dump file(s) is written.
The default is to write one large text file, which is opened when the
dump command is invoked and closed when an <a class="reference internal" href="undump.html"><em>undump</em></a>
command is used or when LAMMPS exits. For the <em>dcd</em> and <em>xtc</em> styles,
this is a single large binary file.</p>
<p>Dump filenames can contain two wildcard characters. If a “*”
character appears in the filename, then one file per snapshot is
written and the “*” character is replaced with the timestep value.
For example, tmp.dump.* becomes tmp.dump.0, tmp.dump.10000,
tmp.dump.20000, etc. This option is not available for the <em>dcd</em> and
<em>xtc</em> styles. Note that the <a class="reference internal" href="dump_modify.html"><em>dump_modify pad</em></a>
command can be used to insure all timestep numbers are the same length
(e.g. 00010), which can make it easier to read a series of dump files
in order with some post-processing tools.</p>
<p>If a “%” character appears in the filename, then each of P processors
writes a portion of the dump file, and the “%” character is replaced
with the processor ID from 0 to P-1. For example, tmp.dump.% becomes
tmp.dump.0, tmp.dump.1, ... tmp.dump.P-1, etc. This creates smaller
files and can be a fast mode of output on parallel machines that
support parallel I/O for output. This option is not available for the
<em>dcd</em>, <em>xtc</em>, and <em>xyz</em> styles.</p>
<p>By default, P = the number of processors meaning one file per
processor, but P can be set to a smaller value via the <em>nfile</em> or
<em>fileper</em> keywords of the <a class="reference internal" href="dump_modify.html"><em>dump_modify</em></a> command.
These options can be the most efficient way of writing out dump files
when running on large numbers of processors.</p>
<p>Note that using the “*” and “%” characters together can produce a
large number of small dump files!</p>
<p>For the <em>atom/mpiio</em>, <em>cfg/mpiio</em>, <em>custom/mpiio</em>, and <em>xyz/mpiio</em>
styles, a single dump file is written in parallel via the MPI-IO
library, which is part of the MPI standard for versions 2.0 and above.
Using MPI-IO requires two steps. First, build LAMMPS with its MPIIO
package installed, e.g.</p>
<div class="highlight-python"><div class="highlight"><pre>make yes-mpiio # installs the MPIIO package
make g++ # build LAMMPS for your platform
</pre></div>
</div>
<p>Second, use a dump filename which contains ”.mpiio”. Note that it
does not have to end in ”.mpiio”, just contain those characters.
Unlike MPI-IO restart files, which must be both written and read using
MPI-IO, the dump files produced by these MPI-IO styles are identical
in format to the files produced by their non-MPI-IO style
counterparts. This means you can write a dump file using MPI-IO and
use the <a class="reference internal" href="read_dump.html"><em>read_dump</em></a> command or perform other
post-processing, just as if the dump file was not written using
MPI-IO.</p>
<p>Note that MPI-IO dump files are one large file which all processors
write to. You thus cannot use the “%” wildcard character described
above in the filename since that specifies generation of multiple
files. You can use the ”.bin” suffix described below in an MPI-IO
dump file; again this file will be written in parallel and have the
same binary format as if it were written without MPI-IO.</p>
<p>If the filename ends with ”.bin”, the dump file (or files, if “*” or
“%” is also used) is written in binary format. A binary dump file
will be about the same size as a text version, but will typically
write out much faster. Of course, when post-processing, you will need
to convert it back to text format (see the <a class="reference internal" href="Section_tools.html#binary"><span>binary2txt tool</span></a>) or write your own code to read the
binary file. The format of the binary file can be understood by
looking at the tools/binary2txt.cpp file. This option is only
available for the <em>atom</em> and <em>custom</em> styles.</p>
<p>If the filename ends with ”.gz”, the dump file (or files, if “*” or “%”
is also used) is written in gzipped format. A gzipped dump file will
be about 3x smaller than the text version, but will also take longer
to write. This option is not available for the <em>dcd</em> and <em>xtc</em>
styles.</p>
<hr class="docutils" />
<p>This section explains the local attributes that can be specified as
part of the <em>local</em> style.</p>
<p>The <em>index</em> attribute can be used to generate an index number from 1
to N for each line written into the dump file, where N is the total
number of local datums from all processors, or lines of output that
will appear in the snapshot. Note that because data from different
processors depend on what atoms they currently own, and atoms migrate
between processor, there is no guarantee that the same index will be
used for the same info (e.g. a particular bond) in successive
snapshots.</p>
<p>The <em>c_ID</em> and <em>c_ID[N]</em> attributes allow local vectors or arrays
calculated by a <a class="reference internal" href="compute.html"><em>compute</em></a> to be output. The ID in the
attribute should be replaced by the actual ID of the compute that has
been defined previously in the input script. See the
<a class="reference internal" href="compute.html"><em>compute</em></a> command for details. There are computes for
calculating local information such as indices, types, and energies for
bonds and angles.</p>
<p>Note that computes which calculate global or per-atom quantities, as
opposed to local quantities, cannot be output in a dump local command.
Instead, global quantities can be output by the <a class="reference internal" href="thermo_style.html"><em>thermo_style custom</em></a> command, and per-atom quantities can be
output by the dump custom command.</p>
<p>If <em>c_ID</em> is used as a attribute, then the local vector calculated by
the compute is printed. If <em>c_ID[N]</em> is used, then N must be in the
range from 1-M, which will print the Nth column of the M-length local
array calculated by the compute.</p>
<p>The <em>f_ID</em> and <em>f_ID[N]</em> attributes allow local vectors or arrays
calculated by a <a class="reference internal" href="fix.html"><em>fix</em></a> to be output. The ID in the attribute
should be replaced by the actual ID of the fix that has been defined
previously in the input script.</p>
<p>If <em>f_ID</em> is used as a attribute, then the local vector calculated by
the fix is printed. If <em>f_ID[N]</em> is used, then N must be in the
range from 1-M, which will print the Nth column of the M-length local
array calculated by the fix.</p>
<p>Here is an example of how to dump bond info for a system,
including the distance and energy of each bond:</p>
<div class="highlight-python"><div class="highlight"><pre>compute 1 all property/local batom1 batom2 btype
compute 2 all bond/local dist eng
dump 1 all local 1000 tmp.dump index c_1[1] c_1[2] c_1[3] c_2[1] c_2[2]
</pre></div>
</div>
<hr class="docutils" />
<p>This section explains the atom attributes that can be specified as
part of the <em>custom</em> and <em>cfg</em> styles.</p>
<em>vy</em>, <em>vz</em>, <em>fx</em>, <em>fy</em>, <em>fz</em>, <em>q</em> attributes are self-explanatory.</p>
<p><em>Id</em> is the atom ID. <em>Mol</em> is the molecule ID, included in the data
file for molecular systems. <em>Proc</em> is the ID of the processor (0 to
Nprocs-1) that currently owns the atom. <em>Procp1</em> is the proc ID+1,
which can be convenient in place of a <em>type</em> attribute (1 to Ntypes)
for coloring atoms in a visualization program. <em>Type</em> is the atom
type (1 to Ntypes). <em>Element</em> is typically the chemical name of an
element, which you must assign to each type via the <a class="reference internal" href="dump_modify.html"><em>dump_modify element</em></a> command. More generally, it can be any
string you wish to associated with an atom type. <em>Mass</em> is the atom
mass. <em>Vx</em>, <em>vy</em>, <em>vz</em>, <em>fx</em>, <em>fy</em>, <em>fz</em>, and <em>q</em> are components of
atom velocity and force and atomic charge.</p>
<p>There are several options for outputting atom coordinates. The <em>x</em>,
<em>y</em>, <em>z</em> attributes write atom coordinates “unscaled”, in the
appropriate distance <a class="reference internal" href="units.html"><em>units</em></a> (Angstroms, sigma, etc). Use
<em>xs</em>, <em>ys</em>, <em>zs</em> if you want the coordinates “scaled” to the box size,
so that each value is 0.0 to 1.0. If the simulation box is triclinic
(tilted), then all atom coords will still be between 0.0 and 1.0. Use
<em>xu</em>, <em>yu</em>, <em>zu</em> if you want the coordinates “unwrapped” by the image
flags for each atom. Unwrapped means that if the atom has passed thru
a periodic boundary one or more times, the value is printed for what
the coordinate would be if it had not been wrapped back into the
periodic box. Note that using <em>xu</em>, <em>yu</em>, <em>zu</em> means that the
coordinate values may be far outside the box bounds printed with the
snapshot. Using <em>xsu</em>, <em>ysu</em>, <em>zsu</em> is similar to using <em>xu</em>, <em>yu</em>, <em>zu</em>,
except that the unwrapped coordinates are scaled by the box size. Atoms
that have passed through a periodic boundary will have the corresponding
cooordinate increased or decreased by 1.0.</p>
<p>The image flags can be printed directly using the <em>ix</em>, <em>iy</em>, <em>iz</em>
attributes. For periodic dimensions, they specify which image of the
simulation box the atom is considered to be in. An image of 0 means
it is inside the box as defined. A value of 2 means add 2 box lengths
to get the true value. A value of -1 means subtract 1 box length to
get the true value. LAMMPS updates these flags as atoms cross
periodic boundaries during the simulation.</p>
<p>The <em>mux</em>, <em>muy</em>, <em>muz</em> attributes are specific to dipolar systems
defined with an atom style of <em>dipole</em>. They give the orientation of
the atom’s point dipole moment. The <em>mu</em> attribute gives the
magnitude of the atom’s dipole moment.</p>
<p>The <em>radius</em> and <em>diameter</em> attributes are specific to spherical
particles that have a finite size, such as those defined with an atom
style of <em>sphere</em>.</p>
<p>The <em>omegax</em>, <em>omegay</em>, and <em>omegaz</em> attributes are specific to
finite-size spherical particles that have an angular velocity. Only
certain atom styles, such as <em>sphere</em> define this quantity.</p>
<p>The <em>angmomx</em>, <em>angmomy</em>, and <em>angmomz</em> attributes are specific to
finite-size aspherical particles that have an angular momentum. Only
the <em>ellipsoid</em> atom style defines this quantity.</p>
<p>The <em>tqx</em>, <em>tqy</em>, <em>tqz</em> attributes are for finite-size particles that
can sustain a rotational torque due to interactions with other
particles.</p>
<p>The <em>c_ID</em> and <em>c_ID[N]</em> attributes allow per-atom vectors or arrays
calculated by a <a class="reference internal" href="compute.html"><em>compute</em></a> to be output. The ID in the
attribute should be replaced by the actual ID of the compute that has
been defined previously in the input script. See the
<a class="reference internal" href="compute.html"><em>compute</em></a> command for details. There are computes for
calculating the per-atom energy, stress, centro-symmetry parameter,
and coordination number of individual atoms.</p>
<p>Note that computes which calculate global or local quantities, as
opposed to per-atom quantities, cannot be output in a dump custom
command. Instead, global quantities can be output by the
<a class="reference internal" href="thermo_style.html"><em>thermo_style custom</em></a> command, and local quantities
can be output by the dump local command.</p>
<p>If <em>c_ID</em> is used as a attribute, then the per-atom vector calculated
by the compute is printed. If <em>c_ID[N]</em> is used, then N must be in
the range from 1-M, which will print the Nth column of the M-length
per-atom array calculated by the compute.</p>
<p>The <em>f_ID</em> and <em>f_ID[N]</em> attributes allow vector or array per-atom
quantities calculated by a <a class="reference internal" href="fix.html"><em>fix</em></a> to be output. The ID in the
attribute should be replaced by the actual ID of the fix that has been
defined previously in the input script. The <a class="reference internal" href="fix_ave_atom.html"><em>fix ave/atom</em></a> command is one that calculates per-atom
quantities. Since it can time-average per-atom quantities produced by
any <a class="reference internal" href="compute.html"><em>compute</em></a>, <a class="reference internal" href="fix.html"><em>fix</em></a>, or atom-style
<a class="reference internal" href="variable.html"><em>variable</em></a>, this allows those time-averaged results to
be written to a dump file.</p>
<p>If <em>f_ID</em> is used as a attribute, then the per-atom vector calculated
by the fix is printed. If <em>f_ID[N]</em> is used, then N must be in the
range from 1-M, which will print the Nth column of the M-length
per-atom array calculated by the fix.</p>
<p>The <em>v_name</em> attribute allows per-atom vectors calculated by a
<a class="reference internal" href="variable.html"><em>variable</em></a> to be output. The name in the attribute
should be replaced by the actual name of the variable that has been
defined previously in the input script. Only an atom-style variable
can be referenced, since it is the only style that generates per-atom
values. Variables of style <em>atom</em> can reference individual atom
attributes, per-atom atom attributes, thermodynamic keywords, or
invoke other computes, fixes, or variables when they are evaluated, so
this is a very general means of creating quantities to output to a
dump file.</p>
<p>The <em>d_name</em> and <em>i_name</em> attributes allow to output custom per atom
floating point or integer properties that are managed by
<p>See <a class="reference internal" href="Section_modify.html"><em>Section_modify</em></a> of the manual for information
on how to add new compute and fix styles to LAMMPS to calculate
per-atom quantities which could then be output into dump files.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions<a class="headerlink" href="#restrictions" title="Permalink to this headline">¶</a></h2>
-<p>To write gzipped dump files, you must compile LAMMPS with the
--DLAMMPS_GZIP option - see the <a class="reference internal" href="Section_start.html#start-2"><span>Making LAMMPS</span></a> section of the documentation.</p>
+<p>To write gzipped dump files, you must either compile LAMMPS with the
+-DLAMMPS_GZIP option or use the styles from the COMPRESS package
+- see the <a class="reference internal" href="Section_start.html#start-2"><span>Making LAMMPS</span></a> section of
+the documentation.</p>
+<p>The <em>atom/gz</em>, <em>cfg/gz</em>, <em>custom/gz</em>, and <em>xyz/gz</em> styles are part
+of the COMPRESS package. They are only enabled if LAMMPS was built
+with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info.</p>
<p>The <em>atom/mpiio</em>, <em>cfg/mpiio</em>, <em>custom/mpiio</em>, and <em>xyz/mpiio</em> styles
are part of the MPIIO package. They are only enabled if LAMMPS was
built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info.</p>
<p>The <em>xtc</em> style is part of the XTC package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info. This is
because some machines may not support the low-level XDR data format
that XTC files are written with, which will result in a compile-time
error when a low-level include file is not found. Putting this style
in a package makes it easy to exclude from a LAMMPS build for those
machines. However, the XTC package also includes two compatibility
header files and associated functions, which should be a suitable
substitute on machines that do not have the appropriate native header
files. This option can be invoked at build time by adding
-DLAMMPS_XDR to the CCFLAGS variable in the appropriate low-level
Makefile, e.g. src/MAKE/Makefile.foo. This compatibility mode has
been tested successfully on Cray XT3/XT4/XT5 and IBM BlueGene/L
machines and should also work on IBM BG/P, and Windows XP/Vista/7
machines.</p>
</div>
<div class="section" id="related-commands">
<h2>Related commands<a class="headerlink" href="#related-commands" title="Permalink to this headline">¶</a></h2>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-<LI>h5md = style of dump command (other styles <I>atom</I> or <I>cfg</I> or <I>dcd</I> or <I>xtc</I> or <I>xyz</I> or <I>local</I> or <I>custom</I> are discussed on the <A HREF = "dump.html">dump</A> doc page)
+
+ <link rel="top" title="LAMMPS 15 May 2015 version documentation" href="index.html"/>
+<span id="index-0"></span><h1>dump h5md command<a class="headerlink" href="#dump-h5md-command" title="Permalink to this headline">¶</a></h1>
+<div class="section" id="syntax">
+<h2>Syntax<a class="headerlink" href="#syntax" title="Permalink to this headline">¶</a></h2>
+<div class="highlight-python"><div class="highlight"><pre>dump ID group-ID h5md N file.h5 args
+</pre></div>
+</div>
+<ul class="simple">
+<li>ID = user-assigned name for the dump</li>
+<li>group-ID = ID of the group of atoms to be imaged</li>
+<li>h5md = style of dump command (other styles <em>atom</em> or <em>cfg</em> or <em>dcd</em> or <em>xtc</em> or <em>xyz</em> or <em>local</em> or <em>custom</em> are discussed on the <a class="reference internal" href="dump.html"><em>dump</em></a> doc page)</li>
+<li>N = dump every this many timesteps</li>
+<li>file.h5 = name of file to write to</li>
+<li>args = list of data elements to dump, with their dump “subintervals”.
At least one element must be given and image may only be present if
-position is specified first.
-
-<PRE> position options
- image
- velocity options
- force options
- species options
- file_from ID: do not open a new file, re-use the already opened file from dump ID
- box value = <I>yes</I> or <I>no</I>
- create_group value = <I>yes</I> or <I>no</I>
- author value = quoted string
-</PRE>
-<P>For the elements <I>position</I>, <I>velocity</I>, <I>force</I> and <I>species</I>, one may specify
-a sub-interval to write the data only every N_element iterations of the dump
-(i.e. every N*N_element time steps). This is specified by the option
-</P>
-<PRE> every N_element
-</PRE>
-<P>that follows directly the element declaration.
-</P>
-
-</UL>
-<P><B>Examples:</B>
-</P>
-<PRE>dump h5md1 all h5md 100 dump_h5md.h5 position image
-dump h5md1 all h5md 100 dump_h5md.h5 position velocity every 10
-</PRE>
-<PRE>dump h5md1 all h5md 100 dump_h5md.h5 velocity author "L. Ammps"
-</PRE>
-<P><B>Description:</B>
-</P>
-<P>Dump a snapshot of atom coordinates every N timesteps in the <A HREF = "http://www.hdfgroup.org/HDF5/">HDF5</A>
-based <A HREF = "http://nongnu.org/h5md/">H5MD</A> file format <A HREF = "#h5md_cpc">(de Buyl et al.)</A>.
-HDF5 files are binary, portable and self-describing.
-This dump style will write only one file, on the root node.
-</P>
-<P>Several dumps may write to the same file, by using file_from and referring to a
-previously defined dump.
-Several groups may also be stored within the same file by defining several dumps.
-A dump that refers (via <I>file_from</I>) to an already open dump ID and that
-concerns another particle group must specify <I>create_group yes</I>.
-</P>
-
-
-<P>Each data element is written every N*N_element steps. For <I>image</I>, no
-subinterval is needed as it must be present at the same interval as <I>position</I>.
-<I>image</I> must be given after <I>position</I> in any case.
-The box information (edges in each dimension) is stored at the same interval
-than the <I>position</I> element, if present. Else it is stored every N steps.
-</P>
-<P>IMPORTANT NOTE: Because periodic boundary conditions are enforced only
+position is specified first.</li>
+</ul>
+<pre class="literal-block">
+position options
+image
+velocity options
+force options
+species options
+file_from ID: do not open a new file, re-use the already opened file from dump ID
+box value = <em>yes</em> or <em>no</em>
+create_group value = <em>yes</em> or <em>no</em>
+author value = quoted string
+</pre>
+<p>For the elements <em>position</em>, <em>velocity</em>, <em>force</em> and <em>species</em>, one
+may specify a sub-interval to write the data only every N_element
+iterations of the dump (i.e. every N*N_element time steps). This is
+<p>It is possible to use this dump style with the
+<a class="reference internal" href="write_dump.html"><em>write_dump</em></a> command. In this case, the subintervals
+must not be set at all. The write_dump command can be used either to
+create a new file or to add current data to an existing dump file by
+using the <em>file_from</em> keyword.</p>
+<p>Typically, the <em>species</em> data is fixed. The following two commands
+store the position data every 100 timesteps, with the image data, and
+store once the species data in the same file.</p>
+<div class="highlight-python"><div class="highlight"><pre>dump h5md1 all h5md 100 dump.h5 position image
+write_dump all h5md dump.h5 file_from h5md1 species
+</pre></div>
+</div>
+</div>
+<hr class="docutils" />
+<div class="section" id="restrictions">
+<h2>Restrictions<a class="headerlink" href="#restrictions" title="Permalink to this headline">¶</a></h2>
+<p>The number of atoms per snapshot cannot change with the h5md style.
+The position data is stored wrapped (box boundaries not enforced, see
+note above). Only orthogonal domains are currently supported. This is
+a limitation of the present dump h5md command and not of H5MD itself.</p>
+<p>The <em>h5md</em> dump style is part of the USER-H5MD package. It is only
+enabled if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info. It also
+requires (i) building the ch5md library provided with LAMMPS (See the
+<a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info.) and
+(ii) having the <a class="reference external" href="http://www.hdfgroup.org/HDF5/">HDF5</a> library installed (C bindings are
+sufficient) on your system. The library ch5md is compiled with the
+h5cc wrapper provided by the HDF5 library.</p>
+</div>
+<hr class="docutils" />
+<div class="section" id="related-commands">
+<h2>Related commands<a class="headerlink" href="#related-commands" title="Permalink to this headline">¶</a></h2>
+ Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
group-ID = ID of the group of atoms to be imaged :l
h5md = style of dump command (other styles {atom} or {cfg} or {dcd} or {xtc} or {xyz} or {local} or {custom} are discussed on the "dump"_dump.html doc page) :l
N = dump every this many timesteps :l
file.h5 = name of file to write to :l
args = list of data elements to dump, with their dump "subintervals".
At least one element must be given and image may only be present if
position is specified first. :l
position options
image
velocity options
force options
species options
file_from ID: do not open a new file, re-use the already opened file from dump ID
box value = {yes} or {no}
create_group value = {yes} or {no}
author value = quoted string :pre
-For the elements {position}, {velocity}, {force} and {species}, one may specify
-a sub-interval to write the data only every N_element iterations of the dump
-(i.e. every N*N_element time steps). This is specified by the option
+For the elements {position}, {velocity}, {force} and {species}, one
+may specify a sub-interval to write the data only every N_element
+iterations of the dump (i.e. every N*N_element time steps). This is
+specified by the option
every N_element :pre
that follows directly the element declaration.
:ule
[Examples:]
dump h5md1 all h5md 100 dump_h5md.h5 position image
-dump h5md1 all h5md 100 dump_h5md.h5 position velocity every 10 :pre
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<h2>Description<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
<p>This command invokes package-specific settings for the various
accelerator packages available in LAMMPS. Currently the following
packages use settings from this command: USER-CUDA, GPU, USER-INTEL,
KOKKOS, and USER-OMP.</p>
<p>If this command is specified in an input script, it must be near the
top of the script, before the simulation box has been defined. This
is because it specifies settings that the accelerator packages use in
their intialization, before a simultion is defined.</p>
<p>This command can also be specified from the command-line when
launching LAMMPS, using the “-pk” <a class="reference internal" href="Section_start.html#start-7"><span>command-line switch</span></a>. The syntax is exactly the same as
when used in an input script.</p>
<p>Note that all of the accelerator packages require the package command
to be specified (except the OPT package), if the package is to be used
in a simulation (LAMMPS can be built with an accelerator package
without using it in a particular simulation). However, in all cases,
a default version of the command is typically invoked by other
accelerator settings.</p>
<p>The USER-CUDA and KOKKOS packages require a “-c on” or “-k on”
<a class="reference internal" href="Section_start.html#start-7"><span>command-line switch</span></a> respectively, which
invokes a “package cuda” or “package kokkos” command with default
settings.</p>
<p>For the GPU, USER-INTEL, and USER-OMP packages, if a “-sf gpu” or “-sf
intel” or “-sf omp” <a class="reference internal" href="Section_start.html#start-7"><span>command-line switch</span></a>
is used to auto-append accelerator suffixes to various styles in the
input script, then those switches also invoke a “package gpu”,
“package intel”, or “package omp” command with default settings.</p>
<div class="admonition warning">
<p class="first admonition-title">Warning</p>
<p class="last">A package command for a particular style can be
invoked multiple times when a simulation is setup, e.g. by the “-c
on”, “-k on”, “-sf”, and “-pk” <a class="reference internal" href="Section_start.html#start-7"><span>command-line switches</span></a>, and by using this command in an
input script. Each time it is used all of the style options are set,
either to default values or to specified settings. I.e. settings from
previous invocations do not persist across multiple invocations.</p>
</div>
<p>See the <a class="reference internal" href="Section_accelerate.html"><em>Section Accelerate</em></a> section of the
manual for more details about using the various accelerator packages
for speeding up LAMMPS simulations.</p>
<hr class="docutils" />
<p>The <em>cuda</em> style invokes settings associated with the use of the
USER-CUDA package.</p>
<p>The <em>Ngpus</em> argument sets the number of GPUs per node. There must be
exactly one MPI task per GPU, as set by the mpirun or mpiexec command.</p>
<p>Optional keyword/value pairs can also be specified. Each has a
default value as listed below.</p>
<p>The <em>newton</em> keyword sets the Newton flags for pairwise and bonded
interactions to <em>off</em> or <em>on</em>, the same as the <a class="reference internal" href="newton.html"><em>newton</em></a>
command allows. The default is <em>off</em> because this will almost always
give better performance for the USER-CUDA package. This means
more computation is done, but less communication.</p>
<p>The <em>gpuID</em> keyword allows selection of which GPUs on each node will
be used for a simulation. GPU IDs range from 0 to N-1 where N is the
physical number of GPUs/node. An ID is specified for each of the
Ngpus being used. For example if you have three GPUs on a machine,
one of which is used for the X-Server (the GPU with the ID 1) while
the others (with IDs 0 and 2) are used for computations you would
specify:</p>
<div class="highlight-python"><div class="highlight"><pre>package cuda 2 gpuID 0 2
</pre></div>
</div>
<p>The purpose of the <em>gpuID</em> keyword is to allow two (or more)
simulations to be run on one workstation. In that case one could set
the first simulation to use GPU 0 and the second to use GPU 1. This is
not necessary however, if the GPUs are in what is called <em>compute
exclusive</em> mode. Using that setting, every process will get its own
GPU automatically. This <em>compute exclusive</em> mode can be set as root
using the <em>nvidia-smi</em> tool which is part of the CUDA installation.</p>
<p>Also note that if the <em>gpuID</em> keyword is not used, the USER-CUDA
package sorts existing GPUs on each node according to their number of
multiprocessors. This way, compute GPUs will be priorized over
X-Server GPUs.</p>
<p>If the <em>timing</em> keyword is specified, detailed timing information for
various subroutines will be output.</p>
<p>If the <em>test</em> keyword is specified, information for the specified atom
with atom-ID will be output at several points during each timestep.
This is mainly usefull for debugging purposes. Note that the
simulation slow down dramatically if this option is used.</p>
<p>The <em>thread</em> keyword can be used to specify how GPU threads are
assigned work during pair style force evaluation. If the value =
<em>tpa</em>, one thread per atom is used. If the value = <em>bpa</em>, one block
per atom is used. If the value = <em>auto</em>, a short test is performed at
the beginning of each run to determing where <em>tpa</em> or <em>bpa</em> mode is
faster. The result of this test is output. Since <em>auto</em> is the
default value, it is usually not necessary to use this keyword.</p>
<hr class="docutils" />
<p>The <em>gpu</em> style invokes settings associated with the use of the GPU
package.</p>
<p>The <em>Ngpu</em> argument sets the number of GPUs per node. There must be
at least as many MPI tasks per node as GPUs, as set by the mpirun or
mpiexec command. If there are more MPI tasks (per node)
than GPUs, multiple MPI tasks will share each GPU.</p>
<p>Optional keyword/value pairs can also be specified. Each has a
default value as listed below.</p>
<p>The <em>neigh</em> keyword specifies where neighbor lists for pair style
computation will be built. If <em>neigh</em> is <em>yes</em>, which is the default,
neighbor list building is performed on the GPU. If <em>neigh</em> is <em>no</em>,
neighbor list building is performed on the CPU. GPU neighbor list
building currently cannot be used with a triclinic box. GPU neighbor
list calculation currently cannot be used with
<a class="reference internal" href="pair_hybrid.html"><em>hybrid</em></a> pair styles. GPU neighbor lists are not
compatible with comannds that are not GPU-enabled. When a non-GPU
enabled command requires a neighbor list, it will also be built on the
CPU. In these cases, it will typically be more efficient to only use
CPU neighbor list builds.</p>
<p>The <em>newton</em> keyword sets the Newton flags for pairwise (not bonded)
interactions to <em>off</em> or <em>on</em>, the same as the <a class="reference internal" href="newton.html"><em>newton</em></a>
command allows. Currently, only an <em>off</em> value is allowed, since all
the GPU package pair styles require this setting. This means more
computation is done, but less communication. In the future a value of
<em>on</em> may be allowed, so the <em>newton</em> keyword is included as an option
for compatibility with the package command for other accelerator
styles. Note that the newton setting for bonded interactions is not
affected by this keyword.</p>
<p>The <em>binsize</em> keyword sets the size of bins used to bin atoms in
neighbor list builds performed on the GPU, if <em>neigh</em> = <em>yes</em> is set.
If <em>binsize</em> is set to 0.0 (the default), then bins = the size of the
pairwise cutoff + neighbor skin distance. This is 2x larger than the
LAMMPS default used for neighbor list building on the CPU. This will
be close to optimal for the GPU, so you do not normally need to use
this keyword. Note that if you use a longer-than-usual pairwise
cutoff, e.g. to allow for a smaller fraction of KSpace work with a
<a class="reference internal" href="kspace_style.html"><em>long-range Coulombic solver</em></a> because the GPU is
faster at performing pairwise interactions, then it may be optimal to
make the <em>binsize</em> smaller than the default. For example, with a
cutoff of 20*sigma in LJ <a class="reference internal" href="units.html"><em>units</em></a> and a neighbor skin
distance of sigma, a <em>binsize</em> = 5.25*sigma can be more efficient than
the default.</p>
<p>The <em>split</em> keyword can be used for load balancing force calculations
between CPU and GPU cores in GPU-enabled pair styles. If 0 < <em>split</em> <
1.0, a fixed fraction of particles is offloaded to the GPU while force
calculation for the other particles occurs simulataneously on the CPU.
If <em>split</em> < 0.0, the optimal fraction (based on CPU and GPU timings)
is calculated every 25 timesteps, i.e. dynamic load-balancing across
the CPU and GPU is performed. If <em>split</em> = 1.0, all force
calculations for GPU accelerated pair styles are performed on the GPU.
In this case, other <a class="reference internal" href="pair_hybrid.html"><em>hybrid</em></a> pair interactions,
<p>In this case, all CPU cores and GPU devices on the nodes would be
utilized. Each GPU device would be shared by 4 CPU cores. The CPU
cores would perform force calculations for some fraction of the
particles at the same time the GPUs performed force calculation for
the other particles.</p>
<p>The <em>gpuID</em> keyword allows selection of which GPUs on each node will
be used for a simulation. The <em>first</em> and <em>last</em> values specify the
GPU IDs to use (from 0 to Ngpu-1). By default, first = 0 and last =
Ngpu-1, so that all GPUs are used, assuming Ngpu is set to the number
of physical GPUs. If you only wish to use a subset, set Ngpu to a
smaller number and first/last to a sub-range of the available GPUs.</p>
<p>The <em>tpa</em> keyword sets the number of GPU thread per atom used to
perform force calculations. With a default value of 1, the number of
threads will be chosen based on the pair style, however, the value can
be set explicitly with this keyword to fine-tune performance. For
large cutoffs or with a small number of particles per GPU, increasing
the value can improve performance. The number of threads per atom must
be a power of 2 and currently cannot be greater than 32.</p>
<p>The <em>device</em> keyword can be used to tune parameters optimized for a
specific accelerator, when using OpenCL. For CUDA, the <em>device</em>
keyword is ignored. Currently, the device type is limited to NVIDIA
Kepler, NVIDIA Fermi, AMD Cypress, or a generic device. More devices
may be added later. The default device type can be specified when
building LAMMPS with the GPU library, via settings in the
lib/gpu/Makefile that is used.</p>
<hr class="docutils" />
<p>The <em>intel</em> style invokes settings associated with the use of the
USER-INTEL package. All of its settings, except the <em>omp</em> and <em>mode</em>
keywords, are ignored if LAMMPS was not built with Xeon Phi
coprocessor support. All of its settings, including the <em>omp</em> and
<em>mode</em> keyword are applicable if LAMMPS was built with coprocessor
support.</p>
<p>The <em>Nphi</em> argument sets the number of coprocessors per node.
This can be set to any value, including 0, if LAMMPS was not
built with coprocessor support.</p>
<p>Optional keyword/value pairs can also be specified. Each has a
default value as listed below.</p>
<p>The <em>omp</em> keyword determines the number of OpenMP threads allocated
for each MPI task when any portion of the interactions computed by a
USER-INTEL pair style are run on the CPU. This can be the case even
if LAMMPS was built with coprocessor support; see the <em>balance</em>
keyword discussion below. If you are running with less MPI tasks/node
than there are CPUs, it can be advantageous to use OpenMP threading on
the CPUs.</p>
<div class="admonition warning">
<p class="first admonition-title">Warning</p>
<p class="last">The <em>omp</em> keyword has nothing to do with coprocessor
threads on the Xeon Phi; see the <em>tpc</em> and <em>tptask</em> keywords below for
a discussion of coprocessor threads.</p>
</div>
<p>The <em>Nthread</em> value for the <em>omp</em> keyword sets the number of OpenMP
threads allocated for each MPI task. Setting <em>Nthread</em> = 0 (the
default) instructs LAMMPS to use whatever value is the default for the
given OpenMP environment. This is usually determined via the
<em>OMP_NUM_THREADS</em> environment variable or the compiler runtime, which
is usually a value of 1.</p>
<p>For more details, including examples of how to set the OMP_NUM_THREADS
environment variable, see the discussion of the <em>Nthreads</em> setting on
this doc page for the “package omp” command. Nthreads is a required
argument for the USER-OMP package. Its meaning is exactly the same
for the USER-INTEL pacakge.</p>
<div class="admonition warning">
<p class="first admonition-title">Warning</p>
<p class="last">If you build LAMMPS with both the USER-INTEL and
USER-OMP packages, be aware that both packages allow setting of the
<em>Nthreads</em> value via their package commands, but there is only a
single global <em>Nthreads</em> value used by OpenMP. Thus if both package
commands are invoked, you should insure the two values are consistent.
If they are not, the last one invoked will take precedence, for both
packages. Also note that if the “-sf intel” <a class="reference internal" href="Section_start.html#start-7"><span>command-line switch</span></a> is used, it invokes a “package
intel” command, followed by a “package omp” command, both with a
setting of <em>Nthreads</em> = 0.</p>
</div>
<p>The <em>mode</em> keyword determines the precision mode to use for
computing pair style forces, either on the CPU or on the coprocessor,
when using a USER-INTEL supported <a class="reference internal" href="pair_style.html"><em>pair style</em></a>. It
can take a value of <em>single</em>, <em>mixed</em> which is the default, or
<em>double</em>. <em>Single</em> means single precision is used for the entire
force calculation. <em>Mixed</em> means forces between a pair of atoms are
computed in single precision, but accumulated and stored in double
precision, including storage of forces, torques, energies, and virial
quantities. <em>Double</em> means double precision is used for the entire
force calculation.</p>
<p>The <em>balance</em> keyword sets the fraction of <a class="reference internal" href="pair_style.html"><em>pair style</em></a> work offloaded to the coprocessor for split
values between 0.0 and 1.0 inclusive. While this fraction of work is
running on the coprocessor, other calculations will run on the host,
including neighbor and pair calculations that are not offloaded, as
well as angle, bond, dihedral, kspace, and some MPI communications.
If <em>split</em> is set to -1, the fraction of work is dynamically adjusted
automatically throughout the run. This typically give performance
within 5 to 10 percent of the optimal fixed fraction.</p>
<p>The <em>ghost</em> keyword determines whether or not ghost atoms, i.e. atoms
at the boundaries of proessor sub-domains, are offloaded for neighbor
and force calculations. When the value = “no”, ghost atoms are not
offloaded. This option can reduce the amount of data transfer with
the coprocessor and can also overlap MPI communication of forces with
computation on the coprocessor when the <a class="reference internal" href="newton.html"><em>newton pair</em></a>
setting is “on”. When the value = “yes”, ghost atoms are offloaded.
In some cases this can provide better performance, especially if the
<em>balance</em> fraction is high.</p>
<p>The <em>tpc</em> keyword sets the max # of coprocessor threads <em>Ntpc</em> that
will run on each core of the coprocessor. The default value = 4,
which is the number of hardware threads per core supported by the
current generation Xeon Phi chips.</p>
<p>The <em>tptask</em> keyword sets the max # of coprocessor threads (Ntptask*
assigned to each MPI task. The default value = 240, which is the
total # of threads an entire current generation Xeon Phi chip can run
(240 = 60 cores * 4 threads/core). This means each MPI task assigned
to the Phi will enough threads for the chip to run the max allowed,
even if only 1 MPI task is assigned. If 8 MPI tasks are assigned to
the Phi, each will run with 30 threads. If you wish to limit the
number of threads per MPI task, set <em>tptask</em> to a smaller value.
E.g. for <em>tptask</em> = 16, if 8 MPI tasks are assigned, each will run
with 16 threads, for a total of 128.</p>
<p>Note that the default settings for <em>tpc</em> and <em>tptask</em> are fine for
most problems, regardless of how many MPI tasks you assign to a Phi.</p>
<p>The <em>no_affinity</em> keyword will turn off automatic setting of core
affinity for MPI tasks and OpenMP threads on the host when using
offload to a coprocessor. Affinity settings are used when possible
to prevent MPI tasks and OpenMP threads from being on separate NUMA
domains and to prevent offload threads from interfering with other
processes/threads used for LAMMPS.</p>
<hr class="docutils" />
<p>The <em>kokkos</em> style invokes settings associated with the use of the
KOKKOS package.</p>
<p>All of the settings are optional keyword/value pairs. Each has a
default value as listed below.</p>
<p>The <em>neigh</em> keyword determines how neighbor lists are built. A value
of <em>half</em> uses half-neighbor lists, the same as used by most pair
styles in LAMMPS. A value of <em>half/thread</em> uses a thread-safe variant
of the half-neighbor list. It should be used instead of <em>half</em> when
running with more than 1 threads per MPI task on a CPU. A value of
<em>n2</em> uses an O(N^2) algorithm to build the neighbor list without
binning, where N = # of atoms on a processor. It is typically slower
than the other methods, which use binning.</p>
<p>A value of <em>full</em> uses a full neighbor lists and is the default. This
performs twice as much computation as the <em>half</em> option, however that
is often a win because it is thread-safe and doesn’t require atomic
operations in the calculation of pair forces. For that reason, <em>full</em>
is the default setting. However, when running in MPI-only mode with 1
thread per MPI task, <em>half</em> neighbor lists will typically be faster,
just as it is for non-accelerated pair styles.</p>
<p>A value of <em>full/cluster</em> is an experimental neighbor style, where
particles interact with all particles within a small cluster, if at
least one of the clusters particles is within the neighbor cutoff
range. This potentially allows for better vectorization on
architectures such as the Intel Phi. If also reduces the size of the
neighbor list by roughly a factor of the cluster size, thus reducing
the total memory footprint considerably.</p>
<p>The <em>newton</em> keyword sets the Newton flags for pairwise and bonded
interactions to <em>off</em> or <em>on</em>, the same as the <a class="reference internal" href="newton.html"><em>newton</em></a>
command allows. The default is <em>off</em> because this will almost always
give better performance for the KOKKOS package. This means more
computation is done, but less communication. However, when running in
MPI-only mode with 1 thread per MPI task, a value of <em>on</em> will
typically be faster, just as it is for non-accelerated pair styles.</p>
<p>The <em>binsize</em> keyword sets the size of bins used to bin atoms in
neighbor list builds. The same value can be set by the <a class="reference internal" href="neigh_modify.html"><em>neigh_modify binsize</em></a> command. Making it an option in the
package kokkos command allows it to be set from the command line. The
default value is 0.0, which means the LAMMPS default will be used,
which is bins = 1/2 the size of the pairwise cutoff + neighbor skin
distance. This is fine when neighbor lists are built on the CPU. For
GPU builds, a 2x larger binsize equal to the pairwise cutoff +
neighbor skin, is often faster, which can be set by this keyword.
Note that if you use a longer-than-usual pairwise cutoff, e.g. to
allow for a smaller fraction of KSpace work with a <a class="reference internal" href="kspace_style.html"><em>long-range Coulombic solver</em></a> because the GPU is faster at
performing pairwise interactions, then this rule of thumb may give too
large a binsize.</p>
<p>The <em>comm</em> and <em>comm/exchange</em> and <em>comm/forward</em> keywords determine
whether the host or device performs the packing and unpacking of data
when communicating per-atom data between processors. “Exchange”
communication happens only on timesteps that neighbor lists are
rebuilt. The data is only for atoms that migrate to new processors.
“Forward” communication happens every timestep. The data is for atom
coordinates and any other atom properties that needs to be updated for
ghost atoms owned by each processor.</p>
<p>The <em>comm</em> keyword is simply a short-cut to set the same value
for both the <em>comm/exchange</em> and <em>comm/forward</em> keywords.</p>
<p>The value options for all 3 keywords are <em>no</em> or <em>host</em> or <em>device</em>.
A value of <em>no</em> means to use the standard non-KOKKOS method of
packing/unpacking data for the communication. A value of <em>host</em> means
to use the host, typically a multi-core CPU, and perform the
packing/unpacking in parallel with threads. A value of <em>device</em> means
to use the device, typically a GPU, to perform the packing/unpacking
operation.</p>
<p>The optimal choice for these keywords depends on the input script and
the hardware used. The <em>no</em> value is useful for verifying that the
Kokkos-based <em>host</em> and <em>device</em> values are working correctly. It may
also be the fastest choice when using Kokkos styles in MPI-only mode
(i.e. with a thread count of 1).</p>
<p>When running on CPUs or Xeon Phi, the <em>host</em> and <em>device</em> values work
identically. When using GPUs, the <em>device</em> value will typically be
optimal if all of your styles used in your input script are supported
by the KOKKOS package. In this case data can stay on the GPU for many
timesteps without being moved between the host and GPU, if you use the
<em>device</em> value. This requires that your MPI is able to access GPU
memory directly. Currently that is true for OpenMPI 1.8 (or later
versions), Mvapich2 1.9 (or later), and CrayMPI. If your script uses
styles (e.g. fixes) which are not yet supported by the KOKKOS package,
then data has to be move between the host and device anyway, so it is
typically faster to let the host handle communication, by using the
<em>host</em> value. Using <em>host</em> instead of <em>no</em> will enable use of
multiple threads to pack/unpack communicated data.</p>
<hr class="docutils" />
<p>The <em>omp</em> style invokes settings associated with the use of the
USER-OMP package.</p>
<p>The <em>Nthread</em> argument sets the number of OpenMP threads allocated for
each MPI task. For example, if your system has nodes with dual
quad-core processors, it has a total of 8 cores per node. You could
use two MPI tasks per node (e.g. using the -ppn option of the mpirun
command in MPICH or -npernode in OpenMPI), and set <em>Nthreads</em> = 4.
This would use all 8 cores on each node. Note that the product of MPI
tasks * threads/task should not exceed the physical number of cores
(on a node), otherwise performance will suffer.</p>
<p>Setting <em>Nthread</em> = 0 instructs LAMMPS to use whatever value is the
default for the given OpenMP environment. This is usually determined
via the <em>OMP_NUM_THREADS</em> environment variable or the compiler
runtime. Note that in most cases the default for OpenMP capable
compilers is to use one thread for each available CPU core when
<em>OMP_NUM_THREADS</em> is not explicitly set, which can lead to poor
performance.</p>
<p>Here are examples of how to set the environment variable when
<p>or you can set it permanently in your shell’s start-up script.
All three of these examples use a total of 4 CPU cores.</p>
<p>Note that different MPI implementations have different ways of passing
the OMP_NUM_THREADS environment variable to all MPI processes. The
2nd example line above is for MPICH; the 3rd example line with -x is
for OpenMPI. Check your MPI documentation for additional details.</p>
<p>What combination of threads and MPI tasks gives the best performance
is difficult to predict and can depend on many components of your
input. Not all features of LAMMPS support OpenMP threading via the
USER-OMP packaage and the parallel efficiency can be very different,
too.</p>
<p>Optional keyword/value pairs can also be specified. Each has a
default value as listed below.</p>
<p>The <em>neigh</em> keyword specifies whether neighbor list building will be
multi-threaded in addition to force calculations. If <em>neigh</em> is set
to <em>no</em> then neighbor list calculation is performed only by MPI tasks
with no OpenMP threading. If <em>mode</em> is <em>yes</em> (the default), a
multi-threaded neighbor list build is used. Using <em>neigh</em> = <em>yes</em> is
almost always faster and should produce idential neighbor lists at the
expense of using more memory. Specifically, neighbor list pages are
allocated for all threads at the same time and each thread works
within its own pages.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions<a class="headerlink" href="#restrictions" title="Permalink to this headline">¶</a></h2>
<p>This command cannot be used after the simulation box is defined by a
<a class="reference internal" href="read_data.html"><em>read_data</em></a> or <a class="reference internal" href="create_box.html"><em>create_box</em></a> command.</p>
<p>The cuda style of this command can only be invoked if LAMMPS was built
with the USER-CUDA package. See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info.</p>
<p>The gpu style of this command can only be invoked if LAMMPS was built
with the GPU package. See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info.</p>
<p>The intel style of this command can only be invoked if LAMMPS was
built with the USER-INTEL package. See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info.</p>
<p>The kk style of this command can only be invoked if LAMMPS was built
with the KOKKOS package. See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info.</p>
<p>The omp style of this command can only be invoked if LAMMPS was built
with the USER-OMP package. See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info.</p>
</div>
<div class="section" id="related-commands">
<h2>Related commands<a class="headerlink" href="#related-commands" title="Permalink to this headline">¶</a></h2>
<h2>Default<a class="headerlink" href="#default" title="Permalink to this headline">¶</a></h2>
<p>For the USER-CUDA package, the default is Ngpu = 1 and the option
defaults are newton = off, gpuID = 0 to Ngpu-1, timing = not enabled,
test = not enabled, and thread = auto. These settings are made
automatically by the required “-c on” <a class="reference internal" href="Section_start.html#start-7"><span>command-line switch</span></a>. You can change them bu using the
package cuda command in your input script or via the “-pk cuda”
<p>For the GPU package, the default is Ngpu = 1 and the option defaults
are neigh = yes, newton = off, binsize = 0.0, split = 1.0, gpuID = 0
to Ngpu-1, tpa = 1, and device = not used. These settings are made
automatically if the “-sf gpu” <a class="reference internal" href="Section_start.html#start-7"><span>command-line switch</span></a> is used. If it is not used, you
must invoke the package gpu command in your input script or via the
240. The default ghost option is determined by the pair style being
used. This value is output to the screen in the offload report at the
end of each run. Note that all of these settings, except “omp” and
“mode”, are ignored if LAMMPS was not built with Xeon Phi coprocessor
support. These settings are made automatically if the “-sf intel”
<a class="reference internal" href="Section_start.html#start-7"><span>command-line switch</span></a> is used. If it is
not used, you must invoke the package intel command in your input
script or or via the “-pk intel” <a class="reference internal" href="Section_start.html#start-7"><span>command-line switch</span></a>.</p>
<p>For the KOKKOS package, the option defaults neigh = full, newton =
off, binsize = 0.0, and comm = host. These settings are made
automatically by the required “-k on” <a class="reference internal" href="Section_start.html#start-7"><span>command-line switch</span></a>. You can change them bu using the
package kokkos command in your input script or via the “-pk kokkos”
<p>For the OMP package, the default is Nthreads = 0 and the option
defaults are neigh = yes. These settings are made automatically if
the “-sf omp” <a class="reference internal" href="Section_start.html#start-7"><span>command-line switch</span></a> is
used. If it is not used, you must invoke the package omp command in
your input script or via the “-pk omp” <a class="reference internal" href="Section_start.html#start-7"><span>command-line switch</span></a>.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<span id="index-0"></span><h1>pair_style lj/cubic command<a class="headerlink" href="#pair-style-lj-cubic-command" title="Permalink to this headline">¶</a></h1>
<p>The location of the inflection point rs is defined
by the LJ diameter, rs/sigma = (26/7)^1/6. The cutoff distance
is defined by rc/rs = 67/48 or rc/sigma = 1.737....
The analytic expression for the
the cubic coefficient
A3*rmin^3/epsilon = 27.93... is given in the paper by
Holian and Ravelo <a class="reference internal" href="#holian"><span>(Holian)</span></a>.</p>
<p>This potential is commonly used to study the shock mechanics
of FCC solids, as in Ravelo et al. <a class="reference internal" href="#ravelo"><span>(Ravelo)</span></a>.</p>
<p>The following coefficients must be defined for each pair of atom
types via the <a class="reference internal" href="pair_coeff.html"><em>pair_coeff</em></a> command as in the example
above, or in the data file or restart files read by the
<a class="reference internal" href="read_data.html"><em>read_data</em></a> or <a class="reference internal" href="read_restart.html"><em>read_restart</em></a>
commands, or by mixing as described below:</p>
<ul class="simple">
<li>epsilon (energy units)</li>
<li>sigma (distance units)</li>
</ul>
<p>Note that sigma is defined in the LJ formula as the zero-crossing
distance for the potential, not as the energy minimum, which
is located at rmin = 2^(1/6)*sigma. In the above example, sigma = 0.8908987,
so rmin = 1.</p>
<hr class="docutils" />
<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
KOKKOS, USER-OMP and OPT packages, respectively. They are only
enabled if LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span>-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><em>suffix</em></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
since pair interaction is already smoothed to 0.0 at the
cutoff.</p>
<p>The <a class="reference internal" href="pair_modify.html"><em>pair_modify</em></a> table option is not relevant
for this pair style.</p>
<p>The lj/cubic pair style does not support the
<a class="reference internal" href="pair_modify.html"><em>pair_modify</em></a> tail option for adding long-range tail
corrections to energy and pressure, since there are no corrections for
a potential that goes to 0.0 at the cutoff.</p>
<p>The lj/cubic pair style writes its information to <a class="reference internal" href="restart.html"><em>binary restart files</em></a>, so pair_style and pair_coeff commands do
not need to be specified in an input script that reads a restart file.</p>
<p>The lj/cubic pair style can only be used via the <em>pair</em>
keyword of the <a class="reference internal" href="run_style.html"><em>run_style respa</em></a> command. It does not
support the <em>inner</em>, <em>middle</em>, <em>outer</em> keywords.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions<a class="headerlink" href="#restrictions" title="Permalink to this headline">¶</a></h2>
<blockquote>
<div>none</div></blockquote>
</div>
<div class="section" id="related-commands">
<h2>Related commands<a class="headerlink" href="#related-commands" title="Permalink to this headline">¶</a></h2>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<span id="index-0"></span><h1>pair_style tersoff command<a class="headerlink" href="#pair-style-tersoff-command" title="Permalink to this headline">¶</a></h1>
<h1>pair_style tersoff/table/omp command<a class="headerlink" href="#pair-style-tersoff-table-omp-command" title="Permalink to this headline">¶</a></h1>
<div class="section" id="syntax">
<h2>Syntax<a class="headerlink" href="#syntax" title="Permalink to this headline">¶</a></h2>
-<p>style = <em>tersoff</em> or <em>tersoff/table</em> or <em>tersoff/cuda</em> or <em>tersoff/omp</em> or <em>tersoff/table/omp</em></p>
+<p>style = <em>tersoff</em> or <em>tersoff/table</em> or <em>tersoff/cuda</em> or <em>tersoff/gpu</em> or <em>tersoff/omp</em> or <em>tersoff/table/omp</em></p>
</div>
<div class="section" id="examples">
<h2>Examples<a class="headerlink" href="#examples" title="Permalink to this headline">¶</a></h2>
<p>Tersoff_2 parameters R and S must be converted to the LAMMPS
parameters R and D (R is different in both forms), using the following
relations: R=(R’+S’)/2 and D=(S’-R’)/2, where the primes indicate the
Tersoff_2 parameters.</p>
<p>In the potentials directory, the file SiCGe.tersoff provides the
LAMMPS parameters for Tersoff’s various versions of Si, as well as his
alloy parameters for Si, C, and Ge. This file can be used for pure Si,
(three different versions), pure C, pure Ge, binary SiC, and binary
SiGe. LAMMPS will generate an error if this file is used with any
combination involving C and Ge, since there are no entries for the GeC
interactions (Tersoff did not publish parameters for this
cross-interaction.) Tersoff files are also provided for the SiC alloy
(SiC.tersoff) and the GaN (GaN.tersoff) alloys.</p>
<p>Many thanks to Rutuparna Narulkar, David Farrell, and Xiaowang Zhou
for helping clarify how Tersoff parameters for alloys have been
defined in various papers.</p>
<hr class="docutils" />
<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
KOKKOS, USER-OMP and OPT packages, respectively. They are only
enabled if LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span>-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><em>suffix</em></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>For atom type pairs I,J and I != J, where types I and J correspond to
two different element types, mixing is performed by LAMMPS as
described above from values in the potential file.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><em>pair_modify</em></a>
shift, table, and tail options.</p>
<p>This pair style does not write its information to <a class="reference internal" href="restart.html"><em>binary restart files</em></a>, since it is stored in potential files. Thus, you
need to re-specify the pair_style and pair_coeff commands in an input
script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><em>run_style respa</em></a> command. It does not support the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>where e is the electron charge, epsilon_0 is the electrical
permittivity of vacuum, and Z_i and Z_j are the nuclear charges of the
two atoms. The switching function S(r) is identical to that used by
<a class="reference internal" href="pair_gromacs.html"><em>pair_style lj/gromacs</em></a>. Here, the inner and outer
cutoff are the same for all pairs of atom types.</p>
<p>The following coefficient must be defined for each pair of atom types
via the <a class="reference internal" href="pair_coeff.html"><em>pair_coeff</em></a> command as in the examples above,
or in the LAMMPS data file. Z can not be specified for two different
atoms types. Therefore the lists of atom types I and atom types J
must match.</p>
<ul class="simple">
<li>Z (multiples of proton charge, e.g. 13.0 for aluminum)</li>
</ul>
<p>Although Z must be defined for all atom type pairs I,J, it is only
stored for individual atom types, i.e. when I = J. Z is normally equal
to the atomic number of the atom type.</p>
<div class="admonition warning">
<p class="first admonition-title">Warning</p>
<p class="last">The numerical values of the exponential decay
constants in the screening function depend on the unit of distance. In
the above equation they are given for units of angstroms. LAMMPS will
automatically convert these values to the distance unit of the
specified LAMMPS <a class="reference internal" href="units.html"><em>units</em></a> setting. The values of Z should
always be given as multiples of a proton’s charge, e.g. 29.0 for
copper.</p>
</div>
<hr class="docutils" />
<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a>
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.</p>
<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
KOKKOS, USER-OMP and OPT packages, respectively. They are only
enabled if LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info.</p>
<p>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span>-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
use the <a class="reference internal" href="suffix.html"><em>suffix</em></a> command in your input script.</p>
<p>See <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a> of the manual for
more instructions on how to use the accelerated styles effectively.</p>
<p>Mixing is not relevant for this pair style, since as explained above,
Z values are stored on a per-type basis, and both Zi and Zj are used
explicitly in the ZBL formula.</p>
<p>The ZBL pair style does not support the <a class="reference internal" href="pair_modify.html"><em>pair_modify</em></a>
shift option, since the ZBL interaction is already smoothed to 0.0 at
the cutoff.</p>
<p>The <a class="reference internal" href="pair_modify.html"><em>pair_modify</em></a> table option is not relevant for
this pair style.</p>
<p>This pair style does not support the <a class="reference internal" href="pair_modify.html"><em>pair_modify</em></a>
tail option for adding long-range tail corrections to energy and
pressure, since there are no corrections for a potential that goes to
0.0 at the cutoff.</p>
<p>This pair style does not write information to <a class="reference internal" href="restart.html"><em>binary restart files</em></a>, so pair_style and pair_coeff commands must be
specified in an input script that reads a restart file.</p>
<p>This pair style can only be used via the <em>pair</em> keyword of the
<a class="reference internal" href="run_style.html"><em>run_style respa</em></a> command. It does not support the
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
// The global parallel_reduce does not support vector_length other than 1 at the moment
if(policy.vector_length() > 1)
Impl::throw_runtime_exception( "Kokkos::parallel_reduce with a TeamPolicy using a vector length of greater than 1 is not currently supported for CUDA.");
// Functor's reduce memory, team scan memory, and team shared memory depend upon team size.
const int shmem_size_total = m_team_begin + m_shmem_begin + m_shmem_size ;
# error "At least one of the following host execution spaces must be defined: Kokkos::OpenMP, Kokkos::Serial, or Kokkos::Threads. You might be seeing this message if you disabled the Kokkos::Serial device explicitly using the Kokkos_ENABLE_Serial:BOOL=OFF CMake option, but did not enable any of the other host execution space devices."
-\mainpage Trilinos/Kokkos: Shared-memory programming interface and computational kernels
-
-\section Kokkos_Intro Introduction
-
-The %Kokkos package has two main components. The first, sometimes
-called "%Kokkos Array" or just "%Kokkos," implements a
-performance-portable shared-memory parallel programming model and data
-containers. The second, called "%Kokkos Classic," consists of
-computational kernels that support the %Tpetra package.
-
-\section Kokkos_Kokkos The %Kokkos programming model
-
-%Kokkos implements a performance-portable shared-memory parallel
-programming model and data containers. It lets you write an algorithm
-once, and just change a template parameter to get the optimal data
-layout for your hardware. %Kokkos has back-ends for the following
-parallel programming models:
-
-- Kokkos::Threads: POSIX Threads (Pthreads)
-- Kokkos::OpenMP: OpenMP
-- Kokkos::Cuda: NVIDIA's CUDA programming model for graphics
- processing units (GPUs)
-- Kokkos::Serial: No thread parallelism
-
-%Kokkos also has optimizations for shared-memory parallel systems with
-nonuniform memory access (NUMA). Its containers can hold data of any
-primitive ("plain old") data type (and some aggregate types). %Kokkos
-Array may be used as a stand-alone programming model.
-
-%Kokkos' parallel operations include the following:
-
-- parallel_for: a thread-parallel "for loop"
-- parallel_reduce: a thread-parallel reduction
-- parallel_scan: a thread-parallel prefix scan operation
-
-as well as expert-level platform-independent interfaces to thread
-"teams," per-team "shared memory," synchronization, and atomic update
-operations.
-
-%Kokkos' data containers include the following:
-
-- Kokkos::View: A multidimensional array suitable for thread-parallel
- operations. Its layout (e.g., row-major or column-major) is
- optimized by default for the particular thread-parallel device.
-- Kokkos::Vector: A drop-in replacement for std::vector that eases
- porting from standard sequential C++ data structures to %Kokkos'
- parallel data structures.
-- Kokkos::UnorderedMap: A parallel lookup table comparable in
- functionality to std::unordered_map.
-
-%Kokkos also uses the above basic containers to implement higher-level
-data structures, like sparse graphs and matrices.
-
-A good place to start learning about %Kokkos would be <a href="http://trilinos.sandia.gov/events/trilinos_user_group_2013/presentations/2013-11-TUG-Kokkos-Tutorial.pdf">these tutorial slides</a> from the 2013 Trilinos Users' Group meeting.
-
-\section Kokkos_Classic %Kokkos Classic
-
-"%Kokkos Classic" consists of computational kernels that support the
-%Tpetra package. These kernels include sparse matrix-vector multiply,
-sparse triangular solve, Gauss-Seidel, and dense vector operations.
-They are templated on the type of objects (\c Scalar) on which they
-operate. This component was not meant to be visible to users; it is
-an implementation detail of the %Tpetra distributed linear algebra
-package.
-
-%Kokkos Classic also implements a shared-memory parallel programming
-model. This inspired and preceded the %Kokkos programming model
-described in the previous section. Users should consider the %Kokkos
-Classic programming model deprecated, and prefer the new %Kokkos
- This is not a realistic simulation of a protein in a lipid membrane.
- When I released this example in 2013, the simulations ran without crashing and produced no obvious visual flaws. However recently (2015) I've noticed that there are some serious problems: Currently, the protein no-longer remains perpendicular to the membrane during the simulations. (In some cases, it also unfolds.) The original version of this example did not behave this way. I'm not sure what changed since then.
+ This is not a realistic simulation of proteins in a lipid membrane. This
+example was only intented to be a technical demonstration to show how to
+combine totally different kinds of coarse-grained molecules (with different
+kinds of force-fields) together in the same simulation in LAMMPS. Tuning the
+force-field parameters to get realistic results was not the goal. I did
+not take the extra time to do this. If you have suggestions for changes,
+please email me (jewett.aij at gmail dot com).
- This example was created to demonstrate how to combine totally different kinds of coarse-grained molecules (with different kinds of force-fields) together in the same simulation in LAMMPS. Tuning the force-field parameters to get realistic results was not the goal.
-
- One day I might tinker with the shape of the protein and the force-field parameters to try and avoid this unsightly outcome. (Probably shortening the length of the helices would help.) Either way, I doubt it would make the simulations any more accurate.
-
- I apologize that the simulations no longer produce the same pretty images shown on the web page.
- This is not a realistic simulation of proteins in a lipid membrane.
- When I released this example in 2013, the simulations ran without crashing and produced no obvious visual flaws. However recently (2015) I've noticed that there are some serious problems: Currently, the protein no-longer remains perpendicular to the membrane during the simulations. (In some cases, it also unfolds.) The original version of this example did not behave this way. I'm not sure what changed since then.
+ This is not a realistic simulation of proteins in a lipid membrane. This
+example was only intented to be a technical demonstration to show how to
+combine totally different kinds of coarse-grained molecules (with different
+kinds of force-fields) together in the same simulation in LAMMPS. Tuning the
+force-field parameters to get realistic results was not the goal. I did
+not take the extra time to do this. If you have suggestions for changes,
+please email me (jewett.aij at gmail dot com).
- In addition, I have also noticed that newer versions of PACKMOL do not always succeed at generating a spherical vesicle in a reasonable amount of time. (You will probably have to play with the .inp files in the packmol_files directory to get PACKMOL to produce any files at all.)
+ In addition, I have noticed that newer versions of PACKMOL do not
+always succeed at generating a spherical vesicle in a reasonable amount of time.
+(You may have to play with the .inp files in the packmol_files directory
+ to get PACKMOL to produce any files at all.
- This example was created to demonstrate how to combine totally different kinds of coarse-grained molecules (with different kinds of force-fields) together in the same simulation in LAMMPS. Tuning the force-field parameters to get realistic results was not the goal.
+(NOTE: This example also demonstrantes how to use an external program
+ ("packmol") to generate the coordinates for the atoms in the system.
+ PLEASE USE "packmol", NOT "ppackmol". -the parallel version of "packmol".
+ This is because "ppackmol" is more likely to get caught in infinite loops.)
- One day I might tinker with the shape of the protein and the force-field parameters to try and avoid this unsightly outcome. (Probably shortening the length of the helices would help.) Either way, I doubt it would make the simulations any more accurate.
-
- I apologize that the simulations no longer produce the same pretty images shown on the web page.