ICODE-ADC/lammps
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge branch 'doc-updates' of https://github.com/jtclemm/lammps into collected-small-fixes

Browse Source
This commit is contained in:
Axel Kohlmeyer
2024-08-16 16:34:30 -04:00
parent a2fa7d68d7 15127ad2e2
commit b6b2cc0667
41 changed files with 173 additions and 201 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
doc/src/Developer_atom.rst
View File

@ -2,7 +2,7 @@ Accessing per-atom data
-----------------------
This page discusses how per-atom data is managed in LAMMPS, how it can
be accessed, what communication patters apply, and some of the utility
be accessed, what communication patterns apply, and some of the utility
functions that exist for a variety of purposes.
@ -14,11 +14,11 @@ As described on the :doc:`parallel partitioning algorithms
simulation domain, either in a *brick* or *tiled* manner. Each MPI
process *owns* exactly one subdomain and the atoms within it. To compute
forces for tuples of atoms that are spread across sub-domain boundaries,
also a "halo" of *ghost* atoms are maintained within a the communication
also a "halo" of *ghost* atoms are maintained within the communication
cutoff distance of its subdomain.
The total number of atoms is stored in `Atom::natoms` (within any
typical class this can be referred to at `atom->natoms`. The number of
typical class this can be referred to at `atom->natoms`). The number of
*owned* (or "local" atoms) are stored in `Atom::nlocal`; the number of
*ghost* atoms is stored in `Atom::nghost`. The sum of `Atom::nlocal`
over all MPI processes should be `Atom::natoms`. This is by default
@ -27,8 +27,8 @@ LAMMPS stops with a "lost atoms" error. For convenience also the
property `Atom::nmax` is available, this is the maximum of
`Atom::nlocal + Atom::nghost` across all MPI processes.
Per-atom properties are either managed by the atom style, or individual
classes. or as custom arrays by the individual classes. If only access
Per-atom properties are either managed by the atom style, individual
classes, or as custom arrays by the individual classes. If only access
to *owned* atoms is needed, they are usually allocated to be of size
`Atom::nlocal`, otherwise of size `Atom::nmax`. Please note that not all
per-atom properties are available or updated on *ghost* atoms. For
@ -61,7 +61,7 @@ can be found via the `Atom::sametag` array. It points to the next atom
index with the same tag or -1 if there are no more atoms with the same
tag. The list will be exhaustive when starting with an index of an
*owned* atom, since the atom IDs are unique, so there can only be one
such atom. Example code to count atoms with same atom ID in subdomain:
such atom. Example code to count atoms with same atom ID in a subdomain:
.. code-block:: c++

9
doc/src/Developer_code_design.rst
View File

@ -69,7 +69,7 @@ The basic LAMMPS class hierarchy which is created by the LAMMPS class
constructor is shown in :ref:`class-topology`. When input commands
are processed, additional class instances are created, or deleted, or
replaced. Likewise, specific member functions of specific classes are
called to trigger actions such creating atoms, computing forces,
called to trigger actions such as creating atoms, computing forces,
computing properties, time-propagating the system, or writing output.
Compositing and Inheritance
@ -110,9 +110,10 @@ As mentioned above, there can be multiple instances of classes derived
from the ``Fix`` or ``Compute`` base classes. They represent a
different facet of LAMMPS' flexibility, as they provide methods which
can be called at different points within a timestep, as explained in
`Developer_flow`. This allows the input script to tailor how a specific
simulation is run, what diagnostic computations are performed, and how
the output of those computations is further processed or output.
the :doc:`How a timestep works <Developer_flow>` doc page. This allows
the input script to tailor how a specific simulation is run, what
diagnostic computations are performed, and how the output of those
computations is further processed or output.
Additional code sharing is possible by creating derived classes from the
derived classes (e.g., to implement an accelerated version of a pair

2
doc/src/Developer_flow.rst
View File

@ -128,7 +128,7 @@ reflect particles off box boundaries in the :doc:`FixWallReflect class
The ``decide()`` method in the Neighbor class determines whether
neighbor lists need to be rebuilt on the current timestep (conditions
can be changed using the :doc:`neigh_modify every/delay/check
<neigh_modify>` command. If not, coordinates of ghost atoms are
<neigh_modify>` command). If not, coordinates of ghost atoms are
acquired by each processor via the ``forward_comm()`` method of the Comm
class. If neighbor lists need to be built, several operations within
the inner if clause of the pseudocode are first invoked. The

33
doc/src/Developer_notes.rst
View File

@ -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
request flag is needed. The :doc:`tersoff <pair_tersoff>` pair style,
for example, needs a "full" neighbor list:
neighbor list request to the specific needs of a style. The :doc:`tersoff
<pair_tersoff>` pair style, 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
from pair style lj/cut:
the request flag may depend on the corresponding r-RESPA settings. Here is an
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
the Modify class, which calls the compute_scalar() method of each
*ecouple_flag* = 1 fixes by invoking the *energy_couple()* method in
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
nxlo_fft,nxhi_fft,nylo_fft,nyhi_fft,nzlo_fft,nzhi_fft = FFT decomposition brick
nxlo_out,nxhi_out,nylo_out,nyhi_out,nzlo_out,nzhi_out = 3d decomposition brick + ghost cells
nFOO_in = 3d decomposition brick
nFOO_fft = FFT decomposition brick
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.

5
doc/src/Developer_par_comm.rst
View File

@ -4,8 +4,7 @@ Communication
Following the selected partitioning scheme, all per-atom data is
distributed across the MPI processes, which allows LAMMPS to handle very
large systems provided it uses a correspondingly large number of MPI
processes. Since The per-atom data (atom IDs, positions, velocities,
types, etc.) To be able to compute the short-range interactions, MPI
processes. To be able to compute the short-range interactions, MPI
processes need not only access to the data of atoms they "own" but also
information about atoms from neighboring subdomains, in LAMMPS referred
to as "ghost" atoms. These are copies of atoms storing required
@ -37,7 +36,7 @@ be larger than half the simulation domain.
Efficient communication patterns are needed to update the "ghost" atom
data, since that needs to be done at every MD time step or minimization
step. The diagrams of the `ghost-atom-comm` figure illustrate how ghost
step. The diagrams of the :ref:`ghost-atom-comm` figure illustrate how ghost
atom communication is performed in two stages for a 2d simulation (three
in 3d) for both a regular and irregular partitioning of the simulation
box. For the regular case (left) atoms are exchanged first in the

4
doc/src/Developer_par_long.rst
View File

@ -93,7 +93,7 @@ processors, since each tile in the initial tiling overlaps with a
handful of tiles in the final tiling.
The transformations could also be done using collective communication
across all $P$ processors with a single call to ``MPI_Alltoall()``, but
across all :math:`P` processors with a single call to ``MPI_Alltoall()``, but
this is typically much slower. However, for the specialized brick and
pencil tiling illustrated in :ref:`fft-parallel` figure, collective
communication across the entire MPI communicator is not required. In
@ -138,7 +138,7 @@ grid/particle operations that LAMMPS supports:
:math:`O(P^{\frac{1}{2}})`.
- For efficiency in performing 1d FFTs, the grid transpose
operations illustrated in Figure \ref{fig:fft} also involve
operations illustrated in Figure :ref:`fft-parallel` also involve
reordering the 3d data so that a different dimension is contiguous
in memory. This reordering can be done during the packing or
unpacking of buffers for MPI communication.

2
doc/src/Developer_par_neigh.rst
View File

@ -149,7 +149,7 @@ supports:
- Dependent on the "pair" setting of the :doc:`newton <newton>` command,
the "half" neighbor lists may contain **all** pairs of atoms where
atom *j* is a ghost atom (i.e. when the newton pair setting is *off*)
atom *j* is a ghost atom (i.e. when the newton pair setting is *off*).
For the newton pair *on* setting the atom *j* is only added to the
list if its *z* coordinate is larger, or if equal the *y* coordinate
is larger, and that is equal, too, the *x* coordinate is larger. For

6
doc/src/Developer_par_openmp.rst
View File

@ -1,13 +1,13 @@
OpenMP Parallelism
^^^^^^^^^^^^^^^^^^
The styles in the INTEL, KOKKOS, and OPENMP package offer to use OpenMP
The styles in the INTEL, KOKKOS, and OPENMP packages offer to use OpenMP
thread parallelism to predominantly distribute loops over local data
and thus follow an orthogonal parallelization strategy to the
decomposition into spatial domains used by the :doc:`MPI partitioning
<Developer_par_part>`. For clarity, this section discusses only the
implementation in the OPENMP package, as it is the simplest. The INTEL
and KOKKOS package offer additional options and are more complex since
and KOKKOS packages offer additional options and are more complex since
they support more features and different hardware like co-processors
or GPUs.
@ -16,7 +16,7 @@ keep the changes to the source code small, so that it would be easier to
maintain the code and keep it in sync with the non-threaded standard
implementation. This is achieved by a) making the OPENMP version a
derived class from the regular version (e.g. ``PairLJCutOMP`` from
``PairLJCut``) and overriding only methods that are multi-threaded or
``PairLJCut``) and only overriding methods that are multi-threaded or
need to be modified to support multi-threading (similar to what was done
in the OPT package), b) keeping the structure in the modified code very
similar so that side-by-side comparisons are still useful, and c)

4
doc/src/Developer_plugins.rst
View File

@ -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

29
doc/src/Developer_unittest.rst
View File

@ -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
for utility functions and for LAMMPS commands, but use the functions
``unittest/c-library`` folder. They are implemented either to be used
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
rule of thumb, the test epsilon can often be in the range 5.0e-14 to
1.0e-13. But for "noisy" force kernels, e.g. those a larger amount of
arithmetic operations involving `exp()`, `log()` or `sin()` functions,
and also due to the effect of compiler optimization or differences
errors. As a rule of thumb, the test epsilon can often be in the range
5.0e-14 to 1.0e-13. But for "noisy" force kernels, e.g. those a larger
amount of arithmetic operations involving `exp()`, `log()` or `sin()`
functions, 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.

19
doc/src/Developer_updating.rst
View File

@ -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
and to unpack data from communication buffers for :doc:`forward
communications <Developer_comm_ops>` were renamed from ``pack_comm()``
and ``unpack_comm()`` to ``pack_forward_comm()`` and
In this change set, the functions to pack/unpack data into communication buffers
for :doc:`forward communications <Developer_comm_ops>` were renamed from
``pack_comm()`` 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.

2
doc/src/Developer_utils.rst
View File

@ -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.

19
doc/src/Developer_write_fix.rst
View File

@ -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
important available methods that are called during a timestep.
``END_OF_STEP`` corresponds to the ``end_of_step()`` method.
.. 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
and atom j owns a body, move the body information to atom i.
information to j-th particle position. Used when atom sorting is performed.
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
``restart_global = 1`` in the constructor and implementing methods void
``write_restart(FILE *fp)`` and ``void restart(char *buf)``.
your fix to the restart file, you might do it by setting the flag
``restart_global = 1`` in the constructor and implementing methods
``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

19
doc/src/Developer_write_pair.rst
View File

@ -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
explicitly set are allocated and, if needed, initialized. In this case,
the memory allocation and initialization is moved to a function
parameters, to define cutoffs, track which pairs of parameters have been
explicitly set and allocated and, if needed, initialized. In this case,
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
of neighbor (= 0) or a pair of 1-2 (= 1), 1-3 (= 2), or 1-4 (= 3)
:doc:`"special" neighbor <special_bonds>`. The ``sbmask()`` inline
function extracts those bits and converts them into a number. This
number is used to look up the corresponding scaling factor for the
list code encodes extra information using the upper 3 bits. The 2 highest
bits encode whether a pair is a regular pair of neighbor (= 0) or a pair
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
data in :doc:`fix neigh/history <fix_neigh_history`. The ``sbmask()``
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,

5
doc/src/Howto_rheo.rst
View File

@ -15,7 +15,6 @@ details of the system, or develop new capabilities. For instance, the numerics
associated with calculating gradients, reproducing kernels, etc. are separated
into distinct classes to simplify the development of new integration schemes
which can call these calculations. Additional numerical details can be found in
:ref:`(Palermo) <howto_rheo_palermo>` and
:ref:`(Clemmer) <howto_rheo_clemmer>`.
Note, if you simply want to run a traditional SPH simulation, the :ref:`SPH package
@ -107,10 +106,6 @@ criteria for creating/deleting a bond or altering force calculations).
----------
.. _howto_rheo_palermo:
**(Palermo)** Palermo, Wolf, Clemmer, O'Connor, in preparation.
.. _howto_rheo_clemmer:
**(Clemmer)** Clemmer, Pierce, O'Connor, Nevins, Jones, Lechman, Tencer, Appl. Math. Model., 130, 310-326 (2024).

