Edits to devleoper doc files 2

doc/src/Developer_notes.rst

@@ -20,7 +20,7 @@ Available topics are:
 Reading and parsing of text and text files
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-It is frequently required for a class in LAMMPS to read in additional
+Classes in LAMMPS frequently need to read in additional
 data from a file, e.g. potential parameters from a potential file for
 manybody potentials.  LAMMPS provides several custom classes and
 convenience functions to simplify the process.  They offer the
@@ -128,9 +128,8 @@ that determines the kind of neighbor list requested.  The default value
 used here asks for a perpetual "half" neighbor list.
 
 Non-default values of the second argument need to be used to adjust a
-neighbor list request to the specific needs of a style an additional
+neighbor list request to the specific needs of a style.  The :doc:`tersoff
-request flag is needed.  The :doc:`tersoff <pair_tersoff>` pair style,
+<pair_tersoff>` pair style, for example, needs a "full" neighbor list:
-for example, needs a "full" neighbor list:
 
 .. code-block:: c++
 
@@ -141,8 +140,8 @@ for example, needs a "full" neighbor list:
    }
 
 When a pair style supports r-RESPA time integration with different cutoff regions,
-the request flag may depend on the corresponding r-RESPA settings. Here an example
+the request flag may depend on the corresponding r-RESPA settings. Here is an
-from pair style lj/cut:
+example from pair style lj/cut:
 
 .. code-block:: c++
 
@@ -160,7 +159,7 @@ from pair style lj/cut:
    }
 
 Granular pair styles need neighbor lists based on particle sizes and not cutoff
-and also may require to have the list of previous neighbors available ("history").
+and also may need to store data across timesteps ("history").
 For example with:
 
 .. code-block:: c++
@@ -169,7 +168,7 @@ For example with:
    else neighbor->add_request(this, NeighConst::REQ_SIZE);
 
 In case a class would need to make multiple neighbor list requests with different
-settings each request can set an id which is then used in the corresponding
+settings, each request can set an id which is then used in the corresponding
 ``init_list()`` function to assign it to the suitable pointer variable. This is
 done for example by the :doc:`pair style meam <pair_meam>`:
 
@@ -279,8 +278,8 @@ And here is how the code operates:
 * The :doc:`thermo_style custom <thermo_style>` command defines
   *ecouple* and *econserve* keywords.
 * These keywords sum the energy contributions from all the
-  *ecouple_flag* = 1 fixes by invoking the energy_couple() method in
+  *ecouple_flag* = 1 fixes by invoking the *energy_couple()* method in
-  the Modify class, which calls the compute_scalar() method of each
+  the Modify class, which calls the *compute_scalar()* method of each
   fix in the list.
 
 ------------------
@@ -320,19 +319,19 @@ The fix must also do the following:
 
    The ev_init() and ev_tally() methods also account for global and
    peratom virial contributions.  Thus you do not need to invoke the
-   v_init() and v_tally() methods, if the fix also calculates peratom
+   v_init() and v_tally() methods if the fix also calculates peratom
    energies.
 
 The fix must also specify whether (by default) to include or exclude
 these contributions to the global/peratom energy/virial of the system.
-For the fix to include the contributions, set either of both of these
+For the fix to include the contributions, set either or both of these
 variables in the constructor:
 
 * *thermo_energy* = 1, for global and peratom energy
 * *thermo_virial* = 1, for global and peratom virial
 
 Note that these variables are zeroed in fix.cpp.  Thus if you don't
