Merge pull request #3607 from akohlmey/no-inn-sewer-ants

Getting out of the insurance business :-)

doc/src/2001/basics.html

@@ -63,7 +63,7 @@ In the src directory, there is one top-level Makefile and several
 low-level machine-specific files named Makefile.xxx where xxx = the
 machine name. If a low-level Makefile exists for your platform, you do
 not need to edit the top-level Makefile.  However you should check the
-system-specific section of the low-level Makefile to insure the
+system-specific section of the low-level Makefile to ensure the
 various paths are correct for your environment. If a low-level
 Makefile does not exist for your platform, you will need to add a
 suitable target to the top-level Makefile. You will also need to

doc/src/2001/input_commands.html

@@ -1206,7 +1206,7 @@ this command is not typically needed if the "nonbond style" and "
 an exception to this is if a short cutoff is used initially,
   but a longer cutoff will be used for a subsequent run (in the same
   input script), in this case the "maximum cutoff" command should be
-  used to insure enough memory is allocated for the later run
+  used to ensure enough memory is allocated for the later run
 note that a restart file contains nonbond cutoffs (so it is not necessary
   to use a "nonbond style" command before "read restart"), but LAMMPS
   still needs to know what the maximum cutoff will be before the

doc/src/Developer_grid.rst

@@ -533,7 +533,7 @@ processor's ghost cells extend further than nearest neighbor
 processors.
 
 This can be checked by callers who have the option to change the
-global grid size to insure more efficient nearest-neighbor-only
+global grid size to ensure more efficient nearest-neighbor-only
 communication if they wish.  In this case, they instantiate a grid of
 a given size (resolution), then invoke *setup_comm()* followed by
 *ghost_adjacent()*.  If the ghost cells are not adjacent, they destroy
@@ -753,7 +753,7 @@ their input script syntax, as described on the :doc:`Howto_grid
 * f_ID:gname:dname
 * f_ID:gname:dname[I]
 
-Each grid a command instantiates has a unique *gname*, defined by the
+Each grid command instantiates has a unique *gname*, defined by the
 command.  Likewise each grid cell data structure (scalar or vector)
 associated with a grid has a unique *dname*, also defined by the
 command.
@@ -784,8 +784,7 @@ The *get_grid_by_index()* method is called after the
 *get_grid_by_name()* method, using the grid index it returned as its
 argument.  This method will return a pointer to the Grid2d or Grid3d
 class.  The caller can use this to query grid attributes, such as the
-global size of the grid.  The :doc:`dump grid <dump>` to insure each
-its grid reference arguments are for grids of the same size.
+global size of the grid, to ensure it is of the expected size.
 
 The *get_griddata_by_name()* method takes a grid index *igrid* and a
 data name as input.  It returns two values.  The *ncol* argument is

doc/src/Errors_common.rst

@@ -113,7 +113,7 @@ LAMMPS output, something is wrong with your simulation.  If you
 suspect this is happening, it is a good idea to print out
 thermodynamic info frequently (e.g. every timestep) via the
 :doc:`thermo <thermo>` so you can monitor what is happening.
-Visualizing the atom movement is also a good idea to insure your model
+Visualizing the atom movement is also a good idea to ensure your model
 is behaving as you expect.
 
 In parallel, one way LAMMPS can hang is due to how different MPI

doc/src/Errors_messages.rst

@@ -6092,7 +6092,7 @@ keyword to allow for additional bonds to be formed
    after a read_data, read_restart, or create_box command.
 
 *Next command must list all universe and uloop variables*
-   This is to insure they stay in sync.
+   This is to ensure they stay in sync.
 
 *No Kspace style defined for compute group/group*
    Self-explanatory.
@@ -7231,7 +7231,7 @@ keyword to allow for additional bonds to be formed
 
 *Replacing a fix, but new style != old style*
    A fix ID can be used a second time, but only if the style matches the
-   previous fix.  In this case it is assumed you with to reset a fix's
+   previous fix.  In this case it is assumed you want to reset a fix's
    parameters.  This error may mean you are mistakenly re-using a fix ID
    when you do not intend to.
 
@@ -7337,7 +7337,7 @@ keyword to allow for additional bonds to be formed
 *Rigid body atoms %d %d missing on proc %d at step %ld*
    This means that an atom cannot find the atom that owns the rigid body
    it is part of, or vice versa.  The solution is to use the communicate
-   cutoff command to insure ghost atoms are acquired from far enough away
+   cutoff command to ensure ghost atoms are acquired from far enough away
    to encompass the max distance printed when the fix rigid/small command
    was invoked.
 

doc/src/Errors_warnings.rst

@@ -351,7 +351,7 @@ This will most likely cause errors in kinetic fluctuations.
    Self-explanatory.
 
 *Kspace_modify slab param < 2.0 may cause unphysical behavior*
-   The kspace_modify slab parameter should be larger to insure periodic
+   The kspace_modify slab parameter should be larger to ensure periodic
    grids padded with empty space do not overlap.
 
 *Less insertions than requested*
@@ -491,7 +491,7 @@ This will most likely cause errors in kinetic fluctuations.
 *Neighbor exclusions used with KSpace solver may give inconsistent Coulombic energies*
    This is because excluding specific pair interactions also excludes
    them from long-range interactions which may not be the desired effect.
-   The special_bonds command handles this consistently by insuring
+   The special_bonds command handles this consistently by ensuring
    excluded (or weighted) 1-2, 1-3, 1-4 interactions are treated
    consistently by both the short-range pair style and the long-range
    solver.  This is not done for exclusions of charged atom pairs via the
@@ -545,7 +545,7 @@ This will most likely cause errors in kinetic fluctuations.
    If there are other fixes that act immediately after the initial stage
    of time integration within a timestep (i.e. after atoms move), then
    the command that sets up the dynamic group should appear after those
-   fixes.  This will insure that dynamic group assignments are made
+   fixes.  This will ensure that dynamic group assignments are made
    after all atoms have moved.
 
 *One or more respa levels compute no forces*

doc/src/Howto_2d.rst

@@ -22,7 +22,7 @@ atom in the file, assign a z coordinate so it falls inside the
 z-boundaries of the box - e.g. 0.0.
 
 Use the :doc:`fix enforce2d <fix_enforce2d>` command as the last
-defined fix to insure that the z-components of velocities and forces
+defined fix to ensure that the z-components of velocities and forces
 are zeroed out every timestep.  The reason to make it the last fix is
 so that any forces induced by other fixes will be zeroed out.
 

doc/src/Howto_coreshell.rst

@@ -111,7 +111,7 @@ Therefore it is typically desirable to decouple the relative motion of
 the core/shell pair, which is an imaginary degree of freedom, from the
 real physical system.  To do that, the :doc:`compute temp/cs <compute_temp_cs>` command can be used, in conjunction with
 any of the thermostat fixes, such as :doc:`fix nvt <fix_nh>` or :doc:`fix langevin <fix_langevin>`.  This compute uses the center-of-mass velocity
-of the core/shell pairs to calculate a temperature, and insures that
+of the core/shell pairs to calculate a temperature, and ensures that
 velocity is what is rescaled for thermostatting purposes.  This
 compute also works for a system with both core/shell pairs and
 non-polarized ions (ions without an attached satellite particle).  The

doc/src/Howto_spherical.rst

@@ -93,7 +93,7 @@ Some of the pair styles used to compute pairwise interactions between
 finite-size particles also compute the correct interaction with point
 particles as well, e.g. the interaction between a point particle and a
 finite-size particle or between two point particles.  If necessary,
-:doc:`pair_style hybrid <pair_hybrid>` can be used to insure the correct
+:doc:`pair_style hybrid <pair_hybrid>` can be used to ensure the correct
 interactions are computed for the appropriate style of interactions.
 Likewise, using groups to partition particles (ellipsoids versus
 spheres versus point particles) will allow you to use the appropriate

doc/src/Python_launch.rst

@@ -70,7 +70,7 @@ single processor outputs, mpi4py is not working correctly.
 Also note that once you import the mpi4py module, mpi4py initializes MPI
 for you, and you can use MPI calls directly in your Python script, as
 described in the mpi4py documentation.  The last line of your Python
-script should be ``MPI.finalize()``, to insure MPI is shut down
+script should be ``MPI.finalize()``, to ensure MPI is shut down
 correctly.
 
 

doc/src/Run_options.rst

@@ -362,10 +362,10 @@ Reorder the processors in the MPI communicator used to instantiate
 LAMMPS, in one of several ways.  The original MPI communicator ranks
 all P processors from 0 to P-1.  The mapping of these ranks to
 physical processors is done by MPI before LAMMPS begins.  It may be
-useful in some cases to alter the rank order.  E.g. to insure that
+useful in some cases to alter the rank order.  E.g. to ensure that
 cores within each node are ranked in a desired order.  Or when using
 the :doc:`run_style verlet/split <run_style>` command with 2 partitions
-to insure that a specific Kspace processor (in the second partition) is
+to ensure that a specific Kspace processor (in the second partition) is
 matched up with a specific set of processors in the first partition.
 See the :doc:`General tips <Speed_tips>` page for more details.
 
@@ -398,7 +398,7 @@ so that the processors in each partition will be
    0 1 2 4 5 6 8 9 10
    3 7 11
 
-See the "processors" command for how to insure processors from each
+See the "processors" command for how to ensure processors from each
 partition could then be grouped optimally for quad-core nodes.
 
 If the keyword is *custom*, then a file that specifies a permutation

doc/src/Run_output.rst

@@ -122,7 +122,7 @@ potentially *dangerous* rebuilds.  If atom movement triggered neighbor
 list rebuilding (see the :doc:`neigh_modify <neigh_modify>` command),
 then dangerous reneighborings are those that were triggered on the
 first timestep atom movement was checked for.  If this count is
-non-zero you may wish to reduce the delay factor to insure no force
+non-zero you may wish to reduce the delay factor to ensure no force
 interactions are missed by atoms moving beyond the neighbor skin
 distance before a rebuild takes place.
 

doc/src/atom_style.rst

@@ -282,7 +282,7 @@ showing the use of the *template* atom style versus *molecular*.
 .. note::
 
    When using the *template* style with a :doc:`molecule template