2
doc/src/Modify_atom.rst
View File

@ -96,7 +96,7 @@ methods that a new variable name or flag needs to be added to.
In ``Atom::peratom_create()`` when using the ``Atom::add_peratom()``
method, a cols argument of 0 is for per-atom vectors, a length >
1 is for per-atom arrays. Note the use of the extra per-thread flag and
the add_peratom_vary() method when last dimension of the array is
the add_peratom_vary() method when the last dimension of the array is
variable-length.
Adding the variable name to Atom::extract() enables the per-atom data

2
doc/src/Modify_contribute.rst
View File

@ -1,7 +1,7 @@
Submitting new features for inclusion in LAMMPS
===============================================
We encourage LAMMPS users to submit new features they wrote for LAMMPS
We encourage LAMMPS users to submit new features they write for LAMMPS
to be included in the LAMMPS distribution and thus become easily
accessible to all LAMMPS users. The LAMMPS source code is managed
with git and public development is hosted on `GitHub

39
doc/src/Modify_gran_sub_mod.rst
View File

@ -65,37 +65,28 @@ need to be defined
.. list-table::
* - ``GranSubMod->mix_coeff()``
* - ``mix_coeff()``
- Optional method to define how coefficients are mixed for different atom types. By default, coefficients are mixed using a geometric mean.
* - ``GranSubMod->coeffs_to_local()``
* - ``coeffs_to_local()``
- Parses coefficients to define local variables. Run once at model construction.
* - ``GranSubMod->init()``
* - ``init()``
- Optional method to define local variables after other GranSubMod types were created. For instance, this method may be used by a tangential model that derives parameters from the normal model.
There are also several type-specific methods
The Normal, Damping, Tangential, Twisting, and Rolling sub-models also have a
``calculate_forces()`` method which calculate the respective forces/torques.
Correspondingly, the Heat sub-model has a ``calculate_heat()`` method. Lastly,
the Normal sub-model has a few extra optional methods:
.. list-table::
* - ``GranSubModNormal->touch()``
- Optional method to test when particles are in contact. By default, this is when particles overlap.
* - ``GranSubModNormal->pulloff_distance()``
- Optional method to return the distance at which particles stop interacting. By default, this is when particles no longer overlap.
* - ``GranSubModNormal->calculate_radius()``
- Optional method to return the radius of the contact. By default, this returns the radius of the geometric cross section.
* - ``GranSubModNormal->set_fncrit()``
- Optional method that defines the critical force to break the contact used by some tangential, rolling, and twisting sub-models. By default, this is the current total normal force including damping.
* - ``GranSubModNormal->calculate_forces()``
- Required method that returns the normal contact force
* - ``GranSubModDamping->calculate_forces()``
- Required method that returns the normal damping force
* - ``GranSubModTangential->calculate_forces()``
- Required method that calculates tangential forces/torques
* - ``GranSubModTwisting->calculate_forces()``
- Required method that calculates twisting friction forces/torques
* - ``GranSubModRolling->calculate_forces()``
- Required method that calculates rolling friction forces/torques
* - ``GranSubModHeat->calculate_heat()``
- Required method that returns the rate of heat flow
* - ``touch()``
- Tests whether particles are in contact. By default, when particles overlap.
* - ``pulloff_distance()``
- Returns the distance at which particles stop interacting. By default, when particles no longer overlap.
* - ``calculate_radius()``
- Returns the radius of the contact. By default, the radius of the geometric cross section.
* - ``set_fncrit()``
- Defines the critical force to break the contact used by some tangential, rolling, and twisting sub-models. By default, the current total normal force including damping.
As an example, say one wanted to create a new normal force option that consisted
of a Hookean force with a piecewise stiffness. This could be done by adding a new

6
doc/src/Modify_overview.rst
View File

@ -12,8 +12,8 @@ programming style choices in LAMMPS is :doc:`given elsewhere
<Developer_code_design>`.
Most of the new features described on the :doc:`Modify <Modify>` doc
page require you to write a new C++ derived class (except for
exceptions described below, where you can make small edits to existing
page require you to write a new C++ derived class (excluding exceptions
described below, this can often be done by making small edits to existing
files). Creating a new class requires 2 files, a source code file
(\*.cpp) and a header file (\*.h). The derived class must provide
certain methods to work as a new option. Depending on how different
@ -46,7 +46,7 @@ then your ``pair_foo.h`` file should be structured as follows:
// clang-format off
PairStyle(foo,PairFoo);
#else
// clanf-format on
// clang-format on
...
(class definition for PairFoo)
...

2
doc/src/Modify_requirements.rst
View File

@ -184,7 +184,7 @@ package so that it is optional.
Included Fortran code has to be compatible with the Fortran 2003
standard. Since not all platforms supported by LAMMPS provide good
support for compiling Fortran files, it should be considered to rewrite
these parts as C++ code, if possible and thus allow for a wider adoption
these parts as C++ code, if possible, and thus allow for a wider adoption
of the contribution. As of January 2023, all previously included
Fortran code for the LAMMPS executable has been replaced by equivalent
C++ code.

2
doc/src/Modify_thermo.rst
View File

@ -14,7 +14,7 @@ style, but can be adapted using :doc:`thermo_modify line <thermo_modify>`.
The thermo styles (one, multi, etc) are defined by lists of keywords
with associated formats for integer and floating point numbers and
identified but an enumerator constant. Adding a new style thus mostly
identified by an enumerator constant. Adding a new style thus mostly
requires defining a new list of keywords and the associated formats and
then inserting the required output processing where the enumerators are
identified. Search for the word "CUSTOMIZATION" with references to

2
doc/src/Python_error.rst
View File

@ -16,7 +16,7 @@ can be handled through the Python exception handling mechanism.
try:
# LAMMPS will normally terminate itself and the running process if an error
# occurs. This would kill the Python interpreter. The library wrapper will
# detect that an error has occured and throw a Python exception
# detect that an error has occurred and throw a Python exception
lmp.command('unknown')
except MPIAbortException as ae:

8
doc/src/Python_neighbor.rst
View File

@ -2,7 +2,7 @@ Neighbor list access
====================
Access to neighbor lists is handled through a couple of wrapper classes
that allows to treat it like either a python list or a NumPy array. The
that allows one to treat it like either a python list or a NumPy array. The
access procedure is similar to that of the C-library interface: use one
of the "find" functions to look up the index of the neighbor list in the
global table of neighbor lists and then get access to the neighbor list
@ -79,11 +79,11 @@ potential is shown below.
* :py:meth:`lammps.get_neighlist_element_neighbors()`: Get element in neighbor list and its neighbors
* :py:meth:`lammps.find_pair_neighlist() <lammps.lammps.find_pair_neighlist()>`: Find neighbor list of pair style
* :py:meth:`lammps.find_fix_neighlist() <lammps.lammps.find_pair_neighlist()>`: Find neighbor list of pair style
* :py:meth:`lammps.find_compute_neighlist() <lammps.lammps.find_pair_neighlist()>`: Find neighbor list of pair style
* :py:meth:`lammps.find_fix_neighlist() <lammps.lammps.find_pair_neighlist()>`: Find neighbor list of fix style
* :py:meth:`lammps.find_compute_neighlist() <lammps.lammps.find_pair_neighlist()>`: Find neighbor list of compute style
**NumPy Methods:**
* :py:meth:`lammps.numpy.get_neighlist() <lammps.numpy_wrapper.numpy_wrapper.get_neighlist()>`: Get neighbor list for given index, which uses NumPy arrays for its element neighbor arrays
* :py:meth:`lammps.numpy.get_neighlist_element_neighbors() <lammps.numpy_wrapper.numpy_wrapper.get_neighlist_element_neighbors()>`: Get element in neighbor list and its neighbors (as numpy array)
* :py:meth:`lammps.numpy.get_neighlist_element_neighbors() <lammps.numpy_wrapper.numpy_wrapper.get_neighlist_element_neighbors()>`: Get element in neighbor list and its neighbors (as a numpy array)

24
doc/src/Python_scatter.rst
View File

@ -23,20 +23,22 @@ passed by all calling processors, to individual atoms, which may be
owned by different processors.
Note that the data returned by the gather methods,
e.g. gather_atoms("x"), is different from the data structure returned
by extract_atom("x") in four ways. (1) Gather_atoms() returns a
vector which you index as x[i]; extract_atom() returns an array
which you index as x[i][j]. (2) Gather_atoms() orders the atoms
by atom ID while extract_atom() does not. (3) Gather_atoms() returns
a list of all atoms in the simulation; extract_atoms() returns just
the atoms local to each processor. (4) Finally, the gather_atoms()
e.g. :py:meth:`gather_atoms("x") <lammps.lammps.gather_atoms()>`, is
different from the data structure returned by
:py:meth:`extract_atom("x") <lammps.lammps.extract_atom()>` in four ways.
(1) :code:`gather_atoms()` returns a vector which you index as x[i];
:code:`extract_atom()` returns an array which you index as x[i][j].
(2) :code:`gather_atoms()` orders the atoms by atom ID while
:code:`extract_atom()` does not. (3) :code:`gather_atoms()` returns
a list of all atoms in the simulation; :code:`extract_atoms()` returns just
the atoms local to each processor. (4) Finally, the :code:`gather_atoms()`
data structure is a copy of the atom coords stored internally in
LAMMPS, whereas extract_atom() returns an array that effectively
LAMMPS, whereas :code:`extract_atom()` returns an array that effectively
points directly to the internal data. This means you can change
values inside LAMMPS from Python by assigning a new values to the
extract_atom() array. To do this with the gather_atoms() vector, you
need to change values in the vector, then invoke the scatter_atoms()
method.
:code:`extract_atom()` array. To do this with the :code:`gather_atoms()` vector, you
need to change values in the vector, then invoke the
:py:meth:`scatter_atoms("x") <lammps.lammps.scatter_atoms()>` method.
For the scatter methods, the array of coordinates passed to must be a
ctypes vector of ints or doubles, allocated and initialized something

6
doc/src/create_atoms.rst
View File

@ -182,9 +182,9 @@ a simulation box which replicates that unit cell along each of the
well as the atoms created by this command with their per-atom
information (e.g. coordinates, velocities) are converted (rotated)
from general to restricted triclinic form when the two commands are
invoked. The <Howto_triclinic>` doc page also discusses other
LAMMPS commands which can input/output general triclinic
representations of the simulation box and per-atom data.
invoked. The :doc:`Howto_triclinic <Howto_triclinic>` doc page also
discusses other LAMMPS commands which can input/output general
triclinic representations of the simulation box and per-atom data.
The *box* style will fill the entire general triclinic box with
particles on the lattice, as explained above.

