Merge pull request #3029 from akohlmey/maintenance-2021-09-29

Second round of maintenance fixes for the stable release

.github/CODEOWNERS

@@ -83,7 +83,7 @@ src/library.*             @sjplimp
 src/main.cpp              @sjplimp
 src/min_*.*               @sjplimp
 src/memory.*              @sjplimp
-src/modify.*              @sjplimp @stanmoore1
+src/modify.*              @sjplimp
 src/molecule.*            @sjplimp
 src/my_page.h             @sjplimp
 src/my_pool_chunk.h       @sjplimp

.github/workflows/codeql-analysis.yml

@@ -3,7 +3,7 @@ name: "CodeQL Code Analysis"
 
 on:
   push:
-    branches: [develop]
+    branches: [master]
 
 jobs:
   analyze:

.github/workflows/compile-msvc.yml

@@ -1,33 +0,0 @@
-# GitHub action to build LAMMPS on Windows with Visual C++
-name: "Native Windows Compilation"
-
-on:
-  push:
-    branches: [develop]
-
-jobs:
-  build:
-    name: Windows Compilation Test
-    if: ${{ github.repository == 'lammps/lammps' }}
-    runs-on: windows-latest
-
-    steps:
-    - name: Checkout repository
-      uses: actions/checkout@v2
-      with:
-        fetch-depth: 2
-
-    - name: Building LAMMPS via CMake
-      shell: bash
-      run: |
-        cmake -C cmake/presets/windows.cmake \
-              -S cmake -B build \
-              -D BUILD_SHARED_LIBS=on \
-              -D LAMMPS_EXCEPTIONS=on
-        cmake --build build --config Release
-
-    - name: Run LAMMPS executable
-      shell: bash
-      run: |
-        ./build/Release/lmp.exe -h
-        ./build/Release/lmp.exe -in bench/in.lj

.github/workflows/unittest-macos.yml

@@ -3,7 +3,7 @@ name: "Unittest for MacOS"
 
 on:
   push:
-    branches: [develop]
+    branches: [master]
 
 jobs:
   build:

.gitignore

@@ -37,8 +37,8 @@ vgcore.*
 .Trashes
 ehthumbs.db
 Thumbs.db
+.clang-format
 .lammps_history
-.vs
 
 #cmake
 /build*
@@ -49,8 +49,3 @@ Thumbs.db
 /Testing
 /cmake_install.cmake
 /lmp
-out/Debug
-out/RelWithDebInfo
-out/Release
-out/x86
-out/x64

SECURITY.md