-   <molecule>` that contains multiple molecules, you should insure the
+   <molecule>` that contains multiple molecules, you should ensure the
    atom types, bond types, angle_types, etc in all the molecules are
    consistent.  E.g. if one molecule represents H2O and another CO2,
    then you probably do not want each molecule file to define 2 atom

doc/src/comm_modify.rst

@@ -148,7 +148,7 @@ In the last scenario, a :doc:`fix <fix>` or :doc:`compute <compute>` or
 :doc:`pairwise potential <pair_style>` needs to calculate with ghost
 atoms beyond the normal pairwise cutoff for some computation it
 performs (e.g. locate neighbors of ghost atoms in a manybody pair
-potential).  Setting the ghost cutoff appropriately can insure it will
+potential).  Setting the ghost cutoff appropriately can ensure it will
 find the needed atoms.
 
 .. note::

doc/src/compute_adf.rst

@@ -75,7 +75,7 @@ neighbor atom in each requested ADF.
 
    If you request any outer cutoff *Router* > force cutoff, or if no
    pair style is defined,  e.g. the :doc:`rerun <rerun>` 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 ensure ghost atom information
    out to the largest value of *Router* + *skin* is communicated, via the
    :doc:`comm_modify cutoff <comm_modify>` command, else the ADF computation
    cannot be performed, and LAMMPS will give an error message.  The *skin* value

doc/src/compute_cna_atom.rst

@@ -43,7 +43,7 @@ compute group.  Note that normally a CNA calculation should only be
 performed on mono-component systems.
 
 The CNA calculation can be sensitive to the specified cutoff value.
-You should insure the appropriate nearest neighbors of an atom are
+You should ensure the appropriate nearest neighbors of an atom are
 found within the cutoff distance for the presumed crystal structure
 (e.g., 12 nearest neighbor for perfect FCC and HCP crystals, 14 nearest
 neighbors for perfect BCC crystals).  These formulas can be used to

doc/src/compute_modify.rst

@@ -58,7 +58,7 @@ are adding atoms or molecules to the system (see the :doc:`fix pour
 <fix_pour>`, :doc:`fix deposit <fix_deposit>`, and :doc:`fix gcmc
 <fix_gcmc>` commands) or expect atoms or molecules to be lost
 (e.g. due to exiting the simulation box or via :doc:`fix evaporate
-<fix_evaporate>`), then this option should be used to insure the
+<fix_evaporate>`), then this option should be used to ensure the
 temperature is correctly normalized.
 
 .. note::

doc/src/compute_msd_chunk.rst

@@ -74,7 +74,7 @@ compute command was first invoked.
    This compute stores the original position (of the
    center-of-mass) of each chunk.  When a displacement is calculated on a
    later timestep, it is assumed that the same atoms are assigned to the
-   same chunk ID.  However LAMMPS has no simple way to insure this is the
+   same chunk ID.  However LAMMPS has no simple way to ensure this is the
    case, though you can use the *ids once* option when specifying the
    :doc:`compute chunk/atom <compute_chunk_atom>` command.  Note that if
    this is not the case, the MSD calculation does not have a sensible

doc/src/compute_rdf.rst

@@ -82,7 +82,7 @@ distance specified.
    every timestep this command is invoked (or every reneighboring
    timestep, whichever is less frequent), which is inefficient.  LAMMPS
    will warn you if this is the case.  If you specify a *Rcut* > force
-   cutoff, you must insure ghost atom information out to *Rcut* + *skin*
+   cutoff, you must ensure ghost atom information out to *Rcut* + *skin*
    is communicated, via the :doc:`comm_modify cutoff <comm_modify>`
    command, else the RDF computation cannot be performed, and LAMMPS will
    give an error message.  The *skin* value is what is specified with the

doc/src/create_atoms.rst

@@ -108,7 +108,7 @@ atom types 1, 2, and 3, then each created molecule will have atom types
 
 For the *box* style, the create_atoms command fills the entire
 simulation box with particles on the lattice.  If your simulation box
-is periodic, you should insure its size is a multiple of the lattice
+is periodic, you should ensure its size is a multiple of the lattice
 spacings, to avoid unwanted atom overlaps at the box boundaries.  If
 your box is periodic and a multiple of the lattice spacing in a
 particular dimension, LAMMPS is careful to put exactly one particle at
@@ -121,7 +121,7 @@ and also consistent with the region volume.  See the :doc:`region
 that its "volume" is either inside or outside its geometric boundary.
 Also note that if a region is the same size as a periodic simulation
 box (in some dimension), LAMMPS does NOT implement the same logic
-described above for the *box* style, to insure exactly one particle at
+described above for the *box* style, to ensure exactly one particle at
 periodic boundaries.  If this is desired, you should either use the
 *box* style, or tweak the region size to get precisely the particles
 you want.
@@ -222,7 +222,7 @@ to the simulation.  For example, grain boundaries can be created, by
 interleaving the create_atoms command with :doc:`lattice <lattice>`
 commands specifying different orientations.
 
-When this command is used, care should be taken to insure the
+When this command is used, care should be taken to ensure the
 resulting system does not contain particles that are highly
 overlapped.  Such overlaps will cause many interatomic potentials to
 compute huge energies and forces, leading to bad dynamics.  There are
@@ -316,7 +316,7 @@ inserting particles, which may be limited by the *region* style or the
 fraction of them (:math:`0 \le f \le 1`) will be assigned particles.
 For the *subset* keyword only the specified *Nsubset* of them will be
 assigned particles.  In both cases the assigned lattice sites are
-chosen randomly.  An iterative algorithm is used that insures the
+chosen randomly.  An iterative algorithm is used that ensures the
 correct number of particles are inserted, in a perfectly random
 fashion.  Which lattice sites are selected will change with the number
 of processors used.

doc/src/create_bonds.rst