2
doc/src/create_box.rst
View File

@ -13,7 +13,7 @@ Syntax
* N = # of atom types to use in this simulation
* region-ID = ID of region to use as simulation domain or NULL for general triclinic box
* alo,ahi,blo,bhi,clo,chi = multipliers on a1,a2,a3 vectors defined by :doc"`lattice <lattice>` command (only when region-ID = NULL)
* alo,ahi,blo,bhi,clo,chi = multipliers on a1,a2,a3 vectors defined by :doc:`lattice <lattice>` command (only when region-ID = NULL)
* zero or more keyword/value pairs may be appended
* keyword = *bond/types* or *angle/types* or *dihedral/types* or *improper/types* or *extra/bond/per/atom* or *extra/angle/per/atom* or *extra/dihedral/per/atom* or *extra/improper/per/atom* or *extra/special/per/atom*

17
doc/src/fix_rheo.rst
View File

@ -47,10 +47,8 @@ Description
.. versionadded:: TBD
Perform time integration for RHEO particles, updating positions, velocities,
and densities. For a detailed breakdown of the integration timestep and
numerical details, see :ref:`(Palermo) <rheo_palermo>`. For an
overview of other features available in the RHEO package, see
:doc:`the RHEO howto <Howto_rheo>`.
and densities. For an overview of other features available in the RHEO package,
see :doc:`the RHEO howto <Howto_rheo>`.
The type of kernel is specified using *kstyle* and the cutoff is *cut*. Four
kernels are currently available. The *quintic* kernel is a standard quintic
@ -73,12 +71,7 @@ and velocity of solid particles are alternatively reconstructed for every
fluid-solid interaction to ensure no-slip and pressure-balanced boundaries.
This is done by estimating the location of the fluid-solid interface and
extrapolating fluid particle properties across the interface to calculate a
temporary apparent density and velocity for a solid particle. The numerical
details are the same as those described in
:ref:`(Palermo) <howto_rheo_palermo>` except there is an additional
restriction that the reconstructed solid density cannot be less than the
equilibrium density. This prevents fluid particles from sticking to solid
surfaces.
temporary apparent density and velocity for a solid particle.
A modified form of Fickian particle shifting can be enabled with the
*shift* keyword. This effectively shifts particle positions to generate a
@ -171,10 +164,6 @@ Default
----------
.. _rheo_palermo:
**(Palermo)** Palermo, Wolf, Clemmer, O'Connor, in preparation.
.. _fix_rheo_hu:
**(Hu)** Hu, and Adams J. Comp. Physics, 213, 844-861 (2006).