@@ -23,10 +23,6 @@ either a user mistake or a bug in the code.  Bugs can be reported in
 the LAMMPS project
 [issue tracker on GitHub](https://github.com/lammps/lammps/issues).
 
-To mitigate issues with using homoglyphs or bidirectional reordering in
-unicode, which have been demonstrated as a vector to obfuscate and hide
-malicious changes to the source code, all LAMMPS submissions are checked
-for unicode characters and only all-ASCII source code is accepted.
 
 # Version Updates
 

cmake/CMakeLists.txt

@@ -81,40 +81,22 @@ check_for_autogen_files(${LAMMPS_SOURCE_DIR})
 include(CheckIncludeFileCXX)
 
 # set required compiler flags and compiler/CPU arch specific optimizations
-if(CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
-  if(CMAKE_SYSTEM_NAME STREQUAL "Windows")
-    if(CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
-      set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /Qrestrict")
-    endif()
-    if(CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.3 OR CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.4)
-      set(CMAKE_TUNE_DEFAULT "/QxCOMMON-AVX512")
-    else()
-      set(CMAKE_TUNE_DEFAULT "/QxHost")
-    endif()
+if((CMAKE_CXX_COMPILER_ID STREQUAL "Intel") OR (CMAKE_CXX_COMPILER_ID STREQUAL "IntelLLVM"))
+  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -restrict")
+  if(CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.3 OR CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.4)
+    set(CMAKE_TUNE_DEFAULT "-xCOMMON-AVX512")
   else()
-    set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -restrict")
-    if(CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.3 OR CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.4)
-      set(CMAKE_TUNE_DEFAULT "-xCOMMON-AVX512")
-    else()
-      set(CMAKE_TUNE_DEFAULT "-xHost")
-    endif()
+    set(CMAKE_TUNE_DEFAULT "-xHost")
   endif()
 endif()
 
-# we require C++11 without extensions. Kokkos requires at least C++14 (currently)
+# we require C++11 without extensions
 set(CMAKE_CXX_STANDARD 11)
-if(PKG_KOKKOS AND (CMAKE_CXX_STANDARD LESS 14))
-  set(CMAKE_CXX_STANDARD 14)
-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
-# and prints lots of pointless warnings about "unsafe" functions
+# ugly hack for MSVC which by default always reports an old C++ standard in the __cplusplus macro
 if(MSVC)
   add_compile_options(/Zc:__cplusplus)
-  add_compile_options(/wd4244)
-  add_compile_options(/wd4267)
-  add_compile_definitions(_CRT_SECURE_NO_WARNINGS)
 endif()
 
 # export all symbols when building a .dll file on windows
@@ -133,7 +115,10 @@ endif()
 set(LAMMPS_BINARY lmp${LAMMPS_MACHINE})
 
 option(BUILD_SHARED_LIBS "Build shared library" OFF)
-option(CMAKE_POSITION_INDEPENDENT_CODE "Create object compatible with shared libraries" ON)
+if(BUILD_SHARED_LIBS) # for all pkg libs, mpi_stubs and linalg
+  set(CMAKE_POSITION_INDEPENDENT_CODE ON)
+endif()
+
 option(BUILD_TOOLS "Build and install LAMMPS tools (msi2lmp, binary2txt, chain)" OFF)
 option(BUILD_LAMMPS_SHELL "Build and install the LAMMPS shell" OFF)
 
@@ -296,16 +281,9 @@ else()
   target_include_directories(mpi_stubs PUBLIC $<BUILD_INTERFACE:${LAMMPS_SOURCE_DIR}/STUBS>)
   if(BUILD_SHARED_LIBS)
     target_link_libraries(lammps PRIVATE mpi_stubs)
-    if(MSVC)
-      target_link_libraries(lmp PRIVATE mpi_stubs)
-      target_include_directories(lmp INTERFACE $<BUILD_INTERFACE:${LAMMPS_SOURCE_DIR}/STUBS>)
-      target_compile_definitions(lmp INTERFACE $<INSTALL_INTERFACE:LAMMPS_LIB_NO_MPI>)
-    endif()
     target_include_directories(lammps INTERFACE $<BUILD_INTERFACE:${LAMMPS_SOURCE_DIR}/STUBS>)
     target_compile_definitions(lammps INTERFACE $<INSTALL_INTERFACE:LAMMPS_LIB_NO_MPI>)
   else()
-    target_include_directories(lammps INTERFACE $<BUILD_INTERFACE:${LAMMPS_SOURCE_DIR}/STUBS>)
-    target_compile_definitions(lammps INTERFACE $<INSTALL_INTERFACE:LAMMPS_LIB_NO_MPI>)
     target_link_libraries(lammps PUBLIC mpi_stubs)
   endif()
   add_library(MPI::MPI_CXX ALIAS mpi_stubs)
@@ -339,6 +317,7 @@ pkg_depends(ML-IAP ML-SNAP)
 pkg_depends(MPIIO MPI)
 pkg_depends(ATC MANYBODY)
 pkg_depends(LATBOLTZ MPI)
+pkg_depends(PHONON KSPACE)
 pkg_depends(SCAFACOS MPI)
 pkg_depends(DIELECTRIC KSPACE)
 pkg_depends(DIELECTRIC EXTRA-PAIR)
@@ -489,12 +468,9 @@ foreach(HEADER cmath)
   endif(NOT FOUND_${HEADER})
 endforeach(HEADER)
 
-# make the standard math library overrideable and autodetected (for systems that don't have it)
-find_library(STANDARD_MATH_LIB m DOC "Standard Math library")
-mark_as_advanced(STANDARD_MATH_LIB)
-if(STANDARD_MATH_LIB)
-  target_link_libraries(lammps PRIVATE ${STANDARD_MATH_LIB})
-endif()
+set(MATH_LIBRARIES "m" CACHE STRING "math library")
+mark_as_advanced( MATH_LIBRARIES )
+target_link_libraries(lammps PRIVATE ${MATH_LIBRARIES})
 
 ######################################
 # Generate Basic Style files
@@ -608,19 +584,22 @@ endif()
 # packages which selectively include variants based on enabled styles
 # e.g. accelerator packages
 ######################################################################
-foreach(PKG_WITH_INCL CORESHELL DPD-SMOOTH PHONON QEQ OPENMP KOKKOS OPT INTEL GPU)
+foreach(PKG_WITH_INCL CORESHELL QEQ OPENMP DPD-SMOOTH KOKKOS OPT INTEL GPU)
   if(PKG_${PKG_WITH_INCL})
     include(Packages/${PKG_WITH_INCL})
   endif()
 endforeach()
 
 if(PKG_PLUGIN)
-  target_compile_definitions(lammps PRIVATE -DLMP_PLUGIN)
-endif()
-
-# link with -ldl or equivalent for plugin loading; except on Windows
-if(NOT ${CMAKE_SYSTEM_NAME} STREQUAL "Windows")
-   target_link_libraries(lammps PRIVATE ${CMAKE_DL_LIBS})
+  if(BUILD_SHARED_LIBS)
+    target_compile_definitions(lammps PRIVATE -DLMP_PLUGIN)
+  else()
+    message(WARNING "Plugin loading will not work unless BUILD_SHARED_LIBS is enabled")
+  endif()
+  # link with -ldl or equivalent for plugin loading; except on Windows
+  if(NOT ${CMAKE_SYSTEM_NAME} STREQUAL "Windows")
+    target_link_libraries(lammps PRIVATE ${CMAKE_DL_LIBS})
+  endif()
 endif()
 
 ######################################################################
@@ -629,7 +608,7 @@ endif()
 # and after everything else that is compiled locally
 ######################################################################
 if(CMAKE_SYSTEM_NAME STREQUAL "Windows")
-  target_link_libraries(lammps PRIVATE "wsock32;psapi")
+  target_link_libraries(lammps PRIVATE -lwsock32 -lpsapi)
 endif()
 
 ######################################################
@@ -807,17 +786,11 @@ if(ClangFormat_FOUND)
 endif()
 
 get_target_property(DEFINES lammps COMPILE_DEFINITIONS)
-get_property(BUILD_IS_MULTI_CONFIG GLOBAL PROPERTY GENERATOR_IS_MULTI_CONFIG)
-if(BUILD_IS_MULTI_CONFIG)
-  set(LAMMPS_BUILD_TYPE "Multi-Config")
-else()
-  set(LAMMPS_BUILD_TYPE ${CMAKE_BUILD_TYPE})
-endif()
 include(FeatureSummary)
 feature_summary(DESCRIPTION "The following tools and libraries have been found and configured:" WHAT PACKAGES_FOUND)
 message(STATUS "<<< Build configuration >>>
    Operating System: ${CMAKE_SYSTEM_NAME} ${CMAKE_LINUX_DISTRO} ${CMAKE_DISTRO_VERSION}
-   Build type:       ${LAMMPS_BUILD_TYPE}
+   Build type:       ${CMAKE_BUILD_TYPE}
    Install path:     ${CMAKE_INSTALL_PREFIX}
    Generator:        ${CMAKE_GENERATOR} using ${CMAKE_MAKE_PROGRAM}")
 ###############################################################################

cmake/CMakeSettings.json

@@ -1,111 +0,0 @@
-{
-  "configurations": [
-    {
-      "name": "x64-Debug-MSVC",
-      "generator": "Ninja",
-      "configurationType": "Debug",
-      "buildRoot": "${workspaceRoot}\\build\\${name}",
-      "installRoot": "${workspaceRoot}\\install\\${name}",
-      "cmakeCommandArgs": "-S ${workspaceRoot}\\cmake -C ${workspaceRoot}\\cmake\\presets\\windows.cmake -DENABLE_TESTING=on",
-      "buildCommandArgs": "",
-      "ctestCommandArgs": "",
-      "inheritEnvironments": [ "msvc_x64_x64" ],
-      "variables": [
-        {
-          "name": "BUILD_SHARED_LIBS",
-          "value": "True",
-          "type": "BOOL"
-        },
-        {
-          "name": "BUILD_TOOLS",
-          "value": "True",
-          "type": "BOOL"
-        },
-        {
-          "name": "LAMMPS_EXCEPTIONS",
-          "value": "True",
-          "type": "BOOL"
-        }
-      ]
-    },
-    {
-      "name": "x64-Debug-Clang",
-      "generator": "Ninja",
-      "configurationType": "Debug",
-      "buildRoot": "${workspaceRoot}\\build\\${name}",
-      "installRoot": "${workspaceRoot}\\install\\${name}",
-      "cmakeCommandArgs": "-S ${workspaceRoot}\\cmake -C ${workspaceRoot}\\cmake\\presets\\windows.cmake -DENABLE_TESTING=on",
-      "buildCommandArgs": "",
-      "ctestCommandArgs": "",
-      "inheritEnvironments": [ "clang_cl_x64" ],
-      "variables": [
-        {
-          "name": "BUILD_TOOLS",
-          "value": "True",
-          "type": "BOOL"
-        },
-        {
-          "name": "LAMMPS_EXCEPTIONS",
-          "value": "True",
-          "type": "BOOL"
-        }
-      ]
-    },
-    {
-      "name": "x64-Debug-OneAPI",
-      "generator": "Ninja",
-      "configurationType": "Debug",
-      "buildRoot": "${workspaceRoot}\\build\\${name}",
-      "installRoot": "${workspaceRoot}\\install\\${name}",
-      "cmakeCommandArgs": "-S ${workspaceRoot}\\cmake -C ${workspaceRoot}\\cmake\\presets\\windows.cmake -DENABLE_TESTING=on -DCMAKE_CXX_COMPILER=icx -DCMAKE_C_COMPILER=icx -DBUILD_MPI=off",
-      "buildCommandArgs": "",
-      "ctestCommandArgs": "",
-      "inheritEnvironments": [ "msvc_x64_x64" ],
-      "variables": [
-        {
-          "name": "BUILD_SHARED_LIBS",
-          "value": "True",
-          "type": "BOOL"
-        },
-        {
-          "name": "BUILD_TOOLS",
-          "value": "True",
-          "type": "BOOL"
-        },
-        {
-          "name": "LAMMPS_EXCEPTIONS",
-          "value": "True",
-          "type": "BOOL"
-        }
-      ]
-    },
-    {
-      "name": "x64-Debug-Intel",
-      "generator": "Ninja",
-      "configurationType": "Debug",
-      "buildRoot": "${workspaceRoot}\\build\\${name}",
-      "installRoot": "${workspaceRoot}\\install\\${name}",
-      "cmakeCommandArgs": "-S ${workspaceRoot}\\cmake -C ${workspaceRoot}\\cmake\\presets\\windows.cmake -DENABLE_TESTING=off -DCMAKE_CXX_COMPILER=icl -DCMAKE_C_COMPILER=icl -DCMAKE_Fortran_COMPILER=ifort -DBUILD_MPI=off",
-      "buildCommandArgs": "",
-      "ctestCommandArgs": "",
-      "inheritEnvironments": [ "msvc_x64_x64" ],
-      "variables": [
-        {
-          "name": "BUILD_SHARED_LIBS",
-          "value": "True",
-          "type": "BOOL"
-        },
-        {
-          "name": "BUILD_TOOLS",
-          "value": "True",
-          "type": "BOOL"
-        },
-        {
-          "name": "LAMMPS_EXCEPTIONS",
-          "value": "True",
-          "type": "BOOL"
-        }
-      ]
-    }
-  ]
-}

cmake/Modules/ExternalCMakeProject.cmake

@@ -1,33 +0,0 @@
-# Build a CMake based external library as subdirectory.
-# The sources will be unpacked to ${CMAKE_BINARY_DIR}/_deps/${target}-src
-# The binaries will be built in ${CMAKE_BINARY_DIR}/_deps/${target}-build
-#
-function(ExternalCMakeProject target url hash basedir cmakedir cmakefile)
-  # change settings locally
-  set(BUILD_SHARED_LIBS OFF)
-  set(CMAKE_POSITION_INDEPENDENT_CODE ON)
-
-  get_filename_component(archive ${url} NAME)
-  file(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/_deps/src)
-  message(STATUS "Downloading ${url}")
-  file(DOWNLOAD ${url} ${CMAKE_BINARY_DIR}/_deps/${archive} EXPECTED_HASH MD5=${hash} SHOW_PROGRESS)
-  message(STATUS "Unpacking and configuring ${archive}")
-  execute_process(COMMAND ${CMAKE_COMMAND} -E tar xzf ${CMAKE_BINARY_DIR}/_deps/${archive}
-    WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/_deps/src)
-  file(GLOB TARGET_SOURCE "${CMAKE_BINARY_DIR}/_deps/src/${basedir}*")
-  list(LENGTH TARGET_SOURCE _num)
-  if(_num GREATER 1)
-    message(FATAL_ERROR "Inconsistent ${target} library sources. "
-      "Please delete ${CMAKE_BINARY_DIR}/_deps/src and re-run cmake")
-  endif()
-  file(REMOVE_RECURSE ${CMAKE_BINARY_DIR}/_deps/${target}-src)
-  file(RENAME ${TARGET_SOURCE} ${CMAKE_BINARY_DIR}/_deps/${target}-src)
-  if(NOT (cmakefile STREQUAL ""))
-    file(COPY ${cmakefile} DESTINATION ${CMAKE_BINARY_DIR}/_deps/${target}-src/${cmakedir}/)
-    get_filename_component(_cmakefile ${cmakefile} NAME)
-    file(RENAME "${CMAKE_BINARY_DIR}/_deps/${target}-src/${cmakedir}/${_cmakefile}"
-      "${CMAKE_BINARY_DIR}/_deps/${target}-src/${cmakedir}/CMakeLists.txt")
-  endif()
-  add_subdirectory("${CMAKE_BINARY_DIR}/_deps/${target}-src/${cmakedir}"
-    "${CMAKE_BINARY_DIR}/_deps/${target}-build")
-endfunction(ExternalCMakeProject)

cmake/Modules/GTest.cmake

@@ -0,0 +1,81 @@
+message(STATUS "Downloading and building Google Test library")
+
+if(CMAKE_BUILD_TYPE STREQUAL "Debug")
+  set(GTEST_LIB_POSTFIX d)
+else()
+  set(GTEST_LIB_POSTFIX)
+endif()
+
+include(ExternalProject)
+set(GTEST_URL "https://github.com/google/googletest/archive/release-1.10.0.tar.gz" CACHE STRING "URL for GTest tarball")
+set(GTEST_MD5 "ecd1fa65e7de707cd5c00bdac56022cd" CACHE STRING "MD5 checksum of GTest tarball")
+mark_as_advanced(GTEST_URL)
+mark_as_advanced(GTEST_MD5)
+ExternalProject_Add(googletest
+                    URL             ${GTEST_URL}
+                    URL_MD5         ${GTEST_MD5}
+                    SOURCE_DIR      "${CMAKE_BINARY_DIR}/gtest-src"
+                    BINARY_DIR      "${CMAKE_BINARY_DIR}/gtest-build"
+                    CMAKE_ARGS      ${CMAKE_REQUEST_PIC} ${CMAKE_EXTRA_GTEST_OPTS}
+                                    -DCMAKE_CXX_COMPILER=${CMAKE_CXX_COMPILER}
+                                    -DCMAKE_INSTALL_PREFIX=<INSTALL_DIR>
+                                    -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
+                                    -DCMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM}
+                                    -DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE}
+                    BUILD_BYPRODUCTS <BINARY_DIR>/lib/libgtest${GTEST_LIB_POSTFIX}${CMAKE_STATIC_LIBRARY_SUFFIX}
+                                     <BINARY_DIR>/lib/libgmock${GTEST_LIB_POSTFIX}${CMAKE_STATIC_LIBRARY_SUFFIX}
+                                     <BINARY_DIR>/lib/libgtest_main${GTEST_LIB_POSTFIX}${CMAKE_STATIC_LIBRARY_SUFFIX}
+                                     <BINARY_DIR>/lib/libgmock_main${GTEST_LIB_POSTFIX}${CMAKE_STATIC_LIBRARY_SUFFIX}
+                    LOG_DOWNLOAD ON
+                    LOG_CONFIGURE ON
+                    LOG_BUILD ON
+                    INSTALL_COMMAND ""
+                    TEST_COMMAND    "")
+
+ExternalProject_Get_Property(googletest SOURCE_DIR)
+set(GTEST_INCLUDE_DIR ${SOURCE_DIR}/googletest/include)
+set(GMOCK_INCLUDE_DIR ${SOURCE_DIR}/googlemock/include)
+
+# workaround for CMake 3.10 on ubuntu 18.04
+file(MAKE_DIRECTORY ${GTEST_INCLUDE_DIR})
+file(MAKE_DIRECTORY ${GMOCK_INCLUDE_DIR})
+
+ExternalProject_Get_Property(googletest BINARY_DIR)
+set(GTEST_LIBRARY_PATH ${BINARY_DIR}/lib/libgtest${GTEST_LIB_POSTFIX}${CMAKE_STATIC_LIBRARY_SUFFIX})
+set(GMOCK_LIBRARY_PATH ${BINARY_DIR}/lib/libgmock${GTEST_LIB_POSTFIX}${CMAKE_STATIC_LIBRARY_SUFFIX})
+set(GTEST_MAIN_LIBRARY_PATH ${BINARY_DIR}/lib/libgtest_main${GTEST_LIB_POSTFIX}${CMAKE_STATIC_LIBRARY_SUFFIX})
+set(GMOCK_MAIN_LIBRARY_PATH ${BINARY_DIR}/lib/libgmock_main${GTEST_LIB_POSTFIX}${CMAKE_STATIC_LIBRARY_SUFFIX})
+
+# Prevent GoogleTest from overriding our compiler/linker options
+# when building with Visual Studio
+set(gtest_force_shared_crt ON CACHE BOOL "" FORCE)
+
+find_package(Threads QUIET)
+
+add_library(GTest::GTest UNKNOWN IMPORTED)
+set_target_properties(GTest::GTest PROPERTIES
+        IMPORTED_LOCATION ${GTEST_LIBRARY_PATH}
+        INTERFACE_INCLUDE_DIRECTORIES ${GTEST_INCLUDE_DIR}
+        INTERFACE_LINK_LIBRARIES "${CMAKE_THREAD_LIBS_INIT}")
+add_dependencies(GTest::GTest googletest)
+
+add_library(GTest::GMock UNKNOWN IMPORTED)
+set_target_properties(GTest::GMock PROPERTIES
+        IMPORTED_LOCATION ${GMOCK_LIBRARY_PATH}
+        INTERFACE_INCLUDE_DIRECTORIES ${GMOCK_INCLUDE_DIR}
+        INTERFACE_LINK_LIBRARIES "${CMAKE_THREAD_LIBS_INIT}")
+add_dependencies(GTest::GMock googletest)
+
+add_library(GTest::GTestMain UNKNOWN IMPORTED)
+set_target_properties(GTest::GTestMain PROPERTIES
+        IMPORTED_LOCATION ${GTEST_MAIN_LIBRARY_PATH}
+        INTERFACE_INCLUDE_DIRECTORIES ${GTEST_INCLUDE_DIR}
+        INTERFACE_LINK_LIBRARIES "${CMAKE_THREAD_LIBS_INIT}")
+add_dependencies(GTest::GTestMain googletest)
+
+add_library(GTest::GMockMain UNKNOWN IMPORTED)
+set_target_properties(GTest::GMockMain PROPERTIES
+        IMPORTED_LOCATION ${GMOCK_MAIN_LIBRARY_PATH}
+        INTERFACE_INCLUDE_DIRECTORIES ${GMOCK_INCLUDE_DIR}
+        INTERFACE_LINK_LIBRARIES "${CMAKE_THREAD_LIBS_INIT}")
+add_dependencies(GTest::GMockMain googletest)

cmake/Modules/LAMMPSUtils.cmake

@@ -85,7 +85,7 @@ endfunction(GenerateBinaryHeader)
 
 # fetch missing potential files
 function(FetchPotentials pkgfolder potfolder)
-  if(EXISTS "${pkgfolder}/potentials.txt")
+  if (EXISTS "${pkgfolder}/potentials.txt")
     file(STRINGS "${pkgfolder}/potentials.txt" linelist REGEX "^[^#].")
     foreach(line ${linelist})
       string(FIND ${line} " " blank)

cmake/Modules/Packages/KOKKOS.cmake

@@ -1,7 +1,7 @@
 ########################################################################
 # As of version 3.3.0 Kokkos requires C++14
 if(CMAKE_CXX_STANDARD LESS 14)
-  message(FATAL_ERROR "The KOKKOS package requires the C++ standard to be set to at least C++14")
+  set(CMAKE_CXX_STANDARD 14)
 endif()
 ########################################################################
 # consistency checks and Kokkos options/settings required by LAMMPS
@@ -39,8 +39,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/3.5.00.tar.gz" CACHE STRING "URL for KOKKOS tarball")
-  set(KOKKOS_MD5 "079323d973ae0e1c38c0a54a150c674e" CACHE STRING "MD5 checksum of KOKKOS tarball")
+  set(KOKKOS_URL "https://github.com/kokkos/kokkos/archive/3.4.01.tar.gz" CACHE STRING "URL for KOKKOS tarball")
+  set(KOKKOS_MD5 "4c84698917c93a18985b311bb6caf84f" CACHE STRING "MD5 checksum of KOKKOS tarball")
   mark_as_advanced(KOKKOS_URL)
   mark_as_advanced(KOKKOS_MD5)
   ExternalProject_Add(kokkos_build
@@ -60,7 +60,7 @@ if(DOWNLOAD_KOKKOS)
   target_link_libraries(lmp PRIVATE LAMMPS::KOKKOS)
   add_dependencies(LAMMPS::KOKKOS kokkos_build)
 elseif(EXTERNAL_KOKKOS)
-  find_package(Kokkos 3.5.00 REQUIRED CONFIG)
+  find_package(Kokkos 3.4.01 REQUIRED CONFIG)
   target_link_libraries(lammps PRIVATE Kokkos::kokkos)
   target_link_libraries(lmp PRIVATE Kokkos::kokkos)
 else()

cmake/Modules/Packages/MACHDYN.cmake

@@ -8,7 +8,7 @@ option(DOWNLOAD_EIGEN3 "Download Eigen3 instead of using an already installed on
 if(DOWNLOAD_EIGEN3)
   message(STATUS "Eigen3 download requested - we will build our own")
 
-  set(EIGEN3_URL "${LAMMPS_THIRDPARTY_URL}/eigen-3.4.0.tar.gz" CACHE STRING "URL for Eigen3 tarball")
+  set(EIGEN3_URL "https://download.lammps.org/thirdparty/eigen-3.4.0.tar.gz" CACHE STRING "URL for Eigen3 tarball")
   set(EIGEN3_MD5 "4c527a9171d71a72a9d4186e65bea559" CACHE STRING "MD5 checksum of Eigen3 tarball")
   mark_as_advanced(EIGEN3_URL)
   mark_as_advanced(EIGEN3_MD5)

cmake/Modules/Packages/ML-PACE.cmake

@@ -1,11 +1,11 @@
-set(PACELIB_URL "https://github.com/ICAMS/lammps-user-pace/archive/refs/tags/v.2021.10.25.tar.gz" CACHE STRING "URL for PACE evaluator library sources")
 
-set(PACELIB_MD5 "a2ac3315c41a1a4a5c912bcb1bc9c5cc" CACHE STRING "MD5 checksum of PACE evaluator library tarball")
+set(PACELIB_URL "https://github.com/ICAMS/lammps-user-pace/archive/refs/tags/v.2021.4.9.tar.gz" CACHE STRING "URL for PACE evaluator library sources")
+set(PACELIB_MD5 "4db54962fbd6adcf8c18d46e1798ceb5" CACHE STRING "MD5 checksum of PACE evaluator library tarball")
 mark_as_advanced(PACELIB_URL)
 mark_as_advanced(PACELIB_MD5)
 
 # download library sources to build folder
-file(DOWNLOAD ${PACELIB_URL} ${CMAKE_BINARY_DIR}/libpace.tar.gz EXPECTED_HASH MD5=${PACELIB_MD5}) #SHOW_PROGRESS
+file(DOWNLOAD ${PACELIB_URL} ${CMAKE_BINARY_DIR}/libpace.tar.gz SHOW_PROGRESS EXPECTED_HASH MD5=${PACELIB_MD5})
 
 # uncompress downloaded sources
 execute_process(
@@ -14,19 +14,12 @@ execute_process(
   WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
 )
 
-file(GLOB lib-pace ${CMAKE_BINARY_DIR}/lammps-user-pace-*)
-add_subdirectory(${lib-pace}/yaml-cpp build-yaml-cpp)
-set(YAML_CPP_INCLUDE_DIR ${lib-pace}/yaml-cpp/include)
-
-file(GLOB PACE_EVALUATOR_INCLUDE_DIR ${lib-pace}/ML-PACE)
-file(GLOB PACE_EVALUATOR_SOURCES ${lib-pace}/ML-PACE/*.cpp)
+file(GLOB PACE_EVALUATOR_INCLUDE_DIR ${CMAKE_BINARY_DIR}/lammps-user-pace-*/USER-PACE)
+file(GLOB PACE_EVALUATOR_SOURCES ${CMAKE_BINARY_DIR}/lammps-user-pace-*/USER-PACE/*.cpp)
 list(FILTER PACE_EVALUATOR_SOURCES EXCLUDE REGEX pair_pace.cpp)
 
 add_library(pace STATIC ${PACE_EVALUATOR_SOURCES})
 set_target_properties(pace PROPERTIES CXX_EXTENSIONS ON OUTPUT_NAME lammps_pace${LAMMPS_MACHINE})
-target_include_directories(pace PUBLIC ${PACE_EVALUATOR_INCLUDE_DIR} ${YAML_CPP_INCLUDE_DIR})
-
-
-target_link_libraries(pace PRIVATE yaml-cpp-pace)
-
+target_include_directories(pace PUBLIC ${PACE_EVALUATOR_INCLUDE_DIR})
 target_link_libraries(lammps PRIVATE pace)
+

cmake/Modules/Packages/ML-QUIP.cmake

@@ -32,8 +32,7 @@ if(DOWNLOAD_QUIP)
   foreach(flag ${LAPACK_LIBRARIES})
     set(temp "${temp} ${flag}")
   endforeach()
-  # Fix cmake crashing when MATH_LINKOPTS not set, required for e.g. recent Cray Programming Environment
-  set(temp "${temp} -L/_DUMMY_PATH_\n")
+  set(temp "${temp}\n")
   set(temp "${temp}PYTHON=python\nPIP=pip\nEXTRA_LINKOPTS=\n")
   set(temp "${temp}HAVE_CP2K=0\nHAVE_VASP=0\nHAVE_TB=0\nHAVE_PRECON=1\nHAVE_LOTF=0\nHAVE_ONIOM=0\n")
   set(temp "${temp}HAVE_LOCAL_E_MIX=0\nHAVE_QC=0\nHAVE_GAP=1\nHAVE_DESCRIPTORS_NONCOMMERCIAL=1\n")

cmake/Modules/Packages/MSCG.cmake

@@ -12,12 +12,41 @@ if(DOWNLOAD_MSCG)
   mark_as_advanced(MSCG_URL)
   mark_as_advanced(MSCG_MD5)
 
-  include(ExternalCMakeProject)
-  ExternalCMakeProject(mscg ${MSCG_URL} ${MSCG_MD5} MSCG-release src/CMake "")
+  # CMake cannot pass BLAS or LAPACK library variable to external project if they are a list
+  list(LENGTH BLAS_LIBRARIES} NUM_BLAS)
+  list(LENGTH LAPACK_LIBRARIES NUM_LAPACK)
+  if((NUM_BLAS GREATER 1) OR (NUM_LAPACK GREATER 1))
+    message(FATAL_ERROR "Cannot compile downloaded MSCG library due to a technical limitation")
+  endif()
 
-  # set include and link library
-  target_include_directories(lammps PRIVATE "${CMAKE_BINARY_DIR}/_deps/mscg-src/src")
-  target_link_libraries(lammps PRIVATE mscg)
+  include(ExternalProject)
+  ExternalProject_Add(mscg_build
+    URL     ${MSCG_URL}
+    URL_MD5 ${MSCG_MD5}
+    SOURCE_SUBDIR src/CMake
+    CMAKE_ARGS ${CMAKE_REQUEST_PIC} ${EXTRA_MSCG_OPTS}
+               -DCMAKE_C_COMPILER=${CMAKE_C_COMPILER}
+               -DCMAKE_CXX_COMPILER=${CMAKE_CXX_COMPILER}
+               -DCMAKE_Fortran_COMPILER=${CMAKE_Fortran_COMPILER}
+               -DBLAS_LIBRARIES=${BLAS_LIBRARIES} -DLAPACK_LIBRARIES=${LAPACK_LIBRARIES}
+               -DCMAKE_INSTALL_PREFIX=<INSTALL_DIR>
+               -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
+               -DCMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM}
+               -DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE}
+    BUILD_COMMAND ${CMAKE_COMMAND} --build . --target mscg
+    INSTALL_COMMAND ""
+    BUILD_BYPRODUCTS <BINARY_DIR>/libmscg.a
+    )
+  ExternalProject_get_property(mscg_build BINARY_DIR)
+  ExternalProject_get_property(mscg_build SOURCE_DIR)
+  file(MAKE_DIRECTORY ${SOURCE_DIR}/src)
+  add_library(LAMMPS::MSCG UNKNOWN IMPORTED)
+  set_target_properties(LAMMPS::MSCG PROPERTIES
+    IMPORTED_LOCATION "${BINARY_DIR}/libmscg.a"
+    INTERFACE_INCLUDE_DIRECTORIES "${SOURCE_DIR}/src"
+    INTERFACE_LINK_LIBRARIES "${LAPACK_LIBRARIES}")
+  target_link_libraries(lammps PRIVATE LAMMPS::MSCG)
+  add_dependencies(LAMMPS::MSCG mscg_build)
 else()
   find_package(MSCG)
   if(NOT MSCG_FOUND)

cmake/Modules/Packages/PHONON.cmake

@@ -1,9 +0,0 @@
-# fix phonon may only be installed if also the FFT wrappers from KSPACE are installed
-if(NOT PKG_KSPACE)
-  get_property(LAMMPS_FIX_HEADERS GLOBAL PROPERTY FIX)
-  list(REMOVE_ITEM LAMMPS_FIX_HEADERS ${LAMMPS_SOURCE_DIR}/PHONON/fix_phonon.h)
-  set_property(GLOBAL PROPERTY FIX "${LAMMPS_FIX_HEADERS}")
-  get_target_property(LAMMPS_SOURCES lammps SOURCES)
-  list(REMOVE_ITEM LAMMPS_SOURCES ${LAMMPS_SOURCE_DIR}/PHONON/fix_phonon.cpp)
-  set_property(TARGET lammps PROPERTY SOURCES "${LAMMPS_SOURCES}")
-endif()

cmake/Modules/Packages/PLUMED.cmake

@@ -54,8 +54,8 @@ if(DOWNLOAD_PLUMED)
     set(PLUMED_BUILD_BYPRODUCTS "<INSTALL_DIR>/lib/libplumedWrapper.a")
   endif()
 
-  set(PLUMED_URL "https://github.com/plumed/plumed2/releases/download/v2.7.3/plumed-src-2.7.3.tgz" CACHE STRING "URL for PLUMED tarball")
-  set(PLUMED_MD5 "f00cc82edfefe6bb3df934911dbe32fb" CACHE STRING "MD5 checksum of PLUMED tarball")
+  set(PLUMED_URL "https://github.com/plumed/plumed2/releases/download/v2.7.2/plumed-src-2.7.2.tgz" CACHE STRING "URL for PLUMED tarball")
+  set(PLUMED_MD5 "cfa0b4dd90a81c25d3302e8d97bfeaea" CACHE STRING "MD5 checksum of PLUMED tarball")
 
   mark_as_advanced(PLUMED_URL)
   mark_as_advanced(PLUMED_MD5)

cmake/Modules/Tools.cmake

@@ -25,9 +25,7 @@ if(BUILD_TOOLS)
   get_filename_component(MSI2LMP_SOURCE_DIR ${LAMMPS_TOOLS_DIR}/msi2lmp/src ABSOLUTE)
   file(GLOB MSI2LMP_SOURCES ${MSI2LMP_SOURCE_DIR}/[^.]*.c)
   add_executable(msi2lmp ${MSI2LMP_SOURCES})
-  if(STANDARD_MATH_LIB)
-    target_link_libraries(msi2lmp PRIVATE ${STANDARD_MATH_LIB})
-  endif()
+  target_link_libraries(msi2lmp PRIVATE ${MATH_LIBRARIES})
   install(TARGETS msi2lmp DESTINATION ${CMAKE_INSTALL_BINDIR})
   install(FILES ${LAMMPS_DOC_DIR}/msi2lmp.1 DESTINATION ${CMAKE_INSTALL_MANDIR}/man1)
 endif()

cmake/Modules/YAML.cmake

@@ -0,0 +1,47 @@
+message(STATUS "Downloading and building YAML library")
+
+include(ExternalProject)
+set(YAML_URL "https://pyyaml.org/download/libyaml/yaml-0.2.5.tar.gz" CACHE STRING "URL for libyaml tarball")
+set(YAML_MD5 "bb15429d8fb787e7d3f1c83ae129a999" CACHE STRING "MD5 checksum of libyaml tarball")
+mark_as_advanced(YAML_URL)
+mark_as_advanced(YAML_MD5)
+
+# support cross-compilation to windows
+if(CMAKE_CROSSCOMPILING AND (CMAKE_SYSTEM_NAME STREQUAL "Windows"))
+  if(CMAKE_SYSTEM_PROCESSOR STREQUAL "x86")
+    set(YAML_CROSS_HOST --host=i686-mingw64)
+  elseif(CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64")
+    set(YAML_CROSS_HOST --host=x86_64-mingw64)
+  else()
+    message(FATAL_ERROR "Unsupported cross-compilation "
+      " for ${CMAKE_SYSTEM_NAME}/${CMAKE_SYSTEM_PROCESSOR}"
+      " on ${CMAKE_HOST_SYSTEM}/${CMAKE_HOST_SYSTEM_PROCESSOR}")
+  endif()
+endif()
+
+ExternalProject_Add(libyaml
+                    URL               ${YAML_URL}
+                    URL_MD5           ${YAML_MD5}
+                    SOURCE_DIR        "${CMAKE_BINARY_DIR}/yaml-src"
+                    BINARY_DIR        "${CMAKE_BINARY_DIR}/yaml-build"
+                    CONFIGURE_COMMAND <SOURCE_DIR>/configure ${CONFIGURE_REQUEST_PIC}
+                                      CXX=${CMAKE_CXX_COMPILER} CC=${CMAKE_C_COMPILER}
+                                      --prefix=<INSTALL_DIR> --disable-shared ${YAML_CROSS_HOST}
+                    BUILD_BYPRODUCTS  <INSTALL_DIR>/lib/libyaml${CMAKE_STATIC_LIBRARY_SUFFIX}
+                    TEST_COMMAND      "")
+
+ExternalProject_Get_Property(libyaml INSTALL_DIR)
+set(YAML_INCLUDE_DIR ${INSTALL_DIR}/include)
+set(YAML_LIBRARY_DIR ${INSTALL_DIR}/lib)
+
+# workaround for CMake 3.10 on ubuntu 18.04
+file(MAKE_DIRECTORY ${YAML_INCLUDE_DIR})
+file(MAKE_DIRECTORY ${YAML_LIBRARY_DIR})
+
+set(YAML_LIBRARY_PATH ${INSTALL_DIR}/lib/libyaml${CMAKE_STATIC_LIBRARY_SUFFIX})
+
+add_library(Yaml::Yaml UNKNOWN IMPORTED)
+set_target_properties(Yaml::Yaml PROPERTIES
+        IMPORTED_LOCATION ${YAML_LIBRARY_PATH}
+        INTERFACE_INCLUDE_DIRECTORIES ${YAML_INCLUDE_DIR})
+add_dependencies(Yaml::Yaml libyaml)

cmake/presets/most.cmake

@@ -48,6 +48,7 @@ set(ALL_PACKAGES
   PHONON
   PLUGIN
   POEMS
+  PYTHON
   QEQ
   REACTION
   REAXFF

cmake/presets/windows.cmake

@@ -1,64 +0,0 @@
-set(WIN_PACKAGES
-  ASPHERE
-  BOCS
-  BODY
-  BROWNIAN
-  CG-DNA
-  CG-SDK
-  CLASS2
-  COLLOID
-  COLVARS
-  CORESHELL
-  DIELECTRIC
-  DIFFRACTION
-  DIPOLE
-  DPD-BASIC
-  DPD-MESO
-  DPD-REACT
-  DPD-SMOOTH
-  DRUDE
-  EFF
-  EXTRA-COMPUTE
-  EXTRA-DUMP
-  EXTRA-FIX
-  EXTRA-MOLECULE
-  EXTRA-PAIR
-  FEP
-  GRANULAR
-  INTERLAYER
-  KSPACE
-  MANIFOLD
-  MANYBODY
-  MC
-  MEAM
-  MISC
-  ML-IAP
-  ML-SNAP
-  MOFFF
-  MOLECULE
-  MOLFILE
-  OPENMP
-  ORIENT
-  PERI
-  PHONON
-  POEMS
-  PTM
-  QEQ
-  QTB
-  REACTION
-  REAXFF
-  REPLICA
-  RIGID
-  SHOCK
-  SMTBQ
-  SPH
-  SPIN
-  SRD
-  TALLY
-  UEF
-  YAFF)
-
-foreach(PKG ${WIN_PACKAGES})
-  set(PKG_${PKG} ON CACHE BOOL "" FORCE)
-endforeach()
-

doc/doxygen/Doxyfile.in

@@ -435,8 +435,6 @@ INPUT                  = @LAMMPS_SOURCE_DIR@/utils.cpp                 \
                          @LAMMPS_SOURCE_DIR@/my_pool_chunk.cpp         \
                          @LAMMPS_SOURCE_DIR@/my_pool_chunk.h           \
                          @LAMMPS_SOURCE_DIR@/math_eigen.h              \
-                         @LAMMPS_SOURCE_DIR@/platform.h                \
-                         @LAMMPS_SOURCE_DIR@/platform.cpp              \
 
 # The EXCLUDE_SYMLINKS tag can be used to select whether or not files or
 # directories that are symbolic links (a Unix file system feature) are excluded

doc/lammps.1

@@ -1,4 +1,4 @@
-.TH LAMMPS "1" "7 January 2022" "2022-1-7"
+.TH LAMMPS "29 September 2021" "2021-09-29"
 .SH NAME
 .B LAMMPS
 \- Molecular Dynamics Simulator.

doc/msi2lmp.1

@@ -1,4 +1,4 @@
-.TH MSI2LMP "1" "v3.9.9" "2018-11-05"
+.TH MSI2LMP "v3.9.9" "2018-11-05"
 .SH NAME
 .B MSI2LMP
 \- Converter for Materials Studio files to LAMMPS

doc/src/Bibliography.rst

@@ -1123,12 +1123,9 @@ Bibliography
 **(Sun)**
    Sun, J. Phys. Chem. B, 102, 7338-7364 (1998).
 
-**(Surblys2019)**
+**(Surblys)**
    Surblys, Matsubara, Kikugawa, Ohara, Phys Rev E, 99, 051301(R) (2019).
 
-**(Surblys2021)**
-   Surblys, Matsubara, Kikugawa, Ohara, J Appl Phys 130, 215104 (2021).
-
 **(Sutmann)**
    Sutmann, Arnold, Fahrenberger, et. al., Physical review / E 88(6), 063308 (2013)
 

doc/src/Build_cmake.rst

@@ -150,42 +150,6 @@ for IDEs like Eclipse, CodeBlocks, or Kate can be selected using the *-G*
 command line flag.  A list of available generator settings for your
 specific CMake version is given when running ``cmake --help``.
 
-.. _cmake_multiconfig:
-
-Multi-configuration build systems
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Throughout this manual it is mostly assumed that LAMMPS is being built
-on a Unix-like operating system with "make" as the underlying "builder",
-since this is the most common case.  In this case the build "configuration"
-is chose using ``-D CMAKE_BUILD_TYPE=<configuration>`` with ``<configuration>``
-being one of "Release", "Debug", "RelWithDebInfo", or "MinSizeRel".
-Some build tools, however, can also use or even require to have a so-called
-multi-configuration build system setup.  For those the built type (or
-configuration) is chosen at compile time using the same build files. E.g.
-with:
-
-.. code-block:: bash
-
-   cmake --build build-multi --config Release
-
-In that case the resulting binaries are not in the build folder directly
-but in sub-directories corresponding to the build type (i.e. Release in
-the example from above).  Similarly, for running unit tests the
-configuration is selected with the *-C* flag:
-
-.. code-block:: bash
-
-   ctest -C Debug
-
-The CMake scripts in LAMMPS have basic support for being compiled using a
-multi-config build system, but not all of it has been ported.  This is in
-particular applicable to compiling packages that require additional libraries
-that would be downloaded and compiled by CMake.  The "windows" preset file
-tries to keep track of which packages can be compiled natively with the
-MSVC compilers out-of-the box.  Not all of those external libraries are
-portable to Windows either.
-
 
 Installing CMake
 ^^^^^^^^^^^^^^^^

doc/src/Build_development.rst

@@ -185,10 +185,6 @@ The ``ctest`` command has many options, the most important ones are:
      - run subset of tests matching the regular expression <regex>
    * - -E <regex>
      - exclude subset of tests matching the regular expression <regex>
-   * - -L <regex>
-     - run subset of tests with a label matching the regular expression <regex>
-   * - -LE <regex>
-     - exclude subset of tests with a label matching the regular expression <regex>
    * - -N
      - dry-run: display list of tests without running them
    * - -T memcheck
@@ -303,12 +299,6 @@ will destroy the original file, if the generation run does not complete,
 so using *-g* is recommended unless the YAML file is fully tested
 and working.
 
-Some of the force style tests are rather slow to run and some are very
-sensitive to small differences like CPU architecture, compiler
-toolchain, compiler optimization. Those tests are flagged with a "slow"
-and/or "unstable" label, and thus those tests can be selectively
-excluded with the ``-LE`` flag or selected with the ``-L`` flag.
-
 .. admonition:: Recommendations and notes for YAML files
    :class: note
 

doc/src/Build_extras.rst

@@ -341,18 +341,6 @@ minutes to hours) to build.  Of course you only need to do that once.)
          $ make lib-kim args="-p /usr/local" # use an existing KIM API installation at the provided location
          $ make lib-kim args="-p /usr/local -a EAM_Dynamo_Ackland_W__MO_141627196590_002" # ditto but add one model or driver
 
-      When using the "-b " option, the KIM library is built using its native
-      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
-      ``cmake3`` executable and tell it to use the gnu version 11 compilers
-      to build KIM, one could use the following command line.
-
-      .. code-block:: bash
-
-         $ CMAKE=cmake3 CXX=g++-11 CC=gcc-11 FC=gfortran-11 make lib-kim args="-b "  # (re-)install KIM API lib using cmake3 and gnu v11 compilers with only example models
-
       Settings for debugging OpenKIM web queries discussed below need to
       be applied by adding them to the ``LMP_INC`` variable through
       editing the ``Makefile.machine`` you are using.  For example:
@@ -572,26 +560,11 @@ They must be specified in uppercase.
    *  - VEGA908
       - GPU
       - AMD GPU MI100 GFX908
-   *  - VEGA90A
+   *  - INTEL_GEN
       - GPU
-      - AMD GPU
-   *  - INTEL_DG1
-      - GPU
-      - Intel Iris XeMAX GPU
-   *  - INTEL_GEN9
-      - GPU
-      - Intel GPU Gen9
-   *  - INTEL_GEN11
-      - GPU
-      - Intel GPU Gen11
-   *  - INTEL_GEN12LP
-      - GPU
-      - Intel GPU Gen12LP
-   *  - INTEL_XEHP
-      - GPU
-      - Intel GPUs Xe-HP
+      - Intel GPUs Gen9+
 
-This list was last updated for version 3.5.0 of the Kokkos library.
+This list was last updated for version 3.4.1 of the Kokkos library.
 
 .. tabs::
 

doc/src/Build_settings.rst

@@ -321,7 +321,9 @@ following settings:
 
       .. code-block:: make
 
-         LMP_INC = -DLAMMPS_JPEG -DLAMMPS_PNG -DLAMMPS_FFMPEG  <other LMP_INC settings>
+         LMP_INC = -DLAMMPS_JPEG
+         LMP_INC = -DLAMMPS_PNG
+         LMP_INC = -DLAMMPS_FFMPEG
 
          JPG_INC = -I/usr/local/include   # path to jpeglib.h, png.h, zlib.h header files if make cannot find them
          JPG_PATH = -L/usr/lib            # paths to libjpeg.a, libpng.a, libz.a (.so) files if make cannot find them
@@ -352,10 +354,8 @@ Read or write compressed files
 -----------------------------------------
 
 If this option is enabled, large files can be read or written with
-compression by ``gzip`` or similar tools by several LAMMPS commands,
-including :doc:`read_data <read_data>`, :doc:`rerun <rerun>`, and
-:doc:`dump <dump>`.  Currently supported compression tools are:
-``gzip``, ``bzip2``, ``zstd``, and ``lzma``.
+gzip compression by several LAMMPS commands, including
+:doc:`read_data <read_data>`, :doc:`rerun <rerun>`, and :doc:`dump <dump>`.
 
 .. tabs::
 
@@ -364,23 +364,23 @@ including :doc:`read_data <read_data>`, :doc:`rerun <rerun>`, and
       .. code-block:: bash
 
          -D WITH_GZIP=value       # yes or no
-                                  # default is yes if CMake can find the gzip program, else no
+                                  # default is yes if CMake can find gzip, else no
+         -D GZIP_EXECUTABLE=path  # path to gzip executable if CMake cannot find it
 
    .. tab:: Traditional make
 
       .. code-block:: make
 
-         LMP_INC = -DLAMMPS_GZIP   <other LMP_INC settings>
+         LMP_INC = -DLAMMPS_GZIP
 
-This option requires that your operating system fully supports the
-"popen()" function in the standard runtime library and that a ``gzip``
-or other executable can be found by LAMMPS in the standard search path
-during a run.
+This option requires that your operating system fully supports the "popen()"
+function in the standard runtime library and that a ``gzip`` executable can be
+found by LAMMPS during a run.
 
 .. note::
 
-   On clusters with high-speed networks, using the "fork()" library call
-   (required by "popen()") can interfere with the fast communication
+   On some clusters with high-speed networks, using the "fork()" library
+   call (required by "popen()") can interfere with the fast communication
    library and lead to simulations using compressed output or input to
    hang or crash. For selected operations, compressed file I/O is also
    available using a compression library instead, which is what the
@@ -452,7 +452,7 @@ those systems:
 
       .. code-block:: make
 
-         LMP_INC = -DLAMMPS_LONGLONG_TO_LONG  <other LMP_INC settings>
+         LMP_INC = -DLAMMPS_LONGLONG_TO_LONG
 
 ----------
 
@@ -479,7 +479,7 @@ e.g. to Python. Of course, the calling code has to be set up to
 
       .. code-block:: make
 
-         LMP_INC = -DLAMMPS_EXCEPTIONS   <other LMP_INC settings>
+         LMP_INC = -DLAMMPS_EXCEPTIONS
 
 .. note::
 
@@ -520,7 +520,7 @@ executable, not the library.
 
       .. code-block:: make
 
-         LMP_INC = -DLAMMPS_TRAP_FPE  <other LMP_INC settings>
+         LMP_INC = -DLAMMPS_TRAP_FPE
 
 After compilation with this flag set, the LAMMPS executable will stop
 and produce a core dump when a division by zero, overflow, illegal math

doc/src/Build_windows.rst

@@ -4,7 +4,6 @@ Notes for building LAMMPS on Windows
 * :ref:`General remarks <generic>`
 * :ref:`Running Linux on Windows <linux>`
 * :ref:`Using GNU GCC ported to Windows <gnu>`
-* :ref:`Using Visual Studio <msvc>`
 * :ref:`Using a cross-compiler <cross>`
 
 ----------
@@ -32,13 +31,13 @@ pre-compiled Windows binary packages are sufficient for your needs.  If
 it is necessary for you to compile LAMMPS on a Windows machine
 (e.g. because it is your main desktop), please also consider using a
 virtual machine software and compile and run LAMMPS in a Linux virtual
-machine, or - if you have a sufficiently up-to-date Windows 10 or
-Windows 11 installation - consider using the Windows subsystem for
-Linux.  This optional Windows feature allows you to run the bash shell
-from Ubuntu from within Windows and from there on, you can pretty much
-use that shell like you are running on an Ubuntu Linux machine
-(e.g. installing software via apt-get and more).  For more details on
-that, please see :doc:`this tutorial <Howto_wsl>`.
+machine, or - if you have a sufficiently up-to-date Windows 10
+installation - consider using the Windows subsystem for Linux.  This
+optional Windows feature allows you to run the bash shell from Ubuntu
+from within Windows and from there on, you can pretty much use that
+shell like you are running on an Ubuntu Linux machine (e.g. installing
+software via apt-get and more).  For more details on that, please see
+:doc:`this tutorial <Howto_wsl>`.
 
 .. _gnu:
 
@@ -68,40 +67,6 @@ requiring changes to the LAMMPS source code, or figure out corrections
 yourself, please report them on the lammps-users mailing list, or file
 them as an issue or pull request on the LAMMPS GitHub project.
 
-.. _msvc:
-
-Using Microsoft Visual Studio
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Following the integration of the :doc:`platform namespace
-<Developer_platform>` into the LAMMPS code base, portability of LAMMPS
-to be compiled on Windows using Visual Studio has been significantly
-improved.  This has been tested with Visual Studio 2019 (aka version
-16).  Not all features and packages in LAMMPS are currently supported
-out of the box, but a preset ``cmake/presets/windows.cmake`` is provided
-that contains the packages that have been compiled successfully.  You
-must use the CMake based build procedure, and either use the integrated
-CMake support of Visual Studio or use an external CMake installation to
-create build files for the Visual Studio build system.  Please note that
-on launching Visual Studio it will scan the directory tree and likely
-miss the correct master ``CMakeLists.txt``.  Try to open the
-``cmake/CMakeSettings.json`` and use those CMake configurations as a
-starting point.  It is also possible to configure and compile LAMMPS
-from the command line with a CMake binary from `cmake.org <https://cmake.org>`_.
-
-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
-accordingly.
-
-To support running in parallel you can compile with OpenMP enabled using
-the OPENMP package or install Microsoft MPI (including the SDK) and compile
-LAMMPS with MPI enabled.
-
-This is work in progress and you should contact the LAMMPS developers
-via GitHub, the forum, or the mailing list, if you have questions or
-LAMMPS specific problems.
-
 .. _cross:
 
 Using a cross-compiler

doc/src/Commands_bond.rst

@@ -35,7 +35,6 @@ OPT.
    * :doc:`class2 (ko) <bond_class2>`
    * :doc:`fene (iko) <bond_fene>`
    * :doc:`fene/expand (o) <bond_fene_expand>`
-   * :doc:`fene/nm <bond_fene>`
    * :doc:`gaussian <bond_gaussian>`
    * :doc:`gromos (o) <bond_gromos>`
    * :doc:`harmonic (iko) <bond_harmonic>`

doc/src/Commands_compute.rst

@@ -28,7 +28,6 @@ KOKKOS, o = OPENMP, t = OPT.
    * :doc:`angle <compute_angle>`
    * :doc:`angle/local <compute_angle_local>`
    * :doc:`angmom/chunk <compute_angmom_chunk>`
-   * :doc:`ave/sphere/atom (k) <compute_ave_sphere_atom>`
    * :doc:`basal/atom <compute_basal_atom>`
    * :doc:`body/local <compute_body_local>`
    * :doc:`bond <compute_bond>`

doc/src/Commands_fix.rst

@@ -23,7 +23,6 @@ OPT.
    :columns: 5
 
    * :doc:`accelerate/cos <fix_accelerate_cos>`
-   * :doc:`acks2/reaxff (k) <fix_acks2_reaxff>`
    * :doc:`adapt <fix_adapt>`
    * :doc:`adapt/fep <fix_adapt_fep>`
    * :doc:`addforce <fix_addforce>`
@@ -104,7 +103,6 @@ OPT.
    * :doc:`manifoldforce <fix_manifoldforce>`
    * :doc:`mdi/engine <fix_mdi_engine>`
    * :doc:`meso/move <fix_meso_move>`
-   * :doc:`mol/swap <fix_mol_swap>`
    * :doc:`momentum (k) <fix_momentum>`
    * :doc:`momentum/chunk <fix_momentum>`
    * :doc:`move <fix_move>`

doc/src/Commands_pair.rst

@@ -210,7 +210,6 @@ OPT.
    * :doc:`nm/cut (o) <pair_nm>`
    * :doc:`nm/cut/coul/cut (o) <pair_nm>`
    * :doc:`nm/cut/coul/long (o) <pair_nm>`
-   * :doc:`nm/cut/split <pair_nm>`
    * :doc:`oxdna/coaxstk <pair_oxdna>`
    * :doc:`oxdna/excv <pair_oxdna>`
    * :doc:`oxdna/hbond <pair_oxdna>`
@@ -263,7 +262,6 @@ OPT.
    * :doc:`spin/neel <pair_spin_neel>`
    * :doc:`srp <pair_srp>`
    * :doc:`sw (giko) <pair_sw>`
-   * :doc:`sw/mod (o) <pair_sw>`
    * :doc:`table (gko) <pair_table>`
    * :doc:`table/rx (k) <pair_table_rx>`
    * :doc:`tdpd <pair_mesodpd>`

doc/src/Developer.rst

@@ -18,5 +18,4 @@ of time and requests from the LAMMPS user community.
    Developer_plugins
    Developer_unittest
    Classes
-   Developer_platform
    Developer_utils

doc/src/Developer_platform.rst

@@ -1,155 +0,0 @@
-Platform abstraction functions
-------------------------------
-
-The ``platform`` sub-namespace inside the ``LAMMPS_NS`` namespace
-provides a collection of wrapper and convenience functions and utilities
-that perform common tasks for which platform specific code would be
-required or for which a more high-level abstraction would be convenient
-and reduce duplicated code.  This reduces redundant implementations and
-encourages consistent behavior and thus has some overlap with the
-:doc:`"utils" sub-namespace <Developer_utils>`.
-
-Time functions
-^^^^^^^^^^^^^^
-
-.. doxygenfunction:: cputime
-   :project: progguide
-
-.. doxygenfunction:: walltime
-   :project: progguide
-
-.. doxygenfunction:: usleep
-   :project: progguide
-
-Platform information functions
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. doxygenfunction:: os_info
-   :project: progguide
-
-.. doxygenfunction:: compiler_info
-   :project: progguide
-
-.. doxygenfunction:: cxx_standard
-   :project: progguide
-
-.. doxygenfunction:: openmp_standard
-   :project: progguide
-
-.. doxygenfunction:: mpi_vendor
-   :project: progguide
-
-.. doxygenfunction:: mpi_info
-   :project: progguide
-
-.. doxygenfunction:: compress_info
-   :project: progguide
-
-
-File and path functions and global constants
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. doxygenvariable:: filepathsep
-   :project: progguide
-
-.. doxygenvariable:: pathvarsep
-   :project: progguide
-
-.. doxygenfunction:: guesspath
-   :project: progguide
-
-.. doxygenfunction:: path_basename
-   :project: progguide
-
-.. doxygenfunction:: path_join
-   :project: progguide
-
-.. doxygenfunction:: file_is_readable
-   :project: progguide
-
-.. doxygenfunction:: is_console
-   :project: progguide
-
-.. doxygenfunction:: path_is_directory
-   :project: progguide
-
-.. doxygenfunction:: current_directory
-   :project: progguide
-
-.. doxygenfunction:: list_directory
-   :project: progguide
-
-.. doxygenfunction:: chdir
-   :project: progguide
-
-.. doxygenfunction:: mkdir
-   :project: progguide
-
-.. doxygenfunction:: rmdir
-   :project: progguide
-
-.. doxygenfunction:: unlink
-   :project: progguide
-
-Standard I/O function wrappers
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. doxygenvariable:: END_OF_FILE
-   :project: progguide
-
-.. doxygenfunction:: ftell
-   :project: progguide
-
-.. doxygenfunction:: fseek
-   :project: progguide
-
-.. doxygenfunction:: ftruncate
-   :project: progguide
-
-.. doxygenfunction:: popen
-   :project: progguide
-
-.. doxygenfunction:: pclose
-   :project: progguide
-
-Environment variable functions
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. doxygenfunction:: putenv
-   :project: progguide
-
-.. doxygenfunction:: unsetenv
-   :project: progguide
-
-.. doxygenfunction:: list_pathenv
-   :project: progguide
-
-.. doxygenfunction:: find_exe_path
-   :project: progguide
-
-Dynamically loaded object or library functions
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. doxygenfunction:: dlopen
-   :project: progguide
-
-.. doxygenfunction:: dlclose
-   :project: progguide
-
-.. doxygenfunction:: dlsym
-   :project: progguide
-
-.. doxygenfunction:: dlerror
-   :project: progguide
-
-Compressed file I/O functions
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. doxygenfunction:: has_compress_extension
-   :project: progguide
-
-.. doxygenfunction:: compressed_read
-   :project: progguide
-
-.. doxygenfunction:: compressed_write
-   :project: progguide

doc/src/Developer_utils.rst

@@ -7,9 +7,7 @@ a collection of convenience functions and utilities that perform common
 tasks that are required repeatedly throughout the LAMMPS code like
 reading or writing to files with error checking or translation of
 strings into specific types of numbers with checking for validity.  This
-reduces redundant implementations and encourages consistent behavior and
-thus has some overlap with the :doc:`"platform" sub-namespace
-<Developer_platform>`.
+reduces redundant implementations and encourages consistent behavior.
 
 I/O with status check and similar functions
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -56,14 +54,11 @@ String to number conversions with validity check
 
 These functions should be used to convert strings to numbers. They are
 are strongly preferred over C library calls like ``atoi()`` or
-``atof()`` since they check if the **entire** string is a valid
+``atof()`` since they check if the **entire** provided string is a valid
 (floating-point or integer) number, and will error out instead of
 silently returning the result of a partial conversion or zero in cases
-where the string is not a valid number.  This behavior improves
-detecting typos or issues when processing input files.
-
-Similarly the :cpp:func:`logical() <LAMMPS_NS::utils::logical>` function
-will convert a string into a boolean and will only accept certain words.
+where the string is not a valid number.  This behavior allows to more
+easily detect typos or issues when processing input files.
 
 The *do_abort* flag should be set to ``true`` in case  this function
 is called only on a single MPI rank, as that will then trigger the
@@ -76,34 +71,16 @@ strings for compliance without conversion.
 
 ----------
 
-.. doxygenfunction:: numeric(const char *file, int line, const std::string &str, bool do_abort, LAMMPS *lmp)
+.. doxygenfunction:: numeric
    :project: progguide
 
-.. doxygenfunction:: numeric(const char *file, int line, const char *str, bool do_abort, LAMMPS *lmp)
+.. doxygenfunction:: inumeric
    :project: progguide
 
-.. doxygenfunction:: inumeric(const char *file, int line, const std::string &str, bool do_abort, LAMMPS *lmp)
+.. doxygenfunction:: bnumeric
    :project: progguide
 
-.. doxygenfunction:: inumeric(const char *file, int line, const char *str, bool do_abort, LAMMPS *lmp)
-   :project: progguide
-
-.. doxygenfunction:: bnumeric(const char *file, int line, const std::string &str, bool do_abort, LAMMPS *lmp)
-   :project: progguide
-
-.. doxygenfunction:: bnumeric(const char *file, int line, const char *str, bool do_abort, LAMMPS *lmp)
-   :project: progguide
-
-.. doxygenfunction:: tnumeric(const char *file, int line, const std::string &str, bool do_abort, LAMMPS *lmp)
-   :project: progguide
-
-.. doxygenfunction:: tnumeric(const char *file, int line, const char *str, bool do_abort, LAMMPS *lmp)
-   :project: progguide
-
-.. doxygenfunction:: logical(const char *file, int line, const std::string &str, bool do_abort, LAMMPS *lmp)
-   :project: progguide
-
-.. doxygenfunction:: logical(const char *file, int line, const char *str, bool do_abort, LAMMPS *lmp)
+.. doxygenfunction:: tnumeric
    :project: progguide
 
 
@@ -118,12 +95,6 @@ and parsing files or arguments.
 .. doxygenfunction:: strdup
    :project: progguide
 
-.. doxygenfunction:: lowercase
-   :project: progguide
-
-.. doxygenfunction:: uppercase
-   :project: progguide
-
 .. doxygenfunction:: trim
    :project: progguide
 
@@ -166,6 +137,21 @@ and parsing files or arguments.
 .. doxygenfunction:: is_double
    :project: progguide
 
+File and path functions
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. doxygenfunction:: guesspath
+   :project: progguide
+
+.. doxygenfunction:: path_basename
+   :project: progguide
+
+.. doxygenfunction:: path_join
+   :project: progguide
+
+.. doxygenfunction:: file_is_readable
+   :project: progguide
+
 Potential file functions
 ^^^^^^^^^^^^^^^^^^^^^^^^
 

doc/src/Developer_write.rst

@@ -29,9 +29,7 @@ of code in the header before include guards:
 .. code-block:: c
 
    #ifdef FIX_CLASS
-   // clang-format off
-   FixStyle(print/vel,FixPrintVel);
-   // clang-format on
+   FixStyle(print/vel,FixPrintVel)
    #else
    /* the definition of the FixPrintVel class comes here */
    ...

doc/src/Errors_messages.rst

@@ -7772,6 +7772,9 @@ keyword to allow for additional bonds to be formed
    The system size must fit in a 32-bit integer to use this dump
    style.
 
+*Too many atoms to dump sort*
+   Cannot sort when running with more than 2\^31 atoms.
+
 *Too many elements extracted from MEAM library.*
    Increase 'maxelt' in meam.h and recompile.
 

doc/src/Examples.rst

@@ -80,7 +80,7 @@ Lowercase directories
 +-------------+------------------------------------------------------------------+
 | friction    | frictional contact of spherical asperities between 2d surfaces   |
 +-------------+------------------------------------------------------------------+
-| mc          | Monte Carlo features via fix gcmc, widom and other commands      |
+| gcmc        | Grand Canonical Monte Carlo (GCMC) via the fix gcmc command      |
 +-------------+------------------------------------------------------------------+
 | granregion  | use of fix wall/region/gran as boundary on granular particles    |
 +-------------+------------------------------------------------------------------+
@@ -205,7 +205,7 @@ Uppercase directories
 +------------+--------------------------------------------------------------------------------------------------+
 | KAPPA      | compute thermal conductivity via several methods                                                 |
 +------------+--------------------------------------------------------------------------------------------------+
-| MC-LOOP    | using LAMMPS in a Monte Carlo mode to relax the energy of a system in a input script loop        |
+| MC         | using LAMMPS in a Monte Carlo mode to relax the energy of a system                               |
 +------------+--------------------------------------------------------------------------------------------------+
 | PACKAGES   | examples for specific packages and contributed commands                                          |
 +------------+--------------------------------------------------------------------------------------------------+

doc/src/Howto_drude2.rst

@@ -491,6 +491,11 @@ NPT ensemble using Nose-Hoover thermostat:
 **(Schroeder)**  Schroeder and Steinhauser, J Chem Phys, 133,
 154511 (2010).
 
+.. _Jiang2:
+
+**(Jiang)** Jiang, Hardy, Phillips, MacKerell, Schulten, and Roux,
+ J Phys Chem Lett, 2, 87-92 (2011).
+
 .. _Thole2:
 
 **(Thole)** Chem Phys, 59, 341 (1981).

doc/src/Howto_thermostat.rst

@@ -2,8 +2,8 @@ Thermostats
 ===========
 
 Thermostatting means controlling the temperature of particles in an MD
-simulation.  :doc:`Barostatting <Howto_barostat>` means controlling
-the pressure.  Since the pressure includes a kinetic component due to
+simulation.  :doc:`Barostatting <Howto_barostat>` means controlling the
+pressure.  Since the pressure includes a kinetic component due to
 particle velocities, both these operations require calculation of the
 temperature.  Typically a target temperature (T) and/or pressure (P)
 is specified by the user, and the thermostat or barostat attempts to
@@ -26,13 +26,11 @@ can be invoked via the *dpd/tstat* pair style:
 * :doc:`pair_style dpd/tstat <pair_dpd>`
 
 :doc:`Fix nvt <fix_nh>` only thermostats the translational velocity of
-particles.  :doc:`Fix nvt/sllod <fix_nvt_sllod>` also does this,
-except that it subtracts out a velocity bias due to a deforming box
-and integrates the SLLOD equations of motion.  See the :doc:`Howto
-nemd <Howto_nemd>` page for further details.  :doc:`Fix nvt/sphere
-<fix_nvt_sphere>` and :doc:`fix nvt/asphere <fix_nvt_asphere>`
-thermostat not only translation velocities but also rotational
-velocities for spherical and aspherical particles.
+particles.  :doc:`Fix nvt/sllod <fix_nvt_sllod>` also does this, except
+that it subtracts out a velocity bias due to a deforming box and
+integrates the SLLOD equations of motion.  See the :doc:`Howto nemd <Howto_nemd>` page for further details.  :doc:`Fix nvt/sphere <fix_nvt_sphere>` and :doc:`fix nvt/asphere <fix_nvt_asphere>` thermostat not only translation
+velocities but also rotational velocities for spherical and aspherical
+particles.
 
 .. note::
 
@@ -42,31 +40,25 @@ velocities for spherical and aspherical particles.
    e.g. molecular systems.  The latter can be tricky to do correctly.
 
 DPD thermostatting alters pairwise interactions in a manner analogous
-to the per-particle thermostatting of :doc:`fix langevin
-<fix_langevin>`.
+to the per-particle thermostatting of :doc:`fix langevin <fix_langevin>`.
 
-Any of the thermostatting fixes can be instructed to use custom
-temperature computes that remove bias which has two effects: first,
-the current calculated temperature, which is compared to the requested
-target temperature, is calculated with the velocity bias removed;
-second, the thermostat adjusts only the thermal temperature component
-of the particle's velocities, which are the velocities with the bias
-removed.  The removed bias is then added back to the adjusted
-velocities.  See the doc pages for the individual fixes and for the
-:doc:`fix_modify <fix_modify>` command for instructions on how to
-assign a temperature compute to a thermostatting fix.
+Any of the thermostatting fixes can be instructed to use custom temperature
+computes that remove bias which has two effects:  first, the current
+calculated temperature, which is compared to the requested target temperature,
+is calculated with the velocity bias removed;  second, the thermostat adjusts
+only the thermal temperature component of the particle's velocities, which are
+the velocities with the bias removed.  The removed bias is then added back
+to the adjusted velocities.  See the doc pages for the individual
+fixes and for the :doc:`fix_modify <fix_modify>` command for
+instructions on how to assign a temperature compute to a
+thermostatting fix.  For example, you can apply a thermostat to only
+the x and z components of velocity by using it in conjunction with
+:doc:`compute temp/partial <compute_temp_partial>`.  Of you could
+thermostat only the thermal temperature of a streaming flow of
+particles without affecting the streaming velocity, by using
+:doc:`compute temp/profile <compute_temp_profile>`.
 
-For example, you can apply a thermostat only to atoms in a spatial
-region by using it in conjunction with :doc:`compute temp/region
-<compute_temp_region>`.  Or you can apply a thermostat to only the x
-and z components of velocity by using it with :doc:`compute
-temp/partial <compute_temp_partial>`.  Of you could thermostat only
-the thermal temperature of a streaming flow of particles without
-affecting the streaming velocity, by using :doc:`compute temp/profile
-<compute_temp_profile>`.
-
-Below is a list of custom temperature computes that can be used like
-that:
+Below is a list of some custom temperature computes that can be used like that:
 
 * :doc:`compute_temp_asphere`
 * :doc:`compute_temp_body`
@@ -80,6 +72,8 @@ that:
 * :doc:`compute_temp_rotate`
 * :doc:`compute_temp_sphere`
 
+
+
 .. note::
 
    Only the nvt fixes perform time integration, meaning they update
@@ -92,17 +86,17 @@ that:
 * :doc:`fix nve/sphere <fix_nve_sphere>`
 * :doc:`fix nve/asphere <fix_nve_asphere>`
 
-Thermodynamic output, which can be setup via the :doc:`thermo_style
-<thermo_style>` command, often includes temperature values.  As
-explained on the page for the :doc:`thermo_style <thermo_style>`
-command, the default temperature is setup by the thermo command
-itself.  It is NOT the temperature associated with any thermostatting
-fix you have defined or with any compute you have defined that
-calculates a temperature.  The doc pages for the thermostatting fixes
-explain the ID of the temperature compute they create.  Thus if you
-want to view these temperatures, you need to specify them explicitly
-via the :doc:`thermo_style custom <thermo_style>` command.  Or you can
-use the :doc:`thermo_modify <thermo_modify>` command to re-define what
+Thermodynamic output, which can be setup via the
+:doc:`thermo_style <thermo_style>` command, often includes temperature
+values.  As explained on the page for the
+:doc:`thermo_style <thermo_style>` command, the default temperature is
+setup by the thermo command itself.  It is NOT the temperature
+associated with any thermostatting fix you have defined or with any
+compute you have defined that calculates a temperature.  The doc pages
+for the thermostatting fixes explain the ID of the temperature compute
+they create.  Thus if you want to view these temperatures, you need to
+specify them explicitly via the :doc:`thermo_style custom <thermo_style>` command.  Or you can use the
+:doc:`thermo_modify <thermo_modify>` command to re-define what
 temperature compute is used for default thermodynamic output.
 
 ----------

doc/src/Packages_details.rst

@@ -1880,12 +1880,6 @@ MPIIO library.  It adds :doc:`dump styles <dump>` with a "mpiio" in
 their style name.  Restart files with an ".mpiio" suffix are also
 written and read in parallel.
 
-.. warning::
-
-   The MPIIO package is currently unmaintained and has become
-   unreliable. Use with caution.
-
-
 **Install:**
 
 The MPIIO package requires that LAMMPS is build in :ref:`MPI parallel mode <serial>`.

doc/src/Speed.rst

@@ -14,7 +14,7 @@ Intel Xeon Phi co-processors.
 
 The `Benchmark page <https://www.lammps.org/bench.html>`_ of the LAMMPS
 website gives performance results for the various accelerator
-packages discussed on the :doc:`Accelerator packages <Speed_packages>`
+packages discussed on the :doc:`Speed packages <Speed_packages>` doc
 page, for several of the standard LAMMPS benchmark problems, as a
 function of problem size and number of compute nodes, on different
 hardware platforms.

doc/src/accel_styles.rst

@@ -1,7 +1,7 @@
 Styles with a *gpu*, *intel*, *kk*, *omp*, or *opt* suffix are
 functionally the same as the corresponding style without the suffix.
 They have been optimized to run faster, depending on your available
-hardware, as discussed on the :doc:`Accelerator packages <Speed_packages>`
+hardware, as discussed on the :doc:`Speed packages <Speed_packages>` doc
 page.  The accelerated styles take the same arguments and should
 produce the same results, except for round-off and precision issues.
 
@@ -13,5 +13,5 @@ You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the :doc:`-suffix command-line switch <Run_options>` when you invoke LAMMPS, or you can use the
 :doc:`suffix <suffix>` command in your input script.
 
-See the :doc:`Accelerator packages <Speed_packages>` page for more
+See the :doc:`Speed packages <Speed_packages>` page for more
 instructions on how to use the accelerated styles effectively.

doc/src/angle_charmm.rst

@@ -56,7 +56,23 @@ radian\^2.
 
 ----------
 
-.. include:: accel_styles.rst
+Styles with a *gpu*, *intel*, *kk*, *omp*, or *opt* suffix are
+functionally the same as the corresponding style without the suffix.
+They have been optimized to run faster, depending on your available
+hardware, as discussed on the :doc:`Speed packages <Speed_packages>` doc
+page.  The accelerated styles take the same arguments and should
+produce the same results, except for round-off and precision issues.
+
+These accelerated styles are part of the GPU, INTEL, KOKKOS,
+OPENMP and OPT packages, respectively.  They are only enabled if
+LAMMPS was built with those packages.  See the :doc:`Build package <Build_package>` page for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the :doc:`-suffix command-line switch <Run_options>` when you invoke LAMMPS, or you can use the
+:doc:`suffix <suffix>` command in your input script.
+
+See :doc:`Speed packages <Speed_packages>` page for more
+instructions on how to use the accelerated styles effectively.
 
 ----------
 

doc/src/angle_class2.rst

@@ -64,44 +64,34 @@ These are the 4 coefficients for the :math:`E_a` formula:
 radians internally; hence the various :math:`K` are effectively energy
 per radian\^2 or radian\^3 or radian\^4.
 
-For the :math:`E_{bb}` formula, each line in a :doc:`angle_coeff
-<angle_coeff>` command in the input script lists 4 coefficients, the
-first of which is "bb" to indicate they are BondBond coefficients.  In
-a data file, these coefficients should be listed under a "BondBond
-Coeffs" heading and you must leave out the "bb", i.e. only list 3
-coefficients after the angle type.
+For the :math:`E_{bb}` formula, each line in a :doc:`angle_coeff <angle_coeff>`
+command in the input script lists 4 coefficients, the first of which
+is "bb" to indicate they are BondBond coefficients.  In a data file,
+these coefficients should be listed under a "BondBond Coeffs" heading
+and you must leave out the "bb", i.e. only list 3 coefficients after
+the angle type.
 
 * bb
 * :math:`M` (energy/distance\^2)
 * :math:`r_1` (distance)
 * :math:`r_2` (distance)
 
-For the :math:`E_{ba}` formula, each line in a :doc:`angle_coeff
-<angle_coeff>` command in the input script lists 5 coefficients, the
-first of which is "ba" to indicate they are BondAngle coefficients.
-In a data file, these coefficients should be listed under a "BondAngle
-Coeffs" heading and you must leave out the "ba", i.e. only list 4
-coefficients after the angle type.
+For the :math:`E_{ba}` formula, each line in a :doc:`angle_coeff <angle_coeff>`
+command in the input script lists 5 coefficients, the first of which
+is "ba" to indicate they are BondAngle coefficients.  In a data file,
+these coefficients should be listed under a "BondAngle Coeffs" heading
+and you must leave out the "ba", i.e. only list 4 coefficients after
+the angle type.
 
 * ba
-* :math:`N_1` (energy/distance)
-* :math:`N_2` (energy/distance)
+* :math:`N_1` (energy/distance\^2)
+* :math:`N_2` (energy/distance\^2)
 * :math:`r_1` (distance)
 * :math:`r_2` (distance)
 
 The :math:`\theta_0` value in the :math:`E_{ba}` formula is not specified,
 since it is the same value from the :math:`E_a` formula.
 
-.. note::
-
-   It is important that the order of the I,J,K atoms in each angle
-   listed in the Angles section of the data file read by the
-   :doc:`read_data <read_data>` command be consistent with the order
-   of the :math:`r_1` and :math:`r_2` BondBond and BondAngle
-   coefficients.  This is because the terms in the formulas for
-   :math:`E_{bb}` and :math:`E_{ba}` will use the I,J atoms to compute
-   :math:`r_{ij}` and the J,K atoms to compute :math:`r_{jk}`.
-
 ----------
 
 .. include:: accel_styles.rst

doc/src/atom_style.rst

@@ -319,9 +319,28 @@ styles; see the :doc:`Modify <Modify>` doc page.
 
 ----------
 
-.. include:: accel_styles.rst
+Styles with a *kk* suffix are functionally the same as the
+corresponding style without the suffix.  They have been optimized to
+run faster, depending on your available hardware, as discussed in on
+the :doc:`Speed packages <Speed_packages>` doc page.  The accelerated
+styles take the same arguments and should produce the same results,
+except for round-off and precision issues.
 
-----------
+Note that other acceleration packages in LAMMPS, specifically the GPU,
+INTEL, OPENMP, and OPT packages do not use accelerated atom
+styles.
+
+The accelerated styles are part of the KOKKOS package.  They are only
+enabled if LAMMPS was built with those packages.  See the :doc:`Build
+package <Build_package>` page for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the :doc:`-suffix command-line
+switch <Run_options>` when you invoke LAMMPS, or you can use the
+:doc:`suffix <suffix>` command in your input script.
+
+See the :doc:`Speed packages <Speed_packages>` page for more
+instructions on how to use the accelerated styles effectively.
 
 Restrictions
 """"""""""""

doc/src/bond_fene.rst

@@ -1,5 +1,4 @@
 .. index:: bond_style fene
-.. index:: bond_style fene/nm
 .. index:: bond_style fene/intel
 .. index:: bond_style fene/kk
 .. index:: bond_style fene/omp
@@ -9,16 +8,12 @@ bond_style fene command
 
 Accelerator Variants: *fene/intel*, *fene/kk*, *fene/omp*
 
-bond_style fene/nm command
-==========================
-
 Syntax
 """"""
 
 .. code-block:: LAMMPS
 
    bond_style fene
-   bond_style fene/nm
 
 Examples
 """"""""
@@ -28,9 +23,6 @@ Examples
    bond_style fene
    bond_coeff 1 30.0 1.5 1.0 1.0
 
-   bond_style fene/nm
-   bond_coeff 1 2.25344 1.5 1.0 1.12246 2 6
-
 Description
 """""""""""
 
@@ -46,36 +38,16 @@ term is attractive, the second Lennard-Jones term is repulsive.  The
 first term extends to :math:`R_0`, the maximum extent of the bond.  The second
 term is cutoff at :math:`2^\frac{1}{6} \sigma`, the minimum of the LJ potential.
 
-The *fene/nm* bond style substitutes the standard LJ potential with the generalized LJ potential
-in the same form as in pair style :doc:`nm/cut <pair_nm>`. The bond energy is then given by
-
-.. math::
-
-  E = -0.5 K r_0^2  \ln \left[ 1 - \left(\frac{r}{R_0}\right)^2\right] + \frac{E_0}{(n-m)} \left[ m \left(\frac{r_0}{r}\right)^n - n \left(\frac{r_0}{r}\right)^m \right]
-
-Similar to the *fene* style, the generalized Lennard-Jones is cut off at
-the potential minimum, :math:`r_0`, to be repulsive only.  The following
-coefficients must be defined for each bond type via the :doc:`bond_coeff
-<bond_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:
+The following coefficients must be defined for each bond type via the
+:doc:`bond_coeff <bond_coeff>` command as in the example above, or in
+the data file or restart files read by the :doc:`read_data <read_data>`
+or :doc:`read_restart <read_restart>` commands:
 
 * :math:`K` (energy/distance\^2)
 * :math:`R_0` (distance)
 * :math:`\epsilon` (energy)
 * :math:`\sigma` (distance)
 
-For the *fene/nm* style, the following coefficients are used.  Please
-note, that the standard LJ potential and thus the regular FENE potential
-is recovered for (n=12 m=6) and :math:`r_0 = 2^\frac{1}{6} \sigma`.
-
-* :math:`K` (energy/distance\^2)
-* :math:`R_0` (distance)
-* :math:`E_0` (energy)
-* :math:`r_0` (distance)
-* :math:`n` (unitless)
-* :math:`m` (unitless)
-
 ----------
 
 .. include:: accel_styles.rst
@@ -85,10 +57,9 @@ is recovered for (n=12 m=6) and :math:`r_0 = 2^\frac{1}{6} \sigma`.
 Restrictions
 """"""""""""
 
-The *fene* bond style can only be used if LAMMPS was built with the MOLECULE
-package; the *fene/nm* bond style can only be used if LAMMPS was built
-with the EXTRA-MOLECULE package. See the :doc:`Build package <Build_package>`
-page for more info.
+This bond style can only be used if LAMMPS was built with the MOLECULE
+package.  See the :doc:`Build package <Build_package>` page for more
+info.
 
 You typically should specify :doc:`special_bonds fene <special_bonds>`
 or :doc:`special_bonds lj/coul 0 1 1 <special_bonds>` to use this bond
@@ -97,8 +68,7 @@ style.  LAMMPS will issue a warning it that's not the case.
 Related commands
 """"""""""""""""
 
-:doc:`bond_coeff <bond_coeff>`, :doc:`delete_bonds <delete_bonds>`,
-:doc:`pair style lj/cut <pair_lj>`, :doc:`pair style nm/cut <pair_nm>`.
+:doc:`bond_coeff <bond_coeff>`, :doc:`delete_bonds <delete_bonds>`
 
 Default
 """""""

doc/src/bond_style.rst

@@ -87,7 +87,6 @@ accelerated styles exist.
 * :doc:`class2 <bond_class2>` - COMPASS (class 2) bond
 * :doc:`fene <bond_fene>` - FENE (finite-extensible non-linear elastic) bond
 * :doc:`fene/expand <bond_fene_expand>` - FENE bonds with variable size particles
-* :doc:`fene/nm <bond_fene>` - FENE bonds with a generalized Lennard-Jones potential
 * :doc:`gaussian <bond_gaussian>` - multicentered Gaussian-based bond potential
 * :doc:`gromos <bond_gromos>` - GROMOS force field bond
 * :doc:`harmonic <bond_harmonic>` - harmonic bond

doc/src/compute.rst

@@ -174,7 +174,6 @@ The individual style names on the :doc:`Commands compute <Commands_compute>` pag
 * :doc:`angle <compute_angle>` - energy of each angle sub-style
 * :doc:`angle/local <compute_angle_local>` - theta and energy of each angle
 * :doc:`angmom/chunk <compute_angmom_chunk>` - angular momentum for each chunk
-* :doc:`ave/sphere/atom <compute_ave_sphere_atom>` - compute local density and temperature around each atom
 * :doc:`basal/atom <compute_basal_atom>` - calculates the hexagonal close-packed "c" lattice vector of each atom
 * :doc:`body/local <compute_body_local>` - attributes of body sub-particles
 * :doc:`bond <compute_bond>` - energy of each bond sub-style

doc/src/compute_ave_sphere_atom.rst

@@ -1,101 +0,0 @@
-.. index:: compute ave/sphere/atom
-.. index:: compute ave/sphere/atom/kk
-
-compute ave/sphere/atom command
-================================
-
-Accelerator Variants: *ave/sphere/atom/kk*
-
-Syntax
-""""""
-
-.. parsed-literal::
-
-   compute ID group-ID ave/sphere/atom keyword values ...
-
-* ID, group-ID are documented in :doc:`compute <compute>` command
-* ave/sphere/atom = style name of this compute command
-* one or more keyword/value pairs may be appended
-
-  .. parsed-literal::
-
-     keyword = *cutoff*
-       *cutoff* value = distance cutoff
-
-Examples
-""""""""
-
-.. code-block:: LAMMPS
-
-   compute 1 all ave/sphere/atom
-
-   compute 1 all ave/sphere/atom cutoff 5.0
-   comm_modify cutoff 5.0
-
-Description
-"""""""""""
-
-Define a computation that calculates the local density and temperature
-for each atom and neighbors inside a spherical cutoff.
-
-The optional keyword *cutoff* defines the distance cutoff
-used when searching for neighbors. The default value is the cutoff
-specified by the pair style. If no pair style is defined, then a cutoff
-must be defined using this keyword. If the specified cutoff is larger than
-that of the pair_style plus neighbor skin (or no pair style is defined),
-the *comm_modify cutoff* option must also be set to match that of the
-*cutoff* keyword.
-
-The neighbor list needed to compute this quantity is constructed each
-time the calculation is performed (i.e. each time a snapshot of atoms
-is dumped).  Thus it can be inefficient to compute/dump this quantity
-too frequently.
-
-.. note::
-
-   If you have a bonded system, then the settings of
-   :doc:`special_bonds <special_bonds>` command can remove pairwise
-   interactions between atoms in the same bond, angle, or dihedral.  This
-   is the default setting for the :doc:`special_bonds <special_bonds>`
-   command, and means those pairwise interactions do not appear in the
-   neighbor list.  Because this fix uses the neighbor list, it also means
-   those pairs will not be included in the order parameter.  This
-   difficulty can be circumvented by writing a dump file, and using the
-   :doc:`rerun <rerun>` command to compute the order parameter for
-   snapshots in the dump file.  The rerun script can use a
-   :doc:`special_bonds <special_bonds>` command that includes all pairs in
-   the neighbor list.
-
-----------
-
-
-.. include:: accel_styles.rst
-
-
-----------
-
-Output info
-"""""""""""
-
-This compute calculates a per-atom array with two columns: density and temperature.
-
-These values can be accessed by any command that uses per-atom values
-from a compute as input.  See the :doc:`Howto output <Howto_output>` doc
-page for an overview of LAMMPS output options.
-
-Restrictions
-""""""""""""
-
-This compute is part of the EXTRA-COMPUTE package.  It is only enabled if
-LAMMPS was built with that package.  See the :doc:`Build package <Build_package>` page for more info.
-
-Related commands
-""""""""""""""""
-
-:doc:`comm_modify <comm_modify>`
-
-Default
-"""""""
-
-The option defaults are *cutoff* = pair style cutoff
-

doc/src/compute_bond_local.rst

@@ -13,7 +13,7 @@ Syntax
 * ID, group-ID are documented in :doc:`compute <compute>` command
 * bond/local = style name of this compute command
 * one or more values may be appended
-* value = *dist* or *dx* or *dy* or *dz* or *engpot* or *force* or *fx* or *fy* or *fz* or *engvib* or *engrot* or *engtrans* or *omega* or *velvib* or *v_name*
+* value = *dist* or *engpot* or *force* or *fx* or *fy* or *fz* or *engvib* or *engrot* or *engtrans* or *omega* or *velvib* or *v_name*
 
 .. parsed-literal::
 
@@ -21,7 +21,6 @@ Syntax
      *engpot* = bond potential energy
      *force* = bond force
 
-     *dx*,\ *dy*,\ *dz* = components of pairwise distance
      *fx*,\ *fy*,\ *fz* = components of bond force
      *engvib* = bond kinetic energy of vibration
      *engrot* = bond kinetic energy of rotation
@@ -64,9 +63,6 @@ whether the 2 atoms represent a simple diatomic molecule, or are part
 of some larger molecule.
 
 The value *dist* is the current length of the bond.
-The values *dx*, *dy*, and *dz* are the xyz components of the
-*distance* between the pair of atoms. This value is always the
-distance from the atom of lower to the one with the higher id.
 
 The value *engpot* is the potential energy for the bond,
 based on the current separation of the pair of atoms in the bond.

doc/src/compute_heat_flux.rst

@@ -89,20 +89,13 @@ included in the calculation.
 .. warning::
 
    The compute *heat/flux* has been reported to produce unphysical
-   values for angle, dihedral, improper and constraint force contributions
+   values for angle, dihedral and improper contributions
    when used with :doc:`compute stress/atom <compute_stress_atom>`,
-   as discussed in :ref:`(Surblys2019) <Surblys3>`, :ref:`(Boone) <Boone>`
-   and :ref:`(Surblys2021) <Surblys4>`. You are strongly advised to
+   as discussed in :ref:`(Surblys) <Surblys2>` and :ref:`(Boone) <Boone>`.
+   You are strongly advised to
    use :doc:`compute centroid/stress/atom <compute_stress_atom>`,
    which has been implemented specifically for such cases.
 
-.. warning::
-
-   Due to an implementation detail, the :math:`y` and :math:`z`
-   components of heat flux from :doc:`fix rigid <fix_rigid>`
-   contribution when computed via :doc:`compute stress/atom <compute_stress_atom>`
-   are highly unphysical and should not be used.
-
 The Green-Kubo formulas relate the ensemble average of the
 auto-correlation of the heat flux :math:`\mathbf{J}`
 to the thermal conductivity :math:`\kappa`:
@@ -239,14 +232,10 @@ none
 
 ----------
 
-.. _Surblys3:
+.. _Surblys2:
 
-**(Surblys2019)** Surblys, Matsubara, Kikugawa, Ohara, Phys Rev E, 99, 051301(R) (2019).
+**(Surblys)** Surblys, Matsubara, Kikugawa, Ohara, Phys Rev E, 99, 051301(R) (2019).
 
 .. _Boone:
 
 **(Boone)** Boone, Babaei, Wilmer, J Chem Theory Comput, 15, 5579--5587 (2019).
-
-.. _Surblys4:
-
-**(Surblys2021)** Surblys, Matsubara, Kikugawa, Ohara, J Appl Phys 130, 215104 (2021).

doc/src/compute_pair_local.rst

@@ -13,12 +13,11 @@ Syntax
 * ID, group-ID are documented in :doc:`compute <compute>` command
 * pair/local = style name of this compute command
 * one or more values may be appended
-* value = *dist* or *dx* or *dy* or *dz* or *eng* or *force* or *fx* or *fy* or *fz* or *pN*
+* value = *dist* or *eng* or *force* or *fx* or *fy* or *fz* or *pN*
 
   .. parsed-literal::
 
        *dist* = pairwise distance
-       *dx*,\ *dy*,\ *dz* = components of pairwise distance
        *eng* = pairwise energy
        *force* = pairwise force
        *fx*,\ *fy*,\ *fz* = components of pairwise force
@@ -57,9 +56,6 @@ force cutoff distance for that interaction, as defined by the
 commands.
 
 The value *dist* is the distance between the pair of atoms.
-The values *dx*, *dy*, and *dz* are the xyz components of the
-*distance* between the pair of atoms. This value is always the
-distance from the atom of lower to the one with the higher id.
 
 The value *eng* is the interaction energy for the pair of atoms.
 
@@ -93,10 +89,10 @@ from the second of the two sub-styles.  If the referenced *pN*
 is not computed for the specific pairwise interaction (based on
 atom types), then the output will be 0.0.
 
-The value *dist*, *dx*, *dy* and *dz* will be in distance :doc:`units <units>`.
-The value *eng* will be in energy :doc:`units <units>`.
-The values *force*, *fx*, *fy*, and *fz* will be in force :doc:`units <units>`.
-The values *pN* will be in whatever units the pair style defines.
+The value *dist* will be in distance :doc:`units <units>`.  The value
+*eng* will be in energy :doc:`units <units>`.  The values *force*, *fx*,
+*fy*, and *fz* will be in force :doc:`units <units>`.  The values *pN*
+will be in whatever units the pair style defines.
 
 The optional *cutoff* keyword determines how the force cutoff distance
 for an interaction is determined.  For the default setting of *type*,

doc/src/compute_stress_atom.rst

@@ -87,10 +87,6 @@ Tersoff 3-body interaction) is assigned in equal portions to each atom
 in the set.  E.g. 1/4 of the dihedral virial to each of the 4 atoms,
 or 1/3 of the fix virial due to SHAKE constraints applied to atoms in
 a water molecule via the :doc:`fix shake <fix_shake>` command.
-As an exception, the virial contribution from
-constraint forces in :doc:`fix rigid <fix_rigid>` on each atom
-is computed from the constraint force acting on the corresponding atom
-and its position, i.e. the total virial is not equally distributed.
 
 In case of compute *centroid/stress/atom*, the virial contribution is:
 
@@ -107,25 +103,13 @@ atom :math:`I` due to the interaction and the relative position
 :math:`\mathbf{r}_{I0}` of the atom :math:`I` to the geometric center
 of the interacting atoms, i.e. centroid, is used.  As the geometric
 center is different for each interaction, the :math:`\mathbf{r}_{I0}`
-also differs. The sixth term, Kspace contribution,
-is computed identically to compute *stress/atom*.
-The seventh term is handed differently depending on
-if the constraint forces are due to :doc:`fix shake <fix_shake>`
-or :doc:`fix rigid <fix_rigid>`.
-In case of SHAKE constraints, each distance constraint is
-handed as a pairwise interaction.
-E.g. in case of a water molecule, two OH and one HH distance
-constraints are treated as three pairwise interactions.
-In case of :doc:`fix rigid <fix_rigid>`,
-all constraint forces in the molecule are treated
-as a single many-body interaction with a single centroid position.
-In case of water molecule, the formula expression would become
-identical to that of the three-body angle interaction.
-Although the total system virial is the same as
+also differs.  The sixth and seventh terms, Kspace and :doc:`fix
+<fix>` contribution respectively, are computed identical to compute
+*stress/atom*.  Although the total system virial is the same as
 compute *stress/atom*, compute *centroid/stress/atom* is know to
-result in more consistent heat flux values for angle, dihedrals,
-improper and constraint force contributions
-when computed via :doc:`compute heat/flux <compute_heat_flux>`.
+result in more consistent heat flux values for angle, dihedrals and
+improper contributions when computed via :doc:`compute heat/flux
+<compute_heat_flux>`.
 
 If no extra keywords are listed, the kinetic contribution all of the
 virial contribution terms are included in the per-atom stress tensor.
@@ -150,8 +134,7 @@ contribution for the cluster interaction is divided evenly among those
 atoms.
 
 Details of how compute *centroid/stress/atom* obtains the virial for
-individual atoms are given in :ref:`(Surblys2019) <Surblys1>` and
-:ref:`(Surblys2021) <Surblys2>`, where the
+individual atoms is given in :ref:`(Surblys) <Surblys1>`, where the
 idea is that the virial of the atom :math:`I` is the result of only
 the force :math:`\mathbf{F}_I` on the atom due to the interaction and
 its positional vector :math:`\mathbf{r}_{I0}`, relative to the
@@ -252,10 +235,10 @@ between the pair of particles.  All bond styles are supported.  All
 angle, dihedral, improper styles are supported with the exception of
 INTEL and KOKKOS variants of specific styles.  It also does not
 support models with long-range Coulombic or dispersion forces,
-i.e. the kspace_style command in LAMMPS.  It also does not implement the
-following fixes which add rigid-body constraints:
-:doc:`fix rigid/* <fix_rigid>` and the OpenMP accelerated version of :doc:`fix rigid/small <fix_rigid>`,
-while all other :doc:`fix rigid/*/small <fix_rigid>` are implemented.
+i.e. the kspace_style command in LAMMPS.  It also does not support the
+following fixes which add rigid-body constraints: :doc:`fix shake
+<fix_shake>`, :doc:`fix rattle <fix_shake>`, :doc:`fix rigid
+<fix_rigid>`, :doc:`fix rigid/small <fix_rigid>`.
 
 LAMMPS will generate an error if one of these options is included in
 your model.  Extension of centroid stress calculations to these force
@@ -287,8 +270,4 @@ none
 
 .. _Surblys1:
 
-**(Surblys2019)** Surblys, Matsubara, Kikugawa, Ohara, Phys Rev E, 99, 051301(R) (2019).
-
-.. _Surblys2:
-
-**(Surblys2021)** Surblys, Matsubara, Kikugawa, Ohara, J Appl Phys 130, 215104 (2021).
+**(Surblys)** Surblys, Matsubara, Kikugawa, Ohara, Phys Rev E, 99, 051301(R) (2019).

doc/src/delete_atoms.rst

@@ -20,10 +20,8 @@ Syntax
          cutoff = delete one atom from pairs of atoms within the cutoff (distance units)
          group1-ID = one atom in pair must be in this group
          group2-ID = other atom in pair must be in this group
-       *porosity* args = group-ID region-ID fraction seed
-         group-ID = group within which to perform deletions
+       *porosity* args = region-ID fraction seed
          region-ID = region within which to perform deletions
-                     or NULL to only impose the group criterion
          fraction = delete this fraction of atoms
          seed = random number seed (positive integer)
 
@@ -45,8 +43,7 @@ Examples
    delete_atoms region sphere compress no
    delete_atoms overlap 0.3 all all
    delete_atoms overlap 0.5 solvent colloid
-   delete_atoms porosity all cube 0.1 482793 bond yes
-   delete_atoms porosity polymer cube 0.1 482793 bond yes
+   delete_atoms porosity cube 0.1 482793 bond yes
 
 Description
 """""""""""
@@ -79,17 +76,12 @@ have occurred that no atom pairs within the cutoff will remain
 minimum number of atoms will be deleted, or that the same atoms will
 be deleted when running on different numbers of processors.
 
-For style *porosity* a specified *fraction* of atoms are deleted which
-are both in the specified group and within the specified region.  The
-region-ID can be specified as NULL to only impose the group criterion.
-Likewise, specifying the group-ID as *all* will only impose the region
-criterion.
-
-For example, if fraction is 0.1, then 10% of the eligible atoms will
-be deleted.  The atoms to delete are chosen randomly.  There is no
-guarantee that the exact fraction of atoms will be deleted, or that
-the same atoms will be deleted when running on different numbers of
-processors.
+For style *porosity* a specified *fraction* of atoms are deleted
+within the specified region.  For example, if fraction is 0.1, then
+10% of the atoms will be deleted.  The atoms to delete are chosen
+randomly.  There is no guarantee that the exact fraction of atoms will
+be deleted, or that the same atoms will be deleted when running on
+different numbers of processors.
 
 If the *compress* keyword is set to *yes*, then after atoms are
 deleted, then atom IDs are re-assigned so that they run from 1 to the
@@ -97,8 +89,8 @@ number of atoms in the system.  Note that this is not done for
 molecular systems (see the :doc:`atom_style <atom_style>` command),
 regardless of the *compress* setting, since it would foul up the bond
 connectivity that has already been assigned.  However, the
-:doc:`reset_atom_ids <reset_atom_ids>` command can be used after this
-command to accomplish the same thing.
+:doc:`reset_atom_ids <reset_atom_ids>` command can be used after this command to
+accomplish the same thing.
 
 Note that the re-assignment of IDs is not really a compression, where
 gaps in atom IDs are removed by decrementing atom IDs that are larger.
@@ -108,15 +100,15 @@ the :doc:`create_atoms <create_atoms>` command explains.
 
 A molecular system with fixed bonds, angles, dihedrals, or improper
 interactions, is one where the topology of the interactions is
-typically defined in the data file read by the :doc:`read_data
-<read_data>` command, and where the interactions themselves are
-defined with the :doc:`bond_style <bond_style>`, :doc:`angle_style
-<angle_style>`, etc commands.  If you delete atoms from such a system,
-you must be careful not to end up with bonded interactions that are
-stored by remaining atoms but which include deleted atoms.  This will
-cause LAMMPS to generate a "missing atoms" error when the bonded
-interaction is computed.  The *bond* and *mol* keywords offer two ways
-to do that.
+typically defined in the data file read by the
+:doc:`read_data <read_data>` command, and where the interactions
+themselves are defined with the :doc:`bond_style <bond_style>`,
+:doc:`angle_style <angle_style>`, etc commands.  If you delete atoms
+from such a system, you must be careful not to end up with bonded
+interactions that are stored by remaining atoms but which include
+deleted atoms.  This will cause LAMMPS to generate a "missing atoms"
+error when the bonded interaction is computed.  The *bond* and *mol*
+keywords offer two ways to do that.
 
 It the *bond* keyword is set to *yes* then any bond or angle or
 dihedral or improper interaction that includes a deleted atom is also

doc/src/dump.rst

@@ -137,7 +137,7 @@ Examples
    dump myDump all atom/gz 100 dump.atom.gz
    dump myDump all atom/zstd 100 dump.atom.zst
    dump 2 subgroup atom 50 dump.run.bin
-   dump 2 subgroup atom/mpiio 50 dump.run.mpiio.bin
+   dump 2 subgroup atom 50 dump.run.mpiio.bin
    dump 4a all custom 100 dump.myforce.* id type x y vx fx
    dump 4b flow custom 100 dump.%.myforce id type c_myF[3] v_ke
    dump 4b flow custom 100 dump.%.myforce id type c_myF[*] v_ke
@@ -169,12 +169,11 @@ or multiple smaller files).
 
 .. note::
 
-   Because periodic boundary conditions are enforced only on timesteps
-   when neighbor lists are rebuilt, the coordinates of an atom written
-   to a dump file may be slightly outside the simulation box.
-   Re-neighbor timesteps will not typically coincide with the
-   timesteps dump snapshots are written.  See the :doc:`dump_modify
-   pbc <dump_modify>` command if you with to force coordinates to be
+   Because periodic boundary conditions are enforced only on
+   timesteps when neighbor lists are rebuilt, the coordinates of an atom
+   written to a dump file may be slightly outside the simulation box.
+   Re-neighbor timesteps will not typically coincide with the timesteps
+   dump snapshots are written.  See the :doc:`dump_modify pbc <dump_modify>` command if you with to force coordinates to be
    strictly inside the simulation box.
 
 .. note::
@@ -190,21 +189,20 @@ or multiple smaller files).
    multiple processors, each of which owns a subset of the atoms.
 
 For the *atom*, *custom*, *cfg*, and *local* styles, sorting is off by
-default.  For the *dcd*, *xtc*, *xyz*, and *molfile* styles, sorting
-by atom ID is on by default. See the :doc:`dump_modify <dump_modify>`
-doc page for details.
+default.  For the *dcd*, *xtc*, *xyz*, and *molfile* styles, sorting by
+atom ID is on by default. See the :doc:`dump_modify <dump_modify>` doc
+page for details.
 
-The *atom/gz*, *cfg/gz*, *custom/gz*, *local/gz*, and *xyz/gz* styles
-are identical in command syntax to the corresponding styles without
-"gz", however, they generate compressed files using the zlib
-library. Thus the filename suffix ".gz" is mandatory. This is an
-alternative approach to writing compressed files via a pipe, as done
-by the regular dump styles, which may be required on clusters where
-the interface to the high-speed network disallows using the fork()
-library call (which is needed for a pipe).  For the remainder of this
-doc page, you should thus consider the *atom* and *atom/gz* styles
-(etc) to be inter-changeable, with the exception of the required
-filename suffix.
+The *atom/gz*, *cfg/gz*, *custom/gz*, *local/gz*, and *xyz/gz* styles are identical
+in command syntax to the corresponding styles without "gz", however,
+they generate compressed files using the zlib library. Thus the filename
+suffix ".gz" is mandatory. This is an alternative approach to writing
+compressed files via a pipe, as done by the regular dump styles, which
+may be required on clusters where the interface to the high-speed network
+disallows using the fork() library call (which is needed for a pipe).
+For the remainder of this doc page, you should thus consider the *atom*
+and *atom/gz* styles (etc) to be inter-changeable, with the exception
+of the required filename suffix.
 
 Similarly, the *atom/zstd*, *cfg/zstd*, *custom/zstd*, *local/zstd*,
 and *xyz/zstd* styles are identical to the gz styles, but use the Zstd
@@ -221,11 +219,6 @@ you should thus consider the *atom* and *atom/mpiio* styles (etc) to
 be inter-changeable.  The one exception is how the filename is
 specified for the MPI-IO styles, as explained below.
 
-.. warning::
-
-   The MPIIO package is currently unmaintained and has become
-   unreliable. Use with caution.
-
 The precision of values output to text-based dump files can be
 controlled by the :doc:`dump_modify format <dump_modify>` command and
 its options.
@@ -282,11 +275,10 @@ This bounding box is convenient for many visualization programs.  The
 meaning of the 6 character flags for "xx yy zz" is the same as above.
 
 Note that the first two numbers on each line are now xlo_bound instead
-of xlo, etc, since they represent a bounding box.  See the :doc:`Howto
-triclinic <Howto_triclinic>` page for a geometric description of
-triclinic boxes, as defined by LAMMPS, simple formulas for how the 6
-bounding box extents (xlo_bound,xhi_bound,etc) are calculated from the
-triclinic parameters, and how to transform those parameters to and
+of xlo, etc, since they represent a bounding box.  See the :doc:`Howto triclinic <Howto_triclinic>` page for a geometric description
+of triclinic boxes, as defined by LAMMPS, simple formulas for how the
+6 bounding box extents (xlo_bound,xhi_bound,etc) are calculated from
+the triclinic parameters, and how to transform those parameters to and
 from other commonly used triclinic representations.
 
 The "ITEM: ATOMS" line in each snapshot lists column descriptors for
@@ -318,24 +310,23 @@ written to the dump file.  This local data is typically calculated by
 each processor based on the atoms it owns, but there may be zero or
 more entities per atom, e.g. a list of bond distances.  An explanation
 of the possible dump local attributes is given below.  Note that by
-using input from the :doc:`compute property/local
-<compute_property_local>` command with dump local, it is possible to
-generate information on bonds, angles, etc that can be cut and pasted
-directly into a data file read by the :doc:`read_data <read_data>`
-command.
+using input from the :doc:`compute property/local <compute_property_local>` command with dump local,
+it is possible to generate information on bonds, angles, etc that can
+be cut and pasted directly into a data file read by the
+:doc:`read_data <read_data>` command.
 
 Style *cfg* has the same command syntax as style *custom* and writes
-extended CFG format files, as used by the `AtomEye
-<http://li.mit.edu/Archive/Graphics/A/>`_ visualization package.
-Since the extended CFG format uses a single snapshot of the system per
-file, a wildcard "\*" must be included in the filename, as discussed
-below.  The list of atom attributes for style *cfg* must begin with
-either "mass type xs ys zs" or "mass type xsu ysu zsu" since these
-quantities are needed to write the CFG files in the appropriate format
-(though the "mass" and "type" fields do not appear explicitly in the
-file).  Any remaining attributes will be stored as "auxiliary
-properties" in the CFG files.  Note that you will typically want to
-use the :doc:`dump_modify element <dump_modify>` command with
+extended CFG format files, as used by the
+`AtomEye <http://li.mit.edu/Archive/Graphics/A/>`_ visualization
+package.  Since the extended CFG format uses a single snapshot of the
+system per file, a wildcard "\*" must be included in the filename, as
+discussed below.  The list of atom attributes for style *cfg* must
+begin with either "mass type xs ys zs" or "mass type xsu ysu zsu"
+since these quantities are needed to write the CFG files in the
+appropriate format (though the "mass" and "type" fields do not appear
+explicitly in the file).  Any remaining attributes will be stored as
+"auxiliary properties" in the CFG files.  Note that you will typically
+want to use the :doc:`dump_modify element <dump_modify>` command with
 CFG-formatted files, to associate element names with atom types, so
 that AtomEye can render atoms appropriately. When unwrapped
 coordinates *xsu*, *ysu*, and *zsu* are requested, the nominal AtomEye
@@ -461,11 +452,6 @@ use the :doc:`read_dump <read_dump>` command or perform other
 post-processing, just as if the dump file was not written using
 MPI-IO.
 
-.. warning::
-
-   The MPIIO package is currently unmaintained and has become
-   unreliable. Use with caution.
-
 Note that MPI-IO dump files are one large file which all processors
 write to.  You thus cannot use the "%" wildcard character described
 above in the filename since that specifies generation of multiple
@@ -722,9 +708,8 @@ are part of the MPIIO package.  They are only enabled if LAMMPS was
 built with that package.  See the :doc:`Build package <Build_package>`
 doc page for more info.
 
-The *xtc* and *dcd* styles are part of the EXTRA-DUMP package.  They
-are only enabled if LAMMPS was built with that package.  See the
-:doc:`Build package <Build_package>` page for more info.
+The *xtc* style 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.
 
 Related commands
 """"""""""""""""

doc/src/dump_image.rst

@@ -6,8 +6,6 @@ dump image command
 dump movie command
 ==================
 
-(see below for :ref:`dump_modify options <dump_modify_image>` specific to dump image/movie)
-
 Syntax
 """"""
 
@@ -17,7 +15,7 @@ Syntax
 
 * ID = user-assigned name for the dump
 * group-ID = ID of the group of atoms to be imaged
-* style = *image* or *movie* = style of dump command (other styles such as *atom* or *cfg* or *dcd* or *xtc* or *xyz* or *local* or *custom* are discussed on the :doc:`dump <dump>` doc page)
+* style = *image* or *movie* = style of dump command (other styles *atom* or *cfg* or *dcd* or *xtc* or *xyz* or *local* or *custom* are discussed on the :doc:`dump <dump>` doc page)
 * N = dump every this many timesteps
 * file = name of file to write image to
 * color = atom attribute that determines color of each atom
@@ -81,69 +79,6 @@ Syntax
          seed = random # seed (positive integer)
          dfactor = strength of shading from 0.0 to 1.0
 
-
-.. _dump_modify_image:
-
-dump_modify options for dump image/movie
-========================================
-
-Syntax
-""""""
-
-.. parsed-literal::
-
-   dump_modify dump-ID keyword values ...
-
-* these keywords apply only to the *image* and *movie* styles and are documented on this page
-* keyword = *acolor* or *adiam* or *amap* or *backcolor* or *bcolor* or *bdiam* or *boxcolor* or *color* or *bitrate* or *framerate*
-* see the :doc:`dump modify <dump_modify>` doc page for more general keywords
-
-  .. parsed-literal::
-
-       *acolor* args = type color
-         type = atom type or range of types (see below)
-         color = name of color or color1/color2/...
-       *adiam* args = type diam
-         type = atom type or range of types (see below)
-         diam = diameter of atoms of that type (distance units)
-       *amap* args = lo hi style delta N entry1 entry2 ... entryN
-         lo = number or *min* = lower bound of range of color map
-         hi = number or *max* = upper bound of range of color map
-         style = 2 letters = "c" or "d" or "s" plus "a" or "f"
-           "c" for continuous
-           "d" for discrete
-           "s" for sequential
-           "a" for absolute
-           "f" for fractional
-         delta = binsize (only used for style "s", otherwise ignored)
-           binsize = range is divided into bins of this width
-         N = # of subsequent entries
-         entry = value color (for continuous style)
-           value = number or *min* or *max* = single value within range
-           color = name of color used for that value
-         entry = lo hi color (for discrete style)
-           lo/hi = number or *min* or *max* = lower/upper bound of subset of range
-           color = name of color used for that subset of values
-         entry = color (for sequential style)
-           color = name of color used for a bin of values
-       *backcolor* arg = color
-         color = name of color for background
-       *bcolor* args = type color
-         type = bond type or range of types (see below)
-         color = name of color or color1/color2/...
-       *bdiam* args = type diam
-         type = bond type or range of types (see below)
-         diam = diameter of bonds of that type (distance units)
-       *boxcolor* arg = color
-         color = name of color for simulation box lines and processor sub-domain lines
-       *color* args = name R G B
-         name = name of color
-         R,G,B = red/green/blue numeric values from 0.0 to 1.0
-       *bitrate* arg = rate
-         rate = target bitrate for movie in kbps
-       *framerate* arg = fps
-         fps = frames per second for movie
-
 Examples
 """"""""
 
@@ -156,8 +91,6 @@ Examples
    dump m1 all movie 1000 movie.avi type type size 640 480
    dump m2 all movie 100 movie.m4v type type zoom 1.8 adiam v_value size 1280 720
 
-   dump_modify 1 amap min max cf 0.0 3 min green 0.5 yellow max blue boxcolor red
-
 Description
 """""""""""
 
@@ -212,10 +145,10 @@ is used.
 Similarly, the format of the resulting movie is chosen with the
 *movie* dump style. This is handled by the underlying FFmpeg converter
 and thus details have to be looked up in the `FFmpeg documentation
-<http://ffmpeg.org/ffmpeg.html>`_.  Typical examples are: .avi, .mpg,
-.m4v, .mp4, .mkv, .flv, .mov, .gif Additional settings of the movie
-compression like bitrate and framerate can be set using the
-dump_modify command as described below.
+<http://ffmpeg.org/ffmpeg.html>`_.
+Typical examples are: .avi, .mpg, .m4v, .mp4, .mkv, .flv, .mov, .gif
+Additional settings of the movie compression like bitrate and
+framerate can be set using the :doc:`dump_modify <dump_modify>` command.
 
 To write out JPEG and PNG format files, you must build LAMMPS with
 support for the corresponding JPEG or PNG library. To convert images
@@ -277,20 +210,19 @@ to colors is as follows:
 * type 6 = cyan
 
 and repeats itself for types > 6.  This mapping can be changed by the
-"dump_modify acolor" command, as described below.
+:doc:`dump_modify acolor <dump_modify>` command.
 
 If *type* is specified for the *diameter* setting then the diameter of
 each atom is determined by its atom type.  By default all types have
-diameter 1.0.  This mapping can be changed by the "dump_modify adiam"
-command, as described below.
+diameter 1.0.  This mapping can be changed by the :doc:`dump_modify adiam <dump_modify>` command.
 
 If *element* is specified for the *color* and/or *diameter* setting,
 then the color and/or diameter of each atom is determined by which
 element it is, which in turn is specified by the element-to-type
-mapping specified by the "dump_modify element" command, as described
-below.  By default every atom type is C (carbon).  Every element has a
-color and diameter associated with it, which is the same as the colors
-and sizes used by the `AtomEye <atomeye_>`_ visualization package.
+mapping specified by the "dump_modify element" command.  By default
+every atom type is C (carbon).  Every element has a color and diameter
+associated with it, which is the same as the colors and sizes used by
+the `AtomEye <atomeye_>`_ visualization package.
 
 .. _atomeye: http://li.mit.edu/Archive/Graphics/A/
 
@@ -300,13 +232,13 @@ settings, they are interpreted in the following way.
 If "vx", for example, is used as the *color* setting, then the color
 of the atom will depend on the x-component of its velocity.  The
 association of a per-atom value with a specific color is determined by
-a "color map", which can be specified via the dump_modify command, as
-described below.  The basic idea is that the atom-attribute will be
-within a range of values, and every value within the range is mapped
-to a specific color.  Depending on how the color map is defined, that
-mapping can take place via interpolation so that a value of -3.2 is
-halfway between "red" and "blue", or discretely so that the value of
--3.2 is "orange".
+a "color map", which can be specified via the
+:doc:`dump_modify <dump_modify>` command.  The basic idea is that the
+atom-attribute will be within a range of values, and every value
+within the range is mapped to a specific color.  Depending on how the
+color map is defined, that mapping can take place via interpolation so
+that a value of -3.2 is halfway between "red" and "blue", or
+discretely so that the value of -3.2 is "orange".
 
 If "vx", for example, is used as the *diameter* setting, then the atom
 will be rendered using the x-component of its velocity as the
@@ -319,10 +251,9 @@ diameter, which can be used as the *diameter* setting.
 
 The various keywords listed above control how the image is rendered.
 As listed below, all of the keywords have defaults, most of which you
-will likely not need to change.  As described below, the dump modify
-command also has options specific to the dump image style,
-particularly for assigning colors to atoms, bonds, and other image
-features.
+will likely not need to change.  The :doc:`dump modify <dump_modify>`
+also has options specific to the dump image style, particularly for
+assigning colors to atoms, bonds, and other image features.
 
 ----------
 
@@ -364,7 +295,7 @@ types to colors is as follows:
 * type 6 = cyan
 
 and repeats itself for bond types > 6.  This mapping can be changed by
-the "dump_modify bcolor" command, as described below.
+the :doc:`dump_modify bcolor <dump_modify>` command.
 
 The bond *width* value can be a numeric value or *atom* or *type* (or
 *none* as indicated above).
@@ -379,8 +310,7 @@ of the 2 atoms in the bond.
 
 If *type* is specified for the *width* value then the diameter of each
 bond is determined by its bond type.  By default all types have
-diameter 0.5.  This mapping can be changed by the "dump_modify bdiam" command,
-as described below.
+diameter 0.5.  This mapping can be changed by the :doc:`dump_modify bdiam <dump_modify>` command.
 
 ----------
 
@@ -400,7 +330,7 @@ mapping of types to colors is as follows:
 * type 6 = cyan
 
 and repeats itself for types > 6.  There is not yet an option to
-change this via the dump_modify command.
+change this via the :doc:`dump_modify <dump_modify>` command.
 
 The line *width* can only be a numeric value, which specifies that all
 lines will be drawn as cylinders with that diameter, e.g. 1.0, which
@@ -427,7 +357,7 @@ default the mapping of types to colors is as follows:
 * type 6 = cyan
 
 and repeats itself for types > 6.  There is not yet an option to
-change this via the dump_modify command.
+change this via the :doc:`dump_modify <dump_modify>` command.
 
 ----------
 
@@ -460,7 +390,7 @@ particle.  By default the mapping of types to colors is as follows:
 * type 6 = cyan
 
 and repeats itself for types > 6.  There is not yet an option to
-change this via the dump_modify command.
+change this via the :doc:`dump_modify <dump_modify>` command.
 
 ----------
 
@@ -484,7 +414,7 @@ the mapping of types to colors is as follows:
 * type 6 = cyan
 
 and repeats itself for types > 6.  There is not yet an option to
-change this via the dump_modify command.
+change this via the :doc:`dump_modify <dump_modify>` command.
 
 ----------
 
@@ -558,8 +488,7 @@ are rendered as thin cylinders in the image.  If *no* is set, then the
 box boundaries are not drawn and the *diam* setting is ignored.  If
 *yes* is set, the 12 edges of the box are drawn, with a diameter that
 is a fraction of the shortest box length in x,y,z (for 3d) or x,y (for
-2d).  The color of the box boundaries can be set with the "dump_modify
-boxcolor" command.
+2d).  The color of the box boundaries can be set with the :doc:`dump_modify boxcolor <dump_modify>` command.
 
 The *axes* keyword determines if and how the coordinate axes are
 rendered as thin cylinders in the image.  If *no* is set, then the
@@ -578,8 +507,7 @@ set (default), then the sub-domain boundaries are not drawn and the
 *diam* setting is ignored.  If *yes* is set, the 12 edges of each
 processor sub-domain are drawn, with a diameter that is a fraction of
 the shortest box length in x,y,z (for 3d) or x,y (for 2d).  The color
-of the sub-domain boundaries can be set with the "dump_modify
-boxcolor" command.
+of the sub-domain boundaries can be set with the :doc:`dump_modify boxcolor <dump_modify>` command.
 
 ----------
 
@@ -679,272 +607,9 @@ Play the movie:
 
 ----------
 
-Dump_modify keywords for dump image and dump movie
-""""""""""""""""""""""""""""""""""""""""""""""""""
-
-The following dump_modify keywords apply only to the dump image and
-dump movie styles.  Any keyword that works with dump image also works
-with dump movie, since the movie is simply a collection of images.
-Some of the keywords only affect the dump movie style.  The
-descriptions give details.
-
-----------
-
-The *acolor* keyword can be used with the dump image command, when its
-atom color setting is *type*, to set the color that atoms of each type
-will be drawn in the image.
-
-The specified *type* should be an integer from 1 to Ntypes = the
-number of atom types.  A wildcard asterisk can be used in place of or
-in conjunction with the *type* argument to specify a range of atom
-types.  This takes the form "\*" or "\*n" or "n\*" or "m\*n".  If N =
-the number of atom types, then an asterisk with no numeric values
-means all types from 1 to N.  A leading asterisk means all types from
-1 to n (inclusive).  A trailing asterisk means all types from n to N
-(inclusive).  A middle asterisk means all types from m to n
-(inclusive).
-
-The specified *color* can be a single color which is any of the 140
-pre-defined colors (see below) or a color name defined by the
-"dump_modify color" command, as described below.  Or it can be two or
-more colors separated by a "/" character, e.g. red/green/blue.  In the
-former case, that color is assigned to all the specified atom types.
-In the latter case, the list of colors are assigned in a round-robin
-fashion to each of the specified atom types.
-
-----------
-
-The *adiam* keyword can be used with the dump image command, when its
-atom diameter setting is *type*, to set the size that atoms of each
-type will be drawn in the image.  The specified *type* should be an
-integer from 1 to Ntypes.  As with the *acolor* keyword, a wildcard
-asterisk can be used as part of the *type* argument to specify a range
-of atom types.  The specified *diam* is the size in whatever distance
-:doc:`units <units>` the input script is using, e.g. Angstroms.
-
-----------
-
-The *amap* keyword can be used with the dump image command, with its
-*atom* keyword, when its atom setting is an atom-attribute, to setup a
-color map.  The color map is used to assign a specific RGB
-(red/green/blue) color value to an individual atom when it is drawn,
-based on the atom's attribute, which is a numeric value, e.g. its
-x-component of velocity if the atom-attribute "vx" was specified.
-
-The basic idea of a color map is that the atom-attribute will be
-within a range of values, and that range is associated with a series
-of colors (e.g. red, blue, green).  An atom's specific value (vx =
--3.2) can then mapped to the series of colors (e.g. halfway between
-red and blue), and a specific color is determined via an interpolation
-procedure.
-
-There are many possible options for the color map, enabled by the
-*amap* keyword.  Here are the details.
-
-The *lo* and *hi* settings determine the range of values allowed for
-the atom attribute.  If numeric values are used for *lo* and/or *hi*,
-then values that are lower/higher than that value are set to the
-value.  I.e. the range is static.  If *lo* is specified as *min* or
-*hi* as *max* then the range is dynamic, and the lower and/or
-upper bound will be calculated each time an image is drawn, based
-on the set of atoms being visualized.
-
-The *style* setting is two letters, such as "ca".  The first letter is
-either "c" for continuous, "d" for discrete, or "s" for sequential.
-The second letter is either "a" for absolute, or "f" for fractional.
-
-A continuous color map is one in which the color changes continuously
-from value to value within the range.  A discrete color map is one in
-which discrete colors are assigned to sub-ranges of values within the
-range.  A sequential color map is one in which discrete colors are
-assigned to a sequence of sub-ranges of values covering the entire
-range.
-
-An absolute color map is one in which the values to which colors are
-assigned are specified explicitly as values within the range.  A
-fractional color map is one in which the values to which colors are
-assigned are specified as a fractional portion of the range.  For
-example if the range is from -10.0 to 10.0, and the color red is to be
-assigned to atoms with a value of 5.0, then for an absolute color map
-the number 5.0 would be used.  But for a fractional map, the number
-0.75 would be used since 5.0 is 3/4 of the way from -10.0 to 10.0.
-
-The *delta* setting must be specified for all styles, but is only used
-for the sequential style; otherwise the value is ignored.  It
-specifies the bin size to use within the range for assigning
-consecutive colors to.  For example, if the range is from -10.0 to
-10.0 and a *delta* of 1.0 is used, then 20 colors will be assigned to
-the range.  The first will be from -10.0 <= color1 < -9.0, then second
-from -9.0 <= color2 < -8.0, etc.
-
-The *N* setting is how many entries follow.  The format of the entries
-depends on whether the color map style is continuous, discrete or
-sequential.  In all cases the *color* setting can be any of the 140
-pre-defined colors (see below) or a color name defined by the
-dump_modify color option.
-
-For continuous color maps, each entry has a *value* and a *color*\ .
-The *value* is either a number within the range of values or *min* or
-*max*\ .  The *value* of the first entry must be *min* and the *value*
-of the last entry must be *max*\ .  Any entries in between must have
-increasing values.  Note that numeric values can be specified either
-as absolute numbers or as fractions (0.0 to 1.0) of the range,
-depending on the "a" or "f" in the style setting for the color map.
-
-Here is how the entries are used to determine the color of an
-individual atom, given the value X of its atom attribute.  X will fall
-between 2 of the entry values.  The color of the atom is linearly
-interpolated (in each of the RGB values) between the 2 colors
-associated with those entries.  For example, if X = -5.0 and the 2
-surrounding entries are "red" at -10.0 and "blue" at 0.0, then the
-atom's color will be halfway between "red" and "blue", which happens
-to be "purple".
-
-For discrete color maps, each entry has a *lo* and *hi* value and a
-*color*\ .  The *lo* and *hi* settings are either numbers within the
-range of values or *lo* can be *min* or *hi* can be *max*\ .  The *lo*
-and *hi* settings of the last entry must be *min* and *max*\ .  Other
-entries can have any *lo* and *hi* values and the sub-ranges of
-different values can overlap.  Note that numeric *lo* and *hi* values
-can be specified either as absolute numbers or as fractions (0.0 to
-1.0) of the range, depending on the "a" or "f" in the style setting
-for the color map.
-
-Here is how the entries are used to determine the color of an
-individual atom, given the value X of its atom attribute.  The entries
-are scanned from first to last.  The first time that *lo* <= X <=
-*hi*, X is assigned the color associated with that entry.  You can
-think of the last entry as assigning a default color (since it will
-always be matched by X), and the earlier entries as colors that
-override the default.  Also note that no interpolation of a color RGB
-is done.  All atoms will be drawn with one of the colors in the list
-of entries.
-
-For sequential color maps, each entry has only a *color*\ .  Here is how
-the entries are used to determine the color of an individual atom,
-given the value X of its atom attribute.  The range is partitioned
-into N bins of width *binsize*\ .  Thus X will fall in a specific bin
-from 1 to N, say the Mth bin.  If it falls on a boundary between 2
-bins, it is considered to be in the higher of the 2 bins.  Each bin is
-assigned a color from the E entries.  If E < N, then the colors are
-repeated.  For example if 2 entries with colors red and green are
-specified, then the odd numbered bins will be red and the even bins
-green.  The color of the atom is the color of its bin.  Note that the
-sequential color map is really a shorthand way of defining a discrete
-color map without having to specify where all the bin boundaries are.
-
-Here is an example of using a sequential color map to color all the
-atoms in individual molecules with a different color.  See the
-examples/pour/in.pour.2d.molecule input script for an example of how
-this is used.
-
-.. code-block:: LAMMPS
-
-   variable        colors string &
-                   "red green blue yellow white &
-                   purple pink orange lime gray"
-   variable        mol atom mol%10
-   dump            1 all image 250 image.*.jpg v_mol type &
-                   zoom 1.6 adiam 1.5
-   dump_modify     1 pad 5 amap 0 10 sa 1 10 ${colors}
-
-In this case, 10 colors are defined, and molecule IDs are
-mapped to one of the colors, even if there are 1000s of molecules.
-
-----------
-
-The *backcolor* sets the background color of the images.  The color
-name can be any of the 140 pre-defined colors (see below) or a color
-name defined by the dump_modify color option.
-
-----------
-
-The *bcolor* keyword can be used with the dump image command, with its
-*bond* keyword, when its color setting is *type*, to set the color
-that bonds of each type will be drawn in the image.
-
-The specified *type* should be an integer from 1 to Nbondtypes = the
-number of bond types.  A wildcard asterisk can be used in place of or
-in conjunction with the *type* argument to specify a range of bond
-types.  This takes the form "\*" or "\*n" or "n\*" or "m\*n".  If N =
-the number of bond types, then an asterisk with no numeric values
-means all types from 1 to N.  A leading asterisk means all types from
-1 to n (inclusive).  A trailing asterisk means all types from n to N
-(inclusive).  A middle asterisk means all types from m to n
-(inclusive).
-
-The specified *color* can be a single color which is any of the 140
-pre-defined colors (see below) or a color name defined by the
-dump_modify color option.  Or it can be two or more colors separated
-by a "/" character, e.g. red/green/blue.  In the former case, that
-color is assigned to all the specified bond types.  In the latter
-case, the list of colors are assigned in a round-robin fashion to each
-of the specified bond types.
-
-----------
-
-The *bdiam* keyword can be used with the dump image command, with its
-*bond* keyword, when its diam setting is *type*, to set the diameter
-that bonds of each type will be drawn in the image.  The specified
-*type* should be an integer from 1 to Nbondtypes.  As with the
-*bcolor* keyword, a wildcard asterisk can be used as part of the
-*type* argument to specify a range of bond types.  The specified
-*diam* is the size in whatever distance :doc:`units <units>` you are
-using, e.g. Angstroms.
-
-----------
-
-The *bitrate* keyword can be used with the :doc:`dump movie
-<dump_image>` command to define the size of the resulting movie file
-and its quality via setting how many kbits per second are to be used
-for the movie file. Higher bitrates require less compression and will
-result in higher quality movies.  The quality is also determined by
-the compression format and encoder.  The default setting is 2000
-kbit/s, which will result in average quality with older compression
-formats.
-
-.. note::
-
-   Not all movie file formats supported by dump movie allow the
-   bitrate to be set.  If not, the setting is silently ignored.
-
-----------
-
-The *boxcolor* keyword sets the color of the simulation box drawn
-around the atoms in each image as well as the color of processor
-sub-domain boundaries.  See the "dump image box" command for how to
-specify that a box be drawn via the *box* keyword, and the sub-domain
-boundaries via the *subbox* keyword.  The color name can be any of the
-140 pre-defined colors (see below) or a color name defined by the
-dump_modify color option.
-
-----------
-
-The *color* keyword allows definition of a new color name, in addition
-to the 140-predefined colors (see below), and associates 3
-red/green/blue RGB values with that color name.  The color name can
-then be used with any other dump_modify keyword that takes a color
-name as a value.  The RGB values should each be floating point values
-between 0.0 and 1.0 inclusive.
-
-When a color name is converted to RGB values, the user-defined color
-names are searched first, then the 140 pre-defined color names.  This
-means you can also use the *color* keyword to overwrite one of the
-pre-defined color names with new RBG values.
-
-----------
-
-The *framerate* keyword can be used with the :doc:`dump movie
-<dump_image>` command to define the duration of the resulting movie
-file.  Movie files written by the dump *movie* command have a default
-frame rate of 24 frames per second and the images generated will be
-converted at that rate.  Thus a sequence of 1000 dump images will
-result in a movie of about 42 seconds.  To make a movie run longer you
-can either generate images more frequently or lower the frame rate.
-To speed a movie up, you can do the inverse.  Using a frame rate
-higher than 24 is not recommended, as it will result in simply
-dropping the rendered images. It is more efficient to dump images less
-frequently.
+See the :doc:`Modify <Modify>` page for information on how to add
+new compute and fix styles to LAMMPS to calculate per-atom quantities
+which could then be output into dump files.
 
 ----------
 
@@ -999,7 +664,7 @@ Related commands
 Default
 """""""
 
-The defaults for the dump image and dump movie keywords are as follows:
+The defaults for the keywords are as follows:
 
 * adiam = not specified (use diameter setting)
 * atom = yes
@@ -1017,101 +682,3 @@ The defaults for the dump image and dump movie keywords are as follows:
 * subbox no 0.0
 * shiny = 1.0
 * ssao = no
-
-----------
-
-The defaults for the dump_modify keywords specific to dump image and dump movie are as follows:
-
-* acolor = \* red/green/blue/yellow/aqua/cyan
-* adiam = \* 1.0
-* amap = min max cf 0.0 2 min blue max red
-* backcolor = black
-* bcolor = \* red/green/blue/yellow/aqua/cyan
-* bdiam = \* 0.5
-* bitrate = 2000
-* boxcolor = yellow
-* color = 140 color names are pre-defined as listed below
-* framerate = 24
-
-----------
-
-These are the standard 109 element names that LAMMPS pre-defines for
-use with the dump image and dump_modify commands.
-
-* 1-10 = "H", "He", "Li", "Be", "B", "C", "N", "O", "F", "Ne"
-* 11-20 = "Na", "Mg", "Al", "Si", "P", "S", "Cl", "Ar", "K", "Ca"
-* 21-30 = "Sc", "Ti", "V", "Cr", "Mn", "Fe", "Co", "Ni", "Cu", "Zn"
-* 31-40 = "Ga", "Ge", "As", "Se", "Br", "Kr", "Rb", "Sr", "Y", "Zr"
-* 41-50 = "Nb", "Mo", "Tc", "Ru", "Rh", "Pd", "Ag", "Cd", "In", "Sn"
-* 51-60 = "Sb", "Te", "I", "Xe", "Cs", "Ba", "La", "Ce", "Pr", "Nd"
-* 61-70 = "Pm", "Sm", "Eu", "Gd", "Tb", "Dy", "Ho", "Er", "Tm", "Yb"
-* 71-80 = "Lu", "Hf", "Ta", "W", "Re", "Os", "Ir", "Pt", "Au", "Hg"
-* 81-90 = "Tl", "Pb", "Bi", "Po", "At", "Rn", "Fr", "Ra", "Ac", "Th"
-* 91-100 = "Pa", "U", "Np", "Pu", "Am", "Cm", "Bk", "Cf", "Es", "Fm"
-* 101-109 = "Md", "No", "Lr", "Rf", "Db", "Sg", "Bh", "Hs", "Mt"
-
-----------
-
-These are the 140 colors that LAMMPS pre-defines for use with the dump
-image and dump_modify commands.  Additional colors can be defined with
-the dump_modify color command.  The 3 numbers listed for each name are
-the RGB (red/green/blue) values.  Divide each value by 255 to get the
-equivalent 0.0 to 1.0 value.
-
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| aliceblue = 240, 248, 255     | antiquewhite = 250, 235, 215         | aqua = 0, 255, 255              | aquamarine = 127, 255, 212     | azure = 240, 255, 255          |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| beige = 245, 245, 220         | bisque = 255, 228, 196               | black = 0, 0, 0                 | blanchedalmond = 255, 255, 205 | blue = 0, 0, 255               |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| blueviolet = 138, 43, 226     | brown = 165, 42, 42                  | burlywood = 222, 184, 135       | cadetblue = 95, 158, 160       | chartreuse = 127, 255, 0       |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| chocolate = 210, 105, 30      | coral = 255, 127, 80                 | cornflowerblue = 100, 149, 237  | cornsilk = 255, 248, 220       | crimson = 220, 20, 60          |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| cyan = 0, 255, 255            | darkblue = 0, 0, 139                 | darkcyan = 0, 139, 139          | darkgoldenrod = 184, 134, 11   | darkgray = 169, 169, 169       |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| darkgreen = 0, 100, 0         | darkkhaki = 189, 183, 107            | darkmagenta = 139, 0, 139       | darkolivegreen = 85, 107, 47   | darkorange = 255, 140, 0       |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| darkorchid = 153, 50, 204     | darkred = 139, 0, 0                  | darksalmon = 233, 150, 122      | darkseagreen = 143, 188, 143   | darkslateblue = 72, 61, 139    |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| darkslategray = 47, 79, 79    | darkturquoise = 0, 206, 209          | darkviolet = 148, 0, 211        | deeppink = 255, 20, 147        | deepskyblue = 0, 191, 255      |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| dimgray = 105, 105, 105       | dodgerblue = 30, 144, 255            | firebrick = 178, 34, 34         | floralwhite = 255, 250, 240    | forestgreen = 34, 139, 34      |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| fuchsia = 255, 0, 255         | gainsboro = 220, 220, 220            | ghostwhite = 248, 248, 255      | gold = 255, 215, 0             | goldenrod = 218, 165, 32       |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| gray = 128, 128, 128          | green = 0, 128, 0                    | greenyellow = 173, 255, 47      | honeydew = 240, 255, 240       | hotpink = 255, 105, 180        |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| indianred = 205, 92, 92       | indigo = 75, 0, 130                  | ivory = 255, 240, 240           | khaki = 240, 230, 140          | lavender = 230, 230, 250       |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| lavenderblush = 255, 240, 245 | lawngreen = 124, 252, 0              | lemonchiffon = 255, 250, 205    | lightblue = 173, 216, 230      | lightcoral = 240, 128, 128     |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| lightcyan = 224, 255, 255     | lightgoldenrodyellow = 250, 250, 210 | lightgreen = 144, 238, 144      | lightgrey = 211, 211, 211      | lightpink = 255, 182, 193      |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| lightsalmon = 255, 160, 122   | lightseagreen = 32, 178, 170         | lightskyblue = 135, 206, 250    | lightslategray = 119, 136, 153 | lightsteelblue = 176, 196, 222 |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| lightyellow = 255, 255, 224   | lime = 0, 255, 0                     | limegreen = 50, 205, 50         | linen = 250, 240, 230          | magenta = 255, 0, 255          |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| maroon = 128, 0, 0            | mediumaquamarine = 102, 205, 170     | mediumblue = 0, 0, 205          | mediumorchid = 186, 85, 211    | mediumpurple = 147, 112, 219   |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| mediumseagreen = 60, 179, 113 | mediumslateblue = 123, 104, 238      | mediumspringgreen = 0, 250, 154 | mediumturquoise = 72, 209, 204 | mediumvioletred = 199, 21, 133 |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| midnightblue = 25, 25, 112    | mintcream = 245, 255, 250            | mistyrose = 255, 228, 225       | moccasin = 255, 228, 181       | navajowhite = 255, 222, 173    |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| navy = 0, 0, 128              | oldlace = 253, 245, 230              | olive = 128, 128, 0             | olivedrab = 107, 142, 35       | orange = 255, 165, 0           |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| orangered = 255, 69, 0        | orchid = 218, 112, 214               | palegoldenrod = 238, 232, 170   | palegreen = 152, 251, 152      | paleturquoise = 175, 238, 238  |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| palevioletred = 219, 112, 147 | papayawhip = 255, 239, 213           | peachpuff = 255, 239, 213       | peru = 205, 133, 63            | pink = 255, 192, 203           |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| plum = 221, 160, 221          | powderblue = 176, 224, 230           | purple = 128, 0, 128            | red = 255, 0, 0                | rosybrown = 188, 143, 143      |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| royalblue = 65, 105, 225      | saddlebrown = 139, 69, 19            | salmon = 250, 128, 114          | sandybrown = 244, 164, 96      | seagreen = 46, 139, 87         |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| seashell = 255, 245, 238      | sienna = 160, 82, 45                 | silver = 192, 192, 192          | skyblue = 135, 206, 235        | slateblue = 106, 90, 205       |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| slategray = 112, 128, 144     | snow = 255, 250, 250                 | springgreen = 0, 255, 127       | steelblue = 70, 130, 180       | tan = 210, 180, 140            |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| teal = 0, 128, 128            | thistle = 216, 191, 216              | tomato = 253, 99, 71            | turquoise = 64, 224, 208       | violet = 238, 130, 238         |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
-| wheat = 245, 222, 179         | white = 255, 255, 255                | whitesmoke = 245, 245, 245      | yellow = 255, 255, 0           | yellowgreen = 154, 205, 50     |
-+-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+

doc/src/dump_modify.rst

@@ -3,9 +3,6 @@
 dump_modify command
 ===================
 
-:doc:`dump_modify <dump_image>` command for image/movie options
-===============================================================
-
 Syntax
 """"""
 
@@ -15,9 +12,8 @@ Syntax
 
 * dump-ID = ID of dump to modify
 * one or more keyword/value pairs may be appended
-
 * these keywords apply to various dump styles
-* keyword = *append* or *at* or *buffer* or *delay* or *element* or *every* or *every/time* or *fileper* or *first* or *flush* or *format* or *header* or *image* or *label* or *maxfiles* or *nfile* or *pad* or *pbc* or *precision* or *region* or *refresh* or *scale* or *sfactor* or *sort* or *tfactor* or *thermo* or *thresh* or *time* or *units* or *unwrap*
+* keyword = *append* or *at* or *buffer* or *delay* or *element* or *every* or *fileper* or *first* or *flush* or *format* or *image* or *label* or *maxfiles* or *nfile* or *pad* or *pbc* or *precision* or *region* or *refresh* or *scale* or *sfactor* or *sort* or *tfactor* or *thermo* or *thresh* or *time* or *units* or *unwrap*
 
   .. parsed-literal::
 
@@ -32,9 +28,6 @@ Syntax
        *every* arg = N
          N = dump every this many timesteps
          N can be a variable (see below)
-       *every/time* arg = Delta
-         Delta = dump every this interval in simulation time (time units)
-         Delta can be a variable (see below)
        *fileper* arg = Np
          Np = write one file for every this many processors
        *first* arg = *yes* or *no*
@@ -42,9 +35,6 @@ Syntax
        *format* args = *line* string, *int* string, *float* string, M string, or *none*
          string = C-style format string
          M = integer from 1 to N, where N = # of per-atom quantities being output
-       *header* arg = *yes* or *no*
-         *yes* to write the header
-         *no* to not write the header
        *image* arg = *yes* or *no*
        *label* arg = string
          string = character string (e.g. BONDS) to use in header of dump local file
@@ -76,11 +66,56 @@ Syntax
        *unwrap* arg = *yes* or *no*
 
 * these keywords apply only to the *image* and *movie* :doc:`styles <dump_image>`
-* keyword = *acolor* or *adiam* or *amap* or *backcolor* or *bcolor* or *bdiam* or *boxcolor* or *color* or *bitrate* or *framerate*
+* keyword = *acolor* or *adiam* or *amap* or *backcolor* or *bcolor* or *bdiam* or *boxcolor* or *color* or *bitrate* or *framerate* or *header*
 
   .. parsed-literal::
 
-       see the :doc:`dump image <dump_image>` doc page for details
+       *acolor* args = type color
+         type = atom type or range of types (see below)
+         color = name of color or color1/color2/...
+       *adiam* args = type diam
+         type = atom type or range of types (see below)
+         diam = diameter of atoms of that type (distance units)
+       *amap* args = lo hi style delta N entry1 entry2 ... entryN
+         lo = number or *min* = lower bound of range of color map
+         hi = number or *max* = upper bound of range of color map
+         style = 2 letters = "c" or "d" or "s" plus "a" or "f"
+           "c" for continuous
+           "d" for discrete
+           "s" for sequential
+           "a" for absolute
+           "f" for fractional
+         delta = binsize (only used for style "s", otherwise ignored)
+           binsize = range is divided into bins of this width
+         N = # of subsequent entries
+         entry = value color (for continuous style)
+           value = number or *min* or *max* = single value within range
+           color = name of color used for that value
+         entry = lo hi color (for discrete style)
+           lo/hi = number or *min* or *max* = lower/upper bound of subset of range
+           color = name of color used for that subset of values
+         entry = color (for sequential style)
+           color = name of color used for a bin of values
+       *backcolor* arg = color
+         color = name of color for background
+       *bcolor* args = type color
+         type = bond type or range of types (see below)
+         color = name of color or color1/color2/...
+       *bdiam* args = type diam
+         type = bond type or range of types (see below)
+         diam = diameter of bonds of that type (distance units)
+       *boxcolor* arg = color
+         color = name of color for simulation box lines and processor sub-domain lines
+       *color* args = name R G B
+         name = name of color
+         R,G,B = red/green/blue numeric values from 0.0 to 1.0
+       *bitrate* arg = rate
+         rate = target bitrate for movie in kbps
+       *framerate* arg = fps
+         fps = frames per second for movie
+       *header* arg = *yes* or *no*
+         *yes* to write the header
+         *no* to not write the header
 
 * these keywords apply only to the */gz* and */zstd* dump styles
 * keyword = *compression_level*
@@ -91,7 +126,7 @@ Syntax
          level = integer specifying the compression level that should be used (see below for supported levels)
 
 * these keywords apply only to the */zstd* dump styles
-* keyword = *checksum*
+* keyword = *compression_level*
 
   .. parsed-literal::
 
@@ -109,6 +144,7 @@ Examples
    dump_modify xtcdump precision 10000 sfactor 0.1
    dump_modify 1 every 1000 nfile 20
    dump_modify 1 every v_myVar
+   dump_modify 1 amap min max cf 0.0 3 min green 0.5 yellow max blue boxcolor red
 
 Description
 """""""""""
@@ -127,9 +163,8 @@ which allow for use of MPI-IO.
 
 ----------
 
-Unless otherwise noted, the following keywords apply to all the
-various dump styles, including the :doc:`dump image <dump_image>` and
-:doc:`dump movie <dump_image>` styles.
+These keywords apply to various dump styles, including the :doc:`dump image <dump_image>` and :doc:`dump movie <dump_image>` styles.  The
+description gives details.
 
 ----------
 
@@ -200,19 +235,11 @@ will be accepted.
 
 ----------
 
-The *every* keyword can be used with any dump style except the *dcd*
-and *xtc* styles.  It does two things.  It specifies that the interval
-between dump snapshots will be set in timesteps, which is the default
-if the *every* or *every/time* keywords are not used.  See the
-*every/time* keyword for how to specify the interval in simulation
-time, i.e. in time units of the :doc:`units <units>` command.  The
-*every* keyword also sets the interval value, which overrides the dump
-frequency originally specified by the :doc:`dump <dump>` command.
-
-The *every* keyword can be specified in one of two ways.  It can be a
-numeric value in which case it must be > 0.  Or it can be an
-:doc:`equal-style variable <variable>`, which should be specified as
-v_name, where name is the variable name.
+The *every* keyword changes the dump frequency originally specified by
+the :doc:`dump <dump>` command to a new value.  The every keyword can be
+specified in one of two ways.  It can be a numeric value in which case
+it must be > 0.  Or it can be an :doc:`equal-style variable <variable>`,
+which should be specified as v_name, where name is the variable name.
 
 In this case, the variable is evaluated at the beginning of a run to
 determine the next timestep at which a dump snapshot will be written
@@ -221,12 +248,11 @@ determine the next timestep, etc.  Thus the variable should return
 timestep values.  See the stagger() and logfreq() and stride() math
 functions for :doc:`equal-style variables <variable>`, as examples of
 useful functions to use in this context.  Other similar math functions
-could easily be added as options for :doc:`equal-style variables
-<variable>`.  Also see the next() function, which allows use of a
-file-style variable which reads successive values from a file, each
-time the variable is evaluated.  Used with the *every* keyword, if the
-file contains a list of ascending timesteps, you can output snapshots
-whenever you wish.
+could easily be added as options for :doc:`equal-style variables <variable>`.  Also see the next() function, which allows
+use of a file-style variable which reads successive values from a
+file, each time the variable is evaluated.  Used with the *every*
+keyword, if the file contains a list of ascending timesteps, you can
+output snapshots whenever you wish.
 
 Note that when using the variable option with the *every* keyword, you
 need to use the *first* option if you want an initial snapshot written
@@ -267,103 +293,14 @@ in file tmp.times:
 
 ----------
 
-The *every/time* keyword can be used with any dump style except the
-*dcd* and *xtc* styles.  It does two things.  It specifies that the
-interval between dump snapshots will be set in simulation time,
-i.e. in time units of the :doc:`units <units>` command.  This can be
-useful when the timestep size varies during a simulation run, e.g. by
-use of the :doc:`fix dt/reset <fix_dt_reset>` command.  The default is
-to specify the interval in timesteps; see the *every* keyword.  The
-*every/time* command also sets the interval value.
-
-.. note::
-
-   If you wish dump styles *atom*, *custom*, *local*, or *xyz* to
-   include the simulation time as a field in the header portion of
-   each snapshot, you also need to use the dump_modify *time* keyword
-   with a setting of *yes*.  See its documentation below.
-
-Note that since snapshots are output on simulation steps, each
-snapshot will be written on the first timestep whose associated
-simulation time is >= the exact snapshot time value.
-
-As with the *every* option, the *Delta* value can be specified in one
-of two ways.  It can be a numeric value in which case it must be >
-0.0.  Or it can be an :doc:`equal-style variable <variable>`, which
-should be specified as v_name, where name is the variable name.
-
-In this case, the variable is evaluated at the beginning of a run to
-determine the next simulation time at which a dump snapshot will be
-written out.  On that timestep the variable will be evaluated again to
-determine the next simulation time, etc.  Thus the variable should
-return values in time units.  Note the current timestep or simulation
-time can be used in an :doc:`equal-style variables <variable>` since
-they are both thermodynamic keywords.  Also see the next() function,
-which allows use of a file-style variable which reads successive
-values from a file, each time the variable is evaluated.  Used with
-the *every/time* keyword, if the file contains a list of ascending
-simulation times, you can output snapshots whenever you wish.
-
-Note that when using the variable option with the *every/time*
-keyword, you need to use the *first* option if you want an initial
-snapshot written to the dump file.  The *every/time* keyword cannot be
-used with the dump *dcd* style.
-
-For example, the following commands will write snapshots at successive
-simulation times which grow by a factor of 1.5 with each interval.
-The dt value used in the variable is to avoid a zero result when the
-initial simulation time is 0.0.
-
-.. code-block:: LAMMPS
-
-   variable        increase equal 1.5*(time+dt)
-   dump            1 all atom 100 tmp.dump
-   dump_modify     1 every/time v_increase first yes
-
-The following commands would write snapshots at the times listed in
-file tmp.times:
-
-.. code-block:: LAMMPS
-
-   variable        f file tmp.times
-   variable        s equal next(f)
-   dump            1 all atom 100 tmp.dump
-   dump_modify     1 every/time v_s
-
-.. note::
-
-   When using a file-style variable with the *every/time* keyword, the
-   file of timesteps must list a first time that is beyond the time
-   associated with the current timestep (e.g. it cannot be 0.0).  And
-   it must list one or more times beyond the length of the run you
-   perform.  This is because the dump command will generate an error
-   if the next time it reads from the file is not a value greater than
-   the current time.  Thus if you wanted output at times 0,15,100 of a
-   run of length 100 in simulation time, the file should contain the
-   values 15,100,101 and you should also use the dump_modify first
-   command.  Any final value > 100 could be used in place of 101.
-
-----------
-
 The *first* keyword determines whether a dump snapshot is written on
 the very first timestep after the dump command is invoked.  This will
-always occur if the current timestep is a multiple of $N$, the
-frequency specified in the :doc:`dump <dump>` command or
-:doc:`dump_modify every <dump_modify>` command, including timestep 0.
-It will also always occur if the current simulation time is a multiple
-of *Delta*, the time interval specified in the doc:`dump_modify
-every/time <dump_modify>` command.
-
-But if this is not the case, a dump snapshot will only be written if
-the setting of this keyword is *yes*\ .  If it is *no*, which is the
+always occur if the current timestep is a multiple of N, the frequency
+specified in the :doc:`dump <dump>` command, including timestep 0.  But
+if this is not the case, a dump snapshot will only be written if the
+setting of this keyword is *yes*\ .  If it is *no*, which is the
 default, then it will not be written.
 
-Note that if the argument to the :doc:`dump_modify every
-<dump_modify>` doc:`dump_modify every/time <dump_modify>` commands is
-a variable and not a numeric value, then specifying *first yes* is the
-only way to write a dump snapshot on the first timestep after the dump
-command is invoked.
-
 ----------
 
 The *flush* keyword determines whether a flush operation is invoked
@@ -443,13 +380,6 @@ The *fileper* keyword is documented below with the *nfile* keyword.
 
 ----------
 
-The *header* keyword toggles whether the dump file will include a
-header.  Excluding a header will reduce the size of the dump file for
-fixes such as :doc:`fix pair/tracker <fix_pair_tracker>` which do not
-require the information typically written to the header.
-
-----------
-
 The *image* keyword applies only to the dump *atom* style.  If the
 image value is *yes*, 3 flags are appended to each atom's coords which
 are the absolute box image of the atom in each dimension.  For
@@ -662,9 +592,7 @@ The dump *local* style cannot be sorted by atom ID, since there are
 typically multiple lines of output per atom.  Some dump styles, such
 as *dcd* and *xtc*, require sorting by atom ID to format the output
 file correctly.  If multiple processors are writing the dump file, via
-the "%" wildcard in the dump filename and the *nfile* or *fileper*
-keywords are set to non-default values (i.e. the number of dump file
-pieces is not equal to the number of procs), then sorting cannot be
+the "%" wildcard in the dump filename, then sorting cannot be
 performed.
 
 .. note::
@@ -742,20 +670,16 @@ threshold criterion is met.  Otherwise it is not met.
 
 ----------
 
-The *time* keyword only applies to the dump *atom*, *custom*, *local*,
-and *xyz* styles (and their COMPRESS package versions *atom/gz*,
-*custom/gz* and *local/gz*\ ).  For the first 3 styles, if set to
-*yes*, each frame will will contain two extra lines before the "ITEM:
-TIMESTEP" entry:
+The *time* keyword only applies to the dump *atom*, *custom*, and
+*local* styles (and their COMPRESS package versions *atom/gz*,
+*custom/gz* and *local/gz*\ ). If set to *yes*, each frame will will
+contain two extra lines before the "ITEM: TIMESTEP" entry:
 
 .. parsed-literal::
 
    ITEM: TIME
    \<elapsed time\>
 
-For the *xyz* style, the simulation time is included on the same line
-as the timestep value.
-
 This will output the current elapsed simulation time in current
 time units equivalent to the :doc:`thermo keyword <thermo_style>` *time*\ .
 This is to simplify post-processing of trajectories using a variable time
@@ -791,35 +715,305 @@ box size stored with the snapshot.
 
 ----------
 
-The COMPRESS package offers both GZ and Zstd compression variants of
-styles atom, custom, local, cfg, and xyz. When using these styles the
-compression level can be controlled by the :code:`compression_level`
-keyword. File names with these styles have to end in either
-:code:`.gz` or :code:`.zst`.
+These keywords apply only to the :doc:`dump image <dump_image>` and
+:doc:`dump movie <dump_image>` styles.  Any keyword that affects an
+image, also affects a movie, since the movie is simply a collection of
+images.  Some of the keywords only affect the :doc:`dump movie <dump_image>` style.  The descriptions give details.
 
-GZ supports compression levels from -1 (default), 0 (no compression),
-and 1 to
-9. 9 being the best compression. The COMPRESS :code:`/gz` styles use 9
-as default compression level.
+----------
+
+The *acolor* keyword can be used with the :doc:`dump image <dump_image>`
+command, when its atom color setting is *type*, to set the color that
+atoms of each type will be drawn in the image.
+
+The specified *type* should be an integer from 1 to Ntypes = the
+number of atom types.  A wildcard asterisk can be used in place of or
+in conjunction with the *type* argument to specify a range of atom
+types.  This takes the form "\*" or "\*n" or "n\*" or "m\*n".  If N = the
+number of atom types, then an asterisk with no numeric values means
+all types from 1 to N.  A leading asterisk means all types from 1 to n
+(inclusive).  A trailing asterisk means all types from n to N
+(inclusive).  A middle asterisk means all types from m to n
+(inclusive).
+
+The specified *color* can be a single color which is any of the 140
+pre-defined colors (see below) or a color name defined by the
+dump_modify color option.  Or it can be two or more colors separated
+by a "/" character, e.g. red/green/blue.  In the former case, that
+color is assigned to all the specified atom types.  In the latter
+case, the list of colors are assigned in a round-robin fashion to each
+of the specified atom types.
+
+----------
+
+The *adiam* keyword can be used with the :doc:`dump image <dump_image>`
+command, when its atom diameter setting is *type*, to set the size
+that atoms of each type will be drawn in the image.  The specified
+*type* should be an integer from 1 to Ntypes.  As with the *acolor*
+keyword, a wildcard asterisk can be used as part of the *type*
+argument to specify a range of atom types.  The specified *diam* is
+the size in whatever distance :doc:`units <units>` the input script is
+using, e.g. Angstroms.
+
+----------
+
+The *amap* keyword can be used with the :doc:`dump image <dump_image>`
+command, with its *atom* keyword, when its atom setting is an
+atom-attribute, to setup a color map.  The color map is used to assign
+a specific RGB (red/green/blue) color value to an individual atom when
+it is drawn, based on the atom's attribute, which is a numeric value,
+e.g. its x-component of velocity if the atom-attribute "vx" was
+specified.
+
+The basic idea of a color map is that the atom-attribute will be
+within a range of values, and that range is associated with a series
+of colors (e.g. red, blue, green).  An atom's specific value (vx =
+-3.2) can then mapped to the series of colors (e.g. halfway between
+red and blue), and a specific color is determined via an interpolation
+procedure.
+
+There are many possible options for the color map, enabled by the
+*amap* keyword.  Here are the details.
+
+The *lo* and *hi* settings determine the range of values allowed for
+the atom attribute.  If numeric values are used for *lo* and/or *hi*,
+then values that are lower/higher than that value are set to the
+value.  I.e. the range is static.  If *lo* is specified as *min* or
+*hi* as *max* then the range is dynamic, and the lower and/or
+upper bound will be calculated each time an image is drawn, based
+on the set of atoms being visualized.
+
+The *style* setting is two letters, such as "ca".  The first letter is
+either "c" for continuous, "d" for discrete, or "s" for sequential.
+The second letter is either "a" for absolute, or "f" for fractional.
+
+A continuous color map is one in which the color changes continuously
+from value to value within the range.  A discrete color map is one in
+which discrete colors are assigned to sub-ranges of values within the
+range.  A sequential color map is one in which discrete colors are
+assigned to a sequence of sub-ranges of values covering the entire
+range.
+
+An absolute color map is one in which the values to which colors are
+assigned are specified explicitly as values within the range.  A
+fractional color map is one in which the values to which colors are
+assigned are specified as a fractional portion of the range.  For
+example if the range is from -10.0 to 10.0, and the color red is to be
+assigned to atoms with a value of 5.0, then for an absolute color map
+the number 5.0 would be used.  But for a fractional map, the number
+0.75 would be used since 5.0 is 3/4 of the way from -10.0 to 10.0.
+
+The *delta* setting must be specified for all styles, but is only used
+for the sequential style; otherwise the value is ignored.  It
+specifies the bin size to use within the range for assigning
+consecutive colors to.  For example, if the range is from -10.0 to
+10.0 and a *delta* of 1.0 is used, then 20 colors will be assigned to
+the range.  The first will be from -10.0 <= color1 < -9.0, then second
+from -9.0 <= color2 < -8.0, etc.
+
+The *N* setting is how many entries follow.  The format of the entries
+depends on whether the color map style is continuous, discrete or
+sequential.  In all cases the *color* setting can be any of the 140
+pre-defined colors (see below) or a color name defined by the
+dump_modify color option.
+
+For continuous color maps, each entry has a *value* and a *color*\ .
+The *value* is either a number within the range of values or *min* or
+*max*\ .  The *value* of the first entry must be *min* and the *value*
+of the last entry must be *max*\ .  Any entries in between must have
+increasing values.  Note that numeric values can be specified either
+as absolute numbers or as fractions (0.0 to 1.0) of the range,
+depending on the "a" or "f" in the style setting for the color map.
+
+Here is how the entries are used to determine the color of an
+individual atom, given the value X of its atom attribute.  X will fall
+between 2 of the entry values.  The color of the atom is linearly
+interpolated (in each of the RGB values) between the 2 colors
+associated with those entries.  For example, if X = -5.0 and the 2
+surrounding entries are "red" at -10.0 and "blue" at 0.0, then the
+atom's color will be halfway between "red" and "blue", which happens
+to be "purple".
+
+For discrete color maps, each entry has a *lo* and *hi* value and a
+*color*\ .  The *lo* and *hi* settings are either numbers within the
+range of values or *lo* can be *min* or *hi* can be *max*\ .  The *lo*
+and *hi* settings of the last entry must be *min* and *max*\ .  Other
+entries can have any *lo* and *hi* values and the sub-ranges of
+different values can overlap.  Note that numeric *lo* and *hi* values
+can be specified either as absolute numbers or as fractions (0.0 to
+1.0) of the range, depending on the "a" or "f" in the style setting
+for the color map.
+
+Here is how the entries are used to determine the color of an
+individual atom, given the value X of its atom attribute.  The entries
+are scanned from first to last.  The first time that *lo* <= X <=
+*hi*, X is assigned the color associated with that entry.  You can
+think of the last entry as assigning a default color (since it will
+always be matched by X), and the earlier entries as colors that
+override the default.  Also note that no interpolation of a color RGB
+is done.  All atoms will be drawn with one of the colors in the list
+of entries.
+
+For sequential color maps, each entry has only a *color*\ .  Here is how
+the entries are used to determine the color of an individual atom,
+given the value X of its atom attribute.  The range is partitioned
+into N bins of width *binsize*\ .  Thus X will fall in a specific bin
+from 1 to N, say the Mth bin.  If it falls on a boundary between 2
+bins, it is considered to be in the higher of the 2 bins.  Each bin is
+assigned a color from the E entries.  If E < N, then the colors are
+repeated.  For example if 2 entries with colors red and green are
+specified, then the odd numbered bins will be red and the even bins
+green.  The color of the atom is the color of its bin.  Note that the
+sequential color map is really a shorthand way of defining a discrete
+color map without having to specify where all the bin boundaries are.
+
+Here is an example of using a sequential color map to color all the
+atoms in individual molecules with a different color.  See the
+examples/pour/in.pour.2d.molecule input script for an example of how
+this is used.
+
+.. code-block:: LAMMPS
+
+   variable        colors string &
+                   "red green blue yellow white &
+                   purple pink orange lime gray"
+   variable        mol atom mol%10
+   dump            1 all image 250 image.*.jpg v_mol type &
+                   zoom 1.6 adiam 1.5
+   dump_modify     1 pad 5 amap 0 10 sa 1 10 ${colors}
+
+In this case, 10 colors are defined, and molecule IDs are
+mapped to one of the colors, even if there are 1000s of molecules.
+
+----------
+
+The *backcolor* sets the background color of the images.  The color
+name can be any of the 140 pre-defined colors (see below) or a color
+name defined by the dump_modify color option.
+
+----------
+
+The *bcolor* keyword can be used with the :doc:`dump image <dump_image>`
+command, with its *bond* keyword, when its color setting is *type*, to
+set the color that bonds of each type will be drawn in the image.
+
+The specified *type* should be an integer from 1 to Nbondtypes = the
+number of bond types.  A wildcard asterisk can be used in place of or
+in conjunction with the *type* argument to specify a range of bond
+types.  This takes the form "\*" or "\*n" or "n\*" or "m\*n".  If N = the
+number of bond types, then an asterisk with no numeric values means
+all types from 1 to N.  A leading asterisk means all types from 1 to n
+(inclusive).  A trailing asterisk means all types from n to N
+(inclusive).  A middle asterisk means all types from m to n
+(inclusive).
+
+The specified *color* can be a single color which is any of the 140
+pre-defined colors (see below) or a color name defined by the
+dump_modify color option.  Or it can be two or more colors separated
+by a "/" character, e.g. red/green/blue.  In the former case, that
+color is assigned to all the specified bond types.  In the latter
+case, the list of colors are assigned in a round-robin fashion to each
+of the specified bond types.
+
+----------
+
+The *bdiam* keyword can be used with the :doc:`dump image <dump_image>`
+command, with its *bond* keyword, when its diam setting is *type*, to
+set the diameter that bonds of each type will be drawn in the image.
+The specified *type* should be an integer from 1 to Nbondtypes.  As
+with the *bcolor* keyword, a wildcard asterisk can be used as part of
+the *type* argument to specify a range of bond types.  The specified
+*diam* is the size in whatever distance :doc:`units <units>` you are
+using, e.g. Angstroms.
+
+----------
+
+The *bitrate* keyword can be used with the :doc:`dump movie <dump_image>` command to define the size of the resulting
+movie file and its quality via setting how many kbits per second are
+to be used for the movie file. Higher bitrates require less
+compression and will result in higher quality movies.  The quality is
+also determined by the compression format and encoder.  The default
+setting is 2000 kbit/s, which will result in average quality with
+older compression formats.
+
+.. note::
+
+   Not all movie file formats supported by dump movie allow the
+   bitrate to be set.  If not, the setting is silently ignored.
+
+----------
+
+The *boxcolor* keyword sets the color of the simulation box drawn
+around the atoms in each image as well as the color of processor
+sub-domain boundaries.  See the "dump image box" command for how to
+specify that a box be drawn via the *box* keyword, and the sub-domain
+boundaries via the *subbox* keyword.  The color name can be any of the
+140 pre-defined colors (see below) or a color name defined by the
+dump_modify color option.
+
+----------
+
+The *color* keyword allows definition of a new color name, in addition
+to the 140-predefined colors (see below), and associates 3
+red/green/blue RGB values with that color name.  The color name can
+then be used with any other dump_modify keyword that takes a color
+name as a value.  The RGB values should each be floating point values
+between 0.0 and 1.0 inclusive.
+
+When a color name is converted to RGB values, the user-defined color
+names are searched first, then the 140 pre-defined color names.  This
+means you can also use the *color* keyword to overwrite one of the
+pre-defined color names with new RBG values.
+
+----------
+
+The *framerate* keyword can be used with the :doc:`dump movie <dump_image>` command to define the duration of the resulting
+movie file.  Movie files written by the dump *movie* command have a
+default frame rate of 24 frames per second and the images generated
+will be converted at that rate.  Thus a sequence of 1000 dump images
+will result in a movie of about 42 seconds.  To make a movie run
+longer you can either generate images more frequently or lower the
+frame rate.  To speed a movie up, you can do the inverse.  Using a
+frame rate higher than 24 is not recommended, as it will result in
+simply dropping the rendered images. It is more efficient to dump
+images less frequently.
+
+----------
+
+The *header* keyword toggles whether the dump file will include a header.
+Excluding a header will reduce the size of the dump file for fixes such as
+:doc:`fix pair/tracker <fix_pair_tracker>` which do not require the information
+typically written to the header.
+
+----------
+
+The COMPRESS package offers both GZ and Zstd compression variants of styles
+atom, custom, local, cfg, and xyz. When using these styles the compression
+level can be controlled by the :code:`compression_level` parameter. File names
+with these styles have to end in either :code:`.gz` or :code:`.zst`.
+
+GZ supports compression levels from -1 (default), 0 (no compression), and 1 to
+9. 9 being the best compression. The COMPRESS :code:`/gz` styles use 9 as
+default compression level.
 
 Zstd offers a wider range of compression levels, including negative
-levels that sacrifice compression for performance. 0 is the default,
-positive levels are 1 to 22, with 22 being the most expensive
+levels that sacrifice compression for performance. 0 is the
+default, positive levels are 1 to 22, with 22 being the most expensive
 compression. Zstd promises higher compression/decompression speeds for
 similar compression ratios. For more details see
 `http://facebook.github.io/zstd/`.
 
-In addition, Zstd compressed files can include a checksum of the
-entire contents. The Zstd enabled dump styles enable this feature by
-default and it can be disabled with the :code:`checksum` keyword.
+In addition, Zstd compressed files can have a checksum of the entire
+contents. The Zstd enabled dump styles enable this feature by default and it
+can be disabled with the :code:`checksum` parameter.
 
 ----------
 
 Restrictions
 """"""""""""
 
-Not all *dump_modify* options can be applied to all dump styles.
-Details are in the discussions of the individual options.
+*dump_modify sort* is not supported for dumps of groups containing
+more than 2 billion atoms.
 
 Related commands
 """"""""""""""""
@@ -854,7 +1048,100 @@ The option defaults are
 * units = no
 * unwrap = no
 
+* acolor = \* red/green/blue/yellow/aqua/cyan
+* adiam = \* 1.0
+* amap = min max cf 0.0 2 min blue max red
+* backcolor = black
+* bcolor = \* red/green/blue/yellow/aqua/cyan
+* bdiam = \* 0.5
+* bitrate = 2000
+* boxcolor = yellow
+* color = 140 color names are pre-defined as listed below
+* framerate = 24
+
 * compression_level = 9 (gz variants)
 * compression_level = 0 (zstd variants)
 * checksum = yes (zstd variants)
 
+----------
+
+These are the standard 109 element names that LAMMPS pre-defines for
+use with the :doc:`dump image <dump_image>` and dump_modify commands.
+
+* 1-10 = "H", "He", "Li", "Be", "B", "C", "N", "O", "F", "Ne"
+* 11-20 = "Na", "Mg", "Al", "Si", "P", "S", "Cl", "Ar", "K", "Ca"
+* 21-30 = "Sc", "Ti", "V", "Cr", "Mn", "Fe", "Co", "Ni", "Cu", "Zn"
+* 31-40 = "Ga", "Ge", "As", "Se", "Br", "Kr", "Rb", "Sr", "Y", "Zr"
+* 41-50 = "Nb", "Mo", "Tc", "Ru", "Rh", "Pd", "Ag", "Cd", "In", "Sn"
+* 51-60 = "Sb", "Te", "I", "Xe", "Cs", "Ba", "La", "Ce", "Pr", "Nd"
+* 61-70 = "Pm", "Sm", "Eu", "Gd", "Tb", "Dy", "Ho", "Er", "Tm", "Yb"
+* 71-80 = "Lu", "Hf", "Ta", "W", "Re", "Os", "Ir", "Pt", "Au", "Hg"
+* 81-90 = "Tl", "Pb", "Bi", "Po", "At", "Rn", "Fr", "Ra", "Ac", "Th"
+* 91-100 = "Pa", "U", "Np", "Pu", "Am", "Cm", "Bk", "Cf", "Es", "Fm"
+* 101-109 = "Md", "No", "Lr", "Rf", "Db", "Sg", "Bh", "Hs", "Mt"
+
+----------
+
+These are the 140 colors that LAMMPS pre-defines for use with the
+:doc:`dump image <dump_image>` and dump_modify commands.  Additional
+colors can be defined with the dump_modify color command.  The 3
+numbers listed for each name are the RGB (red/green/blue) values.
+Divide each value by 255 to get the equivalent 0.0 to 1.0 value.
+
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| aliceblue = 240, 248, 255     | antiquewhite = 250, 235, 215         | aqua = 0, 255, 255              | aquamarine = 127, 255, 212     | azure = 240, 255, 255          |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| beige = 245, 245, 220         | bisque = 255, 228, 196               | black = 0, 0, 0                 | blanchedalmond = 255, 255, 205 | blue = 0, 0, 255               |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| blueviolet = 138, 43, 226     | brown = 165, 42, 42                  | burlywood = 222, 184, 135       | cadetblue = 95, 158, 160       | chartreuse = 127, 255, 0       |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| chocolate = 210, 105, 30      | coral = 255, 127, 80                 | cornflowerblue = 100, 149, 237  | cornsilk = 255, 248, 220       | crimson = 220, 20, 60          |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| cyan = 0, 255, 255            | darkblue = 0, 0, 139                 | darkcyan = 0, 139, 139          | darkgoldenrod = 184, 134, 11   | darkgray = 169, 169, 169       |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| darkgreen = 0, 100, 0         | darkkhaki = 189, 183, 107            | darkmagenta = 139, 0, 139       | darkolivegreen = 85, 107, 47   | darkorange = 255, 140, 0       |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| darkorchid = 153, 50, 204     | darkred = 139, 0, 0                  | darksalmon = 233, 150, 122      | darkseagreen = 143, 188, 143   | darkslateblue = 72, 61, 139    |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| darkslategray = 47, 79, 79    | darkturquoise = 0, 206, 209          | darkviolet = 148, 0, 211        | deeppink = 255, 20, 147        | deepskyblue = 0, 191, 255      |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| dimgray = 105, 105, 105       | dodgerblue = 30, 144, 255            | firebrick = 178, 34, 34         | floralwhite = 255, 250, 240    | forestgreen = 34, 139, 34      |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| fuchsia = 255, 0, 255         | gainsboro = 220, 220, 220            | ghostwhite = 248, 248, 255      | gold = 255, 215, 0             | goldenrod = 218, 165, 32       |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| gray = 128, 128, 128          | green = 0, 128, 0                    | greenyellow = 173, 255, 47      | honeydew = 240, 255, 240       | hotpink = 255, 105, 180        |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| indianred = 205, 92, 92       | indigo = 75, 0, 130                  | ivory = 255, 240, 240           | khaki = 240, 230, 140          | lavender = 230, 230, 250       |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| lavenderblush = 255, 240, 245 | lawngreen = 124, 252, 0              | lemonchiffon = 255, 250, 205    | lightblue = 173, 216, 230      | lightcoral = 240, 128, 128     |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| lightcyan = 224, 255, 255     | lightgoldenrodyellow = 250, 250, 210 | lightgreen = 144, 238, 144      | lightgrey = 211, 211, 211      | lightpink = 255, 182, 193      |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| lightsalmon = 255, 160, 122   | lightseagreen = 32, 178, 170         | lightskyblue = 135, 206, 250    | lightslategray = 119, 136, 153 | lightsteelblue = 176, 196, 222 |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| lightyellow = 255, 255, 224   | lime = 0, 255, 0                     | limegreen = 50, 205, 50         | linen = 250, 240, 230          | magenta = 255, 0, 255          |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| maroon = 128, 0, 0            | mediumaquamarine = 102, 205, 170     | mediumblue = 0, 0, 205          | mediumorchid = 186, 85, 211    | mediumpurple = 147, 112, 219   |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| mediumseagreen = 60, 179, 113 | mediumslateblue = 123, 104, 238      | mediumspringgreen = 0, 250, 154 | mediumturquoise = 72, 209, 204 | mediumvioletred = 199, 21, 133 |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| midnightblue = 25, 25, 112    | mintcream = 245, 255, 250            | mistyrose = 255, 228, 225       | moccasin = 255, 228, 181       | navajowhite = 255, 222, 173    |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| navy = 0, 0, 128              | oldlace = 253, 245, 230              | olive = 128, 128, 0             | olivedrab = 107, 142, 35       | orange = 255, 165, 0           |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| orangered = 255, 69, 0        | orchid = 218, 112, 214               | palegoldenrod = 238, 232, 170   | palegreen = 152, 251, 152      | paleturquoise = 175, 238, 238  |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| palevioletred = 219, 112, 147 | papayawhip = 255, 239, 213           | peachpuff = 255, 239, 213       | peru = 205, 133, 63            | pink = 255, 192, 203           |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| plum = 221, 160, 221          | powderblue = 176, 224, 230           | purple = 128, 0, 128            | red = 255, 0, 0                | rosybrown = 188, 143, 143      |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| royalblue = 65, 105, 225      | saddlebrown = 139, 69, 19            | salmon = 250, 128, 114          | sandybrown = 244, 164, 96      | seagreen = 46, 139, 87         |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| seashell = 255, 245, 238      | sienna = 160, 82, 45                 | silver = 192, 192, 192          | skyblue = 135, 206, 235        | slateblue = 106, 90, 205       |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| slategray = 112, 128, 144     | snow = 255, 250, 250                 | springgreen = 0, 255, 127       | steelblue = 70, 130, 180       | tan = 210, 180, 140            |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| teal = 0, 128, 128            | thistle = 216, 191, 216              | tomato = 253, 99, 71            | turquoise = 64, 224, 208       | violet = 238, 130, 238         |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+
+| wheat = 245, 222, 179         | white = 255, 255, 255                | whitesmoke = 245, 245, 245      | yellow = 255, 255, 0           | yellowgreen = 154, 205, 50     |
++-------------------------------+--------------------------------------+---------------------------------+--------------------------------+--------------------------------+

doc/src/fix.rst

@@ -166,7 +166,6 @@ page are followed by one or more of (g,i,k,o,t) to indicate which
 accelerated styles exist.
 
 * :doc:`accelerate/cos <fix_accelerate_cos>` - apply cosine-shaped acceleration to atoms
-* :doc:`acks2/reaxff <fix_acks2_reaxff>` - apply ACKS2 charge equilibration
 * :doc:`adapt <fix_adapt>` - change a simulation parameter over time
 * :doc:`adapt/fep <fix_adapt_fep>` - enhanced version of fix adapt
 * :doc:`addforce <fix_addforce>` - add a force to each atom
@@ -247,7 +246,6 @@ accelerated styles exist.
 * :doc:`manifoldforce <fix_manifoldforce>` - restrain atoms to a manifold during minimization
 * :doc:`mdi/engine <fix_mdi_engine>` - connect LAMMPS to external programs via the MolSSI Driver Interface (MDI)
 * :doc:`meso/move <fix_meso_move>` - move mesoscopic SPH/SDPD particles in a prescribed fashion
-* :doc:`mol/swap <fix_mol_swap>` - Monte Carlo atom type swapping with a molecule
 * :doc:`momentum <fix_momentum>` - zero the linear and/or angular momentum of a group of atoms
 * :doc:`momentum/chunk <fix_momentum>` - zero the linear and/or angular momentum of a chunk of atoms
 * :doc:`move <fix_move>` - move atoms in a prescribed fashion

doc/src/fix_acks2_reaxff.rst

@@ -1,118 +0,0 @@
-.. index:: fix acks2/reaxff
-.. index:: fix acks2/reaxff/kk
-
-fix acks2/reaxff command
-========================
-
-Accelerator Variants: *acks2/reaxff/kk*
-
-Syntax
-""""""
-
-.. parsed-literal::
-
-   fix ID group-ID acks2/reaxff Nevery cutlo cuthi tolerance params args
-
-* ID, group-ID are documented in :doc:`fix <fix>` command
-* acks2/reaxff = style name of this fix command
-* Nevery = perform ACKS2 every this many steps
-* cutlo,cuthi = lo and hi cutoff for Taper radius
-* tolerance = precision to which charges will be equilibrated
-* params = reaxff or a filename
-
-Examples
-""""""""
-
-.. code-block:: LAMMPS
-
-   fix 1 all acks2/reaxff 1 0.0 10.0 1.0e-6 reaxff
-   fix 1 all acks2/reaxff 1 0.0 10.0 1.0e-6 param.acks2
-
-Description
-"""""""""""
-
-Perform the atom-condensed Kohn-Sham DFT to second order (ACKS2) charge
-equilibration method as described in :ref:`(Verstraelen) <Verstraelen>`.
-ACKS2 impedes unphysical long-range charge transfer sometimes seen with
-QEq (e.g. for dissociation of molecules), at increased computational
-cost.  It is typically used in conjunction with the ReaxFF force field
-model as implemented in the :doc:`pair_style reaxff <pair_reaxff>`
-command, but it can be used with any potential in LAMMPS, so long as it
-defines and uses charges on each atom.  For more technical details about
-the charge equilibration performed by fix acks2/reaxff, see the
-:ref:`(O'Hearn) <O'Hearn>` paper.
-
-The ACKS2 method minimizes the electrostatic energy of the system by
-adjusting the partial charge on individual atoms based on interactions
-with their neighbors. It requires some parameters for each atom type.
-If the *params* setting above is the word "reaxff", then these are
-extracted from the :doc:`pair_style reaxff <pair_reaxff>` command and
-the ReaxFF force field file it reads in.  If a file name is specified
-for *params*\ , then the parameters are taken from the specified file
-and the file must contain one line for each atom type.  The latter form
-must be used when performing QeQ with a non-ReaxFF potential.  The lines
-should be formatted as follows:
-
-.. parsed-literal::
-
-   bond_softness
-   itype chi eta gamma bcut
-
-where the first line is the global parameter *bond_softness*. The
-remaining 1 to Ntypes lines include *itype*, the atom type from 1 to
-Ntypes, *chi*, the electronegativity in eV, *eta*, the self-Coulomb
-potential in eV, *gamma*, the valence orbital exponent, and *bcut*, the
-bond cutoff distance.  Note that these 4 quantities are also in the
-ReaxFF potential file, except that eta is defined here as twice the eta
-value in the ReaxFF file. Note that unlike the rest of LAMMPS, the units
-of this fix are hard-coded to be A, eV, and electronic charge.
-
-**Restart, fix_modify, output, run start/stop, minimize info:**
-
-No information about this fix is written to :doc:`binary restart files
-<restart>`.  No global scalar or vector 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 invoked during :doc:`energy minimization <minimize>`.
-
-----------
-
-.. include:: accel_styles.rst
-
-----------
-
-Restrictions
-""""""""""""
-
-This fix is part of the REAXFF package.  It is only enabled if LAMMPS
-was built with that package.  See the :doc:`Build package
-<Build_package>` doc page for more info.
-
-This fix does not correctly handle interactions involving multiple
-periodic images of the same atom. Hence, it should not be used for
-periodic cell dimensions less than 10 angstroms.
-
-This fix may be used in combination with :doc:`fix efield <fix_efield>`
-and will apply the external electric field during charge equilibration,
-but there may be only one fix efield instance used, it may only use a
-constant electric field, and the electric field vector may only have
-components in non-periodic directions.
-
-Related commands
-""""""""""""""""
-
-:doc:`pair_style reaxff <pair_reaxff>`, :doc:`fix qeq/reaxff <fix_qeq_reaxff>`
-
-**Default:** none
-
-----------
-
-.. _O'Hearn:
-
-**(O'Hearn)** O'Hearn, Alperen, Aktulga, SIAM J. Sci. Comput., 42(1), C1-C22 (2020).
-
-.. _Verstraelen:
-
-**(Verstraelen)** Verstraelen, Ayers, Speybroeck, Waroquier, J. Chem. Phys. 138, 074108 (2013).

doc/src/fix_addtorque.rst

@@ -99,7 +99,7 @@ invoked by the :doc:`minimize <minimize>` command.
 Restrictions
 """"""""""""
 
-This fix is part of the EXTRA-FIX package.  It is only enabled if
+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.
 

doc/src/fix_atom_swap.rst

@@ -73,51 +73,51 @@ is the same after the swap as it was before the swap, even though the
 atom masses have changed.
 
 The *semi-grand* keyword can be set to *yes* to switch to the
-semi-grand canonical ensemble as discussed in :ref:`(Sadigh)
-<Sadigh>`. This means that the total number of each particle type does
-not need to be conserved. The default is *no*, which means that the
-only kind of swap allowed exchanges an atom of one type with an atom
-of a different given type. In other words, the relative mole fractions
-of the swapped atoms remains constant. Whereas in the semi-grand
-canonical ensemble, the composition of the system can change. Note
-that when using *semi-grand*, atoms in the fix group whose type is not
-listed in the *types* keyword are ineligible for attempted
-conversion. An attempt is made to switch the selected atom (if
-eligible) to one of the other listed types with equal
-probability. Acceptance of each attempt depends upon the Metropolis
-criterion.
+semi-grand canonical ensemble as discussed in :ref:`(Sadigh) <Sadigh>`. This
+means that the total number of each particle type does not need to be
+conserved. The default is *no*, which means that the only kind of swap
+allowed exchanges an atom of one type with an atom of a different
+given type. In other words, the relative mole fractions of the swapped
+atoms remains constant. Whereas in the semi-grand canonical ensemble,
+the composition of the system can change. Note that when using
+*semi-grand*, atoms in the fix group whose type is not listed
+in the *types* keyword are ineligible for attempted
+conversion. An attempt is made to switch
+the selected atom (if eligible) to one of the other listed types
+with equal probability. Acceptance of each attempt depends upon the Metropolis criterion.
 
-The *mu* keyword allows users to specify chemical potentials. This is
-required and allowed only when using *semi-grand*\ .  All chemical
-potentials are absolute, so there is one for each swap type listed
-following the *types* keyword.  In semi-grand canonical ensemble
-simulations the chemical composition of the system is controlled by
-the difference in these values. So shifting all values by a constant
-amount will have no effect on the simulation.
+The *mu* keyword allows users to specify chemical
+potentials. This is required and allowed only when using *semi-grand*\ .
+All chemical potentials are absolute, so there is one for
+each swap type listed following the *types* keyword.
+In semi-grand canonical ensemble simulations the chemical composition
+of the system is controlled by the difference in these values. So
+shifting all values by a constant amount will have no effect
+on the simulation.
 
 This command may optionally use the *region* keyword to define swap
 volume.  The specified region must have been previously defined with a
-:doc:`region <region>` command.  It must be defined with side = *in*\
-.  Swap attempts occur only between atoms that are both within the
+:doc:`region <region>` command.  It must be defined with side = *in*\ .
+Swap attempts occur only between atoms that are both within the
 specified region. Swaps are not otherwise attempted.
 
 You should ensure you do not swap atoms belonging to a molecule, or
-LAMMPS will eventually generate an error when it tries to find those
-atoms.  LAMMPS will warn you if any of the atoms eligible for swapping
-have a non-zero molecule ID, but does not check for this at the time of
+LAMMPS will soon generate an error when it tries to find those atoms.
+LAMMPS will warn you if any of the atoms eligible for swapping have a
+non-zero molecule ID, but does not check for this at the time of
 swapping.
 
 If not using *semi-grand* this fix checks to ensure all atoms of the
 given types have the same atomic charge. LAMMPS does not enforce this
-in general, but it is needed for this fix to simplify the swapping
-procedure. Successful swaps will swap the atom type and charge of the
-swapped atoms. Conversely, when using *semi-grand*, it is assumed that
-all the atom types involved in switches have the same
-charge. Otherwise, charge would not be conserved. As a consequence, no
-checks on atomic charges are performed, and successful switches update
-the atom type but not the atom charge. While it is possible to use
-*semi-grand* with groups of atoms that have different charges, these
-charges will not be changed when the atom types change.
+in general, but it is needed for this fix to simplify the
+swapping procedure. Successful swaps will swap the atom type and charge
+of the swapped atoms. Conversely, when using *semi-grand*, it is assumed that all the atom
+types involved in switches have the same charge. Otherwise, charge
+would not be conserved. As a consequence, no checks on atomic charges are
+performed, and successful switches update the atom type but not the
+atom charge. While it is possible to use *semi-grand* with groups of
+atoms that have different charges, these charges will not be changed when the
+atom types change.
 
 Since this fix computes total potential energies before and after
 proposed swaps, so even complicated potential energy calculations are
@@ -133,24 +133,23 @@ OK, including the following:
 Some fixes have an associated potential energy. Examples of such fixes
 include: :doc:`efield <fix_efield>`, :doc:`gravity <fix_gravity>`,
 :doc:`addforce <fix_addforce>`, :doc:`langevin <fix_langevin>`,
-:doc:`restrain <fix_restrain>`, :doc:`temp/berendsen
-<fix_temp_berendsen>`, :doc:`temp/rescale <fix_temp_rescale>`, and
-:doc:`wall fixes <fix_wall>`.  For that energy to be included in the
-total potential energy of the system (the quantity used when
-performing GCMC moves), you MUST enable the :doc:`fix_modify
-<fix_modify>` *energy* option for that fix.  The doc pages for
-individual :doc:`fix <fix>` commands specify if this should be done.
+:doc:`restrain <fix_restrain>`, :doc:`temp/berendsen <fix_temp_berendsen>`,
+:doc:`temp/rescale <fix_temp_rescale>`, and :doc:`wall fixes <fix_wall>`.
+For that energy to be included in the total potential energy of the
+system (the quantity used when performing GCMC moves),
+you MUST enable the :doc:`fix_modify <fix_modify>` *energy* option for
+that fix.  The doc pages for individual :doc:`fix <fix>` commands
+specify if this should be done.
 
 Restart, fix_modify, output, run start/stop, minimize info
 """""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 
-This fix writes the state of the fix to :doc:`binary restart files
-<restart>`.  This includes information about the random number
-generator seed, the next timestep for MC exchanges, the number of
-exchange attempts and successes etc.  See the :doc:`read_restart
-<read_restart>` command for info on how to re-specify a fix in an
-input script that reads a restart file, so that the operation of the
-fix continues in an uninterrupted fashion.
+This fix writes the state of the fix to :doc:`binary restart files <restart>`.  This includes information about the random
+number generator seed, the next timestep for MC exchanges, the number
+of exchange attempts and successes etc.  See
+the :doc:`read_restart <read_restart>` command for info on how to
+re-specify a fix in an input script that reads a restart file, so that
+the operation of the fix continues in an uninterrupted fashion.
 
 .. note::
 
@@ -166,13 +165,12 @@ by various :doc:`output commands <Howto_output>`.  The vector values are
 the following global cumulative quantities:
 
 * 1 = swap attempts
-* 2 = swap accepts
+* 2 = swap successes
 
 The vector values calculated by this fix are "extensive".
 
 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>`.
+the :doc:`run <run>` command.  This fix is not invoked during :doc:`energy minimization <minimize>`.
 
 Restrictions
 """"""""""""
@@ -186,8 +184,7 @@ Related commands
 
 :doc:`fix nvt <fix_nh>`, :doc:`neighbor <neighbor>`,
 :doc:`fix deposit <fix_deposit>`, :doc:`fix evaporate <fix_evaporate>`,
-:doc:`delete_atoms <delete_atoms>`, :doc:`fix gcmc <fix_gcmc>`,
-:doc:`fix mol/swap <fix_mol_swap>`
+:doc:`delete_atoms <delete_atoms>`, :doc:`fix gcmc <fix_gcmc>`
 
 Default
 """""""

doc/src/fix_dt_reset.rst

@@ -78,20 +78,13 @@ outer loop (largest) timestep, which is the same timestep that the
 
 Note that the cumulative simulation time (in time units), which
 accounts for changes in the timestep size as a simulation proceeds,
-can be accessed by the :doc:`thermo_style time <thermo_style>`
-keyword.
-
-Also note that the :doc:`dump_modify every/time <dump_modify>` option
-allows dump files to be written at intervals specified by simulation
-time, rather than by timesteps.  Simulation time is in time units;
-see the :doc:`units <units>` doc page for details.
+can be accessed by the :doc:`thermo_style time <thermo_style>` keyword.
 
 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 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.
 
 This fix computes a global scalar which can be accessed by various
 :doc:`output commands <Howto_output>`.  The scalar stores the last
@@ -100,8 +93,7 @@ timestep on which the timestep was reset to a new value.
 The scalar value calculated by this fix is "intensive".
 
 No parameter of this fix can be used with the *start/stop* keywords of
-the :doc:`run <run>` command.  This fix is not invoked during
-:doc:`energy minimization <minimize>`.
+the :doc:`run <run>` command.  This fix is not invoked during :doc:`energy minimization <minimize>`.
 
 Restrictions
 """"""""""""
@@ -110,7 +102,7 @@ Restrictions
 Related commands
 """"""""""""""""
 
-:doc:`timestep <timestep>`, :doc:`dump_modify every/time <dump_modify>`
+:doc:`timestep <timestep>`
 
 Default
 """""""

doc/src/fix_langevin.rst

@@ -138,18 +138,16 @@ temperature with optional time-dependence as well.
 
 Like other fixes that perform thermostatting, this fix can be used
 with :doc:`compute commands <compute>` that remove a "bias" from the
-atom velocities.  E.g. to apply the thermostat only to atoms within a
-spatial :doc:`region <region>`, or to remove the center-of-mass
-velocity from a group of atoms, or to remove the x-component of
-velocity from the calculation.
-
-This is not done by default, but only if the :doc:`fix_modify
-<fix_modify>` command is used to assign a temperature compute to this
-fix that includes such a bias term.  See the doc pages for individual
-:doc:`compute temp commands <compute>` to determine which ones include
-a bias.  In this case, the thermostat works in the following manner:
-bias is removed from each atom, thermostatting is performed on the
-remaining thermal degrees of freedom, and the bias is added back in.
+atom velocities.  E.g. removing the center-of-mass velocity from a
+group of atoms or removing the x-component of velocity from the
+calculation.  This is not done by default, but only if the
+:doc:`fix_modify <fix_modify>` command is used to assign a temperature
+compute to this fix that includes such a bias term.  See the doc pages
+for individual :doc:`compute commands <compute>` to determine which ones
+include a bias.  In this case, the thermostat works in the following
+manner: bias is removed from each atom, thermostatting is performed on
+the remaining thermal degrees of freedom, and the bias is added back
+in.
 
 The *damp* parameter is specified in time units and determines how
 rapidly the temperature is relaxed.  For example, a value of 100.0 means
@@ -185,8 +183,7 @@ omega (which is derived from the angular momentum in the case of
 aspherical particles).
 
 The rotational temperature of the particles can be monitored by the
-:doc:`compute temp/sphere <compute_temp_sphere>` and :doc:`compute
-temp/asphere <compute_temp_asphere>` commands with their rotate
+:doc:`compute temp/sphere <compute_temp_sphere>` and :doc:`compute temp/asphere <compute_temp_asphere>` commands with their rotate
 options.
 
 For the *omega* keyword there is also a scale factor of

doc/src/fix_langevin_drude.rst

@@ -40,7 +40,7 @@ Example input scripts available: examples/PACKAGES/drude
 Description
 """""""""""
 
-Apply two Langevin thermostats as described in :ref:`(Jiang1) <Jiang1>` for
+Apply two Langevin thermostats as described in :ref:`(Jiang) <Jiang1>` for
 thermalizing the reduced degrees of freedom of Drude oscillators.
 This link describes how to use the :doc:`thermalized Drude oscillator model <Howto_drude>` in LAMMPS and polarizable models in LAMMPS
 are discussed on the :doc:`Howto polarizable <Howto_polarizable>` doc
@@ -167,20 +167,17 @@ functions, and include :doc:`thermo_style <thermo_style>` command
 keywords for the simulation box parameters and timestep and elapsed
 time.  Thus it is easy to specify a time-dependent temperature.
 
-Like other fixes that perform thermostatting, this fix can be used
-with :doc:`compute commands <compute>` that remove a "bias" from the
-atom velocities.  E.g. to apply the thermostat only to atoms within a
-spatial :doc:`region <region>`, or to remove the center-of-mass
-velocity from a group of atoms, or to remove the x-component of
-velocity from the calculation.
-
-This is not done by default, but only if the :doc:`fix_modify
-<fix_modify>` command is used to assign a temperature compute to this
-fix that includes such a bias term.  See the doc pages for individual
-:doc:`compute temp commands <compute>` to determine which ones include
-a bias.  In this case, the thermostat works in the following manner:
-bias is removed from each atom, thermostatting is performed on the
-remaining thermal degrees of freedom, and the bias is added back in.
+Like other fixes that perform thermostatting, this fix can be used with
+:doc:`compute commands <compute>` that remove a "bias" from the atom
+velocities.  E.g. removing the center-of-mass velocity from a group of
+atoms.  This is not done by default, but only if the
+:doc:`fix_modify <fix_modify>` command is used to assign a temperature
+compute to this fix that includes such a bias term.  See the doc pages
+for individual :doc:`compute commands <compute>` to determine which ones
+include a bias.  In this case, the thermostat works in the following
+manner: bias is removed from each atom, thermostatting is performed on
+the remaining thermal degrees of freedom, and the bias is added back
+in.  NOTE: this feature has not been tested.
 
 Note: The temperature thermostatting the core-Drude particle pairs
 should be chosen low enough, so as to mimic as closely as possible the
@@ -300,5 +297,5 @@ The option defaults are zero = no.
 
 .. _Jiang1:
 
-**(Jiang1)** Jiang, Hardy, Phillips, MacKerell, Schulten, and Roux, J
+**(Jiang)** Jiang, Hardy, Phillips, MacKerell, Schulten, and Roux, J
 Phys Chem Lett, 2, 87-92 (2011).

doc/src/fix_mol_swap.rst

@@ -1,170 +0,0 @@
-.. index:: fix mol/swap
-
-fix mol/swap command
-=====================
-
-Syntax
-""""""
-
-.. parsed-literal::
-
-   fix ID group-ID mol/swap N X itype jtype seed T keyword value ...
-
-* ID, group-ID are documented in :doc:`fix <fix>` command
-* atom/swap = style name of this fix command
-* N = invoke this fix every N steps
-* X = number of swaps to attempt every N steps
-* itype,jtype = two atom types to swap with each other
-* seed = random # seed (positive integer)
-* T = scaling temperature of the MC swaps (temperature units)
-* zero or more keyword/value pairs may be appended to args
-* keyword = *ke*
-
-  .. parsed-literal::
-
-       *ke* value = *no* or *yes*
-         *no* = no conservation of kinetic energy after atom swaps
-         *yes* = kinetic energy is conserved after atom swaps
-
-Examples
-""""""""
-
-.. code-block:: LAMMPS
-
-   fix 2 all mol/swap 100 1 2 3 29494 300.0 ke no
-   fix mySwap fluid mol/swap 500 10 1 2 482798 1.0
-
-Description
-"""""""""""
-
-This fix performs Monte Carlo swaps of two specified atom types within
-a randomly selected molecule.  Two possible use cases are as follows.
-
-First, consider a mixture of some molecules with atoms of itype and
-other molecules with atoms of jtype.  The fix will select a random
-molecule and attempt to swap all the itype atoms to jtype for the
-first kind of molecule, or all the jtype atoms to itype for the second
-kind.  Because the swap will only take place if it is energetically
-favorable, the fix can be used to determine the miscibility of 2
-different kinds of molecules much more quickly than just dynamics
-would do it.
-
-Second, consider diblock co-polymers with two types of monomers itype
-and jtype.  The fix will select a random molecule and attempt to do a
-itype <--> jtype swap of all those monomers within the molecule.  Thus
-the fix can be used to find the energetically favorable fractions of
-two flavors of diblock co-polymers.
-
-Intra-molecular swaps of atom types are attempted every N timesteps.  On
-that timestep, X swaps are attempted.  For each attempt a single
-molecule ID is randomly selected.  The range of possible molecule IDs
-from loID to hiID is pre-computed before each run begins.  The
-loID/hiID is set for the molecule with the smallest/largest ID which
-has any itype or jtype atoms in it.  Note that if you define a system
-with many molecule IDs between loID and hiID which have no itype or
-jtype atoms, then the fix will be inefficient at performing swaps.
-Also note that if atoms with molecule ID = 0 exist, they are not
-considered molecules by this fix; they are assumed to be solvent atoms
-or molecules.
-
-Candidate atoms for swapping must also be in the fix group.  Atoms
-within the selected molecule which are not itype or jtype are ignored.
-
-When an atom is swapped from itype to jtype (or vice versa), if
-charges are defined, the charge values for itype versus jtype atoms
-are also swapped.  This requires that all itype atoms in the system
-have the same charge value.  Likewise all jtype atoms in the system
-must have the same charge value.  If this is not the case, LAMMPS
-issues a warning that it cannot swap charge values.
-
-If the *ke* keyword is set to yes, which is the default, and the
-masses of itype and jtype atoms are different, then when a swap
-occurs, the velocity of the swapped atom is rescaled by the sqrt of
-the mass ratio, so as to conserve the kinetic energy of the atom.
-
-----------
-
-The potential energy of the entire system is computed before and after
-each swap is performed within a single molecule.  The specified
-temperature T is used in the Metropolis criterion to accept or reject
-the attempted swap.  If the swap is rejected all swapped values are
-reversed.
-
-The potential energy calculations can include systems and models with
-the following features:
-
-* manybody pair styles, including EAM
-* hybrid pair styles
-* long-range electrostatics (kspace)
-* triclinic systems
-* potential energy contributions from other fixes
-
-For the last bullet point, fixes can have an associated potential
-energy. Examples of such fixes include: :doc:`efield <fix_efield>`,
-:doc:`gravity <fix_gravity>`, :doc:`addforce <fix_addforce>`,
-:doc:`langevin <fix_langevin>`, :doc:`restrain <fix_restrain>`,
-:doc:`temp/berendsen <fix_temp_berendsen>`, :doc:`temp/rescale
-<fix_temp_rescale>`, and :doc:`wall fixes <fix_wall>`.  For that
-energy to be included in the total potential energy of the system (the
-quantity used for the swap accept/reject decision), you MUST enable
-the :doc:`fix_modify <fix_modify>` *energy* option for that fix.  The
-doc pages for individual :doc:`fix <fix>` commands specify if this
-should be done.
-
-.. note::
-
-  One comment on computational efficiency.  If the cutoff lengths
-  defined for the pair style are different for itype versus jtype
-  atoms (for any of their interactions with any other atom type), then
-  a new neighbor list needs to be generated for every attempted swap.
-  This is potentially expensive if N is small or X is large.
-
-Restart, fix_modify, output, run start/stop, minimize info
-"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
-
-This fix writes the state of the fix to :doc:`binary restart files
-<restart>`.  This includes information about the random number
-generator seed, the next timestep for MC exchanges, the number of
-exchange attempts and successes etc.  See the :doc:`read_restart
-<read_restart>` command for info on how to re-specify a fix in an
-input script that reads a restart file, so that the operation of the
-fix continues in an uninterrupted fashion.
-
-.. note::
-
-   For this to work correctly, the timestep must **not** be changed
-   after reading the restart with :doc:`reset_timestep <reset_timestep>`.
-   The fix will try to detect it and stop with an error.
-
-None of the :doc:`fix_modify <fix_modify>` options are relevant to this
-fix.
-
-This fix computes a global vector of length 2, which can be accessed
-by various :doc:`output commands <Howto_output>`.  The vector values are
-the following global cumulative quantities:
-
-* 1 = swap attempts
-* 2 = swap accepts
-
-The vector values calculated by this fix are "extensive".
-
-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
-""""""""""""
-
-This fix is part of the MC package.  It is only enabled if LAMMPS was
-built with that package.  See the :doc:`Build package <Build_package>`
-doc page for more info.
-
-Related commands
-""""""""""""""""
-
-:doc:`fix atom/swap <fix_atom_swap>`, :doc:`fix gcmc <fix_gcmc>`
-
-Default
-"""""""
-
-The option default is ke = yes.

doc/src/fix_nh.rst

@@ -486,20 +486,19 @@ temperature or pressure during thermodynamic output via the
 compute-ID.  It also means that changing attributes of *thermo_temp*
 or *thermo_press* will have no effect on this fix.
 
-Like other fixes that perform thermostatting, this fix can be used
-with :doc:`compute commands <compute>` that remove a "bias" from the
-atom velocities.  E.g. to apply the thermostat only to atoms within a
-spatial :doc:`region <region>`, or to remove the center-of-mass
-velocity from a group of atoms, or to remove the x-component of
-velocity from the calculation.
-
-This is not done by default, but only if the :doc:`fix_modify
-<fix_modify>` command is used to assign a temperature compute to this
-fix that includes such a bias term.  See the doc pages for individual
-:doc:`compute temp commands <compute>` to determine which ones include
-a bias.  In this case, the thermostat works in the following manner:
-bias is removed from each atom, thermostatting is performed on the
-remaining thermal degrees of freedom, and the bias is added back in.
+Like other fixes that perform thermostatting, fix nvt and fix npt can
+be used with :doc:`compute commands <compute>` that calculate a
+temperature after removing a "bias" from the atom velocities.
+E.g. removing the center-of-mass velocity from a group of atoms or
+only calculating temperature on the x-component of velocity or only
+calculating temperature for atoms in a geometric region.  This is not
+done by default, but only if the :doc:`fix_modify <fix_modify>` command
+is used to assign a temperature compute to this fix that includes such
+a bias term.  See the doc pages for individual :doc:`compute commands <compute>` to determine which ones include a bias.  In
+this case, the thermostat works in the following manner: the current
+temperature is calculated taking the bias into account, bias is
+removed from each atom, thermostatting is performed on the remaining
+thermal degrees of freedom, and the bias is added back in.
 
 ----------
 

doc/src/fix_npt_asphere.rst

@@ -48,9 +48,8 @@ can also have a bias velocity removed from them before thermostatting
 takes place; see the description below.
 
 Additional parameters affecting the thermostat and barostat are
-specified by keywords and values documented with the :doc:`fix npt
-<fix_nh>` command.  See, for example, discussion of the *temp*, *iso*,
-*aniso*, and *dilate* keywords.
+specified by keywords and values documented with the :doc:`fix npt <fix_nh>` command.  See, for example, discussion of the *temp*,
+*iso*, *aniso*, and *dilate* keywords.
 
 The particles in the fix group are the only ones whose velocities and
 positions are updated by the velocity/position update portion of the
@@ -90,19 +89,18 @@ It also means that changing attributes of *thermo_temp* or
 *thermo_press* will have no effect on this fix.
 
 Like other fixes that perform thermostatting, this fix can be used
-with :doc:`compute commands <compute>` that remove a "bias" from the
-atom velocities.  E.g. to apply the thermostat only to atoms within a
-spatial :doc:`region <region>`, or to remove the center-of-mass
-velocity from a group of atoms, or to remove the x-component of
-velocity from the calculation.
-
-This is not done by default, but only if the :doc:`fix_modify
-<fix_modify>` command is used to assign a temperature compute to this
-fix that includes such a bias term.  See the doc pages for individual
-:doc:`compute temp commands <compute>` to determine which ones include
-a bias.  In this case, the thermostat works in the following manner:
-bias is removed from each atom, thermostatting is performed on the
-remaining thermal degrees of freedom, and the bias is added back in.
+with :doc:`compute commands <compute>` that calculate a temperature
+after removing a "bias" from the atom velocities.  E.g. removing the
+center-of-mass velocity from a group of atoms or only calculating
+temperature on the x-component of velocity or only calculating
+temperature for atoms in a geometric region.  This is not done by
+default, but only if the :doc:`fix_modify <fix_modify>` command is used
+to assign a temperature compute to this fix that includes such a bias
+term.  See the doc pages for individual :doc:`compute commands <compute>` to determine which ones include a bias.  In
+this case, the thermostat works in the following manner: the current
+temperature is calculated taking the bias into account, bias is
+removed from each atom, thermostatting is performed on the remaining
+thermal degrees of freedom, and the bias is added back in.
 
 ----------
 

doc/src/fix_npt_body.rst

@@ -87,19 +87,18 @@ It also means that changing attributes of *thermo_temp* or
 *thermo_press* will have no effect on this fix.
 
 Like other fixes that perform thermostatting, this fix can be used
-with :doc:`compute commands <compute>` that remove a "bias" from the
-atom velocities.  E.g. to apply the thermostat only to atoms within a
-spatial :doc:`region <region>`, or to remove the center-of-mass
-velocity from a group of atoms, or to remove the x-component of
-velocity from the calculation.
-
-This is not done by default, but only if the :doc:`fix_modify
-<fix_modify>` command is used to assign a temperature compute to this
-fix that includes such a bias term.  See the doc pages for individual
-:doc:`compute temp commands <compute>` to determine which ones include
-a bias.  In this case, the thermostat works in the following manner:
-bias is removed from each atom, thermostatting is performed on the
-remaining thermal degrees of freedom, and the bias is added back in.
+with :doc:`compute commands <compute>` that calculate a temperature
+after removing a "bias" from the atom velocities.  E.g. removing the
+center-of-mass velocity from a group of atoms or only calculating
+temperature on the x-component of velocity or only calculating
+temperature for atoms in a geometric region.  This is not done by
+default, but only if the :doc:`fix_modify <fix_modify>` command is used
+to assign a temperature compute to this fix that includes such a bias
+term.  See the doc pages for individual :doc:`compute commands <compute>` to determine which ones include a bias.  In
+this case, the thermostat works in the following manner: the current
+temperature is calculated taking the bias into account, bias is
+removed from each atom, thermostatting is performed on the remaining
+thermal degrees of freedom, and the bias is added back in.
 
 ----------
 

doc/src/fix_npt_cauchy.rst

@@ -400,20 +400,19 @@ temperature or pressure during thermodynamic output via the
 compute-ID.  It also means that changing attributes of *thermo_temp*
 or *thermo_press* will have no effect on this fix.
 
-Like other fixes that perform thermostatting, this fix can be used
-with :doc:`compute commands <compute>` that remove a "bias" from the
-atom velocities.  E.g. to apply the thermostat only to atoms within a
-spatial :doc:`region <region>`, or to remove the center-of-mass
-velocity from a group of atoms, or to remove the x-component of
-velocity from the calculation.
-
-This is not done by default, but only if the :doc:`fix_modify
-<fix_modify>` command is used to assign a temperature compute to this
-fix that includes such a bias term.  See the doc pages for individual
-:doc:`compute temp commands <compute>` to determine which ones include
-a bias.  In this case, the thermostat works in the following manner:
-bias is removed from each atom, thermostatting is performed on the
-remaining thermal degrees of freedom, and the bias is added back in.
+Like other fixes that perform thermostatting, fix npt/cauchy can
+be used with :doc:`compute commands <compute>` that calculate a
+temperature after removing a "bias" from the atom velocities.
+E.g. removing the center-of-mass velocity from a group of atoms or
+only calculating temperature on the x-component of velocity or only
+calculating temperature for atoms in a geometric region.  This is not
+done by default, but only if the :doc:`fix_modify <fix_modify>` command
+is used to assign a temperature compute to this fix that includes such
+a bias term.  See the doc pages for individual :doc:`compute commands <compute>` to determine which ones include a bias.  In
+this case, the thermostat works in the following manner: the current
+temperature is calculated taking the bias into account, bias is
+removed from each atom, thermostatting is performed on the remaining
+thermal degrees of freedom, and the bias is added back in.
 
 ----------
 

doc/src/fix_npt_sphere.rst

@@ -103,19 +103,18 @@ appropriate compute-ID.  It also means that changing attributes of
 *thermo_temp* or *thermo_press* will have no effect on this fix.
 
 Like other fixes that perform thermostatting, this fix can be used
-with :doc:`compute commands <compute>` that remove a "bias" from the
-atom velocities.  E.g. to apply the thermostat only to atoms within a
-spatial :doc:`region <region>`, or to remove the center-of-mass
-velocity from a group of atoms, or to remove the x-component of
-velocity from the calculation.
-
-This is not done by default, but only if the :doc:`fix_modify
-<fix_modify>` command is used to assign a temperature compute to this
-fix that includes such a bias term.  See the doc pages for individual
-:doc:`compute temp commands <compute>` to determine which ones include
-a bias.  In this case, the thermostat works in the following manner:
-bias is removed from each atom, thermostatting is performed on the
-remaining thermal degrees of freedom, and the bias is added back in.
+with :doc:`compute commands <compute>` that calculate a temperature
+after removing a "bias" from the atom velocities.  E.g. removing the
+center-of-mass velocity from a group of atoms or only calculating
+temperature on the x-component of velocity or only calculating
+temperature for atoms in a geometric region.  This is not done by
+default, but only if the :doc:`fix_modify <fix_modify>` command is used
+to assign a temperature compute to this fix that includes such a bias
+term.  See the doc pages for individual :doc:`compute commands <compute>` to determine which ones include a bias.  In
+this case, the thermostat works in the following manner: the current
+temperature is calculated taking the bias into account, bias is
+removed from each atom, thermostatting is performed on the remaining
+thermal degrees of freedom, and the bias is added back in.
 
 ----------
 

doc/src/fix_nvt_asphere.rst

@@ -72,19 +72,18 @@ It also means that changing attributes of *thermo_temp* will have no
 effect on this fix.
 
 Like other fixes that perform thermostatting, this fix can be used
-with :doc:`compute commands <compute>` that remove a "bias" from the
-atom velocities.  E.g. to apply the thermostat only to atoms within a
-spatial :doc:`region <region>`, or to remove the center-of-mass
-velocity from a group of atoms, or to remove the x-component of
-velocity from the calculation.
-
-This is not done by default, but only if the :doc:`fix_modify
-<fix_modify>` command is used to assign a temperature compute to this
-fix that includes such a bias term.  See the doc pages for individual
-:doc:`compute temp commands <compute>` to determine which ones include
-a bias.  In this case, the thermostat works in the following manner:
-bias is removed from each atom, thermostatting is performed on the
-remaining thermal degrees of freedom, and the bias is added back in.
+with :doc:`compute commands <compute>` that calculate a temperature
+after removing a "bias" from the atom velocities.  E.g. removing the
+center-of-mass velocity from a group of atoms or only calculating
+temperature on the x-component of velocity or only calculating
+temperature for atoms in a geometric region.  This is not done by
+default, but only if the :doc:`fix_modify <fix_modify>` command is used
+to assign a temperature compute to this fix that includes such a bias
+term.  See the doc pages for individual :doc:`compute commands <compute>` to determine which ones include a bias.  In
+this case, the thermostat works in the following manner: the current
+temperature is calculated taking the bias into account, bias is
+removed from each atom, thermostatting is performed on the remaining
+thermal degrees of freedom, and the bias is added back in.
 
 ----------
 

doc/src/fix_nvt_body.rst

@@ -69,19 +69,18 @@ It also means that changing attributes of *thermo_temp* will have no
 effect on this fix.
 
 Like other fixes that perform thermostatting, this fix can be used
-with :doc:`compute commands <compute>` that remove a "bias" from the
-atom velocities.  E.g. to apply the thermostat only to atoms within a
-spatial :doc:`region <region>`, or to remove the center-of-mass
-velocity from a group of atoms, or to remove the x-component of
-velocity from the calculation.
-
-This is not done by default, but only if the :doc:`fix_modify
-<fix_modify>` command is used to assign a temperature compute to this
-fix that includes such a bias term.  See the doc pages for individual
-:doc:`compute temp commands <compute>` to determine which ones include
-a bias.  In this case, the thermostat works in the following manner:
-bias is removed from each atom, thermostatting is performed on the
-remaining thermal degrees of freedom, and the bias is added back in.
+with :doc:`compute commands <compute>` that calculate a temperature
+after removing a "bias" from the atom velocities.  E.g. removing the
+center-of-mass velocity from a group of atoms or only calculating
+temperature on the x-component of velocity or only calculating
+temperature for atoms in a geometric region.  This is not done by
+default, but only if the :doc:`fix_modify <fix_modify>` command is used
+to assign a temperature compute to this fix that includes such a bias
+term.  See the doc pages for individual :doc:`compute commands <compute>` to determine which ones include a bias.  In
+this case, the thermostat works in the following manner: the current
+temperature is calculated taking the bias into account, bias is
+removed from each atom, thermostatting is performed on the remaining
+thermal degrees of freedom, and the bias is added back in.
 
 ----------
 

doc/src/fix_nvt_sllod.rst

@@ -37,16 +37,15 @@ trajectory consistent with the canonical ensemble.
 
 This thermostat is used for a simulation box that is changing size
 and/or shape, for example in a non-equilibrium MD (NEMD) simulation.
-The size/shape change is induced by use of the :doc:`fix deform
-<fix_deform>` command, so each point in the simulation box can be
-thought of as having a "streaming" velocity.  This position-dependent
-streaming velocity is subtracted from each atom's actual velocity to
-yield a thermal velocity which is used for temperature computation and
-thermostatting.  For example, if the box is being sheared in x,
-relative to y, then points at the bottom of the box (low y) have a
-small x velocity, while points at the top of the box (hi y) have a
-large x velocity.  These velocities do not contribute to the thermal
-"temperature" of the atom.
+The size/shape change is induced by use of the :doc:`fix deform <fix_deform>` command, so each point in the simulation box
+can be thought of as having a "streaming" velocity.  This
+position-dependent streaming velocity is subtracted from each atom's
+actual velocity to yield a thermal velocity which is used for
+temperature computation and thermostatting.  For example, if the box
+is being sheared in x, relative to y, then points at the bottom of the
+box (low y) have a small x velocity, while points at the top of the
+box (hi y) have a large x velocity.  These velocities do not
+contribute to the thermal "temperature" of the atom.
 
 .. note::
 
@@ -61,15 +60,13 @@ large x velocity.  These velocities do not contribute to the thermal
    consistent.
 
 The SLLOD equations of motion, originally proposed by Hoover and Ladd
-(see :ref:`(Evans and Morriss) <Evans3>`), were proven to be
-equivalent to Newton's equations of motion for shear flow by
-:ref:`(Evans and Morriss) <Evans3>`. They were later shown to generate
-the desired velocity gradient and the correct production of work by
-stresses for all forms of homogeneous flow by :ref:`(Daivis and Todd)
-<Daivis>`.  As implemented in LAMMPS, they are coupled to a
-Nose/Hoover chain thermostat in a velocity Verlet formulation, closely
-following the implementation used for the :doc:`fix nvt <fix_nh>`
-command.
+(see :ref:`(Evans and Morriss) <Evans3>`), were proven to be equivalent to
+Newton's equations of motion for shear flow by :ref:`(Evans and Morriss) <Evans3>`. They were later shown to generate the desired
+velocity gradient and the correct production of work by stresses for
+all forms of homogeneous flow by :ref:`(Daivis and Todd) <Daivis>`.  As
+implemented in LAMMPS, they are coupled to a Nose/Hoover chain
+thermostat in a velocity Verlet formulation, closely following the
+implementation used for the :doc:`fix nvt <fix_nh>` command.
 
 .. note::
 
@@ -97,28 +94,27 @@ underscore + "temp", and the group for the new compute is the same as
 the fix group.
 
 Note that this is NOT the compute used by thermodynamic output (see
-the :doc:`thermo_style <thermo_style>` command) with ID =
-*thermo_temp*.  This means you can change the attributes of this fix's
-temperature (e.g. its degrees-of-freedom) via the :doc:`compute_modify
-<compute_modify>` command or print this temperature during
-thermodynamic output via the :doc:`thermo_style custom <thermo_style>`
-command using the appropriate compute-ID.  It also means that changing
-attributes of *thermo_temp* will have no effect on this fix.
+the :doc:`thermo_style <thermo_style>` command) with ID = *thermo_temp*.
+This means you can change the attributes of this fix's temperature
+(e.g. its degrees-of-freedom) via the
+:doc:`compute_modify <compute_modify>` command or print this temperature
+during thermodynamic output via the :doc:`thermo_style custom <thermo_style>` command using the appropriate compute-ID.
+It also means that changing attributes of *thermo_temp* will have no
+effect on this fix.
 
 Like other fixes that perform thermostatting, this fix can be used
-with :doc:`compute commands <compute>` that remove a "bias" from the
-atom velocities.  E.g. to apply the thermostat only to atoms within a
-spatial :doc:`region <region>`, or to remove the center-of-mass
-velocity from a group of atoms, or to remove the x-component of
-velocity from the calculation.
-
-This is not done by default, but only if the :doc:`fix_modify
-<fix_modify>` command is used to assign a temperature compute to this
-fix that includes such a bias term.  See the doc pages for individual
-:doc:`compute temp commands <compute>` to determine which ones include
-a bias.  In this case, the thermostat works in the following manner:
-bias is removed from each atom, thermostatting is performed on the
-remaining thermal degrees of freedom, and the bias is added back in.
+with :doc:`compute commands <compute>` that calculate a temperature
+after removing a "bias" from the atom velocities.  E.g. removing the
+center-of-mass velocity from a group of atoms or only calculating
+temperature on the x-component of velocity or only calculating
+temperature for atoms in a geometric region.  This is not done by
+default, but only if the :doc:`fix_modify <fix_modify>` command is used
+to assign a temperature compute to this fix that includes such a bias
+term.  See the doc pages for individual :doc:`compute commands <compute>` to determine which ones include a bias.  In
+this case, the thermostat works in the following manner: the current
+temperature is calculated taking the bias into account, bias is
+removed from each atom, thermostatting is performed on the remaining
+thermal degrees of freedom, and the bias is added back in.
 
 ----------
 

doc/src/fix_nvt_sphere.rst

@@ -86,19 +86,18 @@ It also means that changing attributes of *thermo_temp* will have no
 effect on this fix.
 
 Like other fixes that perform thermostatting, this fix can be used
-with :doc:`compute commands <compute>` that remove a "bias" from the
-atom velocities.  E.g. to apply the thermostat only to atoms within a
-spatial :doc:`region <region>`, or to remove the center-of-mass
-velocity from a group of atoms, or to remove the x-component of
-velocity from the calculation.
-
-This is not done by default, but only if the :doc:`fix_modify
-<fix_modify>` command is used to assign a temperature compute to this
-fix that includes such a bias term.  See the doc pages for individual
-:doc:`compute temp commands <compute>` to determine which ones include
-a bias.  In this case, the thermostat works in the following manner:
-bias is removed from each atom, thermostatting is performed on the
-remaining thermal degrees of freedom, and the bias is added back in.
+with :doc:`compute commands <compute>` that calculate a temperature
+after removing a "bias" from the atom velocities.  E.g. removing the
+center-of-mass velocity from a group of atoms or only calculating
+temperature on the x-component of velocity or only calculating
+temperature for atoms in a geometric region.  This is not done by
+default, but only if the :doc:`fix_modify <fix_modify>` command is used
+to assign a temperature compute to this fix that includes such a bias
+term.  See the doc pages for individual :doc:`compute commands <compute>` to determine which ones include a bias.  In
+this case, the thermostat works in the following manner: the current
+temperature is calculated taking the bias into account, bias is
+removed from each atom, thermostatting is performed on the remaining
+thermal degrees of freedom, and the bias is added back in.
 
 ----------
 

doc/src/fix_oneway.rst

@@ -51,7 +51,7 @@ the :doc:`run <run>` command.  This fix is not invoked during :doc:`energy minim
 Restrictions
 """"""""""""
 
-This fix is part of the EXTRA-FIX package.  It is only enabled if LAMMPS
+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.
 
 Related commands

doc/src/fix_qeq.rst

@@ -230,10 +230,7 @@ These fixes are part of the QEQ package.  They are only enabled if
 LAMMPS was built with that package.  See the :doc:`Build package
 <Build_package>` page for more info.
 
-These qeq fixes are not compatible with the GPU and USER-INTEL packages.
-
-These qeq fixes will ignore electric field contributions from
-:doc:`fix efield <fix_efield>`.
+The qeq fixes are not compatible with the GPU and USER-INTEL packages.
 
 Related commands
 """"""""""""""""

doc/src/fix_qeq_reaxff.rst

@@ -116,12 +116,6 @@ This fix does not correctly handle interactions involving multiple
 periodic images of the same atom.  Hence, it should not be used for
 periodic cell dimensions less than 10 angstroms.
 
-This fix may be used in combination with :doc:`fix efield <fix_efield>`
-and will apply the external electric field during charge equilibration,
-but there may be only one fix efield instance used, it may only use a
-constant electric field, and the electric field vector may only have
-components in non-periodic directions.
-
 Related commands
 """"""""""""""""
 

doc/src/fix_reaxff_species.rst

@@ -56,17 +56,6 @@ number of molecules of each species.  In this context, "species" means
 a unique molecule.  The chemical formula of each species is given in
 the first line.
 
-.. warning::
-
-   In order to compute averaged data, it is required that there are no
-   neighbor list rebuilds between the *Nfreq* steps. For that reason, fix
-   *reaxff/species* may change your neighbor list settings.  There will
-   be a warning message showing the new settings. Having an *Nfreq*
-   setting that is larger than what is required for correct computation
-   of the ReaxFF force field interactions can thus lead to incorrect
-   results.  For typical ReaxFF calculations a value of 100 is already
-   quite large.
-
 If the filename ends with ".gz", the output file is written in gzipped
 format.  A gzipped dump file will be about 3x smaller than the text version,
 but will also take longer to write.

doc/src/fix_saed_vtk.rst

@@ -28,6 +28,7 @@ Syntax
          Nstart = start averaging on this timestep
        *file* arg = filename
          filename = name of file to output time averages to
+       *overwrite* arg = none = overwrite output file with only latest output
 
 Examples
 """"""""
@@ -160,6 +161,10 @@ the *file* keyword and this string is appended with _N.vtk where N is
 an index (0,1,2...) to account for situations with multiple diffraction
 intensity outputs.
 
+The *overwrite* keyword will continuously overwrite the output file
+with the latest output, so that it only contains one timestep worth of
+output.  This option can only be used with the *ave running* setting.
+
 Restart, fix_modify, output, run start/stop, minimize info
 """""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 

doc/src/fix_setforce.rst

@@ -89,13 +89,26 @@ precession vectors instead of the forces.
 
 ----------
 
-.. include:: accel_styles.rst
+Styles with a *gpu*, *intel*, *kk*, *omp*, or *opt* suffix are
+functionally the same as the corresponding style without the suffix.
+They have been optimized to run faster, depending on your available
+hardware, as discussed on the :doc:`Speed packages <Speed_packages>` doc
+page.  The accelerated styles take the same arguments and should
+produce the same results, except for round-off and precision issues.
 
-.. note::
+The region keyword is also supported by Kokkos, but a Kokkos-enabled
+region must be used. See the region :doc:`region <region>` command for
+more information.
 
-  The region keyword is supported by Kokkos, but a Kokkos-enabled
-  region must be used. See the region :doc:`region <region>` command for
-  more information.
+These accelerated styles are part of the r Kokkos package.  They are
+only enabled if LAMMPS was built with that package.  See the :doc:`Build package <Build_package>` page for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the :doc:`-suffix command-line switch <Run_options>` when you invoke LAMMPS, or you can use the
+:doc:`suffix <suffix>` command in your input script.
+
+See the :doc:`Speed packages <Speed_packages>` page for more
+instructions on how to use the accelerated styles effectively.
 
 ----------
 

doc/src/fix_smd.rst

@@ -144,7 +144,7 @@ the :doc:`run <run>` command.  This fix is not invoked during
 Restrictions
 """"""""""""
 
-This fix is part of the EXTRA-FIX package.  It is only enabled if
+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.
 
 Related commands

doc/src/fix_temp_berendsen.rst

@@ -102,19 +102,18 @@ It also means that changing attributes of *thermo_temp* will have no
 effect on this fix.
 
 Like other fixes that perform thermostatting, this fix can be used
-with :doc:`compute commands <compute>` that remove a "bias" from the
-atom velocities.  E.g. to apply the thermostat only to atoms within a
-spatial :doc:`region <region>`, or to remove the center-of-mass
-velocity from a group of atoms, or to remove the x-component of
-velocity from the calculation.
-
-This is not done by default, but only if the :doc:`fix_modify
-<fix_modify>` command is used to assign a temperature compute to this
-fix that includes such a bias term.  See the doc pages for individual
-:doc:`compute temp commands <compute>` to determine which ones include
-a bias.  In this case, the thermostat works in the following manner:
-bias is removed from each atom, thermostatting is performed on the
-remaining thermal degrees of freedom, and the bias is added back in.
+with :doc:`compute commands <compute>` that calculate a temperature
+after removing a "bias" from the atom velocities.  E.g. removing the
+center-of-mass velocity from a group of atoms or only calculating
+temperature on the x-component of velocity or only calculating
+temperature for atoms in a geometric region.  This is not done by
+default, but only if the :doc:`fix_modify <fix_modify>` command is used
+to assign a temperature compute to this fix that includes such a bias
+term.  See the doc pages for individual :doc:`compute commands <compute>` to determine which ones include a bias.  In
+this case, the thermostat works in the following manner: the current
+temperature is calculated taking the bias into account, bias is
+removed from each atom, thermostatting is performed on the remaining
+thermal degrees of freedom, and the bias is added back in.
 
 ----------
 

doc/src/fix_temp_csvr.rst

@@ -110,29 +110,28 @@ during thermodynamic output via the :doc:`thermo_style custom <thermo_style>` co
 It also means that changing attributes of *thermo_temp* will have no
 effect on this fix.
 
-Like other fixes that perform thermostatting, this fix can be used
-with :doc:`compute commands <compute>` that remove a "bias" from the
-atom velocities.  E.g. to apply the thermostat only to atoms within a
-spatial :doc:`region <region>`, or to remove the center-of-mass
-velocity from a group of atoms, or to remove the x-component of
-velocity from the calculation.
-
-This is not done by default, but only if the :doc:`fix_modify
-<fix_modify>` command is used to assign a temperature compute to this
-fix that includes such a bias term.  See the doc pages for individual
-:doc:`compute temp commands <compute>` to determine which ones include
-a bias.  In this case, the thermostat works in the following manner:
-bias is removed from each atom, thermostatting is performed on the
-remaining thermal degrees of freedom, and the bias is added back in.
+Like other fixes that perform thermostatting, these fixes can be used
+with :doc:`compute commands <compute>` that calculate a temperature
+after removing a "bias" from the atom velocities.  E.g. removing the
+center-of-mass velocity from a group of atoms or only calculating
+temperature on the x-component of velocity or only calculating
+temperature for atoms in a geometric region.  This is not done by
+default, but only if the :doc:`fix_modify <fix_modify>` command is used
+to assign a temperature compute to this fix that includes such a bias
+term.  See the doc pages for individual :doc:`compute commands <compute>` to determine which ones include a bias.  In
+this case, the thermostat works in the following manner: the current
+temperature is calculated taking the bias into account, bias is
+removed from each atom, thermostatting is performed on the remaining
+thermal degrees of freedom, and the bias is added back in.
 
 An important feature of these thermostats is that they have an
-associated effective energy that is a constant of motion.  The
-effective energy is the total energy (kinetic + potential) plus the
-accumulated kinetic energy changes due to the thermostat. The latter
-quantity is the global scalar computed by these fixes. This feature is
-useful to check the integration of the equations of motion against
-discretization errors. In other words, the conservation of the
-effective energy can be used to choose an appropriate integration
+associated effective energy that is a constant of motion.
+The effective energy is the total energy (kinetic + potential) plus
+the accumulated kinetic energy changes due to the thermostat. The
+latter quantity is the global scalar computed by these fixes. This
+feature is useful to check the integration of the equations of motion
+against discretization errors. In other words, the conservation of
+the effective energy can be used to choose an appropriate integration
 :doc:`timestep <timestep>`. This is similar to the usual paradigm of
 checking the conservation of the total energy in the microcanonical
 ensemble.

doc/src/fix_temp_rescale.rst

@@ -109,19 +109,19 @@ command using the appropriate compute-ID.  It also means that changing
 attributes of *thermo_temp* will have no effect on this fix.
 
 Like other fixes that perform thermostatting, this fix can be used
-with :doc:`compute commands <compute>` that remove a "bias" from the
-atom velocities.  E.g. to apply the thermostat only to atoms within a
-spatial :doc:`region <region>`, or to remove the center-of-mass
-velocity from a group of atoms, or to remove the x-component of
-velocity from the calculation.
-
-This is not done by default, but only if the :doc:`fix_modify
-<fix_modify>` command is used to assign a temperature compute to this
-fix that includes such a bias term.  See the doc pages for individual
-:doc:`compute temp commands <compute>` to determine which ones include
-a bias.  In this case, the thermostat works in the following manner:
-bias is removed from each atom, thermostatting is performed on the
-remaining thermal degrees of freedom, and the bias is added back in.
+with :doc:`compute commands <compute>` that calculate a temperature
+after removing a "bias" from the atom velocities.  E.g. removing the
+center-of-mass velocity from a group of atoms or only calculating
+temperature on the x-component of velocity or only calculating
+temperature for atoms in a geometric region.  This is not done by
+default, but only if the :doc:`fix_modify <fix_modify>` command is
+used to assign a temperature compute to this fix that includes such a
+bias term.  See the doc pages for individual :doc:`compute commands
+<compute>` to determine which ones include a bias.  In this case, the
+thermostat works in the following manner: the current temperature is
+calculated taking the bias into account, bias is removed from each
+atom, thermostatting is performed on the remaining thermal degrees of
+freedom, and the bias is added back in.
 
 ----------
 

doc/src/fix_tgnh_drude.rst

@@ -187,32 +187,26 @@ barostatting.
 
 ----------
 
-Like other fixes that perform thermostatting, this fix can be used
-with :doc:`compute commands <compute>` that remove a "bias" from the
-atom velocities.  E.g. to apply the thermostat only to atoms within a
-spatial :doc:`region <region>`, or to remove the center-of-mass
-velocity from a group of atoms, or to remove the x-component of
-velocity from the calculation.
-
-This is not done by default, but only if the :doc:`fix_modify
-<fix_modify>` command is used to assign a temperature compute to this
-fix that includes such a bias term.  See the doc pages for individual
-:doc:`compute temp commands <compute>` to determine which ones include
-a bias.  In this case, the thermostat works in the following manner:
-bias is removed from each atom, thermostatting is performed on the
-remaining thermal degrees of freedom, and the bias is added back in.
+Like other fixes that perform thermostatting, these fixes can
+be used with :doc:`compute commands <compute>` that calculate a
+temperature after removing a "bias" from the atom velocities.
+This is not done by default, but only if the :doc:`fix_modify <fix_modify>` command
+is used to assign a temperature compute to this fix that includes such
+a bias term.  See the doc pages for individual :doc:`compute commands <compute>` to determine which ones include a bias.  In
+this case, the thermostat works in the following manner: the current
+temperature is calculated taking the bias into account, bias is
+removed from each atom, thermostatting is performed on the remaining
+thermal DOF, and the bias is added back in.
 
 .. note::
 
-   However, not all temperature compute commands are valid to be used
-   with these fixes.  Precisely, only temperature compute that does
-   not modify the DOF of the group can be used.  E.g. :doc:`compute
-   temp/ramp <compute_temp_ramp>` and :doc:`compute viscosity/cos
-   <compute_viscosity_cos>` compute the kinetic energy after remove a
-   velocity gradient without affecting the DOF of the group, then they
-   can be invoked in this way.  In contrast, :doc:`compute
-   temp/partial <compute_temp_partial>` may remove the DOF at one or
-   more dimensions, therefore it cannot be used with these fixes.
+   However, not all temperature compute commands are valid to be used with these fixes.
+   Precisely, only temperature compute that does not modify the DOF of the group can be used.
+   E.g. :doc:`compute temp/ramp <compute_temp_ramp>` and :doc:`compute viscosity/cos <compute_viscosity_cos>`
+   compute the kinetic energy after remove a velocity gradient without affecting the DOF of the group,
+   then they can be invoked in this way.
+   In contrast, :doc:`compute temp/partial <compute_temp_partial>` may remove the DOF at one or more dimensions,
+   therefore it cannot be used with these fixes.
 
 ----------
 

doc/src/improper_harmonic.rst

@@ -64,7 +64,25 @@ radian\^2.
 
 ----------
 
-.. include:: accel_styles.rst
+Styles with a *gpu*, *intel*, *kk*, *omp*, or *opt* suffix are
+functionally the same as the corresponding style without the suffix.
+They have been optimized to run faster, depending on your available
+hardware, as discussed on the :doc:`Speed packages <Speed_packages>` doc
+page.  The accelerated styles take the same arguments and should
+produce the same results, except for round-off and precision issues.
+
+These accelerated styles are part of the GPU, INTEL, KOKKOS,
+OPENMP and OPT packages, respectively.  They are only enabled if
+LAMMPS was built with those packages.  See the :doc:`Build package
+<Build_package>` page for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the :doc:`-suffix
+command-line switch <Run_options>` when you invoke LAMMPS, or you can
+use the :doc:`suffix <suffix>` command in your input script.
+
+See the :doc:`Speed packages <Speed_packages>` page for more
+instructions on how to use the accelerated styles effectively.
 
 ----------
 

doc/src/kspace_style.rst

@@ -414,26 +414,33 @@ relative RMS error.
 
 ----------
 
-.. include:: accel_styles.rst
+Styles with a *gpu*, *intel*, *kk*, *omp*, or *opt* suffix are
+functionally the same as the corresponding style without the suffix.
+They have been optimized to run faster, depending on your available
+hardware, as discussed on the :doc:`Speed packages <Speed_packages>` doc
+page.  The accelerated styles take the same arguments and should
+produce the same results, except for round-off and precision issues.
 
-.. note::
+More specifically, the *pppm/gpu* style performs charge assignment and
+force interpolation calculations on the GPU.  These processes are
+performed either in single or double precision, depending on whether
+the -DFFT_SINGLE setting was specified in your low-level Makefile, as
+discussed above.  The FFTs themselves are still calculated on the CPU.
+If *pppm/gpu* is used with a GPU-enabled pair style, part of the PPPM
+calculation can be performed concurrently on the GPU while other
+calculations for non-bonded and bonded force calculation are performed
+on the CPU.
 
-  For the GPU package, the *pppm/gpu* style performs charge assignment
-  and force interpolation calculations on the GPU.  These processes
-  are performed either in single or double precision, depending on
-  whether the -DFFT_SINGLE setting was specified in your low-level
-  Makefile, as discussed above.  The FFTs themselves are still
-  calculated on the CPU.  If *pppm/gpu* is used with a GPU-enabled
-  pair style, part of the PPPM calculation can be performed
-  concurrently on the GPU while other calculations for non-bonded and
-  bonded force calculation are performed on the CPU.
+The *pppm/kk* style performs charge assignment and force interpolation
+calculations, along with the FFTs themselves, on the GPU or (optionally) threaded
+on the CPU when using OpenMP and FFTW3.
 
-.. note::
+These accelerated styles are part of the GPU, INTEL, KOKKOS,
+OPENMP, and OPT packages respectively.  They are only enabled if
+LAMMPS was built with those packages.  See the :doc:`Build package <Build_package>` page for more info.
 
-  For the KOKKOS package, the *pppm/kk* style performs charge
-  assignment and force interpolation calculations, along with the FFTs
-  themselves, on the GPU or (optionally) threaded on the CPU when
-  using OpenMP and FFTW3.
+See the :doc:`Speed packages <Speed_packages>` page for more
+instructions on how to use the accelerated styles effectively.
 
 ----------
 

doc/src/package.rst

@@ -166,7 +166,7 @@ intel", or "package omp" command with default settings.
    set, either to default values or to specified settings.  I.e. settings
    from previous invocations do not persist across multiple invocations.
 
-See the :doc:`Accelerator packages <Speed_packages>` page for more details
+See the :doc:`Speed packages <Speed_packages>` page for more details
 about using the various accelerator packages for speeding up LAMMPS
 simulations.
 

doc/src/pair_agni.rst

@@ -67,7 +67,21 @@ and input files are provided in the examples/PACKAGES/agni directory.
 
 ----------
 
-.. include:: accel_styles.rst
+Styles with *omp* suffix is functionally the same as the corresponding
+style without the suffix. They have been optimized to run faster,
+depending on your available hardware, as discussed on the :doc:`Speed packages <Speed_packages>` doc page.  The accelerated style takes
+the same arguments and should produce the same results, except for
+round-off and precision issues.
+
+The accelerated style is part of the OPENMP.  They are only enabled
+if LAMMPS was built with those packages.  See the :doc:`Build package <Build_package>` page for more info.
+
+You can specify the accelerated style explicitly in your input script
+by including their suffix, or you can use the :doc:`-suffix command-line switch <Run_options>` when you invoke LAMMPS, or you can use the
+:doc:`suffix <suffix>` command in your input script.
+
+See the :doc:`Speed packages <Speed_packages>` page for more
+instructions on how to use the accelerated styles effectively.
 
 ----------
 

doc/src/pair_hybrid.rst

@@ -74,17 +74,14 @@ atoms interact with each other via an *eam* potential, the surface atoms
 interact with each other via a *lj/cut* potential, and the metal/surface
 interaction is also computed via a *lj/cut* potential.  The
 *hybrid/overlay* style could be used as in the second example above,
-where multiple potentials are superimposed in an additive fashion to
+where multiple potentials are superposed in an additive fashion to
 compute the interaction between atoms.  In this example, using *lj/cut*
 and *coul/long* together gives the same result as if the
 *lj/cut/coul/long* potential were used by itself.  In this case, it
 would be more efficient to use the single combined potential, but in
 general any combination of pair potentials can be used together in to
 produce an interaction that is not encoded in any single pair_style
-file, e.g. adding Coulombic forces between granular particles.  Another
-limitation of using the *hybrid/overlay* variant, that it does not generate
-*lj/cut* parameters for mixed atom types from a mixing rule due to
-restrictions discussed below.
+file, e.g. adding Coulombic forces between granular particles.
 
 If the *hybrid/scaled* style is used instead of *hybrid/overlay*,
 contributions from sub-styles are weighted by their scale factors, which
@@ -153,14 +150,10 @@ with Tersoff, and the cross-interactions with Lennard-Jones:
    pair_coeff * * tersoff 2 C.tersoff NULL C
    pair_coeff 1 2 lj/cut 1.0 1.5
 
-
-It is not recommended to read pair coefficients for a hybrid style from a "Pair Coeffs"
-or "PairIJ Coeffs" section of a data file via the :doc:`read_data <read_data>` command,
-since those sections expect a fixed number of lines, either one line per atom type or
-one line pair pair of atom types, respectively.  When reading from a data file, the
-lines of the "Pair Coeffs" and "PairIJ Coeffs" are changed in the same way as the *pair_coeff*
-command, i.e. the name of the pair style to which the parameters apply must follow the
-atom type (or atom types), e.g.
+If pair coefficients are specified in the data file read via the
+:doc:`read_data <read_data>` command, then the same rule applies.
+E.g. "eam/alloy" or "lj/cut" must be added after the atom type, for
+each line in the "Pair Coeffs" section, e.g.
 
 .. parsed-literal::
 
@@ -169,11 +162,6 @@ atom type (or atom types), e.g.
    1 lj/cut/coul/cut 1.0 1.0
    ...
 
-   PairIJ Coeffs
-
-   1 1 lj/cut/coul/cut 1.0 1.0
-   ...
-
 Note that the pair_coeff command for some potentials such as
 :doc:`pair_style eam/alloy <pair_eam>` includes a mapping specification
 of elements to all atom types, which in the hybrid case, can include
@@ -220,22 +208,12 @@ examples above, or in the data file read by the :doc:`read_data
 <read_data>`, or by mixing as described below.  Also all sub-styles
 must be used at least once in a :doc:`pair_coeff <pair_coeff>` command.
 
-.. warning::
+.. note::
 
-   With hybrid pair styles the use of mixing to generate pair
-   coefficients is significantly limited compared to the individual pair
-   styles.  LAMMPS **never** performs mixing of parameters from
-   different sub-styles, **even** if they use the same type of
-   coefficients, e.g. contain a Lennard-Jones potential variant.  Those
-   parameters must be provided explicitly.  Also for *hybrid/overlay*
-   and *hybrid/scaled* mixing is **only** performed for pairs of atom
-   types for which only a single pair style is assigned.
-
-   Thus it is strongly recommended to provide all mixed terms
-   explicitly.  For non-hybrid styles those could be generated and
-   written out using the :doc:`write_coeff command <write_coeff>` and
-   then edited as needed to comply with the requirements for hybrid
-   styles as explained above.
+   LAMMPS never performs mixing of parameters from different sub-styles,
+   **even** if they use the same type of coefficients, e.g. contain
+   a Lennard-Jones potential variant.  Those parameters must be provided
+   explicitly.
 
 If you want there to be no interactions between a particular pair of
 atom types, you have 3 choices.  You can assign the pair of atom types
@@ -405,19 +383,30 @@ coefficients to 0.0.
 
 ----------
 
-.. include:: accel_styles.rst
+Styles with a *gpu*, *intel*, *kk*, *omp*, or *opt* suffix are
+functionally the same as the corresponding style without the suffix.
+They have been optimized to run faster, depending on your available
+hardware, as discussed on the :doc:`Speed packages <Speed_packages>` doc
+page.  Pair style *hybrid/scaled* does (currently) not support the
+*gpu*, *omp*, *kk*, or *intel* suffix.
 
-.. note::
+Since the *hybrid*, *hybrid/overlay*, *hybrid/scaled* styles delegate
+computation to the individual sub-styles, the suffix versions of the
+*hybrid* and *hybrid/overlay* styles are used to propagate the
+corresponding suffix to all sub-styles, if those versions
+exist. Otherwise the non-accelerated version will be used.
 
-  Since the *hybrid*, *hybrid/overlay*, *hybrid/scaled* styles
-  delegate computation to the individual sub-styles, the suffix
-  versions of the *hybrid* and *hybrid/overlay* styles are used to
-  propagate the corresponding suffix to all sub-styles, if those
-  versions exist. Otherwise the non-accelerated version will be used.
-  The individual accelerated sub-styles are part of the GPU, KOKKOS,
-  INTEL, OPENMP, and OPT packages, respectively.  They are only
-  enabled if LAMMPS was built with those packages.  See the
-  :doc:`Build package <Build_package>` page for more info.
+The individual accelerated sub-styles are part of the GPU, KOKKOS,
+INTEL, OPENMP, and OPT packages, respectively.  They are only
+enabled if LAMMPS was built with those packages.  See the :doc:`Build
+package <Build_package>` page for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the :doc:`-suffix command-line switch <Run_options>` when you invoke LAMMPS, or you can use the
+:doc:`suffix <suffix>` command in your input script.
+
+See the :doc:`Speed packages <Speed_packages>` page for more
+instructions on how to use the accelerated styles effectively.
 
 ----------
 

doc/src/pair_meam.rst

@@ -28,16 +28,16 @@ Description
    as of November 2010; see description below of the mixture_ref_t
    parameter
 
-Pair style *meam* computes non-bonded interactions for a variety of materials
-using the modified embedded-atom method (MEAM)
+Style *meam* computes pairwise interactions for a variety of materials
+using modified embedded-atom method (MEAM) potentials
 :ref:`(Baskes) <Baskes>`.  Conceptually, it is an extension to the original
-:doc:`EAM method <pair_eam>` which adds angular forces.  It is
+:doc:`EAM potentials <pair_eam>` which adds angular forces.  It is
 thus suitable for modeling metals and alloys with fcc, bcc, hcp and
-diamond cubic structures, as well as materials with covalent interactions
-like silicon and carbon. This *meam* pair style is a translation of the
-original Fortran version to C++. It is functionally equivalent but more
-efficient and has additional features. The Fortran version of the *meam*
-pair style has been removed from LAMMPS after the 12 December 2018 release.
+diamond cubic structures, as well as covalently bonded materials like
+silicon and carbon. Style *meam* is a translation of the (now obsolete)
+*meam* code from Fortran to C++. It is functionally equivalent to *meam*
+but more efficient, and thus *meam* has been removed from LAMMPS after
+the 12 December 2018 release.
 
 In the MEAM formulation, the total energy E of a system of atoms is
 given by:

doc/src/pair_modify.rst

@@ -71,23 +71,21 @@ The *mix* keyword affects pair coefficients for interactions between
 atoms of type I and J, when I != J and the coefficients are not
 explicitly set in the input script.  Note that coefficients for I = J
 must be set explicitly, either in the input script via the
-:doc:`pair_coeff <pair_coeff>` command or in the "Pair Coeffs" or "PairIJ Coeffs"
-sections of the :doc:`data file <read_data>`.  For some pair styles it is not
+:doc:`pair_coeff <pair_coeff>` command or in the "Pair Coeffs" section of the
+:doc:`data file <read_data>`.  For some pair styles it is not
 necessary to specify coefficients when I != J, since a "mixing" rule
 will create them from the I,I and J,J settings.  The pair_modify
 *mix* value determines what formulas are used to compute the mixed
 coefficients.  In each case, the cutoff distance is mixed the same way
 as sigma.
 
-Note that not all pair styles support mixing and some mix options are
-not available for certain pair styles. Also, there are additional
-restrictions when using :doc:`pair style hybrid or hybrid/overlay
-<pair_hybrid>`.  See the page for individual pair styles for those
-restrictions.  Note also that the :doc:`pair_coeff <pair_coeff>` command
-also can be used to directly set coefficients for a specific I != J
-pairing, in which case no mixing is performed.  If possible, LAMMPS will
-print an informational message about how many of the mixed pair
-coefficients were generated and which mixing rule was applied.
+Note that not all pair styles support mixing and some mix options
+are not available for certain pair styles. Also, there are additional
+restrictions when using :doc:`pair style hybrid or hybrid/overlay <pair_hybrid>`.
+See the page for individual pair styles for those restrictions.  Note also that the
+:doc:`pair_coeff <pair_coeff>` command also can be used to directly set
+coefficients for a specific I != J pairing, in which case no mixing is
+performed.
 
 - mix *geometric*
 

doc/src/pair_nm.rst

@@ -1,5 +1,4 @@
 .. index:: pair_style nm/cut
-.. index:: pair_style nm/cut/split
 .. index:: pair_style nm/cut/coul/cut
 .. index:: pair_style nm/cut/coul/long
 .. index:: pair_style nm/cut/omp
@@ -11,9 +10,6 @@ pair_style nm/cut command
 
 Accelerator Variants: *nm/cut/omp*
 
-pair_style nm/cut/split command
-===============================
-
 pair_style nm/cut/coul/cut command
 ==================================
 
@@ -31,15 +27,13 @@ Syntax
 
    pair_style style args
 
-* style = *nm/cut* or *nm/cut/split* or *nm/cut/coul/cut* or *nm/cut/coul/long*
+* style = *nm/cut* or *nm/cut/coul/cut* or *nm/cut/coul/long*
 * args = list of arguments for a particular style
 
   .. parsed-literal::
 
        *nm/cut* args = cutoff
          cutoff = global cutoff for Pair interactions (distance units)
-       *nm/cut/split* args = cutoff
-         cutoff = global cutoff for Pair interactions (distance units)
        *nm/cut/coul/cut* args = cutoff (cutoff2)
          cutoff = global cutoff for Pair (and Coulombic if only 1 arg) (distance units)
          cutoff2 = global cutoff for Coulombic (optional) (distance units)
@@ -56,10 +50,6 @@ Examples
    pair_coeff * * 0.01 5.4 8.0 7.0
    pair_coeff 1 1 0.01 4.4 7.0 6.0
 
-   pair_style nm/cut/split 1.12246
-   pair_coeff 1 1 1.0 1.1246 12 6
-   pair_coeff * * 1.0 1.1246 11 6
-
    pair_style nm/cut/coul/cut 12.0 15.0
    pair_coeff * * 0.01 5.4 8.0 7.0
    pair_coeff 1 1 0.01 4.4 7.0 6.0
@@ -81,15 +71,7 @@ interaction has the following form:
    E = \frac{E_0}{(n-m)} \left[ m \left(\frac{r_0}{r}\right)^n - n
    \left(\frac{r_0}{r}\right)^m \right] \qquad r < r_c
 
-where :math:`r_c` is the cutoff and :math:`r_0` is the minimum of the
-potential.  Please note that this differs from the convention used for
-other Lennard-Jones potentials in LAMMPS where :math:`\sigma` represents
-the location where the energy is zero.
-
-Style *nm/cut/split* applies the standard LJ (12-6) potential above
-:math:`r_0 = 2^\frac{1}{6}\sigma`.  Style *nm/cut/split* is employed in
-polymer equilibration protocols that combine core-softening approaches
-with topology-changing moves :ref:`Dietz <Dietz>`.
+where :math:`r_c` is the cutoff.
 
 Style *nm/cut/coul/cut* adds a Coulombic pairwise interaction given by
 
@@ -173,6 +155,7 @@ the :doc:`run_style respa <run_style>` command.  They do not support the
 
 Restrictions
 """"""""""""
+
 These pair styles are part of the EXTRA-PAIR package.  They are only enabled if
 LAMMPS was built with that package.  See the
 :doc:`Build package <Build_package>` page for more info.
@@ -180,7 +163,7 @@ LAMMPS was built with that package.  See the
 Related commands
 """"""""""""""""
 
-:doc:`pair_coeff <pair_coeff>`, :doc:`pair style lj/cut <pair_lj>`, :doc:`bond style fene/nm <bond_fene>`
+:doc:`pair_coeff <pair_coeff>`
 
 Default
 """""""
@@ -192,7 +175,3 @@ none
 .. _Clarke:
 
 **(Clarke)** Clarke and Smith, J Chem Phys, 84, 2290 (1986).
-
-.. _Dietz:
-
-**(Dietz)** Dietz and Hoy, J. Chem Phys, 156, 014103 (2022).

doc/src/pair_reaxff.rst

@@ -20,7 +20,7 @@ Syntax
   .. parsed-literal::
 
      keyword = *checkqeq* or *lgvdw* or *safezone* or *mincap* or *minhbonds*
-       *checkqeq* value = *yes* or *no* = whether or not to require qeq/reaxff or acks2/reaxff fix
+       *checkqeq* value = *yes* or *no* = whether or not to require qeq/reaxff fix
        *enobonds* value = *yes* or *no* = whether or not to tally energy of atoms with no bonds
        *lgvdw* value = *yes* or *no* = whether or not to use a low gradient vdW correction
        *safezone* = factor used for array allocation
@@ -119,8 +119,7 @@ The ReaxFF parameter files provided were created using a charge
 equilibration (QEq) model for handling the electrostatic interactions.
 Therefore, by default, LAMMPS requires that either the
 :doc:`fix qeq/reaxff <fix_qeq_reaxff>` or the
-:doc:`fix qeq/shielded <fix_qeq>` or :doc:`fix acks2/reaxff <fix_acks2_reaxff>`
-command be used with
+:doc:`fix qeq/shielded <fix_qeq>` command be used with
 *pair_style reaxff* when simulating a ReaxFF model, to equilibrate
 the charges each timestep.
 
@@ -129,8 +128,7 @@ for the QEq fixes, allowing a simulation to be run without charge
 equilibration. In this case, the static charges you assign to each
 atom will be used for computing the electrostatic interactions in
 the system. See the :doc:`fix qeq/reaxff <fix_qeq_reaxff>` or
-:doc:`fix qeq/shielded <fix_qeq>` or :doc:`fix acks2/reaxff <fix_acks2_reaxff>`
-command documentation for more details.
+:doc:`fix qeq/shielded <fix_qeq>` command documentation for more details.
 
 Using the optional keyword *lgvdw* with the value *yes* turns on the
 low-gradient correction of ReaxFF for long-range London Dispersion,
@@ -354,8 +352,7 @@ Related commands
 """"""""""""""""
 
 :doc:`pair_coeff <pair_coeff>`, :doc:`fix qeq/reaxff <fix_qeq_reaxff>`,
-:doc:`fix acks2/reaxff <fix_acks2_reaxff>`, :doc:`fix reaxff/bonds <fix_reaxff_bonds>`,
-:doc:`fix reaxff/species <fix_reaxff_species>`
+:doc:`fix reaxff/bonds <fix_reaxff_bonds>`, :doc:`fix reaxff/species <fix_reaxff_species>`
 
 Default
 """""""

doc/src/pair_style.rst

@@ -274,7 +274,6 @@ accelerated styles exist.
 * :doc:`nm/cut <pair_nm>` - N-M potential
 * :doc:`nm/cut/coul/cut <pair_nm>` - N-M potential with cutoff Coulomb
 * :doc:`nm/cut/coul/long <pair_nm>` - N-M potential with long-range Coulomb
-* :doc:`nm/cut/split <pair_nm>` - Split 12-6 Lennard-Jones and N-M potential
 * :doc:`oxdna/coaxstk <pair_oxdna>` -
 * :doc:`oxdna/excv <pair_oxdna>` -
 * :doc:`oxdna/hbond <pair_oxdna>` -
@@ -328,7 +327,6 @@ accelerated styles exist.
 * :doc:`spin/neel <pair_spin_neel>` -
 * :doc:`srp <pair_srp>` -
 * :doc:`sw <pair_sw>` - Stillinger-Weber 3-body potential
-* :doc:`sw/mod <pair_sw>` - modified Stillinger-Weber 3-body potential
 * :doc:`table <pair_table>` - tabulated pair potential
 * :doc:`table/rx <pair_table_rx>` -
 * :doc:`tdpd <pair_mesodpd>` - tDPD particle interactions

doc/src/pair_sw.rst

@@ -3,34 +3,18 @@
 .. index:: pair_style sw/intel
 .. index:: pair_style sw/kk
 .. index:: pair_style sw/omp
-.. index:: pair_style sw/mod
-.. index:: pair_style sw/mod/omp
 
 pair_style sw command
 =====================
 
 Accelerator Variants: *sw/gpu*, *sw/intel*, *sw/kk*, *sw/omp*
 
-pair_style sw/mod command
-=========================
-
-Accelerator Variants: *sw/mod/omp*
-
 Syntax
 """"""
 
 .. code-block:: LAMMPS
 
-   pair_style style keyword values
-
-* style = *sw* or *sw/mod*
-* keyword = *maxdelcs*
-
-  .. parsed-literal::
-
-       *maxdelcs* value = delta1 delta2 (optional)
-         delta1 = The minimum thershold for cosine of three-body angle
-         delta2 = The maximum threshold for cosine of three-body angle
+   pair_style sw
 
 Examples
 """"""""
@@ -41,9 +25,6 @@ Examples
    pair_coeff * * si.sw Si
    pair_coeff * * GaN.sw Ga N Ga
 
-   pair_style sw/mod maxdelcs 0.25 0.35
-   pair_coeff * * tmd.sw.mod Mo S S
-
 Description
 """""""""""
 
@@ -67,52 +48,8 @@ where :math:`\phi_2` is a two-body term and :math:`\phi_3` is a
 three-body term.  The summations in the formula are over all neighbors J
 and K of atom I within a cutoff distance :math:`a `\sigma`.
 
-The *sw/mod* style is designed for simulations of materials when
-distinguishing three-body angles are necessary, such as borophene
-and transition metal dichalcogenide, which cannot be described
-by the original code for the Stillinger-Weber potential.
-For instance, there are several types of angles around each Mo atom in `MoS_2`,
-and some unnecessary angle types should be excluded in the three-body interaction.
-Such exclusion may be realized by selecting proper angle types directly.
-The exclusion of unnecessary angles is achieved here by the cut-off function (`f_C(\delta)`),
-which induces only minimum modifications for LAMMPS.
-
-Validation, benchmark tests, and applications of the *sw/mod* style
-can be found in :ref:`(Jiang2) <Jiang2>` and :ref:`(Jiang3) <Jiang3>`.
-
-The *sw/mod* style computes the energy E of a system of atoms, whose potential
-function is mostly the same as the Stillinger-Weber potential. The only modification
-is in the three-body term, where the value of :math:`\delta = \cos \theta_{ijk} - \cos \theta_{0ijk}`
-used in the original energy and force expression is scaled by a switching factor :math:`f_C(\delta)`:
-
-.. math::
-
-  f_C(\delta) & = \left\{ \begin{array} {r@{\quad:\quad}l}
-    1 & \left| \delta \right| < \delta_1 \\
-    \frac{1}{2} + \frac{1}{2} \cos \left( \pi \frac{\left| \delta \right| - \delta_1}{\delta_2 - \delta_1} \right) &
-      \delta_1 < \left| \delta \right| < \delta_2 \\
-    0 & \left| \delta \right| > \delta_2
-    \end{array} \right. \\
-
-This cut-off function decreases smoothly from 1 to 0 over the range :math:`[\delta_1, \delta_2]`.
-This smoothly turns off the energy and force contributions for :math:`\left| \delta \right| > \delta_2`.
-It is suggested that :math:`\delta 1` and :math:`\delta_2` to be the value around
-:math:`0.5 \left| \cos \theta_1 - \cos \theta_2 \right|`, with
-:math:`\theta_1` and :math:`\theta_2` as the different types of angles around an atom.
-For borophene and transition metal dichalcogenide, :math:`\delta_1 = 0.25` and :math:`\delta_2 = 0.35`.
-This value enables the cut-off function to exclude unnecessary angles in the three-body SW terms.
-
-.. note::
-
-   The cut-off function is just to be used as a technique to exclude some unnecessary angles,
-   and it has no physical meaning. It should be noted that the force and potential are inconsistent
-   with each other in the decaying range of the cut-off function, as the angle dependence for the
-   cut-off function is not implemented in the force (first derivation of potential).
-   However, the angle variation is much smaller than the given threshold value for actual simulations,
-   so the inconsistency between potential and force can be neglected in actual simulations.
-
-Only a single pair_coeff command is used with the *sw* and *sw/mod* styles
-which specifies a Stillinger-Weber potential file with parameters for all
+Only a single pair_coeff command is used with the *sw* style which
+specifies a Stillinger-Weber potential file with parameters for all
 needed elements.  These are mapped to LAMMPS atom types by specifying
 N additional arguments after the filename in the pair_coeff command,
 where N is the number of LAMMPS atom types:
@@ -222,14 +159,28 @@ taken from the ij and ik pairs (:math:`\sigma`, *a*, :math:`\gamma`)
 
 ----------
 
-.. include:: accel_styles.rst
+Styles with a *gpu*, *intel*, *kk*, *omp*, or *opt* suffix are
+functionally the same as the corresponding style without the suffix.
+They have been optimized to run faster, depending on your available
+hardware, as discussed on the :doc:`Speed packages <Speed_packages>` doc
+page.  The accelerated styles take the same arguments and should
+produce the same results, except for round-off and precision issues.
 
-.. note::
+These accelerated styles are part of the GPU, INTEL, KOKKOS,
+OPENMP and OPT packages, respectively.  They are only enabled if
+LAMMPS was built with those packages.  See the :doc:`Build package <Build_package>` page for more info.
 
-  When using the INTEL package with this style, there is an additional
-  5 to 10 percent performance improvement when the Stillinger-Weber
-  parameters p and q are set to 4 and 0 respectively.  These
-  parameters are common for modeling silicon and water.
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the :doc:`-suffix command-line switch <Run_options>` when you invoke LAMMPS, or you can use the
+:doc:`suffix <suffix>` command in your input script.
+
+When using the INTEL package with this style, there is an
+additional 5 to 10 percent performance improvement when the
+Stillinger-Weber parameters p and q are set to 4 and 0 respectively.
+These parameters are common for modeling silicon and water.
+
+See the :doc:`Speed packages <Speed_packages>` page for more
+instructions on how to use the accelerated styles effectively.
 
 ----------
 
@@ -276,19 +227,10 @@ Related commands
 Default
 """""""
 
-The default values for the *maxdelcs* setting of the *sw/mod* pair
-style are *delta1* = 0.25 and *delta2* = 0.35`.
+none
 
 ----------
 
 .. _Stillinger2:
 
 **(Stillinger)** Stillinger and Weber, Phys Rev B, 31, 5262 (1985).
-
-.. _Jiang2:
-
-**(Jiang2)** J.-W. Jiang, Nanotechnology 26, 315706 (2015).
-
-.. _Jiang3:
-
-**(Jiang3)** J.-W. Jiang, Acta Mech. Solida. Sin 32, 17 (2019).