@@ -130,7 +130,7 @@ a distance that encompasses the *rmax* for new bonds to create.
 
    If you want to create bonds between pairs of 1--3 or 1--4 atoms in
    the current bond topology, then you need to use :doc:`special_bonds
-   lj 0 1 1 <special_bonds>` to insure those pairs appear in the
+   lj 0 1 1 <special_bonds>` to ensure those pairs appear in the
    neighbor list.  They will not appear with the default special_bonds
    settings, which are zero for 1--2, 1--3, and 1--4 atoms.  1--3 or 1--4
    atoms are those which are two hops or three hops apart in the bond

doc/src/dihedral_table.rst

@@ -193,7 +193,7 @@ are then used as described above, when computing energy and force for
 individual dihedral angles and their atoms.  This means that if you
 want the interpolation tables of length *Ntable* to match exactly what
 is in the tabulated file (with effectively nopreliminary
-interpolation), you should set *Ntable* = *Nfile*\ .  To insure the
+interpolation), you should set *Ntable* = *Nfile*\ .  To ensure the
 nodal points in the user's file are aligned with the interpolated
 table entries, the angles in the table should be integer multiples of
 360/\ *Ntable* degrees, or 2\*PI/\ *Ntable* radians (depending on your

doc/src/dump.rst

@@ -596,7 +596,7 @@ then one file per snapshot is written and the "\*" character is
 replaced with the timestep value.  For example, tmp.dump.\* becomes
 tmp.dump.0, tmp.dump.10000, tmp.dump.20000, etc.  This option is not
 available for the *dcd* and *xtc* styles.  Note that the
-:doc:`dump_modify pad <dump_modify>` command can be used to insure all
+:doc:`dump_modify pad <dump_modify>` command can be used to ensure all
 timestep numbers are the same length (e.g., 00010), which can make it
 easier to read a series of dump files in order with some
 post-processing tools.

doc/src/dump_image.rst

@@ -255,7 +255,7 @@ one image file per snapshot is written.  The "\*" character is replaced
 with the timestep value.  For example, tmp.dump.\*.jpg becomes
 tmp.dump.0.jpg, tmp.dump.10000.jpg, tmp.dump.20000.jpg, etc.  Note
 that the :doc:`dump_modify pad <dump_modify>` command can be used to
-insure all timestep numbers are the same length (e.g., 00010), which
+ensure all timestep numbers are the same length (e.g., 00010), which
 can make it easier to convert a series of images into a movie in the
 correct ordering.
 

doc/src/dump_modify.rst

@@ -410,7 +410,7 @@ command is invoked.
 ----------
 
 The *flush* keyword determines whether a flush operation is invoked
-after a dump snapshot is written to the dump file.  A flush insures
+after a dump snapshot is written to the dump file.  A flush ensures
 the output in that file is current (no buffering by the OS), even if
 LAMMPS halts before the simulation completes.  Flushes cannot be
 performed with dump style *xtc*\ .

doc/src/dump_vtk.rst

@@ -130,7 +130,7 @@ character appears in the filename, then one file per snapshot is
 written and the "\*" character is replaced with the timestep value.
 For example, tmp.dump\*.vtk becomes tmp.dump0.vtk, tmp.dump10000.vtk,
 tmp.dump20000.vtk, etc.  Note that the :doc:`dump_modify pad <dump_modify>`
-command can be used to insure all timestep numbers are the same length
+command can be used to ensure all timestep numbers are the same length
 (e.g. 00010), which can make it easier to read a series of dump files
 in order with some post-processing tools.
 
@@ -169,7 +169,7 @@ The *vtk* dump style is part of the VTK package. It is only
 enabled if LAMMPS was built with that package. See the :doc:`Build package <Build_package>` page for more info.
 
 To use this dump style, you also must link to the VTK library.  See
-the info in lib/vtk/README and insure the Makefile.lammps file in that
+the info in lib/vtk/README and ensure the Makefile.lammps file in that
 directory is appropriate for your machine.
 
 The *vtk* dump style supports neither buffering or custom format

doc/src/fix_addforce.rst

@@ -106,7 +106,7 @@ for :math:`f_x`, :math:`f_y`, :math:`f_z`, the energy variable is specified as
 v_name, where name is the variable name.
 
 Note that when the *energy* keyword is used during an energy
-minimization, you must insure that the formula defined for the
+minimization, you must ensure that the formula defined for the
 atom-style :doc:`variable <variable>` is consistent with the force
 variable formulas (i.e., that :math:`-\vec\nabla E = \vec F`).
 For example, if the force were a spring-like, :math:`\vec F = -k\vec x`, then

doc/src/fix_bond_swap.rst

@@ -100,7 +100,7 @@ be met:
 1. All 4 monomers must be in the fix group.
 
 2. All 4 monomers must be owned by the processor (not ghost atoms).
-   This insures that another processor does not attempt to swap bonds
+   This ensures that another processor does not attempt to swap bonds
    involving the same atoms on the same timestep.  Note that this also
    means that bond pairs which straddle processor boundaries are not
    eligible for swapping on this step.

doc/src/fix_deposit.rst

@@ -96,7 +96,7 @@ default group "all" and the group specified in the fix deposit command
 
 If you are computing temperature values which include inserted
 particles, you will want to use the
-:doc:`compute_modify <compute_modify>` dynamic option, which insures the
+:doc:`compute_modify <compute_modify>` dynamic option, which ensures the
 current number of atoms is used as a normalizing factor each time the
 temperature is computed.
 
@@ -128,7 +128,7 @@ side = *in*\ .
    tests against the larger orthonormal box that bounds the tilted
    simulation box.  If the specified region includes volume outside the
    tilted box, then an insertion will likely fail, leading to a "lost
-   atoms" error.  Thus for triclinic boxes you should insure the
+   atoms" error.  Thus for triclinic boxes you should ensure the
    specified region is wholly inside the simulation box.
 
 The locations of inserted particles are taken from uniform distributed

doc/src/fix_efield.rst

@@ -105,7 +105,7 @@ atom as function of its position.  Like variables used for *ex*,
 is the variable name.
 
 Note that when the *energy* keyword is used during an energy
-minimization, you must insure that the formula defined for the
+minimization, you must ensure that the formula defined for the
 atom-style :doc:`variable <variable>` is consistent with the force
 variable formulas, i.e. that -Grad(E) = F.  For example, if the force
 due to the electric field were a spring-like F = kx, then the energy

doc/src/fix_enforce2d.rst

@@ -27,7 +27,7 @@ Description
 """""""""""
 
 Zero out the z-dimension velocity and force on each atom in the group.
-This is useful when running a 2d simulation to insure that atoms do
+This is useful when running a 2d simulation to ensure that atoms do
 not move from their initial z coordinate.
 
 ----------

doc/src/fix_evaporate.rst

@@ -42,7 +42,7 @@ chosen at random and deleted.  If there are less than M eligible
 particles, then all of them are deleted.
 
 If the setting for the *molecule* keyword is *no*, then only single
-atoms are deleted.  In this case, you should insure you do not delete
+atoms are deleted.  In this case, you should ensure you do not delete
 only a portion of a molecule (only some of its atoms), or LAMMPS will
 soon generate an error when it tries to find those atoms.  LAMMPS will
 warn you if any of the atoms eligible for deletion have a non-zero

doc/src/fix_external.rst

@@ -127,7 +127,7 @@ stress tensor components.  Eng is an extensive quantity,
 meaning it should be the sum over per-atom energies of all affected
 atoms.  It should also be provided in :doc:`energy units <units>`
 consistent with the simulation.  See the details below for how to
-insure this energy setting is used appropriately in a minimization.
+ensure this energy setting is used appropriately in a minimization.
 
 Additional public methods that the caller can use to update system
 properties are:

doc/src/fix_gcmc.rst

@@ -353,7 +353,7 @@ about simulating non-neutral systems with kspace on.
 
 Use of this fix typically will cause the number of atoms to fluctuate,
 therefore, you will want to use the
-:doc:`compute_modify dynamic/dof <compute_modify>` command to insure that the
+:doc:`compute_modify dynamic/dof <compute_modify>` command to ensure that the
 current number of atoms is used as a normalizing factor each time
 temperature is computed. A simple example of this is:
 

doc/src/fix_gravity.rst

@@ -83,7 +83,7 @@ specified as an equal-style :doc:`variable <variable>`.  If the value is
 a variable, it should be specified as v_name, where name is the
 variable name.  In this case, the variable will be evaluated each
 timestep, and its value used to determine the quantity.  You should
-insure that the variable calculates a result in the appropriate units,
+ensure that the variable calculates a result in the appropriate units,
 e.g. force/mass or degrees.
 
 Equal-style variables can specify formulas with various mathematical

doc/src/fix_hyper_local.rst

@@ -240,7 +240,7 @@ well for many solid-state systems.
 
 .. note::
 
-   You should insure that ghost atom communication is performed for
+   You should ensure that ghost atom communication is performed for
    a distance of at least *Dcut* + *cutevent* = the distance one or more
    atoms move (between quenched states) to be considered an "event".  It
    is an argument to the "compute event/displace" command used to detect

doc/src/fix_langevin.rst

@@ -194,7 +194,7 @@ For the *omega* keyword there is also a scale factor of
 :math:`F_f` (damping) term in the equation above and of
 :math:`\sqrt{\frac{10.0}{3.0}}` as a multiplier on the :math:`F_r` term.
 This does not affect the thermostatting behavior of the Langevin
-formalism but insures that the randomized rotational diffusivity of
+formalism but ensures that the randomized rotational diffusivity of
 spherical particles is correct.
 
 For the *angmom* keyword a similar scale factor is needed which is

doc/src/fix_mdi_qm.rst

@@ -130,7 +130,7 @@ typically specified via the create_box command or in the data file
 read by the read_data command.
 
 If this keyword is specified, then this fix will send the MDI
-">ELEMENTS" command to the engine, to insure the two codes are
+">ELEMENTS" command to the engine, to ensure the two codes are
 consistent in their definition of atomic species.  If this keyword is
 not specified, then this fix will send the MDI >TYPES command to the
 engine.  This is fine if both the LAMMPS driver and the MDI engine are

doc/src/fix_modify.rst

@@ -140,14 +140,14 @@ molecules to the system (see the :doc:`fix pour <fix_pour>`, :doc:`fix
 deposit <fix_deposit>`, and :doc:`fix gcmc <fix_gcmc>` commands) or
 expect atoms or molecules to be lost (e.g. due to exiting the
 simulation box or via :doc:`fix evaporate <fix_evaporate>`), then this
-option should be used to insure the temperature is correctly
+option should be used to ensure the temperature is correctly
 normalized.
 
 .. note::
 
    Other thermostatting fixes, such as :doc:`fix nvt <fix_nh>`, do
    not use the *dynamic/dof* keyword because they use a temperature
-   compute to calculate temperature.  See the :doc:`compute_modify dynamic/dof <compute_modify>` command for a similar way to insure
+   compute to calculate temperature.  See the :doc:`compute_modify dynamic/dof <compute_modify>` command for a similar way to ensure
    correct temperature normalization for those thermostats.
 
 The *bodyforces* keyword determines whether the forces and torques

doc/src/fix_momentum.rst

@@ -69,7 +69,7 @@ the corresponding flag to 0.
 If the *angular* keyword is used, the angular momentum is zeroed by
 subtracting a rotational component from each atom.
 
-This command can be used to insure the entire collection of atoms (or
+This command can be used to ensure the entire collection of atoms (or
 a subset of them) does not drift or rotate during the simulation due
 to random perturbations (e.g. :doc:`fix langevin <fix_langevin>`
 thermostatting).

doc/src/fix_print.rst

@@ -41,7 +41,7 @@ be used for diagnostic purposes or as a debugging tool to monitor some
 quantity during a run.  The text string must be a single argument, so
 it should be enclosed in single or double quotes if it is more than
 one word.  If it contains variables it must be enclosed in double
-quotes to insure they are not evaluated when the input script line is
+quotes to ensure they are not evaluated when the input script line is
 read, but will instead be evaluated each time the string is printed.
 
 .. note::

doc/src/fix_property_atom.rst

@@ -112,7 +112,7 @@ The new atom properties encode values that migrate with atoms to new
 processors and are written to restart files.  If you want the new
 properties to also be defined for ghost atoms, then use the *ghost*
 keyword with a value of *yes*\ .  This will invoke extra communication
-when ghost atoms are created (at every re-neighboring) to insure the
+when ghost atoms are created (at every re-neighboring) to ensure the
 new properties are also defined for the ghost atoms.
 
 .. admonition:: Properties on ghost atoms

doc/src/fix_recenter.rst

@@ -38,7 +38,7 @@ Constrain the center-of-mass position of a group of atoms by adjusting
 the coordinates of the atoms every timestep.  This is simply a small
 shift that does not alter the dynamics of the system or change the
 relative coordinates of any pair of atoms in the group.  This can be
-used to insure the entire collection of atoms (or a portion of them)
+used to ensure the entire collection of atoms (or a portion of them)
 do not drift during the simulation due to random perturbations
 (e.g. :doc:`fix langevin <fix_langevin>` thermostatting).
 

doc/src/fix_rigid.rst

@@ -316,7 +316,7 @@ to be part of rigid bodies.
 
    To compute the initial center-of-mass position and other
    properties of each rigid body, the image flags for each atom in the
-   body are used to "unwrap" the atom coordinates.  Thus you must insure
+   body are used to "unwrap" the atom coordinates.  Thus you must ensure
    that these image flags are consistent so that the unwrapping creates a
    valid rigid body (one where the atoms are close together),
    particularly if the atoms in a single rigid body straddle a periodic
@@ -337,7 +337,7 @@ This may be useful if you wish a body to rotate but not translate, or
 vice versa, or if you wish it to rotate or translate continuously
 unaffected by interactions with other particles.  Note that if you
 expect a rigid body not to move or rotate by using these keywords, you
-must insure its initial center-of-mass translational or angular
+must ensure its initial center-of-mass translational or angular
 velocity is 0.0.  Otherwise the initial translational or angular
 momentum the body has will persist.
 
@@ -702,9 +702,10 @@ also accounted for by this fix.
 
 ----------
 
-If your simulation is a hybrid model with a mixture of rigid bodies
-and non-rigid particles (e.g. solvent) there are several ways these
-rigid fixes can be used in tandem with :doc:`fix nve <fix_nve>`, :doc:`fix nvt <fix_nh>`, :doc:`fix npt <fix_nh>`, and :doc:`fix nph <fix_nh>`.
+If your simulation is a hybrid model with a mixture of rigid bodies and
+non-rigid particles (e.g. solvent) there are several ways these rigid
+fixes can be used in tandem with :doc:`fix nve <fix_nve>`, :doc:`fix nvt
+<fix_nh>`, :doc:`fix npt <fix_nh>`, and :doc:`fix nph <fix_nh>`.
 
 If you wish to perform NVE dynamics (no thermostatting or
 barostatting), use one of 4 NVE rigid styles to integrate the rigid
@@ -713,13 +714,17 @@ particles.
 
 If you wish to perform NVT dynamics (thermostatting, but no
 barostatting), you can use one of the 2 NVT rigid styles for the rigid
-bodies, and any thermostatting fix for the non-rigid particles (:doc:`fix nvt <fix_nh>`, :doc:`fix langevin <fix_langevin>`, :doc:`fix temp/berendsen <fix_temp_berendsen>`).  You can also use one of the
-4 NVE rigid styles for the rigid bodies and thermostat them using :doc:`fix langevin <fix_langevin>` on the group that contains all the
-particles in the rigid bodies.  The net force added by :doc:`fix langevin <fix_langevin>` to each rigid body effectively thermostats
-its translational center-of-mass motion.  Not sure how well it does at
+bodies, and any thermostatting fix for the non-rigid particles
+(:doc:`fix nvt <fix_nh>`, :doc:`fix langevin <fix_langevin>`, :doc:`fix
+temp/berendsen <fix_temp_berendsen>`).  You can also use one of the 4
+NVE rigid styles for the rigid bodies and thermostat them using
+:doc:`fix langevin <fix_langevin>` on the group that contains all the
+particles in the rigid bodies.  The net force added by :doc:`fix
+langevin <fix_langevin>` to each rigid body effectively thermostats its
+translational center-of-mass motion.  Not sure how well it does at
 thermostatting its rotational motion.
 
-If you with to perform NPT or NPH dynamics (barostatting), you cannot
+If you wish to perform NPT or NPH dynamics (barostatting), you cannot
 use both :doc:`fix npt <fix_nh>` and the NPT or NPH rigid styles.  This
 is because there can only be one fix which monitors the global
 pressure and changes the simulation box dimensions.  So you have 3
@@ -727,27 +732,28 @@ choices:
 
 * Use one of the 4 NPT or NPH styles for the rigid bodies.  Use the
   *dilate* all option so that it will dilate the positions of the
-  non-rigid particles as well.  Use :doc:`fix nvt <fix_nh>` (or any other
-  thermostat) for the non-rigid particles.
+  *non-rigid particles as well.  Use :doc:`fix nvt <fix_nh>` (or any
+  *other thermostat) for the non-rigid particles.
 * Use :doc:`fix npt <fix_nh>` for the group of non-rigid particles.  Use
   the *dilate* all option so that it will dilate the center-of-mass
   positions of the rigid bodies as well.  Use one of the 4 NVE or 2 NVT
   rigid styles for the rigid bodies.
 * Use :doc:`fix press/berendsen <fix_press_berendsen>` to compute the
   pressure and change the box dimensions.  Use one of the 4 NVE or 2 NVT
-  rigid styles for the rigid bodies.  Use :doc:`fix nvt <fix_nh>` (or any
-  other thermostat) for the non-rigid particles.
+  rigid styles for the rigid bodies.  Use :doc:`fix nvt <fix_nh>` (or
+  any other thermostat) for the non-rigid particles.
 
 In all case, the rigid bodies and non-rigid particles both contribute
 to the global pressure and the box is scaled the same by any of the
 barostatting fixes.
 
-You could even use the second and third options for a non-hybrid simulation
-consisting of only rigid bodies, assuming you give :doc:`fix npt <fix_nh>` an empty group, though it's an odd thing to do.  The
-barostatting fixes (:doc:`fix npt <fix_nh>` and :doc:`fix press/berensen <fix_press_berendsen>`) will monitor the pressure
-and change the box dimensions, but not time integrate any particles.
-The integration of the rigid bodies will be performed by fix
-rigid/nvt.
+You could even use the second and third options for a non-hybrid
+simulation consisting of only rigid bodies, assuming you give :doc:`fix
+npt <fix_nh>` an empty group, though it's an odd thing to do.  The
+barostatting fixes (:doc:`fix npt <fix_nh>` and :doc:`fix press/berensen
+<fix_press_berendsen>`) will monitor the pressure and change the box
+dimensions, but not time integrate any particles.  The integration of
+the rigid bodies will be performed by fix rigid/nvt.
 
 ----------
 
@@ -868,7 +874,7 @@ possible to compute the target temperature correctly.  Second, the
 assigned velocities may be partially canceled when constraints are
 first enforced, leading to a different temperature than desired.  A
 workaround for this is to perform a :doc:`run 0 <run>` command, which
-insures all DOFs are accounted for properly, and then rescale the
+ensures all DOFs are accounted for properly, and then rescale the
 temperature to the desired value before performing a simulation.  For
 example:
 

doc/src/fix_rigid_meso.rst

@@ -156,7 +156,7 @@ included in each rigid body.
    To compute the initial center-of-mass position and other
    properties of each rigid body, the image flags for each particle in the
    body are used to "unwrap" the particle coordinates.  Thus you must
-   insure that these image flags are consistent so that the unwrapping
+   ensure that these image flags are consistent so that the unwrapping
    creates a valid rigid body (one where the particles are close together)
    , particularly if the particles in a single rigid body straddle a
    periodic boundary.  This means the input data file or restart file must
@@ -173,7 +173,7 @@ This may be useful if you wish a body to rotate but not translate, or
 vice versa, or if you wish it to rotate or translate continuously
 unaffected by interactions with other particles.  Note that if you
 expect a rigid body not to move or rotate by using these keywords, you
-must insure its initial center-of-mass translational or angular
+must ensure its initial center-of-mass translational or angular
 velocity is 0.0. Otherwise the initial translational or angular
 momentum, the body has, will persist.
 

doc/src/fix_srd.rst

@@ -335,7 +335,7 @@ should be used to turn off big/SRD interactions, e.g. by setting their
 epsilon or cutoff length to 0.0.
 
 The "delete_atoms overlap" command may be useful in setting up an SRD
-simulation to insure there are no initial overlaps between big and SRD
+simulation to ensure there are no initial overlaps between big and SRD
 particles.
 
 ----------

doc/src/fix_wall.rst

@@ -237,7 +237,7 @@ time.  Thus it is easy to specify a time-dependent wall interaction.
 
 .. note::
 
-   For all of the styles, you must insure that r is always > 0 for
+   For all of the styles, you must ensure that r is always > 0 for
    all particles in the group, or LAMMPS will generate an error.  This
    means you cannot start your simulation with particles at the wall
    position *coord* (r = 0) or with particles on the wrong side of the
@@ -277,7 +277,7 @@ boundaries.  The default for *pbc* is *no*, which means the system
 must be non-periodic when using a wall.  But you may wish to use a
 periodic box.  E.g. to allow some particles to interact with the wall
 via the fix group-ID, and others to pass through it and wrap around a
-periodic box.  In this case you should insure that the wall if
+periodic box.  In this case you should ensure that the wall if
 sufficiently far enough away from the box boundary.  If you do not,
 then particles may interact with both the wall and with periodic
 images on the other side of the box, which is probably not what you

doc/src/fix_wall_ees.rst

@@ -104,7 +104,7 @@ respectively, in units of 1/volume.
 
 .. note::
 
-   You must insure that r is always bigger than :math:`\sigma_n` for
+   You must ensure that r is always bigger than :math:`\sigma_n` for
    all particles in the group, or LAMMPS will generate an error.  This
    means you cannot start your simulation with particles touching the wall
    position *coord* (:math:`r = \sigma_n`) or with particles penetrating

doc/src/fix_wall_region.rst

@@ -77,7 +77,7 @@ region surface will move over time in the corresponding manner.
 
    As discussed on the :doc:`region <region>` command doc page,
    regions in LAMMPS do not get wrapped across periodic boundaries.  It
-   is up to you to insure that periodic or non-periodic boundaries are
+   is up to you to ensure that periodic or non-periodic boundaries are
    specified appropriately via the :doc:`boundary <boundary>` command when
    using a region as a wall that bounds particle motion.  This also means
    that if you embed a region in your simulation box and want it to

doc/src/fix_wall_srd.rst

@@ -96,7 +96,7 @@ specify a time-dependent wall position.
 .. note::
 
    Because the trajectory of the SRD particle is tracked as it
-   collides with the wall, you must insure that r = distance of the
+   collides with the wall, you must ensure that r = distance of the
    particle from the wall, is always > 0 for SRD particles, or LAMMPS
    will generate an error.  This means you cannot start your simulation
    with SRD particles at the wall position *coord* (r = 0) or with
@@ -117,7 +117,7 @@ specify a time-dependent wall position.
    a mixture containing other kinds of particles, then you should
    typically use :doc:`another wall command <fix_wall>` to act on the other
    particles.  Since SRD particles will be colliding both with the walls
-   and the other particles, it is important to insure that the other
+   and the other particles, it is important to ensure that the other
    particle's finite extent does not overlap an SRD wall.  If you do not
    do this, you may generate errors when SRD particles end up "inside"
    another particle or a wall at the beginning of a collision step.

doc/src/group.rst

@@ -173,15 +173,15 @@ Note that these lines
    thermo_style    custom step temp pe c_2
    run             0
 
-are necessary to insure that the "eatom" variable is current when the
+are necessary to ensure that the "eatom" variable is current when the
 group command invokes it.  Because the eatom variable computes the
 per-atom energy via the pe/atom compute, it will only be current if a
 run has been performed which evaluated pairwise energies, and the
 pe/atom compute was actually invoked during the run.  Printing the
-thermodynamic info for compute 2 insures that this is the case, since
+thermodynamic info for compute 2 ensures that this is the case, since
 it sums the pe/atom compute values (in the reduce compute) to output
 them to the screen.  See the "Variable Accuracy" section of the
-:doc:`variable <variable>` page for more details on insuring that
+:doc:`variable <variable>` page for more details on ensuring that
 variables are current when they are evaluated between runs.
 
 The *include* style with its arg *molecule* adds atoms to a group that

doc/src/if.rst

@@ -97,7 +97,7 @@ system temperature has reached a certain value, and if so, breaks out
 of the loop to finish the run.  Note that any variable could be
 checked, so long as it is current on the timestep when the run
 completes.  As explained on the :doc:`variable <variable>` doc page,
-this can be insured by including the variable in thermodynamic output.
+this can be ensured by including the variable in thermodynamic output.
 
 .. code-block:: LAMMPS
 

doc/src/jump.rst

@@ -99,7 +99,7 @@ system temperature has reached a certain value, and if so, breaks out
 of the loop to finish the run.  Note that any variable could be
 checked, so long as it is current on the timestep when the run
 completes.  As explained on the :doc:`variable <variable>` doc page,
-this can be insured by including the variable in thermodynamic output.
+this can be ensured by including the variable in thermodynamic output.
 
 .. code-block:: LAMMPS
 

doc/src/molecule.rst

@@ -118,7 +118,7 @@ molecule (header keyword = inertia).
    so you do not overflow those pre-allocated data structures when adding
    molecules later.  Both the :doc:`create_box <create_box>` command and
    the :doc:`read_data <read_data>` command have "extra" options which
-   insure space is allocated for storing topology info for molecules that
+   ensure space is allocated for storing topology info for molecules that
    are added later.
 
 The format of an individual molecule file is similar but

doc/src/neigh_modify.rst

@@ -127,7 +127,7 @@ The *cluster* option does a sanity test every time neighbor lists are
 built for bond, angle, dihedral, and improper interactions, to check
 that each set of 2, 3, or 4 atoms is a cluster of nearby atoms.  It
 does this by computing the distance between pairs of atoms in the
-interaction and insuring they are not further apart than half the
+interaction and ensuring they are not further apart than half the
 periodic box length.  If they are, an error is generated, since the
 interaction would be computed between far-away atoms instead of their
 nearby periodic images.  The only way this should happen is if the
@@ -264,7 +264,7 @@ The *molecule/intra* and *molecule/inter* exclusion options can only
 be used with atom styles that define molecule IDs.
 
 The value of the *page* setting must be at least 10x larger than the
-*one* setting.  This insures neighbor pages are not mostly empty
+*one* setting.  This ensures neighbor pages are not mostly empty
 space.
 
 Related commands

doc/src/package.rst

@@ -629,7 +629,7 @@ too.
    packages, be aware these packages all allow setting of the *Nthreads*
    value via their package commands, but there is only a single global
    *Nthreads* value used by OpenMP.  Thus if multiple package commands are
-   invoked, you should insure the values are consistent.  If they are
+   invoked, you should ensure the values are consistent.  If they are
    not, the last one invoked will take precedence, for all packages.
    Also note that if the :doc:`-sf hybrid intel omp command-line switch <Run_options>` is used, it invokes a "package intel" command, followed by a
    "package omp" command, both with a setting of *Nthreads* = 0. Likewise

doc/src/pair_colloid.rst

@@ -136,7 +136,7 @@ larger, then the pair interacts via the colloid-solvent formula.
 
 Note that the diameter of a particular particle type may appear in
 multiple pair_coeff commands, as it interacts with other particle
-types.  You should insure the particle diameter is specified
+types.  You should ensure the particle diameter is specified
 consistently each time it appears.
 
 The last coefficient is optional.  If not specified, the global cutoff
@@ -201,7 +201,7 @@ Normally, this pair style should be used with finite-size particles
 which have a diameter, e.g. see the :doc:`atom_style sphere <atom_style>` command.  However, this is not a requirement,
 since the only definition of particle size is via the pair_coeff
 parameters for each type.  In other words, the physical radius of the
-particle is ignored.  Thus you should insure that the d1,d2 parameters
+particle is ignored.  Thus you should ensure that the d1,d2 parameters
 you specify are consistent with the physical size of the particles of
 that type.
 

doc/src/pair_dipole.rst

@@ -308,7 +308,7 @@ one of these options:
 * :doc:`fix nvt/sphere update dipole <fix_nvt_sphere>`
 * :doc:`fix npt/sphere update dipole <fix_npt_sphere>`
 
-In all cases the "update dipole" setting insures the dipole moments
+In all cases the "update dipole" setting ensures the dipole moments
 are also rotated when the finite-size spheres rotate.  The 2nd and 3rd
 bullets perform thermostatting; in the case of a Langevin thermostat
 the "omega yes" option also thermostats the rotational degrees of

doc/src/pair_gayberne.rst

@@ -118,7 +118,7 @@ atom type J.  If all three epsilon_j values are zero, they are ignored.
 Thus the typical way to define the :math:`\epsilon_i` and
 :math:`\epsilon_j` coefficients is to list their values in "pair_coeff
 I J" commands when I = J, but set them to 0.0 when I != J.  If you do
-list them when I != J, you should insure they are consistent with their
+list them when I != J, you should ensure they are consistent with their
 values in other pair_coeff commands, since only the last setting will
 be in effect.
 
@@ -126,7 +126,7 @@ Note that if this potential is being used as a sub-style of
 :doc:`pair_style hybrid <pair_hybrid>`, and there is no "pair_coeff I I"
 setting made for Gay-Berne for a particular type I (because I-I
 interactions are computed by another hybrid pair potential), then you
-still need to insure the :math:`\epsilon` a,b,c coefficients are assigned to
+still need to ensure the :math:`\epsilon` a,b,c coefficients are assigned to
 that type. e.g. in a "pair_coeff I J" command.
 
 .. note::

doc/src/pair_hybrid.rst

@@ -468,7 +468,7 @@ Restrictions
 When using a long-range Coulombic solver (via the
 :doc:`kspace_style <kspace_style>` command) with a hybrid pair_style,
 one or more sub-styles will be of the "long" variety,
-e.g. *lj/cut/coul/long* or *buck/coul/long*\ .  You must insure that the
+e.g. *lj/cut/coul/long* or *buck/coul/long*\ .  You must ensure that the
 short-range Coulombic cutoff used by each of these long pair styles is
 the same or else LAMMPS will generate an error.
 

doc/src/pair_meam.rst

@@ -123,7 +123,7 @@ that will be used with other potentials.
    filenames can appear in any order, e.g. "Si C" or "C Si" in the
    example above.  However, if the second filename is **not** NULL (as in the
    example above), it contains settings that are indexed **by numbers**
-   for the elements that precede it.  Thus you need to insure that you list
+   for the elements that precede it.  Thus you need to ensure that you list
    the elements between the filenames in an order consistent with how the
    values in the second filename are indexed.  See details below on the
    syntax for settings in the second file.

doc/src/pair_resquared.rst

@@ -129,14 +129,14 @@ atom type J.  If all three :math:`\epsilon_i` values are zero, they are
 ignored.  Thus the typical way to define the :math:`\epsilon_i` and
 :math:`\epsilon_j` coefficients is to list their values in "pair_coeff
 I J" commands when I = J, but set them to 0.0 when I != J.  If you do
-list them when I != J, you should insure they are consistent with their
+list them when I != J, you should ensure they are consistent with their
 values in other pair_coeff commands.
 
 Note that if this potential is being used as a sub-style of
 :doc:`pair_style hybrid <pair_hybrid>`, and there is no "pair_coeff I I"
 setting made for RE-squared for a particular type I (because I-I
 interactions are computed by another hybrid pair potential), then you
-still need to insure the epsilon a,b,c coefficients are assigned to
+still need to ensure the epsilon a,b,c coefficients are assigned to
 that type in a "pair_coeff I J" command.
 
 For large uniform molecules it has been shown that the :math:`\epsilon_{*,*}`

doc/src/pair_table.rst

@@ -92,9 +92,9 @@ short-range part of one of the long-range solvers specified by the
 :doc:`kspace_style <kspace_style>` command, then you must use one or
 more of the optional keywords listed above for the pair_style command.
 These are *ewald* or *pppm* or *msm* or *dispersion* or *tip4p*\ .  This
-is so LAMMPS can insure the short-range potential and long-range
+is so LAMMPS can ensure the short-range potential and long-range
 solver are compatible with each other, as it does for other
-short-range pair styles, such as :doc:`pair_style lj/cut/coul/long <pair_lj_cut_coul>`.  Note that it is up to you to insure
+short-range pair styles, such as :doc:`pair_style lj/cut/coul/long <pair_lj_cut_coul>`.  Note that it is up to you to ensure
 the tabulated values for each pair of atom types has the correct
 functional form to be compatible with the matching long-range solver.
 

doc/src/pair_zero.rst

@@ -38,7 +38,7 @@ pairwise forces are not otherwise needed.  Examples are the :doc:`fix bond/creat
 :doc:`compute voronoi/atom <compute_voronoi_atom>` commands.
 
 Note that the :doc:`comm_modify cutoff <comm_modify>` command can be
