Merge pull request #3008 from akohlmey/next_patch_release

Update version strings for next patch release

.github/CODEOWNERS

@@ -83,7 +83,7 @@ src/library.*             @sjplimp
 src/main.cpp              @sjplimp
 src/min_*.*               @sjplimp
 src/memory.*              @sjplimp
-src/modify.*              @sjplimp
+src/modify.*              @sjplimp @stanmoore1
 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: [master]
+    branches: [develop]
 
 jobs:
   analyze:

.github/workflows/compile-msvc.yml

@@ -0,0 +1,33 @@
+# 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: [master]
+    branches: [develop]
 
 jobs:
   build:

.gitignore

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

cmake/CMakeLists.txt

@@ -81,22 +81,40 @@ 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") 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")
+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()
   else()
-    set(CMAKE_TUNE_DEFAULT "-xHost")
+    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()
   endif()
 endif()
 
-# we require C++11 without extensions
+# we require C++11 without extensions. Kokkos requires at least C++14 (currently)
 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 hack for MSVC which by default always reports an old C++ standard in the __cplusplus macro
+# 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
 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
@@ -281,6 +299,11 @@ 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(MSVC)
     target_include_directories(lammps INTERFACE $<BUILD_INTERFACE:${LAMMPS_SOURCE_DIR}/STUBS>)
     target_compile_definitions(lammps INTERFACE $<INSTALL_INTERFACE:LAMMPS_LIB_NO_MPI>)
   else()
@@ -468,9 +491,12 @@ foreach(HEADER cmath)
   endif(NOT FOUND_${HEADER})
 endforeach(HEADER)
 
-set(MATH_LIBRARIES "m" CACHE STRING "math library")
-mark_as_advanced( MATH_LIBRARIES )
-target_link_libraries(lammps PRIVATE ${MATH_LIBRARIES})
+# 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()
 
 ######################################
 # Generate Basic Style files
@@ -591,15 +617,12 @@ foreach(PKG_WITH_INCL CORESHELL QEQ OPENMP DPD-SMOOTH KOKKOS OPT INTEL GPU)
 endforeach()
 
 if(PKG_PLUGIN)
-  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()
+  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})
 endif()
 
 ######################################################################
@@ -608,7 +631,7 @@ endif()
 # and after everything else that is compiled locally
 ######################################################################
 if(CMAKE_SYSTEM_NAME STREQUAL "Windows")
-  target_link_libraries(lammps PRIVATE -lwsock32 -lpsapi)
+  target_link_libraries(lammps PRIVATE "wsock32;psapi")
 endif()
 
 ######################################################

cmake/CMakeSettings.json

@@ -0,0 +1,55 @@
+{
+    "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",
+            "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",
+            "buildCommandArgs": "",
+            "ctestCommandArgs": "",
+            "inheritEnvironments": [ "clang_cl_x64" ],
+            "variables": [
+                {
+                    "name": "BUILD_TOOLS",
+                    "value": "True",
+                    "type": "BOOL"
+                },
+                {
+                    "name": "LAMMPS_EXCEPTIONS",
+                    "value": "True",
+                    "type": "BOOL"
+                }
+            ]
+        }
+    ]
+}

cmake/Modules/GTest.cmake

@@ -7,8 +7,8 @@ else()
 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")
+set(GTEST_URL "https://github.com/google/googletest/archive/release-1.11.0.tar.gz" CACHE STRING "URL of googletest source")
+set(GTEST_MD5 "e8a8df240b6938bb6384155d4c37d937" CACHE STRING "MD5 sum for googletest source")
 mark_as_advanced(GTEST_URL)
 mark_as_advanced(GTEST_MD5)
 ExternalProject_Add(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)
-  set(CMAKE_CXX_STANDARD 14)
+  message(FATAL_ERROR "The KOKKOS package requires the C++ standard to be set to at least C++14")
 endif()
 ########################################################################
 # consistency checks and Kokkos options/settings required by LAMMPS

cmake/Modules/Packages/MACHDYN.cmake

@@ -7,8 +7,9 @@ endif()
 option(DOWNLOAD_EIGEN3 "Download Eigen3 instead of using an already installed one)" ${DOWNLOAD_EIGEN3_DEFAULT})
 if(DOWNLOAD_EIGEN3)
   message(STATUS "Eigen3 download requested - we will build our own")
-  set(EIGEN3_URL "https://gitlab.com/libeigen/eigen/-/archive/3.3.9/eigen-3.3.9.tar.gz" CACHE STRING "URL for Eigen3 tarball")
-  set(EIGEN3_MD5 "609286804b0f79be622ccf7f9ff2b660" CACHE STRING "MD5 checksum of Eigen3 tarball")
+
+  set(EIGEN3_URL "${LAMMPS_THIRDPARTY_URL}/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)
   include(ExternalProject)

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_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")
+set(PACELIB_MD5 "a2ac3315c41a1a4a5c912bcb1bc9c5cc" 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 SHOW_PROGRESS EXPECTED_HASH MD5=${PACELIB_MD5})
+file(DOWNLOAD ${PACELIB_URL} ${CMAKE_BINARY_DIR}/libpace.tar.gz EXPECTED_HASH MD5=${PACELIB_MD5}) #SHOW_PROGRESS
 
 # uncompress downloaded sources
 execute_process(
@@ -14,12 +14,19 @@ execute_process(
   WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
 )
 
-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)
+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)
 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})
-target_link_libraries(lammps PRIVATE pace)
+target_include_directories(pace PUBLIC ${PACE_EVALUATOR_INCLUDE_DIR} ${YAML_CPP_INCLUDE_DIR})
 
+
+target_link_libraries(pace PRIVATE yaml-cpp-pace)
+
+target_link_libraries(lammps PRIVATE pace)

cmake/Modules/Tools.cmake

@@ -25,7 +25,9 @@ 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})
-  target_link_libraries(msi2lmp PRIVATE ${MATH_LIBRARIES})
+  if(STANDARD_MATH_LIB)
+    target_link_libraries(msi2lmp PRIVATE ${STANDARD_MATH_LIB})
+  endif()
   install(TARGETS msi2lmp DESTINATION ${CMAKE_INSTALL_BINDIR})
   install(FILES ${LAMMPS_DOC_DIR}/msi2lmp.1 DESTINATION ${CMAKE_INSTALL_MANDIR}/man1)
 endif()

cmake/presets/windows.cmake

@@ -0,0 +1,64 @@
+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,6 +435,8 @@ 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/github-development-workflow.md

@@ -33,9 +33,9 @@ when necessary.
 ## Pull Requests
 
 ALL changes to the LAMMPS code and documentation, however trivial, MUST
-be submitted as a pull request to GitHub. All changes to the "master"
+be submitted as a pull request to GitHub. All changes to the "develop"
 branch must be made exclusively through merging pull requests. The
-"unstable" and "stable" branches, respectively are only to be updated
+"release" and "stable" branches, respectively are only to be updated
 upon patch or stable releases with fast-forward merges based on the
 associated tags. Pull requests may also be submitted to (long-running)
 feature branches created by LAMMPS developers inside the LAMMPS project,
@@ -123,16 +123,16 @@ and thus were this comment should be placed.
 
 LAMMPS uses a continuous release development model with incremental
 changes, i.e. significant effort is made - including automated pre-merge
-testing - that the code in the branch "master" does not get easily
+testing - that the code in the branch "develop" does not get easily
 broken.  These tests are run after every update to a pull request.  More
 extensive and time consuming tests (including regression testing) are
-performed after code is merged to the "master" branch. There are patch
+performed after code is merged to the "develop" branch. There are patch
 releases of LAMMPS every 3-5 weeks at a point, when the LAMMPS
 developers feel, that a sufficient amount of changes have happened, and
 the post-merge testing has been successful. These patch releases are
