<p>If two LAMMPS runs do not produce the same answer on different
machines or different numbers of processors, this is typically not a
bug. 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 within a few 100s or few 1000s of timesteps.
However, the statistical properties of the two runs (e.g. average
energy or temperature) should still be the same.</p>
<p>If the <a class="reference internal" href="velocity.html"><span class="doc">velocity</span></a> command is used to set initial atom
velocities, a particular atom can be assigned a different velocity
when the problem is run on a different number of processors or on
different machines. If this happens, the phase space trajectories of
the two simulations will rapidly diverge. See the discussion of the
<em>loop</em> option in the <a class="reference internal" href="velocity.html"><span class="doc">velocity</span></a> command for details and
options that avoid this issue.</p>
<p>Similarly, the <a class="reference internal" href="create_atoms.html"><span class="doc">create_atoms</span></a> command generates a
lattice of atoms. For the same physical system, the ordering and
numbering of atoms by atom ID may be different depending on the number
of processors.</p>
<p>Some commands use random number generators which may be setup to
produce different random number streams on each processor and hence
will produce different effects when run on different numbers of
processors. A commonly-used example is the <a class="reference internal" href="fix_langevin.html"><span class="doc">fix langevin</span></a> command for thermostatting.</p>
<p>A LAMMPS simulation typically has two stages, setup and run. Most
LAMMPS errors are detected at setup time; others like a bond
stretching too far may not occur until the middle of a run.</p>
<p>LAMMPS tries to flag errors and print informative error messages so
you can fix the problem. Of course, LAMMPS cannot figure out your
physics or numerical mistakes, like choosing too big a timestep,
specifying erroneous force field coefficients, or putting 2 atoms on
top of each other! If you run into errors that LAMMPS doesn’t catch
that you think it should flag, please send an email to the
<p>If you get an error message about an invalid command in your input
script, you can determine what command is causing the problem by
looking in the log.lammps file or using the <a class="reference internal" href="echo.html"><span class="doc">echo command</span></a>
to see it on the screen. If you get an error like “Invalid ...
style”, with ... being fix, compute, pair, etc, it means that you
mistyped the style name or that the command is part of an optional
package which was not compiled into your executable. The list of
available styles in your executable can be listed by using <span class="xref std std-ref">the -h command-line argument</span>. The installation
and compilation of optional packages is explained in the <span class="xref std std-ref">installation instructions</span>.</p>
<p>For a given command, LAMMPS expects certain arguments in a specified
order. If you mess this up, LAMMPS will often flag the error, but it
may also simply read a bogus argument and assign a value that is
valid, but not what you wanted. E.g. trying to read the string “abc”
as an integer value of 0. Careful reading of the associated doc page
for the command should allow you to fix these problems. Note that
some commands allow for variables to be specified in place of numeric
constants so that the value can be evaluated and change over the
course of a run. This is typically done with the syntax <em>v_name</em> for
a parameter, where name is the name of the variable. This is only
allowed if the command documentation says it is.</p>
<p>Generally, LAMMPS will print a message to the screen and logfile and
exit gracefully when it encounters a fatal error. Sometimes it will
print a WARNING to the screen and logfile and continue on; you can
decide if the WARNING is important or not. A WARNING message that is
generated in the middle of a run is only printed to the screen, not to
the logfile, to avoid cluttering up thermodynamic output. If LAMMPS
crashes or hangs without spitting out an error message first then it
could be a bug (see <a class="reference internal" href="#err-2"><span class="std std-ref">this section</span></a>) or one of the following
cases:</p>
<p>LAMMPS runs in the available memory a processor allows to be
allocated. Most reasonable MD runs are compute limited, not memory
limited, so this shouldn’t be a bottleneck on most platforms. Almost
all large memory allocations in the code are done via C-style malloc’s
which will generate an error message if you run out of memory.
Smaller chunks of memory are allocated via C++ “new” statements. If
you are unlucky you could run out of memory just when one of these
small requests is made, in which case the code will crash or hang (in
parallel), since LAMMPS doesn’t trap on those errors.</p>
<p>Illegal arithmetic can cause LAMMPS to run slow or crash. This is
typically due to invalid physics and numerics that your simulation is
computing. If you see wild thermodynamic values or NaN values in your
LAMMPS output, something is wrong with your simulation. If you
suspect this is happening, it is a good idea to print out
thermodynamic info frequently (e.g. every timestep) via the
<a class="reference internal" href="thermo.html"><span class="doc">thermo</span></a> so you can monitor what is happening.
Visualizing the atom movement is also a good idea to insure your model
is behaving as you expect.</p>
<p>In parallel, one way LAMMPS can hang is due to how different MPI
implementations handle buffering of messages. If the code hangs
without an error message, it may be that you need to specify an MPI
setting or two (usually via an environment variable) to enable
buffering or boost the sizes of messages that can be buffered.</p>
<hr class="docutils" />
</div>
<div class="section" id="reporting-bugs">
<span id="err-2"></span><h2>Reporting bugs</h2>
<p>If you are confident that you have found a bug in LAMMPS, follow these
steps.</p>
<p>Check the <a class="reference external" href="http://lammps.sandia.gov/bug.html">New features and bug fixes</a> section of the <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW site</a> to see if the bug has already been reported or fixed or the
<a class="reference external" href="http://lammps.sandia.gov/unbug.html">Unfixed bug</a> to see if a fix is
pending.</p>
<p>Check the <a class="reference external" href="http://lammps.sandia.gov/mail.html">mailing list</a>
to see if it has been discussed before.</p>
<p>If not, send an email to the mailing list describing the problem with
any ideas you have as to what is causing it or where in the code the
problem might be. The developers will ask for more info if needed,
such as an input script or data files.</p>
<p>The most useful thing you can do to help us fix the bug is to isolate
the problem. Run it on the smallest number of atoms and fewest number
of processors and with the simplest input script that reproduces the
bug and try to identify what command or combination of commands is
causing the problem.</p>
<p>As a last resort, you can send an email directly to the
<dd>This is not allowed if the kspace_modify overlap setting is no.</dd>
<dt><em>PPPM order < minimum allowed order</em></dt>
<dd>The default minimum order is 2. This can be reset by the
kspace_modify minorder command.</dd>
<dt><em>PPPM order cannot be < 2 or > than %d</em></dt>
<dd>This is a limitation of the PPPM implementation in LAMMPS.</dd>
<dt><em>PPPMDisp Coulomb grid is too large</em></dt>
<dd>The global PPPM grid is larger than OFFSET in one or more dimensions.
OFFSET is currently set to 4096. You likely need to decrease the
requested accuracy.</dd>
<dt><em>PPPMDisp Dispersion grid is too large</em></dt>
<dd>The global PPPM grid is larger than OFFSET in one or more dimensions.
OFFSET is currently set to 4096. You likely need to decrease the
requested accuracy.</dd>
<dt><em>PPPMDisp can only currently be used with comm_style brick</em></dt>
<dd>This is a current restriction in LAMMPS.</dd>
<dt><em>PPPMDisp coulomb order cannot be greater than %d</em></dt>
<dd>This is a limitation of the PPPM implementation in LAMMPS.</dd>
<dt><em>PPPMDisp used but no parameters set, for further information please see the pppm/disp documentation</em></dt>
<dd>An efficient and accurate usage of the pppm/disp requires settings via the kspace_modify command. Please see the pppm/disp documentation for further instructions.</dd>
<dt><em>PRD command before simulation box is defined</em></dt>
<dd>The prd command cannot be used before a read_data,
read_restart, or create_box command.</dd>
<dt><em>PRD nsteps must be multiple of t_event</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>PRD t_corr must be multiple of t_event</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Package command after simulation box is defined</em></dt>
<dd>The package command cannot be used afer a read_data, read_restart, or
create_box command.</dd>
<dt><em>Package cuda command without USER-CUDA package enabled</em></dt>
<dd>The USER-CUDA package must be installed via “make yes-user-cuda”
before LAMMPS is built, and the “-c on” must be used to enable the
package.</dd>
<dt><em>Package gpu command without GPU package installed</em></dt>
<dd>The GPU package must be installed via “make yes-gpu” before LAMMPS is
built.</dd>
<dt><em>Package intel command without USER-INTEL package installed</em></dt>
<dd>The USER-INTEL package must be installed via “make yes-user-intel”
before LAMMPS is built.</dd>
<dt><em>Package kokkos command without KOKKOS package enabled</em></dt>
<dd>The KOKKOS package must be installed via “make yes-kokkos” before
LAMMPS is built, and the “-k on” must be used to enable the package.</dd>
<dt><em>Package omp command without USER-OMP package installed</em></dt>
<dd>The USER-OMP package must be installed via “make yes-user-omp” before
LAMMPS is built.</dd>
<dt><em>Pair body requires atom style body</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Pair body requires body style nparticle</em></dt>
<dd>This pair style is specific to the nparticle body style.</dd>
<dt><em>Pair brownian requires atom style sphere</em></dt>
<dd>You specified an inner cutoff for a Coulombic table that is longer
than the global cutoff. Probably not what you wanted.</dd>
<dt><em>Temperature for MSST is not for group all</em></dt>
<dd>User-assigned temperature to MSST fix does not compute temperature for
all atoms. Since MSST computes a global pressure, the kinetic energy
contribution from the temperature is assumed to also be for all atoms.
Thus the pressure used by MSST could be inaccurate.</dd>
<dt><em>Temperature for NPT is not for group all</em></dt>
<dd>User-assigned temperature to NPT fix does not compute temperature for
all atoms. Since NPT computes a global pressure, the kinetic energy
contribution from the temperature is assumed to also be for all atoms.
Thus the pressure used by NPT could be inaccurate.</dd>
<dt><em>Temperature for fix modify is not for group all</em></dt>
<dd>The temperature compute is being used with a pressure calculation
which does operate on group all, so this may be inconsistent.</dd>
<dt><em>Temperature for thermo pressure is not for group all</em></dt>
<dd>User-assigned temperature to thermo via the thermo_modify command does
not compute temperature for all atoms. Since thermo computes a global
pressure, the kinetic energy contribution from the temperature is
assumed to also be for all atoms. Thus the pressure printed by thermo
could be inaccurate.</dd>
<dt><em>The fix ave/spatial command has been replaced by the more flexible fix ave/chunk and compute chunk/atom commands – fix ave/spatial will be removed in the summer of 2015</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>The minimizer does not re-orient dipoles when using fix efield</em></dt>
<dd>This means that only the atom coordinates will be minimized,
not the orientation of the dipoles.</dd>
<dt><em>Too many common neighbors in CNA %d times</em></dt>
<dd>More than the maximum # of neighbors was found multiple times. This
was unexpected.</dd>
<dt><em>Too many inner timesteps in fix ttm</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Too many neighbors in CNA for %d atoms</em></dt>
<dd>More than the maximum # of neighbors was found multiple times. This
was unexpected.</dd>
<dt><em>Triclinic box skew is large</em></dt>
<dd>The displacement in a skewed direction is normally required to be less
than half the box length in that dimension. E.g. the xy tilt must be
between -half and +half of the x box length. You have relaxed the
constraint using the box tilt command, but the warning means that a
LAMMPS simulation may be inefficient as a result.</dd>
<dt><em>Use special bonds = 0,1,1 with bond style fene</em></dt>
<dd>Most FENE models need this setting for the special_bonds command.</dd>
<dt><em>Use special bonds = 0,1,1 with bond style fene/expand</em></dt>
<dd>Most FENE models need this setting for the special_bonds command.</dd>
<dt><em>Using a manybody potential with bonds/angles/dihedrals and special_bond exclusions</em></dt>
<dd>This is likely not what you want to do. The exclusion settings will
eliminate neighbors in the neighbor list, which the manybody potential
needs to calculated its terms correctly.</dd>
<dt><em>Using compute temp/deform with inconsistent fix deform remap option</em></dt>
<dd>Fix nvt/sllod assumes deforming atoms have a velocity profile provided
by “remap v” or “remap none” as a fix deform option.</dd>
<dt><em>Using compute temp/deform with no fix deform defined</em></dt>
<dd>This is probably an error, since it makes little sense to use
compute temp/deform in this case.</dd>
<dt><em>Using fix srd with box deformation but no SRD thermostat</em></dt>
<dd>The deformation will heat the SRD particles so this can
be dangerous.</dd>
<dt><em>Using kspace solver on system with no charge</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Using largest cut-off for lj/long/dipole/long long long</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Using largest cutoff for buck/long/coul/long</em></dt>
<dd>Self-exlanatory.</dd>
<dt><em>Using largest cutoff for lj/long/coul/long</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Using largest cutoff for pair_style lj/long/tip4p/long</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Using package gpu without any pair style defined</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Using pair potential shift with pair_modify compute no</em></dt>
<dd>The shift effects will thus not be computed.</dd>
<dt><em>Using pair tail corrections with nonperiodic system</em></dt>
<dd>This is probably a bogus thing to do, since tail corrections are
computed by integrating the density of a periodic system out to
infinity.</dd>
<dt><em>Using pair tail corrections with pair_modify compute no</em></dt>
<dd>The tail corrections will thus not be computed.</dd>
<dt><em>pair style reax is now deprecated and will soon be retired. Users should switch to pair_style reax/c</em></dt>
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>.