-used to insure communication of ghost atoms even when a pair style is
+used to ensure communication of ghost atoms even when a pair style is
 not defined, but it will not trigger neighbor list generation.
 
 The optional *nocoeff* flag allows to read data files with a PairCoeff

doc/src/processors.rst

@@ -133,7 +133,7 @@ each processor's subdomain, as described above.  The mapping of
 processors to the grid is determined by the *map* keyword setting.
 
 The *twolevel* style can be used on machines with multicore nodes to
-minimize off-node communication.  It insures that contiguous
+minimize off-node communication.  It ensures that contiguous
 subsections of the 3d grid are assigned to all the cores of a node.
 For example if *Nc* is 4, then 2x2x1 or 2x1x2 or 1x2x2 subsections of
 the 3d grid will correspond to the cores of each node.  This affects
@@ -289,7 +289,7 @@ processors, it could create a 4x2x10 grid, but it will not create a
 
    If you use the :doc:`partition <partition>` command to invoke
    different "processors" commands on different partitions, and you also
-   use the *part* keyword, then you must insure that both the sending and
+   use the *part* keyword, then you must ensure that both the sending and
    receiving partitions invoke the "processors" command that connects the
    2 partitions via the *part* keyword.  LAMMPS cannot easily check for
    this, but your simulation will likely hang in its setup phase if this
