more spelling fixes and occational re-edits

doc/src/Build_extras.txt

@@ -750,7 +750,7 @@ a global PLUMED installation or downloading it during building LAMMPS.
 -D PLUMED_MODE=value       # Linkage mode for PLUMED, value = static (default), shared, or runtime :pre
 
 If DOWNLOAD_PLUMED is set to "yes", the PLUMED library will be
-downloaded (the version of that is hardcoded to a vetted version of
+downloaded (the version of that is hard-coded to a vetted version of
 PLUMED, usually a recent stable release version) and built inside the
 CMake build directory.  If DOWNLOAD_PLUMED is set to "no" (the default),
 CMake will try to detect an installed version of PLUMED and link to
@@ -788,7 +788,7 @@ Note that 2 symbolic (soft) links, "includelink" and "liblink" are
 created in lib/plumed to point into the location of the PLUMED build to
 use and also a new file lib/plumed/Makefile.lammps is created with
 settings suitable for LAMMPS to compile and link PLUMED in the desired
-linkage mode. After this step is compleded, you can install the
+linkage mode. After this step is completed, you can install the
 USER-PLUMED package and compile LAMMPS in the usual manner:
 
 make yes-user-plumed 
@@ -804,7 +804,7 @@ operating systems, using the static linkage is expected to be the most
 portable, and thus set to be the default.
 
 If you want to change the linkage mode, you have to re-run "make
-lib-plumed" with the desired settings [and] do a reinstall if the
+lib-plumed" with the desired settings [and] do a re-install if the
 USER-PLUMED package with "make yes-user-plumed" to update the required
 makefile settings with the changes in the lib/plumed folder.
 

doc/src/Build_settings.txt

@@ -139,7 +139,7 @@ adequate.
 [Makefile.machine setting]:
 
 LMP_INC = -DLAMMPS_SMALLBIG    # or -DLAMMPS_BIGBIG or -DLAMMPS_SMALLSMALL :pre
-                               # default is LAMMMPS_SMALLBIG if not specified
+                               # default is LAMMPS_SMALLBIG if not specified
 [CMake and make info]:
 
 The default "smallbig" setting allows for simulations with:

doc/src/Build_windows.txt

@@ -66,7 +66,7 @@ In case of problems, you are recommended to contact somebody with
 experience in using cygwin.  If you do come across portability problems
 requiring changes to the LAMMPS source code, or figure out corrections
 yourself, please report them on the lammps-users mailing list, or file
-them as an issue or pull request on the LAMMPS github project.
+them as an issue or pull request on the LAMMPS GitHub project.
 
 
 Using a cross-compiler :h4,link(cross)

doc/src/Commands_parse.txt

@@ -91,7 +91,7 @@ See the "variable"_variable.html command for more details of how
 strings are assigned to variables and evaluated, and how they can be
 used in input script commands.
 
-(4) The line is broken into "words" separated by whitespace (tabs,
+(4) The line is broken into "words" separated by white-space (tabs,
 spaces).  Note that words can thus contain letters, digits,
 underscores, or punctuation characters.
 

doc/src/Errors_messages.txt

@@ -421,9 +421,9 @@ This is an internal error.  It should normally not occur. :dd
 
 This is an internal error.  It should normally not occur. :dd
 
-{Bad real space Coulomb cutoff in fix tune/kspace} :dt
+{Bad real space Coulombic cutoff in fix tune/kspace} :dt
 
-Fix tune/kspace tried to find the optimal real space Coulomb cutoff using
+Fix tune/kspace tried to find the optimal real space Coulombic cutoff using
 the Newton-Rhaphson method, but found a non-positive or NaN cutoff :dd
 
 {Balance command before simulation box is defined} :dt
@@ -3351,21 +3351,21 @@ probably due to errors in the Python code. :dd
 The default minimum order is 2.  This can be reset by the
 kspace_modify minorder command. :dd
 
-{Coulomb cut not supported in pair_style buck/long/coul/coul} :dt
+{Coulombic cutoff not supported in pair_style buck/long/coul/coul} :dt
 
 Must use long-range Coulombic interactions. :dd
 
-{Coulomb cut not supported in pair_style lj/long/coul/long} :dt
+{Coulombic cutoff not supported in pair_style lj/long/coul/long} :dt
 
 Must use long-range Coulombic interactions. :dd
 
-{Coulomb cut not supported in pair_style lj/long/tip4p/long} :dt
+{Coulombic cutoff not supported in pair_style lj/long/tip4p/long} :dt
 
 Must use long-range Coulombic interactions. :dd
 
-{Coulomb cutoffs of pair hybrid sub-styles do not match} :dt
+{Coulombic cutoffs of pair hybrid sub-styles do not match} :dt
 
-If using a Kspace solver, all Coulomb cutoffs of long pair styles must
+If using a Kspace solver, all Coulombic cutoffs of long pair styles must
 be the same. :dd
 
 {Coulombic cut not supported in pair_style lj/long/dipole/long} :dt
@@ -5938,9 +5938,9 @@ map command will force an atom map to be created. :dd
 
 Self-explanatory. :dd
 
-{Input line quote not followed by whitespace} :dt
+{Input line quote not followed by white-space} :dt
 
-An end quote must be followed by whitespace. :dd
+An end quote must be followed by white-space. :dd
 
 {Insertion region extends outside simulation box} :dt
 
@@ -7014,7 +7014,7 @@ The kspace accuracy designated in the input must be greater than zero. :dd
 
 {KSpace accuracy too large to estimate G vector} :dt
 
-Reduce the accuracy request or specify gwald explicitly
+Reduce the accuracy request or specify gewald explicitly
 via the kspace_modify command. :dd
 
 {KSpace accuracy too low} :dt
@@ -9198,7 +9198,7 @@ creates one large file for all processors. :dd
 {Restart file byte ordering is not recognized} :dt
 
 The file does not appear to be a LAMMPS restart file since it doesn't
-contain a recognized byte-orderomg flag at the beginning. :dd
+contain a recognized byte-ordering flag at the beginning. :dd
 
 {Restart file byte ordering is swapped} :dt
 
@@ -9410,7 +9410,7 @@ You may also want to boost the page size. :dd
 
 {Small to big integers are not sized correctly} :dt
 
-This error occurs whenthe sizes of smallint, imageint, tagint, bigint,
+This error occurs when the sizes of smallint, imageint, tagint, bigint,
 as defined in src/lmptype.h are not what is expected.  Contact
 the developers if this occurs. :dd
 

doc/src/Errors_warnings.txt

@@ -757,7 +757,7 @@ Self-explanatory. :dd
 
 This may indicate the shell command did not operate as expected. :dd
 
-{Should not allow rigid bodies to bounce off relecting walls} :dt
+{Should not allow rigid bodies to bounce off reflecting walls} :dt
 
 LAMMPS allows this, but their dynamics are not computed correctly. :dd
 
@@ -850,10 +850,10 @@ Most FENE models need this setting for the special_bonds command. :dd
 
 Most FENE models need this setting for the special_bonds command. :dd
 
-{Using a manybody potential with bonds/angles/dihedrals and special_bond exclusions} :dt
+{Using a many-body potential with bonds/angles/dihedrals and special_bond exclusions} :dt
 
 This is likely not what you want to do.  The exclusion settings will
-eliminate neighbors in the neighbor list, which the manybody potential
+eliminate neighbors in the neighbor list, which the many-body potential
 needs to calculated its terms correctly. :dd
 
 {Using compute temp/deform with inconsistent fix deform remap option} :dt

doc/src/Examples.txt

@@ -78,7 +78,7 @@ micelle:  self-assembly of small lipid-like molecules into 2d bilayers
 min:      energy minimization of 2d LJ melt
 mscg:     parameterize a multi-scale coarse-graining (MSCG) model
 msst:     MSST shock dynamics
-nb3b:     use of nonbonded 3-body harmonic pair style
+nb3b:     use of non-bonded 3-body harmonic pair style
 neb:      nudged elastic band (NEB) calculation for barrier finding
 nemd:     non-equilibrium MD of 2d sheared system
 obstacle: flow around two voids in a 2d channel

doc/src/Howto_chunk.txt

@@ -22,8 +22,8 @@ commands, to calculate various properties of a system:
 "fix ave/chunk"_fix_ave_chunk.html
 any of the "compute */chunk"_compute.html commands :ul
 
-Here, each of the 4 kinds of chunk-related commands is briefly
+Here a brief overview for each of the 4 kinds of chunk-related commands
-overviewed.  Then some examples are given of how to compute different
+is provided.  Then some examples are given of how to compute different
 properties with chunk commands.
 
 Compute chunk/atom command: :h4

doc/src/Howto_client_server.txt

@@ -87,7 +87,7 @@ DFT forces, thru a Python wrapper script on VASP.
 Here is how to launch a client and server code together for any of the
 4 modes of message exchange that the "message"_message.html command
 and the CSlib support.  Here LAMMPS is used as both the client and
-server code.  Another code could be subsitituted for either.
+server code.  Another code could be substituted for either.
 
 The examples below show launching both codes from the same window (or
 batch script), using the "&" character to launch the first code in the

doc/src/Howto_coreshell.txt

@@ -19,7 +19,7 @@ polarizable"_Howto_polarizable.html doc page for a discussion of all
 the polarizable models available in LAMMPS.
 
 Technically, shells are attached to the cores by a spring force f =
-k*r where k is a parametrized spring constant and r is the distance
+k*r where k is a parameterized spring constant and r is the distance
 between the core and the shell. The charges of the core and the shell
 add up to the ion charge, thus q(ion) = q(core) + q(shell). This
 setup introduces the ion polarizability (alpha) given by
@@ -111,7 +111,7 @@ the core and shell particles corresponds to the polarization,
 hereby an instantaneous relaxation of the shells is approximated
 and a fast core/shell spring frequency ensures a nearly constant
 internal kinetic energy during the simulation.
-Thermostats can alter this polarization behaviour, by scaling the
+Thermostats can alter this polarization behavior, by scaling the
 internal kinetic energy, meaning the shell will not react freely to
 its electrostatic environment.
 Therefore it is typically desirable to decouple the relative motion of
@@ -165,7 +165,7 @@ fix_modify press_bar temp CSequ press thermo_press_lmp  # pressure modification
 If "compute temp/cs"_compute_temp_cs.html is used, the decoupled
 relative motion of the core and the shell should in theory be
 stable.  However numerical fluctuation can introduce a small
-momentum to the system, which is noticable over long trajectories.
+momentum to the system, which is noticeable over long trajectories.
 Therefore it is recommendable to use the "fix
 momentum"_fix_momentum.html command in combination with "compute
 temp/cs"_compute_temp_cs.html when equilibrating the system to

doc/src/Howto_dispersion.txt

@@ -74,7 +74,7 @@ command.
 A reasonable approach that combines the upsides of both methods is to
 make the first run using the {kspace_modify force/disp/real} and
 {kspace_modify force/disp/kspace} commands, write down the PPPM
-parameters from the outut, and specify these parameters using the
+parameters from the output, and specify these parameters using the
 second approach in subsequent runs (which have the same composition,
 force field, and approximately the same volume).
 

doc/src/Howto_drude.txt

@@ -17,7 +17,7 @@ for a discussion of all the polarizable models available in LAMMPS.
 The Drude model has a number of features aimed at its use in
 molecular systems ("Lamoureux and Roux"_#howto-Lamoureux):
 
-Thermostating of the additional degrees of freedom associated with the
+Thermostatting of the additional degrees of freedom associated with the
 induced dipoles at very low temperature, in terms of the reduced
 coordinates of the Drude particles with respect to their cores. This
 makes the trajectory close to that of relaxed induced dipoles. :ulb,l

doc/src/Howto_drude2.txt

@@ -82,7 +82,7 @@ decouple the degrees of freedom associated with the Drude oscillators
 from those of the normal atoms. Thermalizing the Drude dipoles at
 temperatures comparable to the rest of the simulation leads to several
 problems (kinetic energy transfer, very short timestep, etc.), which
-can be remediate by the "cold Drude" technique ("Lamoureux and
+can be remedied by the "cold Drude" technique ("Lamoureux and
 Roux"_#Lamoureux2).
 
 Two closely related models are used to represent polarization through
@@ -213,7 +213,7 @@ of mass of the DC-DP pairs, with relaxation time 100 and with random
 seed 12345.  This fix applies also a Langevin thermostat at temperature
 1. to the relative motion of the DPs around their DCs, with relaxation
 time 20 and random seed 13977.  Only the DCs and non-polarizable
-atoms need to be in this fix's group.  LAMMPS will thermostate the DPs
+atoms need to be in this fix's group.  LAMMPS will thermostat the DPs
 together with their DC.  For this, ghost atoms need to know their
 velocities. Thus you need to add the following command:
 
@@ -360,7 +360,7 @@ fix NPH all nph iso 1. 1. 500 :pre
 It is also possible to use a Nose-Hoover instead of a Langevin
 thermostat.  This requires to use "{fix
 drude/transform}"_fix_drude_transform.html just before and after the
-time intergation fixes.  The {fix drude/transform/direct} converts the
+time integration fixes.  The {fix drude/transform/direct} converts the
 atomic masses, positions, velocities and forces into a reduced
 representation, where the DCs transform into the centers of mass of
 the DC-DP pairs and the DPs transform into their relative position
@@ -396,7 +396,7 @@ global pressure and thus a global temperature whatever the fix group.
 We do want the pressure to correspond to the whole system, but we want
 the temperature to correspond to the fix group only.  We must then use
 the {fix_modify} command for this.  In the end, the block of
-instructions for thermostating and barostatting will look like
+instructions for thermostatting and barostatting will look like
 
 compute TATOMS ATOMS temp
 fix DIRECT all drude/transform/direct

doc/src/Howto_elastic.txt

@@ -30,7 +30,7 @@ examples/elastic directory described on the "Examples"_Examples.html
 doc page.
 
 Calculating elastic constants at finite temperature is more
-challenging, because it is necessary to run a simulation that perfoms
+challenging, because it is necessary to run a simulation that performs
 time averages of differential properties. One way to do this is to
 measure the change in average stress tensor in an NVT simulations when
 the cell volume undergoes a finite deformation. In order to balance

doc/src/Howto_github.txt

@@ -96,7 +96,7 @@ machine to a directory with the name you chose. If none is given, it will
 default to "lammps". Typical names are "mylammps" or something similar.
 
 You can use this local clone to make changes and
-test them without interfering with the repository on Github.
+test them without interfering with the repository on GitHub.
 
 To pull changes from upstream into this copy, you can go to the directory
 and use git pull:
@@ -150,7 +150,7 @@ After the commit, the changes can be pushed to the same branch on GitHub:
 $ git push :pre
 
 Git will ask you for your user name and password on GitHub if you have
-not configured anything. If your local branch is not present on Github yet,
+not configured anything. If your local branch is not present on GitHub yet,
 it will ask you to add it by running
 
   $ git push --set-upstream origin github-tutorial-update :pre
@@ -369,7 +369,7 @@ commit and push again:
  $ git commit -m "Merged Axel's suggestions and updated text"
  $ git push git@github.com:Pakketeretet2/lammps :pre
 
-This merge also shows up on the lammps Github page:
+This merge also shows up on the lammps GitHub page:
 
 :c,image(JPG/tutorial_reverse_pull_request7.png)
 

doc/src/Howto_manifold.txt

@@ -31,8 +31,8 @@ plane @ a b c x0 y0 z0 @ a*(x-x0) + b*(y-y0) + c*(z-z0) = 0 @ A plane with norma
 plane_wiggle @ a w @ z - a*sin(w*x) = 0 @ A plane with a sinusoidal modulation on z along x.
 sphere @ R @ x^2 + y^2 + z^2 - R^2 = 0 @ A sphere of radius R
 supersphere @ R q @ | x |^q + | y |^q + | z |^q - R^q = 0 @ A supersphere of hyperradius R
-spine @ a, A, B, B2, c @ -(x^2 + y^2) + (a^2 - z^2/f(z)^2)*(1 + (A*sin(g(z)*z^2))^4), f(z) = c if z > 0, 1 otherwise; g(z) = B if z > 0, B2 otherwise  @ An approximation to a dendtritic spine
+spine @ a, A, B, B2, c @ -(x^2 + y^2) + (a^2 - z^2/f(z)^2)*(1 + (A*sin(g(z)*z^2))^4), f(z) = c if z > 0, 1 otherwise; g(z) = B if z > 0, B2 otherwise  @ An approximation to a dendritic spine
-spine_two @ a, A, B, B2, c @ -(x^2 + y^2) + (a^2 - z^2/f(z)^2)*(1 + (A*sin(g(z)*z^2))^2), f(z) = c if z > 0, 1 otherwise; g(z) = B if z > 0, B2 otherwise  @ Another approximation to a dendtritic spine
+spine_two @ a, A, B, B2, c @ -(x^2 + y^2) + (a^2 - z^2/f(z)^2)*(1 + (A*sin(g(z)*z^2))^2), f(z) = c if z > 0, 1 otherwise; g(z) = B if z > 0, B2 otherwise  @ Another approximation to a dendritic spine
 thylakoid @ wB LB lB @ Various, see "(Paquay)"_#Paquay1 @ A model grana thylakoid consisting of two block-like compartments connected by a bridge of width wB, length LB and taper length lB
 torus @ R r  @  (R - sqrt( x^2 + y^2 ) )^2 + z^2 - r^2  @ A torus with large radius R and small radius r, centered on (0,0,0) :tb(s=@)
 

doc/src/Howto_nemd.txt

@@ -55,5 +55,5 @@ using the "fix flow/gauss"_fix_flow_gauss.html command.
 :line
 
 :link(Daivis-nemd)
-[(Daivis and Todd)] Daivis and Todd, Nonequilibrium Molecular Dyanmics (book),
+[(Daivis and Todd)] Daivis and Todd, Nonequilibrium Molecular Dynamics (book),
 Cambridge University Press, https://doi.org/10.1017/9781139017848, (2017).

doc/src/Howto_polarizable.txt

@@ -45,8 +45,8 @@ high symmetry around each site leads to stable trajectories of the
 core-shell pairs. However, bonded atoms in molecules can be so close
 that a core would interact too strongly or even capture the Drude
 particle of a neighbor. The Drude dipole model is relatively more
-complex in order to remediate this and other issues. Specifically, the
+complex in order to remedy this and other issues. Specifically, the
-Drude model includes specific thermostating of the core-Drude pairs
+Drude model includes specific thermostatting of the core-Drude pairs
 and short-range damping of the induced dipoles.
 
 The three polarization methods can be implemented through a
@@ -77,5 +77,5 @@ motion of the Drude particles with respect to their cores is kept
 approaching the self-consistent regime.  In both models the
 temperature is regulated using the velocities of the center of mass of
 core+shell (or Drude) pairs, but in the Drude model the actual
-relative core-Drude particle motion is thermostated separately as
+relative core-Drude particle motion is thermostatted separately as
 well.

doc/src/Howto_pylammps.txt

@@ -141,16 +141,16 @@ Python code if {L} was a lammps instance:
 L.command("region box block 0 10 0 5 -0.5 0.5") :pre
 
 With the PyLammps interface, any command can be split up into arbitrary parts
-separated by whitespace, passed as individual arguments to a region method.
+separated by white-space, passed as individual arguments to a region method.
 
 L.region("box block", 0, 10, 0, 5, -0.5, 0.5) :pre
 
 Note that each parameter is set as Python literal floating-point number. In the
 PyLammps interface, each command takes an arbitrary parameter list and transparently
-merges it to a single command string, separating individual parameters by whitespace.
+merges it to a single command string, separating individual parameters by white-space.
 
 The benefit of this approach is avoiding redundant command calls and easier
-parameterization. In the original interface parametrization needed to be done
+parameterization. In the original interface parameterization needed to be done
 manually by creating formatted strings.
 
 L.command("region box block %f %f %f %f %f %f" % (xlo, xhi, ylo, yhi, zlo, zhi)) :pre

doc/src/Howto_replica.txt

@@ -9,7 +9,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 
 Multi-replica simulations :h3
 
-Several commands in LAMMPS run mutli-replica simulations, meaning
+Several commands in LAMMPS run multi-replica simulations, meaning
 that multiple instances (replicas) of your simulation are run
 simultaneously, with small amounts of data exchanged between replicas
 periodically.

doc/src/Howto_spc.txt

@@ -30,7 +30,7 @@ r0 of OH bond = 1.0
 theta of HOH angle = 109.47 :all(b),p
 
 Note that as originally proposed, the SPC model was run with a 9
-Angstrom cutoff for both LJ and Coulommbic terms.  It can also be used
+Angstrom cutoff for both LJ and Coulombic terms.  It can also be used
 with long-range Coulombics (Ewald or PPPM in LAMMPS), without changing
 any of the parameters above, though it becomes a different model in
 that mode of usage.

doc/src/Howto_spherical.txt

@@ -236,7 +236,7 @@ particles are point masses.
 Also note that body particles cannot be modeled with the "fix
 rigid"_fix_rigid.html command.  Body particles are treated by LAMMPS
 as single particles, though they can store internal state, such as a
-list of sub-particles.  Individual body partices are typically treated
+list of sub-particles.  Individual body particles are typically treated
 as rigid bodies, and their motion integrated with a command like "fix
 nve/body"_fix_nve_body.html.  Interactions between pairs of body
 particles are computed via a command like "pair_style

doc/src/Howto_spins.txt

@@ -36,7 +36,7 @@ A Langevin thermostat can be applied to those magnetic spins using
 "fix langevin/spin"_fix_langevin_spin.html. Typically, this thermostat 
 can be coupled to another Langevin thermostat applied to the atoms 
 using "fix langevin"_fix_langevin.html in order to simulate 
-thermostated spin-lattice system. 
+thermostatted spin-lattice system. 
 
 The magnetic Gilbert damping can also be applied using "fix 
 langevin/spin"_fix_langevin_spin.html. It allows to either dissipate 

doc/src/Howto_thermostat.txt

@@ -96,5 +96,5 @@ temperature compute is used for default thermodynamic output.
 :line
 
 :link(Daivis-thermostat)
-[(Daivis and Todd)] Daivis and Todd, Nonequilibrium Molecular Dyanmics (book),
+[(Daivis and Todd)] Daivis and Todd, Nonequilibrium Molecular Dynamics (book),
 Cambridge University Press, https://doi.org/10.1017/9781139017848, (2017).

doc/src/Howto_triclinic.txt

@@ -200,7 +200,7 @@ used with non-orthogonal basis vectors to define a lattice that will
 tile a triclinic simulation box via the
 "create_atoms"_create_atoms.html command.
 
-A second use is to run Parinello-Rahman dynamics via the "fix
+A second use is to run Parrinello-Rahman dynamics via the "fix
 npt"_fix_nh.html command, which will adjust the xy, xz, yz tilt
 factors to compensate for off-diagonal components of the pressure
 tensor.  The analog for an "energy minimization"_minimize.html is

doc/src/Howto_viscosity.txt

@@ -140,5 +140,5 @@ with time at sufficiently long times.
 :line
 
 :link(Daivis-viscosity)
-[(Daivis and Todd)] Daivis and Todd, Nonequilibrium Molecular Dyanmics (book),
+[(Daivis and Todd)] Daivis and Todd, Nonequilibrium Molecular Dynamics (book),
 Cambridge University Press, https://doi.org/10.1017/9781139017848, (2017).

doc/src/Intro_authors.txt

@@ -48,7 +48,7 @@ Trung Ngyuen (Northwestern U), GPU and RIGID and BODY packages
 Mike Parks (Sandia), PERI package for Peridynamics
 Roy Pollock (LLNL), Ewald and PPPM solvers
 Christian Trott (Sandia), USER-CUDA and KOKKOS packages
-Ilya Valuev (JIHT), USER-AWPMD package for wave-packet MD
+Ilya Valuev (JIHT), USER-AWPMD package for wave packet MD
 Greg Wagner (Northwestern U), MEAM package for MEAM potential :ul
 
 :line

doc/src/Intro_features.txt

@@ -68,7 +68,7 @@ commands)
   pairwise potentials: Lennard-Jones, Buckingham, Morse, Born-Mayer-Huggins, \
     Yukawa, soft, class 2 (COMPASS), hydrogen bond, tabulated
   charged pairwise potentials: Coulombic, point-dipole
-  manybody potentials: EAM, Finnis/Sinclair EAM, modified EAM (MEAM), \
+  many-body potentials: EAM, Finnis/Sinclair EAM, modified EAM (MEAM), \
     embedded ion method (EIM), EDIP, ADP, Stillinger-Weber, Tersoff, \
     REBO, AIREBO, ReaxFF, COMB, SNAP, Streitz-Mintmire, 3-body polymorphic
   long-range interactions for charge, point-dipoles, and LJ dispersion: \
@@ -114,7 +114,7 @@ Ensembles, constraints, and boundary conditions :h4,link(ensemble)
 
   2d or 3d systems
   orthogonal or non-orthogonal (triclinic symmetry) simulation domains
-  constant NVE, NVT, NPT, NPH, Parinello/Rahman integrators
+  constant NVE, NVT, NPT, NPH, Parrinello/Rahman integrators
   thermostatting options for groups and geometric regions of atoms
   pressure control via Nose/Hoover or Berendsen barostatting in 1 to 3 dimensions
   simulation box deformation (tensile and shear)

doc/src/Intro_nonfeatures.txt

@@ -51,7 +51,7 @@ the option to insert molecule templates instead of atoms.:l
 Force-field assignment: The conversion tools described in the previous
 bullet for CHARMM, AMBER, and Insight will also assign force field
 coefficients in the LAMMPS format, assuming you provide CHARMM, AMBER,
-or Accelerys force field files. :l
+or BIOVIA (formerly Accelrys) force field files. :l
 
 Simulation analysis: If you want to perform analysis on-the-fly as
 your simulation runs, see the "compute"_compute.html and

doc/src/Modify_contribute.txt

@@ -33,11 +33,11 @@ how much effort it will cause to integrate and test it, how much it
 requires changes to the core codebase, and of how much interest it is
 to the larger LAMMPS community.  Please see below for a checklist of
 typical requirements. Once you have prepared everything, see the
-"Howto github"_Howto_github.html doc page for instructions on how to
+"Using GitHub with LAMMPS Howto"_Howto_github.html doc page for instructions on how to
 submit your changes or new files through a GitHub pull request. If you
 prefer to submit patches or full files, you should first make certain,
 that your code works correctly with the latest patch-level version of
-LAMMPS and contains all bugfixes from it. Then create a gzipped tar
+LAMMPS and contains all bug fixes from it. Then create a gzipped tar
 file of all changed or added files or a corresponding patch file using
 'diff -u' or 'diff -c' and compress it with gzip. Please only use gzip
 compression, as this works well on all platforms.

doc/src/Modify_pair.txt

@@ -10,7 +10,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 Pair styles :h3
 
 Classes that compute pairwise interactions are derived from the Pair
-class.  In LAMMPS, pairwise calculation include manybody potentials
+class.  In LAMMPS, pairwise calculation include many-body potentials
 such as EAM or Tersoff where particles interact without a static bond
 topology.  New styles can be created to add new pair potentials to
 LAMMPS.

doc/src/Modify_region.txt

@@ -20,6 +20,6 @@ Here is a brief description of methods you define in your new derived
 class.  See region.h for details.
 
 inside: determine whether a point is in the region
-surface_interior: determine if a point is within a cutoff distance inside of surc
+surface_interior: determine if a point is within a cutoff distance inside of surface
-surface_exterior: determine if a point is within a cutoff distance outside of surf
+surface_exterior: determine if a point is within a cutoff distance outside of surface
 shape_update : change region shape if set by time-dependent variable :tb(s=:)

doc/src/Packages_details.txt

@@ -494,7 +494,7 @@ MANYBODY package :link(PKG-MANYBODY),h4
 
 [Contents:]
 
-A variety of manybody and bond-order potentials.  These include
+A variety of many-body and bond-order potentials.  These include
 (AI)REBO, BOP, EAM, EIM, Stillinger-Weber, and Tersoff potentials.
 
 [Supporting info:]
@@ -518,7 +518,7 @@ MC package :link(PKG-MC),h4
 Several fixes and a pair style that have Monte Carlo (MC) or MC-like
 attributes.  These include fixes for creating, breaking, and swapping
 bonds, for performing atomic swaps, and performing grand-canonical MC
-(GCMC) in conjuction with dynamics.
+(GCMC) in conjunction with dynamics.
 
 [Supporting info:]
 

doc/src/Packages_user.txt

@@ -38,8 +38,8 @@ int = internal library: provided with LAMMPS, but you may need to build it
 ext = external library: you will need to download and install it on your machine :ul
 
 Package, Description, Doc page, Example, Library
-"USER-ATC"_Packages_details.html#PKG-USER-ATC, atom-to-continuum coupling, "fix atc"_fix_atc.html, USER/atc, int
+"USER-ATC"_Packages_details.html#PKG-USER-ATC, Atom-to-Continuum coupling, "fix atc"_fix_atc.html, USER/atc, int
-"USER-AWPMD"_Packages_details.html#PKG-USER-AWPMD, wave-packet MD, "pair_style awpmd/cut"_pair_awpmd.html, USER/awpmd, int
+"USER-AWPMD"_Packages_details.html#PKG-USER-AWPMD, wave packet MD, "pair_style awpmd/cut"_pair_awpmd.html, USER/awpmd, int
 "USER-BOCS"_Packages_details.html#PKG-USER-BOCS, BOCS bottom up coarse graining, "fix bocs"_fix_bocs.html, USER/bocs, no
 "USER-CGDNA"_Packages_details.html#PKG-USER-CGDNA, coarse-grained DNA force fields, src/USER-CGDNA/README, USER/cgdna, no
 "USER-CGSDK"_Packages_details.html#PKG-USER-CGSDK, SDK coarse-graining model, "pair_style lj/sdk"_pair_sdk.html, USER/cgsdk, no

doc/src/Python_call.txt

@@ -79,7 +79,7 @@ of Python and your machine to successfully build LAMMPS.  See the
 lib/python/README file for more info.
 
 If you want to write Python code with callbacks to LAMMPS, then you
-must also follow the steps overviewed in the "Python
+must also follow the steps summarized in the "Python
 run"_Python_run.html doc page.  I.e. you must build LAMMPS as a shared
 library and insure that Python can find the python/lammps.py file and
 the shared library.

doc/src/Python_examples.txt

@@ -46,7 +46,7 @@ http://mt.seas.upenn.edu/Archive/Graphics/A3/A3.html :pre
 :link(atomeye,http://mt.seas.upenn.edu/Archive/Graphics/A)
 :link(atomeye3,http://mt.seas.upenn.edu/Archive/Graphics/A3/A3.html)
 
-The latter link is to AtomEye 3 which has the scriping
+The latter link is to AtomEye 3 which has the scripting
 capability needed by these Python scripts.
 
 Note that for PyMol, you need to have built and installed the

doc/src/Speed.txt

@@ -19,7 +19,7 @@ using code options that implement alternate algorithms that can
 speed-up a simulation.  The second is to use one of the several
 accelerator packages provided with LAMMPS that contain code optimized
 for certain kinds of hardware, including multi-core CPUs, GPUs, and
-Intel Xeon Phi coprocessors.
+Intel Xeon Phi co-processors.
 
 The "Benchmark page"_http://lammps.sandia.gov/bench.html of the LAMMPS
 web site gives performance results for the various accelerator

doc/src/Speed_intel.txt

@@ -14,11 +14,11 @@ Corporation.  It provides two methods for accelerating simulations,
 depending on the hardware you have.  The first is acceleration on
 Intel CPUs by running in single, mixed, or double precision with
 vectorization.  The second is acceleration on Intel Xeon Phi
-coprocessors via offloading neighbor list and non-bonded force
+co-processors via offloading neighbor list and non-bonded force
 calculations to the Phi.  The same C++ code is used in both cases.
-When offloading to a coprocessor from a CPU, the same routine is run
+When offloading to a co-processor from a CPU, the same routine is run
 twice, once on the CPU and once with an offload flag. This allows
-LAMMPS to run on the CPU cores and coprocessor cores simultaneously.
+LAMMPS to run on the CPU cores and co-processor cores simultaneously.
 
 [Currently Available USER-INTEL Styles:]
 
@@ -47,7 +47,7 @@ These are scalable in size; the results given are with 512K
 particles (524K for Liquid Crystal). Most of the simulations are
 standard LAMMPS benchmarks (indicated by the filename extension in
 parenthesis) with modifications to the run length and to add a
-warmup run (for use with offload benchmarks).
+warm-up run (for use with offload benchmarks).
 
 :c,image(JPG/user_intel.png)
 
@@ -134,19 +134,19 @@ Do not use thread affinity (set KMP_AFFINITY=none) :l
 The "newton off" setting may provide better scalability :l
 :ule
 
-For Intel Xeon Phi coprocessors (Offload):
+For Intel Xeon Phi co-processors (Offload):
 
-Edit src/MAKE/OPTIONS/Makefile.intel_coprocessor as necessary :ulb,l
+Edit src/MAKE/OPTIONS/Makefile.intel_co-processor as necessary :ulb,l
 "-pk intel N omp 1" added to command-line where N is the number of
-coprocessors per node. :l
+co-processors per node. :l
 :ule
 
 :line
 
 [Required hardware/software:]
 
-In order to use offload to coprocessors, an Intel Xeon Phi
+In order to use offload to co-processors, an Intel Xeon Phi
-coprocessor and an Intel compiler are required. For this, the
+co-processor and an Intel compiler are required. For this, the
 recommended version of the Intel compiler is 14.0.1.106 or
 versions 15.0.2.044 and higher.
 
@@ -214,7 +214,7 @@ Makefile.intel_cpu_intelmpi # Intel Compiler, Intel MPI, No Offload
 Makefile.knl                # Intel Compiler, Intel MPI, No Offload
 Makefile.intel_cpu_mpich    # Intel Compiler, MPICH, No Offload
 Makefile.intel_cpu_openpmi  # Intel Compiler, OpenMPI, No Offload
-Makefile.intel_coprocessor  # Intel Compiler, Intel MPI, Offload :pre
+Makefile.intel_co-processor  # Intel Compiler, Intel MPI, Offload :pre
 
 Makefile.knl is identical to Makefile.intel_cpu_intelmpi except that
 it explicitly specifies that vectorization should be for Intel Xeon
@@ -227,9 +227,9 @@ source /opt/intel/parallel_studio_xe_2016.3.067/psxevars.sh
 # or psxevars.csh for C-shell
 make intel_cpu_intelmpi :pre
 
-Note that if you build with support for a Phi coprocessor, the same
+Note that if you build with support for a Phi co-processor, the same
-binary can be used on nodes with or without coprocessors installed.
+binary can be used on nodes with or without co-processors installed.
-However, if you do not have coprocessors on your system, building
+However, if you do not have co-processors on your system, building
 without offload support will produce a smaller binary.
 
 The general requirements for Makefiles with the USER-INTEL package
@@ -272,7 +272,7 @@ Advanced performance tuning options are also described below to get
 the best performance.
 
 When running on a single node (including runs using offload to a
-coprocessor), best performance is normally obtained by using 1 MPI
+co-processor), best performance is normally obtained by using 1 MPI
 task per physical core and additional OpenMP threads with SMT. For
 Intel Xeon processors, 2 OpenMP threads should be used for SMT.
 For Intel Xeon Phi CPUs, 2 or 4 OpenMP threads should be used
@@ -290,7 +290,7 @@ NOTE: Setting core affinity is often used to pin MPI tasks and OpenMP
 threads to a core or group of cores so that memory access can be
 uniform. Unless disabled at build time, affinity for MPI tasks and
 OpenMP threads on the host (CPU) will be set by default on the host
-{when using offload to a coprocessor}. In this case, it is unnecessary
+{when using offload to a co-processor}. In this case, it is unnecessary
 to use other methods to control affinity (e.g. taskset, numactl,
 I_MPI_PIN_DOMAIN, etc.). This can be disabled with the {no_affinity}
 option to the "package intel"_package.html command or by disabling the
@@ -310,15 +310,15 @@ editing the input script. This switch will automatically append
 options for the USER-INTEL package.  The default package command will
 specify that USER-INTEL calculations are performed in mixed precision,
 that the number of OpenMP threads is specified by the OMP_NUM_THREADS
-environment variable, and that if coprocessors are present and the
+environment variable, and that if co-processors are present and the
-binary was built with offload support, that 1 coprocessor per node
+binary was built with offload support, that 1 co-processor per node
 will be used with automatic balancing of work between the CPU and the
-coprocessor.
+co-processor.
 
 You can specify different options for the USER-INTEL package by using
 the "-pk intel Nphi" "command-line switch"_Run_options.html with
 keyword/value pairs as specified in the documentation. Here, Nphi = #
-of Xeon Phi coprocessors/node (ignored without offload
+of Xeon Phi co-processors/node (ignored without offload
 support). Common options to the USER-INTEL package include {omp} to
 override any OMP_NUM_THREADS setting and specify the number of OpenMP
 threads, {mode} to set the floating-point precision mode, and {lrt} to
@@ -332,7 +332,7 @@ Examples (see documentation for your MPI/Machine for differences in
 launching MPI applications):
 
 mpirun -np 72 -ppn 36 lmp_machine -sf intel -in in.script                                 # 2 nodes, 36 MPI tasks/node, $OMP_NUM_THREADS OpenMP Threads
-mpirun -np 72 -ppn 36 lmp_machine -sf intel -in in.script -pk intel 0 omp 2 mode double   # Don't use any coprocessors that might be available, use 2 OpenMP threads for each task, use double precision :pre
+mpirun -np 72 -ppn 36 lmp_machine -sf intel -in in.script -pk intel 0 omp 2 mode double   # Don't use any co-processors that might be available, use 2 OpenMP threads for each task, use double precision :pre
 
 [Or run with the USER-INTEL package by editing an input script:]
 
@@ -364,7 +364,7 @@ intel"_package.html command that can improve performance when using
 "PPPM"_kspace_style.html for long-range electrostatics on processors
 with SMT. It generates an extra pthread for each MPI task. The thread
 is dedicated to performing some of the PPPM calculations and MPI
-communications. This feature requires setting the preprocessor flag
+communications. This feature requires setting the pre-processor flag
 -DLMP_INTEL_USELRT in the makefile when compiling LAMMPS. It is unset
 in the default makefiles ({Makefile.mpi} and {Makefile.serial}) but
 it is set in all makefiles tuned for the USER-INTEL package.  On Intel
@@ -422,29 +422,29 @@ that MPI runs are performed in MCDRAM.
 
 The default settings for offload should give good performance.
 
-When using LAMMPS with offload to Intel coprocessors, best performance
+When using LAMMPS with offload to Intel co-processors, best performance
 will typically be achieved with concurrent calculations performed on
-both the CPU and the coprocessor. This is achieved by offloading only
+both the CPU and the co-processor. This is achieved by offloading only
-a fraction of the neighbor and pair computations to the coprocessor or
+a fraction of the neighbor and pair computations to the co-processor or
 using "hybrid"_pair_hybrid.html pair styles where only one style uses
 the "intel" suffix. For simulations with long-range electrostatics or
 bond, angle, dihedral, improper calculations, computation and data
-transfer to the coprocessor will run concurrently with computations
+transfer to the co-processor will run concurrently with computations
 and MPI communications for these calculations on the host CPU. This
 is illustrated in the figure below for the rhodopsin protein benchmark
 running on E5-2697v2 processors with a Intel Xeon Phi 7120p
-coprocessor. In this plot, the vertical access is time and routines
+co-processor. In this plot, the vertical access is time and routines
 running at the same time are running concurrently on both the host and
-the coprocessor.
+the co-processor.
 
 :c,image(JPG/offload_knc.png)
 
 The fraction of the offloaded work is controlled by the {balance}
 keyword in the "package intel"_package.html command. A balance of 0
 runs all calculations on the CPU.  A balance of 1 runs all
-supported calculations on the coprocessor.  A balance of 0.5 runs half
+supported calculations on the co-processor.  A balance of 0.5 runs half
-of the calculations on the coprocessor.  Setting the balance to -1
+of the calculations on the co-processor.  Setting the balance to -1
-(the default) will enable dynamic load balancing that continously
+(the default) will enable dynamic load balancing that continuously
 adjusts the fraction of offloaded work throughout the simulation.
 Because data transfer cannot be timed, this option typically produces
 results within 5 to 10 percent of the optimal fixed balance.
@@ -455,23 +455,23 @@ near-optimal setting that will carry over to additional runs.
 
 The default for the "package intel"_package.html command is to have
 all the MPI tasks on a given compute node use a single Xeon Phi
-coprocessor.  In general, running with a large number of MPI tasks on
+co-processor.  In general, running with a large number of MPI tasks on
 each node will perform best with offload.  Each MPI task will
 automatically get affinity to a subset of the hardware threads
-available on the coprocessor.  For example, if your card has 61 cores,
+available on the co-processor.  For example, if your card has 61 cores,
 with 60 cores available for offload and 4 hardware threads per core
 (240 total threads), running with 24 MPI tasks per node will cause
-each MPI task to use a subset of 10 threads on the coprocessor.  Fine
+each MPI task to use a subset of 10 threads on the co-processor.  Fine
 tuning of the number of threads to use per MPI task or the number of
 threads to use per core can be accomplished with keyword settings of
 the "package intel"_package.html command.
 
 The USER-INTEL package has two modes for deciding which atoms will be
-handled by the coprocessor.  This choice is controlled with the {ghost}
+handled by the co-processor.  This choice is controlled with the {ghost}
 keyword of the "package intel"_package.html command.  When set to 0,
 ghost atoms (atoms at the borders between MPI tasks) are not offloaded
 to the card.  This allows for overlap of MPI communication of forces
-with computation on the coprocessor when the "newton"_newton.html
+with computation on the co-processor when the "newton"_newton.html
 setting is "on".  The default is dependent on the style being used,
 however, better performance may be achieved by setting this option
 explicitly.
@@ -482,21 +482,21 @@ cores.  This is due to the fact that additional threads are generated
 internally to handle the asynchronous offload tasks.
 
 If pair computations are being offloaded to an Intel Xeon Phi
-coprocessor, a diagnostic line is printed to the screen (not to the
+co-processor, a diagnostic line is printed to the screen (not to the
 log file), during the setup phase of a run, indicating that offload
-mode is being used and indicating the number of coprocessor threads
+mode is being used and indicating the number of co-processor threads
 per MPI task.  Additionally, an offload timing summary is printed at
 the end of each run.  When offloading, the frequency for "atom
 sorting"_atom_modify.html is changed to 1 so that the per-atom data is
 effectively sorted at every rebuild of the neighbor lists. All the
-available coprocessor threads on each Phi will be divided among MPI
+available co-processor threads on each Phi will be divided among MPI
 tasks, unless the {tptask} option of the "-pk intel" "command-line
-switch"_Run_options.html is used to limit the coprocessor threads per
+switch"_Run_options.html is used to limit the co-processor threads per
 MPI task.
 
 [Restrictions:]
 
-When offloading to a coprocessor, "hybrid"_pair_hybrid.html styles
+When offloading to a co-processor, "hybrid"_pair_hybrid.html styles
 that require skip lists for neighbor builds cannot be offloaded.
 Using "hybrid/overlay"_pair_hybrid.html is allowed.  Only one intel
 accelerated style may be used with hybrid styles when offloading.

doc/src/Speed_kokkos.txt

@@ -17,7 +17,7 @@ different back end languages such as CUDA, OpenMP, or Pthreads.  The
 Kokkos library also provides data abstractions to adjust (at compile
 time) the memory layout of data structures like 2d and 3d arrays to
 optimize performance on different hardware. For more information on
-Kokkos, see "Github"_https://github.com/kokkos/kokkos. Kokkos is part
+Kokkos, see "GitHub"_https://github.com/kokkos/kokkos. Kokkos is part
 of "Trilinos"_http://trilinos.sandia.gov/packages/kokkos. The Kokkos
 library was written primarily by Carter Edwards, Christian Trott, and
 Dan Sunderland (all Sandia).
@@ -193,7 +193,7 @@ threads/task as Nt. The product of these two values should be N, i.e.
 NOTE: The default for the "package kokkos"_package.html command is to
 use "full" neighbor lists and set the Newton flag to "off" for both
 pairwise and bonded interactions. When running on KNL, this will
-typically be best for pair-wise potentials. For manybody potentials,
+typically be best for pair-wise potentials. For many-body potentials,
 using "half" neighbor lists and setting the Newton flag to "on" may be
 faster. It can also be faster to use non-threaded communication.  Use
 the "-pk kokkos" "command-line switch"_Run_options.html to change the
@@ -207,7 +207,7 @@ mpirun -np 64 lmp_kokkos_phi -k on t 4 -sf kk -pk kokkos newton on neigh half co
 NOTE: MPI tasks and threads should be bound to cores as described
 above for CPUs.
 
-NOTE: To build with Kokkos support for Intel Xeon Phi coprocessors
+NOTE: To build with Kokkos support for Intel Xeon Phi co-processors
 such as Knight's Corner (KNC), your system must be configured to use
 them in "native" mode, not "offload" mode like the USER-INTEL package
 supports.

doc/src/Speed_packages.txt

@@ -14,7 +14,7 @@ Accelerated versions of various "pair_style"_pair_style.html,
 been added to LAMMPS, which will typically run faster than the
 standard non-accelerated versions.  Some require appropriate hardware
 to be present on your system, e.g. GPUs or Intel Xeon Phi
-coprocessors.
+co-processors.
 
 All of these commands are in packages provided with LAMMPS.  An
 overview of packages is give on the "Packages"_Packages.html doc
@@ -161,7 +161,7 @@ package. These styles support vectorized single and mixed precision
 calculations, in addition to full double precision.  In extreme cases,
 this can provide speedups over 3.5x on CPUs.  The package also
 supports acceleration in "offload" mode to Intel(R) Xeon Phi(TM)
-coprocessors.  This can result in additional speedup over 2x depending
+co-processors.  This can result in additional speedup over 2x depending
 on the hardware configuration. :l
 
 Styles with a "kk" suffix are part of the KOKKOS package, and can be

doc/src/Tools.txt

@@ -163,7 +163,7 @@ for the "chain benchmark"_Speed_bench.html.
 
 colvars tools :h4,link(colvars)
 
-The colvars directory contains a collection of tools for postprocessing
+The colvars directory contains a collection of tools for post-processing
 data produced by the colvars collective variable library.
 To compile the tools, edit the makefile for your system and run "make".
 
@@ -406,15 +406,15 @@ supports it.  It has its own WWW page at
 msi2lmp tool :h4,link(msi)
 
 The msi2lmp sub-directory contains a tool for creating LAMMPS template
-input and data files from BIOVIA's Materias Studio files (formerly Accelrys'
+input and data files from BIOVIA's Materias Studio files (formerly
-Insight MD code, formerly MSI/Biosym and its Discover MD code).
+Accelrys' Insight MD code, formerly MSI/Biosym and its Discover MD code).
 
 This tool was written by John Carpenter (Cray), Michael Peachey
 (Cray), and Steve Lustig (Dupont). Several people contributed changes
 to remove bugs and adapt its output to changes in LAMMPS.
 
 This tool has several known limitations and is no longer under active
-development, so there are no changes except for the occasional bugfix.
+development, so there are no changes except for the occasional bug fix.
 
 See the README file in the tools/msi2lmp folder for more information.
 

doc/src/angle_sdk.txt

@@ -28,7 +28,7 @@ The {sdk} angle style is a combination of the harmonic angle potential,
 where theta0 is the equilibrium value of the angle and K a prefactor,
 with the {repulsive} part of the non-bonded {lj/sdk} pair style
 between the atoms 1 and 3.  This angle potential is intended for
-coarse grained MD simulations with the CMM parametrization using the
+coarse grained MD simulations with the CMM parameterization using the
 "pair_style lj/sdk"_pair_sdk.html.  Relative to the pair_style
 {lj/sdk}, however, the energy is shifted by {epsilon}, to avoid sudden
 jumps.  Note that the usual 1/2 factor is included in K.

doc/src/atom_style.txt

@@ -87,7 +87,7 @@ quantities.
 {line} | end points, angular velocity | rigid bodies |
 {meso} | rho, e, cv | SPH particles |
 {molecular} | bonds, angles, dihedrals, impropers | uncharged molecules |
-{peri} | mass, volume | mesocopic Peridynamic models |
+{peri} | mass, volume | mesoscopic Peridynamic models |
 {smd} | volume, kernel diameter, contact radius, mass | solid and fluid SPH particles |
 {sphere} | diameter, mass, angular velocity | granular models |
 {spin} | magnetic moment | system with magnetic particles |

doc/src/balance.txt

@@ -247,7 +247,7 @@ to {Niter} times.  After each dimension finishes, the imbalance factor
 is re-computed, and the balancing operation halts if the {stopthresh}
 criterion is met.
 
-A rebalance operation in a single dimension is performed using a
+A re-balance operation in a single dimension is performed using a
 recursive multisectioning algorithm, where the position of each
 cutting plane (line in 2d) in the dimension is adjusted independently.
 This is similar to a recursive bisectioning for a single value, except
@@ -261,11 +261,11 @@ information, so that they become closer together over time.  Thus as
 the recursion progresses, the count of particles on either side of the
 plane gets closer to the target value.
 
-Once the rebalancing is complete and final processor sub-domains
+Once the re-balancing is complete and final processor sub-domains
 assigned, particles are migrated to their new owning processor, and
 the balance procedure ends.
 
-NOTE: At each rebalance operation, the bisectioning for each cutting
+NOTE: At each re-balance operation, the bisectioning for each cutting
 plane (line in 2d) typically starts with low and high bounds separated
 by the extent of a processor's sub-domain in one dimension.  The size
 of this bracketing region shrinks by 1/2 every iteration.  Thus if
@@ -348,7 +348,7 @@ specified groups, its weight is not changed.  If it belongs to
 multiple groups, its weight is the product of the weight factors.
 
 This weight style is useful in combination with pair style
-"hybrid"_pair_hybrid.html, e.g. when combining a more costly manybody
+"hybrid"_pair_hybrid.html, e.g. when combining a more costly many-body
 potential with a fast pair-wise potential.  It is also useful when
 using "run_style respa"_run_style.html where some portions of the
 system have many bonded interactions and others none.  It assumes that

doc/src/bond_oxdna.txt

@@ -52,7 +52,7 @@ hydrogen-bonding interaction {oxdna/hbond} (see also documentation of
 "(Snodin)"_#oxdna2 bond style the analogous pair styles and an
 additional Debye-Hueckel pair style {oxdna2/dh} have to be defined.
 The coefficients in the above example have to be kept fixed and cannot
-be changed without reparametrizing the entire model.
+be changed without reparameterizing the entire model.
 
 Example input and data files for DNA duplexes can be found in
 examples/USER/cgdna/examples/oxDNA/ and /oxDNA2/.  A simple python

doc/src/comm_modify.txt

@@ -154,6 +154,6 @@ Communication mode {multi} is currently only available for
 
 [Default:]
 
-The option defauls are mode = single, group = all, cutoff = 0.0, vel =
+The option defaults are mode = single, group = all, cutoff = 0.0, vel =
 no.  The cutoff default of 0.0 means that ghost cutoff = neighbor
 cutoff = pairwise force cutoff + neighbor skin.

doc/src/compute_adf.txt

@@ -33,22 +33,22 @@ keyword = {ordinate} :l
 
 compute 1 fluid adf 32 1 1 1 0.0 1.2 0.0 1.2 &
                        1 1 2 0.0 1.2 0.0 1.5 &
-                       1 2 2 0.0 1.5 0.0 1.5 & 
+                       1 2 2 0.0 1.5 0.0 1.5 &
                        2 1 1 0.0 1.2 0.0 1.2 &
                        2 1 2 0.0 1.5 2.0 3.5 &
-                       2 2 2 2.0 3.5 2.0 3.5  
+                       2 2 2 2.0 3.5 2.0 3.5
 compute 1 fluid adf 32 1*2 1*2 1*2 0.5 3.5
 compute 1 fluid adf 32 :pre
 
 [Description:]
 
 Define a computation that calculates one or more angular distribution functions
-(ADF) for a group of particles.  Each ADF is calculated in histogram form 
+(ADF) for a group of particles.  Each ADF is calculated in histogram form
 by measuring the angle formed by a central atom and two neighbor atoms and
 binning these angles into {Nbin} bins.
 Only neighbors for which {Rinner} < {R} < {Router} are counted, where
 {Rinner} and {Router} are specified separately for the first and second
-neighbor atom in each requested ADF. 
+neighbor atom in each requested ADF.
 
 NOTE: If you have a bonded system, then the settings of
 "special_bonds"_special_bonds.html command can remove pairwise
@@ -66,18 +66,18 @@ the dump file.  The rerun script can use a
 "special_bonds"_special_bonds.html command that includes all pairs in
 the neighbor list.
 
-NOTE: If you request any outer cutoff {Router} > force cutoff, or if no 
+NOTE: If you request any outer cutoff {Router} > force cutoff, or if no
 pair style is defined,  e.g. the "rerun"_rerun.html command is being used to
-post-process a dump file of snapshots you must insure ghost atom information 
+post-process a dump file of snapshots you must insure ghost atom information
-out to the largest value of {Router} + {skin} is communicated, via the 
+out to the largest value of {Router} + {skin} is communicated, via the
-"comm_modify cutoff"_comm_modify.html command, else the ADF computation 
+"comm_modify cutoff"_comm_modify.html command, else the ADF computation
-cannot be performed, and LAMMPS will give an error message.  The {skin} value 
+cannot be performed, and LAMMPS will give an error message.  The {skin} value
-is what is specified with the "neighbor"_neighbor.html command.  
+is what is specified with the "neighbor"_neighbor.html command.
 
 The {itypeN},{jtypeN},{ktypeN} settings can be specified in one of two
 ways.  An explicit numeric value can be used, as in the 1st example
 above.  Or a wild-card asterisk can be used to specify a range of atom
-types as in the 2nd example above.  
+types as in the 2nd example above.
 This takes the form "*" or "*n" or "n*" or "m*n".  If N = the
 number of atom types, then an asterisk with no numeric values means
 all types from 1 to N.  A leading asterisk means all types from 1 to n
@@ -88,13 +88,13 @@ all types from 1 to N.  A leading asterisk means all types from 1 to n
 If {itypeN}, {jtypeN}, and {ktypeN} are single values, as in the 1st example
 above, this means that the ADF is computed where atoms of type {itypeN}
 are the central atom, and neighbor atoms of type {jtypeN} and {ktypeN}
-are forming the angle.  If any of {itypeN}, {jtypeN}, or {ktypeN} 
+are forming the angle.  If any of {itypeN}, {jtypeN}, or {ktypeN}
 represent a range of values via
 the wild-card asterisk, as in the 2nd example above, this means that the
 ADF is computed where atoms of any of the range of types represented
 by {itypeN} are the central atom, and the angle is formed by two neighbors,
-one neighbor in the range of types represented by {jtypeN} and another neighbor 
+one neighbor in the range of types represented by {jtypeN} and another neighbor
-in the range of types represented by {ktypeN}. 
+in the range of types represented by {ktypeN}.
 
 If no {itypeN}, {jtypeN}, {ktypeN} settings are specified, then
 LAMMPS will generate a single ADF for all atoms in the group.
@@ -106,13 +106,13 @@ Such an ADF is both uninformative and
 extremely expensive to compute.  For example, with liquid water
 with a 10 A force cutoff, there are 80,000 angles per atom.
 In addition, most of the interesting angular structure occurs for
-neighbors that are the closest to the central atom, involving 
+neighbors that are the closest to the central atom, involving
 just a few dozen angles.
 
-Angles for each ADF are generated by double-looping over the list of 
+Angles for each ADF are generated by double-looping over the list of
-neighbors of each central atom I, 
+neighbors of each central atom I,
-just as they would be in the force calculation for 
+just as they would be in the force calculation for
-a threebody potential such as "Stillinger-Weber"_pair_sw.html.  
+a three-body potential such as "Stillinger-Weber"_pair_sw.html.
 The angle formed by central atom I and neighbor atoms J and K is included in an
 ADF if the following criteria are met:
 
@@ -121,12 +121,12 @@ the distance between atoms I,J is between Rjinner and Rjouter
 the distance between atoms I,K is between Rkinner and Rkouter
 the type of the I atom matches itypeN (one or a range of types)
 atoms I,J,K are distinct
-the type of the J atom matches jtypeN (one or a range of types) 
+the type of the J atom matches jtypeN (one or a range of types)
 the type of the K atom matches ktypeN (one or a range of types) :ul
 
 Each unique angle satisfying the above criteria is counted only once, regardless
 of whether either or both of the neighbor atoms making up the
-angle appear in both the J and K lists. 
+angle appear in both the J and K lists.
 It is OK if a particular angle is included in more than
 one individual histogram, due to the way the {itypeN}, {jtypeN}, {ktypeN}
 arguments are specified.
@@ -146,15 +146,15 @@ number radial distribution function.
 
 The {ordinate} optional keyword determines
 whether the bins are of uniform angular size from zero
-to 180 ({degree}), zero to Pi ({radian}), or the 
+to 180 ({degree}), zero to Pi ({radian}), or the
 cosine of the angle uniform in the range \[-1,1\] ({cosine}).
 {cosine} has the advantage of eliminating the {acos()} function
 call, which speeds up the compute by 2-3x, and it is also preferred
-on physical grounds, because the for uniformly distributed particles 
+on physical grounds, because the for uniformly distributed particles
 in 3D, the angular probability density w.r.t dtheta is
-sin(theta)/2, while for d(cos(theta)), it is 1/2,  
+sin(theta)/2, while for d(cos(theta)), it is 1/2,
-Regardless of which ordinate is chosen, the first column of ADF 
+Regardless of which ordinate is chosen, the first column of ADF
-values is normalized w.r.t. the range of that ordinate, so that 
+values is normalized w.r.t. the range of that ordinate, so that
 the integral is 1.
 
 The simplest way to output the results of the compute adf calculation
@@ -170,7 +170,7 @@ This compute calculates a global array with the number of rows =
 {Nbins}, and the number of columns = 1 + 2*Ntriples, where Ntriples is the
 number of I,J,K triples specified.  The first column has the bin
 coordinate (angle-related ordinate at midpoint of bin). Each subsequent column has
-the two ADF values for a specific set of ({itypeN},{jtypeN},{ktypeN}) 
+the two ADF values for a specific set of ({itypeN},{jtypeN},{ktypeN})
 interactions, as described above.  These values can be used
 by any command that uses a global values from a compute as input.  See
 the "Howto output"_Howto_output.html doc page for an overview of
@@ -181,15 +181,15 @@ The array values calculated by this compute are all "intensive".
 The first column of array values is the angle-related ordinate, either
 the angle in degrees or radians, or the cosine of the angle.  Each
 subsequent pair of columns gives the first and second kinds of ADF
-for a specific set of ({itypeN},{jtypeN},{ktypeN}). The values 
+for a specific set of ({itypeN},{jtypeN},{ktypeN}). The values
 in the first ADF column are normalized numbers >= 0.0,
 whose integral w.r.t. the ordinate is 1,
-i.e. the first ADF is a normalized probability distribution. 
+i.e. the first ADF is a normalized probability distribution.
 The values in the second ADF column are also numbers >= 0.0.
 They are the cumulative density distribution of angles per atom.
 By definition, this ADF is monotonically increasing from zero to
 a maximum value equal to the average total number of
-angles per atom satisfying the ADF criteria. 
+angles per atom satisfying the ADF criteria.
 
 [Restrictions:]
 
@@ -200,7 +200,7 @@ distances, you can use the "rerun"_rerun.html 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
-your model.  
+your model.
 
 [Related commands:]
 

doc/src/compute_bond_local.txt

@@ -68,7 +68,7 @@ in the bond, which is simply 1/2 m1 v1^2 + 1/2 m2 v2^2, where v1 and
 v2 are the magnitude of the velocity of the 2 atoms along the bond
 direction, after the COM velocity has been subtracted from each.
 
-The value {engrot} is the rotationsl kinetic energy of the two atoms
+The value {engrot} is the rotational kinetic energy of the two atoms
 in the bond, which is simply 1/2 m1 v1^2 + 1/2 m2 v2^2, where v1 and
 v2 are the magnitude of the velocity of the 2 atoms perpendicular to
 the bond direction, after the COM velocity has been subtracted from

doc/src/compute_chunk_atom.txt

@@ -210,7 +210,7 @@ between {crmin} and {crmax}.  For example, if {crmin} = 1.0 and
 {crmax} = 10.0 and {ncbin} = 9, then the first bin spans 1.0 < r <
 2.0, and the last bin spans 9.0 < r 10.0.  The geometry of the bins in
 the radial dimensions is the same whether the simulation box is
-orthogonal or triclinic; i.e. the concetric circles are not tilted or
+orthogonal or triclinic; i.e. the concentric circles are not tilted or
 scaled differently in the two different dimensions to transform them
 into ellipses.
 

doc/src/compute_cna_atom.txt

@@ -33,7 +33,7 @@ Currently, there are five kinds of CNA patterns LAMMPS recognizes:
 fcc = 1
 hcp = 2
 bcc = 3
-icosohedral = 4
+icosahedral = 4
 unknown = 5 :ul
 
 The value of the CNA pattern will be 0 for atoms not in the specified

doc/src/compute_damage_atom.txt

@@ -26,7 +26,7 @@ in a group.  This is a quantity relevant for "Peridynamics
 models"_pair_peri.html.  See "this document"_PDF/PDLammps_overview.pdf
 for an overview of LAMMPS commands for Peridynamics modeling.
 
-The "damage" of a Peridymaics particles is based on the bond breakage
+The "damage" of a Peridynamics particles is based on the bond breakage
 between the particle and its neighbors.  If all the bonds are broken
 the particle is considered to be fully damaged.
 

doc/src/compute_displace_atom.txt

@@ -57,7 +57,7 @@ correctly with time=0 atom coordinates from the restart file.
 
 :line
 
-The {refresh} option can be used in conjuction with the "dump_modify
+The {refresh} option can be used in conjunction with the "dump_modify
 refresh" command to generate incremental dump files.
 
 The definition and motivation of an incremental dump file is as

doc/src/compute_msd.txt

@@ -50,7 +50,7 @@ The value of the displacement will be
 
 If the {com} option is set to {yes} then the effect of any drift in
 the center-of-mass of the group of atoms is subtracted out before the
-displacment of each atom is calculated.
+displacement of each atom is calculated.
 
 If the {average} option is set to {yes} then the reference position of
 an atom is based on the average position of that atom, corrected for

doc/src/compute_msd_nongauss.txt

@@ -48,7 +48,7 @@ others.
 
 If the {com} option is set to {yes} then the effect of any drift in
 the center-of-mass of the group of atoms is subtracted out before the
-displacment of each atom is calculated.
+displacement of each atom is calculated.
 
 See the "compute msd"_compute_msd.html doc page for further important
 NOTEs, which also apply to this compute.

doc/src/compute_pair.txt

@@ -15,7 +15,7 @@ compute ID group-ID pair pstyle \[nstyle\] \[evalue\]  :pre
 ID, group-ID are documented in "compute"_compute.html command :ulb,l
 pair = style name of this compute command :l
 pstyle = style name of a pair style that calculates additional values :l
-nsub = {n}-instance of a substyle, if a pair style is used multiple times in a hybrid style :l
+nsub = {n}-instance of a sub-style, if a pair style is used multiple times in a hybrid style :l
 {evalue} = {epair} or {evdwl} or {ecoul} or blank (optional) :l
 :ule
 

doc/src/compute_plasticity_atom.txt

@@ -30,7 +30,7 @@ The plasticity for a Peridynamic particle is the so-called consistency
 parameter (lambda).  For elastic deformation lambda = 0, otherwise
 lambda > 0 for plastic deformation.  For details, see
 "(Mitchell)"_#Mitchell and the PDF doc included in the LAMMPS
-distro in "doc/PDF/PDLammps_EPS.pdf"_PDF/PDLammps_EPS.pdf.
+distribution in "doc/PDF/PDLammps_EPS.pdf"_PDF/PDLammps_EPS.pdf.
 
 This command can be invoked for one of the Peridynamic "pair
 styles"_pair_peri.html: peri/eps.

doc/src/compute_pressure.txt

@@ -40,7 +40,7 @@ below), Kb is the Boltzmann constant, T is the temperature, d is the
 dimensionality of the system (2 or 3 for 2d/3d), and V is the system
 volume (or area in 2d).  The second term is the virial, equal to
 -dU/dV, computed for all pairwise as well as 2-body, 3-body, 4-body,
-manybody, and long-range interactions, where r_i and f_i are the
+many-body, and long-range interactions, where r_i and f_i are the
 position and force vector of atom i, and the black dot indicates a dot
 product.  When periodic boundary conditions are used, N' necessarily
 includes periodic image (ghost) atoms outside the central box, and the
@@ -68,7 +68,7 @@ compute temperature or ke and/or the virial.  The {virial} keyword
 means include all terms except the kinetic energy {ke}.
 
 Details of how LAMMPS computes the virial efficiently for the entire
-system, including for manybody potentials and accounting for the
+system, including for many-body potentials and accounting for the
 effects of periodic boundary conditions are discussed in
 "(Thompson)"_#Thompson1.
 

doc/src/compute_pressure_cylinder.txt

@@ -58,7 +58,7 @@ This compute currently calculates the pressure tensor contributions
 for pair styles only (i.e. no bond, angle, dihedral, etc. contributions
 and in the presence of bonded interactions, the result will be incorrect
 due to exclusions for special bonds)  and requires pair-wise force
-calculations not available for most manybody pair styles. K-space
+calculations not available for most many-body pair styles. K-space
 calculations are also excluded. Note that this pressure compute outputs
 the configurational terms only; the kinetic contribution is not included
 and may be calculated from the number density output by P_kin=density*k*T.

doc/src/compute_reduce.txt

@@ -61,7 +61,7 @@ or {max} options find the minimum or maximum value across all vector
 values.  The {ave} setting adds the vector values into a global total,
 then divides by the number of values in the vector.  The {sumsq}
 option sums the square of the values in the vector into a global
-total.  The {avesq} setting does the same as {sumsq}, then divdes the
+total.  The {avesq} setting does the same as {sumsq}, then divides the
 sum of squares by the number of values.  The last two options can be
 useful for calculating the variance of some quantity, e.g. variance =
 sumsq - ave^2.

doc/src/compute_reduce_chunk.txt

@@ -137,7 +137,7 @@ compute micelle all chunk/atom c_spread compress yes :pre
 Further analysis on a per-micelle basis can now be performed using any
 of the per-chunk computes listed on the "Howto chunk"_Howto_chunk.html
 doc page.  E.g. count the number of atoms in each micelle, calculate
-its center or mass, shape (moments of intertia), radius of gyration,
+its center or mass, shape (moments of inertia), radius of gyration,
 etc.
 
 compute prop all property/chunk micelle count

doc/src/compute_smd_hourglass_error.txt

@@ -29,7 +29,7 @@ within the neighborhood of the central node and the deformation
 gradient, the approximated relative separation will coincide with the
 actual relative separation of the particles i and j in the deformed
 configuration.  This compute is only really useful for debugging the
-hourglass control mechanim which is part of the Total-Lagrangian SPH
+hourglass control mechanism which is part of the Total-Lagrangian SPH
 pair style.
 
 See "this PDF guide"_PDF/SMD_LAMMPS_userguide.pdf to use Smooth

doc/src/compute_smd_tlsph_defgrad.txt

@@ -30,7 +30,7 @@ Mach Dynamics in LAMMPS.
 
 [Output info:]
 
-This compute outputss a per-particle vector of vectors (tensors),
+This compute outputs a per-particle vector of vectors (tensors),
 which can be accessed by any command that uses per-particle values
 from a compute as input. See the "Howto output"_Howto_output.html doc
 page for an overview of LAMMPS output options.

doc/src/compute_smd_tlsph_shape.txt

@@ -38,7 +38,7 @@ overview of LAMMPS output options.
 
 The per-particle vector has 7 entries. The first three entries
 correspond to the lengths of the ellipsoid's axes and have units of
-length.  These axis valus are computed as the contact radius times the
+length.  These axis values are computed as the contact radius times the
 xx, yy, or zz components of the Green-Lagrange strain tensor
 associated with the particle.  The next 4 values are quaternions
 (order: q, x, y, z) which describe the spatial rotation of the

doc/src/compute_stress_atom.txt

@@ -73,9 +73,9 @@ Note that the stress for each atom is due to its interaction with all
 other atoms in the simulation, not just with other atoms in the group.
 
 Details of how LAMMPS computes the virial for individual atoms for
-either pairwise or manybody potentials, and including the effects of
+either pairwise or many-body potentials, and including the effects of
 periodic boundary conditions is discussed in "(Thompson)"_#Thompson2.
-The basic idea for manybody potentials is to treat each component of
+The basic idea for many-body potentials is to treat each component of
 the force computation between a small cluster of atoms in the same
 manner as in the formula above for bond, angle, dihedral, etc
 interactions.  Namely the quantity R dot F is summed over the atoms in

doc/src/compute_tally.txt

@@ -47,7 +47,7 @@ the based classes of LAMMPS.
 The pairwise contributions are computing via a callback that the
 compute registers with the non-bonded pairwise force computation.
 This limits the use to systems that have no bonds, no Kspace, and no
-manybody interactions. On the other hand, the computation does not
+many-body interactions. On the other hand, the computation does not
 have to compute forces or energies a second time and thus can be much
 more efficient. The callback mechanism allows to write more complex
 pairwise property computations.

doc/src/compute_temp_asphere.txt

@@ -60,7 +60,7 @@ same.  If it does not rotate around the axis perpendicular to its
 circular cross section, then it should have 5 dof instead of 6 in 3d.
 The latter is the case for uniaxial ellipsoids in a "GayBerne
 model"_pair_gayberne.html since there is no induced torque around the
-optical axis.  It will also be the case for biaxial ellipsoids when
+optical axis.  It will also be the case for bi-axial ellipsoids when
 exactly two of the semiaxes have the same length and the corresponding
 relative well depths are equal.
 

doc/src/compute_temp_chunk.txt

@@ -118,7 +118,7 @@ or "fix rigid"_fix_rigid.html.  This is because those degrees of
 freedom (e.g. a constrained bond) could apply to sets of atoms that
 are both included and excluded from a specific chunk, and hence the
 concept is somewhat ill-defined.  In some cases, you can use the
-{adof} and {cdof} keywords to adjust the calculated degress of freedom
+{adof} and {cdof} keywords to adjust the calculated degrees of freedom
 appropriately, as explained below.
 
 Note that the per-chunk temperature calculated by this compute and the

doc/src/compute_temp_cs.txt

@@ -74,7 +74,7 @@ relative to the COM velocity of the core/shell pair.  If this compute
 is used with a fix command that performs thermostatting then this bias
 will be subtracted from each atom, thermostatting of the remaining COM
 velocity will be performed, and the bias will be added back in.  This
-means the thermostating will effectively be performed on the
+means the thermostatting will effectively be performed on the
 core/shell pairs, instead of on the individual core and shell atoms.
 Thermostatting fixes that work in this way include "fix
 nvt"_fix_nh.html, "fix temp/rescale"_fix_temp_rescale.html, "fix

doc/src/create_box.txt

@@ -58,7 +58,7 @@ edge vectors starting from the origin given by A = (xhi-xlo,0,0); B =
 (xy,yhi-ylo,0); C = (xz,yz,zhi-zlo).  {Xy,xz,yz} can be 0.0 or
 positive or negative values and are called "tilt factors" because they
 are the amount of displacement applied to faces of an originally
-orthogonal box to transform it into the parallelipiped.
+orthogonal box to transform it into the parallelepiped.
 
 By default, a {prism} region used with the create_box command must
 have tilt factors (xy,xz,yz) that do not skew the box more than half

doc/src/dihedral_charmm.txt

@@ -41,7 +41,7 @@ field.
 NOTE: The newer {charmmfsw} style was released in March 2017.  We
 recommend it be used instead of the older {charmm} style when running
 a simulation with the CHARMM force field, either with long-range
-Coulombics or a Coulomb cutoff, via the "pair_style
+Coulombics or a Coulombic cutoff, via the "pair_style
 lj/charmmfsw/coul/long"_pair_charmm.html and "pair_style
 lj/charmmfsw/coul/charmmfsh"_pair_charmm.html commands respectively.
 Otherwise the older {charmm} style is fine to use.  See the discussion
@@ -87,7 +87,7 @@ special_bonds 1-4 scaling factor to 0.0 (which is the
 default). Otherwise 1-4 non-bonded interactions in dihedrals will be
 computed twice.
 
-For simulations using the CHARMM force field with a Coulomb cutoff,
+For simulations using the CHARMM force field with a Coulombic cutoff,
 the difference between the {charmm} and {charmmfsw} styles is in the
 computation of the 1-4 non-bond interactions, though only if the
 distance between the two atoms is within the switching region of the

doc/src/dump_h5md.txt

@@ -17,7 +17,7 @@ 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"
+args = list of data elements to dump, with their dump "sub-intervals"
   position options
   image
   velocity options
@@ -63,7 +63,7 @@ another particle group must specify {create_group yes}.
 :link(h5md,http://nongnu.org/h5md/)
 
 Each data element is written every N*N_element steps. For {image}, no
-subinterval is needed as it must be present at the same interval as
+sub-interval is needed as it must be present at the same interval as
 {position}.  {image} must be given after {position} in any case.  The
 box information (edges in each dimension) is stored at the same
 interval than the {position} element, if present. Else it is stored
@@ -76,7 +76,7 @@ written to a dump file may be slightly outside the simulation box.
 [Use from write_dump:]
 
 It is possible to use this dump style with the
-"write_dump"_write_dump.html command.  In this case, the subintervals
+"write_dump"_write_dump.html command.  In this case, the sub-intervals
 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 {file_from} keyword.

doc/src/dump_image.txt

@@ -541,10 +541,11 @@ a) Use the ImageMagick convert program. :ulb,l
 % convert *.jpg foo.gif
 % convert -loop 1 *.ppm foo.mpg :pre
 
-Animated GIF files from ImageMagick are unoptimized. You can use a
+Animated GIF files from ImageMagick are not optimized. You can use
-program like gifsicle to optimize and massively shrink them.
+a program like gifsicle to optimize and thus massively shrink them.
-MPEG files created by ImageMagick are in MPEG-1 format with rather
+MPEG files created by ImageMagick are in MPEG-1 format with a rather
-inefficient compression and low quality.
+inefficient compression and low quality compared to more modern
+compression styles like MPEG-4, H.264, VP8, VP9, H.265 and so on.
 
 b) Use QuickTime. :l
 
@@ -564,7 +565,7 @@ allows extremely flexible encoding and decoding of movies.
 cat snap.*.jpg | ffmpeg -y -f image2pipe -c:v mjpeg -i - -b:v 2000k movie.m4v
 cat snap.*.ppm | ffmpeg -y -f image2pipe -c:v ppm -i - -b:v 2400k movie.avi :pre
 
-Frontends for FFmpeg exist for multiple platforms. For more
+Front ends for FFmpeg exist for multiple platforms. For more
 information see the "FFmpeg homepage"_http://www.ffmpeg.org/
 
 :ule

doc/src/dump_modify.txt

@@ -201,7 +201,7 @@ atom type (1 to Ntype) in the simulation.  The same element name can
 be given to multiple atom types.
 
 In the case of {xyz} format dumps, there are no restrictions to what
-label can be used as an element name.  Any whitespace separated text
+label can be used as an element name.  Any white-space separated text
 will be accepted.
 
 :link(atomeye,http://mt.seas.upenn.edu/Archive/Graphics/A)
@@ -667,7 +667,7 @@ command, when its atom diameter setting is {type}, to set the size
 that atoms of each type will be drawn in the image.  The specified
 {type} should be an integer from 1 to Ntypes.  As with the {acolor}
 keyword, a wildcard asterisk can be used as part of the {type}
-argument to specify a range of atomt types.  The specified {diam} is
+argument to specify a range of atom types.  The specified {diam} is
 the size in whatever distance "units"_units.html the input script is
 using, e.g. Angstroms.
 

doc/src/fix.txt

@@ -202,7 +202,7 @@ accelerated styles exist.
 "dt/reset"_fix_dt_reset.html - reset the timestep based on velocity, forces
 "edpd/source"_fix_dpd_source.html - 
 "efield"_fix_efield.html - impose electric field on system
-"ehex"_fix_ehex.html - ehanced heat exchange algorithm
+"ehex"_fix_ehex.html - enhanced heat exchange algorithm
 "enforce2d"_fix_enforce2d.html - zero out z-dimension velocity and force
 "eos/cv"_fix_eos_cv.html - 
 "eos/table"_fix_eos_table.html - 

doc/src/fix_append_atoms.txt

@@ -28,7 +28,7 @@ keyword = {basis} or {size} or {freq} or {temp} or {random} or {units}  :l
     target = target temperature for the region between zhi-extent and zhi (temperature units)
     damp = damping parameter (time units)
     seed = random number seed for langevin kicks
-    extent = extent of thermostated region (distance units)
+    extent = extent of thermostatted region (distance units)
   {random} args = xmax ymax zmax seed
     {xmax}, {ymax}, {zmax} = maximum displacement in particular direction (distance units)
     {seed} = random number seed for random displacement
@@ -68,7 +68,7 @@ be added.
 The {random} keyword will give the atoms random displacements around
 their lattice points to simulate some initial temperature.
 
-The {temp} keyword will cause a region to be thermostated with a
+The {temp} keyword will cause a region to be thermostatted with a
 Langevin thermostat on the zhi boundary.  The size of the region is
 measured from zhi and is set with the {extent} argument.
 

doc/src/fix_ave_chunk.txt

@@ -240,7 +240,7 @@ shake"_fix_shake.html or "fix rigid"_fix_rigid.html.  This is because
 those degrees of freedom (e.g. a constrained bond) could apply to sets
 of atoms that are both included and excluded from a specific chunk,
 and hence the concept is somewhat ill-defined.  In some cases, you can
-use the {adof} and {cdof} keywords to adjust the calculated degress of
+use the {adof} and {cdof} keywords to adjust the calculated degrees of
 freedom appropriately, as explained below.
 
 Also note that a bias can be subtracted from atom velocities before

doc/src/fix_ave_time.txt

@@ -133,7 +133,7 @@ fix 2 all ave/time 100 1 100 c_myRDF\[1\] c_myRDF\[2\] c_myRDF\[3\] file tmp2.rd
 The {Nevery}, {Nrepeat}, and {Nfreq} arguments specify on what
 timesteps the input values will be used in order to contribute to the
 average.  The final averaged quantities are generated on timesteps
-that are a mlutiple of {Nfreq}.  The average is over {Nrepeat}
+that are a multiple of {Nfreq}.  The average is over {Nrepeat}
 quantities, computed in the preceding portion of the simulation every
 {Nevery} timesteps.  {Nfreq} must be a multiple of {Nevery} and
 {Nevery} must be non-zero even if {Nrepeat} is 1.  Also, the timesteps

doc/src/fix_balance.txt

@@ -57,7 +57,7 @@ This command adjusts the size and shape of processor sub-domains
 within the simulation box, to attempt to balance the number of
 particles and thus the computational cost (load) evenly across
 processors.  The load balancing is "dynamic" in the sense that
-rebalancing is performed periodically during the simulation.  To
+re-balancing is performed periodically during the simulation.  To
 perform "static" balancing, before or between runs, see the
 "balance"_balance.html command.
 
@@ -178,15 +178,15 @@ The {group-ID} is ignored.  However the impact of balancing on
 different groups of atoms can be affected by using the {group} weight
 style as described below.
 
-The {Nfreq} setting determines how often a rebalance is performed.  If
+The {Nfreq} setting determines how often a re-balance is performed.  If
-{Nfreq} > 0, then rebalancing will occur every {Nfreq} steps.  Each
+{Nfreq} > 0, then re-balancing will occur every {Nfreq} steps.  Each
-time a rebalance occurs, a reneighboring is triggered, so {Nfreq}
+time a re-balance occurs, a reneighboring is triggered, so {Nfreq}
-should not be too small.  If {Nfreq} = 0, then rebalancing will be
+should not be too small.  If {Nfreq} = 0, then re-balancing will be
 done every time reneighboring normally occurs, as determined by the
 the "neighbor"_neighbor.html and "neigh_modify"_neigh_modify.html
 command settings.
 
-On rebalance steps, rebalancing will only be attempted if the current
+On re-balance steps, re-balancing will only be attempted if the current
 imbalance factor, as defined above, exceeds the {thresh} setting.
 
 :line
@@ -208,7 +208,7 @@ to {Niter} times.  After each dimension finishes, the imbalance factor
 is re-computed, and the balancing operation halts if the {stopthresh}
 criterion is met.
 
-A rebalance operation in a single dimension is performed using a
+A re-balance operation in a single dimension is performed using a
 density-dependent recursive multisectioning algorithm, where the
 position of each cutting plane (line in 2d) in the dimension is
 adjusted independently.  This is similar to a recursive bisectioning
@@ -226,19 +226,19 @@ the recursion progresses, the count of particles on either side of the
 plane gets closer to the target value.
 
 The density-dependent part of this algorithm is often an advantage
-when you rebalance a system that is already nearly balanced.  It
+when you re-balance a system that is already nearly balanced.  It
 typically converges more quickly than the geometric bisectioning
 algorithm used by the "balance"_balance.html command.  However, if can
-be a disadvantage if you attempt to rebalance a system that is far
+be a disadvantage if you attempt to re-balance a system that is far
 from balanced, and converge more slowly.  In this case you probably
 want to use the "balance"_balance.html command before starting a run,
 so that you begin the run with a balanced system.
 
-Once the rebalancing is complete and final processor sub-domains
+Once the re-balancing is complete and final processor sub-domains
 assigned, particles migrate to their new owning processor as part of
 the normal reneighboring procedure.
 
-NOTE: At each rebalance operation, the bisectioning for each cutting
+NOTE: At each re-balance operation, the bisectioning for each cutting
 plane (line in 2d) typically starts with low and high bounds separated
 by the extent of a processor's sub-domain in one dimension.  The size
 of this bracketing region shrinks based on the local density, as
@@ -248,7 +248,7 @@ typically be positioned to better than 1 part in 1000 accuracy
 (relative to the perfect target position).  For {Niter} = 20, it will
 be accurate to better than 1 part in a million.  Thus there is no need
 to set {Niter} to a large value.  This is especially true if you are
-rebalancing often enough that each time you expect only an incremental
+re-balancing often enough that each time you expect only an incremental
 adjustment in the cutting planes is necessary.  LAMMPS will check if
 the threshold accuracy is reached (in a dimension) is less iterations
 than {Niter} and exit early.
@@ -283,7 +283,7 @@ in that sub-box.
 :line
 
 The {out} keyword writes text to the specified {filename} with the
-results of each rebalancing operation.  The file contains the bounds
+results of each re-balancing operation.  The file contains the bounds
 of the sub-domain for each processor after the balancing operation
 completes.  The format of the file is compatible with the
 "Pizza.py"_pizza {mdump} tool which has support for manipulating and
@@ -344,13 +344,13 @@ files"_restart.html.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.
 
 This fix computes a global scalar which is the imbalance factor
-after the most recent rebalance and a global vector of length 3 with
+after the most recent re-balance and a global vector of length 3 with
-additional information about the most recent rebalancing.  The 3
+additional information about the most recent re-balancing.  The 3
 values in the vector are as follows:
 
 1 = max # of particles per processor
-2 = total # iterations performed in last rebalance
+2 = total # iterations performed in last re-balance
-3 = imbalance factor right before the last rebalance was performed :ul
+3 = imbalance factor right before the last re-balance was performed :ul
 
 As explained above, the imbalance factor is the ratio of the maximum
 number of particles (or total weight) on any processor to the average

doc/src/fix_bocs.txt

@@ -91,7 +91,7 @@ package"_Build_package.html doc page for more info.
 [Related:]
 
 For more details about the pressure correction and the entire BOCS software 
-package, visit the "BOCS package on github"_bocsgithub and read the release 
+package, visit the "BOCS package on GitHub"_bocsgithub and read the release 
 paper by Dunn et. al. "(Dunn2)"_#bocs-Dunn2 .
 
 

doc/src/fix_bond_break.txt

@@ -101,7 +101,7 @@ NOTE: Breaking a bond typically alters the energy of a system.  You
 should be careful not to choose bond breaking criteria that induce a
 dramatic change in energy.  For example, if you define a very stiff
 harmonic bond and break it when 2 atoms are separated by a distance
-far from the equilibribum bond length, then the 2 atoms will be
+far from the equilibrium bond length, then the 2 atoms will be
 dramatically released when the bond is broken.  More generally, you
 may need to thermostat your system to compensate for energy changes
 resulting from broken bonds (and angles, dihedrals, impropers).

doc/src/fix_bond_create.txt

@@ -139,8 +139,8 @@ for "extra angle per atom", "extra dihedral per atom", and "extra
 improper per atom" if angles, dihedrals, or impropers are being added
 when bonds are created.  See the "read_data"_read_data.html or
 "create_box"_create_box.html command for more details.  Note that a
-data file with no atoms can be used if you wish to add unbonded atoms
+data file with no atoms can be used if you wish to add non-bonded
-via the "create atoms"_create_atoms.html command, e.g. for a
+atoms via the "create atoms"_create_atoms.html command, e.g. for a
 percolation simulation.
 
 NOTE: LAMMPS stores and maintains a data structure with a list of the
@@ -196,7 +196,7 @@ NOTE: Creating a bond typically alters the energy of a system.  You
 should be careful not to choose bond creation criteria that induce a
 dramatic change in energy.  For example, if you define a very stiff
 harmonic bond and create it when 2 atoms are separated by a distance
-far from the equilibribum bond length, then the 2 atoms will oscillate
+far from the equilibrium bond length, then the 2 atoms will oscillate
 dramatically when the bond is formed.  More generally, you may need to
 thermostat your system to compensate for energy changes resulting from
 created bonds (and angles, dihedrals, impropers).

doc/src/fix_bond_react.txt

@@ -79,7 +79,7 @@ probabilistic criteria to effect predetermined topology changes in
 simulations using standard force fields.
 
 This fix was created to facilitate the dynamic creation of polymeric,
-amorphous or highly-crosslinked systems. A suggested workflow for
+amorphous or highly cross-linked systems. A suggested workflow for
 using this fix is: 1) identify a reaction to be simulated 2) build a
 molecule template of the reaction site before the reaction has
 occurred 3) build a molecule template of the reaction site after the

doc/src/fix_bond_swap.txt

@@ -84,7 +84,7 @@ the molecule IDs for your polymer chains in a certain way, typically
 in the data file, read by the "read_data"_read_data.html command.
 Consider a system of 6-mer chains.  You have 2 choices.  If the
 molecule IDs for monomers on each chain are set to 1,2,3,4,5,6 then
-swaps will conserve chain length.  For a particular momoner there will
+swaps will conserve chain length.  For a particular monomer there will
 be only one other monomer on another chain which is a potential swap
 partner.  If the molecule IDs for monomers on each chain are set to
 1,2,3,3,2,1 then swaps will conserve chain length but swaps will be

doc/src/fix_client_md.txt

@@ -51,7 +51,7 @@ md"_server_md.html doc page.
 Note that when using LAMMPS as an MD client, your LAMMPS input script
 should not normally contain force field commands, like a
 "pair_style"_pair_style.html, "bond_style"_bond_style.html, or
-"kspace_style"_kspace_style.html commmand.  However it is possible for
+"kspace_style"_kspace_style.html command.  However it is possible for
 a server code to only compute a portion of the full force-field, while
 LAMMPS computes the remaining part.  Your LAMMPS script can also
 specify boundary conditions or force constraints in the usual way,

doc/src/fix_cmap.txt

@@ -24,12 +24,12 @@ fix_modify     myCMAP energy yes :pre
 
 [Description:]
 
-This command enables CMAP crossterms to be added to simulations which
+This command enables CMAP cross-terms to be added to simulations which
 use the CHARMM force field.  These are relevant for any CHARMM model
 of a peptide or protein sequences that is 3 or more amino-acid
 residues long; see "(Buck)"_#Buck and "(Brooks)"_#Brooks2 for details,
 including the analytic energy expressions for CMAP interactions.  The
-CMAP crossterms add additional potential energy contributions to pairs
+CMAP cross-terms add additional potential energy contributions to pairs
 of overlapping phi-psi dihedrals of amino-acids, which are important
 to properly represent their conformational behavior.
 
@@ -49,7 +49,7 @@ in its header section:
 
 N crossterms :pre
 
-where N is the number of CMAP crossterms.  It should also have a section
+where N is the number of CMAP cross-terms.  It should also have a section
 in the body of the data file like this with N lines:
 
 CMAP :pre
@@ -69,7 +69,7 @@ sections match those specified in the read_data command following the
 data file name; see the "read_data"_read_data.html doc page for
 more details.
 
-A data file containing CMAP crossterms can be generated from a PDB
+A data file containing CMAP cross-terms can be generated from a PDB
 file using the charmm2lammps.pl script in the tools/ch2lmp directory
 of the LAMMPS distribution.  The script must be invoked with the
 optional "-cmap" flag to do this; see the tools/ch2lmp/README file for
@@ -87,7 +87,7 @@ the note below about how to include the CMAP energy when performing an
 
 [Restart, fix_modify, output, run start/stop, minimize info:]
 
-This fix writes the list of CMAP crossterms to "binary restart
+This fix writes the list of CMAP cross-terms to "binary restart
 files"_restart.html.  See the "read_restart"_read_restart.html command
 for info on how to re-specify a fix in an input script that reads a
 restart file, so that the operation of the fix continues in an

doc/src/fix_colvars.txt

@@ -81,7 +81,7 @@ the image flags to reconstruct the absolute atom positions.
 Setting this to {no} will use the current local coordinates that are
 wrapped back into the simulation cell at each re-neighboring instead.
 
-The {tstat} keyword can be either NULL or the label of a thermostating
+The {tstat} keyword can be either NULL or the label of a thermostatting
 fix that thermostats all atoms in the fix colvars group. This will be
 used to provide the colvars module with the current thermostat target
 temperature.

doc/src/fix_deposit.txt

@@ -255,7 +255,7 @@ temperature compute you are using.
 
 This fix writes the state of the deposition to "binary restart
 files"_restart.html.  This includes information about how many
-particles have been depositied, the random number generator seed, the
+particles have been deposited, the random number generator seed, the
 next timestep for deposition, etc.  See the
 "read_restart"_read_restart.html command for info on how to re-specify
 a fix in an input script that reads a restart file, so that the

doc/src/fix_drude_transform.txt

@@ -91,8 +91,8 @@ different temperatures, two Nose-Hoover thermostats must be defined,
 acting on two distinct groups.
 
 NOTE: The {fix drude/transform/direct} command must appear before any
-Nose-Hoover thermostating fixes.  The {fix drude/transform/inverse}
+Nose-Hoover thermostatting fixes.  The {fix drude/transform/inverse}
-command must appear after any Nose-Hoover thermostating fixes.
+command must appear after any Nose-Hoover thermostatting fixes.
 
 Example:
 
@@ -106,8 +106,8 @@ thermo_style custom step cpu etotal ke pe ebond ecoul elong press vol temp c_TDR
 
 In this example, {gCORES} is the group of the atom cores and {gDRUDES}
 is the group of the Drude particles (electrons). The centers of mass
-of the Drude oscillators will be thermostated at 300.0 and the
+of the Drude oscillators will be thermostatted at 300.0 and the
-internal degrees of freedom will be thermostated at 1.0.  The
+internal degrees of freedom will be thermostatted at 1.0.  The
 temperatures of cores and Drude particles, in center-of-mass and
 relative coordinates, are calculated using "compute
 temp/drude"_compute_temp_drude.html
@@ -130,8 +130,8 @@ fix fINVERSE all drude/transform/inverse :pre
 
 In this example, {gCORES} is the group of the atom cores and {gDRUDES}
 is the group of the Drude particles. The centers of mass of the Drude
-oscillators will be thermostated at 298.0 and the internal degrees of
+oscillators will be thermostatted at 298.0 and the internal degrees of
-freedom will be thermostated at 5.0. The whole system will be
+freedom will be thermostatted at 5.0. The whole system will be
 barostatted at 1.0.
 
 In order to avoid the flying ice cube problem (irreversible transfer

doc/src/fix_ehex.txt

@@ -80,9 +80,9 @@ position to the respective reservoir. The quantity
 \(F_\{\Gamma_\{k(\mathbf r_i)\}\}\) corresponds to the input parameter
 {F}, which is the energy flux into the reservoir. Furthermore,
 \(K_\{\Gamma_\{k(\mathbf r_i)\}\}\) and \(v_\{\Gamma_\{k(\mathbf r_i)\}\}\)
-denote the non-translational kinetic energy and the centre of mass
+denote the non-translational kinetic energy and the center of mass
 velocity of that reservoir. The thermostatting force does not affect
-the centre of mass velocities of the individual reservoirs and the
+the center of mass velocities of the individual reservoirs and the
 entire simulation box. A derivation of the equations and details on
 the numerical implementation with velocity Verlet in LAMMPS can be
 found in reference "(Wirnsberger)"#_Wirnsberger.
@@ -116,10 +116,10 @@ specified in the input script and the keyword {constrain} is set, the
 bond distances will be corrected a second time at the end of the
 integration step.  It is recommended to specify the keyword {com} in
 addition to the keyword {constrain}. With this option all sites of a
-constrained cluster are rescaled, if its centre of mass is located
+constrained cluster are rescaled, if its center of mass is located
 inside the region. Rescaling all sites of a cluster by the same factor
 does not introduce any velocity components along fixed bonds. No
-rescaling takes place if the centre of mass lies outside the region.
+rescaling takes place if the center of mass lies outside the region.
 
 NOTE: You can only use the keyword {com} along with {constrain}.
 

doc/src/fix_eos_table.txt

@@ -35,13 +35,13 @@ temperature.
 
 The interpolation tables are created by fitting cubic splines to the
 file values and interpolating energy values at each of {N} internal
-temperatures, and vice-versa.  During a simulation, these tables are
+temperatures, and vice versa.  During a simulation, these tables are
 used to interpolate internal energy or temperature values as needed.
 The interpolation is done with the {linear} style.
 
 For the {linear} style, the internal temperature is used to find 2
 surrounding table values from which an internal energy is computed by
-linear interpolation, and vice-versa.
+linear interpolation, and vice versa.
 
 The filename specifies a file containing tabulated internal
 temperature and internal energy values.  The keyword specifies a

doc/src/fix_evaporate.txt

@@ -54,8 +54,8 @@ just the single atom is deleted.
 As an example, if you wish to delete 10 water molecules every {N}
 steps, you should set {M} to 30.  If only the water's oxygen atoms
 were in the fix group, then two hydrogen atoms would be deleted when
-an oxygen atom is selected for deletion, whether the hydrogens are
+an oxygen atom is selected for deletion, whether the hydrogen atoms
-inside the evaporation region or not.
+are inside the evaporation region or not.
 
 Note that neighbor lists are re-built on timesteps that atoms are
 removed.  Thus you should not remove atoms too frequently or you will

doc/src/fix_grem.txt

@@ -53,7 +53,7 @@ particles as usual. Either constant volume or constant pressure
 algorithms can be used.
 
 The fix enforces a generalized ensemble in a single replica
-only. Typically, this ideaology is combined with replica exchange with
+only. Typically, this ideology is combined with replica exchange with
 replicas differing by {lambda} only for simplicity, but this is not
 required. A multi-replica simulation can be run within the LAMMPS
 environment using the "temper/grem"_temper_grem.html command. This

doc/src/fix_heat.txt

@@ -109,7 +109,7 @@ are relevant to this fix.
 
 This fix computes a global scalar which can be accessed by various
 "output commands"_Howto_output.html.  This scalar is the most recent
-value by which velocites were scaled.  The scalar value calculated by
+value by which velocities were scaled.  The scalar value calculated by
 this fix is "intensive".  If {eflux} is specified as an atom-style
 variable, this fix computes the average value by which the velocities
 were scaled for all of the atoms that had their velocities scaled.

doc/src/fix_hyper_global.txt

@@ -205,12 +205,12 @@ the current timestep.  The vector stores the following quantities:
 7 = max drift distance of any atom during this run (distance units)
 8 = max bond length during this run (distance units) :ul
 
-9 = cummulative hyper time since fix was defined (time units)
+9 = cumulative hyper time since fix was defined (time units)
-10 = cummulative count of event timesteps since fix was defined
+10 = cumulative count of event timesteps since fix was defined
-11 = cummulative count of atoms in events since fix was defined :ul
+11 = cumulative count of atoms in events since fix was defined :ul
 
 The first 5 quantities are for the current timestep.  Quantities 6-8
-are for the current hyper run.  Quantities 9-11 are cummulative across
+are for the current hyper run.  Quantities 9-11 are cumulative across
 multiple runs (since the fix was defined in the input script).
 
 For value 7, drift is the distance an atom moves between timesteps
@@ -228,7 +228,7 @@ For value 11, each time the "hyper"_hyper.html command checks for an
 event, it invokes a compute to flag zero or more atoms as
 participating in one or more events.  E.g. atoms that have displaced
 more than some distance from the previous quench state.  Value 11 is
-the cummulative count of the number of atoms participating in any of
+the cumulative count of the number of atoms participating in any of
 the events that were found.
 
 The scalar and vector values calculated by this fix are all

doc/src/fix_hyper_local.txt

@@ -310,14 +310,14 @@ quantities:
 18 = count of bias overlaps found during this run
 19 = count of non-matching bias coefficients found during this run :ul
 
-20 = cummulative hyper time since fix created (time units)
+20 = cumulative hyper time since fix created (time units)
-21 = cummulative count of event timesteps since fix created
+21 = cumulative count of event timesteps since fix created
-22 = cummulative count of atoms in events since fix created
+22 = cumulative count of atoms in events since fix created
-23 = cummulative # of new bonds since fix created :ul
+23 = cumulative # of new bonds since fix created :ul
 
 The first quantities (1-5) are for the current timestep.  Quantities
 6-19 are for the current hyper run.  They are reset each time a new
-hyper run is performed.  Quantities 20-23 are cummulative across
+hyper run is performed.  Quantities 20-23 are cumulative across
 multiple runs (since the fix was defined in the input script).
 
 For value 6, the numerator is a count of all biased bonds on every
@@ -333,7 +333,7 @@ For values 13 and 14, the maxstrain of a ghost atom is the maxstrain
 of any bond it is part of, and it is checked for ghost atoms within
 the bond neighbor cutoff.
 
-Values 15-19 are mostly useful for debugging and diagnositc purposes.
+Values 15-19 are mostly useful for debugging and diagnostic purposes.
 
 For values 15-17, it is possible that a ghost atom owned by another
 processor will move far enough (e.g. as part of an event-in-progress)
@@ -367,7 +367,7 @@ For value 22, each time the "hyper"_hyper.html command checks for an
 event, it invokes a compute to flag zero or more atoms as
 participating in one or more events.  E.g. atoms that have displaced
 more than some distance from the previous quench state.  Value 22 is
-the cummulative count of the number of atoms participating in any of
+the cumulative count of the number of atoms participating in any of
 the events that were found.
 
 Value 23 tallies the number of new bonds created by the bond reset

doc/src/fix_imd.txt

@@ -41,7 +41,7 @@ it allows LAMMPS to connect an IMD client, for example the "VMD
 visualization program"_VMD, so that it can monitor the progress of the
 simulation and interactively apply forces to selected atoms.
 
-If LAMMPS is compiled with the preprocessor flag -DLAMMPS_ASYNC_IMD
+If LAMMPS is compiled with the pre-processor flag -DLAMMPS_ASYNC_IMD
 then fix imd will use POSIX threads to spawn a IMD communication
 thread on MPI rank 0 in order to offload data reading and writing
 from the main execution thread and potentially lower the inferred

doc/src/fix_indent.txt

@@ -129,7 +129,7 @@ variable rate equal 1.0
 variable r equal "v_r0 + step*dt*v_rate" :pre
 
 If the {side} keyword is specified as {out}, which is the default,
-then particles outside the indenter are pushded away from its outer
+then particles outside the indenter are pushed away from its outer
 surface, as described above.  This only applies to spherical or
 cylindrical indenters.  If the {side} keyword is specified as {in},
 the action of the indenter is reversed.  Particles inside the indenter

doc/src/fix_langevin.txt

@@ -179,7 +179,7 @@ options.
 For the {omega} keyword there is also a scale factor of 10.0/3.0 that
 is applied as a multiplier on the Ff (damping) term in the equation
 above and of sqrt(10.0/3.0) as a multiplier on the Fr term.  This does
-not affect the thermostatting behaviour of the Langevin formalism but
+not affect the thermostatting behavior of the Langevin formalism but
 insures that the randomized rotational diffusivity of spherical
 particles is correct.
 

doc/src/fix_langevin_drude.txt

@@ -78,22 +78,22 @@ transform:
 \begin\{equation\} F = \frac M \{M'\}\, F' - f' \end\{equation\}
 \begin\{equation\} f = \frac m \{M'\}\, F' + f' \end\{equation\}
 
-This fix also thermostates non-polarizable atoms in the group at
+This fix also thermostats non-polarizable atoms in the group at
 temperature {Tcom}, as if they had a massless Drude partner.  The
 Drude particles themselves need not be in the group. The center of
-mass and the dipole are thermostated iff the core atom is in the
+mass and the dipole are thermostatted iff the core atom is in the
 group.
 
 Note that the thermostat effect of this fix is applied to only the
 translational degrees of freedom of the particles, which is an
 important consideration if finite-size particles, which have
-rotational degrees of freedom, are being thermostated. The
+rotational degrees of freedom, are being thermostatted. The
 translational degrees of freedom can also have a bias velocity removed
-from them before thermostating takes place; see the description below.
+from them before thermostatting takes place; see the description below.
 
 NOTE: Like the "fix langevin"_fix_langevin.html command, this fix does
 NOT perform time integration. It only modifies forces to effect
-thermostating. Thus you must use a separate time integration fix, like
+thermostatting. Thus you must use a separate time integration fix, like
 "fix nve"_fix_nve.html or "fix nph"_fix_nh.html to actually update the
 velocities and positions of atoms using the modified forces.
 Likewise, this fix should not normally be used on atoms that also have
@@ -102,7 +102,7 @@ nvt"_fix_nh.html or "fix temp/rescale"_fix_temp_rescale.html commands.
 
 See the "Howto thermostat"_Howto_thermostat.html doc page for a
 discussion of different ways to compute temperature and perform
-thermostating.
+thermostatting.
 
 :line
 
@@ -126,7 +126,7 @@ comm_modify vel yes :pre
 :line
 
 {Tcom} is the target temperature of the centers of mass, which would
-be used to thermostate the non-polarizable atoms.  {Tdrude} is the
+be used to thermostat the non-polarizable atoms.  {Tdrude} is the
 (normally low) target temperature of the core-Drude particle pairs
 (dipoles).  {Tcom} and {Tdrude} can be specified as an equal-style
 "variable"_variable.html.  If the value is a variable, it should be
@@ -139,7 +139,7 @@ functions, and include "thermo_style"_thermo_style.html command
 keywords for the simulation box parameters and timestep and elapsed
 time.  Thus it is easy to specify a time-dependent temperature.
 
-Like other fixes that perform thermostating, this fix can be used with
+Like other fixes that perform thermostatting, this fix can be used with
 "compute commands"_compute.html that remove a "bias" from the atom
 velocities.  E.g. removing the center-of-mass velocity from a group of
 atoms.  This is not done by default, but only if the
@@ -147,11 +147,11 @@ atoms.  This is not done by default, but only if the
 compute to this fix that includes such a bias term.  See the doc pages
 for individual "compute commands"_compute.html to determine which ones
 include a bias.  In this case, the thermostat works in the following
-manner: bias is removed from each atom, thermostating is performed on
+manner: bias is removed from each atom, thermostatting is performed on
 the remaining thermal degrees of freedom, and the bias is added back
 in.  NOTE: this feature has not been tested.
 
-Note: The temperature thermostating the core-Drude particle pairs
+Note: The temperature thermostatting the core-Drude particle pairs
 should be chosen low enough, so as to mimic as closely as possible the
 self-consistent minimization. It must however be high enough, so that
 the dipoles can follow the local electric field exerted by the
@@ -213,7 +213,7 @@ the system, but is a bit slower. :l
 Use two different random seeds to avoid unphysical correlations. :l
 
 Temperature is controlled by the fix {langevin/drude}, so the
-time-integration fixes do not thermostate.  Don't forget to
+time-integration fixes do not thermostat.  Don't forget to
 time-integrate both cores and Drude particles. :l
 
 Pressure is time-integrated only once by using {nve} for Drude
@@ -223,11 +223,11 @@ for both. :l
 The temperatures of cores and Drude particles are calculated by
 "compute temp/drude"_compute_temp_drude.html :l
 
-Contrary to the alternative thermostating using Nose-Hoover thermostat
+Contrary to the alternative thermostatting using Nose-Hoover thermostat
 fix {npt} and "fix drude/transform"_fix_drude_transform.html, the
 {fix_modify} command is not required here, because the fix {nph}
 computes the global pressure even if its group is {ATOMS}. This is
-what we want. If we thermostated {ATOMS} using {npt}, the pressure
+what we want. If we thermostatted {ATOMS} using {npt}, the pressure
 should be the global one, but the temperature should be only that of
 the cores. That's why the command {fix_modify} should be called in
 that case. :l
@@ -247,7 +247,7 @@ restarted simulation should produce the same behavior.
 
 The "fix_modify"_fix_modify.html {temp} option is supported by this
 fix.  You can use it to assign a temperature "compute"_compute.html
-you have defined to this fix which will be used in its thermostating
+you have defined to this fix which will be used in its thermostatting
 procedure, as described above. For consistency, the group used by the
 compute should include the group of this fix and the Drude particles.
 

doc/src/fix_meso_move.txt

@@ -63,7 +63,7 @@ meso"_fix_meso.html command).  It is up to you to decide whether periodic
 boundaries are appropriate with the kind of particle motion you are
 prescribing with this fix.
 
-NOTE: As dicsussed below, particles are moved relative to their initial
+NOTE: As discussed below, particles are moved relative to their initial
 position at the time the fix is specified.  These initial coordinates
 are stored by the fix in "unwrapped" form, by using the image flags
 associated with each particle.  See the "dump custom"_dump.html command