Merge branch 'develop' into patch-2

.github/workflows/coverity.yml

@@ -67,7 +67,6 @@ jobs:
         -D PKG_MANIFOLD=on \
         -D PKG_MDI=on \
         -D PKG_MGPT=on \
-        -D PKG_ML-PACE=on \
         -D PKG_ML-RANN=on \
         -D PKG_MOLFILE=on \
         -D PKG_NETCDF=on \

.github/workflows/lammps-gui-flatpak.yml

@@ -0,0 +1,53 @@
+# GitHub action to build LAMMPS-GUI as a flatpak bundle
+name: "Build LAMMPS-GUI as flatpak bundle"
+
+on:
+  push:
+    branches:
+      - develop
+
+  workflow_dispatch:
+
+concurrency:
+  group: ${{ github.event_name }}-${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: ${{github.event_name == 'pull_request'}}
+
+jobs:
+  build:
+    name: LAMMPS-GUI flatpak build
+    if: ${{ github.repository == 'lammps/lammps' }}
+    runs-on: ubuntu-latest
+
+    steps:
+    - name: Checkout repository
+      uses: actions/checkout@v4
+      with:
+        fetch-depth: 2
+
+    - name: Install extra packages
+      run: |
+        sudo apt-get update
+        sudo apt-get install -y ccache \
+                                libeigen3-dev \
+                                libcurl4-openssl-dev \
+                                mold \
+                                ninja-build \
+                                python3-dev \
+                                flatpak \
+                                flatpak-builder
+
+    - name: Set up access to flatpak repo
+      run: flatpak --user remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo
+
+    - name: Build flatpak
+      run: |
+        mkdir flatpack-state
+        sed -i -e 's/branch:.*/branch: develop/' tools/lammps-gui/org.lammps.lammps-gui.yml
+        flatpak-builder --force-clean --verbose --repo=flatpak-repo \
+                               --install-deps-from=flathub --state-dir=flatpak-state \
+                               --user --ccache --default-branch=${{ github.ref_name }} \
+                               flatpak-build tools/lammps-gui/org.lammps.lammps-gui.yml
+        flatpak build-bundle --runtime-repo=https://flathub.org/repo/flathub.flatpakrepo \
+                               --verbose  flatpak-repo LAMMPS-Linux-x86_64-GUI.flatpak \
+                               org.lammps.lammps-gui ${{ github.ref_name }}
+        flatpak install -y -v --user LAMMPS-Linux-x86_64-GUI.flatpak

.github/workflows/style-check.yml

@@ -35,3 +35,4 @@ jobs:
          make check-permissions
          make check-homepage
          make check-errordocs
+         make check-fmtlib

.github/workflows/unittest-arm64.yml

@@ -0,0 +1,81 @@
+# GitHub action to build LAMMPS on Linux with ARM64 and run standard unit tests
+name: "Unittest for Linux on ARM64"
+
+on:
+  push:
+    branches: [develop]
+
+  workflow_dispatch:
+
+concurrency:
+  group: ${{ github.event_name }}-${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: ${{github.event_name == 'pull_request'}}
+
+jobs:
+  build:
+    name: Linux ARM64 Unit Test
+    if: ${{ github.repository == 'lammps/lammps' }}
+    runs-on: ubuntu-22.04-arm
+    env:
+      CCACHE_DIR: ${{ github.workspace }}/.ccache
+
+    steps:
+    - name: Checkout repository
+      uses: actions/checkout@v4
+      with:
+        fetch-depth: 2
+
+    - name: Install extra packages
+      run: |
+        sudo apt-get update
+        sudo apt-get install -y ccache \
+                                libeigen3-dev \
+                                libcurl4-openssl-dev \
+                                mold \
+                                ninja-build \
+                                python3-dev
+
+    - name: Create Build Environment
+      run: mkdir build
+
+    - name: Set up ccache
+      uses: actions/cache@v4
+      with:
+        path: ${{ env.CCACHE_DIR }}
+        key: linux-unit-ccache-${{ github.sha }}
+        restore-keys: linux-unit-ccache-
+
+    - name: Building LAMMPS via CMake
+      shell: bash
+      run: |
+        ccache -z
+        python3 -m venv linuxenv
+        source linuxenv/bin/activate
+        python3 -m pip install numpy
+        python3 -m pip install pyyaml
+        cmake -S cmake -B build \
+              -C cmake/presets/gcc.cmake \
+              -C cmake/presets/most.cmake \
+              -D CMAKE_CXX_COMPILER_LAUNCHER=ccache \
+              -D CMAKE_C_COMPILER_LAUNCHER=ccache \
+              -D BUILD_SHARED_LIBS=on \
+              -D DOWNLOAD_POTENTIALS=off \
+              -D ENABLE_TESTING=on \
+              -D MLIAP_ENABLE_ACE=on \
+              -D MLIAP_ENABLE_PYTHON=off \
+              -D PKG_MANIFOLD=on \
+              -D PKG_ML-PACE=on \
+              -D PKG_ML-RANN=on \
+              -D PKG_RHEO=on \
+              -D PKG_PTM=on \
+              -D PKG_PYTHON=on \
+              -D PKG_QTB=on \
+              -D PKG_SMTBQ=on \
+              -G Ninja
+        cmake --build build
+        ccache -s
+
+    - name: Run Tests
+      working-directory: build
+      shell: bash
+      run: ctest -V -LE unstable

cmake/CMakeLists.txt

@@ -3,6 +3,9 @@
 # CMake build system
 # This file is part of LAMMPS
 cmake_minimum_required(VERSION 3.16)
+if(CMAKE_VERSION VERSION_LESS 3.20)
+  message(WARNING "LAMMPS is planning to require at least CMake version 3.20 by Summer 2025. Please upgrade!")
+endif()
 ########################################
 # set policy to silence warnings about ignoring <PackageName>_ROOT but use it
 if(POLICY CMP0074)
@@ -144,16 +147,28 @@ if((PKG_KOKKOS) AND (Kokkos_ENABLE_CUDA) AND NOT (CMAKE_CXX_COMPILER_ID STREQUAL
   set(CMAKE_TUNE_DEFAULT "${CMAKE_TUNE_DEFAULT}" "-Xcudafe --diag_suppress=unrecognized_pragma,--diag_suppress=128")
 endif()
 
-# we require C++11 without extensions. Kokkos requires at least C++17 (currently)
+# we *require* C++11 without extensions but prefer C++17.
+# Kokkos requires at least C++17 (currently)
 if(NOT CMAKE_CXX_STANDARD)
-  set(CMAKE_CXX_STANDARD 11)
+  if(cxx_std_17 IN_LIST CMAKE_CXX_COMPILE_FEATURES)
+    set(CMAKE_CXX_STANDARD 17)
+  else()
+    set(CMAKE_CXX_STANDARD 11)
+  endif()
 endif()
 if(CMAKE_CXX_STANDARD LESS 11)
   message(FATAL_ERROR "C++ standard must be set to at least 11")
 endif()
+if(CMAKE_CXX_STANDARD LESS 17)
+  message(WARNING "Selecting C++17 standard is preferred over C++${CMAKE_CXX_STANDARD}")
+endif()
 if(PKG_KOKKOS AND (CMAKE_CXX_STANDARD LESS 17))
   set(CMAKE_CXX_STANDARD 17)
 endif()
+# turn off C++17 check in lmptype.h
+if(LAMMPS_CXX11)
+  add_compile_definitions(LAMMPS_CXX11)
+endif()
 set(CMAKE_CXX_STANDARD_REQUIRED ON)
 set(CMAKE_CXX_EXTENSIONS OFF CACHE BOOL "Use compiler extensions")
 # ugly hacks for MSVC which by default always reports an old C++ standard in the __cplusplus macro
@@ -347,6 +362,17 @@ foreach(PKG ${STANDARD_PACKAGES} ${SUFFIX_PACKAGES})
   option(PKG_${PKG} "Build ${PKG} Package" OFF)
 endforeach()
 
+set(DEPRECATED_PACKAGES AWPMD ATC POEMS)
+foreach(PKG ${DEPRECATED_PACKAGES})
+  if(PKG_${PKG})
+    message(WARNING
+          "The ${PKG} package will be removed from LAMMPS in Summer 2025 due to lack of "
+          "maintenance and use of code constructs that conflict with modern C++ compilers "
+          "and standards.  Please contact developers@lammps.org if you have any concerns "
+          "about this step.")
+  endif()
+endforeach()
+
 ######################################################
 # packages with special compiler needs or external libs
 ######################################################
@@ -579,6 +605,16 @@ foreach(PKG_WITH_INCL KSPACE PYTHON ML-IAP VORONOI COLVARS ML-HDNNP MDI MOLFILE
   endif()
 endforeach()
 
+# settings for misc packages and styles
+if(PKG_MISC)
+  option(LAMMPS_ASYNC_IMD "Asynchronous IMD processing" OFF)
+  mark_as_advanced(LAMMPS_ASYNC_IMD)
+  if(LAMMPS_ASYNC_IMD)
+    target_compile_definitions(lammps PRIVATE -DLAMMPS_ASYNC_IMD)
+    message(STATUS "Using IMD in asynchronous mode")
+  endif()
+endif()
+
 # optionally enable building script wrappers using swig
 option(WITH_SWIG "Build scripting language wrappers with SWIG" OFF)
 if(WITH_SWIG)
@@ -1078,12 +1114,15 @@ if(BUILD_TOOLS)
   message(STATUS "<<< Building Tools >>>")
 endif()
 if(BUILD_LAMMPS_GUI)
-  message(STATUS "<<< Building LAMMPS GUI >>>")
+  message(STATUS "<<< Building LAMMPS-GUI >>>")
   if(LAMMPS_GUI_USE_PLUGIN)
     message(STATUS "Loading LAMMPS library as plugin at run time")
   else()
     message(STATUS "Linking LAMMPS library at compile time")
   endif()
+  if(BUILD_WHAM)
+    message(STATUS "<<< Building WHAM >>>")
+  endif()
 endif()
 if(ENABLE_TESTING)
   message(STATUS "<<< Building Unit Tests >>>")

cmake/Modules/Packages/INTEL.cmake

@@ -72,6 +72,10 @@ if(INTEL_ARCH STREQUAL "KNL")
   if(NOT CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
     message(FATAL_ERROR "Must use Intel compiler with INTEL for KNL architecture")
   endif()
+  message(WARNING, "Support for Intel Xeon Phi accelerators and Knight's Landing CPUs "
+          "will be removed from LAMMPS in Summer 2025 due to lack of available machines "
+          "in labs and HPC centers and removed support in recent compilers "
+          "Please contact developers@lammps.org if you have any concerns about this step.")
   set(CMAKE_EXE_LINKER_FLAGS  "${CMAKE_EXE_LINKER_FLAGS} -xHost -qopenmp -qoffload")
   set(MIC_OPTIONS "-qoffload-option,mic,compiler,\"-fp-model fast=2 -mGLOB_default_function_attrs=\\\"gather_scatter_loop_unroll=4\\\"\"")
   target_compile_options(lammps PRIVATE -xMIC-AVX512 -qoffload -fno-alias -ansi-alias -restrict -qoverride-limits ${MIC_OPTIONS})

cmake/Modules/Packages/KOKKOS.cmake

@@ -7,26 +7,13 @@ endif()
 
 ########################################################################
 # consistency checks and Kokkos options/settings required by LAMMPS
-if(Kokkos_ENABLE_CUDA)
-  option(Kokkos_ENABLE_IMPL_CUDA_MALLOC_ASYNC "CUDA asynchronous malloc support" OFF)
-  mark_as_advanced(Kokkos_ENABLE_IMPL_CUDA_MALLOC_ASYNC)
-  if(Kokkos_ENABLE_IMPL_CUDA_MALLOC_ASYNC)
-    message(STATUS "KOKKOS: CUDA malloc async support enabled")
-  else()
-    message(STATUS "KOKKOS: CUDA malloc async support disabled")
-  endif()
-endif()
 if(Kokkos_ENABLE_HIP)
   option(Kokkos_ENABLE_HIP_MULTIPLE_KERNEL_INSTANTIATIONS "Enable multiple kernel instantiations with HIP" ON)
   mark_as_advanced(Kokkos_ENABLE_HIP_MULTIPLE_KERNEL_INSTANTIATIONS)
   option(Kokkos_ENABLE_ROCTHRUST "Use RoCThrust library" ON)
   mark_as_advanced(Kokkos_ENABLE_ROCTHRUST)
-
-  if(Kokkos_ARCH_AMD_GFX942 OR Kokkos_ARCH_AMD_GFX940)
-    option(Kokkos_ENABLE_IMPL_HIP_UNIFIED_MEMORY "Enable unified memory with HIP" ON)
-    mark_as_advanced(Kokkos_ENABLE_IMPL_HIP_UNIFIED_MEMORY)
-  endif()
 endif()
+
 # Adding OpenMP compiler flags without the checks done for
 # BUILD_OMP can result in compile failures. Enforce consistency.
 if(Kokkos_ENABLE_OPENMP)
@@ -70,8 +57,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.4.01.tar.gz" CACHE STRING "URL for KOKKOS tarball")
+  set(KOKKOS_URL "https://github.com/kokkos/kokkos/archive/4.5.01.tar.gz" CACHE STRING "URL for KOKKOS tarball")
-  set(KOKKOS_MD5 "de6ee80d00b6212b02bfb7f1e71a8392" CACHE STRING "MD5 checksum of KOKKOS tarball")
+  set(KOKKOS_MD5 "4d832aa0284169d9e3fbae3165286bc6" CACHE STRING "MD5 checksum of KOKKOS tarball")
   mark_as_advanced(KOKKOS_URL)
   mark_as_advanced(KOKKOS_MD5)
   GetFallbackURL(KOKKOS_URL KOKKOS_FALLBACK)
@@ -96,7 +83,7 @@ if(DOWNLOAD_KOKKOS)
   add_dependencies(LAMMPS::KOKKOSCORE kokkos_build)
   add_dependencies(LAMMPS::KOKKOSCONTAINERS kokkos_build)
 elseif(EXTERNAL_KOKKOS)
-  find_package(Kokkos 4.4.01 REQUIRED CONFIG)
+  find_package(Kokkos 4.5.01 REQUIRED CONFIG)
   target_link_libraries(lammps PRIVATE Kokkos::kokkos)
 else()
   set(LAMMPS_LIB_KOKKOS_SRC_DIR ${LAMMPS_LIB_SOURCE_DIR}/kokkos)
@@ -130,7 +117,6 @@ set(KOKKOS_PKG_SOURCES ${KOKKOS_PKG_SOURCES_DIR}/kokkos.cpp
                        ${KOKKOS_PKG_SOURCES_DIR}/atom_vec_kokkos.cpp
                        ${KOKKOS_PKG_SOURCES_DIR}/comm_kokkos.cpp
                        ${KOKKOS_PKG_SOURCES_DIR}/comm_tiled_kokkos.cpp
-                       ${KOKKOS_PKG_SOURCES_DIR}/group_kokkos.cpp
                        ${KOKKOS_PKG_SOURCES_DIR}/min_kokkos.cpp
                        ${KOKKOS_PKG_SOURCES_DIR}/min_linesearch_kokkos.cpp
                        ${KOKKOS_PKG_SOURCES_DIR}/neighbor_kokkos.cpp

cmake/Modules/Packages/ML-PACE.cmake

@@ -1,50 +1,62 @@
 # PACE library support for ML-PACE package
+find_package(pace QUIET)
 
-# set policy to silence warnings about timestamps of downloaded files. review occasionally if it may be set to NEW
+if(pace_FOUND)
-if(POLICY CMP0135)
+    find_package(pace)
-  cmake_policy(SET CMP0135 OLD)
+    target_link_libraries(lammps PRIVATE pace::pace)
-endif()
-
-set(PACELIB_URL "https://github.com/ICAMS/lammps-user-pace/archive/refs/tags/v.2023.11.25.fix.tar.gz" CACHE STRING "URL for PACE evaluator library sources")
-set(PACELIB_MD5 "b45de9a633f42ed65422567e3ce56f9f" CACHE STRING "MD5 checksum of PACE evaluator library tarball")
-mark_as_advanced(PACELIB_URL)
-mark_as_advanced(PACELIB_MD5)
-GetFallbackURL(PACELIB_URL PACELIB_FALLBACK)
-
-# LOCAL_ML-PACE points to top-level dir with local lammps-user-pace repo,
-# to make it easier to check local build without going through the public github releases
-if(LOCAL_ML-PACE)
- set(lib-pace "${LOCAL_ML-PACE}")
 else()
-  # download library sources to build folder
+    # set policy to silence warnings about timestamps of downloaded files. review occasionally if it may be set to NEW
-  if(EXISTS ${CMAKE_BINARY_DIR}/libpace.tar.gz)
+    if(POLICY CMP0135)
-    file(MD5 ${CMAKE_BINARY_DIR}/libpace.tar.gz DL_MD5)
+      cmake_policy(SET CMP0135 OLD)
-  endif()
-  if(NOT "${DL_MD5}" STREQUAL "${PACELIB_MD5}")
-    message(STATUS "Downloading ${PACELIB_URL}")
-    file(DOWNLOAD ${PACELIB_URL} ${CMAKE_BINARY_DIR}/libpace.tar.gz STATUS DL_STATUS SHOW_PROGRESS)
-    file(MD5 ${CMAKE_BINARY_DIR}/libpace.tar.gz DL_MD5)
-    if((NOT DL_STATUS EQUAL 0) OR (NOT "${DL_MD5}" STREQUAL "${PACELIB_MD5}"))
-      message(WARNING "Download from primary URL ${PACELIB_URL} failed\nTrying fallback URL ${PACELIB_FALLBACK}")
-      file(DOWNLOAD ${PACELIB_FALLBACK} ${CMAKE_BINARY_DIR}/libpace.tar.gz EXPECTED_HASH MD5=${PACELIB_MD5} SHOW_PROGRESS)
     endif()
-  else()
+
-    message(STATUS "Using already downloaded archive ${CMAKE_BINARY_DIR}/libpace.tar.gz")
+    set(PACELIB_URL "https://github.com/ICAMS/lammps-user-pace/archive/refs/tags/v.2023.11.25.fix2.tar.gz" CACHE STRING "URL for PACE evaluator library sources")
-  endif()
+    set(PACELIB_MD5 "a53bd87cfee8b07d9f44bc17aad69c3f" CACHE STRING "MD5 checksum of PACE evaluator library tarball")
+    mark_as_advanced(PACELIB_URL)
+    mark_as_advanced(PACELIB_MD5)
+    GetFallbackURL(PACELIB_URL PACELIB_FALLBACK)
+
+    # LOCAL_ML-PACE points to top-level dir with local lammps-user-pace repo,
+    # to make it easier to check local build without going through the public github releases
+    if(LOCAL_ML-PACE)
+     set(lib-pace "${LOCAL_ML-PACE}")
+    else()
+      # download library sources to build folder
+      if(EXISTS ${CMAKE_BINARY_DIR}/libpace.tar.gz)
+        file(MD5 ${CMAKE_BINARY_DIR}/libpace.tar.gz DL_MD5)
+      endif()
+      if(NOT "${DL_MD5}" STREQUAL "${PACELIB_MD5}")
+        message(STATUS "Downloading ${PACELIB_URL}")
+        file(DOWNLOAD ${PACELIB_URL} ${CMAKE_BINARY_DIR}/libpace.tar.gz STATUS DL_STATUS SHOW_PROGRESS)
+        file(MD5 ${CMAKE_BINARY_DIR}/libpace.tar.gz DL_MD5)
+        if((NOT DL_STATUS EQUAL 0) OR (NOT "${DL_MD5}" STREQUAL "${PACELIB_MD5}"))
+          message(WARNING "Download from primary URL ${PACELIB_URL} failed\nTrying fallback URL ${PACELIB_FALLBACK}")
+          file(DOWNLOAD ${PACELIB_FALLBACK} ${CMAKE_BINARY_DIR}/libpace.tar.gz EXPECTED_HASH MD5=${PACELIB_MD5} SHOW_PROGRESS)
+        endif()
+      else()
+        message(STATUS "Using already downloaded archive ${CMAKE_BINARY_DIR}/libpace.tar.gz")
+      endif()
 
 
-  # uncompress downloaded sources
+      # uncompress downloaded sources
-  execute_process(
+      execute_process(
-    COMMAND ${CMAKE_COMMAND} -E remove_directory lammps-user-pace*
+        COMMAND ${CMAKE_COMMAND} -E remove_directory lammps-user-pace*
-    COMMAND ${CMAKE_COMMAND} -E tar xzf libpace.tar.gz
+        COMMAND ${CMAKE_COMMAND} -E tar xzf libpace.tar.gz
-    WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
+        WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
-  )
+      )
-  get_newest_file(${CMAKE_BINARY_DIR}/lammps-user-pace-* lib-pace)
+      get_newest_file(${CMAKE_BINARY_DIR}/lammps-user-pace-* lib-pace)
-endif()
+    endif()
-
+
-add_subdirectory(${lib-pace} build-pace)
+    # some preinstalled yaml-cpp versions don't provide a namespaced target
-set_target_properties(pace PROPERTIES CXX_EXTENSIONS ON OUTPUT_NAME lammps_pace${LAMMPS_MACHINE})
+    find_package(yaml-cpp QUIET)
-
+    if(TARGET yaml-cpp AND NOT TARGET yaml-cpp::yaml-cpp)
-if(CMAKE_PROJECT_NAME STREQUAL "lammps")
+      add_library(yaml-cpp::yaml-cpp ALIAS yaml-cpp)
-  target_link_libraries(lammps PRIVATE pace)
+    endif()
+
+    add_subdirectory(${lib-pace} build-pace)
+    set_target_properties(pace PROPERTIES CXX_EXTENSIONS ON OUTPUT_NAME lammps_pace${LAMMPS_MACHINE})
+
+    if(CMAKE_PROJECT_NAME STREQUAL "lammps")
+      target_link_libraries(lammps PRIVATE pace)
+    endif()
 endif()

cmake/Modules/Packages/PLUMED.cmake

@@ -32,9 +32,9 @@ endif()
 
 # Note: must also adjust check for supported API versions in
 # fix_plumed.cpp when version changes from v2.n.x to v2.n+1.y
-set(PLUMED_URL "https://github.com/plumed/plumed2/releases/download/v2.9.2/plumed-src-2.9.2.tgz"
+set(PLUMED_URL "https://github.com/plumed/plumed2/releases/download/v2.9.3/plumed-src-2.9.3.tgz"
   CACHE STRING "URL for PLUMED tarball")
-set(PLUMED_MD5 "04862602a372c1013bdfee2d6d03bace" CACHE STRING "MD5 checksum of PLUMED tarball")
+set(PLUMED_MD5 "ee1249805fe94bccee17d10610d3f6f1" CACHE STRING "MD5 checksum of PLUMED tarball")
 
 mark_as_advanced(PLUMED_URL)
 mark_as_advanced(PLUMED_MD5)

cmake/Modules/Packages/VTK.cmake

@@ -1,3 +1,5 @@
+# FindVTK requires that C support is enabled when looking for MPI support
+enable_language(C)
 find_package(VTK REQUIRED NO_MODULE)
 target_compile_definitions(lammps PRIVATE -DLAMMPS_VTK)
 if (VTK_MAJOR_VERSION VERSION_LESS 9.0)

doc/doxygen/Doxyfile.in

@@ -2,7 +2,7 @@
 
 DOXYFILE_ENCODING      = UTF-8
 PROJECT_NAME           = "LAMMPS Programmer's Guide"
-PROJECT_NUMBER         = "4 May 2022"
+PROJECT_NUMBER         = "19 November 2024"
 PROJECT_BRIEF          = "Documentation of the LAMMPS library interface and Python wrapper"
 PROJECT_LOGO           = lammps-logo.png
 CREATE_SUBDIRS         = NO

doc/src/Build.rst

@@ -1,10 +1,14 @@
 Build LAMMPS
 ============
 
-LAMMPS is built as a library and an executable from source code using
+LAMMPS is built as a library and an executable from source code using a
-either traditional makefiles for use with GNU make (which may require
+build environment generated by CMake (Unix Makefiles, Ninja, Xcode,
-manual editing), or using a build environment generated by CMake (Unix
+Visual Studio, KDevelop, CodeBlocks and more depending on the platform).
-Makefiles, Ninja, Xcode, Visual Studio, KDevelop, CodeBlocks and more).
+Using CMake is the preferred way to build LAMMPS.  In addition, LAMMPS
+can be compiled using the legacy build system based on traditional
+makefiles for use with GNU make (which may require manual editing).
+Support for the legacy build system is slowly being phased out and may
+not be available for all optional features.
 
 As an alternative, you can download a package with pre-built executables
 or automated build trees, as described in the :doc:`Install <Install>`

doc/src/Build_basics.rst

@@ -160,7 +160,7 @@ with the OpenMP 3.1 semantics used in LAMMPS for maximal compatibility
 with compiler versions in use.  If compilation with OpenMP enabled fails
 because of your compiler requiring strict OpenMP 4.0 semantics, you can
 change the behavior by adding ``-D LAMMPS_OMP_COMPAT=4`` to the
-``LMP_INC`` variable in your makefile, or add it to the command line
+``LMP_INC`` variable in your makefile, or add it to the command-line flags
 while configuring with CMake.  LAMMPS will auto-detect a suitable setting
 for most GNU, Clang, and Intel compilers.
 
@@ -196,13 +196,18 @@ LAMMPS.
 
    .. tab:: CMake build
 
-      By default CMake will use the compiler it finds according to
+      By default CMake will use the compiler it finds according to its
       internal preferences, and it will add optimization flags
       appropriate to that compiler and any :doc:`accelerator packages
       <Speed_packages>` you have included in the build.  CMake will
       check if the detected or selected compiler is compatible with the
       C++ support requirements of LAMMPS and stop with an error, if this
-      is not the case.
+      is not the case.  A C++11 compatible compiler is currently
+      required, but a transition to require C++17 is in progress and
+      planned to be completed in Summer 2025. Currently, setting
+      ``-DLAMMPS_CXX11=yes`` is required when configuring with CMake while
+      using a C++11 compatible compiler that does not support C++17,
+      otherwise setting ``-DCMAKE_CXX_STANDARD=17`` is preferred.
 
       You can tell CMake to look for a specific compiler with setting
       CMake variables (listed below) during configuration.  For a few
@@ -223,6 +228,8 @@ LAMMPS.
          -D CMAKE_C_COMPILER=name              # name of C compiler
          -D CMAKE_Fortran_COMPILER=name        # name of Fortran compiler
 
+         -D CMAKE_CXX_STANDARD=17              # put compiler in C++17 mode
+         -D LAMMPS_CXX11=yes                   # enforce compilation in C++11 mode
          -D CMAKE_CXX_FLAGS=string             # flags to use with C++ compiler
          -D CMAKE_C_FLAGS=string               # flags to use with C compiler
          -D CMAKE_Fortran_FLAGS=string         # flags to use with Fortran compiler
@@ -321,15 +328,23 @@ LAMMPS.
          you would have to install a newer compiler that supports C++11;
          either as a binary package or through compiling from source.
 
-         If you build LAMMPS with any :doc:`Speed_packages` included,
+      While a C++11 compatible compiler is currently sufficient to compile
-         there may be specific compiler or linker flags that are either
+      LAMMPS, a transition to require C++17 is in progress and planned to
-         required or recommended to enable required features and to
+      be completed in Summer 2025. Currently, setting ``-DLAMMPS_CXX11``
-         achieve optimal performance.  You need to include these in the
+      in the ``LMP_INC =`` line in the machine makefile is required when
-         ``CCFLAGS`` and ``LINKFLAGS`` settings above.  For details, see the
+      using a C++11 compatible compiler that does not support C++17.
-         documentation for the individual packages listed on the
+      Otherwise, to enable C++17 support (if not enabled by default) using
-         :doc:`Speed_packages` page.  Or examine these files in the
+      a compiler flag like ``-std=c++17`` in CCFLAGS may needed.
-         ``src/MAKE/OPTIONS`` directory.  They correspond to each of the 5
+
-         accelerator packages and their hardware variants:
+      If you build LAMMPS with any :doc:`Speed_packages` included,
+      there may be specific compiler or linker flags that are either
+      required or recommended to enable required features and to
+      achieve optimal performance.  You need to include these in the
+      ``CCFLAGS`` and ``LINKFLAGS`` settings above.  For details, see the
+      documentation for the individual packages listed on the
+      :doc:`Speed_packages` page.  Or examine these files in the
+      ``src/MAKE/OPTIONS`` directory.  They correspond to each of the 5
+      accelerator packages and their hardware variants:
 
          .. code-block:: bash
 
@@ -502,6 +517,8 @@ using CMake or Make.
                                       # chain.x, micelle2d.x, msi2lmp, phana,
                                       # stl_bin2txt
          -D BUILD_LAMMPS_GUI=value    # yes or no (default). Build LAMMPS-GUI
+         -D BUILD_WHAM=value          # yes (default). Download and build WHAM;
+                                      # only available for BUILD_LAMMPS_GUI=yes
 
       The generated binaries will also become part of the LAMMPS installation
       (see below).

doc/src/Build_cmake.rst

@@ -8,7 +8,7 @@ packages.  Links to those pages on the :doc:`Build overview <Build>`
 page.
 
 The following text assumes some familiarity with CMake and focuses on
-using the command line tool ``cmake`` and what settings are supported
+using the command-line tool ``cmake`` and what settings are supported
 for building LAMMPS.  A more detailed tutorial on how to use CMake
 itself, the text mode or graphical user interface, to change the
 generated output files for different build tools and development
@@ -16,7 +16,7 @@ environments is on a :doc:`separate page <Howto_cmake>`.
 
 .. note::
 
-   LAMMPS currently requires that CMake version 3.16 or later is available.
+   LAMMPS currently requires that CMake version 3.20 or later is available.
 
 .. warning::
 
@@ -32,22 +32,22 @@ environments is on a :doc:`separate page <Howto_cmake>`.
 Advantages of using CMake
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 
-CMake is an alternative to compiling LAMMPS in the traditional way
+CMake is the preferred way of compiling LAMMPS in contrast to the legacy
-through :doc:`(manually customized) makefiles <Build_make>`.  Using
+build system based on GNU make and through :doc:`(manually customized)
-CMake has multiple advantages that are specifically helpful for
+makefiles <Build_make>`.  Using CMake has multiple advantages that are
-people with limited experience in compiling software or for people
+specifically helpful for people with limited experience in compiling
-that want to modify or extend LAMMPS.
+software or for people that want to modify or extend LAMMPS.
 
 - CMake can detect available hardware, tools, features, and libraries
   and adapt the LAMMPS default build configuration accordingly.
 - CMake can generate files for different build tools and integrated
   development environments (IDE).
-- CMake supports customization of settings with a command line, text
+- CMake supports customization of settings with a command-line, text
   mode, or graphical user interface.  No manual editing of files,
-  knowledge of file formats or complex command line syntax is required.
+  knowledge of file formats or complex command-line syntax is required.
 - All enabled components are compiled in a single build operation.
 - Automated dependency tracking for all files and configuration options.
-- Support for true out-of-source compilation. Multiple configurations
+- Support for true out-of-source compilation.  Multiple configurations
   and settings with different choices of LAMMPS packages, settings, or
   compilers can be configured and built concurrently from the same
   source tree.
@@ -68,7 +68,7 @@ that purpose you can use either the command-line utility ``cmake`` (or
 graphical utility ``cmake-gui``, or use them interchangeably.  The
 second step is then the compilation and linking of all objects,
 libraries, and executables using the selected build tool.  Here is a
-minimal example using the command line version of CMake to build LAMMPS
+minimal example using the command-line version of CMake to build LAMMPS
 with no add-on packages enabled and no customization:
 
 .. code-block:: bash
@@ -131,7 +131,7 @@ file called ``CMakeLists.txt`` (for LAMMPS it is located in the
 configuration step.  The cache file contains all current CMake settings.
 
 To modify settings, enable or disable features, you need to set
-*variables* with either the ``-D`` command line flag (``-D
+*variables* with either the ``-D`` command-line flag (``-D
 VARIABLE1_NAME=value``) or change them in the text mode of the graphical
 user interface.  The ``-D`` flag can be used several times in one command.
 
@@ -141,11 +141,11 @@ a different compiler tool chain.  Those are loaded with the ``-C`` flag
 (``-C ../cmake/presets/basic.cmake``).  This step would only be needed
 once, as the settings from the preset files are stored in the
 ``CMakeCache.txt`` file. It is also possible to customize the build
-by adding one or more ``-D`` flags to the CMake command line.
+by adding one or more ``-D`` flags to the CMake command.
 
 Generating files for alternate build tools (e.g. Ninja) and project files
 for IDEs like Eclipse, CodeBlocks, or Kate can be selected using the ``-G``
-command line flag.  A list of available generator settings for your
+command-line flag.  A list of available generator settings for your
 specific CMake version is given when running ``cmake --help``.
 
 .. _cmake_multiconfig:

doc/src/Build_development.rst

@@ -263,9 +263,9 @@ will be skipped if prerequisite features are not available in LAMMPS.
    time.  Preference is given to parts of the code base that are easy to
    test or commonly used.
 
-Tests as shown by the ``ctest`` program are command lines defined in the
+Tests as shown by the ``ctest`` program are commands defined in the
 ``CMakeLists.txt`` files in the ``unittest`` directory tree.  A few
-tests simply execute LAMMPS with specific command line flags and check
+tests simply execute LAMMPS with specific command-line flags and check
 the output to the screen for expected content.  A large number of unit
 tests are special tests programs using the `GoogleTest framework
 <https://github.com/google/googletest/>`_ and linked to the LAMMPS
@@ -420,7 +420,7 @@ during MD timestepping and manipulate per-atom properties like
 positions, velocities, and forces.  For those fix styles, testing can be
 done in a very similar fashion as for force fields and thus there is a
 test program `test_fix_timestep` that shares a lot of code, properties,
-and command line flags with the force field style testers described in
+and command-line flags with the force field style testers described in
 the previous section.
 
 This tester will set up a small molecular system run with verlet run
@@ -642,10 +642,10 @@ The following target are available for both, GNU make and CMake:
 
 .. _gh-cli:
 
-GitHub command line interface
+GitHub command-line interface
 -----------------------------
 
-GitHub has developed a `command line tool <https://cli.github.com>`_
+GitHub has developed a `command-line tool <https://cli.github.com>`_
 to interact with the GitHub website via a command called ``gh``.
 This is extremely convenient when working with a Git repository hosted
 on GitHub (like LAMMPS).  It is thus highly recommended to install it

doc/src/Build_extras.rst

@@ -48,6 +48,7 @@ This is the list of packages that may require additional steps.
    * :ref:`LEPTON <lepton>`
    * :ref:`MACHDYN <machdyn>`
    * :ref:`MDI <mdi>`
+   * :ref:`MISC <misc>`
    * :ref:`ML-HDNNP <ml-hdnnp>`
    * :ref:`ML-IAP <mliap>`
    * :ref:`ML-PACE <ml-pace>`
@@ -209,7 +210,7 @@ necessary for ``hipcc`` and the linker to work correctly.
 Using the CHIP-SPV implementation of HIP is supported. It allows one to
 run HIP code on Intel GPUs via the OpenCL or Level Zero back ends. To use
 CHIP-SPV, you must set ``-DHIP_USE_DEVICE_SORT=OFF`` in your CMake
-command line as CHIP-SPV does not yet support hipCUB. As of Summer 2022,
+command-line as CHIP-SPV does not yet support hipCUB. As of Summer 2022,
 the use of HIP for Intel GPUs is experimental. You should only use this
 option in preparations to run on Aurora system at Argonne.
 
@@ -232,7 +233,7 @@ option in preparations to run on Aurora system at Argonne.
 
 .. code:: bash
 
-   # CUDA target (not recommended, use GPU_ARCH=cuda)
+   # CUDA target (not recommended, use GPU_API=cuda)
    # !!! DO NOT set CMAKE_CXX_COMPILER !!!
    export HIP_PLATFORM=nvcc
    export HIP_PATH=/path/to/HIP/install
@@ -421,9 +422,10 @@ minutes to hours) to build.  Of course you only need to do that once.)
       cmake build system.  The ``lib/kim/Install.py`` script supports a
       ``CMAKE`` environment variable if the cmake executable is named other
       than ``cmake`` on your system.  Additional environment variables may be
-      provided on the command line for use by cmake.  For example, to use the
+      set with the ``make`` command for use by cmake.  For example, to use the
-      ``cmake3`` executable and tell it to use the gnu version 11 compilers
+      ``cmake3`` executable and tell it to use the GNU version 11 compilers
-      to build KIM, one could use the following command line.
+      called ``g++-11``, ``gcc-11`` and ``gfortran-11`` to build KIM, one
+      could use the following command.
 
       .. code-block:: bash
 
@@ -546,16 +548,7 @@ They must be specified in uppercase.
       - Local machine
    *  - AMDAVX
       - HOST
-      - AMD 64-bit x86 CPU (AVX 1)
+      - AMD chip
-   *  - ZEN
-      - HOST
-      - AMD Zen class CPU (AVX 2)
-   *  - ZEN2
-      - HOST
-      - AMD Zen2 class CPU (AVX 2)
-   *  - ZEN3
-      - HOST
-      - AMD Zen3 class CPU (AVX 2)
    *  - ARMV80
       - HOST
       - ARMv8.0 Compatible CPU
@@ -571,105 +564,126 @@ They must be specified in uppercase.
    *  - A64FX
       - HOST
       - ARMv8.2 with SVE Support
+   *  - ARMV9_GRACE
+      - HOST
+      - ARMv9 NVIDIA Grace CPU
    *  - SNB
       - HOST
-      - Intel Sandy/Ivy Bridge CPU (AVX 1)
+      - Intel Sandy/Ivy Bridge CPUs
    *  - HSW
       - HOST
-      - Intel Haswell CPU (AVX 2)
+      - Intel Haswell CPUs
    *  - BDW
       - HOST
-      - Intel Broadwell Xeon E-class CPU (AVX 2 + transactional mem)
+      - Intel Broadwell Xeon E-class CPUs
-   *  - SKL
-      - HOST
-      - Intel Skylake Client CPU
-   *  - SKX
-      - HOST
-      - Intel Skylake Xeon Server CPU (AVX512)
    *  - ICL
       - HOST
-      - Intel Ice Lake Client CPU (AVX512)
+      - Intel Ice Lake Client CPUs (AVX512)
    *  - ICX
       - HOST
-      - Intel Ice Lake Xeon Server CPU (AVX512)
+      - Intel Ice Lake Xeon Server CPUs (AVX512)
-   *  - SPR
+   *  - SKL
       - HOST
-      - Intel Sapphire Rapids Xeon Server CPU (AVX512)
+      - Intel Skylake Client CPUs
+   *  - SKX
+      - HOST
+      - Intel Skylake Xeon Server CPUs (AVX512)
    *  - KNC
       - HOST
       - Intel Knights Corner Xeon Phi
    *  - KNL
       - HOST
       - Intel Knights Landing Xeon Phi
+   *  - SPR
+      - HOST
+      - Intel Sapphire Rapids Xeon Server CPUs (AVX512)
    *  - POWER8
       - HOST
-      - IBM POWER8 CPU
+      - IBM POWER8 CPUs
    *  - POWER9
       - HOST
-      - IBM POWER9 CPU
+      - IBM POWER9 CPUs
+   *  - ZEN
+      - HOST
+      - AMD Zen architecture
+   *  - ZEN2
+      - HOST
+      - AMD Zen2 architecture
+   *  - ZEN3
+      - HOST
+      - AMD Zen3 architecture
    *  - RISCV_SG2042
       - HOST
-      - SG2042 (RISC-V) CPU
+      - SG2042 (RISC-V) CPUs
+   *  - RISCV_RVA22V
+      - HOST
+      - RVA22V (RISC-V) CPUs
    *  - KEPLER30
       - GPU
-      - NVIDIA Kepler generation CC 3.0 GPU
+      - NVIDIA Kepler generation CC 3.0
    *  - KEPLER32
       - GPU
-      - NVIDIA Kepler generation CC 3.2 GPU
+      - NVIDIA Kepler generation CC 3.2
    *  - KEPLER35
       - GPU
-      - NVIDIA Kepler generation CC 3.5 GPU
+      - NVIDIA Kepler generation CC 3.5
    *  - KEPLER37
       - GPU
-      - NVIDIA Kepler generation CC 3.7 GPU
+      - NVIDIA Kepler generation CC 3.7
    *  - MAXWELL50
       - GPU
-      - NVIDIA Maxwell generation CC 5.0 GPU
+      - NVIDIA Maxwell generation CC 5.0
    *  - MAXWELL52
       - GPU
-      - NVIDIA Maxwell generation CC 5.2 GPU
+      - NVIDIA Maxwell generation CC 5.2
    *  - MAXWELL53
       - GPU
-      - NVIDIA Maxwell generation CC 5.3 GPU
+      - NVIDIA Maxwell generation CC 5.3
    *  - PASCAL60
       - GPU
-      - NVIDIA Pascal generation CC 6.0 GPU
+      - NVIDIA Pascal generation CC 6.0
    *  - PASCAL61
       - GPU
-      - NVIDIA Pascal generation CC 6.1 GPU
+      - NVIDIA Pascal generation CC 6.1
    *  - VOLTA70
       - GPU
-      - NVIDIA Volta generation CC 7.0 GPU
+      - NVIDIA Volta generation CC 7.0
    *  - VOLTA72
       - GPU
-      - NVIDIA Volta generation CC 7.2 GPU
+      - NVIDIA Volta generation CC 7.2
    *  - TURING75
       - GPU
-      - NVIDIA Turing generation CC 7.5 GPU
+      - NVIDIA Turing generation CC 7.5
    *  - AMPERE80
       - GPU
-      - NVIDIA Ampere generation CC 8.0 GPU
+      - NVIDIA Ampere generation CC 8.0
    *  - AMPERE86
       - GPU
-      - NVIDIA Ampere generation CC 8.6 GPU
+      - NVIDIA Ampere generation CC 8.6
    *  - ADA89
       - GPU
-      - NVIDIA Ada Lovelace generation CC 8.9 GPU
+      - NVIDIA Ada generation CC 8.9
    *  - HOPPER90
       - GPU
-      - NVIDIA Hopper generation CC 9.0 GPU
+      - NVIDIA Hopper generation CC 9.0
    *  - AMD_GFX906
       - GPU
-      - AMD GPU MI50/MI60
+      - AMD GPU MI50/60
    *  - AMD_GFX908
       - GPU
       - AMD GPU MI100
    *  - AMD_GFX90A
       - GPU
       - AMD GPU MI200
+   *  - AMD_GFX940
+      - GPU
+      - AMD GPU MI300
    *  - AMD_GFX942
       - GPU
       - AMD GPU MI300
+   *  - AMD_GFX942_APU
+      - GPU
+      - AMD APU MI300A
    *  - AMD_GFX1030
       - GPU
       - AMD GPU V620/W6800
@@ -678,7 +692,7 @@ They must be specified in uppercase.
       - AMD GPU RX7900XTX
    *  - AMD_GFX1103
       - GPU
-      - AMD Phoenix APU with Radeon 740M/760M/780M/880M/890M
+      - AMD APU Phoenix
    *  - INTEL_GEN
       - GPU
       - SPIR64-based devices, e.g. Intel GPUs, using JIT
@@ -701,7 +715,7 @@ They must be specified in uppercase.
       - GPU
       - Intel GPU Ponte Vecchio
 
-This list was last updated for version 4.3.0 of the Kokkos library.
+This list was last updated for version 4.5.1 of the Kokkos library.
 
 .. tabs::
 
@@ -2018,7 +2032,7 @@ TBB and MKL.
 .. _mdi:
 
 MDI package
------------------------------
+-----------
 
 .. tabs::
 
@@ -2045,6 +2059,37 @@ MDI package
 
 ----------
 
+.. _misc:
+
+MISC package
+------------
+
+The :doc:`fix imd <fix_imd>` style in this package can be run either
+synchronously (communication with IMD clients is done in the main
+process) or asynchronously (the fix spawns a separate thread that can
+communicate with IMD clients concurrently to the LAMMPS execution).
+
+.. tabs::
+
+   .. tab:: CMake build
+
+      .. code-block:: bash
+
+         -D LAMMPS_ASYNC_IMD=value  # Run IMD server asynchronously
+                                    # value = no (default) or yes
+
+   .. tab:: Traditional make
+
+      To enable asynchronous mode the ``-DLAMMPS_ASYNC_IMD`` define
+      needs to be added to the ``LMP_INC`` variable in the
+      ``Makefile.machine`` you are using.  For example:
+
+      .. code-block:: make
+
+         LMP_INC = -DLAMMPS_ASYNC_IMD -DLAMMPS_MEMALIGN=64
+
+----------
+
 .. _molfile:
 
 MOLFILE package
@@ -2191,7 +2236,7 @@ verified to work in February 2020 with Quantum Espresso versions 6.3 to
       from the sources in the *lib* folder (including the essential
       libqmmm.a) are not included in the static LAMMPS library and
       (currently) not installed, while their code is included in the
-      shared LAMMPS library.  Thus a typical command line to configure
+      shared LAMMPS library.  Thus a typical command to configure
       building LAMMPS for QMMM would be:
 
       .. code-block:: bash

doc/src/Build_make.rst

@@ -8,6 +8,10 @@ Building LAMMPS with traditional makefiles requires that you have a
 for customizing your LAMMPS build with a number of global compilation
 options and features.
 
+This build system is slowly being phased out and may not support all
+optional features and packages in LAMMPS.  It is recommended to switch
+to the :doc:`CMake based build system <Build_cmake>`.
+
 Requirements
 ^^^^^^^^^^^^
 

doc/src/Build_package.rst

@@ -49,6 +49,7 @@ packages:
    * :ref:`LEPTON <lepton>`
    * :ref:`MACHDYN <machdyn>`
    * :ref:`MDI <mdi>`
+   * :ref:`MISC <misc>`
    * :ref:`ML-HDNNP <ml-hdnnp>`
    * :ref:`ML-IAP <mliap>`
    * :ref:`ML-PACE <ml-pace>`

doc/src/Build_windows.rst

@@ -100,9 +100,9 @@ procedure.
 
 It is possible to use both the integrated CMake support of the Visual
 Studio IDE or use an external CMake installation (e.g. downloaded from
-cmake.org) to create build files and compile LAMMPS from the command line.
+cmake.org) to create build files and compile LAMMPS from the command-line.
 
-Compilation via command line and unit tests are checked automatically
+Compilation via command-line and unit tests are checked automatically
 for the LAMMPS development branch through
 `GitHub Actions <https://github.com/lammps/lammps/actions/workflows/compile-msvc.yml>`_.
 
@@ -115,7 +115,7 @@ for the LAMMPS development branch through
 
 Please note, that for either approach CMake will create a so-called
 :ref:`"multi-configuration" build environment <cmake_multiconfig>`, and
-the command lines for building and testing LAMMPS must be adjusted
+the commands for building and testing LAMMPS must be adjusted
 accordingly.
 
 The LAMMPS cmake folder contains a ``CMakeSettings.json`` file with

doc/src/Classes_lammps.rst

@@ -4,7 +4,7 @@ LAMMPS Class
 The LAMMPS class is encapsulating an MD simulation state and thus it is
 the class that needs to be created when starting a new simulation system
 state.  The LAMMPS executable essentially creates one instance of this
-class and passes the command line flags and tells it to process the
+class and passes the command-line flags and tells it to process the
 provided input (a file or ``stdin``).  It shuts the class down when
 control is returned to it and then exits.  When using LAMMPS as a
 library from another code it is required to create an instance of this

doc/src/Commands_bond.rst

@@ -90,6 +90,7 @@ OPT.
    * :doc:`lepton (o) <angle_lepton>`
    * :doc:`mesocnt <angle_mesocnt>`
    * :doc:`mm3 <angle_mm3>`
+   * :doc:`mwlc <angle_mwlc>`
    * :doc:`quartic (o) <angle_quartic>`
    * :doc:`spica (ko) <angle_spica>`
    * :doc:`table (o) <angle_table>`

doc/src/Commands_compute.rst

@@ -58,6 +58,7 @@ KOKKOS, o = OPENMP, t = OPT.
    * :doc:`fep/ta <compute_fep_ta>`
    * :doc:`force/tally <compute_tally>`
    * :doc:`fragment/atom <compute_cluster_atom>`
+   * :doc:`gaussian/grid/local (k) <compute_gaussian_grid_local>`
    * :doc:`global/atom <compute_global_atom>`
    * :doc:`group/group <compute_group_group>`
    * :doc:`gyration <compute_gyration>`
@@ -140,8 +141,8 @@ KOKKOS, o = OPENMP, t = OPT.
    * :doc:`smd/vol <compute_smd_vol>`
    * :doc:`snap <compute_sna_atom>`
    * :doc:`sna/atom <compute_sna_atom>`
-   * :doc:`sna/grid <compute_sna_atom>`
+   * :doc:`sna/grid (k) <compute_sna_atom>`
-   * :doc:`sna/grid/local <compute_sna_atom>`
+   * :doc:`sna/grid/local (k) <compute_sna_atom>`
    * :doc:`snad/atom <compute_sna_atom>`
    * :doc:`snav/atom <compute_sna_atom>`
    * :doc:`sph/e/atom <compute_sph_e_atom>`

doc/src/Commands_fix.rst

@@ -58,6 +58,7 @@ OPT.
    * :doc:`dt/reset (k) <fix_dt_reset>`
    * :doc:`edpd/source <fix_dpd_source>`
    * :doc:`efield (k) <fix_efield>`
+   * :doc:`efield/lepton <fix_efield_lepton>`
    * :doc:`efield/tip4p <fix_efield>`
    * :doc:`ehex <fix_ehex>`
    * :doc:`electrode/conp (i) <fix_electrode>`

doc/src/Commands_input.rst

@@ -69,7 +69,7 @@ WARNING message is printed.  The :doc:`Errors <Errors>` page gives
 more information on what errors mean.  The documentation for each
 command lists restrictions on how the command can be used.
 
-You can use the :ref:`-skiprun <skiprun>` command line flag
+You can use the :ref:`-skiprun <skiprun>` command-line flag
 to have LAMMPS skip the execution of any ``run``, ``minimize``, or similar
 commands to check the entire input for correct syntax to avoid crashes
 on typos or syntax errors in long runs.

doc/src/Commands_pair.rst

@@ -80,6 +80,7 @@ OPT.
    * :doc:`coul/tt <pair_coul_tt>`
    * :doc:`coul/wolf (ko) <pair_coul>`
    * :doc:`coul/wolf/cs <pair_cs>`
+   * :doc:`dispersion/d3 <pair_dispersion_d3>`
    * :doc:`dpd (giko) <pair_dpd>`
    * :doc:`dpd/coul/slater/long (g) <pair_dpd_coul_slater_long>`
    * :doc:`dpd/ext (ko) <pair_dpd_ext>`
@@ -114,7 +115,9 @@ OPT.
    * :doc:`gw/zbl <pair_gw>`
    * :doc:`harmonic/cut (o) <pair_harmonic_cut>`
    * :doc:`hbond/dreiding/lj (o) <pair_hbond_dreiding>`
+   * :doc:`hbond/dreiding/lj/angleoffset (o) <pair_hbond_dreiding>`
    * :doc:`hbond/dreiding/morse (o) <pair_hbond_dreiding>`
+   * :doc:`hbond/dreiding/morse/angleoffset (o) <pair_hbond_dreiding>`
    * :doc:`hdnnp <pair_hdnnp>`
    * :doc:`hippo (g) <pair_amoeba>`
    * :doc:`ilp/graphene/hbn (t) <pair_ilp_graphene_hbn>`

doc/src/Commands_removed.rst

@@ -1,6 +1,10 @@
 Removed commands and packages
 =============================
 
+.. contents::
+
+------
+
 This page lists LAMMPS commands and packages that have been removed from
 the distribution and provides suggestions for alternatives or
 replacements.  LAMMPS has special dummy styles implemented, that will
@@ -8,47 +12,60 @@ stop LAMMPS and print a suitable error message in most cases, when a
 style/command is used that has been removed or will replace the command
 with the direct alternative (if available) and print a warning.
 
-restart2data tool
+LAMMPS shell
------------------
+------------
 
-.. versionchanged:: 23Nov2013
+.. versionchanged:: 29Aug2024
 
-The functionality of the restart2data tool has been folded into the
+The LAMMPS shell has been removed from the LAMMPS distribution. Users
-LAMMPS executable directly instead of having a separate tool.  A
+are encouraged to use the :ref:`LAMMPS-GUI <lammps_gui>` tool instead.
-combination of the commands :doc:`read_restart <read_restart>` and
-:doc:`write_data <write_data>` can be used to the same effect.  For
-added convenience this conversion can also be triggered by
-:doc:`command line flags <Run_options>`
 
-Fix ave/spatial and fix ave/spatial/sphere
+i-PI tool
-------------------------------------------
+---------
 
-.. deprecated:: 11Dec2015
+.. versionchanged:: 27Jun2024
 
-The fixes ave/spatial and ave/spatial/sphere have been removed from LAMMPS
+The i-PI tool has been removed from the LAMMPS distribution.  Instead,
-since they were superseded by the more general and extensible "chunk
+instructions to install i-PI from PyPI via pip are provided.
-infrastructure".  Here the system is partitioned in one of many possible
-ways through the :doc:`compute chunk/atom <compute_chunk_atom>` command
-and then averaging is done using :doc:`fix ave/chunk <fix_ave_chunk>`.
-Please refer to the :doc:`chunk HOWTO <Howto_chunk>` section for an overview.
 
-Box command
+USER-REAXC package
------------
+------------------
 
-.. deprecated:: 22Dec2022
+.. deprecated:: 7Feb2024
 
-The *box* command has been removed and the LAMMPS code changed so it won't
+The USER-REAXC package has been renamed to :ref:`REAXFF <PKG-REAXFF>`.
-be needed.  If present, LAMMPS will ignore the command and print a warning.
+In the process also the pair style and related fixes were renamed to use
+the "reaxff" string instead of "reax/c". For a while LAMMPS was maintaining
+backward compatibility by providing aliases for the styles.  These have
+been removed, so using "reaxff" is now *required*.
 
-Reset_ids, reset_atom_ids, reset_mol_ids commands
+MPIIO package
--------------------------------------------------
+-------------
 
-.. deprecated:: 22Dec2022
+.. deprecated:: 21Nov2023
 
-The *reset_ids*, *reset_atom_ids*, and *reset_mol_ids* commands have
+The MPIIO package has been removed from LAMMPS since it was unmaintained
-been folded into the :doc:`reset_atoms <reset_atoms>` command.  If
+for many years and thus not updated to incorporate required changes that
-present, LAMMPS will replace the commands accordingly and print a
+had been applied to the corresponding non-MPIIO commands. As a
-warning.
+consequence the MPIIO commands had become unreliable and sometimes
+crashing LAMMPS or corrupting data.  Similar functionality is available
+through the :ref:`ADIOS package <PKG-ADIOS>` and the :ref:`NETCDF
+package <PKG-NETCDF>`.  Also, the :doc:`dump_modify nfile or dump_modify
+fileper <dump_modify>` keywords may be used for an efficient way of
+writing out dump files when running on large numbers of processors.
+Similarly, the "nfile" and "fileper" keywords exist for restarts:
+see :doc:`restart <restart>`, :doc:`read_restart <read_restart>`,
+:doc:`write_restart <write_restart>`.
+
+MSCG package
+------------
+
+.. deprecated:: 21Nov2023
+
+The MSCG package has been removed from LAMMPS since it was unmaintained
+for many years and instead superseded by the `OpenMSCG software
+<https://software.rcc.uchicago.edu/mscg/>`_ of the Voth group at the
+University of Chicago, which can be used independent from LAMMPS.
 
 LATTE package
 -------------
@@ -64,18 +81,6 @@ packages, including LATTE.  See the ``examples/QUANTUM`` dir and the
 with LATTE as a plugin library (similar to the way fix latte worked), as
 well as on a different set of MPI processors.
 
-MEAM package
-------------
-
-The MEAM package in Fortran has been replaced by a C++ implementation.
-The code in the :ref:`MEAM package <PKG-MEAM>` is a translation of the
-Fortran code of MEAM into C++, which removes several restrictions
-(e.g. there can be multiple instances in hybrid pair styles) and allows
-for some optimizations leading to better performance.  The pair style
-:doc:`meam <pair_meam>` has the exact same syntax.  For a transition
-period the C++ version of MEAM was called USER-MEAMC so it could
-coexist with the Fortran version.
-
 Minimize style fire/old
 -----------------------
 
@@ -97,38 +102,38 @@ The same functionality is available through
 :doc:`bond style mesocnt <bond_mesocnt>` and
 :doc:`angle style mesocnt <angle_mesocnt>`.
 
-MPIIO package
+Box command
--------------
+-----------
 
-.. deprecated:: 21Nov2023
+.. deprecated:: 22Dec2022
 
-The MPIIO package has been removed from LAMMPS since it was unmaintained
+The *box* command has been removed and the LAMMPS code changed so it won't
-for many years and thus not updated to incorporate required changes that
+be needed.  If present, LAMMPS will ignore the command and print a warning.
-had been applied to the corresponding non-MPIIO commands. As a
-consequence the MPIIO commands had become unreliable and sometimes
-crashing LAMMPS or corrupting data.  Similar functionality is available
-through the :ref:`ADIOS package <PKG-ADIOS>` and the :ref:`NETCDF
-package <PKG-NETCDF>`.  Also, the :doc:`dump_modify nfile or dump_modify
-fileper <dump_modify>` keywords may be used for an efficient way of
-writing out dump files when running on large numbers of processors.
-Similarly, the "nfile" and "fileper" keywords exist for restarts:
-see :doc:`restart <restart>`, :doc:`read_restart <read_restart>`,
-:doc:`write_restart <write_restart>`.
 
+Reset_ids, reset_atom_ids, reset_mol_ids commands
+-------------------------------------------------
 
-MSCG package
+.. deprecated:: 22Dec2022
-------------
 
-.. deprecated:: 21Nov2023
+The *reset_ids*, *reset_atom_ids*, and *reset_mol_ids* commands have
+been folded into the :doc:`reset_atoms <reset_atoms>` command.  If
+present, LAMMPS will replace the commands accordingly and print a
+warning.
 
-The MSCG package has been removed from LAMMPS since it was unmaintained
+MESSAGE package
-for many years and instead superseded by the `OpenMSCG software
+---------------
-<https://software.rcc.uchicago.edu/mscg/>`_ of the Voth group at the
+
-University of Chicago, which can be used independent from LAMMPS.
+.. deprecated:: 4May2022
+
+The MESSAGE package has been removed since it was superseded by the
+:ref:`MDI package <PKG-MDI>`. MDI implements the same functionality
+and in a more general way with direct support for more applications.
 
 REAX package
 ------------
 
+.. deprecated:: 4Jan2019
+
 The REAX package has been removed since it was superseded by the
 :ref:`REAXFF package <PKG-REAXFF>`.  The REAXFF package has been tested
 to yield equivalent results to the REAX package, offers better
@@ -138,20 +143,25 @@ syntax compatible with the removed reax pair style, so input files will
 have to be adapted.  The REAXFF package was originally called
 USER-REAXC.
 
-USER-REAXC package
+MEAM package
-------------------
+------------
 
-.. deprecated:: 7Feb2024
+.. deprecated:: 4Jan2019
 
-The USER-REAXC package has been renamed to :ref:`REAXFF <PKG-REAXFF>`.
+The MEAM package in Fortran has been replaced by a C++ implementation.
-In the process also the pair style and related fixes were renamed to use
+The code in the :ref:`MEAM package <PKG-MEAM>` is a translation of the
-the "reaxff" string instead of "reax/c". For a while LAMMPS was maintaining
+Fortran code of MEAM into C++, which removes several restrictions
-backward compatibility by providing aliases for the styles.  These have
+(e.g. there can be multiple instances in hybrid pair styles) and allows
-been removed, so using "reaxff" is now *required*.
+for some optimizations leading to better performance.  The pair style
+:doc:`meam <pair_meam>` has the exact same syntax.  For a transition
+period the C++ version of MEAM was called USER-MEAMC so it could
+coexist with the Fortran version.
 
 USER-CUDA package
 -----------------
 
+.. deprecated:: 31May2016
+
 The USER-CUDA package had been removed, since it had been unmaintained
 for a long time and had known bugs and problems.  Significant parts of
 the design were transferred to the
@@ -160,19 +170,27 @@ performance characteristics on NVIDIA GPUs. Both, the KOKKOS
 and the :ref:`GPU package <PKG-GPU>` are maintained
 and allow running LAMMPS with GPU acceleration.
 
-i-PI tool
+Fix ave/spatial and fix ave/spatial/sphere
----------
+------------------------------------------
 
-.. versionchanged:: 27Jun2024
+.. deprecated:: 11Dec2015
 
-The i-PI tool has been removed from the LAMMPS distribution.  Instead,
+The fixes ave/spatial and ave/spatial/sphere have been removed from LAMMPS
-instructions to install i-PI from PyPI via pip are provided.
+since they were superseded by the more general and extensible "chunk
+infrastructure".  Here the system is partitioned in one of many possible
+ways through the :doc:`compute chunk/atom <compute_chunk_atom>` command
+and then averaging is done using :doc:`fix ave/chunk <fix_ave_chunk>`.
+Please refer to the :doc:`chunk HOWTO <Howto_chunk>` section for an overview.
 
-LAMMPS shell
+restart2data tool
-------------
+-----------------
 
-.. versionchanged:: 29Aug2024
+.. deprecated:: 23Nov2013
 
-The LAMMPS shell has been removed from the LAMMPS distribution. Users
+The functionality of the restart2data tool has been folded into the
-are encouraged to use the :ref:`LAMMPS-GUI <lammps_gui>` tool instead.
+LAMMPS executable directly instead of having a separate tool.  A
+combination of the commands :doc:`read_restart <read_restart>` and
+:doc:`write_data <write_data>` can be used to the same effect.  For
+added convenience this conversion can also be triggered by
+:doc:`command-line flags <Run_options>`
 

doc/src/Developer_code_design.rst

@@ -203,6 +203,7 @@ processed in the expected order before types are removed from dynamic
 dispatch.
 
 .. admonition:: Important Notes
+   :class: note
 
    In order to be able to detect incompatibilities at compile time and
    to avoid unexpected behavior, it is crucial that all member functions
@@ -300,18 +301,24 @@ Formatting with the {fmt} library
 
 The LAMMPS source code includes a copy of the `{fmt} library
 <https://fmt.dev>`_, which is preferred over formatting with the
-"printf()" family of functions.  The primary reason is that it allows
+"printf()" family of functions.  The primary reason is that it allows a
-a typesafe default format for any type of supported data.  This is
+typesafe default format for any type of supported data.  This is
 particularly useful for formatting integers of a given size (32-bit or
-64-bit) which may require different format strings depending on
+64-bit) which may require different format strings depending on compile
-compile time settings or compilers/operating systems.  Furthermore,
+time settings or compilers/operating systems.  Furthermore, {fmt} gives
-{fmt} gives better performance, has more functionality, a familiar
+better performance, has more functionality, a familiar formatting syntax
-formatting syntax that has similarities to ``format()`` in Python, and
+that has similarities to ``format()`` in Python, and provides a facility
-provides a facility that can be used to integrate format strings and a
+that can be used to integrate format strings and a variable number of
-variable number of arguments into custom functions in a much simpler
+arguments into custom functions in a much simpler way than the varargs
-way than the varargs mechanism of the C library.  Finally, {fmt} has
+mechanism of the C library.  Finally, {fmt} has been included into the
-been included into the C++20 language standard, so changes to adopt it
+C++20 language standard as ``std::format()``, so changes to adopt it are
-are future-proof.
+future-proof, for as long as they are not using any extensions that are
+not (yet) included into C++.
+
+The long-term plan is to switch to using ``std::format()`` instead of
+``fmt::format()`` when the minimum C++ standard required for LAMMPS will
+be set to C++20. See the :ref:`basic build instructions <compile>` for
+more details.
 
 Formatted strings are frequently created by calling the
 ``fmt::format()`` function, which will return a string as a
@@ -319,11 +326,13 @@ Formatted strings are frequently created by calling the
 ``printf()``, the {fmt} library uses ``{}`` to embed format descriptors.
 In the simplest case, no additional characters are needed, as {fmt} will
 choose the default format based on the data type of the argument.
-Otherwise, the ``fmt::print()`` function may be used instead of
+Otherwise, the :cpp:func:`utils::print() <LAMMPS_NS::utils::print>`
-``printf()`` or ``fprintf()``.  In addition, several LAMMPS output
+function may be used instead of ``printf()`` or ``fprintf()``.  In
-functions, that originally accepted a single string as argument have
+addition, several LAMMPS output functions, that originally accepted a
-been overloaded to accept a format string with optional arguments as
+single string as argument have been overloaded to accept a format string
-well (e.g., ``Error::all()``, ``Error::one()``, ``utils::logmesg()``).
+with optional arguments as well (e.g., ``Error::all()``,
+``Error::one()``, :cpp:func:`utils::logmesg()
+<LAMMPS_NS::utils::logmesg>`).
 
 Summary of the {fmt} format syntax
 ==================================

doc/src/Developer_flow.rst

@@ -209,7 +209,7 @@ nve, nvt, npt.
 
 At the end of the timestep, fixes that contain an ``end_of_step()``
 method are invoked.  These typically perform a diagnostic calculation,
-e.g. the ave/time and ave/spatial fixes.  The final operation of the
+e.g. the ave/time and ave/chunk fixes.  The final operation of the
 timestep is to perform any requested output, via the ``write()`` method
 of the Output class.  There are 3 kinds of LAMMPS output: thermodynamic
 output to the screen and log file, snapshots of atom data to a dump

doc/src/Developer_notes.rst

@@ -7,13 +7,7 @@ typically document what a variable stores, what a small section of
 code does, or what a function does and its input/outputs.  The topics
 on this page are intended to document code functionality at a higher level.
 
-Available topics are:
+.. contents::
-
-- `Reading and parsing of text and text files`_
-- `Requesting and accessing neighbor lists`_
-- `Choosing between a custom atom style, fix property/atom, and fix STORE/ATOM`_
-- `Fix contributions to instantaneous energy, virial, and cumulative energy`_
-- `KSpace PPPM FFT grids`_
 
 ----
 
@@ -218,6 +212,146 @@ command:
 
    neighbor->add_request(this, "delete_atoms", NeighConst::REQ_FULL);
 
+
+Errors, warnings, and informational messages
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+LAMMPS has specialized functionality to handle errors (which should
+terminate LAMMPS), warning messages (which should indicate possible
+problems *without* terminating LAMMPS), and informational text for
+messages about the progress and chosen settings.  We *strongly*
+encourage using these facilities and to *stay away* from using
+``printf()`` or ``fprintf()`` or ``std::cout`` or ``std::cerr`` and
+calling ``MPI_Abort()`` or ``exit()`` directly.  Warnings and
+informational messages should be printed only on MPI rank 0 to avoid
+flooding the output when running in parallel with many MPI processes.
+
+**Errors**
+
+When LAMMPS encounters an error, for example a syntax error in the
+input, then a suitable error message should be printed giving a brief,
+one line remark about the reason and then call either ``Error::all()``
+or ``Error::one()``.  ``Error::all()`` must be called when the failing
+code path is executed by *all* MPI processes and the error condition
+will appear for *all* MPI processes the same.  If desired, each MPI
+process may set a flag to either 0 or 1 and then MPI_Allreduce()
+searching for the maximum can be used to determine if there was an error
+on *any* of the MPI processes and make this information available to
+*all*.  ``Error::one()`` in contrast needs to be called when only one or
+a few MPI processes execute the code path or can have the error
+condition.  ``Error::all()`` is generally the preferred option.
+
+Calling these functions does not abort LAMMPS directly, but rather
+throws either a ``LAMMPSException`` (from ``Error::all()``) or a
+``LAMMPSAbortException`` (from ``Error::one()``).  These exceptions are
+caught by the LAMMPS ``main()`` program and then handled accordingly.
+The reason for this approach is to support applications, especially
+graphical applications like :ref:`LAMMPS-GUI <lammps_gui>`, that are
+linked to the LAMMPS library and have a mechanism to avoid that an error
+in LAMMPS terminates the application. By catching the exceptions, the
+application can delete the failing LAMMPS class instance and create a
+new one to try again.  In a similar fashion, the :doc:`LAMMPS Python
+module <Python_module>` checks for this and then re-throws corresponding
+Python exception, which in turn can be caught by the calling Python
+code.
+
+There are multiple "signatures" that can be called:
+
+- ``Error::all(FLERR, "Error message")``: this will abort LAMMPS with
+  the error message "Error message", followed by the last line of input
+  that was read and processed before the error condition happened.
+
+- ``Error::all(FLERR, Error::NOLASTLINE, "Error message")``: this is the
+  same as before but without the last line of input.  This is preferred
+  for errors that would happen *during* a :doc:`run <run>` or
+  :doc:`minimization <minimize>`, since showing the "run" or "minimize"
+  command would be the last line, but is unrelated to the error.
+
+- ``Error::all(FLERR, idx, "Error message")``: this is for argument
+  parsing where "idx" is the index (starting at 0) of the argument for a
+  LAMMPS command that is causing the failure (use -1 for the command
+  itself).  The output may also include the last input line *before* and
+  *after*, if they differ due to substituting variables.  A textual
+  indicator is pointing to the specific word that failed.  Using the
+  constant ``Error::NOPOINTER`` in place of the *idx* argument will
+  suppress the marker and then the behavior is like the *idx* argument
+  is not provided.
+
+FLERR is a macro containing the filename and line where the Error class
+is called and that information is appended to the error message.  This
+allows to quickly find the relevant source code causing the error.  For
+all three signatures, the single string "Error message" may be replaced
+with a format string using '{}' placeholders and followed by a variable
+number of arguments, one for each placeholder. This format string and
+the arguments are then handed for formatting to the `{fmt} library
+<https://fmt.dev>`_ (which is bundled with LAMMPS) and thus allow
+processing similar to the "format()" functionality in Python.
+
+.. note::
+
+   For commands like :doc:`fix ave/time <fix_ave_time>` that accept
+   wildcard arguments, the :cpp:func:`utils::expand_args` function
+   may be passed as an optional argument where the function will provide
+   a map to the original arguments from the expanded argument indices.
+
+For complex errors, that can have multiple causes and which cannot be
+explained in a single line, you can append to the error message, the
+string created by :cpp:func:`utils::errorurl`, which then provides a
+URL pointing to a paragraph of the :doc:`Errors_details` that
+corresponds to the number provided. Example:
+
+.. code-block:: c++
+
+   error->all(FLERR, "Unknown identifier in data file: {}{}", keyword, utils::errorurl(1));
+
+This will output something like this:
+
+.. parsed-literal::
+
+   ERROR: Unknown identifier in data file: Massess
+   For more information see https://docs.lammps.org/err0001 (src/read_data.cpp:1482)
+   Last input line: read_data       data.peptide
+
+Where the URL points to the first paragraph with explanations on
+the :doc:`Errors_details` page in the manual.
+
+**Warnings**
+
+To print warnings, the ``Errors::warning()`` function should be used.
+It also requires the FLERR macros as first argument to easily identify
+the location of the warning in the source code.  Same as with the error
+functions above, the function has two variants: one just taking a single
+string as final argument and a second that uses the `{fmt} library
+<https://fmt.dev>`_ to make it similar to, say, ``fprintf()``.  One
+motivation to use this function is that it will output warnings with
+always the same capitalization of the leading "WARNING" string.  A
+second is that it has a built in rate limiter.  After a given number (by
+default 100), that can be set via the :doc:`thermo_modify command
+<thermo_modify>` no more warnings are printed.  Also, warnings are
+written consistently to both screen and logfile or not, depending on the
+settings for :ref:`screen <screen>` or :doc:`logfile <log>` output.
+
+.. note::
+
+   Unlike ``Error::all()``, the warning function will produce output on
+   *every* MPI process, so it typically would be prefixed with an if
+   statement testing for ``comm->me == 0``, i.e. limiting output to MPI
+   rank 0.
+
+**Informational messages**
+
+Finally, for informational message LAMMPS has the
+:cpp:func:`utils::logmesg() convenience function
+<LAMMPS_NS::utils::logmesg>`.  It also uses the `{fmt} library
+<https://fmt.dev>`_ to support using a format string followed by a
+matching number of arguments.  It will output the resulting formatted
+text to both, the screen and the logfile and will honor the
+corresponding settings about whether this output is active and to which
+file it should be send.  Same as for ``Error::warning()``, it would
+produce output for every MPI process and thus should usually be called
+only on MPI rank 0 to avoid flooding the output when running with many
+parallel processes.
+
 Choosing between a custom atom style, fix property/atom, and fix STORE/ATOM
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 

doc/src/Developer_org.rst

@@ -94,12 +94,12 @@ represents what is generally referred to as an "instance of LAMMPS".  It
 is a composite holding pointers to instances of other core classes
 providing the core functionality of the MD engine in LAMMPS and through
 them abstractions of the required operations.  The constructor of the
-LAMMPS class will instantiate those instances, process the command line
+LAMMPS class will instantiate those instances, process the command-line
 flags, initialize MPI (if not already done) and set up file pointers for
 input and output.  The destructor will shut everything down and free all
 associated memory.  Thus code for the standalone LAMMPS executable in
 ``main.cpp`` simply initializes MPI, instantiates a single instance of
-LAMMPS while passing it the command line flags and input script. It
+LAMMPS while passing it the command-line flags and input script. It
 deletes the LAMMPS instance after the method reading the input returns
 and shuts down the MPI environment before it exits the executable.
 

doc/src/Developer_unittest.rst

@@ -227,12 +227,12 @@ Tests for the C-style library interface
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Tests for validating the LAMMPS C-style library interface are in the
-``unittest/c-library`` folder.  They are implemented either to be used
+``unittest/c-library`` folder.  They text either utility functions or
-for utility functions or for LAMMPS commands, but use the functions
+LAMMPS commands, but use the functions implemented in
-implemented in the ``src/library.cpp`` file as much as possible.  There
+``src/library.cpp`` as much as possible.  There may be some overlap with
-may be some overlap with other tests, but only in as much as is required
+other tests as far as the LAMMPS functionality is concerned, but the
-to test the C-style library API.  The tests are distributed over
+focus is on testing the C-style library API.  The tests are distributed
-multiple test programs which try to match the grouping of the
+over multiple test programs which try to match the grouping of the
 functions in the source code and :ref:`in the manual <lammps_c_api>`.
 
 This group of tests also includes tests invoking LAMMPS in parallel
@@ -258,7 +258,7 @@ Tests for the Python module and package
 
 The ``unittest/python`` folder contains primarily tests for classes and
 functions in the LAMMPS python module but also for commands in the
-PYTHON package.  These tests are only enabled if the necessary
+PYTHON package.  These tests are only enabled, if the necessary
 prerequisites are detected or enabled during configuration and
 compilation of LAMMPS (shared library build enabled, Python interpreter
 found, Python development files found).
@@ -272,29 +272,30 @@ Tests for the Fortran interface
 
 Tests for using the Fortran module are in the ``unittest/fortran``
 folder.  Since they are also using the GoogleTest library, they require
-implementing test wrappers in C++ that will call fortran functions
+test wrappers written in C++ that will call fortran functions with a C
-which provide a C function interface through ISO_C_BINDINGS that will in
+function interface through ISO_C_BINDINGS which will in turn call the
-turn call the functions in the LAMMPS Fortran module.
+functions in the LAMMPS Fortran module.
 
 Tests for the C++-style library interface
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 The tests in the ``unittest/cplusplus`` folder are somewhat similar to
 the tests for the C-style library interface, but do not need to test the
-several convenience and utility functions that are only available through
+convenience and utility functions that are only available through the
-the C-style interface.  Instead it can focus on the more generic features
+C-style library interface.  Instead they focus on the more generic
-that are used internally.  This part of the unit tests is currently still
+features that are used in LAMMPS internally.  This part of the unit
-mostly in the planning stage.
+tests is currently still mostly in the planning stage.
 
 Tests for reading and writing file formats
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 The ``unittest/formats`` folder contains test programs for reading and
-writing files like data files, restart files, potential files or dump files.
+writing files like data files, restart files, potential files or dump
-This covers simple things like the file i/o convenience functions in the
+files.  This covers simple things like the file i/o convenience
-``utils::`` namespace to complex tests of atom styles where creating and
+functions in the ``utils::`` namespace to complex tests of atom styles
-deleting atoms with different properties is tested in different ways
+where creating and deleting of atoms with different properties is tested
-and through script commands or reading and writing of data or restart files.
+in different ways and through script commands or reading and writing of
+data or restart files.
 
 Tests for styles computing or modifying forces
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -443,7 +444,7 @@ file for a style that is similar to one to be tested.  The file name should
 follow the naming conventions described above and after copying the file,
 the first step is to replace the style names where needed.  The coefficient
 values do not have to be meaningful, just in a reasonable range for the
-given system.  It does not matter if some forces are large, as long as
+given system.  It does not matter if some forces are large, for as long as
 they do not diverge.
 
 The template input files define a large number of index variables at the top
@@ -476,7 +477,7 @@ the tabulated coulomb, to test both code paths.  The reference results in the YA
 files then should be compared manually, if they agree well enough within the limits
 of those two approximations.
 
-The ``test_pair_style`` and equivalent programs have special command line options
+The ``test_pair_style`` and equivalent programs have special command-line options
 to update the YAML files. Running a command like
 
 .. code-block:: bash
@@ -531,19 +532,20 @@ Python module.
 Troubleshooting failed unit tests
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-The are by default no unit tests for newly added features (e.g. pair, fix,
+There are by default no unit tests for newly added features (e.g. pair,
-or compute styles) unless your pull request also includes tests for the
+fix, or compute styles) unless your pull request also includes tests for
-added features.  If you are modifying some features, you may see failures
+these added features.  If you are modifying some existing LAMMPS
-for existing tests, if your modifications have some unexpected side effects
+features, you may see failures for existing tests, if your modifications
-or your changes render the existing test invalid.  If you are adding an
+have some unexpected side effects or your changes render the existing
-accelerated version of an existing style, then only tests for INTEL,
+test invalid.  If you are adding an accelerated version of an existing
-KOKKOS (with OpenMP only), OPENMP, and OPT will be run automatically.
+style, then only tests for INTEL, KOKKOS (with OpenMP only), OPENMP, and
-Tests for the GPU package are time consuming and thus are only run
+OPT will be run automatically.  Tests for the GPU package are time
-*after* a merge, or when a special label, ``gpu_unit_tests`` is added
+consuming and thus are only run *after* a merge, or when a special
-to the pull request.  After the test has started, it is often best to
+label, ``gpu_unit_tests`` is added to the pull request.  After the test
-remove the label since every PR activity will re-trigger the test (that
+has started, it is often best to remove the label since every PR
-is a limitation of triggering a test with a label).  Support for unit
+activity will re-trigger the test (that is a limitation of triggering a
-tests when using KOKKOS with GPU acceleration is currently not supported.
+test with a label).  Support for unit tests using KOKKOS with GPU
+acceleration is currently not supported.
 
 When you see a failed build on GitHub, click on ``Details`` to be taken
 to the corresponding LAMMPS Jenkins CI web page.  Click on the "Exit"
@@ -588,7 +590,7 @@ While the epsilon (relative precision) for a single, `IEEE 754 compliant
 <https://en.wikipedia.org/wiki/IEEE_754>`_, double precision floating
 point operation is at about 2.2e-16, the achievable precision for the
 tests is lower due to most numbers being sums over intermediate results
-and the non-associativity of floating point math leading to larger
+for which the non-associativity of floating point math leads to larger
 errors.  As a rule of thumb, the test epsilon can often be in the range
 5.0e-14 to 1.0e-13.  But for "noisy" force kernels, e.g. those a larger
 amount of arithmetic operations involving `exp()`, `log()` or `sin()`
@@ -602,14 +604,14 @@ of floating point operations or that some or most intermediate operations
 may be done using approximations or with single precision floating point
 math.
 
-To rerun the failed unit test individually, change to the ``build`` directory
+To rerun a failed unit test individually, change to the ``build`` directory
 and run the test with verbose output. For example,
 
 .. code-block:: bash
 
     env TEST_ARGS=-v ctest -R ^MolPairStyle:lj_cut_coul_long -V
 
-``ctest`` with the ``-V`` flag also shows the exact command line
+``ctest`` with the ``-V`` flag also shows the exact command
 of the test. One can then use ``gdb --args`` to further debug and
 catch exceptions with the test command, for example,
 

doc/src/Developer_utils.rst

@@ -133,6 +133,9 @@ and parsing files or arguments.
 .. doxygenfunction:: trim_comment
    :project: progguide
 
+.. doxygenfunction:: strcompress
+   :project: progguide
+
 .. doxygenfunction:: strip_style_suffix
    :project: progguide
 
@@ -166,6 +169,9 @@ and parsing files or arguments.
 .. doxygenfunction:: split_lines
    :project: progguide
 
+.. doxygenfunction:: strsame
+   :project: progguide
+
 .. doxygenfunction:: strmatch
    :project: progguide
 
@@ -232,12 +238,21 @@ Convenience functions
 .. doxygenfunction:: logmesg(LAMMPS *lmp, const std::string &mesg)
    :project: progguide
 
+.. doxygenfunction:: print(FILE *fp, const std::string &format, Args&&... args)
+   :project: progguide
+
+.. doxygenfunction:: print(FILE *fp, const std::string &mesg)
+   :project: progguide
+
 .. doxygenfunction:: errorurl
    :project: progguide
 
 .. doxygenfunction:: missing_cmd_args
    :project: progguide
 
+.. doxygenfunction:: point_to_error
+   :project: progguide
+
 .. doxygenfunction:: flush_buffers(LAMMPS *lmp)
    :project: progguide
 

doc/src/Developer_write_fix.rst

@@ -96,8 +96,8 @@ Here the we specify which methods of the fix should be called during
      MPI_Allreduce(localAvgVel, globalAvgVel, 4, MPI_DOUBLE, MPI_SUM, world);
      scale3(1.0 / globalAvgVel[3], globalAvgVel);
      if ((comm->me == 0) && screen) {
-       fmt::print(screen,"{}, {}, {}\n",
+       utils::print(screen, "{}, {}, {}\n",
-                  globalAvgVel[0], globalAvgVel[1], globalAvgVel[2]);
+                    globalAvgVel[0], globalAvgVel[1], globalAvgVel[2]);
      }
    }
 

doc/src/Developer_write_pair.rst

@@ -310,7 +310,7 @@ the constructor and the destructor.
 
 Pair styles are different from most classes in LAMMPS that define a
 "style", as their constructor only uses the LAMMPS class instance
-pointer as an argument, but **not** the command line arguments of the
+pointer as an argument, but **not** the arguments of the
 :doc:`pair_style command <pair_style>`.  Instead, those arguments are
 processed in the ``Pair::settings()`` function (or rather the version in
 the derived class).  The constructor is the place where global defaults
@@ -891,7 +891,7 @@ originally created from mixing or not).
 These data file output functions are only useful for true pair-wise
 additive potentials, where the potential parameters can be entered
 through *multiple* :doc:`pair_coeff commands <pair_coeff>`.  Pair styles
-that require a single "pair_coeff \* \*" command line are not compatible
+that require a single "pair_coeff \* \*" command are not compatible
 with reading their parameters from data files.  For pair styles like
 *born/gauss* that do support writing to data files, the potential
 parameters will be read from the data file, if present, and
@@ -1122,7 +1122,7 @@ once.  Thus, the ``coeff()`` function has to do three tasks, each of
 which is delegated to a function in the ``PairTersoff`` class:
 
 #. map elements to atom types.  Those follow the potential file name in the
-   command line arguments and are processed by the ``map_element2type()`` function.
+   command arguments and are processed by the ``map_element2type()`` function.
 #. read and parse the potential parameter file in the ``read_file()`` function.
 #. Build data structures where the original and derived parameters are
    indexed by all possible triples of atom types and thus can be looked
@@ -1356,8 +1356,8 @@ either 0 or 1.
 
 The ``morseflag`` variable defaults to 0 and is set to 1 in the
 ``PairAIREBOMorse::settings()`` function which is called by the
-:doc:`pair_style <pair_style>` command.  This function delegates
+:doc:`pair_style <pair_style>` command.  This function delegates all
-all command line processing and setting of other parameters to the
+command argument processing and setting of other parameters to the
 ``PairAIREBO::settings()`` function of the base class.
 
 .. code-block:: c++

doc/src/Errors_debug.rst

@@ -83,7 +83,7 @@ Run LAMMPS from within the debugger
 Running LAMMPS under the control of the debugger as shown below only
 works for a single MPI rank (for debugging a program running in parallel
 you usually need a parallel debugger program).  A simple way to launch
-GDB is to prefix the LAMMPS command line with ``gdb --args`` and then
+GDB is to prefix the LAMMPS command-line with ``gdb --args`` and then
 type the command "run" at the GDB prompt.  This will launch the
 debugger, load the LAMMPS executable and its debug info, and then run
 it.  When it reaches the code causing the segmentation fault, it will
@@ -180,7 +180,7 @@ inspect the behavior of a compiled program by essentially emulating a
 CPU and instrumenting the program while running.  This slows down
 execution quite significantly, but can also report issues that are not
 resulting in a crash.  The default valgrind tool is a memory checker and
-you can use it by prefixing the normal command line with ``valgrind``.
+you can use it by prefixing the normal command-line with ``valgrind``.
 Unlike GDB, this will also work for parallel execution, but it is
 recommended to redirect the valgrind output to a file (e.g. with
 ``--log-file=crash-%p.txt``, the %p will be substituted with the
@@ -235,3 +235,53 @@ from GDB. In addition you get a more specific hint about what cause the
 segmentation fault, i.e. that it is a NULL pointer dereference.  To find
 out which pointer exactly was NULL, you need to use the debugger, though.
 
+Debugging when LAMMPS appears to be stuck
+=========================================
+
+Sometimes the LAMMPS calculation appears to be stuck, that is the LAMMPS
+process or processes are active, but there is no visible progress.  This
+can have multiple reasons:
+
+- The selected styles are slow and require a lot of CPU time and the
+  system is large. When extrapolating the expected speed from smaller
+  systems, one has to factor in that not all models scale linearly with
+  system size, e.g. :doc:`kspace styles like ewald or pppm
+  <kspace_style>`. There is very little that can be done in this case.
+- The output interval is not set or set to a large value with the
+  :doc:`thermo <thermo>` command. I the first case, there will be output
+  only at the first and last step.
+- The output is block-buffered and instead of line-buffered. The output
+  will only be written to the screen after 4096 or 8192 characters of
+  output have accumulated.  This most often happens for files but also
+  with MPI parallel executables for output to the screen, since the
+  output to the screen is handled by the MPI library so that output from
+  all processes can be shown.  This can be suppressed by using the
+  ``-nonblock`` or ``-nb`` command-line flag, which turns off buffering
+  for screen and logfile output.
+- An MPI parallel calculation has a bug where a collective MPI function
+  is called (e.g. ``MPI_Barrier()``, ``MPI_Bcast()``,
+  ``MPI_Allreduce()`` and so on) before pending point-to-point
+  communications are completed or when the collective function is only
+  called from a subset of the MPI processes.  This also applies to some
+  internal LAMMPS functions like ``Error::all()`` which uses
+  ``MPI_Barrier()`` and thus ``Error::one()`` must be called, if the
+  error condition does not happen on all MPI processes simultaneously.
+- Some function in LAMMPS has a bug where a ``for`` or ``while`` loop
+  does not trigger the exit condition and thus will loop forever.  This
+  can happen when the wrong variable is incremented or when one value in
+  a comparison becomes ``NaN`` due to an overflow.
+
+In the latter two cases, further information and stack traces (see above)
+can be obtain by attaching a debugger to a running process.  For that the
+process ID (PID) is needed; this can be found on Linux machines with the
+``top``, ``htop``, ``ps``, or ``pstree`` commands.
+
+Then running the (GNU) debugger ``gdb`` with the ``-p`` flag followed by
+the process id will attach the process to the debugger and stop
+execution of that specific process.  From there on it is possible to
+issue all debugger commands in the same way as when LAMMPS was started
+from the debugger (see above).  Most importantly it is possible to
+obtain a stack trace with the ``where`` command and thus determine where
+in the execution of a timestep this process is.  Also internal data can
+be printed and execution single stepped or continued.  When the debugger
+is exited, the calculation will resume normally.

doc/src/Errors_messages.rst

@@ -7774,7 +7774,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
 *Too few values in body section of molecule file*
    Self-explanatory.
 
-*Too many -pk arguments in command line*
+*Too many -pk arguments in command-line*
    The string formed by concatenating the arguments is too long.  Use a
    package command in the input script instead.
 

doc/src/Examples.rst

@@ -146,6 +146,8 @@ Lowercase directories
 +-------------+------------------------------------------------------------------+
 | streitz     | use of Streitz/Mintmire potential with charge equilibration      |
 +-------------+------------------------------------------------------------------+
+| stress_vcm  | removing binned rigid body motion from binned stress profile     |
++-------------+------------------------------------------------------------------+
 | tad         | temperature-accelerated dynamics of vacancy diffusion in bulk Si |
 +-------------+------------------------------------------------------------------+
 | threebody   | regression test input for a variety of manybody potentials       |

doc/src/Fortran.rst

@@ -16,7 +16,7 @@ compiled alongside the code using it from the source code in
 ``fortran/lammps.f90`` *and* with the same compiler used to build the
 rest of the Fortran code that interfaces to LAMMPS.  When linking, you
 also need to :doc:`link to the LAMMPS library <Build_link>`.  A typical
-command line for a simple program using the Fortran interface would be:
+command for a simple program using the Fortran interface would be:
 
 .. code-block:: bash
 
@@ -91,12 +91,12 @@ function and triggered with the optional logical argument set to
      CALL lmp%close(.TRUE.)
    END PROGRAM testlib
 
-It is also possible to pass command line flags from Fortran to C/C++ and
+It is also possible to pass command-line flags from Fortran to C/C++ and
 thus make the resulting executable behave similarly to the standalone
 executable (it will ignore the `-in/-i` flag, though).  This allows
-using the command line to configure accelerator and suffix settings,
+using the command-line to configure accelerator and suffix settings,
 configure screen and logfile output, or to set index style variables
-from the command line and more.  Here is a correspondingly adapted
+from the command-line and more.  Here is a correspondingly adapted
 version of the previous example:
 
 .. code-block:: fortran
@@ -108,7 +108,7 @@ version of the previous example:
      CHARACTER(LEN=128), ALLOCATABLE :: command_args(:)
      INTEGER :: i, argc
 
-     ! copy command line flags to `command_args()`
+     ! copy command-line flags to `command_args()`
      argc = COMMAND_ARGUMENT_COUNT()
      ALLOCATE(command_args(0:argc))
      DO i=0, argc
@@ -321,6 +321,14 @@ of the contents of the :f:mod:`LIBLAMMPS` Fortran interface to LAMMPS.
    :ftype set_string_variable: subroutine
    :f set_internal_variable: :f:subr:`set_internal_variable`
    :ftype set_internal_variable: subroutine
+   :f eval: :f:func:`eval`
+   :ftype eval: function
+   :f clearstep_compute: :f:subr:`clearstep_compute`
+   :ftype clearstep_compute: subroutine
+   :f addstep_compute: :f:subr:`addstep_compute`
+   :ftype addstep_compute: subroutine
+   :f addstep_compute_all: :f:subr:`addstep_compute_all`
+   :ftype addstep_compute_all: subroutine
    :f gather_atoms: :f:subr:`gather_atoms`
    :ftype gather_atoms: subroutine
    :f gather_atoms_concat: :f:subr:`gather_atoms_concat`
@@ -448,7 +456,7 @@ of the contents of the :f:mod:`LIBLAMMPS` Fortran interface to LAMMPS.
    compiled with MPI support, it will also initialize MPI, if it has
    not already been initialized before.
 
-   The *args* argument with the list of command line parameters is
+   The *args* argument with the list of command-line parameters is
    optional and so it the *comm* argument with the MPI communicator.
    If *comm* is not provided, ``MPI_COMM_WORLD`` is assumed. For
    more details please see the documentation of :cpp:func:`lammps_open`.
@@ -954,6 +962,7 @@ Procedures Bound to the :f:type:`lammps` Derived Type
       :f:func:`extract_atom` between runs.
 
    .. admonition:: Array index order
+      :class: tip
 
       Two-dimensional arrays returned from :f:func:`extract_atom` will be
       **transposed** from equivalent arrays in C, and they will be indexed
@@ -1066,6 +1075,7 @@ Procedures Bound to the :f:type:`lammps` Derived Type
    you based on data from the :cpp:class:`Compute` class.
 
    .. admonition:: Array index order
+      :class: tip
 
       Two-dimensional arrays returned from :f:func:`extract_compute` will be
       **transposed** from equivalent arrays in C, and they will be indexed
@@ -1324,6 +1334,7 @@ Procedures Bound to the :f:type:`lammps` Derived Type
    :rtype data: polymorphic
 
    .. admonition:: Array index order
+      :class: tip
 
       Two-dimensional global, per-atom, or local array data from
       :f:func:`extract_fix` will be **transposed** from equivalent arrays in
@@ -1448,11 +1459,62 @@ Procedures Bound to the :f:type:`lammps` Derived Type
    an internal-style variable, an error is generated.
 
    :p character(len=*) name: name of the variable
-   :p read(c_double) val:  new value to assign to the variable
+   :p real(c_double) val:  new value to assign to the variable
    :to: :cpp:func:`lammps_set_internal_variable`
 
 --------
 
+.. f:function:: eval(expr)
+
+   This function is a wrapper around :cpp:func:`lammps_eval` that takes a
+   LAMMPS equal style variable string, evaluates it and returns the resulting
+   scalar value as a floating-point number.
+
+   .. versionadded:: TBD
+
+   :p character(len=\*) expr: string to be evaluated
+   :to: :cpp:func:`lammps_eval`
+   :r value [real(c_double)]: result of the evaluated string
+
+--------
+
+.. f:subroutine:: clearstep_compute()
+
+   Clear whether a compute has been invoked
+
+   .. versionadded:: TBD
+
+   :to: :cpp:func:`lammps_clearstep_compute`
+
+--------
+
+.. f:subroutine:: addstep_compute(nextstep)
+
+   Add timestep to list of future compute invocations
+   if the compute has been invoked on the current timestep
+
+   .. versionadded:: TBD
+
+   overloaded for 32-bit and 64-bit integer arguments
+
+   :p integer(kind=8 or kind=4) nextstep: next timestep
+   :to: :cpp:func:`lammps_addstep_compute`
+
+--------
+
+.. f:subroutine:: addstep_compute_all(nextstep)
+
+   Add timestep to list of future compute invocations
+
+   .. versionadded:: TBD
+
+   overloaded for 32-bit and 64-bit integer arguments
+
+   :p integer(kind=8 or kind=4) nextstep: next timestep
+   :to: :cpp:func:`lammps_addstep_compute_all`
+
+--------
+
 .. f:subroutine:: gather_atoms(name, count, data)
 
    This function calls :cpp:func:`lammps_gather_atoms` to gather the named

doc/src/Howto.rst

@@ -103,6 +103,7 @@ Tutorials howto
    Howto_github
    Howto_lammps_gui
    Howto_moltemplate
+   Howto_python
    Howto_pylammps
    Howto_wsl
 

doc/src/Howto_barostat.rst

@@ -10,20 +10,21 @@ and/or pressure (P) is specified by the user, and the thermostat or
 barostat attempts to equilibrate the system to the requested T and/or
 P.
 
-Barostatting in LAMMPS is performed by :doc:`fixes <fix>`.  Two
+Barostatting in LAMMPS is performed by :doc:`fixes <fix>`.  Three
 barostatting methods are currently available: Nose-Hoover (npt and
-nph) and Berendsen:
+nph), Berendsen, and various linear controllers in deform/pressure:
 
 * :doc:`fix npt <fix_nh>`
 * :doc:`fix npt/sphere <fix_npt_sphere>`
 * :doc:`fix npt/asphere <fix_npt_asphere>`
 * :doc:`fix nph <fix_nh>`
 * :doc:`fix press/berendsen <fix_press_berendsen>`
+* :doc:`fix deform/pressure <fix_deform_pressure>`
 
 The :doc:`fix npt <fix_nh>` commands include a Nose-Hoover thermostat
 and barostat.  :doc:`Fix nph <fix_nh>` is just a Nose/Hoover barostat;
-it does no thermostatting.  Both :doc:`fix nph <fix_nh>` and :doc:`fix press/berendsen <fix_press_berendsen>` can be used in conjunction
+it does no thermostatting.  The fixes :doc:`nph <fix_nh>`, :doc:`press/berendsen <fix_press_berendsen>`, and :doc:`deform/pressure <fix_deform_pressure>`
-with any of the thermostatting fixes.
+can be used in conjunction with any of the thermostatting fixes.
 
 As with the :doc:`thermostats <Howto_thermostat>`, :doc:`fix npt <fix_nh>`
 and :doc:`fix nph <fix_nh>` only use translational motion of the
@@ -44,9 +45,9 @@ a temperature or pressure compute to a barostatting fix.
 .. note::
 
    As with the thermostats, the Nose/Hoover methods (:doc:`fix npt <fix_nh>` and :doc:`fix nph <fix_nh>`) perform time integration.
-   :doc:`Fix press/berendsen <fix_press_berendsen>` does NOT, so it should
+   :doc:`Fix press/berendsen <fix_press_berendsen>` and :doc:`fix deform/pressure <fix_deform_pressure>`
-   be used with one of the constant NVE fixes or with one of the NVT
+   do NOT, so they should be used with one of the constant NVE fixes or with
-   fixes.
+   one of the NVT fixes.
 
 Thermodynamic output, which can be setup via the
 :doc:`thermo_style <thermo_style>` command, often includes pressure

doc/src/Howto_cmake.rst

@@ -56,7 +56,7 @@ using a shell like Bash or Zsh.
    Visual Studio IDE with the bundled CMake or from the Windows command prompt using
    a separately installed CMake package, both using the native Microsoft Visual C++
    compilers and (optionally) the Microsoft MPI SDK.  This tutorial, however, only
-   covers unix-like command line interfaces.
+   covers unix-like command-line interfaces.
 
 We also assume that you have downloaded and unpacked a recent LAMMPS source code package
 or used Git to create a clone of the LAMMPS sources on your compilation machine.
@@ -277,7 +277,7 @@ Setting options
 ---------------
 
 Options that enable, disable or modify settings are modified by setting
-the value of CMake variables. This is done on the command line with the
+the value of CMake variables. This is done on the command-line with the
 *-D* flag in the format ``-D VARIABLE=value``, e.g. ``-D
 CMAKE_BUILD_TYPE=Release`` or ``-D BUILD_MPI=on``.  There is one quirk:
 when used before the CMake directory, there may be a space between the
@@ -376,7 +376,7 @@ Using presets
 -------------
 
 Since LAMMPS has a lot of optional features and packages, specifying
-them all on the command line can be tedious. Or when selecting a
+them all on the command-line can be tedious. Or when selecting a
 different compiler toolchain, multiple options have to be changed
 consistently and that is rather error prone. Or when enabling certain
 packages, they require consistent settings to be operated in a
@@ -384,7 +384,7 @@ particular mode.  For this purpose, we are providing a selection of
 "preset files" for CMake in the folder ``cmake/presets``.  They
 represent a way to pre-load or override the CMake configuration cache by
 setting or changing CMake variables.  Preset files are loaded using the
-*-C* command line flag. You can combine loading multiple preset files or
+*-C* command-line flag. You can combine loading multiple preset files or
 change some variables later with additional *-D* flags.  A few examples:
 
 .. code-block:: bash

doc/src/Howto_github.rst

@@ -163,7 +163,7 @@ After everything is done, add the files to the branch and commit them:
    *git rm*, *git mv* for adding, removing, renaming individual files,
    respectively, and then *git commit* to finalize the commit.
    Carefully check all pending changes with *git status* before
-   committing them.  If you find doing this on the command line too
+   committing them.  If you find doing this on the command-line too
    tedious, consider using a GUI, for example the one included in git
    distributions written in Tk, i.e. use *git gui* (on some Linux
    distributions it may be required to install an additional package to

doc/src/Howto_lammps_gui.rst

@@ -20,8 +20,11 @@ to the online LAMMPS documentation for known LAMMPS commands and styles.
    (Ubuntu 20.04LTS or later and compatible), macOS (version 11 aka Big
    Sur or later), and Windows (version 10 or later) :ref:`are available
    <lammps_gui_install>` for download.  Non-MPI LAMMPS executables (as
-   ``lmp``) for running LAMMPS from the command line and :doc:`some
+   ``lmp``) for running LAMMPS from the command-line and :doc:`some
    LAMMPS tools <Tools>` compiled executables are also included.
+   Also, the pre-compiled LAMMPS-GUI packages include the WHAM executables
+   from http://membrane.urmc.rochester.edu/content/wham/ for use with
+   LAMMPS tutorials.
 
    The source code for LAMMPS-GUI is included in the LAMMPS source code
    distribution and can be found in the ``tools/lammps-gui`` folder.  It
@@ -29,16 +32,16 @@ to the online LAMMPS documentation for known LAMMPS commands and styles.
    <Build_cmake>`.
 
 LAMMPS-GUI tries to provide an experience similar to what people
-traditionally would have running LAMMPS using a command line window and
+traditionally would have running LAMMPS using a command-line window and
 the console LAMMPS executable but just rolled into a single executable:
 
 - writing & editing LAMMPS input files with a text editor
-- run LAMMPS on those input file with selected command line flags
+- run LAMMPS on those input file with selected command-line flags
 - extract data from the created files and visualize it with and
   external software
 
 That procedure is quite effective for people proficient in using the
-command line, as that allows them to use tools for the individual steps
+command-line, as that allows them to use tools for the individual steps
 that they are most comfortable with.  In fact, it is often *required* to
 adopt this workflow when running LAMMPS simulations on high-performance
 computing facilities.
@@ -61,13 +64,18 @@ simple LAMMPS simulations.  It is very suitable for tutorials on LAMMPS
 since you only need to learn how to use a single program for most tasks
 and thus time can be saved and people can focus on learning LAMMPS.
 The tutorials at https://lammpstutorials.github.io/ are specifically
-updated for use with LAMMPS-GUI.
+updated for use with LAMMPS-GUI and can their tutorial materials can
+be downloaded and loaded directly from the GUI.
 
 Another design goal is to keep the barrier low when replacing part of
 the functionality of LAMMPS-GUI with external tools.  That said, LAMMPS-GUI
 has some unique functionality that is not found elsewhere:
 
 - auto-adapting to features available in the integrated LAMMPS library
+- auto-completion for LAMMPS commands and options
+- context-sensitive online help
+- start and stop of simulations via mouse or keyboard
+- monitoring of simulation progress
 - interactive visualization using the :doc:`dump image <dump_image>`
   command with the option to copy-paste the resulting settings
 - automatic slide show generation from dump image out at runtime
@@ -100,10 +108,11 @@ MacOS 11 and later
 ^^^^^^^^^^^^^^^^^^
 
 After downloading the ``LAMMPS-macOS-multiarch-GUI-<version>.dmg``
-installer package, you need to double-click it and then, in the window
+application bundle disk image, you need to double-click it and then, in
-that opens, drag the app bundle as indicated into the "Applications"
+the window that opens, drag the app bundle as indicated into the
-folder.  The follow the instructions in the "README.txt" file to
+"Applications" folder.  Afterwards, the disk image can be unmounted.
-get access to the other included executables.
+Then follow the instructions in the "README.txt" file to get access to
+the other included command-line executables.
 
 Linux on x86\_64
 ^^^^^^^^^^^^^^^^
@@ -117,15 +126,25 @@ into the "LAMMPS_GUI" folder and execute "./lammps-gui" directly.
 
 The second variant uses `flatpak <https://www.flatpak.org>`_ and
 requires the flatpak management and runtime software to be installed.
-After downloading the ``LAMMPS-GUI-Linux-x86_64-GUI-<version>.tar.gz``
+After downloading the ``LAMMPS-GUI-Linux-x86_64-GUI-<version>.flatpak``
 flatpak bundle, you can install it with ``flatpak install --user
-LAMMPS-GUI-Linux-x86_64-GUI-<version>.tar.gz``.  After installation,
+LAMMPS-GUI-Linux-x86_64-GUI-<version>.flatpak``.  After installation,
 LAMMPS-GUI should be integrated into your desktop environment under
 "Applications > Science" but also can be launched from the console with
 ``flatpak run org.lammps.lammps-gui``.  The flatpak bundle also includes
 the console LAMMPS executable ``lmp`` which can be launched to run
-simulations with, for example: ``flatpak run --command=lmp
+simulations with, for example with:
-org.lammps.lammps-gui -in in.melt``.
+
+.. code-block:: sh
+
+   flatpak run --command=lmp org.lammps.lammps-gui -in in.melt
+
+Other bundled command-line executables are run the same way and can be
+listed with:
+
+.. code-block:: sh
+
+   ls $(flatpak info --show-location org.lammps.lammps-gui )/files/bin
 
 
 Compiling from Source
@@ -165,9 +184,9 @@ window is stored when exiting and restored when starting again.
 Opening Files
 ^^^^^^^^^^^^^
 
-The LAMMPS-GUI application can be launched without command line arguments
+The LAMMPS-GUI application can be launched without command-line arguments
 and then starts with an empty buffer in the *Editor* window.  If arguments
-are given LAMMPS will use first command line argument as the file name for
+are given LAMMPS will use first command-line argument as the file name for
 the *Editor* buffer and reads its contents into the buffer, if the file
 exists.  All further arguments are ignored.  Files can also be opened via
 the *File* menu, the `Ctrl-O` (`Command-O` on macOS) keyboard shortcut
@@ -261,14 +280,21 @@ Output Window
 
 By default, when starting a run, an *Output* window opens that displays
 the screen output of the running LAMMPS calculation, as shown below.
-This text would normally be seen in the command line window.
+This text would normally be seen in the command-line window.
 
 .. image:: JPG/lammps-gui-log.png
    :align: center
    :scale: 50%
 
 LAMMPS-GUI captures the screen output from LAMMPS as it is generated and
-updates the *Output* window regularly during a run.
+updates the *Output* window regularly during a run.  If there are any
+warnings or errors in the LAMMPS output, they are highlighted by using
+bold text colored in red.  There is a small panel at the bottom center
+of the *Output* window showing how many warnings and errors were
+detected and how many lines the entire output has.  By clicking on the
+button on the right with the warning symbol or by using the keyboard
+shortcut `Ctrl-N` (`Command-N` on macOS), you can jump to the next
+line with a warning or error.
 
 By default, the *Output* window is replaced each time a run is started.
 The runs are counted and the run number for the current run is displayed
@@ -398,7 +424,7 @@ below.
 Like for the *Output* and *Charts* windows, its content is continuously
 updated during a run.  It will show "(none)" if there are no variables
 defined.  Note that it is also possible to *set* :doc:`index style
-variables <variable>`, that would normally be set via command line
+variables <variable>`, that would normally be set via command-line
 flags, via the "Set Variables..." dialog from the *Run* menu.
 LAMMPS-GUI automatically defines the variable "gui_run" to the current
 value of the run counter.  That way it is possible to automatically
@@ -775,11 +801,11 @@ General Settings:
 
 - *Echo input to log:* when checked, all input commands, including
   variable expansions, are echoed to the *Output* window. This is
-  equivalent to using `-echo screen` at the command line.  There is no
+  equivalent to using `-echo screen` at the command-line.  There is no
   log *file* produced by default, since LAMMPS-GUI uses `-log none`.
 - *Include citation details:* when checked full citation info will be
   included to the log window.  This is equivalent to using `-cite
-  screen` on the command line.
+  screen` on the command-line.
 - *Show log window by default:* when checked, the screen output of a
   LAMMPS run will be collected in a log window during the run
 - *Show chart window by default:* when checked, the thermodynamic
@@ -828,7 +854,7 @@ Accelerators:
 
 This tab enables selection of an accelerator package for LAMMPS to use
 and is equivalent to using the `-suffix` and `-package` flags on the
-command line.  Only settings supported by the LAMMPS library and local
+command-line.  Only settings supported by the LAMMPS library and local
 hardware are available.  The `Number of threads` field allows setting
 the maximum number of threads for the accelerator packages that use
 threads.

doc/src/Howto_peri.rst

@@ -738,8 +738,8 @@ command.
 
 This can be done, for example, by using the built-in visualizer of the
 :doc:`dump image or dump movie <dump_image>` command to create snapshot
-images or a movie. Below are example command lines for using dump image
+images or a movie. Below are example command for using dump image with
-with the :ref:`example listed below <periexample>` and a set of images
+the :ref:`example listed below <periexample>` and a set of images
 created for steps 300, 600, and 2000 this way.
 
 .. code-block:: LAMMPS

doc/src/Howto_pylammps.rst

@@ -1,564 +1,6 @@
 PyLammps Tutorial
 =================
 
-.. contents::
+The PyLammps interface is deprecated and will be removed in a future release of
-
+LAMMPS. As such, the PyLammps version of this tutorial has been removed and is
-Overview
+replaced by the :doc:`Python_head`.
---------
-
-:py:class:`PyLammps <lammps.PyLammps>` is a Python wrapper class for
-LAMMPS which can be created on its own or use an existing
-:py:class:`lammps Python <lammps.lammps>` object.  It creates a simpler,
-more "pythonic" interface to common LAMMPS functionality, in contrast to
-the :py:class:`lammps <lammps.lammps>` wrapper for the LAMMPS :ref:`C
-language library interface API <lammps_c_api>` which is written using
-`Python ctypes <ctypes_>`_.  The :py:class:`lammps <lammps.lammps>`
-wrapper is discussed on the :doc:`Python_head` doc page.
-
-Unlike the flat `ctypes <ctypes_>`_ interface, PyLammps exposes a
-discoverable API.  It no longer requires knowledge of the underlying C++
-code implementation.  Finally, the :py:class:`IPyLammps
-<lammps.IPyLammps>` wrapper builds on top of :py:class:`PyLammps
-<lammps.PyLammps>` and adds some additional features for `IPython
-integration <ipython_>`_ into `Jupyter notebooks <jupyter_>`_, e.g. for
-embedded visualization output from :doc:`dump style image <dump_image>`.
-
-.. _ctypes: https://docs.python.org/3/library/ctypes.html
-.. _ipython: https://ipython.org/
-.. _jupyter: https://jupyter.org/
-
-Comparison of lammps and PyLammps interfaces
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-lammps.lammps
-"""""""""""""
-
-* uses `ctypes <ctypes_>`_
-* direct memory access to native C++ data with optional support for NumPy arrays
-* provides functions to send and receive data to LAMMPS
-* interface modeled after the LAMMPS :ref:`C language library interface API <lammps_c_api>`
-* requires knowledge of how LAMMPS internally works (C pointers, etc)
-* full support for running Python with MPI using `mpi4py <https://mpi4py.readthedocs.io>`_
-* no overhead from creating a more Python-like interface
-
-lammps.PyLammps
-"""""""""""""""
-
-* higher-level abstraction built on *top* of the original :py:class:`ctypes based interface <lammps.lammps>`
-* manipulation of Python objects
-* communication with LAMMPS is hidden from API user
-* shorter, more concise Python
-* better IPython integration, designed for quick prototyping
-* designed for serial execution
-* additional overhead from capturing and parsing the LAMMPS screen output
-
-Quick Start
------------
-
-System-wide Installation
-^^^^^^^^^^^^^^^^^^^^^^^^
-
-Step 1: Building LAMMPS as a shared library
-"""""""""""""""""""""""""""""""""""""""""""
-
-To use LAMMPS inside of Python it has to be compiled as shared
-library. This library is then loaded by the Python interface. In this
-example we enable the MOLECULE package and compile LAMMPS with PNG, JPEG
-and FFMPEG output support enabled.
-
-Step 1a: For the CMake based build system, the steps are:
-
-.. code-block:: bash
-
-   mkdir $LAMMPS_DIR/build-shared
-   cd  $LAMMPS_DIR/build-shared
-
-   # MPI, PNG, Jpeg, FFMPEG are auto-detected
-   cmake ../cmake -DPKG_MOLECULE=yes -DBUILD_LIB=yes -DBUILD_SHARED_LIBS=yes
-   make
-
-Step 1b: For the legacy, make based build system, the steps are:
-
-.. code-block:: bash
-
-   cd $LAMMPS_DIR/src
-
-   # add packages if necessary
-   make yes-MOLECULE
-
-   # compile shared library using Makefile
-   make mpi mode=shlib LMP_INC="-DLAMMPS_PNG -DLAMMPS_JPEG -DLAMMPS_FFMPEG" JPG_LIB="-lpng -ljpeg"
-
-Step 2: Installing the LAMMPS Python package
-""""""""""""""""""""""""""""""""""""""""""""
-
-PyLammps is part of the lammps Python package. To install it simply install
-that package into your current Python installation with:
-
-.. code-block:: bash
-
-   make install-python
-
-.. note::
-
-   Recompiling the shared library requires re-installing the Python package
-
-Installation inside of a virtualenv
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-You can use virtualenv to create a custom Python environment specifically tuned
-for your workflow.
-
-Benefits of using a virtualenv
-""""""""""""""""""""""""""""""
-
-* isolation of your system Python installation from your development installation
-* installation can happen in your user directory without root access (useful for HPC clusters)
-* installing packages through pip allows you to get newer versions of packages than e.g., through apt-get or yum package managers (and without root access)
-* you can even install specific old versions of a package if necessary
-
-**Prerequisite (e.g. on Ubuntu)**
-
-.. code-block:: bash
-
-   apt-get install python-virtualenv
-
-Creating a virtualenv with lammps installed
-"""""""""""""""""""""""""""""""""""""""""""
-
-.. code-block:: bash
-
-   # create virtualenv named 'testing'
-   virtualenv $HOME/python/testing
-
-   # activate 'testing' environment
-   source $HOME/python/testing/bin/activate
-
-Now configure and compile the LAMMPS shared library as outlined above.
-When using CMake and the shared library has already been build, you
-need to re-run CMake to update the location of the python executable
-to the location in the virtual environment with:
-
-.. code-block:: bash
-
-   cmake . -DPython_EXECUTABLE=$(which python)
-
-   # install LAMMPS package in virtualenv
-   (testing) make install-python
-
-   # install other useful packages
-   (testing) pip install matplotlib jupyter mpi4py
-
-   ...
-
-   # return to original shell
-   (testing) deactivate
-
-Creating a new instance of PyLammps
------------------------------------
-
-To create a PyLammps object you need to first import the class from the lammps
-module. By using the default constructor, a new *lammps* instance is created.
-
-.. code-block:: python
-
-   from lammps import PyLammps
-   L = PyLammps()
-
-You can also initialize PyLammps on top of this existing *lammps* object:
-
-.. code-block:: python
-
-   from lammps import lammps, PyLammps
-   lmp = lammps()
-   L = PyLammps(ptr=lmp)
-
-Commands
---------
-
-Sending a LAMMPS command with the existing library interfaces is done using
-the command method of the lammps object instance.
-
-For instance, let's take the following LAMMPS command:
-
-.. code-block:: LAMMPS
-
-   region box block 0 10 0 5 -0.5 0.5
-
-In the original interface this command can be executed with the following
-Python code if *L* was a lammps instance:
-
-.. code-block:: python
-
-   L.command("region box block 0 10 0 5 -0.5 0.5")
-
-With the PyLammps interface, any command can be split up into arbitrary parts
-separated by white-space, passed as individual arguments to a region method.
-
-.. code-block:: python
-
-   L.region("box block", 0, 10, 0, 5, -0.5, 0.5)
-
-Note that each parameter is set as Python literal floating-point number. In the
-PyLammps interface, each command takes an arbitrary parameter list and transparently
-merges it to a single command string, separating individual parameters by white-space.
-
-The benefit of this approach is avoiding redundant command calls and easier
-parameterization. In the original interface parameterization needed to be done
-manually by creating formatted strings.
-
-.. code-block:: python
-
-   L.command("region box block %f %f %f %f %f %f" % (xlo, xhi, ylo, yhi, zlo, zhi))
-
-In contrast, methods of PyLammps accept parameters directly and will convert
-them automatically to a final command string.
-
-.. code-block:: python
-
-   L.region("box block", xlo, xhi, ylo, yhi, zlo, zhi)
-
-System state
-------------
-
-In addition to dispatching commands directly through the PyLammps object, it
-also provides several properties which allow you to query the system state.
-
-L.system
-   Is a dictionary describing the system such as the bounding box or number of atoms
-
-L.system.xlo, L.system.xhi
-   bounding box limits along x-axis
-
-L.system.ylo, L.system.yhi
-   bounding box limits along y-axis
-
-L.system.zlo, L.system.zhi
-   bounding box limits along z-axis
-
-L.communication
-   configuration of communication subsystem, such as the number of threads or processors
-
-L.communication.nthreads
-   number of threads used by each LAMMPS process
-
-L.communication.nprocs
-   number of MPI processes used by LAMMPS
-
-L.fixes
-   List of fixes in the current system
-
-L.computes
-   List of active computes in the current system
-
-L.dump
-   List of active dumps in the current system
-
-L.groups
-   List of groups present in the current system
-
-Working with LAMMPS variables
------------------------------
-
-LAMMPS variables can be both defined and accessed via the PyLammps interface.
-
-To define a variable you can use the :doc:`variable <variable>` command:
-
-.. code-block:: python
-
-   L.variable("a index 2")
-
-A dictionary of all variables is returned by L.variables
-
-you can access an individual variable by retrieving a variable object from the
-L.variables dictionary by name
-
-.. code-block:: python
-
-   a = L.variables['a']
-
-The variable value can then be easily read and written by accessing the value
-property of this object.
-
-.. code-block:: python
-
-   print(a.value)
-   a.value = 4
-
-Retrieving the value of an arbitrary LAMMPS expressions
--------------------------------------------------------
-
-LAMMPS expressions can be immediately evaluated by using the eval method. The
-passed string parameter can be any expression containing global thermo values,
-variables, compute or fix data.
-
-.. code-block:: python
-
-   result = L.eval("ke") # kinetic energy
-   result = L.eval("pe") # potential energy
-
-   result = L.eval("v_t/2.0")
-
-Accessing atom data
--------------------
-
-All atoms in the current simulation can be accessed by using the L.atoms list.
-Each element of this list is an object which exposes its properties (id, type,
-position, velocity, force, etc.).
-
-.. code-block:: python
-
-   # access first atom
-   L.atoms[0].id
-   L.atoms[0].type
-
-   # access second atom
-   L.atoms[1].position
-   L.atoms[1].velocity
-   L.atoms[1].force
-
-Some properties can also be used to set:
-
-.. code-block:: python
-
-   # set position in 2D simulation
-   L.atoms[0].position = (1.0, 0.0)
-
-   # set position in 3D simulation
-   L.atoms[0].position = (1.0, 0.0, 1.)
-
-Evaluating thermo data
-----------------------
-
-Each simulation run usually produces thermo output based on system state,
-computes, fixes or variables. The trajectories of these values can be queried
-after a run via the L.runs list. This list contains a growing list of run data.
-The first element is the output of the first run, the second element that of
-the second run.
-
-.. code-block:: python
-
-   L.run(1000)
-   L.runs[0] # data of first 1000 time steps
-
-   L.run(1000)
-   L.runs[1] # data of second 1000 time steps
-
-Each run contains a dictionary of all trajectories. Each trajectory is
-accessible through its thermo name:
-
-.. code-block:: python
-
-   L.runs[0].thermo.Step # list of time steps in first run
-   L.runs[0].thermo.Ke   # list of kinetic energy values in first run
-
-Together with matplotlib plotting data out of LAMMPS becomes simple:
-
-.. code-block:: python
-
-   import matplotlib.plot as plt
-   steps = L.runs[0].thermo.Step
-   ke    = L.runs[0].thermo.Ke
-   plt.plot(steps, ke)
-
-Error handling with PyLammps
-----------------------------
-
-Using C++ exceptions in LAMMPS for errors allows capturing them on the
-C++ side and rethrowing them on the Python side.  This way you can handle
-LAMMPS errors through the Python exception handling mechanism.
-
-.. warning::
-
-   Capturing a LAMMPS exception in Python can still mean that the
-   current LAMMPS process is in an illegal state and must be
-   terminated. It is advised to save your data and terminate the Python
-   instance as quickly as possible.
-
-Using PyLammps in IPython notebooks and Jupyter
------------------------------------------------
-
-If the LAMMPS Python package is installed for the same Python interpreter as
-IPython, you can use PyLammps directly inside of an IPython notebook inside of
-Jupyter. Jupyter is a powerful integrated development environment (IDE) for
-many dynamic languages like Python, Julia and others, which operates inside of
-any web browser. Besides auto-completion and syntax highlighting it allows you
-to create formatted documents using Markup, mathematical formulas, graphics and
-animations intermixed with executable Python code. It is a great format for
-tutorials and showcasing your latest research.
-
-To launch an instance of Jupyter simply run the following command inside your
-Python environment (this assumes you followed the Quick Start instructions):
-
-.. code-block:: bash
-
-   jupyter notebook
-
-IPyLammps Examples
-------------------
-
-Examples of IPython notebooks can be found in the python/examples/pylammps
-subdirectory. To open these notebooks launch *jupyter notebook* inside this
-directory and navigate to one of them. If you compiled and installed
-a LAMMPS shared library with exceptions, PNG, JPEG and FFMPEG support
-you should be able to rerun all of these notebooks.
-
-Validating a dihedral potential
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-This example showcases how an IPython Notebook can be used to compare a simple
-LAMMPS simulation of a harmonic dihedral potential to its analytical solution.
-Four atoms are placed in the simulation and the dihedral potential is applied on
-them using a datafile. Then one of the atoms is rotated along the central axis by
-setting its position from Python, which changes the dihedral angle.
-
-.. code-block:: python
-
-   phi = [d \* math.pi / 180 for d in range(360)]
-
-   pos = [(1.0, math.cos(p), math.sin(p)) for p in phi]
-
-   pe = []
-   for p in pos:
-       L.atoms[3].position = p
-       L.run(0)
-       pe.append(L.eval("pe"))
-
-By evaluating the potential energy for each position we can verify that
-trajectory with the analytical formula.  To compare both solutions, we plot
-both trajectories over each other using matplotlib, which embeds the generated
-plot inside the IPython notebook.
-
-.. image:: JPG/pylammps_dihedral.jpg
-   :align: center
-
-Running a Monte Carlo relaxation
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-This second example shows how to use PyLammps to create a 2D Monte Carlo Relaxation
-simulation, computing and plotting energy terms and even embedding video output.
-
-Initially, a 2D system is created in a state with minimal energy.
-
-.. image:: JPG/pylammps_mc_minimum.jpg
-   :align: center
-
-It is then disordered by moving each atom by a random delta.
-
-.. code-block:: python
-
-   random.seed(27848)
-   deltaperturb = 0.2
-
-   for i in range(L.system.natoms):
-       x, y = L.atoms[i].position
-       dx = deltaperturb \* random.uniform(-1, 1)
-       dy = deltaperturb \* random.uniform(-1, 1)
-       L.atoms[i].position  = (x+dx, y+dy)
-
-   L.run(0)
-
-.. image:: JPG/pylammps_mc_disordered.jpg
-   :align: center
-
-Finally, the Monte Carlo algorithm is implemented in Python. It continuously
-moves random atoms by a random delta and only accepts certain moves.
-
-.. code-block:: python
-
-   estart = L.eval("pe")
-   elast = estart
-
-   naccept = 0
-   energies = [estart]
-
-   niterations = 3000
-   deltamove = 0.1
-   kT = 0.05
-
-   natoms = L.system.natoms
-
-   for i in range(niterations):
-       iatom = random.randrange(0, natoms)
-       current_atom = L.atoms[iatom]
-
-       x0, y0 = current_atom.position
-
-       dx = deltamove \* random.uniform(-1, 1)
-       dy = deltamove \* random.uniform(-1, 1)
-
-       current_atom.position = (x0+dx, y0+dy)
-
-       L.run(1, "pre no post no")
-
-       e = L.eval("pe")
-       energies.append(e)
-
-       if e <= elast:
-           naccept += 1
-           elast = e
-       elif random.random() <= math.exp(natoms\*(elast-e)/kT):
-           naccept += 1
-           elast = e
-       else:
-           current_atom.position = (x0, y0)
-
-The energies of each iteration are collected in a Python list and finally plotted using matplotlib.
-
-.. image:: JPG/pylammps_mc_energies_plot.jpg
-   :align: center
-
-The IPython notebook also shows how to use dump commands and embed video files
-inside of the IPython notebook.
-
-Using PyLammps and mpi4py (Experimental)
-----------------------------------------
-
-PyLammps can be run in parallel using `mpi4py
-<https://mpi4py.readthedocs.io>`_. This python package can be installed
-using
-
-.. code-block:: bash
-
-   pip install mpi4py
-
-.. warning::
-
-   Usually, any :py:class:`PyLammps <lammps.PyLammps>` command must be
-   executed by *all* MPI processes. However, evaluations and querying
-   the system state is only available on MPI rank 0.  Using these
-   functions from other MPI ranks will raise an exception.
-
-The following is a short example which reads in an existing LAMMPS input
-file and executes it in parallel.  You can find in.melt in the
-examples/melt folder.  Please take note that the
-:py:meth:`PyLammps.eval() <lammps.PyLammps.eval>` is called only from
-MPI rank 0.
-
-.. code-block:: python
-
-   from mpi4py import MPI
-   from lammps import PyLammps
-
-   L = PyLammps()
-   L.file("in.melt")
-
-   if MPI.COMM_WORLD.rank == 0:
-       print("Potential energy: ", L.eval("pe"))
-
-   MPI.Finalize()
-
-To run this script (melt.py) in parallel using 4 MPI processes we invoke the
-following mpirun command:
-
-.. code-block:: bash
-
-   mpirun -np 4 python melt.py
-
-Feedback and Contributing
--------------------------
-
-If you find this Python interface useful, please feel free to provide feedback
-and ideas on how to improve it to Richard Berger (richard.berger@outlook.com). We also
-want to encourage people to write tutorial style IPython notebooks showcasing LAMMPS usage
-and maybe their latest research results.

doc/src/Howto_python.rst

@@ -0,0 +1,441 @@
+LAMMPS Python Tutorial
+======================
+
+.. contents::
+
+-----
+
+Overview
+--------
+
+The :py:class:`lammps <lammps.lammps>` Python module is a wrapper class for the
+LAMMPS :ref:`C language library interface API <lammps_c_api>` which is written using
+`Python ctypes <ctypes_>`_.  The design choice of this wrapper class is to
+follow the C language API closely with only small changes related to Python
+specific requirements and to better accommodate object oriented programming.
+
+In addition to this flat `ctypes <ctypes_>`_ interface, the
+:py:class:`lammps <lammps.lammps>` wrapper class exposes a discoverable
+API that doesn't require as much knowledge of the underlying C language
+library interface or LAMMPS C++ code implementation.
+
+Finally, the API exposes some additional features for `IPython integration
+<ipython_>`_ into `Jupyter notebooks <jupyter_>`_, e.g. for embedded
+visualization output from :doc:`dump style image <dump_image>`.
+
+.. _ctypes: https://docs.python.org/3/library/ctypes.html
+.. _ipython: https://ipython.org/
+.. _jupyter: https://jupyter.org/
+
+-----
+
+Quick Start
+-----------
+
+System-wide or User Installation
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Step 1: Building LAMMPS as a shared library
+"""""""""""""""""""""""""""""""""""""""""""
+
+To use LAMMPS inside of Python it has to be compiled as shared library.
+This library is then loaded by the Python interface.  In this example we
+enable the :ref:`MOLECULE package <PKG-MOLECULE>` and compile LAMMPS
+with :ref:`PNG, JPEG and FFMPEG output support <graphics>` enabled.
+
+.. tabs::
+
+   .. tab:: CMake build
+
+      .. code-block:: bash
+
+         mkdir $LAMMPS_DIR/build-shared
+         cd  $LAMMPS_DIR/build-shared
+
+         # MPI, PNG, Jpeg, FFMPEG are auto-detected
+         cmake ../cmake -DPKG_MOLECULE=yes -DPKG_PYTHON=on -DBUILD_SHARED_LIBS=yes
+         make
+
+   .. tab:: Traditional make
+
+      .. code-block:: bash
+
+         cd $LAMMPS_DIR/src
+
+         # add packages if necessary
+         make yes-MOLECULE
+         make yes-PYTHON
+
+         # compile shared library using Makefile
+         make mpi mode=shlib LMP_INC="-DLAMMPS_PNG -DLAMMPS_JPEG -DLAMMPS_FFMPEG" JPG_LIB="-lpng -ljpeg"
+
+Step 2: Installing the LAMMPS Python package
+""""""""""""""""""""""""""""""""""""""""""""
+
+Next install the LAMMPS Python package into your current Python installation with:
+
+.. code-block:: bash
+
+   make install-python
+
+This will create a so-called `"wheel"
+<https://packaging.python.org/en/latest/discussions/package-formats/#what-is-a-wheel>`_
+and then install the LAMMPS Python module from that "wheel" into either
+into a system folder (provided the command is executed with root
+privileges) or into your personal Python module folder.
+
+.. note::
+
+   Recompiling the shared library requires re-installing the Python
+   package.
+
+Installation inside of a virtual environment
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+You can use virtual environments to create a custom Python environment
+specifically tuned for your workflow.
+
+Benefits of using a virtualenv
+""""""""""""""""""""""""""""""
+
+* isolation of your system Python installation from your development installation
+* installation can happen in your user directory without root access (useful for HPC clusters)
+* installing packages through pip allows you to get newer versions of packages than e.g., through apt-get or yum package managers (and without root access)
+* you can even install specific old versions of a package if necessary
+
+**Prerequisite (e.g. on Ubuntu)**
+
+.. code-block:: bash
+
+   apt-get install python-venv
+
+Creating a virtualenv with lammps installed
+"""""""""""""""""""""""""""""""""""""""""""
+
+.. code-block:: bash
+
+   # create virtual envrionment named 'testing'
+   python3 -m venv $HOME/python/testing
+
+   # activate 'testing' environment
+   source $HOME/python/testing/bin/activate
+
+Now configure and compile the LAMMPS shared library as outlined above.
+When using CMake and the shared library has already been build, you
+need to re-run CMake to update the location of the python executable
+to the location in the virtual environment with:
+
+.. code-block:: bash
+
+   cmake . -DPython_EXECUTABLE=$(which python)
+
+   # install LAMMPS package in virtualenv
+   (testing) make install-python
+
+   # install other useful packages
+   (testing) pip install matplotlib jupyter mpi4py pandas
+
+   ...
+
+   # return to original shell
+   (testing) deactivate
+
+-------
+
+Creating a new lammps instance
+------------------------------
+
+To create a lammps object you need to first import the class from the lammps
+module. By using the default constructor, a new :py:class:`lammps
+<lammps.lammps>` instance is created.
+
+.. code-block:: python
+
+   from lammps import lammps
+   L = lammps()
+
+See the :doc:`LAMMPS Python documentation <Python_create>` for how to customize
+the instance creation with optional arguments.
+
+-----
+
+Commands
+--------
+
+Sending a LAMMPS command with the library interface is done using
+the ``command`` method of the lammps object.
+
+For instance, let's take the following LAMMPS command:
+
+.. code-block:: LAMMPS
+
+   region box block 0 10 0 5 -0.5 0.5
+
+This command can be executed with the following Python code if ``L`` is a ``lammps``
+instance:
+
+.. code-block:: python
+
+   L.command("region box block 0 10 0 5 -0.5 0.5")
+
+For convenience, the ``lammps`` class also provides a command wrapper ``cmd``
+that turns any LAMMPS command into a regular function call:
+
+.. code-block:: python
+
+   L.cmd.region("box block", 0, 10, 0, 5, -0.5, 0.5)
+
+Note that each parameter is set as Python number literal. With
+the wrapper each command takes an arbitrary parameter list and transparently
+merges it to a single command string, separating individual parameters by
+white-space.
+
+The benefit of this approach is avoiding redundant command calls and easier
+parameterization. With the ``command`` function each call needs to be assembled
+manually using formatted strings.
+
+.. code-block:: python
+
+   L.command(f"region box block {xlo} {xhi} {ylo} {yhi} {zlo} {zhi}")
+
+The wrapper accepts parameters directly and will convert
+them automatically to a final command string.
+
+.. code-block:: python
+
+   L.cmd.region("box block", xlo, xhi, ylo, yhi, zlo, zhi)
+
+.. note::
+
+   When running in IPython you can use Tab-completion after ``L.cmd.`` to see
+   all available LAMMPS commands.
+
+-----
+
+Accessing atom data
+-------------------
+
+All per-atom properties that are part of the :doc:`atom style
+<atom_style>` in the current simulation can be accessed using the
+:py:meth:`extract_atoms() <lammps.lammps.extract_atoms()>` method.  This
+can be retrieved as ctypes objects or as NumPy arrays through the
+lammps.numpy module.  Those represent the *local* atoms of the
+individual sub-domain for the current MPI process and may contain
+information for the local ghost atoms or not depending on the property.
+Both can be accessed as lists, but for the ctypes list object the size
+is not known and hast to be retrieved first to avoid out-of-bounds
+accesses.
+
+.. code-block:: python
+
+   nlocal = L.extract_setting("nlocal")
+   nall = L.extract_setting("nall")
+   print("Number of local atoms ", nlocal, "  Number of local and ghost atoms ", nall);
+
+   # access via ctypes directly
+   atom_id = L.extract_atom("id")
+   print("Atom IDs", atom_id[0:nlocal])
+
+   # access through numpy wrapper
+   atom_type = L.numpy.extract_atom("type")
+   print("Atom types", atom_type)
+
+   x = L.numpy.extract_atom("x")
+   v = L.numpy.extract_atom("v")
+   print("positions array shape", x.shape)
+   print("velocity array shape", v.shape)
+   # turn on communicating velocities to ghost atoms
+   L.cmd.comm_modify("vel", "yes")
+   v = L.numpy.extract_atom('v')
+   print("velocity array shape", v.shape)
+
+Some properties can also be set from Python since internally the
+data of the C++ code is accessed directly:
+
+.. code-block:: python
+
+   # set position in 2D simulation
+   x[0] = (1.0, 0.0)
+
+   # set position in 3D simulation
+   x[0] = (1.0, 0.0, 1.)
+
+------
+
+Retrieving the values of thermodynamic data and variables
+---------------------------------------------------------
+
+To access thermodynamic data from the last completed timestep,
+you can use the :py:meth:`get_thermo() <lammps.lammps.get_thermo>`
+method, and to extract the value of (compatible) variables, you
+can use the :py:meth:`extract_variable() <lammps.lammps.extract_variable>`
+method.
+
+.. code-block:: python
+
+   result = L.get_thermo("ke") # kinetic energy
+   result = L.get_thermo("pe") # potential energy
+
+   result = L.extract_variable("t") / 2.0
+
+Error handling
+--------------
+
+We are using C++ exceptions in LAMMPS for errors and the C language
+library interface captures and records them.  This allows checking
+whether errors have happened in Python during a call into LAMMPS and
+then re-throw the error as a Python exception.  This way you can handle
+LAMMPS errors in the conventional way through the Python exception
+handling mechanism.
+
+.. warning::
+
+   Capturing a LAMMPS exception in Python can still mean that the
+   current LAMMPS process is in an illegal state and must be
+   terminated.  It is advised to save your data and terminate the Python
+   instance as quickly as possible.
+
+Using LAMMPS in IPython notebooks and Jupyter
+---------------------------------------------
+
+If the LAMMPS Python package is installed for the same Python
+interpreter as IPython, you can use LAMMPS directly inside of an IPython
+notebook inside of Jupyter. Jupyter is a powerful integrated development
+environment (IDE) for many dynamic languages like Python, Julia and
+others, which operates inside of any web browser.  Besides
+auto-completion and syntax highlighting it allows you to create
+formatted documents using Markup, mathematical formulas, graphics and
+animations intermixed with executable Python code.  It is a great format
+for tutorials and showcasing your latest research.
+
+To launch an instance of Jupyter simply run the following command inside your
+Python environment (this assumes you followed the Quick Start instructions):
+
+.. code-block:: bash
+
+   jupyter notebook
+
+Interactive Python Examples
+---------------------------
+
+Examples of IPython notebooks can be found in the ``python/examples/ipython``
+subdirectory. To open these notebooks launch ``jupyter notebook`` inside this
+directory and navigate to one of them. If you compiled and installed
+a LAMMPS shared library with PNG, JPEG and FFMPEG support
+you should be able to rerun all of these notebooks.
+
+Validating a dihedral potential
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This example showcases how an IPython Notebook can be used to compare a simple
+LAMMPS simulation of a harmonic dihedral potential to its analytical solution.
+Four atoms are placed in the simulation and the dihedral potential is applied on
+them using a datafile. Then one of the atoms is rotated along the central axis by
+setting its position from Python, which changes the dihedral angle.
+
+.. code-block:: python
+
+   phi = [d \* math.pi / 180 for d in range(360)]
+
+   pos = [(1.0, math.cos(p), math.sin(p)) for p in phi]
+
+   x = L.numpy.extract_atom("x")
+
+   pe = []
+   for p in pos:
+       x[3] = p
+       L.cmd.run(0, "post", "no")
+       pe.append(L.get_thermo("pe"))
+
+By evaluating the potential energy for each position we can verify that
+trajectory with the analytical formula.  To compare both solutions, we plot
+both trajectories over each other using matplotlib, which embeds the generated
+plot inside the IPython notebook.
+
+.. image:: JPG/pylammps_dihedral.jpg
+   :align: center
+
+Running a Monte Carlo relaxation
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This second example shows how to use the `lammps` Python interface to create a
+2D Monte Carlo Relaxation simulation, computing and plotting energy terms and
+even embedding video output.
+
+Initially, a 2D system is created in a state with minimal energy.
+
+.. image:: JPG/pylammps_mc_minimum.jpg
+   :align: center
+
+It is then disordered by moving each atom by a random delta.
+
+.. code-block:: python
+
+   random.seed(27848)
+   deltaperturb = 0.2
+   x = L.numpy.extract_atom("x")
+   natoms = x.shape[0]
+
+   for i in range(natoms):
+       dx = deltaperturb \* random.uniform(-1, 1)
+       dy = deltaperturb \* random.uniform(-1, 1)
+       x[i][0] += dx
+       x[i][1] += dy
+
+   L.cmd.run(0, "post", "no")
+
+.. image:: JPG/pylammps_mc_disordered.jpg
+   :align: center
+
+Finally, the Monte Carlo algorithm is implemented in Python. It continuously
+moves random atoms by a random delta and only accepts certain moves.
+
+.. code-block:: python
+
+   estart = L.get_thermo("pe")
+   elast = estart
+
+   naccept = 0
+   energies = [estart]
+
+   niterations = 3000
+   deltamove = 0.1
+   kT = 0.05
+
+   for i in range(niterations):
+       x = L.numpy.extract_atom("x")
+       natoms = x.shape[0]
+       iatom = random.randrange(0, natoms)
+       current_atom = x[iatom]
+
+       x0 = current_atom[0]
+       y0 = current_atom[1]
+
+       dx = deltamove \* random.uniform(-1, 1)
+       dy = deltamove \* random.uniform(-1, 1)
+
+       current_atom[0] = x0 + dx
+       current_atom[1] = y0 + dy
+
+       L.cmd.run(1, "pre no post no")
+
+       e = L.get_thermo("pe")
+       energies.append(e)
+
+       if e <= elast:
+           naccept += 1
+           elast = e
+       elif random.random() <= math.exp(natoms\*(elast-e)/kT):
+           naccept += 1
+           elast = e
+       else:
+           current_atom[0] = x0
+           current_atom[1] = y0
+
+The energies of each iteration are collected in a Python list and finally plotted using matplotlib.
+
+.. image:: JPG/pylammps_mc_energies_plot.jpg
+   :align: center
+
+The IPython notebook also shows how to use dump commands and embed video files
+inside of the IPython notebook.

doc/src/Howto_wsl.rst

@@ -260,7 +260,7 @@ Switch into the :code:`examples/melt` folder:
 
    cd ../examples/melt
 
-To run this example in serial, use the following command line:
+To run this example in serial, use the following command:
 
 .. code-block::
 

doc/src/Install_git.rst

@@ -52,6 +52,7 @@ your machine and "release" is one of the 3 branches listed above.
 between them at any time using "git checkout <branch name>".)
 
 .. admonition:: Saving time and disk space when using ``git clone``
+   :class: note
 
    The complete git history of the LAMMPS project is quite large because
    it contains the entire commit history of the project since fall 2006,
@@ -60,7 +61,7 @@ between them at any time using "git checkout <branch name>".)
    files (mostly by accident).  If you do not need access to the entire
    commit history (most people don't), you can speed up the "cloning"
    process and reduce local disk space requirements by using the
-   ``--depth`` git command line flag.  That will create a "shallow clone"
+   ``--depth`` git command-line flag.  That will create a "shallow clone"
    of the repository, which contains only a subset of the git history.
    Using a depth of 1000 is usually sufficient to include the head
    commits of the *develop*, the *release*, and the *maintenance*

doc/src/Intro_authors.rst

@@ -8,6 +8,8 @@ send an email to all of them at this address: "developers at
 lammps.org".  General questions about LAMMPS should be posted in the
 `LAMMPS forum on MatSci <https://matsci.org/lammps/>`_.
 
+.. We need to keep this file in sync with https://www.lammps.org/authors.html
+
 .. raw:: latex
 
    \small
@@ -27,7 +29,7 @@ lammps.org".  General questions about LAMMPS should be posted in the
    * - `Steve Plimpton <sjp_>`_
      - SNL (retired)
      - sjplimp at gmail.com
-     - MD kernels, parallel algorithms & scalability, code structure and design
+     - original author, MD kernels, parallel algorithms & scalability, code structure and design
    * - `Aidan Thompson <at_>`_
      - SNL
      - athomps at sandia.gov

doc/src/Library.rst

@@ -131,16 +131,15 @@ run LAMMPS in serial mode.
 
 .. _lammps_python_api:
 
-LAMMPS Python APIs
+LAMMPS Python API
-==================
+=================
 
 The LAMMPS Python module enables calling the LAMMPS C library API from
 Python by dynamically loading functions in the LAMMPS shared library through
 the `Python ctypes module <https://docs.python.org/3/library/ctypes.html>`_.
 Because of the dynamic loading, it is **required** that LAMMPS is compiled
 in :ref:`"shared" mode <exe>`.  The Python interface is object-oriented, but
-otherwise tries to be very similar to the C library API.  Three different
+otherwise tries to be very similar to the C library API.
-Python classes to run LAMMPS are available and they build on each other.
 More information on this is in the :doc:`Python_head`
 section of the manual.  Use of the LAMMPS Python module is described in
 :doc:`Python_module`.

doc/src/Library_execute.rst

@@ -7,6 +7,7 @@ This section documents the following functions:
 - :cpp:func:`lammps_command`
 - :cpp:func:`lammps_commands_list`
 - :cpp:func:`lammps_commands_string`
+- :cpp:func:`lammps_expand`
 
 --------------------
 
@@ -79,3 +80,8 @@ Below is a short example using some of these functions.
 .. doxygenfunction:: lammps_commands_string
    :project: progguide
 
+-----------------------
+
+.. doxygenfunction:: lammps_expand
+   :project: progguide
+

doc/src/Library_objects.rst

@@ -1,5 +1,5 @@
-Compute, fixes, variables
+Computes, fixes, variables
-=========================
+==========================
 
 This section documents accessing or modifying data stored by computes,
 fixes, or variables in LAMMPS using the following functions:
@@ -12,6 +12,10 @@ fixes, or variables in LAMMPS using the following functions:
 - :cpp:func:`lammps_set_string_variable`
 - :cpp:func:`lammps_set_internal_variable`
 - :cpp:func:`lammps_variable_info`
+- :cpp:func:`lammps_eval`
+- :cpp:func:`lammps_clearstep_compute`
+- :cpp:func:`lammps_addstep_compute_all`
+- :cpp:func:`lammps_addstep_compute`
 
 -----------------------
 
@@ -55,6 +59,26 @@ fixes, or variables in LAMMPS using the following functions:
 
 -----------------------
 
+.. doxygenfunction:: lammps_eval
+   :project: progguide
+
+-----------------------
+
+.. doxygenfunction:: lammps_clearstep_compute
+   :project: progguide
+
+-----------------------
+
+.. doxygenfunction:: lammps_addstep_compute_all
+   :project: progguide
+
+-----------------------
+
+.. doxygenfunction:: lammps_addstep_compute
+   :project: progguide
+
+-----------------------
+
 .. doxygenenum:: _LMP_DATATYPE_CONST
 
 .. doxygenenum:: _LMP_STYLE_CONST

doc/src/Modify_compute.rst

@@ -45,6 +45,8 @@ class.  See compute.h for details.
 +-----------------------+------------------------------------------------------------------+
 | pair_tally_callback   | callback function for *tally*\ -style computes (optional).       |
 +-----------------------+------------------------------------------------------------------+
+| modify_param          | called when a compute_modify request is executed (optional)      |
++-----------------------+------------------------------------------------------------------+
 | memory_usage          | tally memory usage (optional)                                    |
 +-----------------------+------------------------------------------------------------------+
 

doc/src/Modify_requirements.rst

@@ -208,20 +208,21 @@ Build system (strict)
 
 LAMMPS currently supports two build systems: one that is based on
 :doc:`traditional Makefiles <Build_make>` and one that is based on
-:doc:`CMake <Build_cmake>`.  Therefore, your contribution must be
+:doc:`CMake <Build_cmake>`.  As of fall 2024, it is no longer required
-compatible with and support both build systems.
+to support the traditional make build system.  New packages may choose
+to only support building with CMake.  Additions to existing packages
+must follow the requirements set by that package.
 
 For a single pair of header and implementation files that are an
 independent feature, it is usually only required to add them to
 ``src/.gitignore``.
 
 For traditional make, if your contributed files or package depend on
-other LAMMPS style files or packages also being installed
+other LAMMPS style files or packages also being installed (e.g. because
-(e.g. because your file is a derived class from the other LAMMPS
+your file is a derived class from the other LAMMPS class), then an
-class), then an ``Install.sh`` file is also needed to check for those
+``Install.sh`` file is also needed to check for those dependencies and
-dependencies and modifications to ``src/Depend.sh`` to trigger the checks.
+modifications to ``src/Depend.sh`` to trigger the checks.  See other
-See other README and Install.sh files in other directories as
+README and Install.sh files in other directories as examples.
-examples.
 
 Similarly, for CMake support, changes may need to be made to
 ``cmake/CMakeLists.txt``, some of the files in ``cmake/presets``, and

doc/src/Modify_style.rst

@@ -46,7 +46,7 @@ Include files (varied)
   but instead should be initialized either in the initializer list of
   the constructor or explicitly assigned in the body of the constructor.
   If the member variable is relevant to the functionality of a class
-  (for example when it stores a value from a command line argument), the
+  (for example when it stores a value from a command-line argument), the
   member variable declaration is followed by a brief comment explaining
   its purpose and what its values can be.  Class members that are
   pointers should always be initialized to ``nullptr`` in the

doc/src/Packages_details.rst

@@ -994,6 +994,7 @@ Additional pair styles that are less commonly used.
 
 * ``src/EXTRA-PAIR``: filenames -> commands
 * :doc:`pair_style <pair_style>`
+* ``examples/PACKAGES/dispersion``
 
 ----------
 
@@ -2171,8 +2172,8 @@ the :doc:`Build extras <Build_extras>` page.
 * ``src/OPENMP/README``
 * :doc:`Accelerator packages <Speed_packages>`
 * :doc:`OPENMP package <Speed_omp>`
-* :doc:`Command line option -suffix/-sf omp <Run_options>`
+* :doc:`Command-line option -suffix/-sf omp <Run_options>`
-* :doc:`Command line option -package/-pk omp <Run_options>`
+* :doc:`Command-line option -package/-pk omp <Run_options>`
 * :doc:`package omp <package>`
 * Search the :doc:`commands <Commands_all>` pages (:doc:`fix <Commands_fix>`, :doc:`compute <Commands_compute>`,
   :doc:`pair <Commands_pair>`, :doc:`bond, angle, dihedral, improper <Commands_bond>`,
@@ -2789,14 +2790,15 @@ implements smoothed particle hydrodynamics (SPH) for liquids.  See the
 related :ref:`MACHDYN package <PKG-MACHDYN>` package for smooth Mach dynamics
 (SMD) for solids.
 
-This package contains ideal gas, Lennard-Jones equation of states,
+This package contains ideal gas, Lennard-Jones equation of states, Tait,
-Tait, and full support for complete (i.e. internal-energy dependent)
+and full support for complete (i.e. internal-energy dependent) equations
-equations of state.  It allows for plain or Monaghans XSPH integration
+of state.  It allows for plain or Monaghans XSPH integration of the
-of the equations of motion.  It has options for density continuity or
+equations of motion.  It has options for density continuity or density
-density summation to propagate the density field.  It has
+summation to propagate the density field.  It has :doc:`set <set>`
-:doc:`set <set>` command options to set the internal energy and density
+command options to set the internal energy and density of particles from
-of particles from the input script and allows the same quantities to
+the input script and allows the same quantities to be output with
-be output with thermodynamic output or to dump files via the :doc:`compute property/atom <compute_property_atom>` command.
+thermodynamic output or to dump files via the :doc:`compute
+property/atom <compute_property_atom>` command.
 
 **Author:** Georg Ganzenmuller (Fraunhofer-Institute for High-Speed
 Dynamics, Ernst Mach Institute, Germany).
@@ -2809,6 +2811,17 @@ Dynamics, Ernst Mach Institute, Germany).
 * ``examples/PACKAGES/sph``
 * https://www.lammps.org/movies.html#sph
 
+.. note::
+
+   Please note that the SPH PDF guide file has not been updated for
+   many years and thus does not reflect the current *syntax* of the
+   SPH package commands. For that please refer to the LAMMPS manual.
+
+.. note::
+
+   Please also note, that the :ref:`RHEO package <PKG-RHEO>` offers
+   similar functionality in a more modern and flexible implementation.
+
 ----------
 
 .. _PKG-SPIN:

doc/src/Python_atoms.rst

@@ -2,14 +2,8 @@ Per-atom properties
 ===================
 
 Similar to what is described in :doc:`Library_atoms`, the instances of
-:py:class:`lammps <lammps.lammps>`, :py:class:`PyLammps <lammps.PyLammps>`, or
+:py:class:`lammps <lammps.lammps>` can be used to extract atom quantities
-:py:class:`IPyLammps <lammps.IPyLammps>` can be used to extract atom quantities
+and modify some of them.
-and modify some of them. The main difference between the interfaces is how the information
-is exposed.
-
-While the :py:class:`lammps <lammps.lammps>` is just a thin layer that wraps C API calls,
-:py:class:`PyLammps <lammps.PyLammps>` and :py:class:`IPyLammps <lammps.IPyLammps>` expose
-information as objects and properties.
 
 In some cases the data returned is a direct reference to the original data
 inside LAMMPS cast to ``ctypes`` pointers. Where possible, the wrappers will
@@ -25,57 +19,41 @@ against invalid accesses.
    accordingly. These arrays can change sizes and order at every neighbor list
    rebuild and atom sort event as atoms are migrating between subdomains.
 
-.. tabs::
+.. code-block:: python
 
-   .. tab:: lammps API
+   from lammps import lammps
 
-      .. code-block:: python
+   lmp = lammps()
+   lmp.file("in.sysinit")
 
-         from lammps import lammps
 
-         lmp = lammps()
+   # Read/Write access via ctypes
-         lmp.file("in.sysinit")
+   nlocal = lmp.extract_global("nlocal")
+   x = lmp.extract_atom("x")
 
-         nlocal = lmp.extract_global("nlocal")
+   for i in range(nlocal):
-         x = lmp.extract_atom("x")
+      print("(x,y,z) = (", x[i][0], x[i][1], x[i][2], ")")
 
-         for i in range(nlocal):
+   # Read/Write access via NumPy arrays
-            print("(x,y,z) = (", x[i][0], x[i][1], x[i][2], ")")
+   atom_id = L.numpy.extract_atom("id")
+   atom_type = L.numpy.extract_atom("type")
+   x = L.numpy.extract_atom("x")
+   v = L.numpy.extract_atom("v")
+   f = L.numpy.extract_atom("f")
 
-         lmp.close()
+   # set position in 2D simulation
+   x[0] = (1.0, 0.0)
 
-      **Methods**:
+   # set position in 3D simulation
+   x[0] = (1.0, 0.0, 1.)
 
-      * :py:meth:`extract_atom() <lammps.lammps.extract_atom()>`: extract a per-atom quantity
+   lmp.close()
 
-      **Numpy Methods**:
 
-      * :py:meth:`numpy.extract_atom() <lammps.numpy_wrapper.numpy_wrapper.extract_atom()>`: extract a per-atom quantity as numpy array
+**Methods**:
 
-   .. tab:: PyLammps/IPyLammps API
+* :py:meth:`extract_atom() <lammps.lammps.extract_atom()>`: extract a per-atom quantity
 
-      All atoms in the current simulation can be accessed by using the :py:attr:`PyLammps.atoms <lammps.PyLammps.atoms>` property.
+**Numpy Methods**:
-      Each element of this list is a :py:class:`Atom <lammps.Atom>` or :py:class:`Atom2D <lammps.Atom2D>` object. The attributes of
-      these objects provide access to their data (id, type, position, velocity, force, etc.):
-
-      .. code-block:: python
-
-         # access first atom
-         L.atoms[0].id
-         L.atoms[0].type
-
-         # access second atom
-         L.atoms[1].position
-         L.atoms[1].velocity
-         L.atoms[1].force
-
-      Some attributes can be changed:
-
-      .. code-block:: python
-
-         # set position in 2D simulation
-         L.atoms[0].position = (1.0, 0.0)
-
-         # set position in 3D simulation
-         L.atoms[0].position = (1.0, 0.0, 1.0)
 
+* :py:meth:`numpy.extract_atom() <lammps.numpy_wrapper.numpy_wrapper.extract_atom()>`: extract a per-atom quantity as numpy array

doc/src/Python_create.rst

@@ -6,11 +6,10 @@ Creating or deleting a LAMMPS object
 ====================================
 
 With the Python interface the creation of a :cpp:class:`LAMMPS
-<LAMMPS_NS::LAMMPS>` instance is included in the constructors for the
+<LAMMPS_NS::LAMMPS>` instance is included in the constructor for the
-:py:class:`lammps <lammps.lammps>`, :py:class:`PyLammps <lammps.PyLammps>`,
+:py:class:`lammps <lammps.lammps>` class. Internally it will call either
-and :py:class:`IPyLammps <lammps.IPyLammps>` classes.
+:cpp:func:`lammps_open` or :cpp:func:`lammps_open_no_mpi` from the C library
-Internally it will call either :cpp:func:`lammps_open` or :cpp:func:`lammps_open_no_mpi` from the C
+API to create the class instance.
-library API to create the class instance.
 
 All arguments are optional.  The *name* argument allows loading a
 LAMMPS shared library that is named ``liblammps_machine.so`` instead of
@@ -26,108 +25,25 @@ to run the Python module like the library interface on a subset of the
 MPI ranks after splitting the communicator.
 
 
-Here are simple examples using all three Python interfaces:
+Here is a simple example using the LAMMPS Python interface:
 
-.. tabs::
+.. code-block:: python
 
-   .. tab:: lammps API
+   from lammps import lammps
 
-      .. code-block:: python
+   # NOTE: argv[0] is set by the lammps class constructor
+   args = ["-log", "none"]
 
-         from lammps import lammps
+   # create LAMMPS instance
+   lmp = lammps(cmdargs=args)
 
-         # NOTE: argv[0] is set by the lammps class constructor
+   # get and print numerical version code
-         args = ["-log", "none"]
+   print("LAMMPS Version: ", lmp.version())
 
-         # create LAMMPS instance
+   # explicitly close and delete LAMMPS instance (optional)
-         lmp = lammps(cmdargs=args)
+   lmp.close()
 
-         # get and print numerical version code
+Same as with the :ref:`C library API <lammps_c_api>`, this will use the
-         print("LAMMPS Version: ", lmp.version())
-
-         # explicitly close and delete LAMMPS instance (optional)
-         lmp.close()
-
-   .. tab:: PyLammps API
-
-      The :py:class:`PyLammps <lammps.PyLammps>` class is a wrapper around the
-      :py:class:`lammps <lammps.lammps>` class and all of its lower level functions.
-      By default, it will create a new instance of :py:class:`lammps <lammps.lammps>` passing
-      along all arguments to the constructor of :py:class:`lammps <lammps.lammps>`.
-
-      .. code-block:: python
-
-         from lammps import PyLammps
-
-         # NOTE: argv[0] is set by the lammps class constructor
-         args = ["-log", "none"]
-
-         # create LAMMPS instance
-         L = PyLammps(cmdargs=args)
-
-         # get and print numerical version code
-         print("LAMMPS Version: ", L.version())
-
-         # explicitly close and delete LAMMPS instance (optional)
-         L.close()
-
-      :py:class:`PyLammps <lammps.PyLammps>` objects can also be created on top of an existing
-      :py:class:`lammps <lammps.lammps>` object:
-
-      .. code-block:: python
-
-         from lammps import lammps, PyLammps
-         ...
-         # create LAMMPS instance
-         lmp = lammps(cmdargs=args)
-
-         # create PyLammps instance using previously created LAMMPS instance
-         L = PyLammps(ptr=lmp)
-
-      This is useful if you have to create the :py:class:`lammps <lammps.lammps>`
-      instance is a specific way, but want to take advantage of the
-      :py:class:`PyLammps <lammps.PyLammps>` interface.
-
-   .. tab:: IPyLammps API
-
-      The :py:class:`IPyLammps <lammps.IPyLammps>` class is an extension of the
-      :py:class:`PyLammps <lammps.PyLammps>` class. It has the same construction behavior. By
-      default, it will create a new instance of :py:class:`lammps` passing
-      along all arguments to the constructor of :py:class:`lammps`.
-
-      .. code-block:: python
-
-         from lammps import IPyLammps
-
-         # NOTE: argv[0] is set by the lammps class constructor
-         args = ["-log", "none"]
-
-         # create LAMMPS instance
-         L = IPyLammps(cmdargs=args)
-
-         # get and print numerical version code
-         print("LAMMPS Version: ", L.version())
-
-         # explicitly close and delete LAMMPS instance (optional)
-         L.close()
-
-      You can also initialize IPyLammps on top of an existing :py:class:`lammps` or :py:class:`PyLammps` object:
-
-      .. code-block:: python
-
-         from lammps import lammps, IPyLammps
-         ...
-         # create LAMMPS instance
-         lmp = lammps(cmdargs=args)
-
-         # create PyLammps instance using previously created LAMMPS instance
-         L = PyLammps(ptr=lmp)
-
-      This is useful if you have to create the :py:class:`lammps <lammps.lammps>`
-      instance is a specific way, but want to take advantage of the
-      :py:class:`IPyLammps <lammps.IPyLammps>` interface.
-
-In all of the above cases, same as with the :ref:`C library API <lammps_c_api>`, this will use the
 ``MPI_COMM_WORLD`` communicator for the MPI library that LAMMPS was
 compiled with.
 

doc/src/Python_execute.rst

@@ -1,127 +1,123 @@
 Executing commands
 ==================
 
-Once an instance of the :py:class:`lammps <lammps.lammps>`,
+Once an instance of the :py:class:`lammps <lammps.lammps>` class is created, there are
-:py:class:`PyLammps <lammps.PyLammps>`, or
-:py:class:`IPyLammps <lammps.IPyLammps>` class is created, there are
 multiple ways to "feed" it commands. In a way that is not very different from
 running a LAMMPS input script, except that Python has many more facilities
 for structured programming than the LAMMPS input script syntax. Furthermore
 it is possible to "compute" what the next LAMMPS command should be.
 
-.. tabs::
+Same as in the equivalent :doc:`C library functions <Library_execute>`,
+commands can be read from a file, a single string, a list of strings and a
+block of commands in a single multi-line string. They are processed under the
+same boundary conditions as the C library counterparts.  The example below
+demonstrates the use of :py:func:`lammps.file()`, :py:func:`lammps.command()`,
+:py:func:`lammps.commands_list()`, and :py:func:`lammps.commands_string()`:
 
-   .. tab:: lammps API
+.. code-block:: python
 
-      Same as in the equivalent
+   from lammps import lammps
-      :doc:`C library functions <Library_execute>`, commands can be read from a file, a
+   lmp = lammps()
-      single string, a list of strings and a block of commands in a single
-      multi-line string. They are processed under the same boundary conditions
-      as the C library counterparts.  The example below demonstrates the use
-      of :py:func:`lammps.file()`, :py:func:`lammps.command()`,
-      :py:func:`lammps.commands_list()`, and :py:func:`lammps.commands_string()`:
 
-      .. code-block:: python
+   # read commands from file 'in.melt'
+   lmp.file('in.melt')
 
-         from lammps import lammps
+   # issue a single command
-         lmp = lammps()
+   lmp.command('variable zpos index 1.0')
 
-         # read commands from file 'in.melt'
+   # create 10 groups with 10 atoms each
-         lmp.file('in.melt')
+   cmds = [f"group g{i} id {10*i+1}:{10*(i+1)}" for i in range(10)]
+   lmp.commands_list(cmds)
 
-         # issue a single command
+   # run commands from a multi-line string
-         lmp.command('variable zpos index 1.0')
+   block = """
+   clear
+   region  box block 0 2 0 2 0 2
+   create_box 1 box
+   create_atoms 1 single 1.0 1.0 ${zpos}
+   """
+   lmp.commands_string(block)
 
-         # create 10 groups with 10 atoms each
+For convenience, the :py:class:`lammps <lammps.lammps>` class also provides a
-         cmds = ["group g{} id {}:{}".format(i,10*i+1,10*(i+1)) for i in range(10)]
+command wrapper ``cmd`` that turns any LAMMPS command into a regular function
-         lmp.commands_list(cmds)
+call.
 
-         # run commands from a multi-line string
+For instance, the following LAMMPS command
-         block = """
-         clear
-         region  box block 0 2 0 2 0 2
-         create_box 1 box
-         create_atoms 1 single 1.0 1.0 ${zpos}
-         """
-         lmp.commands_string(block)
 
-   .. tab:: PyLammps/IPyLammps API
+.. code-block:: LAMMPS
 
-      Unlike the lammps API, the PyLammps/IPyLammps APIs allow running LAMMPS
+   region box block 0 10 0 5 -0.5 0.5
-      commands by calling equivalent member functions of :py:class:`PyLammps <lammps.PyLammps>`
-      and :py:class:`IPyLammps <lammps.IPyLammps>` instances.
 
-      For instance, the following LAMMPS command
+would normally be executed with the following Python code:
 
-      .. code-block:: LAMMPS
+.. code-block:: python
 
-         region box block 0 10 0 5 -0.5 0.5
+   from lammps import lammps
 
-      can be executed using with the lammps API with the following Python code if ``lmp`` is an
+   lmp = lammps()
-      instance of :py:class:`lammps <lammps.lammps>`:
+   lmp.command("region box block 0 10 0 5 -0.5 0.5")
 
-      .. code-block:: python
+With the ``cmd`` wrapper, any LAMMPS command can be split up into arbitrary parts.
+These parts are then passed to a member function with the name of the :doc:`command <Commands_all>`.
+For the :doc:`region <region>` command that means the :code:`region()` method can be called.
+The arguments of the command can be passed as one string, or
+individually.
 
-         from lammps import lammps
+.. code-block:: python
 
-         lmp = lammps()
+   from lammps import lammps
-         lmp.command("region box block 0 10 0 5 -0.5 0.5")
 
-      With the PyLammps interface, any LAMMPS command can be split up into arbitrary parts.
+   L = lammps()
-      These parts are then passed to a member function with the name of the :doc:`command <Commands_all>`.
-      For the :doc:`region <region>` command that means the :code:`region()` method can be called.
-      The arguments of the command can be passed as one string, or
-      individually.
 
-      .. code-block:: python
+   # pass command parameters as one string
+   L.cmd.region("box block 0 10 0 5 -0.5 0.5")
 
-         from lammps import PyLammps
+   # OR pass them individually
+   L.cmd.region("box block", 0, 10, 0, 5, -0.5, 0.5)
 
-         L = PyLammps()
+In the latter example, all parameters except the first are Python floating-point literals. The
+member function takes the entire parameter list and transparently merges it to a single command
+string.
 
-         # pass command parameters as one string
+The benefit of this approach is avoiding redundant command calls and easier
-         L.region("box block 0 10 0 5 -0.5 0.5")
+parameterization. With `command`, `commands_list`, and `commands_string` the
+parameterization needed to be done manually by creating formatted command
+strings.
 
-         # OR pass them individually
+.. code-block:: python
-         L.region("box block", 0, 10, 0, 5, -0.5, 0.5)
 
-      In the latter example, all parameters except the first are Python floating-point literals. The
+   lmp.command("region box block %f %f %f %f %f %f" % (xlo, xhi, ylo, yhi, zlo, zhi))
-      member function takes the entire parameter list and transparently merges it to a single command
-      string.
 
-      The benefit of this approach is avoiding redundant command calls and easier
+In contrast, methods of the `cmd` wrapper accept parameters directly and will convert
-      parameterization. In the lammps API parameterization needed to be done
+them automatically to a final command string.
-      manually by creating formatted command strings.
 
-      .. code-block:: python
+.. code-block:: python
 
-         lmp.command("region box block %f %f %f %f %f %f" % (xlo, xhi, ylo, yhi, zlo, zhi))
+   L.cmd.region("box block", xlo, xhi, ylo, yhi, zlo, zhi)
 
-      In contrast, methods of PyLammps accept parameters directly and will convert
+.. note::
-      them automatically to a final command string.
 
-      .. code-block:: python
+   When running in IPython you can use Tab-completion after ``L.cmd.`` to see
+   all available LAMMPS commands.
 
-         L.region("box block", xlo, xhi, ylo, yhi, zlo, zhi)
+Using these facilities, the previous example shown above can be rewritten as follows:
 
-      Using these facilities, the example shown for the lammps API can be rewritten as follows:
+.. code-block:: python
 
-      .. code-block:: python
+   from lammps import lammps
+   L = lammps()
 
-         from lammps import PyLammps
+   # read commands from file 'in.melt'
-         L = PyLammps()
+   L.file('in.melt')
 
-         # read commands from file 'in.melt'
+   # issue a single command
-         L.file('in.melt')
+   L.cmd.variable('zpos', 'index', 1.0)
 
-         # issue a single command
+   # create 10 groups with 10 atoms each
-         L.variable('zpos', 'index', 1.0)
+   for i in range(10):
+      L.cmd.group(f"g{i}", "id", f"{10*i+1}:{10*(i+1)}")
 
-         # create 10 groups with 10 atoms each
+   L.cmd.clear()
-         for i in range(10):
+   L.cmd.region("box block", 0, 2, 0, 2, 0, 2)
-            L.group(f"g{i}", "id", f"{10*i+1}:{10*(i+1)}")
+   L.cmd.create_box(1, "box")
-
+   L.cmd.create_atoms(1, "single", 1.0, 1.0, "${zpos}")
-         L.clear()
-         L.region("box block", 0, 2, 0, 2, 0, 2)
-         L.create_box(1, "box")
-         L.create_atoms(1, "single", 1.0, 1.0, "${zpos}")

doc/src/Python_head.rst

@@ -15,6 +15,7 @@ together.
    Python_call
    Python_formats
    Python_examples
+   Python_jupyter
    Python_error
    Python_trouble
 

doc/src/Python_jupyter.rst

@@ -0,0 +1,45 @@
+Using LAMMPS in IPython notebooks and Jupyter
+=============================================
+
+If the LAMMPS Python package is installed for the same Python interpreter as
+`IPython <ipython>`_, you can use LAMMPS directly inside of an IPython notebook inside of
+Jupyter. `Jupyter <juypter>`_ is a powerful integrated development environment (IDE) for
+many dynamic languages like Python, Julia and others, which operates inside of
+any web browser. Besides auto-completion and syntax highlighting it allows you
+to create formatted documents using Markup, mathematical formulas, graphics and
+animations intermixed with executable Python code. It is a great format for
+tutorials and showcasing your latest research.
+
+The easiest way to install it is via ``pip``:
+
+.. code-block:: bash
+
+   pip install --user jupyter
+
+To launch an instance of Jupyter simply run the following command inside your
+Python environment:
+
+.. code-block:: bash
+
+   jupyter notebook
+
+Interactive Python Examples
+---------------------------
+
+Examples of IPython notebooks can be found in the ``python/examples/ipython``
+subdirectory. They require LAMMPS to be compiled as shared library with PYTHON,
+PNG, JPEG and FFMPEG support.
+
+To open these notebooks launch ``jupyter notebook index.ipynb`` inside this
+directory. The opened file provides an overview of the available examples.
+
+- Example 1: Using LAMMPS with Python (``simple.ipynb``)
+- Example 2: Analyzing LAMMPS thermodynamic data (``thermo.ipynb``)
+- Example 3: Working with Per-Atom Data (``atoms.ipynb``)
+- Example 4: Working with LAMMPS variables (``variables.ipynb``)
+- Example 5: Validating a dihedral potential (``dihedrals/dihedral.ipynb``)
+- Example 6: Running a Monte Carlo relaxation (``montecarlo/mc.ipynb``)
+
+.. note::
+
+   Typically clicking a link in Jupyter will open a new tab, which might be blocked by your pop-up blocker.

doc/src/Python_module.rst

@@ -10,19 +10,11 @@ be installed into a Python system folder or a user folder with ``make
 install-python``.  Components of the module can then loaded into a Python
 session with the ``import`` command.
 
-There are multiple Python interface classes in the :py:mod:`lammps` module:
+.. warning::
 
-- the :py:class:`lammps <lammps.lammps>` class. This is a wrapper around
+   Alternative interfaces such as :py:class:`PyLammps <lammps.PyLammps>` and
-  the C-library interface and its member functions try to replicate the
+   :py:class:`IPyLammps <lammps.IPyLammps>` classes have been deprecated and
-  :ref:`C-library API <lammps_c_api>` closely.  This is the most
+   will be removed in a future version of LAMMPS.
-  feature-complete Python API.
-- the :py:class:`PyLammps <lammps.PyLammps>` class. This is a more high-level
-  and more Python style class implemented on top of the
-  :py:class:`lammps <lammps.lammps>` class.
-- the :py:class:`IPyLammps <lammps.IPyLammps>` class is derived from
-  :py:class:`PyLammps <lammps.PyLammps>` and adds embedded graphics
-  features to conveniently include LAMMPS into `Jupyter
-  <https://jupyter.org/>`_ notebooks.
 
 .. _mpi4py_url: https://mpi4py.readthedocs.io
 
@@ -49,7 +41,7 @@ The ``lammps`` class API
 ========================
 
 The :py:class:`lammps <lammps.lammps>` class is the core of the LAMMPS
-Python interfaces.  It is a wrapper around the :ref:`LAMMPS C library
+Python interface.  It is a wrapper around the :ref:`LAMMPS C library
 API <lammps_c_api>` using the `Python ctypes module
 <https://docs.python.org/3/library/ctypes.html>`_ and a shared library
 compiled from the LAMMPS sources code.  The individual methods in this
@@ -64,40 +56,7 @@ functions. Below is a detailed documentation of the API.
 .. autoclass:: lammps.numpy_wrapper::numpy_wrapper
    :members:
 
-----------
+.. autoclass:: lammps.ipython::wrapper
-
-The ``PyLammps`` class API
-==========================
-
-The :py:class:`PyLammps <lammps.PyLammps>` class is a wrapper that creates a
-simpler, more "Pythonic" interface to common LAMMPS functionality. LAMMPS
-data structures are exposed through objects and properties. This makes Python
-scripts shorter and more concise. See the :doc:`PyLammps Tutorial
-<Howto_pylammps>` for an introduction on how to use this interface.
-
-.. autoclass:: lammps.PyLammps
-   :members:
-
-.. autoclass:: lammps.AtomList
-   :members:
-
-.. autoclass:: lammps.Atom
-   :members:
-
-.. autoclass:: lammps.Atom2D
-   :members:
-
-----------
-
-The ``IPyLammps`` class API
-===========================
-
-The :py:class:`IPyLammps <lammps.PyLammps>` class is an extension of
-:py:class:`PyLammps <lammps.PyLammps>`, adding additional functions to
-quickly display visualizations such as images and videos inside of IPython.
-See the :doc:`PyLammps Tutorial <Howto_pylammps>` for examples.
-
-.. autoclass:: lammps.IPyLammps
    :members:
 
 ----------

doc/src/Python_objects.rst

@@ -4,95 +4,52 @@ Compute, fixes, variables
 This section documents accessing or modifying data from objects like
 computes, fixes, or variables in LAMMPS using the :py:mod:`lammps` module.
 
-.. tabs::
+For :py:meth:`lammps.extract_compute() <lammps.lammps.extract_compute()>` and
+:py:meth:`lammps.extract_fix() <lammps.lammps.extract_fix()>`, the global, per-atom,
+or local data calculated by the compute or fix can be accessed. What is returned
+depends on whether the compute or fix calculates a scalar or vector or array.
+For a scalar, a single double value is returned.  If the compute or fix calculates
+a vector or array, a pointer to the internal LAMMPS data is returned, which you can
+use via normal Python subscripting.
 
-   .. tab:: lammps API
+The one exception is that for a fix that calculates a
+global vector or array, a single double value from the vector or array
+is returned, indexed by I (vector) or I and J (array).  I,J are
+zero-based indices.
+See the :doc:`Howto output <Howto_output>` page for a discussion of
+global, per-atom, and local data, and of scalar, vector, and array
+data types.  See the doc pages for individual :doc:`computes <compute>`
+and :doc:`fixes <fix>` for a description of what they calculate and
+store.
 
-      For :py:meth:`lammps.extract_compute() <lammps.lammps.extract_compute()>` and
+For :py:meth:`lammps.extract_variable() <lammps.lammps.extract_variable()>`,
-      :py:meth:`lammps.extract_fix() <lammps.lammps.extract_fix()>`, the global, per-atom,
+an :doc:`equal-style or atom-style variable <variable>` is evaluated and
-      or local data calculated by the compute or fix can be accessed. What is returned
+its result returned.
-      depends on whether the compute or fix calculates a scalar or vector or array.
-      For a scalar, a single double value is returned.  If the compute or fix calculates
-      a vector or array, a pointer to the internal LAMMPS data is returned, which you can
-      use via normal Python subscripting.
 
-      The one exception is that for a fix that calculates a
+For equal-style variables a single ``c_double`` value is returned and the
-      global vector or array, a single double value from the vector or array
+group argument is ignored.  For atom-style variables, a vector of
-      is returned, indexed by I (vector) or I and J (array).  I,J are
+``c_double`` is returned, one value per atom, which you can use via normal
-      zero-based indices.
+Python subscripting. The values will be zero for atoms not in the
-      See the :doc:`Howto output <Howto_output>` page for a discussion of
+specified group.
-      global, per-atom, and local data, and of scalar, vector, and array
-      data types.  See the doc pages for individual :doc:`computes <compute>`
-      and :doc:`fixes <fix>` for a description of what they calculate and
-      store.
 
-      For :py:meth:`lammps.extract_variable() <lammps.lammps.extract_variable()>`,
+:py:meth:`lammps.numpy.extract_compute() <lammps.numpy_wrapper.numpy_wrapper.extract_compute()>`,
-      an :doc:`equal-style or atom-style variable <variable>` is evaluated and
+:py:meth:`lammps.numpy.extract_fix() <lammps.numpy_wrapper.numpy_wrapper.extract_fix()>`, and
-      its result returned.
+:py:meth:`lammps.numpy.extract_variable() <lammps.numpy_wrapper.numpy_wrapper.extract_variable()>` are
+equivalent NumPy implementations that return NumPy arrays instead of ``ctypes`` pointers.
 
-      For equal-style variables a single ``c_double`` value is returned and the
+The :py:meth:`lammps.set_variable() <lammps.lammps.set_variable()>` method sets an
-      group argument is ignored.  For atom-style variables, a vector of
+existing string-style variable to a new string value, so that subsequent LAMMPS
-      ``c_double`` is returned, one value per atom, which you can use via normal
+commands can access the variable.
-      Python subscripting. The values will be zero for atoms not in the
-      specified group.
 
-      :py:meth:`lammps.numpy.extract_compute() <lammps.numpy_wrapper.numpy_wrapper.extract_compute()>`,
+**Methods**:
-      :py:meth:`lammps.numpy.extract_fix() <lammps.numpy_wrapper.numpy_wrapper.extract_fix()>`, and
-      :py:meth:`lammps.numpy.extract_variable() <lammps.numpy_wrapper.numpy_wrapper.extract_variable()>` are
-      equivalent NumPy implementations that return NumPy arrays instead of ``ctypes`` pointers.
 
-      The :py:meth:`lammps.set_variable() <lammps.lammps.set_variable()>` method sets an
+* :py:meth:`lammps.extract_compute() <lammps.lammps.extract_compute()>`: extract value(s) from a compute
-      existing string-style variable to a new string value, so that subsequent LAMMPS
+* :py:meth:`lammps.extract_fix() <lammps.lammps.extract_fix()>`: extract value(s) from a fix
-      commands can access the variable.
+* :py:meth:`lammps.extract_variable() <lammps.lammps.extract_variable()>`: extract value(s) from a variable
+* :py:meth:`lammps.set_variable() <lammps.lammps.set_variable()>`: set existing named string-style variable to value
 
-      **Methods**:
+**NumPy Methods**:
 
-      * :py:meth:`lammps.extract_compute() <lammps.lammps.extract_compute()>`: extract value(s) from a compute
+* :py:meth:`lammps.numpy.extract_compute() <lammps.numpy_wrapper.numpy_wrapper.extract_compute()>`: extract value(s) from a compute, return arrays as numpy arrays
-      * :py:meth:`lammps.extract_fix() <lammps.lammps.extract_fix()>`: extract value(s) from a fix
+* :py:meth:`lammps.numpy.extract_fix() <lammps.numpy_wrapper.numpy_wrapper.extract_fix()>`: extract value(s) from a fix, return arrays as numpy arrays
-      * :py:meth:`lammps.extract_variable() <lammps.lammps.extract_variable()>`: extract value(s) from a variable
+* :py:meth:`lammps.numpy.extract_variable() <lammps.numpy_wrapper.numpy_wrapper.extract_variable()>`: extract value(s) from a variable, return arrays as numpy arrays
-      * :py:meth:`lammps.set_variable() <lammps.lammps.set_variable()>`: set existing named string-style variable to value
-
-      **NumPy Methods**:
-
-      * :py:meth:`lammps.numpy.extract_compute() <lammps.numpy_wrapper.numpy_wrapper.extract_compute()>`: extract value(s) from a compute, return arrays as numpy arrays
-      * :py:meth:`lammps.numpy.extract_fix() <lammps.numpy_wrapper.numpy_wrapper.extract_fix()>`: extract value(s) from a fix, return arrays as numpy arrays
-      * :py:meth:`lammps.numpy.extract_variable() <lammps.numpy_wrapper.numpy_wrapper.extract_variable()>`: extract value(s) from a variable, return arrays as numpy arrays
-
-
-   .. tab:: PyLammps/IPyLammps API
-
-      PyLammps and IPyLammps classes currently do not add any additional ways of
-      retrieving information out of computes and fixes. This information can still be accessed by using the lammps API:
-
-      .. code-block:: python
-
-         L.lmp.extract_compute(...)
-         L.lmp.extract_fix(...)
-         # OR
-         L.lmp.numpy.extract_compute(...)
-         L.lmp.numpy.extract_fix(...)
-
-      LAMMPS variables can be both defined and accessed via the :py:class:`PyLammps <lammps.PyLammps>` interface.
-
-      To define a variable you can use the :doc:`variable <variable>` command:
-
-      .. code-block:: python
-
-         L.variable("a index 2")
-
-      A dictionary of all variables is returned by the :py:attr:`PyLammps.variables <lammps.PyLammps.variables>` property:
-
-      you can access an individual variable by retrieving a variable object from the
-      ``L.variables`` dictionary by name
-
-      .. code-block:: python
-
-         a = L.variables['a']
-
-      The variable value can then be easily read and written by accessing the value
-      property of this object.
-
-      .. code-block:: python
-
-         print(a.value)
-         a.value = 4

doc/src/Python_overview.rst

@@ -56,7 +56,7 @@ Below is an example output for Python version 3.8.5.
 
 ---------
 
-LAMMPS can work together with Python in three ways.  First, Python can
+LAMMPS can work together with Python in two ways.  First, Python can
 wrap LAMMPS through the its :doc:`library interface <Library>`, so
 that a Python script can create one or more instances of LAMMPS and
 launch one or more simulations.  In Python terms, this is referred to as
@@ -67,22 +67,7 @@ launch one or more simulations.  In Python terms, this is referred to as
 
    Launching LAMMPS via Python
 
-
+Second, LAMMPS can use the Python interpreter, so that a LAMMPS input
-Second, the lower-level Python interface in the :py:class:`lammps Python
-class <lammps.lammps>` can be used indirectly through the provided
-:py:class:`PyLammps <lammps.PyLammps>` and :py:class:`IPyLammps
-<lammps.IPyLammps>` wrapper classes, also written in Python.  These
-wrappers try to simplify the usage of LAMMPS in Python by providing a
-more object-based interface to common LAMMPS functionality.  They also
-reduce the amount of code necessary to parameterize LAMMPS scripts
-through Python and make variables and computes directly accessible.
-
-.. figure:: JPG/pylammps-invoke-lammps.png
-   :figclass: align-center
-
-   Using the PyLammps / IPyLammps wrappers
-
-Third, LAMMPS can use the Python interpreter, so that a LAMMPS input
 script or styles can invoke Python code directly, and pass information
 back-and-forth between the input script and Python functions you write.
 This Python code can also call back to LAMMPS to query or change its

doc/src/Python_properties.rst

@@ -2,14 +2,8 @@ System properties
 =================
 
 Similar to what is described in :doc:`Library_properties`, the instances of
-:py:class:`lammps <lammps.lammps>`, :py:class:`PyLammps <lammps.PyLammps>`, or
+:py:class:`lammps <lammps.lammps>` can be used to extract different kinds
-:py:class:`IPyLammps <lammps.IPyLammps>` can be used to extract different kinds
+of information about the active LAMMPS instance and also to modify some of it.
-of information about the active LAMMPS instance and also to modify some of it. The
-main difference between the interfaces is how the information is exposed.
-
-While the :py:class:`lammps <lammps.lammps>` is just a thin layer that wraps C API calls,
-:py:class:`PyLammps <lammps.PyLammps>` and :py:class:`IPyLammps <lammps.IPyLammps>` expose
-information as objects and properties.
 
 In some cases the data returned is a direct reference to the original data
 inside LAMMPS cast to ``ctypes`` pointers. Where possible, the wrappers will
@@ -25,113 +19,38 @@ against invalid accesses.
    accordingly. These arrays can change sizes and order at every neighbor list
    rebuild and atom sort event as atoms are migrating between subdomains.
 
-.. tabs::
+.. code-block:: python
 
-   .. tab:: lammps API
+   from lammps import lammps
 
-      .. code-block:: python
+   lmp = lammps()
+   lmp.file("in.sysinit")
 
-         from lammps import lammps
+   natoms = lmp.get_natoms()
+   print(f"running simulation with {natoms} atoms")
 
-         lmp = lammps()
+   lmp.command("run 1000 post no");
-         lmp.file("in.sysinit")
 
-         natoms = lmp.get_natoms()
+   for i in range(10):
-         print(f"running simulation with {natoms} atoms")
+      lmp.command("run 100 pre no post no")
+      pe = lmp.get_thermo("pe")
+      ke = lmp.get_thermo("ke")
+      print(f"PE = {pe}\nKE = {ke}")
 
-         lmp.command("run 1000 post no");
+   lmp.close()
 
-         for i in range(10):
+**Methods**:
-            lmp.command("run 100 pre no post no")
-            pe = lmp.get_thermo("pe")
-            ke = lmp.get_thermo("ke")
-            print(f"PE = {pe}\nKE = {ke}")
 
-         lmp.close()
+* :py:meth:`version() <lammps.lammps.version()>`: return the numerical version id, e.g. LAMMPS 2 Sep 2015 -> 20150902
+* :py:meth:`get_thermo() <lammps.lammps.get_thermo()>`: return current value of a thermo keyword
+* :py:meth:`last_thermo() <lammps.lammps.last_thermo()>`: return a dictionary of the last thermodynamic output
+* :py:meth:`get_natoms() <lammps.lammps.get_natoms()>`: total # of atoms as int
+* :py:meth:`reset_box() <lammps.lammps.reset_box()>`: reset the simulation box size
+* :py:meth:`extract_setting() <lammps.lammps.extract_setting()>`: return a global setting
+* :py:meth:`extract_global() <lammps.lammps.extract_global()>`: extract a global quantity
+* :py:meth:`extract_box() <lammps.lammps.extract_box()>`: extract box info
+* :py:meth:`create_atoms() <lammps.lammps.create_atoms()>`: create N atoms with IDs, types, x, v, and image flags
 
-      **Methods**:
+**Properties**:
 
-      * :py:meth:`version() <lammps.lammps.version()>`: return the numerical version id, e.g. LAMMPS 2 Sep 2015 -> 20150902
+* :py:attr:`last_thermo_step <lammps.lammps.last_thermo_step>`: the last timestep thermodynamic output was computed
-      * :py:meth:`get_thermo() <lammps.lammps.get_thermo()>`: return current value of a thermo keyword
-      * :py:meth:`last_thermo() <lammps.lammps.last_thermo()>`: return a dictionary of the last thermodynamic output
-      * :py:meth:`get_natoms() <lammps.lammps.get_natoms()>`: total # of atoms as int
-      * :py:meth:`reset_box() <lammps.lammps.reset_box()>`: reset the simulation box size
-      * :py:meth:`extract_setting() <lammps.lammps.extract_setting()>`: return a global setting
-      * :py:meth:`extract_global() <lammps.lammps.extract_global()>`: extract a global quantity
-      * :py:meth:`extract_box() <lammps.lammps.extract_box()>`: extract box info
-      * :py:meth:`create_atoms() <lammps.lammps.create_atoms()>`: create N atoms with IDs, types, x, v, and image flags
-
-      **Properties**:
-
-      * :py:attr:`last_thermo_step <lammps.lammps.last_thermo_step>`: the last timestep thermodynamic output was computed
-
-   .. tab:: PyLammps/IPyLammps API
-
-      In addition to the functions provided by :py:class:`lammps <lammps.lammps>`, :py:class:`PyLammps <lammps.PyLammps>` objects
-      have several properties which allow you to query the system state:
-
-      L.system
-         Is a dictionary describing the system such as the bounding box or number of atoms
-
-      L.system.xlo, L.system.xhi
-         bounding box limits along x-axis
-
-      L.system.ylo, L.system.yhi
-         bounding box limits along y-axis
-
-      L.system.zlo, L.system.zhi
-         bounding box limits along z-axis
-
-      L.communication
-         configuration of communication subsystem, such as the number of threads or processors
-
-      L.communication.nthreads
-         number of threads used by each LAMMPS process
-
-      L.communication.nprocs
-         number of MPI processes used by LAMMPS
-
-      L.fixes
-         List of fixes in the current system
-
-      L.computes
-         List of active computes in the current system
-
-      L.dump
-         List of active dumps in the current system
-
-      L.groups
-         List of groups present in the current system
-
-      **Retrieving the value of an arbitrary LAMMPS expressions**
-
-      LAMMPS expressions can be immediately evaluated by using the ``eval`` method. The
-      passed string parameter can be any expression containing global :doc:`thermo` values,
-      variables, compute or fix data (see :doc:`Howto_output`):
-
-
-      .. code-block:: python
-
-         result = L.eval("ke") # kinetic energy
-         result = L.eval("pe") # potential energy
-
-         result = L.eval("v_t/2.0")
-
-      **Example**
-
-      .. code-block:: python
-
-         from lammps import PyLammps
-
-         L = PyLammps()
-         L.file("in.sysinit")
-
-         print(f"running simulation with {L.system.natoms} atoms")
-
-         L.run(1000, "post no");
-
-         for i in range(10):
-            L.run(100, "pre no post no")
-            pe = L.eval("pe")
-            ke = L.eval("ke")
-            print(f"PE = {pe}\nKE = {ke}")

doc/src/Run_basics.rst

@@ -1,8 +1,8 @@
 Basics of running LAMMPS
 ========================
 
-LAMMPS is run from the command line, reading commands from a file via
+LAMMPS is run from the command-line, reading commands from a file via
-the ``-in`` command line flag, or from standard input.  Using the ``-in
+the ``-in`` command-line flag, or from standard input.  Using the ``-in
 in.file`` variant is recommended (see note below).  The name of the
 LAMMPS executable is either ``lmp`` or ``lmp_<machine>`` with
 `<machine>` being the machine string used when compiling LAMMPS.  This
@@ -25,7 +25,7 @@ build LAMMPS:
 You normally run the LAMMPS command in the directory where your input
 script is located.  That is also where output files are produced by
 default, unless you provide specific other paths in your input script or
-on the command line.  As in some of the examples above, the LAMMPS
+on the command-line.  As in some of the examples above, the LAMMPS
 executable itself can be placed elsewhere.
 
 .. note::

doc/src/Run_options.rst

@@ -632,7 +632,7 @@ the ``-package omp`` command-line switch or the :doc:`package omp <package>` com
 
 The :doc:`suffix <suffix>` command can also be used within an input
 script to set a suffix, or to turn off or back on any suffix setting
-made via the command line.
+made via the command-line.
 
 ----------
 

doc/src/Run_output.rst

@@ -178,3 +178,64 @@ with and without the communication and a Gflop rate is computed.  The
 3d rate is with communication; the 1d rate is without (just the 1d
 FFTs).  Thus you can estimate what fraction of your FFT time was spent
 in communication, roughly 75% in the example above.
+
+Error message output
+====================
+
+Depending on the error function arguments when it is called in the
+source code, there will be one to four lines of error output.
+
+A single line
+^^^^^^^^^^^^^
+
+The line starts with "ERROR: ", followed by the error message and
+information about the location in the source where the error function
+was called in parenthesis on the right (here: line 131 of the file
+src/fix_print.cpp). Example:
+
+.. parsed-literal::
+
+   ERROR: Fix print timestep variable nevery returned a bad timestep: 9900 (src/fix_print.cpp:131)
+
+Two lines
+^^^^^^^^^
+
+In addition to the single line output, also the last line of the input
+will be repeated.  If a command is spread over multiple lines in the
+input using the continuation character '&', then the error will print
+the entire concatenated line.  For readability all whitespace is
+compressed to single blanks.  Example:
+
+.. parsed-literal::
+
+   ERROR: Unrecognized fix style 'printf' (src/modify.cpp:924)
+   Last input line: fix 0 all printf v_nevery "Step: $(step) ${step}"
+
+Three lines
+^^^^^^^^^^^
+
+In addition to the two line output from above, a third line is added
+that uses caret character markers '^' to indicate which "word" in the
+input failed.  Example:
+
+.. parsed-literal::
+
+   ERROR: Illegal fix print nevery value -100; must be > 0 (src/fix_print.cpp:41)
+   Last input line: fix 0 all print -100 "Step: $(step) ${stepx}"
+                                    ^^^^
+
+Four lines
+^^^^^^^^^^
+
+The three line output is expanded to four lines, if the the input is
+modified through input pre-processing, e.g. when substituting
+variables. Now the last command is printed once in the original form and
+a second time after substitutions are applied.  The caret character
+markers '^' are applied to the second version.  Example:
+
+.. parsed-literal::
+
+   ERROR: Illegal fix print nevery value -100; must be > 0 (src/fix_print.cpp:41)
+   Last input line: fix 0 all print ${nevery} 'Step: $(step) ${step}'
+   --> parsed line: fix 0 all print -100 "Step: $(step) ${step}"
+                                    ^^^^

doc/src/Run_windows.rst

@@ -20,7 +20,7 @@ To run with 4 threads, you can type this:
    lmp -in in.lj.lmp -k on t 4 -sf kk
 
 Alternately, you can also install a package with LAMMPS-GUI included and
-open the LAMMPS-GUI app (the package includes the command line version
+open the LAMMPS-GUI app (the package includes the command-line version
 of LAMMPS as well) and open the input file in the GUI and run it from
 there.  For details on LAMMPS-GUI, see :doc:`Howto_lammps_gui`.
 

doc/src/Speed_gpu.rst

@@ -31,7 +31,8 @@ Coulombics.  It has the following general features:
   (for Nvidia GPUs, AMD GPUs, Intel GPUs, and multicore CPUs).
   so that the same functionality is supported on a variety of hardware.
 
-**Required hardware/software:**
+Required hardware/software
+""""""""""""""""""""""""""
 
 To compile and use this package in CUDA mode, you currently need
 to have an NVIDIA GPU and install the corresponding NVIDIA CUDA
@@ -69,12 +70,14 @@ To compile and use this package in HIP mode, you have to have the AMD ROCm
 software installed. Versions of ROCm older than 3.5 are currently deprecated
 by AMD.
 
-**Building LAMMPS with the GPU package:**
+Building LAMMPS with the GPU package
+""""""""""""""""""""""""""""""""""""
 
 See the :ref:`Build extras <gpu>` page for
 instructions.
 
-**Run with the GPU package from the command line:**
+Run with the GPU package from the command-line
+""""""""""""""""""""""""""""""""""""""""""""""
 
 The ``mpirun`` or ``mpiexec`` command sets the total number of MPI tasks
 used by LAMMPS (one or multiple per compute node) and the number of MPI
@@ -133,7 +136,8 @@ affect the setting for bonded interactions (LAMMPS default is "on").
 The "off" setting for pairwise interaction is currently required for
 GPU package pair styles.
 
-**Or run with the GPU package by editing an input script:**
+Run with the GPU package by editing an input script
+"""""""""""""""""""""""""""""""""""""""""""""""""""
 
 The discussion above for the ``mpirun`` or ``mpiexec`` command, MPI
 tasks/node, and use of multiple MPI tasks/GPU is the same.
@@ -149,7 +153,8 @@ You must also use the :doc:`package gpu <package>` command to enable the
 GPU package, unless the ``-sf gpu`` or ``-pk gpu`` :doc:`command-line switches <Run_options>` were used.  It specifies the number of
 GPUs/node to use, as well as other options.
 
-**Speed-ups to expect:**
+Speed-up to expect
+""""""""""""""""""
 
 The performance of a GPU versus a multicore CPU is a function of your
 hardware, which pair style is used, the number of atoms/GPU, and the
@@ -176,10 +181,13 @@ better with multiple OMP threads because the inter-process communication
 is higher for these styles with the GPU package in order to allow
 deterministic results.
 
-**Guidelines for best performance:**
+Guidelines for best performance
+"""""""""""""""""""""""""""""""
 
-* Using multiple MPI tasks per GPU will often give the best performance,
+* Using multiple MPI tasks (2-10) per GPU will often give the best
-  as allowed my most multicore CPU/GPU configurations.
+  performance, as allowed my most multicore CPU/GPU configurations.
+  Using too many MPI tasks will result in worse performance due to
+  growing overhead with the growing number of MPI tasks.
 * If the number of particles per MPI task is small (e.g. 100s of
   particles), it can be more efficient to run with fewer MPI tasks per
   GPU, even if you do not use all the cores on the compute node.
@@ -199,12 +207,13 @@ deterministic results.
   :doc:`angle <angle_style>`, :doc:`dihedral <dihedral_style>`,
   :doc:`improper <improper_style>`, and :doc:`long-range <kspace_style>`
   calculations will not be included in the "Pair" time.
-* Since only part of the pppm kspace style is GPU accelerated, it
+* Since only part of the pppm kspace style is GPU accelerated, it may be
-  may be faster to only use GPU acceleration for Pair styles with
+  faster to only use GPU acceleration for Pair styles with long-range
-  long-range electrostatics.  See the "pair/only" keyword of the
+  electrostatics.  See the "pair/only" keyword of the :doc:`package
-  package command for a shortcut to do that.  The work between kspace
+  command <package>` for a shortcut to do that.  The distribution of
-  on the CPU and non-bonded interactions on the GPU can be balanced
+  work between kspace on the CPU and non-bonded interactions on the GPU
-  through adjusting the coulomb cutoff without loss of accuracy.
+  can be balanced through adjusting the coulomb cutoff without loss of
+  accuracy.
 * When the *mode* setting for the package gpu command is force/neigh,
   the time for neighbor list calculations on the GPU will be added into
   the "Pair" time, not the "Neigh" time.  An additional breakdown of the
@@ -220,4 +229,6 @@ deterministic results.
 Restrictions
 """"""""""""
 
-None.
+When using :doc:`hybrid pair styles <pair_hybrid>`, the neighbor list
+must be generated on the host instead of the GPU and thus the potential
+GPU acceleration is reduced.

doc/src/Speed_intel.rst

@@ -1,5 +1,5 @@
 INTEL package
-==================
+=============
 
 The INTEL package is maintained by Mike Brown at Intel
 Corporation.  It provides two methods for accelerating simulations,
@@ -13,18 +13,18 @@ twice, once on the CPU and once with an offload flag. This allows
 LAMMPS to run on the CPU cores and co-processor cores simultaneously.
 
 Currently Available INTEL Styles
-"""""""""""""""""""""""""""""""""""""
+""""""""""""""""""""""""""""""""
 
 * Angle Styles: charmm, harmonic
-* Bond Styles: fene, fourier, harmonic
+* Bond Styles: fene, harmonic
 * Dihedral Styles: charmm, fourier, harmonic, opls
-* Fixes: nve, npt, nvt, nvt/sllod, nve/asphere
+* Fixes: nve, npt, nvt, nvt/sllod, nve/asphere, electrode/conp, electrode/conq, electrode/thermo
 * Improper Styles: cvff, harmonic
 * Pair Styles: airebo, airebo/morse, buck/coul/cut, buck/coul/long,
   buck, dpd, eam, eam/alloy, eam/fs, gayberne, lj/charmm/coul/charmm,
   lj/charmm/coul/long, lj/cut, lj/cut/coul/long, lj/long/coul/long,
-  rebo, sw, tersoff
+  rebo, snap, sw, tersoff
-* K-Space Styles: pppm, pppm/disp
+* K-Space Styles: pppm, pppm/disp, pppm/electrode
 
 .. warning::
 
@@ -33,7 +33,7 @@ Currently Available INTEL Styles
    input requires it, LAMMPS will abort with an error message.
 
 Speed-up to expect
-"""""""""""""""""""
+""""""""""""""""""
 
 The speedup will depend on your simulation, the hardware, which
 styles are used, the number of atoms, and the floating-point
@@ -312,21 +312,21 @@ almost all cases.
    recommended, especially when running on a machine with Intel
    Hyper-Threading technology disabled.
 
-Run with the INTEL package from the command line
+Run with the INTEL package from the command-line
-"""""""""""""""""""""""""""""""""""""""""""""""""""""
+""""""""""""""""""""""""""""""""""""""""""""""""
 
-To enable INTEL optimizations for all available styles used in
+To enable INTEL optimizations for all available styles used in the input
-the input script, the ``-sf intel`` :doc:`command-line switch <Run_options>` can be used without any requirement for
+script, the ``-sf intel`` :doc:`command-line switch <Run_options>` can
-editing the input script. This switch will automatically append
+be used without any requirement for editing the input script. This
-"intel" to styles that support it. It also invokes a default command:
+switch will automatically append "intel" to styles that support it. It
-:doc:`package intel 1 <package>`. This package command is used to set
+also invokes a default command: :doc:`package intel 1 <package>`. This
-options for the INTEL package.  The default package command will
+package command is used to set options for the INTEL package.  The
-specify that INTEL calculations are performed in mixed precision,
+default package command will specify that INTEL calculations are
-that the number of OpenMP threads is specified by the OMP_NUM_THREADS
+performed in mixed precision, that the number of OpenMP threads is
-environment variable, and that if co-processors are present and the
+specified by the OMP_NUM_THREADS environment variable, and that if
-binary was built with offload support, that 1 co-processor per node
+co-processors are present and the binary was built with offload support,
-will be used with automatic balancing of work between the CPU and the
+that 1 co-processor per node will be used with automatic balancing of
-co-processor.
+work between the CPU and the co-processor.
 
 You can specify different options for the INTEL package by using
 the ``-pk intel Nphi`` :doc:`command-line switch <Run_options>` with

doc/src/Speed_kokkos.rst

@@ -67,6 +67,14 @@ version 23 November 2023 and Kokkos version 4.2.
    To build with Kokkos support for AMD GPUs, the AMD ROCm toolkit
    software version 5.2.0 or later must be installed on your system.
 
+.. admonition:: Intel Data Center GPU support
+   :class: note
+
+   Support for Kokkos with Intel Data Center GPU accelerators (formerly
+   known under the code name "Ponte Vecchio") in LAMMPS is still a work
+   in progress.  Only a subset of the functionality works correctly.
+   Please contact the LAMMPS developers if you run into problems.
+
 .. admonition:: CUDA and MPI library compatibility
    :class: note
 
@@ -77,16 +85,18 @@ version 23 November 2023 and Kokkos version 4.2.
    rank.  When running with multiple MPI ranks, you may see segmentation
    faults without GPU-aware MPI support. These can be avoided by adding
    the flags :doc:`-pk kokkos gpu/aware off <Run_options>` to the
-   LAMMPS command line or by using the command :doc:`package kokkos
+   LAMMPS command-line or by using the command :doc:`package kokkos
    gpu/aware off <package>` in the input file.
 
-.. admonition:: Intel Data Center GPU support
+.. admonition:: Using multiple MPI ranks per GPU
    :class: note
 
-   Support for Kokkos with Intel Data Center GPU accelerators (formerly
+   Unlike with the GPU package, there are limited benefits from using
-   known under the code name "Ponte Vecchio") in LAMMPS is still a work
+   multiple MPI processes per GPU with KOKKOS.  But when doing this it
-   in progress.  Only a subset of the functionality works correctly.
+   is **required** to enable CUDA MPS (`Multi-Process Service :: GPU
-   Please contact the LAMMPS developers if you run into problems.
+   Deployment and Management Documentation
+   <https://docs.nvidia.com/deploy/mps/index.html>`_ ) to get acceptable
+   performance.
 
 Building LAMMPS with the KOKKOS package
 """""""""""""""""""""""""""""""""""""""
@@ -365,13 +375,13 @@ one or more nodes, each with two GPUs:
 
 .. note::
 
-   When using a GPU, you will achieve the best performance if your
+   When using a GPU, you will achieve the best performance if your input
-   input script does not use fix or compute styles which are not yet
+   script does not use fix or compute styles which are not yet
    Kokkos-enabled. This allows data to stay on the GPU for multiple
    timesteps, without being copied back to the host CPU. Invoking a
-   non-Kokkos fix or compute, or performing I/O for
+   non-Kokkos fix or compute, or performing I/O for :doc:`thermo
-   :doc:`thermo <thermo_style>` or :doc:`dump <dump>` output will cause data
+   <thermo_style>` or :doc:`dump <dump>` output will cause data to be
-   to be copied back to the CPU incurring a performance penalty.
+   copied back to the CPU incurring a performance penalty.
 
 .. note::
 
@@ -379,6 +389,56 @@ one or more nodes, each with two GPUs:
    kspace, etc., you must set the environment variable ``CUDA_LAUNCH_BLOCKING=1``.
    However, this will reduce performance and is not recommended for production runs.
 
+Troubleshooting segmentation faults on GPUs
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+As noted above, KOKKOS by default assumes that the MPI library is
+GPU-aware.  This is not always the case and can lead to segmentation
+faults when using more than one MPI process.  Normally, LAMMPS will
+print a warning like "*Turning off GPU-aware MPI since it is not
+detected*", or an error message like "*Kokkos with GPU-enabled backend
+assumes GPU-aware MPI is available*", OR a **segmentation fault**.  To
+confirm that a segmentation fault is caused by this, you can turn off
+the GPU-aware assumption via the :doc:`package kokkos command <package>`
+or the corresponding command-line flag.
+
+If you still get a segmentation fault, despite running with only one MPI
+process or using the command-line flag to turn off expecting a GPU-aware
+MPI library, then using the CMake compile setting
+``-DKokkos_ENABLE_DEBUG=on`` or adding ``KOKKOS_DEBUG=yes`` to your
+machine makefile for building with traditional make will generate useful
+output that can be passed to the LAMMPS developers for further
+debugging.
+
+Troubleshooting memory allocation on GPUs
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+`Kokkos Tools <https://github.com/kokkos/kokkos-tools/>`_ provides a set
+of lightweight profiling and debugging utilities, which interface with
+instrumentation hooks (eg. `space-time-stack
+<https://github.com/kokkos/kokkos-tools/tree/develop/profiling/space-time-stack>`_)
+built directly into the Kokkos runtime.  After compiling a dynamic LAMMPS
+library, you then have to set the environment variable ``KOKKOS_TOOLS_LIBS``
+before executing your LAMMPS Kokkos run. Example:
+
+.. code-block:: bash
+
+    export KOKKOS_TOOLS_LIBS=${HOME}/kokkos-tools/src/tools/memory-events/kp_memory_event.so
+    mpirun -np 4 lmp_kokkos_cuda_openmpi -in in.lj -k on g 4 -sf kk
+
+Starting with the NVIDIA Pascal GPU architecture, CUDA supports
+`"Unified Virtual Memory" (UVM)
+<https://developer.nvidia.com/blog/unified-memory-cuda-beginners/>`_
+which enables allocating more memory than a GPU possesses by also using
+memory on the host CPU and then CUDA will transparently move data
+between CPU and GPU as needed.  The resulting LAMMPS performance depends
+on `memory access pattern, data residency, and GPU memory
+oversubscription
+<https://developer.nvidia.com/blog/improving-gpu-memory-oversubscription-performance/>`_
+. The CMake option ``-DKokkos_ENABLE_CUDA_UVM=on`` or the makefile
+setting ``KOKKOS_CUDA_OPTIONS=enable_lambda,force_uvm`` enables using
+:ref:`UVM with Kokkos <kokkos>` when compiling LAMMPS.
+
 Run with the KOKKOS package by editing an input script
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
@@ -423,7 +483,7 @@ in the ``kokkos-cuda.cmake`` CMake preset file.
    cmake -DKokkos_ENABLE_CUDA=yes -DKokkos_ENABLE_OPENMP=yes ../cmake
 
 The suffix "/kk" is equivalent to "/kk/device", and for Kokkos CUDA,
-using the ``-sf kk`` in the command line gives the default CUDA version
+using the ``-sf kk`` in the command-line gives the default CUDA version
 everywhere.  However, if the "/kk/host" suffix is added to a specific
 style in the input script, the Kokkos OpenMP (CPU) version of that
 specific style will be used instead.  Set the number of OpenMP threads
@@ -439,7 +499,7 @@ For example, the command to run with 1 GPU and 8 OpenMP threads is then:
 
    mpiexec -np 1 lmp_kokkos_cuda_openmpi -in in.lj -k on g 1 t 8 -sf kk
 
-Conversely, if the ``-sf kk/host`` is used in the command line and then
+Conversely, if the ``-sf kk/host`` is used in the command-line and then
 the "/kk" or "/kk/device" suffix is added to a specific style in your
 input script, then only that specific style will run on the GPU while
 everything else will run on the CPU in OpenMP mode. Note that the
@@ -451,7 +511,7 @@ on the host CPU can overlap with a pair style running on the
 GPU. First compile with ``--default-stream per-thread`` added to ``CCFLAGS``
 in the Kokkos CUDA Makefile.  Then explicitly use the "/kk/host"
 suffix for kspace and bonds, angles, etc.  in the input file and the
-"kk" suffix (equal to "kk/device") on the command line.  Also make
+"kk" suffix (equal to "kk/device") on the command-line.  Also make
 sure the environment variable ``CUDA_LAUNCH_BLOCKING`` is not set to "1"
 so CPU/GPU overlap can occur.
 

doc/src/Speed_omp.rst

@@ -21,7 +21,7 @@ Building LAMMPS with the OPENMP package
 See the :ref:`Build extras <openmp>` page for
 instructions.
 
-Run with the OPENMP package from the command line
+Run with the OPENMP package from the command-line
 """""""""""""""""""""""""""""""""""""""""""""""""""
 
 These examples assume one or more 16-core nodes.

doc/src/Speed_opt.rst

@@ -17,7 +17,7 @@ Building LAMMPS with the OPT package
 
 See the :ref:`Build extras <opt>` page for instructions.
 
-Run with the OPT package from the command line
+Run with the OPT package from the command-line
 """"""""""""""""""""""""""""""""""""""""""""""
 
 .. code-block:: bash

doc/src/Tools.rst

@@ -501,7 +501,7 @@ Here are a few highlights of LAMMPS-GUI
 - Indicator for line that caused an error
 - Visualization of current state in Image Viewer (via calling :doc:`write_dump image <dump_image>`)
 - Capture of images created via :doc:`dump image <dump_image>` in Slide show window
-- Dialog to set variables, similar to the LAMMPS command line flag '-v' / '-var'
+- Dialog to set variables, similar to the LAMMPS command-line flag '-v' / '-var'
 - Support for GPU, INTEL, KOKKOS/OpenMP, OPENMAP, and OPT and accelerator packages
 
 Parallelization
@@ -550,7 +550,7 @@ will be found automatically.  2) you can download the `Flatpak file
 *flatpak* command: ``flatpak install --user
 LAMMPS-Linux-x86_64-GUI-<version>.flatpak`` and run it with ``flatpak
 run org.lammps.lammps-gui``.  The flatpak bundle also includes the
-command line version of LAMMPS and some LAMMPS tools like msi2lmp.  The
+command-line version of LAMMPS and some LAMMPS tools like msi2lmp.  The
 can be launched by using the ``--command`` flag. For example to run
 LAMMPS directly on the ``in.lj`` benchmark input you would type in the
 ``bench`` folder: ``flatpak run --command=lmp -in in.lj`` The flatpak
@@ -608,10 +608,10 @@ would be the ``examples/COUPLE/plugin`` folder of the LAMMPS
 distribution.
 
 When compiling LAMMPS-GUI with plugin support, there is an additional
-command line flag (``-p <path>`` or ``--pluginpath <path>``) which
+command-line flag (``-p <path>`` or ``--pluginpath <path>``) which
 allows to override the path to LAMMPS shared library used by the GUI.
 This is usually auto-detected on the first run and can be changed in the
-LAMMPS-GUI *Preferences* dialog.  The command line flag allows to reset
+LAMMPS-GUI *Preferences* dialog.  The command-line flag allows to reset
 this path to a valid value in case the original setting has become
 invalid.  An empty path ("") as argument restores the default setting.
 
@@ -656,7 +656,7 @@ it will create a compressed ``LAMMPS-Win10-amd64.zip`` zip file with the
 executables and required dependent .dll files.  This zip file can be
 uncompressed and ``lammps-gui.exe`` run directly from there.  The
 uncompressed folder can be added to the ``PATH`` environment and LAMMPS
-and LAMMPS-GUI can be launched from anywhere from the command line.
+and LAMMPS-GUI can be launched from anywhere from the command-line.
 
 **MinGW64 Cross-compiler**
 
@@ -876,7 +876,7 @@ the same ``LAMMPS_CACHING_DIR``. This script does the following:
  #. Start a simple local HTTP server using Python to host files for CMake
 
 Afterwards, it will print out instruction on how to modify the CMake
-command line to make sure it uses the local HTTP server.
+commands to make sure it uses the local HTTP server.
 
 To undo the environment changes and shutdown the local HTTP server,
 run the ``deactivate_caches`` command.
@@ -1025,7 +1025,7 @@ with those in the provided log file with the same number of processors
 in the same subdirectory. If the differences between the actual and
 reference values are within specified tolerances, the test is considered
 passed.  For each test batch, that is, a set of example input scripts,
-the mpirun command, the LAMMPS command line arguments, and the
+the mpirun command, the LAMMPS command-line arguments, and the
 tolerances for individual thermo quantities can be specified in a
 configuration file in YAML format.
 

doc/src/angle_mwlc.rst

@@ -0,0 +1,94 @@
+.. index:: angle_style mwlc
+
+angle_style mwlc command
+==========================
+
+Syntax
+""""""
+
+.. code-block:: LAMMPS
+
+   angle_style mwlc
+
+Examples
+""""""""
+
+.. code-block:: LAMMPS
+
+   angle_style mwlc
+   angle_coeff * 25 1 10 1
+
+Description
+"""""""""""
+
+.. versionadded:: TBD
+
+The *mwlc* angle style models a meltable wormlike chain and can be used
+to model non-linear bending elasticity of polymers, e.g. DNA.  *mwlc*
+uses a potential that is a canonical-ensemble superposition of a
+non-melted and a melted state :ref:`(Farrell) <Farrell>`.  The potential
+is
+
+.. math::
+
+    E = -k_{B}T\,\log [q + q^{m}] + E_{0},
+
+where the non-melted and melted partition functions are
+
+.. math::
+    q = \exp [-k_{1}(1+\cos{\theta})/k_{B}T]; \\
+    q^{m} = \exp [-(\mu+k_{2}(1+\cos{\theta}))/k_{B}T].
+
+:math:`k_1` is the bending elastic constant of the non-melted state,
+:math:`k_2` is the bending elastic constant of the melted state,
+:math:`\mu` is the melting energy, and
+:math:`T` is the reference temperature.
+The reference energy,
+
+.. math::
+    E_{0} = -k_{B}T\,\log [1 + \exp[-\mu/k_{B}T]],
+
+ensures that E is zero for a fully extended chain.
+
+This potential is a continuous version of the two-state potential
+introduced by :ref:`(Yan) <Yan>`.
+
+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_1` (energy)
+* :math:`k_2` (energy)
+* :math:`\mu` (energy)
+* :math:`T` (temperature)
+
+----------
+
+
+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
+
+----------
+
+.. _Farrell:
+
+**(Farrell)** `Farrell, Dobnikar, Podgornik, Curk, Phys Rev Lett, 133, 148101 (2024). <https://doi.org/10.1103/PhysRevLett.133.148101>`_
+
+.. _Yan:
+
+**(Yan)** `Yan, Marko, Phys Rev Lett, 93, 108108 (2004). <https://doi.org/10.1103/PhysRevLett.93.108108>`_

doc/src/angle_style.rst

@@ -94,6 +94,7 @@ of (g,i,k,o,t) to indicate which accelerated styles exist.
 * :doc:`lepton <angle_lepton>` - angle potential from evaluating a string
 * :doc:`mesocnt <angle_mesocnt>` - piecewise harmonic and linear angle for bending-buckling of nanotubes
 * :doc:`mm3 <angle_mm3>` - anharmonic angle
+* :doc:`mwlc <angle_mwlc>` - meltable wormlike chain
 * :doc:`quartic <angle_quartic>` - angle with cubic and quartic terms
 * :doc:`spica <angle_spica>` - harmonic angle with repulsive SPICA pair style between 1-3 atoms
 * :doc:`table <angle_table>` - tabulated by angle

doc/src/bond_bpm_rotational.rst

@@ -155,7 +155,7 @@ page on BPMs.
 If the *break* keyword is set to *no*, LAMMPS assumes bonds should not break
 during a simulation run. This will prevent some unnecessary calculation.
 The recommended bond communication distance no longer depends on bond failure
-coefficients (which are ignored) but instead corresponds to the typical heurestic
+coefficients (which are ignored) but instead corresponds to the typical heuristic
 maximum strain used by typical non-bpm bond styles. Similar behavior to *break no*
 can also be attained by setting arbitrarily high values for all four failure
 coefficients. One cannot use *break no* with *smooth yes*.

doc/src/bond_bpm_spring.rst

@@ -119,7 +119,7 @@ If the *break* keyword is set to *no*, LAMMPS assumes bonds should not break
 during a simulation run. This will prevent some unnecessary calculation.
 The recommended bond communication distance no longer depends on the value of
 :math:`\epsilon_c` (which is ignored) but instead corresponds to the typical
-heurestic maximum strain used by typical non-bpm bond styles. Similar behavior
+heuristic maximum strain used by typical non-bpm bond styles. Similar behavior
 to *break no* can also be attained by setting an arbitrarily high value of
 :math:`\epsilon_c`. One cannot use *break no* with *smooth yes*.
 

doc/src/compute.rst

@@ -236,6 +236,7 @@ The individual style names on the :doc:`Commands compute <Commands_compute>` pag
 * :doc:`fep/ta <compute_fep_ta>` - compute free energies for a test area perturbation
 * :doc:`force/tally <compute_tally>` - force between two groups of atoms via the tally callback mechanism
 * :doc:`fragment/atom <compute_cluster_atom>` - fragment ID for each atom
+* :doc:`gaussian/grid/local <compute_gaussian_grid_local>` - local array of Gaussian atomic contributions on a regular grid
 * :doc:`global/atom <compute_global_atom>` - assign global values to each atom from arrays of global values
 * :doc:`group/group <compute_group_group>` - energy/force between two groups of atoms
 * :doc:`gyration <compute_gyration>` - radius of gyration of group of atoms

doc/src/compute_gaussian_grid_local.rst

@@ -0,0 +1,99 @@
+.. index:: compute gaussian/grid/local
+.. index:: compute gaussian/grid/local/kk
+
+compute gaussian/grid/local command
+===================================
+
+Accelerator Variants: *gaussian/grid/local/kk*
+
+Syntax
+""""""
+
+.. code-block:: LAMMPS
+
+   compute ID group-ID gaussian/grid/local grid nx ny nz rcutfac  R_1 R_2 ... sigma_1 sigma_2
+
+* ID, group-ID are documented in :doc:`compute <compute>` command
+* gaussian/grid/local = style name of this compute command
+* *grid* values = nx, ny, nz, number of grid points in x, y, and z directions (positive integer)
+* *rcutfac* = scale factor applied to all cutoff radii (positive real)
+* *R_1, R_2,...* = list of cutoff radii, one for each type (distance units)
+* *sigma_1, sigma_2,...* = Gaussian widths, one for each type (distance units)
+
+Examples
+""""""""
+
+.. code-block:: LAMMPS
+
+    compute mygrid all gaussian/grid/local grid 40 40 40 4.0 0.5 0.5 0.4 0.4
+
+Description
+"""""""""""
+
+.. versionadded:: TBD
+
+Define a computation that calculates a Gaussian representation of the ionic
+structure. This representation is used for the efficient evaluation
+of quantities related to the structure factor in a grid-based workflow,
+such as the ML-DFT workflow MALA :ref:`(Ellis) <Ellis2021b>`, for which it was originally
+implemented. Usage of the workflow is described in a separate publication :ref:`(Fiedler) <Fiedler2023>`.
+
+For each LAMMPS type, a separate sum of Gaussians is calculated, using
+a separate Gaussian broadening per type. The computation
+is always performed on the numerical grid, no atom-based version of this
+compute exists. The Gaussian representation can only be executed in a local
+fashion, thus the output array only contains rows for grid points
+that are local to the processor subdomain. The layout of the grid is the same
+as for the see :doc:`sna/grid/local <compute_sna_atom>` command.
+
+Namely, the array contains one row for each of the
+local grid points, looping over the global index *ix* fastest,
+then *iy*, and *iz* slowest.  Each row of the array contains
+the global indexes *ix*, *iy*, and *iz* first, followed by the *x*, *y*,
+and *z* coordinates of the grid point, followed by the values of the Gaussians
+(one floating point number per type per grid point).
+
+----------
+
+
+.. include:: accel_styles.rst
+
+
+
+----------
+
+Output info
+"""""""""""
+
+Compute *gaussian/grid/local* evaluates a local array.
+The array contains one row for each of the
+local grid points, looping over the global index *ix* fastest,
+then *iy*, and *iz* slowest.  The array contains math :math:`ntypes+6` columns,
+where *ntypes* is the number of LAMMPS types. The first three columns are
+the global indexes *ix*, *iy*, and *iz*, followed by the *x*, *y*,
+and *z* coordinates of the grid point, followed by the *ntypes* columns
+containing the values of the Gaussians for each type.
+
+Restrictions
+""""""""""""
+
+These computes are part of the ML-SNAP package.  They are only enabled
+if LAMMPS was built with that package.  See the :doc:`Build package
+<Build_package>` page for more info.
+
+Related commands
+""""""""""""""""
+
+:doc:`compute sna/grid/local <compute_sna_atom>`
+
+----------
+
+.. _Ellis2021b:
+
+**(Ellis)** Ellis, Fiedler, Popoola, Modine, Stephens, Thompson, Cangi, Rajamanickam, `Phys. Rev. B, 104, 035120, (2021) <https://doi.org/10.1103/PhysRevB.104.035120>`_
+
+.. _Fiedler2023:
+
+**(Fiedler)** Fiedler, Modine, Schmerler, Vogel, Popoola, Thompson, Rajamanickam, and Cangi,
+`npj Comp. Mater., 9, 115 (2023) <https://doi.org/10.1038/s41524-023-01070-z>`_
+

doc/src/compute_sna_atom.rst

@@ -3,7 +3,9 @@
 .. index:: compute snav/atom
 .. index:: compute snap
 .. index:: compute sna/grid
+.. index:: compute sna/grid/kk
 .. index:: compute sna/grid/local
+.. index:: compute sna/grid/local/kk
 
 compute sna/atom command
 ========================
@@ -20,9 +22,14 @@ compute snap command
 compute sna/grid command
 ========================
 
+compute sna/grid/kk command
+===========================
+
 compute sna/grid/local command
 ==============================
 
+Accelerator Variants: *sna/grid/local/kk*
+
 Syntax
 """"""
 
@@ -33,17 +40,17 @@ Syntax
    compute ID group-ID snav/atom rcutfac rfac0 twojmax R_1 R_2 ... w_1 w_2 ... keyword values ...
    compute ID group-ID snap rcutfac rfac0 twojmax R_1 R_2 ... w_1 w_2 ... keyword values ...
    compute ID group-ID snap rcutfac rfac0 twojmax R_1 R_2 ... w_1 w_2 ... keyword values ...
-   compute ID group-ID sna/grid nx ny nz rcutfac rfac0 twojmax R_1 R_2 ... w_1 w_2 ... keyword values ...
+   compute ID group-ID sna/grid grid nx ny nz rcutfac rfac0 twojmax R_1 R_2 ... w_1 w_2 ... keyword values ...
-   compute ID group-ID sna/grid/local nx ny nz rcutfac rfac0 twojmax R_1 R_2 ... w_1 w_2 ... keyword values ...
+   compute ID group-ID sna/grid/local grid nx ny nz rcutfac rfac0 twojmax R_1 R_2 ... w_1 w_2 ... keyword values ...
 
 * ID, group-ID are documented in :doc:`compute <compute>` command
 * sna/atom = style name of this compute command
-* rcutfac = scale factor applied to all cutoff radii (positive real)
+* *rcutfac* = scale factor applied to all cutoff radii (positive real)
-* rfac0 = parameter in distance to angle conversion (0 < rcutfac < 1)
+* *rfac0* = parameter in distance to angle conversion (0 < rcutfac < 1)
-* twojmax = band limit for bispectrum components (non-negative integer)
+* *twojmax* = band limit for bispectrum components (non-negative integer)
-* R_1, R_2,... = list of cutoff radii, one for each type (distance units)
+* *R_1, R_2,...* = list of cutoff radii, one for each type (distance units)
-* w_1, w_2,... = list of neighbor weights, one for each type
+* *w_1, w_2,...* = list of neighbor weights, one for each type
-* nx, ny, nz = number of grid points in x, y, and z directions (positive integer)
+* *grid* values = nx, ny, nz, number of grid points in x, y, and z directions (positive integer)
 * zero or more keyword/value pairs may be appended
 * keyword = *rmin0* or *switchflag* or *bzeroflag* or *quadraticflag* or *chem* or *bnormflag* or *wselfallflag* or *bikflag* or *switchinnerflag* or *sinner* or *dinner* or *dgradflag* or *nnn* or *wmode* or *delta*
 
@@ -103,7 +110,7 @@ Examples
    compute snap all snap 1.4 0.95 6 2.0 1.0
    compute snap all snap 1.0 0.99363 6 3.81 3.83 1.0 0.93 chem 2 0 1
    compute snap all snap 1.0 0.99363 6 3.81 3.83 1.0 0.93 switchinnerflag 1 sinner 1.35 1.6 dinner 0.25 0.3
-   compute bgrid all sna/grid/local 200 200 200 1.4 0.95 6 2.0 1.0
+   compute bgrid all sna/grid/local grid 200 200 200 1.4 0.95 6 2.0 1.0
    compute bnnn all sna/atom 9.0 0.99363 8 0.5 1.0 rmin0 0.0 nnn 24 wmode 1 delta 0.2
 
 Description
@@ -252,7 +259,8 @@ for finite-temperature Kohn-Sham density functional theory (:ref:`Ellis
 et al. <Ellis2021>`) Neighbor atoms not in the group do not contribute
 to the bispectrum components of the grid points. The distance cutoff
 :math:`R_{ii'}` assumes that *i* has the same type as the neighbor atom
-*i'*.
+*i'*. Both computes can be hardware accelerated with Kokkos by using the
+*sna/grid/kk* and *sna/grid/local/kk* commands, respectively.
 
 Compute *sna/grid* calculates a global array containing bispectrum
 components for a regular grid of points.
@@ -463,6 +471,12 @@ fluctuations in the resulting local atomic environment fingerprint.  The
 detailed formalism is given in the paper by Lafourcade et
 al. :ref:`(Lafourcade) <Lafourcade2023_2>`.
 
+----------
+
+
+.. include:: accel_styles.rst
+
+
 ----------
 
 Output info
@@ -654,7 +668,7 @@ of Angular Momentum, World Scientific, Singapore (1987).
 
 .. _Ellis2021:
 
-**(Ellis)** Ellis, Fiedler, Popoola, Modine, Stephens, Thompson, Cangi, Rajamanickam,  Phys Rev B, 104, 035120, (2021)
+**(Ellis)** Ellis, Fiedler, Popoola, Modine, Stephens, Thompson, Cangi, Rajamanickam, `Phys. Rev. B, 104, 035120, (2021) <https://doi.org/10.1103/PhysRevB.104.035120>`_
 
 .. _Lafourcade2023_2:
 

doc/src/compute_sph_e_atom.rst

@@ -33,6 +33,12 @@ particle.
 See `this PDF guide <PDF/SPH_LAMMPS_userguide.pdf>`_ to using SPH in
 LAMMPS.
 
+.. note::
+
+   Please note that the SPH PDF guide file has not been updated for
+   many years and thus does not reflect the current *syntax* of the
+   SPH package commands. For that please refer to the LAMMPS manual.
+
 The value of the internal energy will be 0.0 for atoms not in the
 specified compute group.
 

doc/src/compute_sph_rho_atom.rst

@@ -32,6 +32,12 @@ kernel function interpolation using "pair style sph/rhosum".
 See `this PDF guide <PDF/SPH_LAMMPS_userguide.pdf>`_ to using SPH in
 LAMMPS.
 
+.. note::
+
+   Please note that the SPH PDF guide file has not been updated for
+   many years and thus does not reflect the current *syntax* of the
+   SPH package commands. For that please refer to the LAMMPS manual.
+
 The value of the SPH density will be 0.0 for atoms not in the
 specified compute group.
 

doc/src/compute_sph_t_atom.rst

@@ -37,6 +37,12 @@ particles, i.e. a Smooth-Particle Hydrodynamics particle.
 See `this PDF guide <PDF/SPH_LAMMPS_userguide.pdf>`_ to using SPH in
 LAMMPS.
 
+.. note::
+
+   Please note that the SPH PDF guide file has not been updated for
+   many years and thus does not reflect the current *syntax* of the
+   SPH package commands. For that please refer to the LAMMPS manual.
+
 The value of the internal energy will be 0.0 for atoms not in the
 specified compute group.
 

doc/src/compute_temp_chunk.rst

@@ -184,11 +184,24 @@ temp/chunk calculation to a file is to use the
 The keyword/value option pairs are used in the following ways.
 
 The *com* keyword can be used with a value of *yes* to subtract the
-velocity of the center-of-mass for each chunk from the velocity of the
+velocity of the center-of-mass (VCM) for each chunk from the velocity of
-atoms in that chunk, before calculating either the global or per-chunk
+the atoms in that chunk, before calculating either the global or per-chunk
-temperature.  This can be useful if the atoms are streaming or
+temperature. This can be useful if the atoms are streaming or
 otherwise moving collectively, and you wish to calculate only the
-thermal temperature.
+thermal temperature. This per-chunk VCM bias can be used in other fixes and
+computes that can incorporate a temperature bias. If this compute is used
+as a temperature bias in other commands then this bias is subtracted from
+each atom, the command runs with the remaining thermal velocities, and
+then the bias is added back in. This includes thermostatting
+fixes like :doc:`fix nvt <fix_nh>`,
+:doc:`fix temp/rescale <fix_temp_rescale>`,
+:doc:`fix temp/berendsen <fix_temp_berendsen>`, and
+:doc:`fix langevin <fix_langevin>`, and computes like
+:doc:`compute stress/atom <compute_stress_atom>` and
+:doc:`compute pressure <compute_pressure>`. See the input script in
+examples/stress_vcm for an example of how to use the *com* keyword in
+conjunction with compute stress/atom to create a stress profile of a rigid
+body while removing the overall motion of the rigid body.
 
 For the *bias* keyword, *bias-ID* refers to the ID of a temperature
 compute that removes a "bias" velocity from each atom.  This also

doc/src/delete_bonds.rst

@@ -62,6 +62,18 @@ For all styles, by default, an interaction is only turned off (or on)
 if all the atoms involved are in the specified group.  See the *any*
 keyword to change the behavior.
 
+.. admonition:: Possible errors caused by using *delete_bonds*
+   :class: warning
+
+   Since this command by default only *turns off* bonded interactions,
+   their definitions are still present and subject to the limitations
+   due to LAMMPS' domain decomposition based parallelization.  That is,
+   when a bond is turned off, the two constituent atoms may move apart
+   and may reach a distance where they can lead to a "bond atoms missing"
+   error and crash the simulation.  Adding the *remove* keyword (see
+   below) is required to fully remove those interactions and prevent
+   the error.
+
 Several of the styles (\ *atom*, *bond*, *angle*, *dihedral*, *improper*\ )
 take a *type* as an argument.  The specified *type* can be a
 :doc:`type label <Howto_type_labels>`.  Otherwise, the type should be an
@@ -98,15 +110,18 @@ of all interactions in the specified group is simply reported.  This
 is useful for diagnostic purposes if bonds have been turned off by a
 bond-breaking potential during a previous run.
 
-The default behavior of the delete_bonds command is to turn off
+.. admonition:: Impact on special_bonds processing and exclusions
-interactions by toggling their type to a negative value, but not to
+   :class: note
-permanently remove the interaction.  For example, a bond_type of 2 is set to
+
-:math:`-2.`  The neighbor list creation routines will not include such an
+   The default behavior of the delete_bonds command is to turn off
-interaction in their interaction lists.  The default is also to not
+   interactions by toggling their type to a negative value, but not to
-alter the list of 1--2, 1--3, or 1--4 neighbors computed by the
+   permanently remove the interaction.  For example, a bond_type of 2 is set to
-:doc:`special_bonds <special_bonds>` command and used to weight pairwise
+   :math:`-2.`  The neighbor list creation routines will not include such an
-force and energy calculations.  This means that pairwise computations
+   interaction in their interaction lists.  The default is also to not
-will proceed as if the bond (or angle, etc.) were still turned on.
+   alter the list of 1--2, 1--3, or 1--4 neighbors computed by the
+   :doc:`special_bonds <special_bonds>` command and used to weight pairwise
+   force and energy calculations.  This means that pairwise computations
+   will proceed as if the bond (or angle, etc.) were still turned on.
 
 Several keywords can be appended to the argument list to alter the
 default behaviors.
@@ -138,9 +153,11 @@ operation, after (optional) removal.  It re-computes the pairwise 1--2,
 turned-off bonds the same as turned-on.  Thus, turned-off bonds must
 be removed if you wish to change the weighting list.
 
-Note that the choice of *remove* and *special* options affects how
+.. note::
-1--2, 1--3, 1--4 pairwise interactions will be computed across bonds that
+
-have been modified by the delete_bonds command.
+   The choice of *remove* and *special* options affects how 1--2,
+   1--3, 1--4 pairwise interactions will be computed across bonds
+   that have been modified by the delete_bonds command.
 
 Restrictions
 """"""""""""

doc/src/dump_image.rst

@@ -681,7 +681,7 @@ MPEG or other movie file you can use:
 
 * c) Use FFmpeg
 
-  FFmpeg is a command line tool that is available on many platforms and
+  FFmpeg is a command-line tool that is available on many platforms and
   allows extremely flexible encoding and decoding of movies.
 
   .. code-block:: bash

doc/src/fix.rst

@@ -237,6 +237,7 @@ accelerated styles exist.
 * :doc:`dt/reset <fix_dt_reset>` - reset the timestep based on velocity, forces
 * :doc:`edpd/source <fix_dpd_source>` - add heat source to eDPD simulations
 * :doc:`efield <fix_efield>` - impose electric field on system
+* :doc:`efield/lepton <fix_efield_lepton>` - impose electric field on system using a Lepton expression for the potential
 * :doc:`efield/tip4p <fix_efield>` - impose electric field on system with TIP4P molecules
 * :doc:`ehex <fix_ehex>` - enhanced heat exchange algorithm
 * :doc:`electrode/conp <fix_electrode>` - impose electric potential

doc/src/fix_adapt.rst

@@ -406,6 +406,8 @@ sub-style name. The angle styles that currently work with fix adapt are:
 +--------------------------------------------------------------------+--------------------+-------------+
 | :doc:`mm3 <angle_mm3>`                                             | k,theta0           | type angles |
 +--------------------------------------------------------------------+--------------------+-------------+
+| :doc:`mwlc <angle_mwlc>`                                           | k1,k2,mu,T         | type angles |
++--------------------------------------------------------------------+--------------------+-------------+
 | :doc:`quartic <angle_quartic>`                                     | k2,k3,k4,theta0    | type angles |
 +--------------------------------------------------------------------+--------------------+-------------+
 | :doc:`spica <angle_spica>`                                         | k,theta0           | type angles |

doc/src/fix_efield.rst

@@ -45,8 +45,9 @@ Description
 
 Add a force :math:`\vec{F} = q\vec{E}` to each charged atom in the group due to an
 external electric field being applied to the system.  If the system
-contains point-dipoles, also add a torque on the dipoles due to the
+contains point-dipoles, also add a torque :math:`\vec{T} = \vec{p} \times \vec{E}` on the dipoles due to the
-external electric field.
+external electric field. This fix does not compute the dipole force :math:`\vec{F} = (\vec{p} \cdot \nabla) \vec{E}`,
+and the :doc:`fix efield/lepton <fix_efield_lepton>` command should be used instead.
 
 .. versionadded:: 28Mar2023
 
@@ -68,6 +69,7 @@ For point-dipoles, equal-style variables can be used, but atom-style
 variables are not currently supported, since they imply a spatial
 gradient in the electric field which means additional terms with
 gradients of the field are required for the force and torque on dipoles.
+The :doc:`fix efield/lepton <fix_efield_lepton>` command should be used instead.
 
 Equal-style variables can specify formulas with various mathematical
 functions, and include :doc:`thermo_style <thermo_style>` command
@@ -229,7 +231,7 @@ Fix style *efield/tip4p* can only be used with tip4p pair styles.
 Related commands
 """"""""""""""""
 
-:doc:`fix addforce <fix_addforce>`
+:doc:`fix addforce <fix_addforce>`, :doc:`fix efield/lepton <fix_efield_lepton>`
 
 Default
 """""""

doc/src/fix_efield_lepton.rst

@@ -0,0 +1,143 @@
+.. index:: fix efield/lepton
+
+fix efield/lepton command
+=========================
+
+Syntax
+""""""
+
+.. code-block:: LAMMPS
+
+   fix ID group-ID efield/lepton V ...
+
+* ID, group-ID are documented in the :doc:`fix <fix>` command
+* style = *efield/lepton*
+* V = electric potential (electric field * distance units)
+* V must be a Lepton expression (see below)
+* zero or more keyword/value pairs may be appended to args
+* keyword = *region* or *step*
+
+  .. parsed-literal::
+
+       *region* value = region-ID
+         region-ID = ID of region atoms must be in to have effect
+       *step* value = h
+         h = step size for numerical differentiation (distance units)
+
+Examples
+""""""""
+
+.. code-block:: LAMMPS
+
+   fix ex all efield/lepton "-E*x; E=1"
+   fix dexx all efield/lepton "-0.5*x^2" step 1
+   fix yukawa all efield/lepton "A*exp(-B*r)/r; r=abs(sqrt(x^2+y^2+z^2)); A=1; B=1" step 1e-6
+   fix infp all efield/lepton "-abs(x)" step 1
+
+   variable th equal 2*PI*ramp(0,1)
+   fix erot all efield/lepton "-(x*cos(v_th)+y*sin(v_th))"
+
+Description
+"""""""""""
+
+.. versionadded:: TBD
+
+Add an electric potential :math:`V` that applies to a group of charged atoms a force :math:`\vec{F} = q \vec{E}`,
+and to dipoles a force :math:`\vec{F} = (\vec{p} \cdot \nabla) \vec{E}` and torque :math:`\vec{T} = \vec{p} \times \vec{E}`,
+where :math:`\vec{E} = - \nabla V`. The fix also evaluates the electrostatic energy (:math:`U_{q} = q V` and :math:`U_{p} = - \vec{p} \cdot \vec{E}`)
+due to this potential when the :doc:`fix_modify energy yes <fix_modify>` command is specified (see below).
+
+.. note::
+
+   This command should be used instead of :doc:`fix efield <fix_efield>` if you want to impose a non-uniform electric field on a system with dipoles
+   since the latter does not include the dipole force term. If you only have charges or if the electric field gradient is negligible,
+   :doc:`fix efield <fix_efield>` should be used since it is faster.
+
+The `Lepton library <https://simtk.org/projects/lepton>`_, that the *efield/lepton* fix style interfaces with, evaluates
+the expression string at run time to compute the energy, forces, and torques. It creates an analytical representation
+of :math:`V` and :math:`\vec{E}`, while the gradient force is computed using a central difference scheme
+
+.. math::
+
+   \vec{F} = \frac{|\vec{p}|}{2h} \left[ \vec{E}(\vec{x} + h \hat{p}) - \vec{E}(\vec{x} - h \hat{p}) \right] .
+
+The Lepton expression must be either enclosed in quotes or must not contain any whitespace so that LAMMPS
+recognizes it as a single keyword. More on valid Lepton expressions below. The final Lepton expression must
+be a function of only :math:`x, y, z`, which refer to the current *unwrapped* coordinates of the atoms to ensure continuity.
+Special care must be taken when using this fix with periodic boundary conditions or box-changing commands.
+
+----------
+
+.. include:: lepton_expression.rst
+
+----------
+
+If the *region* keyword is used, the atom must also be in the specified
+geometric :doc:`region <region>` in order to be affected by the potential.
+
+The *step* keyword is required when :doc:`atom_style dipole <atom_style>` is used and the electric field is non-uniform.
+
+----------
+
+Restart, fix_modify, output, run start/stop, minimize info
+"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
+
+No information about this fix is written to :doc:`binary restart files
+<restart>`.
+
+The :doc:`fix_modify <fix_modify>` *energy* option is supported by this
+fix to add the potential energy defined above to the global potential energy
+of the system as part of :doc:`thermodynamic output <thermo_style>`.
+The default setting for this fix is :doc:`fix_modify energy no <fix_modify>`.
+
+The :doc:`fix_modify <fix_modify>` *virial* option is supported by this
+fix to add the contribution due to the added ***forces*** on charges and dipoles
+to both the global pressure and per-atom stress of the system via the
+:doc:`compute pressure <compute_pressure>` and :doc:`compute stress/atom
+<compute_stress_atom>` commands. The former can be accessed by
+:doc:`thermodynamic output <thermo_style>`. The default setting for
+this fix is :doc:`fix_modify virial no <fix_modify>`.
+
+The :doc:`fix_modify <fix_modify>` *respa* option is supported by this
+fix. This allows to set at which level of the :doc:`r-RESPA <run_style>`
+integrator the fix adding its forces. Default is the outermost level.
+
+This fix computes a global scalar and a global 3-vector of forces,
+which can be accessed by various :doc:`output commands <Howto_output>`.
+The scalar is the potential energy discussed above.
+The vector is the total force added to the group of atoms.
+The scalar and vector values calculated by this fix are "extensive".
+
+This fix cannot be used with the *start/stop* keywords of
+the :doc:`run <run>` command.
+
+The forces due to this fix are imposed during an energy minimization,
+invoked by the :doc:`minimize <minimize>` command. You should not
+specify force components with a variable that has time-dependence for
+use with a minimizer, since the minimizer increments the timestep as
+the iteration count during the minimization.
+
+.. note::
+
+   If you want the electric potential energy to be included in the
+   total potential energy of the system (the quantity being minimized),
+   you MUST enable the :doc:`fix_modify <fix_modify>` *energy* option for this fix.
+
+----------
+
+Restrictions
+""""""""""""
+
+Fix style *efield/lepton* is part of the LEPTON package. It is only enabled if LAMMPS was built with that package.
+See the :doc:`Build package <Build_package>` page for more info.
+
+
+Related commands
+""""""""""""""""
+
+:doc:`fix efield <fix_efield>`
+
+Default
+"""""""
+
+none

doc/src/fix_imd.rst

@@ -26,6 +26,29 @@ Syntax
        *nowait* arg = *on* or *off*
          off = LAMMPS waits to be connected to an IMD client before continuing (default)
          on = LAMMPS listens for an IMD client, but continues with the run
+       *version* arg = *2* or *3*
+         2 = use IMD protocol version 2 (default)
+         3 = use IMD protocol version 3.
+
+  The following keywords are only supported for IMD protocol version 3.
+
+  .. parsed-literal::
+
+       *time* arg = *on* or *off*
+          off = simulation time is not transmitted (default)
+          on = simulation time is transmitted.
+       *box* arg = *on* or *off*
+          off = simulation box data is not transmitted (default)
+          on = simulation box data is transmitted.
+       *coordinates* arg = *on* or *off*
+          off = atomic coordinates are not transmitted (default)
+          on = atomic coordinates are transmitted.
+       *velocities* arg = *on* or *off*
+          off = atomic velocities are not transmitted (default)
+          on = atomic velocities are transmitted.
+       *forces* arg = *on* or *off*
+          off = atomic forces are not transmitted (default)
+          on = atomic forces are transmitted.
 
 Examples
 """"""""
@@ -40,16 +63,19 @@ Description
 
 This fix implements the "Interactive MD" (IMD) protocol which allows
 realtime visualization and manipulation of MD simulations through the
-IMD protocol, as initially implemented in VMD and NAMD.  Specifically
+IMD protocol, as initially implemented in VMD and NAMD.  Specifically it
-it allows LAMMPS to connect an IMD client, for example the `VMD visualization program <VMD_>`_, so that it can monitor the progress of the
+allows LAMMPS to connect an IMD client, for example the `VMD
-simulation and interactively apply forces to selected atoms.
+visualization program <VMD_>`_ (currently only supports IMDv2) or the
+`Python IMDClient <IMDClient_>`_ (supports both IMDv2 and IMDv3), so
+that it can monitor the progress of the simulation and interactively
+apply forces to selected atoms.
 
-If LAMMPS is compiled with the pre-processor flag -DLAMMPS_ASYNC_IMD
+If LAMMPS is compiled with the pre-processor flag
-then fix imd will use POSIX threads to spawn a IMD communication
+:ref:`-DLAMMPS_ASYNC_IMD <misc>` then fix imd will use POSIX threads to
-thread on MPI rank 0 in order to offload data reading and writing
+spawn an IMD communication thread on MPI rank 0 in order to offload data
-from the main execution thread and potentially lower the inferred
+exchange with the IMD client from the main execution thread and
-latencies for slow communication links. This feature has only been
+potentially lower the inferred latencies for slow communication
-tested under linux.
+links. This feature has only been tested under linux.
 
 The source code for this fix includes code developed by the Theoretical
 and Computational Biophysics Group in the Beckman Institute for Advanced
@@ -94,10 +120,19 @@ with different units or as a measure to tweak the forces generated by
 the manipulation of the IMD client, this option allows to make
 adjustments.
 
+.. versionadded:: TBD
+
+In `IMDv3 <IMDv3_>`_, the IMD protocol has been extended to allow for
+the transmission of simulation time, box dimensions, atomic coordinates,
+velocities, and forces. The *version* keyword allows to select the
+version of the protocol to be used. The *time*, *box*, *coordinates*,
+*velocities*, and *forces* keywords allow to select which data is
+transmitted to the IMD client. The default is to transmit all data.
+
 To connect VMD to a listening LAMMPS simulation on the same machine
 with fix imd enabled, one needs to start VMD and load a coordinate or
 topology file that matches the fix group.  When the VMD command
-prompts appears, one types the command line:
+prompts appears, one types the command:
 
 .. parsed-literal::
 
@@ -129,6 +164,10 @@ screen output is active.
 
 .. _imdvmd: https://www.ks.uiuc.edu/Research/vmd/imd/
 
+.. _IMDClient: https://github.com/Becksteinlab/imdclient/tree/main/imdclient
+
+.. _IMDv3: https://imdclient.readthedocs.io/en/latest/protocol_v3.html
+
 Restart, fix_modify, output, run start/stop, minimize info
 """""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 
@@ -147,14 +186,14 @@ This fix is part of the MISC package.  It is only enabled if LAMMPS was
 built with that package.  See the :doc:`Build package <Build_package>`
 page for more info.
 
-When used in combination with VMD, a topology or coordinate file has
+When used in combination with VMD, a topology or coordinate file has to
-to be loaded, which matches (in number and ordering of atoms) the
+be loaded, which matches (in number and ordering of atoms) the group the
-group the fix is applied to. The fix internally sorts atom IDs by
+fix is applied to.  The fix internally sorts atom IDs by ascending
-ascending integer value; in VMD (and thus the IMD protocol) those will
+integer value; in VMD (and thus the IMD protocol) those will be assigned
-be assigned 0-based consecutive index numbers.
+0-based consecutive index numbers.
 
 When using multiple active IMD connections at the same time, each
-needs to use a different port number.
+fix instance needs to use a different port number.
 
 Related commands
 """"""""""""""""

doc/src/fix_precession_spin.rst

@@ -135,7 +135,7 @@ directions for the forces. Only the direction of the vector is
 important; its length is ignored (the entered vectors are
 normalized).
 
-Those styles can be combined within one single command line.
+Those styles can be combined within one single command.
 
 .. note::
 

doc/src/fix_python_invoke.rst

@@ -66,6 +66,15 @@ gives access to the LAMMPS state from Python.
    from these callbacks, trying to execute input script commands will in the best
    case not work or in the worst case result in undefined behavior.
 
+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
 """"""""""""
 

doc/src/fix_reaxff_species.rst

@@ -200,8 +200,8 @@ The 2 values in the global vector are as follows:
 The per-atom vector stores the molecule ID for each atom as identified
 by the fix.  If an atom is not in a molecule, its ID will be 0.
 For atoms in the same molecule, the molecule ID for all of them
-will be the same and will be equal to the smallest atom ID of
+will be the same, and molecule IDs will range from 1 to the number
-any atom in the molecule.
+of molecules.
 
 No parameter of this fix can be used with the *start/stop* keywords of
 the :doc:`run <run>` command.

doc/src/fix_rheo.rst

@@ -64,7 +64,7 @@ Description
 
 Perform time integration for RHEO particles, updating positions, velocities,
 and densities. For a detailed breakdown of the integration timestep and
-numerical details, see :ref:`(Palermo) <rheo_palermo>`. For an overview
+numerical details, see :ref:`(Palermo) <fix_rheo_palermo>`. For an overview
 and list of other features available in the RHEO package, see
 :doc:`the RHEO howto <Howto_rheo>`.
 
@@ -101,7 +101,7 @@ A modified form of Fickian particle shifting can be enabled with the
 more uniform spatial distribution. By default, shifting does not consider the
 type of a particle and therefore may be inappropriate in systems consisting
 of multiple atom types representing multiple fluid phases. However, two
-optional subarguments can follow the *shift* keyword, *exclude/type* and
+optional sub-arguments can follow the *shift* keyword, *exclude/type* and
 *scale/cross/type* to adjust shifting at fluid interfaces.
 
 The *exclude/type* option lets the user specify a list of atom types which
@@ -155,7 +155,7 @@ threshold for this classification is set by the numerical value of
 By default, RHEO integrates particles' densities using a mass diffusion
 equation. Alternatively, one can update densities every timestep by performing
 a kernel summation of the masses of neighboring particles by specifying the *rho/sum*
-keyword. Following this keyword, one may include the optional *self/mass* subargument
+keyword. Following this keyword, one may include the optional *self/mass* sub-argument
 which modifies the behavior of the density summation. Typically, the density
 :math:`\rho` of a particle is calculated as the sum over neighbors
 
@@ -218,11 +218,11 @@ Default
 
 ----------
 
-.. _rheo_palermo:
+.. _fix_rheo_palermo:
 
 **(Palermo)** Palermo, Wolf, Clemmer, O'Connor, Phys. Fluids, 36, 113337 (2024).
 
-.. _rheo_yang:
+.. _fix_rheo_yang:
 
 **(Yang)** Yang, Rakhsha, Hu, Negrut, J. Comp. Physics, 458, 111079 (2022).
 

doc/src/fix_sph.rst

@@ -32,6 +32,12 @@ Hydrodynamics.
 See `this PDF guide <PDF/SPH_LAMMPS_userguide.pdf>`_ to using SPH in
 LAMMPS.
 
+.. note::
+
+   Please note that the SPH PDF guide file has not been updated for
+   many years and thus does not reflect the current *syntax* of the
+   SPH package commands. For that please refer to the LAMMPS manual.
+
 Restart, fix_modify, output, run start/stop, minimize info
 """""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 

doc/src/fix_sph_stationary.rst

@@ -32,6 +32,12 @@ space.  SPH stands for Smoothed Particle Hydrodynamics.
 See `this PDF guide <PDF/SPH_LAMMPS_userguide.pdf>`_ to using SPH in
 LAMMPS.
 
+.. note::
+
+   Please note that the SPH PDF guide file has not been updated for
+   many years and thus does not reflect the current *syntax* of the
+   SPH package commands. For that please refer to the LAMMPS manual.
+
 Restart, fix_modify, output, run start/stop, minimize info
 """""""""""""""""""""""""""""""""""""""""""""""""""""""""""