-set the variables, the contributions will be excluded (by default)
+set the variables, the contributions will be excluded (by default).
 
 However, the user has ultimate control over whether to include or
 exclude the contributions of the fix via the :doc:`fix modify
@@ -406,9 +405,11 @@ processor owns, within the global grid:
 
 .. parsed-literal::
 
-   nxlo_in,nxhi_in,nylo_in,nyhi_in,nzlo_in,nzhi_in = 3d decomposition brick
+   nFOO_in = 3d decomposition brick
-   nxlo_fft,nxhi_fft,nylo_fft,nyhi_fft,nzlo_fft,nzhi_fft = FFT decomposition brick
+   nFOO_fft = FFT decomposition brick
-   nxlo_out,nxhi_out,nylo_out,nyhi_out,nzlo_out,nzhi_out = 3d decomposition brick + ghost cells
+   nFOO_out = 3d decomposition brick + ghost cells
+
+where ``FOO`` corresponds to ``xlo, xhi, ylo, yhi, zlo,`` or ``zhi``.
 
 The ``in`` and ``fft`` indices are from 0 to N-1 inclusive in each
 dimension, where N is the grid size.

doc/src/Developer_plugins.rst

@@ -135,7 +135,7 @@ unique inside the entire LAMMPS executable.
 Fix style example
 ^^^^^^^^^^^^^^^^^
 
-If the factory function would be for a fix or compute, which take three
+If the factory function is for a fix or compute, which take three
 arguments (a pointer to the LAMMPS class, the number of arguments and the
 list of argument strings), then the pointer type is ``lammpsplugin_factory2``
 and it must be assigned to the *creator.v2* member of the plugin struct.
@@ -271,7 +271,7 @@ Plugins need to be compiled with the same compilers and libraries
 as the LAMMPS executable and library.  Otherwise the plugin will likely
 not load due to mismatches in the function signatures (LAMMPS is C++ so
 scope, type, and number of arguments are encoded into the symbol names
-and thus differences in them will lead to failed plugin load commands.
+and thus differences in them will lead to failed plugin load commands).
 Compilation of the plugin can be managed via both, CMake or traditional
 GNU makefiles.  Some examples that can be used as a template are in the
 ``examples/plugins`` folder.  The CMake script code has some small

doc/src/Developer_unittest.rst

@@ -227,12 +227,12 @@ Tests for the C-style library interface
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Tests for validating the LAMMPS C-style library interface are in the
-``unittest/c-library`` folder.  They are implemented in either way used
+``unittest/c-library`` folder.  They are implemented either to be used
-for utility functions and for LAMMPS commands, but use the functions
+for utility functions or for LAMMPS commands, but use the functions
 implemented in the ``src/library.cpp`` file as much as possible.  There
 may be some overlap with other tests, but only in as much as is required
 to test the C-style library API.  The tests are distributed over
-multiple test programs which tries to match the grouping of the
+multiple test programs which try to match the grouping of the
 functions in the source code and :ref:`in the manual <lammps_c_api>`.
 
 This group of tests also includes tests invoking LAMMPS in parallel
@@ -258,7 +258,7 @@ Tests for the Python module and package
 
 The ``unittest/python`` folder contains primarily tests for classes and
 functions in the LAMMPS python module but also for commands in the
-PYTHON package.  These tests are only enabled, if the necessary
+PYTHON package.  These tests are only enabled if the necessary
 prerequisites are detected or enabled during configuration and
 compilation of LAMMPS (shared library build enabled, Python interpreter
 found, Python development files found).
@@ -272,7 +272,7 @@ Tests for the Fortran interface
 
 Tests for using the Fortran module are in the ``unittest/fortran``
 folder.  Since they are also using the GoogleTest library, they require
-to also implement test wrappers in C++ that will call fortran functions
+implementing test wrappers in C++ that will call fortran functions
 which provide a C function interface through ISO_C_BINDINGS that will in
 turn call the functions in the LAMMPS Fortran module.
 
@@ -293,7 +293,7 @@ The ``unittest/formats`` folder contains test programs for reading and
 writing files like data files, restart files, potential files or dump files.
 This covers simple things like the file i/o convenience functions in the
 ``utils::`` namespace to complex tests of atom styles where creating and
-deleting of atoms with different properties is tested in different ways
+deleting atoms with different properties is tested in different ways
 and through script commands or reading and writing of data or restart files.
 
 Tests for styles computing or modifying forces
@@ -411,7 +411,7 @@ With this scheme a large fraction of the code of any tested pair style
 will be executed and consistent results are required for different
 settings and between different accelerated pair style variants and the
 base class, as well as for computing individual pairs through the
-``Pair::single()`` where supported.
+``Pair::single()`` method where supported.
 
 The ``test_pair_style`` tester is used with 4 categories of test inputs:
 
@@ -443,7 +443,7 @@ file for a style that is similar to one to be tested.  The file name should
 follow the naming conventions described above and after copying the file,
 the first step is to replace the style names where needed.  The coefficient
 values do not have to be meaningful, just in a reasonable range for the
-given system.  It does not matter if some forces are large, for as long as
+given system.  It does not matter if some forces are large, as long as
 they do not diverge.
 
 The template input files define a large number of index variables at the top
@@ -535,7 +535,7 @@ The are by default no unit tests for newly added features (e.g. pair, fix,
 or compute styles) unless your pull request also includes tests for the
 added features.  If you are modifying some features, you may see failures
 for existing tests, if your modifications have some unexpected side effects
-or your changes render the existing text invalid.  If you are adding an
+or your changes render the existing test invalid.  If you are adding an
 accelerated version of an existing style, then only tests for INTEL,
 KOKKOS (with OpenMP only), OPENMP, and OPT will be run automatically.
 Tests for the GPU package are time consuming and thus are only run
@@ -543,7 +543,7 @@ Tests for the GPU package are time consuming and thus are only run
 to the pull request.  After the test has started, it is often best to
 remove the label since every PR activity will re-trigger the test (that
 is a limitation of triggering a test with a label).  Support for unit
-tests with using KOKKOS with GPU acceleration is currently not supported.
+tests when using KOKKOS with GPU acceleration is currently not supported.
 
 When you see a failed build on GitHub, click on ``Details`` to be taken
 to the corresponding LAMMPS Jenkins CI web page.  Click on the "Exit"
@@ -589,11 +589,10 @@ While the epsilon (relative precision) for a single, `IEEE 754 compliant
 point operation is at about 2.2e-16, the achievable precision for the
 tests is lower due to most numbers being sums over intermediate results
 and the non-associativity of floating point math leading to larger