6
doc/src/fix_rheo_viscosity.rst
View File

@ -72,8 +72,6 @@ is assigned. This implies a value of
.. math::
\tau_0 = \eta \dot{\gamma}_0 - K \dot{\gamma}_0^N
as further discussed in :ref:`(Palermo) <rheo_palermo2>`.
Restart, fix_modify, output, run start/stop, minimize info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
@ -111,7 +109,3 @@ Default
none
----------
.. _rheo_palermo2:
**(Palermo)** Palermo, Wolf, Clemmer, O'Connor, in preparation.

2
python/lammps/core.py
View File

@ -2067,7 +2067,7 @@ class lammps(object):
""" List of the names of enabled packages in the LAMMPS shared library
This is a wrapper around the functions :cpp:func:`lammps_config_package_count`
and :cpp:func`lammps_config_package_name` of the library interface.
and :cpp:func:`lammps_config_package_name` of the library interface.
:return
"""

16
python/lammps/numpy_wrapper.py
View File

@ -271,11 +271,11 @@ class numpy_wrapper:
# -------------------------------------------------------------------------
def gather_bonds(self):
"""Retrieve global list of bonds as NumPy array
"""Retrieve global list of bonds as a NumPy array
.. versionadded:: 28Jul2021
This is a wrapper around :py:meth:`lammps.gather_bonds() <lammps.lammps.gather_bonds()>`
This is a wrapper around :py:meth:`lammps.gather_bonds() <lammps.lammps.gather_bonds()>`.
It behaves the same as the original method, but returns a NumPy array instead
of a ``ctypes`` list.
@ -289,11 +289,11 @@ class numpy_wrapper:
# -------------------------------------------------------------------------
def gather_angles(self):
""" Retrieve global list of angles as NumPy array
""" Retrieve global list of angles as a NumPy array
.. versionadded:: 8Feb2023
This is a wrapper around :py:meth:`lammps.gather_angles() <lammps.lammps.gather_angles()>`
This is a wrapper around :py:meth:`lammps.gather_angles() <lammps.lammps.gather_angles()>`.
It behaves the same as the original method, but returns a NumPy array instead
of a ``ctypes`` list.
@ -307,11 +307,11 @@ class numpy_wrapper:
# -------------------------------------------------------------------------
def gather_dihedrals(self):
""" Retrieve global list of dihedrals as NumPy array
""" Retrieve global list of dihedrals as a NumPy array
.. versionadded:: 8Feb2023
This is a wrapper around :py:meth:`lammps.gather_dihedrals() <lammps.lammps.gather_dihedrals()>`
This is a wrapper around :py:meth:`lammps.gather_dihedrals() <lammps.lammps.gather_dihedrals()>`.
It behaves the same as the original method, but returns a NumPy array instead
of a ``ctypes`` list.
@ -325,11 +325,11 @@ class numpy_wrapper:
# -------------------------------------------------------------------------
def gather_impropers(self):
""" Retrieve global list of impropers as NumPy array
""" Retrieve global list of impropers as a NumPy array
.. versionadded:: 8Feb2023
This is a wrapper around :py:meth:`lammps.gather_impropers() <lammps.lammps.gather_impropers()>`
This is a wrapper around :py:meth:`lammps.gather_impropers() <lammps.lammps.gather_impropers()>`.
It behaves the same as the original method, but returns a NumPy array instead
of a ``ctypes`` list.