-marked with a `patch_<version date>` tag and the "unstable" branch
+marked with a `patch_<version date>` tag and the "release" branch
 follows only these versions (and thus is always supposed to be of
-production quality, unlike "master", which may be temporary broken, in
+production quality, unlike "develop", which may be temporary broken, in
 the case of larger change sets or unexpected incompatibilities or side
 effects.
 

doc/lammps.1

@@ -1,4 +1,4 @@
-.TH LAMMPS "29 September 2021" "2021-09-29"
+.TH LAMMPS "1" "27 October 2021" "2021-10-27"
 .SH NAME
 .B LAMMPS
 \- Molecular Dynamics Simulator.

doc/msi2lmp.1

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

doc/src/Build_diskspace.rst

@@ -14,7 +14,7 @@ environments with restricted disk space capacity it may be needed to
 reduce the storage requirements. Here are some suggestions:
 
 - Create a so-called shallow repository by cloning only the last commit
-  instead of the full project history by using ``git clone git@github.com:lammps/lammps --depth=1 --branch=master``.
+  instead of the full project history by using ``git clone git@github.com:lammps/lammps --depth=1 --branch=develop``.
   This reduces the downloaded size to about half.  With ``--depth=1`` it is not possible to check out different
   versions/branches of LAMMPS, using ``--depth=1000`` will make multiple recent versions available at little
   extra storage needs (the entire git history had nearly 30,000 commits in fall 2021).

doc/src/Build_manual.rst

@@ -33,12 +33,15 @@ various tools and files.  Some of them have to be installed (see below).  For
 the rest the build process will attempt to download and install them into
 a python virtual environment and local folders.
 
-A current version of the manual (latest patch release, aka unstable
-branch) is is available online at:
-`https://docs.lammps.org/Manual.html <https://docs.lammps.org/Manual.html>`_.
-A version of the manual corresponding to the ongoing development (aka master branch)
-is available online at: `https://docs.lammps.org/latest/
-<https://docs.lammps.org/latest/>`_
+A current version of the manual (latest patch release, that is the state
+of the *release* branch) is is available online at:
+`https://docs.lammps.org/ <https://docs.lammps.org/>`_.
+A version of the manual corresponding to the ongoing development (that is
+the state of the *develop* branch) is available online at:
+`https://docs.lammps.org/latest/ <https://docs.lammps.org/latest/>`_
+A version of the manual corresponding to the latest stable LAMMPS release
+(that is the state of the *stable* branch) is available online at:
+`https://docs.lammps.org/stable/ <https://docs.lammps.org/stable/>`_
 
 Build using GNU make
 --------------------

doc/src/Build_settings.rst

@@ -321,9 +321,7 @@ following settings:
 
       .. code-block:: make
 
-         LMP_INC = -DLAMMPS_JPEG
-         LMP_INC = -DLAMMPS_PNG
-         LMP_INC = -DLAMMPS_FFMPEG
+         LMP_INC = -DLAMMPS_JPEG -DLAMMPS_PNG -DLAMMPS_FFMPEG  <other LMP_INC settings>
 
          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
@@ -354,8 +352,10 @@ Read or write compressed files
 -----------------------------------------
 
 If this option is enabled, large files can be read or written with
-gzip compression by several LAMMPS commands, including
-:doc:`read_data <read_data>`, :doc:`rerun <rerun>`, and :doc:`dump <dump>`.
+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``.
 
 .. tabs::
 
@@ -364,23 +364,23 @@ gzip compression by several LAMMPS commands, including
       .. code-block:: bash
 
          -D WITH_GZIP=value       # yes or no
-                                  # default is yes if CMake can find gzip, else no
-         -D GZIP_EXECUTABLE=path  # path to gzip executable if CMake cannot find it
+                                  # default is yes if CMake can find the gzip program, else no
 
    .. tab:: Traditional make
 
       .. code-block:: make
 
-         LMP_INC = -DLAMMPS_GZIP
+         LMP_INC = -DLAMMPS_GZIP   <other LMP_INC settings>
 
-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.
+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.
 
 .. note::
 
-   On some clusters with high-speed networks, using the "fork()" library
-   call (required by "popen()") can interfere with the fast communication
+   On 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
+         LMP_INC = -DLAMMPS_LONGLONG_TO_LONG  <other LMP_INC settings>
 
 ----------
 
@@ -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
+         LMP_INC = -DLAMMPS_EXCEPTIONS   <other LMP_INC settings>
 
 .. note::
 
@@ -520,7 +520,7 @@ executable, not the library.
 
       .. code-block:: make
 
-         LMP_INC = -DLAMMPS_TRAP_FPE
+         LMP_INC = -DLAMMPS_TRAP_FPE  <other LMP_INC settings>
 
 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,6 +4,7 @@ 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>`
 
 ----------
@@ -31,13 +32,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
-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 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>`.
 
 .. _gnu:
 
@@ -67,6 +68,35 @@ 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>`_.
+
+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_fix.rst

@@ -23,6 +23,7 @@ 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>`
@@ -103,6 +104,7 @@ 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/Developer.rst

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

doc/src/Developer_platform.rst

@@ -0,0 +1,152 @@
+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:: 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,7 +7,9 @@ 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.
+reduces redundant implementations and encourages consistent behavior and
+thus has some overlap with the :doc:`"platform" sub-namespace
+<Developer_platform>`.
 
 I/O with status check and similar functions
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -60,6 +62,9 @@ silently returning the result of a partial conversion or zero in cases
 where the string is not a valid number.  This behavior allows to more
 easily detect 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.
+
 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
 a call to ``Error::one()`` for errors instead of ``Error::all()``
@@ -83,6 +88,9 @@ strings for compliance without conversion.
 .. doxygenfunction:: tnumeric
    :project: progguide
 
+.. doxygenfunction:: logical
+   :project: progguide
+
 
 String processing
 ^^^^^^^^^^^^^^^^^
@@ -95,6 +103,12 @@ and parsing files or arguments.
 .. doxygenfunction:: strdup
    :project: progguide
 
+.. doxygenfunction:: lowercase
+   :project: progguide
+
+.. doxygenfunction:: uppercase
+   :project: progguide
+
 .. doxygenfunction:: trim
    :project: progguide
 
@@ -137,21 +151,6 @@ 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,7 +29,9 @@ of code in the header before include guards:
 .. code-block:: c
 
    #ifdef FIX_CLASS
-   FixStyle(print/vel,FixPrintVel)
+   // clang-format off
+   FixStyle(print/vel,FixPrintVel);
+   // clang-format on
    #else
    /* the definition of the FixPrintVel class comes here */
    ...

doc/src/Examples.rst

@@ -80,7 +80,7 @@ Lowercase directories
 +-------------+------------------------------------------------------------------+
 | friction    | frictional contact of spherical asperities between 2d surfaces   |
 +-------------+------------------------------------------------------------------+
-| gcmc        | Grand Canonical Monte Carlo (GCMC) via the fix gcmc command      |
+| mc          | Monte Carlo features via fix gcmc, widom and other commands      |
 +-------------+------------------------------------------------------------------+
 | 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         | using LAMMPS in a Monte Carlo mode to relax the energy of a system                               |
+| MC-LOOP    | using LAMMPS in a Monte Carlo mode to relax the energy of a system in a input script loop        |
 +------------+--------------------------------------------------------------------------------------------------+
 | PACKAGES   | examples for specific packages and contributed commands                                          |
 +------------+--------------------------------------------------------------------------------------------------+

doc/src/Howto_github.rst

@@ -7,11 +7,11 @@ LAMMPS GitHub tutorial
 
 This document describes the process of how to use GitHub to integrate
 changes or additions you have made to LAMMPS into the official LAMMPS
-distribution.  It uses the process of updating this very tutorial as
-an example to describe the individual steps and options.  You need to
-be familiar with git and you may want to have a look at the
-`git book <http://git-scm.com/book/>`_ to reacquaint yourself with some
-of the more advanced git features used below.
+distribution.  It uses the process of updating this very tutorial as an
+example to describe the individual steps and options.  You need to be
+familiar with git and you may want to have a look at the `git book
+<http://git-scm.com/book/>`_ to familiarize yourself with some of the
+more advanced git features used below.
 
 As of fall 2016, submitting contributions to LAMMPS via pull requests
 on GitHub is the preferred option for integrating contributed features
@@ -37,15 +37,15 @@ username or e-mail address and password.
 **Forking the repository**
 
 To get changes into LAMMPS, you need to first fork the `lammps/lammps`
-repository on GitHub. At the time of writing, *master* is the preferred
+repository on GitHub. At the time of writing, *develop* is the preferred
 target branch. Thus go to `LAMMPS on GitHub <https://github.com/lammps/lammps>`_
-and make sure branch is set to "master", as shown in the figure below.
+and make sure branch is set to "develop", as shown in the figure below.
 
 .. image:: JPG/tutorial_branch.png
    :align: center
 
-If it is not, use the button to change it to *master*\ . Once it is, use the
-fork button to create a fork.
+If it is not, use the button to change it to *develop*. Once it is, use
+the fork button to create a fork.
 
 .. image:: JPG/tutorial_fork.png
    :align: center
@@ -64,11 +64,12 @@ LAMMPS development.
 **Adding changes to your own fork**
 
 Additions to the upstream version of LAMMPS are handled using *feature
-branches*\ .  For every new feature, a so-called feature branch is
+branches*.  For every new feature, a so-called feature branch is
 created, which contains only those modification relevant to one specific
 feature. For example, adding a single fix would consist of creating a
 branch with only the fix header and source file and nothing else.  It is
-explained in more detail here: `feature branch workflow <https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow>`_.
+explained in more detail here: `feature branch workflow
+<https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow>`_.
 
 **Feature branches**
 
@@ -94,8 +95,8 @@ The above command copies ("clones") the git repository to your local
 machine to a directory with the name you chose. If none is given, it will
 default to "lammps". Typical names are "mylammps" or something similar.
 
-You can use this local clone to make changes and
-test them without interfering with the repository on GitHub.
+You can use this local clone to make changes and test them without
+interfering with the repository on GitHub.
 
 To pull changes from upstream into this copy, you can go to the directory
 and use git pull:
@@ -103,28 +104,45 @@ and use git pull:
 .. code-block:: bash
 
      $ cd mylammps
-     $ git checkout master
-     $ git pull https://github.com/lammps/lammps
+     $ git checkout develop
+     $ git pull https://github.com/lammps/lammps develop
 
 You can also add this URL as a remote:
 
 .. code-block:: bash
 
-     $ git remote add lammps_upstream https://www.github.com/lammps/lammps
+     $ git remote add upstream https://www.github.com/lammps/lammps
 
-At this point, you typically make a feature branch from the updated master
+From then on you can update your upstream branches with:
+
+.. code-block:: bash
+
+     $ git fetch upstream
+
+and then refer to the upstream repository branches with
+`upstream/develop` or `upstream/release` and so on.
+
+At this point, you typically make a feature branch from the updated
 branch for the feature you want to work on. This tutorial contains the
 workflow that updated this tutorial, and hence we will call the branch
 "github-tutorial-update":
 
 .. code-block:: bash
 
-    $ git checkout -b github-tutorial-update master
+    $ git fetch upstream
+    $ git checkout -b github-tutorial-update upstream/develop
 
 Now that we have changed branches, we can make our changes to our local
 repository. Just remember that if you want to start working on another,
 unrelated feature, you should switch branches!
 
+.. note::
+
+   Committing changes to the *develop*, *release*, or *stable* branches
+   is strongly discouraged.  While it may be convenient initially, it
+   will create more work in the long run.  Various texts and tutorials
+   on using git effectively discuss the motivation for this.
+
 **After changes are made**
 
 After everything is done, add the files to the branch and commit them:
@@ -287,28 +305,32 @@ After each push, the automated checks are run again.
 
 LAMMPS developers may add labels to your pull request to assign it to
 categories (mostly for bookkeeping purposes), but a few of them are
-important: needs_work, work_in_progress, test-for-regression, and
-full-regression-test. The first two indicate, that your pull request
-is not considered to be complete. With "needs_work" the burden is on
-exclusively on you; while "work_in_progress" can also mean, that a
-LAMMPS developer may want to add changes. Please watch the comments
-to the pull requests. The two "test" labels are used to trigger
-extended tests before the code is merged. This is sometimes done by
-LAMMPS developers, if they suspect that there may be some subtle
-side effects from your changes. It is not done by default, because
-those tests are very time consuming.
+important: *needs_work*, *work_in_progress*, *run_tests*,
+*test_for_regression*, and *ready_for_merge*.  The first two indicate,
+that your pull request is not considered to be complete. With
+"needs_work" the burden is on exclusively on you; while
+"work_in_progress" can also mean, that a LAMMPS developer may want to
+add changes. Please watch the comments to the pull requests. The two
+"test" labels are used to trigger extended tests before the code is
+merged. This is sometimes done by LAMMPS developers, if they suspect
+that there may be some subtle side effects from your changes. It is not
+done by default, because those tests are very time consuming.  The
+*ready_for_merge* label is usually attached when the LAMMPS developer
+assigned to the pull request considers this request complete and to
+trigger a final full test evaluation.
 
 **Reviews**
 
-As of Summer 2018, a pull request needs at least 1 approving review
-from a LAMMPS developer with write access to the repository.
-In case your changes touch code that certain developers are associated
-with, they are auto-requested by the GitHub software.  Those associations
-are set in the file
-`.github/CODEOWNERS <https://github.com/lammps/lammps/blob/master/.github/CODEOWNERS>`_
-Thus if you want to be automatically notified to review when anybody
-changes files or packages, that you have contributed to LAMMPS, you can
-add suitable patterns to that file, or a LAMMPS developer may add you.
+As of Fall 2021, a pull request needs to pass all automatic tests and at
+least 1 approving review from a LAMMPS developer with write access to
+the repository before it is eligible for merging.  In case your changes
+touch code that certain developers are associated with, they are
+auto-requested by the GitHub software.  Those associations are set in
+the file `.github/CODEOWNERS
+<https://github.com/lammps/lammps/blob/develop/.github/CODEOWNERS>`_ Thus
+if you want to be automatically notified to review when anybody changes
+files or packages, that **you** have contributed to LAMMPS, you can add
+suitable patterns to that file, or a LAMMPS developer may add you.
 
 Otherwise, you can also manually request reviews from specific developers,
 or LAMMPS developers - in their assessment of your pull request - may
@@ -329,7 +351,7 @@ LAMMPS developer (including him/herself) or c) Axel Kohlmeyer (akohlmey).
   After the review, the developer can choose to implement changes directly
   or suggest them to you.
 * Case c) means that the pull request has been assigned to the developer