-errors.  In some cases specific properties of the tested style.  As a
+errors.  As a rule of thumb, the test epsilon can often be in the range
-rule of thumb, the test epsilon can often be in the range 5.0e-14 to
+5.0e-14 to 1.0e-13.  But for "noisy" force kernels, e.g. those a larger
-1.0e-13.  But for "noisy" force kernels, e.g. those a larger amount of
+amount of arithmetic operations involving `exp()`, `log()` or `sin()`
-arithmetic operations involving `exp()`, `log()` or `sin()` functions,
+functions, and also due to the effect of compiler optimization or differences
-and also due to the effect of compiler optimization or differences
 between compilers or platforms, epsilon may need to be further relaxed,
 sometimes epsilon can be relaxed to 1.0e-12. If interpolation or lookup
 tables are used, epsilon may need to be set to 1.0e-10 or even higher.

doc/src/Developer_updating.rst

@@ -52,10 +52,9 @@ Rename of pack/unpack_comm() to pack/unpack_forward_comm()
 
 .. versionchanged:: 8Aug2014
 
-In this change set the functions to pack data into communication buffers
+In this change set, the functions to pack/unpack data into communication buffers
-and to unpack data from communication buffers for :doc:`forward
+for :doc:`forward communications <Developer_comm_ops>` were renamed from
-communications <Developer_comm_ops>` were renamed from ``pack_comm()``
+``pack_comm()`` and ``unpack_comm()`` to ``pack_forward_comm()`` and
-and ``unpack_comm()`` to ``pack_forward_comm()`` and
 ``unpack_forward_comm()``, respectively.  Also the meaning of the return
 value of these functions was changed: rather than returning the number
 of items per atom stored in the buffer, now the total number of items
