replace "xxxn't" with "xxx not"

doc/src/Errors_common.rst

@@ -38,7 +38,7 @@ input script command that it was processing.  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
+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
@@ -96,13 +96,13 @@ cases:
 
 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

doc/src/Errors_messages.rst

@@ -2174,7 +2174,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
    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*
@@ -2191,7 +2191,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
 *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*
@@ -3091,7 +3091,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
 *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.
 
@@ -3117,7 +3117,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
 
 *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*
@@ -4125,7 +4125,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
    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*
@@ -4719,7 +4719,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
 
 *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.
@@ -6392,7 +6392,7 @@ keyword to allow for additional bonds to be formed
 
 *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
@@ -6866,7 +6866,7 @@ keyword to allow for additional bonds to be formed
 
 *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*
@@ -6874,7 +6874,7 @@ keyword to allow for additional bonds to be formed
 
 *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*
@@ -7035,7 +7035,7 @@ keyword to allow for additional bonds to be formed
    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*
@@ -7196,7 +7196,7 @@ keyword to allow for additional bonds to be formed
    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*
@@ -7666,7 +7666,7 @@ keyword to allow for additional bonds to be formed
    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.
 
@@ -8320,7 +8320,7 @@ keyword to allow for additional bonds to be formed
 *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*
@@ -8361,7 +8361,7 @@ keyword to allow for additional bonds to be formed
 
 *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*
@@ -8388,7 +8388,7 @@ keyword to allow for additional bonds to be formed
    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.
 

doc/src/Howto_github.rst

@@ -360,7 +360,7 @@ It looks something like this:
 .. 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

doc/src/Modify_overview.rst

@@ -22,7 +22,7 @@ src directory and re-building LAMMPS.
 
 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

doc/src/Python_shlib.rst

@@ -66,7 +66,7 @@ CMAKE_INSTALL_PREFIX.
    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

doc/src/compute_adf.rst

@@ -209,7 +209,7 @@ atoms further away than that distance.  If you want an ADF for larger
 distances, you can use the :doc:`rerun <rerun>` command to post-process
 a dump file and set the cutoff for the potential to be longer in the
 rerun script.  Note that in the rerun context, the force cutoff is
-arbitrary, since you aren't running dynamics and thus are not changing
+arbitrary, since you are not running dynamics and thus are not changing
 your model.
 
 Related commands

doc/src/compute_rdf.rst

@@ -180,7 +180,7 @@ atoms further away than that distance.  If you want an RDF for larger
 distances, you can use the :doc:`rerun <rerun>` command to post-process
 a dump file and set the cutoff for the potential to be longer in the
 rerun script.  Note that in the rerun context, the force cutoff is
-arbitrary, since you aren't running dynamics and thus are not changing
+arbitrary, since you are not running dynamics and thus are not changing
 your model.  The definition of g(r) used by LAMMPS is only appropriate
 for characterizing atoms that are uniformly distributed throughout the
 simulation cell. In such cases, the coordination number is still

doc/src/create_atoms.rst

@@ -200,7 +200,7 @@ not overlap, regardless of their relative orientations.
    optional keywords allowed by the :doc:`create_box <create_box>` command
    for extra bonds (angles,etc) or extra special neighbors.  This is
    because by default, the :doc:`create_box <create_box>` command sets up a
-   non-molecular system which doesn't allow molecules to be added.
+   non-molecular system which does not allow molecules to be added.
 
 ----------
 

doc/src/dump.rst

@@ -286,7 +286,7 @@ Style *custom* 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 *q* for atom style *bond*\ , since that atom style doesn't
+such as *q* for atom style *bond*\ , since that atom style does not
 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

doc/src/dump_modify.rst

@@ -520,7 +520,7 @@ includes an initial snapshot with the reference position of all atoms.
 Note that only computes with a *refresh* option will work with
 dump_modify refresh.  See individual compute doc pages for details.
 Currently, only compute displace/atom supports this option.  Others
-may be added at some point.  If you use a compute that doesn't support
+may be added at some point.  If you use a compute that does not support
 refresh operations, LAMMPS will not complain; dump_modify refresh will
 simply do nothing.
 