@@ -306,7 +306,7 @@ machine or when the processor ranks were reordered by use of the
 :doc:`-reorder command-line switch <Run_options>` or due to use of
 MPI-specific launch options such as a config file.
 
-If you have multiple partitions you should insure that each one writes
+If you have multiple partitions you should ensure that each one writes
 to a different file, e.g. using a :doc:`world-style variable <variable>`
 for the filename.  The file has a self-explanatory header, followed by
 one-line per processor in this format:

doc/src/python.rst

@@ -359,7 +359,7 @@ library.
 Third, if your Python code calls back to LAMMPS (discussed in the
 next section) and causes LAMMPS to perform an MPI operation requires
 global communication (e.g. via MPI_Allreduce), such as computing the
-global temperature of the system, then you must insure all your Python
+global temperature of the system, then you must ensure all your Python
 functions (running independently on different processors) call back to
 LAMMPS.  Otherwise the code may hang.
 

doc/src/read_data.rst

@@ -149,9 +149,9 @@ is required representing the equivalent offset for molecule IDs.
 If *merge* is specified, the data file atoms
 are added to the current system without changing their IDs.  They are
 assumed to merge (without duplication) with the currently defined
-atoms.  It is up to you to insure there are no multiply defined atom
+atoms.  It is up to you to ensure there are no multiply defined atom
 IDs, as LAMMPS only performs an incomplete check that this is the case