@@ -109,7 +108,7 @@ Use ev_init() to initialize variables derived from eflag and vflag
 There are several variables that need to be initialized based on
 the values of the "eflag" and "vflag" variables and since sometimes
 there are new bits added and new variables need to be set to 1 or 0.
-To make this consistent, across all styles, there is now an inline
+To make this consistent across all styles, there is now an inline
 function ``ev_init(eflag, vflag)`` that makes those settings
 consistently and calls either ``ev_setup()`` or ``ev_unset()``.
 Example from a pair style:
@@ -211,14 +210,14 @@ The :cpp:func:`utils::open_potential()
 calls to ``force->open_potential()`` and should be used to replace
 ``fopen()`` for opening potential files for reading.  The custom
 function does three additional steps compared to ``fopen()``: 1) it will
-try to parse the ``UNITS:`` and ``DATE:`` metadata will stop with an
+try to parse the ``UNITS:`` and ``DATE:`` metadata and will stop with an
 error on a units mismatch and will print the date info, if present, in
 the log file; 2) for pair styles that support it, it will set up
 possible automatic unit conversions based on the embedded unit
 information and LAMMPS' current units setting; 3) it will not only try
 to open a potential file at the given path, but will also search in the
 folders listed in the ``LAMMPS_POTENTIALS`` environment variable.  This
-allows to keep potential files in a common location instead of having to
+allows potential files to reside in a common location instead of having to
 copy them around for simulations.
 
 Old:
@@ -306,7 +305,7 @@ Simplify customized error messages
 
 Aided by features of the bundled {fmt} library, error messages now
 can have a variable number of arguments and the string will be interpreted
-as a {fmt} style format string so that custom error messages can be
+as a {fmt} style format string so that error messages can be
 easily customized without having to use temporary buffers and ``sprintf()``.
 Example:
 
@@ -332,7 +331,7 @@ Use of "override" instead of "virtual"
 
 .. versionchanged:: 17Feb2022
 
-Since LAMMPS requires C++11 we switched to use the "override" keyword
+Since LAMMPS requires C++11, we switched to use the "override" keyword
 instead of "virtual" to indicate polymorphism in derived classes.  This
 allows the C++ compiler to better detect inconsistencies when an
 override is intended or not.  Please note that "override" has to be
@@ -370,7 +369,7 @@ Simplified function names for forward and reverse communication
 
 .. versionchanged:: 24Mar2022
 
-Rather then using the function name to distinguish between the different
+Rather than using the function name to distinguish between the different
 forward and reverse communication functions for styles, LAMMPS now uses
 the type of the "this" pointer argument.
 

doc/src/Developer_utils.rst

@@ -622,7 +622,7 @@ classes:
    of a dense, symmetric, real matrix.
 
 #. The "PEigenDense" class only calculates the principal eigenvalue
-   (ie. the largest or smallest eigenvalue), and its corresponding
+   (i.e. the largest or smallest eigenvalue), and its corresponding
    eigenvector.  However it is much more efficient than "Jacobi" when
    applied to large matrices (larger than 13x13).  PEigenDense also can
    understand complex-valued Hermitian matrices.

doc/src/Developer_write_fix.rst

@@ -74,8 +74,7 @@ The next method we need to implement is ``setmask()``:
 
 Here the we specify which methods of the fix should be called during
 :doc:`execution of a timestep <Developer_flow>`.  The constant
-``END_OF_STEP`` corresponds to the ``end_of_step()`` method. The most
+``END_OF_STEP`` corresponds to the ``end_of_step()`` method.
-important available methods that are called during a timestep.
 
 .. code-block:: c++
 
@@ -127,7 +126,7 @@ there is no need to inherit from it directly.
 The code above computes average velocity for all particles in the
 simulation.  Yet you have one unused parameter in fix call from the
 script: ``group_name``.  This parameter specifies the group of atoms
-used in the fix. So we should compute average for all particles in the
+used in the fix. So we should compute the average for all particles in the
 simulation only if ``group_name == "all"``, but it can be any group.
 The group membership information of an atom is contained in the *mask*
 property of an atom and the bit corresponding to a given group is
@@ -142,7 +141,7 @@ stored in the groupbit variable which is defined in Fix base class:
    }
 
 Class Atom encapsulates atoms positions, velocities, forces, etc. Users
-can access them using particle index. Note, that particle indexes are
+can access them using the particle index. Note, that particle indexes are
 usually changed every few timesteps because of neighbor list rebuilds
 and spatial sorting (to improve cache efficiency).
 
@@ -154,8 +153,8 @@ this situation there are several methods which should be implemented:
 - ``double memory_usage()``: return how much memory the fix uses (optional)
 - ``void grow_arrays(int)``: do reallocation of the per-particle arrays in your fix
 - ``void copy_arrays(int i, int j, int delflag)``: copy i-th per-particle
-  information to j-th. Used when atom sorting is performed. if delflag is set
+  information to j-th particle position. Used when atom sorting is performed.
-  and atom j owns a body, move the body information to atom i.
+  if delflag is set and atom j owns a body, move the body information to atom i.
 - ``void set_arrays(int i)``: sets i-th particle related information to zero
 
 Note, that if your class implements these methods, it must add calls of
@@ -230,11 +229,11 @@ is just a bunch of template functions for allocating 1D and 2D
 arrays. So you need to add include ``memory.h`` to have access to them.
 
 Finally, if you need to write/read some global information used in
-your fix to the restart file, you might do it by setting flag
+your fix to the restart file, you might do it by setting the flag
-``restart_global = 1`` in the constructor and implementing methods void
+``restart_global = 1`` in the constructor and implementing methods
-``write_restart(FILE *fp)`` and ``void restart(char *buf)``.
+``void write_restart(FILE *fp)`` and ``void restart(char *buf)``.
 If, in addition, you want to write the per-atom property to restart
-files additional settings and functions are needed:
+files then these additional settings and functions are needed:
 
 - a fix flag indicating this needs to be set ``restart_peratom = 1;``
 - ``atom->add_callback()`` and ``atom->delete_callback()`` must be called

doc/src/Developer_write_pair.rst

@@ -371,9 +371,9 @@ but moving this to a separate function allows users to change global
 settings like the default cutoff without having to reissue all
 pair_coeff commands or re-read the ``Pair Coeffs`` sections from the
 data file.  In the ``settings()`` function, also the arrays for storing
-parameters, to define cutoffs, track with pairs of parameters have been
+parameters, to define cutoffs, track which pairs of parameters have been
-explicitly set are allocated and, if needed, initialized.  In this case,
+explicitly set and allocated and, if needed, initialized.  In this case,
-the memory allocation and initialization is moved to a function
+the memory allocation and initialization are moved to a function
 ``allocate()``.
 
 .. code-block:: c++
@@ -588,11 +588,12 @@ loop atoms are also initialized.
        jnum = numneigh[i];
 
 The inner loop (index *j*) processes the neighbor lists.  The neighbor
-list code encodes in the upper 2 bits whether a pair is a regular pair
+list code encodes extra information using the upper 3 bits. The 2 highest
-of neighbor (= 0) or a pair of 1-2 (= 1), 1-3 (= 2), or 1-4 (= 3)
+bits encode whether a pair is a regular pair of neighbor (= 0) or a pair
-:doc:`"special" neighbor <special_bonds>`.  The ``sbmask()`` inline
+of 1-2 (= 1), 1-3 (= 2), or 1-4 (= 3) :doc:`"special" neighbor <special_bonds>`. The next highest bit encodes whether the pair stores
-function extracts those bits and converts them into a number.  This
+data in :doc:`fix neigh/history <fix_neigh_history`. The ``sbmask()``
-number is used to look up the corresponding scaling factor for the
+inline function extracts those bits and converts them into a number.
+This number is used to look up the corresponding scaling factor for the
 non-bonded interaction from the ``force->special_lj`` array and stores
 it in the `factor_lj` variable.  Due to the additional bits, the value
 of *j* would be out of range when accessing data from per-atom arrays,
@@ -891,7 +892,7 @@ through *multiple* :doc:`pair_coeff commands <pair_coeff>`.  Pair styles
 that require a single "pair_coeff \* \*" command line are not compatible
 with reading their parameters from data files.  For pair styles like
 *born/gauss* that do support writing to data files, the potential
-parameters will be read from the data file, if present and
+parameters will be read from the data file, if present, and
 :doc:`pair_coeff commands <pair_coeff>` may not be needed.
 
 The member variable ``writedata`` should be set to 1 in the constructor,

src/atom.cpp

@@ -82,7 +82,7 @@ are updated by the AtomVec class as needed.
 
 /** Atom class constructor
  *
- * This resets and initialized all kinds of settings,
+ * This resets and initializes all kinds of settings,
  * parameters, and pointer variables for per-atom arrays.
  * This also initializes the factory for creating
  * instances of classes derived from the AtomVec base
@@ -2831,7 +2831,7 @@ This will remove a property that was requested, e.g. by the
 :doc:`fix property/atom <fix_property_atom>` command.  It frees the
 allocated memory and sets the pointer to ``nullptr`` for the entry in
 the list so it can be reused. The lists of these pointers are never
-compacted or shrink, so that indices to name mappings remain valid.
+compacted or shrunk, so that indices to name mappings remain valid.
 \endverbatim
  * \param index Index of property in the respective list of properties
  * \param flag Data type of property: 0 for int, 1 for double
@@ -2991,11 +2991,11 @@ length of the data area, and a short description.
      - single double value defined by fix property/atom vector name
    * - i2_name
      - int
-     - n
+     - N
      - N integer values defined by fix property/atom array name
    * - d2_name
      - double
-     - n
+     - N
      - N double values defined by fix property/atom array name
 
 *See also*

src/input.cpp

@@ -78,7 +78,7 @@ template <typename T> static Command *command_creator(LAMMPS *lmp)
 
 The Input class contains methods for reading, pre-processing and
 parsing LAMMPS commands and input files and will dispatch commands
-to the respective class instances or contains the code to execute
+to the respective class instances or contain the code to execute
 the commands directly.  It also contains the instance of the
 Variable class which performs computations and text substitutions.
 
@@ -320,8 +320,8 @@ void Input::file()
  *
 \verbatim embed:rst
 
-This function opens the file at the path *filename*, put the current
+This function opens the file at the path *filename*, puts the current
-file pointer stored in *infile* on a stack and instead assign *infile*
+file pointer stored in *infile* on a stack and instead assigns *infile*
 with the newly opened file pointer.  Then it will call the
 :cpp:func:`Input::file() <LAMMPS_NS::Input::file()>` function to read,
 parse and execute the contents of that file.  When the end of the file

src/lammps.cpp

@@ -1171,7 +1171,7 @@ bool LAMMPS::is_installed_pkg(const char *pkg)
 /** \brief Return name of package that a specific style belongs to
  *
  * This function checks the given name against all list of styles
- * for all type of styles and if the name and the style match, it
+ * for all types of styles and if the name and the style match, it
  * returns which package this style belongs to.
  *
  * \param style Type of style (e.g. atom, pair, fix, etc.)

src/my_page.cpp

@@ -40,7 +40,7 @@ using namespace LAMMPS_NS;
  * chunks of size *maxchunk*.  The combination of these two
  * parameters determines how much memory is wasted by either switching
  * to the next page too soon or allocating too large pages that never
- * get properly used.  It is an error, if a requested chunk is larger
+ * get properly used.  An error is issued if a requested chunk is larger
  * than *maxchunk*.  The *pagedelta* parameter determines how many
  * pages are allocated in one go.  In combination with the *pagesize*
  * setting, this determines how often blocks of memory get allocated
@@ -48,7 +48,7 @@ using namespace LAMMPS_NS;
  *
  * \note
  * This is a template class with explicit instantiation. If the class
- * is used with a new data type a new explicit instantiation may need to
+ * is used with a new data type, a new explicit instantiation may need to
  * be added at the end of the file ``src/my_page.cpp`` to avoid symbol
  * lookup errors. */
 
@@ -101,7 +101,7 @@ template <class T> int MyPage<T>::init(int user_maxchunk, int user_pagesize, int
  *
  * This will allocate more pages as needed.
  * If the parameter *N* is larger than the *maxchunk*
- * setting an error is flagged.
+ * setting, an error is flagged.
  *
  * \param  n  number of items for which storage is requested
  * \return    memory location or null pointer, if error or allocation failed */

src/my_page.h

@@ -62,7 +62,7 @@ template <class T> class MyPage {
   /** Mark *N* items as used of the chunk reserved with a preceding call to vget().
    *
    * This will advance the internal pointer inside the current memory page.
-   * It is not necessary to call this function for *N* = 0, that is the reserved
+   * It is not necessary to call this function for *N* = 0, implying the reserved
    * storage was not used.  A following call to vget() will then reserve the
    * same location again.  It is an error if *N* > *maxchunk*.
    *

src/my_pool_chunk.cpp

@@ -35,7 +35,7 @@ using namespace LAMMPS_NS;
  *
  * \note
  * This is a template class with explicit instantiation. If the class
- * is used with a new data type a new explicit instantiation may need
+ * is used with a new data type, a new explicit instantiation may need
  * to be added at the end of the file ``src/my_pool_chunk.cpp`` to
  * avoid symbol lookup errors. */
 

src/platform.h

@@ -28,7 +28,7 @@ namespace platform {
   /*! Return the consumed CPU time for the current process in seconds
    *
    * This is a wrapper around the POSIX function getrusage() and its Windows equivalent.
-   * It is to be used in a similar fashion than MPI_Wtime().  Its resolution may be rather
+   * It is to be used in a similar fashion as MPI_Wtime().  Its resolution may be rather
    * low so it can only be trusted when observing processes consuming CPU time of at least
    * a few seconds.
    *
@@ -38,7 +38,7 @@ namespace platform {
 
   /*! Return the wall clock state for the current process in seconds
    *
-   * This this clock is counting continuous time and is initialized during
+   * This clock is counting continuous time and is initialized during
    * load of the executable/library.  Its absolute value must be considered
    * arbitrary and thus elapsed wall times are measured in taking differences.
    * It is therefore to be used in a similar fashion as MPI_Wtime() but
@@ -154,7 +154,7 @@ namespace platform {
    *
    * Return a human-readable string describing the most recent error that
    * occurred when using one of the functions for dynamic loading objects
-   * the last call to this function. The string is empty, if there was no error.
+   * the last call to this function. If there was no error, the string is empty.
    *
    * \return  string with error message or empty */
 
@@ -247,13 +247,13 @@ namespace platform {
    * This function will traverse the list of directories in the PATH
    * environment variable and look for the executable *cmd*.  If the
    * file exists and is executable the full path is returned as string,
-   * otherwise and empty string is returned.
+   * otherwise an empty string is returned.
    *
-   * On Windows the *cmd* string must not include and extension as
+   * On Windows the *cmd* string must not include an extension as
    * this function will automatically append the extensions ".exe",
    * ".com" and ".bat" and look for those paths. On Windows also the
-   * current directory is checked (and first), while otherwise not unless
+   * current directory is checked (and first), but otherwise is not checked
-   * "." exists in the PATH environment variable.
+   * unless "." exists in the PATH environment variable.
    *
    * Because of the nature of the check, this will not detect shell functions
    * built-in command or aliases.
@@ -274,7 +274,7 @@ namespace platform {
    *
    * Unlike the the ``mkdir()`` or ``_mkdir()`` functions of the
    * C library, this function will also try to create non-existing sub-directories
-   * in case they don't exist, and thus behave like the ``mkdir -p`` command rather
+   * in case they don't exist, and thus behaves like the ``mkdir -p`` command rather
    * than plain ``mkdir`` or ``md`.
    *
    * \param  path  directory path
