Merge branch 'kokkospod' of https://github.com/cesmix-mit/lammps into kokkospod

.github/CODEOWNERS

@@ -37,7 +37,7 @@ src/MESONT/*          @iafoss
 src/ML-HDNNP/*        @singraber
 src/ML-IAP/*          @athomps
 src/ML-PACE/*         @yury-lysogorskiy
-src/ML-POD/*          @exapde @rohskopf
+src/ML-POD/*          @exapde
 src/MOFFF/*           @hheenen
 src/MOLFILE/*         @akohlmey
 src/NETCDF/*          @pastewka
@@ -65,9 +65,12 @@ src/MANYBODY/pair_nb3b_screened.*   @flodesani
 src/REPLICA/*_grem.*                @dstelter92
 src/EXTRA-COMPUTE/compute_stress_mop*.* @RomainVermorel
 src/EXTRA-COMPUTE/compute_born_matrix.* @Bibobu @athomps
+src/EXTRA-FIX/fix_deform_pressure.* @jtclemm
 src/MISC/*_tracker.*                @jtclemm
 src/MC/fix_gcmc.*                   @athomps
 src/MC/fix_sgcmc.*                  @athomps
+src/REAXFF/compute_reaxff_atom.*    @rbberger
+src/KOKKOS/compute_reaxff_atom_kokkos.*    @rbberger
 src/REPLICA/fix_pimd_langevin.*     @Yi-FanLi
 
 # core LAMMPS classes
@@ -80,7 +83,7 @@ src/bond.*                @sjplimp
 src/comm*.*               @sjplimp
 src/compute.*             @sjplimp
 src/dihedral.*            @sjplimp
-src/domain.*              @sjplimp
+src/domain.*              @sjplimp @stanmoore1
 src/dump*.*               @sjplimp
 src/error.*               @sjplimp
 src/finish.*              @sjplimp

.github/workflows/unittest-macos.yml

@@ -15,7 +15,7 @@ jobs:
   build:
     name: MacOS Unit Test
     if: ${{ github.repository == 'lammps/lammps' }}
-    runs-on: macos-latest
+    runs-on: macos-13
     env:
       CCACHE_DIR: ${{ github.workspace }}/.ccache
 
@@ -43,6 +43,8 @@ jobs:
       working-directory: build
       run: |
         ccache -z
+        python3 -m venv macosenv
+        source macosenv/bin/activate
         python3 -m pip install numpy
         python3 -m pip install pyyaml
         cmake -C ../cmake/presets/clang.cmake \

cmake/CMakeLists.txt

@@ -222,6 +222,10 @@ endif()
 add_executable(lmp ${MAIN_SOURCES})
 target_link_libraries(lmp PRIVATE lammps)
 set_target_properties(lmp PROPERTIES OUTPUT_NAME ${LAMMPS_BINARY})
+# re-export all symbols for plugins
+if(PKG_PLUGIN AND (NOT ((CMAKE_SYSTEM_NAME STREQUAL "Windows"))))
+  set_target_properties(lmp PROPERTIES ENABLE_EXPORTS TRUE)
+endif()
 install(TARGETS lmp EXPORT LAMMPS_Targets DESTINATION ${CMAKE_INSTALL_BINDIR})
 
 option(CMAKE_VERBOSE_MAKEFILE "Generate verbose Makefiles" OFF)
@@ -428,6 +432,7 @@ if(BUILD_OMP)
       (CMAKE_CXX_COMPILER_ID STREQUAL "IntelLLVM") OR (CMAKE_CXX_COMPILER_ID STREQUAL "XLClang") OR
       ((CMAKE_CXX_COMPILER_ID STREQUAL "AppleClang") AND (CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 10.0)) OR
       ((CMAKE_CXX_COMPILER_ID STREQUAL "Clang") AND (CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 10.0)) OR
+      ((CMAKE_CXX_COMPILER_ID STREQUAL "CrayClang") AND (CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 10.0)) OR
       ((CMAKE_CXX_COMPILER_ID STREQUAL "Intel") AND (CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 19.0)))
     # GCC 9.x and later plus Clang 10.x and later implement strict OpenMP 4.0 semantics for consts.
     # Intel 18.0 was tested to support both, so we switch to OpenMP 4+ from 19.x onward to be safe.
@@ -438,6 +443,21 @@ if(BUILD_OMP)
   target_compile_definitions(lammps PRIVATE -DLAMMPS_OMP_COMPAT=${LAMMPS_OMP_COMPAT_LEVEL})
   target_link_libraries(lammps PRIVATE OpenMP::OpenMP_CXX)
   target_link_libraries(lmp PRIVATE OpenMP::OpenMP_CXX)
+
+  # this hack is required to correctly link with OpenMP support when using CrayClang version 15.0.2
+  # CrayClang is only directly recognized by version 3.28 and later
+  if(CMAKE_VERSION VERSION_LESS 3.28)
+    get_filename_component(_exe "${CMAKE_CXX_COMPILER}" NAME)
+    if((CMAKE_CXX_COMPILER_ID STREQUAL "Clang") AND (_exe STREQUAL "crayCC"))
+      set(CMAKE_SHARED_LINKER_FLAGS_${BTYPE} "${CMAKE_SHARED_LINKER_FLAGS_${BTYPE} -fopenmp")
+      set(CMAKE_STATIC_LINKER_FLAGS_${BTYPE} "${CMAKE_STATIC_LINKER_FLAGS_${BTYPE} -fopenmp")
+    endif()
+  else()
+    if(CMAKE_CXX_COMPILER_ID STREQUAL "CrayClang")
+      set(CMAKE_SHARED_LINKER_FLAGS_${BTYPE} "${CMAKE_SHARED_LINKER_FLAGS_${BTYPE} -fopenmp")
+      set(CMAKE_STATIC_LINKER_FLAGS_${BTYPE} "${CMAKE_STATIC_LINKER_FLAGS_${BTYPE} -fopenmp")
+    endif()
+  endif()
 endif()
 
 # lower C++ standard for fmtlib sources when using Intel classic compiler
@@ -552,12 +572,12 @@ endforeach()
 ########################################################################
 # Basic system tests (standard libraries, headers, functions, types)   #
 ########################################################################
-foreach(HEADER cmath)
+if (NOT ((CMAKE_CXX_COMPILER_ID STREQUAL "Intel") OR (CMAKE_CXX_COMPILER_ID STREQUAL "IntelLLVM")))
-  check_include_file_cxx(${HEADER} FOUND_${HEADER})
+  check_include_file_cxx(cmath FOUND_CMATH)
-  if(NOT FOUND_${HEADER})
+  if(NOT FOUND_CMATH)
-    message(FATAL_ERROR "Could not find needed header - ${HEADER}")
+    message(FATAL_ERROR "Could not find the required 'cmath' header")
-  endif(NOT FOUND_${HEADER})
+  endif(NOT FOUND_CMATH)
-endforeach(HEADER)
+endif()
 
 # make the standard math library overrideable and autodetected (for systems that don't have it)
 find_library(STANDARD_MATH_LIB m DOC "Standard Math library")

cmake/Modules/OpenCLLoader.cmake

@@ -1,6 +1,6 @@
 message(STATUS "Downloading and building OpenCL loader library")
-set(OPENCL_LOADER_URL "${LAMMPS_THIRDPARTY_URL}/opencl-loader-2024.02.09.tar.gz" CACHE STRING "URL for OpenCL loader tarball")
+set(OPENCL_LOADER_URL "${LAMMPS_THIRDPARTY_URL}/opencl-loader-2024.05.09.tar.gz" CACHE STRING "URL for OpenCL loader tarball")
-set(OPENCL_LOADER_MD5 "f3573cf9daa3558ba46fd5866517f38f" CACHE STRING "MD5 checksum of OpenCL loader tarball")
+set(OPENCL_LOADER_MD5 "e7796826b21c059224fabe997e0f2075" CACHE STRING "MD5 checksum of OpenCL loader tarball")
 mark_as_advanced(OPENCL_LOADER_URL)
 mark_as_advanced(OPENCL_LOADER_MD5)
 

cmake/Modules/Packages/INTEL.cmake

@@ -111,6 +111,9 @@ if(PKG_KSPACE)
   list(APPEND INTEL_SOURCES ${INTEL_SOURCES_DIR}/verlet_lrt_intel.cpp)
   RegisterIntegrateStyle(${INTEL_SOURCES_DIR}/verlet_lrt_intel.h)
 endif()
+if(PKG_ML-SNAP)
+  list(APPEND INTEL_SOURCES ${INTEL_SOURCES_DIR}/sna_intel.cpp)
+endif()
 
 target_sources(lammps PRIVATE ${INTEL_SOURCES})
 target_include_directories(lammps PRIVATE ${INTEL_SOURCES_DIR})

cmake/Modules/Packages/KOKKOS.cmake

@@ -45,8 +45,8 @@ if(DOWNLOAD_KOKKOS)
   list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_CXX_EXTENSIONS=${CMAKE_CXX_EXTENSIONS}")
   list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE}")
   include(ExternalProject)
-  set(KOKKOS_URL "https://github.com/kokkos/kokkos/archive/4.2.00.tar.gz" CACHE STRING "URL for KOKKOS tarball")
+  set(KOKKOS_URL "https://github.com/kokkos/kokkos/archive/4.3.00.tar.gz" CACHE STRING "URL for KOKKOS tarball")
-  set(KOKKOS_MD5 "731647b61a4233f568d583702e9cd6d1" CACHE STRING "MD5 checksum of KOKKOS tarball")
+  set(KOKKOS_MD5 "889dcea2b5ced3debdc5b0820044bdc4" CACHE STRING "MD5 checksum of KOKKOS tarball")
   mark_as_advanced(KOKKOS_URL)
   mark_as_advanced(KOKKOS_MD5)
   GetFallbackURL(KOKKOS_URL KOKKOS_FALLBACK)
@@ -71,7 +71,7 @@ if(DOWNLOAD_KOKKOS)
   add_dependencies(LAMMPS::KOKKOSCORE kokkos_build)
   add_dependencies(LAMMPS::KOKKOSCONTAINERS kokkos_build)
 elseif(EXTERNAL_KOKKOS)
-  find_package(Kokkos 4.2.00 REQUIRED CONFIG)
+  find_package(Kokkos 4.3.00 REQUIRED CONFIG)
   target_link_libraries(lammps PRIVATE Kokkos::kokkos)
 else()
   set(LAMMPS_LIB_KOKKOS_SRC_DIR ${LAMMPS_LIB_SOURCE_DIR}/kokkos)
@@ -139,8 +139,9 @@ if(PKG_KSPACE)
       message(WARNING "Using KISS FFT with the CUDA backend of Kokkos may be sub-optimal.")
       target_compile_definitions(lammps PRIVATE -DFFT_KOKKOS_KISS)
     elseif(FFT_KOKKOS STREQUAL "CUFFT")
+      find_package(CUDAToolkit REQUIRED)
       target_compile_definitions(lammps PRIVATE -DFFT_KOKKOS_CUFFT)
-      target_link_libraries(lammps PRIVATE cufft)
+      target_link_libraries(lammps PRIVATE CUDA::cufft)
     endif()
   elseif(Kokkos_ENABLE_HIP)
     if(NOT ((FFT_KOKKOS STREQUAL "KISS") OR (FFT_KOKKOS STREQUAL "HIPFFT")))

cmake/Modules/Packages/ML-IAP.cmake

@@ -10,6 +10,14 @@ endif()
 
 option(MLIAP_ENABLE_PYTHON "Build ML-IAP package with Python support" ${MLIAP_ENABLE_PYTHON_DEFAULT})
 
+# if ML-PACE package *and* MLIAP with Python is enabled is included we may also include ML-PACE support in ML-IAP
+set(MLIAP_ENABLE_ACE_DEFAULT OFF)
+if(PKG_ML-PACE)
+  set(MLIAP_ENABLE_ACE_DEFAULT ON)
+endif()
+
+option(MLIAP_ENABLE_ACE "Build ML-IAP package with ACE support" ${MLIAP_ENABLE_ACE_DEFAULT})
+
 if(MLIAP_ENABLE_PYTHON)
   find_package(Cythonize REQUIRED)
   find_package(Python COMPONENTS NumPy REQUIRED)
@@ -36,3 +44,10 @@ if(MLIAP_ENABLE_PYTHON)
   target_compile_definitions(lammps PRIVATE -DMLIAP_PYTHON)
   target_include_directories(lammps PRIVATE ${MLIAP_BINARY_DIR})
 endif()
+
+if(MLIAP_ENABLE_ACE)
+  if(NOT PKG_ML-PACE)
+    message(FATAL_ERROR "Must enable ML-PACE package for including ACE support in ML-IAP")
+  endif()
+  target_compile_definitions(lammps PRIVATE -DMLIAP_ACE)
+endif()

cmake/presets/kokkos-cuda.cmake

@@ -10,7 +10,7 @@ get_filename_component(NVCC_WRAPPER_CMD ${CMAKE_CURRENT_SOURCE_DIR}/../lib/kokko
 set(CMAKE_CXX_COMPILER ${NVCC_WRAPPER_CMD} CACHE FILEPATH "" FORCE)
 
 # If KSPACE is also enabled, use CUFFT for FFTs
-set(FFT_KOKKOS "CUFFT" CACHE STRING FORCE)
+set(FFT_KOKKOS "CUFFT" CACHE STRING "" FORCE)
 
 # hide deprecation warnings temporarily for stable release
 set(Kokkos_ENABLE_DEPRECATION_WARNINGS OFF CACHE BOOL "" FORCE)

cmake/presets/kokkos-hip.cmake

@@ -13,7 +13,7 @@ set(CMAKE_CXX_COMPILER hipcc CACHE STRING "" FORCE)
 set(CMAKE_TUNE_FLAGS "-munsafe-fp-atomics" CACHE STRING "" FORCE)
 
 # If KSPACE is also enabled, use CUFFT for FFTs
-set(FFT_KOKKOS "HIPFFT" CACHE STRING FORCE)
+set(FFT_KOKKOS "HIPFFT" CACHE STRING "" FORCE)
 
 # hide deprecation warnings temporarily for stable release
 set(Kokkos_ENABLE_DEPRECATION_WARNINGS OFF CACHE BOOL "" FORCE)

doc/lammps.1

@@ -1,7 +1,7 @@
-.TH LAMMPS "1" "7 February 2024" "2024-02-07"
+.TH LAMMPS "1" "17 April 2024" "2024-04-17"
 .SH NAME
 .B LAMMPS
-\- Molecular Dynamics Simulator.  Version 7 February 2024
+\- Molecular Dynamics Simulator.  Version 17 April 2024
 
 .SH SYNOPSIS
 .B lmp
@@ -297,7 +297,7 @@ the chapter on errors in the
 manual gives some additional information about error messages, if possible.
 
 .SH COPYRIGHT
-© 2003--2022 Sandia Corporation
+© 2003--2024 Sandia Corporation
 
 This package is free software; you can redistribute it and/or modify
 it under the terms of the GNU General Public License version 2 as

doc/src/Bibliography.rst

@@ -877,6 +877,9 @@ Bibliography
 **(PLUMED)**
    G.A. Tribello, M. Bonomi, D. Branduardi, C. Camilloni and G. Bussi, Comp. Phys. Comm 185, 604 (2014)
 
+**(Pavlov)**
+D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Journal of High Performance Computing Applications, 38, 34-49 (2024).
+
 **(Paquay)**
    Paquay and Kusters, Biophys. J., 110, 6, (2016). preprint available at `arXiv:1411.3019 <https://arxiv.org/abs/1411.3019/>`_.
 

doc/src/Build_extras.rst

@@ -533,9 +533,6 @@ They must be specified in uppercase.
    *  - A64FX
       - HOST
       - ARMv8.2 with SVE Support
-   *  - WSM
-      - HOST
-      - Intel Westmere CPU (SSE 4.2)
    *  - SNB
       - HOST
       - Intel Sandy/Ivy Bridge CPU (AVX 1)
@@ -566,18 +563,15 @@ They must be specified in uppercase.
    *  - KNL
       - HOST
       - Intel Knights Landing Xeon Phi
-   *  - BGQ
-      - HOST
-      - IBM Blue Gene/Q CPU
-   *  - POWER7
-      - HOST
-      - IBM POWER7 CPU
    *  - POWER8
       - HOST
       - IBM POWER8 CPU
    *  - POWER9
       - HOST
       - IBM POWER9 CPU
+   *  - RISCV_SG2042
+      - HOST
+      - SG2042 (RISC-V) CPU
    *  - KEPLER30
       - GPU
       - NVIDIA Kepler generation CC 3.0 GPU
@@ -666,7 +660,7 @@ They must be specified in uppercase.
       - GPU
       - Intel GPU Ponte Vecchio
 
-This list was last updated for version 4.2 of the Kokkos library.
+This list was last updated for version 4.3.0 of the Kokkos library.
 
 .. tabs::
 

doc/src/Commands_bond.rst

@@ -89,6 +89,7 @@ OPT.
    * :doc:`cosine/shift (o) <angle_cosine_shift>`
    * :doc:`cosine/shift/exp (o) <angle_cosine_shift_exp>`
    * :doc:`cosine/squared (o) <angle_cosine_squared>`
+   * :doc:`cosine/squared/restricted (o) <angle_cosine_squared_restricted>`
    * :doc:`cross <angle_cross>`
    * :doc:`dipole (o) <angle_dipole>`
    * :doc:`fourier (o) <angle_fourier>`
@@ -127,6 +128,7 @@ OPT.
    * :doc:`charmmfsw (k) <dihedral_charmm>`
    * :doc:`class2 (ko) <dihedral_class2>`
    * :doc:`cosine/shift/exp (o) <dihedral_cosine_shift_exp>`
+   * :doc:`cosine/squared/restricted <dihedral_cosine_squared_restricted>`
    * :doc:`fourier (io) <dihedral_fourier>`
    * :doc:`harmonic (iko) <dihedral_harmonic>`
    * :doc:`helix (o) <dihedral_helix>`

doc/src/Commands_fix.rst

@@ -61,6 +61,7 @@ OPT.
    * :doc:`controller <fix_controller>`
    * :doc:`damping/cundall <fix_damping_cundall>`
    * :doc:`deform (k) <fix_deform>`
+   * :doc:`deform/pressure <fix_deform_pressure>`
    * :doc:`deposit <fix_deposit>`
    * :doc:`dpd/energy (k) <fix_dpd_energy>`
    * :doc:`drag <fix_drag>`
@@ -262,6 +263,7 @@ OPT.
    * :doc:`wall/body/polyhedron <fix_wall_body_polyhedron>`
    * :doc:`wall/colloid <fix_wall>`
    * :doc:`wall/ees <fix_wall_ees>`
+   * :doc:`wall/flow (k) <fix_wall_flow>`
    * :doc:`wall/gran (k) <fix_wall_gran>`
    * :doc:`wall/gran/region <fix_wall_gran_region>`
    * :doc:`wall/harmonic <fix_wall>`

doc/src/Commands_pair.rst

@@ -245,6 +245,7 @@ OPT.
    * :doc:`oxrna2/coaxstk <pair_oxrna2>`
    * :doc:`pace (k) <pair_pace>`
    * :doc:`pace/extrapolation (k) <pair_pace>`
+   * :doc:`pedone (o) <pair_pedone>`
    * :doc:`pod <pair_pod>`
    * :doc:`peri/eps <pair_peri>`
    * :doc:`peri/lps (o) <pair_peri>`
@@ -256,6 +257,7 @@ OPT.
    * :doc:`rann <pair_rann>`
    * :doc:`reaxff (ko) <pair_reaxff>`
    * :doc:`rebo (io) <pair_airebo>`
+   * :doc:`rebomos (o) <pair_rebomos>`
    * :doc:`resquared (go) <pair_resquared>`
    * :doc:`saip/metal (t) <pair_saip_metal>`
    * :doc:`sdpd/taitwater/isothermal <pair_sdpd_taitwater_isothermal>`

doc/src/Developer_updating.rst

@@ -18,6 +18,7 @@ Available topics in mostly chronological order are:
 - `Setting flags in the constructor`_
 - `Rename of pack/unpack_comm() to pack/unpack_forward_comm()`_
 - `Use ev_init() to initialize variables derived from eflag and vflag`_
+- `Use utils::count_words() functions instead of atom->count_words()`_
 - `Use utils::numeric() functions instead of force->numeric()`_
 - `Use utils::open_potential() function to open potential files`_
 - `Use symbolic Atom and AtomVec constants instead of numerical values`_
@@ -130,6 +131,41 @@ Not applying this change will not cause a compilation error, but
 can lead to inconsistent behavior and incorrect tallying of
 energy or virial.
 
+Use utils::count_words() functions instead of atom->count_words()
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. versionchanged:: 2Jun2020
+
+The "count_words()" functions for parsing text have been moved from the
+Atom class to the :doc:`utils namespace <Developer_utils>`.  The
+"count_words()" function in "utils" uses the Tokenizer class internally
+to split a line into words and count them, thus it will not modify the
+argument string as the function in the Atoms class did and thus had a
+variant using a copy buffer.  Unlike the old version, the new version
+does not remove comments. For that you can use the
+:cpp:func:`utils::trim_comment() function
+<LAMMPS_NS::utils::trim_comment>` as shown in the example below.
+
+Old:
+
+.. code-block:: c++
+
+   nwords = atom->count_words(line);
+   int nwords = atom->count_words(buf);
+
+New:
+
+.. code-block:: c++
+
+   nwords = utils::count_words(line);
+   int nwords = utils::count_words(utils::trim_comment(buf));
+
+.. seealso::
+
+   :cpp:func:`utils::count_words() <LAMMPS_NS::utils::count_words>`,
+   :cpp:func:`utils::trim_comments() <LAMMPS_NS::utils::trim_comments>`
+
+
 Use utils::numeric() functions instead of force->numeric()
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
@@ -137,11 +173,12 @@ Use utils::numeric() functions instead of force->numeric()
 
 The "numeric()" conversion functions (including "inumeric()",
 "bnumeric()", and "tnumeric()") have been moved from the Force class to
-the utils namespace.  Also they take an additional argument that selects
+the :doc:`utils namespace <Developer_utils>`.  Also they take an
-whether the ``Error::all()`` or ``Error::one()`` function should be
+additional argument that selects whether the ``Error::all()`` or
-called in case of an error.  The former should be used when *all* MPI
+``Error::one()`` function should be called in case of an error.  The
-processes call the conversion function and the latter *must* be used
+former should be used when *all* MPI processes call the conversion
-when they are called from only one or a subset of the MPI processes.
+function and the latter *must* be used when they are called from only
+one or a subset of the MPI processes.
 
 Old:
 

doc/src/Developer_utils.rst

@@ -635,10 +635,10 @@ Tohoku University (under MIT license)
 
 ----------
 
-.. doxygenfunction:: MathEigen::jacobi3(double const *const *mat, double *eval, double **evec)
+.. doxygenfunction:: MathEigen::jacobi3(double const *const *mat, double *eval, double **evec, int sort)
    :project: progguide
 
-.. doxygenfunction:: MathEigen::jacobi3(double const mat[3][3], double *eval, double evec[3][3])
+.. doxygenfunction:: MathEigen::jacobi3(double const mat[3][3], double *eval, double evec[3][3], int sort)
    :project: progguide
 
 ---------------------------

doc/src/Errors_details.rst

@@ -13,15 +13,44 @@ discussions of such cases.
 Unknown identifier in data file
 -------------------------------
 
-This error happens when LAMMPS encounters a line of text in an unexpected format
+This error happens when LAMMPS encounters a line of text with an
-while reading a data file. This is most commonly cause by inconsistent header and
+unexpected keyword while :doc:`reading a data file <read_data>`.  This
-section data.  The header section informs LAMMPS how many entries or lines are expected in the
+would be either header keywords or section header keywords.  This is
-various sections (like Atoms, Masses, Pair Coeffs, *etc.*\ ) of the data file.
+most commonly due to a mistyped keyword or due to a keyword that is
-If there is a mismatch, LAMMPS will either keep reading beyond the end of a section
+inconsistent with the :doc:`atom style <atom_style>` used.
-or stop reading before the section has ended.
 
-Such a mismatch can happen unexpectedly when the first line of the data
+The header section informs LAMMPS how many entries or lines are expected
-is *not* a comment as required by the format.  That would result in
+in the various sections (like Atoms, Masses, Pair Coeffs, *etc.*\ ) of
-LAMMPS expecting, for instance, 0 atoms because the "atoms" header line
+the data file.  If there is a mismatch, LAMMPS will either keep reading
-is treated as a comment.
+beyond the end of a section or stop reading before the section has
+ended.  In that case the next line will not contain a recognized keyword.
 
+Such a mismatch can also happen when the first line of the data
+is *not* a comment as required by the format, but a line with a valid
+header keyword.  That would result in LAMMPS expecting, for instance,
+0 atoms because the "atoms" header line is the first line and thus
+treated as a comment.
+
+Another possibility to trigger this error is to have a keyword in the
+data file that corresponds to a fix (e.g. :doc:`fix cmap <fix_cmap>`)
+but the :doc:`read_data <read_data>` command is missing the (optional)
+arguments that identify the fix and the header keyword and section
+keyword or those arguments are inconsistent with the keywords in the
+data file.
+
+.. _err0002:
+
+Incorrect format in ... section of data file
+--------------------------------------------
+
+This error happens when LAMMPS reads the contents of a section of a
+:doc:`data file <read_data>` and the number of parameters in the line
+differs from what is expected.  This most commonly happens, when the
+atom style is different from what is expected for a specific data file
+since changing the atom style usually changes the format of the line.
+
+This error can also happen when the number of entries indicated in the
+header of a data file (e.g. the number of atoms) is larger than the
+number of lines provided (e.g. in the corresponding Atoms section)
+and then LAMMPS will continue reading into the next section and that
+would have a completely different format.

doc/src/Errors_messages.rst

@@ -7883,12 +7883,6 @@ keyword to allow for additional bonds to be formed
    Fix poems cannot (yet) work with coupled bodies whose joints connect
    the bodies in a tree structure.
 
-*Triclinic box skew is too large*
-   The displacement in a skewed direction must be less than half the box
-   length in that dimension.  E.g. the xy tilt must be between -half and
-   +half of the x box length.  This constraint can be relaxed by using
-   the box tilt command.
-
 *Tried to convert a double to int, but input_double > INT_MAX*
    Self-explanatory.
 

doc/src/Errors_warnings.rst

@@ -752,13 +752,6 @@ This will most likely cause errors in kinetic fluctuations.
    More than the maximum # of neighbors was found multiple times.  This
    was unexpected.
 
-*Triclinic box skew is large*
-   The displacement in a skewed direction is normally required to be less
-   than half the box length in that dimension.  E.g. the xy tilt must be
-   between -half and +half of the x box length.  You have relaxed the
-   constraint using the box tilt command, but the warning means that a
-   LAMMPS simulation may be inefficient as a result.
-
 *Use special bonds = 0,1,1 with bond style fene*
    Most FENE models need this setting for the special_bonds command.
 

doc/src/Fortran.rst

@@ -1255,8 +1255,8 @@ Procedures Bound to the :f:type:`lammps` Derived Type
    three elements of the global vector calculated by fix recenter into the
    variables *dx*, *dy*, and *dz*, respectively.
 
-   If asked for per-atom or local data, :f:func:`extract_compute` returns a
+   If asked for per-atom or local data, :f:func:`extract_fix` returns a
-   pointer to actual LAMMPS data. The pointer so returned will have the
+   pointer to actual LAMMPS data.  The pointer returned will have the
    appropriate size to match the internal data, and will be
    type/kind/rank-checked at the time of the assignment. For example,
 

doc/src/Howto_2d.rst

@@ -1,42 +1,112 @@
+================
  2d simulations
-==============
+================
 
-Use the :doc:`dimension <dimension>` command to specify a 2d simulation.
+You must use the :doc:`dimension <dimension>` command to specify a 2d
+simulation.  The default is 3d.
 
-Make the simulation box periodic in z via the :doc:`boundary <boundary>`
+A 2d simulation box must be periodic in z as set by the :doc:`boundary
-command.  This is the default.
+<boundary>` command.  This is the default.
 
-If using the :doc:`create_box <create_box>` command to define a
+Simulation boxes in LAMMPS can be either orthogonal or triclinic in
-simulation box, set the z dimensions narrow, but finite, so that the
+shape.  Orthogonal boxes in 2d are a rectangle with 4 edges that are
-:doc:`create_atoms <create_atoms>` command will fill the 3d simulation
+each perpendicular to either the x or y coordinate axes.  Triclinic
-box with a single z plane of atoms - e.g.
+boxes in 2d are a parallelogram with opposite pairs of faces parallel
+to each other.  LAMMPS supports two forms of triclinic boxes,
+restricted and general, which for 2d differ in how the box is oriented
+with respect to the xy coordinate axes.  See the :doc:`Howto triclinic
+<Howto_triclinic>` for a detailed description of all 3 kinds of
+simulation boxes.
+
+Here are examples of using the :doc:`create_box <create_box>` command
+to define the simulation box for a 2d system.
 
 .. code-block:: LAMMPS
 
-   create_box 1 -10 10 -10 10 -0.25 0.25
+   # 2d orthogonal box using a block-style region
+   region mybox block -10 10 0 10 -0.5 0.5
+   create_box 1 mybox
 
-If using the :doc:`read_data <read_data>` command to read in a file of
+   # 2d restricted triclinic box using a prism-style region with only xy tilt
-atom coordinates, set the "zlo zhi" values to be finite but narrow,
+   region mybox prism 0 10 0 10 -0.5 0.5 2.0 0.0 0.0
-similar to the create_box command settings just described.  For each
+   create_box 1 mybox
-atom in the file, assign a z coordinate so it falls inside the
-z-boundaries of the box - e.g. 0.0.
 
-Use the :doc:`fix enforce2d <fix_enforce2d>` command as the last
+   # 2d general triclinic box using a primitive cell for a 2d hex lattice
-defined fix to ensure that the z-components of velocities and forces
+   lattice       custom 1.0 a1 1.0 0.0 0.0 a2 0.5 0.86602540378 0.0 &
-are zeroed out every timestep.  The reason to make it the last fix is
+                 a3 0.0 0.0 1.0 basis 0.0 0.0 0.0 triclinic/general
-so that any forces induced by other fixes will be zeroed out.
+   create_box    1 NULL 0 5 0 5 -0.5 0.5
 
-Many of the example input scripts included in the LAMMPS distribution
+Note that for 2d orthogonal or restricted triclinic boxes, the box has
+a 3rd dimension which must straddle z = 0.0 in the z dimension.
+Typically the width of box in the z dimension should be narrow,
+e.g. -0.5 to 0.5, but that is not required.  For a 2d general
+triclinic box, the *a3* vector defined by the :doc:`lattice <lattice>`
+command must be (0.0,0.0,1.0), which is its default value.  Also the
+*clo* and *chi* arguments of the :doc:`create_box <create_box>`
+command must be -0.5 and 0.5.
+
+Here are examples of using the :doc:`read_data <read_data>` command
+to define the simulation box for a 2d system via keywords in the
+header section of the data file.  These are the same boxes as the examples
+for the :doc:`create_box <create_box>` command
+
+.. code-block:: LAMMPS
+
+   # 2d orthogonal box
+   -10 10   xlo xhi
+   0 10     ylo yhi
+   -0.5 0.5 zlo zhi       # this is the default, so no need to specify
+
+   # 2d restricted triclinic box with only xy tilt
+   -10 10   xlo xhi
+   0 10     ylo yhi
+   -0.5 0.5 zlo zhi       # this is the default, so no need to specify
+   2.0 0.0 0.0 xy xz yz
+
+   # 3d general triclinic box using a primitive cell for a 2d hex lattice
+   5 0 0              avec
+   2.5 4.3301270189 0 bvec
+   0 0 1              cvec           # this is the default, so no need to specify
+   0 0 -0.5           abc origin     # this is the default for 2d, so no need to specify
+
+Note that for 2d orthogonal or restricted triclinic boxes, the box has
+a 3rd dimension specified by the *zlo zhi* values, which must straddle
+z = 0.0.  Typically the width of box in the z dimension should be
+narrow, e.g. -0.5 to 0.5, but that is not required.  For a 2d general
+triclinic box, the z component of *avec* and *bvec* must be zero, and
+*cvec* must be (0,0,1), which is the default.  The z component of *abc
+origin* must also be -0.5, which is the default.
+
+If using the :doc:`create_atoms <create_atoms>` command to create
+atoms in the 2d simulation box, all the z coordinates of created atoms
+will be zero.
+
+If using the :doc:`read_data <read_data>` command to read in a data
+file of atom coordinates for a 2d system, the z coordinates of all
+atoms should be zero.  A value within epsilon of zero is also allowed
+in case the data file was generated by another program with finite
+numeric precision, in which case the z coord for the atom will be set
+to zero.
+
+Use the :doc:`fix enforce2d <fix_enforce2d>` command as the last fix
+defined in the input script.  It ensures that the z-components of
+velocities and forces are zeroed out every timestep.  The reason to
+make it the last fix is so that any forces added by other fixes will
+also be zeroed out.
+
+Many of the example input scripts included in the examples directory
 are for 2d models.
 
 .. note::
 
    Some models in LAMMPS treat particles as finite-size spheres, as
-   opposed to point particles.  See the :doc:`atom_style sphere <atom_style>` and :doc:`fix nve/sphere <fix_nve_sphere>`
+   opposed to point particles.  See the :doc:`atom_style sphere
-   commands for details.  By default, for 2d simulations, such particles
+   <atom_style>` and :doc:`fix nve/sphere <fix_nve_sphere>` commands
-   will still be modeled as 3d spheres, not 2d discs (circles), meaning
+   for details.  By default, for 2d simulations, such particles will
+   still be modeled as 3d spheres, not 2d discs (circles), meaning
    their moment of inertia will be that of a sphere.  If you wish to
-   model them as 2d discs, see the :doc:`set density/disc <set>` command
+   model them as 2d discs, see the :doc:`set density/disc <set>`
-   and the *disc* option for the :doc:`fix nve/sphere <fix_nve_sphere>`,
+   command and the *disc* option for the :doc:`fix nve/sphere
-   :doc:`fix nvt/sphere <fix_nvt_sphere>`, :doc:`fix nph/sphere <fix_nph_sphere>`, :doc:`fix npt/sphere <fix_npt_sphere>`
+   <fix_nve_sphere>`, :doc:`fix nvt/sphere <fix_nvt_sphere>`,
-   commands.
+   :doc:`fix nph/sphere <fix_nph_sphere>`, :doc:`fix npt/sphere
+   <fix_npt_sphere>` commands.

doc/src/Howto_body.rst

@@ -102,8 +102,19 @@ particles of different styles
 | :doc:`dump image <dump_image>`                 | output body particle attributes as an image         |
 +------------------------------------------------+-----------------------------------------------------+
 
-The pair styles defined for use with specific body styles are listed
+The pair styles currently defined for use with specific body styles
-in the sections below.
+are listed in the sections below.
+
+Note that for all the body styles, if the data file defines a general
+triclinic box, then the orientation of the body particle and its
+corresponding 6 moments of inertia and other orientation-dependent
+values should reflect the fact the body is defined withing a general
+triclinic box with edge vectors **A**,**B**,**C**.  LAMMPS will rotate
+the box to convert it to a restricted triclinic box.  This operation
+will also rotate the orientation of the body particles.  See the
+:doc:`Howto triclinic <Howto_triclinic>` doc page for more details.
+The sections below highlight the orientation-dependent values specific
+to each body style.
 
 ----------
 
@@ -154,12 +165,18 @@ values consistent with the current orientation of the rigid body
 around its center of mass.  The values are with respect to the
 simulation box XYZ axes, not with respect to the principal axes of the
 rigid body itself.  LAMMPS performs the latter calculation internally.
+
 The coordinates of each sub-particle are specified as its x,y,z
 displacement from the center-of-mass of the body particle.  The
 center-of-mass position of the particle is specified by the x,y,z
 values in the *Atoms* section of the data file, as is the total mass
 of the body particle.
 
+Note that if the data file defines a general triclinic simulation box,
+these sub-particle displacements are orientation-dependent and, as
+mentioned above, should reflect the body particle's orientation within
+the general triclinic box.
+
 The :doc:`pair_style body/nparticle <pair_body_nparticle>` command can be used
 with this body style to compute body/body and body/non-body interactions.
 
@@ -226,6 +243,7 @@ values consistent with the current orientation of the rigid body
 around its center of mass.  The values are with respect to the
 simulation box XYZ axes, not with respect to the principal axes of the
 rigid body itself.  LAMMPS performs the latter calculation internally.
+
 The coordinates of each vertex are specified as its x,y,z displacement
 from the center-of-mass of the body particle.  The center-of-mass
 position of the particle is specified by the x,y,z values in the
@@ -270,6 +288,11 @@ A disk, whose diameter is 3.0, mass 1.0, is specified as follows:
    0 0 0
    3.0
 
+Note that if the data file defines a general triclinic simulation box,
+these polygon vertex displacements are orientation-dependent and, as
+mentioned above, should reflect the body particle's orientation within
+the general triclinic box.
+
 The :doc:`pair_style body/rounded/polygon <pair_body_rounded_polygon>`
 command can be used with this body style to compute body/body
 interactions.  The :doc:`fix wall/body/polygon <fix_wall_body_polygon>`
@@ -366,6 +389,7 @@ values consistent with the current orientation of the rigid body
 around its center of mass.  The values are with respect to the
 simulation box XYZ axes, not with respect to the principal axes of the
 rigid body itself.  LAMMPS performs the latter calculation internally.
+
 The coordinates of each vertex are specified as its x,y,z displacement
 from the center-of-mass of the body particle.  The center-of-mass
 position of the particle is specified by the x,y,z values in the
@@ -435,6 +459,11 @@ A sphere whose diameter is 3.0 and mass 1.0, is specified as follows:
 The number of edges and faces for a rod or sphere must be listed,
 but is ignored.
 
+Note that if the data file defines a general triclinic simulation box,
+these polyhedron vertex displacements are orientation-dependent and,
+as mentioned above, should reflect the body particle's orientation
+within the general triclinic box.
+
 The :doc:`pair_style body/rounded/polhedron
 <pair_body_rounded_polyhedron>` command can be used with this body
 style to compute body/body interactions.  The :doc:`fix

doc/src/Howto_bpm.rst

@@ -15,7 +15,8 @@ orientation for rotational models. This produces a stress-free initial
 state. Furthermore, bonds are allowed to break under large strains,
 producing fracture. The examples/bpm directory has sample input scripts
 for simulations of the fragmentation of an impacted plate and the
-pouring of extended, elastic bodies.
+pouring of extended, elastic bodies. See :ref:`(Clemmer) <howto-Clemmer>`
+for more general information on the approach and the LAMMPS implementation.
 
 ----------
 
@@ -150,3 +151,9 @@ the following are currently compatible with BPM bond styles:
    interactions, one will need to switch between different *special_bonds*
    settings in the input script. An example is found in
    ``examples/bpm/impact``.
+
+----------
+
+.. _howto-Clemmer:
+
+**(Clemmer)** Clemmer, Monti, Lechman, Soft Matter, 20, 1702 (2024).

doc/src/Howto_granular.rst

@@ -45,10 +45,15 @@ atoms, and should be used for granular system instead of the fix style
 
 To model heat conduction, one must add the temperature and heatflow
 atom variables with:
+
 * :doc:`fix property/atom <fix_property_atom>`
+
 a temperature integration fix
+
 * :doc:`fix heat/flow <fix_heat_flow>`
+
 and a heat conduction option defined in both
+
 * :doc:`pair_style granular <pair_granular>`
 * :doc:`fix wall/gran <fix_wall_gran>`
 

doc/src/Howto_triclinic.rst

@@ -2,43 +2,195 @@ Triclinic (non-orthogonal) simulation boxes
 ===========================================
 
 By default, LAMMPS uses an orthogonal simulation box to encompass the
-particles.  The :doc:`boundary <boundary>` command sets the boundary
+particles.  The orthogonal box has its "origin" at (xlo,ylo,zlo) and
-conditions of the box (periodic, non-periodic, etc).  The orthogonal
+extends to (xhi,yhi,zhi).  Conceptually it is defined by 3 edge
-box has its "origin" at (xlo,ylo,zlo) and is defined by 3 edge vectors
+vectors starting from the origin given by **A** = (xhi-xlo,0,0); **B**
-starting from the origin given by **a** = (xhi-xlo,0,0); **b** =
+= (0,yhi-ylo,0); **C** = (0,0,zhi-zlo).  The :doc:`boundary
-(0,yhi-ylo,0); **c** = (0,0,zhi-zlo).  The 6 parameters
+<boundary>` command sets the boundary conditions for the 6 faces of
+the box (periodic, non-periodic, etc).  The 6 parameters
 (xlo,xhi,ylo,yhi,zlo,zhi) are defined at the time the simulation box
-is created, e.g. by the :doc:`create_box <create_box>` or
+is created by one of these commands:
-:doc:`read_data <read_data>` or :doc:`read_restart <read_restart>`
-commands.  Additionally, LAMMPS defines box size parameters lx,ly,lz
-where lx = xhi-xlo, and similarly in the y and z dimensions.  The 6
-parameters, as well as lx,ly,lz, can be output via the
-:doc:`thermo_style custom <thermo_style>` command.
 
-LAMMPS also allows simulations to be performed in triclinic
+* :doc:`create_box <create_box>`
-(non-orthogonal) simulation boxes shaped as a parallelepiped with
+* :doc:`read_data <read_data>`
-triclinic symmetry.  The parallelepiped has its "origin" at
+* :doc:`read_restart <read_restart>`
-(xlo,ylo,zlo) and is defined by 3 edge vectors starting from the
+* :doc:`read_dump <read_dump>`
-origin given by **a** = (xhi-xlo,0,0); **b** = (xy,yhi-ylo,0); **c** =
-(xz,yz,zhi-zlo).  *xy,xz,yz* can be 0.0 or positive or negative values
-and are called "tilt factors" because they are the amount of
-displacement applied to faces of an originally orthogonal box to
-transform it into the parallelepiped.  In LAMMPS the triclinic
-simulation box edge vectors **a**, **b**, and **c** cannot be arbitrary
-vectors.  As indicated, **a** must lie on the positive x axis.  **b** must
-lie in the xy plane, with strictly positive y component. **c** may have
-any orientation with strictly positive z component.  The requirement
-that **a**, **b**, and **c** have strictly positive x, y, and z components,
-respectively, ensures that **a**, **b**, and **c** form a complete
-right-handed basis.  These restrictions impose no loss of generality,
-since it is possible to rotate/invert any set of 3 crystal basis
-vectors so that they conform to the restrictions.
 
-For example, assume that the 3 vectors **A**,\ **B**,\ **C** are the edge
+Internally, LAMMPS defines box size parameters lx,ly,lz where lx =
-vectors of a general parallelepiped, where there is no restriction on
+xhi-xlo, and similarly in the y and z dimensions.  The 6 parameters, as
-**A**,\ **B**,\ **C** other than they form a complete right-handed basis i.e.
+well as lx,ly,lz, can be output via the :doc:`thermo_style custom
-**A** x **B** . **C** > 0.  The equivalent LAMMPS **a**,\ **b**,\ **c** are a linear
+<thermo_style>` command.  See the :doc:`Howto 2d <Howto_2d>` doc page
-rotation of **A**, **B**, and **C** and can be computed as follows:
+for info on how zlo and zhi are defined for 2d simulations.
+
+----------
+
+Triclinic simulation boxes
+""""""""""""""""""""""""""
+
+LAMMPS also allows simulations to be performed using triclinic
+(non-orthogonal) simulation boxes shaped as a 3d parallelepiped with
+triclinic symmetry.  For 2d simulations a triclinic simulation box is
+effectively a parallelogram; see the :doc:`Howto 2d <Howto_2d>` doc
+page for details.
+
+One use of triclinic simulation boxes is to model solid-state crystals
+with triclinic symmetry.  The :doc:`lattice <lattice>` command can be
+used with non-orthogonal basis vectors to define a lattice that will
+tile a triclinic simulation box via the :doc:`create_atoms
+<create_atoms>` command.
+
+A second use is to run Parrinello-Rahman dynamics via the :doc:`fix
+npt <fix_nh>` command, which will adjust the xy, xz, yz tilt factors
+to compensate for off-diagonal components of the pressure tensor.  The
+analog for an :doc:`energy minimization <minimize>` is the :doc:`fix
+box/relax <fix_box_relax>` command.
+
+A third use is to shear a bulk solid to study the response of the
+material.  The :doc:`fix deform <fix_deform>` command can be used for
+this purpose.  It allows dynamic control of the xy, xz, yz tilt
+factors as a simulation runs.  This is discussed in the :doc:`Howto
+NEMD <Howto_nemd>` doc page on non-equilibrium MD (NEMD) simulations.
+
+Conceptually, a triclinic parallelepiped is defined with an "origin"
+at (xlo,ylo,zhi) and 3 edge vectors **A** = (ax,ay,az), **B** =
+(bx,by,bz), **C** = (cx,cy,cz) which can be arbitrary vectors, so long
+as they are non-zero, distinct, and not co-planar.  In addition, they
+must define a right-handed system, such that (**A** cross **B**)
+points in the direction of **C**.  Note that a left-handed system can
+be converted to a right-handed system by simply swapping the order of
+any pair of the **A**, **B**, **C** vectors.
+
+The 4 commands listed above for defining orthogonal simulation boxes
+have triclinic options which allow for specification of the origin and
+edge vectors **A**, **B**, **C**.  For each command, this can be done
+in one of two ways, for what LAMMPS calls a *general* triclinic box or
+a *restricted* triclinic box.
+
+A *general* triclinic box is specified by an origin (xlo, ylo, zlo)
+and arbitrary edge vectors **A** = (ax,ay,az), **B** = (bx,by,bz), and
+**C** = (cx,cy,cz).  So there are 12 parameters in total.
+
+A *restricted* triclinic box also has an origin (xlo,ylo,zlo), but its
+edge vectors are of the following restricted form: **A** =
+(xhi-xlo,0,0), **B** = (xy,yhi-ylo,0), **C** = (xz,yz,zhi-zlo).  So
+there are 9 parameters in total.  Note that the restricted form
+requires **A** to be along the x-axis, **B** to be in the xy plane
+with a y-component in the +y direction, and **C** to have its
+z-component in the +z direction.  Note that a restricted triclinic box
+is *right-handed* by construction since (**A** cross **B**) points in
+the direction of **C**.
+
+The *xy,xz,yz* values can be zero or positive or negative.  They are
+called "tilt factors" because they are the amount of displacement
+applied to edges of faces of an orthogonal box to change it into a
+restricted triclinic parallelepiped.
+
+.. note::
+
+   Any right-handed general triclinic box (i.e. solid-state crystal
+   basis vectors) can be rotated in 3d around its origin in order to
+   conform to the LAMMPS definition of a restricted triclinic box.
+   See the discussion in the next sub-section about general triclinic
+   simulation boxes in LAMMPS.
+
+Note that the :doc:`thermo_style custom <thermo_style>` command has
+keywords for outputting the various parameters that define the size
+and shape of orthogonal, restricted triclinic, and general triclinic
+simulation boxes.
+
+For orthogonal boxes there 6 thermo keywords (xlo,ylo,zlo) and
+(xhi,yhi,zhi).
+
+For restricted triclinic boxes there are 9 thermo keywords for
+(xlo,ylo,zlo), (xhi,yhi,zhi), and the (xy,xz,yz) tilt factors.
+
+For general triclinic boxes there are 12 thermo keywords for
+(xlo,ylo,zhi) and the components of the **A**, **B**, **C** edge
+vectors, namely (avecx,avecy,avecz), (bvecx,bvecy,bvecz), and
+(cvecx,cvecy,cvecz),
+
+The remainder of this doc page explains (a) how LAMMPS operates with
+general triclinic simulation boxes, (b) mathematical transformations
+between general and restricted triclinic boxes which may be useful
+when creating LAMMPS inputs or interpreting outputs for triclinic
+simulations, and (c) how LAMMPS uses tilt factors for restricted
+triclinic simulation boxes.
+
+----------
+
+General triclinic simulation boxes in LAMMPS
+""""""""""""""""""""""""""""""""""""""""""""
+
+LAMMPS allows specification of general triclinic simulation boxes with
+their atoms as a convenience for users who may be converting data from
+solid-state crystallographic representations or from DFT codes for
+input to LAMMPS.  Likewise it allows output of dump files, data files,
+and thermodynamic data (e.g. pressure tensor) in a general triclinic
+format.
+
+However internally, LAMMPS only uses restricted triclinic simulation
+boxes.  This is for parallel efficiency and to formulate partitioning
+of the simulation box across processors, neighbor list building, and
+inter-processor communication of per-atom data with methods similar to
+those used for orthogonal boxes.
+
+This means 4 things which are important to understand:
+
+* Input of a general triclinic system is immediately converted to a
+  restricted triclinic system.
+* If output of per-atom data for a general triclinic system is
+  requested (e.g. for atom coordinates in a dump file),
+  conversion from a restricted to general triclinic system is done at
+  the time of output.
+* The conversion of the simulation box and per-atom data from general
+  triclinic to restricted triclinic (and vice versa) is a 3d rotation
+  operation around an origin, which is the lower left corner of the
+  simulation box.  This means an input data file for a general
+  triclinic system should specify all per-atom quantities consistent
+  with the general triclinic box and its orientation relative to the
+  standard x,y,z coordinate axes.  For example, atom coordinates
+  should be inside the general triclinic simulation box defined by the
+  edge vectors **A**, **B**, **C** and its origin.  Likewise per-atom
+  velocities should be in directions consistent with the general
+  triclinic box orientation.  E.g. a velocity vector which will be in
+  the +x direction once LAMMPS converts from a general to restricted
+  triclinic box, should be specified in the data file in the direction
+  of the **A** edge vector.  See the :doc:`read_data <read_data>` doc
+  page for info on all the per-atom vector quantities to which this
+  rule applies when a data file for a general triclinic box is input.
+* If commands such as :doc:`write_data <write_data>` or :doc:`dump
+  custom <dump>` are used to output general triclinic information, it
+  is effectively the inverse of the operation described in the
+  preceding bullet.
+* Other LAMMPS commands such as :doc:`region <region>` or
+  :doc:`velocity <velocity>` or :doc:`set <set>`, operate on a
+  restricted triclinic system even if a general triclinic system was
+  defined initially.
+
+This is the list of commands which have general triclinic options:
+
+* :doc:`create_box <create_box>` - define a general triclinic box
+* :doc:`create_atoms <create_atoms>` - add atoms to a general triclinic box
+* :doc:`lattice <lattice>` - define a custom lattice consistent with the **A**, **B**, **C** edge vectors of a general triclinic box
+* :doc:`read_data <read_data>` - read a data file for a general triclinic system
+* :doc:`write_data <write_data>` - write a data file for a general triclinic system
+* :doc:`dump atom, dump custom <dump>` - output dump snapshots in general triclinic format
+* :doc:`dump_modify triclinic/general <dump_modify>` - select general triclinic format for dump output
+* :doc:`thermo_style <thermo_style>` - output the pressure tensor in
+  general triclinic format
+* :doc:`thermo_modify triclinic/general <thermo_modify>` - select general triclinic format for thermo output
+* :doc:`read_restart <read_restart>` - read a restart file for a general triclinic system
+* :doc:`write_restart <read_restart>` - write a restart file for a general triclinic system
+
+----------
+
+Transformation from general to restricted triclinic boxes
+"""""""""""""""""""""""""""""""""""""""""""""""""""""""""
+
+Let **A**,\ **B**,\ **C** be the right-handed edge vectors of a
+general triclinic simulation box.  The equivalent LAMMPS **a**,\
+**b**,\ **c** for a restricted triclinic box are a 3d rotation of
+**A**, **B**, and **C** and can be computed as follows:
 
 .. math::
 
@@ -55,23 +207,17 @@ rotation of **A**, **B**, and **C** and can be computed as follows:
   c_y = & \mathbf{C} \cdot \widehat{(\mathbf{A} \times \mathbf{B})} \times \mathbf{\hat{A}} \quad = \quad \frac{\mathbf{B} \cdot \mathbf{C} - b_x c_x}{b_y} \\
   c_z = & |\mathbf{C} \cdot \widehat{(\mathbf{A} \times \mathbf{B})}|\quad = \quad \sqrt{C^2 - {c_x}^2 - {c_y}^2}
 
-where A = \| **A** \| indicates the scalar length of **A**\ . The hat symbol (\^)
+where A = \| **A** \| indicates the scalar length of **A**\ . The hat
-indicates the corresponding unit vector. :math:`\beta` and :math:`\gamma` are angles
+symbol (\^) indicates the corresponding unit vector. :math:`\beta` and
-between the vectors described below. Note that by construction,
+:math:`\gamma` are angles between the **A**, **B**, **C** vectors
-**a**, **b**, and **c** have strictly positive x, y, and z components, respectively.
+as described below.
-If it should happen that
-**A**, **B**, and **C** form a left-handed basis, then the above equations
-are not valid for **c**\ . In this case, it is necessary
-to first apply an inversion. This can be achieved
-by interchanging two basis vectors or by changing the sign of one of them.
 
-For consistency, the same rotation/inversion applied to the basis vectors
+For consistency, the same rotation applied to the triclinic box edge
-must also be applied to atom positions, velocities,
+vectors can also be applied to atom positions, velocities, and other
-and any other vector quantities.
+vector quantities.  This can be conveniently achieved by first
-This can be conveniently achieved by first converting to
+converting to fractional coordinates in the general triclinic
-fractional coordinates in the
+coordinates and then converting to coordinates in the restricted
-old basis and then converting to distance coordinates in the new basis.
+triclinic basis.  The transformation is given by the following equation:
-The transformation is given by the following equation:
 
 .. math::
 
@@ -82,87 +228,24 @@ The transformation is given by the following equation:
       \mathbf{A \times B}
     \end{pmatrix} \cdot \mathbf{X}
 
-where *V* is the volume of the box, **X** is the original vector quantity and
+where *V* is the volume of the box (same in either basis), **X** is
-**x** is the vector in the LAMMPS basis.
+the fractional vector in the general triclinic basis and **x** is the
+resulting vector in the restricted triclinic basis.
 
-There is no requirement that a triclinic box be periodic in any
+----------
-dimension, though it typically should be in at least the second dimension
-of the tilt (y in xy) if you want to enforce a shift in periodic
-boundary conditions across that boundary.  Some commands that work
-with triclinic boxes, e.g. the :doc:`fix deform <fix_deform>` and :doc:`fix npt <fix_nh>` commands, require periodicity or non-shrink-wrap
-boundary conditions in specific dimensions.  See the command doc pages
-for details.
 
-The 9 parameters (xlo,xhi,ylo,yhi,zlo,zhi,xy,xz,yz) are defined at the
+Crystallographic general triclinic representation of a simulation box
-time the simulation box is created.  This happens in one of 3 ways.
+"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
-If the :doc:`create_box <create_box>` command is used with a region of
-style *prism*, then a triclinic box is setup.  See the
-:doc:`region <region>` command for details.  If the
-:doc:`read_data <read_data>` command is used to define the simulation
-box, and the header of the data file contains a line with the "xy xz
-yz" keyword, then a triclinic box is setup.  See the
-:doc:`read_data <read_data>` command for details.  Finally, if the
-:doc:`read_restart <read_restart>` command reads a restart file which
-was written from a simulation using a triclinic box, then a triclinic
-box will be setup for the restarted simulation.
 
-Note that you can define a triclinic box with all 3 tilt factors =
+General triclinic crystal structures are often defined using three
-0.0, so that it is initially orthogonal.  This is necessary if the box
+lattice constants *a*, *b*, and *c*, and three angles :math:`\alpha`,
-will become non-orthogonal, e.g. due to the :doc:`fix npt <fix_nh>` or
+:math:`\beta`, and :math:`\gamma`. Note that in this nomenclature, the
-:doc:`fix deform <fix_deform>` commands.  Alternatively, you can use the
+a, b, and c lattice constants are the scalar lengths of the edge
-:doc:`change_box <change_box>` command to convert a simulation box from
-orthogonal to triclinic and vice versa.
-
-As with orthogonal boxes, LAMMPS defines triclinic box size parameters
-lx,ly,lz where lx = xhi-xlo, and similarly in the y and z dimensions.
-The 9 parameters, as well as lx,ly,lz, can be output via the
-:doc:`thermo_style custom <thermo_style>` command.
-
-To avoid extremely tilted boxes (which would be computationally
-inefficient), LAMMPS normally requires that no tilt factor can skew
-the box more than half the distance of the parallel box length, which
-is the first dimension in the tilt factor (x for xz).  This is required
-both when the simulation box is created, e.g. via the
-:doc:`create_box <create_box>` or :doc:`read_data <read_data>` commands,
-as well as when the box shape changes dynamically during a simulation,
-e.g. via the :doc:`fix deform <fix_deform>` or :doc:`fix npt <fix_nh>`
-commands.
-
-For example, if xlo = 2 and xhi = 12, then the x box length is 10 and
-the xy tilt factor must be between -5 and 5.  Similarly, both xz and
-yz must be between -(xhi-xlo)/2 and +(yhi-ylo)/2.  Note that this is
-not a limitation, since if the maximum tilt factor is 5 (as in this
-example), then configurations with tilt = ..., -15, -5, 5, 15, 25,
-... are geometrically all equivalent.  If the box tilt exceeds this
-limit during a dynamics run (e.g. via the :doc:`fix deform <fix_deform>`
-command), then the box is "flipped" to an equivalent shape with a tilt
-factor within the bounds, so the run can continue.  See the :doc:`fix deform <fix_deform>` page for further details.
-
-One exception to this rule is if the first dimension in the tilt
-factor (x for xy) is non-periodic.  In that case, the limits on the
-tilt factor are not enforced, since flipping the box in that dimension
-does not change the atom positions due to non-periodicity.  In this
-mode, if you tilt the system to extreme angles, the simulation will
-simply become inefficient, due to the highly skewed simulation box.
-
-Box flips that may occur using the :doc:`fix deform <fix_deform>` or
-:doc:`fix npt <fix_nh>` commands can be turned off using the *flip no*
-option with either of the commands.
-
-Note that if a simulation box has a large tilt factor, LAMMPS will run
-less efficiently, due to the large volume of communication needed to
-acquire ghost atoms around a processor's irregular-shaped subdomain.
-For extreme values of tilt, LAMMPS may also lose atoms and generate an
-error.
-
-Triclinic crystal structures are often defined using three lattice
-constants *a*, *b*, and *c*, and three angles :math:`\alpha`,
-:math:`\beta`, and :math:`\gamma`. Note that in this nomenclature,
-the a, b, and c lattice constants are the scalar lengths of the edge
 vectors **a**, **b**, and **c** defined above.  The relationship
 between these 6 quantities (a, b, c, :math:`\alpha`, :math:`\beta`,
-:math:`\gamma`) and the LAMMPS box sizes (lx,ly,lz) =
+:math:`\gamma`) and the LAMMPS restricted triclinic box sizes
-(xhi-xlo,yhi-ylo,zhi-zlo) and tilt factors (xy,xz,yz) is as follows:
+(lx,ly,lz) = (xhi-xlo,yhi-ylo,zhi-zlo) and tilt factors (xy,xz,yz) is
+as follows:
 
 .. math::
 
@@ -186,15 +269,19 @@ The inverse relationship can be written as follows:
 
 The values of *a*, *b*, *c*, :math:`\alpha` , :math:`\beta`, and
 :math:`\gamma` can be printed out or accessed by computes using the
-:doc:`thermo_style custom <thermo_style>` keywords
+:doc:`thermo_style custom <thermo_style>` keywords *cella*, *cellb*,
-*cella*, *cellb*, *cellc*, *cellalpha*, *cellbeta*, *cellgamma*,
+*cellc*, *cellalpha*, *cellbeta*, *cellgamma*, respectively.
-respectively.
+
+----------
+
+Output of restricted and general triclinic boxes in a dump file
+"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 
 As discussed on the :doc:`dump <dump>` command doc page, when the BOX
-BOUNDS for a snapshot is written to a dump file for a triclinic box,
+BOUNDS for a snapshot is written to a dump file for a restricted
-an orthogonal bounding box which encloses the triclinic simulation box
+triclinic box, an orthogonal bounding box which encloses the triclinic
-is output, along with the 3 tilt factors (xy, xz, yz) of the triclinic
+simulation box is output, along with the 3 tilt factors (xy, xz, yz) of
-box, formatted as follows:
+the restricted triclinic box, formatted as follows:
 
 .. parsed-literal::
 
@@ -204,7 +291,7 @@ box, formatted as follows:
    zlo_bound zhi_bound yz
 
 This bounding box is convenient for many visualization programs and is
-calculated from the 9 triclinic box parameters
+calculated from the 9 restricted triclinic box parameters
 (xlo,xhi,ylo,yhi,zlo,zhi,xy,xz,yz) as follows:
 
 .. parsed-literal::
@@ -217,22 +304,66 @@ calculated from the 9 triclinic box parameters
    zhi_bound = zhi
 
 These formulas can be inverted if you need to convert the bounding box
-back into the triclinic box parameters, e.g. xlo = xlo_bound -
+back into the restricted triclinic box parameters, e.g. xlo =
-MIN(0.0,xy,xz,xy+xz).
+xlo_bound - MIN(0.0,xy,xz,xy+xz).
 
-One use of triclinic simulation boxes is to model solid-state crystals
+----------
-with triclinic symmetry.  The :doc:`lattice <lattice>` command can be
-used with non-orthogonal basis vectors to define a lattice that will
-tile a triclinic simulation box via the
-:doc:`create_atoms <create_atoms>` command.
 
-A second use is to run Parrinello-Rahman dynamics via the :doc:`fix npt <fix_nh>` command, which will adjust the xy, xz, yz tilt
+Periodicity and tilt factors for triclinic simulation boxes
-factors to compensate for off-diagonal components of the pressure
+"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
-tensor.  The analog for an :doc:`energy minimization <minimize>` is
-the :doc:`fix box/relax <fix_box_relax>` command.
 
-A third use is to shear a bulk solid to study the response of the
+There is no requirement that a triclinic box be periodic in any
-material.  The :doc:`fix deform <fix_deform>` command can be used for
+dimension, though it typically should be in y or z if you wish to
-this purpose.  It allows dynamic control of the xy, xz, yz tilt
+enforce a shift in coordinates due to periodic boundary conditions
-factors as a simulation runs.  This is discussed in the next section
+across the y or z boundaries.  See the doc page for the :doc:`boundary
-on non-equilibrium MD (NEMD) simulations.
+<boundary>` command for an explanation of shifted coordinates for
+restricted triclinic boxes which are periodic.
+
+Some commands that work with triclinic boxes, e.g. the :doc:`fix
+deform <fix_deform>` and :doc:`fix npt <fix_nh>` commands, require
+periodicity or non-shrink-wrap boundary conditions in specific
+dimensions.  See the command doc pages for details.
+
+A restricted triclinic box can be defined with all 3 tilt factors =
+0.0, so that it is initially orthogonal.  This is necessary if the box
+will become non-orthogonal, e.g. due to use of the :doc:`fix npt
+<fix_nh>` or :doc:`fix deform <fix_deform>` commands.  Alternatively,
+you can use the :doc:`change_box <change_box>` command to convert a
+simulation box from orthogonal to restricted triclinic and vice versa.
+
+.. note::
+
+   Highly tilted restricted triclinic simulation boxes can be
+   computationally inefficient.  This is due to the large volume of
+   communication needed to acquire ghost atoms around a processor's
+   irregular-shaped subdomain.  For extreme values of tilt, LAMMPS may
+   also lose atoms and generate an error.
+
+LAMMPS will issue a warning if you define a restricted triclinic box
+with a tilt factor which skews the box more than half the distance of
+the parallel box length, which is the first dimension in the tilt
+factor (e.g. x for xz).
+
+For example, if xlo = 2 and xhi = 12, then the x box length is 10 and
+the xy tilt factor should be between -5 and 5 to avoid the warning.
+Similarly, both xz and yz should be between -(xhi-xlo)/2 and
++(yhi-ylo)/2.  Note that these are not limitations, since if the
+maximum tilt factor is 5 (as in this example), then simulations boxes
+and atom configurations with tilt = ..., -15, -5, 5, 15, 25, ... are
+all geometrically equivalent.
+
+If the box tilt exceeds this limit during a dynamics run (e.g. due to
+the :doc:`fix deform <fix_deform>` command), then by default the box
+is "flipped" to an equivalent shape with a tilt factor within the
+warning bounds, and the run continues.  See the :doc:`fix deform
+<fix_deform>` page for further details.  Box flips that would normally
+occur using the :doc:`fix deform <fix_deform>` or :doc:`fix npt
+<fix_nh>` commands can be suppressed using the *flip no* option with
+either of the commands.
+
+One exception to box flipping is if the first dimension in the tilt
+factor (e.g. x for xy) is non-periodic.  In that case, the limits on
+the tilt factor are not enforced, since flipping the box in that
+dimension would not change the atom positions due to non-periodicity.
+In this mode, if the system tilts to large angles, the simulation will
+simply become inefficient, due to the highly skewed simulation box.

doc/src/Howto_type_labels.rst

@@ -14,16 +14,17 @@ wherever they appear in LAMMPS input or output files.  The total number
 Ntypes for each interaction is "locked in" when the simulation box
 is created.
 
-A recent addition to LAMMPS is the option to use strings - referred
+A recent addition to LAMMPS is the option to use strings - referred to
-to as type labels - as an alternative.  Using type labels instead of
+as type labels - as an alternative.  Using type labels instead of
 numeric types can be advantageous in various scenarios.  For example,
-type labels can make inputs more readable and generic (i.e. usable through
+type labels can make inputs more readable and generic (i.e. usable
-the :doc:`include command <include>` for different systems with different
+through the :doc:`include command <include>` for different systems with
-numerical values assigned to types.  This generality also applies to
+different numerical values assigned to types.  This generality also
-other inputs like data files read by :doc:`read_data <read_data>` or
+applies to other inputs like data files read by :doc:`read_data
-molecule template files read by the :doc:`molecule <molecule>`
+<read_data>` or molecule template files read by the :doc:`molecule
-command.  See below for a list of other commands that can use
+<molecule>` command.  A discussion of the current type label support can
-type labels in different ways.
+be found in :ref:`(Gissinger) <Typelabel24>`.  See below for a list of
+other commands that can use type labels in different ways.
 
 LAMMPS will *internally* continue to use numeric types, which means
 that many previous restrictions still apply.  For example, the total
@@ -124,3 +125,9 @@ between the files.  The creation of simulation-ready reaction templates
 for :doc:`fix bond/react <fix_bond_react>` is much simpler when using
 type labels, and results in templates that can be used without
 modification in multiple simulations or different systems.
+
+-----------
+
+.. _Typelabel24:
+
+**(Gissinger)** J. R. Gissinger, I. Nikiforov, Y. Afshar, B. Waters, M. Choi, D. S. Karls, A. Stukowski, W. Im, H. Heinz, A. Kohlmeyer, and E. B. Tadmor, J Phys Chem B, 128, 3282-3297 (2024).

doc/src/Intro_citing.rst

@@ -47,6 +47,8 @@ In addition there are DOIs generated for individual stable releases:
 - 3 March 2020 version: `DOI:10.5281/zenodo.3726417 <https://dx.doi.org/10.5281/zenodo.3726417>`_
 - 29 October 2020 version: `DOI:10.5281/zenodo.4157471 <https://dx.doi.org/10.5281/zenodo.4157471>`_
 - 29 September 2021 version: `DOI:10.5281/zenodo.6386596 <https://dx.doi.org/10.5281/zenodo.6386596>`_
+- 23 June 2022 version: `DOI:10.5281/zenodo.10806836 <https://doi.org/10.5281/zenodo.10806836>`_
+- 2 August 2023 version: `DOI:10.5281/zenodo.10806852 <https://doi.org/10.5281/zenodo.10806852>`_
 
 Home page
 ^^^^^^^^^

doc/src/Intro_features.rst

@@ -29,7 +29,7 @@ General features
 * spatial decomposition of simulation domain for MPI parallelism
 * particle decomposition inside spatial decomposition for OpenMP and GPU parallelism
 * GPLv2 licensed open-source distribution
-* highly portable C++-11
+* highly portable C++-11 (optional packages may require C++17)
 * modular code with most functionality in optional packages
 * only depends on MPI library for basic parallel functionality, MPI stub for serial compilation
 * other libraries are optional and only required for specific packages
@@ -81,7 +81,7 @@ commands)
 * pairwise potentials: Lennard-Jones, Buckingham, Morse, Born-Mayer-Huggins, Yukawa, soft, Class II (COMPASS), hydrogen bond, harmonic, gaussian, tabulated, scripted
 * charged pairwise potentials: Coulombic, point-dipole
 * many-body potentials: EAM, Finnis/Sinclair, MEAM, MEAM+SW, EIM, EDIP, ADP, Stillinger-Weber, Tersoff, REBO, AIREBO, ReaxFF, COMB, Streitz-Mintmire, 3-body polymorphic, BOP, Vashishta
-* machine learning potentials: ACE, AGNI, GAP, Behler-Parrinello (N2P2), POD, RANN
+* machine learning potentials: ACE, AGNI, GAP, Behler-Parrinello (N2P2), POD, RANN, SNAP
 * interfaces to ML potentials distributed by external groups: ANI, ChIMES, DeepPot, HIPNN, MTP
 * long-range interactions for charge, point-dipoles, and LJ dispersion:  Ewald, Wolf, PPPM (similar to particle-mesh Ewald), MSM, ScaFaCoS
 * polarization models: :doc:`QEq <fix_qeq>`, :doc:`core/shell model <Howto_coreshell>`, :doc:`Drude dipole model <Howto_drude>`

doc/src/Python_scatter.rst

@@ -56,6 +56,19 @@ like this:
    x[n3-1] = z coord of atom with ID natoms
    lmp.scatter_atoms("x", 1, 3, x)
 
+The coordinates can also be provided as arguments to the initializer of x:
+
+.. code-block:: python
+
+   from ctypes import c_double
+   natoms = 2
+   n3 = 3*natoms
+   # init in constructor
+   x = (n3*c_double)(0.0, 0.0, 0.0, 1.0, 1.0, 1.0)
+   lmp.scatter_atoms("x", 1, 3, x)
+   # or using a list
+   coords = [1.0, 2.0, 3.0, -3.0, -2.0, -1.0]
+   x = (c_double*len(coords))(*coords)
+
 Alternatively, you can just change values in the vector returned by
 the gather methods, since they are also ctypes vectors.
-

doc/src/Speed_kokkos.rst

@@ -20,11 +20,28 @@ including Sikandar Mashayak (UIUC), Ray Shan (Sandia), and Dan Ibanez
 (Sandia). For more information on developing using Kokkos abstractions
 see the `Kokkos Wiki <https://github.com/kokkos/kokkos/wiki>`_.
 
-Kokkos currently provides support for 4 modes of execution (per MPI
+.. note::
+
+   The Kokkos library is under active development and tracking the
+   availability of accelerator hardware, so is the KOKKOS package in
+   LAMMPS.  This means that only a certain range of versions of the
+   Kokkos library are compatible with the KOKKOS package of a certain
+   range of LAMMPS versions.  For that reason LAMMPS comes with a
+   bundled version of the Kokkos library that has been validated on
+   multiple platforms and may contain selected back-ported bug fixes
+   from upstream Kokkos versions.  While it is possible to build LAMMPS
+   with an external version of Kokkos, it is untested and may result in
+   incorrect execution or crashes.
+
+Kokkos currently provides full support for 4 modes of execution (per MPI
 task). These are Serial (MPI-only for CPUs and Intel Phi), OpenMP
-(threading for many-core CPUs and Intel Phi), CUDA (for NVIDIA
+(threading for many-core CPUs and Intel Phi), CUDA (for NVIDIA GPUs) and
-GPUs) and HIP (for AMD GPUs). You choose the mode at build time to
+HIP (for AMD GPUs).  Additional modes (e.g. OpenMP target, Intel data
-produce an executable compatible with a specific hardware.
+center GPUs) are under development.  You choose the mode at build time
+to produce an executable compatible with a specific hardware.
+
+The following compatibility notes have been last updated for LAMMPS
+version 23 November 2023 and Kokkos version 4.2.
 
 .. admonition:: C++17 support
    :class: note
@@ -63,13 +80,13 @@ produce an executable compatible with a specific hardware.
    LAMMPS command line or by using the command :doc:`package kokkos
    gpu/aware off <package>` in the input file.
 
-.. admonition:: AMD GPU support
+.. admonition:: Intel Data Center GPU support
    :class: note
 
-   To build with Kokkos the HIPCC compiler from the AMD ROCm software
+   Support for Kokkos with Intel Data Center GPU accelerators (formerly
-   version 3.5 or later is required.  Supporting this Kokkos mode in
+   known under the code name "Ponte Vecchio") in LAMMPS is still a work
-   LAMMPS is still work in progress.  Please contact the LAMMPS developers
+   in progress.  Only a subset of the functionality works correctly.
-   if you run into problems.
+   Please contact the LAMMPS developers if you run into problems.
 
 Building LAMMPS with the KOKKOS package
 """""""""""""""""""""""""""""""""""""""
@@ -292,6 +309,10 @@ one or more nodes, each with two GPUs:
    settings. Experimenting with its options can provide a speed-up for
    specific calculations. For example:
 
+.. code-block:: bash
+
+   mpirun -np 2 lmp_kokkos_cuda_openmpi -k on g 2 -sf kk -pk kokkos newton on neigh half binsize 2.8 -in in.lj      # Newton on, half neighbor list, set binsize = neighbor ghost cutoff
+
 .. note::
 
    The default binsize for :doc:`atom sorting <atom_modify>` on GPUs
@@ -302,9 +323,15 @@ one or more nodes, each with two GPUs:
    frequent sorting than default (e.g. sorting every 100 time steps
    instead of 1000) may improve performance.
 
-.. code-block:: bash
+.. note::
 
-   mpirun -np 2 lmp_kokkos_cuda_openmpi -k on g 2 -sf kk -pk kokkos newton on neigh half binsize 2.8 -in in.lj      # Newton on, half neighbor list, set binsize = neighbor ghost cutoff
+   When running on GPUs with many MPI ranks (tens of thousands and
+   more), the creation of the atom map (required for molecular systems)
+   on the GPU can slow down significantly or run out of GPU memory and
+   thus slow down the whole calculation or cause a crash.  You can use
+   the "-pk kokkos atom/map no" :doc:`command-line switch <Run_options>`
+   of the :doc:`package kokkos atom/map no <package>` command to create
+   the atom map on the CPU instead.
 
 .. note::
 
@@ -420,11 +447,18 @@ Generally speaking, the following rules of thumb apply:
   of using single or mixed precision with the GPU package depends
   significantly on the hardware in use and the simulated system and pair
   style.
-* When running on Intel hardware, KOKKOS is not as fast as
+* When running on Intel Phi hardware, KOKKOS is not as fast as
   the INTEL package, which is optimized for x86 hardware (not just
   from Intel) and compilation with the Intel compilers.  The INTEL
   package also can increase the vector length of vector instructions
   by switching to single or mixed precision mode.
+* The KOKKOS package by default assumes that you are using exactly one
+  MPI rank per GPU. When trying to use multiple MPI ranks per GPU it is
+  mandatory to enable `CUDA Multi-Process Service (MPS)
+  <https://docs.nvidia.com/deploy/mps/index.html>`_ to get good
+  performance.  In this case it is better to not use all available
+  MPI ranks in order to avoid competing with the MPS daemon for
+  CPU resources.
 
 See the `Benchmark page <https://www.lammps.org/bench.html>`_ of the
 LAMMPS website for performance of the KOKKOS package on different

doc/src/angle_cosine_squared_restricted.rst

@@ -0,0 +1,80 @@
+.. index:: angle_style cosine/squared/restricted
+.. index:: angle_style cosine/squared/restricted/omp
+
+angle_style cosine/squared/restricted command
+=============================================
+
+Accelerator Variants: *cosine/squared/restricted/omp*
+
+Syntax
+""""""
+
+.. code-block:: LAMMPS
+
+   angle_style cosine/squared/restricted
+
+Examples
+""""""""
+
+.. code-block:: LAMMPS
+
+   angle_style cosine/squared/restricted
+   angle_coeff 2*4 75.0 100.0
+
+Description
+"""""""""""
+
+.. versionadded:: 17Apr2024
+
+The *cosine/squared/restricted* angle style uses the potential
+
+.. math::
+
+   E = K [\cos(\theta) - \cos(\theta_0)]^2 / \sin^2(\theta)
+
+, which is commonly used in the MARTINI force field,
+where :math:`\theta_0` is the equilibrium value of the angle, and :math:`K`
+is a prefactor.  Note that the usual 1/2 factor is included in :math:`K`.
+
+See :ref:`(Bulacu) <restricted-Bulacu>` for a description of the restricted angle for the MARTINI force field.
+
+The following coefficients must be defined for each angle type via the
+:doc:`angle_coeff <angle_coeff>` command as in the example above, or in
+the data file or restart files read by the :doc:`read_data <read_data>`
+or :doc:`read_restart <read_restart>` commands:
+
+* :math:`K` (energy)
+* :math:`\theta_0` (degrees)
+
+:math:`\theta_0` is specified in degrees, but LAMMPS converts it to radians
+internally.
+
+----------
+
+.. include:: accel_styles.rst
+
+----------
+
+Restrictions
+""""""""""""
+
+This angle style can only be used if LAMMPS was built with the
+EXTRA-MOLECULE package.  See the :doc:`Build package <Build_package>` doc page
+for more info.
+
+Related commands
+""""""""""""""""
+
+:doc:`angle_coeff <angle_coeff>`
+
+Default
+"""""""
+
+none
+
+----------
+
+.. _restricted-Bulacu:
+
+**(Bulacu)** Bulacu, Goga, Zhao, Rossi, Monticelli, Periole, Tieleman, Marrink, J Chem Theory Comput, 9, 3282-3292
+(2013).

doc/src/angle_style.rst

@@ -10,7 +10,7 @@ Syntax
 
    angle_style style
 
-* style = *none* or *zero* or *hybrid* or *amoeba* or *charmm* or *class2* or *class2/p6* or *cosine* or *cosine/buck6d* or *cosine/delta* or *cosine/periodic* or *cosine/shift* or *cosine/shift/exp* or *cosine/squared* or *cross* or *dipole* or *fourier* or *fourier/simple* or *gaussian* or *harmonic* or *lepton* or *mm3* or *quartic* or *spica* or *table*
+* style = *none* or *zero* or *hybrid* or *amoeba* or *charmm* or *class2* or *class2/p6* or *cosine* or *cosine/buck6d* or *cosine/delta* or *cosine/periodic* or *cosine/shift* or *cosine/shift/exp* or *cosine/squared* or *cosine/squared/restricted* or *cross* or *dipole* or *fourier* or *fourier/simple* or *gaussian* or *harmonic* or *lepton* or *mm3* or *quartic* or *spica* or *table*
 
 Examples
 """"""""
@@ -84,6 +84,7 @@ of (g,i,k,o,t) to indicate which accelerated styles exist.
 * :doc:`cosine/shift <angle_cosine_shift>` - angle cosine with a shift
 * :doc:`cosine/shift/exp <angle_cosine_shift_exp>` - cosine with shift and exponential term in spring constant
 * :doc:`cosine/squared <angle_cosine_squared>` - angle with cosine squared term
+* :doc:`cosine/squared/restricted <angle_cosine_squared_restricted>` - angle with restricted cosine squared term
 * :doc:`cross <angle_cross>` - cross term coupling angle and bond lengths
 * :doc:`dipole <angle_dipole>` - angle that controls orientation of a point dipole
 * :doc:`fourier <angle_fourier>` - angle with multiple cosine terms

doc/src/atom_style.rst

@@ -283,21 +283,22 @@ Note that there may be additional arguments required along with the
 arguments are described on the :doc:`Howto body <Howto_body>` doc page.
 
 For the *dielectric* style, each particle can be either a physical
-particle (e.g. an ion), or an interface particle representing a boundary
+particle (e.g. an ion), or an interface particle representing a
-element between two regions of different dielectric constant. For
+boundary element between two regions of different dielectric
-interface particles, in addition to the properties associated with
+constant. For interface particles, in addition to the properties
-atom_style full, each particle also should be assigned a normal unit
+associated with atom_style full, each particle also should be assigned
-vector (defined by normx, normy, normz), an area (area/patch), the
+a unit dipole vector (mu) representing the direction of the induced
+dipole moment at each interface particle, an area (area/patch), the
 difference and mean of the dielectric constants of two sides of the
 interface along the direction of the normal vector (ed and em), the
-local dielectric constant at the boundary element (epsilon), and a mean
+local dielectric constant at the boundary element (epsilon), and a
-local curvature (curv).  Physical particles must be assigned these
+mean local curvature (curv).  Physical particles must be assigned
-values, as well, but only their local dielectric constants will be used;
+these values, as well, but only their local dielectric constants will
-see documentation for associated :doc:`pair styles <pair_dielectric>`
+be used; see documentation for associated :doc:`pair styles
-and :doc:`fixes <fix_polarize>`.  The distinction between the physical
+<pair_dielectric>` and :doc:`fixes <fix_polarize>`.  The distinction
-and interface particles is only meaningful when :doc:`fix polarize
+between the physical and interface particles is only meaningful when
-<fix_polarize>` commands are applied to the interface particles. This
+:doc:`fix polarize <fix_polarize>` commands are applied to the
-style is part of the DIELECTRIC package.
+interface particles. This style is part of the DIELECTRIC package.
 
 For the *dipole* style, a point dipole vector mu is defined for each
 point particle.  Note that if you wish the particles to be finite-size

doc/src/boundary.rst

@@ -42,8 +42,10 @@ commands.
 The style *p* means the box is periodic, so that particles interact
 across the boundary, and they can exit one end of the box and re-enter
 the other end.  A periodic dimension can change in size due to
-constant pressure boundary conditions or box deformation (see the :doc:`fix npt <fix_nh>` and :doc:`fix deform <fix_deform>` commands).  The *p*
+constant pressure boundary conditions or box deformation (see the
-style must be applied to both faces of a dimension.
+:doc:`fix npt <fix_nh>` and :doc:`fix deform <fix_deform>` commands).
+The *p* style must be applied to both faces of a dimension.  For 2d
+simulations the z dimension must be periodic (which is the default).
 
 The styles *f*, *s*, and *m* mean the box is non-periodic, so that
 particles do not interact across the boundary and do not move from one
@@ -76,28 +78,44 @@ atoms becomes less than 50.0.  This can be useful if you start a
 simulation with an empty box or if you wish to leave room on one side
 of the box, e.g. for atoms to evaporate from a surface.
 
-For triclinic (non-orthogonal) simulation boxes, if the second dimension
+LAMMPS also allows use of triclinic (non-orthogonal) simulation boxes.
-of a tilt factor (e.g. y for xy) is periodic, then the periodicity is
-enforced with the tilt factor offset.  If the first dimension is
-shrink-wrapped, then the shrink wrapping is applied to the tilted box
-face, to encompass the atoms.  E.g. for a positive xy tilt, the xlo
-and xhi faces of the box are planes tilting in the +y direction as y
-increases.  These tilted planes are shrink-wrapped around the atoms to
-determine the x extent of the box.
-
 See the :doc:`Howto triclinic <Howto_triclinic>` page for a
-geometric description of triclinic boxes, as defined by LAMMPS, and
+description of both general and restricted triclinic boxes and how to
-how to transform these parameters to and from other commonly used
+define them.  General triclinic boxes (arbitrary edge vectors **A**,
-triclinic representations.
+**B**, and **C**) are converted internally to restricted triclinic
+boxes with tilt factors (xy,xz,yz) which skew an otherwise orthogonal
+box.
+
+The boundary <boundary> command settings explained above for the 6
+faces of an orthogonal box also apply in similar manner to the 6 faces
+of a restricted triclinic box (and thus to the corresponding 6 faces
+of a general triclinic box), with the following context.
+
+if the second dimension of a tilt factor (e.g. y for xy) is periodic,
+then the periodicity is enforced with the tilt factor offset.  This
+means that for y periodicity a particle which exits the lower y
+boundary is displaced in the x-direction by xy before it re-enters the
+upper y boundary.  And vice versa if a particle exits the upper y
+boundary.  Likewise the ghost atoms surrounding a particle near the
+lower y boundary include images of particles near the upper y-boundary
+which are displaced in the x-direction by xy.  Similar rules apply for
+z-periodicity and the xz and/or yz tilt factors.
+
+If the first dimension of a tilt factor is shrink-wrapped, then the
+shrink wrapping is applied to the tilted box face, to encompass the
+atoms.  E.g. for a positive xy tilt, the xlo and xhi faces of the box
+are planes tilting in the +y direction as y increases.  The position
+of these tilted planes are adjusted dynamically to shrink-wrap around
+the atoms to determine the xlo and xhi extents of the box.
 
 Restrictions
 """"""""""""
 
 This command cannot be used after the simulation box is defined by a
-:doc:`read_data <read_data>` or :doc:`create_box <create_box>` command or
+:doc:`read_data <read_data>` or :doc:`create_box <create_box>` command
-:doc:`read_restart <read_restart>` command.  See the
+or :doc:`read_restart <read_restart>` command.  See the
-:doc:`change_box <change_box>` command for how to change the simulation
+:doc:`change_box <change_box>` command for how to change the
-box boundaries after it has been defined.
+simulation box boundaries after it has been defined.
 
 For 2d simulations, the z dimension must be periodic.
 

doc/src/compute_adf.rst

@@ -204,8 +204,23 @@ angles per atom satisfying the ADF criteria.
 Restrictions
 """"""""""""
 
-This compute is part of the EXTRA-COMPUTE package.  It is only enabled if
+This compute is part of the EXTRA-COMPUTE package.  It is only enabled
-LAMMPS was built with that package.  See the :doc:`Build package <Build_package>` page for more info.
+if LAMMPS was built with that package.  See the :doc:`Build package
+<Build_package>` page for more info.
+
+By default, the ADF is not computed for distances longer than the
+largest force cutoff, since the neighbor list creation will only contain
+pairs up to that distance (plus neighbor list skin).  If you use outer
+cutoffs larger than that, you must use :doc:`neighbor style 'bin' or
+'nsq' <neighbor>`.
+
+If you want an ADF for a larger outer cutoff, you can also use the
+:doc:`rerun <rerun>` command to post-process a dump file, use :doc:`pair
+style zero <pair_zero>` and set the force cutoff to be larger in the
+rerun script.  Note that in the rerun context, the force cutoff is
+arbitrary and with pair style zero you are not computing any forces, and
+since you are not running dynamics you are not changing the model that
+generated the trajectory.
 
 The ADF is not computed for neighbors outside the force cutoff,
 since processors (in parallel) don't know about atom coordinates for

doc/src/compute_ave_sphere_atom.rst

@@ -102,6 +102,8 @@ This compute is part of the EXTRA-COMPUTE package.  It is only enabled
 if LAMMPS was built with that package.  See the :doc:`Build package
 <Build_package>` page for more info.
 
+This compute requires :doc:`neighbor styles 'bin' or 'nsq' <neighbor>`.
+
 Related commands
 """"""""""""""""
 

doc/src/compute_composition_atom.rst

@@ -107,6 +107,8 @@ This compute is part of the EXTRA-COMPUTE package.  It is only enabled
 if LAMMPS was built with that package.  See the :doc:`Build package
 <Build_package>` page for more info.
 
+This compute requires :doc:`neighbor styles 'bin' or 'nsq' <neighbor>`.
+
 Related commands
 """"""""""""""""
 

doc/src/compute_count_type.rst

@@ -12,7 +12,7 @@ Syntax
 
 * ID, group-ID are documented in :doc:`compute <compute>` command
 * count/type = style name of this compute command
-* mode = {atom} or {bond} or {angle} or {dihedral} or {improper}
+* mode = *atom* or *bond* or *angle* or *dihedral* or *improper*
 
 Examples
 """"""""
@@ -69,29 +69,42 @@ for each type:
 
 ----------
 
-If the {mode} setting is {atom} then the count of atoms for each atom
+If the *mode* setting is *atom* then the count of atoms for each atom
 type is tallied.  Only atoms in the specified group are counted.
 
-If the {mode} setting is {bond} then the count of bonds for each bond
+The atom count for each type can be normalized by the total number of
+atoms like so:
+
+.. code-block:: LAMMPS
+
+   compute typevec all count/type atom # number of atoms of each type
+   variable normtypes vector c_typevec/atoms # divide by total number of atoms
+   variable ntypes equal extract_setting(ntypes) # number of atom types
+   thermo_style custom step v_normtypes[*${ntypes}] # vector variable needs upper limit
+
+Similarly, bond counts can be normalized by the total number of bonds.
+The same goes for angles, dihedrals, and impropers (see below).
+
+If the *mode* setting is *bond* then the count of bonds for each bond
 type is tallied.  Only bonds with both atoms in the specified group
 are counted.
 
-For {mode} = {bond}, broken bonds with a bond type of zero are also
+For *mode* = *bond*, broken bonds with a bond type of zero are also
 counted.  The :doc:`bond_style quartic <bond_quartic>` and :doc:`BPM
-bond styles <Howto_bpm>` break bonds by doing this.  See the :doc:`
+bond styles <Howto_bpm>` break bonds by doing this.  See the
-Howto broken bonds <Howto_broken_bonds>` doc page for more details.
+:doc:`Howto broken bonds <Howto_broken_bonds>` doc page for more details.
 Note that the group setting is ignored for broken bonds; all broken
 bonds in the system are counted.
 
-If the {mode} setting is {angle} then the count of angles for each
+If the *mode* setting is *angle* then the count of angles for each
 angle type is tallied.  Only angles with all 3 atoms in the specified
 group are counted.
 
-If the {mode} setting is {dihedral} then the count of dihedrals for
+If the *mode* setting is *dihedral* then the count of dihedrals for
 each dihedral type is tallied.  Only dihedrals with all 4 atoms in the
 specified group are counted.
 
-If the {mode} setting is {improper} then the count of impropers for
+If the *mode* setting is *improper* then the count of impropers for
 each improper type is tallied.  Only impropers with all 4 atoms in the
 specified group are counted.
 
@@ -101,18 +114,19 @@ Output info
 """""""""""
 
 This compute calculates a global vector of counts.  If the mode is
-{atom} or {bond} or {angle} or {dihedral} or {improper}, then the
+*atom* or *bond* or *angle* or *dihedral* or *improper*, then the
 vector length is the number of atom types or bond types or angle types
 or dihedral types or improper types, respectively.
 
-If the mode is {bond} this compute also calculates a global scalar
+If the mode is *bond* this compute also calculates a global scalar
 which is the number of broken bonds with type = 0, as explained above.
 
 These values can be used by any command that uses global scalar or
 vector values from a compute as input.  See the :doc:`Howto output
 <Howto_output>` page for an overview of LAMMPS output options.
 
-The scalar and vector values calculated by this compute are "extensive".
+The scalar and vector values calculated by this compute are both
+"intensive".
 
 Restrictions
 """"""""""""

doc/src/compute_efield_wolf_atom.rst

@@ -106,6 +106,8 @@ Restrictions
 This compute is part of the EXTRA-COMPUTE package. It is only enabled if
 LAMMPS was built with that package.
 
+This compute requires :doc:`neighbor styles 'bin' or 'nsq' <neighbor>`.
+
 Related commands
 """"""""""""""""
 

doc/src/compute_fabric.rst

@@ -64,7 +64,7 @@ tangential force tensor. The contact tensor is calculated as
 
 .. math::
 
-   C_{ab}  =  \frac{15}{2} (\phi_{ab} - \mathrm{Tr}(\phi) \delta_{ab})
+   C_{ab}  =  \frac{15}{2} (\phi_{ab} - \frac{1}{3} \mathrm{Tr}(\phi) \delta_{ab})
 
 where :math:`a` and :math:`b` are the :math:`x`, :math:`y`, :math:`z`
 directions, :math:`\delta_{ab}` is the Kronecker delta function, and
@@ -83,7 +83,7 @@ The branch tensor is calculated as
 
 .. math::
 
-   B_{ab}  =  \frac{15}{6 \mathrm{Tr}(D)} (D_{ab} - \mathrm{Tr}(D) \delta_{ab})
+   B_{ab}  =  \frac{15}{2\, \mathrm{Tr}(D)} (D_{ab} - \frac{1}{3} \mathrm{Tr}(D) \delta_{ab})
 
 where the tensor :math:`D` is defined as
 
@@ -101,7 +101,7 @@ The normal force fabric tensor is calculated as
 
 .. math::
 
-   F^n_{ab}  =  \frac{15}{6\, \mathrm{Tr}(N)} (N_{ab} - \mathrm{Tr}(N) \delta_{ab})
+   F^n_{ab}  =  \frac{15}{2\, \mathrm{Tr}(N)} (N_{ab} - \frac{1}{3} \mathrm{Tr}(N) \delta_{ab})
 
 where the tensor :math:`N` is defined as
 
@@ -119,7 +119,7 @@ as
 
 .. math::
 
-   F^t_{ab}  =  \frac{15}{9\, \mathrm{Tr}(N)} (T_{ab} - \mathrm{Tr}(T) \delta_{ab})
+   F^t_{ab}  =  \frac{5}{\mathrm{Tr}(N)} (T_{ab} - \frac{1}{3} \mathrm{Tr}(T) \delta_{ab})
 
 where the tensor :math:`T` is defined as
 

doc/src/compute_mliap.rst

@@ -20,7 +20,7 @@ Syntax
        *model* values = style
          style = *linear* or *quadratic* or *mliappy*
        *descriptor* values = style filename
-         style = *sna*
+         style = *sna* or *ace*
          filename = name of file containing descriptor definitions
        *gradgradflag* value = 0/1
          toggle gradgrad method for force gradient
@@ -31,6 +31,7 @@ Examples
 .. code-block:: LAMMPS
 
    compute mliap model linear descriptor sna Ta06A.mliap.descriptor
+   compute mliap model linear descriptor ace H_N_O_ccs.yace gradgradflag 1
 
 Description
 """""""""""
@@ -40,18 +41,15 @@ of machine-learning interatomic potentials with respect to model parameters.
 It is used primarily for calculating the gradient of energy, force, and
 stress components with respect to model parameters, which is useful when
 training :doc:`mliap pair_style <pair_mliap>` models to match target data.
-It provides separate
+It provides separate definitions of the interatomic potential functional
-definitions of the interatomic potential functional form (*model*)
+form (*model*) and the geometric quantities that characterize the atomic
-and the geometric quantities that characterize the atomic positions
+positions (*descriptor*). By defining *model* and *descriptor* separately,
-(*descriptor*). By defining *model* and *descriptor* separately,
 it is possible to use many different models with a given descriptor,
-or many different descriptors with a given model. Currently, the
+or many different descriptors with a given model. Currently, the compute
-compute supports just two models, *linear* and *quadratic*,
+supports *linear* and *quadratic* SNAP descriptor computes used in
-and one descriptor, *sna*, the SNAP descriptor used by
+:doc:`pair_style snap <pair_snap>`, *linear* SO3 descriptor computes, and
-:doc:`pair_style snap <pair_snap>`, including the linear, quadratic,
+*linear* ACE descriptor computes used in :doc:`pair_style pace <pair_pace>`,
-and chem variants. Work is currently underway to extend
+and it is straightforward to add new descriptor styles.
-the interface to handle neural network energy models,
-and it is also straightforward to add new descriptor styles.
 
 The compute *mliap* command must be followed by two keywords
 *model* and *descriptor* in either order.
@@ -60,19 +58,31 @@ The *model* keyword is followed by the model style (*linear*,
 *quadratic* or *mliappy*).  The *mliappy* model is only available if
 LAMMPS is built with the *mliappy* Python module. There are
 :ref:`specific installation instructions <mliap>` for that module.
+For the *mliap* compute, specifying a *linear* model will compute the
+specified descriptors and gradients with respect to linear model parameters
+whereas *quadratic* will do the same, but for the quadratic products of
+descriptors.
 
 The *descriptor* keyword is followed by a descriptor style, and
-additional arguments.  The compute currently supports two descriptor
+additional arguments.  The compute currently supports three descriptor
-styles *sna* and *so3*, but it is is straightforward to add additional
+styles: *sna*, *so3*, and *ace*, but it is is straightforward to add
-descriptor styles.  The SNAP descriptor style *sna* is the same as that
+additional descriptor styles.  The SNAP descriptor style *sna* is the
-used by :doc:`pair_style snap <pair_snap>`, including the linear,
+same as that used by :doc:`pair_style snap <pair_snap>`, including the
-quadratic, and chem variants.  A single additional argument specifies
+linear, quadratic, and chem variants.  A single additional argument
-the descriptor filename containing the parameters and setting used by
+specifies the descriptor filename containing the parameters and setting used
-the SNAP descriptor.  The descriptor filename usually ends in the
+by the SNAP descriptor.  The descriptor filename usually ends in the
 *.mliap.descriptor* extension.  The format of this file is identical to
 the descriptor file in the :doc:`pair_style mliap <pair_mliap>`, and is
 described in detail there.
 
+The ACE descriptor style *ace* is the same as :doc:`pair_style pace <pair_pace>`.
+A single additional argument specifies the *ace* descriptor filename
+that contains parameters and settings for the ACE descriptors. This file
+format differs from the SNAP or SO3 descriptor files, and has a *.yace* or
+*.ace* extension. However, as with other mliap descriptor styles, this file
+is identical to the ace descriptor file in :doc:`pair_style mliap <pair_mliap>`,
+where it is described in further detail.
+
 .. note::
 
    The number of LAMMPS atom types (and the value of *nelems* in the model)
@@ -172,8 +182,10 @@ This compute is part of the ML-IAP package.  It is only enabled if
 LAMMPS was built with that package. In addition, building LAMMPS with
 the ML-IAP package requires building LAMMPS with the ML-SNAP package.
 The *mliappy* model also requires building LAMMPS with the PYTHON
-package.  See the :doc:`Build package <Build_package>` page for more
+package. The *ace* descriptor also requires building LAMMPS with the
-info.
+ML-PACE package. See the :doc:`Build package <Build_package>` page for
+more info. Note that `kk` (KOKKOS) accelerated variants of SNAP and
+ACE descriptors are not compatible with `mliap descriptor`.
 
 Related commands
 """"""""""""""""

doc/src/compute_pressure.rst

@@ -153,7 +153,8 @@ Related commands
 Default
 """""""
 
-none
+By default the compute includes contributions from the keywords:
+``ke pair bond angle dihedral improper kspace fix``
 
 ----------
 

doc/src/compute_property_atom.rst

@@ -23,6 +23,7 @@ Syntax
                              spx, spy, spz, sp, fmx, fmy, fmz,
                              nbonds,
                              radius, diameter, omegax, omegay, omegaz,
+                             temperature, heatflow,
                              angmomx, angmomy, angmomz,
                              shapex, shapey, shapez,
                              quatw, quati, quatj, quatk, tqx, tqy, tqz,
@@ -56,6 +57,8 @@ Syntax
            *nbonds* = number of bonds assigned to an atom
            *radius,diameter* = radius,diameter of spherical particle
            *omegax,omegay,omegaz* = angular velocity of spherical particle
+           *temperature* = internal temperature of spherical particle
+           *heatflow* = internal heat flow of spherical particle
            *angmomx,angmomy,angmomz* = angular momentum of aspherical particle
            *shapex,shapey,shapez* = 3 diameters of aspherical particle
            *quatw,quati,quatj,quatk* = quaternion components for aspherical or body particles

doc/src/compute_rdf.rst

@@ -176,22 +176,29 @@ also numbers :math:`\ge 0.0`.
 Restrictions
 """"""""""""
 
-The RDF is not computed for distances longer than the force cutoff,
+By default, the RDF is not computed for distances longer than the
-since processors (in parallel) do not know about atom coordinates for
+largest force cutoff, since the neighbor list creation will only contain
-atoms further away than that distance.  If you want an RDF for larger
+pairs up to that distance (plus neighbor list skin).  This distance can
-distances, you can use the :doc:`rerun <rerun>` command to post-process
+be increased using the *cutoff* keyword but this keyword is only valid
-a dump file and set the cutoff for the potential to be longer in the
+with :doc:`neighbor styles 'bin' and 'nsq' <neighbor>`.
+
+If you want an RDF for larger distances, you can also use the
+:doc:`rerun <rerun>` command to post-process a dump file, use :doc:`pair
+style zero <pair_zero>` and set the force cutoff to be longer in the
 rerun script.  Note that in the rerun context, the force cutoff is
-arbitrary, since you are not running dynamics and thus are not changing
+arbitrary and with pair style zero you are not computing any forces, and
-your model.  The definition of :math:`g(r)` used by LAMMPS is only appropriate
+you are not running dynamics you are not changing the model that
-for characterizing atoms that are uniformly distributed throughout the
+generated the trajectory.
-simulation cell. In such cases, the coordination number is still
+
-correct and meaningful.  As an example, if a large simulation cell
+The definition of :math:`g(r)` used by LAMMPS is only appropriate for
-contains only one atom of type *itypeN* and one of *jtypeN*, then :math:`g(r)`
+characterizing atoms that are uniformly distributed throughout the
-will register an arbitrarily large spike at whatever distance they
+simulation cell. In such cases, the coordination number is still correct
-happen to be at, and zero everywhere else.
+and meaningful.  As an example, if a large simulation cell contains only
-The function :math:`\text{coord}(r)` will show a step
+one atom of type *itypeN* and one of *jtypeN*, then :math:`g(r)` will
-change from zero to one at the location of the spike in :math:`g(r)`.
+register an arbitrarily large spike at whatever distance they happen to
+be at, and zero everywhere else.  The function :math:`\text{coord}(r)`
+will show a step change from zero to one at the location of the spike in
+:math:`g(r)`.
 
 .. note::
 

doc/src/compute_reduce.rst

@@ -56,8 +56,9 @@ Examples
    compute 1 all reduce sum c_force
    compute 1 all reduce/region subbox sum c_force
    compute 2 all reduce min c_press[2] f_ave v_myKE
-   compute 2 all reduce min c_press[*] f_ave v_myKE
+   compute 2 all reduce min c_press[*] f_ave v_myKE inputs peratom
    compute 3 fluid reduce max c_index[1] c_index[2] c_dist replace 1 3 replace 2 3
+   compute 4 all reduce max c_bond inputs local
 
 Description
 """""""""""

doc/src/compute_stress_atom.rst

@@ -289,7 +289,8 @@ Related commands
 Default
 """""""
 
-none
+By default the compute includes contributions from the keywords:
+``ke pair bond angle dihedral improper kspace fix``
 
 ----------
 

doc/src/compute_stress_mop.rst

@@ -126,16 +126,19 @@ These styles are part of the EXTRA-COMPUTE package. They are only
 enabled if LAMMPS is built with that package. See the :doc:`Build
 package <Build_package>` doc page on for more info.
 
-The method is only implemented for 3d orthogonal simulation boxes whose
+The method is implemented for orthogonal simulation boxes whose
 size does not change in time, and axis-aligned planes.
 
 The method only works with two-body pair interactions, because it
 requires the class method ``Pair::single()`` to be implemented, which is
 not possible for manybody potentials.  In particular, compute
-*stress/mop/profile* and *stress/mop* do not work with more than two-body pair
+*stress/mop/profile* and *stress/mop* do not work with more than two-body
-interactions, long range (kspace) interactions and
+pair interactions, long range (kspace) interactions and
 improper intramolecular interactions.
 
+The impact of fixes that affect the stress (e.g. fix langevin) is
+also not included in the stress computed here.
+
 Related commands
 """"""""""""""""
 

doc/src/create_atoms.rst

@@ -86,25 +86,46 @@ Description
 """""""""""
 
 This command creates atoms (or molecules) within the simulation box,
-either on a lattice, or a single atom (or molecule), or on a surface
+either on a lattice, or at random points, or on a surface defined by a
-defined by a triangulated mesh, or a random collection of atoms (or
+triangulated mesh.  Or it creates a single atom (or molecule) at a
-molecules).  It is an alternative to reading in atom coordinates
+specified point.  It is an alternative to reading in atom coordinates
 explicitly via a :doc:`read_data <read_data>` or :doc:`read_restart
-<read_restart>` command.  A simulation box must already exist, which is
+<read_restart>` command.
+
+To use this command a simulation box must already exist, which is
 typically created via the :doc:`create_box <create_box>` command.
-Before using this command, a lattice must also be defined using the
+Before using this command, a lattice must typically also be defined
-:doc:`lattice <lattice>` command, unless you specify the *single* style
+using the :doc:`lattice <lattice>` command, unless you specify the
-with units = box or the *random* style.  For the remainder of this doc
+*single* or *mesh* style with units = box or the *random* style.  To
-page, a created atom or molecule is referred to as a "particle".
+create atoms on a lattice for general triclinic boxes, see the
+discussion below.
+
+For the remainder of this doc page, a created atom or molecule is
+referred to as a "particle".
 
 If created particles are individual atoms, they are assigned the
 specified atom *type*, though this can be altered via the *basis*
 keyword as discussed below.  If molecules are being created, the type
-of each atom in the created molecule is specified in the file read by
+of each atom in the created molecule is specified in a specified file
-the :doc:`molecule <molecule>` command, and those values are added to
+read by the :doc:`molecule <molecule>` command, and those values are
-the specified atom *type* (e.g., if *type* = 2 and the file specifies
+added to the specified atom *type* (e.g., if *type* = 2 and the file
-atom types 1, 2, and 3, then each created molecule will have atom types
+specifies atom types 1, 2, and 3, then each created molecule will have
-3, 4, and 5).
+atom types 3, 4, and 5).
+
+.. note::
+
+   You cannot use this command to create atoms that are outside the
+   simulation box; they will just be ignored by LAMMPS.  This is true
+   even if you are using shrink-wrapped box boundaries, as specified
+   by the :doc:`boundary <boundary>` command.  However, you can first
+   use the :doc:`change_box <change_box>` command to temporarily
+   expand the box, then add atoms via create_atoms, then finally use
+   change_box command again if needed to re-shrink-wrap the new atoms.
+   See the :doc:`change_box <change_box>` doc page for an example of
+   how to do this, using the create_atoms *single* style to insert a
+   new atom outside the current simulation box.
+
+----------
 
 For the *box* style, the create_atoms command fills the entire
 simulation box with particles on the lattice.  If your simulation box
@@ -126,10 +147,117 @@ periodic boundaries.  If this is desired, you should either use the
 *box* style, or tweak the region size to get precisely the particles
 you want.
 
+----------
+
+If the simulation box is formulated as a general triclinic box defined
+by arbitrary edge vectors **A**, **B**, **C**, then the *box* and
+*region* styles will create atoms on a lattice commensurate with those
+edge vectors.  See the :doc:`Howto_triclinic <Howto_triclinic>` doc
+page for a detailed explanation of orthogonal, restricted triclinic,
+and general triclinic simulation boxes.  As with the :doc:`create_box
+<create_box>` command, the :doc:`lattice <lattice>` command used by
+this command must be of style *custom* and use its *triclinic/general*
+option.  The *a1, *a2*, *a3* settings of the :doc:`lattice <lattice>`
+command define the edge vectors of a unit cell of the general
+triclinic lattice. The :doc:`create_box <create_box>` command creates
+a simulation box which replicates that unit cell along each of the
+**A**, **B**, **C** edge vectors.
+
+.. note::
+
+   LAMMPS allows specification of general triclinic simulation boxes
+   as a convenience for users who may be converting data from
+   solid-state crystallographic representations or from DFT codes for
+   input to LAMMPS.  However, as explained on the
+   :doc:`Howto_triclinic <Howto_triclinic>` doc page, internally,
+   LAMMPS only uses restricted triclinic simulation boxes.  This means
+   the box created by the :doc:`create_box <create_box>` command as
+   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.
+
+The *box* style will fill the entire general triclinic box with
+particles on the lattice, as explained above.
+
+.. note::
+
+    The *region* style also operates as explained above, but the check
+    for particles inside the region is performed *after* the particle
+    coordinates have been converted to the restricted triclinic box.
+    This means the region must also be defined with respect to the
+    restricted triclinic box, not the general triclinic box.
+
+If the simulation box is general triclinic, the *single*, *random*,
+and *mesh* styles described next operate on the box *after* it has
+been converted to restricted triclinic.  So all the settings for those
+styles should be made in that context.
+
+----------
+
 For the *single* style, a single particle is added to the system at
 the specified coordinates.  This can be useful for debugging purposes
 or to create a tiny system with a handful of particles at specified
-positions.
+positions.  For a 2d simulation the specified z coordinate must be
+0.0.
+
+.. versionchanged:: 2Jun2022
+
+The *porosity* style has been renamed to *random* with added functionality.
+
+For the *random* style, *N* particles are added to the system at
+randomly generated coordinates, which can be useful for generating an
+amorphous system.  For 2d simulations, the z coordinates of all added
+atoms will be 0.0.
+
+The particles are created one by one using the specified random number
+*seed*, resulting in the same set of particle coordinates, independent
+of how many processors are being used in the simulation.  Unless the
+*overlap* keyword is specified, particles created by the *random*
+style will typically be highly overlapped.  Various additional
+criteria can be used to accept or reject a random particle insertion;
+see the keyword discussion below.  Multiple attempts per particle are
+made (see the *maxtry* keyword) until the insertion is either
+successful or fails.  If this command fails to add all requested *N*
+particles, a warning will be output.
+
+If the *region-ID* argument is specified as NULL, then the randomly
+created particles will be anywhere in the simulation box.  If a
+*region-ID* is specified, a geometric volume is filled that is both
+inside the simulation box and is also consistent with the region
+volume.  See the :doc:`region <region>` command for details.  Note
+that a region can be specified so that its "volume" is either inside
+or outside its geometric boundary.
+
+Note that the create_atoms command adds particles to those that
+already exist.  This means it can be used to add particles to a system
+previously read in from a data or restart file.  Or the create_atoms
+command can be used multiple times, to add multiple sets of particles
+to the simulation.  For example, grain boundaries can be created, by
+interleaving the create_atoms command with :doc:`lattice <lattice>`
+commands specifying different orientations.
+
+When this command is used, care should be taken to ensure the
+resulting system does not contain particles that are highly
+overlapped.  Such overlaps will cause many interatomic potentials to
+compute huge energies and forces, leading to bad dynamics.  There are
+several strategies to avoid this problem:
+
+* Use the :doc:`delete_atoms overlap <delete_atoms>` command after
+  create_atoms.  For example, this strategy can be used to overlay and
+  surround a large protein molecule with a volume of water molecules,
+  then delete water molecules that overlap with the protein atoms.
+
+* For the *random* style, use the optional *overlap* keyword to avoid
+  overlaps when each new particle is created.
+
+* Before running dynamics on an overlapped system, perform an
+  :doc:`energy minimization <minimize>`.  Or run initial dynamics with
+  :doc:`pair_style soft <pair_soft>` or with :doc:`fix nve/limit
+  <fix_nve_limit>` to un-overlap the particles, before running normal
+  dynamics.
 
 .. figure:: img/marble_race.jpg
             :figwidth: 33%
@@ -189,73 +317,6 @@ to the area of that triangle.
    beneficial to exclude computing interactions between the created
    particles using :doc:`neigh_modify exclude <neigh_modify>`.
 
-.. versionchanged:: 2Jun2022
-
-The *porosity* style has been renamed to *random* with added functionality.
-
-For the *random* style, *N* particles are added to the system at
-randomly generated coordinates, which can be useful for generating an
-amorphous system.  The particles are created one by one using the
-specified random number *seed*, resulting in the same set of particle
-coordinates, independent of how many processors are being used in the
-simulation.  Unless the *overlap* keyword is specified, particles
-created by the *random* style will typically be highly overlapped.
-Various additional criteria can be used to accept or reject a random
-particle insertion; see the keyword discussion below.  Multiple
-attempts per particle are made (see the *maxtry* keyword) until the
-insertion is either successful or fails.  If this command fails to add
-all requested *N* particles, a warning will be output.
-
-If the *region-ID* argument is specified as NULL, then the randomly
-created particles will be anywhere in the simulation box.  If a
-*region-ID* is specified, a geometric volume is filled that is both
-inside the simulation box and is also consistent with the region
-volume.  See the :doc:`region <region>` command for details.  Note
-that a region can be specified so that its "volume" is either inside
-or outside its geometric boundary.
-
-Note that the create_atoms command adds particles to those that
-already exist.  This means it can be used to add particles to a system
-previously read in from a data or restart file.  Or the create_atoms
-command can be used multiple times, to add multiple sets of particles
-to the simulation.  For example, grain boundaries can be created, by
-interleaving the create_atoms command with :doc:`lattice <lattice>`
-commands specifying different orientations.
-
-When this command is used, care should be taken to ensure the
-resulting system does not contain particles that are highly
-overlapped.  Such overlaps will cause many interatomic potentials to
-compute huge energies and forces, leading to bad dynamics.  There are
-several strategies to avoid this problem:
-
-* Use the :doc:`delete_atoms overlap <delete_atoms>` command after
-  create_atoms.  For example, this strategy can be used to overlay and
-  surround a large protein molecule with a volume of water molecules,
-  then delete water molecules that overlap with the protein atoms.
-
-* For the *random* style, use the optional *overlap* keyword to avoid
-  overlaps when each new particle is created.
-
-* Before running dynamics on an overlapped system, perform an
-  :doc:`energy minimization <minimize>`.  Or run initial dynamics with
-  :doc:`pair_style soft <pair_soft>` or with :doc:`fix nve/limit
-  <fix_nve_limit>` to un-overlap the particles, before running normal
-  dynamics.
-
-.. note::
-
-   You cannot use any of the styles explained above to create atoms
-   that are outside the simulation box; they will just be ignored by
-   LAMMPS.  This is true even if you are using shrink-wrapped box
-   boundaries, as specified by the :doc:`boundary <boundary>` command.
-   However, you can first use the :doc:`change_box <change_box>`
-   command to temporarily expand the box, then add atoms via
-   create_atoms, then finally use change_box command again if needed
-   to re-shrink-wrap the new atoms.  See the :doc:`change_box
-   <change_box>` doc page for an example of how to do this, using the
-   create_atoms *single* style to insert a new atom outside the
-   current simulation box.
-
 ----------
 
 Individual atoms are inserted by this command, unless the *mol*
@@ -268,6 +329,12 @@ molecule can be specified in the molecule file.  See the
 required to be in this file are the coordinates and types of atoms in
 the molecule.
 
+.. note::
+
+  If you are using the *mol* keyword in combination with the
+  :doc:`atom style template <atom_style>` command, they must use
+  the same molecule template-ID.
+
 Using a lattice to add molecules, e.g. via the *box* or *region* or
 *single* styles, is exactly the same as adding atoms on lattice
 points, except that entire molecules are added at each point, i.e. on
@@ -401,12 +468,13 @@ to.
 
 The *overlap* keyword only applies to the *random* style.  It prevents
 newly created particles from being created closer than the specified
-*Doverlap* distance from any other particle.  When the particles being
+*Doverlap* distance from any other particle.  If particles have finite
-created are molecules, the radius of the molecule (from its geometric
+size (see :doc:`atom_style sphere <atom_style>` for example) *Doverlap*
-center) is added to *Doverlap*.  If particles have finite size (see
+should be specified large enough to include the particle size in the
-:doc:`atom_style sphere <atom_style>` for example) *Doverlap* should
+non-overlapping criterion.  If molecules are being randomly inserted, then
-be specified large enough to include the particle size in the
+an insertion is only accepted if each particle in the molecule meets the
-non-overlapping criterion.
+overlap criterion with respect to other particles (not including particles
+in the molecule itself).
 
 .. note::
 
@@ -463,12 +531,19 @@ on a single CPU core.
 -----
 
 The *units* keyword determines the meaning of the distance units used
-to specify the coordinates of the one particle created by the *single*
+by parameters for various styles.  A *box* value selects standard
-style, or the overlap distance *Doverlap* by the *overlap* keyword.  A
+distance units as defined by the :doc:`units <units>` command (e.g.,
-*box* value selects standard distance units as defined by the
+:math:`\AA` for units = *real* or *metal*\ .  A *lattice* value means
-:doc:`units <units>` command (e.g., :math:`\AA` for
+the distance units are in lattice spacings.  These are affected settings:
-units = *real* or *metal*\ .  A *lattice* value means the distance units are in
+
-lattice spacings.
+* for *single* style: coordinates of the particle created
+* for *random* style: overlap distance *Doverlap* by the *overlap* keyword
+* for *mesh* style: *bisect* threshold value for *meshmode* = *bisect*
+* for *mesh* style: *radthresh* value for *meshmode* = *bisect*
+* for *mesh* style: *density* value for *meshmode* = *qrand*
+
+Since *density* represents an area (distance ^2), the lattice spacing
+factor is also squared.
 
 ----------
 

doc/src/create_box.rst

@@ -9,9 +9,11 @@ Syntax
 .. code-block:: LAMMPS
 
    create_box N region-ID keyword value ...
+   create_box N NULL alo ahi blo bhi clo chi keyword value ...
 
 * N = # of atom types to use in this simulation
-* region-ID = ID of region to use as simulation domain
+* 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)
 * 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*
 
@@ -32,121 +34,204 @@ Examples
 
 .. code-block:: LAMMPS
 
+   # orthogonal or restricted triclinic box using regionID = mybox
    create_box 2 mybox
    create_box 2 mybox bond/types 2 extra/bond/per/atom 1
 
+.. code-block:: LAMMPS
+
+   # 2d general triclinic box using primitive cell for 2d hex lattice
+   lattice       custom 1.0 a1 1.0 0.0 0.0 a2 0.5 0.86602540378 0.0 &
+                 a3 0.0 0.0 1.0 basis 0.0 0.0 0.0 triclinic/general
+   create_box    1 NULL 0 5 0 5 -0.5 0.5
+
+.. code-block:: LAMMPS
+
+   # 3d general triclinic box using primitive cell for 3d fcc lattice
+   lattice custom 1.0 a2 0.0 0.5 0.5 a1 0.5 0.0 0.5 a3 0.5 0.5 0.0 basis 0.0 0.0 0.0 triclinic/general
+   create box 1 NULL -5 5 -10 10 0 20
+
 Description
 """""""""""
 
-This command creates a simulation box based on the specified region.
+This command creates a simulation box. It also partitions the box into
-Thus a :doc:`region <region>` command must first be used to define a
+a regular 3d grid of smaller sub-boxes, one per processor (MPI task).
-geometric domain.  It also partitions the simulation box into a
+The geometry of the partitioning is based on the size and shape of the
-regular 3d grid of rectangular bricks, one per processor, based on the
+simulation box, the number of processors being used and the settings
-number of processors being used and the settings of the
+of the :doc:`processors <processors>` command.  The partitioning can
-:doc:`processors <processors>` command.  The partitioning can later be
+later be changed by the :doc:`balance <balance>` or :doc:`fix balance
-changed by the :doc:`balance <balance>` or :doc:`fix balance <fix_balance>` commands.
+<fix_balance>` commands.
 
-The argument N is the number of atom types that will be used in the
+Simulation boxes in LAMMPS can be either orthogonal or triclinic in
+shape.  Orthogonal boxes are a brick in 3d (rectangle in 2d) with 6
+faces that are each perpendicular to one of the standard xyz
+coordinate axes.  Triclinic boxes are a parallelepiped in 3d
+(parallelogram in 2d) with opposite pairs of faces parallel to each
+other.  LAMMPS supports two forms of triclinic boxes, restricted and
+general, which differ in how the box is oriented with respect to the
+xyz coordinate axes.  See the :doc:`Howto triclinic <Howto_triclinic>`
+for a detailed description of all 3 kinds of simulation boxes.
+
+The argument *N* is the number of atom types that will be used in the
 simulation.
 
+Orthogonal and restricted triclinic boxes are created by specifying a
+region ID previously defined by the :doc:`region <region>` command.
+General triclinic boxes are discussed below.
+
 If the region is not of style *prism*, then LAMMPS encloses the region
 (block, sphere, etc.) with an axis-aligned orthogonal bounding box
-which becomes the simulation domain.
+which becomes the simulation domain.  For a 2d simulation, the zlo and
+zhi values of the simulation box must straddle zero.
 
 If the region is of style *prism*, LAMMPS creates a non-orthogonal
 simulation domain shaped as a parallelepiped with triclinic symmetry.
 As defined by the :doc:`region prism <region>` command, the
-parallelepiped has its "origin" at (xlo,ylo,zlo) and is defined by three
+parallelepiped has an "origin" at (xlo,ylo,zlo) and three edge vectors
-edge vectors starting from the origin given by
+starting from the origin given by :math:`\vec a =
-:math:`\vec a = (x_\text{hi}-x_\text{lo},0,0)`;
+(x_\text{hi}-x_\text{lo},0,0)`; :math:`\vec b =
-:math:`\vec b = (xy,y_\text{hi}-y_\text{lo},0)`; and
+(xy,y_\text{hi}-y_\text{lo},0)`; and :math:`\vec c =
-:math:`\vec c = (xz,yz,z_\text{hi}-z_\text{lo})`.
+(xz,yz,z_\text{hi}-z_\text{lo})`.  In LAMMPS lingo, this is a
-The parameters *xy*\ , *xz*\ , and *yz* can be 0.0 or
+restricted triclinic box because the three edge vectors cannot be
-positive or negative values and are called "tilt factors" because they
+defined in arbitrary (general) directions.  The parameters *xy*\ ,
-are the amount of displacement applied to faces of an originally
+*xz*\ , and *yz* can be 0.0 or positive or negative values and are
-orthogonal box to transform it into the parallelepiped.
+called "tilt factors" because they are the amount of displacement
+applied to faces of an originally orthogonal box to transform it into
+the parallelepiped.  For a 2d simulation, the zlo and zhi values of
+the simulation box must straddle zero.
 
-By default, a *prism* region used with the create_box command must have
+Typically a *prism* region used with the create_box command should
-tilt factors :math:`(xy,xz,yz)` that do not skew the box more than half
+have tilt factors :math:`(xy,xz,yz)` that do not skew the box more
-the distance of the parallel box length.  For example, if
+than half the distance of the parallel box length.  For example, if
-:math:`x_\text{lo} = 2` and :math:`x_\text{hi} = 12`, then the :math:`x`
+:math:`x_\text{lo} = 2` and :math:`x_\text{hi} = 12`, then the
-box length is 10 and the :math:`xy` tilt factor must be between
+:math:`x` box length is 10 and the :math:`xy` tilt factor must be
-:math:`-5` and :math:`5`.  Similarly, both :math:`xz` and :math:`yz`
+between :math:`-5` and :math:`5`.  Similarly, both :math:`xz` and
-must be between :math:`-(x_\text{hi}-x_\text{lo})/2` and
+:math:`yz` must be between :math:`-(x_\text{hi}-x_\text{lo})/2` and
 :math:`+(y_\text{hi}-y_\text{lo})/2`.  Note that this is not a
-limitation, since if the maximum tilt factor is 5 (as in this example),
+limitation, since if the maximum tilt factor is 5 (as in this
-then configurations with tilt :math:`= \dots, -15`, :math:`-5`,
+example), then configurations with tilt :math:`= \dots, -15`,
-:math:`5`, :math:`15`, :math:`25, \dots` are all geometrically
+:math:`-5`, :math:`5`, :math:`15`, :math:`25, \dots` are all
-equivalent.  Simulations with large tilt factors will run inefficiently,
+geometrically equivalent.
-since they require more ghost atoms and thus more communication.  With
-very large tilt factors, LAMMPS will eventually produce incorrect
-trajectories and stop with errors due to lost atoms or similar.
 
-See the :doc:`Howto triclinic <Howto_triclinic>` page for a
+LAMMPS will issue a warning if the tilt factors of the created box do
-geometric description of triclinic boxes, as defined by LAMMPS, and
+not meet this criterion.  This is because simulations with large tilt
-how to transform these parameters to and from other commonly used
+factors may run inefficiently, since they require more ghost atoms and
-triclinic representations.
+thus more communication.  With very large tilt factors, LAMMPS may
+eventually produce incorrect trajectories and stop with errors due to
+lost atoms or similar issues.
 
-When a prism region is used, the simulation domain should normally be periodic
+See the :doc:`Howto triclinic <Howto_triclinic>` page for geometric
-in the dimension that the tilt is applied to, which is given by the second
+descriptions of triclinic boxes and tilt factors, as well as how to
-dimension of the tilt factor (e.g., :math:`y` for :math:`xy` tilt).  This is so
+transform the restricted triclinic parameters to and from other
-that pairs of atoms interacting across that boundary will have one of them
+commonly used triclinic representations.
-shifted by the tilt factor.  Periodicity is set by the
+
-:doc:`boundary <boundary>` command.  For example, if the :math:`xy` tilt factor
+When a prism region is used, the simulation domain should normally be
-is non-zero, then the :math:`y` dimension should be periodic.  Similarly, the
+periodic in the dimension that the tilt is applied to, which is given
-:math:`z` dimension should be periodic if :math:`xz` or :math:`yz` is non-zero.
+by the second dimension of the tilt factor (e.g., :math:`y` for
-LAMMPS does not require this periodicity, but you may lose atoms if this is not
+:math:`xy` tilt).  This is so that pairs of atoms interacting across
-the case.
+that boundary will have one of them shifted by the tilt factor.
+Periodicity is set by the :doc:`boundary <boundary>` command.  For
+example, if the :math:`xy` tilt factor is non-zero, then the :math:`y`
+dimension should be periodic.  Similarly, the :math:`z` dimension
+should be periodic if :math:`xz` or :math:`yz` is non-zero.  LAMMPS
+does not require this periodicity, but you may lose atoms if this is
+not the case.
 
 Note that if your simulation will tilt the box (e.g., via the
-:doc:`fix deform <fix_deform>` command), the simulation box must be set up to
+:doc:`fix deform <fix_deform>` command), the simulation box must be
-be triclinic, even if the tilt factors are initially 0.0.  You can
+created as triclinic, even if the tilt factors are initially 0.0.  You
-also change an orthogonal box to a triclinic box or vice versa by
+can also change an orthogonal box to a triclinic box or vice versa by
 using the :doc:`change box <change_box>` command with its *ortho* and
 *triclinic* options.
 
 .. note::
 
-   If the system is non-periodic (in a dimension), then you should
+   If the system is non-periodic (in a dimension), then you should not
-   not make the lo/hi box dimensions (as defined in your
+   make the lo/hi box dimensions (as defined in your :doc:`region
-   :doc:`region <region>` command) radically smaller/larger than the extent
+   <region>` command) radically smaller/larger than the extent of the
-   of the atoms you eventually plan to create (e.g., via the
+   atoms you eventually plan to create (e.g., via the
-   :doc:`create_atoms <create_atoms>` command).  For example, if your atoms
+   :doc:`create_atoms <create_atoms>` command).  For example, if your
-   extend from 0 to 50, you should not specify the box bounds as :math:`-10000`
+   atoms extend from 0 to 50, you should not specify the box bounds as
-   and :math:`10000`. This is because as described above, LAMMPS uses the
+   :math:`-10000` and :math:`10000`. This is because as described
-   specified box size to lay out the 3d grid of processors.  A huge
+   above, LAMMPS uses the specified box size to lay out the 3d grid of
-   (mostly empty) box will be sub-optimal for performance when using
+   processors.  A huge (mostly empty) box will be sub-optimal for
-   "fixed" boundary conditions (see the :doc:`boundary <boundary>`
+   performance when using "fixed" boundary conditions (see the
-   command).  When using "shrink-wrap" boundary conditions (see the
+   :doc:`boundary <boundary>` command).  When using "shrink-wrap"
-   :doc:`boundary <boundary>` command), a huge (mostly empty) box may cause
+   boundary conditions (see the :doc:`boundary <boundary>` command), a
-   a parallel simulation to lose atoms the first time that LAMMPS
+   huge (mostly empty) box may cause a parallel simulation to lose
-   shrink-wraps the box around the atoms.
+   atoms the first time that LAMMPS shrink-wraps the box around the
+   atoms.
+
+----------
+
+As noted above, general triclinic boxes in LAMMPS allow the box to
+have arbitrary edge vectors **A**, **B**, **C**.  The only
+restrictions are that the three vectors be distinct, non-zero, and not
+co-planar.  They must also define a right-handed system such that
+(**A** x **B**) points in the direction of **C**.  Note that a
+left-handed system can be converted to a right-handed system by simply
+swapping the order of any pair of the **A**, **B**, **C** vectors.
+
+To create a general triclinic boxes, the region is specified as NULL
+and the next 6 parameters (alo,ahi,blo,bhi,clo,chi) define the three
+edge vectors **A**, **B**, **C** using additional information
+previously defined by the :doc:`lattice <lattice>` command.
+
+The lattice must be of style *custom* and use its *triclinic/general*
+option.  This insures the lattice satisfies the restrictions listed
+above.  The *a1, *a2*, *a3* settings of the :doc:`lattice <lattice>`
+command define the edge vectors of a unit cell of the general
+triclinic lattice.  This command uses them to define the three edge
+vectors and origin of the general triclinic box as:
+
+* **A** = (ahi-alo) * *a1*
+* **B** = (bhi-blo) * *a2*
+* **C** = (chi-clo) * *a3*
+* origin = (alo*a1 + blo*a2 + clo*a3)
+
+For 2d general triclinic boxes, clo = -0.5 and chi = 0.5 is required.
+
+.. note::
+
+   LAMMPS allows specification of general triclinic simulation boxes
+   as a convenience for users who may be converting data from
+   solid-state crystallographic representations or from DFT codes for
+   input to LAMMPS.  However, as explained on the
+   :doc:`Howto_triclinic <Howto_triclinic>` doc page, internally,
+   LAMMPS only uses restricted triclinic simulation boxes.  This means
+   the box defined by this command and per-atom information
+   (e.g. coordinates, velocities) defined by the :doc:`create_atoms
+   <create_atoms>` command 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.
 
 ----------
 
 The optional keywords can be used to create a system that allows for
 bond (angle, dihedral, improper) interactions, or for molecules with
-special 1--2, 1--3, or 1--4 neighbors to be added later.  These optional
+special 1--2, 1--3, or 1--4 neighbors to be added later.  These
-keywords serve the same purpose as the analogous keywords that can be
+optional keywords serve the same purpose as the analogous keywords
-used in a data file which are recognized by the
+that can be used in a data file which are recognized by the
 :doc:`read_data <read_data>` command when it sets up a system.
 
 Note that if these keywords are not used, then the create_box command
 creates an atomic (non-molecular) simulation that does not allow bonds
-between pairs of atoms to be defined, or a
+between pairs of atoms to be defined, or a :doc:`bond potential
-:doc:`bond potential <bond_style>` to be specified, or for molecules with
+<bond_style>` to be specified, or for molecules with special neighbors
-special neighbors to be added to the system by commands such as
+to be added to the system by commands such as :doc:`create_atoms mol
-:doc:`create_atoms mol <create_atoms>`, :doc:`fix deposit <fix_deposit>`
+<create_atoms>`, :doc:`fix deposit <fix_deposit>` or :doc:`fix pour
-or :doc:`fix pour <fix_pour>`.
+<fix_pour>`.
 
 As an example, see the examples/deposit/in.deposit.molecule script,
 which deposits molecules onto a substrate.  Initially there are no
-molecules in the system, but they are added later by the
+molecules in the system, but they are added later by the :doc:`fix
-:doc:`fix deposit <fix_deposit>` command.  The create_box command in the
+deposit <fix_deposit>` command.  The create_box command in the script
-script uses the bond/types and extra/bond/per/atom keywords to allow
+uses the bond/types and extra/bond/per/atom keywords to allow this.
-this.  If the added molecule contained more than one special bond
+If the added molecule contained more than one special bond (allowed by
-(allowed by default), an extra/special/per/atom keyword would also
+default), an extra/special/per/atom keyword would also need to be
-need to be specified.
+specified.
 
 ----------
 

doc/src/dihedral_cosine_squared_restricted.rst

@@ -0,0 +1,71 @@
+.. index:: dihedral_style cosine/squared/restricted
+
+dihedral_style cosine/squared/restricted command
+================================================
+
+
+Syntax
+""""""
+
+.. code-block:: LAMMPS
+
+   dihedral_style cosine/squared/restricted
+
+Examples
+""""""""
+
+.. code-block:: LAMMPS
+
+   dihedral_style cosine/squared/restricted
+   dihedral_coeff 1 10.0 120
+
+Description
+"""""""""""
+
+.. versionadded:: 17Apr2024
+
+The *cosine/squared/restricted* dihedral style uses the potential
+
+.. math::
+
+   E = K [\cos(\phi) - \cos(\phi_0)]^2 / \sin^2(\phi)
+
+, which is commonly used in the MARTINI force field.
+
+See :ref:`(Bulacu) <restricted-Bul>` for a description of the restricted dihedral for the MARTINI force field.
+
+The following coefficients must be defined for each dihedral type via the
+:doc:`dihedral_coeff <dihedral_coeff>` command as in the example above, or in
+the data file or restart files read by the :doc:`read_data <read_data>`
+or :doc:`read_restart <read_restart>` commands:
+
+* :math:`K` (energy)
+* :math:`\phi_0` (degrees)
+
+:math:`\phi_0` is specified in degrees, but LAMMPS converts it to radians internally.
+
+----------
+
+Restrictions
+""""""""""""
+
+This dihedral style can only be used if LAMMPS was built with the
+EXTRA-MOLECULE package.  See the :doc:`Build package <Build_package>` doc page
+for more info.
+
+Related commands
+""""""""""""""""
+
+:doc:`dihedral_coeff <dihedral_coeff>`
+
+Default
+"""""""
+
+none
+
+----------
+
+.. _restricted-Bul:
+
+**(Bulacu)** Bulacu, Goga, Zhao, Rossi, Monticelli, Periole, Tieleman, Marrink, J Chem Theory Comput, 9, 3282-3292
+(2013).

doc/src/dihedral_style.rst

@@ -10,7 +10,7 @@ Syntax
 
    dihedral_style style
 
-* style = *none* or *zero* or *hybrid* or *charmm* or *charmmfsw* or *class2* or *cosine/shift/exp* or *fourier* or *harmonic* or *helix* or *lepton* or *multi/harmonic* or *nharmonic* or *opls* or *spherical* or *table* or *table/cut*
+* style = *none* or *zero* or *hybrid* or *charmm* or *charmmfsw* or *class2* or *cosine/shift/exp* or *cosine/squared/restricted* or *fourier* or *harmonic* or *helix* or *lepton* or *multi/harmonic* or *nharmonic* or *opls* or *spherical* or *table* or *table/cut*
 
 Examples
 """"""""
@@ -105,6 +105,7 @@ exist.
 * :doc:`charmmfsw <dihedral_charmm>` - CHARMM dihedral with force switching
 * :doc:`class2 <dihedral_class2>` - COMPASS (class 2) dihedral
 * :doc:`cosine/shift/exp <dihedral_cosine_shift_exp>` - dihedral with exponential in spring constant
+* :doc:`cosine/squared/restricted <dihedral_cosine_squared_restricted>` - squared cosine dihedral with restricted term
 * :doc:`fourier <dihedral_fourier>` - dihedral with multiple cosine terms
 * :doc:`harmonic <dihedral_harmonic>` - harmonic dihedral
 * :doc:`helix <dihedral_helix>` - helix dihedral

doc/src/dump.rst

@@ -104,7 +104,6 @@ Syntax
                                q, mux, muy, muz, mu,
                                radius, diameter, omegax, omegay, omegaz,
                                angmomx, angmomy, angmomz, tqx, tqy, tqz,
-                               heatflow, temperature,
                                c_ID, c_ID[I], f_ID, f_ID[I], v_name,
                                i_name, d_name, i2_name[I], d2_name[I]
 
@@ -131,8 +130,6 @@ Syntax
            omegax,omegay,omegaz = angular velocity of spherical particle
            angmomx,angmomy,angmomz = angular momentum of aspherical particle
            tqx,tqy,tqz = torque on finite-size particles
-           heatflow = rate of heat flow into particle
-           temperature = temperature of particle
            c_ID = per-atom vector calculated by a compute with ID
            c_ID[I] = Ith column of per-atom array calculated by a compute with ID, I can include wildcard (see below)
            f_ID = per-atom vector calculated by a fix with ID
@@ -278,16 +275,20 @@ format <dump_modify>` command and its options.
 Format of native LAMMPS format dump files:
 
 The *atom*, *custom*, *grid*, and *local* styles create files in a
-simple LAMMPS-specific text format that is self-explanatory when
+simple LAMMPS-specific text format that is mostly self-explanatory
-viewing a dump file.  Many post-processing tools either included with
+when viewing a dump file.  Many post-processing tools either included
-LAMMPS or third-party tools can read this format, as does the
+with LAMMPS or third-party tools can read this format, as does the
 :doc:`rerun <rerun>` command.  See tools described on the :doc:`Tools
 <Tools>` doc page for examples, including `Pizza.py
 <https://lammps.github.io/pizza>`_.
 
 For all these styles, the dimensions of the simulation box are
-included in each snapshot.  For an orthogonal simulation box this
+included in each snapshot.  The simulation box in LAMMPS can be
-information is formatted as:
+defined in one of 3 ways: orthogonal, restricted triclinic, and
+general triclinic.  See the :doc:`Howto triclinic <Howto_triclinic>`
+doc page for a detailed description of all 3 options.
+
+For an orthogonal simulation box the box information is formatted as:
 
 .. parsed-literal::
 
@@ -304,10 +305,10 @@ the six characters is one of *p* (periodic), *f* (fixed), *s* (shrink wrap),
 or *m* (shrink wrapped with a minimum value).  See the
 :doc:`boundary <boundary>` command for details.
 
-For triclinic simulation boxes (non-orthogonal), an orthogonal
+For a restricted triclinic simulation box, an orthogonal bounding box
-bounding box which encloses the triclinic simulation box is output,
+which encloses the restricted triclinic simulation box is output,
-along with the three tilt factors (*xy*, *xz*, *yz*) of the triclinic box,
+along with the three tilt factors (*xy*, *xz*, *yz*) of the triclinic
-formatted as follows:
+box, formatted as follows:
 
 .. parsed-literal::
 
@@ -329,6 +330,10 @@ bounding box extents (xlo_bound, xhi_bound, etc.) are calculated from the
 triclinic parameters, and how to transform those parameters to and
 from other commonly used triclinic representations.
 
+For a general triclinic simulation box, see the "General triclinic"
+section below for a description of the ITEM: BOX BOUNDS format as well
+as how per-atom coordinates and per-atom vector quantities are output.
+
 The *atom* and *custom* styles output a "ITEM: NUMBER OF ATOMS" line
 with the count of atoms in the snapshot.  Likewise they output an
 "ITEM: ATOMS" line which includes column descriptors for the per-atom
@@ -400,7 +405,6 @@ command.
 
 Dump files in other popular formats:
 
-
 .. note::
 
    This section only discusses file formats relevant to this doc page.
@@ -656,6 +660,87 @@ how to control the compression level in both variants.
 
 ----------
 
+General triclinic simulation box output for the *atom* and *custom* styles:
+
+As mentioned above, the simulation box can be defined as a general
+triclinic box, which means that 3 arbitrary box edge vectors **A**,
+**B**, **C** can be specified.  See the :doc:`Howto triclinic
+<Howto_triclinic>` doc page for a detailed description of general
+triclinic boxes.
+
+This option is provided as a convenience for users who may be
+converting data from solid-state crystallographic representations or
+from DFT codes for input to LAMMPS.  However, as explained on the
+:doc:`Howto_triclinic <Howto_triclinic>` doc page, internally, LAMMPS
+only uses restricted triclinic simulation boxes.  This means the box
+and per-atom information (e.g. coordinates, velocities) LAMMPS stores
+are converted (rotated) from general to restricted triclinic form when
+the system is created.
+
+For dump output, if the :doc:`dump_modify triclinic/general
+<dump_modify>` command is used, the box description and per-atom
+coordinates and other per-atom vectors will be converted (rotated)
+from restricted to general form when each dump file snapshots is
+output.  This option can only be used if the simulation box was
+initially created as general triclinic.  If the option is not used,
+and the simulation box is general triclinic, then the dump file
+snapshots will reflect the internal restricted triclinic geometry.
+
+The dump_modify triclinic/general option affects 3 aspects of the dump
+file output.
+
+First, the format for the BOX BOUNDS is as follows
+
+.. parsed-literal::
+
+   ITEM: BOX BOUNDS abc origin
+   ax ay az originx
+   bx by bz originy
+   cx cy cz originz
+
+where the **A** edge vector of the box is (ax,ay,az) and similarly
+for **B** and **C**.  The origin of all 3 edge vectors is (originx,
+originy, originz).
+
+Second, the coordinates of each atom are converted (rotated) so that
+the atom is inside (or near) the general triclinic box defined by the
+**A**, **B**, **C** edge vectors.  For style *atom*, this only alters
+output for unscaled atom coords, via the :doc:`dump_modify scaled no
+<dump_modify>` setting. For style *custom*, this alters output for
+either unscaled or unwrapped output of atom coords, via the *x,y,z* or
+*xu,yu,zu* attributes.  For output of scaled atom coords by both
+styles, there is no difference between restricted and general
+triclinic values.
+
+Third, the output for any attribute of the *custom* style which
+represents a per-atom vector quantity will be converted (rotated) to
+be oriented consistent with the general triclinic box and its
+orientation relative to the standard xyz coordinate axes.
+
+This applies to the following *custom* style attributes:
+
+* vx,vy,vz = atom velocities
+* fx,fy,fz = forces on atoms
+* mux,muy,muz = orientation of dipole moment of atom
+* omegax,omegay,omegaz = angular velocity of spherical particle
+* angmomx,angmomy,angmomz = angular momentum of aspherical particle
+* tqx,tqy,tqz = torque on finite-size particles
+
+For example, if the velocity of an atom in a restricted triclinic box
+is along the x-axis, then it will be output for a general triclinic
+box as a vector along the **A** edge vector of the box.
+
+.. note::
+
+   For style *custom*, the :doc:`dump_modify thresh <dump_modify>`
+   command may access per-atom attributes either directly or
+   indirectly through a compute or variable.  If the attribute is an
+   atom coordinate or one of the vectors mentioned above, its value
+   will *NOT* be a general triclinic (rotated) value.  Rather it will
+   be a restricted triclinic value.
+
+----------
+
 Arguments for different styles:
 
 The sections below describe per-atom, local, and per grid cell

doc/src/dump_modify.rst

@@ -17,7 +17,7 @@ Syntax
 * one or more keyword/value pairs may be appended
 
 * these keywords apply to various dump styles
-* keyword = *append* or *at* or *balance* or *buffer* or *colname* or *delay* or *element* or *every* or *every/time* or *fileper* or *first* or *flush* or *format* or *header* or *image* or *label* or *maxfiles* or *nfile* or *pad* or *pbc* or *precision* or *region* or *refresh* or *scale* or *sfactor* or *skip* or *sort* or *tfactor* or *thermo* or *thresh* or *time* or *units* or *unwrap*
+* keyword = *append* or *at* or *balance* or *buffer* or *colname* or *delay* or *element* or *every* or *every/time* or *fileper* or *first* or *flush* or *format* or *header* or *image* or *label* or *maxfiles* or *nfile* or *pad* or *pbc* or *precision* or *region* or *refresh* or *scale* or *sfactor* or *skip* or *sort* or *tfactor* or *thermo* or *thresh* or *time* or *triclinic/general* or *units* or *unwrap*
 
   .. parsed-literal::
 
@@ -74,12 +74,13 @@ Syntax
           -N = sort per-atom lines in descending order by the Nth column
        *tfactor* arg = time scaling factor (> 0.0)
        *thermo* arg = *yes* or *no*
-       *time* arg = *yes* or *no*
        *thresh* args = attribute operator value
          attribute = same attributes (x,fy,etotal,sxx,etc) used by dump custom style
          operator = "<" or "<=" or ">" or ">=" or "==" or "!=" or "\|\^"
          value = numeric value to compare to, or LAST
          these 3 args can be replaced by the word "none" to turn off thresholding
+       *time* arg = *yes* or *no*
+       *triclinic/general* arg = *yes* or *no*
        *units* arg = *yes* or *no*
        *unwrap* arg = *yes* or *no*
 
@@ -802,8 +803,9 @@ region since the last dump.
    dump_modify ... thresh v_charge |^ LAST
 
 This will dump atoms whose charge has changed from an absolute value
-less than :math:`\frac12` to greater than :math:`\frac12` (or vice versa) since the last dump (e.g., due to reactions and subsequent charge equilibration in a
+less than :math:`\frac12` to greater than :math:`\frac12` (or vice
-reactive force field).
+versa) since the last dump (e.g., due to reactions and subsequent
+charge equilibration in a reactive force field).
 
 The choice of operators listed above are the usual comparison
 operators.  The XOR operation (exclusive or) is also included as "\|\^".
@@ -811,6 +813,18 @@ In this context, XOR means that if either the attribute or value is
 0.0 and the other is non-zero, then the result is "true" and the
 threshold criterion is met.  Otherwise it is not met.
 
+.. note::
+
+   For style *custom*, the *triclinic/general* keyword can alter dump
+   output for general triclinic simulation boxes and their atoms.  See
+   the :doc:`dump <dump>` command for details of how this changes the
+   format of dump file snapshots.  The thresh keyword may access
+   per-atom attributes either directly or indirectly through a compute
+   or variable.  If the attribute is an atom coordinate or a per-atom
+   vector (such as velocity, force, or dipole moment), its value will
+   *NOT* be a general triclinic (rotated) value.  Rather it will be a
+   restricted triclinic value.
+
 ----------
 
 The *time* keyword only applies to the dump *atom*, *custom*, *local*,
@@ -835,6 +849,29 @@ The default setting is *no*\ .
 
 ----------
 
+The *triclinic/general* keyword only applies to the dump *atom* and
+*custom* styles.  It can only be used with a value of *yes* if the
+simulation box was created as a general triclinic box.  See the
+:doc:`Howto_triclinic <Howto_triclinic>` doc page for a detailed
+explanation of orthogonal, restricted triclinic, and general triclinic
+simulation boxes.
+
+If this keyword is used with a value of *yes*, the box information at
+the beginning of each snapshot will include information about the 3
+arbitrary edge vectors **A**, **B**, **C** that define the general
+triclinic box as well as their origin.  The format is described on the
+:doc:`dump <dump>` doc page.
+
+The coordinates of each atom will likewise be output as values in (or
+near) the general triclinic box.  Likewise, per-atom vector quantities
+such as velocity, omega, dipole moment, etc will have orientations
+consistent with the general triclinic box, meaning they will be
+rotated relative to the standard xyz coordinate axes.  See the
+:doc:`dump <dump>` doc page for a full list of which dump attributes
+this affects.
+
+----------
+
 The *units* keyword only applies to the dump *atom*, *custom*, and
 *local* styles (and their COMPRESS package versions *atom/gz*,
 *custom/gz* and *local/gz*\ ). If set to *yes*, each individual dump
@@ -922,6 +959,8 @@ The option defaults are
 * sort = off for dump styles *atom*, *custom*, *cfg*, and *local*
 * sort = id for dump styles *dcd*, *xtc*, and *xyz*
 * thresh = none
+* time = no
+* triclinic/general no
 * units = no
 * unwrap = no
 

doc/src/fix.rst

@@ -226,6 +226,7 @@ accelerated styles exist.
 * :doc:`controller <fix_controller>` - apply control loop feedback mechanism
 * :doc:`damping/cundall <fix_damping_cundall>` - Cundall non-viscous damping for granular simulations
 * :doc:`deform <fix_deform>` - change the simulation box size/shape
+* :doc:`deform/pressure <fix_deform_pressure>` - change the simulation box size/shape with additional loading conditions
 * :doc:`deposit <fix_deposit>` - add new atoms above a surface
 * :doc:`dpd/energy <fix_dpd_energy>` - constant energy dissipative particle dynamics
 * :doc:`drag <fix_drag>` - drag atoms towards a defined coordinate
@@ -427,6 +428,7 @@ accelerated styles exist.
 * :doc:`wall/body/polyhedron <fix_wall_body_polyhedron>` - time integration for body particles of style :doc:`rounded/polyhedron <Howto_body>`
 * :doc:`wall/colloid <fix_wall>` - Lennard-Jones wall interacting with finite-size particles
 * :doc:`wall/ees <fix_wall_ees>` - wall for ellipsoidal particles
+* :doc:`wall/flow <fix_wall_flow>` - flow boundary conditions
 * :doc:`wall/gran <fix_wall_gran>` - frictional wall(s) for granular simulations
 * :doc:`wall/gran/region <fix_wall_gran_region>` - :doc:`fix wall/region <fix_wall_region>` equivalent for use with granular particles
 * :doc:`wall/harmonic <fix_wall>` - harmonic spring wall

doc/src/fix_atom_swap.rst

@@ -168,7 +168,7 @@ the following global cumulative quantities:
 * 1 = swap attempts
 * 2 = swap accepts
 
-The vector values calculated by this fix are "extensive".
+The vector values calculated by this fix are "intensive".
 
 No parameter of this fix can be used with the *start/stop* keywords of
 the :doc:`run <run>` command.  This fix is not invoked during

doc/src/fix_ave_chunk.rst

@@ -31,7 +31,7 @@ Syntax
        v_name = per-atom vector calculated by an atom-style variable with name
 
 * zero or more keyword/arg pairs may be appended
-* keyword = *norm* or *ave* or *bias* or *adof* or *cdof* or *file* or *overwrite* or *format* or *title1* or *title2* or *title3*
+* keyword = *norm* or *ave* or *bias* or *adof* or *cdof* or *file* or *append* or *overwrite* or *format* or *title1* or *title2* or *title3*
 
   .. parsed-literal::
 
@@ -51,6 +51,8 @@ Syntax
          dof_per_chunk = define this many degrees-of-freedom per chunk for temperature calculation
        *file* arg = filename
          filename = file to write results to
+       *append* arg = filename
+         filename = file to append results to
        *overwrite* arg = none = overwrite output file with only latest output
        *format* arg = string
          string = C-style format string
@@ -433,15 +435,21 @@ molecule.
 
 ----------
 
-The *file* keyword allows a filename to be specified.  Every
+.. versionadded:: 17Apr2024
-:math:`N_\text{freq}` timesteps, a section of chunk info will be written to a
+   new keyword *append*
-text file in the following format.  A line with the timestep and number of
+
-chunks is written.  Then one line per chunk is written, containing the chunk
+The *file* or *append* keywords allow a filename to be specified.  If
-ID :math:`(1-N_\text{chunk}),` an optional original ID value, optional
+*file* is used, then the filename is overwritten if it already exists.
-coordinate values for chunks that represent spatial bins, the number of atoms
+If *append* is used, then the filename is appended to if it already
-in the chunk, and one or more calculated values.  More explanation of the
+exists, or created if it does not exist.  Every :math:`N_\text{freq}`
-optional values is given below.  The number of values in each line
+timesteps, a section of chunk info will be written to a text file in the
-corresponds to the number of values specified in the fix ave/chunk
+following format.  A line with the timestep and number of chunks is
+written.  Then one line per chunk is written, containing the chunk ID
+:math:`(1-N_\text{chunk}),` an optional original ID value, optional
+coordinate values for chunks that represent spatial bins, the number of
+atoms in the chunk, and one or more calculated values.  More explanation
+of the optional values is given below.  The number of values in each
+line corresponds to the number of values specified in the fix ave/chunk
 command.  The number of atoms and the value(s) are summed or average
 quantities, as explained above.
 

doc/src/fix_ave_correlate.rst

@@ -65,7 +65,6 @@ Examples
    fix 1 all ave/correlate 1 50 10000 &
              c_thermo_press[1] c_thermo_press[2] c_thermo_press[3] &
              type upper ave running title1 "My correlation data"
-
    fix 1 all ave/correlate 1 50 10000 c_thermo_press[*]
 
 Description

doc/src/fix_ave_correlate_long.rst

@@ -20,11 +20,11 @@ Syntax
   .. parsed-literal::
 
        c_ID = global scalar calculated by a compute with ID
-       c_ID[I] = Ith component of global vector calculated by a compute with ID
+       c_ID[I] = Ith component of global vector calculated by a compute with ID, I can include wildcard (see below)
        f_ID = global scalar calculated by a fix with ID
-       f_ID[I] = Ith component of global vector calculated by a fix with ID
+       f_ID[I] = Ith component of global vector calculated by a fix with ID, I can include wildcard (see below)
        v_name = global value calculated by an equal-style variable with name
-       v_name[I] = Ith component of global vector calculated by a vector-style variable with name
+       v_name[I] = Ith component of a vector-style variable with name, I can include wildcard (see below)
 
 * zero or more keyword/arg pairs may be appended
 * keyword = *type* or *start* or *file* or *overwrite* or *title1* or *title2* or *ncorr* or *nlen* or *ncount*
@@ -63,6 +63,7 @@ Examples
    fix 1 all ave/correlate/long 1 10000 &
              c_thermo_press[1] c_thermo_press[2] c_thermo_press[3] &
              type upper title1 "My correlation data" nlen 15 ncount 3
+   fix 1 all ave/correlate/long 1 10000 c_thermo_press[*]
 
 Description
 """""""""""
@@ -80,8 +81,10 @@ specified values may represent calculations performed by computes and
 fixes which store their own "group" definitions.
 
 Each listed value can be the result of a compute or fix or the
-evaluation of an equal-style variable. See the
+evaluation of an equal-style or vector-style variable.  For
-:doc:`fix ave/correlate <fix_ave_correlate>` page for details.
+vector-style variables, the specified indices can include a wildcard
+character.  See the :doc:`fix ave/correlate <fix_ave_correlate>` page
+for details.
 
 The *Nevery* and *Nfreq* arguments specify on what time steps the input
 values will be used to calculate correlation data and the frequency

doc/src/fix_ave_histo.rst

@@ -35,7 +35,7 @@ Syntax
        v_name[I] = value calculated by a vector-style variable with name, I can include wildcard (see below)
 
 * zero or more keyword/arg pairs may be appended
-* keyword = *mode* or *kind* or *file* or *ave* or *start* or *beyond* or *overwrite* or *title1* or *title2* or *title3*
+* keyword = *mode* or *kind* or *file* or *append* or *ave* or *start* or *beyond* or *overwrite* or *title1* or *title2* or *title3*
 
   .. parsed-literal::
 
@@ -45,6 +45,8 @@ Syntax
        *kind* arg = *global* or *peratom* or *local*
        *file* arg = filename
          filename = name of file to output histogram(s) to
+       *append* arg = filename
+         filename = name of file to append histogram(s) to
        *ave* args = *one* or *running* or *window*
          one = output a new average value every Nfreq steps
          running = output cumulative average of all previous Nfreq steps
@@ -317,19 +319,25 @@ on.  The default is step 0.  Often input values can be 0.0 at time 0,
 so setting *start* to a larger value can avoid including a 0.0 in
 a running or windowed histogram.
 
-The *file* keyword allows a filename to be specified.  Every *Nfreq*
+.. versionadded:: 17Apr2024
-steps, one histogram is written to the file.  This includes a leading
+   new keyword *append*
-line that contains the timestep, number of bins, the total count of
+
-values contributing to the histogram, the count of values that were
+The *file* or *append* keywords allow a filename to be specified.  If
-not histogrammed (see the *beyond* keyword), the minimum value
+*file* is used, then the filename is overwritten if it already exists.
-encountered, and the maximum value encountered.  The min/max values
+If *append* is used, then the filename is appended to if it already
-include values that were not histogrammed.  Following the leading
+exists, or created if it does not exist.  Every *Nfreq* steps, one
-line, one line per bin is written into the file.  Each line contains
+histogram is written to the file.  This includes a leading line that
-the bin #, the coordinate for the center of the bin (between *lo* and
+contains the timestep, number of bins, the total count of values
-*hi*\ ), the count of values in the bin, and the normalized count.  The
+contributing to the histogram, the count of values that were not
-normalized count is the bin count divided by the total count (not
+histogrammed (see the *beyond* keyword), the minimum value encountered,
-including values not histogrammed), so that the normalized values sum
+and the maximum value encountered.  The min/max values include values
-to 1.0 across all bins.
+that were not histogrammed.  Following the leading line, one line per
+bin is written into the file.  Each line contains the bin #, the
+coordinate for the center of the bin (between *lo* and *hi*\ ), the
+count of values in the bin, and the normalized count.  The normalized
+count is the bin count divided by the total count (not including values
+not histogrammed), so that the normalized values sum to 1.0 across all
+bins.
 
 The *overwrite* keyword will continuously overwrite the output file
 with the latest output, so that it only contains one timestep worth of

doc/src/fix_ave_time.rst

@@ -28,7 +28,7 @@ Syntax
        v_name[I] = value calculated by a vector-style variable with name, I can include wildcard (see below)
 
 * zero or more keyword/arg pairs may be appended
-* keyword = *mode* or *file* or *ave* or *start* or *off* or *overwrite* or *format* or *title1* or *title2* or *title3*
+* keyword = *mode* or *file* or *append* or *ave* or *start* or *off* or *overwrite* or *format* or *title1* or *title2* or *title3*
 
   .. parsed-literal::
 
@@ -45,6 +45,8 @@ Syntax
          M = value # from 1 to Nvalues
        *file* arg = filename
          filename = name of file to output time averages to
+       *append* arg = filename
+         filename = name of file to append time averages to
        *overwrite* arg = none = overwrite output file with only latest output
        *format* arg = string
          string = C-style format string
@@ -270,16 +272,21 @@ are effectively constant or are simply current values (e.g., they are
 being written to a file with other time-averaged values for purposes
 of creating well-formatted output).
 
-The *file* keyword allows a filename to be specified.  Every *Nfreq*
+.. versionadded:: 17Apr2024
-steps, one quantity or vector of quantities is written to the file for
+   new keyword *append*
-each input value specified in the fix ave/time command.  For *mode* =
+
-scalar, this means a single line is written each time output is
+The *file* or *append* keywords allow a filename to be specified.  If
-performed.  Thus the file ends up to be a series of lines, i.e. one
+*file* is used, then the filename is overwritten if it already exists.
-column of numbers for each input value.  For *mode* = vector, an array
+If *append* is used, then the filename is appended to if it already
-of numbers is written each time output is performed.  The number of rows
+exists, or created if it does not exist.  Every *Nfreq* steps, one
-is the length of the input vectors, and the number of columns is the
+quantity or vector of quantities is written to the file for each input
-number of values.  Thus the file ends up to be a series of these array
+value specified in the fix ave/time command.  For *mode* = scalar, this
-sections.
+means a single line is written each time output is performed.  Thus the
+file ends up to be a series of lines, i.e. one column of numbers for
+each input value.  For *mode* = vector, an array of numbers is written
+each time output is performed.  The number of rows is the length of the
+input vectors, and the number of columns is the number of values.  Thus
+the file ends up to be a series of these array sections.
 
 .. versionadded:: 4May2022
 

doc/src/fix_balance.rst

@@ -14,15 +14,15 @@ Syntax
 * balance = style name of this fix command
 * Nfreq = perform dynamic load balancing every this many steps
 * thresh = imbalance threshold that must be exceeded to perform a re-balance
-* style = *shift* or *rcb*
+* style = *shift* or *rcb* or *report*
-
   .. parsed-literal::
 
-       shift args = dimstr Niter stopthresh
+       *shift* args = dimstr Niter stopthresh
          dimstr = sequence of letters containing *x* or *y* or *z*, each not more than once
          Niter = # of times to iterate within each dimension of dimstr sequence
          stopthresh = stop balancing when this imbalance threshold is reached
        *rcb* args = none
+       *report* args = none
 
 * zero or more keyword/arg pairs may be appended
 * keyword = *weight* or *out*
@@ -70,6 +70,13 @@ re-balancing is performed periodically during the simulation.  To
 perform "static" balancing, before or between runs, see the
 :doc:`balance <balance>` command.
 
+.. versionadded:: 17Apr2024
+
+The *report* balance style only computes the load imbalance but
+does not attempt any re-balancing.  This way the load imbalance
+information can be used otherwise, for instance for stopping a
+run with :doc:`fix halt <fix_halt>`.
+
 Load-balancing is typically most useful if the particles in the
 simulation box have a spatially-varying density distribution or
 where the computational cost varies significantly between different

doc/src/fix_charge_regulation.rst

@@ -253,11 +253,11 @@ built with that package.  See the :doc:`Build package <Build_package>`
 page for more info.
 
 The :doc:`atom_style <atom_style>`, used must contain the charge
-property, for example, the style could be *charge* or *full*. Only
+property and have per atom type masses, for example, the style could be
-usable for 3D simulations. Atoms specified as free ions cannot be part
+*charge* or *full*. Only usable for 3D simulations.  Atoms specified as
-of rigid bodies or molecules and cannot have bonding interactions. The
+free ions cannot be part of rigid bodies or molecules and cannot have
-scheme is limited to integer charges, any atoms with non-integer charges
+bonding interactions.  The scheme is limited to integer charges, any
-will not be considered by the fix.
+atoms with non-integer charges will not be considered by the fix.
 
 All interaction potentials used must be continuous, otherwise the MD
 integration and the particle exchange MC moves do not correspond to the

doc/src/fix_deform.rst

@@ -4,6 +4,9 @@
 fix deform command
 ==================
 
+:doc:`fix deform/pressure <fix_deform_pressure>` command
+========================================================
+
 Accelerator Variants: *deform/kk*
 
 Syntax
@@ -11,18 +14,18 @@ Syntax
 
 .. code-block:: LAMMPS
 
-   fix ID group-ID deform N parameter args ... keyword value ...
+   fix ID group-ID fix_style N parameter style args ... keyword value ...
 
 * ID, group-ID are documented in :doc:`fix <fix>` command
-* deform = style name of this fix command
+* fix_style = *deform* or *deform/pressure*
 * N = perform box deformation every this many timesteps
-* one or more parameter/arg pairs may be appended
+* one or more parameter/style/args sequences of arguments may be appended
 
   .. parsed-literal::
 
      parameter = *x* or *y* or *z* or *xy* or *xz* or *yz*
        *x*, *y*, *z* args = style value(s)
-         style = *final* or *delta* or *scale* or *vel* or *erate* or *trate* or *volume* or *wiggle* or *variable*
+         style = *final* or *delta* or *scale* or *vel* or *erate* or *trate* or *volume* or *wiggle* or *variable* or *pressure* or *pressure/mean*
            *final* values = lo hi
              lo hi = box boundaries at end of run (distance units)
            *delta* values = dlo dhi
@@ -43,8 +46,15 @@ Syntax
            *variable* values = v_name1 v_name2
              v_name1 = variable with name1 for box length change as function of time
              v_name2 = variable with name2 for change rate as function of time
+           *pressure* values = target gain (ONLY available in :doc:`fix deform/pressure <fix_deform_pressure>` command)
+             target = target pressure (pressure units)
+             gain = proportional gain constant (1/(time * pressure) or 1/time units)
+           *pressure/mean* values = target gain (ONLY available in :doc:`fix deform/pressure <fix_deform_pressure>` command)
+             target = target pressure (pressure units)
+             gain = proportional gain constant (1/(time * pressure) or 1/time units)
+
        *xy*, *xz*, *yz* args = style value
-         style = *final* or *delta* or *vel* or *erate* or *trate* or *wiggle*
+         style = *final* or *delta* or *vel* or *erate* or *trate* or *wiggle* or *variable*
            *final* value = tilt
              tilt = tilt factor at end of run (distance units)
            *delta* value = dtilt
@@ -62,9 +72,12 @@ Syntax
            *variable* values = v_name1 v_name2
              v_name1 = variable with name1 for tilt change as function of time
              v_name2 = variable with name2 for change rate as function of time
+           *pressure* values = target gain (ONLY available in :doc:`fix deform/pressure <fix_deform_pressure>` command)
+             target = target pressure (pressure units)
+             gain = proportional gain constant (1/(time * pressure) or 1/time units)
 
 * zero or more keyword/value pairs may be appended
-* keyword = *remap* or *flip* or *units*
+* keyword = *remap* or *flip* or *units* or *couple* or *vol/balance/p* or *max/rate* or *normalize/pressure*
 
   .. parsed-literal::
 
@@ -77,6 +90,15 @@ Syntax
        *units* value = *lattice* or *box*
          lattice = distances are defined in lattice units
          box = distances are defined in simulation box units
+       *couple* value = *none* or *xyz* or *xy* or *yz* or *xz* (ONLY available in :doc:`fix deform/pressure <fix_deform_pressure>` command)
+         couple pressure values of various dimensions
+       *vol/balance/p* value = *yes* or *no* (ONLY available in :doc:`fix deform/pressure <fix_deform_pressure>` command)
+         Modifies the behavior of the *volume* option to try and balance pressures
+       *max/rate* value = *rate* (ONLY available in :doc:`fix deform/pressure <fix_deform_pressure>` command)
+         rate = maximum strain rate for pressure control
+       *normalize/pressure* value = *yes* or *no* (ONLY available in :doc:`fix deform/pressure <fix_deform_pressure>` command)
+         Modifies pressure controls such that the deviation in pressure is normalized by the target pressure
+
 
 Examples
 """"""""
@@ -88,6 +110,8 @@ Examples
    fix 1 all deform 1 xy erate 0.001 remap v
    fix 1 all deform 10 y delta -0.5 0.5 xz vel 1.0
 
+See examples for :doc:`fix deform/pressure <fix_deform_pressure>` on its doc page
+
 Description
 """""""""""
 
@@ -95,29 +119,46 @@ Change the volume and/or shape of the simulation box during a dynamics
 run.  Orthogonal simulation boxes have 3 adjustable parameters
 (x,y,z).  Triclinic (non-orthogonal) simulation boxes have 6
 adjustable parameters (x,y,z,xy,xz,yz).  Any or all of them can be
-adjusted independently and simultaneously by this command.
+adjusted independently and simultaneously.
 
-This fix can be used to perform non-equilibrium MD (NEMD) simulations
+The fix deform command allows use of all the arguments listed above,
-of a continuously strained system.  See the :doc:`fix nvt/sllod <fix_nvt_sllod>` and :doc:`compute temp/deform <compute_temp_deform>` commands for more details.  Note
+except those flagged as available ONLY for the :doc:`fix
-that simulation of a continuously extended system (extensional flow)
+deform/pressure <fix_deform_pressure>` command, which are
-can be modeled using the :ref:`UEF package <PKG-UEF>` and its :doc:`fix commands <fix_nh_uef>`.
+pressure-based controls.  The fix deform/pressure command allows use
+of all the arguments listed above.
+
+The rest of this doc page explains the options common to both
+commands.  The :doc:`fix deform/pressure <fix_deform_pressure>` doc
+page explains the options available ONLY with the fix deform/pressure
+command.  Note that a simulation can define only a single deformation
+command: fix deform or fix deform/pressure.
+
+Both these fixes can be used to perform non-equilibrium MD (NEMD)
+simulations of a continuously strained system.  See the :doc:`fix
+nvt/sllod <fix_nvt_sllod>` and :doc:`compute temp/deform
+<compute_temp_deform>` commands for more details.  Note that
+simulation of a continuously extended system (extensional flow) can be
+modeled using the :ref:`UEF package <PKG-UEF>` and its :doc:`fix
+commands <fix_nh_uef>`.
 
 For the *x*, *y*, *z* parameters, the associated dimension cannot be
 shrink-wrapped.  For the *xy*, *yz*, *xz* parameters, the associated
-second dimension cannot be shrink-wrapped.  Dimensions not varied by this
+second dimension cannot be shrink-wrapped.  Dimensions not varied by
-command can be periodic or non-periodic.  Dimensions corresponding to
+this command can be periodic or non-periodic.  Dimensions
-unspecified parameters can also be controlled by a :doc:`fix npt <fix_nh>` or :doc:`fix nph <fix_nh>` command.
+corresponding to unspecified parameters can also be controlled by a
+:doc:`fix npt <fix_nh>` or :doc:`fix nph <fix_nh>` command.
 
 The size and shape of the simulation box at the beginning of the
-simulation run were either specified by the
+simulation run were either specified by the :doc:`create_box
-:doc:`create_box <create_box>` or :doc:`read_data <read_data>` or
+<create_box>` or :doc:`read_data <read_data>` or :doc:`read_restart
-:doc:`read_restart <read_restart>` command used to setup the simulation
+<read_restart>` command used to setup the simulation initially if it
-initially if it is the first run, or they are the values from the end
+is the first run, or they are the values from the end of the previous
-of the previous run.  The :doc:`create_box <create_box>`, :doc:`read data <read_data>`, and :doc:`read_restart <read_restart>` commands
+run.  The :doc:`create_box <create_box>`, :doc:`read data
-specify whether the simulation box is orthogonal or non-orthogonal
+<read_data>`, and :doc:`read_restart <read_restart>` commands specify
-(triclinic) and explain the meaning of the xy,xz,yz tilt factors.  If
+whether the simulation box is orthogonal or non-orthogonal (triclinic)
-fix deform changes the xy,xz,yz tilt factors, then the simulation box
+and explain the meaning of the xy,xz,yz tilt factors.  If fix deform
-must be triclinic, even if its initial tilt factors are 0.0.
+changes the xy,xz,yz tilt factors, then the simulation box must be
+triclinic, even if its initial tilt factors are 0.0.
 
 As described below, the desired simulation box size and shape at the
 end of the run are determined by the parameters of the fix deform
@@ -258,21 +299,22 @@ of the units keyword below.
 
 The *variable* style changes the specified box length dimension by
 evaluating a variable, which presumably is a function of time.  The
-variable with *name1* must be an :doc:`equal-style variable <variable>`
+variable with *name1* must be an :doc:`equal-style variable
-and should calculate a change in box length in units of distance.
+<variable>` and should calculate a change in box length in units of
-Note that this distance is in box units, not lattice units; see the
+distance.  Note that this distance is in box units, not lattice units;
-discussion of the *units* keyword below.  The formula associated with
+see the discussion of the *units* keyword below.  The formula
-variable *name1* can reference the current timestep.  Note that it
+associated with variable *name1* can reference the current timestep.
-should return the "change" in box length, not the absolute box length.
+Note that it should return the "change" in box length, not the
-This means it should evaluate to 0.0 when invoked on the initial
+absolute box length.  This means it should evaluate to 0.0 when
-timestep of the run following the definition of fix deform.  It should
+invoked on the initial timestep of the run following the definition of
-evaluate to a value > 0.0 to dilate the box at future times, or a
+fix deform.  It should evaluate to a value > 0.0 to dilate the box at
-value < 0.0 to compress the box.
+future times, or a value < 0.0 to compress the box.
 
-The variable *name2* must also be an :doc:`equal-style variable <variable>` and should calculate the rate of box length
+The variable *name2* must also be an :doc:`equal-style variable
-change, in units of distance/time, i.e. the time-derivative of the
+<variable>` and should calculate the rate of box length change, in
-*name1* variable.  This quantity is used internally by LAMMPS to reset
+units of distance/time, i.e. the time-derivative of the *name1*
-atom velocities when they cross periodic boundaries.  It is computed
+variable.  This quantity is used internally by LAMMPS to reset atom
+velocities when they cross periodic boundaries.  It is computed
 internally for the other styles, but you must provide it when using an
 arbitrary variable.
 
@@ -414,12 +456,13 @@ can reference the current timestep.  Note that it should return the
 should evaluate to 0.0 when invoked on the initial timestep of the run
 following the definition of fix deform.
 
-The variable *name2* must also be an :doc:`equal-style variable <variable>` and should calculate the rate of tilt change,
+The variable *name2* must also be an :doc:`equal-style variable
-in units of distance/time, i.e. the time-derivative of the *name1*
+<variable>` and should calculate the rate of tilt change, in units of
-variable.  This quantity is used internally by LAMMPS to reset atom
+distance/time, i.e. the time-derivative of the *name1* variable.  This
-velocities when they cross periodic boundaries.  It is computed
+quantity is used internally by LAMMPS to reset atom velocities when
-internally for the other styles, but you must provide it when using an
+they cross periodic boundaries.  It is computed internally for the
-arbitrary variable.
+other styles, but you must provide it when using an arbitrary
+variable.
 
 Here is an example of using the *variable* style to perform the same
 box deformation as the *wiggle* style formula listed above, where we
@@ -510,33 +553,40 @@ box without explicit remapping of their coordinates.
 .. note::
 
    For non-equilibrium MD (NEMD) simulations using "remap v" it is
-   usually desirable that the fluid (or flowing material, e.g. granular
+   usually desirable that the fluid (or flowing material,
-   particles) stream with a velocity profile consistent with the
+   e.g. granular particles) stream with a velocity profile consistent
-   deforming box.  As mentioned above, using a thermostat such as :doc:`fix nvt/sllod <fix_nvt_sllod>` or :doc:`fix lavgevin <fix_langevin>`
+   with the deforming box.  As mentioned above, using a thermostat
-   (with a bias provided by :doc:`compute temp/deform <compute_temp_deform>`), will typically accomplish
+   such as :doc:`fix nvt/sllod <fix_nvt_sllod>` or :doc:`fix lavgevin
-   that.  If you do not use a thermostat, then there is no driving force
+   <fix_langevin>` (with a bias provided by :doc:`compute temp/deform
-   pushing the atoms to flow in a manner consistent with the deforming
+   <compute_temp_deform>`), will typically accomplish that.  If you do
-   box.  E.g. for a shearing system the box deformation velocity may vary
+   not use a thermostat, then there is no driving force pushing the
+   atoms to flow in a manner consistent with the deforming box.
+   E.g. for a shearing system the box deformation velocity may vary
    from 0 at the bottom to 10 at the top of the box.  But the stream
-   velocity profile of the atoms may vary from -5 at the bottom to +5 at
+   velocity profile of the atoms may vary from -5 at the bottom to +5
-   the top.  You can monitor these effects using the :doc:`fix ave/chunk <fix_ave_chunk>`, :doc:`compute temp/deform <compute_temp_deform>`, and :doc:`compute temp/profile <compute_temp_profile>` commands.  One way to induce
+   at the top.  You can monitor these effects using the :doc:`fix
-   atoms to stream consistent with the box deformation is to give them an
+   ave/chunk <fix_ave_chunk>`, :doc:`compute temp/deform
+   <compute_temp_deform>`, and :doc:`compute temp/profile
+   <compute_temp_profile>` commands.  One way to induce atoms to
+   stream consistent with the box deformation is to give them an
    initial velocity profile, via the :doc:`velocity ramp <velocity>`
-   command, that matches the box deformation rate.  This also typically
+   command, that matches the box deformation rate.  This also
-   helps the system come to equilibrium more quickly, even if a
+   typically helps the system come to equilibrium more quickly, even
-   thermostat is used.
+   if a thermostat is used.
 
 .. note::
 
    If a :doc:`fix rigid <fix_rigid>` is defined for rigid bodies, and
    *remap* is set to *x*, then the center-of-mass coordinates of rigid
-   bodies will be remapped to the changing simulation box.  This will be
+   bodies will be remapped to the changing simulation box.  This will
-   done regardless of whether atoms in the rigid bodies are in the fix
+   be done regardless of whether atoms in the rigid bodies are in the
-   deform group or not.  The velocity of the centers of mass are not
+   fix deform group or not.  The velocity of the centers of mass are
-   remapped even if *remap* is set to *v*, since :doc:`fix nvt/sllod <fix_nvt_sllod>` does not currently do anything special
+   not remapped even if *remap* is set to *v*, since :doc:`fix
+   nvt/sllod <fix_nvt_sllod>` does not currently do anything special
    for rigid particles.  If you wish to perform a NEMD simulation of
    rigid particles, you can either thermostat them independently or
-   include a background fluid and thermostat the fluid via :doc:`fix nvt/sllod <fix_nvt_sllod>`.
+   include a background fluid and thermostat the fluid via :doc:`fix
+   nvt/sllod <fix_nvt_sllod>`.
 
 The *flip* keyword allows the tilt factors for a triclinic box to
 exceed half the distance of the parallel box length, as discussed
@@ -568,7 +618,8 @@ command if you want to include lattice spacings in a variable formula.
 Restart, fix_modify, output, run start/stop, minimize info
 """""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 
-This fix will restore the initial box settings from :doc:`binary restart files <restart>`, which allows the fix to be properly continue
+This fix will restore the initial box settings from :doc:`binary
+restart files <restart>`, which allows the fix to be properly continue
 deformation, when using the start/stop options of the :doc:`run <run>`
 command.  None of the :doc:`fix_modify <fix_modify>` options are
 relevant to this fix.  No global or per-atom quantities are stored by
@@ -586,12 +637,14 @@ Restrictions
 You cannot apply x, y, or z deformations to a dimension that is
 shrink-wrapped via the :doc:`boundary <boundary>` command.
 
-You cannot apply xy, yz, or xz deformations to a second dimension (y in
+You cannot apply xy, yz, or xz deformations to a second dimension (y
-xy) that is shrink-wrapped via the :doc:`boundary <boundary>` command.
+in xy) that is shrink-wrapped via the :doc:`boundary <boundary>`
+command.
 
 Related commands
 """"""""""""""""
 
+:doc:`fix deform/pressure <fix_deform_pressure>`,
 :doc:`change_box <change_box>`
 
 Default

doc/src/fix_deform_pressure.rst

@@ -0,0 +1,336 @@
+.. index:: fix deform/pressure
+
+fix deform/pressure command
+===========================
+
+Syntax
+""""""
+
+.. parsed-literal::
+
+   fix ID group-ID deform/pressure N parameter style args ... keyword value ...
+
+* ID, group-ID are documented in :doc:`fix <fix>` command
+* deform/pressure = style name of this fix command
+* N = perform box deformation every this many timesteps
+* one or more parameter/arg sequences may be appended
+
+  .. parsed-literal::
+
+     parameter = *x* or *y* or *z* or *xy* or *xz* or *yz* or *box*
+       *x*, *y*, *z* args = style value(s)
+         style = *final* or *delta* or *scale* or *vel* or *erate* or *trate* or *volume* or *wiggle* or *variable* or *pressure* or *pressure/mean*
+           *pressure* values = target gain
+             target = target pressure (pressure units)
+             gain = proportional gain constant (1/(time * pressure) or 1/time units)
+           *pressure/mean* values = target gain
+             target = target pressure (pressure units)
+             gain = proportional gain constant (1/(time * pressure) or 1/time units)
+           NOTE: All other styles are documented by the :doc:`fix deform <fix_deform>` command
+
+       *xy*, *xz*, *yz* args = style value
+         style = *final* or *delta* or *vel* or *erate* or *trate* or *wiggle* or *variable* or *pressure* or *erate/rescale*
+           *pressure* values = target gain
+             target = target pressure (pressure units)
+             gain = proportional gain constant (1/(time * pressure) or 1/time units)
+           *erate/rescale* value = R
+             R = engineering shear strain rate (1/time units)
+           NOTE: All other styles are documented by the :doc:`fix deform <fix_deform>` command
+
+       *box* = style value
+         style = *volume* or *pressure*
+           *volume* value = none = isotropically adjust system to preserve volume of system
+           *pressure* values = target gain
+             target = target mean pressure (pressure units)
+             gain = proportional gain constant (1/(time * pressure) or 1/time units)
+
+* zero or more keyword/value pairs may be appended
+* keyword = *remap* or *flip* or *units* or *couple* or *vol/balance/p* or *max/rate* or *normalize/pressure*
+
+  .. parsed-literal::
+
+       *couple* value = *none* or *xyz* or *xy* or *yz* or *xz*
+         couple pressure values of various dimensions
+       *vol/balance/p* value = *yes* or *no*
+         Modifies the behavior of the *volume* option to try and balance pressures
+       *max/rate* value = *rate*
+         rate = maximum strain rate for pressure control
+       *normalize/pressure* value = *yes* or *no*
+         Modifies pressure controls such that the deviation in pressure is normalized by the target pressure
+       NOTE: All other keywords are documented by the :doc:`fix deform <fix_deform>` command
+
+Examples
+""""""""
+
+.. code-block:: LAMMPS
+
+   fix 1 all deform/pressure 1 x pressure 2.0 0.1 normalize/pressure yes max/rate 0.001
+   fix 1 all deform/pressure 1 x trate 0.1 y volume z volume vol/balance/p yes
+   fix 1 all deform/pressure 1 x trate 0.1 y pressure/mean 0.0 1.0 z pressure/mean 0.0 1.0
+
+Description
+"""""""""""
+
+.. versionadded:: 17Apr2024
+
+This fix is an extension of the :doc:`fix deform <fix_deform>`
+command, which allows all of its options to be used as well as new
+pressure-based controls implemented by this command.
+
+All arguments described on the :doc:`fix deform <fix_deform>` doc page
+also apply to this fix unless otherwise noted below.  The rest of this
+doc page explains the arguments specific to this fix.  Note that a
+simulation can define only a single deformation command: fix deform or
+fix deform/pressure.
+
+----------
+
+For the *x*, *y*, and *z* parameters, this is the meaning of the
+styles and values provided by this fix.
+
+The *pressure* style adjusts a dimension's box length to control the
+corresponding component of the pressure tensor. This option attempts to
+maintain a specified target pressure using a linear controller where the
+box length :math:`L` evolves according to the equation
+
+.. math::
+
+   \frac{d L(t)}{dt} = L(t) k (P_t - P)
+
+where :math:`k` is a proportional gain constant, :math:`P_t` is the target
+pressure, and :math:`P` is the current pressure along that dimension. This
+approach is similar to the method used to control the pressure by
+:doc:`fix press/berendsen <fix_press_berendsen>`. The target pressure
+accepts either a constant numeric value or a LAMMPS :ref:`variable <variable>`.
+Notably, this variable can be a function of time or other components of
+the pressure tensor. By default, :math:`k` has units of 1/(time * pressure)
+although this will change if the *normalize/pressure* option is set as
+:ref:`discussed below <deform_normalize>`. There is no proven method
+to choosing an appropriate value of :math:`k` as it will depend on the
+specific details of a simulation. Testing different values is recommended.
+
+By default, there is no limit on the resulting strain rate in any dimension.
+A maximum limit can be applied using the :ref:`max/rate <deform_max_rate>`
+option. Akin to :doc:`fix nh <fix_nh>`, pressures in different dimensions
+can be coupled using the :ref:`couple <deform_couple>` option. This means
+the instantaneous pressure along coupled dimensions are averaged and the box
+strains identically along the coupled dimensions.
+
+The *pressure/mean* style changes a dimension's box length to maintain
+a constant mean pressure defined as the trace of the pressure tensor.
+This option has identical arguments to the *pressure* style and a similar
+functional equation, except the current and target pressures refer to the
+mean trace of the pressure tensor. All options for the *pressure* style
+also apply to the *pressure/mean* style except for the
+:ref:`couple <deform_couple>` option.
+
+Note that while this style can be identical to coupled *pressure* styles,
+it is generally not the same. For instance in 2D, a coupled *pressure*
+style in the *x* and *y* dimensions would be equivalent to using the
+*pressure/mean* style with identical settings in each dimension. However,
+it would not be the same if settings (e.g. gain constants) were used in
+the *x* and *y* dimensions or if the *pressure/mean* command was only applied
+along one dimension.
+
+----------
+
+For the *xy*, *xz*, and *yz* parameters, this is the meaning of the
+styles and values provided by this fix.  Note that changing the
+tilt factors of a triclinic box does not change its volume.
+
+The *pressure* style adjusts a tilt factor to control the corresponding
+off-diagonal component of the pressure tensor. This option attempts to
+maintain a specified target value using a linear controller where the
+tilt factor T evolves according to the equation
+
+.. parsed-literal::
+
+   \frac{d T(t)}{dt} = L(t) k (P - P_t)
+
+where :math:`k` is a proportional gain constant, :math:`P_t` is the
+target pressure, :math:`P` is the current pressure, and :math:`L` is
+the perpendicular box length. The target pressure accepts either a
+constant numeric value or a LAMMPS :ref:`variable
+<variable>`. Notably, this variable can be a function of time or other
+components of the pressure tensor. By default, :math:`k` has units of
+1/(time * pressure) although this will change if the
+*normalize/pessure* option is set as :ref:`discussed below
+<deform_normalize>`.  There is no proven method to choosing an
+appropriate value of :math:`k` as it will depend on the specific
+details of a simulation and testing different values is
+recommended. One can also apply a maximum limit to the magnitude of
+the applied strain using the :ref:`max/rate <deform_max_rate>` option.
+
+The *erate/rescale* style operates similarly to the *erate* style with
+a specified strain rate in units of 1/time. The difference is that
+the change in the tilt factor will depend on the current length of
+the box perpendicular to the shear direction, L, instead of the
+original length, L0. The tilt factor T as a function of time will
+change as
+
+.. parsed-literal::
+
+   T(t) = T(t-1) + L\*erate\* \Delta t
+
+where T(t-1) is the tilt factor on the previous timestep and :math:`\Delta t`
+is the timestep size. This option may be useful in scenarios where
+L changes in time.
+
+----------
+
+The *box* parameter provides an additional control over the *x*, *y*,
+and *z* box lengths by isotropically dilating or contracting the box
+to either maintain a fixed mean pressure or volume. This isotropic
+scaling is applied after the box is deformed by the above *x*, *y*,
+*z*, *xy*, *xz*, and *yz* styles, acting as a second deformation
+step. This parameter will change the overall strain rate in the *x*,
+*y*, or *z* dimensions.  This parameter can only be used in
+combination with the *x*, *y*, or *z* commands: *vel*, *erate*,
+*trate*, *pressure*, or *wiggle*. This is the meaning of its styles
+and values.
+
+The *volume* style isotropically scales box lengths to maintain a constant
+box volume in response to deformation from other parameters. This style
+may be useful in scenarios where one wants to apply a constant deviatoric
+pressure using *pressure* styles in the *x*, *y*, and *z* dimensions (
+deforming the shape of the box), while maintaining a constant volume.
+
+The *pressure* style isotropically scales box lengths in an attempt to
+maintain a target mean pressure (the trace of the pressure tensor) of the
+system. This is accomplished by isotropically scaling all box lengths
+:math:`L` by an additional factor of :math:`k (P_t - P_m)` where :math:`k`
+is the proportional gain constant, :math:`P_t` is the target pressure, and
+:math:`P_m` is the current mean pressure. This style may be useful in
+scenarios where one wants to apply a constant deviatoric strain rate
+using various strain-based styles (e.g. *trate*) along the *x*, *y*, and *z*
+dimensions (deforming the shape of the box), while maintaining a mean pressure.
+
+----------
+
+The optional keywords provided by this fix are described below.
+
+.. _deform_normalize:
+
+The *normalize/pressure* keyword changes how box dimensions evolve when
+using the *pressure* or *pressure/mean* deformation styles. If the
+*deform/normalize* value is set to *yes*, then the deviation from the
+target pressure is normalized by the absolute value of the target
+pressure such that the proportional gain constant scales a percentage
+error and has units of 1/time. If the target pressure is ever zero, this
+will produce an error unless the *max/rate* keyword is defined,
+described below, which will cap the divergence.
+
+.. _deform_max_rate:
+
+The *max/rate* keyword sets an upper threshold, *rate*, that limits the
+maximum magnitude of the instantaneous strain rate applied in any dimension.
+This keyword only applies to the *pressure* and *pressure/mean* options. If
+a pressure-controlled rate is used for both *box* and either *x*, *y*, or
+*z*, then this threshold will apply separately to each individual controller
+such that the cumulative strain rate on a box dimension may be up to twice
+the value of *rate*.
+
+.. _deform_couple:
+
+The *couple* keyword allows two or three of the diagonal components of
+the pressure tensor to be "coupled" together for the *pressure* option.
+The value specified with the keyword determines which are coupled. For
+example, *xz* means the *Pxx* and *Pzz* components of the stress tensor
+are coupled. *Xyz* means all 3 diagonal components are coupled. Coupling
+means two things: the instantaneous stress will be computed as an average
+of the corresponding diagonal components, and the coupled box dimensions
+will be changed together in lockstep, meaning coupled dimensions will be
+dilated or contracted by the same percentage every timestep. If a *pressure*
+style is defined for more than one coupled dimension, the target pressures
+and gain constants must be identical. Alternatively, if a *pressure*
+style is only defined for one of the coupled dimensions, its settings are
+copied to other dimensions with undefined styles. *Couple xyz* can be used
+for a 2d simulation; the *z* dimension is simply ignored.
+
+.. _deform_balance:
+
+The *vol/balance/p* keyword modifies the behavior of the *volume* style when
+applied to two of the *x*, *y*, and *z* dimensions. Instead of straining
+the two dimensions in lockstep, the two dimensions are allowed to
+separately dilate or contract in a manner to maintain a constant
+volume while simultaneously trying to keep the pressure along each
+dimension equal using a method described in :ref:`(Huang2014) <Huang2014>`.
+
+----------
+
+If any pressure controls are used, this fix computes a temperature and
+pressure each timestep. To do this, the fix creates its own computes
+of style "temp" and "pressure", as if these commands had been issued:
+
+.. code-block:: LAMMPS
+
+   compute fix-ID_temp group-ID temp
+   compute fix-ID_press group-ID pressure fix-ID_temp
+
+See the :doc:`compute temp <compute_temp>` and :doc:`compute pressure
+<compute_pressure>` commands for details.  Note that the IDs of the
+new computes are the fix-ID + underscore + "temp" or fix_ID
++ underscore + "press", and the group for the new computes is the same
+as the fix group.
+
+Note that these are NOT the computes used by thermodynamic output (see
+the :doc:`thermo_style <thermo_style>` command) with ID =
+*thermo_temp* and *thermo_press*.  This means you can change the
+attributes of this fix's temperature or pressure via the
+:doc:`compute_modify <compute_modify>` command or print this
+temperature or pressure during thermodynamic output via the
+:doc:`thermo_style custom <thermo_style>` command using the
+appropriate compute-ID. It also means that changing attributes of
+*thermo_temp* or *thermo_press* will have no effect on this fix.
+
+Restart, fix_modify, output, run start/stop, minimize info
+"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
+
+This fix will restore the initial box settings from :doc:`binary
+restart files <restart>`, which allows the fix to be properly continue
+deformation, when using the start/stop options of the :doc:`run <run>`
+command.  No global or per-atom quantities are stored by this fix for
+access by various :doc:`output commands <Howto_output>`.
+
+If any pressure controls are used, the :doc:`fix_modify <fix_modify>`
+*temp* and *press* options are supported by this fix, unlike in
+:doc:`fix deform <fix_deform>`.  You can use them to assign a
+:doc:`compute <compute>` you have defined to this fix which will be
+used in its temperature and pressure calculations.  If you do this,
+note that the kinetic energy derived from the compute temperature
+should be consistent with the virial term computed using all atoms for
+the pressure.  LAMMPS will warn you if you choose to compute
+temperature on a subset of atoms.
+
+This fix can perform deformation over multiple runs, using the *start*
+and *stop* keywords of the :doc:`run <run>` command.  See the
+:doc:`run <run>` command for details of how to do this.
+
+This fix is not invoked during :doc:`energy minimization <minimize>`.
+
+Restrictions
+""""""""""""
+
+You cannot apply x, y, or z deformations to a dimension that is
+shrink-wrapped via the :doc:`boundary <boundary>` command.
+
+You cannot apply xy, yz, or xz deformations to a second dimension (y
+in xy) that is shrink-wrapped via the :doc:`boundary <boundary>`
+command.
+
+Related commands
+""""""""""""""""
+
+:doc:`fix deform <fix_deform>`, :doc:`change_box <change_box>`
+
+Default
+"""""""
+
+The option defaults are normalize/pressure = no.
+
+----------
+
+.. _Huang2014:
+
+**(Huang2014)** X. Huang, "Exploring critical-state behavior using DEM",
+Doctoral dissertation, Imperial College. (2014). https://doi.org/10.25560/25316

doc/src/fix_electrode.rst

@@ -45,7 +45,7 @@ Syntax
                 rng_v = integer used to initialize random number generator
 
 * zero or more keyword/value pairs may be appended
-* keyword = *algo* or *symm* or *couple* or *etypes* or *ffield* or *write_mat* or *write_inv* or *read_mat* or *read_inv*
+* keyword = *algo* or *symm* or *couple* or *etypes* or *ffield* or *write_mat* or *write_inv* or *read_mat* or *read_inv* or *qtotal* or *eta*
 
 .. parsed-literal::
 
@@ -68,6 +68,10 @@ Syntax
         filename = file from which to read elastance matrix
     *read_inv* value = filename
         filename = file from which to read inverted matrix
+    *qtotal* value = number or *v_* equal-style variable
+        add overall potential so that all electrode charges add up to *qtotal*
+    *eta* value = d_propname
+        d_propname = a custom double vector defined via fix property/atom
 
 Examples
 """"""""
@@ -249,6 +253,27 @@ be enabled if any electrode particle has the same type as any
 electrolyte particle (which would be unusual in a typical simulation)
 and the fix will issue an error in that case.
 
+.. versionadded:: 17Apr2024
+
+The keyword *qtotal* causes *fix electrode/conp* and *fix
+electrode/thermo* to add an overall potential to all electrodes so that
+the total charge on the electrodes is a specified amount (which may be
+an equal-style variable).  For example, if a user wanted to simulate a
+solution of excess cations such that the total electrolyte charge is +2,
+setting *qtotal -2* would cause the total electrode charge to be -2, so
+that the simulation box remains overall electroneutral. Since *fix
+electrode/conq* constrains the total charges of individual electrodes,
+and since *symm on* constrains the total charge of all electrodes to be
+zero, either option is incompatible with the *qtotal* keyword (even if
+*qtotal* is set to zero).
+
+.. versionadded:: 17Apr2024
+
+The keyword *eta* takes the name of a custom double vector defined via
+fix property/atom.  The values will be used instead of the standard eta
+value.  The property/atom fix must be for vector of double values and
+use the *ghost on* option.
+
 Restart, fix_modify, output, run start/stop, minimize info
 """""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 

doc/src/fix_gcmc.rst

@@ -427,7 +427,7 @@ the following global cumulative quantities:
 * 7 = rotation attempts
 * 8 = rotation successes
 
-The vector values calculated by this fix are "extensive".
+The vector values calculated by this fix are "intensive".
 
 No parameter of this fix can be used with the *start/stop* keywords of
 the :doc:`run <run>` command.  This fix is not invoked during
@@ -440,8 +440,11 @@ This fix is part of the MC package.  It is only enabled if LAMMPS was
 built with that package.  See the :doc:`Build package <Build_package>`
 doc page for more info.
 
+This fix style requires an :doc:`atom style <atom_style>` with per atom
+type masses.
+
 Do not set "neigh_modify once yes" or else this fix will never be
-called.  Reneighboring is required.
+called.  Reneighboring is **required**.
 
 Only usable for 3D simulations.
 

doc/src/fix_hyper_local.rst

@@ -512,8 +512,7 @@ Value 27 computes the average boost for biased bonds only on this step.
 Value 28 is the count of bonds with an absolute value of strain >= q
 on this step.
 
-The scalar value is an "extensive" quantity since it grows with the
+The scalar value and vector values are all "intensive".
-system size; the vector values are all "intensive".
 
 This fix also computes a local vector of length the number of bonds
 currently in the system.  The value for each bond is its :math:`C_{ij}`

doc/src/fix_indent.rst

@@ -8,13 +8,12 @@ Syntax
 
 .. code-block:: LAMMPS
 
-   fix ID group-ID indent K keyword values ...
+   fix ID group-ID indent K gstyle args keyword value ...
 
 * ID, group-ID are documented in :doc:`fix <fix>` command
 * indent = style name of this fix command
 * K = force constant for indenter surface (force/distance\^2 units)
-* one or more keyword/value pairs may be appended
+* gstyle = *sphere* or *cylinder* or *cone* or *plane*
-* keyword = *sphere* or *cylinder* or *plane* or *side* or *units*
 
   .. parsed-literal::
 
@@ -27,14 +26,26 @@ Syntax
          c1, c2 = coords of cylinder axis in other 2 dimensions (distance units)
          R = cylinder radius of indenter (distance units)
          any of c1,c2,R can be a variable (see below)
+       *cone* args = dim c1 c2 radlo radhi lo hi
+         dim = *x* or *y* or *z* = axis of cone
+         c1, c2 = coords of cone axis in other 2 dimensions (distance units)
+         radlo,radhi = cone radii at lo and hi end (distance units)
+         lo,hi = bounds of cone in dim (distance units)
+         any of c1, c2, radlo, radhi, lo, hi can be a variable (see below)
        *plane* args = dim pos side
          dim = *x* or *y* or *z* = plane perpendicular to this dimension
          pos = position of plane in dimension x, y, or z (distance units)
          pos can be a variable (see below)
          side = *lo* or *hi*
+
+* zero or more keyword/value pairs may be appended
+* keyword = *side* or *units*
+
+  .. parsed-literal::
+
        *side* value = *in* or *out*
-         *in* = the indenter acts on particles inside the sphere or cylinder
+         *in* = the indenter acts on particles inside the sphere or cylinder or cone
-         *out* = the indenter acts on particles outside the sphere or cylinder
+         *out* = the indenter acts on particles outside the sphere or cylinder or cone
        *units* value = *lattice* or *box*
          lattice = the geometry is defined in lattice units
          box = the geometry is defined in simulation box units
@@ -53,12 +64,12 @@ Description
 
 Insert an indenter within a simulation box.  The indenter repels all
 atoms in the group that touch it, so it can be used to push into a
-material or as an obstacle in a flow.  Or it can be used as a
+material or as an obstacle in a flow.  Alternatively, it can be used as a
 constraining wall around a simulation; see the discussion of the
 *side* keyword below.
 
-The indenter can either be spherical or cylindrical or planar.  You
+The *gstyle* geometry of the indenter can either be a sphere, a
-must set one of those 3 keywords.
+cylinder, a cone, or a plane.
 
 A spherical indenter exerts a force of magnitude
 
@@ -75,15 +86,20 @@ A cylindrical indenter exerts the same force, except that *r* is the
 distance from the atom to the center axis of the cylinder.  The
 cylinder extends infinitely along its axis.
 
-Spherical and cylindrical indenters account for periodic boundaries in
+A conical indenter is similar to a cylindrical indenter except that it
-two ways.  First, the center point of a spherical indenter (x,y,z) or
+has a finite length (between *lo* and *hi*), and that two different
-axis of a cylindrical indenter (c1,c2) is remapped back into the
+radii (one at each end, *radlo* and *radhi*) can be defined.
-simulation box, if the box is periodic in a particular dimension.
+
-This occurs every timestep if the indenter geometry is specified with
+Spherical, cylindrical, and conical indenters account for periodic
-a variable (see below), e.g. it is moving over time.  Second, the
+boundaries in two ways.  First, the center point of a spherical
-calculation of distance to the indenter center or axis accounts for
+indenter (x,y,z) or axis of a cylindrical/conical indenter (c1,c2) is
-periodic boundaries.  Both of these mean that an indenter can
+remapped back into the simulation box, if the box is periodic in a
-effectively move through and straddle one or more periodic boundaries.
+particular dimension.  This occurs every timestep if the indenter
+geometry is specified with a variable (see below), e.g. it is moving
+over time.  Second, the calculation of distance to the indenter center
+or axis accounts for periodic boundaries.  Both of these mean that an
+indenter can effectively move through and straddle one or more
+periodic boundaries.
 
 A planar indenter is really an axis-aligned infinite-extent wall
 exerting the same force on atoms in the system, where *R* is the
@@ -97,9 +113,13 @@ is specified as *hi*\ .
 
 Any of the 4 quantities defining a spherical indenter's geometry can
 be specified as an equal-style :doc:`variable <variable>`, namely *x*,
-*y*, *z*, or *R*\ .  Similarly, for a cylindrical indenter, any of *c1*,
+*y*, *z*, or *R*\ .  For a cylindrical indenter, any of the 3
-*c2*, or *R*, can be a variable.  For a planar indenter, *pos* can be
+quantities *c1*, *c2*, or *R*, can be a variable.  For a conical
-a variable.  If the value is a variable, it should be specified as
+indenter, any of the 6 quantities *c1*, *c2*, *radlo*, *radhi*, *lo*,
+or *hi* can be a variable.  For a planar indenter, the single value
+*pos* can be a variable.
+
+If any of these values is a variable, it should be specified as
 v_name, where name is the variable name.  In this case, the variable
 will be evaluated each timestep, and its value used to define the
 indenter geometry.
@@ -110,7 +130,8 @@ command keywords for the simulation box parameters and timestep and
 elapsed time.  Thus it is easy to specify indenter properties that
 change as a function of time or span consecutive runs in a continuous
 fashion.  For the latter, see the *start* and *stop* keywords of the
-:doc:`run <run>` command and the *elaplong* keyword of :doc:`thermo_style custom <thermo_style>` for details.
+:doc:`run <run>` command and the *elaplong* keyword of
+:doc:`thermo_style custom <thermo_style>` for details.
 
 For example, if a spherical indenter's x-position is specified as v_x,
 then this variable definition will keep it's center at a relative
@@ -141,12 +162,13 @@ rate.
 
 If the *side* keyword is specified as *out*, which is the default,
 then particles outside the indenter are pushed away from its outer
-surface, as described above.  This only applies to spherical or
+surface, as described above.  This only applies to spherical,
-cylindrical indenters.  If the *side* keyword is specified as *in*,
+cylindrical, and conical indenters.  If the *side* keyword is
-the action of the indenter is reversed.  Particles inside the indenter
+specified as *in*, the action of the indenter is reversed.  Particles
-are pushed away from its inner surface.  In other words, the indenter
+inside the indenter are pushed away from its inner surface.  In other
-is now a containing wall that traps the particles inside it.  If the
+words, the indenter is now a containing wall that traps the particles
-radius shrinks over time, it will squeeze the particles.
+inside it.  If the radius shrinks over time, it will squeeze the
+particles.
 
 The *units* keyword determines the meaning of the distance units used
 to define the indenter geometry.  A *box* value selects standard
@@ -166,10 +188,10 @@ lattice spacings in a variable formula.
 
 The force constant *K* is not affected by the *units* keyword.  It is
 always in force/distance\^2 units where force and distance are defined
-by the :doc:`units <units>` command.  If you wish K to be scaled by the
+by the :doc:`units <units>` command.  If you wish K to be scaled by
-lattice spacing, you can define K with a variable whose formula
+the lattice spacing, you can define K with a variable whose formula
-contains *xlat*, *ylat*, *zlat* keywords of the
+contains *xlat*, *ylat*, *zlat* keywords of the :doc:`thermo_style
-:doc:`thermo_style <thermo_style>` command, e.g.
+<thermo_style>` command, e.g.
 
 .. code-block:: LAMMPS
 

doc/src/fix_mol_swap.rst

@@ -146,7 +146,7 @@ the following global cumulative quantities:
 * 1 = swap attempts
 * 2 = swap accepts
 
-The vector values calculated by this fix are "extensive".
+The vector values calculated by this fix are "intensive".
 
 No parameter of this fix can be used with the *start/stop* keywords of
 the :doc:`run <run>` command.  This fix is not invoked during

doc/src/fix_nonaffine_displacement.rst

@@ -8,7 +8,7 @@ Syntax
 
 .. parsed-literal::
 
-   fix ID group nonaffine/displacement style args reference/style nstep
+   fix ID group nonaffine/displacement style args reference/style nstep keyword values
 
 * ID, group are documented in :doc:`fix <fix>` command
 * nonaffine/displacement = style name of this fix command
@@ -32,6 +32,13 @@ Syntax
        *update* = update the reference frame every *nstep* timesteps
        *offset* = update the reference frame *nstep* timesteps before calculating the nonaffine displacement
 
+* zero or more keyword/value pairs may be appended
+
+  .. parsed-literal::
+
+       *z/min* values = zmin
+         zmin = minimum coordination number to calculate D2min
+
 Examples
 """"""""
 
@@ -76,6 +83,12 @@ is the identity tensor. This calculation is only performed on timesteps that
 are a multiple of *nevery* (including timestep zero). Data accessed before
 this occurs will simply be zeroed.
 
+For particles with low coordination numbers, calculations of :math:`D^2_\mathrm{min}`
+may not be accurate. An optional minimum coordination number can be defined using
+the *z/min* keyword. If any particle has fewer than the specified number of particles
+in the cutoff distance or in contact, the above calculations will be skipped and the
+corresponding peratom array entries will be zero.
+
 The *integrated* style simply integrates the velocity of particles
 every timestep to calculate a displacement. This style only works if
 used in conjunction with another fix that deforms the box and displaces
@@ -86,8 +99,8 @@ Both of these methods require defining a reference state. With the *fixed* refer
 style, the user picks a specific timestep *nstep* at which particle positions are saved.
 If peratom data is accessed from this compute prior to this timestep, it will simply be
 zeroed. The *update* reference style implies the reference state will be updated every
-*nstep* timesteps. The *offset* reference only applies to the *d2min* metric and will
+*nstep* timesteps. The *offset* reference will update the reference state *nstep*
-update the reference state *nstep* timesteps before a multiple of *nevery* timesteps.
+timesteps before a multiple of *nevery* timesteps.
 
 
 ----------

doc/src/fix_property_atom.rst

@@ -22,6 +22,8 @@ Syntax
        *mol* = molecule IDs
        *q* = charge
        *rmass* = per-atom mass
+       *temperature* = internal temperature of atom
+       *heatflow* = internal heat flow of atom
        i_name = new integer vector referenced by name
        d_name = new floating-point vector referenced by name
        i2_name = new integer array referenced by name
@@ -59,14 +61,18 @@ these properties for each atom in the system when a data file is read.
 This fix augments the set of per-atom properties with new custom
 ones. This can be useful in several scenarios.
 
-If the atom style does not define molecule IDs, per-atom charge, or
+If the atom style does not define molecule IDs, per-atom charge,
-per-atom mass, they can be added using the *mol*\ , *q* or *rmass*
+per-atom mass, internal temperature, or internal heat flow, they can
+be added using the *mol*\ , *q*, *rmass*, *temperature*, or *heatflow*
 keywords.  This could be useful to define "molecules" to use as rigid
 bodies with the :doc:`fix rigid <fix_rigid>` command, or to carry
 around an extra flag with atoms (stored as a molecule ID) that can be
 used by various commands like :doc:`compute chunk/atom
 <compute_chunk_atom>` to group atoms without having to use the group
 command (which is limited to a total of 32 groups including *all*\ ).
+For finite-size particles, an internal temperature and heat flow can
+be used to model heat conduction as in the
+:doc:`GRANULAR package <Howto_granular>`.
 
 Another application is to use the *rmass* flag in order to have
 per-atom masses instead of per-type masses.  This could be used to
@@ -85,9 +91,10 @@ properties that are not needed such as bond lists, which incurs some
 overhead when there are no bonds.
 
 In the future, we may add additional existing per-atom properties to
-fix property/atom, similar to *mol*\ , *q* or *rmass*\ , which
+fix property/atom, similar to *mol*\ , *q*, *rmass*\ , *temperature*\ ,
-"turn-on" specific properties defined by some atom styles, so they can
+or *heatflow* which "turn-on" specific properties defined by some atom
-be easily used by atom styles that do not define them.
+styles, so they can be easily used by atom styles that do not define
+them.
 
 More generally, the *i_name* and *d_name* options allow one or more
 new custom per-atom vectors to be defined.  Likewise the *i2_name* and

doc/src/fix_reaxff_species.rst

@@ -20,7 +20,7 @@ Syntax
 * Nfreq = calculate average bond-order every this many timesteps
 * filename = name of output file
 * zero or more keyword/value pairs may be appended
-* keyword = *cutoff* or *element* or *position* or *delete*
+* keyword = *cutoff* or *element* or *position* or *delete* or *delete_rate_limit*
 
   .. parsed-literal::
 
@@ -110,10 +110,10 @@ all types from 1 to :math:`N`.  A leading asterisk means all types from
 The optional keyword *element* can be used to specify the chemical
 symbol printed for each LAMMPS atom type. The number of symbols must
 match the number of LAMMPS atom types and each symbol must consist of
-1 or 2 alphanumeric characters. Normally, these symbols should be
+1 or 2 alphanumeric characters. By default, these symbols are the same
-chosen to match the chemical identity of each LAMMPS atom type, as
+as the chemical identity of each LAMMPS atom type, as specified by the
-specified using the :doc:`reaxff pair_coeff <pair_reaxff>` command and
+:doc:`ReaxFF pair_coeff <pair_reaxff>` command and the ReaxFF force
-the ReaxFF force field file.
+field file.
 
 The optional keyword *position* writes center-of-mass positions of
 each identified molecules to file *filepos* every *posfreq* timesteps.
@@ -233,5 +233,5 @@ Default
 """""""
 
 The default values for bond-order cutoffs are 0.3 for all I-J pairs.
-The default element symbols are C, H, O, N.
+The default element symbols are taken from the ReaxFF pair_coeff command.
 Position files are not written by default.

doc/src/fix_rigid.rst

@@ -171,14 +171,15 @@ Examples of large rigid bodies are a colloidal particle, or portions
 of a biomolecule such as a protein.
 
 Example of small rigid bodies are patchy nanoparticles, such as those
-modeled in :ref:`this paper <Zhang1>` by Sharon Glotzer's group, clumps of
+modeled in :ref:`this paper <Zhang1>` by Sharon Glotzer's group,
-granular particles, lipid molecules consisting of one or more point
+clumps of granular particles, lipid molecules consisting of one or
-dipoles connected to other spheroids or ellipsoids, irregular
+more point dipoles connected to other spheroids or ellipsoids,
-particles built from line segments (2d) or triangles (3d), and
+irregular particles built from line segments (2d) or triangles (3d),
-coarse-grain models of nano or colloidal particles consisting of a
+and coarse-grain models of nano or colloidal particles consisting of a
-small number of constituent particles.  Note that the :doc:`fix shake <fix_shake>` command can also be used to rigidify small
+small number of constituent particles.  Note that the :doc:`fix shake
-molecules of 2, 3, or 4 atoms, e.g. water molecules.  That fix treats
+<fix_shake>` command can also be used to rigidify small molecules of
-the constituent atoms as point masses.
+2, 3, or 4 atoms, e.g. water molecules.  That fix treats the
+constituent atoms as point masses.
 
 These fixes also update the positions and velocities of the atoms in
 each rigid body via time integration, in the NVE, NVT, NPT, or NPH
@@ -212,13 +213,14 @@ processors when ghost atom info is accumulated.
 
 .. note::
 
-   To use the *rigid/small* styles the ghost atom cutoff must be
+   To use the *rigid/small* styles the ghost atom cutoff must be large
-   large enough to span the distance between the atom that owns the body
+   enough to span the distance between the atom that owns the body and
-   and every other atom in the body.  This distance value is printed out
+   every other atom in the body.  This distance value is printed out
-   when the rigid bodies are defined.  If the
+   when the rigid bodies are defined.  If the :doc:`pair_style
-   :doc:`pair_style <pair_style>` cutoff plus neighbor skin does not span
+   <pair_style>` cutoff plus neighbor skin does not span this
-   this distance, then you should use the :doc:`comm_modify cutoff <comm_modify>` command with a setting epsilon larger than
+   distance, then you should use the :doc:`comm_modify cutoff
-   the distance.
+   <comm_modify>` command with a setting epsilon larger than the
+   distance.
 
 Which of the two variants is faster for a particular problem is hard
 to predict.  The best way to decide is to perform a short test run.
@@ -229,49 +231,54 @@ differences may accumulate to produce divergent trajectories.
 .. note::
 
    You should not update the atoms in rigid bodies via other
-   time-integration fixes (e.g. :doc:`fix nve <fix_nve>`, :doc:`fix nvt <fix_nh>`, :doc:`fix npt <fix_nh>`, :doc:`fix move <fix_move>`),
+   time-integration fixes (e.g. :doc:`fix nve <fix_nve>`, :doc:`fix
-   or you will have conflicting updates to positions and velocities
+   nvt <fix_nh>`, :doc:`fix npt <fix_nh>`, :doc:`fix move
-   resulting in unphysical behavior in most cases. When performing a hybrid
+   <fix_move>`), or you will have conflicting updates to positions and
-   simulation with some atoms in rigid bodies, and some not, a separate
+   velocities resulting in unphysical behavior in most cases. When
-   time integration fix like :doc:`fix nve <fix_nve>` or :doc:`fix nvt <fix_nh>` should be used for the non-rigid particles.
+   performing a hybrid simulation with some atoms in rigid bodies, and
+   some not, a separate time integration fix like :doc:`fix nve
+   <fix_nve>` or :doc:`fix nvt <fix_nh>` should be used for the
+   non-rigid particles.
 
 .. note::
 
-   These fixes are overkill if you simply want to hold a collection
+   These fixes are overkill if you simply want to hold a collection of
-   of atoms stationary or have them move with a constant velocity.  A
+   atoms stationary or have them move with a constant velocity.  A
-   simpler way to hold atoms stationary is to not include those atoms in
+   simpler way to hold atoms stationary is to not include those atoms
-   your time integration fix.  E.g. use "fix 1 mobile nve" instead of
+   in your time integration fix.  E.g. use "fix 1 mobile nve" instead
-   "fix 1 all nve", where "mobile" is the group of atoms that you want to
+   of "fix 1 all nve", where "mobile" is the group of atoms that you
-   move.  You can move atoms with a constant velocity by assigning them
+   want to move.  You can move atoms with a constant velocity by
-   an initial velocity (via the :doc:`velocity <velocity>` command),
+   assigning them an initial velocity (via the :doc:`velocity
-   setting the force on them to 0.0 (via the :doc:`fix setforce <fix_setforce>` command), and integrating them as usual
+   <velocity>` command), setting the force on them to 0.0 (via the
-   (e.g. via the :doc:`fix nve <fix_nve>` command).
+   :doc:`fix setforce <fix_setforce>` command), and integrating them
+   as usual (e.g. via the :doc:`fix nve <fix_nve>` command).
 
 .. warning::
 
-   The aggregate properties of each rigid body are
+   The aggregate properties of each rigid body are calculated at the
-   calculated at the start of a simulation run and are maintained in
+   start of a simulation run and are maintained in internal data
-   internal data structures. The properties include the position and
+   structures. The properties include the position and velocity of the
-   velocity of the center-of-mass of the body, its moments of inertia, and
+   center-of-mass of the body, its moments of inertia, and its angular
-   its angular momentum.  This is done using the properties of the
+   momentum.  This is done using the properties of the constituent
-   constituent atoms of the body at that point in time (or see the *infile*
+   atoms of the body at that point in time (or see the *infile*
-   keyword option).  Thereafter, changing these properties of individual
+   keyword option).  Thereafter, changing these properties of
-   atoms in the body will have no effect on a rigid body's dynamics, unless
+   individual atoms in the body will have no effect on a rigid body's
-   they effect any computation of per-atom forces or torques. If the
+   dynamics, unless they effect any computation of per-atom forces or
-   keyword *reinit* is set to *yes* (the default), the rigid body data
+   torques. If the keyword *reinit* is set to *yes* (the default), the
-   structures will be recreated at the beginning of each *run* command;
+   rigid body data structures will be recreated at the beginning of
-   if the keyword *reinit* is set to *no*, the rigid body data structures
+   each *run* command; if the keyword *reinit* is set to *no*, the
-   will be built only at the very first *run* command and maintained for
+   rigid body data structures will be built only at the very first
-   as long as the rigid fix is defined. For example, you might think you
+   *run* command and maintained for as long as the rigid fix is
-   could displace the atoms in a body or add a large velocity to each atom
+   defined. For example, you might think you could displace the atoms
-   in a body to make it move in a desired direction before a second run is
+   in a body or add a large velocity to each atom in a body to make it
-   performed, using the :doc:`set <set>` or
+   move in a desired direction before a second run is performed, using
-   :doc:`displace_atoms <displace_atoms>` or :doc:`velocity <velocity>`
+   the :doc:`set <set>` or :doc:`displace_atoms <displace_atoms>` or
-   commands.  But these commands will not affect the internal attributes
+   :doc:`velocity <velocity>` commands.  But these commands will not
-   of the body unless *reinit* is set to *yes*\ . With *reinit* set to *no*
+   affect the internal attributes of the body unless *reinit* is set
-   (or using the *infile* option, which implies *reinit* *no*\ ) the position
+   to *yes*\ . With *reinit* set to *no* (or using the *infile*
-   and velocity of individual atoms in the body will be reset when time
+   option, which implies *reinit* *no*\ ) the position and velocity of
-   integration starts again.
+   individual atoms in the body will be reset when time integration
+   starts again.
 
 ----------
 
@@ -316,17 +323,17 @@ to be part of rigid bodies.
 
 .. note::
 
-   To compute the initial center-of-mass position and other
+   To compute the initial center-of-mass position and other properties
-   properties of each rigid body, the image flags for each atom in the
+   of each rigid body, the image flags for each atom in the body are
-   body are used to "unwrap" the atom coordinates.  Thus you must ensure
+   used to "unwrap" the atom coordinates.  Thus you must ensure that
-   that these image flags are consistent so that the unwrapping creates a
+   these image flags are consistent so that the unwrapping creates a
    valid rigid body (one where the atoms are close together),
-   particularly if the atoms in a single rigid body straddle a periodic
+   particularly if the atoms in a single rigid body straddle a
-   boundary.  This means the input data file or restart file must define
+   periodic boundary.  This means the input data file or restart file
-   the image flags for each atom consistently or that you have used the
+   must define the image flags for each atom consistently or that you
-   :doc:`set <set>` command to specify them correctly.  If a dimension is
+   have used the :doc:`set <set>` command to specify them correctly.
-   non-periodic then the image flag of each atom must be 0 in that
+   If a dimension is non-periodic then the image flag of each atom
-   dimension, else an error is generated.
+   must be 0 in that dimension, else an error is generated.
 
 The *force* and *torque* keywords discussed next are only allowed for
 the *rigid* styles.
@@ -362,12 +369,13 @@ settings from the final keyword are used.
 
 .. note::
 
-   For computational efficiency, you may wish to turn off pairwise
+   For computational efficiency, you may wish to turn off pairwise and
-   and bond interactions within each rigid body, as they no longer
+   bond interactions within each rigid body, as they no longer
-   contribute to the motion.  The :doc:`neigh_modify exclude <neigh_modify>` and :doc:`delete_bonds <delete_bonds>`
+   contribute to the motion.  The :doc:`neigh_modify exclude
-   commands are used to do this.  If the rigid bodies have strongly
+   <neigh_modify>` and :doc:`delete_bonds <delete_bonds>` commands are
-   overlapping atoms, you may need to turn off these interactions to
+   used to do this.  If the rigid bodies have strongly overlapping
-   avoid numerical problems due to large equal/opposite intra-body forces
+   atoms, you may need to turn off these interactions to avoid
+   numerical problems due to large equal/opposite intra-body forces
    swamping the contribution of small inter-body forces.
 
 For computational efficiency, you should typically define one fix
@@ -379,7 +387,8 @@ is more expensive.
 
 The constituent particles within a rigid body can be point particles
 (the default in LAMMPS) or finite-size particles, such as spheres or
-ellipsoids or line segments or triangles.  See the :doc:`atom_style sphere and ellipsoid and line and tri <atom_style>` commands for more
+ellipsoids or line segments or triangles.  See the :doc:`atom_style
+sphere and ellipsoid and line and tri <atom_style>` commands for more
 details on these kinds of particles.  Finite-size particles contribute
 differently to the moment of inertia of a rigid body than do point
 particles.  Finite-size particles can also experience torque (e.g. due
@@ -389,7 +398,8 @@ orientation.  These contributions are accounted for by these fixes.
 Forces between particles within a body do not contribute to the
 external force or torque on the body.  Thus for computational
 efficiency, you may wish to turn off pairwise and bond interactions
-between particles within each rigid body.  The :doc:`neigh_modify exclude <neigh_modify>` and :doc:`delete_bonds <delete_bonds>`
+between particles within each rigid body.  The :doc:`neigh_modify
+exclude <neigh_modify>` and :doc:`delete_bonds <delete_bonds>`
 commands are used to do this.  For finite-size particles this also
 means the particles can be highly overlapped when creating the rigid
 body.
@@ -401,16 +411,17 @@ perform constant NVE time integration.  They are referred to below as
 the 4 NVE rigid styles.  The only difference is that the *rigid* and
 *rigid/small* styles use an integration technique based on Richardson
 iterations.  The *rigid/nve* and *rigid/small/nve* styles uses the
-methods described in the paper by :ref:`Miller <Miller3>`, which are thought
+methods described in the paper by :ref:`Miller <Miller3>`, which are
-to provide better energy conservation than an iterative approach.
+thought to provide better energy conservation than an iterative
+approach.
 
 The *rigid/nvt* and *rigid/nvt/small* styles performs constant NVT
 integration using a Nose/Hoover thermostat with chains as described
-originally in :ref:`(Hoover) <Hoover>` and :ref:`(Martyna) <Martyna2>`, which
+originally in :ref:`(Hoover) <Hoover>` and :ref:`(Martyna)
-thermostats both the translational and rotational degrees of freedom
+<Martyna2>`, which thermostats both the translational and rotational
-of the rigid bodies.  They are referred to below as the 2 NVT rigid
+degrees of freedom of the rigid bodies.  They are referred to below as
-styles.  The rigid-body algorithm used by *rigid/nvt* is described in
+the 2 NVT rigid styles.  The rigid-body algorithm used by *rigid/nvt*
-the paper by :ref:`Kamberaj <Kamberaj>`.
+is described in the paper by :ref:`Kamberaj <Kamberaj>`.
 
 The *rigid/npt*, *rigid/nph*, *rigid/npt/small*, and *rigid/nph/small*
 styles perform constant NPT or NPH integration using a Nose/Hoover
@@ -436,12 +447,12 @@ The target pressures for each of the 6 components of the stress tensor
 can be specified independently via the *x*, *y*, *z* keywords, which
 correspond to the 3 simulation box dimensions.  For each component,
 the external pressure or tensor component at each timestep is a ramped
-value during the run from *Pstart* to *Pstop*\ . If a target pressure is
+value during the run from *Pstart* to *Pstop*\ . If a target pressure
-specified for a component, then the corresponding box dimension will
+is specified for a component, then the corresponding box dimension
-change during a simulation.  For example, if the *y* keyword is used,
+will change during a simulation.  For example, if the *y* keyword is
-the y-box length will change.  A box dimension will not change if that
+used, the y-box length will change.  A box dimension will not change
-component is not specified, although you have the option to change
+if that component is not specified, although you have the option to
-that dimension via the :doc:`fix deform <fix_deform>` command.
+change that dimension via the :doc:`fix deform <fix_deform>` command.
 
 For all barostat keywords, the *Pdamp* parameter operates like the
 *Tdamp* parameter, determining the time scale on which pressure is
@@ -525,11 +536,11 @@ discussed below.
 
 The *langevin* keyword applies a Langevin thermostat to the constant
 NVE time integration performed by any of the 4 NVE rigid styles:
-*rigid*, *rigid/nve*, *rigid/small*, *rigid/small/nve*\ .  It cannot be
+*rigid*, *rigid/nve*, *rigid/small*, *rigid/small/nve*\ .  It cannot
-used with the 2 NVT rigid styles: *rigid/nvt*, *rigid/small/nvt*\ .  The
+be used with the 2 NVT rigid styles: *rigid/nvt*, *rigid/small/nvt*\ .
-desired temperature at each timestep is a ramped value during the run
+The desired temperature at each timestep is a ramped value during the
-from *Tstart* to *Tstop*\ .  The *Tdamp* parameter is specified in time
+run from *Tstart* to *Tstop*\ .  The *Tdamp* parameter is specified in
-units and determines how rapidly the temperature is relaxed.  For
+time units and determines how rapidly the temperature is relaxed.  For
 example, a value of 100.0 means to relax the temperature in a timespan
 of (roughly) 100 time units (:math:`\tau` or fs or ps - see the
 :doc:`units <units>` command).  The random # *seed* must be a positive
@@ -564,29 +575,30 @@ used.  *Tchain* is the number of thermostats in the Nose Hoover chain.
 This value, along with *Tdamp* can be varied to dampen undesirable
 oscillations in temperature that can occur in a simulation.  As a rule
 of thumb, increasing the chain length should lead to smaller
-oscillations. The keyword *pchain* specifies the number of
+oscillations. The keyword *pchain* specifies the number of thermostats
-thermostats in the chain thermostatting the barostat degrees of
+in the chain thermostatting the barostat degrees of freedom.
-freedom.
 
 .. note::
 
    There are alternate ways to thermostat a system of rigid bodies.
-   You can use :doc:`fix langevin <fix_langevin>` to treat the individual
+   You can use :doc:`fix langevin <fix_langevin>` to treat the
-   particles in the rigid bodies as effectively immersed in an implicit
+   individual particles in the rigid bodies as effectively immersed in
-   solvent, e.g. a Brownian dynamics model.  For hybrid systems with both
+   an implicit solvent, e.g. a Brownian dynamics model.  For hybrid
-   rigid bodies and solvent particles, you can thermostat only the
+   systems with both rigid bodies and solvent particles, you can
-   solvent particles that surround one or more rigid bodies by
+   thermostat only the solvent particles that surround one or more
-   appropriate choice of groups in the compute and fix commands for
+   rigid bodies by appropriate choice of groups in the compute and fix
-   temperature and thermostatting.  The solvent interactions with the
+   commands for temperature and thermostatting.  The solvent
-   rigid bodies should then effectively thermostat the rigid body
+   interactions with the rigid bodies should then effectively
-   temperature as well without use of the Langevin or Nose/Hoover options
+   thermostat the rigid body temperature as well without use of the
-   associated with the fix rigid commands.
+   Langevin or Nose/Hoover options associated with the fix rigid
+   commands.
 
 ----------
 
 The *mol* keyword can only be used with the *rigid/small* styles.  It
-must be used when other commands, such as :doc:`fix deposit <fix_deposit>` or :doc:`fix pour <fix_pour>`, add rigid
+must be used when other commands, such as :doc:`fix deposit
-bodies on-the-fly during a simulation.  You specify a *template-ID*
+<fix_deposit>` or :doc:`fix pour <fix_pour>`, add rigid bodies
+on-the-fly during a simulation.  You specify a *template-ID*
 previously defined using the :doc:`molecule <molecule>` command, which
 reads a file that defines the molecule.  You must use the same
 *template-ID* that the other fix which is adding rigid bodies uses.
@@ -670,16 +682,16 @@ cross periodic boundaries during the simulation.
 
 .. note::
 
-   If you use the *infile* or *mol* keywords and write restart
+   If you use the *infile* or *mol* keywords and write restart files
-   files during a simulation, then each time a restart file is written,
+   during a simulation, then each time a restart file is written, the
-   the fix also write an auxiliary restart file with the name
+   fix also write an auxiliary restart file with the name rfile.rigid,
-   rfile.rigid, where "rfile" is the name of the restart file,
+   where "rfile" is the name of the restart file,
    e.g. tmp.restart.10000 and tmp.restart.10000.rigid.  This auxiliary
-   file is in the same format described above.  Thus it can be used in a
+   file is in the same format described above.  Thus it can be used in
-   new input script that restarts the run and re-specifies a rigid fix
+   a new input script that restarts the run and re-specifies a rigid
-   using an *infile* keyword and the appropriate filename.  Note that the
+   fix using an *infile* keyword and the appropriate filename.  Note
-   auxiliary file will contain one line for every rigid body, even if the
+   that the auxiliary file will contain one line for every rigid body,
-   original file only listed a subset of the rigid bodies.
+   even if the original file only listed a subset of the rigid bodies.
 
 If the system has rigid bodies with finite-size overlapping particles
 and the model uses the :doc:`fix gravity <fix_gravity>` command to
@@ -728,10 +740,11 @@ also accounted for by this fix.
 
 ----------
 
-If your simulation is a hybrid model with a mixture of rigid bodies and
+If your simulation is a hybrid model with a mixture of rigid bodies
-non-rigid particles (e.g. solvent) there are several ways these rigid
+and non-rigid particles (e.g. solvent) there are several ways these
-fixes can be used in tandem with :doc:`fix nve <fix_nve>`, :doc:`fix nvt
+rigid fixes can be used in tandem with :doc:`fix nve <fix_nve>`,
-<fix_nh>`, :doc:`fix npt <fix_nh>`, and :doc:`fix nph <fix_nh>`.
+:doc:`fix nvt <fix_nh>`, :doc:`fix npt <fix_nh>`, and :doc:`fix nph
+<fix_nh>`.
 
 If you wish to perform NVE dynamics (no thermostatting or
 barostatting), use one of 4 NVE rigid styles to integrate the rigid
@@ -741,14 +754,14 @@ particles.
 If you wish to perform NVT dynamics (thermostatting, but no
 barostatting), you can use one of the 2 NVT rigid styles for the rigid
 bodies, and any thermostatting fix for the non-rigid particles
-(:doc:`fix nvt <fix_nh>`, :doc:`fix langevin <fix_langevin>`, :doc:`fix
+(:doc:`fix nvt <fix_nh>`, :doc:`fix langevin <fix_langevin>`,
-temp/berendsen <fix_temp_berendsen>`).  You can also use one of the 4
+:doc:`fix temp/berendsen <fix_temp_berendsen>`).  You can also use one
-NVE rigid styles for the rigid bodies and thermostat them using
+of the 4 NVE rigid styles for the rigid bodies and thermostat them
-:doc:`fix langevin <fix_langevin>` on the group that contains all the
+using :doc:`fix langevin <fix_langevin>` on the group that contains
-particles in the rigid bodies.  The net force added by :doc:`fix
+all the particles in the rigid bodies.  The net force added by
-langevin <fix_langevin>` to each rigid body effectively thermostats its
+:doc:`fix langevin <fix_langevin>` to each rigid body effectively
-translational center-of-mass motion.  Not sure how well it does at
+thermostats its translational center-of-mass motion.  Not sure how
-thermostatting its rotational motion.
+well it does at thermostatting its rotational motion.
 
 If you wish to perform NPT or NPH dynamics (barostatting), you cannot
 use both :doc:`fix npt <fix_nh>` and the NPT or NPH rigid styles.  This
@@ -774,12 +787,12 @@ to the global pressure and the box is scaled the same by any of the
 barostatting fixes.
 
 You could even use the second and third options for a non-hybrid
-simulation consisting of only rigid bodies, assuming you give :doc:`fix
+simulation consisting of only rigid bodies, assuming you give
-npt <fix_nh>` an empty group, though it's an odd thing to do.  The
+:doc:`fix npt <fix_nh>` an empty group, though it's an odd thing to
-barostatting fixes (:doc:`fix npt <fix_nh>` and :doc:`fix press/berensen
+do.  The barostatting fixes (:doc:`fix npt <fix_nh>` and :doc:`fix
-<fix_press_berendsen>`) will monitor the pressure and change the box
+press/berensen <fix_press_berendsen>`) will monitor the pressure and
-dimensions, but not time integrate any particles.  The integration of
+change the box dimensions, but not time integrate any particles.  The
-the rigid bodies will be performed by fix rigid/nvt.
+integration of the rigid bodies will be performed by fix rigid/nvt.
 
 ----------
 
@@ -824,10 +837,10 @@ various :doc:`output commands <Howto_output>`.  The scalar value
 calculated by these fixes is "intensive".  The scalar is the current
 temperature of the collection of rigid bodies.  This is averaged over
 all rigid bodies and their translational and rotational degrees of
-freedom.  The translational energy of a rigid body is 1/2 m v\^2, where
+freedom.  The translational energy of a rigid body is 1/2 m v\^2,
-m = total mass of the body and v = the velocity of its center of mass.
+where m = total mass of the body and v = the velocity of its center of
-The rotational energy of a rigid body is 1/2 I w\^2, where I = the
+mass.  The rotational energy of a rigid body is 1/2 I w\^2, where I =
-moment of inertia tensor of the body and w = its angular velocity.
+the moment of inertia tensor of the body and w = its angular velocity.
 Degrees of freedom constrained by the *force* and *torque* keywords
 are removed from this calculation, but only for the *rigid* and
 *rigid/nve* fixes.

doc/src/fix_sgcmc.rst

@@ -148,6 +148,8 @@ components of the vector represent the following quantities:
 * ...
 * N+2: The current global concentration of species *X* (= number of atoms of type *N* / total number of atoms)
 
+The vector values calculated by this fix are "intensive".
+
 Restrictions
 """"""""""""
 
@@ -155,6 +157,9 @@ This fix is part of the MC package. It is only enabled if LAMMPS was
 built with that package.  See the :doc:`Build package <Build_package>`
 page for more info.
 
+This fix style requires an :doc:`atom style <atom_style>` with per atom
+type masses.
+
 At present the fix provides optimized subroutines for EAM type
 potentials (see above) that calculate potential energy changes due to
 *local* atom type swaps very efficiently.  Other potentials are

doc/src/fix_ttm.rst

@@ -96,11 +96,11 @@ each processor, which is acceptable when the overall grid is reasonably
 small.  For larger grids you should use fix *ttm/grid* instead.
 
 Fix *ttm/mod* adds options to account for external heat sources (e.g. at
-a surface) and for specifying parameters that allow the electronic
+a surface) and for specifying parameters that allow the electronic heat
-heat capacity to depend strongly on electronic temperature.  It is
+capacity to depend strongly on electronic temperature.  It is more
-more expensive computationally than fix *ttm* because it treats the
+expensive computationally than fix *ttm* because it treats the thermal
-thermal diffusion equation as non-linear.  More details on fix *ttm/mod*
+diffusion equation as non-linear.  More details on fix *ttm/mod* are
-are given below.
+given below.
 
 Heat transfer between the electronic and atomic subsystems is carried
 out via an inhomogeneous Langevin thermostat.  Only atoms in the fix
@@ -136,23 +136,23 @@ transfer between the subsystems:
   \bigtriangledown (\kappa_e \bigtriangledown T_e) -
   g_p (T_e - T_a) + g_s T_a'
 
-where C_e is the specific heat, rho_e is the density, kappa_e is the
+where :math:`C_e` is the specific heat, :math:`\rho_e` is the density,
-thermal conductivity, T is temperature, the "e" and "a" subscripts
+:math:`\kappa_e` is the thermal conductivity, *T* is temperature, the
-represent electronic and atomic subsystems respectively, g_p is the
+"e" and "a" subscripts represent electronic and atomic subsystems
-coupling constant for the electron-ion interaction, and g_s is the
+respectively, :math:`g_p` is the coupling constant for the electron-ion
-electron stopping coupling parameter.  C_e, rho_e, and kappa_e are
+interaction, and :math:`g_s` is the electron stopping coupling
-specified as parameters to the fix.  The other quantities are derived.
+parameter.  :math:`C_e`, :math:`\rho_e`, and :math:`\kappa_e` are
-The form of the heat diffusion equation used here is almost the same
+specified as parameters to the fix *ttm* or *ttm/grid*.  The other
-as that in equation 6 of :ref:`(Duffy) <Duffy>`, with the exception that the
+quantities are derived.  The form of the heat diffusion equation used
-electronic density is explicitly represented, rather than being part
+here is almost the same as that in equation 6 of :ref:`(Duffy) <Duffy>`,
-of the specific heat parameter.
+with the exception that the electronic density is explicitly
+represented, rather than being part of the specific heat parameter.
 
 Currently, the TTM fixes assume that none of the user-supplied
-parameters will vary with temperature. Note that :ref:`(Duffy)
+parameters will vary with temperature. Note that :ref:`(Duffy) <Duffy>`
-<Duffy>` used a tanh() functional form for the temperature dependence
+used a tanh() functional form for the temperature dependence of the
-of the electronic specific heat, but ignored temperature dependencies
+electronic specific heat, but ignored temperature dependencies of any of
-of any of the other parameters.  See more discussion below for fix
+the other parameters.  See more discussion below for fix *ttm/mod*.
-ttm/mod.
 
 .. note::
 
@@ -265,27 +265,27 @@ heat sources (e.g. laser heating in ablation simulations):
   \bigtriangledown (\kappa_e \bigtriangledown T_e) -
   g_p (T_e - T_a) + g_s T_a' + \theta (x-x_{surface})I_0 \exp(-x/l_{skin})
 
-where theta is the Heaviside step function, I_0 is the (absorbed)
+where :math:`\theta` is the Heaviside step function, :math:`I_0` is the
-laser pulse intensity for ablation simulations, l_skin is the depth
+(absorbed) laser pulse intensity for ablation simulations,
-of skin-layer, and all other designations have the same meaning as in
+:math:`l_{skin}` is the depth of the skin-layer, and all other
-the former equation. The duration of the pulse is set by the parameter
+designations have the same meaning as in the former equation. The
-*tau* in the *init_file*.
+duration of the pulse is set by the parameter *tau* in the *init_file*.
 
-Fix ttm/mod also allows users to specify the dependencies of C_e and
+Fix *ttm/mod* also allows users to specify the dependencies of
-kappa_e on the electronic temperature. The specific heat is expressed
+:math:`C_e` and :math:`\kappa_e` on the electronic temperature. The
-as
+specific heat is expressed as
 
 .. math::
 
   C_e = C_0 + (a_0 + a_1 X + a_2 X^2 + a_3 X^3 + a_4 X^4) \exp (-(AX)^2)
 
-where *X* = T_e/1000, and the thermal conductivity is defined as
+where :math:`X = \frac{T_e}{1000}`, and the thermal conductivity is
-kappa_e = D_e\*rho_e\*C_e, where D_e is the thermal diffusion
+defined as :math:`\kappa_e = D_e \cdot rho_e \cdot C_e`, where
-coefficient.
+:math:`D_e` is the thermal diffusion coefficient.
 
-Electronic pressure effects are included in the TTM model to account
+Electronic pressure effects are included in the TTM model to account for
-for the blast force acting on ions because of electronic pressure
+the blast force acting on ions because of electronic pressure gradient
-gradient (see :ref:`(Chen) <Chen>`, :ref:`(Norman) <Norman>`).  The total force
+(see :ref:`(Chen) <Chen>`, :ref:`(Norman) <Norman>`).  The total force
 acting on an ion is:
 
 .. math::
@@ -293,25 +293,26 @@ acting on an ion is:
   {\vec F}_i = - \partial U / \partial {\vec r}_i + {\vec
   F}_{langevin} - \nabla P_e/n_{ion}
 
-where F_langevin is a force from Langevin thermostat simulating
+where :math:`F_{langevin}` is a force from Langevin thermostat
-electron-phonon coupling, and nabla P_e/n_ion is the electron blast
+simulating electron-phonon coupling, and :math:`\nabla P_e/n_{ion}` is
-force.
+the electron blast force.
 
-The electronic pressure is taken to be P_e = B\*rho_e\*C_e\*T_e
+The electronic pressure is taken to be :math:`P_e = B \cdot rho_e \cdot
+C_e \cdot T_e`
 
-The current fix ttm/mod implementation allows TTM simulations with a
+The current fix *ttm/mod* implementation allows TTM simulations with a
 vacuum. The vacuum region is defined as the grid cells with zero
 electronic temperature. The numerical scheme does not allow energy
 exchange with such cells. Since the material can expand to previously
-unoccupied region in some simulations, the vacuum border can be
+unoccupied region in some simulations, the vacuum border can be allowed
-allowed to move. It is controlled by the *surface_movement* parameter
+to move. It is controlled by the *surface_movement* parameter in the
-in the *init_file*. If it is set to 1, then "vacuum" cells can be
+*init_file*. If it is set to 1, then "vacuum" cells can be changed to
-changed to "electron-filled" cells with the temperature *T_e_min* if
+"electron-filled" cells with the temperature *T_e_min* if atoms move
-atoms move into them (currently only implemented for the case of
+into them (currently only implemented for the case of 1-dimensional
-1-dimensional motion of flat surface normal to the X axis). The
+motion of a flat surface normal to the X axis). The initial locations of
-initial borders of vacuum can be set in the *init_file* via *lsurface*
+the interfaces of the electron density to the vacuum can be set in the
-and *rsurface* parameters. In this case, electronic pressure gradient
+*init_file* via *lsurface* and *rsurface* parameters. In this case,
-is calculated as
+electronic pressure gradient is calculated as
 
 .. math::
 
@@ -319,10 +320,10 @@ is calculated as
   \frac{x}{x+\lambda}\frac{(C_e{}T_e)_{x+\Delta
   x}-(C_e{}T_e)_{x}}{\Delta x} \right]
 
-where lambda is the electron mean free path (see :ref:`(Norman) <Norman>`,
+where :math:`\lambda` is the electron mean free path (see :ref:`(Norman)
-:ref:`(Pisarev) <Pisarev>`)
+<Norman>`, :ref:`(Pisarev) <Pisarev>`)
 
-The fix ttm/mod parameter file *init_file* has the following syntax.
+The fix *ttm/mod* parameter file *init_file* has the following syntax.
 Every line with an odd number is considered as a comment and
 ignored. The lines with the even numbers are treated as follows:
 

doc/src/fix_wall_flow.rst

@@ -0,0 +1,175 @@
+.. index:: fix wall/flow
+.. index:: fix wall/flow/kk
+
+fix wall/flow command
+=====================
+
+Accelerator Variants: *wall/flow/kk*
+
+Syntax
+""""""
+
+.. code-block:: LAMMPS
+
+   fix ID group-ID wall/flow axis vflow T seed N coords ... keyword value
+
+* ID, group-ID are documented in :doc:`fix <fix>` command
+* wall/flow = style name of this fix command
+* axis = flow axis (*x*, *y*, or *z*)
+* vflow = generated flow velocity in *axis* direction (velocity units)
+* T = flow temperature (temperature units)
+* seed = random seed for stochasticity (positive integer)
+* N = number of walls
+* coords = list of N wall positions along the *axis* direction in ascending order (distance units)
+* zero or more keyword/value pairs may be appended
+* keyword = *units*
+
+  .. parsed-literal::
+
+       *units* value = *lattice* or *box*
+         *lattice* = wall positions are defined in lattice units
+         *box* = the wall positions are defined in simulation box units
+
+Examples
+""""""""
+
+.. code-block:: LAMMPS
+
+   fix 1 all wall/flow x 0.4 1.5 593894 4 2.0 4.0 6.0 8.0
+
+Description
+"""""""""""
+
+.. versionadded:: 17Apr2024
+
+This fix implements flow boundary conditions (FBC) introduced in
+:ref:`(Pavlov1) <fbc-Pavlov1>` and :ref:`(Pavlov2) <fbc-Pavlov2>`.
+The goal is to generate a stationary flow with a shifted Maxwell
+velocity distribution:
+
+.. math::
+
+   f_a(v_a) \propto \exp{\left(-\frac{m (v_a-v_{\text{flow}})^2}{2 kB T}\right)}
+
+where :math:`v_a` is the component of velocity along the specified
+*axis* argument (a = x,y,z), :math:`v_{\text{flow}}` is the flow
+velocity specified as the *vflow* argument, *T* is the specified flow
+temperature, *m* is the particle mass, and *kB* is the Boltzmann
+constant.
+
+This is achieved by defining a series of *N* transparent walls along
+the flow *axis* direction.  Each wall is at the specified position
+listed in the *coords* argument.  Note that an additional transparent
+wall is defined by the code at the boundary of the (periodic)
+simulation domain in the *axis* direction.  So there are effectively
+N+1 walls.
+
+Each time a particle in the specified group passes through one of the
+transparent walls, its velocity is re-assigned.  Particles not in the
+group do not interact with the wall. This can be used, for example, to
+add obstacles composed of atoms, or to simulate a solution of complex
+molecules in a one-atom liquid (note that the fix has been tested for
+one-atom systems only).
+
+Conceptually, the velocity re-assignment represents creation of a new
+particle within the system with simultaneous removal of the particle
+which passed through the wall.  The velocity components in directions
+parallel to the wall are re-assigned according to the standard Maxwell
+velocity distribution for the specified temperature *T*.  The velocity
+component perpendicular to the wall is re-assigned according to the
+shifted Maxwell distribution defined above:
+
+.. math::
+
+   f_{\text{a generated}}(v_a) \propto v_a f_a(v_a)
+
+It can be shown that for an ideal-gas scenario this procedure makes
+the velocity distribution of particles between walls exactly as
+desired.
+
+Since in most cases simulated systems are not an ideal gas, multiple
+walls can be defined, since a single wall may not be sufficient for
+maintaining a stationary flow without "congestion" which can manifest
+itself as regions in the flow with increased particle density located
+upstream from static obstacles.
+
+For the same reason, the actual temperature and velocity of the
+generated flow may differ from what is requested.  The degree of
+discrepancy is determined by how different from an ideal gas the
+simulated system is.  Therefore, a calibration procedure may be
+required for such a system as described in :ref:`(Pavlov)
+<fbc-Pavlov2>`.
+
+Note that the interactions between particles on different sides of a
+transparent wall are not disabled or neglected.  Likewise particle
+positions are not altered by the velocity reassignment.  This removes
+the need to modify the force field to work correctly in cases when a
+particle is close to a wall.
+
+For example, if particle positions were uniformly redistributed across
+the surface of a wall, two particles could end up too close to each
+other, potentially causing the simulation to explode.  However due to
+this compromise, some collective phenomena such as regions with
+increased/decreased density or collective movements are not fully
+removed when particles cross a wall.  This unwanted consequence can
+also be potentially mitigated by using more multiple walls.
+
+.. note::
+
+  When the specified flow has a high velocity, a lost atoms error can
+  occur (see :doc:`error messages <Errors_messages>`).  If this
+  happens, you should ensure the checks for neighbor list rebuilds,
+  set via the :doc:`neigh_modify <neigh_modify>` command, are as
+  conservative as possible (every timestep if needed).  Those are the
+  default settings.
+
+Restart, fix_modify, output, run start/stop, minimize info
+"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
+
+No information about this fix is written to :doc:`binary restart files
+<restart>`.
+
+None of the :doc:`fix_modify <fix_modify>` options are relevant to
+this fix.
+
+No global or per-atom quantities are stored by this fix for access by
+various :doc:`output commands <Howto_output>`.
+
+No parameter of this fix can be used with the *start/stop* keywords of
+the :doc:`run <run>` command.
+
+This fix is not invoked during :doc:`energy minimization <minimize>`.
+
+Restrictions
+""""""""""""
+
+Fix *wall_flow* is part of the EXTRA-FIX package.  It is only enabled
+if LAMMPS was built with that package.  See the :doc:`Build package
+<Build_package>` page for more info.
+
+Flow boundary conditions should not be used with rigid bodies such as
+those defined by a "fix rigid" command.
+
+This fix can only be used with periodic boundary conditions along the
+flow axis. The size of the box in this direction must not change. Also,
+the fix is designed to work only in an orthogonal simulation box.
+
+Related commands
+""""""""""""""""
+
+:doc:`fix wall/reflect <fix_wall>` command
+
+Default
+"""""""
+
+The default for the units keyword is lattice.
+
+----------
+
+.. _fbc-Pavlov1:
+
+**(Pavlov1)** Pavlov, Kolotinskii, Stegailov, "GPU-Based Molecular Dynamics of Turbulent Liquid Flows with OpenMM", Proceedings of PPAM-2022, LNCS (Springer), vol. 13826, pp. 346-358 (2023)
+
+.. _fbc-Pavlov2:
+
+**(Pavlov2)** Pavlov, Galigerov, Kolotinskii, Nikolskiy, Stegailov, "GPU-based Molecular Dynamics of Fluid Flows: Reaching for Turbulence", Int. J. High Perf. Comp. Appl., (2024)

doc/src/fix_widom.rst

@@ -179,7 +179,7 @@ the following global cumulative quantities:
 * 2 = average difference in potential energy on each timestep
 * 3 = volume of the insertion region
 
-The vector values calculated by this fix are "extensive".
+The vector values calculated by this fix are "intensive".
 
 No parameter of this fix can be used with the *start/stop* keywords of
 the :doc:`run <run>` command.  This fix is not invoked during
@@ -195,8 +195,11 @@ doc page for more info.
 Do not set "neigh_modify once yes" or else this fix will never be
 called.  Reneighboring is **required**.
 
-Can be run in parallel, but aspects of the GCMC part will not scale well
+This fix style requires an :doc:`atom style <atom_style>` with per atom
-in parallel. Only usable for 3D simulations.
+type masses.
+
+Can be run in parallel, but some aspects of the insertion procedure
+will not scale well in parallel. Only usable for 3D simulations.
 
 
 Related commands

doc/src/labelmap.rst

@@ -43,7 +43,8 @@ The label map can also be defined by the :doc:`read_data <read_data>`
 command when it reads these sections in a data file: Atom Type Labels,
 Bond Type Labels, etc.  See the :doc:`Howto type labels
 <Howto_type_labels>` doc page for a general discussion of how type
-labels can be used.
+labels can be used.  See :ref:`(Gissinger) <Typelabel>` for a discussion
+of the type label implementation in LAMMPS and its uses.
 
 Valid type labels can contain any alphanumeric character, but must not
 start with a number, a '#', or a '*' character.  They can contain other
@@ -98,3 +99,9 @@ Default
 """""""
 
 none
+
+-----------
+
+.. _Typelabel:
+
+**(Gissinger)** J. R. Gissinger, I. Nikiforov, Y. Afshar, B. Waters, M. Choi, D. S. Karls, A. Stukowski, W. Im, H. Heinz, A. Kohlmeyer, and E. B. Tadmor, J Phys Chem B, 128, 3282-3297 (2024).

doc/src/lattice.rst

@@ -19,7 +19,7 @@ Syntax
        scale = lattice constant in distance units (for all other units)
 
 * zero or more keyword/value pairs may be appended
-* keyword = *origin* or *orient* or *spacing* or *a1* or *a2* or *a3* or *basis*
+* keyword = *origin* or *orient* or *spacing* or *a1* or *a2* or *a3* or *basis* or *triclinic/general*
 
   .. parsed-literal::
 
@@ -34,6 +34,7 @@ Syntax
          x,y,z = primitive vector components that define unit cell
        *basis* values = x y z
          x,y,z = fractional coords of a basis atom (0 <= x,y,z < 1)
+       *triclinic/general* values = no values
 
 Examples
 """"""""
@@ -44,7 +45,7 @@ Examples
    lattice hex 0.85
    lattice sq 0.8 origin 0.0 0.5 0.0 orient x 1 1 0 orient y -1 1 0
    lattice custom 3.52 a1 1.0 0.0 0.0 a2 0.5 1.0 0.0 a3 0.0 0.0 0.5 &
-                       basis 0.0 0.0 0.0 basis 0.5 0.5 0.5
+                       basis 0.0 0.0 0.0 basis 0.5 0.5 0.5 triclinic/general
    lattice none 2.0
 
 Description
@@ -129,10 +130,13 @@ and a3 are 3 orthogonal unit vectors (edges of a unit cube).  But you
 can specify them to be of any length and non-orthogonal to each other,
 so that they describe a tilted parallelepiped.  Via the *basis*
 keyword you add atoms, one at a time, to the unit cell.  Its arguments
-are fractional coordinates (0.0 <= x,y,z < 1.0).  The position vector
+are fractional coordinates (0.0 <= x,y,z < 1.0).  For 2d simulations,
-x of a basis atom within the unit cell is thus a linear combination of
+the fractional z coordinate for any basis atom must be 0.0.
-the unit cell's 3 edge vectors, i.e. x = bx a1 + by a2 + bz a3,
+
-where bx,by,bz are the 3 values specified for the *basis* keyword.
+The position vector x of a basis atom within the unit cell is a linear
+combination of the unit cell's 3 edge vectors, i.e. x = bx a1 + by
+a2 + bz a3, where bx,by,bz are the 3 values specified for the *basis*
+keyword.
 
 ----------
 
@@ -168,18 +172,21 @@ The *origin* option specifies how the unit cell will be shifted or
 translated when mapping it into the simulation box.  The x,y,z values
 are fractional values (0.0 <= x,y,z < 1.0) meaning shift the lattice
 by a fraction of the lattice spacing in each dimension.  The meaning
-of "lattice spacing" is discussed below.
+of "lattice spacing" is discussed below.  For 2d simulations, the
+*origin* z value must be 0.0.
 
 The *orient* option specifies how the unit cell will be rotated when
 mapping it into the simulation box.  The *dim* argument is one of the
 3 coordinate axes in the simulation box.  The other 3 arguments are
 the crystallographic direction in the lattice that you want to orient
 along that axis, specified as integers.  E.g. "orient x 2 1 0" means
-the x-axis in the simulation box will be the [210] lattice
+the x-axis in the simulation box will be the [210] lattice direction,
-direction, and similarly for y and z.  The 3 lattice directions you
+and similarly for y and z.  The 3 lattice directions you specify do
-specify do not have to be unit vectors, but they must be mutually
+not have to be unit vectors, but they must be mutually orthogonal and
-orthogonal and obey the right-hand rule, i.e. (X cross Y) points in
+obey the right-hand rule, i.e. (X cross Y) points in the Z direction.
-the Z direction.
+For 2d simulations, the *orient* x and y vectors must define 0 for
+their 3rd component.  Similarly the *orient* z vector must define 0
+for its 1st and 2nd components.
 
 .. note::
 
@@ -193,6 +200,59 @@ the Z direction.
 
 ----------
 
+The *triclinic/general* option specifies that the defined lattice is
+for use with a general triclinic simulation box, as opposed to an
+orthogonal or restricted triclinic box.  The :doc:`Howto triclinic
+<Howto_triclinic>` doc page explains all 3 kinds of simulation boxes
+LAMMPS supports.
+
+If this option is specified, a *custom* lattice style must be used.
+The *a1*, *a2*, *a3* vectors should define the edge vectors of a
+single unit cell of the lattice with one or more basis atoms.  They
+edge vectors can be arbitrary so long as they are non-zero, distinct,
+and not co-planar.  In addition, they must define a right-handed
+system, such that (*a1* cross *a2*) points in the direction of *a3*.
+Note that a left-handed system can be converted to a right-handed
+system by simply swapping the order of any pair of the *a1*, *a2*,
+*a3* vectors.  For 2d simulations, the *a3* vector must be specified
+as (0.0,0.0,1.0), which is its default value.
+
+If this option is used, the *origin* and *orient* settings must have
+their default values.  Namely (0.0,0.0,0.0) for the *origin* and
+(100), (010), (001) for the *orient* vectors.
+
+The :doc:`create_box <create_box>` command can be used to create a
+general triclinic box that replicates the *a1*, *a2*, *a3* unit cell
+vectors in each direction to create the 3 arbitrary edge vectors of
+the overall simulation box.  It requires a lattice with the
+*triclinic/general* option.
+
+Likewise, the :doc:`create_atoms <create_atoms>` command can be used
+to add atoms (or molecules) to a general triclinic box which lie on
+the lattice points defined by *a1*, *a2*, *a3* and the unit cell basis
+atoms.  To do this, it also requires a lattice with the
+*triclinic/general* option.
+
+.. note::
+
+   LAMMPS allows specification of general triclinic lattices and
+   simulation boxes as a convenience for users who may be converting
+   data from solid-state crystallographic representations or from DFT
+   codes for input to LAMMPS.  However, as explained on the
+   :doc:`Howto_triclinic <Howto_triclinic>` doc page, internally,
+   LAMMPS only uses restricted triclinic simulation boxes.  This means
+   the box and per-atom information (e.g. coordinates, velocities)
+   defined by the :doc:`create_box <create_box>` and
+   :doc:`create_atoms <create_atoms>` commands are converted from
+   general to restricted triclinic form when the two commands are
+   invoked.  It also means that any other commands which use lattice
+   spacings from this command (e.g. the region command), will be
+   operating on a restricted triclinic simulation box, even if the
+   *triclinic/general* option was used to define the lattice.  See the
+   next section for details.
+
+----------
+
 Several LAMMPS commands have the option to use distance units that are
 inferred from "lattice spacings" in the x,y,z box directions.
 E.g. the :doc:`region <region>` command can create a block of size
@@ -216,6 +276,18 @@ coordinates of the 8 corner points of the modified unit cell (4 in
 2d).  Similarly, the Y and Z lattice spacings are defined as the
 difference in the min/max of the y and z coordinates.
 
+.. note::
+
+   If the *triclinic/general* option is specified, the unit cell
+   defined by *a1*, *a2*, *a3* edge vectors is first converted to a
+   restricted triclinic orientation, which is a rotation operation.
+   The min/max extent of the 8 corner points is then determined, as
+   described in the preceding paragraph, to set the lattice
+   spacings. As explained for the *triclinic/general* option above,
+   this is because any use of the lattice spacings by other commands
+   will be for a restricted triclinic simulation box, not a general
+   triclinic box.
+
 Note that if the unit cell is orthogonal with axis-aligned edges (no
 rotation via the *orient* keyword), then the lattice spacings in each
 dimension are simply the scale factor (described above) multiplied by

doc/src/package.rst

@@ -74,7 +74,7 @@ Syntax
            *no_affinity* values = none
        *kokkos* args = keyword value ...
          zero or more keyword/value pairs may be appended
-         keywords = *neigh* or *neigh/qeq* or *neigh/thread* or *neigh/transpose* or *newton* or *binsize* or *comm* or *comm/exchange* or *comm/forward* or *comm/pair/forward* or *comm/fix/forward* or *comm/reverse* or *comm/pair/reverse* or *sort* or *gpu/aware* or *pair/only*
+         keywords = *neigh* or *neigh/qeq* or *neigh/thread* or *neigh/transpose* or *newton* or *binsize* or *comm* or *comm/exchange* or *comm/forward* or *comm/pair/forward* or *comm/fix/forward* or *comm/reverse* or *comm/pair/reverse* or *sort* or *atom/map* or *gpu/aware* or *pair/only*
            *neigh* value = *full* or *half*
              full = full neighbor list
              half = half neighbor list built in thread-safe manner
@@ -108,6 +108,9 @@ Syntax
            *sort* value = *no* or *device*
              *no* = perform atom sorting in non-KOKKOS mode
              *device* = perform atom sorting on device (e.g. on GPU)
+           *atom/map* value = *no* or *device*
+             *no* = build atom map in non-KOKKOS mode
+             *device* = build atom map on device (e.g. on GPU)
            *gpu/aware* = *off* or *on*
              *off* = do not use GPU-aware MPI
              *on* = use GPU-aware MPI (default)
@@ -566,15 +569,19 @@ performing the exchange pack/unpack on the host CPU can give speedup
 since it reduces the number of CUDA kernel launches.
 
 The *sort* keyword determines whether the host or device performs atom
-sorting, see the :doc:`atom_modify sort <atom_modify>` command.  The
+sorting, see the :doc:`atom_modify sort <atom_modify>` command.  The value
-value options for the *sort* keyword are *no* or *device* similar to the
+options for the *sort* keyword are *no* or *device* similar to the *comm*
-*comm* keywords above. If a value of *host* is used it will be
+keywords above. If a value of *host* is used it will be automatically be
-automatically be changed to *no* since the *sort* keyword does not
+changed to *no* since the *sort* keyword does not support *host* mode. Not
-support *host* mode. The value of *no* will also always be used when
+all fix styles with extra atom data support *device* mode and in that case
-running on the CPU, i.e. setting the value to *device* will have no
+a warning will be given and atom sorting will run in *no* mode instead.
-effect if the simulation is running on the CPU. Not all fix styles with
+
-extra atom data support *device* mode and in that case a warning will be
+.. versionadded:: 17Apr2024
-given and atom sorting will run in *no* mode instead.
+
+The *atom/map* keyword determines whether the host or device builds the
+atom_map, see the :doc:`atom_modify map <atom_modify>` command.  The
+value options for the *atom/map* keyword are identical to the *sort*
+keyword above.
 
 The *gpu/aware* keyword chooses whether GPU-aware MPI will be used. When
 this keyword is set to *on*, buffers in GPU memory are passed directly
@@ -593,12 +600,13 @@ for OpenMPI 1.8 (or later versions), Mvapich2 1.9 (or later) when the
 Spectrum MPI when the "-gpu" flag is used.
 
 The *pair/only* keyword can change how the KOKKOS suffix "kk" is applied
-when using an accelerator device.  By default device acceleration is
+when using an accelerator device.  By default device acceleration is always
-always used for all available styles.  With *pair/only* set to *on* the
+used for all available styles.  With *pair/only* set to *on* the suffix
-suffix setting will choose device acceleration only for pair styles and
+setting will choose device acceleration only for pair styles and run all
-run all other force computations on the host CPU.
+other force computations on the host CPU.  The *comm* flags, along with the
-The *comm* flags will also automatically be changed to *no*\ . This can
+*sort* and *atom/map* keywords will also automatically be changed to *no*\ .
-result in better performance for certain configurations and system sizes.
+This can result in better performance for certain configurations and
+system sizes.
 
 ----------
 
@@ -684,18 +692,18 @@ Restrictions
 This command cannot be used after the simulation box is defined by a
 :doc:`read_data <read_data>` or :doc:`create_box <create_box>` command.
 
-The gpu style of this command can only be invoked if LAMMPS was built
+The *gpu* style of this command can only be invoked if LAMMPS was built
 with the GPU package.  See the :doc:`Build package <Build_package>` doc
 page for more info.
 
-The intel style of this command can only be invoked if LAMMPS was
+The *intel* style of this command can only be invoked if LAMMPS was
 built with the INTEL package.  See the :doc:`Build package <Build_package>` page for more info.
 
-The kk style of this command can only be invoked if LAMMPS was built
+The *kokkos* style of this command can only be invoked if LAMMPS was built
 with the KOKKOS package.  See the :doc:`Build package <Build_package>`
 doc page for more info.
 
-The omp style of this command can only be invoked if LAMMPS was built
+The *omp* style of this command can only be invoked if LAMMPS was built
 with the OPENMP package.  See the :doc:`Build package <Build_package>`
 doc page for more info.
 
@@ -704,19 +712,27 @@ Related commands
 
 :doc:`suffix <suffix>`, :doc:`-pk command-line switch <Run_options>`
 
-Default
+Defaults
-"""""""
+""""""""
 
-For the GPU package, the default is Ngpu = 0 and the option defaults are neigh
+For the GPU package, the default parameters and settings are:
-= yes, newton = off, binsize = 0.0, split = 1.0, gpuID = 0 to Ngpu-1, tpa = 1,
-omp = 0, and platform=-1.  These settings are made automatically if the "-sf
-gpu" :doc:`command-line switch <Run_options>` is used.  If it is not used, you
-must invoke the package gpu command in your input script or via the "-pk gpu"
-:doc:`command-line switch <Run_options>`.
 
-For the INTEL package, the default is Nphi = 1 and the option defaults are omp
+.. parsed-literal::
-= 0, mode = mixed, lrt = no, balance = -1, tpc = 4, tptask = 240, pppm_table =
+
-yes.  The default ghost option is determined by the pair style being used.
+   Ngpu = 0, neigh = yes, newton = off, binsize = 0.0, split = 1.0, gpuID = 0 to Ngpu-1, tpa = 1, omp = 0, platform=-1.
+
+These settings are made automatically if the "-sf gpu"
+:doc:`command-line switch <Run_options>` is used.  If it is not used,
+you must invoke the package gpu command in your input script or via the
+"-pk gpu" :doc:`command-line switch <Run_options>`.
+
+For the INTEL package, the default parameters and settings are:
+
+.. parsed-literal::
+
+   Nphi = 1, omp = 0, mode = mixed, lrt = no, balance = -1, tpc = 4, tptask = 240, pppm_table = yes
+
+The default ghost option is determined by the pair style being used.
 This value is output to the screen in the offload report at the end of each
 run.  Note that all of these settings, except "omp" and "mode", are ignored if
 LAMMPS was not built with Xeon Phi co-processor support.  These settings are
@@ -724,20 +740,35 @@ made automatically if the "-sf intel" :doc:`command-line switch <Run_options>`
 is used.  If it is not used, you must invoke the package intel command in your
 input script or via the "-pk intel" :doc:`command-line switch <Run_options>`.
 
-For the KOKKOS package, the option defaults for GPUs are neigh = full,
+For the KOKKOS package when using GPUs, the option defaults are:
-neigh/qeq = full, newton = off, binsize for GPUs = 2x LAMMPS default value,
-comm = device, sort = device, neigh/transpose = off, gpu/aware = on. When
-LAMMPS can safely detect that GPU-aware MPI is not available, the default value
-of gpu/aware becomes "off". For CPUs or Xeon Phis, the option defaults are
-neigh = half, neigh/qeq = half, newton = on, binsize = 0.0, comm = no, and sort
-= no. For GPUs, option neigh/thread = on when there are 16k atoms or less on an MPI
-rank, otherwise it is "off". These settings are made automatically by the
-required "-k on" :doc:`command-line switch <Run_options>`. You can change them
-by using the package kokkos command in your input script or via the :doc:`-pk
-kokkos command-line switch <Run_options>`.
 
-For the OMP package, the default is Nthreads = 0 and the option defaults are
+.. parsed-literal::
-neigh = yes.  These settings are made automatically if the "-sf omp"
+
-:doc:`command-line switch <Run_options>` is used.  If it is not used, you must
+   neigh = full, neigh/qeq = full, newton = off, binsize = 2x LAMMPS default value, comm = device, sort = device, atom/map = device, neigh/transpose = off, gpu/aware = on
-invoke the package omp command in your input script or via the "-pk omp"
+
-:doc:`command-line switch <Run_options>`.
+For GPUs, option neigh/thread = on when there are 16k atoms or less on
+an MPI rank, otherwise it is "off". When LAMMPS can safely detect that
+GPU-aware MPI is not available, the default value of gpu/aware becomes
+"off".
+
+For the KOKKOS package when using CPUs or Xeon Phis, the option defaults are:
+
+.. parsed-literal::
+
+   neigh = half, neigh/qeq = half, newton = on, binsize = 0.0, comm = no, sort = no, atom/map = no
+
+These settings are made automatically by
+the required "-k on" :doc:`command-line switch <Run_options>`.  You can
+change them by using the package kokkos command in your input script or
+via the :doc:`-pk kokkos command-line switch <Run_options>`.
+
+For the OMP package, the defaults are
+
+.. parsed-literal::
+
+   Nthreads = 0, neigh = yes
+
+These settings are made automatically if the "-sf omp"
+:doc:`command-line switch <Run_options>` is used.  If it is not used,
+you must invoke the package omp command in your input script or via the
+"-pk omp" :doc:`command-line switch <Run_options>`.

doc/src/pair_airebo.rst

@@ -156,7 +156,7 @@ pair_coeff command:
 The first 2 arguments must be \* \* so as to span all LAMMPS atom types.
 The first three C arguments map LAMMPS atom types 1,2,3 to the C
 element in the AIREBO file.  The final H argument maps LAMMPS atom
-type 4 to the H element in the SW file.  If a mapping value is
+type 4 to the H element in the AIREBO file.  If a mapping value is
 specified as NULL, the mapping is not performed.  This can be used
 when a *airebo* potential is used as part of the *hybrid* pair style.
 The NULL values are placeholders for atom types that will be used with
@@ -222,12 +222,12 @@ enabled if LAMMPS was built with that package.  See the :doc:`Build package <Bui
 These pair potentials require the :doc:`newton <newton>` setting to be
 "on" for pair interactions.
 
-The CH.airebo and CH.airebo-m potential files provided with LAMMPS
+The CH.airebo and CH.airebo-m potential files provided with LAMMPS (see
-(see the potentials directory) are parameterized for metal :doc:`units <units>`.
+the potentials directory) are parameterized for metal :doc:`units
-You can use the AIREBO, AIREBO-M or REBO potential with any LAMMPS units,
+<units>`.  You can use the pair styles with *any* LAMMPS units, but you
-but you would need to create your own AIREBO or AIREBO-M potential file
+would need to create your own AIREBO or AIREBO-M potential file with
-with coefficients listed in the appropriate units, if your simulation
+coefficients listed in the appropriate units, if your simulation does
-does not use "metal" units.
+not use "metal" units.
 
 The pair styles provided here **only** support potential files parameterized
 for the elements carbon and hydrogen (designated with "C" and "H" in the

doc/src/pair_dsmc.rst

@@ -138,8 +138,12 @@ This pair style can only be used via the *pair* keyword of the
 Restrictions
 """"""""""""
 
-This style is part of the MC package.  It is only enabled if LAMMPS
+This pair style is part of the MC package.  It is only enabled if LAMMPS
-was built with that package.  See the :doc:`Build package <Build_package>` page for more info.
+was built with that package.  See the :doc:`Build package
+<Build_package>` page for more info.
+
+This pair style requires an :doc:`atom style <atom_style>` with per
+atom type masses.
 
 Related commands
 """"""""""""""""

doc/src/pair_eam.rst

@@ -140,6 +140,21 @@ The OpenKIM Project at
 provides EAM potentials that can be used directly in LAMMPS with the
 :doc:`kim command <kim_commands>` interface.
 
+.. warning::
+
+   The EAM potential files tabulate the embedding energy as a function
+   of the local electron density :math:`\rho`.  When atoms get too
+   close, this electron density may exceed the range for which the
+   embedding energy was tabulated for.  To avoid crashes, LAMMPS will
+   assume a linearly increasing embedding energy for electron densities
+   beyond the maximum tabulated value.  LAMMPS will print a warning when
+   this happens.  It may be acceptable at the beginning of an
+   equilibration (e.g. when using randomized coordinates) but would be a
+   big concern for accuracy if it happens during production runs.  The
+   EAM potential file triggering the warning during production is thus
+   not a good choice, and the EAM model in general not likely a good
+   model for the kind of system under investigation.
+
 ----------
 
 For style *eam*, potential values are read from a file that is in the

doc/src/pair_granular.rst

@@ -187,6 +187,7 @@ for the damping model currently supported are:
 2. *mass_velocity*
 3. *viscoelastic*
 4. *tsuji*
+5. *coeff_restitution*
 
 If the *damping* keyword is not specified, the *viscoelastic* model is
 used by default.
@@ -248,6 +249,29 @@ The dimensionless coefficient of restitution :math:`e` specified as part
 of the normal contact model parameters should be between 0 and 1, but
 no error check is performed on this.
 
+The *coeff_restitution* model is useful when a specific normal coefficient of
+restitution :math:`e` is required. In these models, the normal coefficient of
+restitution :math:`e` is specified as an input. Following the approach of
+:ref:`(Brilliantov et al) <Brill1996>`, when using the *hooke* normal model,
+*coeff_restitution* calculates the damping coefficient as:
+
+.. math::
+
+   \eta_n = \sqrt{\frac{4m_{eff}k_n}{1+\left( \frac{\pi}{\log(e)}\right)^2}} ,
+
+For any other normal model, e.g. the *hertz* and *hertz/material* models, the damping
+coefficient is:
+
+.. math::
+
+   \eta_n = -2\sqrt{\frac{5}{6}}\frac{\log(e)}{\sqrt{\pi^2+(\log(e))^2}}(R_{eff} \delta_{ij})^{\frac{1}{4}}\sqrt{\frac{3}{2}k_n m_{eff}} ,
+
+where :math:`k_n = \frac{4}{3} E_{eff}` for the *hertz/material* model. Since
+*coeff_restitution* accounts for the effective mass, effective radius, and
+pairwise overlaps (except when used with the *hooke* normal model) when calculating
+the damping coefficient, it accurately reproduces the specified coefficient of
+restitution for both monodisperse and polydisperse particle pairs.
+
 The total normal force is computed as the sum of the elastic and
 damping components:
 

doc/src/pair_meam.rst

@@ -427,8 +427,8 @@ package. They are only enabled if LAMMPS was built with that package.
 See the :doc:`Build package <Build_package>` page for more info.
 
 The maximum number of elements, that can be read from the MEAM library
-file, is determined at compile time. The default is 5.  If you need
+file, is determined at compile time. The default is 8.  If you need
-support for more elements, you have to change the the constant 'maxelt'
+support for more elements, you have to change the the constant 'MAXELT'
 at the beginning of the file ``src/MEAM/meam.h`` and update/recompile
 LAMMPS.  There is no limit on the number of atoms types.
 

doc/src/pair_mliap.rst

@@ -22,7 +22,7 @@ Syntax
          style = *linear* or *quadratic* or *nn* or *mliappy*
          filename = name of file containing model definitions
        *descriptor* values = style filename
-         style = *sna* or *so3*
+         style = *sna* or *so3* or *ace*
          filename = name of file containing descriptor definitions
        *unified* values = filename ghostneigh_flag
          filename = name of file containing serialized unified Python object
@@ -36,6 +36,7 @@ Examples
    pair_style mliap model linear InP.mliap.model descriptor sna InP.mliap.descriptor
    pair_style mliap model quadratic W.mliap.model descriptor sna W.mliap.descriptor
    pair_style mliap model nn Si.nn.mliap.model descriptor so3 Si.nn.mliap.descriptor
+   pair_style mliap model mliappy ACE_NN_Pytorch.pt descriptor ace ccs_single_element.yace
    pair_style mliap unified mliap_unified_lj_Ar.pkl 0
    pair_coeff * * In P
 
@@ -49,8 +50,8 @@ quantities that characterize the atomic positions (*descriptor*).
 
 By defining *model* and *descriptor* separately, it is possible to use
 many different models with a given descriptor, or many different
-descriptors with a given model.  The pair style currently supports only
+descriptors with a given model.  The pair style currently supports *sna*,
-*sna* and *so3* descriptor styles, but it is straightforward to add new
+*so3* and *ace* descriptor styles, but it is straightforward to add new
 descriptor styles.  By using the *unified* keyword, it is possible to
 define a Python model that combines functionalities of both *model* and
 *descriptor*.
@@ -72,6 +73,26 @@ the smooth SO(3) power spectrum with the explicit inclusion of a radial
 basis :ref:`(Bartok) <Bartok2013>` and :ref:`(Zagaceta) <Zagaceta2020>`.
 The available models are *linear* and *nn*.
 
+.. versionadded:: 17Apr2024
+
+The descriptor style *ace* is a class of highly general atomic
+descriptors, atomic cluster expansion descriptors (ACE) from
+:ref:`(Drautz) <Drautz19>`, that include a radial basis, an angular
+basis, and bases for other variables (such as chemical species) if
+relevant. In descriptor style *ace*, the *ace* descriptors may be
+defined up to an arbitrary body order. This descriptor style is the same
+as that used in :doc:`pair_style pace <pair_pace>` and :doc:`compute
+pace <compute_pace>`.  The available models with *ace* in ML-IAP are
+*linear* and *mliappy*.  The *ace* descriptors and models require
+building LAMMPS with the ML-PACE package (see below).  The *mliappy*
+model style may be used with *ace* descriptors, but it requires that
+LAMMPS is also built with the PYTHON package.  As with other model
+styles, the *mliappy* model style can be used to couple arbitrary python
+models that use the *ace* descriptors such as Pytorch NNs.  Note that
+*ALL* mliap model styles with *ace* descriptors require that descriptors
+and hyperparameters are supplied in a `.yace` or `.ace` file, similar to
+:doc:`compute pace <compute_pace>`.
+
 The pair_style *mliap* command must be followed by two keywords *model*
 and *descriptor* in either order, or the one keyword *unified*.  A
 single *pair_coeff* command is also required.  The first 2 arguments
@@ -136,7 +157,7 @@ The detail of *nn* module implementation can be found at :ref:`(Yanxon) <Yanxon2
    the mliap-specific python module that is built into LAMMPS.
 
 The *descriptor* keyword is followed by a descriptor style, and additional arguments.
-Currently two descriptor styles are available: *sna* and *so3*.
+Currently three descriptor styles are available: *sna*, *so3*, and *ace*.
 
 - *sna* indicates the bispectrum component descriptors used by the Spectral
   Neighbor Analysis Potential (SNAP) potentials of :doc:`pair_style snap
@@ -148,6 +169,16 @@ Currently two descriptor styles are available: *sna* and *so3*.
 - *so3* indicated the power spectrum component descriptors. A single additional
   argument specifies the descriptor filename containing the parameters and setting.
 
+- *ace* indicates the atomic cluster expansion (ACE) descriptors. A single
+  additional argument specifies the filename containing parameters, settings, and
+  definitions of the ace descriptors (through tabulated basis function indices and
+  corresponding generalized Clebsch-Gordan coefficients) in the ctilde file format,
+  e.g. in the potential file format with `*.ace` or `*.yace` extensions from
+  :doc:`pair_style pace <pair_pace>`. Note that unlike the potential file, the
+  Clebsch-Gordan coefficients in the descriptor file supplied should *NOT* be
+  multiplied by linear or square root embedding terms.
+
+
 The SNAP descriptor file closely follows the format of the
 :doc:`pair_style snap <pair_snap>` parameter file.  The file can contain
 blank and comment lines (start with #) anywhere. Each non-blank
@@ -169,6 +200,24 @@ contains a few more arguments (e.g., *nmax* and *alpha*). The preparation
 of SO3 descriptor and model files can be done with the
 `Pyxtal_FF <https://github.com/qzhu2017/PyXtal_FF>`_ package.
 
+The ACE descriptor file differs from the SNAP and SO3 files. It more
+closely resembles the potential file format for linear or square-root
+embedding ACE potentials used in the :doc:`pair_style pace <pair_pace>`.
+As noted above, the key difference is that the Clebsch-Gordan
+coefficients in the descriptor file with *mliap descriptor ace* are
+*NOT* multiplied by linear or square root embedding terms.  In other
+words,the model is separated from the descriptor definitions and
+hyperparameters.  In :doc:`pair_style pace <pair_pace>`, they are
+combined.  The ACE descriptor files required by *mliap* are generated
+automatically in `FitSNAP <https://github.com/FitSNAP/FitSNAP>`_ during
+linear, pytorch, etc. ACE model fitting. Additional tools are provided
+there to prepare *ace* descriptor files and hyperparameters before model
+fitting.  The *ace* descriptor files can also be extracted from ACE
+model fits in `python-ace. <https://github.com/ICAMS/python-ace>`_.  It
+is important to note that order of the types listed in :doc:`pair_coeff
+<pair_coeff>` must match the order of the elements/types listed in the
+ACE descriptor file for all *mliap* styles when using *ace* descriptors.
+
 See the :doc:`pair_coeff <pair_coeff>` page for alternate ways
 to specify the path for these *model* and *descriptor* files.
 
@@ -245,7 +294,10 @@ This pair style is part of the ML-IAP package.  It is only enabled if
 LAMMPS was built with that package. In addition, building LAMMPS with
 the ML-IAP package requires building LAMMPS with the ML-SNAP package.
 The *mliappy* model requires building LAMMPS with the PYTHON package.
-See the :doc:`Build package <Build_package>` page for more info.
+The *ace* descriptor requires building LAMMPS with the ML-PACE package.
+See the :doc:`Build package <Build_package>` page for more info. Note
+that `pair_mliap/kk` acceleration will *not* invoke the `kk`
+accelerated variants of SNAP or ACE descriptors.
 
 
 Related commands
@@ -271,5 +323,3 @@ none
 .. _Yanxon2020:
 
 **(Yanxon2020)** Yanxon, Zagaceta, Tang, Matteson, Zhu, Mach. Learn.: Sci. Technol. 2, 027001 (2020).
-
-

doc/src/pair_pedone.rst

@@ -0,0 +1,137 @@
+.. index:: pair_style pedone
+.. index:: pair_style pedone/omp
+
+pair_style pedone command
+=========================
+
+Accelerator Variants: *pedone/omp*
+
+
+Syntax
+""""""
+
+.. code-block:: LAMMPS
+
+   pair_style style args
+
+* style = pedone*
+* args = list of arguments for a particular style
+
+.. parsed-literal::
+
+    *pedone* args = cutoff
+      cutoff = global cutoff for Pedone interactions (distance units)
+
+Examples
+""""""""
+
+.. code-block:: LAMMPS
+
+pair_style hybrid/overlay pedone 15.0 coul/long 15.0
+kspace_style pppm 1.0e-5
+
+pair_coeff * * coul/long
+pair_coeff 1 2 pedone 0.030211 2.241334 2.923245 5.0
+pair_coeff 2 2 pedone 0.042395 1.379316 3.618701 22.0
+
+Used in input scripts:
+
+   .. parsed-literal::
+
+      examples/PACKAGES/pedone/in.pedone.relax
+      examples/PACKAGES/pedone/in.pedone.melt
+
+
+
+Description
+"""""""""""
+
+.. versionadded:: 17Apr2024
+
+Pair style *pedone* computes the **non-Coulomb** interactions of the Pedone
+(or PMMCS) potential :ref:`(Pedone) <Pedone>` which combines Coulomb
+interactions, Morse potential, and repulsive :math:`r^{-12}`
+Lennard-Jones terms (see below).  The *pedone* pair style is meant
+to be used in addition to a :doc:`Coulomb pair style <pair_coul>` via
+pair style :doc:`hybrid/overlay <pair_hybrid>` (see example above).
+Using *coul/long* or *could/dsf* (for solids) is recommended.
+
+The full Pedone potential function from :ref:`(Pedone) <Pedone>` for each
+pair of atoms is:
+
+.. math::
+
+   E =  \frac{C q_i q_j}{\epsilon  r}
+       + D_0 \left[ e^{- 2 \alpha (r - r_0)} - 2 e^{- \alpha (r - r_0)} \right]
+       + \frac{B_0}{r^{12}} \qquad r < r_c
+
+:math:`r_c` is the cutoff and :math:`C` is a conversion factor that is
+specific to the choice of :doc:`units <units>` so that the entire
+Coulomb term is in energy units with :math:`q_i` and :math:`q_j` as the
+assigned charges in multiples of the elementary charge.
+
+The following coefficients must be defined for the selected pairs of
+atom types via the :doc:`pair_coeff <pair_coeff>` command as in the
+example above:
+
+* :math:`D_0` (energy units)
+* :math:`\alpha` (1/distance units)
+* :math:`r_0` (distance units)
+* :math:`C_0` (energy units)
+* cutoff (distance units)
+
+The last coefficient is optional.  If not specified, the global *pedone*
+cutoff is used.
+
+----------
+
+.. include:: accel_styles.rst
+
+----------
+
+Mixing, shift, table, tail correction, restart, rRESPA info
+"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
+
+This pair style does not support mixing.
+
+This pair style support the :doc:`pair_modify <pair_modify>` shift
+option for the energy of the pair interaction.
+
+This pair style does not support the :doc:`pair_modify <pair_modify>`
+tail option for adding long-range tail corrections to energy and
+pressure.
+
+This pair style writes its information to :doc:`binary restart files <restart>`,
+so pair_style and pair_coeff commands does not need to be specified in an input
+script that reads a restart file.
+
+This pair style can only be used via the *pair* keyword of the
+:doc:`run_style respa <run_style>` command.  It does not support the
+*inner*, *middle*, or *outer* keywords.
+
+----------
+
+Restrictions
+""""""""""""
+
+The *pedone* pair style is only enabled if LAMMPS was built with the
+EXTRA-PAIR package.  See the :doc:`Build package <Build_package>` page
+for more info.
+
+Related commands
+""""""""""""""""
+
+:doc:`pair_coeff <pair_coeff>`, :doc:`pair_style <pair_style>`,
+:doc:`pair style coul/long and coul/dsf <pair_coul>`,
+:doc:`pair style morse <pair_morse>`
+
+Default
+"""""""
+
+none
+
+-------------
+
+.. _Pedone:
+
+**(Pedone)** A. Pedone, G. Malavasi, M. C. Menziani, A. N. Cormack, and U. Segre, J. Phys. Chem. B, 110, 11780 (2006)

doc/src/pair_rebomos.rst

@@ -0,0 +1,150 @@
+.. index:: pair_style rebomos
+.. index:: pair_style rebomos/omp
+
+pair_style rebomos command
+==========================
+
+Accelerator Variants: *rebomos/omp*
+
+Syntax
+""""""
+
+.. code-block:: LAMMPS
+
+   pair_style rebomos
+
+* rebomos = name of this pair style
+
+Examples
+""""""""
+
+.. code-block:: LAMMPS
+
+   pair_style rebomos
+   pair_coeff * * ../potentials/MoS.rebomos Mo S
+
+Example input scripts available: examples/threebody/
+
+Description
+"""""""""""
+
+.. versionadded:: 17Apr2024
+
+The *rebomos* pair style computes the interactions between molybdenum
+and sulfur atoms :ref:`(Stewart) <Stewart>` utilizing an adaptive
+interatomic reactive empirical bond order potential that is similar in
+form to the AIREBO potential :ref:`(Stuart) <Stuart2>`.  The potential
+is based on an earlier parameterizations for :math:`\text{MoS}_2`
+developed by :ref:`(Liang) <Liang>`.
+
+The REBOMoS potential consists of two terms:
+
+.. math::
+
+   E & = \frac{1}{2} \sum_i \sum_{j \neq i}
+   \left[ E^{\text{REBO}}_{ij} + E^{\text{LJ}}_{ij}  \right] \\
+
+The :math:`E^{\text{REBO}}` term describes the covalently bonded
+interactions between Mo and S atoms while the :math:`E^{\text{LJ}}` term
+describes longer range dispersion forces between layers.  A cubic spline
+function is applied to smoothly switch between covalent bonding at short
+distances to dispersion interactions at longer distances. This allows
+the model to capture bond formation and breaking events which may occur
+between adjacent MoS2 layers, edges, defects, and more.
+
+----------
+
+Only a single pair_coeff command is used with the *rebomos* pair style
+which specifies an REBOMoS potential file with parameters for Mo and S.
+These are mapped to LAMMPS atom types by specifying N additional
+arguments after the filename in the pair_coeff command, where N is the
+number of LAMMPS atom types:
+
+* filename
+* :math:`N` element names = mapping of REBOMoS elements to atom types
+
+See the :doc:`pair_coeff <pair_coeff>` page for alternate ways
+to specify the path for the potential file.
+
+As an example, if your LAMMPS simulation has three atom types and you want
+the first two to be Mo, and the third to be S, you would use the following
+pair_coeff command:
+
+.. code-block:: LAMMPS
+
+   pair_coeff * * MoS.rebomos Mo Mo S
+
+The first 2 arguments must be \* \* so as to span all LAMMPS atom types.
+The first two Mo arguments map LAMMPS atom types 1 and 2 to the Mo
+element in the REBOMoS file.  The final S argument maps LAMMPS atom type
+3 to the S element in the REBOMoS file.  If a mapping value is specified
+as NULL, the mapping is not performed.  This can be used when a
+*rebomos* potential is used as part of the *hybrid* pair style.  The
+NULL values are placeholders for atom types that will be used with other
+potentials.
+
+----------
+
+.. include:: accel_styles.rst
+
+----------
+
+Mixing, shift, table, tail correction, restart, rRESPA info
+"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
+
+This pair style does not support the :doc:`pair_modify <pair_modify>`
+mix, shift, table, and tail options.
+
+This pair style does not write their information to :doc:`binary restart
+files <restart>`, since it is stored in potential files.  Thus, you need
+to re-specify the pair_style and pair_coeff commands in an input script
+that reads a restart file.
+
+This pair styles can only be used via the *pair* keyword of the
+:doc:`run_style respa <run_style>` command.  It does not support the
+*inner*, *middle*, *outer* keywords.
+
+Restrictions
+""""""""""""
+
+This pair style is part of the MANYBODY package.  It is only enabled if
+LAMMPS was built with that package.  See the :doc:`Build package
+<Build_package>` page for more info.
+
+These pair potentials require the :doc:`newton <newton>` setting to be
+"on" for pair interactions.
+
+The MoS.rebomos potential file provided with LAMMPS (see the potentials
+directory) is parameterized for metal :doc:`units <units>`.  You can use
+the *rebomos* pair style with any LAMMPS units setting, but you would
+need to create your own REBOMoS potential file with coefficients listed
+in the appropriate units.
+
+The pair style provided here **only** supports potential files parameterized
+for the elements molybdenum and sulfur (designated with "Mo" and "S" in the
+*pair_coeff* command.  Using potential files for other elements will trigger
+an error.
+
+Related commands
+""""""""""""""""
+
+:doc:`pair_coeff <pair_coeff>`, :doc:`pair style rebo <pair_airebo>`
+
+Default
+"""""""
+
+none
+
+----------
+
+.. _Stewart:
+
+**(Steward)**  Stewart, Spearot, Modelling Simul. Mater. Sci. Eng. 21, 045003, (2013).
+
+.. _Stuart2:
+
+**(Stuart)** Stuart, Tutein, Harrison, J Chem Phys, 112, 6472-6486, (2000).
+
+.. _Liang:
+
+**(Liang)**  Liang, Phillpot, Sinnott Phys. Rev. B79 245110, (2009), Erratum: Phys. Rev. B85 199903(E), (2012)

doc/src/pair_style.rst

@@ -275,30 +275,30 @@ accelerated styles exist.
 * :doc:`lj/smooth/linear <pair_lj_smooth_linear>` - linear smoothed LJ potential
 * :doc:`lj/switch3/coulgauss/long <pair_lj_switch3_coulgauss_long>` - smoothed LJ vdW potential with Gaussian electrostatics
 * :doc:`lj96/cut <pair_lj96>` - Lennard-Jones 9/6 potential
-* :doc:`local/density <pair_local_density>` - generalized basic local density potential
+* :doc:`local/density <pair_local_density>` - Generalized basic local density potential
-* :doc:`lubricate <pair_lubricate>` - hydrodynamic lubrication forces
+* :doc:`lubricate <pair_lubricate>` - Hydrodynamic lubrication forces
-* :doc:`lubricate/poly <pair_lubricate>` - hydrodynamic lubrication forces with polydispersity
+* :doc:`lubricate/poly <pair_lubricate>` - Hydrodynamic lubrication forces with polydispersity
-* :doc:`lubricateU <pair_lubricateU>` - hydrodynamic lubrication forces for Fast Lubrication Dynamics
+* :doc:`lubricateU <pair_lubricateU>` - Hydrodynamic lubrication forces for Fast Lubrication Dynamics
-* :doc:`lubricateU/poly <pair_lubricateU>` - hydrodynamic lubrication forces for Fast Lubrication with polydispersity
+* :doc:`lubricateU/poly <pair_lubricateU>` - Hydrodynamic lubrication forces for Fast Lubrication with polydispersity
 * :doc:`mdpd <pair_mesodpd>` - mDPD particle interactions
 * :doc:`mdpd/rhosum <pair_mesodpd>` - mDPD particle interactions for mass density
-* :doc:`meam <pair_meam>` - modified embedded atom method (MEAM)
+* :doc:`meam <pair_meam>` - Modified embedded atom method (MEAM)
-* :doc:`meam/ms <pair_meam>` - multi-state modified embedded atom method (MS-MEAM)
+* :doc:`meam/ms <pair_meam>` - Multi-state modified embedded atom method (MS-MEAM)
-* :doc:`meam/spline <pair_meam_spline>` - splined version of MEAM
+* :doc:`meam/spline <pair_meam_spline>` - Splined version of MEAM
-* :doc:`meam/sw/spline <pair_meam_sw_spline>` - splined version of MEAM with a Stillinger-Weber term
+* :doc:`meam/sw/spline <pair_meam_sw_spline>` - Splined version of MEAM with a Stillinger-Weber term
-* :doc:`mesocnt <pair_mesocnt>` - mesoscopic vdW potential for (carbon) nanotubes
+* :doc:`mesocnt <pair_mesocnt>` - Mesoscopic vdW potential for (carbon) nanotubes
-* :doc:`mesocnt/viscous <pair_mesocnt>` - mesoscopic vdW potential for (carbon) nanotubes with friction
+* :doc:`mesocnt/viscous <pair_mesocnt>` - Mesoscopic vdW potential for (carbon) nanotubes with friction
-* :doc:`mgpt <pair_mgpt>` - simplified model generalized pseudopotential theory (MGPT) potential
+* :doc:`mgpt <pair_mgpt>` - Simplified model generalized pseudopotential theory (MGPT) potential
 * :doc:`mie/cut <pair_mie>` - Mie potential
-* :doc:`mm3/switch3/coulgauss/long <pair_lj_switch3_coulgauss_long>` - smoothed MM3 vdW potential with Gaussian electrostatics
+* :doc:`mm3/switch3/coulgauss/long <pair_lj_switch3_coulgauss_long>` - Smoothed MM3 vdW potential with Gaussian electrostatics
 * :doc:`momb <pair_momb>` - Many-Body Metal-Organic (MOMB) force field
 * :doc:`morse <pair_morse>` - Morse potential
-* :doc:`morse/smooth/linear <pair_morse>` - linear smoothed Morse potential
+* :doc:`morse/smooth/linear <pair_morse>` - Linear smoothed Morse potential
 * :doc:`morse/soft <pair_morse>` - Morse potential with a soft core
 * :doc:`multi/lucy <pair_multi_lucy>` - DPD potential with density-dependent force
 * :doc:`multi/lucy/rx <pair_multi_lucy_rx>` - reactive DPD potential with density-dependent force
-* :doc:`nb3b/harmonic <pair_nb3b>` - non-bonded 3-body harmonic potential
+* :doc:`nb3b/harmonic <pair_nb3b>` - Non-bonded 3-body harmonic potential
-* :doc:`nb3b/screened <pair_nb3b>` - non-bonded 3-body screened harmonic potential
+* :doc:`nb3b/screened <pair_nb3b>` - Non-bonded 3-body screened harmonic potential
 * :doc:`nm/cut <pair_nm>` - N-M potential
 * :doc:`nm/cut/coul/cut <pair_nm>` - N-M potential with cutoff Coulomb
 * :doc:`nm/cut/coul/long <pair_nm>` - N-M potential with long-range Coulomb
@@ -322,20 +322,22 @@ accelerated styles exist.
 * :doc:`oxrna2/xstk <pair_oxrna2>` -
 * :doc:`pace <pair_pace>` - Atomic Cluster Expansion (ACE) machine-learning potential
 * :doc:`pace/extrapolation <pair_pace>` - Atomic Cluster Expansion (ACE) machine-learning potential with extrapolation grades
+* :doc:`pedone <pair_pedone>` - Pedone (PMMCS) potential (non-Coulomb part)
 * :doc:`pod <pair_pod>` - Proper orthogonal decomposition (POD) machine-learning potential
-* :doc:`peri/eps <pair_peri>` - peridynamic EPS potential
+* :doc:`peri/eps <pair_peri>` - Peridynamic EPS potential
-* :doc:`peri/lps <pair_peri>` - peridynamic LPS potential
+* :doc:`peri/lps <pair_peri>` - Peridynamic LPS potential
-* :doc:`peri/pmb <pair_peri>` - peridynamic PMB potential
+* :doc:`peri/pmb <pair_peri>` - Peridynamic PMB potential
-* :doc:`peri/ves <pair_peri>` - peridynamic VES potential
+* :doc:`peri/ves <pair_peri>` - Peridynamic VES potential
-* :doc:`polymorphic <pair_polymorphic>` - polymorphic 3-body potential
+* :doc:`polymorphic <pair_polymorphic>` - Polymorphic 3-body potential
 * :doc:`python <pair_python>` -
 * :doc:`quip <pair_quip>` -
 * :doc:`rann <pair_rann>` -
 * :doc:`reaxff <pair_reaxff>` - ReaxFF potential
-* :doc:`rebo <pair_airebo>` - second generation REBO potential of Brenner
+* :doc:`rebo <pair_airebo>` - Second generation REBO potential of Brenner
+* :doc:`rebomos <pair_rebomos>` - REBOMoS potential for MoS2
 * :doc:`resquared <pair_resquared>` - Everaers RE-Squared ellipsoidal potential
-* :doc:`saip/metal <pair_saip_metal>` - interlayer potential for hetero-junctions formed with hexagonal 2D materials and metal surfaces
+* :doc:`saip/metal <pair_saip_metal>` - Interlayer potential for hetero-junctions formed with hexagonal 2D materials and metal surfaces
-* :doc:`sdpd/taitwater/isothermal <pair_sdpd_taitwater_isothermal>` - smoothed dissipative particle dynamics for water at isothermal conditions
+* :doc:`sdpd/taitwater/isothermal <pair_sdpd_taitwater_isothermal>` - Smoothed dissipative particle dynamics for water at isothermal conditions
 * :doc:`smatb <pair_smatb>` - Second Moment Approximation to the Tight Binding
 * :doc:`smatb/single <pair_smatb>` - Second Moment Approximation to the Tight Binding for single-element systems
 * :doc:`smd/hertz <pair_smd_hertz>` -

doc/src/processors.rst

@@ -25,6 +25,8 @@ Syntax
            *numa* params = none
            *custom* params = infile
              infile = file containing grid layout
+       *numa_nodes* arg = Nn
+             Nn = number of numa domains per node
        *map* arg = *cart* or *cart/reorder* or *xyz* or *xzy* or *yxz* or *yzx* or *zxy* or *zyx*
           cart = use MPI_Cart() methods to map processors to 3d grid with reorder = 0
           cart/reorder = use MPI_Cart() methods to map processors to 3d grid with reorder = 1
@@ -157,26 +159,30 @@ surface-to-volume ratio of each processor's subdomain.
    for most MPI implementations, but some MPIs provide options for this
    ordering, e.g. via environment variable settings.
 
-The *numa* style operates similar to the *twolevel* keyword except
+The *numa* style operates similar to the *twolevel* keyword except that
-that it auto-detects which cores are running on which nodes.
+it auto-detects which cores are running on which nodes.  It will also
-Currently, it does this in only 2 levels, but it may be extended in
+subdivide the cores into numa domains. Currently, the number of numa
-the future to account for socket topology and other non-uniform memory
+domains is not auto-detected and must be specified using the
-access (NUMA) costs.  It also uses a different algorithm than the
+*numa_nodes* keyword; otherwise, the default value is used. The *numa*
-*twolevel* keyword for doing the two-level factorization of the
+style uses a different algorithm than the *twolevel* keyword for doing
-simulation box into a 3d processor grid to minimize off-node
+the two-level factorization of the simulation box into a 3d processor
-communication, and it does its own MPI-based mapping of nodes and
+grid to minimize off-node communication and communication across numa
-cores to the regular 3d grid.  Thus it may produce a different layout
+domains. It does its own MPI-based mapping of nodes and cores to the
-of the processors than the *twolevel* options.
+regular 3d grid.  Thus it may produce a different layout of the
+processors than the *twolevel* options.
 
 The *numa* style will give an error if the number of MPI processes is
 not divisible by the number of cores used per node, or any of the Px
-or Py of Pz values is greater than 1.
+or Py or Pz values is greater than 1.
 
 .. note::
 
    Unlike the *twolevel* style, the *numa* style does not require
    any particular ordering of MPI ranks in order to work correctly. This
    is because it auto-detects which processes are running on which nodes.
+   However, it assumes that the lowest ranks are in the first numa
+   domain, and so forth. MPI rank orderings that do not preserve this
+   property might result in more intra-node communication between CPUs.
 
 The *custom* style uses the file *infile* to define both the 3d
 factorization and the mapping of processors to the grid.
@@ -207,6 +213,14 @@ any order, but no processor ID should appear more than once.
 
 ----------
 
+The *numa_nodes* keyword is used to specify the number of numa domains
+per node. It is currently only used by the *numa* style for two-level
+factorization to reduce the amount of MPI communications between CPUs.
+A good setting for this will typically be equal to the number of CPU
+sockets per node.
+
+----------
+
 The *map* keyword affects how the P processor IDs (from 0 to P-1) are
 mapped to the 3d grid of processors.  It is only used by the
 *onelevel* and *twolevel* grid settings.
@@ -356,5 +370,5 @@ Related commands
 Default
 """""""
 
-The option defaults are Px Py Pz = \* \* \*, grid = onelevel, and map =
+The option defaults are Px Py Pz = \* \* \*, grid = onelevel, map =
-cart.
+cart, and numa_nodes = 2.

doc/src/read_data.rst

@@ -63,11 +63,16 @@ Description
 
 Read in a data file containing information LAMMPS needs to run a
 simulation.  The file can be ASCII text or a gzipped text file
-(detected by a .gz suffix).  This is one of 3 ways to specify initial
+(detected by a .gz suffix).
-atom coordinates; see the :doc:`read_restart <read_restart>` and
+
-:doc:`create_atoms <create_atoms>` commands for alternative methods.
+This is one of 3 ways to specify the simulation box: see the
-Also see the explanation of the :doc:`-restart command-line switch
+:doc:`create_box <create_box>` and :doc:`read_restart <read_restart>`
-<Run_options>` which can convert a restart file to a data file.
+and commands for alternative methods.  It is also one of 3 ways to
+specify initial atom coordinates: see the :doc:`create_atoms
+<create_atoms>` and :doc:`read_restart <read_restart>` and commands
+for alternative methods.  Also see the explanation of the
+:doc:`-restart command-line switch <Run_options>` which can convert a
+restart file to a data file.
 
 This command can be used multiple times to add new atoms and their
 properties to an existing system by using the *add*, *offset*, and
@@ -122,37 +127,55 @@ keyword must be used.
 
 .. note::
 
-   The simulation box size (xlo to xhi, ylo to yhi, zlo to zhi) in
+   If the first read_data command defined an orthogonal or restricted
-   the new data file will be merged with the existing simulation box to
+   triclinic or general triclinic simulation box (see the sub-section
-   create a large enough box in each dimension to contain both the
+   below on header keywords), then subsequent data files must define
-   existing and new atoms.  Each box dimension never shrinks due to this
+   the same kind of simulation box.  For orthogonal boxes, the new box
-   merge operation, it only stays the same or grows. Care must be used if
+   can be a different size; see the next Note.  For a restricted
-   you are growing the existing simulation box in a periodic dimension.
+   triclinic box, the 3 new tilt factors ("xy xz yz" keyword) must
-   If there are existing atoms with bonds that straddle that periodic
+   have the same values as in the original data file.  For a general
-   boundary, then the atoms may become far apart if the box size grows.
+   triclinic box, the new avec, bvec, cvec, and "abc origin" keywords
-   This will separate the atoms in the bond, which can lead to "lost"
+   must have the same values in the original data file.  files.  Also
-   bond atoms or bad dynamics.
+   the *shift* keyword cannot be used in subsequent read_data commands
+   for a general triclinic box.
+
+.. note::
+
+   For orthogonal boxes, the simulation box size in the new data file
+   will be merged with the existing simulation box to create a large
+   enough box in each dimension to contain both the existing and new
+   atoms.  Each box dimension never shrinks due to this merge
+   operation, it only stays the same or grows.  Care must be used if
+   you are growing the existing simulation box in a periodic
+   dimension.  If there are existing atoms with bonds that straddle
+   that periodic boundary, then the atoms may become far apart if the
+   box size grows.  This will separate the atoms in the bond, which
+   can lead to "lost" bond atoms or bad dynamics.
 
 The three choices for the *add* argument affect how the atom IDs and
-molecule IDs of atoms in the data file are treated.  If *append* is
+molecule IDs of atoms in the data file are treated.
-specified, atoms in the data file are added to the current system,
+
-with their atom IDs reset so that an atom-ID = M in the data file
+If *append* is specified, atoms in the data file are added to the
-becomes atom-ID = N+M, where N is the largest atom ID in the current
+current system, with their atom IDs reset so that an atom-ID = M in
-system.  This rule is applied to all occurrences of atom IDs in the
+the data file becomes atom-ID = N+M, where N is the largest atom ID in
-data file, e.g. in the Velocity or Bonds section. This is also done
+the current system.  This rule is applied to all occurrences of atom
-for molecule IDs, if the atom style does support molecule IDs or
+IDs in the data file, e.g. in the Velocity or Bonds section. This is
-they are enabled via fix property/atom. If *IDoffset* is specified,
+also done for molecule IDs, if the atom style does support molecule
-then *IDoffset* is a numeric value is given, e.g. 1000, so that an
+IDs or they are enabled via fix property/atom.
-atom-ID = M in the data file becomes atom-ID = 1000+M. For systems
+
-with enabled molecule IDs, another numerical argument *MOLoffset*
+If *IDoffset* is specified, then *IDoffset* is a numeric value is
-is required representing the equivalent offset for molecule IDs.
+given, e.g. 1000, so that an atom-ID = M in the data file becomes
-If *merge* is specified, the data file atoms
+atom-ID = 1000+M. For systems with enabled molecule IDs, another
-are added to the current system without changing their IDs.  They are
+numerical argument *MOLoffset* is required representing the equivalent
-assumed to merge (without duplication) with the currently defined
+offset for molecule IDs.
-atoms.  It is up to you to ensure there are no multiply defined atom
+
-IDs, as LAMMPS only performs an incomplete check that this is the case
+If *merge* is specified, the data file atoms are added to the current
-by ensuring the resulting max atom-ID >= the number of atoms. For
+system without changing their IDs.  They are assumed to merge (without
-molecule IDs, there is no check done at all.
+duplication) with the currently defined atoms.  It is up to you to
+ensure there are no multiply defined atom IDs, as LAMMPS only performs
+an incomplete check that this is the case by ensuring the resulting
+max atom-ID >= the number of atoms. For molecule IDs, there is no
+check done at all.
 
 The *offset* and *shift* keywords can only be used if the *add*
 keyword is also specified.
@@ -288,13 +311,16 @@ Format of the header of a data file
 """""""""""""""""""""""""""""""""""
 
 These are the recognized header keywords.  Header lines can come in
-any order.  The value(s) are read from the beginning of the line.
+any order.  Each keyword takes a single value unless noted in this
+list.  The value(s) are read from the beginning of the line.
 Thus the keyword *atoms* should be in a line like "1000 atoms"; the
 keyword *ylo yhi* should be in a line like "-10.0 10.0 ylo yhi"; the
 keyword *xy xz yz* should be in a line like "0.0 5.0 6.0 xy xz yz".
-All these settings have a default value of 0, except the lo/hi box
+
-size defaults are -0.5 and 0.5.  A line need only appear if the value
+All these settings have a default value of 0, except for the
-is different than the default.
+simulation box size settings; their defaults are explained below.  A
+keyword line need only appear if its value is different than the
+default.
 
 * *atoms* = # of atoms in system
 * *bonds* = # of bonds in system
@@ -315,81 +341,178 @@ is different than the default.
 * *lines* = # of line segments in system
 * *triangles* = # of triangles in system
 * *bodies* = # of bodies in system
-* *xlo xhi* = simulation box boundaries in x dimension
+* *xlo xhi* = simulation box boundaries in x dimension (2 values)
-* *ylo yhi* = simulation box boundaries in y dimension
+* *ylo yhi* = simulation box boundaries in y dimension (2 values)
-* *zlo zhi* = simulation box boundaries in z dimension
+* *zlo zhi* = simulation box boundaries in z dimension (2 values)
-* *xy xz yz* = simulation box tilt factors for triclinic system
+* *xy xz yz* = simulation box tilt factors for triclinic system (3 values)
+* *avec* = first edge vector of a general triclinic simulation box (3 values)
+* *bvec* = second edge vector of a general triclinic simulation box (3 values)
+* *cvec* = third edge vector of a general triclinic simulation box (3 values)
+* *abc origin* = origin of a general triclinic simulation box (3 values)
 
-The initial simulation box size is determined by the lo/hi settings.
+----------
-In any dimension, the system may be periodic or non-periodic; see the
-:doc:`boundary <boundary>` command.  When the simulation box is created
-it is also partitioned into a regular 3d grid of rectangular bricks,
-one per processor, based on the number of processors being used and
-the settings of the :doc:`processors <processors>` command.  The
-partitioning can later be changed by the :doc:`balance <balance>` or
-:doc:`fix balance <fix_balance>` commands.
 
-If the *xy xz yz* line does not appear, LAMMPS will set up an
+Header specification of the simulation box size and shape
-axis-aligned (orthogonal) simulation box.  If the line does appear,
+"""""""""""""""""""""""""""""""""""""""""""""""""""""""""
-LAMMPS creates a non-orthogonal simulation domain shaped as a
-parallelepiped with triclinic symmetry.  The parallelepiped has its
-"origin" at (xlo,ylo,zlo) and is defined by 3 edge vectors starting
-from the origin given by A = (xhi-xlo,0,0); B = (xy,yhi-ylo,0); C =
-(xz,yz,zhi-zlo).  *Xy,xz,yz* can be 0.0 or positive or negative values
-and are called "tilt factors" because they are the amount of
-displacement applied to faces of an originally orthogonal box to
-transform it into the parallelepiped.
 
-The tilt factors (xy,xz,yz) should not skew the box more than half the
+The last 8 keywords in the list of header keywords are for simulation
-distance of the corresponding parallel box length.  For example, if
+boxes of 3 kinds which LAMMPS supports:
-:math:`x_\text{lo} = 2` and :math:`x_\text{hi} = 12`, then the :math:`x`
-box length is 10 and the :math:`xy` tilt factor must be between
-:math:`-5` and :math:`5`.  Similarly, both :math:`xz` and :math:`yz`
-must be between :math:`-(x_\text{hi}-x_\text{lo})/2` and
-:math:`+(y_\text{hi}-y_\text{lo})/2`.  Note that this is not a
-limitation, since if the maximum tilt factor is 5 (as in this example),
-then configurations with tilt :math:`= \dots, -15`, :math:`-5`,
-:math:`5`, :math:`15`, :math:`25, \dots` are all geometrically
-equivalent.  Simulations with large tilt factors will run inefficiently,
-since they require more ghost atoms and thus more communication.  With
-very large tilt factors, LAMMPS will eventually produce incorrect
-trajectories and stop with errors due to lost atoms or similar.
 
-See the :doc:`Howto triclinic <Howto_triclinic>` page for a
+* orthogonal box = faces are perpendicular to the xyz coordinate axes
-geometric description of triclinic boxes, as defined by LAMMPS, and
+* restricted triclinic box = a parallelepiped defined by 3 edge vectors oriented in a constrained manner
-how to transform these parameters to and from other commonly used
+* general triclinic box = a parallelepiped defined by 3 arbitrary edge vectors
-triclinic representations.
 
-When a triclinic system is used, the simulation domain should normally
+For restricted and general triclinic boxes, see the
-be periodic in the dimension that the tilt is applied to, which is
+:doc:`Howto_triclinic <Howto_triclinic>` doc page for a fuller
-given by the second dimension of the tilt factor (e.g. y for xy tilt).
+description than is given here.
-This is so that pairs of atoms interacting across that boundary will
-have one of them shifted by the tilt factor.  Periodicity is set by
-the :doc:`boundary <boundary>` command.  For example, if the xy tilt
-factor is non-zero, then the y dimension should be periodic.
-Similarly, the z dimension should be periodic if xz or yz is non-zero.
-LAMMPS does not require this periodicity, but you may lose atoms if
-this is not the case.
 
-Also note that if your simulation will tilt the box, e.g. via the
+The units of the values for all 8 keywords in in distance units; see
-:doc:`fix deform <fix_deform>` command, the simulation box must be setup
+the :doc:`units <units>` command for details.
-to be triclinic, even if the tilt factors are initially 0.0.  You can
-also change an orthogonal box to a triclinic box or vice versa by using
-the :doc:`change box <change_box>` command with its *ortho* and
-*triclinic* options.
 
-For 2d simulations, the *zlo zhi* values should be set to bound the z
+For all 3 kinds of simulation boxes, the system may be periodic or
-coords for atoms that appear in the file; the default of -0.5 0.5 is
+non-periodic in any dimension; see the :doc:`boundary <boundary>`
-valid if all z coords are 0.0.  For 2d triclinic simulations, the xz
+command for details.
-and yz tilt factors must be 0.0.
+
+When the simulation box is created by the read_data command, it is
+also partitioned into a regular 3d grid of subdomains, one per
+processor, based on the number of processors being used and the
+settings of the :doc:`processors <processors>` command.  For each kind
+of simulation box the subdomains have the same shape as the simulation
+box, i.e. smaller orthogonal bricks for orthogonal boxes, smaller
+parallelepipeds for triclinic boxes.  The partitioning can later be
+changed by the :doc:`balance <balance>` or :doc:`fix balance
+<fix_balance>` commands.
+
+For an orthogonal box, only the *xlo xhi*, *ylo yhi*, *zlo zhi*
+keywords are used.  They define the extent of the simulation box in
+each dimension so that the resulting edge vectors of an orthogonal box
+are:
+
+* **A** = (xhi-xlo,0,0)
+* **B** = (0,yhi-ylo,0)
+* **C** = (0,0,zhi-zlo)
+
+The origin (lower left corner) of the orthogonal box is at
+(xlo,ylo,zlo).  The default values for these 3 keywords are -0.5 and
+0.5 for each lo/hi pair.  For a 2d simulation, the zlo and zhi values
+must straddle zero.  The default zlo/zhi values do this, so that
+keyword is not needed in 2d.
+
+For a restricted triclinic box, the *xy xz yz* keyword is used in
+addition to the *xlo xhi*, *ylo yhi*, *zlo zhi* keywords.  The three
+*xy,xz,yz* values can be 0.0 or positive or negative, and are called
+"tilt factors" because they are the amount of displacement applied to
+edges of faces of an orthogonal box to transform it into a restricted
+triclinic parallelepiped.
+
+The :doc:`Howto_triclinic <Howto_triclinic>` doc page discusses the
+tilt factors in detail and explains that the resulting edge vectors of
+a restricted triclinic box are:
+
+* **A** = (xhi-xlo,0,0)
+* **B** = (xy,yhi-ylo,0)
+* **C** = (xz,yz,zhi-zlo)
+
+This restricted form of edge vectors requires that **A** be in the
+direction of the x-axis, **B** be in the xy plane with its y-component
+in the +y direction, and **C** have its z-component in the +z
+direction.  The origin (lower left corner) of the restricted triclinic
+box is at (xlo,ylo,zlo).
+
+For a 2d simulation, the zlo and zhi values must straddle zero.  The
+default zlo/zhi values do this, so that keyword is not needed in 2d.
+The xz and yz values must also be zero in 2d.  The shape of the 2d
+restricted triclinic simulation box is effectively a parallelogram.
+
+.. note::
+
+   When a restricted triclinic box is used, the simulation domain
+   should normally be periodic in any dimensions that tilt is applied
+   to, which is given by the second dimension of the tilt factor
+   (e.g. y for xy tilt).  This is so that pairs of atoms interacting
+   across that boundary will have one of them shifted by the tilt
+   factor.  Periodicity is set by the :doc:`boundary <boundary>`
+   command which also describes the shifting by the tilt factor.  For
+   example, if the xy tilt factor is non-zero, then the y dimension
+   should be periodic.  Similarly, the z dimension should be periodic
+   if xz or yz is non-zero.  LAMMPS does not require this periodicity,
+   but you may lose atoms if this is not the case.
+
+.. note::
+
+   Normally, the specified tilt factors (xy,xz,yz) should not skew the
+   simulation box by more than half the distance of the corresponding
+   parallel box length for computational efficiency.  For example, if
+   :math:`x_\text{lo} = 2` and :math:`x_\text{hi} = 12`, then the
+   :math:`x` box length is 10 and the :math:`xy` tilt factor should be
+   between :math:`-5` and :math:`5`.  LAMMPS will issue a warning if
+   this is not the case.  See the last sub-section of the
+   :doc:`Howto_triclinic <Howto_triclinic>` doc page for more details.
+
+.. note::
+
+   If a simulation box is initially orthogonal, but will tilt during a
+   simulation, e.g. via the :doc:`fix deform <fix_deform>` command,
+   then the box should be defined as restricted triclinic with all 3
+   tilt factors = 0.0.  Alternatively, the :doc:`change box
+   <change_box>` command can be used to convert an orthogonal box to a
+   restricted triclinic box.
+
+For a general triclinic box, the *avec*, *bvec*, *cvec*, and *abc
+origin* keywords are used.  The *xlo xhi*, *ylo yhi*, *zlo zhi*, and
+*xy xz yz* keywords are NOT used.  The first 3 keywords define the 3
+edge vectors **A**, **B**, **C** of the general triclinic box.  They
+can be arbitrary vectors so long as they are distinct, non-zero, and
+not co-planar.  They must also define a right-handed system such that
+(**A** x **B**) points in the direction of **C**.  Note that a
+left-handed system can be converted to a right-handed system by simply
+swapping the order of any pair of the **A**, **B**, **C** vectors.
+The origin of the box (origin of the 3 edge vectors) is set by the
+*abc origin* keyword.
+
+The default values for these 4 keywords are as follows:
+
+* avec = (1,0,0)
+* bvec = (0,1,0)
+* cvec = (0,0,1)
+* abc origin = (0,0,0) for 3d, (0,0,-0.5) for 2d
+
+For 2d simulations, *cvec* = (0,0,1) is required, and the 3rd value of
+*abc origin* must be -0.5.  These are the default values, so the
+*cvec* keyword is not needed in 2d.
+
+.. note::
+
+   LAMMPS allows specification of general triclinic simulation boxes
+   as a convenience for users who may be converting data from
+   solid-state crystallographic representations or from DFT codes for
+   input to LAMMPS.  However, as explained on the
+   :doc:`Howto_triclinic <Howto_triclinic>` doc page, internally,
+   LAMMPS only uses restricted triclinic simulation boxes.  This means
+   the box and per-atom information (e.g. coordinates, velocities) in
+   the data file are converted (rotated) from general to restricted
+   triclinic form when the file is read.  Other sections of the data
+   file must also list their per-atom data appropriately if vector
+   quantities are specified. This requirement is explained below for
+   the relevant sections.  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 following explanations apply to all 3 kinds of simulation boxes:
+orthogonal, restricted triclinic, and general triclinic.
 
 If the system is periodic (in a dimension), then atom coordinates can
 be outside the bounds (in that dimension); they will be remapped (in a
-periodic sense) back inside the box.  Note that if the *add* option is
+periodic sense) back inside the box.  For triclinic boxes, periodicity
-being used to add atoms to a simulation box that already exists, this
+in x,y,z refers to the faces of the parallelepiped defined by the
-periodic remapping will be performed using simulation box bounds that
+**A**,**B**,**C** edge vectors of the simulation box.  See the
-are the union of the existing box and the box boundaries in the new
+:doc:`boundary <boundary>` command doc page for a fuller discussion.
-data file.
+
+Note that if the *add* option is being used to add atoms to a
+simulation box that already exists, this periodic remapping will be
+performed using simulation box bounds that are the union of the
+existing box and the box boundaries in the new data file.
 
 If the system is non-periodic (in a dimension), then an image flag for
 that direction has no meaning, since there cannot be periodic images
@@ -406,7 +529,6 @@ individually back into the principal unit cell in that direction.  This
 operation is equivalent to the behavior of the :doc:`change_box command
 <change_box>` when used to change periodicity.
 
-
 If those atoms with non-zero image flags are involved in bonded
 interactions, this reset can lead to undesired changes, when the image
 flag values differ between the atoms, i.e. the bonded interaction
@@ -421,73 +543,81 @@ needed, so that the image flag would be zero.
 
 .. note::
 
-   If the system is non-periodic (in a dimension), then all atoms in the
+   If the system is non-periodic (in a dimension), then all atoms in
-   data file must have coordinates (in that dimension) that are "greater
+   the data file must have coordinates (in that dimension) that are
-   than or equal to" the lo value and "less than or equal to" the hi
+   "greater than or equal to" the lo value and "less than or equal to"
-   value.  If the non-periodic dimension is of style "fixed" (see the
+   the hi value.  If the non-periodic dimension is of style "fixed"
-   :doc:`boundary <boundary>` command), then the atom coords must be
+   (see the :doc:`boundary <boundary>` command), then the atom coords
-   strictly "less than" the hi value, due to the way LAMMPS assign atoms
+   must be strictly "less than" the hi value, due to the way LAMMPS
-   to processors.  Note that you should not make the lo/hi values
+   assign atoms to processors.  Note that you should not make the
-   radically smaller/larger than the extent of the atoms.  For example,
+   lo/hi values radically smaller/larger than the extent of the atoms.
-   if your atoms extend from 0 to 50, you should not specify the box
+   For example, if atoms extend from 0 to 50, you should not specify
-   bounds as -10000 and 10000 unless you also use the :doc:`processors
+   the box bounds as -10000 and 10000 unless you also use the
-   command <processors>`.  This is because LAMMPS uses the specified box
+   :doc:`processors command <processors>`.  This is because LAMMPS
-   size to layout the 3d grid of processors.  A huge (mostly empty) box
+   uses the specified box size to layout the 3d grid of processors.  A
-   will be sub-optimal for performance when using "fixed" boundary
+   huge (mostly empty) box will be sub-optimal for performance when
-   conditions (see the :doc:`boundary <boundary>` command).  When using
+   using "fixed" boundary conditions (see the :doc:`boundary
-   "shrink-wrap" boundary conditions (see the :doc:`boundary <boundary>`
+   <boundary>` command).  When using "shrink-wrap" boundary conditions
-   command), a huge (mostly empty) box may cause a parallel simulation
+   (see the :doc:`boundary <boundary>` command), a huge (mostly empty)
-   to lose atoms when LAMMPS shrink-wraps the box around the atoms.  The
+   box may cause a parallel simulation to lose atoms when LAMMPS
-   read_data command will generate an error in this case.
+   shrink-wraps the box around the atoms.  The read_data command will
+   generate an error in this case.
+
+----------
+
+Meaning of other header keywords
+""""""""""""""""""""""""""""""""
 
 The "extra bond per atom" setting (angle, dihedral, improper) is only
 needed if new bonds (angles, dihedrals, impropers) will be added to
-the system when a simulation runs, e.g. by using the :doc:`fix bond/create <fix_bond_create>` command. Using this header flag
+the system when a simulation runs, e.g. by using the :doc:`fix
-is deprecated; please use the *extra/bond/per/atom* keyword (and
+bond/create <fix_bond_create>` command. Using this header flag is
+deprecated; please use the *extra/bond/per/atom* keyword (and
 correspondingly for angles, dihedrals and impropers) in the read_data
 command instead. Either will pre-allocate space in LAMMPS data
 structures for storing the new bonds (angles, dihedrals, impropers).
 
 The "extra special per atom" setting is typically only needed if new
-bonds/angles/etc will be added to the system, e.g. by using the :doc:`fix bond/create <fix_bond_create>` command.  Or if entire new molecules
+bonds/angles/etc will be added to the system, e.g. by using the
-will be added to the system, e.g. by using the
+:doc:`fix bond/create <fix_bond_create>` command.  Or if entire new
-:doc:`fix deposit <fix_deposit>` or :doc:`fix pour <fix_pour>` commands,
+molecules will be added to the system, e.g. by using the :doc:`fix
-which will have more special 1-2,1-3,1-4 neighbors than any other
+deposit <fix_deposit>` or :doc:`fix pour <fix_pour>` commands, which
-molecules defined in the data file.  Using this header flag is
+will have more special 1-2,1-3,1-4 neighbors than any other molecules
-deprecated; please use the *extra/special/per/atom* keyword instead.
+defined in the data file.  Using this header flag is deprecated;
-Using this setting will pre-allocate space in the LAMMPS data
+please use the *extra/special/per/atom* keyword instead.  Using this
-structures for storing these neighbors.  See the
+setting will pre-allocate space in the LAMMPS data structures for
-:doc:`special_bonds <special_bonds>` and :doc:`molecule <molecule>` doc
+storing these neighbors.  See the :doc:`special_bonds <special_bonds>`
-pages for more discussion of 1-2,1-3,1-4 neighbors.
+and :doc:`molecule <molecule>` doc pages for more discussion of
+1-2,1-3,1-4 neighbors.
 
 .. note::
 
-   All of the "extra" settings are only applied in the first data
+   All of the "extra" settings are only applied in the first data file
-   file read and when no simulation box has yet been created; as soon as
+   read and when no simulation box has yet been created; as soon as
    the simulation box is created (and read_data implies that), these
    settings are *locked* and cannot be changed anymore. Please see the
-   description of the *add* keyword above for reading multiple data files.
+   description of the *add* keyword above for reading multiple data
-   If they appear in later data files, they are ignored.
+   files.  If they appear in later data files, they are ignored.
 
 The "ellipsoids" and "lines" and "triangles" and "bodies" settings are
-only used with :doc:`atom_style ellipsoid or line or tri or body <atom_style>` and specify how many of the atoms are
+only used with :doc:`atom_style ellipsoid or line or tri or body
-finite-size ellipsoids or lines or triangles or bodies; the remainder
+<atom_style>` and specify how many of the atoms are finite-size
-are point particles.  See the discussion of ellipsoidflag and the
+ellipsoids or lines or triangles or bodies; the remainder are point
-*Ellipsoids* section below.  See the discussion of lineflag and the
+particles.  See the discussion of ellipsoidflag and the *Ellipsoids*
-*Lines* section below.  See the discussion of triangleflag and the
+section below.  See the discussion of lineflag and the *Lines* section
-*Triangles* section below.  See the discussion of bodyflag and the
+below.  See the discussion of triangleflag and the *Triangles* section
-*Bodies* section below.
+below.  See the discussion of bodyflag and the *Bodies* section below.
 
 .. note::
 
-   For :doc:`atom_style template <atom_style>`, the molecular
+   For :doc:`atom_style template <atom_style>`, the molecular topology
-   topology (bonds,angles,etc) is contained in the molecule templates
+   (bonds,angles,etc) is contained in the molecule templates read-in
-   read-in by the :doc:`molecule <molecule>` command.  This means you
+   by the :doc:`molecule <molecule>` command.  This means you cannot
-   cannot set the *bonds*, *angles*, etc header keywords in the data
+   set the *bonds*, *angles*, etc header keywords in the data file,
-   file, nor can you define *Bonds*, *Angles*, etc sections as discussed
+   nor can you define *Bonds*, *Angles*, etc sections as discussed
    below.  You can set the *bond types*, *angle types*, etc header
-   keywords, though it is not necessary.  If specified, they must match
+   keywords, though it is not necessary.  If specified, they must
-   the maximum values defined in any of the template molecules.
+   match the maximum values defined in any of the template molecules.
 
 ----------
 
@@ -680,6 +810,19 @@ appended to it, which indicate which image of a periodic simulation
 box the atom is in.  These may be important to include for some kinds
 of analysis.
 
+.. note::
+
+   For orthogonal and restricted and general triclinic simulation
+   boxes, the atom coordinates (x,y,z) listed in this section should
+   be inside the corresponding simulation box.  For restricted
+   triclinic boxes that means the parallelepiped defined by the *xlo
+   xhi*, *ylo yhi*, *zlo zhi*, and *xy xz yz*, keywords.  For general
+   triclinic boxes that means the parallelepiped defined by the 3 edge
+   vectors and origin specified by the *avec*, *bvec*, *cvec*, and
+   *abc origin* header keywords.  See the discussion in the header
+   section above about how atom coordinates outside the simulation box
+   are (or are not) remapped to be inside the box.
+
 .. list-table::
 
    * - angle
@@ -690,10 +833,12 @@ of analysis.
      - atom-ID atom-type bodyflag mass x y z
    * - bond
      - atom-ID molecule-ID atom-type x y z
+   * - bpm/sphere
+     - atom-ID molecule-ID atom-type diameter density x y z
    * - charge
      - atom-ID atom-type q x y z
    * - dielectric
-     - atom-ID atom-type q x y z normx normy normz area ed em epsilon curvature
+     - atom-ID atom-type q x y z mux muy muz area ed em epsilon curvature
    * - dipole
      - atom-ID atom-type q x y z mux muy muz
    * - dpd
@@ -720,8 +865,6 @@ of analysis.
      - atom-ID atom-type rho esph cv x y z
    * - sphere
      - atom-ID atom-type diameter density x y z
-   * - bpm/sphere
-     - atom-ID molecule-ID atom-type diameter density x y z
    * - spin
      - atom-ID atom-type x y z spx spy spz sp
    * - tdpd
@@ -757,24 +900,42 @@ The per-atom values have these meanings and units, listed alphabetically:
 * lineflag = 1 for line segment particles, 0 for point or spherical particles
 * mass = mass of particle (mass units)
 * molecule-ID = integer ID of molecule the atom belongs to
-* mux,muy,muz = components of dipole moment of atom (dipole units)
+* mux,muy,muz = components of dipole moment of atom (dipole units) (see general triclinic note below)
 * q = charge on atom (charge units)
 * rho = density (need units) for SPH particles
 * sp = magnitude of magnetic spin of atom (Bohr magnetons)
-* spx,spy,spz = components of magnetic spin of atom (unit vector)
+* spx,spy,spz = components of magnetic spin of atom (unit vector) (see general triclinic note below)
 * template-atom = which atom within a template molecule the atom is
 * template-index = which molecule within the molecule template the atom is part of
 * theta = internal temperature of a DPD particle
 * triangleflag = 1 for triangular particles, 0 for point or spherical particles
 * volume = volume of Peridynamic particle (distance\^3 units)
 * x,y,z = coordinates of atom (distance units)
-* x0,y0,z0 = original (strain-free) coordinates of atom (distance units)
+* x0,y0,z0 = original (strain-free) coordinates of atom (distance
+  units) (see general triclinic note below)
 
 The units for these quantities depend on the unit style; see the
 :doc:`units <units>` command for details.
 
-For 2d simulations specify z as 0.0, or a value within the *zlo zhi*
+For 2d simulations, the atom coordinate z must be specified as 0.0.
-setting in the data file header.
+If the data file is created by another program, then z values for a 2d
+simulation can be within epsilon of 0.0, and LAMMPS will force them to
+zero.
+
+.. note::
+
+   If the data file defines a general triclinic box, then the
+   following per-atom values in the list above are per-atom vectors
+   which imply an orientation: (mux,muy,muz) and (spx,spy,spz).  This
+   means they should be specified consistent with the general
+   triclinic box and its orientation relative to the standard x,y,z
+   coordinate axes.  For example a dipole moment vector which will be
+   in the +x direction once LAMMPS converts from a general to
+   restricted triclinic box, should be specified in the data file in
+   the direction of the **A** edge vector.  Likewise the (x0,y0,z0)
+   per-atom strain-free coordinates should be inside the general
+   triclinic simulation box as explained in the note above.  See the
+   :doc:`Howto triclinic <Howto_triclinic>` doc page for more details.
 
 The atom-ID is used to identify the atom throughout the simulation and
 in dump files.  Normally, it is a unique value from 1 to Natoms for
@@ -922,9 +1083,8 @@ that use unwrapped coordinates internally are as follows:
 
 Atom velocities and other atom quantities not defined above are set to
 0.0 when the *Atoms* section is read.  Velocities can be set later by
-a *Velocities* section in the data file or by a
+a *Velocities* section in the data file or by a :doc:`velocity
-:doc:`velocity <velocity>` or :doc:`set <set>` command in the input
+<velocity>` or :doc:`set <set>` command in the input script.
-script.
 
 ----------
 
@@ -963,8 +1123,9 @@ the "bodies" keyword.
 
 Each body can have a variable number of integer and/or floating-point
 values.  The number and meaning of the values is defined by the body
-style, as described in the :doc:`Howto body <Howto_body>` doc page.  The
+style, as described in the :doc:`Howto body <Howto_body>` doc page.
-body style is given as an argument to the :doc:`atom_style body <atom_style>` command.
+The body style is given as an argument to the :doc:`atom_style body
+<atom_style>` command.
 
 The Ninteger and Ndouble values determine how many integer and
 floating-point values are specified for this particle.  Ninteger and
@@ -1179,10 +1340,10 @@ and a general discussion of how type labels can be used.
 
        12 1 2 1 1 0 0 0
 
-The *Ellipsoids* section must appear if :doc:`atom_style ellipsoid <atom_style>` is used and any atoms are listed in the
+The *Ellipsoids* section must appear if :doc:`atom_style ellipsoid
-*Atoms* section with an ellipsoidflag = 1.  The number of ellipsoids
+<atom_style>` is used and any atoms are listed in the *Atoms* section
-should be specified in the header section via the "ellipsoids"
+with an ellipsoidflag = 1.  The number of ellipsoids should be
-keyword.
+specified in the header section via the "ellipsoids" keyword.
 
 The 3 shape values specify the 3 diameters or aspect ratios of a
 finite-size ellipsoidal particle, when it is oriented along the 3
@@ -1200,6 +1361,12 @@ the quaternion that represents its new orientation is given by
 LAMMPS normalizes each atom's quaternion in case (a,b,c) is not
 specified as a unit vector.
 
+If the data file defines a general triclinic box, then the quaternion
+for each ellipsoid should be specified for its orientation relative to
+the standard x,y,z coordinate axes.  When the system is converted to a
+restricted triclinic box, the ellipsoid quaternions will be altered to
+reflect the new orientation of the ellipsoid.
+
 The *Ellipsoids* section must appear after the *Atoms* section.
 
 ----------
@@ -1316,13 +1483,24 @@ is used and any atoms are listed in the *Atoms* section with a
 lineflag = 1.  The number of lines should be specified in the header
 section via the "lines" keyword.
 
-The 2 end points are the end points of the line segment.  The ordering
+The 2 end points are the end points of the line segment.  They should
-of the 2 points should be such that using a right-hand rule to cross
+be values close to the center point of the line segment specified in
-the line segment with a unit vector in the +z direction, gives an
+the Atoms section of the data file, even if individual end points are
-"outward" normal vector perpendicular to the line segment.
+outside the simulation box.
+
+The ordering of the 2 points should be such that using a right-hand
+rule to cross the line segment with a unit vector in the +z direction,
+gives an "outward" normal vector perpendicular to the line segment.
 I.e. normal = (c2-c1) x (0,0,1).  This orientation may be important
 for defining some interactions.
 
+If the data file defines a general triclinic box, then the x1,y1 and
+x2,y2 values for each line segment should be specified for its
+orientation relative to the standard x,y,z coordinate axes.  When the
+system is converted to a restricted triclinic box, the x1,y1,x2,y2
+values will be altered to reflect the new orientation of the line
+segment.
+
 The *Lines* section must appear after the *Atoms* section.
 
 ----------
@@ -1444,15 +1622,27 @@ via the :doc:`pair_coeff <pair_coeff>` command in the input script.
 
        12 0.0 0.0 0.0 2.0 0.0 1.0 0.0 2.0 1.0
 
-The *Triangles* section must appear if :doc:`atom_style tri <atom_style>` is used and any atoms are listed in the *Atoms*
+The *Triangles* section must appear if :doc:`atom_style tri
-section with a triangleflag = 1.  The number of lines should be
+<atom_style>` is used and any atoms are listed in the *Atoms* section
-specified in the header section via the "triangles" keyword.
+with a triangleflag = 1.  The number of lines should be specified in
+the header section via the "triangles" keyword.
 
-The 3 corner points are the corner points of the triangle.  The
+The 3 corner points are the corner points of the triangle.  They
-ordering of the 3 points should be such that using a right-hand rule
+should be values close to the center point of the triangle specified
-to go from point1 to point2 to point3 gives an "outward" normal vector
+in the Atoms section of the data file, even if individual corner
-to the face of the triangle.  I.e. normal = (c2-c1) x (c3-c1).  This
+points are outside the simulation box.
-orientation may be important for defining some interactions.
+
+The ordering of the 3 points should be such that using a right-hand
+rule to go from point1 to point2 to point3 gives an "outward" normal
+vector to the face of the triangle.  I.e. normal = (c2-c1) x (c3-c1).
+This orientation may be important for defining some interactions.
+
+If the data file defines a general triclinic box, then the x1,y1,z1
+and x2,y2,z2 and x3,y3,z3 values for each triangle should be specified
+for its orientation relative to the standard x,y,z coordinate axes.
+When the system is converted to a restricted triclinic box, the
+x1,y1,z1,x2,y2,z2,x3,y3,z3 values will be altered to reflect the new
+orientation of the triangle.
 
 The *Triangles* section must appear after the *Atoms* section.
 
@@ -1493,6 +1683,12 @@ Vx, vy, vz, and ervel are in :doc:`units <units>` of velocity.  Lx, ly,
 lz are in units of angular momentum (distance-velocity-mass).  Wx, Wy,
 Wz are in units of angular velocity (radians/time).
 
+If the data file defines a general triclinic box, then each of the 3
+vectors (translational velocity, angular momentum, angular velocity)
+should be specified for the rotated coordinate axes of the general
+triclinic box.  See the :doc:`Howto triclinic <Howto_triclinic>` doc
+page for more details.
+
 For atom_style hybrid, following the 4 initial values (ID,vx,vy,vz),
 specific values for each sub-style must be listed.  The order of the
 sub-styles is the same as they were listed in the
@@ -1513,8 +1709,8 @@ fields:
 
    atom-ID vx vy vz ervel wx wy wz
 
-Translational velocities can also be set by the
+Translational velocities can also be (re)set by the :doc:`velocity
-:doc:`velocity <velocity>` command in the input script.
+<velocity>` command in the input script.
 
 ----------
 

doc/src/replicate.rst

@@ -8,56 +8,118 @@ Syntax
 
 .. code-block:: LAMMPS
 
-   replicate nx ny nz *keyword*
+   replicate nx ny nz keyword ...
 
 nx,ny,nz = replication factors in each dimension
 
-* optional *keyword* = *bbox*
+* zero or more keywords may be appended
+* keyword = *bbox* or *bond/periodic*
 
   .. parsed-literal::
 
-       *bbox* = only check atoms in replicas that overlap with a processor's subdomain
+       *bbox* = use a bounding-box algorithm which is faster for large proc counts
+       *bond/periodic* = use an algorithm that correctly replicates periodic bond loops
 
 Examples
 """"""""
 
+For examples of replicating simple linear polymer chains (periodic or
+non-periodic) or periodic carbon nanotubes, see examples/replicate.
+
 .. code-block:: LAMMPS
 
    replicate 2 3 2
+   replicate 2 3 2 bbox
+   replicate 2 3 2 bond/periodic
 
 Description
 """""""""""
 
-Replicate the current simulation one or more times in each dimension.
+Replicate the current system one or more times in each dimension.  For
-For example, replication factors of 2,2,2 will create a simulation
+example, replication factors of 2,2,2 will create a simulation with 8x
-with 8x as many atoms by doubling the simulation domain in each
+as many atoms by doubling the size of the simulation box in each
-dimension.  A replication factor of 1 in a dimension leaves the
+dimension.  A replication factor of 1 leaves the simulation domain
-simulation domain unchanged.  When the new simulation box is created
+unchanged in that dimension.
-it is also partitioned into a regular 3d grid of rectangular bricks,
-one per processor, based on the number of processors being used and
-the settings of the :doc:`processors <processors>` command.  The
-partitioning can later be changed by the :doc:`balance <balance>` or
-:doc:`fix balance <fix_balance>` commands.
 
-All properties of the atoms are replicated, including their
+When the new simulation box is created it is partitioned into a
-velocities, which may or may not be desirable.  New atom IDs are
+regular 3d grid of rectangular bricks, one per processor, based on the
-assigned to new atoms, as are molecule IDs.  Bonds and other topology
+number of processors being used and the settings of the
-interactions are created between pairs of new atoms as well as between
+:doc:`processors <processors>` command.  The partitioning can be
-old and new atoms.  This is done by using the image flag for each atom
+changed by subsequent :doc:`balance <balance>` or :doc:`fix balance
-to "unwrap" it out of the periodic box before replicating it.
+<fix_balance>` commands.
 
-This means that any molecular bond you specify in the original data
+All properties of each atom are replicated (except per-atom fix data,
-file that crosses a periodic boundary should be between two atoms with
+see the Restrictions section below).  This includes their velocities,
-image flags that differ by 1.  This will allow the bond to be
+which may or may not be desirable.  New atom IDs are assigned to new
-unwrapped appropriately.
+atoms, as are new molecule IDs.  Bonds and other topology interactions
+are created between pairs of new atoms as well as between old and new
+atoms.
 
-The optional keyword *bbox* uses a bounding box to only check atoms in
+.. note::
-replicas that overlap with a processor's subdomain when assigning
+
-atoms to processors.  It typically results in a substantial speedup
+   The bond discussion which follows only refers to models with
-when using the replicate command on a large number of processors.  It
+   permanent covalent bonds typically defined in LAMMPS via a data
-does require temporary use of more memory, specifically that each
+   file.  It is not relevant to systems modeled with many-body
-processor can store all atoms in the entire system before it is
+   potentials which can define bonds on-the-fly, based on the current
-replicated.
+   positions of nearby atoms, e.g. models using the :doc:`AIREBO
+   <pair_airebo>` or :doc:`ReaxFF <pair_reaxff>` potentials.
+
+If the *bond/periodic* keyword is not specified, bond replication is
+done by using the image flag for each atom to "unwrap" it out of the
+periodic box before replicating it.  After replication is performed,
+atoms outside the new periodic box are wrapped back into it.  This
+assigns correct images flags to all atoms in the system.  For this to
+work, all original atoms in the original simulation box must have
+consistent image flags.  This means that if two atoms have a bond
+between them which crosses a periodic boundary, their respective image
+flags will differ by 1 in that dimension.
+
+Image flag consistency is not possible if a system has a periodic bond
+loop, meaning there is a chain of bonds which crosses an entire
+dimension and re-connects to itself across a periodic boundary.  In
+this case you MUST use the *bond/periodic* keyword to correctly
+replicate the system.  This option zeroes the image flags for all
+atoms and uses a different algorithm to find new (nearby) bond
+neighbors in the replicated system.  In the final replicated system
+all image flags are zero (in each dimension).
+
+.. note::
+
+   LAMMPS does not check for image flag consistency before performing
+   the replication (it does issue a warning about this before a
+   simulation is run).  If the original image flags are inconsistent,
+   the replicated system will also have inconsistent image flags, but
+   will otherwise be correctly replicated.  This is NOT the case if
+   there is a periodic bond loop.  See the next note.
+
+.. note::
+
+   LAMMPS does not check for periodic bond loops.  If you use the
+   *bond/periodic* keyword for a system without periodic bond loops,
+   the system will be correctly replicated, but image flag information
+   will be lost (which may or may not be important to your model).  If
+   you do not use the *bond/periodic* keyword for a system with
+   periodic bond loops, the replicated system will have invalid bonds
+   (typically very long), resulting in bad dynamics.
+
+If possible, the *bbox* keyword should be used when running on a large
+number of processors, as it can result in a substantial speed-up for
+the replication operation.  It uses a bounding box to only check atoms
+in replicas that overlap with each processor's new subdomain when
+assigning atoms to processors.  It also preserves image flag
+information.  The only drawback to the *bbox* option is that it
+requires a temporary use of more memory.  Each processor must be able
+to store all atoms (and their per-atom data) in the original system,
+before it is replicated.
+
+.. note::
+
+  The algorithm used by the *bond/periodic* keyword builds on the
+  algorithm used by the *bbox* keyword and thus has the same memory
+  requirements.  If you specify only the *bond/peridoic* keyword it
+  will internally set the *bbox* keyword as well.
+
+----------
 
 Restrictions
 """"""""""""
@@ -65,49 +127,30 @@ Restrictions
 A 2d simulation cannot be replicated in the z dimension.
 
 If a simulation is non-periodic in a dimension, care should be used
-when replicating it in that dimension, as it may put atoms nearly on
+when replicating it in that dimension, as it may generate atoms nearly
-top of each other.
+on top of each other.
-
-.. note::
-
-   You cannot use the replicate command on a system which has a
-   molecule that spans the box and is bonded to itself across a periodic
-   boundary, so that the molecule is effectively a loop.  A simple
-   example would be a linear polymer chain that spans the simulation box
-   and bonds back to itself across the periodic boundary.  More realistic
-   examples would be a CNT (meant to be an infinitely long CNT) or a
-   graphene sheet or a bulk periodic crystal where there are explicit
-   bonds specified between near neighbors.  (Note that this only applies
-   to systems that have permanent bonds as specified in the data file.  A
-   CNT that is just atoms modeled with the :doc:`AIREBO potential <pair_airebo>` has no such permanent bonds, so it can be
-   replicated.)  The reason replication does not work with those systems
-   is that the image flag settings described above cannot be made
-   consistent.  I.e. it is not possible to define images flags so that
-   when every pair of bonded atoms is unwrapped (using the image flags),
-   they will be close to each other.  The only way the replicate command
-   could work in this scenario is for it to break a bond, insert more
-   atoms, and re-connect the loop for the larger simulation box.  But it
-   is not clever enough to do this.  So you will have to construct a
-   larger version of your molecule as a pre-processing step and input a
-   new data file to LAMMPS.
 
 If the current simulation was read in from a restart file (before a
-run is performed), there must not be any fix information stored in
+run is performed), there must not be any fix information stored in the
-the file for individual atoms.  Similarly, no fixes can be defined at
+file for individual atoms.  Similarly, no fixes can be defined at the
-the time the replicate command is used that require vectors of atom
+time the replicate command is used that require vectors of atom
 information to be stored.  This is because the replicate command does
 not know how to replicate that information for new atoms it creates.
-To work around this restriction, restart files may be converted into
+
-data files and fixes may be undefined via the :doc:`unfix <unfix>`
+To work around this restriction two options are possible.  (1) Fixes
-command before and redefined after the replicate command.
+which use the stored data in the restart file can be defined before
+replication and then deleted via the :doc:`unfix <unfix>` command and
+re-defined after it.  Or (2) the restart file can be converted to a
+data file (which deletes the stored fix information) and fixes defined
+after the replicate command.  In both these scenarios, the per-atom
+fix information in the restart file is lost.
 
 Related commands
 """"""""""""""""
 
 none
 
-
 Default
 """""""
 
-none
+No settings for using the *bbox* or *bond/periodic* algorithms.

doc/src/thermo_modify.rst

@@ -11,7 +11,7 @@ Syntax
    thermo_modify keyword value ...
 
 * one or more keyword/value pairs may be listed
-* keyword = *lost* or *lost/bond* or *warn* or *norm* or *flush* or *line* or *colname* or *format* or *temp* or *press*
+* keyword = *lost* or *lost/bond* or *warn* or *norm* or *flush* or *line* or *colname* or *format* or *temp* or *press* or *triclinic/general*
 
   .. parsed-literal::
 
@@ -32,6 +32,8 @@ Syntax
               *or* a thermo keyword or reference to compute, fix, property or variable.
        *temp* value = compute ID that calculates a temperature
        *press* value = compute ID that calculates a pressure
+       *triclinic/general* arg = *yes* or *no*
+
 
 Examples
 """"""""
@@ -240,6 +242,19 @@ command, thermo output uses a default compute for pressure with ID =
    keyword, then the new pressure compute specified by the *press*
    keyword will be unaffected by the *temp* setting.
 
+The *triclinic/general* keyword can only be used with a value of *yes*
+if the simulation box was created as a general triclinic box.  See the
+:doc:`Howto_triclinic <Howto_triclinic>` doc page for a detailed
+explanation of orthogonal, restricted triclinic, and general triclinic
+simulation boxes.
+
+If this keyword is *yes*, the output of the simulation box edge
+vectors and the pressure tensor components for the system are
+affected.  These are specified by the *avec,bvec,cvec* and
+*pxx,pyy,pzz,pxy,pxz,pyz* keywords of the :doc:`thermo_style
+<thermo_style>` command.  See the :doc:`thermo_style <thermo_style>`
+doc page for details.
+
 Restrictions
 """"""""""""
 none
@@ -253,8 +268,9 @@ Default
 """""""
 
 The option defaults are lost = error, warn = 100, norm = yes for unit
-style of *lj*, norm = no for unit style of *real* and *metal*,
+style of *lj*, norm = no for unit style of *real* and *metal*, flush =
-flush = no, and temp/press = compute IDs defined by thermo_style.
+no, temp/press = compute IDs defined by thermo_style, and
+triclinic/general = no.
 
 The defaults for the line and format options depend on the thermo style.
 For styles "one" and "custom", the line and format defaults are "one",

doc/src/thermo_style.rst

@@ -25,12 +25,18 @@ Syntax
                              evdwl, ecoul, epair, ebond, eangle, edihed, eimp,
                              emol, elong, etail,
                              enthalpy, ecouple, econserve,
-                             vol, density, lx, ly, lz, xlo, xhi, ylo, yhi, zlo, zhi,
+                             vol, density,
-                             xy, xz, yz, xlat, ylat, zlat,
+                             xlo, xhi, ylo, yhi, zlo, zhi,
-                             bonds, angles, dihedrals, impropers,
+                             xy, xz, yz,
-                             pxx, pyy, pzz, pxy, pxz, pyz,
+                             avecx, avecy, avecz,
-                             fmax, fnorm, nbuild, ndanger,
+                             bvecx, bvecy, bvecz,
+                             cvecx, cvecy, cvecz,
+                             lx, ly, lz,
+                             xlat, ylat, zlat,
                              cella, cellb, cellc, cellalpha, cellbeta, cellgamma,
+                             pxx, pyy, pzz, pxy, pxz, pyz,
+                             bonds, angles, dihedrals, impropers,
+                             fmax, fnorm, nbuild, ndanger,
                              c_ID, c_ID[I], c_ID[I][J],
                              f_ID, f_ID[I], f_ID[I][J],
                              v_name, v_name[I]
@@ -66,18 +72,21 @@ Syntax
            econserve = pe + ke + ecouple = etotal + ecouple
            vol = volume
            density = mass density of system
-           lx,ly,lz = box lengths in x,y,z
            xlo,xhi,ylo,yhi,zlo,zhi = box boundaries
-           xy,xz,yz = box tilt for triclinic (non-orthogonal) simulation boxes
+           xy,xz,yz = box tilt for restricted triclinic (non-orthogonal) simulation boxes
+           avecx,avecy,avecz = components of edge vector A of the simulation box
+           bvecx,bvecy,bvecz = components of edge vector B of the simulation box
+           cvecx,cvecy,cvecz = components of edge vector C of the simulation box
+           lx,ly,lz = box lengths in x,y,z
            xlat,ylat,zlat = lattice spacings as calculated by :doc:`lattice <lattice>` command
-           bonds,angles,dihedrals,impropers = # of these interactions defined
+           cella,cellb,cellc = periodic cell lattice constants a,b,c
+           cellalpha, cellbeta, cellgamma = periodic cell angles alpha,beta,gamma
            pxx,pyy,pzz,pxy,pxz,pyz = 6 components of pressure tensor
+           bonds,angles,dihedrals,impropers = # of these interactions defined
            fmax = max component of force on any atom in any dimension
            fnorm = length of force vector for all atoms
            nbuild = # of neighbor list builds
            ndanger = # of dangerous neighbor list builds
-           cella,cellb,cellc = periodic cell lattice constants a,b,c
-           cellalpha, cellbeta, cellgamma = periodic cell angles alpha,beta,gamma
            c_ID = global scalar value calculated by a compute with ID
            c_ID[I] = Ith component of global vector calculated by a compute with ID, I can include wildcard (see below)
            c_ID[I][J] = I,J component of global array calculated by a compute with ID
@@ -102,8 +111,11 @@ Examples
 Description
 """""""""""
 
-Set the style and content for printing thermodynamic data to the screen
+Set the style and content for printing thermodynamic data to the
-and log files.
+screen and log files.  The units for each column of output
+corresponding to the list of keywords is determined by the :doc:`units
+<units>` command for the simulation.  E.g. energies will be in energy
+units, temperature in temperature units, pressure in pressure units.
 
 Style *one* prints a single line of thermodynamic info that is the
 equivalent of "thermo_style custom step temp epair emol etotal press".
@@ -245,7 +257,7 @@ and *pxx*, *pyy*, etc.
 ----------
 
 Here is more information on other keywords whose meaning may not be
-clear:
+clear.
 
 The *step*, *elapsed*, and *elaplong* keywords refer to timestep
 count.  *Step* is the current timestep, or iteration count when a
@@ -319,6 +331,63 @@ thermostatting or barostatting to their coupling reservoirs -- that is,
 the NVT, NPH, or NPT ensembles, the *econserve* quantity should remain
 constant over time even though *etotal* may change.
 
+In LAMMPS, the simulation box can be defined as orthogonal or
+triclinic (non-orthogonal).  See the :doc:`Howto_triclinic
+<Howto_triclinic>` doc page for a detailed explanation of orthogonal,
+restricted triclinic, and general triclinic simulation boxes and how
+LAMMPS rotates a general triclinic box to be restricted triclinic
+internally.
+
+The *lx*, *ly*, *lz* keywords are the extent of the simulation box in
+each dimension.  The *xlo*, *xhi*, *ylo*, *yhi*, *zlo*, *zhi* keywords
+are the lower and upper bounds of the simulation box in each dimension.
+I.e. *lx* = *xhi* - *xlo*).  These 9 values are the same for all 3 kinds
+of boxes.  I.e. for a restricted triclinic box, they are the values as
+if the box were not tilted.  For a general triclinic box, they are the
+values after it is internally rotated to be a restricted triclinic box.
+
+The *xy*, *xz*, *yz* are the current tilt factors for a triclinic box.
+They are the same for restricted and general triclinic boxes.
+
+The *avecx*, *avecy*, *avecz*, *bvecx*, *bvecy*, *bvecz*, *cvecx*,
+*cvecy*, *cvecz* are the components of the 3 edge vectors of the
+current general simulation box.  If it is an orthogonal box the
+vectors are along the x, y, z coordinate axes.  If it is a restricted
+triclinic box, the **A** vector is along the x axis, the **B** vector
+is in the xy plane with a +y coordinate, and the **C** vector has a +z
+coordinate, as explained on the :doc:`Howto_triclinic
+<Howto_triclinic>` doc page.  If the :doc:`thermo_modify
+triclinic/general <thermo_modify>` option is set then they are the
+**A**, **B**, **C** vector which define the general triclinic box.
+
+The *cella*, *cellb*, *cellc*, *cellalpha*, *cellbeta*, *cellgamma*
+keywords correspond to the usual crystallographic quantities that
+define the periodic simulation box of a crystalline system.  See the
+:doc:`Howto triclinic <Howto_triclinic>` page for a precise definition
+of these quantities in terms of the LAMMPS representation of a
+restricted triclinic simulation box via *lx*, *ly*, *lz*, *yz*, *xz*,
+*xy*\ .
+
+The *pxx,pyy,pzz,pxy,pxz,pyz* keywords are the 6 components of the
+symmetric pressure tensor for the system.  See the :doc:`compute
+pressure <compute_pressure>` command doc page for details of how it is
+calculated.
+
+If the :doc:`thermo_modify triclinic/general <thermo_modify>` option
+is set then the 6 components will be output as values consistent with
+the orientation of the general triclinic box relative to the standard
+xyz coordinate axes.  If this keyword is not used, the values will be
+consistent with the orientation of the restricted triclinic box (which
+aligns with the xyz coordinate axes).  As explained on the
+:doc:`Howto_triclinic <Howto_triclinic>` doc page, even if the
+simulation box is created as a general triclinic box, internally
+LAMMPS uses a restricted triclinic box.
+
+Note that because the pressure tensor components are computed using
+force vectors and atom coordinates, both of which are rotated in the
+general versus restricted triclinic representation, the values will
+typically be different for the two cases.
+
 The *fmax* and *fnorm* keywords are useful for monitoring the progress
 of an :doc:`energy minimization <minimize>`.  The *fmax* keyword
 calculates the maximum force in any dimension on any atom in the
@@ -338,14 +407,6 @@ to reduce the delay factor to ensure no force interactions are missed
 by atoms moving beyond the neighbor skin distance before a rebuild
 takes place.
 
-The keywords *cella*, *cellb*, *cellc*, *cellalpha*,
-*cellbeta*, *cellgamma*, correspond to the usual crystallographic
-quantities that define the periodic unit cell of a crystal.  See the
-:doc:`Howto triclinic <Howto_triclinic>` page for a geometric
-description of triclinic periodic cells, including a precise
-definition of these quantities in terms of the internal LAMMPS cell
-dimensions *lx*, *ly*, *lz*, *yz*, *xz*, *xy*\ .
-
 ----------
 
 For output values from a compute or fix or variable, the bracketed

doc/src/variable.rst

@@ -279,9 +279,9 @@ This means the variable can then be evaluated as many times as desired
 and will return those values.  There are two ways to cause the next
 set of per-atom values from the file to be read: use the
 :doc:`next <next>` command or the next() function in an atom-style
-variable, as discussed below.  Unlike most variable styles
+variable, as discussed below.  Unlike most variable styles, which
-atomfile-style variables are **deleted** during a :doc:`clear <clear>`
+remain defined, atomfile-style variables are **deleted** during a
-command.
+:doc:`clear <clear>` command.
 
 The rules for formatting the file are as follows.  Each time a set of
 per-atom values is read, a non-blank line is searched for in the file.
@@ -289,23 +289,37 @@ The file is read line by line but only up to 254 characters are used.
 The rest are ignored.  A comment character "#" can be used anywhere
 on a line and all text following and the "#" character are ignored;
 text starting with the comment character is stripped.  Blank lines
-are skipped.  The first "word" of a non-blank line, delimited by
+are skipped.  The first non-blank line is expected to contain a single
-white-space, is read as the count N of per-atom lines to immediately
+integer number as the count *N* of per-atom lines to follow.  *N* can
-follow.  N can be the total number of atoms in the system, or only a
+be the total number of atoms in the system or less, indicating that data
-subset.  The next N lines have the following format
+for a subset is read.  The next N lines must consist of two numbers,
-
+the atom-ID of the atom for which a value is set followed by a floating
-.. parsed-literal::
+point number with the value.  The atom-IDs may be listed in any order.
-
-   ID value
-
-where ID is an atom ID and value is the per-atom numeric value that
-will be assigned to that atom.  IDs can be listed in any order.
 
 .. note::
 
-   Every time a set of per-atom lines is read, the value for all
+   Every time a set of per-atom lines is read, the value of the atomfile
-   atoms is first set to 0.0.  Thus values for atoms whose ID does not
+   variable for **all** atoms is first initialized to 0.0.  Thus values
-   appear in the set, will remain 0.0.
+   for atoms whose ID do not appear in the set in the file will remain
+   at 0.0.
+
+Below is a small example for the atomfile variable file format:
+
+ .. parsed-literal::
+
+   # first set
+   4
+   # atom-ID value
+   3 1
+   4 -4
+   1 0.5
+   2 -0.5
+
+   # second set
+   2
+
+   2  1.0
+   4 -1.0
 
 ----------
 
@@ -1174,12 +1188,17 @@ custom atom properties are the same; just replace the leading "i" with
 
 +--------+---------------+------------------------------------------+
 | equal  | i_name[I]     | element of per-atom vector (I = atom ID) |
++--------+---------------+------------------------------------------+
 | equal  | i2_name[I][J] | element of per-atom array (I = atom ID)  |
 +--------+---------------+------------------------------------------+
++--------+---------------+------------------------------------------+
 | vector | i_name[I]     | element of per-atom vector (I = atom ID) |
++--------+---------------+------------------------------------------+
 | vector | i2_name[I][J] | element of per-atom array (I = atom ID)  |
 +--------+---------------+------------------------------------------+
++--------+---------------+------------------------------------------+
 | atom   | i_name        | per-atom vector                          |
++--------+---------------+------------------------------------------+
 | atom   | i2_name[I]    | column of per-atom array                 |
 +--------+---------------+------------------------------------------+
 
@@ -1222,15 +1241,23 @@ table:
 
 +--------+------------+------------------------------------------+
 | equal  | c_ID       | global scalar                            |
++--------+------------+------------------------------------------+
 | equal  | c_ID[I]    | element of global vector                 |
++--------+------------+------------------------------------------+
 | equal  | c_ID[I][J] | element of global array                  |
++--------+------------+------------------------------------------+
 | equal  | C_ID[I]    | element of per-atom vector (I = atom ID) |
++--------+------------+------------------------------------------+
 | equal  | C_ID[I][J] | element of per-atom array (I = atom ID)  |
 +--------+------------+------------------------------------------+
++--------+------------+------------------------------------------+
 | vector | c_ID       | global vector                            |
++--------+------------+------------------------------------------+
 | vector | c_ID[I]    | column of global array                   |
 +--------+------------+------------------------------------------+
++--------+------------+------------------------------------------+
 | atom   | c_ID       | per-atom vector                          |
++--------+------------+------------------------------------------+
 | atom   | c_ID[I]    | column of per-atom array                 |
 +--------+------------+------------------------------------------+
 
@@ -1286,15 +1313,23 @@ and atom-style variables are listed in the following table:
 
 +--------+------------+------------------------------------------+
 | equal  | f_ID       | global scalar                            |
++--------+------------+------------------------------------------+
 | equal  | f_ID[I]    | element of global vector                 |
++--------+------------+------------------------------------------+
 | equal  | f_ID[I][J] | element of global array                  |
++--------+------------+------------------------------------------+
 | equal  | F_ID[I]    | element of per-atom vector (I = atom ID) |
++--------+------------+------------------------------------------+
 | equal  | F_ID[I][J] | element of per-atom array (I = atom ID)  |
 +--------+------------+------------------------------------------+
++--------+------------+------------------------------------------+
 | vector | f_ID       | global vector                            |
++--------+------------+------------------------------------------+
 | vector | f_ID[I]    | column of global array                   |
 +--------+------------+------------------------------------------+
++--------+------------+------------------------------------------+
 | atom   | f_ID       | per-atom vector                          |
++--------+------------+------------------------------------------+
 | atom   | f_ID[I]    | column of per-atom array                 |
 +--------+------------+------------------------------------------+
 
@@ -1365,17 +1400,27 @@ per-atom vector.
 
 +--------+-----------+-----------------------------------------------------------------------------------+
 | equal  | v_name    | global scalar from an equal-style variable                                        |
++--------+-----------+-----------------------------------------------------------------------------------+
 | equal  | v_name[I] | element of global vector from a vector-style variable                             |
++--------+-----------+-----------------------------------------------------------------------------------+
 | equal  | v_name[I] | element of per-atom vector (I = atom ID) from an atom- or atomfile-style variable |
 +--------+-----------+-----------------------------------------------------------------------------------+
++--------+-----------+-----------------------------------------------------------------------------------+
 | vector | v_name    | global scalar from an equal-style variable                                        |
++--------+-----------+-----------------------------------------------------------------------------------+
 | vector | v_name    | global vector from a vector-style variable                                        |
++--------+-----------+-----------------------------------------------------------------------------------+
 | vector | v_name[I] | element of global vector from a vector-style variable                             |
++--------+-----------+-----------------------------------------------------------------------------------+
 | vector | v_name[I] | element of per-atom vector (I = atom ID) from an atom- or atomfile-style variable |
 +--------+-----------+-----------------------------------------------------------------------------------+
++--------+-----------+-----------------------------------------------------------------------------------+
 | atom   | v_name    | global scalar from an equal-style variable                                        |
++--------+-----------+-----------------------------------------------------------------------------------+
 | atom   | v_name    | per-atom vector from an atom-style or atomfile-style variable                     |
++--------+-----------+-----------------------------------------------------------------------------------+
 | atom   | v_name[I] | element of global vector from a vector-style variable                             |
++--------+-----------+-----------------------------------------------------------------------------------+
 | atom   | v_name[I] | element of per-atom vector (I = atom ID) from an atom- or atomfile-style variable |
 +--------+-----------+-----------------------------------------------------------------------------------+
 

doc/src/write_data.rst

@@ -12,13 +12,14 @@ Syntax
 
 * file = name of data file to write out
 * zero or more keyword/value pairs may be appended
-* keyword = *pair* or *nocoeff* or *nofix* or *nolabelmap*
+* keyword = *nocoeff* or *nofix* or *nolabelmap* or *triclinic/general* or *types* or *pair*
 
   .. parsed-literal::
 
        *nocoeff* = do not write out force field info
        *nofix* = do not write out extra sections read by fixes
        *nolabelmap* = do not write out type labels
+       *triclinic/general* = write data file in general triclinic format
        *types* value = *numeric* or *labels*
        *pair* value = *ii* or *ij*
          *ii* = write one line of pair coefficient info per atom type
@@ -31,6 +32,7 @@ Examples
 
    write_data data.polymer
    write_data data.*
+   write_data data.solid triclinic/general
 
 Description
 """""""""""
@@ -85,10 +87,11 @@ using the :doc:`-r command-line switch <Run_options>`.
    :doc:`fixes <fix>` are stored.  :doc:`Binary restart files <read_restart>`
    store more information.
 
-Bond interactions (angle, etc) that have been turned off by the :doc:`fix shake <fix_shake>` or :doc:`delete_bonds <delete_bonds>` command will
+Bond interactions (angle, etc) that have been turned off by the
-be written to a data file as if they are turned on.  This means they
+:doc:`fix shake <fix_shake>` or :doc:`delete_bonds <delete_bonds>`
-will need to be turned off again in a new run after the data file is
+command will be written to a data file as if they are turned on.  This
-read.
+means they will need to be turned off again in a new run after the
+data file is read.
 
 Bonds that are broken (e.g. by a bond-breaking potential) are not
 written to the data file.  Thus these bonds will not exist when the
@@ -122,6 +125,23 @@ not written to the data file.  By default, they are written if they
 exist.  A type label must be defined for every numeric type (within a
 given type-kind) to be written to the data file.
 
+Use of the *triclinic/general* keyword will output a data file which
+specifies a general triclinic simulation box as well as per-atom
+quantities consistent with the general triclinic box.  The latter means
+that per-atom vectors, such as velocities and dipole moments will be
+oriented consistent with the 3d rotation implied by the general
+triclinic box (relative to the associated restricted triclinic box).
+
+This option can only be requested if the simulation box was initially
+defined to be general triclinic.  If if was and the
+*triclinic/general* keyword is not used, then the data file will
+specify a restricted triclinic box, since that is the internal format
+LAMMPS uses for both general and restricted triclinic simulations.
+See the :doc:`Howto triclinic <Howto_triclinic>` doc page for more
+explanation of how general triclinic simulation boxes are supported by
+LAMMPS.  And see the :doc:`read_data <read_data>` doc page for details
+of how the format is altered for general triclinic data files.
+
 The *types* keyword determines how atom types, bond types, angle
 types, etc are written into these data file sections: Atoms, Bonds,
 Angles, etc.  The default is the *numeric* setting, even if type label

doc/src/write_restart.rst

@@ -55,21 +55,22 @@ alter the number of files written.
 Restart files can be read by a :doc:`read_restart <read_restart>`
 command to restart a simulation from a particular state.  Because the
 file is binary (to enable exact restarts), it may not be readable on
-another machine.  In this case, you can use the :doc:`-r command-line switch <Run_options>` to convert a restart file to a data file.
+another machine.  In this case, you can use the :doc:`-r command-line
+switch <Run_options>` to convert a restart file to a data file.
 
 .. note::
 
    Although the purpose of restart files is to enable restarting a
    simulation from where it left off, not all information about a
-   simulation is stored in the file.  For example, the list of fixes that
+   simulation is stored in the file.  For example, the list of fixes
-   were specified during the initial run is not stored, which means the
+   that were specified during the initial run is not stored, which
-   new input script must specify any fixes you want to use.  Even when
+   means the new input script must specify any fixes you want to use.
-   restart information is stored in the file, as it is for some fixes,
+   Even when restart information is stored in the file, as it is for
-   commands may need to be re-specified in the new input script, in order
+   some fixes, commands may need to be re-specified in the new input
-   to re-use that information. Details are usually given in the
+   script, in order to re-use that information. Details are usually
-   documentation of the respective command. Also, see the
+   given in the documentation of the respective command. Also, see the
-   :doc:`read_restart <read_restart>` command for general information about
+   :doc:`read_restart <read_restart>` command for general information
-   what is stored in a restart file.
+   about what is stored in a restart file.
 
 ----------
 

doc/utils/requirements.txt

@@ -1,4 +1,4 @@
-Sphinx >= 5.3.0, <8.0
+Sphinx >= 5.3.0, <7.3
 sphinxcontrib-spelling
 sphinxcontrib-jquery
 git+https://github.com/akohlmey/sphinx-fortran@parallel-read

doc/utils/sphinx-config/false_positives.txt

@@ -50,6 +50,7 @@ agilio
 Agilio
 agni
 Agnolin
+ahi
 Ahrens
 Ai
 Aidan
@@ -86,6 +87,7 @@ allocator
 allocators
 allosws
 AlO
+alo
 Alonso
 Alperen
 alphak
@@ -187,6 +189,10 @@ automagically
 Auvergne
 Avalos
 avalue
+avec
+avecx
+avecy
+avecz
 aveforce
 Avendano
 Averett
@@ -194,11 +200,14 @@ avi
 AVX
 awpmd
 AWPMD
+ax
 Axel
 Axilrod
 Ay
+ay
 Ayton
 Az
+az
 Azevedo
 azimuthal
 Azuri
@@ -271,6 +280,7 @@ Bext
 Bfrac
 bgq
 Bh
+bhi
 Bialke
 biaxial
 bicrystal
@@ -307,6 +317,7 @@ Bkappa
 blabel
 Blaise
 blanchedalmond
+blo
 blocksize
 blueviolet
 bn
@@ -380,12 +391,17 @@ btype
 buckPlusAttr
 buf
 builtin
+Bulacu
 Bulatov
 Bureekaew
 burlywood
 Bussi
 Buturigakkwaishi
 Buyl
+bvec
+bvecx
+bvecy
+bvecz
 Bybee
 bz
 Cadarache
@@ -476,6 +492,7 @@ ChiralIDs
 chirality
 Cho
 Chodera
+Choi
 ChooseOffset
 chris
 Christoph
@@ -617,6 +634,7 @@ cstdlib
 cstring
 cstyle
 csvr
+ctilde
 ctrl
 ctrn
 ctypes
@@ -648,14 +666,21 @@ cv
 Cv
 Cval
 cvar
+cvec
+cvecx
+cvecy
+cvecz
 cvff
 cwiggle
+cx
+cy
 cygwin
 Cygwin
 cylindrically
 Cyrot
 cyrstals
 cython
+cz
 Daivis
 Dammak
 dampflag
@@ -947,6 +972,7 @@ elastance
 Electroneg
 electronegative
 electronegativity
+electroneutral
 electroneutrality
 Eleftheriou
 ElementN
@@ -1301,6 +1327,7 @@ gmres
 gname
 gneb
 GNEB
+Goga
 Goldfarb
 Gompper
 Gonzalez-Melchor
@@ -1478,6 +1505,7 @@ hydroxyl
 Hynninen
 Hyoungki
 hyperdynamics
+hyperparameters
 hyperplane
 hyperradius
 hyperspherical
@@ -1770,6 +1798,7 @@ Kolafa
 Kollman
 kolmogorov
 Kolmogorov
+Kolotinskii
 Kondor
 konglt
 Koning
@@ -2038,6 +2067,7 @@ Makefiles
 makelist
 makepkg
 Makse
+Malavasi
 malloc
 Malolepsza
 Manby
@@ -2147,6 +2177,7 @@ membered
 memcheck
 Mendelev
 Menon
+Menziani
 mer
 Meremianin
 Mersenne
@@ -2257,6 +2288,7 @@ Montalenti
 Monterey
 Montero
 Monti
+Monticelli
 Mora
 Morefoo
 Morfill
@@ -2266,6 +2298,7 @@ morris
 Morriss
 morse
 Morteza
+MoS
 Mosayebi
 Moseler
 Moskalev
@@ -2683,6 +2716,9 @@ organometallic
 orientational
 orientationsFile
 orientorder
+originx
+originy
+originz
 Orlikowski
 ornl
 Ornstein
@@ -2726,6 +2762,7 @@ papayawhip
 paquay
 Paquay
 parallelepiped
+parallelepipeds
 Parallelizable
 parallelization
 parallelized
@@ -2769,11 +2806,14 @@ Peachey
 peachpuff
 Pearlman
 Pedersen
+pedone
+Pedone
 peID
 PEigenDense
 Peng
 peptide
 peratom
+Perf
 Pergamon
 pergrid
 peri
@@ -2781,6 +2821,7 @@ peridynamic
 Peridynamic
 peridynamics
 Peridynamics
+Periole
 perl
 permittivity
 perp
@@ -3070,6 +3111,7 @@ reaxff
 ReaxFF
 REAXFF
 rebo
+rebomos
 recurse
 recursing
 Ree
@@ -3195,6 +3237,7 @@ Ronevich
 Rosati
 Rosato
 Rosenberger
+Rossi
 Rossky
 rosybrown
 rotationally
@@ -3597,6 +3640,7 @@ tesselation
 tesselations
 Tetot
 tex
+textrm
 tfac
 tfmc
 tfMC
@@ -3637,6 +3681,7 @@ thrid
 ThunderX
 thylakoid
 THz
+Tieleman
 Tigran
 Tij
 Tildesley
@@ -3884,7 +3929,9 @@ Verlet
 versa
 Verstraelen
 ves
+vf
 vflag
+vflow
 vfrac
 vhi
 vibrational
@@ -4115,6 +4162,7 @@ zenodo
 Zepeda
 zflag
 Zhang
+Zhao
 Zhen
 zhi
 Zhigilei