8
python/lammps/pylammps.py
View File

@ -358,6 +358,7 @@ class Atom2D(Atom):
@property
def velocity(self):
"""Access to velocity of an atom
:getter: Return velocity of atom
:setter: Set velocity of atom
:type: numpy.array (float, float)
@ -372,6 +373,7 @@ class Atom2D(Atom):
@property
def force(self):
"""Access to force of an atom
:getter: Return force of atom
:setter: Set force of atom
:type: numpy.array (float, float)
@ -418,7 +420,7 @@ class PyLammps(object):
"""
This is a Python wrapper class around the lower-level
:py:class:`lammps` class, exposing a more Python-like,
object-oriented interface for prototyping system inside of IPython and
object-oriented interface for prototyping systems inside of IPython and
Jupyter notebooks.
It either creates its own instance of :py:class:`lammps` or can be
@ -556,7 +558,7 @@ class PyLammps(object):
Commands will be added to the command history but not executed.
Add `commands` only to the command history, but do not execute them, so that you can
conveniently create Lammps input files, using
conveniently create LAMMPS input files, using
:py:meth:`PyLammps.write_script()`.
"""
self._cmd_history.append(cmd)
@ -908,7 +910,7 @@ class PyLammps(object):
class IPyLammps(PyLammps):
"""
IPython wrapper for LAMMPS which adds embedded graphics capabilities to PyLammmps interface
IPython wrapper for LAMMPS which adds embedded graphics capabilities to PyLammps interface
It either creates its own instance of :py:class:`lammps` or can be
initialized with an existing instance. The arguments are the same of the

8
src/atom.cpp
View File

@ -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*

6
src/input.cpp
View File

@ -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
file pointer stored in *infile* on a stack and instead assign *infile*
This function opens the file at the path *filename*, puts the current
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

2
src/lammps.cpp
View File

@ -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.)

6
src/my_page.cpp
View File

@ -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 */

2
src/my_page.h
View File

@ -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*.
*

2
src/my_pool_chunk.cpp
View File

@ -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. */

18
src/platform.h
View File

@ -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
* "." exists in the PATH environment variable.
* current directory is checked (and first), but otherwise is not checked
* 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*.
*

4
src/potential_file_reader.cpp
View File

@ -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.

4
src/text_file_reader.cpp
View File

@ -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.

8
src/utils.h
View File

@ -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
* Return vector with the 3 sub-strings
* Format of grid ID reference = id:gname:dname.
* Return vector with the 3 sub-strings.
*
* \param name = complete grid ID
* \return std::vector<std::string> containing the 3 sub-strings */