@@ -286,7 +286,7 @@ namespace platform {
    *
    * Unlike the the ``rmdir()`` or ``_rmdir()`` functions of the
    * C library, this function will check for the contents of the
-   * folder and recurse into any sub-folders, if necessary and
+   * folder and recurse into any sub-folders, if necessary, and
    * delete all contained folders and their contents before
    * deleting the folder *path*.
    *

src/potential_file_reader.cpp

@@ -134,7 +134,7 @@ char *PotentialFileReader::next_line(int nparams)
  *
  * This reads lines from the file using the next_line() function,
  * and splits them into floating-point numbers using the
- * ValueTokenizer class and stores the number is the provided list.
+ * ValueTokenizer class and stores the number in the provided list.
  *
  * \param  list  Pointer to array with suitable storage for *n* doubles
  * \param  n     Number of doubles to be read */
@@ -154,7 +154,7 @@ void PotentialFileReader::next_dvector(double *list, int n)
  *
  * This reads lines from the file using the next_line() function,
  * and splits them into floating-point numbers using the
- * ValueTokenizer class and stores the number is the provided list.
+ * ValueTokenizer class and stores the number in the provided list.
  *
  * \param   nparams     Number of words to be read
  * \param   separators  String with list of separators.

src/text_file_reader.cpp

@@ -177,7 +177,7 @@ char *TextFileReader::next_line(int nparams)
  *
  * This reads lines from the file using the next_line() function,
  * and splits them into floating-point numbers using the
- * ValueTokenizer class and stores the number is the provided list.
+ * ValueTokenizer class and stores the number in the provided list.
  *
  * \param  list  Pointer to array with suitable storage for *n* doubles
  * \param  n     Number of doubles to be read */
@@ -206,7 +206,7 @@ void TextFileReader::next_dvector(double *list, int n)
  *
  * This reads lines from the file using the next_line() function,
  * and splits them into floating-point numbers using the
- * ValueTokenizer class and stores the number is the provided list.
+ * ValueTokenizer class and stores the number in the provided list.
  *
  * \param   nparams     Number of words to be read
  * \param   separators  String with list of separators.

src/utils.h

@@ -87,7 +87,7 @@ namespace utils {
 
   /*! Return text redirecting the user to a specific paragraph in the manual
    *
-   * The LAMMPS manual contains detailed detailed explanations for errors and
+   * The LAMMPS manual contains detailed explanations for errors and
    * warnings where a simple error message may not be sufficient.  These can
    * be reached through URLs with a numeric code.  This function creates the
    * corresponding text to be included into the error message that redirects
@@ -391,7 +391,7 @@ This functions adds the following case to :cpp:func:`utils::bounds() <LAMMPS_NS:
    *
    *  This function checks if a given string may be a type label and
    *  then searches the labelmap type indicated by the *mode* argument
-   *  for the corresponding numeric type.  If this is found a copy of
+   *  for the corresponding numeric type.  If this is found, a copy of
    *  the numeric type string is made and returned. Otherwise a null
    *  pointer is returned.
    *  If a string is returned, the calling code must free it with delete[].
@@ -436,8 +436,8 @@ This functions adds the following case to :cpp:func:`utils::bounds() <LAMMPS_NS:
 
   /*! Parse grid reference into 3 sub-strings
    *
-   * Format of grid ID reference = id:gname:dname
+   * Format of grid ID reference = id:gname:dname.
-   * Return vector with the 3 sub-strings
+   * Return vector with the 3 sub-strings.
    *
    * \param name = complete grid ID
    * \return std::vector<std::string> containing the 3 sub-strings  */