<span id="err-1"></span><h2>12.1. Common problems</h2>
<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 <a class="reference internal" href="Section_start.html#start-7"><span class="std std-ref">the -h command-line argument</span></a>. The installation
and compilation of optional packages is explained in the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">installation instructions</span></a>.</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>
<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
<p>means that line #78 in the file src/velocity.cpp generated the error.
Looking in the source code may help you figure out what went wrong.</p>
<p>Note that error messages from <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">user-contributed packages</span></a> are not listed here. If such an
error occurs and is not self-explanatory, you’ll need to look in the
source code or contact the author of the package.</p>
</div>
<div class="section" id="error">
<span id="id2"></span><h2>12.4. Errors:</h2>
<dl class="docutils">
<dt><em>1-3 bond count is inconsistent</em></dt>
<dd>An inconsistency was detected when computing the number of 1-3
neighbors for each atom. This likely means something is wrong with
the bond topologies you have defined.</dd>
<dt><em>1-4 bond count is inconsistent</em></dt>
<dd>An inconsistency was detected when computing the number of 1-4
neighbors for each atom. This likely means something is wrong with
the bond topologies you have defined.</dd>
<dt><em>Accelerator sharing is not currently supported on system</em></dt>
<dd>Multiple MPI processes cannot share the accelerator on your
system. For NVIDIA GPUs, see the nvidia-smi command to change this
setting.</dd>
<dt><em>All angle coeffs are not set</em></dt>
<dd>All angle coefficients must be set in the data file or by the
angle_coeff command before running a simulation.</dd>
<dt><em>All atom IDs = 0 but atom_modify id = yes</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>All atoms of a swapped type must have same charge.</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>All atoms of a swapped type must have the same charge.</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>All bond coeffs are not set</em></dt>
<dd>All bond coefficients must be set in the data file or by the
bond_coeff command before running a simulation.</dd>
<dt><em>All dihedral coeffs are not set</em></dt>
<dd>All dihedral coefficients must be set in the data file or by the
dihedral_coeff command before running a simulation.</dd>
<dt><em>All improper coeffs are not set</em></dt>
<dd>All improper coefficients must be set in the data file or by the
improper_coeff command before running a simulation.</dd>
<dt><em>All masses are not set</em></dt>
<dd>For atom styles that define masses for each atom type, all masses must
be set in the data file or by the mass command before running a
simulation. They must also be set before using the velocity
command.</dd>
<dt><em>All mol IDs should be set for fix gcmc group atoms</em></dt>
<dd>The molecule flag is on, yet not all molecule ids in the fix group
have been set to non-zero positive values by the user. This is an
error since all atoms in the fix gcmc group are eligible for deletion,
rotation, and translation and therefore must have valid molecule ids.</dd>
<dt><em>All pair coeffs are not set</em></dt>
<dd>All pair coefficients must be set in the data file or by the
pair_coeff command before running a simulation.</dd>
<dt><em>All read_dump x,y,z fields must be specified for scaled, triclinic coords</em></dt>
<dd>For triclinic boxes and scaled coordinates you must specify all 3 of
the x,y,z fields, else LAMMPS cannot reconstruct the unscaled
coordinates.</dd>
<dt><em>All universe/uloop variables must have same # of values</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>All variables in next command must be same style</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Angle atom missing in delete_bonds</em></dt>
<dd>The delete_bonds command cannot find one or more atoms in a particular
angle on a particular processor. The pairwise cutoff is too short or
the atoms are too far apart to make a valid angle.</dd>
<dt><em>Angle atom missing in set command</em></dt>
<dd>The set command cannot find one or more atoms in a particular angle on
a particular processor. The pairwise cutoff is too short or the atoms
are too far apart to make a valid angle.</dd>
<dt><em>Angle atoms %d %d %d missing on proc %d at step %ld</em></dt>
<dd>One or more of 3 atoms needed to compute a particular angle are
missing on this processor. Typically this is because the pairwise
cutoff is set too short or the angle has blown apart and an atom is
too far away.</dd>
<dt><em>Angle atoms missing on proc %d at step %ld</em></dt>
<dd>One or more of 3 atoms needed to compute a particular angle are
missing on this processor. Typically this is because the pairwise
cutoff is set too short or the angle has blown apart and an atom is
too far away.</dd>
<dt><em>Angle coeff for hybrid has invalid style</em></dt>
<dd>Angle style hybrid uses another angle style as one of its
coefficients. The angle style used in the angle_coeff command or read
from a restart file is not recognized.</dd>
<dt><em>Angle coeffs are not set</em></dt>
<dd>No angle coefficients have been assigned in the data file or via the
angle_coeff command.</dd>
<dt><em>Angle extent > half of periodic box length</em></dt>
<dd>This error was detected by the neigh_modify check yes setting. It is
an error because the angle atoms are so far apart it is ambiguous how
it should be defined.</dd>
<dt><em>Angle potential must be defined for SHAKE</em></dt>
<dd>When shaking angles, an angle_style potential must be used.</dd>
<dt><em>Angle style hybrid cannot have hybrid as an argument</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Angle style hybrid cannot have none as an argument</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Angle style hybrid cannot use same angle style twice</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Angle table must range from 0 to 180 degrees</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Angle table parameters did not set N</em></dt>
<dd>List of angle table parameters must include N setting.</dd>
<dt><em>Angle_coeff command before angle_style is defined</em></dt>
<dd>Coefficients cannot be set in the data file or via the angle_coeff
command until an angle_style has been assigned.</dd>
<dt><em>Angle_coeff command before simulation box is defined</em></dt>
<dd>The angle_coeff command cannot be used before a read_data,
read_restart, or create_box command.</dd>
<dt><em>Angle_coeff command when no angles allowed</em></dt>
<dd>The chosen atom style does not allow for angles to be defined.</dd>
<dt><em>Angle_style command when no angles allowed</em></dt>
<dd>The chosen atom style does not allow for angles to be defined.</dd>
<dt><em>Angles assigned incorrectly</em></dt>
<dd>Angles read in from the data file were not assigned correctly to
atoms. This means there is something invalid about the topology
definitions.</dd>
<dt><em>Angles defined but no angle types</em></dt>
<dd>The data file header lists angles but no angle types.</dd>
<dt><em>Append boundary must be shrink/minimum</em></dt>
<dd>The boundary style of the face where atoms are added
must be of type m (shrink/minimum).</dd>
<dt><em>Arccos of invalid value in variable formula</em></dt>
<dd>Argument of arccos() must be between -1 and 1.</dd>
<dt><em>Arcsin of invalid value in variable formula</em></dt>
<dd>Argument of arcsin() must be between -1 and 1.</dd>
<dt><em>Assigning body parameters to non-body atom</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Assigning ellipsoid parameters to non-ellipsoid atom</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Assigning line parameters to non-line atom</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Assigning quat to non-body atom</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Assigning tri parameters to non-tri atom</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>At least one atom of each swapped type must be present to define charges.</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Atom IDs must be consecutive for velocity create loop all</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Atom IDs must be used for molecular systems</em></dt>
<dd>Atom IDs are used to identify and find partner atoms in bonds.</dd>
<dt><em>Atom count changed in fix neb</em></dt>
<dd>This is not allowed in a NEB calculation.</dd>
<dt><em>Atom count is inconsistent, cannot write data file</em></dt>
<dd>The sum of atoms across processors does not equal the global number
of atoms. Probably some atoms have been lost.</dd>
<dt><em>Atom count is inconsistent, cannot write restart file</em></dt>
<dd>Sum of atoms across processors does not equal initial total count.
This is probably because you have lost some atoms.</dd>
<dt><em>Atom in too many rigid bodies - boost MAXBODY</em></dt>
<dd>Fix poems has a parameter MAXBODY (in fix_poems.cpp) which determines
the maximum number of rigid bodies a single atom can belong to (i.e. a
multibody joint). The bodies you have defined exceed this limit.</dd>
<dt><em>Atom sort did not operate correctly</em></dt>
<dd>This is an internal LAMMPS error. Please report it to the
developers.</dd>
<dt><em>Atom sorting has bin size = 0.0</em></dt>
<dd>The neighbor cutoff is being used as the bin size, but it is zero.
Thus you must explicitly list a bin size in the atom_modify sort
command or turn off sorting.</dd>
<dt><em>Atom style hybrid cannot have hybrid as an argument</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Atom style hybrid cannot use same atom style twice</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Atom style template molecule must have atom types</em></dt>
<dd>The defined molecule(s) does not specify atom types.</dd>
<dt><em>Atom style was redefined after using fix property/atom</em></dt>
<dd>This is not allowed.</dd>
<dt><em>Atom type must be zero in fix gcmc mol command</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Atom vector in equal-style variable formula</em></dt>
<dd>Atom vectors generate one value per atom which is not allowed
in an equal-style variable.</dd>
<dt><em>Atom-style variable in equal-style variable formula</em></dt>
<dd>Atom-style variables generate one value per atom which is not allowed
in an equal-style variable.</dd>
<dt><em>Atom_modify id command after simulation box is defined</em></dt>
<dd>The atom_modify id command cannot be used after a read_data,
read_restart, or create_box command.</dd>
<dt><em>Atom_modify map command after simulation box is defined</em></dt>
<dd>The atom_modify map command cannot be used after a read_data,
read_restart, or create_box command.</dd>
<dt><em>Atom_modify sort and first options cannot be used together</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Atom_style command after simulation box is defined</em></dt>
<dd>The atom_style command cannot be used after a read_data,
read_restart, or create_box command.</dd>
<dt><em>Atom_style line can only be used in 2d simulations</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Atom_style tri can only be used in 3d simulations</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Atomfile variable could not read values</em></dt>
<dd>Check the file assigned to the variable.</dd>
<dt><em>Atomfile variable in equal-style variable formula</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Atomfile-style variable in equal-style variable formula</em></dt>
<dd>Self-explanatory.</dd>
<dt><em>Attempt to pop empty stack in fix box/relax</em></dt>
<dd>Internal LAMMPS error. Please report it to the developers.</dd>
<dt><em>Attempt to push beyond stack limit in fix box/relax</em></dt>
<dd>Internal LAMMPS error. Please report it to the developers.</dd>
<dt><em>Attempting to rescale a 0.0 temperature</em></dt>
<dd>Cannot rescale a temperature that is already 0.0.</dd>
<dt><em>Bad FENE bond</em></dt>
<dd>Two atoms in a FENE bond have become so far apart that the bond cannot
be computed.</dd>
<dt><em>Bad TIP4P angle type for PPPM/TIP4P</em></dt>
<dd>Specified angle type is not valid.</dd>
<dt><em>Bad TIP4P angle type for PPPMDisp/TIP4P</em></dt>
<dd>Specified angle type is not valid.</dd>
<dt><em>Bad TIP4P bond type for PPPM/TIP4P</em></dt>
<dd>Specified bond type is not valid.</dd>
<dt><em>Bad TIP4P bond type for PPPMDisp/TIP4P</em></dt>
<dd>Specified bond type is not valid.</dd>
<dt><em>Bad fix ID in fix append/atoms command</em></dt>
<dd>The value of the fix_id for keyword spatial must start with ‘f_’.</dd>
<dt><em>Bad grid of processors</em></dt>
<dd>The 3d grid of processors defined by the processors command does not
match the number of processors LAMMPS is being run on.</dd>
<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>.