-by insuring the resulting max atom-ID >= the number of atoms. For
+by ensuring the resulting max atom-ID >= the number of atoms. For
 molecule IDs, there is no check done at all.
 
 The *offset* and *shift* keywords can only be used if the *add*
@@ -180,7 +180,7 @@ The *shift* keyword can be used to specify an (Sx, Sy, Sz)
 displacement applied to the coordinates of each atom.  Sz must be 0.0
 for a 2d simulation.  This is a mechanism for adding structured
 collections of atoms at different locations within the simulation box,
-to build up a complex geometry.  It is up to you to insure atoms do
+to build up a complex geometry.  It is up to you to ensure atoms do
 not end up overlapping unphysically which would lead to bad dynamics.
 Note that the :doc:`displace_atoms <displace_atoms>` command can be used
 to move a subset of atoms after they have been read from a data file.

doc/src/read_dump.rst

@@ -233,7 +233,7 @@ labels for fields *id* and *type*\ .
 For dump files in *xyz* format, only the *x*, *y*, and *z* fields are
 supported.  The dump file does not store atom IDs, so these are
 assigned consecutively to the atoms as they appear in the dump file,
-starting from 1.  Thus you should insure that order of atoms is
+starting from 1.  Thus you should ensure that order of atoms is
 consistent from snapshot to snapshot in the XYZ dump file.  See
 the :doc:`dump_modify sort <dump_modify>` command if the XYZ dump file
 was written by LAMMPS.
@@ -243,7 +243,7 @@ For dump files in *molfile* format, the *x*, *y*, *z*, *vx*, *vy*, and
 velocities, or their respective plugins may not support reading of
 velocities.  The molfile dump files do not store atom IDs, so these
 are assigned consecutively to the atoms as they appear in the dump
-file, starting from 1.  Thus you should insure that order of atoms are
+file, starting from 1.  Thus you should ensure that order of atoms are
 consistent from snapshot to snapshot in the molfile dump file.
 See the :doc:`dump_modify sort <dump_modify>` command if the dump file
 was written by LAMMPS.

doc/src/rerun.rst

