Merge branch 'master' into symbolic-atom-constants

Here is a checklist of steps you need to follow to submit a single file or user package for our consideration. Following these steps will save both you and us time. See existing files in packages in the source directory for examples. If you are uncertain, please ask on the lammps-users mailing list.

* C++ source code must be compatible with the C++-11 standard. Packages may require a later standard, if justified.

* All source files you provide must compile with the most current version of LAMMPS with multiple configurations. In particular you need to test compiling LAMMPS from scratch with `-DLAMMPS_BIGBIG` set in addition to the default `-DLAMMPS_SMALLBIG` setting. Your code will need to work correctly in serial and in parallel using MPI.

* For consistency with the rest of LAMMPS and especially, if you want your contribution(s) to be added to main LAMMPS code or one of its standard packages, it needs to be written in a style compatible with other LAMMPS source files. This means: 2-character indentation per level, no tabs, no trailing whitespace, no lines over 80 characters. I/O is done via the C-style stdio library, style class header files should not import any system headers, STL containers should be avoided in headers, and forward declarations used where possible or needed. All added code should be placed into the LAMMPS_NS namespace or a sub-namespace; global or static variables should be avoided, as they conflict with the modular nature of LAMMPS and the C++ class structure. There MUST NOT be any "using namespace XXX;" statements in headers. In the implementation file (<name>.cpp) system includes should be placed in angular brackets (<>) and for c-library functions the C++ style header files should be included (<cstdio> instead of <stdio.h>, or <cstring> instead of <string.h>). This all is so the developers can more easily understand, integrate, and maintain your contribution and reduce conflicts with other parts of LAMMPS. This basically means that the code accesses data structures, performs its operations, and is formatted similar to other LAMMPS source files, including the use of the error class for error and warning messages.

* Source, style name, and documentation file should follow the following naming convention: style names should be lowercase and words separated by a forward slash; for a new fix style 'foo/bar', the class should be named FixFooBar, the name of the source files should be 'fix_foo_bar.h' and 'fix_foo_bar.cpp' and the corresponding documentation should be in a file 'fix_foo_bar.rst'.

endif

SPHINXEXTRA = -j $(shell $(PYTHON) -c 'import multiprocessing;print(multiprocessing.cpu_count())') $(shell test -f $(BUILDDIR)/doxygen/xml/run.stamp && printf -- "-E")

#SPHINXEXTRA = -j $(shell $(PYTHON) -c 'import multiprocessing;print(multiprocessing.cpu_count())') $(shell test -f $(BUILDDIR)/doxygen/xml/run.stamp && printf -- "-E")

# temporarily disable caching so that the hack for the sphinx-tabs extensions to get proper non-html output works

SPHINXEXTRA = -E -j $(shell $(PYTHON) -c 'import multiprocessing;print(multiprocessing.cpu_count())')

# grab list of sources from doxygen config file.

# we only want to use explicitly listed files.

    * string.h -> cstring

    * time.h -> ctime

    * Do NOT replace (as they are C++-11): `inttypes.h` and `stdint.h`.

  * Code should follow the C++-98 standard. C++-11 is only accepted

  * Code must follow the C++-11 standard. C++98-only is no longer accepted

  * Code should use `nullptr` instead of `NULL` where applicable.

  in individual special purpose packages

  * indentation is 2 spaces per level

  * there should be NO tabs and no trailing whitespace (review the "checkstyle" test on pull requests)

  Forward declarations should be used instead when possible.

  * iostreams should be avoided. LAMMPS uses stdio from the C-library.

  * use of STL in headers and class definitions should be avoided.

  exception is <string>, but it won't need to be explicitly included

  since pointers.h already includes it. so std::string can be used directly.

  * there MUST NOT be any "using namespace XXX;" statements in headers.

  * static class members should be avoided at all cost.

  * anything storing atom IDs should be using `tagint` and not `int`.

  compiling LAMMPS with `-DLAMMPS_BIGBIG`.

  * when including both `lmptype.h` (and using defines or macros from it)

  and `mpi.h`, `lmptype.h` must be included first.

  * see https://github.com/lammps/lammps/blob/master/doc/include-file-conventions.md

  for general include file conventions and best practices

  * when pair styles are added, check if settings for flags like

  `single_enable`, `writedata`, `reinitflag`, `manybody_flag`

  and others are correctly set and supported.

Available Architecture settings

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

These are the possible choices for the Kokkos architecture ID as of

version 3.2 of the Kokkos library. They must be specified in uppercase.

These are the possible choices for the Kokkos architecture ID.

They must be specified in uppercase.

.. list-table::

   :header-rows: 0

      - GPU

      - Intel GPUs Gen9+

This list was last updated for version 3.2 of the Kokkos library.

.. tabs::

   .. tab:: Basic CMake build settings:

     - :math:`2^{63}` steps (= :math:`9.223 \cdot 10^{18}`)

     - :math:`2^{31}` steps (= :math:`2.147 \cdot 10^9`)

   * - Atom ID values

     - :math:`1 \le i \le 2^{31} (= 2.147 \dot 10^9)`

     - :math:`1 \le i \le 2^{31} (= 2.147 \cdot 10^9)`

     - :math:`1 \le i \le 2^{63} (= 9.223 \cdot 10^{18})`

     - :math:`1 \le i \le 2^{31} (= 2.147 \dot 10^9)`

     - :math:`1 \le i \le 2^{31} (= 2.147 \cdot 10^9)`

   * - Image flag values

     - :math:`-512 \le i \le 511`

     - :math:`- 1\,048\,576 \le i \le 1\,048\,575`