Merge branch 'lammps:develop' into mliappy_unified

.github/dependabot.yml

@@ -0,0 +1,6 @@
+version: 2
+updates:
+  - package-ecosystem: "github-actions"
+    directory: "/"
+    schedule:
+      interval: "weekly"

.github/workflows/codeql-analysis.yml

@@ -5,12 +5,19 @@ on:
   push:
     branches: [develop]
 
+  workflow_dispatch:
+
 jobs:
   analyze:
     name: Analyze
     if: ${{ github.repository == 'lammps/lammps' }}
     runs-on: ubuntu-latest
 
+    permissions:
+      security-events: write
+      actions: read
+      contents: read
+
     strategy:
       fail-fast: false
       matrix:
@@ -18,17 +25,17 @@ jobs:
 
     steps:
     - name: Checkout repository
-      uses: actions/checkout@v2
+      uses: actions/checkout@v3
       with:
         fetch-depth: 2
 
     - name: Setup Python
-      uses: actions/setup-python@v2
+      uses: actions/setup-python@v4
       with:
         python-version: '3.x'
 
     - name: Initialize CodeQL
-      uses: github/codeql-action/init@v1
+      uses: github/codeql-action/init@v2
       with:
         languages: ${{ matrix.language }}
         config-file: ./.github/codeql/${{ matrix.language }}.yml
@@ -46,4 +53,4 @@ jobs:
         cmake --build . --parallel 2
 
     - name: Perform CodeQL Analysis
-      uses: github/codeql-action/analyze@v1
+      uses: github/codeql-action/analyze@v2

.github/workflows/compile-msvc.yml

@@ -5,6 +5,8 @@ on:
   push:
     branches: [develop]
 
+  workflow_dispatch:
+
 jobs:
   build:
     name: Windows Compilation Test
@@ -13,12 +15,12 @@ jobs:
 
     steps:
     - name: Checkout repository
-      uses: actions/checkout@v2
+      uses: actions/checkout@v3
       with:
         fetch-depth: 2
 
     - name: Select Python version
-      uses: actions/setup-python@v2
+      uses: actions/setup-python@v4
       with:
         python-version: '3.10'
 

.github/workflows/unittest-macos.yml

@@ -5,6 +5,8 @@ on:
   push:
     branches: [develop]
 
+  workflow_dispatch:
+
 jobs:
   build:
     name: MacOS Unit Test
@@ -15,7 +17,7 @@ jobs:
 
     steps:
     - name: Checkout repository
-      uses: actions/checkout@v2
+      uses: actions/checkout@v3
       with:
         fetch-depth: 2
 
@@ -26,7 +28,7 @@ jobs:
       run: mkdir build
 
     - name: Set up ccache
-      uses: actions/cache@v2
+      uses: actions/cache@v3
       with:
         path: ${{ env.CCACHE_DIR }}
         key: macos-ccache-${{ github.sha }}

cmake/CMakeLists.jpeg

@@ -0,0 +1,615 @@
+cmake_minimum_required(VERSION 3.10)
+# When using CMake 3.4 and later, don't export symbols from executables unless
+# the CMAKE_ENABLE_EXPORTS variable is set.
+if(POLICY CMP0065)
+  cmake_policy(SET CMP0065 NEW)
+endif()
+if (POLICY CMP0077)
+  cmake_policy(SET CMP0077 NEW)
+endif()
+if(CMAKE_EXECUTABLE_SUFFIX)
+  set(CMAKE_EXECUTABLE_SUFFIX_TMP ${CMAKE_EXECUTABLE_SUFFIX})
+endif()
+
+project(libjpeg-turbo C)
+set(VERSION 2.1.3)
+set(COPYRIGHT_YEAR "1991-2022")
+string(REPLACE "." ";" VERSION_TRIPLET ${VERSION})
+list(GET VERSION_TRIPLET 0 VERSION_MAJOR)
+list(GET VERSION_TRIPLET 1 VERSION_MINOR)
+list(GET VERSION_TRIPLET 2 VERSION_REVISION)
+function(pad_number NUMBER OUTPUT_LEN)
+  string(LENGTH "${${NUMBER}}" INPUT_LEN)
+  if(INPUT_LEN LESS OUTPUT_LEN)
+    math(EXPR ZEROES "${OUTPUT_LEN} - ${INPUT_LEN} - 1")
+    set(NUM ${${NUMBER}})
+    foreach(C RANGE ${ZEROES})
+      set(NUM "0${NUM}")
+    endforeach()
+    set(${NUMBER} ${NUM} PARENT_SCOPE)
+  endif()
+endfunction()
+pad_number(VERSION_MINOR 3)
+pad_number(VERSION_REVISION 3)
+set(LIBJPEG_TURBO_VERSION_NUMBER ${VERSION_MAJOR}${VERSION_MINOR}${VERSION_REVISION})
+
+# CMake 3.14 and later sets CMAKE_MACOSX_BUNDLE to TRUE by default when
+# CMAKE_SYSTEM_NAME is iOS, tvOS, or watchOS, which breaks the libjpeg-turbo
+# build.  (Specifically, when CMAKE_MACOSX_BUNDLE is TRUE, executables for
+# Apple platforms are built as application bundles, which causes CMake to
+# complain that our install() directives for executables do not specify a
+# BUNDLE DESTINATION.  Even if CMake did not complain, building executables as
+# application bundles would break our iOS packages.)
+set(CMAKE_MACOSX_BUNDLE FALSE)
+
+string(TIMESTAMP DEFAULT_BUILD "%Y%m%d")
+set(BUILD ${DEFAULT_BUILD} CACHE STRING "Build string (default: ${DEFAULT_BUILD})")
+
+# NOTE: On Windows, this does nothing except when using MinGW or Cygwin.
+# CMAKE_BUILD_TYPE has no meaning in Visual Studio, and it always defaults to
+# Debug when using NMake.
+if(NOT CMAKE_BUILD_TYPE)
+  set(CMAKE_BUILD_TYPE Release)
+endif()
+message(STATUS "CMAKE_BUILD_TYPE = ${CMAKE_BUILD_TYPE}")
+
+message(STATUS "VERSION = ${VERSION}, BUILD = ${BUILD}")
+
+include(cmakescripts/PackageInfo.cmake)
+
+# Detect CPU type and whether we're building 64-bit or 32-bit code
+math(EXPR BITS "${CMAKE_SIZEOF_VOID_P} * 8")
+string(TOLOWER ${CMAKE_SYSTEM_PROCESSOR} CMAKE_SYSTEM_PROCESSOR_LC)
+set(COUNT 1)
+foreach(ARCH ${CMAKE_OSX_ARCHITECTURES})
+  if(COUNT GREATER 1)
+    message(FATAL_ERROR "The libjpeg-turbo build system does not support multiple values in CMAKE_OSX_ARCHITECTURES.")
+  endif()
+  math(EXPR COUNT "${COUNT}+1")
+endforeach()
+if(CMAKE_SYSTEM_PROCESSOR_LC MATCHES "x86_64" OR
+  CMAKE_SYSTEM_PROCESSOR_LC MATCHES "amd64" OR
+  CMAKE_SYSTEM_PROCESSOR_LC MATCHES "i[0-9]86" OR
+  CMAKE_SYSTEM_PROCESSOR_LC MATCHES "x86" OR
+  CMAKE_SYSTEM_PROCESSOR_LC MATCHES "ia32")
+  if(BITS EQUAL 64 OR CMAKE_C_COMPILER_ABI MATCHES "ELF X32")
+    set(CPU_TYPE x86_64)
+  else()
+    set(CPU_TYPE i386)
+  endif()
+  if(NOT CMAKE_SYSTEM_PROCESSOR STREQUAL ${CPU_TYPE})
+    set(CMAKE_SYSTEM_PROCESSOR ${CPU_TYPE})
+  endif()
+elseif(CMAKE_SYSTEM_PROCESSOR_LC STREQUAL "aarch64" OR
+  CMAKE_SYSTEM_PROCESSOR_LC MATCHES "^arm")
+  if(BITS EQUAL 64)
+    set(CPU_TYPE arm64)
+  else()
+    set(CPU_TYPE arm)
+  endif()
+elseif(CMAKE_SYSTEM_PROCESSOR_LC MATCHES "^ppc" OR
+  CMAKE_SYSTEM_PROCESSOR_LC MATCHES "^powerpc")
+  set(CPU_TYPE powerpc)
+else()
+  set(CPU_TYPE ${CMAKE_SYSTEM_PROCESSOR_LC})
+endif()
+if(CMAKE_OSX_ARCHITECTURES MATCHES "x86_64" OR
+  CMAKE_OSX_ARCHITECTURES MATCHES "arm64" OR
+  CMAKE_OSX_ARCHITECTURES MATCHES "i386")
+  set(CPU_TYPE ${CMAKE_OSX_ARCHITECTURES})
+endif()
+if(CMAKE_OSX_ARCHITECTURES MATCHES "ppc")
+  set(CPU_TYPE powerpc)
+endif()
+if(MSVC_IDE AND CMAKE_GENERATOR_PLATFORM MATCHES "arm64")
+  set(CPU_TYPE arm64)
+endif()
+
+message(STATUS "${BITS}-bit build (${CPU_TYPE})")
+
+macro(report_directory var)
+  if(CMAKE_INSTALL_${var} STREQUAL CMAKE_INSTALL_FULL_${var})
+    message(STATUS "CMAKE_INSTALL_${var} = ${CMAKE_INSTALL_${var}}")
+  else()
+    message(STATUS "CMAKE_INSTALL_${var} = ${CMAKE_INSTALL_${var}} (${CMAKE_INSTALL_FULL_${var}})")
+  endif()
+  mark_as_advanced(CLEAR CMAKE_INSTALL_${var})
+endmacro()
+
+set(DIRLIST "BINDIR;DATAROOTDIR;DOCDIR;INCLUDEDIR;LIBDIR")
+if(UNIX)
+  list(APPEND DIRLIST "MANDIR")
+endif()
+foreach(dir ${DIRLIST})
+  report_directory(${dir})
+endforeach()
+
+
+###############################################################################
+# CONFIGURATION OPTIONS
+###############################################################################
+
+macro(boolean_number var)
+  if(${var})
+    set(${var} 1 ${ARGN})
+  else()
+    set(${var} 0 ${ARGN})
+  endif()
+endmacro()
+
+option(ENABLE_SHARED "Build shared libraries" FALSE)
+boolean_number(ENABLE_SHARED)
+option(ENABLE_STATIC "Build static libraries" TRUE)
+boolean_number(ENABLE_STATIC)
+option(REQUIRE_SIMD "Generate a fatal error if SIMD extensions are not available for this platform (default is to fall back to a non-SIMD build)" FALSE)
+boolean_number(REQUIRE_SIMD)
+option(WITH_12BIT "Encode/decode JPEG images with 12-bit samples (implies WITH_ARITH_DEC=0 WITH_ARITH_ENC=0 WITH_JAVA=0 WITH_SIMD=0 WITH_TURBOJPEG=0 )" FALSE)
+boolean_number(WITH_12BIT)
+option(WITH_ARITH_DEC "Include arithmetic decoding support when emulating the libjpeg v6b API/ABI" TRUE)
+boolean_number(WITH_ARITH_DEC)
+option(WITH_ARITH_ENC "Include arithmetic encoding support when emulating the libjpeg v6b API/ABI" TRUE)
+boolean_number(WITH_ARITH_ENC)
+if(CMAKE_C_COMPILER_ABI MATCHES "ELF X32")
+  set(WITH_JAVA 0)
+else()
+  option(WITH_JAVA "Build Java wrapper for the TurboJPEG API library (implies ENABLE_SHARED=1)" FALSE)
+  boolean_number(WITH_JAVA)
+endif()
+option(WITH_JPEG7 "Emulate libjpeg v7 API/ABI (this makes ${CMAKE_PROJECT_NAME} backward-incompatible with libjpeg v6b)" FALSE)
+boolean_number(WITH_JPEG7)
+option(WITH_JPEG8 "Emulate libjpeg v8 API/ABI (this makes ${CMAKE_PROJECT_NAME} backward-incompatible with libjpeg v6b)" FALSE)
+boolean_number(WITH_JPEG8)
+option(WITH_MEM_SRCDST "Include in-memory source/destination manager functions when emulating the libjpeg v6b or v7 API/ABI" TRUE)
+boolean_number(WITH_MEM_SRCDST)
+option(WITH_SIMD "Include SIMD extensions, if available for this platform" FALSE)
+boolean_number(WITH_SIMD)
+option(WITH_TURBOJPEG "Include the TurboJPEG API library and associated test programs" FALSE)
+boolean_number(WITH_TURBOJPEG)
+option(WITH_FUZZ "Build fuzz targets" FALSE)
+
+macro(report_option var desc)
+  if(${var})
+    message(STATUS "${desc} enabled (${var} = ${${var}})")
+  else()
+    message(STATUS "${desc} disabled (${var} = ${${var}})")
+  endif()
+endmacro()
+
+if(WITH_JAVA)
+  set(ENABLE_SHARED 1)
+endif()
+
+# Explicitly setting CMAKE_POSITION_INDEPENDENT_CODE=FALSE disables PIC for all
+# targets, which will cause the shared library builds to fail.  Thus, if shared
+# libraries are enabled and CMAKE_POSITION_INDEPENDENT_CODE is explicitly set
+# to FALSE, we need to unset it, thus restoring the default behavior
+# (automatically using PIC for shared library targets.)
+if(DEFINED CMAKE_POSITION_INDEPENDENT_CODE AND
+  NOT CMAKE_POSITION_INDEPENDENT_CODE AND ENABLE_SHARED)
+  unset(CMAKE_POSITION_INDEPENDENT_CODE CACHE)
+endif()
+
+report_option(ENABLE_SHARED "Shared libraries")
+report_option(ENABLE_STATIC "Static libraries")
+
+if(ENABLE_SHARED)
+  set(CMAKE_INSTALL_RPATH ${CMAKE_INSTALL_FULL_LIBDIR})
+endif()
+
+if(WITH_JPEG8 OR WITH_JPEG7)
+  set(WITH_ARITH_ENC 1)
+  set(WITH_ARITH_DEC 1)
+endif()
+if(WITH_JPEG8)
+  set(WITH_MEM_SRCDST 0)
+endif()
+
+if(WITH_12BIT)
+  set(WITH_ARITH_DEC 0)
+  set(WITH_ARITH_ENC 0)
+  set(WITH_JAVA 0)
+  set(WITH_SIMD 0)
+  set(WITH_TURBOJPEG 0)
+  set(BITS_IN_JSAMPLE 12)
+else()
+  set(BITS_IN_JSAMPLE 8)
+endif()
+report_option(WITH_12BIT "12-bit JPEG support")
+
+if(WITH_ARITH_DEC)
+  set(D_ARITH_CODING_SUPPORTED 1)
+endif()
+if(NOT WITH_12BIT)
+  report_option(WITH_ARITH_DEC "Arithmetic decoding support")
+endif()
+
+if(WITH_ARITH_ENC)
+  set(C_ARITH_CODING_SUPPORTED 1)
+endif()
+if(NOT WITH_12BIT)
+  report_option(WITH_ARITH_ENC "Arithmetic encoding support")
+endif()
+
+if(NOT WITH_12BIT)
+  report_option(WITH_TURBOJPEG "TurboJPEG API library")
+  report_option(WITH_JAVA "TurboJPEG Java wrapper")
+endif()
+
+if(WITH_MEM_SRCDST)
+  set(MEM_SRCDST_SUPPORTED 1)
+  set(MEM_SRCDST_FUNCTIONS "global:  jpeg_mem_dest;  jpeg_mem_src;")
+endif()
+if(NOT WITH_JPEG8)
+  report_option(WITH_MEM_SRCDST "In-memory source/destination managers")
+endif()
+
+set(SO_AGE 2)
+if(WITH_MEM_SRCDST)
+  set(SO_AGE 3)
+endif()
+
+if(WITH_JPEG8)
+  set(JPEG_LIB_VERSION 80)
+elseif(WITH_JPEG7)
+  set(JPEG_LIB_VERSION 70)
+else()
+  set(JPEG_LIB_VERSION 62)
+endif()
+
+math(EXPR JPEG_LIB_VERSION_DIV10 "${JPEG_LIB_VERSION} / 10")
+math(EXPR JPEG_LIB_VERSION_MOD10 "${JPEG_LIB_VERSION} % 10")
+if(JPEG_LIB_VERSION STREQUAL "62")
+  set(DEFAULT_SO_MAJOR_VERSION ${JPEG_LIB_VERSION})
+else()
+  set(DEFAULT_SO_MAJOR_VERSION ${JPEG_LIB_VERSION_DIV10})
+endif()
+if(JPEG_LIB_VERSION STREQUAL "80")
+  set(DEFAULT_SO_MINOR_VERSION 2)
+else()
+  set(DEFAULT_SO_MINOR_VERSION 0)
+endif()
+
+# This causes SO_MAJOR_VERSION/SO_MINOR_VERSION to reset to defaults if
+# WITH_JPEG7 or WITH_JPEG8 has changed.
+if((DEFINED WITH_JPEG7_INT AND NOT WITH_JPEG7 EQUAL WITH_JPEG7_INT) OR
+  (DEFINED WITH_JPEG8_INT AND NOT WITH_JPEG8 EQUAL WITH_JPEG8_INT))
+  set(FORCE_SO_VERSION "FORCE")
+endif()
+set(WITH_JPEG7_INT ${WITH_JPEG7} CACHE INTERNAL "")
+set(WITH_JPEG8_INT ${WITH_JPEG8} CACHE INTERNAL "")
+
+set(SO_MAJOR_VERSION ${DEFAULT_SO_MAJOR_VERSION} CACHE STRING
+  "Major version of the libjpeg API shared library (default: ${DEFAULT_SO_MAJOR_VERSION})"
+  ${FORCE_SO_VERSION})
+set(SO_MINOR_VERSION ${DEFAULT_SO_MINOR_VERSION} CACHE STRING
+  "Minor version of the libjpeg API shared library (default: ${DEFAULT_SO_MINOR_VERSION})"
+  ${FORCE_SO_VERSION})
+
+set(JPEG_LIB_VERSION_DECIMAL "${JPEG_LIB_VERSION_DIV10}.${JPEG_LIB_VERSION_MOD10}")
+message(STATUS "Emulating libjpeg API/ABI v${JPEG_LIB_VERSION_DECIMAL} (WITH_JPEG7 = ${WITH_JPEG7}, WITH_JPEG8 = ${WITH_JPEG8})")
+message(STATUS "libjpeg API shared library version = ${SO_MAJOR_VERSION}.${SO_AGE}.${SO_MINOR_VERSION}")
+
+# Because the TurboJPEG API library uses versioned symbols and changes the
+# names of functions whenever they are modified in a backward-incompatible
+# manner, it is always backward-ABI-compatible with itself, so the major and
+# minor SO versions don't change.  However, we increase the middle number (the
+# SO "age") whenever functions are added to the API.
+set(TURBOJPEG_SO_MAJOR_VERSION 0)
+set(TURBOJPEG_SO_AGE 2)
+set(TURBOJPEG_SO_VERSION 0.${TURBOJPEG_SO_AGE}.0)
+
+
+###############################################################################
+# COMPILER SETTINGS
+###############################################################################
+
+if(MSVC)
+  option(WITH_CRT_DLL
+    "Link all ${CMAKE_PROJECT_NAME} libraries and executables with the C run-time DLL (msvcr*.dll) instead of the static C run-time library (libcmt*.lib.)  The default is to use the C run-time DLL only with the libraries and executables that need it."
+    FALSE)
+  if(NOT WITH_CRT_DLL)
+    # Use the static C library for all build types
+    foreach(var CMAKE_C_FLAGS CMAKE_C_FLAGS_DEBUG CMAKE_C_FLAGS_RELEASE
+      CMAKE_C_FLAGS_MINSIZEREL CMAKE_C_FLAGS_RELWITHDEBINFO)
+      if(${var} MATCHES "/MD")
+        string(REGEX REPLACE "/MD" "/MT" ${var} "${${var}}")
+      endif()
+    endforeach()
+  endif()
+  add_definitions(-D_CRT_NONSTDC_NO_WARNINGS)
+endif()
+
+if(CMAKE_COMPILER_IS_GNUCC OR CMAKE_C_COMPILER_ID STREQUAL "Clang")
+  # Use the maximum optimization level for release builds
+  foreach(var CMAKE_C_FLAGS_RELEASE CMAKE_C_FLAGS_RELWITHDEBINFO)
+    if(${var} MATCHES "-O2")
+      string(REGEX REPLACE "-O2" "-O3" ${var} "${${var}}")
+    endif()
+  endforeach()
+endif()
+
+if(CMAKE_SYSTEM_NAME STREQUAL "SunOS")
+  if(CMAKE_C_COMPILER_ID MATCHES "SunPro")
+    # Use the maximum optimization level for release builds
+    foreach(var CMAKE_C_FLAGS_RELEASE CMAKE_C_FLAGS_RELWITHDEBINFO)
+      if(${var} MATCHES "-xO3")
+        string(REGEX REPLACE "-xO3" "-xO5" ${var} "${${var}}")
+      endif()
+      if(${var} MATCHES "-xO2")
+        string(REGEX REPLACE "-xO2" "-xO5" ${var} "${${var}}")
+      endif()
+    endforeach()
+  endif()
+endif()
+
+string(TOUPPER ${CMAKE_BUILD_TYPE} CMAKE_BUILD_TYPE_UC)
+
+set(EFFECTIVE_C_FLAGS "${CMAKE_C_FLAGS} ${CMAKE_C_FLAGS_${CMAKE_BUILD_TYPE_UC}}")
+message(STATUS "Compiler flags = ${EFFECTIVE_C_FLAGS}")
+
+set(EFFECTIVE_LD_FLAGS "${CMAKE_EXE_LINKER_FLAGS} ${CMAKE_EXE_LINKER_FLAGS_${CMAKE_BUILD_TYPE_UC}}")
+message(STATUS "Linker flags = ${EFFECTIVE_LD_FLAGS}")
+
+include(CheckCSourceCompiles)
+include(CheckIncludeFiles)
+include(CheckTypeSize)
+
+check_type_size("size_t" SIZE_T)
+check_type_size("unsigned long" UNSIGNED_LONG)
+
+if(SIZE_T EQUAL UNSIGNED_LONG)
+  check_c_source_compiles("int main(int argc, char **argv) { unsigned long a = argc;  return __builtin_ctzl(a); }"
+    HAVE_BUILTIN_CTZL)
+endif()
+if(MSVC)
+  check_include_files("intrin.h" HAVE_INTRIN_H)
+endif()
+
+if(UNIX)
+  if(CMAKE_CROSSCOMPILING)
+    set(RIGHT_SHIFT_IS_UNSIGNED 0)
+  else()
+    include(CheckCSourceRuns)
+    check_c_source_runs("
+      #include <stdio.h>
+      #include <stdlib.h>
+      int is_shifting_signed (long arg) {
+        long res = arg >> 4;
+        if (res == -0x7F7E80CL)
+          return 1; /* right shift is signed */
+        /* see if unsigned-shift hack will fix it. */
+        /* we can't just test exact value since it depends on width of long... */
+        res |= (~0L) << (32-4);
+        if (res == -0x7F7E80CL)
+          return 0; /* right shift is unsigned */
+        printf(\"Right shift isn't acting as I expect it to.\\\\n\");
+        printf(\"I fear the JPEG software will not work at all.\\\\n\\\\n\");
+        return 0; /* try it with unsigned anyway */
+      }
+      int main (void) {
+        exit(is_shifting_signed(-0x7F7E80B1L));
+      }" RIGHT_SHIFT_IS_UNSIGNED)
+  endif()
+endif()
+
+if(MSVC)
+  set(INLINE_OPTIONS "__inline;inline")
+else()
+  set(INLINE_OPTIONS "__inline__;inline")
+endif()
+option(FORCE_INLINE "Force function inlining" TRUE)
+boolean_number(FORCE_INLINE)
+if(FORCE_INLINE)
+  if(MSVC)
+    list(INSERT INLINE_OPTIONS 0 "__forceinline")
+  else()
+    list(INSERT INLINE_OPTIONS 0 "inline __attribute__((always_inline))")
+    list(INSERT INLINE_OPTIONS 0 "__inline__ __attribute__((always_inline))")
+  endif()
+endif()
+foreach(inline ${INLINE_OPTIONS})
+  check_c_source_compiles("${inline} static int foo(void) { return 0; } int main(void) { return foo(); }"
+    INLINE_WORKS)
+  if(INLINE_WORKS)
+    set(INLINE ${inline})
+    break()
+  endif()
+endforeach()
+if(NOT INLINE_WORKS)
+  message(FATAL_ERROR "Could not determine how to inline functions.")
+endif()
+message(STATUS "INLINE = ${INLINE} (FORCE_INLINE = ${FORCE_INLINE})")
+
+if(WITH_TURBOJPEG)
+  if(MSVC)
+    set(THREAD_LOCAL "__declspec(thread)")
+  else()
+    set(THREAD_LOCAL "__thread")
+  endif()
+  check_c_source_compiles("${THREAD_LOCAL} int i;  int main(void) { i = 0;  return i; }" HAVE_THREAD_LOCAL)
+  if(HAVE_THREAD_LOCAL)
+    message(STATUS "THREAD_LOCAL = ${THREAD_LOCAL}")
+  else()
+    message(WARNING "Thread-local storage is not available.  The TurboJPEG API library's global error handler will not be thread-safe.")
+    unset(THREAD_LOCAL)
+  endif()
+endif()
+
+if(UNIX AND NOT APPLE)
+  file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/conftest.map "VERS_1 { global: *; };")
+  set(CMAKE_REQUIRED_FLAGS
+    "-Wl,--version-script,${CMAKE_CURRENT_BINARY_DIR}/conftest.map")
+  check_c_source_compiles("int main(void) { return 0; }" HAVE_VERSION_SCRIPT)
+  set(CMAKE_REQUIRED_FLAGS)
+  file(REMOVE ${CMAKE_CURRENT_BINARY_DIR}/conftest.map)
+  if(HAVE_VERSION_SCRIPT)
+    message(STATUS "Linker supports GNU-style version scripts")
+    set(MAPFLAG "-Wl,--version-script,")
+    set(TJMAPFLAG "-Wl,--version-script,")
+  else()
+    message(STATUS "Linker does not support GNU-style version scripts")
+    if(CMAKE_SYSTEM_NAME STREQUAL "SunOS")
+      # The Solaris linker doesn't like our version script for the libjpeg API
+      # library, but the version script for the TurboJPEG API library should
+      # still work.
+      file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/conftest.map
+        "VERS_1 { global: foo;  local: *; }; VERS_2 { global: foo2; } VERS_1;")
+      set(CMAKE_REQUIRED_FLAGS "-Wl,-M,${CMAKE_CURRENT_BINARY_DIR}/conftest.map -shared")
+      check_c_source_compiles("int foo() { return 0; } int foo2() { return 2; }"
+        HAVE_MAPFILE)
+      set(CMAKE_REQUIRED_FLAGS)
+      file(REMOVE ${CMAKE_CURRENT_BINARY_DIR}/conftest.map)
+      if(HAVE_MAPFILE)
+        message(STATUS "Linker supports mapfiles")
+        set(TJMAPFLAG "-Wl,-M,")
+      else()
+        message(STATUS "Linker does not support mapfiles")
+      endif()
+    endif()
+  endif()
+endif()
+
+# Generate files
+if(WIN32)
+  configure_file(${CMAKE_CURRENT_SOURCE_DIR}/win/jconfig.h.in jconfig.h)
+else()
+  configure_file(jconfig.h.in jconfig.h)
+endif()
+configure_file(jconfigint.h.in jconfigint.h)
+configure_file(jversion.h.in jversion.h)
+if(UNIX)
+  configure_file(libjpeg.map.in libjpeg.map)
+endif()
+
+# Include directories and compiler definitions
+include_directories(${CMAKE_CURRENT_BINARY_DIR} ${CMAKE_CURRENT_SOURCE_DIR})
+
+
+###############################################################################
+# TARGETS
+###############################################################################
+
+if(CMAKE_EXECUTABLE_SUFFIX_TMP)
+  set(CMAKE_EXECUTABLE_SUFFIX ${CMAKE_EXECUTABLE_SUFFIX_TMP})
+endif()
+message(STATUS "CMAKE_EXECUTABLE_SUFFIX = ${CMAKE_EXECUTABLE_SUFFIX}")
+
+set(JPEG_SOURCES jcapimin.c jcapistd.c jccoefct.c jccolor.c jcdctmgr.c jchuff.c
+  jcicc.c jcinit.c jcmainct.c jcmarker.c jcmaster.c jcomapi.c jcparam.c
+  jcphuff.c jcprepct.c jcsample.c jctrans.c jdapimin.c jdapistd.c jdatadst.c
+  jdatasrc.c jdcoefct.c jdcolor.c jddctmgr.c jdhuff.c jdicc.c jdinput.c
+  jdmainct.c jdmarker.c jdmaster.c jdmerge.c jdphuff.c jdpostct.c jdsample.c
+  jdtrans.c jerror.c jfdctflt.c jfdctfst.c jfdctint.c jidctflt.c jidctfst.c
+  jidctint.c jidctred.c jquant1.c jquant2.c jutils.c jmemmgr.c jmemnobs.c)
+
+if(WITH_ARITH_ENC OR WITH_ARITH_DEC)
+  set(JPEG_SOURCES ${JPEG_SOURCES} jaricom.c)
+endif()
+
+if(WITH_ARITH_ENC)
+  set(JPEG_SOURCES ${JPEG_SOURCES} jcarith.c)
+endif()
+
+if(WITH_ARITH_DEC)
+  set(JPEG_SOURCES ${JPEG_SOURCES} jdarith.c)
+endif()
+
+if(WITH_SIMD)
+  add_subdirectory(simd)
+  if(NEON_INTRINSICS)
+    add_definitions(-DNEON_INTRINSICS)
+  endif()
+elseif(NOT WITH_12BIT)
+  message(STATUS "SIMD extensions: None (WITH_SIMD = ${WITH_SIMD})")
+endif()
+if(WITH_SIMD)
+  message(STATUS "SIMD extensions: ${CPU_TYPE} (WITH_SIMD = ${WITH_SIMD})")
+  if(MSVC_IDE OR XCODE)
+    set_source_files_properties(${SIMD_OBJS} PROPERTIES GENERATED 1)
+  endif()
+else()
+  add_library(simd OBJECT jsimd_none.c)
+  if(NOT WIN32 AND (CMAKE_POSITION_INDEPENDENT_CODE OR ENABLE_SHARED))
+    set_target_properties(simd PROPERTIES POSITION_INDEPENDENT_CODE 1)
+  endif()
+endif()
+
+if(WITH_JAVA)
+  add_subdirectory(java)
+endif()
+
+if(ENABLE_SHARED)
+  add_subdirectory(sharedlib)
+endif()
+
+if(ENABLE_STATIC)
+  add_library(jpeg-static STATIC ${JPEG_SOURCES} $<TARGET_OBJECTS:simd>
+    ${SIMD_OBJS})
+  if(NOT MSVC)
+    set_target_properties(jpeg-static PROPERTIES OUTPUT_NAME jpeg)
+  endif()
+endif()
+
+if(WITH_TURBOJPEG)
+  if(ENABLE_SHARED)
+    set(TURBOJPEG_SOURCES ${JPEG_SOURCES} $<TARGET_OBJECTS:simd> ${SIMD_OBJS}
+      turbojpeg.c transupp.c jdatadst-tj.c jdatasrc-tj.c rdbmp.c rdppm.c
+      wrbmp.c wrppm.c)
+    set(TJMAPFILE ${CMAKE_CURRENT_SOURCE_DIR}/turbojpeg-mapfile)
+    if(WITH_JAVA)
+      set(TURBOJPEG_SOURCES ${TURBOJPEG_SOURCES} turbojpeg-jni.c)
+      include_directories(${JAVA_INCLUDE_PATH} ${JAVA_INCLUDE_PATH2})
+      set(TJMAPFILE ${CMAKE_CURRENT_SOURCE_DIR}/turbojpeg-mapfile.jni)
+    endif()
+    if(MSVC)
+      configure_file(${CMAKE_SOURCE_DIR}/win/turbojpeg.rc.in
+        ${CMAKE_BINARY_DIR}/win/turbojpeg.rc)
+      set(TURBOJPEG_SOURCES ${TURBOJPEG_SOURCES}
+        ${CMAKE_BINARY_DIR}/win/turbojpeg.rc)
+    endif()
+    add_library(turbojpeg SHARED ${TURBOJPEG_SOURCES})
+    set_property(TARGET turbojpeg PROPERTY COMPILE_FLAGS
+      "-DBMP_SUPPORTED -DPPM_SUPPORTED")
+    if(WIN32)
+      set_target_properties(turbojpeg PROPERTIES DEFINE_SYMBOL DLLDEFINE)
+    endif()
+    if(MINGW)
+      set_target_properties(turbojpeg PROPERTIES LINK_FLAGS -Wl,--kill-at)
+    endif()
+    if(APPLE AND (NOT CMAKE_OSX_DEPLOYMENT_TARGET OR
+                  CMAKE_OSX_DEPLOYMENT_TARGET VERSION_GREATER 10.4))
+      if(NOT CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG)
+        set(CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG "-Wl,-rpath,")
+      endif()
+      set_target_properties(turbojpeg PROPERTIES MACOSX_RPATH 1)
+    endif()
+    set_target_properties(turbojpeg PROPERTIES
+      SOVERSION ${TURBOJPEG_SO_MAJOR_VERSION} VERSION ${TURBOJPEG_SO_VERSION})
+    if(TJMAPFLAG)
+      set_target_properties(turbojpeg PROPERTIES
+        LINK_FLAGS "${TJMAPFLAG}${TJMAPFILE}")
+    endif()
+  endif()
+
+  if(ENABLE_STATIC)
+    add_library(turbojpeg-static STATIC ${JPEG_SOURCES} $<TARGET_OBJECTS:simd>
+      ${SIMD_OBJS} turbojpeg.c transupp.c jdatadst-tj.c jdatasrc-tj.c rdbmp.c
+      rdppm.c wrbmp.c wrppm.c)
+    set_property(TARGET turbojpeg-static PROPERTY COMPILE_FLAGS
+      "-DBMP_SUPPORTED -DPPM_SUPPORTED")
+    if(NOT MSVC)
+      set_target_properties(turbojpeg-static PROPERTIES OUTPUT_NAME turbojpeg)
+    endif()
+  endif()
+endif()
+
+if(WIN32)
+  set(USE_SETMODE "-DUSE_SETMODE")
+endif()
+if(WITH_12BIT)
+  set(COMPILE_FLAGS "-DGIF_SUPPORTED -DPPM_SUPPORTED ${USE_SETMODE}")
+else()
+  set(COMPILE_FLAGS "-DBMP_SUPPORTED -DGIF_SUPPORTED -DPPM_SUPPORTED -DTARGA_SUPPORTED ${USE_SETMODE}")
+  set(CJPEG_BMP_SOURCES rdbmp.c rdtarga.c)
+  set(DJPEG_BMP_SOURCES wrbmp.c wrtarga.c)
+endif()

cmake/CMakeLists.png

@@ -0,0 +1,741 @@
+# CMakeLists.txt
+
+# Copyright (C) 2018 Cosmin Truta
+# Copyright (C) 2007,2009-2018 Glenn Randers-Pehrson
+# Written by Christian Ehrlicher, 2007
+# Revised by Roger Lowman, 2009-2010
+# Revised by Clifford Yapp, 2011-2012,2017
+# Revised by Roger Leigh, 2016
+# Revised by Andreas Franek, 2016
+# Revised by Sam Serrels, 2017
+# Revised by Vadim Barkov, 2017
+# Revised by Vicky Pfau, 2018
+# Revised by Cameron Cawley, 2018
+# Revised by Cosmin Truta, 2018
+# Revised by Kyle Bentley, 2018
+
+# This code is released under the libpng license.
+# For conditions of distribution and use, see the disclaimer
+# and license in png.h
+
+cmake_minimum_required(VERSION 3.10)
+cmake_policy(VERSION 3.1)
+# When using CMake 3.4 and later, don't export symbols from executables unless
+# the CMAKE_ENABLE_EXPORTS variable is set.
+if(POLICY CMP0065)
+  cmake_policy(SET CMP0065 NEW)
+endif()
+if (POLICY CMP0077)
+  cmake_policy(SET CMP0077 NEW)
+endif()
+set(CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS ON)
+
+project(libpng C ASM)
+enable_testing()
+
+set(PNGLIB_MAJOR 1)
+set(PNGLIB_MINOR 6)
+set(PNGLIB_RELEASE 37)
+set(PNGLIB_NAME libpng${PNGLIB_MAJOR}${PNGLIB_MINOR})
+set(PNGLIB_VERSION ${PNGLIB_MAJOR}.${PNGLIB_MINOR}.${PNGLIB_RELEASE})
+
+include(GNUInstallDirs)
+
+# needed packages
+
+# Allow users to specify location of Zlib.
+# Useful if zlib is being built alongside this as a sub-project.
+option(PNG_BUILD_ZLIB "Custom zlib Location, else find_package is used" ON)
+
+if(NOT PNG_BUILD_ZLIB)
+  find_package(ZLIB REQUIRED)
+  include_directories(${ZLIB_INCLUDE_DIR})
+endif()
+
+if(UNIX AND NOT APPLE AND NOT BEOS AND NOT HAIKU)
+  find_library(M_LIBRARY m)
+else()
+  # libm is not needed and/or not available
+  set(M_LIBRARY "")
+endif()
+
+# COMMAND LINE OPTIONS
+option(PNG_SHARED "Build shared lib" OFF)
+option(PNG_STATIC "Build static lib" ON)
+option(PNG_TESTS  "Build libpng tests" OFF)
+
+# Many more configuration options could be added here
+option(PNG_FRAMEWORK "Build OS X framework" OFF)
+option(PNG_DEBUG "Build with debug output" OFF)
+option(PNG_HARDWARE_OPTIMIZATIONS "Enable hardware optimizations" OFF)
+
+set(PNG_PREFIX "" CACHE STRING "Prefix to add to the API function names")
+set(DFA_XTRA "" CACHE FILEPATH "File containing extra configuration settings")
+
+if(PNG_HARDWARE_OPTIMIZATIONS)
+
+# set definitions and sources for arm
+if(CMAKE_SYSTEM_PROCESSOR MATCHES "^arm" OR
+  CMAKE_SYSTEM_PROCESSOR MATCHES "^aarch64")
+  set(PNG_ARM_NEON_POSSIBLE_VALUES check on off)
+  set(PNG_ARM_NEON "check" CACHE STRING "Enable ARM NEON optimizations:
+     check: (default) use internal checking code;
+     off: disable the optimizations;
+     on: turn on unconditionally.")
+  set_property(CACHE PNG_ARM_NEON PROPERTY STRINGS
+     ${PNG_ARM_NEON_POSSIBLE_VALUES})
+  list(FIND PNG_ARM_NEON_POSSIBLE_VALUES ${PNG_ARM_NEON} index)
+  if(index EQUAL -1)
+    message(FATAL_ERROR
+            "PNG_ARM_NEON must be one of [${PNG_ARM_NEON_POSSIBLE_VALUES}]")
+  elseif(NOT ${PNG_ARM_NEON} STREQUAL "off")
+    set(libpng_arm_sources
+      arm/arm_init.c
+      arm/filter_neon.S
+      arm/filter_neon_intrinsics.c
+      arm/palette_neon_intrinsics.c)
+
+    if(${PNG_ARM_NEON} STREQUAL "on")
+      add_definitions(-DPNG_ARM_NEON_OPT=2)
+    elseif(${PNG_ARM_NEON} STREQUAL "check")
+      add_definitions(-DPNG_ARM_NEON_CHECK_SUPPORTED)
+    endif()
+  else()
+    add_definitions(-DPNG_ARM_NEON_OPT=0)
+  endif()
+endif()
+
+# set definitions and sources for powerpc
+if(CMAKE_SYSTEM_PROCESSOR MATCHES "^powerpc*" OR
+   CMAKE_SYSTEM_PROCESSOR MATCHES "^ppc64*")
+  set(PNG_POWERPC_VSX_POSSIBLE_VALUES on off)
+  set(PNG_POWERPC_VSX "on" CACHE STRING "Enable POWERPC VSX optimizations:
+     off: disable the optimizations.")
+  set_property(CACHE PNG_POWERPC_VSX PROPERTY STRINGS
+     ${PNG_POWERPC_VSX_POSSIBLE_VALUES})
+  list(FIND PNG_POWERPC_VSX_POSSIBLE_VALUES ${PNG_POWERPC_VSX} index)
+  if(index EQUAL -1)
+    message(FATAL_ERROR
+            "PNG_POWERPC_VSX must be one of [${PNG_POWERPC_VSX_POSSIBLE_VALUES}]")
+  elseif(NOT ${PNG_POWERPC_VSX} STREQUAL "off")
+    set(libpng_powerpc_sources
+      powerpc/powerpc_init.c
+      powerpc/filter_vsx_intrinsics.c)
+    if(${PNG_POWERPC_VSX} STREQUAL "on")
+      add_definitions(-DPNG_POWERPC_VSX_OPT=2)
+    endif()
+  else()
+    add_definitions(-DPNG_POWERPC_VSX_OPT=0)
+  endif()
+endif()
+
+# set definitions and sources for intel
+if(CMAKE_SYSTEM_PROCESSOR MATCHES "^i?86" OR
+   CMAKE_SYSTEM_PROCESSOR MATCHES "^x86_64*")
+  set(PNG_INTEL_SSE_POSSIBLE_VALUES on off)
+  set(PNG_INTEL_SSE "on" CACHE STRING "Enable INTEL_SSE optimizations:
+     off: disable the optimizations")
+  set_property(CACHE PNG_INTEL_SSE PROPERTY STRINGS
+     ${PNG_INTEL_SSE_POSSIBLE_VALUES})
+  list(FIND PNG_INTEL_SSE_POSSIBLE_VALUES ${PNG_INTEL_SSE} index)
+  if(index EQUAL -1)
+    message(FATAL_ERROR
+            "PNG_INTEL_SSE must be one of [${PNG_INTEL_SSE_POSSIBLE_VALUES}]")
+  elseif(NOT ${PNG_INTEL_SSE} STREQUAL "off")
+    set(libpng_intel_sources
+      intel/intel_init.c
+      intel/filter_sse2_intrinsics.c)
+    if(${PNG_INTEL_SSE} STREQUAL "on")
+      add_definitions(-DPNG_INTEL_SSE_OPT=1)
+    endif()
+  else()
+    add_definitions(-DPNG_INTEL_SSE_OPT=0)
+  endif()
+endif()
+
+# set definitions and sources for MIPS
+if(CMAKE_SYSTEM_PROCESSOR MATCHES "mipsel*" OR
+   CMAKE_SYSTEM_PROCESSOR MATCHES "mips64el*")
+  set(PNG_MIPS_MSA_POSSIBLE_VALUES on off)
+  set(PNG_MIPS_MSA "on" CACHE STRING "Enable MIPS_MSA optimizations:
+     off: disable the optimizations")
+  set_property(CACHE PNG_MIPS_MSA PROPERTY STRINGS
+     ${PNG_MIPS_MSA_POSSIBLE_VALUES})
+  list(FIND PNG_MIPS_MSA_POSSIBLE_VALUES ${PNG_MIPS_MSA} index)
+  if(index EQUAL -1)
+    message(FATAL_ERROR
+            "PNG_MIPS_MSA must be one of [${PNG_MIPS_MSA_POSSIBLE_VALUES}]")
+  elseif(NOT ${PNG_MIPS_MSA} STREQUAL "off")
+    set(libpng_mips_sources
+      mips/mips_init.c
+      mips/filter_msa_intrinsics.c)
+    if(${PNG_MIPS_MSA} STREQUAL "on")
+      add_definitions(-DPNG_MIPS_MSA_OPT=2)
+    endif()
+  else()
+    add_definitions(-DPNG_MIPS_MSA_OPT=0)
+  endif()
+endif()
+
+else(PNG_HARDWARE_OPTIMIZATIONS)
+
+# set definitions and sources for arm
+if(CMAKE_SYSTEM_PROCESSOR MATCHES "^arm" OR
+   CMAKE_SYSTEM_PROCESSOR MATCHES "^aarch64")
+  add_definitions(-DPNG_ARM_NEON_OPT=0)
+endif()
+
+# set definitions and sources for powerpc
+if(CMAKE_SYSTEM_PROCESSOR MATCHES "^powerpc*" OR
+   CMAKE_SYSTEM_PROCESSOR MATCHES "^ppc64*")
+  add_definitions(-DPNG_POWERPC_VSX_OPT=0)
+endif()
+
+# set definitions and sources for intel
+if(CMAKE_SYSTEM_PROCESSOR MATCHES "^i?86" OR
+   CMAKE_SYSTEM_PROCESSOR MATCHES "^x86_64*")
+  add_definitions(-DPNG_INTEL_SSE_OPT=0)
+endif()
+
+# set definitions and sources for MIPS
+if(CMAKE_SYSTEM_PROCESSOR MATCHES "mipsel*" OR
+   CMAKE_SYSTEM_PROCESSOR MATCHES "mips64el*")
+  add_definitions(-DPNG_MIPS_MSA_OPT=0)
+endif()
+
+endif(PNG_HARDWARE_OPTIMIZATIONS)
+
+# SET LIBNAME
+set(PNG_LIB_NAME png${PNGLIB_MAJOR}${PNGLIB_MINOR})
+
+# to distinguish between debug and release lib
+set(CMAKE_DEBUG_POSTFIX "d")
+
+include(CheckCSourceCompiles)
+option(ld-version-script "Enable linker version script" ON)
+if(ld-version-script AND NOT APPLE)
+  # Check if LD supports linker scripts.
+  file(WRITE "${CMAKE_CURRENT_BINARY_DIR}/conftest.map" "VERS_1 {
+        global: sym;
+        local: *;
+};
+
+VERS_2 {
+        global: sym2;
+                main;
+} VERS_1;
+")
+  set(CMAKE_REQUIRED_FLAGS_SAVE ${CMAKE_REQUIRED_FLAGS})
+  set(CMAKE_REQUIRED_FLAGS ${CMAKE_REQUIRED_FLAGS} "-Wl,--version-script='${CMAKE_CURRENT_BINARY_DIR}/conftest.map'")
+  check_c_source_compiles("void sym(void) {}
+void sym2(void) {}
+int main(void) {return 0;}
+" HAVE_LD_VERSION_SCRIPT)
+  if(NOT HAVE_LD_VERSION_SCRIPT)
+    set(CMAKE_REQUIRED_FLAGS ${CMAKE_REQUIRED_FLAGS_SAVE} "-Wl,-M -Wl,${CMAKE_CURRENT_BINARY_DIR}/conftest.map")
+  check_c_source_compiles("void sym(void) {}
+void sym2(void) {}
+int main(void) {return 0;}
+" HAVE_SOLARIS_LD_VERSION_SCRIPT)
+  endif()
+  set(CMAKE_REQUIRED_FLAGS ${CMAKE_REQUIRED_FLAGS_SAVE})
+  file(REMOVE "${CMAKE_CURRENT_BINARY_DIR}/conftest.map")
+endif()
+
+# Find symbol prefix.  Likely obsolete and unnecessary with recent
+# toolchains (it's not done in many other projects).
+function(symbol_prefix)
+  set(SYMBOL_PREFIX)
+
+  execute_process(COMMAND "${CMAKE_C_COMPILER}" "-E" "-"
+                  INPUT_FILE /dev/null
+                  OUTPUT_VARIABLE OUT
+                  RESULT_VARIABLE STATUS)
+
+  if(CPP_FAIL)
+    message(WARNING "Failed to run the C preprocessor")
+  endif()
+
+  string(REPLACE "\n" ";" OUT "${OUT}")
+  foreach(line ${OUT})
+    string(REGEX MATCH "^PREFIX=" found_match "${line}")
+    if(found_match)
+      string(REGEX REPLACE "^PREFIX=(.*\)" "\\1" prefix "${line}")
+      string(REGEX MATCH "__USER_LABEL_PREFIX__" found_match "${prefix}")
+      if(found_match)
+        string(REGEX REPLACE "(.*)__USER_LABEL_PREFIX__(.*)" "\\1\\2" prefix "${prefix}")
+      endif()
+      set(SYMBOL_PREFIX "${prefix}")
+    endif()
+  endforeach()
+
+  message(STATUS "Symbol prefix: ${SYMBOL_PREFIX}")
+  set(SYMBOL_PREFIX "${SYMBOL_PREFIX}" PARENT_SCOPE)
+endfunction()
+
+if(UNIX)
+  symbol_prefix()
+endif()
+
+find_program(AWK NAMES gawk awk)
+
+include_directories(${CMAKE_CURRENT_BINARY_DIR})
+
+if(NOT AWK OR ANDROID)
+  # No awk available to generate sources; use pre-built pnglibconf.h
+  configure_file(${CMAKE_CURRENT_SOURCE_DIR}/scripts/pnglibconf.h.prebuilt
+                 ${CMAKE_CURRENT_BINARY_DIR}/pnglibconf.h)
+  add_custom_target(genfiles) # Dummy
+else()
+  include(CMakeParseArguments)
+  # Generate .chk from .out with awk
+  # generate_chk(INPUT inputfile OUTPUT outputfile [DEPENDS dep1 [dep2...]])
+  function(generate_chk)
+    set(options)
+    set(oneValueArgs INPUT OUTPUT)
+    set(multiValueArgs DEPENDS)
+    cmake_parse_arguments(_GC "${options}" "${oneValueArgs}" "${multiValueArgs}" ${ARGN})
+    if(NOT _GC_INPUT)
+      message(FATAL_ERROR "generate_chk: Missing INPUT argument")
+    endif()
+    if(NOT _GC_OUTPUT)
+      message(FATAL_ERROR "generate_chk: Missing OUTPUT argument")
+    endif()
+
+    add_custom_command(OUTPUT "${_GC_OUTPUT}"
+                       COMMAND "${CMAKE_COMMAND}"
+                               "-DINPUT=${_GC_INPUT}"
+                               "-DOUTPUT=${_GC_OUTPUT}"
+                               -P "${CMAKE_CURRENT_BINARY_DIR}/scripts/genchk.cmake"
+                       DEPENDS "${_GC_INPUT}" ${_GC_DEPENDS}
+                       WORKING_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}")
+  endfunction()
+
+  # Generate .out from .c with awk
+  # generate_out(INPUT inputfile OUTPUT outputfile [DEPENDS dep1 [dep2...]])
+  function(generate_out)
+    set(options)
+    set(oneValueArgs INPUT OUTPUT)
+    set(multiValueArgs DEPENDS)
+    cmake_parse_arguments(_GO "${options}" "${oneValueArgs}" "${multiValueArgs}" ${ARGN})
+    if(NOT _GO_INPUT)
+      message(FATAL_ERROR "generate_out: Missing INPUT argument")
+    endif()
+    if(NOT _GO_OUTPUT)
+      message(FATAL_ERROR "generate_out: Missing OUTPUT argument")
+    endif()
+
+    add_custom_command(OUTPUT "${_GO_OUTPUT}"
+                       COMMAND "${CMAKE_COMMAND}"
+                               "-DINPUT=${_GO_INPUT}"
+                               "-DOUTPUT=${_GO_OUTPUT}"
+                               -P "${CMAKE_CURRENT_BINARY_DIR}/scripts/genout.cmake"
+                       DEPENDS "${_GO_INPUT}" ${_GO_DEPENDS}
+                       WORKING_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}")
+  endfunction()
+
+  # Generate specific source file with awk
+  # generate_source(OUTPUT outputfile [DEPENDS dep1 [dep2...]])
+  function(generate_source)
+    set(options)
+    set(oneValueArgs OUTPUT)
+    set(multiValueArgs DEPENDS)
+    cmake_parse_arguments(_GSO "${options}" "${oneValueArgs}" "${multiValueArgs}" ${ARGN})
+    if(NOT _GSO_OUTPUT)
+      message(FATAL_ERROR "generate_source: Missing OUTPUT argument")
+    endif()
+
+    add_custom_command(OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/${_GSO_OUTPUT}"
+                       COMMAND "${CMAKE_COMMAND}"
+                               "-DOUTPUT=${_GSO_OUTPUT}"
+                               -P "${CMAKE_CURRENT_BINARY_DIR}/scripts/gensrc.cmake"
+                       DEPENDS ${_GSO_DEPENDS}
+                       WORKING_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}")
+  endfunction()
+
+  # Copy file
+  function(generate_copy source destination)
+    add_custom_command(OUTPUT "${destination}"
+                       COMMAND "${CMAKE_COMMAND}" -E remove "${destination}"
+                       COMMAND "${CMAKE_COMMAND}" -E copy "${source}"
+                                                          "${destination}"
+                       DEPENDS "${source}")
+  endfunction()
+
+  # Generate scripts/pnglibconf.h
+  generate_source(OUTPUT "scripts/pnglibconf.c"
+                  DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/scripts/pnglibconf.dfa"
+                          "${CMAKE_CURRENT_SOURCE_DIR}/scripts/options.awk"
+                          "${CMAKE_CURRENT_SOURCE_DIR}/pngconf.h")
+
+  # Generate pnglibconf.c
+  generate_source(OUTPUT "pnglibconf.c"
+                  DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/scripts/pnglibconf.dfa"
+                          "${CMAKE_CURRENT_SOURCE_DIR}/scripts/options.awk"
+                          "${CMAKE_CURRENT_SOURCE_DIR}/pngconf.h")
+
+  if(PNG_PREFIX)
+    set(PNGLIBCONF_H_EXTRA_DEPENDS
+        "${CMAKE_CURRENT_BINARY_DIR}/scripts/prefix.out"
+        "${CMAKE_CURRENT_SOURCE_DIR}/scripts/macro.lst")
+    set(PNGPREFIX_H_EXTRA_DEPENDS
+        "${CMAKE_CURRENT_BINARY_DIR}/scripts/intprefix.out")
+  endif()
+
+  generate_out(INPUT "${CMAKE_CURRENT_BINARY_DIR}/pnglibconf.c"
+               OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/pnglibconf.out")
+
+  # Generate pnglibconf.h
+  generate_source(OUTPUT "pnglibconf.h"
+                  DEPENDS "${CMAKE_CURRENT_BINARY_DIR}/pnglibconf.out"
+                          ${PNGLIBCONF_H_EXTRA_DEPENDS})
+
+  generate_out(INPUT "${CMAKE_CURRENT_SOURCE_DIR}/scripts/intprefix.c"
+               OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/scripts/intprefix.out"
+               DEPENDS "${CMAKE_CURRENT_BINARY_DIR}/pnglibconf.h")
+
+  generate_out(INPUT "${CMAKE_CURRENT_SOURCE_DIR}/scripts/prefix.c"
+               OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/scripts/prefix.out"
+               DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/png.h"
+                       "${CMAKE_CURRENT_SOURCE_DIR}/pngconf.h"
+                       "${CMAKE_CURRENT_BINARY_DIR}/pnglibconf.out")
+
+  # Generate pngprefix.h
+  generate_source(OUTPUT "pngprefix.h"
+                  DEPENDS ${PNGPREFIX_H_EXTRA_DEPENDS})
+
+  generate_out(INPUT "${CMAKE_CURRENT_SOURCE_DIR}/scripts/sym.c"
+               OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/scripts/sym.out"
+               DEPENDS "${CMAKE_CURRENT_BINARY_DIR}/pnglibconf.h")
+
+  generate_out(INPUT "${CMAKE_CURRENT_SOURCE_DIR}/scripts/symbols.c"
+               OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/scripts/symbols.out"
+               DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/png.h"
+                       "${CMAKE_CURRENT_SOURCE_DIR}/pngconf.h"
+                       "${CMAKE_CURRENT_SOURCE_DIR}/scripts/pnglibconf.h.prebuilt")
+
+  generate_out(INPUT "${CMAKE_CURRENT_SOURCE_DIR}/scripts/vers.c"
+               OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/scripts/vers.out"
+               DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/png.h"
+                       "${CMAKE_CURRENT_SOURCE_DIR}/pngconf.h"
+                       "${CMAKE_CURRENT_BINARY_DIR}/pnglibconf.h")
+
+  generate_chk(INPUT "${CMAKE_CURRENT_BINARY_DIR}/scripts/symbols.out"
+               OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/scripts/symbols.chk"
+               DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/scripts/checksym.awk"
+                       "${CMAKE_CURRENT_SOURCE_DIR}/scripts/symbols.def")
+
+  add_custom_target(symbol-check DEPENDS
+                    "${CMAKE_CURRENT_BINARY_DIR}/scripts/symbols.chk")
+
+  generate_copy("${CMAKE_CURRENT_BINARY_DIR}/scripts/sym.out"
+                "${CMAKE_CURRENT_BINARY_DIR}/libpng.sym")
+  generate_copy("${CMAKE_CURRENT_BINARY_DIR}/scripts/vers.out"
+                "${CMAKE_CURRENT_BINARY_DIR}/libpng.vers")
+
+  add_custom_target(genvers DEPENDS "${CMAKE_CURRENT_BINARY_DIR}/libpng.vers")
+  add_custom_target(gensym DEPENDS "${CMAKE_CURRENT_BINARY_DIR}/libpng.sym")
+
+  add_custom_target("genprebuilt"
+                    COMMAND "${CMAKE_COMMAND}"
+                            "-DOUTPUT=scripts/pnglibconf.h.prebuilt"
+                            -P "${CMAKE_CURRENT_BINARY_DIR}/scripts/gensrc.cmake"
+                    WORKING_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}")
+
+  # A single target handles generation of all generated files.  If
+  # they are depended upon separately by multiple targets, this
+  # confuses parallel make (it would require a separate top-level
+  # target for each file to track the dependencies properly).
+  add_custom_target(genfiles DEPENDS
+    "${CMAKE_CURRENT_BINARY_DIR}/libpng.sym"
+    "${CMAKE_CURRENT_BINARY_DIR}/libpng.vers"
+    "${CMAKE_CURRENT_BINARY_DIR}/pnglibconf.c"
+    "${CMAKE_CURRENT_BINARY_DIR}/pnglibconf.h"
+    "${CMAKE_CURRENT_BINARY_DIR}/pnglibconf.out"
+    "${CMAKE_CURRENT_BINARY_DIR}/pngprefix.h"
+    "${CMAKE_CURRENT_BINARY_DIR}/scripts/intprefix.out"
+    "${CMAKE_CURRENT_BINARY_DIR}/scripts/pnglibconf.c"
+    "${CMAKE_CURRENT_BINARY_DIR}/scripts/prefix.out"
+    "${CMAKE_CURRENT_BINARY_DIR}/scripts/sym.out"
+    "${CMAKE_CURRENT_BINARY_DIR}/scripts/symbols.chk"
+    "${CMAKE_CURRENT_BINARY_DIR}/scripts/symbols.out"
+    "${CMAKE_CURRENT_BINARY_DIR}/scripts/vers.out")
+endif(NOT AWK OR ANDROID)
+
+# OUR SOURCES
+set(libpng_public_hdrs
+  png.h
+  pngconf.h
+  "${CMAKE_CURRENT_BINARY_DIR}/pnglibconf.h"
+)
+set(libpng_private_hdrs
+  pngpriv.h
+  pngdebug.h
+  pnginfo.h
+  pngstruct.h
+)
+if(AWK AND NOT ANDROID)
+  list(APPEND libpng_private_hdrs "${CMAKE_CURRENT_BINARY_DIR}/pngprefix.h")
+endif()
+set(libpng_sources
+  ${libpng_public_hdrs}
+  ${libpng_private_hdrs}
+  png.c
+  pngerror.c
+  pngget.c
+  pngmem.c
+  pngpread.c
+  pngread.c
+  pngrio.c
+  pngrtran.c
+  pngrutil.c
+  pngset.c
+  pngtrans.c
+  pngwio.c
+  pngwrite.c
+  pngwtran.c
+  pngwutil.c
+  ${libpng_arm_sources}
+  ${libpng_intel_sources}
+  ${libpng_mips_sources}
+  ${libpng_powerpc_sources}
+)
+set(pngtest_sources
+  pngtest.c
+)
+set(pngvalid_sources
+  contrib/libtests/pngvalid.c
+)
+set(pngstest_sources
+  contrib/libtests/pngstest.c
+)
+set(pngunknown_sources
+  contrib/libtests/pngunknown.c
+)
+set(pngimage_sources
+  contrib/libtests/pngimage.c
+)
+set(pngfix_sources
+  contrib/tools/pngfix.c
+)
+set(png_fix_itxt_sources
+  contrib/tools/png-fix-itxt.c
+)
+
+if(MSVC)
+  add_definitions(-D_CRT_SECURE_NO_DEPRECATE)
+endif()
+
+if(PNG_DEBUG)
+  add_definitions(-DPNG_DEBUG)
+endif()
+
+# NOW BUILD OUR TARGET
+include_directories(${CMAKE_CURRENT_SOURCE_DIR} ${ZLIB_INCLUDE_DIR})
+
+unset(PNG_LIB_TARGETS)
+
+if(PNG_STATIC)
+  # does not work without changing name
+  set(PNG_LIB_NAME_STATIC png_static)
+  add_library(png_static STATIC ${libpng_sources})
+  add_dependencies(png_static genfiles)
+  # MSVC doesn't use a different file extension for shared vs. static
+  # libs.  We are able to change OUTPUT_NAME to remove the _static
+  # for all other platforms.
+  if(NOT MSVC)
+    set_target_properties(png_static PROPERTIES
+      OUTPUT_NAME "${PNG_LIB_NAME}"
+      CLEAN_DIRECT_OUTPUT 1)
+  else()
+    set_target_properties(png_static PROPERTIES
+      OUTPUT_NAME "${PNG_LIB_NAME}_static"
+      CLEAN_DIRECT_OUTPUT 1)
+  endif()
+  list(APPEND PNG_LIB_TARGETS png_static)
+  if(MSVC)
+    # msvc does not append 'lib' - do it here to have consistent name
+    set_target_properties(png_static PROPERTIES PREFIX "lib")
+  endif()
+  target_link_libraries(png_static ${M_LIBRARY})
+endif()
+
+if(NOT PNG_LIB_TARGETS)
+  message(SEND_ERROR
+    "No library variant selected to build. "
+    "Please enable at least one of the following options: "
+    "PNG_STATIC, PNG_SHARED, PNG_FRAMEWORK")
+endif()
+
+# Set a variable with CMake code which:
+# Creates a symlink from src to dest (if possible) or alternatively
+# copies if different.
+include(CMakeParseArguments)
+
+function(create_symlink DEST_FILE)
+
+  cmake_parse_arguments(S "" "FILE;TARGET" "" ${ARGN})
+
+  if(NOT S_TARGET AND NOT S_FILE)
+    message(FATAL_ERROR "create_symlink: Missing TARGET or FILE argument")
+  endif()
+
+  if(S_TARGET AND S_FILE)
+    message(FATAL_ERROR "create_symlink: Both source file ${S_FILE} and build target ${S_TARGET} arguments are present; can only have one.")
+  endif()
+
+  if(S_FILE)
+    # If we don't need to symlink something that's coming from a build target,
+    # we can go ahead and symlink/copy at configure time.
+    if(CMAKE_HOST_WIN32 AND NOT CYGWIN)
+      execute_process(
+        COMMAND "${CMAKE_COMMAND}" -E copy_if_different ${S_FILE} ${DEST_FILE}
+        WORKING_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}")
+    else()
+      execute_process(
+        COMMAND ${CMAKE_COMMAND} -E create_symlink ${S_FILE} ${DEST_FILE}
+        WORKING_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}")
+    endif()
+  endif()
+
+  if(S_TARGET)
+    # We need to use generator expressions, which can be a bit tricky, so for
+    # simplicity make the symlink a POST_BUILD step and use the TARGET
+    # signature of add_custom_command.
+    if(CMAKE_HOST_WIN32 AND NOT CYGWIN)
+      add_custom_command(TARGET ${S_TARGET} POST_BUILD
+        COMMAND "${CMAKE_COMMAND}" -E copy_if_different $<TARGET_LINKER_FILE_NAME:${S_TARGET}> $<TARGET_LINKER_FILE_DIR:${S_TARGET}>/${DEST_FILE})
+    else()
+      add_custom_command(TARGET ${S_TARGET} POST_BUILD
+        COMMAND "${CMAKE_COMMAND}" -E create_symlink $<TARGET_LINKER_FILE_NAME:${S_TARGET}> $<TARGET_LINKER_FILE_DIR:${S_TARGET}>/${DEST_FILE})
+    endif()
+  endif()
+
+endfunction()
+
+# Create source generation scripts.
+configure_file(${CMAKE_CURRENT_SOURCE_DIR}/scripts/genchk.cmake.in
+               ${CMAKE_CURRENT_BINARY_DIR}/scripts/genchk.cmake @ONLY)
+configure_file(${CMAKE_CURRENT_SOURCE_DIR}/scripts/genout.cmake.in
+               ${CMAKE_CURRENT_BINARY_DIR}/scripts/genout.cmake @ONLY)
+configure_file(${CMAKE_CURRENT_SOURCE_DIR}/scripts/gensrc.cmake.in
+               ${CMAKE_CURRENT_BINARY_DIR}/scripts/gensrc.cmake @ONLY)
+
+# libpng is a library so default to 'lib'
+if(NOT DEFINED CMAKE_INSTALL_LIBDIR)
+  set(CMAKE_INSTALL_LIBDIR lib)
+endif()
+
+# CREATE PKGCONFIG FILES
+# We use the same files like ./configure, so we have to set its vars.
+# Only do this on Windows for Cygwin - the files don't make much sense outside
+# of a UNIX look-alike.
+if(NOT WIN32 OR CYGWIN OR MINGW)
+  set(prefix      ${CMAKE_INSTALL_PREFIX})
+  set(exec_prefix ${CMAKE_INSTALL_PREFIX})
+  set(libdir      ${CMAKE_INSTALL_FULL_LIBDIR})
+  set(includedir  ${CMAKE_INSTALL_FULL_INCLUDEDIR})
+  set(LIBS        "-lz -lm")
+  configure_file(${CMAKE_CURRENT_SOURCE_DIR}/libpng.pc.in
+    ${CMAKE_CURRENT_BINARY_DIR}/${PNGLIB_NAME}.pc @ONLY)
+  create_symlink(libpng.pc FILE ${PNGLIB_NAME}.pc)
+
+  configure_file(${CMAKE_CURRENT_SOURCE_DIR}/libpng-config.in
+    ${CMAKE_CURRENT_BINARY_DIR}/${PNGLIB_NAME}-config @ONLY)
+  create_symlink(libpng-config FILE ${PNGLIB_NAME}-config)
+endif()
+
+# SET UP LINKS
+if(PNG_SHARED)
+  set_target_properties(png PROPERTIES
+#   VERSION 16.${PNGLIB_RELEASE}.1.6.37
+    VERSION 16.${PNGLIB_RELEASE}.0
+    SOVERSION 16
+    CLEAN_DIRECT_OUTPUT 1)
+endif()
+
+# INSTALL
+if(NOT SKIP_INSTALL_LIBRARIES AND NOT SKIP_INSTALL_ALL)
+  install(TARGETS ${PNG_LIB_TARGETS}
+          EXPORT libpng
+          RUNTIME DESTINATION bin
+          LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
+          ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
+          FRAMEWORK DESTINATION ${CMAKE_INSTALL_LIBDIR})
+
+  if(PNG_SHARED)
+    # Create a symlink for libpng.dll.a => libpng16.dll.a on Cygwin
+    if(CYGWIN OR MINGW)
+      create_symlink(libpng${CMAKE_IMPORT_LIBRARY_SUFFIX} TARGET png)
+      install(FILES $<TARGET_LINKER_FILE_DIR:png>/libpng${CMAKE_IMPORT_LIBRARY_SUFFIX}
+              DESTINATION ${CMAKE_INSTALL_LIBDIR})
+    endif()
+
+    if(NOT WIN32)
+      create_symlink(libpng${CMAKE_SHARED_LIBRARY_SUFFIX} TARGET png)
+      install(FILES $<TARGET_LINKER_FILE_DIR:png>/libpng${CMAKE_SHARED_LIBRARY_SUFFIX}
+              DESTINATION ${CMAKE_INSTALL_LIBDIR})
+    endif()
+  endif()
+
+  if(PNG_STATIC)
+    if(NOT WIN32 OR CYGWIN OR MINGW)
+      create_symlink(libpng${CMAKE_STATIC_LIBRARY_SUFFIX} TARGET png_static)
+      install(FILES $<TARGET_LINKER_FILE_DIR:png_static>/libpng${CMAKE_STATIC_LIBRARY_SUFFIX}
+              DESTINATION ${CMAKE_INSTALL_LIBDIR})
+    endif()
+  endif()
+endif()
+
+if(NOT SKIP_INSTALL_HEADERS AND NOT SKIP_INSTALL_ALL)
+  install(FILES ${libpng_public_hdrs} DESTINATION include)
+  install(FILES ${libpng_public_hdrs} DESTINATION include/${PNGLIB_NAME})
+endif()
+if(NOT SKIP_INSTALL_EXECUTABLES AND NOT SKIP_INSTALL_ALL)
+  if(NOT WIN32 OR CYGWIN OR MINGW)
+    install(PROGRAMS ${CMAKE_CURRENT_BINARY_DIR}/libpng-config DESTINATION bin)
+    install(PROGRAMS ${CMAKE_CURRENT_BINARY_DIR}/${PNGLIB_NAME}-config DESTINATION bin)
+  endif()
+endif()
+
+if(NOT SKIP_INSTALL_PROGRAMS AND NOT SKIP_INSTALL_ALL)
+  install(TARGETS ${PNG_BIN_TARGETS}
+          RUNTIME DESTINATION bin)
+endif()
+
+if(NOT SKIP_INSTALL_FILES AND NOT SKIP_INSTALL_ALL)
+  # Install man pages
+  if(NOT PNG_MAN_DIR)
+    set(PNG_MAN_DIR "share/man")
+  endif()
+  install(FILES libpng.3 libpngpf.3 DESTINATION ${PNG_MAN_DIR}/man3)
+  install(FILES png.5 DESTINATION ${PNG_MAN_DIR}/man5)
+  # Install pkg-config files
+  if(NOT CMAKE_HOST_WIN32 OR CYGWIN OR MINGW)
+    install(FILES ${CMAKE_CURRENT_BINARY_DIR}/libpng.pc
+            DESTINATION ${CMAKE_INSTALL_LIBDIR}/pkgconfig)
+    install(PROGRAMS ${CMAKE_CURRENT_BINARY_DIR}/libpng-config
+            DESTINATION bin)
+    install(FILES ${CMAKE_CURRENT_BINARY_DIR}/${PNGLIB_NAME}.pc
+            DESTINATION ${CMAKE_INSTALL_LIBDIR}/pkgconfig)
+    install(PROGRAMS ${CMAKE_CURRENT_BINARY_DIR}/${PNGLIB_NAME}-config
+            DESTINATION bin)
+  endif()
+endif()
+
+# Create an export file that CMake users can include() to import our targets.
+if(NOT SKIP_INSTALL_EXPORT AND NOT SKIP_INSTALL_ALL)
+  install(EXPORT libpng DESTINATION lib/libpng FILE lib${PNG_LIB_NAME}.cmake)
+endif()
+
+# what's with libpng-manual.txt and all the extra files?
+
+# UNINSTALL
+# do we need this?
+
+# DIST
+# do we need this?
+
+# to create msvc import lib for mingw compiled shared lib
+# pexports libpng.dll > libpng.def
+# lib /def:libpng.def /machine:x86

cmake/CMakeLists.txt

@@ -135,9 +135,14 @@ set(CMAKE_CXX_EXTENSIONS OFF CACHE BOOL "Use compiler extensions")
 # ugly hacks for MSVC which by default always reports an old C++ standard in the __cplusplus macro
 # and prints lots of pointless warnings about "unsafe" functions
 if(MSVC)
-  add_compile_options(/Zc:__cplusplus)
-  add_compile_options(/wd4244)
-  add_compile_options(/wd4267)
+  if(CMAKE_CXX_COMPILER_ID STREQUAL "MSVC")
+    add_compile_options(/Zc:__cplusplus)
+    add_compile_options(/wd4244)
+    add_compile_options(/wd4267)
+    if(LAMMPS_EXCEPTIONS)
+      add_compile_options(/EHsc)
+    endif()
+  endif()
   add_compile_definitions(_CRT_SECURE_NO_WARNINGS)
 endif()
 
@@ -189,6 +194,7 @@ option(CMAKE_VERBOSE_MAKEFILE "Generate verbose Makefiles" OFF)
 
 set(STANDARD_PACKAGES
   ADIOS
+  AMOEBA
   ASPHERE
   ATC
   AWPMD
@@ -353,6 +359,7 @@ pkg_depends(MPIIO MPI)
 pkg_depends(ATC MANYBODY)
 pkg_depends(LATBOLTZ MPI)
 pkg_depends(SCAFACOS MPI)
+pkg_depends(AMOEBA KSPACE)
 pkg_depends(DIELECTRIC KSPACE)
 pkg_depends(DIELECTRIC EXTRA-PAIR)
 pkg_depends(CG-DNA MOLECULE)
@@ -781,14 +788,16 @@ if(BUILD_SHARED_LIBS)
     find_package(Python COMPONENTS Interpreter)
   endif()
   if(BUILD_IS_MULTI_CONFIG)
-    set(LIBLAMMPS_SHARED_BINARY ${CMAKE_BINARY_DIR}/$<CONFIG>/liblammps${LAMMPS_MACHINE}${CMAKE_SHARED_LIBRARY_SUFFIX})
+    set(MY_BUILD_DIR ${CMAKE_BINARY_DIR}/$<CONFIG>)
   else()
-    set(LIBLAMMPS_SHARED_BINARY ${CMAKE_BINARY_DIR}/liblammps${LAMMPS_MACHINE}${CMAKE_SHARED_LIBRARY_SUFFIX})
+    set(MY_BUILD_DIR ${CMAKE_BINARY_DIR})
   endif()
+  set(LIBLAMMPS_SHARED_BINARY ${MY_BUILD_DIR}/liblammps${LAMMPS_MACHINE}${CMAKE_SHARED_LIBRARY_SUFFIX})
   if(Python_EXECUTABLE)
     add_custom_target(
       install-python ${CMAKE_COMMAND} -E remove_directory build
-      COMMAND ${Python_EXECUTABLE} ${LAMMPS_PYTHON_DIR}/install.py -p ${LAMMPS_PYTHON_DIR}/lammps -l ${LIBLAMMPS_SHARED_BINARY}
+      COMMAND ${Python_EXECUTABLE} ${LAMMPS_PYTHON_DIR}/install.py -p ${LAMMPS_PYTHON_DIR}/lammps
+              -l ${LIBLAMMPS_SHARED_BINARY} -w ${MY_BUILD_DIR}
       COMMENT "Installing LAMMPS Python module")
   else()
     add_custom_target(

cmake/CMakeLists.zlib

@@ -0,0 +1,195 @@
+cmake_minimum_required(VERSION 3.10)
+# When using CMake 3.4 and later, don't export symbols from executables unless
+# the CMAKE_ENABLE_EXPORTS variable is set.
+if(POLICY CMP0065)
+  cmake_policy(SET CMP0065 NEW)
+endif()
+if (POLICY CMP0077)
+  cmake_policy(SET CMP0077 NEW)
+endif()
+set(CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS ON)
+
+project(zlib C)
+
+set(VERSION "1.2.11")
+
+option(ASM686 "Enable building i686 assembly implementation" OFF)
+option(AMD64 "Enable building amd64 assembly implementation" OFF)
+
+set(INSTALL_BIN_DIR "${CMAKE_INSTALL_PREFIX}/bin" CACHE PATH "Installation directory for executables")
+set(INSTALL_LIB_DIR "${CMAKE_INSTALL_PREFIX}/lib" CACHE PATH "Installation directory for libraries")
+set(INSTALL_INC_DIR "${CMAKE_INSTALL_PREFIX}/include" CACHE PATH "Installation directory for headers")
+set(INSTALL_MAN_DIR "${CMAKE_INSTALL_PREFIX}/share/man" CACHE PATH "Installation directory for manual pages")
+set(INSTALL_PKGCONFIG_DIR "${CMAKE_INSTALL_PREFIX}/share/pkgconfig" CACHE PATH "Installation directory for pkgconfig (.pc) files")
+
+include(CheckTypeSize)
+include(CheckFunctionExists)
+include(CheckIncludeFile)
+include(CheckCSourceCompiles)
+
+check_include_file(sys/types.h HAVE_SYS_TYPES_H)
+check_include_file(stdint.h    HAVE_STDINT_H)
+check_include_file(stddef.h    HAVE_STDDEF_H)
+
+#
+# Check to see if we have large file support
+#
+set(CMAKE_REQUIRED_DEFINITIONS -D_LARGEFILE64_SOURCE=1)
+# We add these other definitions here because CheckTypeSize.cmake
+# in CMake 2.4.x does not automatically do so and we want
+# compatibility with CMake 2.4.x.
+if(HAVE_SYS_TYPES_H)
+    list(APPEND CMAKE_REQUIRED_DEFINITIONS -DHAVE_SYS_TYPES_H)
+endif()
+if(HAVE_STDINT_H)
+    list(APPEND CMAKE_REQUIRED_DEFINITIONS -DHAVE_STDINT_H)
+endif()
+if(HAVE_STDDEF_H)
+    list(APPEND CMAKE_REQUIRED_DEFINITIONS -DHAVE_STDDEF_H)
+endif()
+check_type_size(off64_t OFF64_T)
+check_type_size(off64_t OFF64_T)
+if(HAVE_OFF64_T)
+   add_definitions(-D_LARGEFILE64_SOURCE=1)
+endif()
+set(CMAKE_REQUIRED_DEFINITIONS) # clear variable
+
+#
+# Check for fseeko
+#
+check_function_exists(fseeko HAVE_FSEEKO)
+if(NOT HAVE_FSEEKO)
+    add_definitions(-DNO_FSEEKO)
+endif()
+
+#
+# Check for unistd.h
+#
+check_include_file(unistd.h Z_HAVE_UNISTD_H)
+
+if(MSVC)
+    set(CMAKE_DEBUG_POSTFIX "d")
+    add_definitions(-D_CRT_SECURE_NO_DEPRECATE)
+    add_definitions(-D_CRT_NONSTDC_NO_DEPRECATE)
+    include_directories(${CMAKE_CURRENT_SOURCE_DIR})
+endif()
+
+if(NOT CMAKE_CURRENT_SOURCE_DIR STREQUAL CMAKE_CURRENT_BINARY_DIR)
+    # If we're doing an out of source build and the user has a zconf.h
+    # in their source tree...
+    if(EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/zconf.h)
+        file(RENAME ${CMAKE_CURRENT_SOURCE_DIR}/zconf.h ${CMAKE_CURRENT_SOURCE_DIR}/zconf.h.included)
+  endif()
+endif()
+
+set(ZLIB_PC ${CMAKE_CURRENT_BINARY_DIR}/zlib.pc)
+configure_file( ${CMAKE_CURRENT_SOURCE_DIR}/zlib.pc.cmakein
+		${ZLIB_PC} @ONLY)
+configure_file(	${CMAKE_CURRENT_SOURCE_DIR}/zconf.h.cmakein
+		${CMAKE_CURRENT_BINARY_DIR}/zconf.h @ONLY)
+include_directories(${CMAKE_CURRENT_BINARY_DIR} ${CMAKE_SOURCE_DIR})
+
+
+#============================================================================
+# zlib
+#============================================================================
+
+set(ZLIB_PUBLIC_HDRS
+    ${CMAKE_CURRENT_BINARY_DIR}/zconf.h
+    zlib.h
+)
+set(ZLIB_PRIVATE_HDRS
+    crc32.h
+    deflate.h
+    gzguts.h
+    inffast.h
+    inffixed.h
+    inflate.h
+    inftrees.h
+    trees.h
+    zutil.h
+)
+set(ZLIB_SRCS
+    adler32.c
+    compress.c
+    crc32.c
+    deflate.c
+    gzclose.c
+    gzlib.c
+    gzread.c
+    gzwrite.c
+    inflate.c
+    infback.c
+    inftrees.c
+    inffast.c
+    trees.c
+    uncompr.c
+    zutil.c
+)
+
+if(NOT MINGW)
+    set(ZLIB_DLL_SRCS
+        win32/zlib1.rc # If present will override custom build rule below.
+    )
+endif()
+
+if(CMAKE_COMPILER_IS_GNUCC)
+    if(ASM686)
+        set(ZLIB_ASMS contrib/asm686/match.S)
+    elseif (AMD64)
+        set(ZLIB_ASMS contrib/amd64/amd64-match.S)
+    endif ()
+
+	if(ZLIB_ASMS)
+		add_definitions(-DASMV)
+		set_source_files_properties(${ZLIB_ASMS} PROPERTIES LANGUAGE C COMPILE_FLAGS -DNO_UNDERLINE)
+	endif()
+endif()
+
+if(MSVC)
+    if(ASM686)
+		ENABLE_LANGUAGE(ASM_MASM)
+        set(ZLIB_ASMS
+			contrib/masmx86/inffas32.asm
+			contrib/masmx86/match686.asm
+		)
+    elseif (AMD64)
+		ENABLE_LANGUAGE(ASM_MASM)
+        set(ZLIB_ASMS
+			contrib/masmx64/gvmat64.asm
+			contrib/masmx64/inffasx64.asm
+		)
+    endif()
+
+	if(ZLIB_ASMS)
+		add_definitions(-DASMV -DASMINF)
+	endif()
+endif()
+
+# parse the full version number from zlib.h and include in ZLIB_FULL_VERSION
+file(READ ${CMAKE_CURRENT_SOURCE_DIR}/zlib.h _zlib_h_contents)
+string(REGEX REPLACE ".*#define[ \t]+ZLIB_VERSION[ \t]+\"([-0-9A-Za-z.]+)\".*"
+    "\\1" ZLIB_FULL_VERSION ${_zlib_h_contents})
+
+if(MINGW)
+    # This gets us DLL resource information when compiling on MinGW.
+    if(NOT CMAKE_RC_COMPILER)
+        set(CMAKE_RC_COMPILER windres.exe)
+    endif()
+
+    add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/zlib1rc.obj
+                       COMMAND ${CMAKE_RC_COMPILER}
+                            -D GCC_WINDRES
+                            -I ${CMAKE_CURRENT_SOURCE_DIR}
+                            -I ${CMAKE_CURRENT_BINARY_DIR}
+                            -o ${CMAKE_CURRENT_BINARY_DIR}/zlib1rc.obj
+                            -i ${CMAKE_CURRENT_SOURCE_DIR}/win32/zlib1.rc)
+    set(ZLIB_DLL_SRCS ${CMAKE_CURRENT_BINARY_DIR}/zlib1rc.obj)
+endif(MINGW)
+
+add_library(zlibstatic STATIC ${ZLIB_SRCS} ${ZLIB_ASMS} ${ZLIB_PUBLIC_HDRS} ${ZLIB_PRIVATE_HDRS})
+
+if(UNIX)
+    # On unix-like platforms the library is almost always called libz
+   set_target_properties(zlibstatic PROPERTIES OUTPUT_NAME z)
+endif()

cmake/CMakeSettings.json

@@ -8,7 +8,7 @@
       "installRoot": "${workspaceRoot}\\install\\${name}",
       "cmakeCommandArgs": "-C ${workspaceRoot}\\cmake\\presets\\windows.cmake",
       "buildCommandArgs": "",
-      "ctestCommandArgs": "",
+      "ctestCommandArgs": "-V",
       "inheritEnvironments": [ "msvc_x64_x64" ],
       "variables": [
         {
@@ -26,11 +26,6 @@
           "value": "True",
           "type": "BOOL"
         },
-        {
-          "name": "PKG_PYTHON",
-          "value": "True",
-          "type": "BOOL"
-        },
         {
           "name": "ENABLE_TESTING",
           "value": "True",
@@ -46,7 +41,7 @@
       "installRoot": "${workspaceRoot}\\install\\${name}",
       "cmakeCommandArgs": "-C ${workspaceRoot}\\cmake\\presets\\windows.cmake",
       "buildCommandArgs": "",
-      "ctestCommandArgs": "",
+      "ctestCommandArgs": "-V",
       "inheritEnvironments": [ "msvc_x64_x64" ],
       "variables": [
         {
@@ -64,11 +59,6 @@
           "value": "True",
           "type": "BOOL"
         },
-        {
-          "name": "PKG_PYTHON",
-          "value": "True",
-          "type": "BOOL"
-        },
         {
           "name": "ENABLE_TESTING",
           "value": "True",
@@ -102,11 +92,6 @@
           "value": "True",
           "type": "BOOL"
         },
-        {
-          "name": "PKG_PYTHON",
-          "value": "True",
-          "type": "BOOL"
-        },
         {
           "name": "ENABLE_TESTING",
           "value": "True",
@@ -122,7 +107,7 @@
       "installRoot": "${workspaceRoot}\\install\\${name}",
       "cmakeCommandArgs": "-C ${workspaceRoot}\\cmake\\presets\\windows.cmake -DCMAKE_C_COMPILER=clang-cl.exe -DCMAKE_CXX_COMPILER=clang-cl.exe",
       "buildCommandArgs": "",
-      "ctestCommandArgs": "",
+      "ctestCommandArgs": "-V",
       "inheritEnvironments": [ "clang_cl_x64" ],
       "variables": [
         {
@@ -140,11 +125,6 @@
           "value": "True",
           "type": "BOOL"
         },
-        {
-          "name": "PKG_PYTHON",
-          "value": "True",
-          "type": "BOOL"
-        },
         {
           "name": "ENABLE_TESTING",
           "value": "True",
@@ -158,9 +138,16 @@
       "configurationType": "Debug",
       "buildRoot": "${workspaceRoot}\\build\\${name}",
       "installRoot": "${workspaceRoot}\\install\\${name}",
+      "buildCommandArgs": "",
+      "ctestCommandArgs": "-V",
       "inheritEnvironments": [],
       "cmakeCommandArgs": "-C ${workspaceRoot}\\cmake\\presets\\windows-intel-llvm.cmake -C ${workspaceRoot}\\cmake\\presets\\windows.cmake",
       "variables": [
+        {
+          "name": "PKG_ELECTRODE",
+          "value": "True",
+          "type": "BOOL"
+        },
         {
           "name": "BUILD_SHARED_LIBS",
           "value": "True",
@@ -176,11 +163,6 @@
           "value": "True",
           "type": "BOOL"
         },
-        {
-          "name": "PKG_PYTHON",
-          "value": "True",
-          "type": "BOOL"
-        },
         {
           "name": "ENABLE_TESTING",
           "value": "True",
@@ -190,11 +172,6 @@
           "name": "FFT",
           "value": "MKL",
           "type": "STRING"
-        },
-        {
-          "name": "PKG_PLUGIN",
-          "value": "True",
-          "type": "BOOL"
         }
       ]
     },
@@ -205,8 +182,15 @@
       "buildRoot": "${workspaceRoot}\\build\\${name}",
       "installRoot": "${workspaceRoot}\\install\\${name}",
       "cmakeCommandArgs": "-C ${workspaceRoot}\\cmake\\presets\\windows-intel-llvm.cmake -C ${workspaceRoot}\\cmake\\presets\\windows.cmake",
+      "buildCommandArgs": "",
+      "ctestCommandArgs": "-V",
       "inheritEnvironments": [],
       "variables": [
+        {
+          "name": "PKG_ELECTRODE",
+          "value": "True",
+          "type": "BOOL"
+        },
         {
           "name": "BUILD_SHARED_LIBS",
           "value": "True",
@@ -222,11 +206,6 @@
           "value": "True",
           "type": "BOOL"
         },
-        {
-          "name": "PKG_PYTHON",
-          "value": "True",
-          "type": "BOOL"
-        },
         {
           "name": "ENABLE_TESTING",
           "value": "True",
@@ -236,11 +215,6 @@
           "name": "FFT",
           "value": "MKL",
           "type": "STRING"
-        },
-        {
-          "name": "PKG_PLUGIN",
-          "value": "True",
-          "type": "BOOL"
         }
       ]
     },
@@ -251,8 +225,15 @@
       "buildRoot": "${workspaceRoot}\\build\\${name}",
       "installRoot": "${workspaceRoot}\\install\\${name}",
       "cmakeCommandArgs": "-C ${workspaceRoot}\\cmake\\presets\\windows-intel-classic.cmake -C ${workspaceRoot}\\cmake\\presets\\windows.cmake",
+      "buildCommandArgs": "",
+      "ctestCommandArgs": "-V",
       "inheritEnvironments": [],
       "variables": [
+        {
+          "name": "PKG_ELECTRODE",
+          "value": "True",
+          "type": "BOOL"
+        },
         {
           "name": "BUILD_SHARED_LIBS",
           "value": "True",
@@ -268,11 +249,6 @@
           "value": "True",
           "type": "BOOL"
         },
-        {
-          "name": "PKG_PYTHON",
-          "value": "True",
-          "type": "BOOL"
-        },
         {
           "name": "ENABLE_TESTING",
           "value": "False",
@@ -282,11 +258,6 @@
           "name": "FFT",
           "value": "MKL",
           "type": "STRING"
-        },
-        {
-          "name": "PKG_PLUGIN",
-          "value": "True",
-          "type": "BOOL"
         }
       ]
     },
@@ -297,8 +268,15 @@
       "buildRoot": "${workspaceRoot}\\build\\${name}",
       "installRoot": "${workspaceRoot}\\install\\${name}",
       "cmakeCommandArgs": "-C ${workspaceRoot}\\cmake\\presets\\windows-intel-classic.cmake -C ${workspaceRoot}\\cmake\\presets\\windows.cmake",
+      "buildCommandArgs": "",
+      "ctestCommandArgs": "-V",
       "inheritEnvironments": [],
       "variables": [
+        {
+          "name": "PKG_ELECTRODE",
+          "value": "True",
+          "type": "BOOL"
+        },
         {
           "name": "BUILD_SHARED_LIBS",
           "value": "True",
@@ -314,11 +292,6 @@
           "value": "True",
           "type": "BOOL"
         },
-        {
-          "name": "PKG_PYTHON",
-          "value": "True",
-          "type": "BOOL"
-        },
         {
           "name": "ENABLE_TESTING",
           "value": "False",
@@ -328,11 +301,6 @@
           "name": "FFT",
           "value": "MKL",
           "type": "STRING"
-        },
-        {
-          "name": "PKG_PLUGIN",
-          "value": "True",
-          "type": "BOOL"
         }
       ]
     }

cmake/Modules/LAMMPSInterfacePlugin.cmake

@@ -0,0 +1,208 @@
+# CMake script code to define LAMMPS settings required for building LAMMPS plugins
+
+# enforce out-of-source build
+if(${CMAKE_SOURCE_DIR} STREQUAL ${CMAKE_BINARY_DIR})
+  message(FATAL_ERROR "In-source builds are not allowed. You must create and use a build directory. "
+    "Please remove CMakeCache.txt and CMakeFiles first.")
+endif()
+
+set(LAMMPS_THIRDPARTY_URL "https://download.lammps.org/thirdparty"
+  CACHE STRING "URL for thirdparty package downloads")
+
+# global LAMMPS/plugin build settings
+set(LAMMPS_SOURCE_DIR ""  CACHE PATH "Location of LAMMPS sources folder")
+if(NOT LAMMPS_SOURCE_DIR)
+  message(FATAL_ERROR "Must set LAMMPS_SOURCE_DIR")
+endif()
+
+# by default, install into $HOME/.local (not /usr/local),
+# so that no root access (and sudo) is needed
+if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
+  set(CMAKE_INSTALL_PREFIX "$ENV{HOME}/.local" CACHE PATH "Default install path" FORCE)
+endif()
+
+# 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)
+  if(CMAKE_CXX_COMPILER_ID STREQUAL "MSVC")
+    add_compile_options(/Zc:__cplusplus)
+    add_compile_options(/wd4244)
+    add_compile_options(/wd4267)
+    if(LAMMPS_EXCEPTIONS)
+      add_compile_options(/EHsc)
+    endif()
+  endif()
+  add_compile_definitions(_CRT_SECURE_NO_WARNINGS)
+endif()
+
+# C++11 is required
+set(CMAKE_CXX_STANDARD 11)
+set(CMAKE_CXX_STANDARD_REQUIRED ON)
+
+# Need -restrict with Intel compilers
+if(CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
+  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -restrict")
+endif()
+set(CMAKE_POSITION_INDEPENDENT_CODE TRUE)
+
+#######
+# helper functions from LAMMPSUtils.cmake
+function(validate_option name values)
+  string(TOLOWER ${${name}} needle_lower)
+  string(TOUPPER ${${name}} needle_upper)
+  list(FIND ${values} ${needle_lower} IDX_LOWER)
+  list(FIND ${values} ${needle_upper} IDX_UPPER)
+  if(${IDX_LOWER} LESS 0 AND ${IDX_UPPER} LESS 0)
+    list_to_bulletpoints(POSSIBLE_VALUE_LIST ${${values}})
+    message(FATAL_ERROR "\n########################################################################\n"
+      "Invalid value '${${name}}' for option ${name}\n"
+      "\n"
+      "Possible values are:\n"
+      "${POSSIBLE_VALUE_LIST}"
+      "########################################################################")
+  endif()
+endfunction(validate_option)
+
+# helper function for getting the most recently modified file or folder from a glob pattern
+function(get_newest_file path variable)
+  file(GLOB _dirs ${path})
+  set(_besttime 2000-01-01T00:00:00)
+  set(_bestfile "<unknown>")
+  foreach(_dir ${_dirs})
+    file(TIMESTAMP ${_dir} _newtime)
+    if(_newtime IS_NEWER_THAN _besttime)
+      set(_bestfile ${_dir})
+      set(_besttime ${_newtime})
+    endif()
+  endforeach()
+  if(_bestfile STREQUAL "<unknown>")
+    message(FATAL_ERROR "Could not find valid path at: ${path}")
+  endif()
+  set(${variable} ${_bestfile} PARENT_SCOPE)
+endfunction()
+
+# get LAMMPS version date
+function(get_lammps_version version_header variable)
+    file(STRINGS ${version_header} line REGEX LAMMPS_VERSION)
+    string(REGEX REPLACE "#define LAMMPS_VERSION \"([0-9]+) ([A-Za-z]+) ([0-9]+)\"" "\\1\\2\\3" date "${line}")
+    set(${variable} "${date}" PARENT_SCOPE)
+endfunction()
+
+#################################################################################
+# LAMMPS C++ interface. We only need the header related parts except on windows.
+add_library(lammps INTERFACE)
+target_include_directories(lammps INTERFACE ${LAMMPS_SOURCE_DIR})
+if((CMAKE_SYSTEM_NAME STREQUAL "Windows") AND CMAKE_CROSSCOMPILING)
+  target_link_libraries(lammps INTERFACE ${CMAKE_BINARY_DIR}/../liblammps.dll.a)
+endif()
+
+################################################################################
+# MPI configuration
+if(NOT CMAKE_CROSSCOMPILING)
+  set(MPI_CXX_SKIP_MPICXX TRUE)
+  find_package(MPI QUIET)
+  option(BUILD_MPI "Build MPI version" ${MPI_FOUND})
+else()
+  option(BUILD_MPI "Build MPI version" OFF)
+endif()
+
+if(BUILD_MPI)
+  # do not include the (obsolete) MPI C++ bindings which makes
+  # for leaner object files and avoids namespace conflicts
+  set(MPI_CXX_SKIP_MPICXX TRUE)
+  # We use a non-standard procedure to cross-compile with MPI on Windows
+  if((CMAKE_SYSTEM_NAME STREQUAL "Windows") AND CMAKE_CROSSCOMPILING)
+    # Download and configure custom MPICH files for Windows
+    message(STATUS "Downloading and configuring MPICH-1.4.1 for Windows")
+    set(MPICH2_WIN64_DEVEL_URL "${LAMMPS_THIRDPARTY_URL}/mpich2-win64-devel.tar.gz" CACHE STRING "URL for MPICH2 (win64) tarball")
+    set(MPICH2_WIN32_DEVEL_URL "${LAMMPS_THIRDPARTY_URL}/mpich2-win32-devel.tar.gz" CACHE STRING "URL for MPICH2 (win32) tarball")
+    set(MPICH2_WIN64_DEVEL_MD5 "4939fdb59d13182fd5dd65211e469f14" CACHE STRING "MD5 checksum of MPICH2 (win64) tarball")
+    set(MPICH2_WIN32_DEVEL_MD5 "a61d153500dce44e21b755ee7257e031" CACHE STRING "MD5 checksum of MPICH2 (win32) tarball")
+    mark_as_advanced(MPICH2_WIN64_DEVEL_URL)
+    mark_as_advanced(MPICH2_WIN32_DEVEL_URL)
+    mark_as_advanced(MPICH2_WIN64_DEVEL_MD5)
+    mark_as_advanced(MPICH2_WIN32_DEVEL_MD5)
+
+    include(ExternalProject)
+    if(CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64")
+      ExternalProject_Add(mpi4win_build
+        URL     ${MPICH2_WIN64_DEVEL_URL}
+        URL_MD5 ${MPICH2_WIN64_DEVEL_MD5}
+        CONFIGURE_COMMAND "" BUILD_COMMAND "" INSTALL_COMMAND ""
+        BUILD_BYPRODUCTS <SOURCE_DIR>/lib/libmpi.a)
+    else()
+      ExternalProject_Add(mpi4win_build
+        URL     ${MPICH2_WIN32_DEVEL_URL}
+        URL_MD5 ${MPICH2_WIN32_DEVEL_MD5}
+        CONFIGURE_COMMAND "" BUILD_COMMAND "" INSTALL_COMMAND ""
+        BUILD_BYPRODUCTS <SOURCE_DIR>/lib/libmpi.a)
+    endif()
+
+    ExternalProject_get_property(mpi4win_build SOURCE_DIR)
+    file(MAKE_DIRECTORY "${SOURCE_DIR}/include")
+    add_library(MPI::MPI_CXX UNKNOWN IMPORTED)
+    set_target_properties(MPI::MPI_CXX PROPERTIES
+      IMPORTED_LOCATION "${SOURCE_DIR}/lib/libmpi.a"
+      INTERFACE_INCLUDE_DIRECTORIES "${SOURCE_DIR}/include"
+      INTERFACE_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX")
+    add_dependencies(MPI::MPI_CXX mpi4win_build)
+
+    # set variables for status reporting at the end of CMake run
+    set(MPI_CXX_INCLUDE_PATH "${SOURCE_DIR}/include")
+    set(MPI_CXX_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX")
+    set(MPI_CXX_LIBRARIES "${SOURCE_DIR}/lib/libmpi.a")
+  else()
+    find_package(MPI REQUIRED)
+    option(LAMMPS_LONGLONG_TO_LONG "Workaround if your system or MPI version does not recognize 'long long' data types" OFF)
+    if(LAMMPS_LONGLONG_TO_LONG)
+      target_compile_definitions(lammps INTERFACE -DLAMMPS_LONGLONG_TO_LONG)
+    endif()
+  endif()
+  target_link_libraries(lammps INTERFACE MPI::MPI_CXX)
+else()
+  add_library(mpi_stubs INTERFACE)
+  target_include_directories(mpi_stubs INTERFACE $<BUILD_INTERFACE:${LAMMPS_SOURCE_DIR}/STUBS>)
+  target_link_libraries(lammps INTERFACE mpi_stubs)
+endif()
+
+################################################################################
+# detect if we may enable OpenMP support by default
+set(BUILD_OMP_DEFAULT OFF)
+find_package(OpenMP QUIET)
+if(OpenMP_FOUND)
+  check_include_file_cxx(omp.h HAVE_OMP_H_INCLUDE)
+  if(HAVE_OMP_H_INCLUDE)
+    set(BUILD_OMP_DEFAULT ON)
+  endif()
+endif()
+
+option(BUILD_OMP "Build with OpenMP support" ${BUILD_OMP_DEFAULT})
+
+if(BUILD_OMP)
+  find_package(OpenMP REQUIRED)
+  check_include_file_cxx(omp.h HAVE_OMP_H_INCLUDE)
+  if(NOT HAVE_OMP_H_INCLUDE)
+    message(FATAL_ERROR "Cannot find the 'omp.h' header file required for full OpenMP support")
+  endif()
+
+  if (((CMAKE_CXX_COMPILER_ID STREQUAL "GNU") AND (CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 9.0)) OR
+      (CMAKE_CXX_COMPILER_ID STREQUAL "PGI") OR
+      ((CMAKE_CXX_COMPILER_ID STREQUAL "Clang") AND (CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 10.0)) OR
+      ((CMAKE_CXX_COMPILER_ID STREQUAL "Intel") AND (CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 19.0)))
+    # GCC 9.x and later plus Clang 10.x and later implement strict OpenMP 4.0 semantics for consts.
+    # Intel 18.0 was tested to support both, so we switch to OpenMP 4+ from 19.x onward to be safe.
+    target_compile_definitions(lammps INTERFACE -DLAMMPS_OMP_COMPAT=4)
+  else()
+    target_compile_definitions(lammps INTERFACE -DLAMMPS_OMP_COMPAT=3)
+  endif()
+  target_link_libraries(lammps INTERFACE OpenMP::OpenMP_CXX)
+endif()
+
+################
+# integer size selection
+set(LAMMPS_SIZES "smallbig" CACHE STRING "LAMMPS integer sizes (smallsmall: all 32-bit, smallbig: 64-bit #atoms #timesteps, bigbig: also 64-bit imageint, 64-bit atom ids)")
+set(LAMMPS_SIZES_VALUES smallbig bigbig smallsmall)
+set_property(CACHE LAMMPS_SIZES PROPERTY STRINGS ${LAMMPS_SIZES_VALUES})
+validate_option(LAMMPS_SIZES LAMMPS_SIZES_VALUES)
+string(TOUPPER ${LAMMPS_SIZES} LAMMPS_SIZES)
+target_compile_definitions(lammps INTERFACE -DLAMMPS_${LAMMPS_SIZES})

cmake/Modules/LAMMPSUtils.cmake

@@ -24,6 +24,24 @@ function(validate_option name values)
     endif()
 endfunction(validate_option)
 
+# helper function for getting the most recently modified file or folder from a glob pattern
+function(get_newest_file path variable)
+  file(GLOB _dirs ${path})
+  set(_besttime 2000-01-01T00:00:00)
+  set(_bestfile "<unknown>")
+  foreach(_dir ${_dirs})
+    file(TIMESTAMP ${_dir} _newtime)
+    if(_newtime IS_NEWER_THAN _besttime)
+      set(_bestfile ${_dir})
+      set(_besttime ${_newtime})
+    endif()
+  endforeach()
+  if(_bestfile STREQUAL "<unknown>")
+    message(FATAL_ERROR "Could not find valid path at: ${path}")
+  endif()
+  set(${variable} ${_bestfile} PARENT_SCOPE)
+endfunction()
+
 function(get_lammps_version version_header variable)
     file(STRINGS ${version_header} line REGEX LAMMPS_VERSION)
     set(MONTHS x Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec)

cmake/Modules/Packages/KOKKOS.cmake

@@ -47,8 +47,8 @@ if(DOWNLOAD_KOKKOS)
   list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_CXX_EXTENSIONS=${CMAKE_CXX_EXTENSIONS}")
   list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE}")
   include(ExternalProject)
-  set(KOKKOS_URL "https://github.com/kokkos/kokkos/archive/3.6.00.tar.gz" CACHE STRING "URL for KOKKOS tarball")
-  set(KOKKOS_MD5 "b5c44ea961031795f434002cd7b31c20" CACHE STRING "MD5 checksum of KOKKOS tarball")
+  set(KOKKOS_URL "https://github.com/kokkos/kokkos/archive/3.6.01.tar.gz" CACHE STRING "URL for KOKKOS tarball")
+  set(KOKKOS_MD5 "0ec97fc0c356dd65bd2487defe81a7bf" CACHE STRING "MD5 checksum of KOKKOS tarball")
   mark_as_advanced(KOKKOS_URL)
   mark_as_advanced(KOKKOS_MD5)
   ExternalProject_Add(kokkos_build
@@ -72,7 +72,7 @@ if(DOWNLOAD_KOKKOS)
   add_dependencies(LAMMPS::KOKKOSCORE kokkos_build)
   add_dependencies(LAMMPS::KOKKOSCONTAINERS kokkos_build)
 elseif(EXTERNAL_KOKKOS)
-  find_package(Kokkos 3.6.00 REQUIRED CONFIG)
+  find_package(Kokkos 3.6.01 REQUIRED CONFIG)
   target_link_libraries(lammps PRIVATE Kokkos::kokkos)
   target_link_libraries(lmp PRIVATE Kokkos::kokkos)
 else()

cmake/Modules/Packages/MDI.cmake

@@ -8,8 +8,8 @@ option(DOWNLOAD_MDI "Download and compile the MDI library instead of using an al
 
 if(DOWNLOAD_MDI)
   message(STATUS "MDI download requested - we will build our own")
-  set(MDI_URL "https://github.com/MolSSI-MDI/MDI_Library/archive/v1.3.2.tar.gz" CACHE STRING "URL for MDI tarball")
-  set(MDI_MD5 "836f5da400d8cff0f0e4435640f9454f" CACHE STRING "MD5 checksum for MDI tarball")
+  set(MDI_URL "https://github.com/MolSSI-MDI/MDI_Library/archive/v1.4.1.tar.gz" CACHE STRING "URL for MDI tarball")
+  set(MDI_MD5 "f9505fccd4c79301a619f6452dad4ad9" CACHE STRING "MD5 checksum for MDI tarball")
   mark_as_advanced(MDI_URL)
   mark_as_advanced(MDI_MD5)
   enable_language(C)
@@ -44,7 +44,7 @@ if(DOWNLOAD_MDI)
   ExternalProject_Add(mdi_build
     URL     ${MDI_URL}
     URL_MD5 ${MDI_MD5}
-    CMAKE_ARGS ${CMAKE_REQUEST_PIC}
+    CMAKE_ARGS
     -DCMAKE_INSTALL_PREFIX=<INSTALL_DIR>
     -DCMAKE_C_COMPILER=${CMAKE_C_COMPILER}
     -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
@@ -54,6 +54,7 @@ if(DOWNLOAD_MDI)
     -Dlanguage=C
     -Dlibtype=STATIC
     -Dmpi=${MDI_USE_MPI}
+    -Dplugins=ON
     -Dpython_plugins=${MDI_USE_PYTHON_PLUGINS}
     UPDATE_COMMAND ""
     INSTALL_COMMAND ""

cmake/Modules/Packages/ML-HDNNP.cmake

@@ -44,7 +44,9 @@ if(DOWNLOAD_N2P2)
   else()
     # get path to MPI include directory
     get_target_property(N2P2_MPI_INCLUDE MPI::MPI_CXX INTERFACE_INCLUDE_DIRECTORIES)
-    set(N2P2_PROJECT_OPTIONS "-I${N2P2_MPI_INCLUDE}")
+    foreach (_INCL ${N2P2_MPI_INCLUDE})
+      set(N2P2_PROJECT_OPTIONS "${N2P2_PROJECT_OPTIONS} -I${_INCL}")
+    endforeach()
   endif()
 
   # prefer GNU make, if available. N2P2 lib seems to need it.
@@ -75,7 +77,7 @@ if(DOWNLOAD_N2P2)
     UPDATE_COMMAND ""
     CONFIGURE_COMMAND ""
     PATCH_COMMAND sed -i -e "s/\\(MPI_\\(P\\|Unp\\)ack(\\)/\\1(void *) /" src/libnnpif/LAMMPS/InterfaceLammps.cpp
-    BUILD_COMMAND ${N2P2_MAKE} -f makefile libnnpif ${N2P2_BUILD_OPTIONS}
+    BUILD_COMMAND ${N2P2_MAKE} -C <SOURCE_DIR>/src -f makefile libnnpif ${N2P2_BUILD_OPTIONS}
     BUILD_ALWAYS YES
     INSTALL_COMMAND ""
     BUILD_IN_SOURCE 1

cmake/Modules/Packages/ML-PACE.cmake

@@ -1,6 +1,6 @@
-set(PACELIB_URL "https://github.com/ICAMS/lammps-user-pace/archive/refs/tags/v.2021.10.25.fix.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.10.25.fix2.tar.gz" CACHE STRING "URL for PACE evaluator library sources")
 
-set(PACELIB_MD5 "e0572de57039d4afedefb25707b6ceae" CACHE STRING "MD5 checksum of PACE evaluator library tarball")
+set(PACELIB_MD5 "32394d799bc282bb57696c78c456e64f" CACHE STRING "MD5 checksum of PACE evaluator library tarball")
 mark_as_advanced(PACELIB_URL)
 mark_as_advanced(PACELIB_MD5)
 
@@ -13,8 +13,8 @@ execute_process(
   COMMAND ${CMAKE_COMMAND} -E tar xzf libpace.tar.gz
   WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
 )
+get_newest_file(${CMAKE_BINARY_DIR}/lammps-user-pace-* lib-pace)
 
-file(GLOB lib-pace ${CMAKE_BINARY_DIR}/lammps-user-pace-*)
 # enforce building libyaml-cpp as static library and turn off optional features
 set(YAML_BUILD_SHARED_LIBS OFF)
 set(YAML_CPP_BUILD_CONTRIB OFF)
@@ -32,5 +32,6 @@ target_include_directories(pace PUBLIC ${PACE_EVALUATOR_INCLUDE_DIR} ${YAML_CPP_
 
 
 target_link_libraries(pace PRIVATE yaml-cpp-pace)
-
-target_link_libraries(lammps PRIVATE pace)
+if(CMAKE_PROJECT_NAME STREQUAL "lammps")
+  target_link_libraries(lammps PRIVATE pace)
+endif()

cmake/Modules/Packages/ML-QUIP.cmake

@@ -43,6 +43,7 @@ if(DOWNLOAD_QUIP)
   file(WRITE ${CMAKE_BINARY_DIR}/quip.config "${temp}")
 
   message(STATUS "QUIP download via git requested - we will build our own")
+  set(CMAKE_EP_GIT_REMOTE_UPDATE_STRATEGY CHECKOUT)
   # QUIP has no releases (except for a tag marking the end of Python 2 support). We use the current "public" branch
   # The LAMMPS interface wrapper has a compatibility constant that is being checked at runtime.
   include(ExternalProject)

cmake/Modules/generate_lmpgitversion.cmake

@@ -31,5 +31,7 @@ set(temp "${temp}const char *LAMMPS_NS::LAMMPS::git_descriptor() { return \"${te
 set(temp "${temp}#endif\n\n")
 
 message(STATUS "Generating lmpgitversion.h...")
-file(WRITE "${LAMMPS_STYLE_HEADERS_DIR}/lmpgitversion.h.tmp" "${temp}" )
-execute_process(COMMAND ${CMAKE_COMMAND} -E copy_if_different "${LAMMPS_STYLE_HEADERS_DIR}/lmpgitversion.h.tmp" "${LAMMPS_STYLE_HEADERS_DIR}/lmpgitversion.h")
+
+string(REPLACE "\\ " " " LAMMPS_GIT_HEADER "${LAMMPS_STYLE_HEADERS_DIR}/lmpgitversion.h")
+file(WRITE "${LAMMPS_GIT_HEADER}.tmp" "${temp}" )
+execute_process(COMMAND ${CMAKE_COMMAND} -E copy_if_different "${LAMMPS_GIT_HEADER}.tmp" "${LAMMPS_GIT_HEADER}")

cmake/presets/all_off.cmake

@@ -3,6 +3,7 @@
 
 set(ALL_PACKAGES
   ADIOS
+  AMOEBA
   ASPHERE
   ATC
   AWPMD

cmake/presets/all_on.cmake

@@ -5,6 +5,7 @@
 
 set(ALL_PACKAGES
   ADIOS
+  AMOEBA
   ASPHERE
   ATC
   AWPMD

cmake/presets/mingw-cross.cmake

@@ -1,4 +1,5 @@
 set(WIN_PACKAGES
+  AMOEBA
   ASPHERE
   ATC
   AWPMD
@@ -46,8 +47,8 @@ set(WIN_PACKAGES
   MISC
   ML-HDNNP
   ML-IAP
-  ML-SNAP
   ML-RANN
+  ML-SNAP
   MOFFF
   MOLECULE
   MOLFILE
@@ -56,6 +57,7 @@ set(WIN_PACKAGES
   ORIENT
   PERI
   PHONON
+  PLUGIN
   POEMS
   PTM
   QEQ

cmake/presets/most.cmake

@@ -3,6 +3,7 @@
 # are removed. The resulting binary should be able to run most inputs.
 
 set(ALL_PACKAGES
+  AMOEBA
   ASPHERE
   BOCS
   BODY

cmake/presets/windows.cmake

@@ -1,4 +1,5 @@
 set(WIN_PACKAGES
+  AMOEBA
   ASPHERE
   BOCS
   BODY
@@ -43,6 +44,7 @@ set(WIN_PACKAGES
   PERI
   PHONON
   POEMS
+  PLUGIN
   PTM
   QEQ
   QTB

doc/Makefile

@@ -13,6 +13,7 @@ VENV           = $(BUILDDIR)/docenv
 ANCHORCHECK    = $(VENV)/bin/rst_anchor_check
 SPHINXCONFIG   = $(BUILDDIR)/utils/sphinx-config
 MATHJAX        = $(SPHINXCONFIG)/_static/mathjax
+MATHJAXTAG     = 3.2.2
 
 PYTHON         = $(word 3,$(shell type python3))
 DOXYGEN        = $(word 3,$(shell type doxygen))
@@ -230,12 +231,13 @@ $(VENV):
 		$(PYTHON) -m venv $(VENV); \
 		. $(VENV)/bin/activate; \
 		pip $(PIP_OPTIONS) install --upgrade pip; \
+		pip $(PIP_OPTIONS) install --upgrade wheel; \
 		pip $(PIP_OPTIONS) install -r $(BUILDDIR)/utils/requirements.txt; \
 		deactivate;\
 	)
 
 $(MATHJAX):
-	@git clone -b 3.2.0 -c advice.detachedHead=0 --depth 1 https://github.com/mathjax/MathJax.git $@
+	@git clone -b $(MATHJAXTAG) -c advice.detachedHead=0 --depth 1 https://github.com/mathjax/MathJax.git $@
 
 $(ANCHORCHECK): $(VENV)
 	@( \

doc/lammps.1

@@ -1,7 +1,7 @@
-.TH LAMMPS "1" "4 May 2022" "2022-5-4"
+.TH LAMMPS "1" "23 June 2022" "2022-6-23"
 .SH NAME
 .B LAMMPS
-\- Molecular Dynamics Simulator.  Version 24 March 2022
+\- Molecular Dynamics Simulator.  Version 23 June 2022
 
 .SH SYNOPSIS
 .B lmp

doc/src/Build_settings.rst

@@ -287,8 +287,8 @@ Output of JPG, PNG, and movie files
 
 The :doc:`dump image <dump_image>` command has options to output JPEG or
 PNG image files.  Likewise the :doc:`dump movie <dump_image>` command
-outputs movie files in MPEG format.  Using these options requires the
-following settings:
+outputs movie files in a variety of movie formats.  Using these options
+requires the following settings:
 
 .. tabs::
 
@@ -328,11 +328,12 @@ following settings:
          JPG_LIB = -ljpeg -lpng -lz       # library names
 
       As with CMake, you do not need to set ``JPG_INC`` or ``JPG_PATH``,
-      if make can find the graphics header and library files.  You must
-      specify ``JPG_LIB`` with a list of graphics libraries to include
-      in the link.  You must insure ffmpeg is in a directory where
-      LAMMPS can find it at runtime, that is a directory in your PATH
-      environment variable.
+      if make can find the graphics header and library files in their
+      default system locations.  You must specify ``JPG_LIB`` with a
+      list of graphics libraries to include in the link.  You must make
+      certain that the ffmpeg executable (or ffmpeg.exe on Windows) is
+      in a directory where LAMMPS can find it at runtime; that is
+      usually a directory list in your ``PATH`` environment variable.
 
 Using ``ffmpeg`` to output movie files requires that your machine
 supports the "popen" function in the standard runtime library.

doc/src/Commands_bond.rst

@@ -74,6 +74,7 @@ OPT.
    *
    *
    *
+   * :doc:`amoeba <angle_amoeba>`
    * :doc:`charmm (iko) <angle_charmm>`
    * :doc:`class2 (ko) <angle_class2>`
    * :doc:`class2/p6 <angle_class2>`
@@ -152,6 +153,7 @@ OPT.
    *
    *
    *
+   * :doc:`amoeba <improper_amoeba>`
    * :doc:`class2 (ko) <improper_class2>`
    * :doc:`cossq (o) <improper_cossq>`
    * :doc:`cvff (io) <improper_cvff>`

doc/src/Commands_compute.rst

@@ -138,6 +138,8 @@ KOKKOS, o = OPENMP, t = OPT.
    * :doc:`smd/vol <compute_smd_vol>`
    * :doc:`snap <compute_sna_atom>`
    * :doc:`sna/atom <compute_sna_atom>`
+   * :doc:`sna/grid <compute_sna_atom>`
+   * :doc:`sna/grid/local <compute_sna_atom>`
    * :doc:`snad/atom <compute_sna_atom>`
    * :doc:`snav/atom <compute_sna_atom>`
    * :doc:`sph/e/atom <compute_sph_e_atom>`

doc/src/Commands_fix.rst

@@ -28,6 +28,8 @@ OPT.
    * :doc:`adapt/fep <fix_adapt_fep>`
    * :doc:`addforce <fix_addforce>`
    * :doc:`addtorque <fix_addtorque>`
+   * :doc:`amoeba/bitorsion <fix_amoeba_bitorsion>`
+   * :doc:`amoeba/pitorsion <fix_amoeba_pitorsion>`
    * :doc:`append/atoms <fix_append_atoms>`
    * :doc:`atc <fix_atc>`
    * :doc:`atom/swap <fix_atom_swap>`
@@ -103,7 +105,7 @@ OPT.
    * :doc:`lb/viscous <fix_lb_viscous>`
    * :doc:`lineforce <fix_lineforce>`
    * :doc:`manifoldforce <fix_manifoldforce>`
-   * :doc:`mdi/aimd <fix_mdi_aimd>`
+   * :doc:`mdi/qm <fix_mdi_qm>`
    * :doc:`meso/move <fix_meso_move>`
    * :doc:`mol/swap <fix_mol_swap>`
    * :doc:`momentum (k) <fix_momentum>`

doc/src/Commands_pair.rst

@@ -38,6 +38,7 @@ OPT.
    * :doc:`agni (o) <pair_agni>`
    * :doc:`airebo (io) <pair_airebo>`
    * :doc:`airebo/morse (io) <pair_airebo>`
+   * :doc:`amoeba <pair_amoeba>`
    * :doc:`atm <pair_atm>`
    * :doc:`awpmd/cut <pair_awpmd>`
    * :doc:`beck (go) <pair_beck>`
@@ -124,6 +125,7 @@ OPT.
    * :doc:`hbond/dreiding/lj (o) <pair_hbond_dreiding>`
    * :doc:`hbond/dreiding/morse (o) <pair_hbond_dreiding>`
    * :doc:`hdnnp <pair_hdnnp>`
+   * :doc:`hippo <pair_amoeba>`
    * :doc:`ilp/graphene/hbn (t) <pair_ilp_graphene_hbn>`
    * :doc:`ilp/tmd (t) <pair_ilp_tmd>`
    * :doc:`kolmogorov/crespi/full <pair_kolmogorov_crespi_full>`
@@ -194,7 +196,7 @@ OPT.
    * :doc:`lubricateU/poly <pair_lubricateU>`
    * :doc:`mdpd <pair_mesodpd>`
    * :doc:`mdpd/rhosum <pair_mesodpd>`
-   * :doc:`meam <pair_meam>`
+   * :doc:`meam (k) <pair_meam>`
    * :doc:`meam/spline (o) <pair_meam_spline>`
    * :doc:`meam/sw/spline <pair_meam_sw_spline>`
    * :doc:`mesocnt <pair_mesocnt>`
@@ -269,6 +271,7 @@ OPT.
    * :doc:`spin/neel <pair_spin_neel>`
    * :doc:`srp <pair_srp>`
    * :doc:`sw (giko) <pair_sw>`
+   * :doc:`sw/angle/table <pair_sw_angle_table>`
    * :doc:`sw/mod (o) <pair_sw>`
    * :doc:`table (gko) <pair_table>`
    * :doc:`table/rx (k) <pair_table_rx>`
@@ -279,6 +282,7 @@ OPT.
    * :doc:`tersoff/table (o) <pair_tersoff>`
    * :doc:`tersoff/zbl (gko) <pair_tersoff_zbl>`
    * :doc:`thole <pair_thole>`
+   * :doc:`threebody/table <pair_threebody_table>`
    * :doc:`tip4p/cut (o) <pair_coul>`
    * :doc:`tip4p/long (o) <pair_coul>`
    * :doc:`tip4p/long/soft (o) <pair_fep_soft>`

doc/src/Developer_plugins.rst

@@ -276,10 +276,27 @@ Compilation of the plugin can be managed via both, CMake or traditional
 GNU makefiles.  Some examples that can be used as a template are in the
 ``examples/plugins`` folder.  The CMake script code has some small
 adjustments to allow building the plugins for running unit tests with
-them. Another example that converts the KIM package into a plugin can be
-found in the ``examples/kim/plugin`` folder.  No changes to the sources
-of the KIM package themselves are needed; only the plugin interface and
-loader code needs to be added.  This example only supports building with
-CMake, but is probably a more typical example. To compile you need to
-run CMake with -DLAMMPS_SOURCE_DIR=<path/to/lammps/src/folder>.  Other
+them.
+
+Another example that converts the KIM package into a plugin can be found
+in the ``examples/kim/plugin`` folder.  No changes to the sources of the
+KIM package themselves are needed; only the plugin interface and loader
+code needs to be added.  This example only supports building with CMake,
+but is probably a more typical example. To compile you need to run CMake
+with -DLAMMPS_SOURCE_DIR=<path/to/lammps/src/folder>.  Other
 configuration setting are identical to those for compiling LAMMPS.
+
+A second example for a plugin from a package is in the
+``examples/PACKAGES/pace/plugin`` folder that will create a plugin from
+the ML-PACE package.  In this case the bulk of the code is in a static
+external library that is being downloaded and compiled first and then
+combined with the pair style wrapper and the plugin loader.  This
+example also contains a NSIS script that can be used to create an
+Installer package for Windows (the mutual licensing terms of the
+external library and LAMMPS conflict when distributing binaries, so the
+ML-PACE package cannot be linked statically, but the LAMMPS headers
+required to build the plugin are also available under a less restrictive
+license).  This will automatically set the required environment variable
+and launching a (compatible) LAMMPS binary will load and register the
+plugin and the ML-PACE package can then be used as it was linked into
+LAMMPS.

doc/src/Developer_utils.rst

@@ -154,6 +154,9 @@ and parsing files or arguments.
 .. doxygenfunction:: trim_and_count_words
    :project: progguide
 
+.. doxygenfunction:: join_words
+   :project: progguide
+
 .. doxygenfunction:: split_words
    :project: progguide
 

doc/src/Errors_warnings.rst

@@ -470,6 +470,12 @@ This will most likely cause errors in kinetic fluctuations.
 *More than one compute sna/atom*
    Self-explanatory.
 
+*More than one compute sna/grid*
+   Self-explanatory.
+
+*More than one compute sna/grid/local*
+   Self-explanatory.
+
 *More than one compute snad/atom*
    Self-explanatory.
 

doc/src/Howto.rst

@@ -65,6 +65,7 @@ Force fields howto
    :maxdepth: 1
 
    Howto_bioFF
+   Howto_amoeba
    Howto_tip3p
    Howto_tip4p
    Howto_spc

doc/src/Howto_amoeba.rst

@@ -0,0 +1,324 @@
+AMOEBA and HIPPO force fields
+=============================
+
+The AMOEBA and HIPPO polarizable force fields were developed by Jay
+Ponder's group at the U Washington at St Louis.  Their implementation
+in LAMMPS was done using F90 code provided by the Ponder group from
+their `Tinker MD code <https://dasher.wustl.edu/tinker/>`_.
+
+The current implementation (July 2022) of AMOEBA in LAMMPS matches the
+version discussed in :ref:`(Ponder) <amoeba-Ponder>`, :ref:`(Ren)
+<amoeba-Ren>`, and :ref:`(Shi) <amoeba-Shi>`.  Likewise the current
+implementation of HIPPO in LAMMPS matches the version discussed in
+:ref:`(Rackers) <amoeba-Rackers>`.
+
+These force fields can be used when polarization effects are desired
+in simulations of water, organic molecules, and biomolecules including
+proteins, provided that parameterizations (Tinker PRM force field
+files) are available for the systems you are interested in.  Files in
+the LAMMPS potentials directory with a "amoeba" or "hippo" suffix can
+be used.  The Tinker distribution and website have additional force
+field files as well:
+`https://github.com/TinkerTools/tinker/tree/release/params
+<https://github.com/TinkerTools/tinker/tree/release/params>`_.
+
+Note that currently, HIPPO can only be used for water systems, but
+HIPPO files for a variety of small organic and biomolecules are in
+preparation by the Ponder group.  Those force field files will be
+included in the LAMMPS distribution when available.
+
+To use the AMOEBA or HIPPO force fields, a simulation must be 3d, and
+fully periodic or fully non-periodic, and use an orthogonal (not
+triclinic) simulation box.
+
+----------
+
+The AMOEBA and HIPPO force fields contain the following terms in their
+energy (U) computation.  Further details for AMOEBA equations are in
+:ref:`(Ponder) <amoeba-Ponder>`, further details for the HIPPO
+equations are in :ref:`(Rackers) <amoeba-Rackers>`.
+
+.. math::
+
+  U & = U_{intermolecular} + U_{intramolecular} \\
+  U_{intermolecular} & = U_{hal} + U_{repulsion} + U_{dispersion} + U_{multipole} + U_{polar} + U_{qxfer} \\
+  U_{intramolecular} & = U_{bond} + U_{angle} + U_{torsion} + U_{oop} + U_{b\theta} + U_{UB} + U_{pitorsion} + U_{bitorsion}
+
+For intermolecular terms, the AMOEBA force field includes only the
+:math:`U_{hal}`, :math:`U_{multipole}`, :math:`U_{polar}` terms.  The
+HIPPO force field includes all but the :math:`U_{hal}` term.  In
+LAMMPS, these are all computed by the :doc:`pair_style amoeba or hippo
+<pair_style>` command.  Note that the :math:`U_{multipole}` and
+:math:`U_{polar}` terms in this formula are not the same for the
+AMOEBA and HIPPO force fields.
+
+For intramolecular terms, the :math:`U_{bond}`, :math:`U_{angle}`,
+:math:`U_{torsion}`, :math:`U_{oop}` terms are computed by the
+:doc:`bond_style class2 <bond_class2>` :doc:`angle_style amoeba
+<angle_amoeba>`, :doc:`dihedral_style fourier <dihedral_fourier>`, and
+:doc:`improper_style amoeba <improper_amoeba>` commands respectively.
+The :doc:`angle_style amoeba <angle_amoeba>` command includes the
+:math:`U_{b\theta}` bond-angle cross term, and the :math:`U_{UB}` term
+for a Urey-Bradley bond contribution between the I,K atoms in the IJK
+angle.
+
+The :math:`U_{pitorsion}` term is computed by the :doc:`fix
+amoeba/pitorsion <fix_amoeba_pitorsion>` command.  It computes 6-body
+interaction between a pair of bonded atoms which each have 2
+additional bond partners.
+
+The :math:`U_{bitorsion}` term is computed by the :doc:`fix
+amoeba/bitorsion <fix_amoeba_bitorsion>` command.  It computes 5-body
+interaction between two 4-body torsions (dihedrals) which overlap,
+having 3 atoms in common.
+
+These command doc pages have additional details on the terms they
+compute:
+
+* :doc:`pair_style amoeba or hippo <pair_amoeba>`
+* :doc:`bond_style class2 <bond_class2>`
+* :doc:`angle_style amoeba <angle_amoeba>`
+* :doc:`dihedral_style fourier <dihedral_fourier>`
+* :doc:`improper_style amoeba <improper_amoeba>`
+* :doc:`fix amoeba/pitorsion <fix_amoeba_pitorsion>`
+* :doc:`fix amoeba/bitorsion <fix_amoeba_bitorsion>`
+
+----------
+
+To use the AMOEBA or HIPPO force fields in LAMMPS, use commands like
+the following appropriately in your input script.  The only change
+needed for AMOEBA vs HIPPO simulation is for the :doc:`pair_style
+<pair_style>` and :doc:`pair_coeff <pair_coeff>` commands, as shown
+below.  See examples/amoeba for example input scripts for both AMOEBA
+and HIPPO.
+
+.. code-block:: LAMMPS
+
+   units              real                           # required
+   atom_style         amoeba
+   bond_style         class2                         # CLASS2 package
+   angle_style        amoeba
+   dihedral_style     fourier                        # EXTRA-MOLECULE package
+   improper_style     amoeba
+                                                     # required per-atom data
+   fix                amtype all property/atom i_amtype ghost yes
+   fix                extra all property/atom &
+                      i_amgroup i_ired i_xaxis i_yaxis i_zaxis d_pval ghost yes
+   fix                polaxe all property/atom i_polaxe
+
+   fix                pit all amoeba/pitorsion       # PiTorsion terms in FF
+   fix_modify         pit energy yes
+                                                     # Bitorsion terms in FF
+   fix                bit all amoeba/bitorsion bitorsion.ubiquitin.data
+   fix_modify         bit energy yes
+
+   read_data          data.ubiquitin fix amtype NULL "Tinker Types" &
+                      fix pit "pitorsion types" "PiTorsion Coeffs" &
+                      fix pit pitorsions PiTorsions &
+                      fix bit bitorsions BiTorsions
+
+   pair_style         amoeba                          # AMOEBA FF
+   pair_coeff         * * amoeba_ubiquitin.prm amoeba_ubiquitin.key
+
+   pair_style         hippo                           # HIPPO FF
+   pair_coeff         * * hippo_water.prm hippo_water.key
+
+   special_bonds      lj/coul 0.5 0.5 0.5 one/five yes     # 1-5 neighbors
+
+The data file read by the :doc:`read_data <read_data>` command should
+be created by the tools/tinker/tinker2lmp.py conversion program
+described below.  It will create a section in the data file with the
+header "Tinker Types".  A :doc:`fix property/atom <fix_property_atom>`
+command for the data must be specified before the read_data command.
+In the example above the fix ID is *amtype*.
+
+Similarly, if the system you are simulating defines AMOEBA/HIPPO
+pitorsion or bitorsion interactions, there will be entries in the data
+file for those interactions.  They require a :doc:`fix
+amoeba/pitortion <fix_amoeba_pitorsion>` and :doc:`fix
+amoeba/bitorsion <fix_amoeba_bitorsion>` command be defined.  In the
+example above, the IDs for these two fixes are *pit* and *bit*.
+
+Of course, if the system being modeled does not have one or more of
+the following -- bond, angle, dihedral, improper, pitorsion,
+bitorsion interactions -- then the corresponding style and fix
+commands above do not need to be used.  See the example scripts in
+examples/amoeba for water systems as examples; they are simpler than
+what is listed above.
+
+The two :doc:`fix property/atom <fix_property_atom>` commands with IDs
+(in the example above) *extra* and *polaxe* are also needed to define
+internal per-atom quantities used by the AMOEBA and HIPPO force
+fields.
+
+The :doc:`pair_coeff <pair_coeff>` command used for either the AMOEBA
+or HIPPO force field takes two arguments for Tinker force field files,
+namely a PRM and KEY file.  The keyfile can be specified as NULL and
+default values for a various settings will be used.  Note that these 2
+files are meant to allow use of native Tinker files as-is.  However
+LAMMPS does not support all the options which can be included
+in a Tinker PRM or KEY file.  See specifics below.
+
+A :doc:`special_bonds <special_bonds>` command with the *one/five*
+option is required, since the AMOEBA/HIPPO force fields define
+weighting factors for not only 1-2, 1-3, 1-4 interactions, but also
+1-5 interactions.  This command will trigger a per-atom list of 1-5
+neighbors to be generated.  The AMOEBA and HIPPO force fields define
+their own custom weighting factors for all the 1-2, 1-3, 1-4, 1-5
+terms which in the Tinker PRM and KEY files; they can be different for
+different terms in the force field.
+
+In addition to the list above, these command doc pages have additional
+details:
+
+* :doc:`atom_style amoeba <atom_style>`
+* :doc:`fix property/atom <fix_property_atom>`
+* :doc:`special_bonds <special_bonds>`
+
+----------
+
+Tinker PRM and KEY files
+
+A Tinker PRM file is composed of sections, each of which has multiple
+lines.  This is the list of PRM sections LAMMPS knows how to parse and
+use.  Any other sections are skipped:
+
+* Angle Bending Parameters
+* Atom Type Definitions
+* Atomic Multipole Parameters
+* Bond Stretching Parameters
+* Charge Penetration Parameters
+* Charge Transfer Parameters
+* Dipole Polarizability Parameters
+* Dispersion Parameters
+* Force Field Definition
+* Literature References
+* Out-of-Plane Bend Parameters
+* Pauli Repulsion Parameters
+* Pi-Torsion Parameters
+* Stretch-Bend Parameters
+* Torsion-Torsion Parameters
+* Torsional Parameters
+* Urey-Bradley Parameters
+* Van der Waals Pair Parameters
+* Van der Waals Parameters
+
+A Tinker KEY file is composed of lines, each of which has a keyword
+followed by zero or more parameters.  This is the list of keywords
+LAMMPS knows how to parse and use in the same manner Tinker does.  Any
+other keywords are skipped.  The value in parenthesis is the default
+value for the keyword if it is not specified, or if the keyfile in the
+:doc:`pair_coeff <pair_coeff>` command is specified as NULL:
+
+* a-axis (0.0)
+* b-axis (0.0)
+* c-axis (0.0)
+* ctrn-cutoff (6.0)
+* ctrn-taper (0.9 * ctrn-cutoff)
+* cutoff
+* delta-halgren (0.07)
+* dewald (no long-range dispersion unless specified)
+* dewald-alpha (0.4)
+* dewald-cutoff (7.0)
+* dispersion-cutoff (9.0)
+* dispersion-taper (9.0 * dispersion-cutoff)
+* dpme-grid
+* dpme-order (4)
+* ewald (no long-range electrostatics unless specified)
+* ewald-alpha (0.4)
+* ewald-cutoff (7.0)
+* gamma-halgren (0.12)
+* mpole-cutoff (9.0)
+* mpole-taper (0.65 * mpole-cutoff)
+* pcg-guess (enabled by default)
+* pcg-noguess (disable pcg-guess if specified)
+* pcg-noprecond (disable pcg-precond if specified)
+* pcg-peek (1.0)
+* pcg-precond (enabled by default)
+* pewald-alpha (0.4)
+* pme-grid
+* pme-order (5)
+* polar-eps (1.0e-6)
+* polar-iter (100)
+* polar-predict (no prediction operation unless specified)
+* ppme-order (5)
+* repulsion-cutoff (6.0)
+* repulsion-taper (0.9 * repulsion-cutoff)
+* taper
+* usolve-cutoff (4.5)
+* usolve-diag (2.0)
+* vdw-cutoff (9.0)
+* vdw-taper (0.9 * vdw-cutoff)
+
+----------
+
+Tinker2lmp.py tool
+
+This conversion tool is found in the tools/tinker directory.
+As shown in examples/amoeba/README, these commands produce
+the data files found in examples/amoeba, and also illustrate
+all the options available to use with the tinker2lmp.py script:
+
+.. code-block:: bash
+
+   % python tinker2lmp.py -xyz water_dimer.xyz -amoeba amoeba_water.prm -data data.water_dimer.amoeba                # AMOEBA non-periodic system
+   % python tinker2lmp.py -xyz water_dimer.xyz -hippo hippo_water.prm -data data.water_dimer.hippo                   # HIPPO non-periodic system
+   % python tinker2lmp.py -xyz water_box.xyz -amoeba amoeba_water.prm -data data.water_box.amoeba -pbc 18.643 18.643 18.643    # AMOEBA periodic system
+   % python tinker2lmp.py -xyz water_box.xyz -hippo hippo_water.prm -data data.water_box.hippo -pbc 18.643 18.643 18.643       # HIPPO periodic system
+   % python tinker2lmp.py -xyz ubiquitin.xyz -amoeba amoeba_ubiquitin.prm -data data.ubiquitin.new -pbc 54.99 41.91 41.91 -bitorsion bitorsion.ubiquitin.data.new   # system with bitorsions
+
+Switches and their arguments may be specified in any order.
+
+The -xyz switch is required and specifies an input XYZ file as an
+argument.  The format of this file is an extended XYZ format defined
+and used by Tinker for its input.  Example \*.xyz files are in the
+examples/amoeba directory.  The file lists the atoms in the system.
+Each atom has the following information: Tinker species name (ignored
+by LAMMPS), xyz coordinates, Tinker numeric type, and a list of atom
+IDs the atom is bonded to.
+
+Here is more information about the extended XYZ format defined and
+used by Tinker, and links to programs that convert standard PDB files
+to the extended XYZ format:
+
+* `http://openbabel.org/docs/current/FileFormats/Tinker_XYZ_format.html <http://openbabel.org/docs/current/FileFormats/Tinker_XYZ_format.html>`_
+* `https://github.com/emleddin/pdbxyz-xyzpdb <https://github.com/emleddin/pdbxyz-xyzpdb>`_
+* `https://github.com/TinkerTools/tinker/blob/release/source/pdbxyz.f <https://github.com/TinkerTools/tinker/blob/release/source/pdbxyz.f>`_
+
+The -amoeba or -hippo switch is required.  It specifies an input
+AMOEBA or HIPPO PRM force field file as an argument.  This should be
+the same file used by the :doc:`pair_style <pair_style>` command in
+the input script.
+
+The -data switch is required.  It specifies an output file name for
+the LAMMPS data file that will be produced.
+
+For periodic systems, the -pbc switch is required.  It specifies the
+periodic box size for each dimension (x,y,z).  For a Tinker simulation
+these are specified in the KEY file.
+
+The -bitorsion switch is only needed if the system contains Tinker
+bitorsion interactions.  The data for each type of bitorsion
+interaction will be written to the specified file, and read by the
+:doc:`fix amoeba/bitorsion <fix_amoeba_bitorsion>` command.  The data
+includes 2d arrays of values to which splines are fit, and thus is not
+compatible with the LAMMPS data file format.
+
+----------
+
+.. _howto-Ponder:
+
+**(Ponder)** Ponder, Wu, Ren, Pande, Chodera, Schnieders, Haque,  Mobley, Lambrecht, DiStasio Jr, M. Head-Gordon, Clark,  Johnson, T. Head-Gordon, J Phys Chem B, 114, 2549-2564 (2010).
+
+.. _howto-Rackers:
+
+**(Rackers)** Rackers, Silva, Wang, Ponder, J Chem Theory Comput, 17, 7056-7084 (2021).
+
+.. _howto-Ren:
+
+**(Ren)** Ren and Ponder, J Phys Chem B, 107, 5933 (2003).
+
+.. _howto-Shi:
+
+**(Shi)** Shi, Xia, Zhang, Best, Wu, Ponder, Ren, J Chem Theory Comp, 9, 4046, 2013.
+

doc/src/Howto_body.rst

@@ -239,7 +239,7 @@ is consistent with the 6 moments of inertia: ixx iyy izz ixy ixz iyz =
 
 .. parsed-literal::
 
-   3 1 27
+   3 1 19
    4
    1 1 4 0 0 0
    -0.7071 -0.7071 0

doc/src/Howto_mdi.rst

@@ -5,9 +5,9 @@ Client/server coupling of two (or more) codes is where one code is the
 "client" and sends request messages (data) to one (or more) "server"
 code(s).  A server responds to each request with a reply message
 (data).  This enables two (or more) codes to work in tandem to perform
-a simulation.  LAMMPS can act as either a client or server code; it
-does this by using the `MolSSI Driver Interface (MDI) library
-<https://molssi-mdi.github.io/MDI_Library/html/index.html>`_,
+a simulation.  In this context, LAMMPS can act as either a client or
+server code.  It does this by using the `MolSSI Driver Interface (MDI)
+library <https://molssi-mdi.github.io/MDI_Library/html/index.html>`_,
 developed by the `Molecular Sciences Software Institute (MolSSI)
 <https://molssi.org>`_, which is supported by the :ref:`MDI <PKG-MDI>`
 package.
@@ -63,22 +63,39 @@ The package also provides a :doc:`mdi plugin <mdi>` command which
 enables LAMMPS to operate as an MDI driver and load an MDI engine as a
 plugin library.
 
-The package also has a `fix mdi/aimd <fix_mdi_aimd>` command in which
-LAMMPS operates as an MDI driver to perform *ab initio* MD simulations
-in conjunction with a quantum mechanics code.  Its post_force() method
-illustrates how a driver issues MDI commands to another code.  This
-command can be used to couple to an MDI engine which is either a
-stand-alone code or a plugin library.
+The package also has a `fix mdi/qm <fix_mdi_qm>` command in which
+LAMMPS operates as an MDI driver in conjunction with a quantum
+mechanics code as an MDI engine.  The post_force() method of the
+fix_mdi_qm.cpp file shows how a driver issues MDI commands to another
+code.  This command can be used to couple to an MDI engine which is
+either a stand-alone code or a plugin library.
+
+As explained on the `fix mdi/qm <fix_mdi_qm>` command doc page, it can
+be used to perform *ab initio* MD simulations or energy minimizations,
+or to evaluate the quantum energy and forces for a series of
+independent systems.  The examples/mdi directory has example input
+scripts for all of these use cases.
 
 ----------
 
 The examples/mdi directory contains Python scripts and LAMMPS input
 script which use LAMMPS as either an MDI driver or engine or both.
-Three example use cases are provided:
+Currently, 5 example use cases are provided:
 
-* Run ab initio MD (AIMD) using 2 instances of LAMMPS, one as driver
-  and one as an engine.  As an engine, LAMMPS is a surrogate for a
-  quantum code.
+* Run ab initio MD (AIMD) using 2 instances of LAMMPS.  As a driver
+  LAMMPS performs the timestepping in either NVE or NPT mode.  As an
+  engine, LAMMPS computes forces and is a surrogate for a quantum
+  code.
+
+* As a driver, LAMMPS runs an MD simulation.  Every N steps it passes
+  the current snapshot to an MDI engine to evaluate the energy,
+  virial, and peratom forces.  As the engine LAMMPS is a surrogate for
+  a quantum code.
+
+* As a driver, LAMMPS loops over a series of data files and passes the
+  configuration to an MDI engine to evaluate the energy, virial, and
+  peratom forces.  As the engine LAMMPS is a surrogate for a quantum
+  code.
 
 * A Python script driver invokes a sequence of unrelated LAMMPS
   calculations.  Calculations can be single-point energy/force
@@ -91,20 +108,22 @@ Three example use cases are provided:
 
 Note that in any of these example where LAMMPS is used as an engine,
 an actual QM code (which supports MDI) could be used in its place,
-without modifying other code or scripts, except to specify the name of
-the QM code.
+without modifying the input scripts or launch commands, except to
+specify the name of the QM code.
 
-The examples/mdi/README file explains how to launch both driver and
+The examples/mdi/Run.sh file illustrates how to launch both driver and
 engine codes so that they communicate using the MDI library via either
-MPI or sockets.
+MPI or sockets.  Or using the engine as a stand-alone code or plugin
+library.
 
 -------------
 
-Currently there are two quantum DFT codes which have direct MDI
-support, `Quantum ESPRESSO (QE) <https://www.quantum-espresso.org/>`_
-and `INQ <https://qsg.llnl.gov/node/101.html>`_.  There are also
-several QM codes which have indirect support through QCEngine or i-PI.
-The former means they require a wrapper program (QCEngine) with MDI
+Currently there are at least two quantum DFT codes which have direct
+MDI support, `Quantum ESPRESSO (QE)
+<https://www.quantum-espresso.org/>`_ and `INQ
+<https://qsg.llnl.gov/node/101.html>`_.  There are also several QM
+codes which have indirect support through QCEngine or i-PI.  The
+former means they require a wrapper program (QCEngine) with MDI
 support which writes/read files to pass data to the quantum code
 itself.  The list of QCEngine-supported and i-PI-supported quantum
 codes is on the `MDI webpage

doc/src/Howto_structured_data.rst

@@ -184,7 +184,7 @@ frame.
 
 .. code-block:: python
 
-   import re, yaml
+   import yaml
    import pandas as pd
 
    try:
@@ -193,7 +193,7 @@ frame.
        from yaml import SafeLoader as Loader
 
    with open("ave.yaml") as f:
-       ave = yaml.load(docs, Loader=Loader)
+       ave = yaml.load(f, Loader=Loader)
 
    keys = ave['keywords']
    df = {}

doc/src/Howto_viscosity.rst

@@ -68,7 +68,8 @@ liquid Ar via the GK formalism:
    # Sample LAMMPS input script for viscosity of liquid Ar
 
    units       real
-   variable    T equal 86.4956
+   variable    T equal 200.0       # run temperature
+   variable    Tinit equal 250.0   # equilibration temperature
    variable    V equal vol
    variable    dt equal 4.0
    variable    p equal 400     # correlation length
@@ -99,12 +100,14 @@ liquid Ar via the GK formalism:
 
    # equilibration and thermalization
 
-   velocity     all create $T 102486 mom yes rot yes dist gaussian
-   fix          NVT all nvt temp $T $T 10 drag 0.2
+   velocity     all create ${Tinit} 102486 mom yes rot yes dist gaussian
+   fix          NVT all nvt temp ${Tinit} ${Tinit} 10 drag 0.2
    run          8000
 
    # viscosity calculation, switch to NVE if desired
 
+   velocity     all create $T 102486 mom yes rot yes dist gaussian
+   fix          NVT all nvt temp $T $T 10 drag 0.2
    #unfix       NVT
    #fix         NVE all nve
 
@@ -122,7 +125,7 @@ liquid Ar via the GK formalism:
    run          100000
    variable     v equal (v_v11+v_v22+v_v33)/3.0
    variable     ndens equal count(all)/vol
-   print        "average viscosity: $v [Pa.s] @ $T K, ${ndens} /A^3"
+   print        "average viscosity: $v [Pa.s] @ $T K, ${ndens} atoms/A^3"
 
 The fifth method is related to the above Green-Kubo method,
 but uses the Einstein formulation, analogous to the Einstein
@@ -131,9 +134,9 @@ time-integrated momentum fluxes play the role of Cartesian
 coordinates, whose mean-square displacement increases linearly
 with time at sufficiently long times.
 
-The sixth is periodic perturbation method. It is also a non-equilibrium MD method.
-However, instead of measure the momentum flux in response of applied velocity gradient,
-it measures the velocity profile in response of applied stress.
+The sixth is the periodic perturbation method, which is also a non-equilibrium MD method.
+However, instead of measuring the momentum flux in response to an applied velocity gradient,
+it measures the velocity profile in response to applied stress.
 A cosine-shaped periodic acceleration is added to the system via the
 :doc:`fix accelerate/cos <fix_accelerate_cos>` command,
 and the :doc:`compute viscosity/cos<compute_viscosity_cos>` command is used to monitor the

doc/src/Intro_citing.rst

@@ -30,8 +30,8 @@ initial versions of LAMMPS is:
   `S. Plimpton, Fast Parallel Algorithms for Short-Range Molecular Dynamics, J Comp Phys, 117, 1-19 (1995). <http://www.sandia.gov/~sjplimp/papers/jcompphys95.pdf>`_
 
 
-DOI for the LAMMPS code
-^^^^^^^^^^^^^^^^^^^^^^^
+DOI for the LAMMPS source code
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 LAMMPS developers use the `Zenodo service at CERN <https://zenodo.org/>`_
 to create digital object identifies (DOI) for stable releases of the

doc/src/Packages_details.rst

@@ -27,6 +27,7 @@ page gives those details.
    :columns: 6
 
    * :ref:`ADIOS <PKG-ADIOS>`
+   * :ref:`AMOEBA <PKG-AMOEBA>`
    * :ref:`ASPHERE <PKG-ASPHERE>`
    * :ref:`ATC <PKG-ATC>`
    * :ref:`AWPMD <PKG-AWPMD>`
@@ -149,6 +150,24 @@ This package has :ref:`specific installation instructions <adios>` on the :doc:`
 
 ----------
 
+.. _PKG-AMOEBA:
+
+AMOEBA package
+---------------
+
+**Contents:**
+
+TODO
+
+**Supporting info:**
+
+* src/AMOEBA: filenames -> commands
+* :doc:`AMOEBA and HIPPO howto <Howto_amoeba>`
+* examples/amoeba
+* TODO
+
+----------
+
 .. _PKG-ASPHERE:
 
 ASPHERE package
@@ -657,7 +676,7 @@ advection-diffusion-reaction systems. The equations of motion of these
 DPD extensions are integrated through a modified velocity-Verlet (MVV)
 algorithm.
 
-**Author:** Zhen Li (Division of Applied Mathematics, Brown University)
+**Author:** Zhen Li (Department of Mechanical Engineering, Clemson University)
 
 **Supporting info:**
 
@@ -1479,7 +1498,7 @@ the :doc:`Build extras <Build_extras>` page.
 * lib/mdi/README
 * :doc:`Howto MDI <Howto_mdi>`
 * :doc:`mdi <mdi>`
-* :doc:`fix mdi/aimd <fix_mdi_aimd>`
+* :doc:`fix mdi/qm <fix_mdi_qm>`
 * examples/PACKAGES/mdi
 
 ----------
@@ -1801,6 +1820,8 @@ computes which analyze attributes of the potential.
 * src/ML-SNAP: filenames -> commands
 * :doc:`pair_style snap <pair_snap>`
 * :doc:`compute sna/atom <compute_sna_atom>`
+* :doc:`compute sna/grid <compute_sna_atom>`
+* :doc:`compute sna/grid/local <compute_sna_atom>`
 * :doc:`compute snad/atom <compute_sna_atom>`
 * :doc:`compute snav/atom <compute_sna_atom>`
 * examples/snap

doc/src/Packages_list.rst

@@ -33,6 +33,11 @@ whether an extra library is needed to build and use the package:
      - :doc:`dump adios <dump_adios>`
      - PACKAGES/adios
      - ext
+   * - :ref:`AMOEBA <PKG-AMOEBA>`
+     - AMOEBA and HIPPO force fields
+     - :doc:`AMOEBA and HIPPO howto <Howto_amoeba>`
+     - amoeba
+     - no
    * - :ref:`ASPHERE <PKG-ASPHERE>`
      - aspherical particle models
      - :doc:`Howto spherical <Howto_spherical>`

doc/src/Speed_measure.rst

@@ -42,5 +42,4 @@ inaccurate relative timing data, because processors have to wait when
 communication occurs for other processors to catch up.  Thus the
 reported times for "Communication" or "Other" may be higher than they
 really are, due to load-imbalance.  If this is an issue, you can
-uncomment the MPI_Barrier() lines in src/timer.cpp, and re-compile
-LAMMPS, to obtain synchronized timings.
+use the :doc:`timer sync <timer>` command to obtain synchronized timings.

doc/src/Tools.rst

@@ -95,7 +95,7 @@ Miscellaneous tools
    * :ref:`LAMMPS shell <lammps_shell>`
    * :ref:`LAMMPS magic patterns for file(1) <magic>`
    * :ref:`Offline build tool <offline>`
-   * :ref:`singularity <singularity_tool>`
+   * :ref:`singularity/apptainer <singularity_tool>`
    * :ref:`SWIG interface <swig>`
    * :ref:`vim <vim>`
 
@@ -1007,14 +1007,15 @@ Ivanov, at University of Iceland (ali5 at hi.is).
 
 .. _singularity_tool:
 
-singularity tool
-----------------------------------------
+singularity/apptainer tool
+--------------------------
 
-The singularity sub-directory contains container definitions files
-that can be used to build container images for building and testing
-LAMMPS on specific OS variants using the `Singularity <https://sylabs.io>`_
-container software. Contributions for additional variants are welcome.
-For more details please see the README.md file in that folder.
+The singularity sub-directory contains container definitions files that
+can be used to build container images for building and testing LAMMPS on
+specific OS variants using the `Apptainer <https://apptainer.org>`_ or
+`Singularity <https://sylabs.io>`_ container software. Contributions for
+additional variants are welcome.  For more details please see the
+README.md file in that folder.
 
 ----------
 

doc/src/angle_amoeba.rst

@@ -0,0 +1,138 @@
+.. index:: angle_style amoeba
+
+angle_style amoeba command
+==========================
+
+
+Syntax
+""""""
+
+.. code-block:: LAMMPS
+
+   angle_style amoeba
+
+Examples
+""""""""
+
+.. code-block:: LAMMPS
+
+   angle_style amoeba
+   angle_coeff * 75.0 -25.0 1.0 0.3 0.02 0.003
+   angle_coeff * ba 3.6551 24.895 1.0119 1.5228
+   angle_coeff * ub -7.6 1.5537
+
+Description
+"""""""""""
+
+The *amoeba* angle style uses the potential
+
+.. math::
+
+   E & = E_a + E_{ba} + E_{ub} \\
+   E_a & = K_2\left(\theta - \theta_0\right)^2 + K_3\left(\theta - \theta_0\right)^3 + K_4\left(\theta - \theta_0\right)^4 + K_5\left(\theta - \theta_0\right)^5 + K_6\left(\theta - \theta_0\right)^6 \\
+   E_{ba} & = N_1 (r_{ij} - r_1) (\theta - \theta_0) + N_2(r_{jk} - r_2)(\theta - \theta_0) \\
+   E_{UB} & = K_{ub} (r_{ik} - r_{ub})^2
+
+where :math:`E_a` is the angle term, :math:`E_{ba}` is a bond-angle
+term, :math:`E_{UB}` is a Urey-Bradley bond term, :math:`\theta_0` is
+the equilibrium angle, :math:`r_1` and :math:`r_2` are the equilibrium
+bond lengths, and :math:`r_{ub}` is the equilibrium Urey-Bradley bond
+length.
+
+These formulas match how the Tinker MD code performs its angle
+calculations for the AMOEBA and HIPPO force fields.  See the
+:doc:`Howto amoeba <Howto_amoeba>` page for more information about
+the implementation of AMOEBA and HIPPO in LAMMPS.
+
+Note that the :math:`E_a` and :math:`E_{ba}` formulas are identical to
+those used for the :doc:`angle_style class2/p6 <angle_class2>`
+command, however there is no bond-bond cross term formula for
+:math:`E_{bb}`.  Additionally, there is a :math:`E_{UB}` term for a
+Urey-Bradley bond.  It is effectively a harmonic bond between the I
+and K atoms of angle IJK, even though that bond is not enumerated in
+the "Bonds" section of the data file.
+
+There are also two ways that Tinker computes the angle :math:`\theta`
+in the :math:`E_a` formula.  The first is the standard way of treating
+IJK as an "in-plane" angle.  The second is an "out-of-plane" method
+which Tinker may use if the center atom J in the angle is bonded to
+one additional atom in addition to I and K.  In this case, all 4 atoms
+are used to compute the :math:`E_a` formula, resulting in forces on
+all 4 atoms.  In the Tinker PRM file, these 2 options are denoted by
+*angle* versus *anglep* entries in the "Angle Bending Parameters"
+section of the PRM force field file.  The *pflag* coefficient
+described below selects between the 2 options.
+
+----------
+
+
+Coefficients for the :math:`E_a`, :math:`E_{bb}`, and :math:`E_{ub}`
+formulas must be defined for each angle type via the :doc:`angle_coeff
+<angle_coeff>` command as in the example above, or in the data file or
+restart files read by the :doc:`read_data <read_data>` or
+:doc:`read_restart <read_restart>` commands.
+
+These are the 8 coefficients for the :math:`E_a` formula:
+
+* pflag = 0 or 1
+* ubflag = 0 or 1
+* :math:`\theta_0` (degrees)
+* :math:`K_2` (energy)
+* :math:`K_3` (energy)
+* :math:`K_4` (energy)
+* :math:`K_5` (energy)
+* :math:`K_6` (energy)
+
+A pflag value of 0 vs 1 selects between the "in-plane" and
+"out-of-plane" options described above.  Ubflag is 1 if there is a
+Urey-Bradley term associated with this angle type, else it is 0.
+:math:`\theta_0` is specified in degrees, but LAMMPS converts it to
+radians internally; hence the various :math:`K` values are effectively
+energy per radian\^2 or radian\^3 or radian\^4 or radian\^5 or
+radian\^6.
+
+For the :math:`E_{ba}` formula, each line in a :doc:`angle_coeff
+<angle_coeff>` command in the input script lists 5 coefficients, the
+first of which is "ba" to indicate they are BondAngle coefficients.
+In a data file, these coefficients should be listed under a "BondAngle
+Coeffs" heading and you must leave out the "ba", i.e. only list 4
+coefficients after the angle type.
+
+* ba
+* :math:`N_1` (energy/distance\^2)
+* :math:`N_2` (energy/distance\^2)
+* :math:`r_1` (distance)
+* :math:`r_2` (distance)
+
+The :math:`\theta_0` value in the :math:`E_{ba}` formula is not specified,
+since it is the same value from the :math:`E_a` formula.
+
+For the :math:`E_{ub}` formula, each line in a :doc:`angle_coeff
+<angle_coeff>` command in the input script lists 3 coefficients, the
+first of which is "ub" to indicate they are UreyBradley coefficients.
+In a data file, these coefficients should be listed under a
+"UreyBradley Coeffs" heading and you must leave out the "ub",
+i.e. only list 2 coefficients after the angle type.
+
+* ub
+* :math:`K_{ub}` (energy/distance\^2)
+* :math:`r_{ub}` (distance)
+
+----------
+
+Restrictions
+""""""""""""
+
+This angle style can only be used if LAMMPS was built with the AMOEBA
+package.  See the :doc:`Build package <Build_package>` doc page for
+more info.
+
+Related commands
+""""""""""""""""
+
+:doc:`angle_coeff <angle_coeff>`
+
+Default
+"""""""
+
+none

doc/src/angle_class2.rst

@@ -24,7 +24,7 @@ Examples
 .. code-block:: LAMMPS
 
    angle_style class2
-   angle_coeff * 75.0
+   angle_coeff * 75.0 25.0 0.3 0.002
    angle_coeff 1 bb 10.5872 1.0119 1.5228
    angle_coeff * ba 3.6551 24.895 1.0119 1.5228
 

doc/src/angle_style.rst

@@ -73,6 +73,7 @@ of (g,i,k,o,t) to indicate which accelerated styles exist.
 * :doc:`zero <angle_zero>` - topology but no interactions
 * :doc:`hybrid <angle_hybrid>` - define multiple styles of angle interactions
 
+* :doc:`amoeba <angle_amoeba>` - AMOEBA angle
 * :doc:`charmm <angle_charmm>` - CHARMM angle
 * :doc:`class2 <angle_class2>` - COMPASS (class 2) angle
 * :doc:`class2/p6 <angle_class2>` - COMPASS (class 2) angle expanded to 6th order

doc/src/atom_style.rst

@@ -10,7 +10,7 @@ Syntax
 
    atom_style style args
 
-* style = *angle* or *atomic* or *body* or *bond* or *charge* or *dipole* or  *dpd* or *edpd* or *electron* or *ellipsoid* or *full* or *line* or *mdpd* or *molecular* or *oxdna* or *peri* or *smd* or *sph* or *sphere* or *bpm/sphere* or *spin* or *tdpd* or *tri* or *template* or *hybrid*
+* style = *amoeba* or *angle* or *atomic* or *body* or *bond* or *charge* or *dipole* or *dpd* or *edpd* or *electron* or *ellipsoid* or *full* or *line* or *mdpd* or *molecular* or *oxdna* or *peri* or *smd* or *sph* or *sphere* or or *bpm/sphere* or *spin* or *tdpd* or *tri* or *template* or *hybrid*
 
   .. parsed-literal::
 
@@ -78,6 +78,8 @@ coordinates, velocities, atom IDs and types.  See the
 :doc:`set <set>` commands for info on how to set these various
 quantities.
 
++--------------+-----------------------------------------------------+--------------------------------------+
+| *amoeba*     | molecular + charge + 1/5 neighbors                  | AMOEBA/HIPPO polarized force fields  |
 +--------------+-----------------------------------------------------+--------------------------------------+
 | *angle*      | bonds and angles                                    | bead-spring polymers with stiffness  |
 +--------------+-----------------------------------------------------+--------------------------------------+
@@ -137,11 +139,13 @@ quantities.
 .. note::
 
    It is possible to add some attributes, such as a molecule ID, to
-   atom styles that do not have them via the :doc:`fix property/atom <fix_property_atom>` command.  This command also
-   allows new custom attributes consisting of extra integer or
-   floating-point values to be added to atoms.  See the :doc:`fix property/atom <fix_property_atom>` page for examples of cases
-   where this is useful and details on how to initialize, access, and
-   output the custom values.
+   atom styles that do not have them via the :doc:`fix property/atom
+   <fix_property_atom>` command.  This command also allows new custom
+   attributes consisting of extra integer or floating-point values to
+   be added to atoms.  See the :doc:`fix property/atom
+   <fix_property_atom>` page for examples of cases where this is
+   useful and details on how to initialize, access, and output the
+   custom values.
 
 All of the above styles define point particles, except the *sphere*,
 *bpm/sphere*, *ellipsoid*, *electron*, *peri*, *wavepacket*, *line*,
@@ -154,19 +158,20 @@ per-type basis, using the :doc:`mass <mass>` command, The finite-size
 particle styles assign mass to individual particles on a per-particle
 basis.
 
-For the *sphere* and *bpm/sphere* styles, the particles are spheres and each stores a
-per-particle diameter and mass.  If the diameter > 0.0, the particle
-is a finite-size sphere.  If the diameter = 0.0, it is a point
-particle.  Note that by use of the *disc* keyword with the :doc:`fix
-nve/sphere <fix_nve_sphere>`, :doc:`fix nvt/sphere <fix_nvt_sphere>`,
-:doc:`fix nph/sphere <fix_nph_sphere>`, :doc:`fix npt/sphere
-<fix_npt_sphere>` commands for the *sphere* style, spheres can be effectively treated as 2d
-discs for a 2d simulation if desired.  See also the :doc:`set
-density/disc <set>` command.  The *sphere* and *bpm/sphere* styles take an optional 0
-or 1 argument.  A value of 0 means the radius of each sphere is
-constant for the duration of the simulation.  A value of 1 means the
-radii may vary dynamically during the simulation, e.g. due to use of
-the :doc:`fix adapt <fix_adapt>` command.
+For the *sphere* and *bpm/sphere* styles, the particles are spheres
+and each stores a per-particle diameter and mass.  If the diameter >
+0.0, the particle is a finite-size sphere.  If the diameter = 0.0, it
+is a point particle.  Note that by use of the *disc* keyword with the
+:doc:`fix nve/sphere <fix_nve_sphere>`, :doc:`fix nvt/sphere
+<fix_nvt_sphere>`, :doc:`fix nph/sphere <fix_nph_sphere>`, :doc:`fix
+npt/sphere <fix_npt_sphere>` commands for the *sphere* style, spheres
+can be effectively treated as 2d discs for a 2d simulation if desired.
+See also the :doc:`set density/disc <set>` command.  The *sphere* and
+*bpm/sphere* styles take an optional 0 or 1 argument.  A value of 0
+means the radius of each sphere is constant for the duration of the
+simulation.  A value of 1 means the radii may vary dynamically during
+the simulation, e.g. due to use of the :doc:`fix adapt <fix_adapt>`
+command.
 
 For the *ellipsoid* style, the particles are ellipsoids and each
 stores a flag which indicates whether it is a finite-size ellipsoid or
@@ -175,15 +180,16 @@ vector with the 3 diameters of the ellipsoid and a quaternion 4-vector
 with its orientation.
 
 For the *dielectric* style, each particle can be either a physical
-particle (e.g. an ion), or an interface particle representing a boundary
-element. For physical particles, the per-particle properties are
-the same as atom_style full.  For interface particles, in addition to
-these properties, each particle also has an area, a normal unit vector,
-a mean local curvature, the mean and difference of the dielectric constants
-of two sides of the interface, and the local dielectric constant at the
-boundary element.  The distinction between the physical and interface
-particles is only meaningful when :doc:`fix polarize <fix_polarize>`
-commands are applied to the interface particles.
+particle (e.g. an ion), or an interface particle representing a
+boundary element. For physical particles, the per-particle properties
+are the same as atom_style full.  For interface particles, in addition
+to these properties, each particle also has an area, a normal unit
+vector, a mean local curvature, the mean and difference of the
+dielectric constants of two sides of the interface, and the local
+dielectric constant at the boundary element.  The distinction between
+the physical and interface particles is only meaningful when :doc:`fix
+polarize <fix_polarize>` commands are applied to the interface
+particles.
 
 For the *dipole* style, a point dipole is defined for each point
 particle.  Note that if you wish the particles to be finite-size
@@ -272,16 +278,17 @@ showing the use of the *template* atom style versus *molecular*.
 
 .. note::
 
-   When using the *template* style with a :doc:`molecule template <molecule>` that contains multiple molecules, you should
-   insure the atom types, bond types, angle_types, etc in all the
-   molecules are consistent.  E.g. if one molecule represents H2O and
-   another CO2, then you probably do not want each molecule file to
-   define 2 atom types and a single bond type, because they will conflict
-   with each other when a mixture system of H2O and CO2 molecules is
-   defined, e.g. by the :doc:`read_data <read_data>` command.  Rather the
-   H2O molecule should define atom types 1 and 2, and bond type 1.  And
-   the CO2 molecule should define atom types 3 and 4 (or atom types 3 and
-   2 if a single oxygen type is desired), and bond type 2.
+   When using the *template* style with a :doc:`molecule template
+   <molecule>` that contains multiple molecules, you should insure the
+   atom types, bond types, angle_types, etc in all the molecules are
+   consistent.  E.g. if one molecule represents H2O and another CO2,
+   then you probably do not want each molecule file to define 2 atom
+   types and a single bond type, because they will conflict with each
+   other when a mixture system of H2O and CO2 molecules is defined,
+   e.g. by the :doc:`read_data <read_data>` command.  Rather the H2O
+   molecule should define atom types 1 and 2, and bond type 1.  And
+   the CO2 molecule should define atom types 3 and 4 (or atom types 3
+   and 2 if a single oxygen type is desired), and bond type 2.
 
 For the *body* style, the particles are arbitrary bodies with internal
 attributes defined by the "style" of the bodies, which is specified by
@@ -339,6 +346,8 @@ Many of the styles listed above are only enabled if LAMMPS was built
 with a specific package, as listed below.  See the :doc:`Build package
 <Build_package>` page for more info.
 
+The *amoeba* style is part of the AMOEBA package.
+
 The *angle*, *bond*, *full*, *molecular*, and *template* styles are
 part of the MOLECULE package.
 
@@ -350,9 +359,11 @@ The *dipole* style is part of the DIPOLE package.
 
 The *peri* style is part of the PERI package for Peridynamics.
 
-The *oxdna* style is part of the CG-DNA package for coarse-grained simulation of DNA and RNA.
+The *oxdna* style is part of the CG-DNA package for coarse-grained
+simulation of DNA and RNA.
 
-The *electron* style is part of the EFF package for :doc:`electronic force fields <pair_eff>`.
+The *electron* style is part of the EFF package for :doc:`electronic
+force fields <pair_eff>`.
 
 The *dpd* style is part of the DPD-REACT package for dissipative
 particle dynamics (DPD).
@@ -363,7 +374,8 @@ dissipative particle dynamics (mDPD), and transport dissipative particle
 dynamics (tDPD), respectively.
 
 The *sph* style is part of the SPH package for smoothed particle
-hydrodynamics (SPH).  See `this PDF guide <PDF/SPH_LAMMPS_userguide.pdf>`_ to using SPH in LAMMPS.
+hydrodynamics (SPH).  See `this PDF guide
+<PDF/SPH_LAMMPS_userguide.pdf>`_ to using SPH in LAMMPS.
 
 The *mesont* style is part of the MESONT package.
 

doc/src/compute.rst

@@ -284,6 +284,8 @@ The individual style names on the :doc:`Commands compute <Commands_compute>` pag
 * :doc:`smd/vol <compute_smd_vol>` - per-particle volumes and their sum in Smooth Mach Dynamics
 * :doc:`snap <compute_sna_atom>` - gradients of SNAP energy and forces w.r.t. linear coefficients and related quantities for fitting SNAP potentials
 * :doc:`sna/atom <compute_sna_atom>` - bispectrum components for each atom
+* :doc:`sna/grid <compute_sna_atom>` - global array of bispectrum components on a regular grid
+* :doc:`sna/grid/local <compute_sna_atom>` - local array of bispectrum components on a regular grid
 * :doc:`snad/atom <compute_sna_atom>` - derivative of bispectrum components for each atom
 * :doc:`snav/atom <compute_sna_atom>` - virial contribution from bispectrum components for each atom
 * :doc:`sph/e/atom <compute_sph_e_atom>` - per-atom internal energy of Smooth-Particle Hydrodynamics atoms

doc/src/compute_ave_sphere_atom.rst

@@ -35,16 +35,24 @@ Examples
 Description
 """""""""""
 
-Define a computation that calculates the local density and temperature
-for each atom and neighbors inside a spherical cutoff.
+Define a computation that calculates the local mass density and
+temperature for each atom based on its neighbors inside a spherical
+cutoff.  If an atom has M neighbors, then its local mass density is
+calculated as the sum of its mass and its M neighbor masses, divided
+by the volume of the cutoff sphere (or circle in 2d).  The local
+temperature of the atom is calculated as the temperature of the
+collection of M+1 atoms, after subtracting the center-of-mass velocity
+of the M+1 atoms from each of the M+1 atom's velocities.  This is
+effectively the thermal velocity of the neighborhood of the central
+atom, similar to :doc:`compute temp/com <compute_temp_com>`.
 
-The optional keyword *cutoff* defines the distance cutoff
-used when searching for neighbors. The default value is the cutoff
-specified by the pair style. If no pair style is defined, then a cutoff
-must be defined using this keyword. If the specified cutoff is larger than
-that of the pair_style plus neighbor skin (or no pair style is defined),
-the *comm_modify cutoff* option must also be set to match that of the
-*cutoff* keyword.
+The optional keyword *cutoff* defines the distance cutoff used when
+searching for neighbors. The default value is the cutoff specified by
+the pair style. If no pair style is defined, then a cutoff must be
+defined using this keyword. If the specified cutoff is larger than
+that of the pair_style plus neighbor skin (or no pair style is
+defined), the *comm_modify cutoff* option must also be set to match
+that of the *cutoff* keyword.
 
 The neighbor list needed to compute this quantity is constructed each
 time the calculation is performed (i.e. each time a snapshot of atoms
@@ -55,16 +63,16 @@ too frequently.
 
    If you have a bonded system, then the settings of
    :doc:`special_bonds <special_bonds>` command can remove pairwise
-   interactions between atoms in the same bond, angle, or dihedral.  This
-   is the default setting for the :doc:`special_bonds <special_bonds>`
-   command, and means those pairwise interactions do not appear in the
-   neighbor list.  Because this fix uses the neighbor list, it also means
-   those pairs will not be included in the order parameter.  This
-   difficulty can be circumvented by writing a dump file, and using the
-   :doc:`rerun <rerun>` command to compute the order parameter for
-   snapshots in the dump file.  The rerun script can use a
-   :doc:`special_bonds <special_bonds>` command that includes all pairs in
-   the neighbor list.
+   interactions between atoms in the same bond, angle, or dihedral.
+   This is the default setting for the :doc:`special_bonds
+   <special_bonds>` command, and means those pairwise interactions do
+   not appear in the neighbor list.  Because this compute uses the
+   neighbor list, it also means those pairs will not be included in
+   the order parameter.  This difficulty can be circumvented by
+   writing a dump file, and using the :doc:`rerun <rerun>` command to
+   compute the order parameter for snapshots in the dump file.  The
+   rerun script can use a :doc:`special_bonds <special_bonds>` command
+   that includes all pairs in the neighbor list.
 
 ----------
 
@@ -77,17 +85,20 @@ too frequently.
 Output info
 """""""""""
 
-This compute calculates a per-atom array with two columns: density and temperature.
+This compute calculates a per-atom array with two columns: mass
+density in density :doc:`units <units>` and temperature in temperature
+:doc:`units <units>`.
 
 These values can be accessed by any command that uses per-atom values
-from a compute as input.  See the :doc:`Howto output <Howto_output>` doc
-page for an overview of LAMMPS output options.
+from a compute as input.  See the :doc:`Howto output <Howto_output>`
+doc page for an overview of LAMMPS output options.
 
 Restrictions
 """"""""""""
 
-This compute is part of the EXTRA-COMPUTE package.  It is only enabled if
-LAMMPS was built with that package.  See the :doc:`Build package <Build_package>` page for more info.
+This compute is part of the EXTRA-COMPUTE package.  It is only enabled
+if LAMMPS was built with that package.  See the :doc:`Build package
+<Build_package>` page for more info.
 
 Related commands
 """"""""""""""""
@@ -97,5 +108,5 @@ Related commands
 Default
 """""""
 
-The option defaults are *cutoff* = pair style cutoff
+The option defaults are *cutoff* = pair style cutoff.
 

doc/src/compute_sna_atom.rst

@@ -2,6 +2,8 @@
 .. index:: compute snad/atom
 .. index:: compute snav/atom
 .. index:: compute snap
+.. index:: compute sna/grid
+.. index:: compute sna/grid/local
 
 compute sna/atom command
 ========================
@@ -15,6 +17,12 @@ compute snav/atom command
 compute snap command
 ====================
 
+compute sna/grid command
+========================
+
+compute sna/grid/local command
+==============================
+
 Syntax
 """"""
 
@@ -24,6 +32,9 @@ Syntax
    compute ID group-ID snad/atom rcutfac rfac0 twojmax R_1 R_2 ... w_1 w_2 ... keyword values ...
    compute ID group-ID snav/atom rcutfac rfac0 twojmax R_1 R_2 ... w_1 w_2 ... keyword values ...
    compute ID group-ID snap rcutfac rfac0 twojmax R_1 R_2 ... w_1 w_2 ... keyword values ...
+   compute ID group-ID snap rcutfac rfac0 twojmax R_1 R_2 ... w_1 w_2 ... keyword values ...
+   compute ID group-ID sna/grid nx ny nz rcutfac rfac0 twojmax R_1 R_2 ... w_1 w_2 ... keyword values ...
+   compute ID group-ID sna/grid/local nx ny nz rcutfac rfac0 twojmax R_1 R_2 ... w_1 w_2 ... keyword values ...
 
 * ID, group-ID are documented in :doc:`compute <compute>` command
 * sna/atom = style name of this compute command
@@ -32,8 +43,9 @@ Syntax
 * twojmax = band limit for bispectrum components (non-negative integer)
 * R_1, R_2,... = list of cutoff radii, one for each type (distance units)
 * w_1, w_2,... = list of neighbor weights, one for each type
+* nx, ny, nz = number of grid points in x, y, and z directions (positive integer)
 * zero or more keyword/value pairs may be appended
-* keyword = *rmin0* or *switchflag* or *bzeroflag* or *quadraticflag* or *chem* or *bnormflag* or *wselfallflag* or *bikflag* or *switchinnerflag* or *sinner* or *dinner*
+* keyword = *rmin0* or *switchflag* or *bzeroflag* or *quadraticflag* or *chem* or *bnormflag* or *wselfallflag* or *bikflag* or *switchinnerflag* or *sinner* or *dinner* or *dgradflag*
 
   .. parsed-literal::
 
@@ -56,9 +68,6 @@ Syntax
        *wselfallflag* value = *0* or *1*
           *0* = self-contribution only for element of central atom
           *1* = self-contribution for all elements
-       *bikflag* value = *0* or *1* (only implemented for compute snap)
-          *0* = per-atom bispectrum descriptors are summed over atoms
-          *1* = per-atom bispectrum descriptors are not summed over atoms
        *switchinnerflag* value = *0* or *1*
           *0* = do not use inner switching function
           *1* = use inner switching function
@@ -66,6 +75,12 @@ Syntax
           *sinnerlist* = *ntypes* values of *Sinner* (distance units)
        *dinner* values = *dinnerlist*
           *dinnerlist* = *ntypes* values of *Dinner* (distance units)
+       *bikflag* value = *0* or *1* (only implemented for compute snap)
+          *0* = descriptors are summed over atoms of each type
+          *1* = descriptors are listed separately for each atom
+       *dgradflag* value = *0* or *1* (only implemented for compute snap)
+          *0* = descriptor gradients are summed over atoms of each type
+          *1* = descriptor gradients are listed separately for each atom pair
 
 Examples
 """"""""
@@ -78,6 +93,7 @@ Examples
    compute snap all snap 1.4 0.95 6 2.0 1.0
    compute snap all snap 1.0 0.99363 6 3.81 3.83 1.0 0.93 chem 2 0 1
    compute snap all snap 1.0 0.99363 6 3.81 3.83 1.0 0.93 switchinnerflag 1 sinner 1.35 1.6 dinner 0.25 0.3
+   compute bgrid all sna/grid/local 200 200 200 1.4 0.95 6 2.0 1.0
 
 Description
 """""""""""
@@ -212,6 +228,46 @@ command:
 See section below on output for a detailed explanation of the data
 layout in the global array.
 
+The compute *sna/grid* and *sna/grid/local* commands calculate
+bispectrum components for a regular grid of points.
+These are calculated from the local density of nearby atoms *i'*
+around each grid point, as if there was a central atom *i*
+at the grid point. This is useful for characterizing fine-scale
+structure in a configuration of atoms, and it is used
+in the `MALA package <https://github.com/casus/mala>`_
+to build machine-learning surrogates for finite-temperature Kohn-Sham
+density functional theory (:ref:`Ellis et al. <Ellis2021>`)
+Neighbor atoms not in the group do not contribute to the
+bispectrum components of the grid points. The distance cutoff :math:`R_{ii'}`
+assumes that *i* has the same type as the neighbor atom *i'*.
+
+Compute *sna/grid* calculates a global array containing bispectrum
+components for a regular grid of points.
+The grid is aligned with the current box dimensions, with the
+first point at the box origin, and forming a regular 3d array with
+*nx*, *ny*, and *nz* points in the x, y, and z directions. For triclinic
+boxes, the array is congruent with the periodic lattice vectors
+a, b, and c. The array contains one row for each of the
+:math:`nx \times ny \times nz` grid points, looping over the index for *ix* fastest,
+then *iy*, and *iz* slowest.  Each row of the array contains the *x*, *y*,
+and *z* coordinates of the grid point, followed by the bispectrum
+components. See section below on output for a detailed explanation of the data
+layout in the global array.
+
+Compute *sna/grid/local* calculates bispectrum components of a regular
+grid of points similarly to compute *sna/grid* described above.
+However, because the array is local, it contains only rows for grid points
+that are local to the processor sub-domain. The global grid
+of :math:`nx \times ny \times nz` points is still laid out in space the same as for *sna/grid*,
+but grid points are strictly partitioned, so that every grid point appears in
+one and only one local array.  The array contains one row for each of the
+local grid points, looping over the global index *ix* fastest,
+then *iy*, and *iz* slowest.  Each row of the array contains
+the global indexes *ix*, *iy*, and *iz* first, followed by the *x*, *y*,
+and *z* coordinates of the grid point, followed by the bispectrum
+components. See section below on output for a detailed explanation of the data
+layout in the global array.
+
 The value of all bispectrum components will be zero for atoms not in
 the group. Neighbor atoms not in the group do not contribute to the
 bispectrum of atoms in the group.
@@ -307,15 +363,6 @@ This option is typically used in conjunction with the *chem* keyword,
 and LAMMPS will generate a warning if both *chem* and *bnormflag*
 are not both set or not both unset.
 
-The keyword *bikflag* determines whether or not to expand the bispectrum
-rows of the global array returned by compute snap. If *bikflag* is set
-to *1* then the bispectrum row, which is typically the per-atom bispectrum
-descriptors :math:`B_{i,k}` summed over all atoms *i* to produce
-:math:`B_k`, becomes bispectrum rows equal to the number of atoms. Thus,
-the resulting bispectrum rows are :math:`B_{i,k}` instead of just
-:math:`B_k`. In this case, the entries in the final column for these rows
-are set to zero.
-
 The keyword *switchinnerflag* with value 1
 activates an additional radial switching
 function similar to :math:`f_c(r)` above, but acting to switch off
@@ -340,6 +387,36 @@ When the central atom and the neighbor atom have different types,
 the values of :math:`S_{inner}` and :math:`D_{inner}` are
 the arithmetic means of the values for both types.
 
+The keywords *bikflag* and *dgradflag* are only used by compute *snap*.
+The keyword *bikflag* determines whether or not to list the descriptors
+of each atom separately, or sum them together and list in a single row.
+If *bikflag* is set
+to *0* then a single bispectrum row is used, which contains the per-atom bispectrum
+descriptors :math:`B_{i,k}` summed over all atoms *i* to produce
+:math:`B_k`.  If *bikflag* is set
+to *1* this is replaced by a separate per-atom bispectrum row for each atom.
+In this case, the entries in the final column for these rows
+are set to zero.
+
+The keyword *dgradflag* determines whether to sum atom gradients or list
+them separately. If *dgradflag* is set to 0, the bispectrum
+descriptor gradients w.r.t. atom *j* are summed over all atoms *i'*
+of type *I* (similar to *snad/atom* above).
+If *dgradflag* is set to 1, gradients are listed separately for each pair of atoms.
+Each row corresponds
+to a single term :math:`\frac{\partial {B_{i,k}  }}{\partial {r}^a_j}`
+where :math:`{r}^a_j` is the *a-th* position coordinate of the atom with global
+index *j*. This also changes
+the number of columns to be equal to the number of bispectrum components, with 3
+additional columns representing the indices :math:`i`, :math:`j`, and :math:`a`,
+as explained more in the Output info section below. The option *dgradflag=1*
+requires that *bikflag=1*.
+
+.. note::
+
+   Using *dgradflag* = 1 produces a global array with :math:`N + 3N^2 + 1` rows
+   which becomes expensive for systems with more than 1000 atoms.
+
 .. note::
 
    If you have a bonded system, then the settings of :doc:`special_bonds
@@ -414,6 +491,21 @@ number of columns in the global array generated by *snap* are 31, and
 931, respectively, while the number of rows is 1+3\*\ *N*\ +6, where *N*
 is the total number of atoms.
 
+Compute *sna/grid* evaluates a global array.
+The array contains one row for each of the
+:math:`nx \times ny \times nz` grid points, looping over the index for *ix* fastest,
+then *iy*, and *iz* slowest.  Each row of the array contains the *x*, *y*,
+and *z* coordinates of the grid point, followed by the bispectrum
+components.
+
+Compute *sna/grid/local* evaluates a local array.
+The array contains one row for each of the
+local grid points, looping over the global index *ix* fastest,
+then *iy*, and *iz* slowest.  Each row of the array contains
+the global indexes *ix*, *iy*, and *iz* first, followed by the *x*, *y*,
+and *z* coordinates of the grid point, followed by the bispectrum
+components.
+
 If the *quadratic* keyword value is set to 1, then additional columns
 are generated, corresponding to the products of all distinct pairs of
 bispectrum components. If the number of bispectrum components is *K*,
@@ -435,6 +527,42 @@ components. For the purposes of handling contributions to force, virial,
 and quadratic combinations, these :math:`N_{elem}^3` sub-blocks are
 treated as a single block of :math:`K N_{elem}^3` columns.
 
+If the *bik* keyword is set to 1, the structure of the snap array is expanded.
+The first :math:`N` rows of the snap array
+correspond to :math:`B_{i,k}` instead of a single row summed over atoms :math:`i`.
+In this case, the entries in the final column for these rows
+are set to zero. Also, each row contains only non-zero entries for the
+columns corresponding to the type of that atom. This is not true in the case
+of *dgradflag* keyword = 1 (see below).
+
+If the *dgradflag* keyword is set to 1, this changes the structure of the
+global array completely.
+Here the *snad/atom* quantities are replaced with rows corresponding to
+descriptor gradient components on single atoms:
+
+.. math::
+
+  \frac{\partial {B_{i,k}  }}{\partial {r}^a_j}
+
+where :math:`{r}^a_j` is the *a-th* position coordinate of the atom with global
+index *j*. The rows are
+organized in chunks, where each chunk corresponds to an atom with global index
+:math:`j`. The rows in an atom :math:`j` chunk correspond to
+atoms with global index :math:`i`. The total number of rows for
+these descriptor gradients is therefore :math:`3N^2`.
+The number of columns is equal to the number of bispectrum components,
+plus 3 additional left-most columns representing the global atom indices
+:math:`i`, :math:`j`,
+and Cartesian direction :math:`a`  (0, 1, 2, for x, y, z).
+The first 3 columns of the first :math:`N` rows belong to the reference
+potential force components. The remaining K columns contain the
+:math:`B_{i,k}` per-atom descriptors corresponding to the non-zero entries
+obtained when *bikflag* = 1.
+The first column of the last row, after the first
+:math:`N + 3N^2` rows, contains the reference potential
+energy. The virial components are not used with this option. The total number of
+rows is therefore :math:`N + 3N^2 + 1` and the number of columns is :math:`K + 3`.
+
 These values can be accessed by any command that uses per-atom values
 from a compute as input.  See the :doc:`Howto output <Howto_output>` doc
 page for an overview of LAMMPS output options. To see how this command
@@ -464,8 +592,7 @@ The optional keyword defaults are *rmin0* = 0,
 
 .. _Thompson20141:
 
-**(Thompson)** Thompson, Swiler, Trott, Foiles, Tucker, under review, preprint
-available at `arXiv:1409.3880 <http://arxiv.org/abs/1409.3880>`_
+**(Thompson)** Thompson, Swiler, Trott, Foiles, Tucker, J Comp Phys, 285, 316, (2015).
 
 .. _Bartok20101:
 
@@ -486,4 +613,8 @@ of Angular Momentum, World Scientific, Singapore (1987).
 
 .. _Cusentino2020:
 
-**(Cusentino)** Cusentino, Wood, and Thompson, J Phys Chem A, xxx, xxxxx, (2020)
+**(Cusentino)** Cusentino, Wood, Thompson, J Phys Chem A, 124, 5456, (2020)
+
+.. _Ellis2021:
+
+**(Ellis)** Ellis, Fiedler, Popoola, Modine, Stephens, Thompson, Cangi, Rajamanickam,  Phys Rev B, 104, 035120, (2021)

doc/src/dump.rst

@@ -27,6 +27,9 @@ dump command
 :doc:`dump custom/adios <dump_adios>` command
 =============================================
 
+:doc:`dump cfg/uef <dump_cfg_uef>` command
+==========================================
+
 Syntax
 """"""
 
@@ -36,7 +39,7 @@ Syntax
 
 * ID = user-assigned name for the dump
 * group-ID = ID of the group of atoms to be dumped
-* style = *atom* or *atom/gz* or *atom/zstd or *atom/mpiio* or *cfg* or *cfg/gz* or *cfg/zstd* or *cfg/mpiio* or *custom* or *custom/gz* or *custom/zstd* or *custom/mpiio* or *dcd* or *h5md* or *image* or *local* or *local/gz* or *local/zstd* or *molfile* or *movie* or *netcdf* or *netcdf/mpiio* or *vtk* or *xtc* or *xyz* or *xyz/gz* or *xyz/zstd* or *xyz/mpiio* or *yaml*
+* style = *atom* or *atom/gz* or *atom/zstd or *atom/mpiio* or *cfg* or *cfg/gz* or *cfg/zstd* or *cfg/mpiio* or *cfg/uef* or *custom* or *custom/gz* or *custom/zstd* or *custom/mpiio* or *dcd* or *h5md* or *image* or *local* or *local/gz* or *local/zstd* or *molfile* or *movie* or *netcdf* or *netcdf/mpiio* or *vtk* or *xtc* or *xyz* or *xyz/gz* or *xyz/zstd* or *xyz/mpiio* or *yaml*
 * N = dump every this many timesteps
 * file = name of file to write dump info to
 * args = list of arguments for a particular style
@@ -47,22 +50,23 @@ Syntax
        *atom/gz* args = none
        *atom/zstd* args = none
        *atom/mpiio* args = none
-       *atom/adios* args = none,  discussed on :doc:`dump atom/adios <dump_adios>` doc page
+       *atom/adios* args = none,  discussed on :doc:`dump atom/adios <dump_adios>` page
        *cfg* args = same as *custom* args, see below
        *cfg/gz* args = same as *custom* args, see below
        *cfg/zstd* args = same as *custom* args, see below
        *cfg/mpiio* args = same as *custom* args, see below
+       *cfg/uef* args = same as *custom* args, discussed on :doc:`dump cfg/uef <dump_cfg_uef>` page
        *custom*, *custom/gz*, *custom/zstd*, *custom/mpiio* args = see below
-       *custom/adios* args = same as *custom* args, discussed on :doc:`dump custom/adios <dump_adios>` doc page
+       *custom/adios* args = same as *custom* args, discussed on :doc:`dump custom/adios <dump_adios>` page
        *dcd* args = none
-       *h5md* args = discussed on :doc:`dump h5md <dump_h5md>` doc page
-       *image* args = discussed on :doc:`dump image <dump_image>` doc page
+       *h5md* args = discussed on :doc:`dump h5md <dump_h5md>` page
+       *image* args = discussed on :doc:`dump image <dump_image>` page
        *local*, *local/gz*, *local/zstd* args = see below
-       *molfile* args = discussed on :doc:`dump molfile <dump_molfile>` doc page
-       *movie* args = discussed on :doc:`dump image <dump_image>` doc page
-       *netcdf* args = discussed on :doc:`dump netcdf <dump_netcdf>` doc page
-       *netcdf/mpiio* args = discussed on :doc:`dump netcdf <dump_netcdf>` doc page
-       *vtk* args = same as *custom* args, see below, also :doc:`dump vtk <dump_vtk>` doc page
+       *molfile* args = discussed on :doc:`dump molfile <dump_molfile>` page
+       *movie* args = discussed on :doc:`dump image <dump_image>` page
+       *netcdf* args = discussed on :doc:`dump netcdf <dump_netcdf>` page
+       *netcdf/mpiio* args = discussed on :doc:`dump netcdf <dump_netcdf>` page
+       *vtk* args = same as *custom* args, see below, also :doc:`dump vtk <dump_vtk>` page
        *xtc* args = none
        *xyz* args = none
        *xyz/gz* args = none
@@ -155,7 +159,7 @@ timesteps in one of several styles.  The *image* and *movie* styles are
 the exception: the *image* style renders a JPG, PNG, or PPM image file
 of the atom configuration every N timesteps while the *movie* style
 combines and compresses them into a movie file; both are discussed in
-detail on the :doc:`dump image <dump_image>` doc page.  The timesteps on
+detail on the :doc:`dump image <dump_image>` page.  The timesteps on
 which dump output is written can also be controlled by a variable.
 See the :doc:`dump_modify every <dump_modify>` command.
 
@@ -194,7 +198,7 @@ or multiple smaller files).
 For the *atom*, *custom*, *cfg*, and *local* styles, sorting is off by
 default.  For the *dcd*, *xtc*, *xyz*, and *molfile* styles, sorting
 by atom ID is on by default. See the :doc:`dump_modify <dump_modify>`
-doc page for details.
+page for details.
 
 The *atom/gz*, *cfg/gz*, *custom/gz*, *local/gz*, and *xyz/gz* styles
 are identical in command syntax to the corresponding styles without
@@ -204,7 +208,7 @@ alternative approach to writing compressed files via a pipe, as done
 by the regular dump styles, which may be required on clusters where
 the interface to the high-speed network disallows using the fork()
 library call (which is needed for a pipe).  For the remainder of this
-doc page, you should thus consider the *atom* and *atom/gz* styles
+page, you should thus consider the *atom* and *atom/gz* styles
 (etc) to be inter-changeable, with the exception of the required
 filename suffix.
 
@@ -218,7 +222,7 @@ As explained below, the *atom/mpiio*, *cfg/mpiio*, *custom/mpiio*, and
 *xyz/mpiio* styles are identical in command syntax and in the format
 of the dump files they create, to the corresponding styles without
 "mpiio", except the single dump file they produce is written in
-parallel via the MPI-IO library.  For the remainder of this doc page,
+parallel via the MPI-IO library.  For the remainder of this page,
 you should thus consider the *atom* and *atom/mpiio* styles (etc) to
 be inter-changeable.  The one exception is how the filename is
 specified for the MPI-IO styles, as explained below.
@@ -664,7 +668,7 @@ so that each value is 0.0 to 1.0.  If the simulation box is triclinic
 (tilted), then all atom coords will still be between 0.0 and 1.0.
 I.e. actual unscaled (x,y,z) = xs\*A + ys\*B + zs\*C, where (A,B,C) are
 the non-orthogonal vectors of the simulation box edges, as discussed
-on the :doc:`Howto triclinic <Howto_triclinic>` doc page.
+on the :doc:`Howto triclinic <Howto_triclinic>` page.
 
 Use *xu*, *yu*, *zu* if you want the coordinates "unwrapped" by the
 image flags for each atom.  Unwrapped means that if the atom has
@@ -779,6 +783,11 @@ To write gzipped dump files, you must either compile LAMMPS with the
 -DLAMMPS_GZIP option or use the styles from the COMPRESS package.
 See the :doc:`Build settings <Build_settings>` page for details.
 
+While a dump command is active (i.e. has not been stopped by using
+the undump command), no commands may be used that will change the
+timestep (e.g. :doc:`reset_timestep <reset_timestep>`).  LAMMPS
+will terminate with an error otherwise.
+
 The *atom/gz*, *cfg/gz*, *custom/gz*, and *xyz/gz* styles are part of
 the COMPRESS package.  They are only enabled if LAMMPS was built with
 that package.  See the :doc:`Build package <Build_package>` page for
@@ -787,7 +796,7 @@ more info.
 The *atom/mpiio*, *cfg/mpiio*, *custom/mpiio*, and *xyz/mpiio* styles
 are part of the MPIIO package.  They are only enabled if LAMMPS was
 built with that package.  See the :doc:`Build package <Build_package>`
-doc page for more info.
+page for more info.
 
 The *xtc*, *dcd* and *yaml* styles are part of the EXTRA-DUMP package.
 They are only enabled if LAMMPS was built with that package.  See the
@@ -797,12 +806,12 @@ Related commands
 """"""""""""""""
 
 :doc:`dump atom/adios <dump_adios>`, :doc:`dump custom/adios <dump_adios>`,
-:doc:`dump h5md <dump_h5md>`, :doc:`dump image <dump_image>`,
-:doc:`dump molfile <dump_molfile>`, :doc:`dump_modify <dump_modify>`,
-:doc:`undump <undump>`
+:doc:`dump cfg/uef <dump_cfg_uef>`, :doc:`dump h5md <dump_h5md>`,
+:doc:`dump image <dump_image>`, :doc:`dump molfile <dump_molfile>`,
+:doc:`dump_modify <dump_modify>`, :doc:`undump <undump>`, :doc:`write_dump <write_dump>`
 
 Default
 """""""
 
 The defaults for the *image* and *movie* styles are listed on the
-:doc:`dump image <dump_image>` doc page.
+:doc:`dump image <dump_image>` page.

doc/src/fix.rst

@@ -171,6 +171,8 @@ accelerated styles exist.
 * :doc:`adapt/fep <fix_adapt_fep>` - enhanced version of fix adapt
 * :doc:`addforce <fix_addforce>` - add a force to each atom
 * :doc:`addtorque <fix_addtorque>` - add a torque to a group of atoms
+* :doc:`amoeba/bitorsion <fix_amoeba_bitorsion>` - torsion/torsion terms in AMOEBA force field
+* :doc:`amoeba/pitorsion <fix_amoeba_pitorsion>` - 6-body terms in AMOEBA force field
 * :doc:`append/atoms <fix_append_atoms>` - append atoms to a running simulation
 * :doc:`atc <fix_atc>` - initiates a coupled MD/FE simulation
 * :doc:`atom/swap <fix_atom_swap>` - Monte Carlo atom type swapping
@@ -194,7 +196,7 @@ accelerated styles exist.
 * :doc:`bond/swap <fix_bond_swap>` - Monte Carlo bond swapping
 * :doc:`box/relax <fix_box_relax>` - relax box size during energy minimization
 * :doc:`charge/regulation <fix_charge_regulation>` - Monte Carlo sampling of charge regulation
-* :doc:`cmap <fix_cmap>` - enables CMAP cross-terms of the CHARMM force field
+* :doc:`cmap <fix_cmap>` - CMAP torsion/torsion terms in CHARMM force field
 * :doc:`colvars <fix_colvars>` - interface to the collective variables "Colvars" library
 * :doc:`controller <fix_controller>` - apply control loop feedback mechanism
 * :doc:`damping/cundall <fix_damping_cundall>` - Cundall non-viscous damping for granular simulations
@@ -246,7 +248,7 @@ accelerated styles exist.
 * :doc:`lb/viscous <fix_lb_viscous>` -
 * :doc:`lineforce <fix_lineforce>` - constrain atoms to move in a line
 * :doc:`manifoldforce <fix_manifoldforce>` - restrain atoms to a manifold during minimization
-* :doc:`mdi/aimd <fix_mdi_aimd>` - LAMMPS operates as driver for ab initio MD (AIMD) via the MolSSI Driver Interface (MDI)
+* :doc:`mdi/qm <fix_mdi_qm>` - LAMMPS operates as driver for a quantum code 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/src/fix_amoeba_bitorsion.rst

@@ -0,0 +1,166 @@
+.. index:: fix amoeba/bitorsion
+
+fix amoeba/bitorsion command
+============================
+
+Syntax
+""""""
+
+.. parsed-literal::
+
+   fix ID group-ID ameoba/bitorsion filename
+
+* ID, group-ID are documented in :doc:`fix <fix>` command
+* amoeba/bitorsion = style name of this fix command
+* filename = force-field file with AMOEBA bitorsion coefficients
+
+Examples
+""""""""
+
+.. code-block:: LAMMPS
+
+   fix            bit all amoeba/bitorsion bitorsion.ubiquitin.data
+   read_data      proteinX.data fix bit bitorsions BiTorsions
+   fix_modify     bit energy yes
+
+Description
+"""""""""""
+
+This command enables 5-body torsion/torsion interactions to be added
+to simulations which use the AMOEBA and HIPPO force fields.  It
+matches how the Tinker MD code computes its torsion/torsion
+interactions for the AMOEBA and HIPPO force fields.  See the
+:doc:`Howto amoeba <Howto_amoeba>` doc page for more information about
+the implementation of AMOEBA and HIPPO in LAMMPS.
+
+Bitorsion interactions add additional potential energy contributions
+to pairs of overlapping phi-psi dihedrals of amino-acids, which are
+important to properly represent their conformational behavior.
+
+The examples/amoeba directory has a sample input script and data file
+for ubiquitin, which illustrates use of the fix amoeba/bitorsion
+command.
+
+As in the example above, this fix should be used before reading a data
+file that contains a listing of bitorsion interactions.  The
+*filename* specified should contain the bitorsion parameters for the
+AMOEBA or HIPPO force field.
+
+The data file read by the :doc:`read_data <read_data>` command must
+contain the topology of all the bitorsion interactions, similar to the
+topology data for bonds, angles, dihedrals, etc.  Specifically it
+should have a line like this in its header section:
+
+.. parsed-literal::
+
+   N bitorsions
+
+where N is the number of bitorsion 5-body interactions.  It should
+also have a section in the body of the data file like this with N
+lines:
+
+.. parsed-literal::
+
+   BiTorsions
+
+          1       1       8      10      12      18      20
+          2       5      18      20      22      25      27
+          [...]
+          N       3     314     315     317      318    330
+
+The first column is an index from 1 to N to enumerate the bitorsion
+5-atom tuples; it is ignored by LAMMPS.  The second column is the
+*type* of the interaction; it is an index into the bitorsion force
+field file.  The remaining 5 columns are the atom IDs of the atoms in
+the two 4-atom dihedrals that overlap to create the bitorsion 5-body
+interaction.  Note that the *bitorsions* and *BiTorsions* keywords for
+the header and body sections match those specified in the
+:doc:`read_data <read_data>` command following the data file name.
+
+The data file should be generated by using the
+tools/tinker/tinker2lmp.py conversion script which creates a LAMMPS
+data file from Tinker input files, including its PRM file which
+contains the parameters necessary for computing bitorsion
+interactions.  The script must be invoked with the optional
+"-bitorsion" flag to do this; see the example for the ubiquitin system
+in the tools/tinker/README file.  The same conversion script also
+creates the file of bitorsion coefficient data which is read by this
+command.
+
+The potential energy associated with bitorsion interactions can be
+output as described below.  It can also be included in the total
+potential energy of the system, as output by the :doc:`thermo_style
+<thermo_style>` command, if the :doc:`fix_modify energy <fix_modify>`
+command is used, as in the example above.  See the note below about
+how to include the bitorsion energy when performing an :doc:`energy
+minimization <minimize>`.
+
+----------
+
+Restart, fix_modify, output, run start/stop, minimize info
+"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
+
+This fix writes the list of bitorsion interactions to :doc:`binary
+restart files <restart>`.  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.
+
+The :doc:`fix_modify <fix_modify>` *energy* option is supported by
+this fix to add the potential energy of the bitorsion interactions to
+both the global potential energy and peratom potential energies of the
+system as part of :doc:`thermodynamic output <thermo_style>` or output
+by the :doc:`compute pe/atom <compute_pe_atom>` command.  The default
+setting for this fix is :doc:`fix_modify energy yes <fix_modify>`.
+
+The :doc:`fix_modify <fix_modify>` *virial* option is supported by
+this fix to add the contribution due to the bitorsion interactions to
+both the global pressure and per-atom stress of the system via the
+:doc:`compute pressure <compute_pressure>` and :doc:`compute
+stress/atom <compute_stress_atom>` commands.  The former can be
+accessed by :doc:`thermodynamic output <thermo_style>`.  The default
+setting for this fix is :doc:`fix_modify virial yes <fix_modify>`.
+
+This fix computes a global scalar which can be accessed by various
+:doc:`output commands <Howto_output>`.  The scalar is the potential
+energy discussed above.  The scalar value calculated by this fix is
+"extensive".
+
+No parameter of this fix can be used with the *start/stop* keywords of
+the :doc:`run <run>` command.
+
+The forces due to this fix are imposed during an energy minimization,
+invoked by the :doc:`minimize <minimize>` command.
+
+The :doc:`fix_modify <fix_modify>` *respa* option is supported by this
+fix. This allows to set at which level of the :doc:`r-RESPA
+<run_style>` integrator the fix is adding its forces. Default is the
+outermost level.
+
+.. note::
+
+   For energy minimization, if you want the potential energy
+   associated with the bitorsion terms forces to be included in the
+   total potential energy of the system (the quantity being
+   minimized), you MUST not disable the :doc:`fix_modify <fix_modify>`
+   *energy* option for this fix.
+
+Restrictions
+""""""""""""
+
+To function as expected this fix command must be issued *before* a
+:doc:`read_data <read_data>` command but *after* a :doc:`read_restart
+<read_restart>` command.
+
+This fix can only be used if LAMMPS was built with the AMOEBA package.
+See the :doc:`Build package <Build_package>` page for more info.
+
+Related commands
+""""""""""""""""
+
+:doc:`fix_modify <fix_modify>`, :doc:`read_data <read_data>`
+
+Default
+"""""""
+
+none

doc/src/fix_amoeba_pitorsion.rst

@@ -0,0 +1,178 @@
+.. index:: fix amoeba/pitorsion
+
+fix amoeba/pitorsion command
+============================
+
+Syntax
+""""""
+
+.. parsed-literal::
+
+   fix ID group-ID ameoba/pitorsion
+
+* ID, group-ID are documented in :doc:`fix <fix>` command
+* amoeba/pitorsion = style name of this fix command
+
+Examples
+""""""""
+
+.. code-block:: LAMMPS
+
+   fix            pit all amoeba/pitorsion
+   read_data      proteinX.data fix pit "pitorsion types" "PiTorsion Coeffs" &
+                  fix pit pitorsions PiTorsions
+   fix_modify     pit energy yes
+
+Description
+"""""""""""
+
+This command enables 6-body pitorsion interactions to be added to
+simulations which use the AMOEBA and HIPPO force fields.  It matches
+how the Tinker MD code computes its pitorsion interactions for the
+AMOEBA and HIPPO force fields.  See the :doc:`Howto amoeba
+<Howto_amoeba>` doc page for more information about the implementation
+of AMOEBA and HIPPO in LAMMPS.
+
+Pitorsion interactions add additional potential energy contributions
+to 6-tuples of atoms IJKLMN which have a bond between atoms K and L,
+where both K and L are additionally bonded to exactly two other atoms.
+Namely K is also bonded to I and J.  And L is also bonded to M and N.
+
+The examples/amoeba directory has a sample input script and data file
+for ubiquitin, which illustrates use of the fix amoeba/pitorsion
+command.
+
+As in the example above, this fix should be used before reading a data
+file that contains a listing of pitorsion interactions.
+
+The data file read by the :doc:`read_data <read_data>` command must
+contain the topology of all the pitorsion interactions, similar to the
+topology data for bonds, angles, dihedrals, etc.  Specifically it
+should have two lines like these in its header section:
+
+.. parsed-literal::
+
+   M pitorsion types
+   N pitorsions
+
+where N is the number of pitorsion 5-body interactions and M is the
+number of pitorsion types.  It should also have two sections in the body
+of the data file like these with M and N lines each:
+
+.. parsed-literal::
+
+   PiTorsion Coeffs
+
+          1 6.85
+          2 10.2
+          [...]
+          M 6.85
+
+.. parsed-literal::
+
+   PiTorsions
+
+          1       1       8      10      12      18      20
+          2       5      18      20      22      25      27
+          [...]
+          N       3     314     315     317      318    330
+
+For PiTorsion Coeffs, the first column is an index from 1 to M to
+enumerate the pitorsion types.  The second column is the single
+prefactor coefficient needed for each type.
+
+For PiTorsions, the first column is an index from 1 to N to enumerate
+the pitorsion 5-atom tuples; it is ignored by LAMMPS.  The second
+column is the "type" of the interaction; it is an index into the
+PiTorsion Coeffs.  The remaining 5 columns are the atom IDs of the
+atoms in the two 4-atom dihedrals that overlap to create the pitorsion
+5-body interaction.
+
+Note that the *pitorsion types* and *pitorsions* and *PiTorsion
+Coeffs* and *PiTorsions* keywords for the header and body sections of
+the data file match those specified in the :doc:`read_data
+<read_data>` command following the data file name.
+
+The data file should be generated by using the
+tools/tinker/tinker2lmp.py conversion script which creates a LAMMPS
+data file from Tinker input files, including its PRM file which
+contains the parameters necessary for computing pitorsion
+interactions.
+
+The potential energy associated with pitorsion interactions can be
+output as described below.  It can also be included in the total
+potential energy of the system, as output by the :doc:`thermo_style
+<thermo_style>` command, if the :doc:`fix_modify energy <fix_modify>`
+command is used, as in the example above.  See the note below about
+how to include the pitorsion energy when performing an :doc:`energy
+minimization <minimize>`.
+
+----------
+
+Restart, fix_modify, output, run start/stop, minimize info
+"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
+
+This fix writes the list of pitorsion interactions to :doc:`binary
+restart files <restart>`.  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.
+
+The :doc:`fix_modify <fix_modify>` *energy* option is supported by
+this fix to add the potential energy of the pitorsion interactions to
+both the global potential energy and peratom potential energies of the
+system as part of :doc:`thermodynamic output <thermo_style>` or output
+by the :doc:`compute pe/atom <compute_pe_atom>` command.  The default
+setting for this fix is :doc:`fix_modify energy yes <fix_modify>`.
+
+The :doc:`fix_modify <fix_modify>` *virial* option is supported by
+this fix to add the contribution due to the pitorsion interactions to
+both the global pressure and per-atom stress of the system via the
+:doc:`compute pressure <compute_pressure>` and :doc:`compute
+stress/atom <compute_stress_atom>` commands.  The former can be
+accessed by :doc:`thermodynamic output <thermo_style>`.  The default
+setting for this fix is :doc:`fix_modify virial yes <fix_modify>`.
+
+This fix computes a global scalar which can be accessed by various
+:doc:`output commands <Howto_output>`.  The scalar is the potential
+energy discussed above.  The scalar value calculated by this fix is
+"extensive".
+
+No parameter of this fix can be used with the *start/stop* keywords of
+the :doc:`run <run>` command.
+
+The forces due to this fix are imposed during an energy minimization,
+invoked by the :doc:`minimize <minimize>` command.
+
+The :doc:`fix_modify <fix_modify>` *respa* option is supported by this
+fix. This allows to set at which level of the :doc:`r-RESPA
+<run_style>` integrator the fix is adding its forces. Default is the
+outermost level.
+
+.. note::
+
+   For energy minimization, if you want the potential energy
+   associated with the pitorsion terms forces to be included in the
+   total potential energy of the system (the quantity being
+   minimized), you MUST not disable the :doc:`fix_modify <fix_modify>`
+   *energy* option for this fix.
+
+Restrictions
+""""""""""""
+
+To function as expected this fix command must be issued *before* a
+:doc:`read_data <read_data>` command but *after* a :doc:`read_restart
+<read_restart>` command.
+
+This fix can only be used if LAMMPS was built with the AMOEBA package.
+See the :doc:`Build package <Build_package>` page for more info.
+
+Related commands
+""""""""""""""""
+
+:doc:`fix_modify <fix_modify>`, :doc:`read_data <read_data>`
+
+Default
+"""""""
+
+none

doc/src/fix_cmap.rst

@@ -26,13 +26,13 @@ Examples
 Description
 """""""""""
 
-This command enables CMAP cross-terms to be added to simulations which
-use the CHARMM force field.  These are relevant for any CHARMM model
-of a peptide or protein sequences that is 3 or more amino-acid
-residues long; see :ref:`(Buck) <Buck>` and :ref:`(Brooks) <Brooks2>`
-for details, including the analytic energy expressions for CMAP
-interactions.  The CMAP cross-terms add additional potential energy
-contributions to pairs of overlapping phi-psi dihedrals of
+This command enables CMAP 5-body interactions to be added to
+simulations which use the CHARMM force field.  These are relevant for
+any CHARMM model of a peptide or protein sequences that is 3 or more
+amino-acid residues long; see :ref:`(Buck) <Buck>` and :ref:`(Brooks)
+<Brooks2>` for details, including the analytic energy expressions for
+CMAP interactions.  The CMAP 5-body terms add additional potential
+energy contributions to pairs of overlapping phi-psi dihedrals of
 amino-acids, which are important to properly represent their
 conformational behavior.
 
@@ -47,15 +47,15 @@ lammps/potentials directory: charmm22.cmap and charmm36.cmap.
 
 The data file read by the "read_data" must contain the topology of all
 the CMAP interactions, similar to the topology data for bonds, angles,
-dihedrals, etc.  Specially it should have a line like this
-in its header section:
+dihedrals, etc.  Specially it should have a line like this in its
+header section:
 
 .. parsed-literal::
 
    N crossterms
 
-where N is the number of CMAP cross-terms.  It should also have a section
-in the body of the data file like this with N lines:
+where N is the number of CMAP 5-body interactions.  It should also
+have a section in the body of the data file like this with N lines:
 
 .. parsed-literal::
 
@@ -66,28 +66,29 @@ in the body of the data file like this with N lines:
           [...]
           N       3     314     315     317      318    330
 
-The first column is an index from 1 to N to enumerate the CMAP terms;
-it is ignored by LAMMPS.  The second column is the "type" of the
-interaction; it is an index into the CMAP force field file.  The
+The first column is an index from 1 to N to enumerate the CMAP 5-atom
+tuples; it is ignored by LAMMPS.  The second column is the "type" of
+the interaction; it is an index into the CMAP force field file.  The
 remaining 5 columns are the atom IDs of the atoms in the two 4-atom
-dihedrals that overlap to create the CMAP 5-body interaction.  Note
-that the "crossterm" and "CMAP" keywords for the header and body
-sections match those specified in the read_data command following the
-data file name; see the :doc:`read_data <read_data>` page for
-more details.
+dihedrals that overlap to create the CMAP interaction.  Note that the
+"crossterm" and "CMAP" keywords for the header and body sections match
+those specified in the read_data command following the data file name;
+see the :doc:`read_data <read_data>` page for more details.
 
-A data file containing CMAP cross-terms can be generated from a PDB
-file using the charmm2lammps.pl script in the tools/ch2lmp directory
-of the LAMMPS distribution.  The script must be invoked with the
-optional "-cmap" flag to do this; see the tools/ch2lmp/README file for
-more information.
+A data file containing CMAP 5-body interactions can be generated from
+a PDB file using the charmm2lammps.pl script in the tools/ch2lmp
+directory of the LAMMPS distribution.  The script must be invoked with
+the optional "-cmap" flag to do this; see the tools/ch2lmp/README file
+for more information.  The same conversion script also creates the
+file of CMAP coefficient data which is read by this command.
 
 The potential energy associated with CMAP interactions can be output
 as described below.  It can also be included in the total potential
-energy of the system, as output by the
-:doc:`thermo_style <thermo_style>` command, if the :doc:`fix_modify energy <fix_modify>` command is used, as in the example above.  See
-the note below about how to include the CMAP energy when performing an
-:doc:`energy minimization <minimize>`.
+energy of the system, as output by the :doc:`thermo_style
+<thermo_style>` command, if the :doc:`fix_modify energy <fix_modify>`
+command is used, as in the example above.  See the note below about
+how to include the CMAP energy when performing an :doc:`energy
+minimization <minimize>`.
 
 ----------
 
@@ -134,10 +135,11 @@ outermost level.
 
 .. note::
 
-   If you want the potential energy associated with the CMAP terms
-   forces to be included in the total potential energy of the system
-   (the quantity being minimized), you MUST not disable the
-   :doc:`fix_modify <fix_modify>` *energy* option for this fix.
+   For energy minimization, if you want the potential energy
+   associated with the CMAP terms forces to be included in the total
+   potential energy of the system (the quantity being minimized), you
+   MUST not disable the :doc:`fix_modify <fix_modify>` *energy* option
+   for this fix.
 
 Restrictions
 """"""""""""

doc/src/fix_latte.rst

@@ -116,13 +116,6 @@ potential energy of the system as part of :doc:`thermodynamic output
 <thermo_style>`.  The default setting for this fix is :doc:`fix_modify
 energy yes <fix_modify>`.
 
-The :doc:`fix_modify <fix_modify>` *virial* option is supported by
-this fix to add the contribution compute by LATTE to the global
-pressure of the system via the :doc:`compute pressure
-<compute_pressure>` command.  This can be accessed by
-:doc:`thermodynamic output <thermo_style>`.  The default setting for
-this fix is :doc:`fix_modify virial yes <fix_modify>`.
-
 The :doc:`fix_modify <fix_modify>` *virial* option is supported by
 this fix to add the contribution computed by LATTE to the global
 pressure of the system as part of :doc:`thermodynamic output
@@ -137,7 +130,7 @@ energy discussed above.  The scalar value calculated by this fix is
 No parameter of this fix can be used with the *start/stop* keywords of
 the :doc:`run <run>` command.
 
-The DFTB forces computed by LATTE via this fix are imposed during an
+The DFTB forces computed by LATTE via this fix are used during an
 energy minimization, invoked by the :doc:`minimize <minimize>`
 command.
 

doc/src/fix_mdi_aimd.rst

@@ -1,103 +0,0 @@
-.. index:: fix mdi/aimd
-
-fix mdi/aimd command
-======================
-
-Syntax
-""""""
-
-.. parsed-literal::
-
-   fix ID group-ID mdi/aimd keyword
-
-* ID, group-ID are documented in :doc:`fix <fix>` command
-* mdi/aimd = style name of this fix command
-* optional keyword = *plugin*
-
-Examples
-""""""""
-
-.. code-block:: LAMMPS
-
-   fix 1 all mdi/aimd
-   fix 1 all mdi/aimd plugin
-
-Description
-"""""""""""
-
-This command enables LAMMPS to act as a client with another server
-code to couple the two codes together to perform ab initio MD (AIMD)
-simulations.
-
-More specifically, this command causes LAMMPS to begin using the `MDI
-Library <https://molssi-mdi.github.io/MDI_Library/html/index.html>`_
-to run as an MDI driver (client), which sends MDI commands to an
-external MDI engine code (server) which in the case of AIMD is a
-quantum mechanics (QM) code, or could be LAMMPS itself, acting as a
-surrogate for a QM code.  See the :doc:`Howto mdi <Howto_mdi>` page
-for more information about how LAMMPS can operate as either an MDI
-driver or engine.
-
-The examples/mdi directory contains input scripts performing AIMD in
-this manner with LAMMPS acting as both a driver and an engine
-(surrogate for a QM code).  The examples/mdi/README file explains how
-to launch both driver and engine codes so that they communicate using
-the MDI library via either MPI or sockets.  Any QM code that supports
-MDI could be used in place of LAMMPS acting as a QM surrogate.  See
-the :doc:`Howto mdi <Howto_mdi>` page for a current list (March 2022)
-of such QM codes.
-
-The engine code can run either as a stand-alone code, launched at the
-same time as LAMMPS, or as a plugin library.  See the :doc:`mdi plugin
-<mdi>` command for how to trigger LAMMPS to load the plugin library.
-Again, the examples/mdi/README file explains how to launch both driver
-and engine codes so that engine is used in plugin mode.
-
-To use this fix with a plugin engine, you must specify the
-*plugin* keyword as the last argument, as illustrated above.
-
-.. note::
-
-   As of April 2022, the *plugin* keyword is needed.  In a future
-   version of the MDI library it will no longer be necessary.
-
-----------
-
-This fix performs the timestepping portion of an AIMD simulation.
-Both LAMMPS and the engine code (QM or LAMMPS) should define the same
-system (simulation box, atoms and their types) in their respective
-input scripts.  LAMMPS then begins its timestepping.
-
-At the point in each timestep when LAMMPS needs the force on each
-atom, it communicates with the engine code.  It sends the current
-simulation box size and shape (if they change dynamically, e.g. during
-an NPT simulation), and the current atom coordinates.  The engine code
-computes quantum forces on each atom and returns them to LAMMPS.  If
-LAMMPS also needs the system energy and/or virial, it requests those
-values from the engine code as well.
-
-Restrictions
-""""""""""""
-
-This command is part of the MDI package.  It is only enabled if
-LAMMPS was built with that package.  See the :doc:`Build package
-<Build_package>` page for more info.
-
-To use LAMMPS as an MDI driver in conjunction with other MDI-enabled
-atomistic codes, the :doc:`units <units>` command should be used to
-specify *real* or *metal* units.  This will ensure the correct unit
-conversions between LAMMPS and MDI units, which the other codes will
-also perform in their preferred units.
-
-LAMMPS can also be used as an MDI driver in other unit choices it
-supports, e.g. *lj*, but then no unit conversion is performed.
-
-Related commands
-""""""""""""""""
-
-:doc:`mdi engine <mdi>`
-
-Default
-"""""""
-
-none

doc/src/fix_mdi_qm.rst

@@ -0,0 +1,276 @@
+.. index:: fix mdi/qm
+
+fix mdi/qm command
+======================
+
+Syntax
+""""""
+
+.. parsed-literal::
+
+   fix ID group-ID mdi/qm keyword
+
+* ID, group-ID are documented in :doc:`fix <fix>` command
+* mdi/qm = style name of this fix command
+* zero or more keyword/value pairs may be appended
+* keyword = *virial* or *add* or *every* or *connect* or *elements*
+
+  .. parsed-literal::
+
+       *virial* args = *yes* or *no*
+         yes = request virial tensor from server code
+         no = do not request virial tensor from server code
+       *add* args = *yes* or *no*
+         yes = add returned value from server code to LAMMPS quantities
+         no = do not add returned values to LAMMPS quantities
+       *every* args = Nevery
+         Nevery = request values from server code once every Nevery steps
+       *connect* args = *yes* or *no*
+         yes = perform a one-time connection to the MDI engine code
+         no = do not perform the connection operation
+       *elements* args = N_1 N_2 ... N_ntypes
+         N_1,N_2,...N_ntypes = atomic number for each of ntypes LAMMPS atom types
+
+Examples
+""""""""
+
+.. code-block:: LAMMPS
+
+   fix 1 all mdi/qm
+   fix 1 all mdi/qm virial yes
+   fix 1 all mdi/qm add no every 100 elements 13 29
+
+Description
+"""""""""""
+
+This command enables LAMMPS to act as a client with another server
+code that will compute the total energy, per-atom forces, and total
+virial for atom conformations and simulation box size/shapes that
+LAMMPS sends it.
+
+Typically the server code will be a quantum mechanics (QM) code, hence
+the name of the fix.  However this is not required, the server code
+could be another classical molecular dynamics code or LAMMPS itself.
+The server code must support use of the `MDI Library
+<https://molssi-mdi.github.io/MDI_Library/html/index.html>`_ as
+explained below.
+
+These are example use cases for this fix, discussed further below:
+
+* perform an ab initio MD (AIMD) simulation with quantum forces
+* perform an energy minimization with quantum forces
+* perform a nudged elastic band (NEB) calculation with quantum forces
+* perform a QM calculation for a series of independent systems which LAMMPS reads or generates
+
+The code coupling performed by this command is done via the `MDI
+Library <https://molssi-mdi.github.io/MDI_Library/html/index.html>`_.
+LAMMPS runs as an MDI driver (client), and sends MDI commands to an
+external MDI engine code (server), e.g. a QM code which has support
+for MDI.  See the :doc:`Howto mdi <Howto_mdi>` page for more
+information about how LAMMPS can operate as either an MDI driver or
+engine.
+
+The examples/mdi directory contains input scripts using this fix in
+the various use cases discussed below.  In each case, two instances of
+LAMMPS are used, once as an MDI driver, once as an MDI engine
+(surrogate for a QM code).  The examples/mdi/README file explains how
+to launch two codes so that they communicate via the MDI library using
+either MPI or sockets.  Any QM code that supports MDI could be used in
+place of LAMMPS acting as a QM surrogate.  See the :doc:`Howto mdi
+<Howto_mdi>` page for a current list (March 2022) of such QM codes.
+
+Note that an engine code can support MDI in either or both of two
+modes.  It can be used as a stand-alone code, launched at the same
+time as LAMMPS.  Or it can be used as a plugin library, which LAMMPS
+loads.  See the :doc:`mdi plugin <mdi>` command for how to trigger
+LAMMPS to load a plugin library.  The examples/mdi/README file
+explains how to launch the two codes in either mode.
+
+----------
+
+The *virial* keyword setting of yes or no determines whether
+LAMMPS will request the QM code to also compute and return
+a 6-element symmetric virial tensor for the system.
+
+The *add* keyword setting of *yes* or *no* determines whether the
+energy and forces and virial returned by the QM code will be added to
+the LAMMPS internal energy and forces and virial or not.  If the
+setting is *no* then the default :doc:`fix_modify energy <fix_modify>`
+and :doc:`fix_modify virial <fix_modify>` settings are also set to
+*no* and your input scripts should not set them to yes.  See more
+details on these fix_modify settings below.
+
+Whatever the setting for the *add* keyword, the QM energy, forces, and
+virial will be stored by the fix, so they can be accessed by other
+commands.  See details below.
+
+The *every* keyword determines how often the QM code will be invoked
+during a dynamics run with the current LAMMPS simulation box and
+configuration of atoms.  The QM code will be called once every
+*Nevery* timesteps.
+
+The *connect* keyword determines whether this fix performs a one-time
+connection to the QM code.  The default is *yes*.  The only time a
+*no* is needed is if this command is used multiple times in an input
+script.  E.g. if it used inside a loop which also uses the :doc:`clear
+<clear>` command to destroy the system (including any defined fixes).
+See the examples/mdi/in.series.driver script as an example of this,
+where LAMMPS is using the QM code to compute energy and forces for a
+series of system configurations.  In this use case *connect no*
+is used along with the :doc:`mdi connect and exit <mdi>` command
+to one-time initiate/terminate the connection outside the loop.
+
+The *elements* keyword allows specification of what element each
+LAMMPS atom type corresponds to.  This is specified by the atomic
+number of the element, e.g. 13 for Al.  An atomic number must be
+specified for each of the ntypes LAMMPS atom types.  Ntypes is
+typically specified via the create_box command or in the data file
+read by the read_data command.  If this keyword is not specified, then
+this fix will send the LAMMPS atom type for each atom to the MDI
+engine.  If both the LAMMPS driver and the MDI engine are initialized
+so that atom type values are consistent in both codes, then the
+*elements* keyword is not needed.  Otherwise the keyword can be used
+to insure the two codes are consistent in their definition of atomic
+species.
+
+----------
+
+The following 3 example use cases are illustrated in the examples/mdi
+directory.  See its README file for more details.
+
+(1) To run an ab initio MD (AIMD) dynamics simulation, or an energy
+minimization with QM forces, or a multi-replica NEB calculation, use
+*add yes* and *every 1* (the defaults).  This is so that every time
+LAMMPS needs energy and forces, the QM code will be invoked.
+
+Both LAMMPS and the QM code should define the same system (simulation
+box, atoms and their types) in their respective input scripts.  Note
+that on this scenario, it may not be necessary for LAMMPS to define a
+pair style or use a neighbor list.
+
+LAMMPS will then perform the timestepping or minimization iterations
+for the simulation.  At the point in each timestep or iteration when
+LAMMPS needs the force on each atom, it communicates with the engine
+code.  It sends the current simulation box size and shape (if they
+change dynamically, e.g. during an NPT simulation), and the current
+atom coordinates.  The engine code computes quantum forces on each
+atom and the total energy of the system and returns them to LAMMPS.
+
+Note that if the AIMD simulation is an NPT or NPH model, or the energy
+minimization includes :doc:`fix box relax <fix_box_relax>` to
+equilibrate the box size/shape, then LAMMPS computes a pressure.  This
+means the *virial* keyword should be set to *yes* so that the QM
+contribution to the pressure can be included.
+
+(2) To run dynamics with a LAMMPS interatomic potential, and evaluate
+the QM energy and forces once every 1000 steps, use *add no* and
+*every 1000*.  This could be useful for using an MD run to generate
+randomized configurations which are then passed to the QM code to
+produce training data for a machine learning potential.  A :doc:`dump
+custom <dump>` command could be invoked every 1000 steps to dump the
+atom coordinates and QM forces to a file.  Likewise the QM energy and
+virial could be output with the :doc:`thermo_style custom
+<thermo_style>` command.
+
+(3) To do a QM evaluation of energy and forces for a series of *N*
+independent systems (simulation box and atoms), use *add no* and
+*every 1*.  Write a LAMMPS input script which loops over the *N*
+systems.  See the :doc:`Howto multiple <Howto_multiple>` doc page for
+details on looping and removing old systems.  The series of systems
+could be initialized by reading them from data files with
+:doc:`read_data <read_data>` commands.  Or, for example, by using the
+:doc:`lattice <lattice>` , :doc:`create_atoms <create_atoms>`,
+:doc:`delete_atoms <delete_atoms>`, and/or :doc:`displace_atoms
+random <displace_atoms>` commands to generate a series of different
+systems.  At the end of the loop perform :doc:`run 0 <run>` and
+:doc:`write_dump <write_dump>` commands to invoke the QM code and
+output the QM energy and forces.  As in (2) this be useful to produce
+QM data for training a machine learning potential.
+
+----------
+
+Restart, fix_modify, output, run start/stop, minimize info
+"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
+
+No information about this fix is written to :doc:`binary restart files
+<restart>`.
+
+The :doc:`fix_modify <fix_modify>` *energy* option is supported by
+this fix to add the potential energy computed by the QM code to the
+global potential energy of the system as part of :doc:`thermodynamic
+output <thermo_style>`.  The default setting for this fix is
+:doc:`fix_modify energy yes <fix_modify>`, unless the *add* keyword is
+set to *no*, in which case the default setting is *no*.
+
+The :doc:`fix_modify <fix_modify>` *virial* option is supported by
+this fix to add the contribution computed by the QM code to the global
+pressure of the system as part of :doc:`thermodynamic output
+<thermo_style>`.  The default setting for this fix is :doc:`fix_modify
+virial yes <fix_modify>`, unless the *add* keyword is set to *no*, in
+which case the default setting is *no*.
+
+This fix computes a global scalar which can be accessed by various
+:doc:`output commands <Howto_output>`.  The scalar is the energy
+returned by the QM code.  The scalar value calculated by this fix is
+"extensive".
+
+This fix also computes a global vector with of length 6 which contains
+the symmetric virial tensor values returned by the QM code.  It can
+likewise be accessed by various :doc:`output commands <Howto_output>`.
+
+The ordering of values in the symmetric virial tensor is as follows:
+vxx, vyy, vzz, vxy, vxz, vyz.  The values will be in pressure
+:doc:`units <units>`.
+
+This fix also computes a peratom array with 3 columns which contains
+the peratom forces returned by the QM code.  It can likewise be
+accessed 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.
+
+Assuming the *add* keyword is set to *yes* (the default), the forces
+computed by the QM code are used during an energy minimization,
+invoked by the :doc:`minimize <minimize>` command.
+
+.. note::
+
+   If you want the potential energy associated with the QM forces to
+   be included in the total potential energy of the system (the
+   quantity being minimized), you MUST not disable the
+   :doc:`fix_modify <fix_modify>` *energy* option for this fix, which
+   means the *add* keyword should also be set to *yes* (the default).
+
+
+Restrictions
+""""""""""""
+
+This command is part of the MDI package.  It is only enabled if
+LAMMPS was built with that package.  See the :doc:`Build package
+<Build_package>` page for more info.
+
+The QM code does not currently compute and return per-atom energy or
+per-atom virial contributions.  So they will not show up as part of
+the calculations performed by the :doc:`compute pe/atom
+<compute_pe_atom>` or :doc:`compute stress/atom <compute_stress_atom>`
+commands.
+
+To use LAMMPS as an MDI driver in conjunction with other MDI-enabled
+codes (MD or QM codes), the :doc:`units <units>` command should be
+used to specify *real* or *metal* units.  This will ensure the correct
+unit conversions between LAMMPS and MDI units.  The other code will
+also perform similar unit conversions into its preferred units.
+
+LAMMPS can also be used as an MDI driver in other unit choices it
+supports, e.g. *lj*, but then no unit conversion is performed.
+
+Related commands
+""""""""""""""""
+
+:doc:`mdi plugin <mdi>`, :doc:`mdi engine <mdi>`
+
+Default
+"""""""
+
+The default for the optional keywords are virial = no, add = yes,
+every = 1, connect = yes.

doc/src/fix_reaxff_species.rst

@@ -20,7 +20,7 @@ Syntax
 * Nfreq = calculate average bond-order every this many timesteps
 * filename = name of output file
 * zero or more keyword/value pairs may be appended
-* keyword = *cutoff* or *element* or *position*
+* keyword = *cutoff* or *element* or *position* or *delete*
 
   .. parsed-literal::
 
@@ -31,6 +31,14 @@ Syntax
        *position* value = posfreq filepos
          posfreq = write position files every this many timestep
          filepos = name of position output file
+       *delete* value = filedel keyword value
+         filedel = name of delete species output file
+         keyword = *specieslist* or *masslimit*
+           *specieslist* value = Nspecies Species1 Species2 ...
+             Nspecies = number of species in list
+           *masslimit* value = massmin massmax
+             massmin = minimum molecular weight of species to delete
+             massmax = maximum molecular weight of species to delete
 
 Examples
 """"""""
@@ -40,6 +48,7 @@ Examples
    fix 1 all reaxff/species 10 10 100 species.out
    fix 1 all reaxff/species 1 2 20 species.out cutoff 1 1 0.40 cutoff 1 2 0.55
    fix 1 all reaxff/species 1 100 100 species.out element Au O H position 1000 AuOH.pos
+   fix 1 all reaxff/species 1 100 100 species.out delete species.del masslimit 0 50
 
 Description
 """""""""""
@@ -59,13 +68,18 @@ 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.
+   neighbor list rebuilds for at least Nrepeat\*Nevery steps preceding
+   each *Nfreq* step.  For that reason, fix *reaxff/species* may
+   change your neighbor list settings.  Reneighboring will occur no
+   more frequently than every Nrepeat\*Nevery timesteps, and will
+   occur less frequently if *Nfreq* is not a multiple of
+   Nrepeat\*Nevery.  There will be a warning message showing the new
+   settings.  Having a *Nfreq* setting that is larger than what is
+   required for correct computation of the ReaxFF force field
+   interactions, in combination with certain *Nrepeat* and *Nevery*
+   settings, can thus lead to incorrect results.  For typical ReaxFF
+   calculations, reneighboring only every 100 steps is already quite a
+   low frequency.
 
 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,
@@ -104,6 +118,30 @@ character appears in *filepos*, then one file per snapshot is written
 at *posfreq* and the "\*" character is replaced with the timestep
 value.  For example, AuO.pos.\* becomes AuO.pos.0, AuO.pos.1000, etc.
 
+The optional keyword *delete* enables the periodic removal of
+molecules from the system.  Criteria for deletion can be either a list
+of specific chemical formulae or a range of molecular weights.
+Molecules are deleted every *Nfreq* timesteps, and bond connectivity
+is determined using the *Nevery* and *Nrepeat* keywords.  The
+*filedel* argument is the name of the output file that records the
+species that are removed from the system.  The *specieslist* keyword
+permits specific chemical species to be deleted.  The *Nspecies*
+argument specifies how many species are eligible for deletion and is
+followed by a list of chemical formulae, whose strings are compared to
+species identified by this fix.  For example, "specieslist 2 CO CO2"
+deletes molecules that are identified as "CO" and "CO2" in the species
+output file.  When using the *specieslist* keyword, the *filedel* file
+has the following format: the first line lists the chemical formulae
+eligible for deletion, and each additional line contains the timestep
+on which a molecule deletion occurs and the number of each species
+deleted on that timestep.  The *masslimit* keyword permits deletion of
+molecules with molecular weights between *massmin* and *massmax*.
+When using the *masslimit* keyword, each line of the *filedel* file
+contains the timestep on which deletions occurs, followed by how many
+of each species are deleted (with quantities preceding chemical
+formulae).  The *specieslist* and *masslimit* keywords cannot both be
+used in the same *reaxff/species* fix.
+
 ----------
 
 The *Nevery*, *Nrepeat*, and *Nfreq* arguments specify on what

doc/src/if.rst

@@ -156,27 +156,28 @@ and Boolean operators:
 Each A and B is a number or string or a variable reference like $a or
 ${abc}, or A or B can be another Boolean expression.
 
-If a variable is used it can produce a number when evaluated, like an
-:doc:`equal-style variable <variable>`.  Or it can produce a string,
-like an :doc:`index-style variable <variable>`.  For an individual
-Boolean operator, A and B must both be numbers or must both be
-strings.  You cannot compare a number to a string.
+Note that all variables used will be substituted for before the
+Boolean expression in evaluated.  A variable can produce a number,
+like an :doc:`equal-style variable <variable>`.  Or it can produce a
+string, like an :doc:`index-style variable <variable>`.
+
+The Boolean operators "==" and "!=" can operate on a pair or strings
+or numbers.  They cannot compare a number to a string.  All the other
+Boolean operations can only operate on numbers.
 
 Expressions are evaluated left to right and have the usual C-style
 precedence: the unary logical NOT operator "!" has the highest
 precedence, the 4 relational operators "<", "<=", ">", and ">=" are
 next; the two remaining relational operators "==" and "!=" are next;
 then the logical AND operator "&&"; and finally the logical OR
-operator "\|\|" and logical XOR (exclusive or) operator "\|\^" have the
-lowest precedence.  Parenthesis can be used to group one or more
+operator "\|\|" and logical XOR (exclusive or) operator "\|\^" have
+the lowest precedence.  Parenthesis can be used to group one or more
 portions of an expression and/or enforce a different order of
 evaluation than what would occur with the default precedence.
 
 When the 6 relational operators (first 6 in list above) compare 2
 numbers, they return either a 1.0 or 0.0 depending on whether the
-relationship between A and B is TRUE or FALSE.  When the 6 relational
-operators compare 2 strings, they also return a 1.0 or 0.0 for TRUE or
-FALSE, but the comparison is done by the C function strcmp().
+relationship between A and B is TRUE or FALSE.
 
 When the 3 logical operators (last 3 in list above) compare 2 numbers,
 they also return either a 1.0 or 0.0 depending on whether the
@@ -190,8 +191,16 @@ returns 1.0 if its argument is 0.0, else it returns 0.0.  The 3
 logical operators can only be used to operate on numbers, not on
 strings.
 
-The overall Boolean expression produces a TRUE result if the result is
-non-zero.  If the result is zero, the expression result is FALSE.
+The overall Boolean expression produces a TRUE result if the numeric
+result is non-zero.  If the result is zero, the expression result is
+FALSE.
+
+.. note::
+
+   If the Boolean expression is a single numeric value with no Boolean
+   operators, it will be FALSE if the value = 0.0, otherwise TRUE.  If
+   the Boolean expression is a single string, an error message will be
+   issued.
 
 ----------
 

doc/src/improper_amoeba.rst

@@ -0,0 +1,77 @@
+.. index:: improper_style amoeba
+
+improper_style harmonic command
+===============================
+
+Syntax
+""""""
+
+.. code-block:: LAMMPS
+
+   improper_style amoeba
+
+Examples
+""""""""
+
+.. code-block:: LAMMPS
+
+   improper_style amoeba
+   improper_coeff 1 49.6
+
+Description
+"""""""""""
+
+The *amoeba* improper style uses the potential
+
+.. math::
+
+   E = K (\chi)^2
+
+where :math:`\chi` is the improper angle and :math:`K` is a prefactor.
+Note that the usual 1/2 factor is included in :math:`K`.
+
+This formula seems like a simplified version of the formula for the
+:doc:`improper_style harmonic <improper_harmonic>` command with
+:math:`\chi_0` = 0.0.  However the computation of the angle
+:math:`\chi` is done differently to match how the Tinker MD code
+computes its out-of-plane improper for the AMOEBA and HIPPO force
+fields.  See the :doc:`Howto amoeba <Howto_amoeba>` doc page for more
+information about the implementation of AMOEBA and HIPPO in LAMMPS.
+
+If the 4 atoms in an improper quadruplet (listed in the data file read
+by the :doc:`read_data <read_data>` command are ordered I,J,K,L then
+atoms I,K,L are considered to lie in a plane and atom J is
+out-of-place.  The angle :math:`\chi_0` is computed as the Allinger
+angle which is defined as the angle between the plane of I,K,L, and
+the vector from atom I to atom J.
+
+The following coefficient must be defined for each improper type via
+the :doc:`improper_coeff <improper_coeff>` command as in the example
+above, or in the data file or restart files read by the
+:doc:`read_data <read_data>` or :doc:`read_restart <read_restart>`
+commands:
+
+* :math:`K` (energy)
+
+Note that the angle :math:`\chi` is computed in radians; hence
+:math:`K` is effectively energy per radian\^2.
+
+----------
+
+Restrictions
+""""""""""""
+
+This improper style can only be used if LAMMPS was built with the
+AMOEBA package.  See the :doc:`Build package <Build_package>` doc page
+for more info.
+
+Related commands
+""""""""""""""""
+
+:doc:`improper_coeff <improper_coeff>`, `improper_harmonic
+:doc:<improper_harmonic>`
+
+Default
+"""""""
+
+none

doc/src/improper_style.rst

@@ -77,6 +77,7 @@ more of (g,i,k,o,t) to indicate which accelerated styles exist.
 * :doc:`zero <improper_zero>` - topology but no interactions
 * :doc:`hybrid <improper_hybrid>` - define multiple styles of improper interactions
 
+* :doc:`amoeba <improper_amoeba>` - AMOEBA out-of-plane improper
 * :doc:`class2 <improper_class2>` - COMPASS (class 2) improper
 * :doc:`cossq <improper_cossq>` - improper with a cosine squared term
 * :doc:`cvff <improper_cvff>` - CVFF improper

doc/src/kim_commands.rst

@@ -29,15 +29,16 @@ Examples
 Description
 """""""""""
 
-The *kim command* includes a set of sub-commands that allow LAMMPS users to use
-interatomic models (IM) (potentials and force fields) and their predictions for
-various physical properties archived in the
-`Open Knowledgebase of Interatomic Models (OpenKIM) <https://openkim.org>`_
-repository.
+The *kim command* includes a set of sub-commands that allow LAMMPS
+users to use interatomic models (IM) (potentials and force fields) and
+their predictions for various physical properties archived in the
+`Open Knowledgebase of Interatomic Models (OpenKIM)
+<https://openkim.org>`_ repository.
 
-Using OpenKIM provides LAMMPS users with immediate access to a large number of
-verified IMs and their predictions. OpenKIM IMs have multiple benefits including
-`reliability, reproducibility and convenience <https://openkim.org/doc/overview/kim-features/>`_.
+Using OpenKIM provides LAMMPS users with immediate access to a large
+number of verified IMs and their predictions. OpenKIM IMs have
+multiple benefits including `reliability, reproducibility and
+convenience <https://openkim.org/doc/overview/kim-features/>`_.
 
 .. _IM_types:
 

doc/src/kspace_style.rst

@@ -129,8 +129,8 @@ Examples
 
    kspace_style pppm 1.0e-4
    kspace_style pppm/cg 1.0e-5 1.0e-6
-   kspace style msm 1.0e-4
-   kspace style scafacos fmm 1.0e-4
+   kspace_style msm 1.0e-4
+   kspace_style scafacos fmm 1.0e-4
    kspace_style none
 
 Used in input scripts:
@@ -475,8 +475,8 @@ that package **and** the KSPACE package.  See the :doc:`Build package
 <Build_package>` page for more info.
 
 For MSM, a simulation must be 3d and one can use any combination of
-periodic, non-periodic, or shrink-wrapped boundaries (specified using
-the :doc:`boundary <boundary>` command).
+periodic, non-periodic, but not shrink-wrapped boundaries (specified
+using the :doc:`boundary <boundary>` command).
 
 For Ewald and PPPM, a simulation must be 3d and periodic in all
 dimensions.  The only exception is if the slab option is set with

doc/src/mdi.rst

@@ -8,21 +8,26 @@ Syntax
 
 .. parsed-literal::
 
-   mdi mode args
+   mdi option args
 
-* mode = *engine* or *plugin*
+* option = *engine* or *plugin* or *connect* or *exit*
 
   .. parsed-literal::
 
-     *engine* args = none
-     *plugin* args = name keyword value keyword value
+     *engine* args = zero or more keyword arg pairs
+       keywords = *elements*
+         *elements* args = N_1 N_2 ... N_ntypes
+           N_1,N_2,...N_ntypes = atomic number for each of ntypes LAMMPS atom types
+     *plugin* args = name keyword value keyword value ...
        name = name of plugin library, e.g. lammps means a liblammps.so library will be loaded
+       keyword/value pairs in any order, some are required, some are optional
        keywords = *mdi* or *infile* or *extra* or *command*
-         *mdi* value = args passed to MDI for driver to operate with plugins
-         *infile* value = filename the engine will read at start-up
+         *mdi* value = args passed to MDI for driver to operate with plugins (required)
+         *infile* value = filename the engine will read at start-up (optional)
          *extra* value = aditional command-line args to pass to engine library when loaded
-         *command* value = a LAMMPS input script command to execute
-
+         *command* value = a LAMMPS input script command to execute (required)
+     *connect* args = none
+     *exit* args = none
 
 Examples
 """"""""
@@ -30,26 +35,19 @@ Examples
 .. code-block:: LAMMPS
 
    mdi engine
+   mdi engine elements 13 29
    mdi plugin lammps mdi "-role ENGINE -name lammps -method LINK" &
               infile in.aimd.engine extra "-log log.aimd.engine.plugin" &
               command "run 5"
+   mdi connect
+   mdi exit
 
 Description
 """""""""""
 
-This command implements two high-level operations within LAMMPS to use
-the `MDI Library
-<https://molssi-mdi.github.io/MDI_Library/html/index.html>` for
-coupling to other codes in a client/server protocol.
-
-The *engine* mode enables LAMMPS to act as an MDI engine (server),
-responding to requests from an MDI driver (client) code.
-
-The *plugin* mode enables LAMMPS to act as an MDI driver (client), and
-load the MDI engine (server) code as a library plugin.  In this case
-the MDI engine is a library plugin.  It can also be a stand-alone
-code, launched separately from LAMMPS, in which case the mdi plugin
-command is not used.
+This command implements operations within LAMMPS to use the `MDI
+Library <https://molssi-mdi.github.io/MDI_Library/html/index.html>`
+for coupling to other codes in a client/server protocol.
 
 See the Howto MDI doc page for a discussion of all the different ways
 2 or more codes can interact via MDI.
@@ -61,6 +59,22 @@ stand-alone code or as a plugin.  The README file in that directory
 shows how to launch and couple codes for all the 4 usage modes, and so
 they communicate via the MDI library using either MPI or sockets.
 
+The scripts in that directory illustrate the use of all the options
+for this command.
+
+The *engine* option enables LAMMPS to act as an MDI engine (server),
+responding to requests from an MDI driver (client) code.
+
+The *plugin* option enables LAMMPS to act as an MDI driver (client),
+and load the MDI engine (server) code as a library plugin.  In this
+case the MDI engine is a library plugin.  An MDI engine can also be a
+stand-alone code, launched separately from LAMMPS, in which case the
+mdi plugin command is not used.
+
+The *connect* and *exit* options are only used when LAMMPS is acting
+as an MDI driver.  As explained below, these options are normally not
+needed, except for a specific kind of use case.
+
 ----------
 
 The *mdi engine* command is used to make LAMMPS operate as an MDI
@@ -100,6 +114,8 @@ commands, which are described further below.
      - Send/request charge on each atom (N values)
    * - >COORDS or <COORDS
      - Send/request coordinates of each atom (3N values)
+   * - >ELEMENTS
+     - Send elements (atomic numbers) for each atom (N values)
    * - <ENERGY
      - Request total energy (potential + kinetic) of the system (1 value)
    * - >FORCES or <FORCES
@@ -121,11 +137,11 @@ commands, which are described further below.
    * - <PE
      - Request potential energy of the system (1 value)
    * - <STRESS
-     - Request stress tensor (virial) of the system (6 values)
+     - Request symmetric stress tensor (virial) of the system (9 values)
    * - >TOLERANCE
      - Send 4 tolerance parameters for next MD minimization via OPTG command
    * - >TYPES or <TYPES
-     - Send/request the numeric type of each atom (N values)
+     - Send/request the LAMMPS atom type for each atom (N values)
    * - >VELOCITIES or <VELOCITIES
      - Send/request the velocity of each atom (3N values)
    * - @INIT_MD or @INIT_OPTG
@@ -145,9 +161,25 @@ commands, which are described further below.
    builds.  If the change in atom positions is large (since the
    previous >COORDS command), then LAMMPS will do a more expensive
    operation to migrate atoms to new processors as needed and
-   re-neighbor.  If the >NATOMS or >TYPES commands have been sent
-   (since the previous >COORDS command), then LAMMPS assumes the
-   system is new and re-initializes an entirely new simulation.
+   re-neighbor.  If the >NATOMS or >TYPES or >ELEMENTS commands have
+   been sent (since the previous >COORDS command), then LAMMPS assumes
+   the system is new and re-initializes an entirely new simulation.
+
+.. note::
+
+   The >TYPES or >ELEMENTS commands are how the MDI driver tells the
+   LAMMPS engine which LAMMPS atom type to assign to each atom.  If
+   both the MDI driver and the LAMMPS engine are initialized so that
+   atom type values are consistent in both codes, then the >TYPES
+   command can be used.  If not, the optional *elements* keyword can
+   be used to specify what element each LAMMPS atom type corresponds
+   to.  This is specified by the atomic number of the element, e.g. 13
+   for Al.  An atomic number must be specified for each of the ntypes
+   LAMMPS atom types.  Ntypes is typically specified via the
+   create_box command or in the data file read by the read_data
+   command.  In this has been done, the MDI driver can send an
+   >ELEMENTS command to the LAMMPS driver with the atomic number of
+   each atom.
 
 The MD and OPTG commands perform an entire MD simulation or energy
 minimization (to convergence) with no communication from the driver
@@ -270,7 +302,7 @@ The *command* keyword is required.  It specifies a LAMMPS input script
 command (as a single argument in quotes if it is multiple words).
 Once the plugin library is launched, LAMMPS will execute this command.
 Other previously-defined commands in the input script, such as the
-:doc:`fix mdi/aimd <fix_mdi_aimd>` command, should perform MDI
+:doc:`fix mdi/qm <fix_mdi_qm>` command, should perform MDI
 communication with the engine, while the specified *command* executes.
 Note that if *command* is an :doc:`include <include>` command, then it
 could specify a filename with multiple LAMMPS commands.
@@ -284,6 +316,31 @@ could specify a filename with multiple LAMMPS commands.
    "mdi plugin" command could then load the same library plugin or
    a different one if desired.
 
+----------
+
+The *mdi connect* and *mdi exit* commands are only used when LAMMPS is
+operating as an MDI driver.  And when other LAMMPS command(s) which
+send MDI commands and associated data to/from the MDI engine are not
+able to initiate and terminate the connection to the engine code.
+
+The only current MDI driver command in LAMMPS is the :doc:`fix mdi/qm
+<fix_mdi_qm>` command.  If it is only used once in an input script
+then it can initiate and terminate the connection.  But if it is being
+issued multiple times, e.g. in a loop that issues a :doc:`clear
+<clear>` command, then it cannot initiate or terminate the connection
+multiple times.  Instead, the *mdi connect* and *mdi exit* commands
+should be used outside the loop to initiate or terminate the connection.
+
+See the examples/mdi/in.series.driver script for an example of how
+this is done.  The LOOP in that script is reading a series of data
+file configurations and passing them to an MDI engine (e.g. quantum
+code) for energy and force evaluation.  A *clear* command inside the
+loop wipes out the current system so a new one can be defined.  This
+operation also destroys all fixes.  So the :doc:`fix mdi/qm
+<fix_mdi_qm>` command is issued once per loop iteration.  Note that it
+includes a "connect no" option which disables the initiate/terminate
+logic within that fix.
+
 
 Restrictions
 """"""""""""
@@ -304,7 +361,7 @@ supports, e.g. *lj*, but then no unit conversion is performed.
 Related commands
 """"""""""""""""
 
-:doc:`fix mdi/aimd <fix_mdi_aimd>`
+:doc:`fix mdi/qm <fix_mdi_qm>`
 
 Default
 """""""

doc/src/min_style.rst

@@ -4,7 +4,7 @@ min_style cg command
 ====================
 
 min_style hftn command
-====================
+======================
 
 min_style sd command
 ====================

doc/src/neighbor.rst

@@ -49,29 +49,27 @@ sometimes be faster.  Either style should give the same answers.
 
 The *multi* style is a modified binning algorithm that is useful for
 systems with a wide range of cutoff distances, e.g. due to different
-size particles. For granular pair styles, cutoffs are set to the
-sum of the maximum atomic radii for each atom type.
-For the *bin* style, the bin size is set to 1/2 of
-the largest cutoff distance between any pair of atom types and a
-single set of bins is defined to search over for all atom types.  This
-can be inefficient if one pair of types has a very long cutoff, but
-other type pairs have a much shorter cutoff. The *multi* style uses
-different sized bins for collections of different sized particles, where
-"size" may mean the physical size of the particle or its cutoff
-distance for interacting with other particles. Different
+size particles. For granular pair styles, cutoffs are set to the sum of
+the maximum atomic radii for each atom type.  For the *bin* style, the
+bin size is set to 1/2 of the largest cutoff distance between any pair
+of atom types and a single set of bins is defined to search over for all
+atom types.  This can be inefficient if one pair of types has a very
+long cutoff, but other type pairs have a much shorter cutoff. The
+*multi* style uses different sized bins for collections of different
+sized particles, where "size" may mean the physical size of the particle
+or its cutoff distance for interacting with other particles. Different
 sets of bins are then used to construct the neighbor lists as as further
 described by Shire, Hanley, and Stratford :ref:`(Shire) <bytype-Shire>`.
-This imposes some extra setup overhead, but the searches themselves
-may be much faster. By default, each atom type defines a separate
-collection of particles. For systems where two or more atom types
-have the same size (either physical size or cutoff distance), the
-definition of collections can be customized, which can result in less
-overhead and faster performance. See the :doc:`neigh_modify <neigh_modify>`
-command for how to define custom collections. Whether the collection
-definition is customized or not, also see the
-:doc:`comm_modify mode multi <comm_modify>` command for communication
-options that further improve performance in a manner consistent with
-neighbor style multi.
+This imposes some extra setup overhead, but the searches themselves may
+be much faster. By default, each atom type defines a separate collection
+of particles. For systems where two or more atom types have the same
+size (either physical size or cutoff distance), the definition of
+collections can be customized, which can result in less overhead and
+faster performance. See the :doc:`neigh_modify <neigh_modify>` command
+for how to define custom collections. Whether the collection definition
+is customized or not, also see the :doc:`comm_modify mode multi
+<comm_modify>` command for communication options that further improve
+performance in a manner consistent with neighbor style multi.
 
 An alternate style, *multi/old*, sets the bin size to 1/2 of the shortest
 cutoff distance and multiple sets of bins are defined to search over for
@@ -80,6 +78,16 @@ algorithm in LAMMPS but was found to be significantly slower than the new
 approach. For now we are keeping the old option in case there are use cases
 where multi/old outperforms the new multi style.
 
+.. note::
+
+   If there are multiple sub-styles in a :doc:`hybrid/overlay pair style
+   <pair_hybrid>` that cover the same atom types, but have significantly
+   different cutoffs, the *multi* style does not apply.  Instead, the
+   :doc:`pair_modify neigh/trim <pair_modify>` setting applies (which is
+   *yes* by default).  Please check the neighbor list summary printed at
+   the beginning of a calculation to verify that the desired set of
+   neighbor list builds is performed.
+
 
 The :doc:`neigh_modify <neigh_modify>` command has additional options
 that control how often neighbor lists are built and which pairs are

doc/src/package.rst

@@ -71,7 +71,7 @@ Syntax
            *no_affinity* values = none
        *kokkos* args = keyword value ...
          zero or more keyword/value pairs may be appended
-         keywords = *neigh* or *neigh/qeq* or *neigh/thread* or *newton* or *binsize* or *comm* or *comm/exchange* or *comm/forward* *comm/pair/forward* *comm/fix/forward* or *comm/reverse* or *gpu/aware* or *pair/only*
+         keywords = *neigh* or *neigh/qeq* or *neigh/thread* or *newton* or *binsize* or *comm* or *comm/exchange* or *comm/forward* *comm/pair/forward* *comm/fix/forward* or *comm/reverse* or *comm/pair/reverse* or *gpu/aware* or *pair/only*
            *neigh* value = *full* or *half*
              full = full neighbor list
              half = half neighbor list built in thread-safe manner
@@ -96,6 +96,7 @@ Syntax
            *comm/pair/forward* value = *no* or *device*
            *comm/fix/forward* value = *no* or *device*
            *comm/reverse* value = *no* or *host* or *device*
+           *comm/pair/reverse* value = *no* or *device*
              no = perform communication pack/unpack in non-KOKKOS mode
              host = perform pack/unpack on host (e.g. with OpenMP threading)
              device = perform pack/unpack on device (e.g. on GPU)
@@ -500,7 +501,7 @@ rule of thumb may give too large a binsize and the default should be
 overridden with a smaller value.
 
 The *comm* and *comm/exchange* and *comm/forward* and *comm/pair/forward*
-and *comm/fix/forward* and comm/reverse*
+and *comm/fix/forward* and *comm/reverse* and *comm/pair/reverse*
 keywords determine whether the host or device performs the packing and
 unpacking of data when communicating per-atom data between processors.
 "Exchange" communication happens only on timesteps that neighbor lists
@@ -521,9 +522,16 @@ packing/unpacking data for the communication. A value of *host* means to
 use the host, typically a multi-core CPU, and perform the
 packing/unpacking in parallel with threads. A value of *device* means to
 use the device, typically a GPU, to perform the packing/unpacking
-operation. If a value of *host* is used for the *comm/pair/forward* or
-*comm/fix/forward* keyword, it will be automatically be changed to *no*
-since these keywords don't support *host* mode.
+operation.
+
+For the *comm/pair/forward* or *comm/fix/forward* or *comm/pair/reverse*
+keywords, if a value of *host* is used it will be automatically
+be changed to *no* since these keywords don't support *host* mode. The
+value of *no* will also always be used when running on the CPU, i.e. setting
+the value to *device* will have no effect if the pair/fix style is
+running on the CPU. For the *comm/fix/forward* or *comm/pair/reverse*
+keywords, not all styles support *device* mode and in that case will run
+in *no* mode instead.
 
 The optimal choice for these keywords depends on the input script and
 the hardware used. The *no* value is useful for verifying that the

doc/src/pair_amoeba.rst

@@ -0,0 +1,253 @@
+.. index:: pair_style amoeba
+.. index:: pair_style hippo
+
+pair_style amoeba command
+=========================
+
+pair_style hippo command
+========================
+Syntax
+""""""
+
+.. code-block:: LAMMPS
+
+   pair_style style
+
+* style = *amoeba* or *hippo*
+
+Examples
+""""""""
+
+.. code-block:: LAMMPS
+
+   pair_style amoeba
+   pair_coeff * * protein.prm.amoeba protein.key.amoeba
+
+.. code-block:: LAMMPS
+
+   pair_style hippo
+   pair_coeff * * water.prm.hippo water.key.hippo
+
+
+Additional info
+"""""""""""""""
+
+* :doc:`Howto amoeba <Howto_amoeba>`
+* examples/amoeba
+* tools/amoeba
+* potentials/\*.amoeba
+* potentials/\*.hippo
+
+Description
+"""""""""""
+
+The *amoeba* style computes the AMOEBA polarizable field formulated
+by Jay Ponder's group at the U Washington at St Louis :ref:`(Ren)
+<amoeba-Ren>`, :ref:`(Shi) <amoeba-Shi>`.  The *hippo* style computes
+the HIPPO polarizable force field, an extension to AMOEBA, formulated
+by Josh Rackers and collaborators in the Ponder group :ref:`(Rackers)
+<amoeba-Rackers>`.
+
+These force fields can be used when polarization effects are desired
+in simulations of water, organic molecules, and biomolecules including
+proteins, provided that parameterizations (Tinker PRM force field
+files) are available for the systems you are interested in.  Files in
+the LAMMPS potentials directory with a "amoeba" or "hippo" suffix can
+be used.  The Tinker distribution and website have additional force
+field files as well.
+
+As discussed on the :doc:`Howto amoeba <Howto_amoeba>` doc page, the
+intermolecular (non-bonded) portion of the AMOEBA force field contains
+these terms:
+
+.. math::
+
+   U_{amoeba} = U_{multipole} + U_{polar} + U_{hal}
+
+while the HIPPO force field contains these terms:
+
+.. math::
+
+   U_{hippo} = U_{multipole} + U_{polar} + U_{qxfer} + U_{repulsion} + U_{dispersion}
+
+Conceptually, these terms compute the following interactions:
+
+* :math:`U_{hal}` = buffered 14-7 van der Waals with offsets applied to hydrogen atoms
+* :math:`U_{repulsion}` = Pauli repulsion due to rearrangement of electron density
+* :math:`U_{dispersion}` = dispersion between correlated, instantaneous induced dipole moments
+* :math:`U_{multipole}` = electrostatics between permanent point charges, dipoles, and quadrupoles
+* :math:`U_{polar}` = electronic polarization between induced point dipoles
+* :math:`U_{qxfer}` = charge transfer effects
+
+Note that the AMOEBA versus HIPPO force fields typically compute the
+same term differently using their own formulas.  The references on
+this doc page give full details for both force fields.
+
+The formulas for the AMOEBA energy terms are:
+
+.. math::
+
+   U_{hal} = \epsilon_{ij} \left( \frac{1.07}{\rho_{ij} + 0.07} \right)^7 \left( \frac{1.12}{\rho_{ij}^7 + 0.12} - 2 \right)
+   U_{multipole} = \vec{M_i}\bold{T_{ij}}\vec{M_j}
+      \vec{M} = \left( q, \vec{\mu_{perm}}, \bold{\Theta} \right)
+   U_{polar} = \frac{1}{2}\vec{\mu_i}^{ind} \vec{E_i}^{perm}
+
+The formulas for the HIPPO energy terms are:
+
+.. math::
+
+   U_{multipole} = Z_i \frac{1}{r_{ij}} Z_j + Z_i T_{ij}^{damp} \vec{M_j} + Z_j T_{ji}^{damp} \vec{M_i} + \vec{M_i} T_{ij}^{damp} \vec{M_j}
+      \vec{M} = \left( Q, \vec{\mu_{perm}}, \bold{\Theta} \right)
+   U_{polar} = \frac{1}{2}\vec{\mu_i}^{ind} \vec{E_i}^{perm}
+   U_{qxfer} = \epsilon_i e^{-\eta_j r_{ij}} + \epsilon_j e^{-\eta_i r_{ij}}
+   U_{repulsion} = \frac{K_i K_j}{r_{ij}} S^2
+      S^2 = \left( \int{\phi_i \phi_j} dv \right)^2 = \vec{M_i}\bold{T_{ij}^{repulsion}}\vec{M_j}
+   U_{dispersion} = -\frac{C_6^iC_6^j}{r_{ij}^6} \left( f_{damp}^{dispersion} \right)_{ij}^2
+
+.. note::
+
+  The AMOEBA and HIPPO force fields compute long-range charge, dipole,
+  and quadrupole interactions as well as long-range dispersion
+  effects.  However, unlike other models with long-range interactions
+  in LAMMPS, this does not require use of a KSpace style via the
+  :doc:`kspace_style <kspace_style>` command.  That is because for
+  AMOEBA and HIPPO the long-range computations are intertwined with
+  the pairwise computations.  So these pair style include both short-
+  and long-range computations.  This means the energy and virial
+  computed by the pair style as well as the "Pair" timing reported by
+  LAMMPS will include the long-range calculations.
+
+The implementation of the AMOEBA and HIPPO force fields in LAMMPS was
+done using F90 code provided by the Ponder group from their `Tinker MD
+code <https://dasher.wustl.edu/tinker/>`_.
+
+The current implementation (July 2022) of AMOEBA in LAMMPS matches the
+version discussed in :ref:`(Ponder) <amoeba-Ponder>`, :ref:`(Ren)
+<amoeba-Ren>`, and :ref:`(Shi) <amoeba-Shi>`.  Likewise the current
+implementation of HIPPO in LAMMPS matches the version discussed in
+:ref:`(Rackers) <amoeba-Rackers>`.
+
+----------
+
+Only a single pair_coeff command is used with either the *amoeba* and
+*hippo* styles which specifies two Tinker files, a PRM and KEY file.
+
+.. code-block:: LAMMPS
+
+   pair_coeff * * ../potentials/protein.prm.amoeba ../potentials/protein.key.amoeba
+   pair_coeff * * ../potentials/water.prm.hippo ../potentials/water.key.hippo
+
+Examples of the PRM files are in the potentials directory with an
+\*.amoeba or \*.hippo suffix.  The examples/amoeba directory has
+examples of both PRM and KEY files.
+
+A Tinker PRM file is composed of sections, each of which has multiple
+lines.  A Tinker KEY file is composed of lines, each of which has a
+keyword followed by zero or more parameters.
+
+The list of PRM sections and KEY keywords which LAMMPS recognizes are
+listed on the :doc:`Howto amoeba <Howto_amoeba>` doc page.  If not
+recognized, the section or keyword is skipped.
+
+Note that if the KEY file is specified as NULL, then no file is
+required; default values for various AMOEBA/HIPPO settings are used.
+The :doc:`Howto amoeba <Howto_amoeba>` doc page also gives the default
+settings.
+
+----------
+
+Mixing, shift, table, tail correction, restart, rRESPA info
+"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
+
+These pair styles do not support the :doc:`pair_modify <pair_modify>`
+mix, shift, table, and tail options.
+
+These pair styles do not write their information to :doc:`binary
+restart files <restart>`, since it is stored in potential files.
+Thus, you need to re-specify the pair_style and pair_coeff commands in
+an input script that reads a restart file.
+
+These pair styles can only be used via the *pair* keyword of the
+:doc:`run_style respa <run_style>` command.  They do not support the
+*inner*\ , *middle*\ , *outer* keywords.
+
+----------
+
+Restrictions
+""""""""""""
+
+These pair styles are part of the AMOEBA package.  They are only
+enabled if LAMMPS was built with that package.  See the :doc:`Build
+package <Build_package>` doc page for more info.
+
+The AMOEBA and HIPPO potential (PRM) and KEY files provided with
+LAMMPS in the potentials and examples/amoeba directories are Tinker
+files parameterized for Tinker units.  Their numeric parameters are
+converted by LAMMPS to its real units :doc:`units <units>`.  Thus you
+can only use these pair styles with real units.
+
+These potentials do not yet calculate per-atom energy or virial
+contributions.
+
+As explained on the :doc:`AMOEBA and HIPPO howto <Howto_amoeba>` page,
+use of these pair styles to run a simulation with the AMOEBA or HIPPO
+force fields requires several things.
+
+The first is a data file generated by the tools/tinker/tinker2lmp.py
+conversion script which uses Tinker file force field file input to
+create a data file compatible with LAMMPS.
+
+The second is use of these commands:
+
+* :doc:`atom_style amoeba <atom_style>`
+* :doc:`fix property/atom <fix_property_atom>`
+* :doc:`special_bonds one/five <special_bonds>`
+
+And third, depending on the model being simulated, these
+commands for intramolecular interactions may also be required:
+
+* :doc:`bond_style class2 <bond_class2>`
+* :doc:`angle_style amoeba <angle_amoeba>`
+* :doc:`dihedral_style fourier <dihedral_fourier>`
+* :doc:`improper_style amoeba <improper_amoeba>`
+* :doc:`fix amoeba/pitorsion <fix_amoeba_pitorsion>`
+* :doc:`fix amoeba/bitorsion <fix_amoeba_bitorsion>`
+
+----------
+
+Related commands
+""""""""""""""""
+
+:doc:`atom_style amoeba <atom_style>`,
+:doc:`bond_style class2 <bond_class2>`,
+:doc:`angle_style amoeba <angle_amoeba>`,
+:doc:`dihedral_style fourier <dihedral_fourier>`,
+:doc:`improper_style amoeba <improper_amoeba>`,
+:doc:`fix amoeba/pitorsion <fix_amoeba_pitorsion>`,
+:doc:`fix amoeba/bitorsion <fix_amoeba_bitorsion>`,
+:doc:`special_bonds one/five <special_bonds>`,
+:doc:`fix property/atom <fix_property_atom>`
+
+Default
+"""""""
+
+none
+
+----------
+
+.. _amoeba-Ponder:
+
+**(Ponder)** Ponder, Wu, Ren, Pande, Chodera, Schnieders, Haque, Mobley, Lambrecht, DiStasio Jr, M. Head-Gordon, Clark, Johnson, T. Head-Gordon, J Phys Chem B, 114, 2549-2564 (2010).
+
+.. _amoeba-Rackers:
+
+**(Rackers)** Rackers, Silva, Wang, Ponder, J Chem Theory Comput, 17, 7056-7084 (2021).
+
+.. _amoeba-Ren:
+
+**(Ren)** Ren and Ponder, J Phys Chem B, 107, 5933 (2003).
+
+.. _amoeba-Shi:
+
+**(Shi)** Shi, Xia, Zhang, Best, Wu, Ponder, Ren, J Chem Theory Comp, 9, 4046, 2013.
+

doc/src/pair_e3b.rst

@@ -50,6 +50,12 @@ Examples
    pair_style hybrid/overlay e3b 1 lj/cut/tip4p/long 1 2 1 1 0.15 8.5
    pair_coeff * * e3b preset 2011
 
+Used in example input script:
+
+.. parsed-literal::
+
+   examples/PACKAGES/e3b/in.e3b-tip4p2005
+
 Description
 """""""""""
 
@@ -68,21 +74,27 @@ The *e3b* style computes an \"explicit three-body\" (E3B) potential for water :r
    0 & r>R_f\\
    \end{cases}
 
-This potential was developed as a water model that includes the three-body cooperativity of hydrogen bonding explicitly.
-To use it in this way, it must be applied in conjunction with a conventional two-body water model, through *pair_style hybrid/overlay*.
-The three body interactions are split into three types: A, B, and C.
-Type A corresponds to anti-cooperative double hydrogen bond donor interactions.
-Type B corresponds to the cooperative interaction of molecules that both donate and accept a hydrogen bond.
-Type C corresponds to anti-cooperative double hydrogen bond acceptor interactions.
-The three-body interactions are smoothly cutoff by the switching function s(r) between Rs and Rc3.
-The two-body interactions are designed to correct for the effective many-body interactions implicitly included in the conventional two-body potential.
-The two-body interactions are cut off sharply at Rc2, because K3 is typically significantly smaller than K2.
-See :ref:`(Kumar 2008) <Kumar>` for more details.
+This potential was developed as a water model that includes the
+three-body cooperativity of hydrogen bonding explicitly.  To use it in
+this way, it must be applied in conjunction with a conventional two-body
+water model, through pair style :doc:`hybrid/overlay <pair_hybrid>`.  The
+three body interactions are split into three types: A, B, and C.  Type A
+corresponds to anti-cooperative double hydrogen bond donor interactions.
+Type B corresponds to the cooperative interaction of molecules that both
+donate and accept a hydrogen bond.  Type C corresponds to
+anti-cooperative double hydrogen bond acceptor interactions.  The
+three-body interactions are smoothly cutoff by the switching function
+s(r) between Rs and Rc3.  The two-body interactions are designed to
+correct for the effective many-body interactions implicitly included in
+the conventional two-body potential.  The two-body interactions are cut
+off sharply at Rc2, because K3 is typically significantly smaller than
+K2.  See :ref:`(Kumar 2008) <Kumar>` for more details.
 
-Only a single *pair_coeff* command is used with the *e3b* style.
-The first two arguments must be \* \*.
-The oxygen atom type for the pair style is passed as the only argument to the *pair_style* command, not in the *pair_coeff* command.
-The hydrogen atom type is inferred by the ordering of the atoms.
+Only a single :doc:`pair_coeff <pair_coeff>` command is used with the
+*e3b* style and the first two arguments must be \* \*.  The oxygen atom
+type for the pair style is passed as the only argument to the
+*pair_style* command, not in the *pair_coeff* command.  The hydrogen
+atom type is inferred from the ordering of the atoms.
 
 .. note::
 
@@ -90,26 +102,41 @@ The hydrogen atom type is inferred by the ordering of the atoms.
    Each water molecule must have consecutive IDs with the oxygen first.
    This pair style does not test that this criteria is met.
 
-The *pair_coeff* command must have at least one keyword/value pair, as described above.
-The *preset* keyword sets the potential parameters to the values used in :ref:`(Tainter 2011) <Tainter2011>` or :ref:`(Tainter 2015) <Tainter2015>`.
-To use the water models defined in those references, the *e3b* style should always be used in conjunction with an *lj/cut/tip4p/long* style through *pair_style hybrid/overlay*, as demonstrated in the second example above.
-The *preset 2011* option should be used with the :doc:`TIP4P water model <Howto_tip4p>`.
-The *preset 2015* option should be used with the :doc:`TIP4P/2005 water model <Howto_tip4p>`.
-If the *preset* keyword is used, no other keyword is needed.
-Changes to the preset parameters can be made by specifying the *preset* keyword followed by the specific parameter to change, like *Ea*\ .
-Note that the other keywords must come after *preset* in the pair_style command.
-The *e3b* style can also be used to implement any three-body potential of the same form by specifying all the keywords except *neigh*\ : *Ea*, *Eb*, *Ec*, *E2*, *K3*, *K2*, *Rc3*, *Rc2*, *Rs*, and *bondL*\ .
-The keyword *bondL* specifies the intramolecular OH bond length of the water model being used.
-This is needed to include H atoms that are within the cutoff even when the attached oxygen atom is not.
+The *pair_coeff* command must have at least one keyword/value pair, as
+described above.  The *preset* keyword sets the potential parameters to
+the values used in :ref:`(Tainter 2011) <Tainter2011>` or
+:ref:`(Tainter 2015) <Tainter2015>`.  To use the water models defined in
+those references, the *e3b* style should always be used in conjunction
+with an *lj/cut/tip4p/long* style through *pair_style hybrid/overlay*,
+as demonstrated in the second example above.  The *preset 2011* option
+should be used with the :doc:`TIP4P water model <Howto_tip4p>`.  The
+*preset 2015* option should be used with the :doc:`TIP4P/2005 water
+model <Howto_tip4p>`.  If the *preset* keyword is used, no other keyword
+is needed.  Changes to the preset parameters can be made by specifying
+the *preset* keyword followed by the specific parameter to change, like
+*Ea*\ .  Note that the other keywords must come after *preset* in the
+pair_style command.  The *e3b* style can also be used to implement any
+three-body potential of the same form by specifying all the keywords
+except *neigh*\ : *Ea*, *Eb*, *Ec*, *E2*, *K3*, *K2*, *Rc3*, *Rc2*,
+*Rs*, and *bondL*\ .  The keyword *bondL* specifies the intramolecular
+OH bond length of the water model being used.  This is needed to include
+H atoms that are within the cutoff even when the attached oxygen atom is
+not.
 
-This pair style allocates arrays sized according to the number of pairwise interactions within Rc3.
-To do this it needs an estimate for the number of water molecules within Rc3 of an oxygen atom.
-This estimate defaults to 10 and can be changed using the *neigh* keyword, which takes an integer as an argument.
-If the neigh setting is too small, the simulation will fail with the error "neigh is too small".
-If the neigh setting is too large, the pair style will use more memory than necessary.
+This pair style allocates arrays sized according to the number of
+pairwise interactions within Rc3.  To do this it needs an estimate for
+the number of water molecules within Rc3 of an oxygen atom.  This
+estimate defaults to 10 and can be changed using the *neigh* keyword,
+which takes an integer as an argument.  If the neigh setting is too
+small, the simulation will fail with the error "neigh is too small".  If
+the neigh setting is too large, the pair style will use more memory than
+necessary.
 
-This pair style tallies a breakdown of the total E3B potential energy into sub-categories, which can be accessed via the :doc:`compute pair <compute_pair>` command as a vector of values of length 4.
-The 4 values correspond to the terms in the first equation above: the E2 term, the Ea term, the Eb term, and the Ec term.
+This pair style tallies a breakdown of the total E3B potential energy
+into sub-categories, which can be accessed via the :doc:`compute pair
+<compute_pair>` command as a vector of values of length 4.  The 4 values
+correspond to the terms in the first equation above: the E2 term, the Ea
+term, the Eb term, and the Ec term.
 
 See the examples/PACKAGES/e3b directory for a complete example script.
 

doc/src/pair_meam.rst

@@ -1,8 +1,11 @@
 .. index:: pair_style meam
+.. index:: pair_style meam/kk
 
 pair_style meam command
 =========================
 
+Accelerator Variants: *meam/kk*
+
 Syntax
 """"""
 
@@ -347,6 +350,12 @@ Most published MEAM parameter sets use the default values *attrac* = *repulse* =
 Setting *repuls* = *attrac* = *delta* corresponds to the form used in several
 recent published MEAM parameter sets, such as :ref:`(Valone) <Valone>`
 
+----------
+
+.. include:: accel_styles.rst
+
+----------
+
 .. note::
 
    The default form of the *erose* expression in LAMMPS was corrected

doc/src/pair_modify.rst

@@ -13,7 +13,7 @@ Syntax
 * one or more keyword/value pairs may be listed
 * keyword = *pair* or *shift* or *mix* or *table* or *table/disp* or *tabinner*
   or *tabinner/disp* or *tail* or *compute* or *nofdotr* or *special* or
-  *compute/tally*
+  *compute/tally* or *neigh/trim*
 
   .. parsed-literal::
 
@@ -37,6 +37,7 @@ Syntax
           which = *lj/coul* or *lj* or *coul*
           w1,w2,w3 = 1-2, 1-3, 1-4 weights from 0.0 to 1.0 inclusive
        *compute/tally* value = *yes* or *no*
+       *neigh/trim* value = *yes* or *no*
 
 Examples
 """"""""
@@ -283,6 +284,31 @@ the *pair* keyword.  Use *no* to disable, or *yes* to enable.
    The "pair_modify pair compute/tally" command must be issued
    **before** the corresponding compute style is defined.
 
+The *neigh/trim* keyword controls whether an explicit cutoff is set for
+each neighbor list request issued by individual pair sub-styles when
+using :doc:`pair hybrid/overlay <pair_hybrid>`.  When this keyword is
+set to *no*, then the cutoff of each pair sub-style neighbor list will
+be set equal to the largest cutoff, even if a shorter cutoff is
+specified for a particular sub-style.  If possible the neighbor list
+will be copied directly from another list.  When this keyword is set to
+*yes* then the cutoff of the neighbor list will be explicitly set to the
+value requested by the pair sub-style, and if possible the list will be
+created by trimming neighbors from another list with a longer cutoff,
+otherwise a new neighbor list will be created with the specified cutoff.
+The *yes* option can be faster when there are multiple pair styles with
+different cutoffs since the number of pair-wise distance checks between
+neighbors is reduced (but the time required to build the neighbor lists
+is increased). The *no* option could be faster when two or more neighbor
+lists have similar (but not exactly the same) cutoffs.
+
+.. note::
+
+   The "pair_modify neigh/trim" command *only* applies when there are
+   multiple pair sub-styles for the same atoms with different cutoffs,
+   i.e. when using pair style hybrid/overlay.  If you have different
+   cutoffs for different pairs for atoms type, the :doc:`neighbor style
+   multi <neighbor>` should be used to create optimized neighbor lists.
+
 ----------
 
 Restrictions
@@ -298,13 +324,13 @@ Related commands
 
 :doc:`pair_style <pair_style>`, :doc:`pair_style hybrid <pair_hybrid>`,
 :doc:`pair_coeff <pair_coeff>`, :doc:`thermo_style <thermo_style>`,
-:doc:`compute \*/tally <compute_tally>`
+:doc:`compute \*/tally <compute_tally>`, :doc:`neighbor multi <neighbor>`
 
 Default
 """""""
 
 The option defaults are mix = geometric, shift = no, table = 12,
-tabinner = sqrt(2.0), tail = no, and compute = yes.
+tabinner = sqrt(2.0), tail = no, compute = yes, and neigh/trim yes.
 
 Note that some pair styles perform mixing, but only a certain style of
 mixing.  See the doc pages for individual pair styles for details.

doc/src/pair_none.rst

@@ -20,28 +20,37 @@ Examples
 Description
 """""""""""
 
-Using a pair style of none means pair forces and energies are not
-computed.
+Using a pair style of *none* means that any previous pair style setting
+will be deleted and pairwise forces and energies are not computed.
 
-With this choice, the force cutoff is 0.0, which means that only atoms
-within the neighbor skin distance (see the :doc:`neighbor <neighbor>`
-command) are communicated between processors.  You must insure the
-skin distance is large enough to acquire atoms needed for computing
-bonds, angles, etc.
+As a consequence there will be a pairwise force cutoff of 0.0, which has
+implications for the default setting of the neighbor list and the
+communication cutoff.  Those are the sum of the largest pairwise cutoff
+and the neighbor skin distance (see the documentation of the
+:doc:`neighbor <neighbor>` command and the :doc:`comm_modify
+<comm_modify>` command).  When you have bonds, angles, dihedrals, or
+impropers defined at the same time, you must set the communication
+cutoff so that communication cutoff distance is large enough to acquire
+and communicate sufficient ghost atoms from neighboring sub-domains as
+needed for computing bonds, angles, etc.
 
-A pair style of *none* will also prevent pairwise neighbor lists from
-being built.  However if the :doc:`neighbor <neighbor>` style is *bin*,
-data structures for binning are still allocated.  If the neighbor skin
-distance is small, then these data structures can consume a large
-amount of memory.  So you should either set the neighbor style to
-*nsq* or set the skin distance to a larger value.
+A pair style of *none* will also not request a pairwise neighbor list.
+However if the :doc:`neighbor <neighbor>` style is *bin*, data
+structures for binning are still allocated.  If the neighbor list cutoff
+is small, then these data structures can consume a large amount of
+memory.  So you should either set the neighbor style to *nsq* or set the
+skin distance to a larger value.
 
-See the :doc:`pair_style zero <pair_zero>` for a way to trigger the
-building of a neighbor lists, but compute no pairwise interactions.
+See the :doc:`pair_style zero <pair_zero>` for a way to set a pairwise
+cutoff and thus trigger the building of a neighbor lists and setting
+a corresponding communication cutoff, but compute no pairwise interactions.
 
 Restrictions
 """"""""""""
-none
+
+You must not use a :doc:`pair_coeff <pair_coeff>` command with this pair
+style.  Since there is no interaction computed, you cannot set any
+coefficients for it.
 
 Related commands
 """"""""""""""""

doc/src/pair_style.rst

@@ -116,6 +116,7 @@ accelerated styles exist.
 * :doc:`agni <pair_agni>` - AGNI machine-learning potential
 * :doc:`airebo <pair_airebo>` - AIREBO potential of Stuart
 * :doc:`airebo/morse <pair_airebo>` - AIREBO with Morse instead of LJ
+* :doc:`amoeba <pair_amoeba>` -
 * :doc:`atm <pair_atm>` - Axilrod-Teller-Muto potential
 * :doc:`awpmd/cut <pair_awpmd>` - Antisymmetrized Wave Packet MD potential for atoms and electrons
 * :doc:`beck <pair_beck>` - Beck potential
@@ -202,6 +203,7 @@ accelerated styles exist.
 * :doc:`hbond/dreiding/lj <pair_hbond_dreiding>` - DREIDING hydrogen bonding LJ potential
 * :doc:`hbond/dreiding/morse <pair_hbond_dreiding>` - DREIDING hydrogen bonding Morse potential
 * :doc:`hdnnp <pair_hdnnp>` - High-dimensional neural network potential
+* :doc:`hippo <pair_amoeba>` -
 * :doc:`ilp/graphene/hbn <pair_ilp_graphene_hbn>` - registry-dependent interlayer potential (ILP)
 * :doc:`ilp/tmd <pair_ilp_tmd>` - interlayer potential (ILP) potential for transition metal dichalcogenides (TMD)
 * :doc:`kim <pair_kim>` - interface to potentials provided by KIM project
@@ -348,6 +350,7 @@ accelerated styles exist.
 * :doc:`spin/neel <pair_spin_neel>` -
 * :doc:`srp <pair_srp>` -
 * :doc:`sw <pair_sw>` - Stillinger-Weber 3-body potential
+* :doc:`sw/angle/table <pair_sw_angle_table>` - Stillinger-Weber potential with tabulated angular term
 * :doc:`sw/mod <pair_sw>` - modified Stillinger-Weber 3-body potential
 * :doc:`table <pair_table>` - tabulated pair potential
 * :doc:`table/rx <pair_table_rx>` -
@@ -358,6 +361,7 @@ accelerated styles exist.
 * :doc:`tersoff/table <pair_tersoff>` -
 * :doc:`tersoff/zbl <pair_tersoff_zbl>` - Tersoff/ZBL 3-body potential
 * :doc:`thole <pair_thole>` - Coulomb interactions with thole damping
+* :doc:`threebody/table <pair_threebody_table>` - generic tabulated three-body potential
 * :doc:`tip4p/cut <pair_coul>` - Coulomb for TIP4P water w/out LJ
 * :doc:`tip4p/long <pair_coul>` - long-range Coulomb for TIP4P water w/out LJ
 * :doc:`tip4p/long/soft <pair_fep_soft>` -

doc/src/pair_sw.rst

@@ -24,13 +24,16 @@ Syntax
    pair_style style keyword values
 
 * style = *sw* or *sw/mod*
-* keyword = *maxdelcs*
+* keyword = *maxdelcs* or *threebody*
 
   .. parsed-literal::
 
-       *maxdelcs* value = delta1 delta2 (optional)
+       *maxdelcs* value = delta1 delta2 (optional, sw/mod only)
          delta1 = The minimum thershold for the variation of cosine of three-body angle
          delta2 = The maximum threshold for the variation of cosine of three-body angle
+       *threebody* value = *on* or *off* (optional, sw only)
+         on (default) = Compute both the three-body and two-body terms of the potential
+         off = Compute only the two-body term of the potential
 
 Examples
 """"""""
@@ -44,6 +47,11 @@ Examples
    pair_style sw/mod maxdelcs 0.25 0.35
    pair_coeff * * tmd.sw.mod Mo S S
 
+   pair_style hybrid sw threebody on sw threebody off
+   pair_coeff * * sw 1 mW_xL.sw mW NULL
+   pair_coeff 1 2 sw 2 mW_xL.sw mW xL
+   pair_coeff 2 2 sw 2 mW_xL.sw mW xL
+
 Description
 """""""""""
 
@@ -68,22 +76,25 @@ three-body term.  The summations in the formula are over all neighbors J
 and K of atom I within a cutoff distance :math:`a `\sigma`.
 
 The *sw/mod* style is designed for simulations of materials when
-distinguishing three-body angles are necessary, such as borophene
-and transition metal dichalcogenides, which cannot be described
-by the original code for the Stillinger-Weber potential.
-For instance, there are several types of angles around each Mo atom in `MoS_2`,
-and some unnecessary angle types should be excluded in the three-body interaction.
-Such exclusion may be realized by selecting proper angle types directly.
-The exclusion of unnecessary angles is achieved here by the cut-off function (`f_C(\delta)`),
-which induces only minimum modifications for LAMMPS.
+distinguishing three-body angles are necessary, such as borophene and
+transition metal dichalcogenides, which cannot be described by the
+original code for the Stillinger-Weber potential.  For instance, there
+are several types of angles around each Mo atom in `MoS_2`, and some
+unnecessary angle types should be excluded in the three-body
+interaction.  Such exclusion may be realized by selecting proper angle
+types directly.  The exclusion of unnecessary angles is achieved here by
+the cut-off function (`f_C(\delta)`), which induces only minimum
+modifications for LAMMPS.
 
 Validation, benchmark tests, and applications of the *sw/mod* style
 can be found in :ref:`(Jiang2) <Jiang2>` and :ref:`(Jiang3) <Jiang3>`.
 
-The *sw/mod* style computes the energy E of a system of atoms, whose potential
-function is mostly the same as the Stillinger-Weber potential. The only modification
-is in the three-body term, where the value of :math:`\delta = \cos \theta_{ijk} - \cos \theta_{0ijk}`
-used in the original energy and force expression is scaled by a switching factor :math:`f_C(\delta)`:
+The *sw/mod* style computes the energy E of a system of atoms, whose
+potential function is mostly the same as the Stillinger-Weber
+potential. The only modification is in the three-body term, where the
+value of :math:`\delta = \cos \theta_{ijk} - \cos \theta_{0ijk}` used in
+the original energy and force expression is scaled by a switching factor
+:math:`f_C(\delta)`:
 
 .. math::
 
@@ -94,28 +105,46 @@ used in the original energy and force expression is scaled by a switching factor
     0 & \left| \delta \right| > \delta_2
     \end{array} \right. \\
 
-This cut-off function decreases smoothly from 1 to 0 over the range :math:`[\delta_1, \delta_2]`.
-This smoothly turns off the energy and force contributions for :math:`\left| \delta \right| > \delta_2`.
-It is suggested that :math:`\delta 1` and :math:`\delta_2` to be the value around
-:math:`0.5 \left| \cos \theta_1 - \cos \theta_2 \right|`, with
-:math:`\theta_1` and :math:`\theta_2` as the different types of angles around an atom.
-For borophene and transition metal dichalcogenides, :math:`\delta_1 = 0.25` and :math:`\delta_2 = 0.35`.
-This value enables the cut-off function to exclude unnecessary angles in the three-body SW terms.
+This cut-off function decreases smoothly from 1 to 0 over the range
+:math:`[\delta_1, \delta_2]`.  This smoothly turns off the energy and
+force contributions for :math:`\left| \delta \right| > \delta_2`.  It is
+suggested that :math:`\delta 1` and :math:`\delta_2` to be the value
+around :math:`0.5 \left| \cos \theta_1 - \cos \theta_2 \right|`, with
+:math:`\theta_1` and :math:`\theta_2` as the different types of angles
+around an atom.  For borophene and transition metal dichalcogenides,
+:math:`\delta_1 = 0.25` and :math:`\delta_2 = 0.35`.  This value enables
+the cut-off function to exclude unnecessary angles in the three-body SW
+terms.
 
 .. note::
 
-   The cut-off function is just to be used as a technique to exclude some unnecessary angles,
-   and it has no physical meaning. It should be noted that the force and potential are inconsistent
-   with each other in the decaying range of the cut-off function, as the angle dependence for the
-   cut-off function is not implemented in the force (first derivation of potential).
-   However, the angle variation is much smaller than the given threshold value for actual simulations,
-   so the inconsistency between potential and force can be neglected in actual simulations.
+   The cut-off function is just to be used as a technique to exclude
+   some unnecessary angles, and it has no physical meaning. It should be
+   noted that the force and potential are inconsistent with each other
+   in the decaying range of the cut-off function, as the angle
+   dependence for the cut-off function is not implemented in the force
+   (first derivation of potential).  However, the angle variation is
+   much smaller than the given threshold value for actual simulations,
+   so the inconsistency between potential and force can be neglected in
+   actual simulations.
 
-Only a single pair_coeff command is used with the *sw* and *sw/mod* styles
-which specifies a Stillinger-Weber potential file with parameters for all
-needed elements.  These are mapped to LAMMPS atom types by specifying
-N additional arguments after the filename in the pair_coeff command,
-where N is the number of LAMMPS atom types:
+The *threebody* keyword is optional and determines whether or not the
+three-body term of the potential is calculated.  The default value is
+"on" and it is only available for the plain *sw* pair style variants,
+but not available for the *sw/mod* and :doc:`sw/angle/table
+<pair_sw_angle_table>` pair style variants.  To turn off the threebody
+contributions all :math:`\lambda_{ijk}` parameters from the potential
+file are forcibly set to 0.  In addition the pair style implementation
+may employ code optimizations for the *threebody off* setting that can
+result in significant speedups versus the default.  These code optimizations
+are currently only available for the MANYBODY and OPENMP packages.
+
+Only a single pair_coeff command is used with the *sw* and *sw/mod*
+styles which specifies a Stillinger-Weber potential file with parameters
+for all needed elements, except for when the *threebody off* setting is
+used (see note below).  These are mapped to LAMMPS atom types by
+specifying N additional arguments after the filename in the pair_coeff
+command, where N is the number of LAMMPS atom types:
 
 * filename
 * N element names = mapping of SW elements to atom types
@@ -130,16 +159,22 @@ pair_coeff command:
 
 .. code-block:: LAMMPS
 
+   pair_style sw
    pair_coeff * * SiC.sw Si Si Si C
 
 The first 2 arguments must be \* \* so as to span all LAMMPS atom types.
-The first three Si arguments map LAMMPS atom types 1,2,3 to the Si
-element in the SW file.  The final C argument maps LAMMPS atom type 4
-to the C element in the SW file.  If a mapping value is specified as
-NULL, the mapping is not performed.  This can be used when a *sw*
+The first three Si arguments map LAMMPS atom types 1, 2, and 3 to the Si
+element in the SW file.  The final C argument maps LAMMPS atom type 4 to
+the C element in the SW file.  If an argument value is specified as
+NULL, the mapping is not performed.  This can be used when an *sw*
 potential is used as part of the *hybrid* pair style.  The NULL values
-are placeholders for atom types that will be used with other
-potentials.
+are placeholders for atom types that will be used with other potentials.
+
+.. note::
+
+   When the *threebody off* keyword is used, multiple pair_coeff commands may
+   be used to specific the pairs of atoms which don't require three-body term.
+   In these cases, the first 2 arguments are not required to be \* \*.
 
 Stillinger-Weber files in the *potentials* directory of the LAMMPS
 distribution have a ".sw" suffix.  Lines that are not blank or
@@ -243,30 +278,39 @@ described above from values in the potential file.
 This pair style does not support the :doc:`pair_modify <pair_modify>`
 shift, table, and tail options.
 
-This pair style does not write its information to :doc:`binary restart files <restart>`, since it is stored in potential files.  Thus, you
-need to re-specify the pair_style and pair_coeff commands in an input
-script that reads a restart file.
+This pair style does not write its information to :doc:`binary restart
+files <restart>`, since it is stored in potential files.  Thus, you need
+to re-specify the pair_style and pair_coeff commands in an input script
+that reads a restart file.
 
 This pair style can only be used via the *pair* keyword of the
 :doc:`run_style respa <run_style>` command.  It does not support the
 *inner*, *middle*, *outer* keywords.
 
+The single() function of the *sw* pair style is only enabled and
+supported for the case of the *threebody off* setting.
+
 ----------
 
 Restrictions
 """"""""""""
 
-This pair style is part of the MANYBODY package.  It is only enabled
-if LAMMPS was built with that package.  See the :doc:`Build package <Build_package>` page for more info.
+This pair style is part of the MANYBODY package.  It is only enabled if
+LAMMPS was built with that package.  See the :doc:`Build package
+<Build_package>` page for more info.
 
 This pair style requires the :doc:`newton <newton>` setting to be "on"
 for pair interactions.
 
 The Stillinger-Weber potential files provided with LAMMPS (see the
 potentials directory) are parameterized for metal :doc:`units <units>`.
-You can use the SW potential with any LAMMPS units, but you would need
-to create your own SW potential file with coefficients listed in the
-appropriate units if your simulation does not use "metal" units.
+You can use the sw or sw/mod pair styles with any LAMMPS units, but you
+would need to create your own SW potential file with coefficients listed
+in the appropriate units if your simulation does not use "metal" units.
+If the potential file contains a 'UNITS:' metadata tag in the first line
+of the potential file, then LAMMPS can convert it transparently between
+"metal" and "real" units.
+
 
 Related commands
 """"""""""""""""
@@ -276,8 +320,9 @@ Related commands
 Default
 """""""
 
-The default values for the *maxdelcs* setting of the *sw/mod* pair
-style are *delta1* = 0.25 and *delta2* = 0.35`.
+The default value for the *threebody* setting of the "sw" pair style is
+"on", the default values for the "*maxdelcs* setting of the *sw/mod*
+pair style are *delta1* = 0.25 and *delta2* = 0.35`.
 
 ----------
 

doc/src/pair_sw_angle_table.rst

@@ -0,0 +1,312 @@
+.. index:: pair_style sw/angle/table
+
+pair_style sw/angle/table command
+=================================
+
+Syntax
+""""""
+
+.. code-block:: LAMMPS
+
+   pair_style style
+
+* style = *sw/angle/table*
+
+
+Examples
+""""""""
+
+.. code-block:: LAMMPS
+
+   pair_style sw/angle/table
+   pair_coeff * * spce.sw type
+
+Used in example input script:
+
+.. parsed-literal::
+
+   examples/PACKAGES/manybody_table/in.spce_sw
+
+
+Description
+"""""""""""
+
+The *sw/angle/table* style is a modification of the original
+:doc:`pair_style sw <pair_sw>`. It has been developed for coarse-grained
+simulations (of water) (:ref:`Scherer1 <Scherer1>`), but can be employed
+for all kinds of systems. It computes a modified 3-body
+:ref:`Stillinger-Weber <Stillinger3>` potential for the energy E of a
+system of atoms as
+
+.. math::
+
+   E & =  \sum_i \sum_{j > i} \phi_2 (r_{ij}) +
+          \sum_i \sum_{j \neq i} \sum_{k > j}
+          \phi_3 (r_{ij}, r_{ik}, \theta_{ijk}) \\
+  \phi_2(r_{ij}) & =  A_{ij} \epsilon_{ij} \left[ B_{ij} (\frac{\sigma_{ij}}{r_{ij}})^{p_{ij}} -
+                    (\frac{\sigma_{ij}}{r_{ij}})^{q_{ij}} \right]
+                    \exp \left( \frac{\sigma_{ij}}{r_{ij} - a_{ij} \sigma_{ij}} \right) \\
+  \phi_3(r_{ij},r_{ik},\theta_{ijk}) & = f^{\textrm{3b}}\left(\theta_{ijk}\right)
+                    \exp \left( \frac{\gamma_{ij} \sigma_{ij}}{r_{ij} - a_{ij} \sigma_{ij}} \right)
+                    \exp \left( \frac{\gamma_{ik} \sigma_{ik}}{r_{ik} - a_{ik} \sigma_{ik}} \right)
+
+where :math:`\phi_2` is a two-body term and :math:`\phi_3` is a
+three-body term.  The summations in the formula are over all neighbors J
+and K of atom I within a cutoff distance :math:`a \sigma`.  In contrast
+to the original *sw* style, *sw/angle/table* allows for a flexible
+three-body term :math:`f^{\textrm{3b}}\left(\theta_{ijk}\right)` which
+is read in as a tabulated interaction. It can be parameterized with the
+csg_fmatch app of VOTCA as available at:
+https://gitlab.mpcdf.mpg.de/votca/votca.
+
+Only a single pair_coeff command is used with the *sw/angle/table* style
+which specifies a modified Stillinger-Weber potential file with
+parameters for all needed elements.  These are mapped to LAMMPS atom
+types by specifying N_el additional arguments after the ".sw" filename
+in the pair_coeff command, where N_el is the number of LAMMPS atom
+types:
+
+* ".sw" filename
+* N_el element names = mapping of SW elements to atom types
+
+See the :doc:`pair_coeff <pair_coeff>` page for alternate ways to
+specify the path for the potential file.
+
+As an example, imagine a file SiC.sw has Stillinger-Weber values for Si
+and C.  If your LAMMPS simulation has 4 atoms types and you want the
+first 3 to be Si, and the fourth to be C, you would use the following
+pair_coeff command:
+
+.. code-block:: LAMMPS
+
+   pair_coeff * * SiC.sw Si Si Si C
+
+The first 2 arguments must be \* \* so as to span all LAMMPS atom types.
+The first three Si arguments map LAMMPS atom types 1,2,3 to the Si
+element in the SW file.  The final C argument maps LAMMPS atom type 4 to
+the C element in the SW file.  If a mapping value is specified as NULL,
+the mapping is not performed.  This can be used when a *sw/angle/table*
+potential is used as part of the *hybrid* pair style.  The NULL values
+are placeholders for atom types that will be used with other potentials.
+
+The (modified) Stillinger-Weber files have a ".sw" suffix. Lines that
+are not blank or comments (starting with #) define parameters for a
+triplet of elements. The parameters in a single entry correspond to the
+two-body and three-body coefficients in the formula above. Here, also
+the suffix ".sw" is used though the original Stillinger-Weber file
+format is supplemented with four additional lines per parameter block to
+specify the tabulated three-body interaction. A single entry then
+contains:
+
+* element 1 (the center atom in a 3-body interaction)
+* element 2
+* element 3
+* :math:`\epsilon` (energy units)
+* :math:`\sigma` (distance units)
+* a
+* :math:`\lambda`
+* :math:`\gamma`
+* :math:`\cos\theta_0`
+* A
+* B
+* p
+* q
+* tol
+* filename
+* keyword
+* style
+* N
+
+The A, B, p, and q parameters are used only for two-body interactions.
+The :math:`\lambda` and :math:`\cos\theta_0` parameters, only used for
+three-body interactions in the original Stillinger-Weber style, are read
+in but ignored in this modified pair style. The :math:`\epsilon`
+parameter is only used for two-body interactions in this modified pair
+style and not for the three-body terms. The :math:`\sigma` and *a*
+parameters are used for both two-body and three-body
+interactions. :math:`\gamma` is used only in the three-body
+interactions, but is defined for pairs of atoms. The non-annotated
+parameters are unitless.
+
+LAMMPS introduces an additional performance-optimization parameter tol
+that is used for both two-body and three-body interactions.  In the
+Stillinger-Weber potential, the interaction energies become negligibly
+small at atomic separations substantially less than the theoretical
+cutoff distances.  LAMMPS therefore defines a virtual cutoff distance
+based on a user defined tolerance tol.  The use of the virtual cutoff
+distance in constructing atom neighbor lists can significantly reduce
+the neighbor list sizes and therefore the computational cost.  LAMMPS
+provides a *tol* value for each of the three-body entries so that they
+can be separately controlled. If tol = 0.0, then the standard
+Stillinger-Weber cutoff is used.
+
+The additional parameters *filename*, *keyword*, *style*, and *N* refer
+to the tabulated angular potential
+:math:`f^{\textrm{3b}}\left(\theta_{ijk}\right)`.  The tabulated angular
+potential has to be of the format as used in the :doc:`angle_style table
+<angle_table>` command:
+
+An interpolation tables of length *N* is created. The interpolation is
+done in one of 2 *styles*: *linear* or *spline*.  For the *linear*
+style, the angle is used to find 2 surrounding table values from which
+an energy or its derivative is computed by linear interpolation. For the
+*spline* style, a cubic spline coefficients are computed and stored at
+each of the *N* values in the table.  The angle is used to find the
+appropriate set of coefficients which are used to evaluate a cubic
+polynomial which computes the energy or derivative.
+
+The *filename* specifies the file containing the tabulated energy and
+derivative values of :math:`f^{\textrm{3b}}\left(\theta_{ijk}\right)`.
+The *keyword* then specifies a section of the file.  The format of this
+file is as follows (without the parenthesized comments):
+
+.. parsed-literal::
+
+   # Angle potential for harmonic (one or more comment or blank lines)
+
+   HAM                           (keyword is the first text on line)
+   N 181 FP 0 0 EQ 90.0          (N, FP, EQ parameters)
+                                 (blank line)
+   1 0.0 200.5 2.5               (index, angle, energy, derivative)
+   2 1.0 198.0 2.5
+   ...
+   181 180.0 0.0 0.0
+
+A section begins with a non-blank line whose first character is not a
+"#"; blank lines or lines starting with "#" can be used as comments
+between sections.  The first line begins with a keyword which identifies
+the section. The next line lists (in any order) one or more parameters
+for the table.  Each parameter is a keyword followed by one or more
+numeric values.
+
+The parameter "N" is required and its value is the number of table
+entries that follow.  Note that this may be different than the *N*
+specified in the Stillinger-Weber potential file. Let Nsw = *N* in the
+".sw" file, and Nfile = "N" in the tabulated angular file.  What LAMMPS
+does is a preliminary interpolation by creating splines using the Nfile
+tabulated values as nodal points.  It uses these to interpolate as
+needed to generate energy and derivative values at Ntable different
+points.  The resulting tables of length Nsw are then used as described
+above, when computing energy and force for individual angles and their
+atoms.  This means that if you want the interpolation tables of length
+Nsw to match exactly what is in the tabulated file (with effectively no
+preliminary interpolation), you should set Nsw = Nfile.
+
+The "FP" parameter is optional.  If used, it is followed by two values
+fplo and fphi, which are the second derivatives at the innermost and
+outermost angle settings.  These values are needed by the spline
+construction routines.  If not specified by the "FP" parameter, they are
+estimated (less accurately) by the first two and last two derivative
+values in the table.
+
+The "EQ" parameter is also optional.  If used, it is followed by a the
+equilibrium angle value, which is used, for example, by the :doc:`fix
+shake <fix_shake>` command. If not used, the equilibrium angle is set to
+180.0.
+
+Following a blank line, the next N lines of the angular table file list
+the tabulated values.  On each line, the first value is the index from 1
+to N, the second value is the angle value (in degrees), the third value
+is the energy (in energy units), and the fourth is -dE/d(theta) (also in
+energy units).  The third term is the energy of the 3-atom configuration
+for the specified angle.  The last term is the derivative of the energy
+with respect to the angle (in degrees, not radians).  Thus the units of
+the last term are still energy, not force.  The angle values must
+increase from one line to the next.  The angle values must also begin
+with 0.0 and end with 180.0, i.e. span the full range of possible
+angles.
+
+Note that one angular potential file can contain many sections, each
+with a tabulated potential.  LAMMPS reads the file section by section
+until it finds one that matches the specified *keyword* of appropriate
+section of the ".sw" file.
+
+The Stillinger-Weber potential file must contain entries for all the
+elements listed in the pair_coeff command.  It can also contain entries
+for additional elements not being used in a particular simulation;
+LAMMPS ignores those entries.
+
+For a single-element simulation, only a single entry is required
+(e.g. SiSiSi).  For a two-element simulation, the file must contain 8
+entries (for SiSiSi, SiSiC, SiCSi, SiCC, CSiSi, CSiC, CCSi, CCC), that
+specify SW parameters for all permutations of the two elements
+interacting in three-body configurations.  Thus for 3 elements, 27
+entries would be required, etc.
+
+As annotated above, the first element in the entry is the center atom in
+a three-body interaction.  Thus an entry for SiCC means a Si atom with 2
+C atoms as neighbors.  The parameter values used for the two-body
+interaction come from the entry where the second and third elements are
+the same.  Thus the two-body parameters for Si interacting with C, comes
+from the SiCC entry.  The three-body angular potential
+:math:`f^{\textrm{3b}}\left(\theta_{ijk}\right)` can in principle be
+specific to the three elements of the configuration. However, the user
+must ensure that it makes physically sense.  Note also that the function
+:math:`\phi_3` contains two exponential screening factors with parameter
+values from the ij pair and ik pairs. So :math:`\phi_3` for a C atom
+bonded to a Si atom and a second C atom will depend on the three-body
+parameters for the CSiC entry, and also on the two-body parameters for
+the CCC and CSiSi entries. Since the order of the two neighbors is
+arbitrary, the three-body parameters and the tabulated angular potential
+for entries CSiC and CCSi should be the same.  Similarly, the two-body
+parameters for entries SiCC and CSiSi should also be the same.  The
+parameters used only for two-body interactions (A, B, p, and q) in
+entries whose second and third element are different (e.g. SiCSi) are
+not used for anything and can be set to 0.0 if desired.  This is also
+true for the parameters in :math:`\phi_3` that are taken from the ij and
+ik pairs (:math:`\sigma`, *a*, :math:`\gamma`)
+
+Additional input files and reference data can be found at:
+https://gitlab.mpcdf.mpg.de/votca/votca/-/tree/master/csg-tutorials/spce/3body_sw
+
+----------
+
+Mixing, shift, table, tail correction, restart, rRESPA info
+"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
+
+For atom type pairs I,J and I != J, where types I and J correspond to
+two different element types, mixing is performed by LAMMPS as described
+above from values in the potential file, but not for the tabulated
+angular potential file.
+
+This pair style does not support the :doc:`pair_modify <pair_modify>`
+shift, table, and tail options.
+
+This pair style does not write its information to :doc:`binary restart
+files <restart>`, since it is stored in potential files.  Thus, you need
+to re-specify the pair_style and pair_coeff commands in an input script
+that reads a restart file.
+
+This pair style can only be used via the *pair* keyword of the
+:doc:`run_style respa <run_style>` command.  It does not support the
+*inner*, *middle*, *outer* keywords.
+
+----------
+
+Restrictions
+""""""""""""
+
+This pair style is part of the MANYBODY package.  It is only enabled if
+LAMMPS was built with that package. See the :doc:`Build package
+<Build_package>` page for more info.
+
+This pair style requires the :doc:`newton <newton>` setting to be "on"
+for pair interactions.
+
+Related commands
+""""""""""""""""
+
+:doc:`pair_coeff <pair_coeff>`, :doc:`pair_style sw <pair_sw>`,
+:doc:`pair_style threebody/table <pair_threebody_table>`
+
+
+----------
+
+.. _Stillinger3:
+
+**(Stillinger)** Stillinger and Weber, Phys Rev B, 31, 5262 (1985).
+
+.. _Scherer1:
+
+**(Scherer1)** C. Scherer and D. Andrienko, Phys. Chem. Chem. Phys. 20, 22387-22394 (2018).
+

doc/src/pair_threebody_table.rst

@@ -0,0 +1,281 @@
+.. index:: pair_style threebody/table
+
+pair_style threebody/table command
+==================================
+
+Syntax
+""""""
+
+.. code-block:: LAMMPS
+
+   pair_style style
+
+* style = *threebody/table*
+
+
+Examples
+""""""""
+
+.. code-block:: LAMMPS
+
+   pair_style threebody/table
+   pair_coeff * * spce2.3b type1 type2
+
+   pair_style hybrid/overlay table linear 1200 threebody/table
+   pair_coeff      1 1 table table_CG_CG.txt VOTCA
+   pair_coeff      * * threebody/table spce.3b type
+
+Used in example input scripts:
+
+.. parsed-literal::
+
+   examples/PACKAGES/manybody_table/in.spce
+   examples/PACKAGES/manybody_table/in.spce2
+
+Description
+"""""""""""
+
+The *threebody/table* style is a pair style for generic tabulated
+three-body interactions.  It has been developed for (coarse-grained)
+simulations (of water) with Kernel-based machine learning (ML)
+potentials (:ref:`Scherer2 <Scherer2>`).  As for many other MANYBODY
+package pair styles the energy of a system is computed as a sum over
+three-body terms:
+
+.. math::
+
+   E =  \sum_i \sum_{j \neq i} \sum_{k > j} \phi_3 (r_{ij}, r_{ik}, \theta_{ijk})
+
+The summations in the formula are over all neighbors J and K of atom I
+within a cutoff distance :math:`cut`.  In contrast to the
+Stillinger-Weber potential, all forces are not calculated analytically,
+but read in from a three-body force/energy table which can be generated
+with the csg_ml app of VOTCA as available at:
+https://gitlab.mpcdf.mpg.de/votca/votca.
+
+Only a single pair_coeff command is used with the *threebody/table*
+style which specifies a threebody potential (".3b") file with parameters
+for all needed elements. These are then mapped to LAMMPS atom types by
+specifying N_el additional arguments after the ".3b" filename in the
+pair_coeff command, where N_el is the number of LAMMPS atom types:
+
+* ".3b" filename
+* N_el element names = mapping of threebody elements to atom types
+
+See the :doc:`pair_coeff <pair_coeff>` page for alternate ways to
+specify the path for the potential file.
+
+As an example, imagine a file SiC.3b has three-body values for Si and C.
+If your LAMMPS simulation has 4 atoms types and you want the first 3 to
+be Si, and the fourth to be C, you would use the following pair_coeff
+command:
+
+.. code-block:: LAMMPS
+
+   pair_coeff * * SiC.3b Si Si Si C
+
+The first 2 arguments must be \* \* so as to span all LAMMPS atom types.
+The first three Si arguments map LAMMPS atom types 1,2,3 to the Si
+element in the ".3b" file.  The final C argument maps LAMMPS atom type 4
+to the C element in the threebody file. If a mapping value is specified
+as NULL, the mapping is not performed. This can be used when a
+*threebody/table* potential is used as part of the *hybrid* pair style.
+The NULL values are placeholders for atom types that will be used with
+other potentials.
+
+The three-body files have a ".3b" suffix. Lines that are not blank or
+comments (starting with #) define parameters for a triplet of
+elements. The parameters in a single entry specify to the (three-body)
+cutoff distance and the tabulated three-body interaction. A single entry
+then contains:
+
+* element 1 (the center atom in a 3-body interaction)
+* element 2
+* element 3
+* cut (distance units)
+* filename
+* keyword
+* style
+* N
+
+The parameter :math:`cut` is the (three-body) cutoff distance.  When set
+to 0, no interaction is calculated for this element triplet.  The
+parameters *filename*, *keyword*, *style*, and *N* refer to the
+tabulated three-body potential.
+
+The tabulation is done on a three-dimensional grid of the two distances
+:math:`r_{ij}` and :math:`r_{ik}` as well as the angle
+:math:`\theta_{ijk}` which is constructed in the following way. There
+are two different cases.  If element 2 and element 3 are of the same
+type (e.g. SiCC), the distance :math:`r_{ij}` is varied in "N" steps
+from rmin to rmax and the distance :math:`r_{ik}` is varied from
+:math:`r_{ij}` to rmax. This can be done, due to the symmetry of the
+triplet. If element 2 and element 3 are not of the same type
+(e.g. SiCSi), there is no additional symmetry and the distance
+:math:`r_{ik}` is also varied from rmin to rmax in "N" steps.  The angle
+:math:`\theta_{ijk}` is always varied in "2N" steps from (0.0 +
+180.0/(4N)) to (180.0 - 180.0/(4N)). Therefore, the total number of
+table entries is "M = N * N * (N+1)" for the symmetric (element 2 and
+element 3 are of the same type) and "M = 2 * N * N * N" for the general
+case (element 2 and element 3 are not of the same type).
+
+The forces on all three particles I, J, and K of a triplet of this type
+of three-body interaction potential (:math:`\phi_3 (r_{ij}, r_{ik},
+\theta_{ijk})`) lie within the plane defined by the three inter-particle
+distance vectors :math:`{\mathbf r}_{ij}`, :math:`{\mathbf r}_{ik}`, and
+:math:`{\mathbf r}_{jk}`.  This property is used to project the forces
+onto the inter-particle distance vectors as follows
+
+.. math::
+
+   \begin{pmatrix}
+      {\mathbf f}_{i} \\
+      {\mathbf f}_{j} \\
+      {\mathbf f}_{k} \\
+   \end{pmatrix} =
+   \begin{pmatrix}
+      f_{i1} & f_{i2} & 0 \\
+      f_{j1} & 0 & f_{j2} \\
+      0 & f_{k1} & f_{k2} \\
+   \end{pmatrix}
+   \begin{pmatrix}
+      {\mathbf r}_{ij} \\
+      {\mathbf r}_{ik} \\
+      {\mathbf r}_{jk} \\
+   \end{pmatrix}
+
+and then tabulate the 6 force constants :math:`f_{i1}`, :math:`f_{i2}`,
+:math:`f_{j1}`, :math:`f_{j2}`, :math:`f_{k1}`, and :math:`f_{k2}`, as
+well as the energy of a triplet e.  Due to symmetry reasons, the
+following relations hold: :math:`f_{i1}=-f_{j1}`,
+:math:`f_{i2}=-f_{k1}`, and :math:`f_{j2}=-f_{k2}`. As in this pair
+style the forces are read in directly, a correct MD simulation is also
+performed in the case that the triplet energies are set to e=0.
+
+The *filename* specifies the file containing the tabulated energy and
+derivative values of :math:`\phi_3 (r_{ij}, r_{ik}, \theta_{ijk})`.  The
+*keyword* then specifies a section of the file. The format of this file
+is as follows (without the parenthesized comments):
+
+.. parsed-literal::
+
+   # Tabulated three-body potential for spce water (one or more comment or blank lines)
+
+   ENTRY1                                                                      (keyword is the first text on line)
+   N 12 rmin 2.55 rmax 3.65                                                    (N, rmin, rmax parameters)
+                                                                               (blank line)
+   1 2.55 2.55 3.75 -867.212 -611.273 867.212 21386.8 611.273 -21386.8  0.0    (index, r_ij, r_ik, theta, f_i1, f_i2, f_j1, f_j2, f_k1, f_k2, e)
+   2 2.55 2.55 11.25 -621.539 -411.189 621.539 5035.95 411.189 -5035.95  0.0
+   ...
+   1872 3.65 3.65 176.25 -0.00215132 -0.00412886 0.00215137 0.00111754 0.00412895 -0.00111757  0.0
+
+A section begins with a non-blank line whose first character is not a
+"#"; blank lines or lines starting with "#" can be used as comments
+between sections.  The first line begins with a keyword which identifies
+the section. The next line lists (in any order) one or more parameters
+for the table.  Each parameter is a keyword followed by one or more
+numeric values.
+
+The parameter "N" is required. It should be the same than the parameter
+"N" of the ".3b" file, otherwise its value is overwritten. "N"
+determines the number of table entries "M" that follow: "M = N * N *
+(N+1)" (symmetric triplet, e.g. SiCC) or "M = 2 * N * N * N" (asymmetric
+triplet, e.g. SiCSi). Therefore "M = 12 * 12 * 13 = 1872" in the above
+symmetric example. The parameters "rmin" and "rmax" are also required
+and determine the minimum and maximum of the inter-particle distances
+:math:`r_{ij}` and :math:`r_{ik}`.
+
+Following a blank line, the next M lines of the angular table file list
+the tabulated values.  On each line, the first value is the index from 1
+to M, the second value is the distance :math:`r_{ij}`, the third value
+is the distance :math:`r_{ik}`, the fourth value is the angle
+:math:`\theta_{ijk})`, the next six values are the force constants
+:math:`f_{i1}`, :math:`f_{i2}`, :math:`f_{j1}`, :math:`f_{j2}`,
+:math:`f_{k1}`, and :math:`f_{k2}`, and the last value is the energy e.
+
+Note that one three-body potential file can contain many sections, each
+with a tabulated potential. LAMMPS reads the file section by section
+until it finds one that matches the specified *keyword* of appropriate
+section of the ".3b" file.
+
+At the moment, only the *style* *linear* is allowed and
+implemented. After reading in the force table, it is internally stored
+in LAMMPS as a lookup table. For each triplet configuration occurring in
+the simulation within the cutoff distance, the next nearest tabulated
+triplet configuration is looked up. No interpolation is done.  This
+allows for a very efficient force calculation with the stored force
+constants and energies. Due to the know table structure, the lookup can
+be done efficiently. It has been tested (:ref:`Scherer2 <Scherer2>`)
+that with a reasonably small bin size, the accuracy and speed is
+comparable to that of a Stillinger-Weber potential with tabulated
+three-body interactions (:doc:`pair_style sw/angle/table
+<pair_sw_angle_table>`) while the table format of this pair style allows
+for more flexible three-body interactions.
+
+As for the Stillinger-Weber potential, the three-body potential file
+must contain entries for all the elements listed in the pair_coeff
+command.  It can also contain entries for additional elements not being
+used in a particular simulation; LAMMPS ignores those entries.
+
+For a single-element simulation, only a single entry is required
+(e.g. SiSiSi).  For a two-element simulation, the file must contain 8
+entries (for SiSiSi, SiSiC, SiCSi, SiCC, CSiSi, CSiC, CCSi, CCC), that
+specify threebody parameters for all permutations of the two elements
+interacting in three-body configurations.  Thus for 3 elements, 27
+entries would be required, etc.
+
+As annotated above, the first element in the entry is the center atom in
+a three-body interaction. Thus an entry for SiCC means a Si atom with 2
+C atoms as neighbors. The tabulated three-body forces can in principle
+be specific to the three elements of the configuration.  However, the
+user must ensure that it makes physically sense.  E.g., the tabulated
+three-body forces for the entries CSiC and CCSi should be the same
+exchanging :math:`r_{ij}` with r_{ik}, :math:`f_{j1}` with
+:math:`f_{k1}`, and :math:`f_{j2}` with :math:`f_{k2}`.
+
+Additional input files and reference data can be found at:
+https://gitlab.mpcdf.mpg.de/votca/votca/-/tree/master/csg-tutorials/ml
+
+----------
+
+Mixing, shift, table, tail correction, restart, rRESPA info
+"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
+
+As all interactions are tabulated, no mixing is performed.
+
+This pair style does not support the :doc:`pair_modify <pair_modify>`
+shift, table, and tail options.
+
+This pair style does not write its information to :doc:`binary restart
+files <restart>`, since it is stored in potential files.  Thus, you need
+to re-specify the pair_style and pair_coeff commands in an input script
+that reads a restart file.
+
+This pair style can only be used via the *pair* keyword of the
+:doc:`run_style respa <run_style>` command.  It does not support the
+*inner*, *middle*, *outer* keywords.
+
+----------
+
+Restrictions
+""""""""""""
+
+This pair style is part of the MANYBODY package.  It is only enabled if
+LAMMPS was built with that package. See the :doc:`Build package
+<Build_package>` page for more info.
+
+This pair style requires the :doc:`newton <newton>` setting to be "on"
+for pair interactions.
+
+Related commands
+""""""""""""""""
+
+:doc:`pair_coeff <pair_coeff>`, :doc:`pair sw/angle/table <pair_sw_angle_table>`
+
+
+----------
+
+.. _Scherer2:
+
+**(Scherer2)** C. Scherer, R. Scheid, D. Andrienko, and T. Bereau, J. Chem. Theor. Comp. 16, 3194-3204 (2020).
+

doc/src/read_data.rst

@@ -56,7 +56,7 @@ Examples
    read_data ../run7/data.polymer.gz
    read_data data.protein fix mycmap crossterm CMAP
    read_data data.water add append offset 3 1 1 1 1 shift 0.0 0.0 50.0
-   read_data data.water add merge 1 group solvent
+   read_data data.water add merge group solvent
 
 Description
 """""""""""
@@ -622,6 +622,8 @@ of analysis.
      - atom-ID molecule-ID atom-type x y z
    * - charge
      - atom-ID atom-type q x y z
+   * - dielectric
+     - atom-ID atom-type q x y z normx normy normz area ed em epsilon curvature
    * - dipole
      - atom-ID atom-type q x y z mux muy muz
    * - dpd

doc/src/read_dump.rst

@@ -24,12 +24,13 @@ Syntax
        *fx*,\ *fy*,\ *fz* = force components
 
 * zero or more keyword/value pairs may be appended
-* keyword = *nfile* or *box* or *replace* or *purge* or *trim* or *add* or *label* or *scaled* or *wrapped* or *format*
+* keyword = *nfile* or *box* or *timestep* or *replace* or *purge* or *trim* or *add* or *label* or *scaled* or *wrapped* or *format*
 
   .. parsed-literal::
 
        *nfile* value = Nfiles = how many parallel dump files exist
        *box* value = *yes* or *no* = replace simulation box with dump box
+       *timestep* value = *yes* or *no* = reset simulation timestep with dump timestep
        *replace* value = *yes* or *no* = overwrite atoms with dump atoms
        *purge* value = *yes* or *no* = delete all atoms before adding dump atoms
        *trim* value = *yes* or *no* = trim atoms not in dump snapshot
@@ -60,6 +61,7 @@ Examples
    read_dump dump.dcd 0 x y z box yes format molfile dcd
    read_dump dump.file 1000 x y z vx vy vz box yes format molfile lammpstrj /usr/local/lib/vmd/plugins/LINUXAMD64/plugins/molfile
    read_dump dump.file 5000 x y vx vy trim yes
+   read_dump dump.file 5000 x y vx vy add yes box no timestep no
    read_dump ../run7/dump.file.gz 10000 x y z box yes
    read_dump dump.xyz 10 x y z box no format molfile xyz ../plugins
    read_dump dump.dcd 0 x y z format molfile dcd
@@ -71,9 +73,9 @@ Description
 """""""""""
 
 Read atom information from a dump file to overwrite the current atom
-coordinates, and optionally the atom velocities and image flags and
-the simulation box dimensions.  This is useful for restarting a run
-from a particular snapshot in a dump file.  See the
+coordinates, and optionally the atom velocities and image flags, the
+simulation timestep, and the simulation box dimensions.  This is useful
+for restarting a run from a particular snapshot in a dump file.  See the
 :doc:`read_restart <read_restart>` and :doc:`read_data <read_data>`
 commands for alternative methods to do this.  Also see the
 :doc:`rerun <rerun>` command for a means of reading multiple snapshots
@@ -89,9 +91,9 @@ Also note that reading per-atom information from a dump snapshot is
 limited to the atom coordinates, velocities and image flags, as
 explained below.  Other atom properties, which may be necessary to run
 a valid simulation, such as atom charge, or bond topology information
-for a molecular system, are not read from (or even contained in) dump
-files.  Thus this auxiliary information should be defined in the usual
-way, e.g. in a data file read in by a :doc:`read_data <read_data>`
+for a molecular system, are not read from (or may not even be contained
+in) dump files.  Thus this auxiliary information should be defined in
+the usual way, e.g. in a data file read in by a :doc:`read_data <read_data>`
 command, before using the read_dump command, or by the :doc:`set <set>`
 command, after the dump snapshot is read.
 
@@ -165,11 +167,10 @@ variable *ntimestep*:
     uint64_t  ntimestep  5*scalar
       (0)    0 50 100 150 200
 
-Note that the *xyz*
-and *molfile* formats do not store the timestep.  For these formats,
-timesteps are numbered logically, in a sequential manner, starting
-from 0.  Thus to access the 10th snapshot in an *xyz* or *mofile*
-formatted dump file, use *Nstep* = 9.
+Note that the *xyz* and *molfile* formats do not store the timestep.
+For these formats, timesteps are numbered logically, in a sequential
+manner, starting from 0.  Thus to access the 10th snapshot in an *xyz*
+or *mofile* formatted dump file, use *Nstep* = 9.
 
 The dimensions of the simulation box for the selected snapshot are
 also read; see the *box* keyword discussion below.  For the *native*
@@ -266,8 +267,10 @@ for how this is done, determined by the specified fields and optional
 keywords.
 
 The timestep of the snapshot becomes the current timestep for the
-simulation.  See the :doc:`reset_timestep <reset_timestep>` command if
-you wish to change this after the dump snapshot is read.
+simulation unless the *timestep* keyword is specified with a *no* value
+(default setting is *yes*).  See the :doc:`reset_timestep <reset_timestep>`
+command if you wish to change this to a different value after the dump
+snapshot is read.
 
 If the *box* keyword is specified with a *yes* value, then the current
 simulation box dimensions are replaced by the dump snapshot box
@@ -391,7 +394,7 @@ Related commands
 Default
 """""""
 
-The option defaults are box = yes, replace = yes, purge = no, trim =
-no, add = no, scaled = no, wrapped = yes, and format = native.
+The option defaults are box = yes, timestep = yes, replace = yes, purge = no,
+trim = no, add = no, scaled = no, wrapped = yes, and format = native.
 
 .. _vmd: http://www.ks.uiuc.edu/Research/vmd

doc/src/read_restart.rst

@@ -11,7 +11,6 @@ Syntax
    read_restart file flag
 
 * file = name of binary restart file to read in
-* flag = remap (optional)
 
 Examples
 """"""""
@@ -19,44 +18,40 @@ Examples
 .. code-block:: LAMMPS
 
    read_restart save.10000
-   read_restart save.10000 remap
    read_restart restart.*
    read_restart restart.*.mpiio
-   read_restart poly.*.% remap
 
 Description
 """""""""""
 
 Read in a previously saved system configuration from a restart file.
 This allows continuation of a previous run.  Details about what
-information is stored (and not stored) in a restart file is given
-below.  Basically this operation will re-create the simulation box
-with all its atoms and their attributes as well as some related global
-settings, at the point in time it was written to the restart file by a
-previous simulation.  The simulation box will be partitioned into a
-regular 3d grid of rectangular bricks, one per processor, based on the
-number of processors in the current simulation and the settings of the
+information is stored (and not stored) in a restart file is given below.
+Basically this operation will re-create the simulation box with all its
+atoms and their attributes as well as some related global settings, at
+the point in time it was written to the restart file by a previous
+simulation.  The simulation box will be partitioned into a regular 3d
+grid of rectangular bricks, one per processor, based on the number of
+processors in the current simulation and the settings of the
 :doc:`processors <processors>` command.  The partitioning can later be
-changed by the :doc:`balance <balance>` or :doc:`fix balance <fix_balance>` commands.
-
-.. note::
-
-   Normally, restart files are written by the
-   :doc:`restart <restart>` or :doc:`write_restart <write_restart>` commands
-   so that all atoms in the restart file are inside the simulation box.
-   If this is not the case, the read_restart command will print an error
-   that atoms were "lost" when the file is read.  This error should be
-   reported to the LAMMPS developers so the invalid writing of the
-   restart file can be fixed.  If you still wish to use the restart file,
-   the optional *remap* flag can be appended to the read_restart command.
-   This should avoid the error, by explicitly remapping each atom back
-   into the simulation box, updating image flags for the atom
-   appropriately.
+changed by the :doc:`balance <balance>` or :doc:`fix balance
+<fix_balance>` commands.
 
 Restart files are saved in binary format to enable exact restarts,
 meaning that the trajectories of a restarted run will precisely match
 those produced by the original run had it continued on.
 
+The binary restart file format was not designed with backward, forward,
+or cross-platform compatibility in mind, so the files are only expected
+to be read correctly by the same LAMMPS executable on the same platform.
+Changes to the architecture, compilation settings, or LAMMPS version can
+render a restart file unreadable or it may read the data incorrectly.
+If you want a more portable format, you can use the data file format as
+created by the :doc:`write_data <write_data>` command.  Binary restart
+files can also be converted into a data file from the command line by
+the LAMMPS executable that wrote them using the :ref:`-restart2data
+<restart2data>` command line flag.
+
 Several things can prevent exact restarts due to round-off effects, in
 which case the trajectories in the 2 runs will slowly diverge.  These
 include running on a different number of processors or changing
@@ -65,7 +60,8 @@ certain settings such as those set by the :doc:`newton <newton>` or
 these cases.
 
 Certain fixes will not restart exactly, though they should provide
-statistically similar results.  These include :doc:`fix shake <fix_shake>` and :doc:`fix langevin <fix_langevin>`.
+statistically similar results.  These include :doc:`fix shake
+<fix_shake>` and :doc:`fix langevin <fix_langevin>`.
 
 Certain pair styles will not restart exactly, though they should
 provide statistically similar results.  This is because the forces
@@ -81,18 +77,19 @@ produced the restart file, it could be a LAMMPS bug, so consider
 :doc:`reporting it <Errors_bugs>` if you think the behavior is a bug.
 
 Because restart files are binary, they may not be portable to other
-machines.  In this case, you can use the :doc:`-restart command-line switch <Run_options>` to convert a restart file to a data file.
+machines.  In this case, you can use the :doc:`-restart command-line
+switch <Run_options>` to convert a restart file to a data file.
 
-Similar to how restart files are written (see the
-:doc:`write_restart <write_restart>` and :doc:`restart <restart>`
-commands), the restart filename can contain two wild-card characters.
-If a "\*" appears in the filename, the directory is searched for all
-filenames that match the pattern where "\*" is replaced with a timestep
-value.  The file with the largest timestep value is read in.  Thus,
-this effectively means, read the latest restart file.  It's useful if
-you want your script to continue a run from where it left off.  See
-the :doc:`run <run>` command and its "upto" option for how to specify
-the run command so it does not need to be changed either.
+Similar to how restart files are written (see the :doc:`write_restart
+<write_restart>` and :doc:`restart <restart>` commands), the restart
+filename can contain two wild-card characters.  If a "\*" appears in the
+filename, the directory is searched for all filenames that match the
+pattern where "\*" is replaced with a timestep value.  The file with the
+largest timestep value is read in.  Thus, this effectively means, read
+the latest restart file.  It's useful if you want your script to
+continue a run from where it left off.  See the :doc:`run <run>` command
+and its "upto" option for how to specify the run command so it does not
+need to be changed either.
 
 If a "%" character appears in the restart filename, LAMMPS expects a
 set of multiple files to exist.  The :doc:`restart <restart>` and
@@ -222,17 +219,17 @@ its calculations in a consistent manner.
 
 .. note::
 
-   There are a handful of commands which can be used before or
-   between runs which may require a system initialization.  Examples
-   include the "balance", "displace_atoms", "delete_atoms", "set" (some
-   options), and "velocity" (some options) commands.  This is because
-   they can migrate atoms to new processors.  Thus they will also discard
-   unused "state" information from fixes.  You will know the discard has
+   There are a handful of commands which can be used before or between
+   runs which may require a system initialization.  Examples include the
+   "balance", "displace_atoms", "delete_atoms", "set" (some options),
+   and "velocity" (some options) commands.  This is because they can
+   migrate atoms to new processors.  Thus they will also discard unused
+   "state" information from fixes.  You will know the discard has
    occurred because a list of discarded fixes will be printed to the
    screen and log file, as explained above.  This means that if you wish
    to retain that info in a restarted run, you must re-specify the
-   relevant fixes and computes (which create fixes) before those commands
-   are used.
+   relevant fixes and computes (which create fixes) before those
+   commands are used.
 
 Some pair styles, like the :doc:`granular pair styles <pair_gran>`, also
 use a fix to store "state" information that persists from timestep to
@@ -245,18 +242,19 @@ LAMMPS allows bond interactions (angle, etc) to be turned off or
 deleted in various ways, which can affect how their info is stored in
 a restart file.
 
-If bonds (angles, etc) have been turned off by the :doc:`fix shake <fix_shake>` or :doc:`delete_bonds <delete_bonds>` command,
-their info will be written to a restart file as if they are turned on.
-This means they will need to be turned off again in a new run after
-the restart file is read.
+If bonds (angles, etc) have been turned off by the :doc:`fix shake
+<fix_shake>` or :doc:`delete_bonds <delete_bonds>` command, their info
+will be written to a restart file as if they are turned on.  This means
+they will need to be turned off again in a new run after the restart
+file is read.
 
 Bonds that are broken (e.g. by a bond-breaking potential) are written
 to the restart file as broken bonds with a type of 0.  Thus these
 bonds will still be broken when the restart file is read.
 
-Bonds that have been broken by the :doc:`fix bond/break <fix_bond_break>` command have disappeared from the
-system.  No information about these bonds is written to the restart
-file.
+Bonds that have been broken by the :doc:`fix bond/break
+<fix_bond_break>` command have disappeared from the system.  No
+information about these bonds is written to the restart file.
 
 ----------
 

doc/src/special_bonds.rst

@@ -11,7 +11,7 @@ Syntax
    special_bonds keyword values ...
 
 * one or more keyword/value pairs may be appended
-* keyword = *amber* or *charmm* or *dreiding* or *fene* or *lj/coul* or *lj* or *coul* or *angle* or *dihedral*
+* keyword = *amber* or *charmm* or *dreiding* or *fene* or *lj/coul* or *lj* or *coul* or *angle* or *dihedral* or *one/five*
 
   .. parsed-literal::
 
@@ -27,6 +27,7 @@ Syntax
          w1,w2,w3 = weights (0.0 to 1.0) on pairwise Coulombic interactions
        *angle* value = *yes* or *no*
        *dihedral* value = *yes* or *no*
+       *one/five* value = *yes* or *no*
 
 Examples
 """"""""
@@ -45,10 +46,10 @@ Description
 Set weighting coefficients for pairwise energy and force contributions
 between pairs of atoms that are also permanently bonded to each other,
 either directly or via one or two intermediate bonds.  These weighting
-factors are used by nearly all :doc:`pair styles <pair_style>` in LAMMPS
-that compute simple pairwise interactions.  Permanent bonds between
-atoms are specified by defining the bond topology in the data file
-read by the :doc:`read_data <read_data>` command.  Typically a
+factors are used by nearly all :doc:`pair styles <pair_style>` in
+LAMMPS that compute simple pairwise interactions.  Permanent bonds
+between atoms are specified by defining the bond topology in the data
+file read by the :doc:`read_data <read_data>` command.  Typically a
 :doc:`bond_style <bond_style>` command is also used to define a bond
 potential.  The rationale for using these weighting factors is that
 the interaction between a pair of bonded atoms is all (or mostly)
@@ -58,31 +59,34 @@ atoms should be excluded (or reduced by a weighting factor).
 
 .. note::
 
-   These weighting factors are NOT used by :doc:`pair styles <pair_style>` that compute many-body interactions, since the
-   "bonds" that result from such interactions are not permanent, but are
-   created and broken dynamically as atom conformations change.  Examples
-   of pair styles in this category are EAM, MEAM, Stillinger-Weber,
-   Tersoff, COMB, AIREBO, and ReaxFF.  In fact, it generally makes no
-   sense to define permanent bonds between atoms that interact via these
-   potentials, though such bonds may exist elsewhere in your system,
-   e.g. when using the :doc:`pair_style hybrid <pair_hybrid>` command.
-   Thus LAMMPS ignores special_bonds settings when many-body potentials
-   are calculated.  Please note, that the existence of explicit bonds
-   for atoms that are described by a many-body potential will alter the
-   neighbor list and thus can render the computation of those interactions
-   invalid, since those pairs are not only used to determine direct
-   pairwise interactions but also neighbors of neighbors and more.
-   The recommended course of action is to remove such bonds, or - if
-   that is not possible - use a special bonds setting of 1.0 1.0 1.0.
+   These weighting factors are NOT used by :doc:`pair styles
+   <pair_style>` that compute many-body interactions, since the
+   "bonds" that result from such interactions are not permanent, but
+   are created and broken dynamically as atom conformations change.
+   Examples of pair styles in this category are EAM, MEAM,
+   Stillinger-Weber, Tersoff, COMB, AIREBO, and ReaxFF.  In fact, it
+   generally makes no sense to define permanent bonds between atoms
+   that interact via these potentials, though such bonds may exist
+   elsewhere in your system, e.g. when using the :doc:`pair_style
+   hybrid <pair_hybrid>` command.  Thus LAMMPS ignores special_bonds
+   settings when many-body potentials are calculated.  Please note,
+   that the existence of explicit bonds for atoms that are described
+   by a many-body potential will alter the neighbor list and thus can
+   render the computation of those interactions invalid, since those
+   pairs are not only used to determine direct pairwise interactions
+   but also neighbors of neighbors and more.  The recommended course
+   of action is to remove such bonds, or - if that is not possible -
+   use a special bonds setting of 1.0 1.0 1.0.
 
 .. note::
 
    Unlike some commands in LAMMPS, you cannot use this command
    multiple times in an incremental fashion: e.g. to first set the LJ
-   settings and then the Coulombic ones.  Each time you use this command
-   it sets all the coefficients to default values and only overrides the
-   one you specify, so you should set all the options you need each time
-   you use it.  See more details at the bottom of this page.
+   settings and then the Coulombic ones.  Each time you use this
+   command it sets all the coefficients to default values and only
+   overrides the one you specify, so you should set all the options
+   you need each time you use it.  See more details at the bottom of
+   this page.
 
 The Coulomb factors are applied to any Coulomb (charge interaction)
 term that the potential calculates.  The LJ factors are applied to the
@@ -94,14 +98,14 @@ exclude it completely.
 
 The first of the 3 coefficients (LJ or Coulombic) is the weighting
 factor on 1-2 atom pairs, which are pairs of atoms directly bonded to
-each other.  The second coefficient is the weighting factor on 1-3 atom
-pairs which are those separated by 2 bonds (e.g. the two H atoms in a
-water molecule).  The third coefficient is the weighting factor on 1-4
-atom pairs which are those separated by 3 bonds (e.g. the first and fourth
-atoms in a dihedral interaction).  Thus if the 1-2 coefficient is set
-to 0.0, then the pairwise interaction is effectively turned off for
-all pairs of atoms bonded to each other.  If it is set to 1.0, then
-that interaction will be at full strength.
+each other.  The second coefficient is the weighting factor on 1-3
+atom pairs which are those separated by 2 bonds (e.g. the two H atoms
+in a water molecule).  The third coefficient is the weighting factor
+on 1-4 atom pairs which are those separated by 3 bonds (e.g. the first
+and fourth atoms in a dihedral interaction).  Thus if the 1-2
+coefficient is set to 0.0, then the pairwise interaction is
+effectively turned off for all pairs of atoms bonded to each other.
+If it is set to 1.0, then that interaction will be at full strength.
 
 .. note::
 
@@ -184,21 +188,27 @@ interaction between atoms 2 and 5 will be unaffected (full weighting
 of 1.0).  If the *dihedral* keyword is specified as *no* which is the
 default, then the 2,5 interaction will also be weighted by 0.5.
 
+The *one/five* keyword enable calculation and storage of a list of 1-5
+neighbors in the molecular topology for each atom.  It is required by
+some pair styles, such as :doc:`pair_style amoeba <pair_style>` and
+:doc:`pair_style hippo <pair_style>`.
+
 ----------
 
 .. note::
 
    LAMMPS stores and maintains a data structure with a list of the
-   first, second, and third neighbors of each atom (within the bond topology of
-   the system).  If new bonds are created (or molecules added containing
-   atoms with more special neighbors), the size of this list needs to
-   grow.  Note that adding a single bond always adds a new first neighbor
-   but may also induce \*many\* new second and third neighbors, depending on the
-   molecular topology of your system.  Using the *extra/special/per/atom*
-   keyword to either :doc:`read_data <read_data>` or :doc:`create_box <create_box>`
-   reserves empty space in the list for this N additional first, second, or third
-   neighbors to be added.  If you do not do this, you may get an error
-   when bonds (or molecules) are added.
+   first, second, and third neighbors of each atom (within the bond
+   topology of the system).  If new bonds are created (or molecules
+   added containing atoms with more special neighbors), the size of
+   this list needs to grow.  Note that adding a single bond always
+   adds a new first neighbor but may also induce \*many\* new second
+   and third neighbors, depending on the molecular topology of your
+   system.  Using the *extra/special/per/atom* keyword to either
+   :doc:`read_data <read_data>` or :doc:`create_box <create_box>`
+   reserves empty space in the list for this N additional first,
+   second, or third neighbors to be added.  If you do not do this, you
+   may get an error when bonds (or molecules) are added.
 
 ----------
 
@@ -226,16 +236,16 @@ In the first case you end up with (after the second command):
    LJ: 0.0 0.0 0.0
    Coul: 0.0 0.0 1.0
 
-while only in the second case, you get the desired settings of:
+while only in the second case do you get the desired settings of:
 
 .. parsed-literal::
 
    LJ: 0.0 1.0 1.0
    Coul: 0.0 0.0 1.0
 
-This happens because the LJ (and Coul) settings are reset to
-their default values before modifying them, each time the
-*special_bonds* command is issued.
+This happens because the LJ (and Coul) settings are reset to their
+default values before modifying them, each time the *special_bonds*
+command is issued.
 
 Restrictions
 """"""""""""

doc/utils/requirements.txt

@@ -6,4 +6,3 @@ breathe
 Pygments
 six
 pyyaml
-wheel

doc/utils/sphinx-config/false_positives.txt

@@ -94,6 +94,7 @@ amu
 Amzallag
 analytical
 Anders
+Andrienko
 Andzelm
 Ang
 anglegrad
@@ -119,6 +120,7 @@ Antonelli
 api
 Apoorva
 Appl
+apptainer
 Apu
 arallel
 arccos
@@ -239,6 +241,7 @@ benchmarking
 Bennet
 Berardi
 Beraun
+Bereau
 berendsen
 Berendsen
 berger
@@ -266,6 +269,7 @@ binutils
 biomolecular
 biomolecule
 Biomolecules
+biomolecules
 Biophys
 Biosym
 biquadratic
@@ -275,6 +279,7 @@ Bispectrum
 bitbucket
 bitmapped
 bitmask
+bitorsion
 bitrate
 bitrates
 Bitzek
@@ -370,6 +375,7 @@ Caltech
 Camilloni
 Camiloni
 Campana
+Cangi
 Cao
 Capolungo
 Caro
@@ -439,6 +445,7 @@ chiralIDs
 ChiralIDs
 chirality
 Cho
+Chodera
 ChooseOffset
 chris
 Christoph
@@ -560,6 +567,7 @@ Crozier
 Cryst
 Crystallogr
 Csanyi
+csg
 csh
 cshrc
 CSiC
@@ -572,6 +580,7 @@ cstring
 cstyle
 csvr
 ctrl
+ctrn
 ctypes
 Ctypes
 cuda
@@ -692,6 +701,7 @@ devel
 Devemy
 deviatoric
 Devine
+dewald
 df
 dfftw
 DFT
@@ -769,6 +779,7 @@ DPD
 dpdTheta
 dphi
 DPhil
+dpme
 dr
 dR
 dragforce
@@ -873,6 +884,7 @@ Eindhoven
 Eisenforschung
 Ejtehadi
 El
+el
 elaplong
 elastance
 Electroneg
@@ -1081,6 +1093,7 @@ fm
 fmackay
 fmag
 fmass
+fmatch
 fmm
 fmt
 fmtlib
@@ -1270,6 +1283,7 @@ gzipped
 Haak
 Hafskjold
 halfstepback
+halgren
 Halperin
 Halver
 Hamaker
@@ -1277,6 +1291,7 @@ Hamel
 Hammerschmidt
 Hanley
 haptic
+Haque
 Hara
 Harpertown
 Harting
@@ -1319,6 +1334,7 @@ hexatic
 hexorder
 Heyes
 HfO
+hftn
 hgrid
 hhmrr
 Hibbs
@@ -1563,6 +1579,7 @@ jpeglib
 jpg
 JPG
 jpl
+json
 Jth
 jtranch
 jtype
@@ -1618,6 +1635,7 @@ Kemper
 kepler
 keV
 Keyes
+keyfile
 Khersonskii
 Khrapak
 Khvostov
@@ -1693,6 +1711,7 @@ Ladd
 lagrangian
 lambdai
 LambdaLanczos
+Lambrecht
 lamda
 lammps
 Lammps
@@ -2078,6 +2097,7 @@ mlparks
 Mniszewski
 mnt
 mobi
+Mobley
 modc
 Modell
 modelled
@@ -2128,6 +2148,7 @@ mpiexec
 mpiio
 mpirun
 mplayer
+mpole
 mps
 mradius
 Mrovec
@@ -2162,6 +2183,7 @@ multicore
 multielectron
 multinode
 multiphysics
+Multipole
 multiscale
 multisectioning
 multithreading
@@ -2349,6 +2371,7 @@ nodesets
 Noehring
 Noffset
 noforce
+noguess
 Noid
 nolib
 nonequilibrium
@@ -2357,11 +2380,16 @@ nonGaussian
 nonlocal
 Nonlocal
 Noordhoek
+noprecond
 nopreliminary
 Nord
 norder
 Nordlund
+noremap
 normals
+normx
+normy
+normz
 Noskov
 noslip
 noticable
@@ -2405,6 +2433,7 @@ Nstep
 Nsteplast
 Nstop
 nsub
+Nsw
 Nswap
 nt
 Nt
@@ -2528,6 +2557,7 @@ palegreen
 paleturquoise
 palevioletred
 Panagiotopoulos
+Pande
 Pandit
 Papaconstantopoulos
 papayawhip
@@ -2562,6 +2592,7 @@ Pavia
 Paxton
 pbc
 pc
+pcg
 pchain
 Pchain
 pcmoves
@@ -2595,7 +2626,9 @@ Persp
 peru
 Peskin
 Pettifor
+pewald
 pfactor
+pflag
 pgi
 ph
 Philipp
@@ -2628,6 +2661,7 @@ pIp
 Pisarev
 Pishevar
 Pitera
+pitorsion
 pj
 pjintve
 pKa
@@ -2643,6 +2677,7 @@ plt
 plumedfile
 pmb
 pmcmoves
+pme
 Pmolrotate
 Pmoltrans
 pN
@@ -2667,7 +2702,9 @@ polyelectrolyte
 polyhedra
 Polym
 polymorphism
+Ponder
 popen
+Popoola
 Popov
 popstore
 Poresag
@@ -2684,6 +2721,7 @@ potin
 Pourtois
 powderblue
 PowerShell
+ppme
 ppn
 pppm
 Prakash
@@ -2693,6 +2731,7 @@ pre
 Pre
 prec
 precession
+precond
 prefactor
 prefactors
 prepend
@@ -2787,6 +2826,8 @@ Qsb
 qtb
 quadratically
 quadrupolar
+quadrupole
+quadrupoles
 Quant
 quartic
 quat
@@ -2798,10 +2839,12 @@ quatk
 quatw
 queryargs
 Queteschiner
+quickmin
 qw
 qx
 qy
 qz
+Rackers
 radialscreened
 radialscreenedspin
 radialspin
@@ -2810,6 +2853,7 @@ radians
 Rafferty
 rahman
 Rahman
+Rajamanickam
 Ralf
 Raman
 ramped
@@ -3034,11 +3078,13 @@ scalexz
 scaleyz
 Scalfi
 Schaik
+Scheid
 Schilfgarde
 Schimansky
 Schiotz
 Schlitter
 Schmid
+Schnieders
 Schoen
 Schotte
 Schratt
@@ -3051,6 +3097,7 @@ screenshot
 screenshots
 Scripps
 Scripta
+sd
 sdk
 sdpd
 SDPD
@@ -3172,6 +3219,7 @@ Souza
 sp
 spacings
 Spearot
+specieslist
 specular
 spellcheck
 Spellmeyer
@@ -3210,6 +3258,7 @@ statvolt
 stdin
 stdio
 stdlib
+stdout
 steelblue
 Stegailov
 Steinbach
@@ -3493,6 +3542,9 @@ Tz
 Tzou
 ub
 Uberuaga
+ubflag
+Ubflag
+ubiquitin
 uca
 uChem
 uCond
@@ -3546,12 +3598,14 @@ upenn
 upto
 Urbakh
 Urbana
+UreyBradley
 Usabiaga
 usec
 uSemiParallel
 userguide
 username
 usleep
+usolve
 usr
 util
 utils
@@ -3585,6 +3639,7 @@ Vcm
 vdfmax
 vdim
 vdisplace
+vdw
 vdW
 vdwl
 vec
@@ -3659,13 +3714,19 @@ vx
 Vx
 vxcm
 vxmu
+vxx
+vxy
+vxz
 vy
 Vy
 vycm
+vyy
+vyz
 vz
 Vz
 vzcm
 vzi
+vzz
 Waals
 Wadley
 wallstyle
@@ -3732,6 +3793,7 @@ Xeon
 xflag
 xhi
 xHost
+Xia
 Xiaohu
 Xiaowang
 Xie

examples/COUPLE/fortran2/LAMMPS-wrapper.cpp

@@ -12,8 +12,8 @@
 ------------------------------------------------------------------------- */
 
 /* ------------------------------------------------------------------------
-    Contributing author:  Karl D. Hammond <karlh@ugcs.caltech.edu>
-                          University of Tennessee, Knoxville (USA), 2012
+    Contributing author:  Karl D. Hammond <hammondkd@missouri.edu>
+                          University of Missouri (USA), 2012
 ------------------------------------------------------------------------- */
 
 /* This is set of "wrapper" functions to assist LAMMPS.F90, which itself
@@ -23,6 +23,7 @@
 
 #include <mpi.h>
 #include "LAMMPS-wrapper.h"
+#define LAMMPS_LIB_MPI 1
 #include <library.h>
 #include <lammps.h>
 #include <atom.h>
@@ -56,181 +57,40 @@ void lammps_error_all (void *ptr, const char *file, int line, const char *str)
 
 int lammps_extract_compute_vectorsize (void *ptr, char *id, int style)
 {
-   class LAMMPS *lmp = (class LAMMPS *) ptr;
-   int icompute = lmp->modify->find_compute(id);
-   if ( icompute < 0 ) return 0;
-   class Compute *compute = lmp->modify->compute[icompute];
-
-   if ( style == 0 )
-   {
-      if ( !compute->vector_flag )
-         return 0;
-      else
-         return compute->size_vector;
-   }
-   else if ( style == 1 )
-   {
-      return lammps_get_natoms (ptr);
-   }
-   else if ( style == 2 )
-   {
-      if ( !compute->local_flag )
-         return 0;
-      else
-         return compute->size_local_rows;
-   }
-   else
-      return 0;
+   int *size;
+   size = (int *) lammps_extract_compute(ptr, id, style, LMP_SIZE_VECTOR);
+   if (size) return *size;
+   return 0;
 }
 
 void lammps_extract_compute_arraysize (void *ptr, char *id, int style,
       int *nrows, int *ncols)
 {
-   class LAMMPS *lmp = (class LAMMPS *) ptr;
-   int icompute = lmp->modify->find_compute(id);
-   if ( icompute < 0 )
-   {
-      *nrows = 0;
-      *ncols = 0;
-   }
-   class Compute *compute = lmp->modify->compute[icompute];
-
-   if ( style == 0 )
-   {
-      if ( !compute->array_flag )
-      {
-         *nrows = 0;
-         *ncols = 0;
-      }
-      else
-      {
-         *nrows = compute->size_array_rows;
-         *ncols = compute->size_array_cols;
-      }
-   }
-   else if ( style == 1 )
-   {
-      if ( !compute->peratom_flag )
-      {
-         *nrows = 0;
-         *ncols = 0;
-      }
-      else
-      {
-         *nrows = lammps_get_natoms (ptr);
-         *ncols = compute->size_peratom_cols;
-      }
-   }
-   else if ( style == 2 )
-   {
-      if ( !compute->local_flag )
-      {
-         *nrows = 0;
-         *ncols = 0;
-      }
-      else
-      {
-         *nrows = compute->size_local_rows;
-         *ncols = compute->size_local_cols;
-      }
-   }
-   else
-   {
-      *nrows = 0;
-      *ncols = 0;
-   }
-
+   int *tmp;
+   tmp = (int *) lammps_extract_compute(ptr, id, style, LMP_SIZE_ROWS);
+   if (tmp) *nrows = *tmp;
+   tmp = (int *) lammps_extract_compute(ptr, id, style, LMP_SIZE_COLS);
+   if (tmp) *ncols = *tmp;
    return;
 }
 
 int lammps_extract_fix_vectorsize (void *ptr, char *id, int style)
 {
-   class LAMMPS *lmp = (class LAMMPS *) ptr;
-   int ifix = lmp->modify->find_fix(id);
-   if ( ifix < 0 ) return 0;
-   class Fix *fix = lmp->modify->fix[ifix];
-
-   if ( style == 0 )
-   {
-      if ( !fix->vector_flag )
-         return 0;
-      else
-         return fix->size_vector;
-   }
-   else if ( style == 1 )
-   {
-      return lammps_get_natoms (ptr);
-   }
-   else if ( style == 2 )
-   {
-      if ( !fix->local_flag )
-         return 0;
-      else
-         return fix->size_local_rows;
-   }
-   else
-      return 0;
+   int *size;
+   size = (int *) lammps_extract_fix(ptr, id, style, LMP_SIZE_VECTOR, 0, 0);
+   if (size) return *size;
+   return 0;
 }
 
 void lammps_extract_fix_arraysize (void *ptr, char *id, int style,
       int *nrows, int *ncols)
 {
-   class LAMMPS *lmp = (class LAMMPS *) ptr;
-   int ifix = lmp->modify->find_fix(id);
-   if ( ifix < 0 )
-   {
-      *nrows = 0;
-      *ncols = 0;
-   }
-   class Fix *fix = lmp->modify->fix[ifix];
-
-   if ( style == 0 )
-   {
-      if ( !fix->array_flag )
-      {
-         *nrows = 0;
-         *ncols = 0;
-      }
-      else
-      {
-         *nrows = fix->size_array_rows;
-         *ncols = fix->size_array_cols;
-      }
-   }
-   else if ( style == 1 )
-   {
-      if ( !fix->peratom_flag )
-      {
-         *nrows = 0;
-         *ncols = 0;
-      }
-      else
-      {
-         *nrows = lammps_get_natoms (ptr);
-         *ncols = fix->size_peratom_cols;
-      }
-   }
-   else if ( style == 2 )
-   {
-      if ( !fix->local_flag )
-      {
-         *nrows = 0;
-         *ncols = 0;
-      }
-      else
-      {
-         *nrows = fix->size_local_rows;
-         *ncols = fix->size_local_cols;
-      }
-   }
-   else
-   {
-      *nrows = 0;
-      *ncols = 0;
-   }
-
+   int *tmp;
+   tmp = (int *) lammps_extract_fix(ptr, id, style, LMP_SIZE_ROWS, 0, 0);
+   if (tmp) *nrows = *tmp;
+   tmp = (int *) lammps_extract_fix(ptr, id, style, LMP_SIZE_COLS, 0, 0);
+   if (tmp) *ncols = *tmp;
    return;
-
 }
 
 /* vim: set ts=3 sts=3 expandtab: */

examples/COUPLE/fortran2/LAMMPS-wrapper.h

@@ -12,8 +12,8 @@
 ------------------------------------------------------------------------- */
 
 /* ------------------------------------------------------------------------
-    Contributing author:  Karl D. Hammond <karlh@ugcs.caltech.edu>
-                          University of Tennessee, Knoxville (USA), 2012
+    Contributing author:  Karl D. Hammond <hammondkd@missouri.edu>
+                          University of Missouri (USA), 2012
 ------------------------------------------------------------------------- */
 
 /* This is set of "wrapper" functions to assist LAMMPS.F90, which itself

examples/COUPLE/fortran2/LAMMPS.F90

@@ -1292,7 +1292,7 @@ contains !! Wrapper functions local to this module {{{1
       Cname = string2Cstring (name)
       Ccount = size(data) / natoms
       if ( Ccount /= 1 .and. Ccount /= 3 ) &
-         call lammps_error_all (ptr, FLERR, 'lammps_gather_atoms requires&
+         call lammps_error_all (ptr, FLERR, 'lammps_scatter_atoms requires&
             & count to be either 1 or 3')
       Fdata = data
       Cdata = C_loc (Fdata(1))
@@ -1355,7 +1355,7 @@ contains !! Wrapper functions local to this module {{{1
       Cname = string2Cstring (name)
       Ccount = size(data) / ndata
       if ( Ccount /= 1 .and. Ccount /= 3 ) &
-         call lammps_error_all (ptr, FLERR, 'lammps_gather_atoms requires&
+         call lammps_error_all (ptr, FLERR, 'lammps_scatter_atoms requires&
             & count to be either 1 or 3')
       Fdata = data
       Cdata = C_loc (Fdata(1))

examples/COUPLE/fortran2/Makefile

@@ -14,7 +14,7 @@ CXXLIB = -lstdc++    # replace with your C++ runtime libs
 # Flags for Fortran compiler, C++ compiler, and C preprocessor, respectively
 FFLAGS = -O2 -fPIC
 CXXFLAGS = -O2 -fPIC
-CPPFLAGS = -DOMPI_SKIP_MPICXX=1 -DMPICH_SKIP_MPICXX -DLAMMPS_LIB_MPI
+CPPFLAGS = -DOMPI_SKIP_MPICXX=1 -DMPICH_SKIP_MPICXX
 
 all : liblammps_fortran.a liblammps_fortran.so
 

examples/COUPLE/fortran2/README

@@ -11,9 +11,8 @@ This interface was created by Karl Hammond who you can contact with
 questions:
 
 Karl D. Hammond
-University of Tennessee, Knoxville
-karlh at ugcs.caltech.edu
-karlh at utk.edu
+University of Missouri
+hammondkd at missouri.edu
 
 -------------------------------------
 

examples/COUPLE/fortran_dftb/LAMMPS-wrapper.cpp

@@ -12,8 +12,8 @@
 ------------------------------------------------------------------------- */
 
 /* ------------------------------------------------------------------------
-    Contributing author:  Karl D. Hammond <karlh@ugcs.caltech.edu>
-                          University of Tennessee, Knoxville (USA), 2012
+    Contributing author:  Karl D. Hammond <hammondkd@missouri.edu>
+                          University of Missouri (USA), 2012
 ------------------------------------------------------------------------- */
 
 /* This is set of "wrapper" functions to assist LAMMPS.F90, which itself
@@ -23,6 +23,7 @@
 
 #include <mpi.h>
 #include "LAMMPS-wrapper.h"
+#define LAMMPS_LIB_MPI 1
 #include <library.h>
 #include <lammps.h>
 #include <atom.h>
@@ -56,181 +57,40 @@ void lammps_error_all (void *ptr, const char *file, int line, const char *str)
 
 int lammps_extract_compute_vectorsize (void *ptr, char *id, int style)
 {
-   class LAMMPS *lmp = (class LAMMPS *) ptr;
-   int icompute = lmp->modify->find_compute(id);
-   if ( icompute < 0 ) return 0;
-   class Compute *compute = lmp->modify->compute[icompute];
-
-   if ( style == 0 )
-   {
-      if ( !compute->vector_flag )
-         return 0;
-      else
-         return compute->size_vector;
-   }
-   else if ( style == 1 )
-   {
-      return lammps_get_natoms (ptr);
-   }
-   else if ( style == 2 )
-   {
-      if ( !compute->local_flag )
-         return 0;
-      else
-         return compute->size_local_rows;
-   }
-   else
-      return 0;
+   int *size;
+   size = (int *) lammps_extract_compute(ptr, id, style, LMP_SIZE_VECTOR);
+   if (size) return *size;
+   return 0;
 }
 
 void lammps_extract_compute_arraysize (void *ptr, char *id, int style,
       int *nrows, int *ncols)
 {
-   class LAMMPS *lmp = (class LAMMPS *) ptr;
-   int icompute = lmp->modify->find_compute(id);
-   if ( icompute < 0 )
-   {
-      *nrows = 0;
-      *ncols = 0;
-   }
-   class Compute *compute = lmp->modify->compute[icompute];
-
-   if ( style == 0 )
-   {
-      if ( !compute->array_flag )
-      {
-         *nrows = 0;
-         *ncols = 0;
-      }
-      else
-      {
-         *nrows = compute->size_array_rows;
-         *ncols = compute->size_array_cols;
-      }
-   }
-   else if ( style == 1 )
-   {
-      if ( !compute->peratom_flag )
-      {
-         *nrows = 0;
-         *ncols = 0;
-      }
-      else
-      {
-         *nrows = lammps_get_natoms (ptr);
-         *ncols = compute->size_peratom_cols;
-      }
-   }
-   else if ( style == 2 )
-   {
-      if ( !compute->local_flag )
-      {
-         *nrows = 0;
-         *ncols = 0;
-      }
-      else
-      {
-         *nrows = compute->size_local_rows;
-         *ncols = compute->size_local_cols;
-      }
-   }
-   else
-   {
-      *nrows = 0;
-      *ncols = 0;
-   }
-
+   int *tmp;
+   tmp = (int *) lammps_extract_compute(ptr, id, style, LMP_SIZE_ROWS);
+   if (tmp) *nrows = *tmp;
+   tmp = (int *) lammps_extract_compute(ptr, id, style, LMP_SIZE_COLS);
+   if (tmp) *ncols = *tmp;
    return;
 }
 
 int lammps_extract_fix_vectorsize (void *ptr, char *id, int style)
 {
-   class LAMMPS *lmp = (class LAMMPS *) ptr;
-   int ifix = lmp->modify->find_fix(id);
-   if ( ifix < 0 ) return 0;
-   class Fix *fix = lmp->modify->fix[ifix];
-
-   if ( style == 0 )
-   {
-      if ( !fix->vector_flag )
-         return 0;
-      else
-         return fix->size_vector;
-   }
-   else if ( style == 1 )
-   {
-      return lammps_get_natoms (ptr);
-   }
-   else if ( style == 2 )
-   {
-      if ( !fix->local_flag )
-         return 0;
-      else
-         return fix->size_local_rows;
-   }
-   else
-      return 0;
+   int *size;
+   size = (int *) lammps_extract_fix(ptr, id, style, LMP_SIZE_VECTOR, 0, 0);
+   if (size) return *size;
+   return 0;
 }
 
 void lammps_extract_fix_arraysize (void *ptr, char *id, int style,
       int *nrows, int *ncols)
 {
-   class LAMMPS *lmp = (class LAMMPS *) ptr;
-   int ifix = lmp->modify->find_fix(id);
-   if ( ifix < 0 )
-   {
-      *nrows = 0;
-      *ncols = 0;
-   }
-   class Fix *fix = lmp->modify->fix[ifix];
-
-   if ( style == 0 )
-   {
-      if ( !fix->array_flag )
-      {
-         *nrows = 0;
-         *ncols = 0;
-      }
-      else
-      {
-         *nrows = fix->size_array_rows;
-         *ncols = fix->size_array_cols;
-      }
-   }
-   else if ( style == 1 )
-   {
-      if ( !fix->peratom_flag )
-      {
-         *nrows = 0;
-         *ncols = 0;
-      }
-      else
-      {
-         *nrows = lammps_get_natoms (ptr);
-         *ncols = fix->size_peratom_cols;
-      }
-   }
-   else if ( style == 2 )
-   {
-      if ( !fix->local_flag )
-      {
-         *nrows = 0;
-         *ncols = 0;
-      }
-      else
-      {
-         *nrows = fix->size_local_rows;
-         *ncols = fix->size_local_cols;
-      }
-   }
-   else
-   {
-      *nrows = 0;
-      *ncols = 0;
-   }
-
+   int *tmp;
+   tmp = (int *) lammps_extract_fix(ptr, id, style, LMP_SIZE_ROWS, 0, 0);
+   if (tmp) *nrows = *tmp;
+   tmp = (int *) lammps_extract_fix(ptr, id, style, LMP_SIZE_COLS, 0, 0);
+   if (tmp) *ncols = *tmp;
    return;
-
 }
 
 /* vim: set ts=3 sts=3 expandtab: */

examples/COUPLE/fortran_dftb/LAMMPS-wrapper.h

@@ -12,8 +12,8 @@
 ------------------------------------------------------------------------- */
 
 /* ------------------------------------------------------------------------
-    Contributing author:  Karl D. Hammond <karlh@ugcs.caltech.edu>
-                          University of Tennessee, Knoxville (USA), 2012
+    Contributing author:  Karl D. Hammond <hammondkd@missouri.edu>
+                          University of Missouri (USA), 2012
 ------------------------------------------------------------------------- */
 
 /* This is set of "wrapper" functions to assist LAMMPS.F90, which itself

examples/COUPLE/fortran_dftb/LAMMPS-wrapper2.cpp

@@ -12,8 +12,7 @@
 ------------------------------------------------------------------------- */
 
 /* ------------------------------------------------------------------------
-    Contributing author:  Karl D. Hammond <karlh@ugcs.caltech.edu>
-                          University of Tennessee, Knoxville (USA), 2012
+    Contributing author:  Nir Goldman, LLNL <ngoldman@llnl.gov>, 2016
 ------------------------------------------------------------------------- */
 
 /* This is set of "wrapper" functions to assist LAMMPS.F90, which itself

examples/COUPLE/fortran_dftb/LAMMPS-wrapper2.h

@@ -12,7 +12,7 @@
 ------------------------------------------------------------------------- */
 
 /* ------------------------------------------------------------------------
-    Contributing author:  Nir Goldman, ngoldman@llnl.gov, Oct. 19th, 2016
+    Contributing author:  Nir Goldman, LLNL <ngoldman@llnl.gov>, 2016
 ------------------------------------------------------------------------- */
 
 /* This is set of "wrapper" functions to assist LAMMPS.F90, which itself

examples/COUPLE/fortran_dftb/LAMMPS.F90

@@ -12,8 +12,8 @@
 !--------------------------------------------------------------------------
 
 !! ------------------------------------------------------------------------
-!   Contributing author:  Karl D. Hammond <karlh@ugcs.caltech.edu>
-!                         University of Tennessee, Knoxville (USA), 2012
+!   Contributing author:  Karl D. Hammond <hammondkd@missouri.edu>
+!                         University of Missouri (USA), 2012
 !--------------------------------------------------------------------------
 
 !! LAMMPS, a Fortran 2003 module containing an interface between Fortran

examples/ELASTIC_T/BORN_MATRIX/Argon/Analytical/compute_born.py

@@ -1,7 +1,6 @@
 #!/usr/bin/env python3
 # -*- coding: utf-8 -*-
 
-import sys
 import numpy as np
 
 def reduce_Born(Cf):

examples/ELASTIC_T/BORN_MATRIX/Argon/Numdiff/compute_born.py

@@ -1,7 +1,6 @@
 #!/usr/bin/env python3
 # -*- coding: utf-8 -*-
 
-import sys
 import numpy as np
 
 def reduce_Born(Cf):

examples/ELASTIC_T/BORN_MATRIX/Silicon/elastic_utils.py

@@ -1,5 +1,5 @@
 import numpy as np
-from lammps import lammps, LAMMPS_INT, LMP_STYLE_GLOBAL, LMP_VAR_EQUAL, LMP_VAR_ATOM
+from lammps import lammps, LMP_VAR_EQUAL
 
 # method for rotating elastic constants
 

examples/PACKAGES/manybody_table/README

@@ -0,0 +1,56 @@
+Three examples inputs for pair styles threebody/table (in.spce and
+in.spce2) and sw/angle/table (in.spce_sw).  All inputs are for the
+simulation of coarse-grained SPC/E water.
+
+A water molecule is represented by one coarse-grained (CG) bead.
+
+For the two threebody/table examples the three-body (force) tables are
+in the files 1-1-1.table and 1-1-2.table. These have been parametrized
+with the kernel-based machine learning (ML) with the VOTCA package
+(https://gitlab.mpcdf.mpg.de/votca/votca).  For a example on the
+parametrization, have a look at
+https://gitlab.mpcdf.mpg.de/votca/votca/-/tree/master/csg-examples/guide
+and
+https://gitlab.mpcdf.mpg.de/votca/votca/-/tree/master/csg-examples/ml.
+
+In both cases, the parametrization is done according to a sample system,
+using the three-body forces of a Stillinger-Weber potential with
+tabulated angular forces (sw/angle/table) (see in.spce_sw). These then
+are learned with the covariant meshing technique with the settings files
+used in
+https://gitlab.mpcdf.mpg.de/votca/votca/-/tree/master/csg-examples/ml/3body/with_binning.
+
+The first example, in.spce uses the LAMMPS data file (data.spce) with
+the starting configuration of 1000 CG water molecules, and a threebody
+file (spce.3b) which loads the 1-1-1.table file.
+
+A hybrid/overlay pair style is used to sum a tabulated pairwise
+interaction (table_CG_CG.txt) with the tabulated threebody interactions.
+The tabulated pair interaction is the effectively the same as in the
+what is used by the in.spce_sw input using sw/angle/table pair style.
+
+IMPORTANT NOTE: The threebody tables are parameterized without storing
+energies (the last column of the threebody table files is zero).  This
+is due to a current limitation of the paramerization procedure.
+
+This in.spce2 example uses the data.spce2 file and the threebody input
+spce2.3b.  This is essentially the same simulation as in in.spce only
+the atom type of the first 100 CG water molecules has been changed from
+1 to 2.  This is done to demonstrate how to run a simulation with
+different atom types.
+
+For this (artificial) two-element simulation, the threebody file now
+contain 8 entries for: type1 type1 type1, type1 type1 type2, type1 type2
+type1, type1 type2 type2, type2 type1 type1, type2 type1 type2, type2
+type2 type1, type2 type2 type2.  Each entry has the same structure as
+above. However, entries where the second and the third element are
+different require a different force table (1-1-2.table) instead of
+(1-1-1.table).  1-1-2.table contains exactly the force constants as
+1-1-1.table.  However it has to have the asymmetric structure where both
+interparticle distances (r_ij and r_ik) are varied from rmin to rmax and
+therefore contains "M = 2 * N * N * N" (2 * 12 * 12 * 12 = 3456)
+entries.
+
+The third example, in.spce_sw, contains the analytical twobody interactions
+and replaces the threebody term of the Stillinger-Weber potential with an
+angle/table style potential  which is stored in the table_CG_CG_CG.txt file.