@@ -188,7 +188,7 @@ involve pair interactions, such as use compute msd to calculated
 displacements over time, you do not need to define a :doc:`pair style
 <pair_style>`, which may also mean neighbor lists will not need to be
 calculated which saves time.  The :doc:`comm_modify cutoff
-<comm_modify>` command can also be used to insure ghost atoms are
+<comm_modify>` command can also be used to ensure ghost atoms are
 acquired from far enough away for operations like bond and angle
 evaluations, if no pair style is being used.
 
@@ -203,7 +203,7 @@ If time-averaging fixes like :doc:`fix ave/time <fix_ave_time>` are
 used, they are invoked on timesteps that are a function of their
 *Nevery*, *Nrepeat*, and *Nfreq* settings.  As an example, see the
 :doc:`fix ave/time <fix_ave_time>` page for details.  You must
-insure those settings are consistent with the snapshot timestamps that
+ensure those settings are consistent with the snapshot timestamps that
 are read from the dump file(s).  If an averaging fix is not invoked on
 a timestep it expects to be, LAMMPS will flag an error.
 

doc/src/run.rst

@@ -104,7 +104,7 @@ must be done.
 .. note::
 
    If your input script changes the system between 2 runs, then the
-   initial setup must be performed to insure the change is recognized by
+   initial setup must be performed to ensure the change is recognized by
    all parts of the code that are affected.  Examples are adding a
    :doc:`fix <fix>` or :doc:`dump <dump>` or :doc:`compute <compute>`, changing
    a :doc:`neighbor <neigh_modify>` list parameter, or writing restart file

doc/src/run_style.rst

@@ -203,7 +203,7 @@ operates on pair style computations, it is mutually exclusive with
 either the *pair* or the *inner*\ /\ *middle*\ /\ *outer* keywords.
 
 When using rRESPA (or for any MD simulation) care must be taken to
-choose a timestep size(s) that insures the Hamiltonian for the chosen
+choose a timestep size(s) that ensures the Hamiltonian for the chosen
 ensemble is conserved.  For the constant NVE ensemble, total energy
 must be conserved.  Unfortunately, it is difficult to know *a priori*
 how well energy will be conserved, and a fairly long test simulation

doc/src/set.rst

@@ -254,7 +254,7 @@ fraction of the selected atoms.  The actual number of atoms changed
 will be exactly the requested number.  For *type/ratio* the specified
 fraction (0 <= *fraction* <= 1) determines the number.  For
 *type/subset*, the specified *Nsubset* is the number.  An iterative
-algorithm is used which insures the correct number of atoms are
+algorithm is used which ensures the correct number of atoms are
 selected, in a perfectly random fashion.  Which atoms are selected
 will change with the number of processors used.  These keywords do not
 allow use of an atom-style variable.

doc/src/thermo_modify.rst

@@ -141,7 +141,7 @@ You can always include a divide by the number of atoms in the variable
 formula if this is not the case.
 
 The *flush* keyword invokes a flush operation after thermodynamic info
-is written to the screen and log file.  This insures the output is
+is written to the screen and log file.  This ensures the output is
 updated and not buffered (by the application) even if LAMMPS halts
 before the simulation completes.  Please note that this does not affect
 buffering by the OS or devices, so you may still lose data in case the

doc/src/thermo_style.rst

@@ -334,7 +334,7 @@ the number of re-builds that LAMMPS considered potentially
 the :doc:`neigh_modify <neigh_modify>` command), then dangerous
 reneighborings are those that were triggered on the first timestep
 atom movement was checked for.  If this count is non-zero you may wish
-to reduce the delay factor to insure no force interactions are missed
+to reduce the delay factor to ensure no force interactions are missed
 by atoms moving beyond the neighbor skin distance before a rebuild
 takes place.
 

doc/src/variable.rst

@@ -1420,7 +1420,7 @@ follows.  Also note that the 0-timestep run must actually use and
 invoke the compute in question (e.g. via :doc:`thermo <thermo_style>` or
 :doc:`dump <dump>` output) in order for it to enable the compute to be
 used in a variable after the run.  Thus if you are trying to print a
-variable that uses a compute you have defined, you can insure it is
+variable that uses a compute you have defined, you can ensure it is
 invoked on the last timestep of the preceding run by including it in
 thermodynamic output.
 
@@ -1460,7 +1460,7 @@ alter the state of the system between runs, causing a variable to
 evaluate incorrectly.
 
 The solution to this issue is the same as for case (2) above, namely
-perform a 0-timestep run before the variable is evaluated to insure
+perform a 0-timestep run before the variable is evaluated to ensure
 the system is up-to-date.  For example, this sequence of commands
 would print a potential energy that reflected the changed pairwise
 coefficient:

doc/src/velocity.rst

@@ -246,7 +246,7 @@ freedom (DOFs) is known.  Thus it is not possible to compute the
 target temperature correctly.  Second, the assigned velocities may be
 partially canceled when constraints are first enforced, leading to a
 different temperature than desired.  A workaround for this is to
-perform a :doc:`run 0 <run>` command, which insures all DOFs are
+perform a :doc:`run 0 <run>` command, which ensures all DOFs are
 accounted for properly, and then rescale the temperature to the
 desired value before performing a simulation.  For example:
 

examples/COUPLE/library/irregular.cpp

@@ -119,7 +119,7 @@ void Irregular::pattern(int n, int *proclist)
   for (int i = 0; i < nrecv; i++)
     MPI_Irecv(&recvcount[i],1,MPI_INT,MPI_ANY_SOURCE,0,comm,&request[i]);
 
-  // barrier to insure receives are posted
+  // barrier to ensure receives are posted
 
   MPI_Barrier(comm);
 
@@ -128,7 +128,7 @@ void Irregular::pattern(int n, int *proclist)
   for (int i = 0; i < nsend; i++)
     MPI_Send(&sendcount[i],1,MPI_INT,sendproc[i],0,comm);
 
-  // insure all MPI_ANY_SOURCE messages are received
+  // ensure all MPI_ANY_SOURCE messages are received
   // set recvproc
 
   if (nrecv) MPI_Waitall(nrecv,request,status);
@@ -270,7 +270,7 @@ void Irregular::exchange_same(char *sendbuf, char *recvbuf)
 
   char *buf = (char *) memory->smalloc(nsendmax,"buf");
 
-  // barrier to insure receives are posted
+  // barrier to ensure receives are posted
 
   MPI_Barrier(comm);
 
@@ -325,7 +325,7 @@ void Irregular::exchange_varying(char *sendbuf, char *recvbuf)
 
   char *buf = (char *) memory->smalloc(nsendmax,"buf");
 
-  // barrier to insure receives are posted
+  // barrier to ensure receives are posted
 
   MPI_Barrier(comm);
 

examples/COUPLE/plugin/liblammpsplugin.h

@@ -169,7 +169,7 @@ struct _liblammpsplugin {
   void (*scatter_subset)(void *, const char *, int, int, int, int *, void *);
 
 /* lammps_create_atoms() takes tagint and imageint as args
- * the ifdef insures they are compatible with rest of LAMMPS
+ * the ifdef ensures they are compatible with rest of LAMMPS
  * caller must match to how LAMMPS library is built */
 
 #ifndef LAMMPS_BIGBIG

examples/QM/LATTE/README

@@ -79,7 +79,7 @@ Copy the LAMMPS executable (lmp_mpi or lmp) into this dir as lmp_mpi.
 Copy the LATTE executable LATTE_DOUBLE into this dir.
 The run commands below assume you have done this.
 
-(5) Insure LD_LIBRARY_PATH includes the dir where MDI was built in (1)
+(5) Ensure LD_LIBRARY_PATH includes the dir where MDI was built in (1)
 with its libmdi.so file, e.g. mdi/build/MDI_Library.  This is needed
 so when LATTE_DOUBLE runs as an executable it will able to find
 libmdi.so.

examples/pour/in.pour.2d.molecule

@@ -34,7 +34,7 @@ fix		ywalls all wall/gran hertz/history 4000.0 NULL 100.0 NULL 0 1 &
 molecule        object molecule.vshape
 fix             3 all rigid/small molecule mol object
 
-# insure region size + molecule size does not overlap wall
+# ensure region size + molecule size does not overlap wall
 
 region          slab block 3.0 97.0 30 34.5 -0.5 0.5 units box
 fix             ins all pour 500 0 4767548 vol 0.8 10 &

examples/pour/log.27Nov18.pour.2d.molecule.g++.1

@@ -44,7 +44,7 @@ fix             3 all rigid/small molecule mol object
 0 rigid bodies with 0 atoms
   2.23607 = max distance from body owner to body atom
 
-# insure region size + molecule size does not overlap wall
+# ensure region size + molecule size does not overlap wall
 
 region          slab block 3.0 97.0 30 34.5 -0.5 0.5 units box
 fix             ins all pour 500 0 4767548 vol 0.8 10 	        region slab mol object rigid 3

examples/pour/log.27Nov18.pour.2d.molecule.g++.4

@@ -44,7 +44,7 @@ fix             3 all rigid/small molecule mol object
 0 rigid bodies with 0 atoms
   2.23607 = max distance from body owner to body atom
 
-# insure region size + molecule size does not overlap wall
+# ensure region size + molecule size does not overlap wall
 
 region          slab block 3.0 97.0 30 34.5 -0.5 0.5 units box
 fix             ins all pour 500 0 4767548 vol 0.8 10 	        region slab mol object rigid 3

lib/atc/README

@@ -40,7 +40,7 @@ Makefile.lammps is created by the make command, by copying one of the
 Makefile.lammps.* files.  See the EXTRAMAKE setting at the top of the
 Makefile.* files.
 
-IMPORTANT: You must examine the final Makefile.lammps to insure it is
+IMPORTANT: You must examine the final Makefile.lammps to ensure it is
 correct for your system, else the LAMMPS build will likely fail.
 
 Makefile.lammps has settings for 3 variables:

lib/awpmd/README

@@ -43,7 +43,7 @@ Makefile.lammps is created by the make command, by copying one of the
 Makefile.lammps.* files.  See the EXTRAMAKE setting at the top of the
 Makefile.* files.
 
-IMPORTANT: You must examine the final Makefile.lammps to insure it is
+IMPORTANT: You must examine the final Makefile.lammps to ensure it is
 correct for your system, else the LAMMPS build will likely fail.
 
 Makefile.lammps has settings for 3 variables:

lib/gpu/README

@@ -128,12 +128,12 @@ Makefile.lammps is created by the make command, by copying one of the
 Makefile.lammps.* files.  See the EXTRAMAKE setting at the top of the
 Makefile.* files.
 
-IMPORTANT: You should examine the final Makefile.lammps to insure it is
+IMPORTANT: You should examine the final Makefile.lammps to ensure it is
 correct for your system, else the LAMMPS build can fail.
 
 IMPORTANT: If you re-build the library, e.g. for a different precision
 (see below), you should do a "make clean" first, e.g. make -f
-Makefile.linux clean, to insure all previous derived files are removed
+Makefile.linux clean, to ensure all previous derived files are removed
 before the new build is done.
 
 NOTE: The system-specific setting LAMMPS_SMALLBIG (default), LAMMPS_BIGBIG,

python/lammps/core.py

@@ -1204,7 +1204,7 @@ class lammps(object):
   # dtype = 0 for integer values, 1 for double values
   # count = number of per-atom valus, 1 for type or charge, 3 for x or f
   # returned data is a 1d vector - doc how it is ordered?
-  # NOTE: need to insure are converting to/from correct Python type
+  # NOTE: need to ensure are converting to/from correct Python type
   #   e.g. for Python list or NumPy or ctypes
 
   def gather_atoms(self,name,dtype,count):
@@ -1258,7 +1258,7 @@ class lammps(object):
   # type = 0 for integer values, 1 for double values
   # count = number of per-atom valus, 1 for type or charge, 3 for x or f
   # assume data is of correct type and length, as created by gather_atoms()
-  # NOTE: need to insure are converting to/from correct Python type
+  # NOTE: need to ensure are converting to/from correct Python type
   #   e.g. for Python list or NumPy or ctypes
 
   def scatter_atoms(self,name,dtype,count,data):
@@ -1305,7 +1305,7 @@ class lammps(object):
   # type = 0 for integer values, 1 for double values
   # count = number of per-atom valus, 1 for type or charge, 3 for x or f
   # returned data is a 1d vector - doc how it is ordered?
-  # NOTE: need to insure are converting to/from correct Python type
+  # NOTE: need to ensure are converting to/from correct Python type
   #   e.g. for Python list or NumPy or ctypes
   def gather(self,name,dtype,count):
     if name: name = name.encode()
@@ -1354,7 +1354,7 @@ class lammps(object):
   # type = 0 for integer values, 1 for double values
   # count = number of per-atom valus, 1 for type or charge, 3 for x or f
   # assume data is of correct type and length, as created by gather_atoms()
-  # NOTE: need to insure are converting to/from correct Python type
+  # NOTE: need to ensure are converting to/from correct Python type
   #   e.g. for Python list or NumPy or ctypes
 
   def scatter(self,name,dtype,count,data):
@@ -1414,7 +1414,7 @@ class lammps(object):
   # type = type of each atom (1 to Ntypes) (required)
   # x = coords of each atom as (N,3) array (required)
   # v = velocity of each atom as (N,3) array (optional, can be None)
-  # NOTE: how could we insure are passing correct type to LAMMPS
+  # NOTE: how could we ensure are passing correct type to LAMMPS
   #   e.g. for Python list or NumPy, etc
   #   ditto for gather_atoms() above
 

src/ADIOS/dump_atom_adios.cpp

@@ -153,7 +153,7 @@ void DumpAtomADIOS::write()
   internal->varAtoms.SetShape({nAtomsGlobal, nColumns});
   internal->varAtoms.SetSelection({{startRow, 0}, {nAtomsLocal, nColumns}});
 
-  // insure buf is sized for packing
+  // ensure buf is sized for packing
   // adios does not limit per-process data size so nme*size_one is not
   // constrained to int
   // if sorting on IDs also request ID list from pack()

src/ADIOS/dump_custom_adios.cpp

@@ -165,7 +165,7 @@ void DumpCustomADIOS::write()
   internal->varAtoms.SetShape({nAtomsGlobal, nColumns});
   internal->varAtoms.SetSelection({{startRow, 0}, {nAtomsLocal, nColumns}});
 
-  // insure filewriter proc can receive everyone's info
+  // ensure filewriter proc can receive everyone's info
   // limit nmax*size_one to int since used as arg in MPI_Rsend() below
   // pack my data into buf
   // if sorting on IDs also request ID list from pack()

src/AMOEBA/atom_vec_amoeba.cpp

@@ -101,7 +101,7 @@ void AtomVecAmoeba::grow_pointers()
 
 void AtomVecAmoeba::pack_restart_pre(int ilocal)
 {
-  // insure negative vectors are needed length
+  // ensure negative vectors are needed length
 
   if (bond_per_atom < atom->bond_per_atom) {
     delete[] bond_negative;

src/BOCS/compute_pressure_bocs.cpp

@@ -56,7 +56,7 @@ ComputePressureBocs::ComputePressureBocs(LAMMPS *lmp, int narg, char **arg) :
   phi_coeff = nullptr;
 
   // store temperature ID used by pressure computation
-  // insure it is valid for temperature computation
+  // ensure it is valid for temperature computation
 
   if (strcmp(arg[3],"NULL") == 0) id_temp = nullptr;
   else {

src/BODY/compute_body_local.cpp

@@ -85,7 +85,7 @@ ComputeBodyLocal::~ComputeBodyLocal()
 
 void ComputeBodyLocal::init()
 {
-  // if non-body particles in group insure only indices 1,2,3 are used
+  // if non-body particles in group ensure only indices 1,2,3 are used
 
   int nonbody = 0;
   int *mask = atom->mask;

src/BPM/atom_vec_bpm_sphere.cpp

@@ -148,7 +148,7 @@ void AtomVecBPMSphere::create_atom_post(int ilocal)
 
 void AtomVecBPMSphere::pack_restart_pre(int ilocal)
 {
-  // insure bond_negative vector is needed length
+  // ensure bond_negative vector is needed length
 
   if (bond_per_atom < atom->bond_per_atom) {
     delete[] bond_negative;

src/CG-SPICA/pair_lj_spica_coul_long.cpp

@@ -368,7 +368,7 @@ void PairLJSPICACoulLong::init_style()
 
   cut_coulsq = cut_coul * cut_coul;
 
-  // insure use of KSpace long-range solver, set g_ewald
+  // ensure use of KSpace long-range solver, set g_ewald
 
   if (force->kspace == nullptr) error->all(FLERR, "Pair style requires a KSpace style");
   g_ewald = force->kspace->g_ewald;

src/CLASS2/pair_lj_class2_coul_long.cpp

@@ -688,7 +688,7 @@ void PairLJClass2CoulLong::init_style()
   else
     cut_respa = nullptr;
 
-  // insure use of KSpace long-range solver, set g_ewald
+  // ensure use of KSpace long-range solver, set g_ewald
 
   if (force->kspace == nullptr) error->all(FLERR, "Pair style requires a KSpace style");
   g_ewald = force->kspace->g_ewald;

src/COLLOID/fix_wall_colloid.cpp

@@ -38,7 +38,7 @@ void FixWallColloid::init()
   if (!atom->sphere_flag)
     error->all(FLERR,"Fix wall/colloid requires atom style sphere");
 
-  // insure all particles in group are extended particles
+  // ensure all particles in group are extended particles
 
   double *radius = atom->radius;
   int *mask = atom->mask;

src/COLLOID/pair_brownian.cpp

@@ -449,7 +449,7 @@ void PairBrownian::init_style()
 
   neighbor->add_request(this);
 
-  // insure all particles are finite-size
+  // ensure all particles are finite-size
   // for pair hybrid, should limit test to types using the pair style
 
   double *radius = atom->radius;

src/COLLOID/pair_brownian_poly.cpp

@@ -325,7 +325,7 @@ void PairBrownianPoly::init_style()
   if (!atom->sphere_flag)
     error->all(FLERR,"Pair brownian/poly requires atom style sphere");
 
-  // insure all particles are finite-size
+  // ensure all particles are finite-size
   // for pair hybrid, should limit test to types using the pair style
 
   double *radius = atom->radius;

src/COLLOID/pair_lubricateU_poly.cpp

@@ -1133,7 +1133,7 @@ void PairLubricateUPoly::init_style()
   if (!atom->sphere_flag)
     error->all(FLERR,"Pair lubricate/poly requires atom style sphere");
 
-  // insure all particles are finite-size
+  // ensure all particles are finite-size
   // for pair hybrid, should limit test to types using the pair style
 
   double *radius = atom->radius;

src/CORESHELL/compute_temp_cs.cpp

@@ -123,7 +123,7 @@ void ComputeTempCS::setup()
   if (firstflag) {
     firstflag = 0;
 
-    // insure # of core atoms = # of shell atoms
+    // ensure # of core atoms = # of shell atoms
 
     int ncores = group->count(cgroup);
     nshells = group->count(sgroup);
@@ -133,7 +133,7 @@ void ComputeTempCS::setup()
     // for each C/S pair:
     // set partner IDs of both atoms if this atom stores bond between them
     // will set partner IDs for ghost atoms if needed by another proc
-    // nall loop insures all ghost atom partner IDs are set before reverse comm
+    // nall loop ensures all ghost atom partner IDs are set before reverse comm
 
     int *num_bond = atom->num_bond;
     tagint **bond_atom = atom->bond_atom;

src/DIELECTRIC/pair_coul_long_dielectric.cpp

@@ -200,7 +200,7 @@ void PairCoulLongDielectric::init_style()
 
   cut_coulsq = cut_coul * cut_coul;
 
-  // insure use of KSpace long-range solver, set g_ewald
+  // ensure use of KSpace long-range solver, set g_ewald
 
   if (force->kspace == nullptr) error->all(FLERR, "Pair style requires a KSpace style");
   g_ewald = force->kspace->g_ewald;