-  overseeing the merging of pull requests into the master branch.
+  overseeing the merging of pull requests into the *develop* branch.
 
 In this case, Axel assigned the tutorial to Steve:
 
@@ -351,11 +373,11 @@ Sometimes, however, you might not feel comfortable having other people
 push changes into your own branch, or maybe the maintainers are not sure
 their idea was the right one.  In such a case, they can make changes,
 reassign you as the assignee, and file a "reverse pull request", i.e.
-file a pull request in your GitHub repository to include changes in the
-branch, that you have submitted as a pull request yourself.  In that
-case, you can choose to merge their changes back into your branch,
-possibly make additional changes or corrections and proceed from there.
-It looks something like this:
+file a pull request in **your** forked GitHub repository to include
+changes in the branch, that you have submitted as a pull request
+yourself.  In that case, you can choose to merge their changes back into
+your branch, possibly make additional changes or corrections and proceed
+from there.  It looks something like this:
 
 .. image:: JPG/tutorial_reverse_pull_request.png
    :align: center
@@ -419,7 +441,7 @@ This merge also shows up on the lammps GitHub page:
 
 **After a merge**
 
-When everything is fine, the feature branch is merged into the master branch:
+When everything is fine, the feature branch is merged into the *develop* branch:
 
 .. image:: JPG/tutorial_merged.png
    :align: center
@@ -433,8 +455,8 @@ branch!
 
 .. code-block:: bash
 
-   $ git checkout master
-   $ git pull master
+   $ git checkout develop
+   $ git pull https://github.com/lammps/lammps develop
    $ git branch -d github-tutorial-update
 
 If you do not pull first, it is not really a problem but git will warn
@@ -442,6 +464,7 @@ you at the next statement that you are deleting a local branch that
 was not yet fully merged into HEAD. This is because git does not yet
 know your branch just got merged into LAMMPS upstream. If you
 first delete and then pull, everything should still be fine.
+You can display all branches that are fully merged by:
 
 Finally, if you delete the branch locally, you might want to push this
 to your remote(s) as well:
@@ -453,14 +476,14 @@ to your remote(s) as well:
 **Recent changes in the workflow**
 
 Some changes to the workflow are not captured in this tutorial.  For
-example, in addition to the master branch, to which all new features
-should be submitted, there is now also an "unstable" and a "stable"
-branch; these have the same content as "master", but are only updated
-after a patch release or stable release was made.
-Furthermore, the naming of the patches now follow the pattern
-"patch_<Day><Month><Year>" to simplify comparisons between releases.
-Finally, all patches and submissions are subject to automatic testing
-and code checks to make sure they at the very least compile.
+example, in addition to the *develop* branch, to which all new features
+should be submitted, there is also a *release* and a *stable* branch;
+these have the same content as *develop*, but are only updated after a
+patch release or stable release was made.  Furthermore, the naming of
+the patches now follow the pattern "patch_<Day><Month><Year>" to
+simplify comparisons between releases.  Finally, all patches and
+submissions are subject to automatic testing and code checks to make
+sure they at the very least compile.
 
 A discussion of the LAMMPS developer GitHub workflow can be found in the file
-`doc/github-development-workflow.md <https://github.com/lammps/lammps/blob/master/doc/github-development-workflow.md>`_
+`doc/github-development-workflow.md <https://github.com/lammps/lammps/blob/develop/doc/github-development-workflow.md>`_

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,11 +26,13 @@ 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::
 