doc/src/fix_atom_swap.rst

@@ -108,7 +108,7 @@ non-zero molecule ID, but does not check for this at the time of
 swapping.
 
 If not using *semi-grand* this fix checks to ensure all atoms of the
-given types have the same atomic charge. LAMMPS doesn't enforce this
+given types have the same atomic charge. LAMMPS does not enforce this
 in general, but it is needed for this fix to simplify the
 swapping procedure. Successful swaps will swap the atom type and charge
 of the swapped atoms. Conversely, when using *semi-grand*\ , it is assumed that all the atom

doc/src/fix_ehex.rst

@@ -109,7 +109,7 @@ found in reference "(Wirnsberger)"#_Wirnsberger.
 
 This fix is different from a thermostat such as :doc:`fix nvt <fix_nh>`
 or :doc:`fix temp/rescale <fix_temp_rescale>` in that energy is
-added/subtracted continually.  Thus if there isn't another mechanism
+added/subtracted continually.  Thus if there is not another mechanism
 in place to counterbalance this effect, the entire system will heat or
 cool continuously.
 

doc/src/fix_heat.rst

@@ -96,7 +96,7 @@ with optional time-dependence as well.
 
 Fix heat is different from a thermostat such as :doc:`fix nvt <fix_nh>`
 or :doc:`fix temp/rescale <fix_temp_rescale>` in that energy is
-added/subtracted continually.  Thus if there isn't another mechanism
+added/subtracted continually.  Thus if there is not another mechanism
 in place to counterbalance this effect, the entire system will heat or
 cool continuously.  You can use multiple heat fixes so that the net
 energy change is 0.0 or use :doc:`fix viscous <fix_viscous>` to drain

doc/src/fix_spring.rst

@@ -45,7 +45,7 @@ Apply a spring force to a group of atoms or between two groups of
 atoms.  This is useful for applying an umbrella force to a small
 molecule or lightly tethering a large group of atoms (e.g. all the
 solvent or a large molecule) to the center of the simulation box so
-that it doesn't wander away over the course of a long simulation.  It
+that it does not wander away over the course of a long simulation.  It
 can also be used to hold the centers of mass of two groups of atoms at
 a given distance or orientation with respect to each other.
 

doc/src/if.rst

@@ -53,7 +53,7 @@ until one is found to be true, in which case its commands (f1, f2,
 ..., fN) are executed.  If no Boolean expression is TRUE, then the
 commands associated with the else keyword, namely (e1, e2, ..., eN),
 are executed.  The elif and else keywords and their associated
-commands are optional.  If they aren't specified and the initial
+commands are optional.  If they are not specified and the initial
 Boolean expression is FALSE, then no commands are executed.
 
 The syntax for Boolean expressions is described below.

doc/src/molecule.rst

@@ -123,7 +123,7 @@ a description of the file.  Then lines are read one at a time.  Lines
 can have a trailing comment starting with '#' that is ignored.  If the
 line is blank (only white-space after comment is deleted), it is
 skipped.  If the line contains a header keyword, the corresponding
-value(s) is read from the line.  If it doesn't contain a header
+value(s) is read from the line.  If it does not contain a header
 keyword, the line begins the body of the file.
 
 The body of the file contains zero or more sections.  The first line

doc/src/neigh_modify.rst

@@ -177,7 +177,7 @@ atom can have.
    LAMMPS can crash without an error message if the number of
    neighbors for a single particle is larger than the *page* setting,
    which means it is much, much larger than the *one* setting.  This is
