replace "xxxn't" with "xxx not"

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

does not catch that you think it should flag, please send an email to

the `developers <https://lammps.sandia.gov/authors.html>`_.

If you get an error message about an invalid command in your input

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

limited, so this should not 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.

parallel), since LAMMPS does not trap on those errors.

Illegal arithmetic can cause LAMMPS to run slow or crash.  This is

typically due to invalid physics and numerics that your simulation is

   The command is accessing a vector added by the fix property/atom

   command, that does not exist.

*Compute property/atom for atom property that isn't allocated*

*Compute property/atom for atom property that is not allocated*

   Self-explanatory.

*Compute property/atom integer vector does not exist*

*Compute property/local does not (yet) work with atom_style template*

   Self-explanatory.

*Compute property/local for property that isn't allocated*

*Compute property/local for property that is not allocated*

   Self-explanatory.

*Compute rdf requires a pair style be defined*

*Dump_modify region ID does not exist*

   Self-explanatory.

*Dumping an atom property that isn't allocated*

*Dumping an atom property that is not allocated*

   The chosen atom style does not define the per-atom quantity being

   dumped.

*Energy was not tallied on needed timestep*

   You are using a thermo keyword that requires potentials to

   have tallied energy, but they didn't on this timestep.  See the

   have tallied energy, but they did not on this timestep.  See the

   variable doc page for ideas on how to make this work.

*Epsilon or sigma reference not set by pair style in PPPMDisp*

   Fixes that calculate global or local quantities cannot be used with

   fix store/state.

*Fix store/state for atom property that isn't allocated*

*Fix store/state for atom property that is not allocated*

   Self-explanatory.

*Fix store/state variable is not atom-style variable*

*Invalid LAMMPS restart file*

   The file does not appear to be a LAMMPS restart file since

   it doesn't contain the correct magic string at the beginning.

   it does not contain the correct magic string at the beginning.

*Invalid Masses section in molecule file*

   Self-explanatory.

*Pair hybrid sub-style does not support single call*

   You are attempting to invoke a single() call on a pair style

   that doesn't support it.

   that does not support it.

*Pair hybrid sub-style is not used*

   No pair_coeff command used a sub-style specified in the pair_style

*Per-atom energy was not tallied on needed timestep*

   You are using a thermo keyword that requires potentials to

   have tallied energy, but they didn't on this timestep.  See the

   have tallied energy, but they did not on this timestep.  See the

   variable doc page for ideas on how to make this work.

*Per-atom fix in equal-style variable formula*

*Per-atom virial was not tallied on needed timestep*

   You are using a thermo keyword that requires potentials to have

   tallied the virial, but they didn't on this timestep.  See the

   tallied the virial, but they did not on this timestep.  See the

   variable doc page for ideas on how to make this work.

*Per-processor system is too big*

   It cannot be larger than the size of atom IDs, e.g. the maximum 32-bit

   integer.

*Read dump of atom property that isn't allocated*

*Read dump of atom property that is not allocated*

   Self-explanatory.

*Read rerun dump file timestep > specified stop*

   creates one large file for all processors.

*Restart file byte ordering is not recognized*

   The file does not appear to be a LAMMPS restart file since it doesn't

   The file does not appear to be a LAMMPS restart file since it does not

   contain a recognized byte-ordering flag at the beginning.

*Restart file byte ordering is swapped*

   Keywords that refer to time (such as cpu, elapsed) do not

   make sense in between runs.

*Threshhold for an atom property that isn't allocated*

*Threshhold for an atom property that is not allocated*

   A dump threshold has been requested on a quantity that is

   not defined by the atom style used in this simulation.

*Variable name must be alphanumeric or underscore characters*

   Self-explanatory.

*Variable uses atom property that isn't allocated*

*Variable uses atom property that is not allocated*

   Self-explanatory.

*Velocity command before simulation box is defined*

*Virial was not tallied on needed timestep*

   You are using a thermo keyword that requires potentials to

   have tallied the virial, but they didn't on this timestep.  See the

   have tallied the virial, but they did not on this timestep.  See the

   variable doc page for ideas on how to make this work.

*Voro++ error: narea and neigh have a different size*

   This is because LAMMPS does not compute the Lennard-Jones interactions

   with these particles for efficiency reasons.

*World variable count doesn't match # of partitions*

*World variable count does not match # of partitions*

   A world-style variable must specify a number of values equal to the

   number of processor partitions.

.. image:: JPG/tutorial_reverse_pull_request.png

   :align: center

For some reason, the highlighted button didn't work in my case, but I

For some reason, the highlighted button did not work in my case, but I

can go to my own repository and merge the pull request from there:

.. image:: JPG/tutorial_reverse_pull_request2.png

The advantage of C++ and its object-orientation is that all the code

and variables needed to define the new feature are in the 2 files you

write, and thus shouldn't make the rest of LAMMPS more complex or

write, and thus should not make the rest of LAMMPS more complex or

cause side-effect bugs.

Here is a concrete example.  Suppose you write 2 files pair_foo.cpp

   make install

This will also install the Python module into your virtualenv. Since virtualenv

doesn't change your LD_LIBRARY_PATH, you still need to add its lib64 folder to

does not change your LD_LIBRARY_PATH, you still need to add its lib64 folder to

it, which contains the installed liblammps.so.

.. code-block:: bash