@@ -40,25 +42,31 @@ 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.  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>`.
+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.
 
-Below is a list of some custom temperature computes that can be used like that:
+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:
 
 * :doc:`compute_temp_asphere`
 * :doc:`compute_temp_body`
@@ -72,8 +80,6 @@ Below is a list of some custom temperature computes that can be used like that:
 * :doc:`compute_temp_rotate`
 * :doc:`compute_temp_sphere`
 
-
-
 .. note::
 
    Only the nvt fixes perform time integration, meaning they update
@@ -86,17 +92,17 @@ Below is a list of some custom temperature computes that can be used like 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/Install_git.rst

@@ -9,7 +9,8 @@ has several advantages:
   command.
 * You can create your own development branches to add code to LAMMPS.
 * You can submit your new features back to GitHub for inclusion in
-  LAMMPS.
+  LAMMPS.  For that you should first create your own :doc:`fork on
+  GitHub <Howto_github>`.
 
 You must have `git <git_>`_ installed on your system to use the
 commands explained below to communicate with the git servers on
@@ -20,35 +21,53 @@ provides `limited support for subversion clients <svn_>`_.
 
    As of October 2016, the official home of public LAMMPS development is
    on GitHub.  The previously advertised LAMMPS git repositories on
-   git.lammps.org and bitbucket.org are now deprecated or offline.
+   git.lammps.org and bitbucket.org are now offline or deprecated.
 
 .. _git: https://git-scm.com
 .. _svn: https://help.github.com/en/github/importing-your-projects-to-github/working-with-subversion-on-github
 
-You can follow LAMMPS development on 3 different git branches:
+You can follow the LAMMPS development on 3 different git branches:
 
-* **stable**   :  this branch is updated with every stable release
-* **unstable** :  this branch is updated with every patch release
-* **master**   :  this branch continuously follows ongoing development
+* **stable**   :  this branch is updated with every stable release;
+  updates are always "fast forward" merges from *develop*
+* **release**  :  this branch is updated with every patch release;
+  updates are always "fast forward" merges from *develop*
+* **develop**  :  this branch follows the ongoing development and
+  is updated with every merge commit of a pull request
 
 To access the git repositories on your box, use the clone command to
 create a local copy of the LAMMPS repository with a command like:
 
 .. code-block:: bash
 
-   $ git clone -b unstable https://github.com/lammps/lammps.git mylammps
+   $ git clone -b release https://github.com/lammps/lammps.git mylammps
 
 where "mylammps" is the name of the directory you wish to create on
-your machine and "unstable" is one of the 3 branches listed above.
+your machine and "release" is one of the 3 branches listed above.
 (Note that you actually download all 3 branches; you can switch
 between them at any time using "git checkout <branch name>".)
 
+.. note::
+
+   The complete git history of the LAMMPS project is quite large because
+   it contains the entire commit history of the project since fall 2006,
+   which includes the time when LAMMPS was managed with subversion. This
+   also includes commits that have added and removed some large files
+   (mostly by accident).  If you do not need access to the entire commit
+   history, you can speed up the "cloning" process and reduce local disk
+   space requirements by using the *--depth* git command line flag thus
+   create a "shallow clone" of the repository that contains only a
+   subset of the git history. Using a depth of 1000 is usually sufficient
+   to include the head commits of the *develop* and the *release* branches.
+   To include the head commit of the *stable* branch you may need a depth
+   of up to 10000.
+
 Once the command completes, your directory will contain the same files
 as if you unpacked a current LAMMPS tarball, with the exception, that
 the HTML documentation files are not included.  They can be fetched
 from the LAMMPS website by typing ``make fetch`` in the doc directory.
-Or they can be generated from the content provided in doc/src by
-typing ``make html`` from the doc directory.
+Or they can be generated from the content provided in ``doc/src`` by
+typing ``make html`` from the ``doc`` directory.
 
 After initial cloning, as bug fixes and new features are added to
 LAMMPS you can stay up-to-date by typing the following git commands
@@ -56,9 +75,9 @@ from within the "mylammps" directory:
 
 .. code-block:: bash
 
-   $ git checkout unstable      # not needed if you always stay in this branch
-   $ git checkout stable        # use one of these 3 checkout commands
-   $ git checkout master        # to choose the branch to follow
+   $ git checkout release      # not needed if you always stay in this branch
+   $ git checkout stable       # use one of these 3 checkout commands
+   $ git checkout develop      # to choose the branch to follow
    $ git pull
 
 Doing a "pull" will not change any files you have added to the LAMMPS
@@ -81,7 +100,7 @@ Stable versions and what tagID to use for a particular stable version
 are discussed on `this page <https://www.lammps.org/bug.html#version>`_.
 Note that this command will print some warnings, because in order to get
 back to the latest revision and to be able to update with ``git pull``