-   because LAMMPS doesn't error check these limits for every pairwise
+   because LAMMPS does not error check these limits for every pairwise
    interaction (too costly), but only after all the particle's neighbors
    have been found.  This problem usually means something is very wrong
    with the way you have setup your problem (particle spacing, cutoff

doc/src/package.rst

@@ -444,7 +444,7 @@ CPUs (i.e. the Kokkos CUDA back end is not enabled).
 A value of *full* uses a full neighbor lists and is the default when
 running on GPUs. This performs twice as much computation as the *half*
 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
+does not require atomic operations in the calculation of pair forces. For
 that reason, *full* is the default setting for GPUs. However, when
 running on CPUs, a *half* neighbor list is the default because it are
 often faster, just as it is for non-accelerated pair styles. Similarly,

doc/src/pair_agni.rst

@@ -119,7 +119,7 @@ The AGNI force field files provided with LAMMPS (see the
 potentials directory) are parameterized for metal :doc:`units <units>`.
 You can use the AGNI potential with any LAMMPS units, but you would need
 to create your own AGNI potential file with coefficients listed in the
-appropriate units if your simulation doesn't use "metal" units.
+appropriate units if your simulation does not use "metal" units.
 
 Related commands
 """"""""""""""""

doc/src/pair_airebo.rst

@@ -246,7 +246,7 @@ The CH.airebo and CH.airebo-m potential files provided with LAMMPS
 You can use the AIREBO, AIREBO-M or REBO potential with any LAMMPS units,
 but you would need to create your own AIREBO or AIREBO-M potential file
 with coefficients listed in the appropriate units, if your simulation
-doesn't use "metal" units.
+does not use "metal" units.
 
 Related commands
 """"""""""""""""

doc/src/pair_comb.rst

@@ -196,7 +196,7 @@ with LAMMPS (see the potentials directory) are parameterized for metal
 :doc:`units <units>`.  You can use the COMB potential with any LAMMPS
 units, but you would need to create your own COMB potential file with
 coefficients listed in the appropriate units if your simulation
-doesn't use "metal" units.
+does not use "metal" units.
 
 Related commands
 """"""""""""""""

doc/src/pair_drip.rst

@@ -127,7 +127,7 @@ The *C.drip* parameter file provided with LAMMPS (see the "potentials"
 directory) is parameterized for metal :doc:`units <units>`. You can use the DRIP
 potential with any LAMMPS units, but you would need to create your own custom
 parameter file with coefficients listed in the appropriate units, if your
-simulation doesn't use "metal" units.
+simulation does not use "metal" units.
 
 Related commands
 """"""""""""""""

doc/src/pair_edip.rst

@@ -174,7 +174,7 @@ The EDIP potential files provided with LAMMPS (see the potentials directory)
 are parameterized for metal :doc:`units <units>`.
 You can use the EDIP potential with any LAMMPS units, but you would need
 to create your own EDIP potential file with coefficients listed in the
-appropriate units if your simulation doesn't use "metal" units.
+appropriate units if your simulation does not use "metal" units.
 
 Related commands
 """"""""""""""""

doc/src/pair_gw.rst

@@ -111,7 +111,7 @@ The Gao-Weber potential files provided with LAMMPS (see the
 potentials directory) are parameterized for metal :doc:`units <units>`.
 You can use the GW potential with any LAMMPS units, but you would need
 to create your own GW potential file with coefficients listed in the
-appropriate units if your simulation doesn't use "metal" units.
+appropriate units if your simulation does not use "metal" units.
 
 Related commands
 """"""""""""""""

doc/src/pair_lcbop.rst

@@ -84,7 +84,7 @@ The C.lcbop potential file provided with LAMMPS (see the potentials
 directory) is parameterized for metal :doc:`units <units>`.  You can use
 the LCBOP potential with any LAMMPS units, but you would need to
 create your own LCBOP potential file with coefficients listed in the
-appropriate units if your simulation doesn't use "metal" units.
+appropriate units if your simulation does not use "metal" units.
 
 Related commands
 """"""""""""""""

doc/src/pair_reaxc.rst

@@ -149,7 +149,7 @@ drops to zero.
 Optional keywords *safezone* and *mincap* are used for allocating
 reax/c arrays.  Increasing these values can avoid memory problems,
 such as segmentation faults and bondchk failed errors, that could
-occur under certain conditions. These keywords aren't used by the
+occur under certain conditions. These keywords are not used by the
 Kokkos version, which instead uses a more robust memory allocation
 scheme that checks if the sizes of the arrays have been exceeded and
 automatically allocates more memory.
@@ -341,7 +341,7 @@ The ReaxFF potential files provided with LAMMPS in the potentials
 directory are parameterized for real :doc:`units <units>`.  You can use
 the ReaxFF potential with any LAMMPS units, but you would need to
 create your own potential file with coefficients listed in the
-appropriate units if your simulation doesn't use "real" units.
+appropriate units if your simulation does not use "real" units.
 
 Related commands
 """"""""""""""""

doc/src/pair_sw.rst

@@ -222,7 +222,7 @@ The Stillinger-Weber potential files provided with LAMMPS (see the
 potentials directory) are parameterized for metal :doc:`units <units>`.
 You can use the SW potential with any LAMMPS units, but you would need
 to create your own SW potential file with coefficients listed in the
-appropriate units if your simulation doesn't use "metal" units.
+appropriate units if your simulation does not use "metal" units.
 
 Related commands
 """"""""""""""""

doc/src/pair_tersoff.rst

@@ -271,7 +271,7 @@ The Tersoff potential files provided with LAMMPS (see the potentials
 directory) are parameterized for metal :doc:`units <units>`.  You can
 use the Tersoff potential with any LAMMPS units, but you would need to
 create your own Tersoff potential file with coefficients listed in the
-appropriate units if your simulation doesn't use "metal" units.
+appropriate units if your simulation does not use "metal" units.
 
 Related commands
 """"""""""""""""

doc/src/pair_tersoff_mod.rst

@@ -209,7 +209,7 @@ The Tersoff/MOD potential files provided with LAMMPS (see the potentials
 directory) are parameterized for metal :doc:`units <units>`.  You can
 use the Tersoff/MOD potential with any LAMMPS units, but you would need to
 create your own Tersoff/MOD potential file with coefficients listed in the
-appropriate units if your simulation doesn't use "metal" units.
+appropriate units if your simulation does not use "metal" units.
 
 Related commands
 """"""""""""""""

doc/src/pair_tersoff_zbl.rst

@@ -286,7 +286,7 @@ The Tersoff/ZBL potential files provided with LAMMPS (see the
 potentials directory) are parameterized for metal :doc:`units <units>`.
 You can use the Tersoff potential with any LAMMPS units, but you would
 need to create your own Tersoff potential file with coefficients
-listed in the appropriate units if your simulation doesn't use "metal"
+listed in the appropriate units if your simulation does not use "metal"
 units.
 
 Related commands

doc/src/pair_vashishta.rst

@@ -245,7 +245,7 @@ The Vashishta potential files provided with LAMMPS (see the potentials
 directory) are parameterized for metal :doc:`units <units>`.  You can
 use the Vashishta potential with any LAMMPS units, but you would need
 to create your own potential file with coefficients listed in the
-appropriate units if your simulation doesn't use "metal" units.
+appropriate units if your simulation does not use "metal" units.
 
 Related commands
 """"""""""""""""

doc/src/read_data.rst

@@ -227,7 +227,7 @@ description of the file.  Then lines are read one at a time.  Lines
 can have a trailing comment starting with '#' that is ignored.  If the
 line is blank (only white-space after comment is deleted), it is
 skipped.  If the line contains a header keyword, the corresponding
-value(s) is read from the line.  If it doesn't contain a header
+value(s) is read from the line.  If it does not contain a header
 keyword, the line begins the body of the file.
 
 The body of the file contains zero or more sections.  The first line

doc/src/read_restart.rst

@@ -92,7 +92,7 @@ value.  The file with the largest timestep value is read in.  Thus,
 this effectively means, read the latest restart file.  It's useful if
 you want your script to continue a run from where it left off.  See
 the :doc:`run <run>` command and its "upto" option for how to specify
-the run command so it doesn't need to be changed either.
+the run command so it does not need to be changed either.
 
 If a "%" character appears in the restart filename, LAMMPS expects a
 set of multiple files to exist.  The :doc:`restart <restart>` and

doc/src/rerun.rst

@@ -55,7 +55,7 @@ initial simulation produced the dump file:
 
 * Compute the energy and forces of snapshots using a different potential.
 * Calculate one or more diagnostic quantities on the snapshots that
-  weren't computed in the initial run.  These can also be computed with
+  were not computed in the initial run.  These can also be computed with
   settings not used in the initial run, e.g. computing an RDF via the
   :doc:`compute rdf <compute_rdf>` command with a longer cutoff than was
   used initially.