Edits to devleoper doc files 2
This commit is contained in:
jtclemm
@ -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.
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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,
|
||||
|
||||
@ -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*
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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.)
|
||||
|
||||
@ -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 */
|
||||
|
||||
@ -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*.
|
||||
*
|
||||
|
||||
@ -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. */
|
||||
|
||||
|
||||
@ -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*.
|
||||
*
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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 */
|
||||
|
||||
Reference in New Issue
Block a user