-again, you will need to do ``git checkout unstable`` (or
+again, you will need to do ``git checkout release`` (or
 check out any other desired branch) first.
 
 Once you have updated your local files with a ``git pull`` (or ``git

doc/src/Intro_opensource.rst

@@ -19,7 +19,7 @@ software and open-source distribution, see `www.gnu.org <gnuorg_>`_
 or `www.opensource.org <opensource_>`_.  The legal text of the GPL as it
 applies to LAMMPS is in the LICENSE file included in the LAMMPS distribution.
 
-.. _gpl: https://github.com/lammps/lammps/blob/master/LICENSE
+.. _gpl: https://github.com/lammps/lammps/blob/develop/LICENSE
 
 .. _lgpl: https://www.gnu.org/licenses/old-licenses/lgpl-2.1.html
 

doc/src/Manual_version.rst

@@ -7,7 +7,7 @@ correctly and reliably at all times.  You can follow its development
 in a public `git repository on GitHub <https://github.com/lammps/lammps>`_.
 
 Whenever we fix a bug or update or add a feature, it will be merged into
-the `master` branch of the git repository.  When a sufficient number of
+the *develop* branch of the git repository.  When a sufficient number of
 changes have accumulated *and* the software passes a set of automated
 tests, we release it in the next *patch* release, which are made every
 few weeks.  Info on patch releases are on `this website page

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:`Speed packages <Speed_packages>` doc
+packages discussed on the :doc:`Accelerator packages <Speed_packages>`
 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:`Speed packages <Speed_packages>` doc
+hardware, as discussed on the :doc:`Accelerator packages <Speed_packages>`
 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:`Speed packages <Speed_packages>` page for more
+See the :doc:`Accelerator packages <Speed_packages>` page for more
 instructions on how to use the accelerated styles effectively.

doc/src/angle_charmm.rst

@@ -56,23 +56,7 @@ radian\^2.
 
 ----------
 
-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.
+.. include:: accel_styles.rst
 
 ----------
 

doc/src/atom_style.rst

@@ -319,28 +319,9 @@ styles; see the :doc:`Modify <Modify>` doc page.
 
 ----------
 
-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.
+.. include:: accel_styles.rst
 
-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/fix.rst

@@ -166,6 +166,7 @@ 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
@@ -246,6 +247,7 @@ 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

@@ -0,0 +1,118 @@
+.. 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_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 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
+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
 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,23 +133,24 @@ 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::
 
@@ -165,12 +166,13 @@ by various :doc:`output commands <Howto_output>`.  The vector values are
 the following global cumulative quantities:
 
 * 1 = swap attempts
-* 2 = swap successes
+* 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>`.
+the :doc:`run <run>` command.  This fix is not invoked during
+:doc:`energy minimization <minimize>`.
 
 Restrictions
 """"""""""""
@@ -184,7 +186,8 @@ 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:`delete_atoms <delete_atoms>`, :doc:`fix gcmc <fix_gcmc>`,
+:doc:`fix mol/swap <fix_mol_swap>`
 
 Default
 """""""

doc/src/fix_langevin.rst

@@ -138,16 +138,18 @@ 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. 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.
+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.
 
 The *damp* parameter is specified in time units and determines how
 rapidly the temperature is relaxed.  For example, a value of 100.0 means
@@ -183,7 +185,8 @@ 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

@@ -167,17 +167,20 @@ 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. 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.
+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.
 
 Note: The temperature thermostatting the core-Drude particle pairs
 should be chosen low enough, so as to mimic as closely as possible the

doc/src/fix_mol_swap.rst

@@ -0,0 +1,170 @@
+.. 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,19 +486,20 @@ 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, 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.
+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.
 
 ----------
 

doc/src/fix_npt_asphere.rst

@@ -48,8 +48,9 @@ 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
@@ -89,18 +90,19 @@ 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 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.
+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.
 
 ----------
 

doc/src/fix_npt_body.rst

@@ -87,18 +87,19 @@ 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 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.
+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.
 
 ----------
 

doc/src/fix_npt_cauchy.rst

@@ -400,19 +400,20 @@ 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, 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.
+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.
 
 ----------
 

doc/src/fix_npt_sphere.rst

@@ -103,18 +103,19 @@ 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 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.
+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.
 
 ----------
 

doc/src/fix_nvt_asphere.rst

@@ -72,18 +72,19 @@ 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 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.
+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.
 
 ----------
 

doc/src/fix_nvt_body.rst

@@ -69,18 +69,19 @@ 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 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.
+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.
 
 ----------
 

doc/src/fix_nvt_sllod.rst

@@ -37,15 +37,16 @@ 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::
 
@@ -60,13 +61,15 @@ contribute to the thermal "temperature" of the atom.
    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::
 
@@ -94,27 +97,28 @@ 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 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.
+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.
 
 ----------
 

doc/src/fix_nvt_sphere.rst

@@ -86,18 +86,19 @@ 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 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.
+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.
 
 ----------
 

doc/src/fix_qeq.rst

@@ -230,7 +230,10 @@ 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.
 
-The qeq fixes are not compatible with the GPU and USER-INTEL packages.
+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>`.
 
 Related commands
 """"""""""""""""

doc/src/fix_qeq_reaxff.rst

@@ -116,6 +116,12 @@ 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,6 +56,17 @@ 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,7 +28,6 @@ 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
 """"""""
@@ -161,10 +160,6 @@ 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,26 +89,13 @@ precession vectors instead of the forces.
 
 ----------
 
-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.
+.. include:: accel_styles.rst
 
-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.
+.. note::
 
-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.
+  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.
 
 ----------
 

doc/src/fix_temp_berendsen.rst

@@ -102,18 +102,19 @@ 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 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.
+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.
 
 ----------
 

doc/src/fix_temp_csvr.rst

@@ -110,28 +110,29 @@ 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, 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.
+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.
 
 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 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.
+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.
 
 ----------
 

doc/src/fix_tgnh_drude.rst

@@ -187,26 +187,32 @@ barostatting.
 
 ----------
 
-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.
+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.
 
 .. 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,25 +64,7 @@ radian\^2.
 
 ----------
 
-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.
+.. include:: accel_styles.rst
 
 ----------
 

doc/src/kspace_style.rst

@@ -414,33 +414,26 @@ relative RMS error.
 
 ----------
 
-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.
+.. include:: accel_styles.rst
 
-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.
+.. note::
 
-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.
+  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.
 
-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.
+.. note::
 
-See the :doc:`Speed packages <Speed_packages>` page for more
-instructions on how to use the accelerated styles effectively.
+  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.
 
 ----------
 

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:`Speed packages <Speed_packages>` page for more details
+See the :doc:`Accelerator packages <Speed_packages>` page for more details
 about using the various accelerator packages for speeding up LAMMPS
 simulations.
 

doc/src/pair_agni.rst

@@ -67,21 +67,7 @@ and input files are provided in the examples/PACKAGES/agni directory.
 
 ----------
 
-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.
+.. include:: accel_styles.rst
 
 ----------
 

doc/src/pair_hybrid.rst

@@ -383,30 +383,19 @@ coefficients to 0.0.
 
 ----------
 
-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.
+.. include:: accel_styles.rst
 
-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.
+.. note::
 
-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.
+  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.
 
 ----------
 

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 fix
+       *checkqeq* value = *yes* or *no* = whether or not to require qeq/reaxff or acks2/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,7 +119,8 @@ 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>` command be used with
+:doc:`fix qeq/shielded <fix_qeq>` or :doc:`fix acks2/reaxff <fix_acks2_reaxff>`
+command be used with
 *pair_style reaxff* when simulating a ReaxFF model, to equilibrate
 the charges each timestep.
 
@@ -128,7 +129,8 @@ 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>` command documentation for more details.
+:doc:`fix qeq/shielded <fix_qeq>` or :doc:`fix acks2/reaxff <fix_acks2_reaxff>`
+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,
@@ -352,7 +354,8 @@ Related commands
 """"""""""""""""
 
 :doc:`pair_coeff <pair_coeff>`, :doc:`fix qeq/reaxff <fix_qeq_reaxff>`,
-:doc:`fix reaxff/bonds <fix_reaxff_bonds>`, :doc:`fix reaxff/species <fix_reaxff_species>`
+:doc:`fix acks2/reaxff <fix_acks2_reaxff>`, :doc:`fix reaxff/bonds <fix_reaxff_bonds>`,
+:doc:`fix reaxff/species <fix_reaxff_species>`
 
 Default
 """""""

doc/src/pair_sw.rst

@@ -159,28 +159,14 @@ taken from the ij and ik pairs (:math:`\sigma`, *a*, :math:`\gamma`)
 
 ----------
 
-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.
+.. include:: accel_styles.rst
 
-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.
+.. note::
 
-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.
+  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.
 
 ----------
 

doc/src/plugin.rst

@@ -65,10 +65,8 @@ only enabled if LAMMPS was built with that package.
 See the :doc:`Build package <Build_package>` page for
 more info. Plugins are not available on Windows.
 
-For the loading of plugins to work the LAMMPS library must be
-:ref:`compiled as a shared library <library>`.  If plugins
-access functions or classes from a package, LAMMPS must have
-been compiled with that package included.
+If plugins access functions or classes from a package, LAMMPS must
+have been compiled with that package included.
 
 Plugins are dependent on the LAMMPS binary interface (ABI)
 and particularly the MPI library used. So they are not guaranteed

doc/src/region.rst

@@ -371,26 +371,13 @@ sub-regions can be defined with the *open* keyword.
 
 ----------
 
-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.
+.. include:: accel_styles.rst
 
-The code using the region (such as a fix or compute) must also be supported
-by Kokkos or no acceleration will occur. Currently, only *block* style
-regions are supported by Kokkos.
+.. note::
 
-These accelerated styles are part of the 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.
+  Currently, only *block* style regions are supported by Kokkos.  The
+  code using the region (such as a fix or compute) must also be
+  supported by Kokkos or no acceleration will occur.
 
 ----------
 

doc/src/run_style.rst

@@ -125,12 +125,13 @@ screen.0 by default; see the :doc:`-plog and -pscreen command-line switches <Run
 for the second partition will not contain thermodynamic output beyond the
 first timestep of the run.
 
-See the :doc:`Speed packages <Speed_packages>` page for performance
-details of the speed-up offered by the *verlet/split* style.  One
-important performance consideration is the assignment of logical
-processors in the 2 partitions to the physical cores of a parallel
-machine.  The :doc:`processors <processors>` command has options to
-support this, and strategies are discussed in :doc:`Section 5 <Speed>` of the manual.
+See the :doc:`Accelerator packages <Speed_packages>` page for
+performance details of the speed-up offered by the *verlet/split*
+style.  One important performance consideration is the assignment of
+logical processors in the 2 partitions to the physical cores of a
+parallel machine.  The :doc:`processors <processors>` command has
+options to support this, and strategies are discussed in :doc:`Section
+5 <Speed>` of the manual.
 
 ----------
 
@@ -295,10 +296,10 @@ except for round-off and precision issues.
 
 You can specify *respa/omp* explicitly in your input script, 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.
+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
+See the :doc:`Accelerator packages <Speed_packages>` page for more
 instructions on how to use the accelerated styles effectively.
 
 ----------
@@ -308,7 +309,8 @@ Restrictions
 
 The *verlet/split* style can only be used if LAMMPS was built with the
 REPLICA package. Correspondingly the *respa/omp* style is available
-only if the OPENMP package was included. See the :doc:`Build package <Build_package>` page for more info.
+only if the OPENMP package was included. See the :doc:`Build package
+<Build_package>` page for more info.
 
 Whenever using rRESPA, the user should experiment with trade-offs in
 speed and accuracy for their system, and verify that they are

doc/utils/check-styles.py

@@ -254,7 +254,7 @@ for command_type, entries in index.items():
 
 print("Total number of style index entries:", total_index)
 
-skip_fix = ('python', 'NEIGH_HISTORY/omp','qeq/reax','reax/c/bonds','reax/c/species')
+skip_fix = ('python', 'NEIGH_HISTORY/omp','acks2/reax','qeq/reax','reax/c/bonds','reax/c/species')
 skip_pair = ('meam/c','lj/sf','reax/c')
 
 counter = 0
@@ -282,7 +282,7 @@ if counter:
 counter = 0
 
 counter += check_style_index("compute", compute, index["compute"])
-counter += check_style_index("fix", fix, index["fix"], skip=['python','qeq/reax','reax/c/bonds','reax/c/species'])
+counter += check_style_index("fix", fix, index["fix"], skip=['python','acks2/reax','qeq/reax','reax/c/bonds','reax/c/species'])
 counter += check_style_index("angle_style", angle, index["angle_style"])
 counter += check_style_index("bond_style", bond, index["bond_style"])
 counter += check_style_index("dihedral_style", dihedral, index["dihedral_style"])

doc/utils/requirements.txt

@@ -1,7 +1,7 @@
-Sphinx==4.0.3
-sphinxcontrib-spelling==7.2.1
+Sphinx
+sphinxcontrib-spelling
 git+git://github.com/akohlmey/sphinx-fortran@parallel-read
-sphinx_tabs==3.2.0
-breathe==4.31.0
-Pygments==2.10.0
-six==1.16.0
+sphinx_tabs
+breathe
+Pygments
+six

doc/utils/sphinx-config/false_positives.txt

@@ -19,6 +19,7 @@ accuracies
 ach
 ackland
 Ackland
+acks
 acolor
 acos
 Acta
@@ -77,6 +78,7 @@ allocators
 allosws
 AlO
 Alonso
+Alperen
 alphak
 alphashrink
 amap
@@ -685,6 +687,7 @@ diagonalized
 diagonalizers
 diagonalizing
 Diallo
+diblock
 Dickel
 diel
 differentiable
@@ -1135,6 +1138,7 @@ Germann
 Germano
 gerolf
 Gerolf
+getrusage
 Gershgorin
 getter
 gettimeofday
@@ -1222,6 +1226,7 @@ Guo
 gw
 gyromagnetic
 gz
+gzip
 gzipped
 Haak
 Hafskjold
@@ -1252,6 +1257,7 @@ hbond
 hcp
 hdnnp
 HDNNP
+Hearn
 heatconduction
 Hebbeker
 Hebenstreit
@@ -1278,6 +1284,7 @@ hgrid
 hhmrr
 Hibbs
 Higdon
+hiID
 Hijazi
 Hilger
 Hinestrosa
@@ -1774,6 +1781,7 @@ Loewen
 logfile
 logfreq
 logicals
+loID
 Lomdahl
 Lond
 lookup
@@ -1809,6 +1817,7 @@ lyon
 Lysogorskiy
 Lyulin
 lz
+lzma
 Maaravi
 MACHDYN
 machdyn
@@ -2262,6 +2271,7 @@ Nmols
 nn
 nnodes
 Nocedal
+nO
 nocite
 nocoeff
 nodeless
@@ -2761,6 +2771,7 @@ REAXFF
 ReaxFF
 reaxff
 rebo
+recurse
 recursing
 Ree
 refactored
@@ -3075,6 +3086,7 @@ Spearot
 specular
 spellcheck
 Spellmeyer
+Speybroeck
 sph
 SPH
 Spickermann
@@ -3440,6 +3452,7 @@ usec
 uSemiParallel
 userguide
 username
+usleep
 usr
 util
 utils
@@ -3487,6 +3500,7 @@ Verlag
 verlet
 Verlet
 versa
+Verstraelen
 ves
 vflag
 vhi
@@ -3553,6 +3567,7 @@ vzcm
 vzi
 Waals
 Wadley
+Waroquier
 wallstyle
 walltime
 Waltham
@@ -3657,6 +3672,7 @@ Yc
 ycm
 Yeh
 yellowgreen
+yEs
 Yethiraj
 yflag
 yhi

examples/README

@@ -75,7 +75,6 @@ eim:      NaCl using the EIM potential
 ellipse:  ellipsoidal particles in spherical solvent, 2d system
 flow:     Couette and Poiseuille flow in a 2d channel
 friction: frictional contact of spherical asperities between 2d surfaces
-gcmc:     Grand Canonical MC with fix gcmc, Widom insertion with fix widom
 gjf:      use of fix langevin Gronbech-Jensen/Farago option
 granregion: use of fix wall/region/gran as boundary on granular particles
 hugoniostat: Hugoniostat shock dynamics
@@ -83,6 +82,7 @@ hyper:    global and local hyperdynamics of diffusion on Pt surface
 indent:   spherical indenter into a 2d solid
 kim:      use of potentials in Knowledge Base for Interatomic Models (KIM)
 latte:    use of LATTE density-functional tight-binding quantum code
+mc:       MC package models: GCMC, Widom, fix mol/swap
 meam:     MEAM test for SiC and shear (same as shear examples)
 melt:     rapid melt of 3d LJ system
 message:  client/server coupling of 2 codes
@@ -167,7 +167,7 @@ The KAPPA directory has example scripts for computing the thermal
 conductivity (kappa) of a LJ liquid using 5 different methods.  See
 the KAPPA/README file for more info.
 
-The MC directory has an example script for using LAMMPS as an
+The MC-LOOP directory has an example script for using LAMMPS as an
 energy-evaluation engine in a iterative Monte Carlo energy-relaxation
 loop.
 

examples/mc/in.mixed

@@ -0,0 +1,44 @@
+# test script for fix mol/swap
+# initial system is 50/50 chains of type 1 and type 2
+# b/c epsilon12 is set to 1.02 (weakly same as 1/1 or 1/2) the
+#   system will stay in equilibrium as a mix of both chain types
+# fix mol/swap helps this happen quickly
+# see the last 2 columns of thermo output for counts of 2 chain types
+
+units              lj
+atom_style         angle
+neighbor           0.36 bin
+neigh_modify       delay 0
+
+pair_style         lj/cut 1.1224620483
+bond_style         fene
+angle_style        cosine
+special_bonds      lj 0.0 1.0 1.0
+
+read_data          data.bead
+
+pair_coeff         * * 1.0 1.0 1.1224620483
+pair_coeff         1 2 1.02 1.0 1.1224620483
+bond_coeff         1 30.0 1.5 1.0 1.0
+angle_coeff        1 1.500
+pair_modify        shift yes
+
+variable           vt1 atom type==1
+variable           vt2 atom type==2
+group              g1 dynamic all var vt1 every 100
+group              g2 dynamic all var vt2 every 100
+variable           count1 equal count(g1)
+variable           count2 equal count(g2)
+
+timestep           0.010
+
+fix                1 all langevin 1.0 1.0 100.0 702547
+fix                2 all nve
+fix                3 all mol/swap 100 1 1 2 482794 1.0
+
+compute            p all pressure thermo_temp
+thermo             1000
+thermo_style       custom step temp etotal press f_3[1] f_3[2] v_count1 v_count2
+
+run                50000
+

examples/mc/in.pure

@@ -0,0 +1,44 @@
+# test script for fix mol/swap
+# initial system is 50/50 chains of type 1 and type 2
+# b/c epsilon12 is set to 1.1 (stronger than 1/1 or 2/2) the
+#   system will go to equilibrium as mostly one type or the other
+# fix mol/swap helps this happen quickly
+# see the last 2 columns of thermo output for counts of 2 chain types
+
+units              lj
+atom_style         angle
+neighbor           0.36 bin
+neigh_modify       delay 0
+
+pair_style         lj/cut 1.1224620483
+bond_style         fene
+angle_style        cosine
+special_bonds      lj 0.0 1.0 1.0
+
+read_data          data.bead
+
+pair_coeff         * * 1.0 1.0 1.1224620483
+pair_coeff         1 2 1.1 1.0 1.1224620483
+bond_coeff         1 30.0 1.5 1.0 1.0
+angle_coeff        1 1.500
+pair_modify        shift yes
+
+variable           vt1 atom type==1
+variable           vt2 atom type==2
+group              g1 dynamic all var vt1 every 100
+group              g2 dynamic all var vt2 every 100
+variable           count1 equal count(g1)
+variable           count2 equal count(g2)
+
+timestep           0.010
+
+fix                1 all langevin 1.0 1.0 100.0 702547
+fix                2 all nve
+fix                3 all mol/swap 100 1 1 2 482794 1.0
+
+compute            p all pressure thermo_temp
+thermo             1000
+thermo_style       custom step temp etotal press f_3[1] f_3[2] v_count1 v_count2
+
+run                50000
+

examples/mc/log.13Oct21.mixed.g++.4

@@ -0,0 +1,164 @@
+LAMMPS (29 Sep 2021)
+# test script for fix mol/swap
+# initial system is 50/50 chains of type 1 and type 2
+# b/c epsilon12 is set to 1.02 (weakly same as 1/1 or 1/2) the
+#   system will stay in equilibrium as a mix of both chain types
+# fix mol/swap helps this happen quickly
+# see the last 2 columns of thermo output for counts of 2 chain types
+
+units              lj
+atom_style         angle
+neighbor           0.36 bin
+neigh_modify       delay 0
+
+pair_style         lj/cut 1.1224620483
+bond_style         fene
+angle_style        cosine
+special_bonds	   lj 0.0 1.0 1.0
+
+read_data          data.bead
+Reading data file ...
+  orthogonal box = (-8.2115700 -8.2115700 -8.2115700) to (8.2115700 8.2115700 8.2115700)
+  1 by 2 by 2 MPI processor grid
+  reading atoms ...
+  4000 atoms
+  scanning bonds ...
+  1 = max bonds/atom
+  scanning angles ...
+  1 = max angles/atom
+  reading bonds ...
+  3900 bonds
+  reading angles ...
+  3800 angles
+Finding 1-2 1-3 1-4 neighbors ...
+  special bond factors lj:    0        1        1       
+  special bond factors coul:  0        0        0       
+     2 = max # of 1-2 neighbors
+     2 = max # of 1-3 neighbors
+     4 = max # of 1-4 neighbors
+     6 = max # of special neighbors
+  special bonds CPU = 0.001 seconds
+  read_data CPU = 0.028 seconds
+
+pair_coeff         * * 1.0 1.0 1.1224620483
+pair_coeff         1 2 1.02 1.0 1.1224620483
+bond_coeff         1 30.0 1.5 1.0 1.0
+angle_coeff        1 1.500
+pair_modify 	   shift yes
+
+variable           vt1 atom type==1
+variable           vt2 atom type==2
+group              g1 dynamic all var vt1 every 100
+dynamic group g1 defined
+group              g2 dynamic all var vt2 every 100
+dynamic group g2 defined
+variable           count1 equal count(g1)
+variable           count2 equal count(g2)
+
+timestep	   0.010
+
+fix                1 all langevin 1.0 1.0 100.0 702547
+fix                2 all nve
+fix                3 all mol/swap 100 1 1 2 482794 1.0
+
+compute            p all pressure thermo_temp
+thermo             1000
+thermo_style       custom step temp etotal press f_3[1] f_3[2] v_count1 v_count2
+
+run                50000
+Neighbor list info ...
+  update every 1 steps, delay 0 steps, check yes
+  max neighbors/atom: 2000, page size: 100000
+  master list distance cutoff = 1.482462
+  ghost atom cutoff = 1.482462
+  binsize = 0.74123102, bins = 23 23 23
+  1 neighbor lists, perpetual/occasional/extra = 1 0 0
+  (1) pair lj/cut, perpetual
+      attributes: half, newton on
+      pair build: half/bin/newton
+      stencil: half/bin/3d
+      bin: standard
+WARNING: Communication cutoff 1.4824620483 is shorter than a bond length based estimate of 1.815. This may lead to errors. (../comm.cpp:728)
+Per MPI rank memory allocation (min/avg/max) = 5.313 | 5.314 | 5.314 Mbytes
+Step Temp TotEng Press f_3[1] f_3[2] v_count1 v_count2 
+       0            0    21.451627     5.079399            0            0         2000         2000 
+    1000   0.49011138     21.59359    4.2337989           10           10         2000         2000 
+    2000   0.55288866    21.724374    4.4596786           20           20         2080         1920 
+    3000   0.59299724    21.844178    4.6112243           30           29         2280         1720 
+    4000   0.64746348    21.964318    4.9463669           40           39         2280         1720 
+    5000   0.67853936    22.053147    5.1950218           50           48         2320         1680 
+    6000   0.70751144    22.147453    5.0636869           60           58         2240         1760 
+    7000   0.73570064    22.233705    5.4872622           70           68         2160         1840 
+    8000    0.7677554    22.312938    5.4283736           80           77         2360         1640 
+    9000   0.78493237    22.383155    5.8547233           90           87         2440         1560 
+   10000   0.80634514    22.449402    5.8785731          100           96         2400         1600 
+   11000   0.82563194    22.475286    5.8193738          110          104         2400         1600 
+   12000   0.81684024    22.527492    6.0323967          120          114         2320         1680 
+   13000   0.84497155    22.567888    6.0488755          130          122         2240         1760 
+   14000   0.85452242    22.606908    6.1983634          140          132         2080         1920 
+   15000   0.88109242    22.654336    6.1408279          150          141         1960         2040 
+   16000   0.88925915    22.707597    6.1560975          160          150         2000         2000 
+   17000   0.91598439    22.762791    6.1071728          170          160         2000         2000 
+   18000   0.92453211    22.778304    6.3330693          180          170         2240         1760 
+   19000   0.92839551    22.797316    6.2917909          190          180         2000         2000 
+   20000   0.93054033    22.819289     6.091701          200          189         2200         1800 
+   21000   0.93955351    22.844135    6.5833013          210          198         2000         2000 
+   22000   0.94454858    22.856272    6.5661753          220          207         2200         1800 
+   23000   0.95446407    22.878735    6.5957294          230          216         2160         1840 
+   24000   0.94748257    22.894539    6.6187447          240          226         1920         2080 
+   25000   0.95732202    22.912292    6.4795471          250          236         1680         2320 
+   26000   0.96970172    22.908988     6.537366          260          245         1720         2280 
+   27000   0.96032166    22.924899    6.6238248          270          255         1960         2040 
+   28000   0.96197769      22.9358    6.8926097          280          264         1920         2080 
+   29000   0.98745595    22.964694    6.5839025          290          271         2040         1960 
+   30000   0.99264869    22.947884    6.3893499          300          280         1920         2080 
+   31000   0.96953069    22.957927    6.6616047          310          289         1800         2200 
+   32000   0.99955117    22.963979    6.5958456          320          298         1680         2320 
+   33000   0.97090103    22.969029    6.9087296          330          307         1800         2200 
+   34000   0.99818457    22.988477    6.6471994          340          316         1920         2080 
+   35000    0.9965288    22.992883    6.9691785          350          325         2040         1960 
+   36000   0.99533174    22.983774    6.6585089          360          334         2000         2000 
+   37000   0.98819278    22.995387     6.618802          370          344         2080         1920 
+   38000   0.99598576    22.991892    6.7536669          380          354         2080         1920 
+   39000   0.99312702    22.989239    6.4028165          390          364         2080         1920 
+   40000    1.0035821    23.001944    6.9307671          400          374         1920         2080 
+   41000   0.99914733     23.00134    6.6251677          410          383         1880         2120 
+   42000   0.98054536    22.981781    6.5918554          420          393         1880         2120 
+   43000   0.99413829       23.008    6.7390795          430          403         1720         2280 
+   44000   0.98867961     23.00521    6.8505543          440          412         1600         2400 
+   45000   0.99626811    23.019995     6.827741          450          421         1640         2360 
+   46000    1.0186043    23.020759    6.6195562          460          430         1680         2320 
+   47000    1.0121335    23.019271    6.6022102          470          439         1800         2200 
+   48000   0.99883756    23.013973    6.5255522          480          448         1920         2080 
+   49000   0.99425223    23.022708     6.609746          490          458         2240         1760 
+   50000   0.99505489    23.012641    6.4592863          500          468         2240         1760 
+Loop time of 19.4175 on 4 procs for 50000 steps with 4000 atoms
+
+Performance: 2224796.830 tau/day, 2574.996 timesteps/s
+95.0% CPU use with 4 MPI tasks x no OpenMP threads
+
+MPI task timing breakdown:
+Section |  min time  |  avg time  |  max time  |%varavg| %total
+---------------------------------------------------------------
+Pair    | 2.5467     | 2.6684     | 2.7896     |   6.3 | 13.74
+Bond    | 2.3037     | 2.4117     | 2.5085     |   5.3 | 12.42
+Neigh   | 7.3597     | 7.3633     | 7.3673     |   0.1 | 37.92
+Comm    | 3.0482     | 3.2694     | 3.4997     |  10.2 | 16.84
+Output  | 0.0014609  | 0.0017069  | 0.0021793  |   0.7 |  0.01
+Modify  | 2.9624     | 3.0581     | 3.1424     |   4.7 | 15.75
+Other   |            | 0.6447     |            |       |  3.32
+
+Nlocal:        1000.00 ave        1013 max         986 min
+Histogram: 1 0 0 1 0 0 0 1 0 1
+Nghost:        1186.25 ave        1198 max        1178 min
+Histogram: 2 0 0 0 0 0 1 0 0 1
+Neighs:        4927.00 ave        5028 max        4790 min
+Histogram: 1 0 0 0 0 1 0 1 0 1
+
+Total # of neighbors = 19708
+Ave neighs/atom = 4.9270000
+Ave special neighs/atom = 5.7000000
+Neighbor list builds = 10721
+Dangerous builds = 0
+
+Total wall time: 0:00:19

examples/mc/log.13Oct21.pure.g++.4

@@ -0,0 +1,164 @@
+LAMMPS (29 Sep 2021)
+# test script for fix mol/swap
+# initial system is 50/50 chains of type 1 and type 2
+# b/c epsilon12 is set to 1.1 (stronger than 1/1 or 2/2) the
+#   system will go to equilibrium as mostly one type or the other
+# fix mol/swap helps this happen quickly
+# see the last 2 columns of thermo output for counts of 2 chain types
+
+units              lj
+atom_style         angle
+neighbor           0.36 bin
+neigh_modify       delay 0
+
+pair_style         lj/cut 1.1224620483
+bond_style         fene
+angle_style        cosine
+special_bonds	   lj 0.0 1.0 1.0
+
+read_data          data.bead
+Reading data file ...
+  orthogonal box = (-8.2115700 -8.2115700 -8.2115700) to (8.2115700 8.2115700 8.2115700)
+  1 by 2 by 2 MPI processor grid
+  reading atoms ...
+  4000 atoms
+  scanning bonds ...
+  1 = max bonds/atom
+  scanning angles ...
+  1 = max angles/atom
+  reading bonds ...
+  3900 bonds
+  reading angles ...
+  3800 angles
+Finding 1-2 1-3 1-4 neighbors ...
+  special bond factors lj:    0        1        1       
+  special bond factors coul:  0        0        0       
+     2 = max # of 1-2 neighbors
+     2 = max # of 1-3 neighbors
+     4 = max # of 1-4 neighbors
+     6 = max # of special neighbors
+  special bonds CPU = 0.001 seconds
+  read_data CPU = 0.034 seconds
+
+pair_coeff         * * 1.0 1.0 1.1224620483
+pair_coeff         1 2 1.1 1.0 1.1224620483
+bond_coeff         1 30.0 1.5 1.0 1.0
+angle_coeff        1 1.500
+pair_modify 	   shift yes
+
+variable           vt1 atom type==1
+variable           vt2 atom type==2
+group              g1 dynamic all var vt1 every 100
+dynamic group g1 defined
+group              g2 dynamic all var vt2 every 100
+dynamic group g2 defined
+variable           count1 equal count(g1)
+variable           count2 equal count(g2)
+
+timestep	   0.010
+
+fix                1 all langevin 1.0 1.0 100.0 702547
+fix                2 all nve
+fix                3 all mol/swap 100 1 1 2 482794 1.0
+
+compute            p all pressure thermo_temp
+thermo             1000
+thermo_style       custom step temp etotal press f_3[1] f_3[2] v_count1 v_count2
+
+run                50000
+Neighbor list info ...
+  update every 1 steps, delay 0 steps, check yes
+  max neighbors/atom: 2000, page size: 100000
+  master list distance cutoff = 1.482462
+  ghost atom cutoff = 1.482462
+  binsize = 0.74123102, bins = 23 23 23
+  1 neighbor lists, perpetual/occasional/extra = 1 0 0
+  (1) pair lj/cut, perpetual
+      attributes: half, newton on
+      pair build: half/bin/newton
+      stencil: half/bin/3d
+      bin: standard
+WARNING: Communication cutoff 1.4824620483 is shorter than a bond length based estimate of 1.815. This may lead to errors. (../comm.cpp:728)
+Per MPI rank memory allocation (min/avg/max) = 5.313 | 5.314 | 5.314 Mbytes
+Step Temp TotEng Press f_3[1] f_3[2] v_count1 v_count2 
+       0            0      21.4699     5.230121            0            0         2000         2000 
+    1000   0.50228459     21.61044    4.3659303           10            9         1960         2040 
+    2000   0.55721903     21.75955    4.5695439           20           17         1960         2040 
+    3000   0.61139287    21.892943    4.6514755           30           26         2240         1760 
+    4000   0.65767189    22.002303    5.1854503           40           33         2280         1720 
+    5000   0.69383416    22.110271    5.3803498           50           41         2280         1720 
+    6000   0.72692038    22.205887    5.1756569           60           49         2280         1720 
+    7000   0.77151336    22.306777    5.5743555           70           56         2240         1760 
+    8000   0.78606858     22.37036    5.7745208           80           64         2560         1440 
+    9000   0.79363653    22.420931    5.7369418           90           71         2680         1320 
+   10000   0.82352629    22.488759    6.0238896          100           76         2720         1280 
+   11000   0.83867685    22.534887    6.1263771          110           82         2800         1200 
+   12000   0.85335127    22.590281    6.1499954          120           86         2800         1200 
+   13000   0.86430985    22.632068    6.1654016          130           89         2760         1240 
+   14000   0.88057592    22.680253    6.2162735          140           94         2800         1200 
+   15000   0.89326694    22.719731    6.4789839          150           97         2760         1240 
+   16000   0.90667644    22.737367     6.214481          160          101         2760         1240 
+   17000   0.91190336    22.758572    6.2293336          170          105         2600         1400 
+   18000   0.93182455    22.782019    6.2865382          180          111         2680         1320 
+   19000   0.93002139    22.797048    6.5579988          190          117         2600         1400 
+   20000   0.92396243    22.796108    6.6207461          200          122         2800         1200 
+   21000   0.92949808    22.802813    6.3753268          210          125         2920         1080 
+   22000   0.93415719    22.807112    6.4696121          220          130         3040          960 
+   23000    0.9214833     22.82116    6.4146288          230          131         3080          920 
+   24000   0.95693685    22.839738    6.4035728          240          135         2920         1080 
+   25000   0.95421851    22.865199    6.4510751          250          138         2880         1120 
+   26000   0.95476555    22.878082    6.4652888          260          145         3000         1000 
+   27000   0.95773535    22.880671     6.757952          270          149         3000         1000 
+   28000   0.95405332    22.896053    6.7425175          280          155         3080          920 
+   29000   0.95955713    22.904144    6.6672832          290          161         3240          760 
+   30000   0.95521498    22.886699    6.6197941          300          164         3360          640 
+   31000   0.96431176     22.91094    6.6373887          310          168         3440          560 
+   32000   0.96592495    22.903679    6.4245884          320          172         3520          480 
+   33000   0.96457971    22.922681    6.6987987          330          175         3480          520 
+   34000   0.96541889     22.92116    6.5992755          340          178         3600          400 
+   35000   0.96892691    22.923361    6.7973298          350          178         3600          400 
+   36000   0.97267726    22.923431    6.6577403          360          179         3640          360 
+   37000   0.97514714    22.939979    6.4028068          370          183         3640          360 
+   38000   0.98638599    22.952022    6.6518868          380          183         3640          360 
+   39000   0.97864891    22.962534    6.3906837          390          184         3680          320 
+   40000    0.9933016    22.975785    6.6819613          400          185         3720          280 
+   41000    0.9861477    22.977271    6.6747347          410          187         3800          200 
+   42000   0.98157369    22.963129     6.830028          420          187         3800          200 
+   43000   0.98202452    22.966947    6.5257905          430          187         3800          200 
+   44000   0.99540503    22.971262    6.5546513          440          187         3800          200 
+   45000   0.98433653    22.978028    6.4316725          450          189         3800          200 
+   46000   0.97912775    22.981328    6.9139851          460          189         3800          200 
+   47000    0.9791927    22.981131    6.6417971          470          190         3840          160 
+   48000   0.99601024    22.998536    6.6756953          480          191         3880          120 
+   49000   0.99589958    22.998489    6.9262843          490          191         3880          120 
+   50000   0.99294715     23.00399    6.6976013          500          192         3920           80 
+Loop time of 19.5161 on 4 procs for 50000 steps with 4000 atoms
+
+Performance: 2213556.537 tau/day, 2561.987 timesteps/s
+95.0% CPU use with 4 MPI tasks x no OpenMP threads
+
+MPI task timing breakdown:
+Section |  min time  |  avg time  |  max time  |%varavg| %total
+---------------------------------------------------------------
+Pair    | 2.6256     | 2.7183     | 2.8265     |   5.2 | 13.93
+Bond    | 2.3363     | 2.4406     | 2.5197     |   4.8 | 12.51
+Neigh   | 7.382      | 7.3884     | 7.3936     |   0.2 | 37.86
+Comm    | 3.014      | 3.2136     | 3.3994     |   9.4 | 16.47
+Output  | 0.0014574  | 0.0017086  | 0.0020613  |   0.5 |  0.01
+Modify  | 3.0282     | 3.1295     | 3.2034     |   4.1 | 16.04
+Other   |            | 0.624      |            |       |  3.20
+
+Nlocal:        1000.00 ave        1011 max         993 min
+Histogram: 2 0 0 0 0 1 0 0 0 1
+Nghost:        1187.25 ave        1202 max        1179 min
+Histogram: 2 0 0 1 0 0 0 0 0 1
+Neighs:        4939.25 ave        5067 max        4850 min
+Histogram: 1 0 0 2 0 0 0 0 0 1
+
+Total # of neighbors = 19757
+Ave neighs/atom = 4.9392500
+Ave special neighs/atom = 5.7000000
+Neighbor list builds = 10714
+Dangerous builds = 0
+
+Total wall time: 0:00:19

examples/plugins/CMakeLists.txt

@@ -14,6 +14,15 @@ endif()
 
 project(plugins VERSION 1.0 LANGUAGES CXX)
 
+# 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
+if(MSVC)
+  add_compile_options(/Zc:__cplusplus)
+  add_compile_options(/wd4244)
+  add_compile_options(/wd4267)
+  add_compile_definitions(_CRT_SECURE_NO_WARNINGS)
+endif()
+
 # NOTE: the next line should be commented out when used outside of the LAMMPS package
 get_filename_component(LAMMPS_SOURCE_DIR ${PROJECT_SOURCE_DIR}/../../src ABSOLUTE)
 set(LAMMPS_HEADER_DIR ${LAMMPS_SOURCE_DIR} CACHE PATH "Location of LAMMPS headers")
@@ -32,15 +41,10 @@ set(CMAKE_CXX_STANDARD 11)
 set(CMAKE_CXX_STANDARD_REQUIRED ON)
 
 # Need -restrict with Intel compilers
-if((CMAKE_CXX_COMPILER_ID STREQUAL "Intel") OR (CMAKE_CXX_COMPILER_ID STREQUAL "IntelLLVM"))
+if(CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
   set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -restrict")
 endif()
 
-# bail out on windows
-if(CMAKE_SYSTEM_NAME STREQUAL Windows)
-  message(FATAL_ERROR "LAMMPS plugins are currently not supported on Windows")
-endif()
-
 set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR})
 include(CheckIncludeFileCXX)
 include(LAMMPSInterfaceCXX)
@@ -62,12 +66,21 @@ add_library(zero2plugin MODULE zero2plugin.cpp pair_zero2.cpp bond_zero2.cpp
                                angle_zero2.cpp dihedral_zero2.cpp improper_zero2.cpp)
 target_link_libraries(zero2plugin PRIVATE lammps)
 
-set_target_properties(morse2plugin nve2plugin helloplugin zero2plugin PROPERTIES
-                      PREFIX ""
-                      LINK_FLAGS "-rdynamic")
+set_target_properties(morse2plugin nve2plugin helloplugin zero2plugin PROPERTIES PREFIX "")
 
 # MacOS seems to need this
 if(CMAKE_SYSTEM_NAME STREQUAL Darwin)
+  set_target_properties(morse2plugin nve2plugin helloplugin zero2plugin
+    PROPERTIES LINK_FLAGS "-Wl,-undefined,dynamic_lookup")
+elseif(CMAKE_SYSTEM_NAME STREQUAL "Windows")
+# tell CMake to export all symbols to a .dll on Windows with special case for MinGW cross-compilers
+  set_target_properties(morse2plugin nve2plugin helloplugin zero2plugin
+    PROPERTIES WINDOWS_EXPORT_ALL_SYMBOLS TRUE)
+  if(CMAKE_CROSSCOMPILING)
+    set_target_properties(morse2plugin nve2plugin helloplugin zero2plugin
+      PROPERTIES LINK_FLAGS "-Wl,--export-all-symbols")
+  endif()
+else()
   set_target_properties(morse2plugin nve2plugin helloplugin zero2plugin PROPERTIES
-                        LINK_FLAGS "-Wl,-undefined,dynamic_lookup")
+    LINK_FLAGS "-rdynamic")
 endif()