diff --git a/doc/src/Developer_notes.rst b/doc/src/Developer_notes.rst index 9f950dda8a..af26b4b913 100644 --- a/doc/src/Developer_notes.rst +++ b/doc/src/Developer_notes.rst @@ -20,7 +20,7 @@ Available topics are: Reading and parsing of text and text files ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -It is frequently required for a class in LAMMPS to read in additional +Classes in LAMMPS frequently need to read in additional data from a file, e.g. potential parameters from a potential file for manybody potentials. LAMMPS provides several custom classes and convenience functions to simplify the process. They offer the @@ -128,9 +128,8 @@ that determines the kind of neighbor list requested. The default value used here asks for a perpetual "half" neighbor list. Non-default values of the second argument need to be used to adjust a -neighbor list request to the specific needs of a style an additional -request flag is needed. The :doc:`tersoff ` pair style, -for example, needs a "full" neighbor list: +neighbor list request to the specific needs of a style. The :doc:`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 `: @@ -279,8 +278,8 @@ And here is how the code operates: * The :doc:`thermo_style custom ` 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. diff --git a/doc/src/Developer_plugins.rst b/doc/src/Developer_plugins.rst index dd5431507e..d00982dc63 100644 --- a/doc/src/Developer_plugins.rst +++ b/doc/src/Developer_plugins.rst @@ -135,7 +135,7 @@ unique inside the entire LAMMPS executable. Fix style example ^^^^^^^^^^^^^^^^^ -If the factory function would be for a fix or compute, which take three +If the factory function is for a fix or compute, which take three arguments (a pointer to the LAMMPS class, the number of arguments and the list of argument strings), then the pointer type is ``lammpsplugin_factory2`` and it must be assigned to the *creator.v2* member of the plugin struct. @@ -271,7 +271,7 @@ Plugins need to be compiled with the same compilers and libraries as the LAMMPS executable and library. Otherwise the plugin will likely not load due to mismatches in the function signatures (LAMMPS is C++ so scope, type, and number of arguments are encoded into the symbol names -and thus differences in them will lead to failed plugin load commands. +and thus differences in them will lead to failed plugin load commands). Compilation of the plugin can be managed via both, CMake or traditional GNU makefiles. Some examples that can be used as a template are in the ``examples/plugins`` folder. The CMake script code has some small diff --git a/doc/src/Developer_unittest.rst b/doc/src/Developer_unittest.rst index b48c3b4e17..96144b087d 100644 --- a/doc/src/Developer_unittest.rst +++ b/doc/src/Developer_unittest.rst @@ -227,12 +227,12 @@ Tests for the C-style library interface ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Tests for validating the LAMMPS C-style library interface are in the -``unittest/c-library`` folder. They are implemented in either way used -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 `. 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. diff --git a/doc/src/Developer_updating.rst b/doc/src/Developer_updating.rst index 83491ac095..f2aa60d6ae 100644 --- a/doc/src/Developer_updating.rst +++ b/doc/src/Developer_updating.rst @@ -52,10 +52,9 @@ Rename of pack/unpack_comm() to pack/unpack_forward_comm() .. versionchanged:: 8Aug2014 -In this change set the functions to pack data into communication buffers -and to unpack data from communication buffers for :doc:`forward -communications ` 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 ` 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. diff --git a/doc/src/Developer_utils.rst b/doc/src/Developer_utils.rst index 2923e5b29c..b7f62d5364 100644 --- a/doc/src/Developer_utils.rst +++ b/doc/src/Developer_utils.rst @@ -622,7 +622,7 @@ classes: of a dense, symmetric, real matrix. #. The "PEigenDense" class only calculates the principal eigenvalue - (ie. the largest or smallest eigenvalue), and its corresponding + (i.e. the largest or smallest eigenvalue), and its corresponding eigenvector. However it is much more efficient than "Jacobi" when applied to large matrices (larger than 13x13). PEigenDense also can understand complex-valued Hermitian matrices. diff --git a/doc/src/Developer_write_fix.rst b/doc/src/Developer_write_fix.rst index f8732f74e3..afa569b05d 100644 --- a/doc/src/Developer_write_fix.rst +++ b/doc/src/Developer_write_fix.rst @@ -74,8 +74,7 @@ The next method we need to implement is ``setmask()``: Here the we specify which methods of the fix should be called during :doc:`execution of a timestep `. 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 diff --git a/doc/src/Developer_write_pair.rst b/doc/src/Developer_write_pair.rst index c286b9e1dd..4a38010c37 100644 --- a/doc/src/Developer_write_pair.rst +++ b/doc/src/Developer_write_pair.rst @@ -371,9 +371,9 @@ but moving this to a separate function allows users to change global settings like the default cutoff without having to reissue all pair_coeff commands or re-read the ``Pair Coeffs`` sections from the data file. In the ``settings()`` function, also the arrays for storing -parameters, to define cutoffs, track with pairs of parameters have been -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 `. 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 `. The next highest bit encodes whether the pair stores +data in :doc:`fix neigh/history 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 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 ` may not be needed. The member variable ``writedata`` should be set to 1 in the constructor, diff --git a/src/atom.cpp b/src/atom.cpp index 9af945367b..249651259e 100644 --- a/src/atom.cpp +++ b/src/atom.cpp @@ -82,7 +82,7 @@ are updated by the AtomVec class as needed. /** Atom class constructor * - * This resets and initialized all kinds of settings, + * This resets and initializes all kinds of settings, * parameters, and pointer variables for per-atom arrays. * This also initializes the factory for creating * instances of classes derived from the AtomVec base @@ -2831,7 +2831,7 @@ This will remove a property that was requested, e.g. by the :doc:`fix property/atom ` 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* diff --git a/src/input.cpp b/src/input.cpp index c3409f13ff..38c38ca2ee 100644 --- a/src/input.cpp +++ b/src/input.cpp @@ -78,7 +78,7 @@ template 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() ` function to read, parse and execute the contents of that file. When the end of the file diff --git a/src/lammps.cpp b/src/lammps.cpp index d3b01dd328..47540cc66c 100644 --- a/src/lammps.cpp +++ b/src/lammps.cpp @@ -1171,7 +1171,7 @@ bool LAMMPS::is_installed_pkg(const char *pkg) /** \brief Return name of package that a specific style belongs to * * This function checks the given name against all list of styles - * for all type of styles and if the name and the style match, it + * for all types of styles and if the name and the style match, it * returns which package this style belongs to. * * \param style Type of style (e.g. atom, pair, fix, etc.) diff --git a/src/my_page.cpp b/src/my_page.cpp index 94412aee0b..88bc522f29 100644 --- a/src/my_page.cpp +++ b/src/my_page.cpp @@ -40,7 +40,7 @@ using namespace LAMMPS_NS; * chunks of size *maxchunk*. The combination of these two * parameters determines how much memory is wasted by either switching * to the next page too soon or allocating too large pages that never - * get properly used. It is an error, if a requested chunk is larger + * get properly used. An error is issued if a requested chunk is larger * than *maxchunk*. The *pagedelta* parameter determines how many * pages are allocated in one go. In combination with the *pagesize* * setting, this determines how often blocks of memory get allocated @@ -48,7 +48,7 @@ using namespace LAMMPS_NS; * * \note * This is a template class with explicit instantiation. If the class - * is used with a new data type a new explicit instantiation may need to + * is used with a new data type, a new explicit instantiation may need to * be added at the end of the file ``src/my_page.cpp`` to avoid symbol * lookup errors. */ @@ -101,7 +101,7 @@ template int MyPage::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 */ diff --git a/src/my_page.h b/src/my_page.h index 1f5c9ad797..d35658ef91 100644 --- a/src/my_page.h +++ b/src/my_page.h @@ -62,7 +62,7 @@ template 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*. * diff --git a/src/my_pool_chunk.cpp b/src/my_pool_chunk.cpp index b4f497cf31..23bd450afa 100644 --- a/src/my_pool_chunk.cpp +++ b/src/my_pool_chunk.cpp @@ -35,7 +35,7 @@ using namespace LAMMPS_NS; * * \note * This is a template class with explicit instantiation. If the class - * is used with a new data type a new explicit instantiation may need + * is used with a new data type, a new explicit instantiation may need * to be added at the end of the file ``src/my_pool_chunk.cpp`` to * avoid symbol lookup errors. */ diff --git a/src/platform.h b/src/platform.h index 4328f873dd..6cb2380b50 100644 --- a/src/platform.h +++ b/src/platform.h @@ -28,7 +28,7 @@ namespace platform { /*! Return the consumed CPU time for the current process in seconds * * This is a wrapper around the POSIX function getrusage() and its Windows equivalent. - * It is to be used in a similar fashion than MPI_Wtime(). Its resolution may be rather + * It is to be used in a similar fashion as MPI_Wtime(). Its resolution may be rather * low so it can only be trusted when observing processes consuming CPU time of at least * a few seconds. * @@ -38,7 +38,7 @@ namespace platform { /*! Return the wall clock state for the current process in seconds * - * This this clock is counting continuous time and is initialized during + * This clock is counting continuous time and is initialized during * load of the executable/library. Its absolute value must be considered * arbitrary and thus elapsed wall times are measured in taking differences. * It is therefore to be used in a similar fashion as MPI_Wtime() but @@ -154,7 +154,7 @@ namespace platform { * * Return a human-readable string describing the most recent error that * occurred when using one of the functions for dynamic loading objects - * the last call to this function. The string is empty, if there was no error. + * the last call to this function. If there was no error, the string is empty. * * \return string with error message or empty */ @@ -247,13 +247,13 @@ namespace platform { * This function will traverse the list of directories in the PATH * environment variable and look for the executable *cmd*. If the * file exists and is executable the full path is returned as string, - * otherwise and empty string is returned. + * otherwise an empty string is returned. * - * On Windows the *cmd* string must not include and extension as + * On Windows the *cmd* string must not include an extension as * this function will automatically append the extensions ".exe", * ".com" and ".bat" and look for those paths. On Windows also the - * current directory is checked (and first), while otherwise not unless - * "." 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*. * diff --git a/src/potential_file_reader.cpp b/src/potential_file_reader.cpp index 9c73e30f17..2a93a4a524 100644 --- a/src/potential_file_reader.cpp +++ b/src/potential_file_reader.cpp @@ -134,7 +134,7 @@ char *PotentialFileReader::next_line(int nparams) * * This reads lines from the file using the next_line() function, * and splits them into floating-point numbers using the - * ValueTokenizer class and stores the number is the provided list. + * ValueTokenizer class and stores the number in the provided list. * * \param list Pointer to array with suitable storage for *n* doubles * \param n Number of doubles to be read */ @@ -154,7 +154,7 @@ void PotentialFileReader::next_dvector(double *list, int n) * * This reads lines from the file using the next_line() function, * and splits them into floating-point numbers using the - * ValueTokenizer class and stores the number is the provided list. + * ValueTokenizer class and stores the number in the provided list. * * \param nparams Number of words to be read * \param separators String with list of separators. diff --git a/src/text_file_reader.cpp b/src/text_file_reader.cpp index df928dcc1c..3cff7880a9 100644 --- a/src/text_file_reader.cpp +++ b/src/text_file_reader.cpp @@ -177,7 +177,7 @@ char *TextFileReader::next_line(int nparams) * * This reads lines from the file using the next_line() function, * and splits them into floating-point numbers using the - * ValueTokenizer class and stores the number is the provided list. + * ValueTokenizer class and stores the number in the provided list. * * \param list Pointer to array with suitable storage for *n* doubles * \param n Number of doubles to be read */ @@ -206,7 +206,7 @@ void TextFileReader::next_dvector(double *list, int n) * * This reads lines from the file using the next_line() function, * and splits them into floating-point numbers using the - * ValueTokenizer class and stores the number is the provided list. + * ValueTokenizer class and stores the number in the provided list. * * \param nparams Number of words to be read * \param separators String with list of separators. diff --git a/src/utils.h b/src/utils.h index 3b85824a68..4ba5f0abe2 100644 --- a/src/utils.h +++ b/src/utils.h @@ -87,7 +87,7 @@ namespace utils { /*! Return text redirecting the user to a specific paragraph in the manual * - * The LAMMPS manual contains detailed detailed explanations for errors and + * The LAMMPS manual contains detailed explanations for errors and * warnings where a simple error message may not be sufficient. These can * be reached through URLs with a numeric code. This function creates the * corresponding text to be included into the error message that redirects @@ -391,7 +391,7 @@ This functions adds the following case to :cpp:func:`utils::bounds() containing the 3 sub-strings */