Merge pull request #1947 from akohlmey/next_lammps_version

Step version string for next patch release

.github/CONTRIBUTING.md

@@ -73,7 +73,7 @@ Here is a checklist of steps you need to follow to submit a single file or user
 * If you want your contribution to be added as a user-contributed feature, and it is a single file (actually a `<name>.cpp` and `<name>.h` file) it can be rapidly added to the USER-MISC directory. Include the one-line entry to add to the USER-MISC/README file in that directory, along with the 2 source files. You can do this multiple times if you wish to contribute several individual features.
 * If you want your contribution to be added as a user-contribution and it is several related features, it is probably best to make it a user package directory with a name like USER-FOO. In addition to your new files, the directory should contain a README text file. The README should contain your name and contact information and a brief description of what your new package does. If your files depend on other LAMMPS style files also being installed (e.g. because your file is a derived class from the other LAMMPS class), then an Install.sh file is also needed to check for those dependencies. See other README and Install.sh files in other USER directories as examples. Send us a tarball of this USER-FOO directory.
 * Your new source files need to have the LAMMPS copyright, GPL notice, and your name and email address at the top, like other user-contributed LAMMPS source files. They need to create a class that is inside the LAMMPS namespace. If the file is for one of the USER packages, including USER-MISC, then we are not as picky about the coding style (see above). I.e. the files do not need to be in the same stylistic format and syntax as other LAMMPS files, though that would be nice for developers as well as users who try to read your code.
-* You **must** also create or extend a documentation file for each new command or style you are adding to LAMMPS. For simplicity and convenience, the documentation of groups of closely related commands or styles may be combined into a single file. This will be one file for a single-file feature. For a package, it might be several files. These are files in the [reStructuredText](https://docutils.sourceforge.io/rst.html) markup language, that are then converted to HTML and PDF. The tools for this conversion are included in the source distribution, and the translation can be as simple as doing "make html pdf" in the doc folder. Thus the documentation source files must be in the same format and style as other `<name>.rst` files in the lammps/doc/src directory for similar commands and styles; use one or more of them as a starting point. An introduction to reStructuredText can be found at [https://docutils.sourceforge.io/docs/user/rst/quickstart.html](https://docutils.sourceforge.io/docs/user/rst/quickstart.html). As appropriate, the text files can include mathematical expressions in MathJAX markup or links to equations (see doc/Eqs/*.tex for examples, we auto-create the associated JPG files), or figures (see doc/JPG for examples), or even additional PDF files with further details (see doc/PDF for examples). The doc page should also include literature citations as appropriate; see the bottom of doc/fix_nh.rst for examples and the earlier part of the same file for how to format the cite itself. The "Restrictions" section of the doc page should indicate that your command is only available if LAMMPS is built with the appropriate USER-MISC or USER-FOO package. See other user package doc files for examples of how to do this. The prerequisite for building the HTML format files are Python 3.x and virtualenv. Please run at least `make html` and `make spelling` and carefully inspect and proofread the resulting HTML format doc page as well as the output produced to the screen. Make sure that all spelling errors are fixed or the necessary false positives are added to the `doc/utils/sphinx-config/false_positives.txt` file.  For new styles, those usually also need to be added to lists on the respective overview pages. This can be checked for also with `make style_check`.
+* You **must** also create or extend a documentation file for each new command or style you are adding to LAMMPS. For simplicity and convenience, the documentation of groups of closely related commands or styles may be combined into a single file. This will be one file for a single-file feature. For a package, it might be several files. These are files in the [reStructuredText](https://docutils.sourceforge.io/rst.html) markup language, that are then converted to HTML and PDF. The tools for this conversion are included in the source distribution, and the translation can be as simple as doing "make html pdf" in the doc folder. Thus the documentation source files must be in the same format and style as other `<name>.rst` files in the lammps/doc/src directory for similar commands and styles; use one or more of them as a starting point. An introduction to reStructuredText can be found at [https://docutils.sourceforge.io/docs/user/rst/quickstart.html](https://docutils.sourceforge.io/docs/user/rst/quickstart.html). The text files can include mathematical expressions and symbol in ".. math::" sections or ":math:" expressions or figures (see doc/JPG for examples), or even additional PDF files with further details (see doc/PDF for examples). The doc page should also include literature citations as appropriate; see the bottom of doc/fix_nh.rst for examples and the earlier part of the same file for how to format the cite itself. The "Restrictions" section of the doc page should indicate that your command is only available if LAMMPS is built with the appropriate USER-MISC or USER-FOO package. See other user package doc files for examples of how to do this. The prerequisite for building the HTML format files are Python 3.x and virtualenv. Please run at least `make html`, `make pdf` and `make spelling` and carefully inspect and proofread the resulting HTML format doc page as well as the output produced to the screen. Make sure that all spelling errors are fixed or the necessary false positives are added to the `doc/utils/sphinx-config/false_positives.txt` file.  For new styles, those usually also need to be added to lists on the respective overview pages. This can be checked for also with `make style_check`.
 * For a new package (or even a single command) you should include one or more example scripts demonstrating its use. These should run in no more than a couple minutes, even on a single processor, and not require large data files as input. See directories under examples/USER for examples of input scripts other users provided for their packages. These example inputs are also required for validating memory accesses and testing for memory leaks with valgrind
 * If there is a paper of yours describing your feature (either the algorithm/science behind the feature itself, or its initial usage, or its implementation in LAMMPS), you can add the citation to the *.cpp source file. See src/USER-EFF/atom_vec_electron.cpp for an example. A LaTeX citation is stored in a variable at the top of the file and a single line of code that references the variable is added to the constructor of the class. Whenever a user invokes your feature from their input script, this will cause LAMMPS to output the citation to a log.cite file and prompt the user to examine the file. Note that you should only use this for a paper you or your group authored. E.g. adding a cite in the code for a paper by Nose and Hoover if you write a fix that implements their integrator is not the intended usage. That kind of citation should just be in the doc page you provide.
 

cmake/CMakeLists.txt

@@ -2,7 +2,7 @@
 # CMake build system
 # This file is part of LAMMPS
 # Created by Christoph Junghans and Richard Berger
-cmake_minimum_required(VERSION 2.8.12)
+cmake_minimum_required(VERSION 3.10)
 
 project(lammps CXX)
 set(SOVERSION 0)
@@ -51,39 +51,35 @@ check_for_autogen_files(${LAMMPS_SOURCE_DIR})
 include(CheckCCompilerFlag)
 include(CheckIncludeFileCXX)
 
+# set required compiler flags and compiler/CPU arch specific optimizations
 if(${CMAKE_CXX_COMPILER_ID} STREQUAL "Intel")
-  set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -restrict -std=c++11")
+  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -restrict")
+  if(CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.3 OR CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.4)
+    set(CMAKE_TUNE_DEFAULT "-xCOMMON-AVX512")
+  else()
+    set(CMAKE_TUNE_DEFAULT "-xHost")
+  endif()
 endif()
 
-option(DISABLE_CXX11_REQUIREMENT "Disable check that requires C++11 for compiling LAMMPS" OFF)
-if(DISABLE_CXX11_REQUIREMENT)
-  add_definitions(-DLAMMPS_CXX98)
-# else()
-#  set(CMAKE_CXX_STANDARD 11)
+if(${CMAKE_CXX_COMPILER_ID} STREQUAL "GNU")
+  set(CMAKE_TUNE_DEFAULT "-ffast-math -march=native")
 endif()
 
-# GNU compiler features
+if(${CMAKE_CXX_COMPILER_ID} STREQUAL "Clang")
+  set(CMAKE_TUNE_DEFAULT "-ffast-math -march=native")
+endif()
+
+# we require C++11
+set(CMAKE_CXX_STANDARD 11)
+set(CMAKE_CXX_STANDARD_REQUIRED ON)
+
+# GNU compiler specific features for testing
 if (${CMAKE_CXX_COMPILER_ID} STREQUAL "GNU")
-  option(ENABLE_COVERAGE "Enable code coverage" OFF)
+  option(ENABLE_COVERAGE "Enable collecting code coverage data" OFF)
   mark_as_advanced(ENABLE_COVERAGE)
   if(ENABLE_COVERAGE)
     set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} --coverage")
   endif()
-  option(ENABLE_SANITIZE_ADDRESS "Enable address sanitizer" OFF)
-  mark_as_advanced(ENABLE_SANITIZE_ADDRESS)
-  if(ENABLE_SANITIZE_ADDRESS)
-    set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fsanitize=address")
-  endif()
-  option(ENABLE_SANITIZE_UNDEFINED "Enable undefined behavior sanitizer" OFF)
-  mark_as_advanced(ENABLE_SANITIZE_UNDEFINED)
-  if(ENABLE_SANITIZE_UNDEFINED)
-    set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fsanitize=undefined")
-  endif()
-  option(ENABLE_SANITIZE_THREAD "Enable thread sanitizer" OFF)
-  mark_as_advanced(ENABLE_SANITIZE_THREAD)
-  if(ENABLE_SANITIZE_THREAD)
-    set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fsanitize=thread")
-  endif()
 endif()
 
 ########################################################################
@@ -128,12 +124,12 @@ set(LAMMPS_API_DEFINES)
 set(DEFAULT_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE
   GRANULAR KSPACE LATTE MANYBODY MC MESSAGE MISC MOLECULE PERI POEMS QEQ
   REPLICA RIGID SHOCK SPIN SNAP SRD KIM PYTHON MSCG MPIIO VORONOI
-  USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-MESO USER-CGSDK USER-COLVARS
+  USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-MESODPD USER-CGSDK USER-COLVARS
   USER-DIFFRACTION USER-DPD USER-DRUDE USER-EFF USER-FEP USER-H5MD USER-LB
   USER-MANIFOLD USER-MEAMC USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
-  USER-NETCDF USER-PHONON USER-PLUMED USER-PTM USER-QTB USER-REAXC
-  USER-SCAFACOS USER-SDPD USER-SMD USER-SMTBQ USER-SPH USER-TALLY USER-UEF
-  USER-VTK USER-QUIP USER-QMMM USER-YAFF USER-ADIOS)
+  USER-NETCDF USER-PHONON USER-PLUMED USER-PTM USER-QTB USER-REACTION
+  USER-REAXC USER-SCAFACOS USER-SDPD USER-SMD USER-SMTBQ USER-SPH USER-TALLY
+  USER-UEF USER-VTK USER-QUIP USER-QMMM USER-YAFF USER-ADIOS)
 set(ACCEL_PACKAGES USER-OMP KOKKOS OPT USER-INTEL GPU)
 foreach(PKG ${DEFAULT_PACKAGES} ${ACCEL_PACKAGES})
   option(PKG_${PKG} "Build ${PKG} Package" OFF)
@@ -171,17 +167,25 @@ if(PKG_USER-ADIOS)
   list(APPEND LAMMPS_LINK_LIBS adios2::adios2)
 endif()
 
-# do MPI detection after language activation, if MPI for these language is required
+# do MPI detection after language activation,
+# in case MPI for these languages is required
 set(MPI_CXX_SKIP_MPICXX TRUE)
 find_package(MPI QUIET)
 option(BUILD_MPI "Build MPI version" ${MPI_FOUND})
+
 if(BUILD_MPI)
-  find_package(MPI REQUIRED)
-  include_directories(${MPI_CXX_INCLUDE_PATH})
-  list(APPEND LAMMPS_LINK_LIBS ${MPI_CXX_LIBRARIES})
-  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)
-    add_definitions(-DLAMMPS_LONGLONG_TO_LONG)
+  # We use a non-standard procedure to compile with MPI on windows
+  if (CMAKE_SYSTEM_NAME STREQUAL Windows)
+    include(MPI4WIN)
+  else()
+    find_package(MPI REQUIRED)
+    include_directories(${MPI_CXX_INCLUDE_PATH})
+    add_definitions(-DMPICH_SKIP_MPICXX -DOMPI_SKIP_MPICXX=1)
+    list(APPEND LAMMPS_LINK_LIBS ${MPI_CXX_LIBRARIES})
+    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)
+      add_definitions(-DLAMMPS_LONGLONG_TO_LONG)
+    endif()
   endif()
 else()
   enable_language(C)
@@ -251,14 +255,15 @@ if(PKG_MSCG OR PKG_USER-ATC OR PKG_USER-AWPMD OR PKG_USER-QUIP OR PKG_LATTE)
   find_package(LAPACK)
   find_package(BLAS)
   if(NOT LAPACK_FOUND OR NOT BLAS_FOUND)
-    if(CMAKE_GENERATOR STREQUAL "Ninja")
-      status(FATAL_ERROR "Cannot build internal linear algebra library with Ninja build tool due to lack for Fortran support")
+    include(CheckGeneratorSupport)
+    if(NOT CMAKE_GENERATOR_SUPPORT_FORTRAN)
+      status(FATAL_ERROR "Cannot build internal linear algebra library as CMake build tool lacks Fortran support")
     endif()
     enable_language(Fortran)
     file(GLOB LAPACK_SOURCES ${LAMMPS_LIB_SOURCE_DIR}/linalg/[^.]*.[fF])
     add_library(linalg STATIC ${LAPACK_SOURCES})
-    set(BLAS_LIBRARIES linalg)
-    set(LAPACK_LIBRARIES linalg)
+    set(BLAS_LIBRARIES "$<TARGET_FILE:linalg>")
+    set(LAPACK_LIBRARIES "$<TARGET_FILE:linalg>")
   else()
     list(APPEND LAPACK_LIBRARIES ${BLAS_LIBRARIES})
   endif()
@@ -337,11 +342,11 @@ include(Packages/MESSAGE)
 include(Packages/MSCG)
 include(Packages/COMPRESS)
 
-# the windows version of LAMMPS requires a couple extra libraries
-if(${CMAKE_SYSTEM_NAME} STREQUAL "Windows")
-  list(APPEND LAMMPS_LINK_LIBS -lwsock32 -lpsapi)
+set(CMAKE_TUNE_FLAGS "${CMAKE_TUNE_DEFAULT}" CACHE STRING "Compiler specific optimization or instrumentation")
+set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${CMAKE_TUNE_FLAGS}")
+if(CMAKE_Fortran_COMPILER)
+  set(CMAKE_Fortran_FLAGS "${CMAKE_Fortran_FLAGS} ${CMAKE_TUNE_FLAGS}")
 endif()
-
 ########################################################################
 # Basic system tests (standard libraries, headers, functions, types)   #
 ########################################################################
@@ -355,9 +360,6 @@ endforeach(HEADER)
 set(MATH_LIBRARIES "m" CACHE STRING "math library")
 mark_as_advanced( MATH_LIBRARIES )
 include(CheckLibraryExists)
-if (CMAKE_VERSION VERSION_LESS "3.4")
-  enable_language(C) # check_library_exists isn't supported without a C compiler before v3.4
-endif()
 # RB: disabled this check because it breaks with KOKKOS CUDA enabled
 #foreach(FUNC sin cos)
 #  check_library_exists(${MATH_LIBRARIES} ${FUNC} "" FOUND_${FUNC}_${MATH_LIBRARIES})
@@ -428,6 +430,9 @@ foreach(SIMPLE_LIB POEMS USER-ATC USER-AWPMD USER-H5MD)
       ${LAMMPS_LIB_SOURCE_DIR}/${PKG_LIB}/[^.]*.c
       ${LAMMPS_LIB_SOURCE_DIR}/${PKG_LIB}/[^.]*.cpp)
     add_library(${PKG_LIB} STATIC ${${PKG_LIB}_SOURCES})
+    if(LAMMPS_USE_MPI4WIN)
+      add_dependencies(${PKG_LIB} mpi4win_build)
+    endif()
     list(APPEND LAMMPS_LINK_LIBS ${PKG_LIB})
     if(PKG_LIB STREQUAL awpmd)
       target_include_directories(awpmd PUBLIC ${LAMMPS_LIB_SOURCE_DIR}/awpmd/systems/interact ${LAMMPS_LIB_SOURCE_DIR}/awpmd/ivutils/include)
@@ -465,6 +470,18 @@ include(Packages/OPT)
 include(Packages/USER-INTEL)
 include(Packages/GPU)
 
+######################################################################
+# the windows version of LAMMPS requires a couple extra libraries
+# and the MPI library - if use - has to be linked right before those
+# and after everything else that is compiled locally
+######################################################################
+if(${CMAKE_SYSTEM_NAME} STREQUAL "Windows")
+  if(LAMMPS_USE_MPI4WIN)
+    list(APPEND LAMMPS_LINK_LIBS ${MPI4WIN_LIBRARIES})
+  endif()
+  list(APPEND LAMMPS_LINK_LIBS -lwsock32 -lpsapi)
+endif()
+
 ######################################################
 # Generate style headers based on global list of
 # styles registered during package selection
@@ -586,14 +603,14 @@ if(BUILD_TOOLS)
   add_executable(binary2txt ${LAMMPS_TOOLS_DIR}/binary2txt.cpp)
   install(TARGETS binary2txt DESTINATION ${CMAKE_INSTALL_BINDIR})
 
-  # ninja-build currently does not support fortran. thus we skip building this tool
-  if(CMAKE_GENERATOR STREQUAL "Ninja")
-    message(STATUS "Skipping building 'chain.x' with Ninja build tool due to lack of Fortran support")
-  else()
+  include(CheckGeneratorSupport)
+  if(CMAKE_GENERATOR_SUPPORT_FORTRAN)
     enable_language(Fortran)
     add_executable(chain.x ${LAMMPS_TOOLS_DIR}/chain.f)
     target_link_libraries(chain.x ${CMAKE_Fortran_IMPLICIT_LINK_LIBRARIES})
     install(TARGETS chain.x DESTINATION ${CMAKE_INSTALL_BINDIR})
+  else()
+    message(WARNING "CMake build doesn't support fortran, skipping building 'chain.x'")
   endif()
 
   enable_language(C)
@@ -685,6 +702,7 @@ feature_summary(DESCRIPTION "The following tools and libraries have been found a
 message(STATUS "<<< Build configuration >>>
    Build type       ${CMAKE_BUILD_TYPE}
    Install path     ${CMAKE_INSTALL_PREFIX}
+   Generator        ${CMAKE_GENERATOR} using ${CMAKE_MAKE_PROGRAM}
    Compilers and Flags:
    C++ Compiler     ${CMAKE_CXX_COMPILER}
        Type         ${CMAKE_CXX_COMPILER_ID}
@@ -717,7 +735,7 @@ else()
 endif()
 message(STATUS "Link libraries: ${LAMMPS_LINK_LIBS}")
 if(BUILD_MPI)
-  message(STATUS "Using MPI with headers in ${MPI_CXX_INCLUDE_PATH} and ${MPI_CXX_LIBRARIES}")
+  message(STATUS "Using MPI with headers in ${MPI_CXX_INCLUDE_PATH} and these libraries: ${MPI_CXX_LIBRARIES};${MPI_Fortran_LIBRARIES}")
 endif()
 if(PKG_GPU)
   message(STATUS "GPU API: ${GPU_API}")

cmake/Modules/CheckGeneratorSupport.cmake

@@ -0,0 +1,21 @@
+# ninja-build<1.10 does not support fortran.
+if(CMAKE_GENERATOR STREQUAL "Ninja")
+  set(CMAKE_GENERATOR_SUPPORT_FORTRAN FALSE)
+  execute_process(COMMAND "${CMAKE_MAKE_PROGRAM}" --version
+    OUTPUT_VARIABLE NINJA_VERSION
+    OUTPUT_STRIP_TRAILING_WHITESPACE
+    RESULT_VARIABLE _Ninja_version_result
+  )
+  if(_Ninja_version_result)
+    message(WARNING "Unable to determine ninja version: ${_Ninja_version_result}, assuming fortran isn't supported")
+  elseif(NINJA_VERSION VERSION_LESS "1.10")
+    message(WARNING "Ninja build tool too old, to compile Fortran code, please install ninja-1.10 or newer")
+  else()
+    set(CMAKE_GENERATOR_SUPPORT_FORTRAN TRUE)
+  endif()
+else()
+  set(CMAKE_GENERATOR_SUPPORT_FORTRAN TRUE)
+  if(NOT CMAKE_GENERATOR STREQUAL "Unix Makefiles")
+    message(WARNING "Assuming fortran is supported for ${CMAKE_GENERATOR}")
+  endif()
+endif()

cmake/Modules/MPI4WIN.cmake

@@ -0,0 +1,23 @@
+# Download and configure custom MPICH files for Windows
+message(STATUS "Downloading and configuring MPICH-1.4.1 for Windows")
+include(ExternalProject)
+if (CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64")
+  ExternalProject_Add(mpi4win_build
+    URL https://download.lammps.org/thirdparty/mpich2-win64-devel.tar.gz
+    URL_MD5 4939fdb59d13182fd5dd65211e469f14
+    CONFIGURE_COMMAND "" BUILD_COMMAND "" INSTALL_COMMAND ""
+    BUILD_BYPRODUCTS <SOURCE_DIR>/lib/libmpi.a)
+else()
+  ExternalProject_Add(mpi4win_build
+    URL https://download.lammps.org/thirdparty/mpich2-win32-devel.tar.gz
+    URL_MD5 a61d153500dce44e21b755ee7257e031
+    CONFIGURE_COMMAND "" BUILD_COMMAND "" INSTALL_COMMAND ""
+    BUILD_BYPRODUCTS <SOURCE_DIR>/lib/libmpi.a)
+endif()
+
+ExternalProject_get_property(mpi4win_build SOURCE_DIR)
+add_definitions(-DMPICH_SKIP_MPICXX)
+include_directories("${SOURCE_DIR}/include")
+set(MPI4WIN_LIBRARIES "${SOURCE_DIR}/lib/libmpi.a")
+list(APPEND LAMMPS_DEPS mpi4win_build)
+set(LAMMPS_USE_MPI4WIN ON)

cmake/Modules/Packages/GPU.cmake

@@ -1,7 +1,4 @@
 if(PKG_GPU)
-    if (CMAKE_VERSION VERSION_LESS "3.1")
-      message(FATAL_ERROR "For the GPU package you need at least cmake-3.1")
-    endif()
     set(GPU_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/GPU)
     set(GPU_SOURCES ${GPU_SOURCES_DIR}/gpu_extra.h
                     ${GPU_SOURCES_DIR}/fix_gpu.h
@@ -111,6 +108,9 @@ if(PKG_GPU)
       endif()
 
       list(APPEND LAMMPS_LINK_LIBS gpu)
+      if(LAMMPS_USE_MPI4WIN)
+        add_dependencies(gpu mpi4win_build)
+      endif()
 
       add_executable(nvc_get_devices ${LAMMPS_LIB_SOURCE_DIR}/gpu/geryon/ucl_get_devices.cpp)
       target_compile_definitions(nvc_get_devices PRIVATE -DUCL_CUDADR)
@@ -172,6 +172,9 @@ if(PKG_GPU)
       target_compile_definitions(gpu PRIVATE -DUSE_OPENCL)
 
       list(APPEND LAMMPS_LINK_LIBS gpu)
+      if(LAMMPS_USE_MPI4WIN)
+        add_dependencies(gpu mpi4win_build)
+      endif()
 
       add_executable(ocl_get_devices ${LAMMPS_LIB_SOURCE_DIR}/gpu/geryon/ucl_get_devices.cpp)
       target_compile_definitions(ocl_get_devices PRIVATE -DUCL_OPENCL)

cmake/Modules/Packages/KIM.cmake

@@ -34,30 +34,30 @@ if(PKG_KIM)
   endif()
   option(DOWNLOAD_KIM "Download KIM-API from OpenKIM instead of using an already installed one" ${DOWNLOAD_KIM_DEFAULT})
   if(DOWNLOAD_KIM)
-    if(CMAKE_GENERATOR STREQUAL "Ninja")
-      message(FATAL_ERROR "Cannot build downloaded KIM-API library with Ninja build tool")
-    endif()
     message(STATUS "KIM-API download requested - we will build our own")
-    include(CheckLanguage)
+    # Workaround for cross compilation with MinGW where ${CMAKE_INSTALL_LIBDIR}
+    # is a full path, so we need to remove the prefix
+    string(REPLACE ${CMAKE_INSTALL_PREFIX} "" _KIM_LIBDIR ${CMAKE_INSTALL_LIBDIR})
     include(ExternalProject)
     enable_language(C)
-    check_language(Fortran)
-    if(NOT CMAKE_Fortran_COMPILER)
-      message(FATAL_ERROR "Compiling the KIM-API library requires a Fortran compiler")
-    endif()
+    enable_language(Fortran)
     ExternalProject_Add(kim_build
       URL https://s3.openkim.org/kim-api/kim-api-2.1.3.txz
       URL_MD5 6ee829a1bbba5f8b9874c88c4c4ebff8
       BINARY_DIR build
-      CMAKE_ARGS -DCMAKE_C_COMPILER=${CMAKE_C_COMPILER}
+      CMAKE_ARGS ${CMAKE_REQUEST_PIC}
+                 -DCMAKE_C_COMPILER=${CMAKE_C_COMPILER}
                  -DCMAKE_CXX_COMPILER=${CMAKE_CXX_COMPILER}
                  -DCMAKE_Fortran_COMPILER=${CMAKE_Fortran_COMPILER}
                  -DCMAKE_INSTALL_PREFIX=<INSTALL_DIR>
                  -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
+                 -DCMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM}
+                 -DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE}
+                 BUILD_BYPRODUCTS <INSTALL_DIR>/${_KIM_LIBDIR}/libkim-api${CMAKE_SHARED_LIBRARY_SUFFIX} 
       )
     ExternalProject_get_property(kim_build INSTALL_DIR)
     set(KIM-API_INCLUDE_DIRS ${INSTALL_DIR}/include/kim-api)
-    set(KIM-API_LDFLAGS ${INSTALL_DIR}/${CMAKE_INSTALL_LIBDIR}/libkim-api${CMAKE_SHARED_LIBRARY_SUFFIX})
+    set(KIM-API_LDFLAGS ${INSTALL_DIR}/${_KIM_LIBDIR}/libkim-api${CMAKE_SHARED_LIBRARY_SUFFIX})
     list(APPEND LAMMPS_DEPS kim_build)
   else()
     find_package(KIM-API ${KIM-API_MIN_VERSION} REQUIRED)

cmake/Modules/Packages/LATTE.cmake

@@ -8,13 +8,10 @@ if(PKG_LATTE)
   endif()
   option(DOWNLOAD_LATTE "Download the LATTE library instead of using an already installed one" ${DOWNLOAD_LATTE_DEFAULT})
   if(DOWNLOAD_LATTE)
-    if (CMAKE_VERSION VERSION_LESS "3.7") # due to SOURCE_SUBDIR
-      message(FATAL_ERROR "For downlading LATTE you need at least cmake-3.7")
-    endif()
-    if(CMAKE_GENERATOR STREQUAL "Ninja")
-      message(FATAL_ERROR "Cannot build downloaded LATTE library with Ninja build tool")
-    endif()
     message(STATUS "LATTE download requested - we will build our own")
+    # Workaround for cross compilation with MinGW where ${CMAKE_INSTALL_LIBDIR}
+    # is a full path, so we need to remove the prefix
+    string(REPLACE ${CMAKE_INSTALL_PREFIX} "" _LATTE_LIBDIR ${CMAKE_INSTALL_LIBDIR})
     include(ExternalProject)
     ExternalProject_Add(latte_build
       URL https://github.com/lanl/LATTE/archive/v1.2.1.tar.gz
@@ -24,15 +21,20 @@ if(PKG_LATTE)
       -DBLAS_LIBRARIES=${BLAS_LIBRARIES} -DLAPACK_LIBRARIES=${LAPACK_LIBRARIES}
       -DCMAKE_Fortran_COMPILER=${CMAKE_Fortran_COMPILER} -DCMAKE_Fortran_FLAGS=${CMAKE_Fortran_FLAGS}
       -DCMAKE_Fortran_FLAGS_${BTYPE}=${CMAKE_Fortran_FLAGS_${BTYPE}} -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
+      -DCMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM} -DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE}
+      BUILD_BYPRODUCTS <INSTALL_DIR>/${_LATTE_LIBDIR}/liblatte.a
     )
-    ExternalProject_get_property(latte_build INSTALL_DIR)
-    set(LATTE_LIBRARIES ${INSTALL_DIR}/${CMAKE_INSTALL_LIBDIR}/liblatte.a)
     list(APPEND LAMMPS_DEPS latte_build)
+    ExternalProject_get_property(latte_build INSTALL_DIR)
+    set(LATTE_LIBRARIES ${INSTALL_DIR}/${_LATTE_LIBDIR}/liblatte.a)
   else()
     find_package(LATTE)
     if(NOT LATTE_FOUND)
       message(FATAL_ERROR "LATTE library not found, help CMake to find it by setting LATTE_LIBRARY, or set DOWNLOAD_LATTE=ON to download it")
     endif()
   endif()
+  if(NOT LAPACK_FOUND)
+    add_dependencies(latte_build linalg)
+  endif()
   list(APPEND LAMMPS_LINK_LIBS ${LATTE_LIBRARIES} ${LAPACK_LIBRARIES})
 endif()

cmake/Modules/Packages/MSCG.cmake

@@ -8,12 +8,6 @@ if(PKG_MSCG)
   endif()
   option(DOWNLOAD_MSCG "Download MSCG library instead of using an already installed one)" ${DOWNLOAD_MSCG_DEFAULT})
   if(DOWNLOAD_MSCG)
-    if (CMAKE_VERSION VERSION_LESS "3.7") # due to SOURCE_SUBDIR
-      message(FATAL_ERROR "For downlading MSCG you need at least cmake-3.7")
-    endif()
-    if(CMAKE_GENERATOR STREQUAL "Ninja")
-      message(FATAL_ERROR "Cannot build downloaded MSCG library with Ninja build tool")
-    endif()
     include(ExternalProject)
     if(NOT LAPACK_FOUND)
       set(EXTRA_MSCG_OPTS "-DLAPACK_LIBRARIES=${CMAKE_CURRENT_BINARY_DIR}/liblinalg.a")
@@ -22,8 +16,17 @@ if(PKG_MSCG)
       URL https://github.com/uchicago-voth/MSCG-release/archive/1.7.3.1.tar.gz
       URL_MD5 8c45e269ee13f60b303edd7823866a91
       SOURCE_SUBDIR src/CMake
-      CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=<INSTALL_DIR> ${CMAKE_REQUEST_PIC} ${EXTRA_MSCG_OPTS}
-      BUILD_COMMAND make mscg INSTALL_COMMAND ""
+      CMAKE_ARGS ${CMAKE_REQUEST_PIC} ${EXTRA_MSCG_OPTS}
+                 -DCMAKE_C_COMPILER=${CMAKE_C_COMPILER}
+                 -DCMAKE_CXX_COMPILER=${CMAKE_CXX_COMPILER}
+                 -DCMAKE_Fortran_COMPILER=${CMAKE_Fortran_COMPILER}
+                 -DCMAKE_INSTALL_PREFIX=<INSTALL_DIR>
+                 -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
+                 -DCMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM}
+                 -DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE}
+      BUILD_COMMAND ${CMAKE_COMMAND} --build . --target mscg
+      INSTALL_COMMAND ""
+      BUILD_BYPRODUCTS <BINARY_DIR>/libmscg.a
       )
     ExternalProject_get_property(mscg_build BINARY_DIR)
     set(MSCG_LIBRARIES ${BINARY_DIR}/libmscg.a)

cmake/Modules/Packages/USER-COLVARS.cmake

@@ -5,22 +5,7 @@ if(PKG_USER-COLVARS)
   file(GLOB COLVARS_SOURCES ${COLVARS_SOURCE_DIR}/[^.]*.cpp)
 
   # Build Lepton by default
-  set(COLVARS_LEPTON_DEFAULT ON)
-  # but not if C++11 is disabled per user request
-  if(DEFINED DISABLE_CXX11_REQUIREMENT)
-    if(DISABLE_CXX11_REQUIREMENT)
-      set(COLVARS_LEPTON_DEFAULT OFF)
-    endif()
-  endif()
-
-  option(COLVARS_LEPTON "Build and link the Lepton library" ${COLVARS_LEPTON_DEFAULT})
-
-  # Verify that the user's choice is consistent
-  if(DEFINED DISABLE_CXX11_REQUIREMENT)
-    if((DISABLE_CXX11_REQUIREMENT) AND (COLVARS_LEPTON))
-      message(FATAL_ERROR "Building the Lepton library requires C++11 or later.")
-    endif()
-  endif()
+  option(COLVARS_LEPTON "Build and link the Lepton library" ON)
 
   if(COLVARS_LEPTON)
     set(LEPTON_DIR ${LAMMPS_LIB_SOURCE_DIR}/colvars/lepton)

cmake/Modules/Packages/USER-INTEL.cmake

@@ -74,11 +74,6 @@ if(PKG_USER-INTEL)
     add_definitions(-DLMP_INTEL_OFFLOAD)
   else()
     if(CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
-      if(CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.3 OR CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.4)
-        set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -xCOMMON-AVX512")
-      else()
-        set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -xHost")
-      endif()
       include(CheckCXXCompilerFlag)
       foreach(_FLAG -O2 -fp-model fast=2 -no-prec-div -qoverride-limits -qopt-zmm-usage=high -qno-offload -fno-alias -ansi-alias -restrict)
         check_cxx_compiler_flag("${__FLAG}" COMPILER_SUPPORTS${_FLAG})

cmake/Modules/Packages/USER-MOLFILE.cmake

@@ -1,8 +1,4 @@
 if(PKG_USER-MOLFILE)
-  if (CMAKE_VERSION VERSION_LESS "3.10") # due to INTERFACE without a library
-    message(FATAL_ERROR "For configuring USER-MOLFILE you need CMake 3.10 or later")
-  endif()
-
   set(MOLFILE_INCLUDE_DIRS "${LAMMPS_LIB_SOURCE_DIR}/molfile" CACHE STRING "Path to VMD molfile plugin headers")
   add_library(molfile INTERFACE)
   target_include_directories(molfile INTERFACE ${MOLFILE_INCLUDE_DIRS})

cmake/Modules/Packages/USER-NETCDF.cmake

@@ -1,6 +1,6 @@
 if(PKG_USER-NETCDF)
   # USER-NETCDF can use NetCDF, Parallel NetCDF (PNetCDF), or both. At least one necessary.
-  # NetCDF library enables dump sytle "netcdf", while PNetCDF enables dump style "netcdf/mpiio"
+  # NetCDF library enables dump style "netcdf", while PNetCDF enables dump style "netcdf/mpiio"
   find_package(NetCDF)
   if(NETCDF_FOUND)
     find_package(PNetCDF)

cmake/Modules/Packages/USER-PLUMED.cmake

@@ -29,9 +29,6 @@ if(PKG_USER-PLUMED)
 
   option(DOWNLOAD_PLUMED "Download Plumed package instead of using an already installed one" ${DOWNLOAD_PLUMED_DEFAULT})
   if(DOWNLOAD_PLUMED)
-    if(CMAKE_GENERATOR STREQUAL "Ninja")
-      message(FATAL_ERROR "Cannot build downloaded Plumed library with Ninja build tool")
-    endif()
     if(BUILD_MPI)
       set(PLUMED_CONFIG_MPI "--enable-mpi")
       set(PLUMED_CONFIG_CC  ${CMAKE_MPI_C_COMPILER})
@@ -47,6 +44,13 @@ if(PKG_USER-PLUMED)
       set(PLUMED_CONFIG_OMP "--disable-openmp")
     endif()
     message(STATUS "PLUMED download requested - we will build our own")
+    if(PLUMED_MODE STREQUAL "STATIC")
+      set(PLUMED_BUILD_BYPRODUCTS "<INSTALL_DIR>/lib/libplumed.a")
+    elseif(PLUMED_MODE STREQUAL "SHARED")
+      set(PLUMED_BUILD_BYPRODUCTS "<INSTALL_DIR>/lib/libplumed${CMAKE_SHARED_LIBRARY_SUFFIX};<INSTALL_DIR>/lib/libplumedKernel${CMAKE_SHARED_LIBRARY_SUFFIX}")
+    elseif(PLUMED_MODE STREQUAL "RUNTIME")
+      set(PLUMED_BUILD_BYPRODUCTS "<INSTALL_DIR>/lib/libplumedWrapper.a")
+    endif()
     include(ExternalProject)
     ExternalProject_Add(plumed_build
       URL https://github.com/plumed/plumed2/releases/download/v2.6.0/plumed-src-2.6.0.tgz
@@ -59,6 +63,7 @@ if(PKG_USER-PLUMED)
                                                ${PLUMED_CONFIG_OMP}
                                                CXX=${PLUMED_CONFIG_CXX}
                                                CC=${PLUMED_CONFIG_CC}
+      BUILD_BYPRODUCTS ${PLUMED_BUILD_BYPRODUCTS} 
     )
     ExternalProject_get_property(plumed_build INSTALL_DIR)
     set(PLUMED_INSTALL_DIR ${INSTALL_DIR})

cmake/Modules/Packages/USER-SCAFACOS.cmake

@@ -4,6 +4,7 @@ if(PKG_USER-SCAFACOS)
 
   find_package(GSL REQUIRED)
   find_package(PkgConfig QUIET)
+  find_package(MPI REQUIRED)
   set(DOWNLOAD_SCAFACOS_DEFAULT ON)
   if(PKG_CONFIG_FOUND)
     pkg_check_modules(SCAFACOS QUIET scafacos)
@@ -13,9 +14,6 @@ if(PKG_USER-SCAFACOS)
   endif()
   option(DOWNLOAD_SCAFACOS "Download ScaFaCoS library instead of using an already installed one" ${DOWNLOAD_SCAFACOS_DEFAULT})
   if(DOWNLOAD_SCAFACOS)
-    if(CMAKE_GENERATOR STREQUAL "Ninja")
-      message(FATAL_ERROR "Cannot build downloaded ScaFaCoS library with Ninja build tool")
-    endif()
     message(STATUS "ScaFaCoS download requested - we will build our own")
     include(ExternalProject)
     ExternalProject_Add(scafacos_build
@@ -29,6 +27,22 @@ if(PKG_USER-SCAFACOS)
                                                CXX=${CMAKE_MPI_CXX_COMPILER}
                                                CC=${CMAKE_MPI_C_COMPILER}
                                                F77=
+      BUILD_BYPRODUCTS 
+        <INSTALL_DIR>/lib/libfcs.a
+        <INSTALL_DIR>/lib/libfcs_direct.a
+        <INSTALL_DIR>/lib/libfcs_ewald.a
+        <INSTALL_DIR>/lib/libfcs_fmm.a
+        <INSTALL_DIR>/lib/libfcs_p2nfft.a
+        <INSTALL_DIR>/lib/libfcs_p3m.a
+        <INSTALL_DIR>/lib/libfcs_near.a
+        <INSTALL_DIR>/lib/libfcs_gridsort.a
+        <INSTALL_DIR>/lib/libfcs_resort.a
+        <INSTALL_DIR>/lib/libfcs_redist.a
+        <INSTALL_DIR>/lib/libfcs_common.a
+        <INSTALL_DIR>/lib/libfcs_pnfft.a
+        <INSTALL_DIR>/lib/libfcs_pfft.a
+        <INSTALL_DIR>/lib/libfcs_fftw3_mpi.a
+        <INSTALL_DIR>/lib/libfcs_fftw3.a
     )
     ExternalProject_get_property(scafacos_build INSTALL_DIR)
     set(SCAFACOS_BUILD_DIR ${INSTALL_DIR})

cmake/Modules/Packages/VORONOI.cmake

@@ -7,9 +7,6 @@ if(PKG_VORONOI)
   endif()
   option(DOWNLOAD_VORO "Download and compile the Voro++ library instead of using an already installed one" ${DOWNLOAD_VORO_DEFAULT})
   if(DOWNLOAD_VORO)
-    if(CMAKE_GENERATOR STREQUAL "Ninja")
-      message(FATAL_ERROR "Cannot build downloaded Voro++ library with Ninja build tool")
-    endif()
     message(STATUS "Voro++ download requested - we will build our own")
     include(ExternalProject)
 
@@ -29,6 +26,7 @@ if(PKG_VORONOI)
       URL https://download.lammps.org/thirdparty/voro++-0.4.6.tar.gz
       URL_MD5 2338b824c3b7b25590e18e8df5d68af9
       CONFIGURE_COMMAND "" BUILD_COMMAND make ${VORO_BUILD_OPTIONS} BUILD_IN_SOURCE 1 INSTALL_COMMAND ""
+      BUILD_BYPRODUCTS <SOURCE_DIR>/src/libvoro++.a
       )
     ExternalProject_get_property(voro_build SOURCE_DIR)
     set(VORO_LIBRARIES ${SOURCE_DIR}/src/libvoro++.a)

cmake/README.md

@@ -217,7 +217,7 @@ cmake -C ../cmake/presets/all_on.cmake -C ../cmake/presets/nolib.cmake -D PKG_GP
 </tr>
 <tr>
   <td><code>CMAKE_VERBOSE_MAKEFILE</code></td>
-  <td>Enable verbose output from Makefile builds (useful for debugging), the same can be achived by adding `VERBOSE=1` to the `make` call.</td>
+  <td>Enable verbose output from Makefile builds (useful for debugging), the same can be achieved by adding `VERBOSE=1` to the `make` call.</td>
   <td>
   <dl>
     <dt><code>off</code> (default)</dt>
@@ -576,7 +576,7 @@ cmake -C ../cmake/presets/all_on.cmake -C ../cmake/presets/nolib.cmake -D PKG_GP
   Several fixes and a pair style that have Monte Carlo (MC) or MC-like
   attributes. These include fixes for creating, breaking, and swapping bonds,
   for performing atomic swaps, and performing grand-canonical MC (GCMC) in
-  conjuction with dynamics.
+  conjunction with dynamics.
   </td>
   <td>
   <dl>
@@ -1383,8 +1383,8 @@ cmake -C ../cmake/presets/all_on.cmake -C ../cmake/presets/nolib.cmake -D PKG_GP
   Some potentials that are also implemented in the Yet Another Force Field (YAFF) code.
   The expressions and their use are discussed in the following papers:
   <ul>
-    <li><a href="http://dx.doi.org/10.1002/jcc.23877" target="_blank">Vanduyfhuys et al., J. Comput. Chem., 36 (13), 1015-1027 (2015)</a></li>
-    <li><a href="http://dx.doi.org/10.1002/jcc.25173" target="_blank">Vanduyfhuys et al., J. Comput. Chem., 39 (16), 999-1011 (2018)</a></li>
+    <li><a href="https://doi.org/10.1002/jcc.23877" target="_blank">Vanduyfhuys et al., J. Comput. Chem., 36 (13), 1015-1027 (2015)</a></li>
+    <li><a href="https://doi.org/10.1002/jcc.25173" target="_blank">Vanduyfhuys et al., J. Comput. Chem., 39 (16), 999-1011 (2018)</a></li>
   </ul>
   </td>
   <td>

cmake/presets/all_off.cmake

@@ -7,11 +7,11 @@ set(ALL_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE GPU
         SRD VORONOI
         USER-ADIOS USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK
         USER-COLVARS USER-DIFFRACTION USER-DPD USER-DRUDE USER-EFF USER-FEP
-        USER-H5MD USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
+        USER-H5MD USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESODPD
         USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE USER-NETCDF USER-OMP
         USER-PHONON USER-PLUMED USER-PTM USER-QMMM USER-QTB USER-QUIP
-        USER-REAXC USER-SCAFACOS USER-SDPD USER-SMD USER-SMTBQ USER-SPH
-        USER-TALLY USER-UEF USER-VTK USER-YAFF)
+        USER-REACTION USER-REAXC USER-SCAFACOS USER-SDPD USER-SMD USER-SMTBQ
+        USER-SPH USER-TALLY USER-UEF USER-VTK USER-YAFF)
 
 foreach(PKG ${ALL_PACKAGES})
   set(PKG_${PKG} OFF CACHE BOOL "" FORCE)

cmake/presets/all_on.cmake

@@ -9,11 +9,11 @@ set(ALL_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE GPU
         SRD VORONOI
         USER-ADIOS USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK
         USER-COLVARS USER-DIFFRACTION USER-DPD USER-DRUDE USER-EFF USER-FEP
-        USER-H5MD USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
+        USER-H5MD USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESODPD
         USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE USER-NETCDF USER-OMP
         USER-PHONON USER-PLUMED USER-PTM USER-QMMM USER-QTB USER-QUIP
-        USER-REAXC USER-SCAFACOS USER-SDPD USER-SMD USER-SMTBQ USER-SPH
-        USER-TALLY USER-UEF USER-VTK USER-YAFF)
+        USER-REACTION USER-REAXC USER-SCAFACOS USER-SDPD USER-SMD USER-SMTBQ
+        USER-SPH USER-TALLY USER-UEF USER-VTK USER-YAFF)
 
 foreach(PKG ${ALL_PACKAGES})
   set(PKG_${PKG} ON CACHE BOOL "" FORCE)

cmake/presets/clang.cmake

@@ -13,5 +13,5 @@ set(OpenMP_C_LIB_NAMES "omp" CACHE STRING "" FORCE)
 set(OpenMP_CXX "clang++" CACHE STRING "" FORCE)
 set(OpenMP_CXX_FLAGS "-fopenmp" CACHE STRING "" FORCE)
 set(OpenMP_CXX_LIB_NAMES "omp" CACHE STRING "" FORCE)
-set(OpenMP_omp_LIBRARY "/usr/lib64/libomp.so" CACHE PATH "" FORCE)
+set(OpenMP_omp_LIBRARY "libomp.so" CACHE PATH "" FORCE)
 

cmake/presets/intel.cmake

@@ -0,0 +1,17 @@
+# preset that will enable clang/clang++ with support for MPI and OpenMP (on Linux boxes)
+
+set(CMAKE_CXX_COMPILER "icpc" CACHE STRING "" FORCE)
+set(CMAKE_C_COMPILER "icc" CACHE STRING "" FORCE)
+set(CMAKE_CXX_FLAGS "-O3 -DNDEBG" CACHE STRING "" FORCE)
+set(MPI_CXX "icpc" CACHE STRING "" FORCE)
+set(MPI_CXX_COMPILER "mpicxx" CACHE STRING "" FORCE)
+unset(HAVE_OMP_H_INCLUDE CACHE)
+
+set(OpenMP_C "icc" CACHE STRING "" FORCE)
+set(OpenMP_C_FLAGS "-qopenmp" CACHE STRING "" FORCE)
+set(OpenMP_C_LIB_NAMES "omp" CACHE STRING "" FORCE)
+set(OpenMP_CXX "icpc" CACHE STRING "" FORCE)
+set(OpenMP_CXX_FLAGS "-qopenmp" CACHE STRING "" FORCE)
+set(OpenMP_CXX_LIB_NAMES "omp" CACHE STRING "" FORCE)
+set(OpenMP_omp_LIBRARY "libiomp5.so" CACHE PATH "" FORCE)
+

cmake/presets/mingw-cross.cmake

@@ -1,17 +1,28 @@
 set(WIN_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE GPU
-                 GRANULAR KSPACE MANYBODY MC MISC MOLECULE OPT PERI POEMS QEQ
-                 REPLICA RIGID SHOCK SNAP SPIN SRD VORONOI USER-ATC USER-AWPMD
-                 USER-BOCS USER-CGDNA USER-CGSDK USER-COLVARS USER-DIFFRACTION
-                 USER-DPD USER-DRUDE USER-EFF USER-FEP USER-INTEL USER-MANIFOLD
-                 USER-MEAMC USER-MESO USER-MISC USER-MGPT USER-MOFFF USER-MOLFILE
-                 USER-OMP USER-PHONON USER-PTM USER-QTB USER-REAXC USER-SDPD
-                 USER-SMD USER-SMTBQ USER-SPH USER-TALLY USER-UEF USER-YAFF)
+                 GRANULAR KSPACE LATTE MANYBODY MC MISC MOLECULE OPT PERI
+                 POEMS QEQ REPLICA RIGID SHOCK SNAP SPIN SRD VORONOI
+                 USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK
+                 USER-COLVARS USER-DIFFRACTION USER-DPD USER-DRUDE USER-EFF
+                 USER-FEP USER-INTEL USER-MANIFOLD USER-MEAMC USER-MESODPD
+                 USER-MISC USER-MGPT USER-MOFFF USER-MOLFILE USER-OMP
+                 USER-PHONON USER-PTM USER-QTB USER-REACTION USER-REAXC
+                 USER-SDPD USER-SMD USER-SMTBQ USER-SPH USER-TALLY USER-UEF
+                 USER-YAFF)
 
 foreach(PKG ${WIN_PACKAGES})
   set(PKG_${PKG} ON CACHE BOOL "" FORCE)
 endforeach()
 
+# these two packages require a full MPI implementation
+if(BUILD_MPI)
+  set(PKG_MPIIO ON CACHE BOOL "" FORCE)
+  set(PKG_USER-LB ON CACHE BOOL "" FORCE)
+endif()
+
 set(DOWNLOAD_VORO ON CACHE BOOL "" FORCE)
 set(DOWNLOAD_EIGEN3 ON CACHE BOOL "" FORCE)
 set(LAMMPS_MEMALIGN "0" CACHE STRING "" FORCE)
+set(CMAKE_TUNE_FLAGS "-Wno-missing-include-dirs" CACHE STRING "" FORCE)
+set(CMAKE_EXE_LINKER_FLAGS "--enable-stdcall-fixup" CACHE STRING "" FORCE)
+set(BUILD_TOOLS ON CACHE BOOL "" FORCE)
 set(CMAKE_INSTALL_PREFIX "${CMAKE_CURRENT_BINARY_DIR}/lammps-installer")

cmake/presets/most.cmake

@@ -2,14 +2,16 @@
 # external libraries. Compared to all_on.cmake some more unusual packages
 # are removed. The resulting binary should be able to run most inputs.
 
-set(ALL_PACKAGES ASPHERE CLASS2 COLLOID CORESHELL DIPOLE
-        GRANULAR KSPACE MANYBODY MC MISC MOLECULE OPT PERI
-        PYTHON QEQ REPLICA RIGID SHOCK SNAP SRD VORONOI
-        USER-CGDNA USER-CGSDK USER-COLVARS USER-DIFFRACTION USER-DPD
-        USER-DRUDE USER-FEP USER-MEAMC USER-MESO
-        USER-MISC USER-MOFFF USER-OMP USER-PHONON USER-REAXC
-        USER-SPH USER-SMD USER-UEF USER-YAFF)
+set(ALL_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL
+        DIPOLE GRANULAR KSPACE MANYBODY MC MISC MOLECULE OPT PERI
+        POEMS PYTHON QEQ REPLICA RIGID SHOCK SNAP SPIN SRD VORONOI
+        USER-CGDNA USER-CGSDK USER-COLVARS USER-DIFFRACTION
+        USER-DPD USER-DRUDE USER-FEP USER-MEAMC USER-MESODPD
+        USER-MISC USER-MOFFF USER-OMP USER-PHONON USER-REACTION
+        USER-REAXC USER-SPH USER-SMD USER-UEF USER-YAFF)
 
 foreach(PKG ${ALL_PACKAGES})
   set(PKG_${PKG} ON CACHE BOOL "" FORCE)
 endforeach()
+
+set(BUILD_TOOLS ON CACHE BOOL "" FORCE)

doc/Makefile

@@ -76,13 +76,9 @@ html: $(ANCHORCHECK) $(MATHJAX)
 	@rm -rf html/USER
 	@rm -rf html/JPG
 	@cp -r src/PDF html/PDF
-	@cp -r src/USER html/USER
 	@mkdir -p html/JPG
-	@cp `grep -A2 '\.\. image::' src/*.rst | grep ':target:' | sed -e 's,.*:target: JPG/,src/JPG/,' | sort | uniq` html/JPG/
+	@cp `grep -A2 '\.\. .*image::' src/*.rst | grep ':target:' | sed -e 's,.*:target: JPG/,src/JPG/,' | sort | uniq` html/JPG/
 	@rm -rf html/PDF/.[sg]*
-	@rm -rf html/USER/.[sg]*
-	@rm -rf html/USER/*/.[sg]*
-	@rm -rf html/USER/*/*.[sg]*
 	@mkdir -p html/_static/mathjax
 	@cp -r $(MATHJAX)/es5 html/_static/mathjax/
 	@echo "Build finished. The HTML pages are in doc/html."
@@ -151,11 +147,7 @@ pdf: $(ANCHORCHECK)
 	@rm -rf latex/PDF
 	@rm -rf latex/USER
 	@cp -r src/PDF latex/PDF
-	@cp -r src/USER latex/USER
 	@rm -rf latex/PDF/.[sg]*
-	@rm -rf latex/USER/.[sg]*
-	@rm -rf latex/USER/*/.[sg]*
-	@rm -rf latex/USER/*/*.[sg]*
 	@echo "Build finished. Manual.pdf and Developer.pdf are in this directory."
 
 fetch:

doc/lammps.1

@@ -1,4 +1,4 @@
-.TH LAMMPS "3 March 2020" "2020-03-03"
+.TH LAMMPS "19 March 2020" "2020-03-19"
 .SH NAME
 .B LAMMPS
 \- Molecular Dynamics Simulator.

doc/msi2lmp.1

@@ -31,7 +31,7 @@ of benzene, you have to provide the files 'benzene.car' and 'benzene.mdf'
 in the current working directory.
 .B msi2lmp
 will then read and process those files according to its remaining settings.
-All other settins are optional and have defaults as listed.
+All other settings are optional and have defaults as listed.
 .TP
 \fB\-c <I,1,II,2,O,0>\fR, \fB\-class <I,1,II,2,O,0>\fR
 The \-c or \-class option selects the force field class, i.e which pair

doc/src/2001/README.html

@@ -10,7 +10,7 @@ LAMMPS</H2>
 LAMMPS = Large-scale Atomic/Molecular Massively Parallel Simulator</P>
 <P>
 This is the documentation for the LAMMPS 2001 version, written in F90,
-which has been superceded by more current versions.  See the <A
+which has been superseded by more current versions.  See the <A
 HREF="http://www.cs.sandia.gov/~sjplimp/lammps.html">LAMMPS WWW
 Site</A> for more information.
 <P>

doc/src/2001/basics.html

@@ -47,7 +47,7 @@ directories: </P>
 <P>
 The src directory contains the F90 and C source files for LAMMPS as 
 well as several sample Makefiles for different machines. To make LAMMPS 
-for a specfic machine, you simply type</P>
+for a specific machine, you simply type</P>
 <P>
 make machine</P>
 <P>

doc/src/2001/input_commands.html

@@ -1079,7 +1079,7 @@ for style aveforce, average force on the group of fixed atoms is computed,
   to new total value -> has effect of applying same force to entire group
   of atoms
 thermostatting constraints (rescale, hoover/drag, langevin) cannot be used in
-  conjuction with global "temp control", since they conflict and will
+  conjunction with global "temp control", since they conflict and will
   cause atom velocities to be reset twice
 thermostatting constraints (rescale, hoover/drag, langevin) cannot be used
   when performing a minimization
@@ -1089,7 +1089,7 @@ meaning of rescale and Langevin thermostatting coefficients is same as in
   "temp control" command
 for rescale style, it can be used as a coarse temperature rescaler,
   for example "rescale 200.0 300.0 100 10.0 1.0" will ramp the temperature
-  up during the simulation, resetting it to the target temperatue as needed
+  up during the simulation, resetting it to the target temperature as needed
 for rescale style, it can be used to create an instantaneous
   drag force that slowly rescales the temperature without oscillation,
   for example "rescale 300.0 300.0 1 0.0 0.0001" will force (or keep) 
@@ -1952,7 +1952,7 @@ for rescale style, the amount of rescaling is contfolled by the fractional
   to halfway between the current and target temperature
 for rescale style, it can be used as a coarse temperature rescaler,
   for example "rescale 200.0 300.0 100 10.0 1.0" will ramp the temperature
-  up during the simulation, resetting it to the target temperatue as needed
+  up during the simulation, resetting it to the target temperature as needed
 for rescale style, it can be used to create an instantaneous
   drag force that slowly rescales the temperature without oscillation,
   for example "rescale 300.0 300.0 1 0.0 0.0001" will force (or keep) 

doc/src/99/README.html

@@ -10,7 +10,7 @@ LAMMPS</H2>
 LAMMPS = Large-scale Atomic/Molecular Massively Parallel Simulator</P>
 <P>
 This is the documentation for the LAMMPS 99 version, written in F77,
-which has been superceded by more current versions.  See the <A
+which has been superseded by more current versions.  See the <A
 HREF="http://www.cs.sandia.gov/~sjplimp/lammps.html">LAMMPS WWW
 Site</A> for more information.
 <P>

doc/src/99/basics.html

@@ -45,7 +45,7 @@ directories: </P>
 <P>
 The src directory contains the F77 and C source files for LAMMPS as 
 well as several sample Makefiles for different machines. To make LAMMPS 
-for a specfic machine, you simply type</P>
+for a specific machine, you simply type</P>
 <P>
 make machine</P>
 <P>

doc/src/99/input_commands.html

@@ -430,7 +430,7 @@ accuracy criterion effectively determines how many k-space vectors are used
 for PPPM, accuracy criterion determines mesh spacing (see "particle mesh"
   command)
 for PPPM, must be running on power-of-2 number of processors for FFTs
-must use periodic boundary conditions in conjuction with Ewald and PPPM
+must use periodic boundary conditions in conjunction with Ewald and PPPM
 cannot use any styles other than none with nonbond style = lj/shift or
   nonbond style = soft
 Coulomb style = smooth should be used with nonbond style = lj/switch,
@@ -772,7 +772,7 @@ for style aveforce, average force on the group of fixed atoms is computed,
   to new total value -> has effect of applying same force to entire group
   of atoms
 thermostatting constraints (rescale, langevin, nose/hoover) cannot be used in
-  conjuction with global "temp control", since they conflict and will
+  conjunction with global "temp control", since they conflict and will
   cause atom velocities to be reset twice
 if multiple Langevin constraints are specified the Marsaglia RNG will
   only use the last RNG seed specified for initialization

doc/src/Build.rst

@@ -8,7 +8,6 @@ for use with GNU make or gmake, or a build environment generated by CMake
 alternative you can download a package with pre-built executables
 as described on the :doc:`Install <Install>` doc page.
 
-
 .. toctree::
    :maxdepth: 1
 

doc/src/Build_basics.rst

@@ -10,10 +10,8 @@ CMake and make:
 * :ref:`Build the LAMMPS documentation <doc>`
 * :ref:`Install LAMMPS after a build <install>`
 
-
 ----------
 
-
 .. _serial:
 
 Serial vs parallel build
@@ -42,14 +40,14 @@ is below.
    -D LAMMPS_MACHINE=name    # name = mpi, serial, mybox, titan, laptop, etc
                              # no default value
 
-The executable created by CMake (after running make) is named *lmp* unless
-the LAMMPS\_MACHINE option is set.  When setting `LAMMPS_MACHINE=name`
-the executable will be named *lmp\_name*\.  Using `BUILD\_MPI=no` will
+The executable created by CMake (after running make) is named ``lmp`` unless
+the LAMMPS_MACHINE option is set.  When setting ``LAMMPS_MACHINE=name``
+the executable will be called ``lmp_name``.  Using ``BUILD_MPI=no`` will
 enforce building a serial executable using the MPI STUBS library.
 
 **Traditional make**\ :
 
-The build with traditional makefiles has to be done inside the source folder `src`.
+The build with traditional makefiles has to be done inside the source folder ``src``.
 
 .. code-block:: bash
 
@@ -57,19 +55,18 @@ The build with traditional makefiles has to be done inside the source folder `sr
    make serial             # serial build, produces lmp_serial using Makefile/serial
    make mybox              # uses Makefile.mybox to produce lmp_mybox
 
-
 Any "make machine" command will look up the make settings from a file
-Makefile.machine, create a folder Obj\_machine with all objects and
-generated files and an executable called *lmp\_machine*\ .  The standard
-parallel build with `make mpi` assumes a standard MPI installation with
+Makefile.machine, create a folder Obj_machine with all objects and
+generated files and an executable called ``lmp_machine``\ .  The standard
+parallel build with ``make mpi`` assumes a standard MPI installation with
 MPI compiler wrappers where all necessary compiler and linker flags to
 get access and link with the suitable MPI headers and libraries are set
 by the wrapper programs.  For other cases or the serial build, you have
-to adjust the make file variables MPI\_INC, MPI\_PATH, MPI\_LIB as well
-as CC and LINK.  To enable OpenMP threading usually a compiler specific
-flag needs to be added to the compile and link commands.  For the GNU
-compilers, this is *-fopenmp*\ , which can be added to the CC and LINK
-makefile variables.
+to adjust the make file variables ``MPI_INC``, ``MPI_PATH``, ``MPI_LIB``
+as well as ``CC`` and ``LINK``\ .  To enable OpenMP threading usually
+a compiler specific flag needs to be added to the compile and link
+commands.  For the GNU compilers, this is ``-fopenmp``\ , which can be
+added to the ``CC`` and ``LINK`` makefile variables.
 
 For the serial build the following make variables are set (see src/MAKE/Makefile.serial):
 
@@ -82,8 +79,8 @@ For the serial build the following make variables are set (see src/MAKE/Makefile
    MPI_LIB =       -lmpi_stubs
 
 You also need to build the STUBS library for your platform before making
-LAMMPS itself.  A "make serial" build does this for you automatically,
-otherwise, type "make mpi-stubs" from the src directory, or "make" from
+LAMMPS itself.  A ``make serial`` build does this for you automatically,
+otherwise, type ``make mpi-stubs`` from the src directory, or ``make`` from
 the src/STUBS dir.  If the build fails, you will need to edit the
 STUBS/Makefile for your platform.  The stubs library does not provide
 MPI/IO functions required by some LAMMPS packages, e.g. MPIIO or USER-LB,
@@ -91,8 +88,8 @@ and thus is not compatible with those packages.
 
 .. note::
 
-   The file STUBS/mpi.c provides a CPU timer function called
-   MPI\_Wtime() that calls gettimeofday() .  If your operating system
+   The file ``src/STUBS/mpi.c`` provides a CPU timer function called
+   MPI_Wtime() that calls gettimeofday() .  If your operating system
    does not support gettimeofday() , you will need to insert code to
    call another timer.  Note that the ANSI-standard function clock()
    rolls over after an hour or so, and is therefore insufficient for
@@ -129,35 +126,33 @@ to: e.g. LATTE and USER-COLVARS.  See the :doc:`Packages details
 <Packages_details>` doc page for more info on these packages and the doc
 pages for their respective commands for OpenMP threading info.
 
-For CMake, if you use BUILD\_OMP=yes, you can use these packages and
-turn on their native OpenMP support and turn on their native OpenMP
-support at run time, by setting the OMP\_NUM\_THREADS environment
+For CMake, if you use ``BUILD_OMP=yes``, you can use these packages
+and turn on their native OpenMP support and turn on their native OpenMP
+support at run time, by setting the ``OMP_NUM_THREADS`` environment
 variable before you launch LAMMPS.
 
-For building via conventional make, the CCFLAGS and LINKFLAGS
+For building via conventional make, the ``CCFLAGS`` and ``LINKFLAGS``
 variables in Makefile.machine need to include the compiler flag that
-enables OpenMP. For GNU compilers it is -fopenmp.  For (recent) Intel
-compilers it is -qopenmp.  If you are using a different compiler,
+enables OpenMP. For GNU compilers it is ``-fopenmp``\ .  For (recent) Intel
+compilers it is ``-qopenmp``\ .  If you are using a different compiler,
 please refer to its documentation.
 
 .. _default-none-issues:
 
-**OpenMP Compiler compatibility info**\ : 
+**OpenMP Compiler compatibility info**\ :
 
-Some compilers do not fully support the 'default(none)' directive
+Some compilers do not fully support the ``default(none)`` directive
 and others (e.g. GCC version 9 and beyond) may implement OpenMP 4.0
-semantics, which are incompatible with the OpenMP 3.1 directives used
+semantics, which are incompatible with the OpenMP 3.1 semantics used
 in LAMMPS (for maximal compatibility with compiler versions in use).
-In those case, all 'default(none)' directives (which aid in detecting
-incorrect and unwanted sharing) can be replaced with 'default(shared)'
-while dropping all 'shared()' directives. The script
-'src/USER-OMP/hack\_openmp\_for\_pgi\_gcc9.sh' can be used to automate
+In those case, all ``default(none)`` directives (which aid in detecting
+incorrect and unwanted sharing) can be replaced with ``default(shared)``
+while dropping all ``shared()`` directives. The script
+'src/USER-OMP/hack_openmp_for_pgi_gcc9.sh' can be used to automate
 this conversion.
 
-
 ----------
 
-
 .. _compile:
 
 Choice of compiler and compile/link options
@@ -188,11 +183,11 @@ optimization flags appropriate to that compiler and any
 build.
 
 You can tell CMake to look for a specific compiler with these variable
-settings.  Likewise you can specify the FLAGS variables if you want to
-experiment with alternate optimization flags.  You should specify all
-3 compilers, so that the small number of LAMMPS source files written
-in C or Fortran are built with a compiler consistent with the one used
-for all the C++ files:
+settings.  Likewise you can specify the corresponding ``CMAKE_*_FLAGS``
+variables if you want to experiment with alternate optimization flags.
+You should specify all 3 compilers, so that the small number of LAMMPS
+source files written in C or Fortran are built with a compiler consistent
+with the one used for all the C++ files:
 
 .. code-block:: bash
 
@@ -204,7 +199,6 @@ for all the C++ files:
    -D CMAKE_C_FLAGS=string               # flags to use with C compiler
    -D CMAKE_Fortran_FLAGS=string         # flags to use with Fortran compiler
 
-
 A few example command lines are:
 
 .. code-block:: bash
@@ -219,6 +213,14 @@ A few example command lines are:
 For compiling with the Clang/LLVM compilers a special CMake preset is
 included that can be loaded with `-C ../cmake/presets/clang.cmake`.
 
+In addition you can set ``CMAKE_TUNE_FLAGS`` to specifically add compiler
+flags to tune for optimal performance on given hosts. By default these are
+initialized to some compiler specific flags, where known, to optimize the
+LAMMPS executable with optimizations and instructions available on the host
+where LAMMPS is compiled. For example, for Intel compilers this would be
+``-xHost`` and for GNU compilers this would be ``-march=native``. To turn
+these flags off, set ``-D CMAKE_TUNE_FLAGS=``.
+
 .. note::
 
    When the cmake command completes, it prints a summary to the screen
@@ -306,33 +308,32 @@ are set, defaults are applied.
    -D LAMMPS_LIB_SUFFIX=name    # name = mpi, serial, mybox, titan, laptop, etc
                                 # no default value
 
-Setting BUILD\_EXE=no will not produce an executable.  Setting
-BUILD\_LIB=yes will produce a static library named *liblammps.a*\ .
-Setting both BUILD\_LIB=yes and BUILD\_SHARED\_LIBS=yes will produce a
-shared library named *liblammps.so* instead. If LAMMPS\_LIB\_SUFFIX is
-set to *name* in addition, the name of the generated libraries will be
-changed to either *liblammps\_name.a* or *liblammps\_name.so*\ ,
-respectively.
+Setting ``BUILD_EXE=no`` will not produce an executable.  Setting
+``BUILD_LIB=yes`` will produce a static library named ``liblammps.a``\ .
+Setting both ``BUILD_LIB=yes`` and ``BUILD_SHARED_LIBS=yes`` will produce a
+shared library named ``liblammps.so`` instead. If ``LAMMPS_LIB_SUFFIX=name``
+is set in addition, the name of the generated libraries will be changed to
+either ``liblammps_name.a`` or ``liblammps_name.so``\ , respectively.
 
 **Traditional make**\ :
 
 With the traditional makefile based build process, the choice of
 the generated executable or library depends on the "mode" setting.
-Several options are available and "mode=exe" is the default.
+Several options are available and ``mode=exe`` is the default.
 
 .. code-block:: bash
 
    make machine               # build LAMMPS executable lmp_machine
-   mkae mode=exe machine      # same as "make machine"
+   make mode=exe machine      # same as "make machine"
    make mode=lib machine      # build LAMMPS static lib liblammps_machine.a
    make mode=shlib machine    # build LAMMPS shared lib liblammps_machine.so
    make mode=shexe machine    # same as "mode=exe" but uses objects from "mode=shlib"
 
-The two "exe" builds will generate and executable *lmp\_machine*\ ,
-while the two library builds will create a file *liblammps\_machine.a*
-or *liblammps\_machine.so*\ . They will also create generic soft links,
-named *liblammps.a* and *liblammps.so*\ , which point to the specific
-*liblammps\_machine.a/so* files.
+The two "exe" builds will generate and executable ``lmp_machine``\ ,
+while the two library builds will create a file ``liblammps_machine.a``
+or ``liblammps_machine.so``\ . They will also create generic soft links,
+named ``liblammps.a`` and ``liblammps.so``\ , which point to the specific
+``liblammps_machine.a/so`` files.
 
 **CMake and make info**\ :
 
@@ -341,13 +342,12 @@ the auxiliary libraries it depends on must also exist as shared
 libraries.  This will be the case for libraries included with LAMMPS,
 such as the dummy MPI library in src/STUBS or any package libraries in
 the lib/packages directory, since they are always built in a shared
-library compatible way using the -fPIC switch.  However, if a library
+library compatible way using the ``-fPIC`` switch.  However, if a library
 like MPI or FFTW does not exist as a shared library, the shared library
 build may generate an error.  This means you will need to install a
 shared library version of the auxiliary library.  The build instructions
 for the library should tell you how to do this.
 
-
 As an example, here is how to build and install the `MPICH library
 <mpich_>`_, a popular open-source version of MPI, as a shared library
 in the default /usr/local/lib location:
@@ -360,10 +360,10 @@ in the default /usr/local/lib location:
    make
    make install
 
-You may need to use "sudo make install" in place of the last line if you
-do not have write privileges for /usr/local/lib.  The end result should
-be the file /usr/local/lib/libmpich.so.  On many Linux installations the
-folder "${HOME}/.local" is an alternative to using /usr/local and does
+You may need to use ``sudo make install`` in place of the last line if you
+do not have write privileges for ``/usr/local/lib``.  The end result should
+be the file ``/usr/local/lib/libmpich.so``.  On many Linux installations the
+folder ``${HOME}/.local`` is an alternative to using ``/usr/local`` and does
 not require superuser or sudo access.  In that case the configuration
 step becomes:
 
@@ -377,7 +377,6 @@ recommended to ensure the integrity of the system software installation.
 
 ----------
 
-
 .. _doc:
 
 Build the LAMMPS documentation
@@ -412,7 +411,6 @@ LAMMPS source distribution.
   make package_check # check for complete and consistent package lists
   make spelling      # spell-check the manual
 
-
 Thus "make html" will create a "doc/html" directory with the HTML format
 manual pages so that you can browse them with a web browser locally on
 your system.
@@ -421,8 +419,7 @@ your system.
 
    You can also download a tarball of the documentation for the
    current LAMMPS version (HTML and PDF files), from the website
-   `download page <http://lammps.sandia.gov/download.html>`_.
-
+   `download page <https://lammps.sandia.gov/download.html>`_.
 
 **CMake build option**\ :
 
@@ -430,16 +427,14 @@ It is also possible to create the HTML version of the manual within
 the :doc:`CMake build directory <Build_cmake>`.  The reason for this
 option is to include the installation of the HTML manual pages into
 the "install" step when installing LAMMPS after the CMake build via
-"make install".
+``make install``.
 
 .. code-block:: bash
 
    -D BUILD_DOC=value       # yes or no (default)
 
-
 ----------
 
-
 .. _tools:
 
 Build LAMMPS tools
@@ -450,7 +445,6 @@ using CMake or Make.
 
 **CMake build3**\ :
 
-
 .. code-block:: bash
 
    -D BUILD_TOOLS=value       # yes or no (default)
@@ -460,7 +454,6 @@ The generated binaries will also become part of the LAMMPS installation
 
 **Traditional make**\ :
 
-
 .. code-block:: bash
 
    cd lammps/tools
@@ -470,10 +463,8 @@ The generated binaries will also become part of the LAMMPS installation
    make micelle2d        # build only micelle2d tool
    make thermo_extract   # build only thermo_extract tool
 
-
 ----------
 
-
 .. _install:
 
 Install LAMMPS after a build
@@ -487,7 +478,6 @@ you want to copy files to is protected.
 
 **CMake build**\ :
 
-
 .. code-block:: bash
 
    cmake -D CMAKE_INSTALL_PREFIX=path [options ...] ../cmake
@@ -496,6 +486,6 @@ you want to copy files to is protected.
 
 **Traditional make**\ :
 
-There is no "install" option in the src/Makefile for LAMMPS.  If you
-wish to do this you will need to first build LAMMPS, then manually
+There is no "install" option in the ``src/Makefile`` for LAMMPS.  If
+you wish to do this you will need to first build LAMMPS, then manually
 copy the desired LAMMPS files to the appropriate system directories.

doc/src/Build_cmake.rst

@@ -9,49 +9,47 @@ Richard Berger (Temple U) has also written a `more comprehensive guide <https://
 for how to use CMake to build LAMMPS.  If you are new to CMake it is a
 good place to start.
 
-
 ----------
 
-
 Building LAMMPS with CMake is a two-step process.  First you use CMake
 to create a build environment in a new directory.  On Linux systems,
-this will be based on makefiles for use with make.  Then you use the
-make command to build LAMMPS, which uses the created
+this will be by default based on Unix-style makefiles for use with make.
+Then you use the *make* command to build LAMMPS, which uses the created
 Makefile(s). Example:
 
-
 .. code-block:: bash
 
    cd lammps                        # change to the LAMMPS distribution directory
    mkdir build; cd build            # create a new directory (folder) for build
    cmake [options ...] ../cmake     # configuration with (command-line) cmake
-   make                             # compilation
+   cmake --build .                  # compilation (or type "make")
 
-The cmake command will detect available features, enable selected
+The ``cmake`` command will detect available features, enable selected
 packages and options, and will generate the build environment.  By default
 this build environment will be created for "Unix Makefiles" on most
 platforms and particularly on Linux.  However, alternate build tools
-(e.g. Ninja) and support files for Integrated Development Environments
-(IDE) like Eclipse, CodeBlocks, or Kate can be generated, too. This is
-selected via the "-G" command line flag. For the rest of the documentation
-we will assume that the build environment is generated for makefiles
-and thus the make command will be used to compile and link LAMMPS as
-indicated above, producing (by default) an executable called "lmp" and
-a library called "liblammps.a" in the "build" folder.  When generating
-a build environment for the "Ninja" build tool, the build command would
-be "ninja" instead of "make".
+(e.g. Ninja) and project files for Integrated Development Environments
+(IDEs) like Eclipse, CodeBlocks, or Kate can be generated, too. This is
+selected via the ``-G`` command line flag. Further details about features
+and settings for CMake are in the `CMake online documentation <cmake_doc_>`_
 
-If your machine has multiple CPU cores (most do these days), using a
-command like "make -jN" (with N being the number of available local
-CPU cores) can be much faster.  If you plan to do development on
-LAMMPS or need to re-compile LAMMPS repeatedly, installation of the
-ccache (= Compiler Cache) software may speed up repeated compilation
-even more.
+.. _cmake_doc: https://cmake.org/documentation/
+
+For the rest of the documentation
+we will assume that the build environment is generated for "Unix Makefiles"
+and thus the ``make`` command will be used to compile and link LAMMPS as
+indicated above, producing (by default) an executable called ``lmp`` and
+a library called ``liblammps.a`` in the ``build`` folder.
+
+If your machine has multiple CPU cores (most do these days), you can
+compile sources in parallel with a command like ``make -j N`` (with N
+being the maximum number of concurrently executed tasks).  Also
+installation of the ``ccache`` (= Compiler Cache) software may speed
+up repeated compilation, e.g. during code development, significantly.
 
 After compilation, you may optionally install the LAMMPS executable into
 your system with:
 
-
 .. code-block:: bash
 
    make install    # optional, copy LAMMPS executable & library elsewhere
@@ -59,18 +57,19 @@ your system with:
 This will install the lammps executable and library (if requested), some
 tools (if configured) and additional files like library API headers,
 manpages, potential and force field files. The location of the installation
-tree is set by the CMake variable "CMAKE\_INSTALL\_PREFIX" which defaults
+tree is set by the CMake variable "CMAKE_INSTALL_PREFIX" which defaults
 to ${HOME}/.local
 
-
 ----------
 
+.. _cmake_build:
 
-There are 3 variants of CMake: a command-line version (cmake), a text mode
-UI version (ccmake), and a graphical GUI version (cmake-GUI).  You can use
-any of them interchangeably to configure and create the LAMMPS build
-environment.  On Linux all the versions produce a Makefile as their
-output.  See more details on each below.
+There are 3 variants of the CMake command itself: a command-line version
+(``cmake`` or ``cmake3``), a text mode UI version (``ccmake`` or ``ccmake3``),
+and a graphical GUI version (``cmake-gui``).  You can use any of them
+interchangeably to configure and create the LAMMPS build environment.
+On Linux all the versions produce a Makefile as their output by default.
+See more details on each below.
 
 You can specify a variety of options with any of the 3 versions, which
 affect how the build is performed and what is included in the LAMMPS
@@ -80,7 +79,7 @@ the :doc:`Build <Build>` doc page.
 You must perform the CMake build system generation and compilation in
 a new directory you create.  It can be anywhere on your local machine.
 In these Build pages we assume that you are building in a directory
-called "lammps/build".  You can perform separate builds independently
+called ``lammps/build``.  You can perform separate builds independently
 with different options, so long as you perform each of them in a
 separate directory you create.  All the auxiliary files created by one
 build process (executable, object files, log files, etc) are stored in
@@ -88,17 +87,16 @@ this directory or sub-directories within it that CMake creates.
 
 .. note::
 
-   To perform a CMake build, no packages can be installed or a
-   build been previously attempted in the LAMMPS src directory by using
-   "make" commands to :doc:`perform a conventional LAMMPS build <Build_make>`.  CMake detects if this is the case and
-   generates an error, telling you to type "make no-all purge" in the src
-   directory to un-install all packages.  The purge removes all the \*.h
-   files auto-generated by make.
+   To perform a CMake build, no packages can be installed or a build
+   been previously attempted in the LAMMPS src directory by using ``make``
+   commands to :doc:`perform a conventional LAMMPS build <Build_make>`.
+   CMake detects if this is the case and generates an error, telling you
+   to type ``make no-all purge`` in the src directory to un-install all
+   packages.  The purge removes all the \*.h files auto-generated by
+   make.
 
-You must have CMake version 2.8 or later on your system to build
-LAMMPS.  A handful of LAMMPS packages (KOKKOS, LATTE, MSCG) require a
-later version.  CMake will print a message telling you if a later
-version is required.  Installation instructions for CMake are below.
+You must have CMake version 3.10 or later on your system to build
+LAMMPS.  Installation instructions for CMake are below.
 
 After the initial build, if you edit LAMMPS source files, or add your
 own new files to the source directory, you can just re-type make from
@@ -108,30 +106,28 @@ ccmake or cmake-gui) again from the same build directory and alter
 various options; see details below.  Or you can remove the entire build
 folder, recreate the directory and start over.
 
-
 ----------
 
-
 **Command-line version of CMake**\ :
 
-
 .. code-block:: bash
 
-   cmake [options ...] /path/to/lammps/cmake  # build from any dir
-   cmake [options ...] ../cmake               # build from lammps/build
+   cmake  [options ...] /path/to/lammps/cmake  # build from any dir
+   cmake  [options ...] ../cmake               # build from lammps/build
+   cmake3 [options ...] ../cmake               # build from lammps/build
 
 The cmake command takes one required argument, which is the LAMMPS
 cmake directory which contains the CMakeLists.txt file.
 
-The argument can be preceeded or followed by various CMake
+The argument can be prefixed or followed by various CMake
 command-line options.  Several useful ones are:
 
-
 .. code-block:: bash
 
    -D CMAKE_INSTALL_PREFIX=path  # where to install LAMMPS executable/lib if desired
    -D CMAKE_BUILD_TYPE=type      # type = RelWithDebInfo (default), Release, MinSizeRel, or Debug
-   -G output                     # style of output CMake generates
+   -G output                     # style of output CMake generates (e.g. "Unix Makefiles" or "Ninja")
+   -D CMAKE_MAKE_PROGRAM=builder # name of the builder executable (e.g. when using "gmake" instead of "make")
    -DVARIABLE=value              # setting for a LAMMPS feature to enable
    -D VARIABLE=value             # ditto, but cannot come after CMakeLists.txt dir
    -C path/to/preset/file        # load some CMake settings before configuring
@@ -139,13 +135,13 @@ command-line options.  Several useful ones are:
 All the LAMMPS-specific -D variables that a LAMMPS build supports are
 described on the pages linked to from the :doc:`Build <Build>` doc page.
 All of these variable names are upper-case and their values are
-lower-case, e.g. -D LAMMPS\_SIZES=smallbig.  For boolean values, any of
+lower-case, e.g. -D LAMMPS_SIZES=smallbig.  For boolean values, any of
 these forms can be used: yes/no, on/off, 1/0.
 
 On Unix/Linux machines, CMake generates a Makefile by default to
 perform the LAMMPS build.  Alternate forms of build info can be
 generated via the -G switch, e.g. Visual Studio on a Windows machine,
-Xcode on MacOS, or KDevelop on Linux.  Type "cmake --help" to see the
+Xcode on MacOS, or KDevelop on Linux.  Type ``cmake --help`` to see the
 "Generator" styles of output your system supports.
 
 .. note::
@@ -170,13 +166,10 @@ In these cases it is usually better to first remove all the
 files/directories in the build directory, or start with a fresh build
 directory.
 
-
 ----------
 
-
 **Curses version (terminal-style menu) of CMake**\ :
 
-
 .. code-block:: bash
 
    ccmake ../cmake
@@ -188,13 +181,10 @@ required to edit some of the entries of CMake configuration variables
 in between.  Please see the `ccmake manual <https://cmake.org/cmake/help/latest/manual/ccmake.1.html>`_ for
 more information.
 
-
 ----------
 
-
 **GUI version of CMake**\ :
 
-
 .. code-block:: bash
 
    cmake-gui ../cmake
@@ -207,15 +197,12 @@ edit some of the entries of CMake configuration variables in between.
 Please see the `cmake-gui manual <https://cmake.org/cmake/help/latest/manual/cmake-gui.1.html>`_
 for more information.
 
-
 ----------
 
-
 **Installing CMake**
 
 Check if your machine already has CMake installed:
 
-
 .. code-block:: bash
 
    which cmake             # do you have it?
@@ -225,7 +212,6 @@ Check if your machine already has CMake installed:
 On clusters or supercomputers which use environment modules to manage
 software packages, do this:
 
-
 .. code-block:: bash
 
    module list            # is a module for cmake already loaded?

doc/src/Build_development.rst

@@ -2,12 +2,10 @@ Development build options (CMake only)
 ======================================
 
 The CMake build of LAMMPS has a few extra options which are useful during
-development,  testing or debugging.
-
+development, testing or debugging.
 
 ----------
 
-
 .. _compilation:
 
 Verify compilation flags
@@ -17,47 +15,47 @@ Sometimes it is necessary to verify the complete sequence of compilation flags
 generated by the CMake build. To enable a more verbose output during
 compilation you can use the following option.
 
-
 .. code-block:: bash
 
    -D CMAKE_VERBOSE_MAKEFILE=value    # value = no (default) or yes
 
 Another way of doing this without reconfiguration is calling make with variable VERBOSE set to 1:
 
-
 .. code-block:: bash
 
    make VERBOSE=1
 
-
 ----------
 
-
 .. _sanitizer:
 
 Address, Undefined Behavior, and Thread Sanitizer Support
 -------------------------------------------------------------------------
 
-Compilers such as GCC and Clang support generating binaries which use different
-sanitizers to detect problems in code during run-time. They can detect `memory leaks <https://clang.llvm.org/docs/AddressSanitizer.html>`_,
-code that runs into `undefined behavior <https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html>`_ of the
-language and `data races <https://clang.llvm.org/docs/ThreadSanitizer.html>`_ in threaded code.
+Compilers such as GCC and Clang support generating instrumented binaries
+which use different sanitizer libraries to detect problems in code
+during run-time. They can detect issues like:
 
-The following settings allow you enable these features if your compiler supports
-it. Please note that they come with a performance hit. However, they are
-usually faster than using tools like Valgrind.
+ - `memory leaks <https://clang.llvm.org/docs/AddressSanitizer.html>`_
+ - `undefined behavior <https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html>`_
+ - `data races <https://clang.llvm.org/docs/ThreadSanitizer.html>`_
 
+Please note that this kind of instrumentation usually comes with a small
+performance hit (much less than using tools like `Valgrind <valgrind_>`_).
+The to enable these features additional compiler flags need to be added
+to the compilation and linking stages.  This is most easily done through
+setting the ``CMAKE_TUNE_FLAGS`` variable during configuration. Examples:
 
 .. code-block:: bash
 
-   -D ENABLE_SANITIZE_ADDRESS=value    # enable Address Sanitizer, value = no (default) or yes
-   -D ENABLE_SANITIZE_UNDEFINED=value  # enable Undefined Behaviour Sanitizer, value = no (default) or yes
-   -D ENABLE_SANITIZE_THREAD=value     # enable Thread Sanitizer, value = no (default) or yes
+   -D CMAKE_TUNE_FLAGS=-fsanitize=address    # enable address sanitizer / memory leak checker
+   -D CMAKE_TUNE_FLAGS=-fsanitize=undefined  # enable undefined behavior sanitizer
+   -D CMAKE_TUNE_FLAGS=-fsanitize=thread     # enable thread sanitizer
 
+.. _valgrind: https://valgrind.org
 
 ----------
 
-
 .. _testing:
 
 Code Coverage and Testing
@@ -71,7 +69,6 @@ developers can run the tests directly on their workstation.
 
    this is incomplete and only represents a small subset of tests that we run
 
-
 .. code-block:: bash
 
    -D ENABLE_TESTING=value               # enable simple run tests of LAMMPS, value = no (default) or yes
@@ -80,7 +77,6 @@ developers can run the tests directly on their workstation.
 
 If you enable testing in the CMake build it will create an additional target called "test". You can run them with:
 
-
 .. code-block:: bash
 
    make test
@@ -92,14 +88,12 @@ faster.
 You can also collect code coverage metrics while running the tests by enabling
 coverage support during building.
 
-
 .. code-block:: bash
 
    -D ENABLE_COVERAGE=value  # enable coverage measurements, value = no (default) or yes
 
 This will also add the following targets to generate coverage reports after running the LAMMPS executable:
 
-
 .. code-block:: bash
 
    make test               # run tests first!
@@ -108,7 +102,6 @@ This will also add the following targets to generate coverage reports after runn
 
 These reports require GCOVR to be installed. The easiest way to do this to install it via pip:
 
-
 .. code-block:: bash
 
    pip install git+https://github.com/gcovr/gcovr.git

doc/src/Build_link.rst

@@ -11,7 +11,7 @@ The :doc:`Build basics <Build_basics>` doc page explains how to build
 LAMMPS as either a shared or static library.  This results in one of
 these 2 files:
 
-.. parsed-literal::
+.. code-block:: bash
 
    liblammps.so      # shared library
    liblammps.a       # static library
@@ -25,13 +25,12 @@ these 2 files:
    then its mpi.h file needs to be included.  While it is technically
    possible to use a full MPI library in the calling code and link to
    a serial LAMMPS library compiled with MPI STUBS, it is recommended
-   to use the *same* MPI library for both, and then use MPI\_Comm\_split()
+   to use the *same* MPI library for both, and then use MPI_Comm_split()
    in the calling code to pass a suitable communicator with a subset
    of MPI ranks to the function creating the LAMMPS instance.
 
 ----------
 
-
 **Link with LAMMPS as a static library**\ :
 
 The calling application can link to LAMMPS as a static library with
@@ -44,7 +43,7 @@ executable code from the library is copied into the calling executable.
 *CMake build*\ :
 
 This assumes that LAMMPS has been configured with "-D BUILD_LIB=yes"
-and installed with "make install" and the PKG\_CONFIG\_PATH environment
+and installed with "make install" and the PKG_CONFIG_PATH environment
 variable updated to include the *liblammps.pc* file installed into the
 configured destination folder, if needed.  The commands to compile and
 link the coupled executable are then:
@@ -54,7 +53,6 @@ link the coupled executable are then:
    mpicc -c -O $(pkgconf liblammps --cflags) caller.c
    mpicxx -o caller caller.o -$(pkgconf liblammps --libs)
 
-
 *Traditional make*\ :
 
 This assumes that LAMMPS has been compiled in the folder
@@ -101,7 +99,7 @@ change to:
 
    gcc -c -O -I${HOME}/lammps/src/STUBS -I${HOME}/lammps/src -caller.c
    g++ -o caller caller.o -L${HOME}/lammps/lib/poems \
-     -L${HOME}/lammps/src/STUBS -L${HOME}/lammps/src -llammps -lpoems -lmpi_stubs 
+     -L${HOME}/lammps/src/STUBS -L${HOME}/lammps/src -llammps -lpoems -lmpi_stubs
 
 Note, that you need to link with "g++" instead of "gcc", since LAMMPS
 is C++ code.  You can display the currently applied settings for building
@@ -115,15 +113,15 @@ Which should output something like:
 
 .. code-block:: bash
 
-   # Compiler: 
+   # Compiler:
    CXX=g++
-   # Linker: 
+   # Linker:
    LD=g++
-   # Compilation: 
+   # Compilation:
    CXXFLAGS=-g -O3 -DLAMMPS_GZIP -DLAMMPS_MEMALIGN=64 -I${HOME}/lammps/lib/poems -I${HOME}/lammps/src/STUBS
-   # Linking: 
+   # Linking:
    LDFLAGS=-g -O
-   # Libraries: 
+   # Libraries:
    LDLIBS=-L${HOME}/lammps/lib/poems -L${HOME}/lammps/src/STUBS -lpoems -lmpi_stubs
 
 From this you can gather the necessary paths and flags.  With
@@ -165,11 +163,11 @@ traditional make build using "make mode=shlib serial" becomes:
    g++ -o caller caller.o -L${HOME}/lammps/src -llammps
 
 *Locating liblammps.so at runtime*\ :
-   
+
 However, now the `liblammps.so` file is required at runtime and needs
 to be in a folder, where the shared linker program of the operating
 system can find it.  This would be either a folder like "/usr/local/lib64"
-or "${HOME}/.local/lib64" or a folder pointed to by the LD\_LIBRARY\_PATH
+or "${HOME}/.local/lib64" or a folder pointed to by the LD_LIBRARY_PATH
 environment variable. You can type
 
 .. code-block:: bash
@@ -179,7 +177,7 @@ environment variable. You can type
 to see what directories are in that list.
 
 Or you can add the LAMMPS src directory (or the directory you performed
-a CMake style build in) to your LD\_LIBRARY\_PATH, so that the current
+a CMake style build in) to your LD_LIBRARY_PATH, so that the current
 version of the shared library is always available to programs that use it.
 
 For the Bourne or Korn shells (/bin/sh, /bin/ksh, /bin/bash etc.), you
@@ -193,7 +191,6 @@ would add something like this to your ~/.profile file:
 For the csh or tcsh shells, you would equivalently add something like this
 to your ~/.cshrc file:
 
-
 .. code-block:: csh
 
    setenv LD_LIBRARY_PATH ${LD_LIBRARY_PATH}:${HOME}/lammps/src
@@ -203,7 +200,7 @@ You can verify whether all required shared libraries are found with the
 
 .. code-block:: bash
 
-   $ LD_LIBRARY_PATH=/home/user/lammps/src ldd caller 
+   $ LD_LIBRARY_PATH=/home/user/lammps/src ldd caller
         linux-vdso.so.1 (0x00007ffe729e0000)
         liblammps.so => /home/user/lammps/src/liblammps.so (0x00007fc91bb9e000)
         libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fc91b984000)
@@ -212,12 +209,11 @@ You can verify whether all required shared libraries are found with the
         libc.so.6 => /lib64/libc.so.6 (0x00007fc91b65b000)
         /lib64/ld-linux-x86-64.so.2 (0x00007fc91c094000)
 
-
 If a required library is missing, you would get a 'not found' entry:
 
 .. code-block:: bash
 
-   $  ldd caller 
+   $  ldd caller
         linux-vdso.so.1 (0x00007ffd672fe000)
         liblammps.so => not found
         libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fb7c7e86000)
@@ -226,16 +222,14 @@ If a required library is missing, you would get a 'not found' entry:
         libc.so.6 => /usr/lib64/libc.so.6 (0x00007fb7c7b5d000)
         /lib64/ld-linux-x86-64.so.2 (0x00007fb7c80a2000)
 
-
 ----------
 
-
 **Calling the LAMMPS library**\ :
 
 Either flavor of library (static or shared) allows one or more LAMMPS
 objects to be instantiated from the calling program. When used from a
 C++ program, most of the symbols and functions in LAMMPS are wrapped
-in a LAMMPS\_NS namespace; you can safely use any of its classes and
+in a LAMMPS_NS namespace; you can safely use any of its classes and
 methods from within the calling code, as needed, and you will not incur
 conflicts with functions and variables in your code that share the name.
 This, however, does not extend to all additional libraries bundled with
@@ -246,9 +240,11 @@ C-style interface, provided in src/library.cpp and src/library.h.
 
 See the :doc:`Python library <Python_library>` doc page for a
 description of the Python interface to LAMMPS, which wraps the C-style
-interface from a shared library through the ctypes python module.
+interface from a shared library through the `ctypes python module <ctypes_>`_.
 
 See the sample codes in examples/COUPLE/simple for examples of C++ and
 C and Fortran codes that invoke LAMMPS through its library interface.
 Other examples in the COUPLE directory use coupling ideas discussed on
 the :doc:`Howto couple <Howto_couple>` doc page.
+
+.. _ctypes: https://docs.python.org/3/library/ctypes.html

doc/src/Build_make.rst

@@ -31,7 +31,7 @@ machines, especially workstations, desktops, and laptops, so we suggest
 you try it first when building LAMMPS in those cases.
 
 The commands below perform a default LAMMPS build, producing the LAMMPS
-executable lmp\_serial and lmp\_mpi in lammps/src:
+executable lmp_serial and lmp_mpi in lammps/src:
 
 .. code-block:: bash
 
@@ -73,8 +73,7 @@ in the LAMMPS distribution.  Typing "make machine" uses
 use Makefile.serial and Makefile.mpi, respectively.  Other makefiles
 are in these directories:
 
-
-.. parsed-literal::
+.. code-block:: bash
 
    OPTIONS      # Makefiles which enable specific options
    MACHINES     # Makefiles for specific machines
@@ -93,7 +92,6 @@ customized machine Makefile are contributed by users.  Since both
 compilers, OS configurations, and LAMMPS itself keep changing, their
 settings may become outdated:
 
-
 .. code-block:: bash
 
    make mac             # build serial LAMMPS on a Mac

doc/src/Build_package.rst

@@ -47,15 +47,13 @@ versus make.
 
 **CMake build**\ :
 
-
-.. code-block:: bash
+.. code-block:: csh
 
    -D PKG_NAME=value          # yes or no (default)
 
 Examples:
 
-
-.. code-block:: bash
+.. code-block:: csh
 
    -D PKG_MANYBODY=yes
    -D PKG_USER-INTEL=yes
@@ -76,7 +74,6 @@ once with CMake.
 
 **Traditional make**\ :
 
-
 .. code-block:: bash
 
    cd lammps/src
@@ -87,7 +84,6 @@ once with CMake.
 
 Examples:
 
-
 .. code-block:: bash
 
    make no-rigid
@@ -132,10 +128,8 @@ src directory.
    That is no longer the case, so that CMake will build as-is without the
    need to un-install those packages.
 
-
 ----------
 
-
 **CMake shortcuts for installing many packages**\ :
 
 Instead of specifying all the CMake options via the command-line,
@@ -152,13 +146,14 @@ one of them as a starting point and customize it to your needs.
 
 .. code-block:: bash
 
-    cmake -C ../cmake/presets/all_on.cmake  [OPTIONS] ../cmake  # enable all packages
-    cmake -C ../cmake/presets/all_off.cmake [OPTIONS] ../cmake  # disable all packages
     cmake -C ../cmake/presets/minimal.cmake [OPTIONS] ../cmake  # enable just a few core packages
-    cmake -C ../cmake/presets/most.cmake    [OPTIONS] ../cmake  # enable most common packages
+    cmake -C ../cmake/presets/most.cmake    [OPTIONS] ../cmake  # enable most packages
     cmake -C ../cmake/presets/nolib.cmake   [OPTIONS] ../cmake  # disable packages that do require extra libraries or tools
     cmake -C ../cmake/presets/clang.cmake   [OPTIONS] ../cmake  # change settings to use the Clang compilers by default
-    cmake -C ../cmake/presets/mingw.cmake   [OPTIONS] ../cmake  # enable all packages compatible with MinGW compilers
+    cmake -C ../cmake/presets/intel.cmake   [OPTIONS] ../cmake  # change settings to use the Intel compilers by default
+    cmake -C ../cmake/presets/all_on.cmake  [OPTIONS] ../cmake  # enable all packages
+    cmake -C ../cmake/presets/all_off.cmake [OPTIONS] ../cmake  # disable all packages
+    mingw64-cmake -C ../cmake/presets/mingw-cross.cmake [OPTIONS] ../cmake  #  compile with MinGW cross compilers
 
 .. note::
 
@@ -169,7 +164,6 @@ one of them as a starting point and customize it to your needs.
 
 **Example:**
 
-
 .. code-block:: bash
 
    # build LAMMPS with most commonly used packages, but then remove
@@ -186,15 +180,13 @@ one of them as a starting point and customize it to your needs.
    # but leaving all other settings untouched. You can run:
    cmake -C ../cmake/presets/no_all.cmake .
 
-
 ----------
 
-
 **Make shortcuts for installing many packages**\ :
 
 The following commands are useful for managing package source files
 and their installation when building LAMMPS via traditional make.
-Just type "make" in lammps/src to see a one-line summary.
+Just type ``make`` in lammps/src to see a one-line summary.
 
 These commands install/un-install sets of packages:
 
@@ -211,8 +203,8 @@ These commands install/un-install sets of packages:
     make yes-ext                        # install packages that require external libraries
     make no-ext                         # uninstall packages that require external libraries
 
-which install/un-install various sets of packages.  Typing "make
-package" will list all the these commands.
+which install/un-install various sets of packages.  Typing ``make
+package`` will list all the these commands.
 
 .. note::
 
@@ -221,7 +213,7 @@ package" will list all the these commands.
    directory src and the sub-directories with the package name (e.g.
    src/KSPACE, src/USER-ATC), so that the files are included or excluded
    when LAMMPS is built.  Only source files in the src folder will be
-   compiled. 
+   compiled.
 
 The following make commands help manage files that exist in both the
 src directory and in package sub-directories.  You do not normally
@@ -229,23 +221,23 @@ need to use these commands unless you are editing LAMMPS files or are
 :doc:`installing a patch <Install_patch>` downloaded from the LAMMPS web
 site.
 
-Type "make package-status" or "make ps" to show which packages are
+Type ``make package-status`` or ``make ps`` to show which packages are
 currently installed.  For those that are installed, it will list any
 files that are different in the src directory and package
 sub-directory.
 
-Type "make package-installed" or "make pi" to show which packages are
+Type ``make package-installed`` or ``make pi`` to show which packages are
 currently installed, without listing the status of packages that are
 not installed.
 
-Type "make package-update" or "make pu" to overwrite src files with
+Type ``make package-update`` or ``make pu`` to overwrite src files with
 files from the package sub-directories if the package is installed.
 It should be used after a :doc:`patch has been applied <Install_patch>`,
 since patches only update the files in the package sub-directory, but
 not the src files.
 
-Type "make package-overwrite" to overwrite files in the package
+Type ``make package-overwrite`` to overwrite files in the package
 sub-directories with src files.
 
-Type "make package-diff" to list all differences between pairs of
+Type ``make package-diff`` to list all differences between pairs of
 files in both the source directory and the package directory.

doc/src/Build_settings.rst

@@ -12,22 +12,20 @@ explain how to do this for building both with CMake and make.
 * :ref:`Output of movie files <graphics>` via the :doc:`dump_movie <dump_image>` command
 * :ref:`Memory allocation alignment <align>`
 * :ref:`Workaround for long long integers <longlong>`
-* :ref:`Error handling exceptions <exceptions>` when using LAMMPS as a library  
-
+* :ref:`Error handling exceptions <exceptions>` when using LAMMPS as a library
 
 ----------
 
-
 .. _cxx11:
 
 C++11 standard compliance
 ------------------------------------------
 
-The LAMMPS developers plan to transition to make the C++11 standard the
-minimum requirement for compiling LAMMPS.  Currently this only applies to
-some packages like KOKKOS while the rest aims to be compatible with the C++98
-standard.  Most currently used compilers are compatible with C++11; some need
-to set extra flags to enable C++11 compliance.  Example for GNU c++:
+A C++11 standard compatible compiler is a requirement for compiling LAMMPS.
+LAMMPS version 3 March 2020 is the last version compatible with the previous
+C++98 standard for the core code and most packages. Most currently used
+C++ compilers are compatible with C++11, but some older ones may need extra
+flags to enable C++11 compliance.  Example for GNU c++ 4.8.x:
 
 .. code-block:: make
 
@@ -35,7 +33,6 @@ to set extra flags to enable C++11 compliance.  Example for GNU c++:
 
 ----------
 
-
 .. _fft:
 
 FFT library
@@ -49,7 +46,6 @@ LAMMPS can use them if they are available on your system.
 
 **CMake variables**\ :
 
-
 .. code-block:: bash
 
    -D FFT=value              # FFTW3 or MKL or KISS, default is FFTW3 if found, else KISS
@@ -69,7 +65,6 @@ OpenMP threads are enabled and a packages like KOKKOS or USER-OMP is
 used.  If CMake cannot detect the FFT library, you can set these variables
 to assist:
 
-
 .. code-block:: bash
 
    -D FFTW3_INCLUDE_DIRS=path  # path to FFTW3 include files
@@ -81,7 +76,6 @@ to assist:
 
 **Makefile.machine settings**\ :
 
-
 .. code-block:: make
 
    FFT_INC = -DFFT_FFTW3         # -DFFT_FFTW3, -DFFT_FFTW (same as -DFFT_FFTW3), -DFFT_MKL, or -DFFT_KISS
@@ -91,8 +85,7 @@ to assist:
    FFT_INC = -DFFT_MKL_THREADS   # enable using threaded FFTs with MKL libraries
    FFT_INC = -DFFT_PACK_ARRAY    # or -DFFT_PACK_POINTER or -DFFT_PACK_MEMCPY
 
-# default is FFT\_PACK\_ARRAY if not specified
-
+# default is FFT_PACK_ARRAY if not specified
 
 .. code-block:: make
 
@@ -102,14 +95,14 @@ to assist:
    FFT_LIB =       -lfftw3 -lfftw3_omp # FFTW3 double precision with threads (needs -DFFT_FFTW_THREADS)
    FFT_LIB =       -lfftw3 -lfftw3f    # FFTW3 single precision
    FFT_LIB =       -lmkl_intel_lp64 -lmkl_sequential -lmkl_core   # MKL with Intel compiler, serial interface
-   FFT_LIB =       -lmkl_gf_lp64 -lmkl_sequential -lmkl_core      # MKL with GNU compier, serial interface
+   FFT_LIB =       -lmkl_gf_lp64 -lmkl_sequential -lmkl_core      # MKL with GNU compiler, serial interface
    FFT_LIB =       -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core # MKL with Intel compiler, threaded interface
    FFT_LIB =       -lmkl_gf_lp64 -lmkl_gnu_thread -lmkl_core      # MKL with GNU compiler, threaded interface
    FFT_LIB =       -lmkl_rt            # MKL with automatic runtime selection of interface libs
 
-As with CMake, you do not need to set paths in FFT\_INC or FFT\_PATH, if
+As with CMake, you do not need to set paths in ``FFT_INC`` or ``FFT_PATH``, if
 the compiler can find the FFT header and library files in its default search path.
-You must specify FFT\_LIB with the appropriate FFT libraries to include in the link.
+You must specify ``FFT_LIB`` with the appropriate FFT libraries to include in the link.
 
 **CMake and make info**\ :
 
@@ -133,14 +126,15 @@ platform and can be faster than the KISS FFT library.  You can
 download it from `www.fftw.org <http://www.fftw.org>`_.  LAMMPS requires
 version 3.X; the legacy version 2.1.X is no longer supported.
 
-Building FFTW for your box should be as simple as ./configure; make;
-make install.  The install command typically requires root privileges
+Building FFTW for your box should be as simple as ``./configure; make;
+make install``\ .  The install command typically requires root privileges
 (e.g. invoke it via sudo), unless you specify a local directory with
-the "--prefix" option of configure.  Type "./configure --help" to see
+the "--prefix" option of configure.  Type ``./configure --help`` to see
 various options.
 
 The Intel MKL math library is part of the Intel compiler suite.  It
-can be used with the Intel or GNU compiler (see FFT\_LIB setting above).
+can be used with the Intel or GNU compiler (see the ``FFT_LIB`` setting
+above).
 
 Performing 3d FFTs in parallel can be time consuming due to data
 access and required communication.  This cost can be reduced by
@@ -149,16 +143,15 @@ precision means the real and imaginary parts of a complex datum are
 4-byte floats.  Double precision means they are 8-byte doubles.  Note
 that Fourier transform and related PPPM operations are somewhat less
 sensitive to floating point truncation errors and thus the resulting
-error is less than the difference in precision. Using the -DFFT\_SINGLE
+error is less than the difference in precision. Using the ``-DFFT_SINGLE``
 setting trades off a little accuracy for reduced memory use and
 parallel communication costs for transposing 3d FFT data.
 
-When using -DFFT\_SINGLE with FFTW3 you may need to build the FFTW
+When using ``-DFFT_SINGLE`` with FFTW3 you may need to build the FFTW
 library a second time with support for single-precision.
 
 For FFTW3, do the following, which should produce the additional
-library libfftw3f.a or libfftw3f.so.
-
+library ``libfftw3f.a`` or ``libfftw3f.so``\ .
 
 .. code-block:: bash
 
@@ -167,15 +160,13 @@ library libfftw3f.a or libfftw3f.so.
 
 Performing 3d FFTs requires communication to transpose the 3d FFT
 grid.  The data packing/unpacking for this can be done in one of 3
-modes (ARRAY, POINTER, MEMCPY) as set by the FFT\_PACK syntax above.
+modes (ARRAY, POINTER, MEMCPY) as set by the FFT_PACK syntax above.
 Depending on the machine, the size of the FFT grid, the number of
 processors used, one option may be slightly faster.  The default is
 ARRAY mode.
 
-
 ----------
 
-
 .. _size:
 
 Size of LAMMPS data types
@@ -187,19 +178,18 @@ adequate.
 
 **CMake variable**\ :
 
-
 .. code-block:: bash
 
    -D LAMMPS_SIZES=value   # smallbig (default) or bigbig or smallsmall
 
 **Makefile.machine setting**\ :
 
-
 .. code-block:: make
 
    LMP_INC = -DLAMMPS_SMALLBIG    # or -DLAMMPS_BIGBIG or -DLAMMPS_SMALLSMALL
 
-# default is LAMMPS\_SMALLBIG if not specified
+The default setting is ``-DLAMMPS_SMALLBIG`` if nothing is specified
+
 **CMake and make info**\ :
 
 The default "smallbig" setting allows for simulations with:
@@ -247,12 +237,10 @@ than crashing randomly or corrupting data.
 Also note that the GPU package requires its lib/gpu library to be
 compiled with the same size setting, or the link will fail.  A CMake
 build does this automatically.  When building with make, the setting
-in whichever lib/gpu/Makefile is used must be the same as above.
-
+in whichever ``lib/gpu/Makefile`` is used must be the same as above.
 
 ----------
 
-
 .. _graphics:
 
 Output of JPG, PNG, and movie files
@@ -265,7 +253,6 @@ following settings:
 
 **CMake variables**\ :
 
-
 .. code-block:: bash
 
    -D WITH_JPEG=value      # yes or no
@@ -279,7 +266,6 @@ Usually these settings are all that is needed.  If CMake cannot find
 the graphics header, library, executable files, you can set these
 variables:
 
-
 .. code-block:: bash
 
    -D JPEG_INCLUDE_DIR=path    # path to jpeglib.h header file
@@ -292,7 +278,6 @@ variables:
 
 **Makefile.machine settings**\ :
 
-
 .. code-block:: make
 
    LMP_INC = -DLAMMPS_JPEG
@@ -303,15 +288,16 @@ variables:
    JPG_PATH = -L/usr/lib            # paths to libjpeg.a, libpng.a, libz.a (.so) files if make cannot find them
    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
+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.
 
 **CMake and make info**\ :
 
-Using ffmpeg to output movie files requires that your machine
+Using ``ffmpeg`` to output movie files requires that your machine
 supports the "popen" function in the standard runtime library.
 
 .. note::
@@ -321,10 +307,8 @@ supports the "popen" function in the standard runtime library.
    communication library and lead to simulations using ffmpeg to hang or
    crash.
 
-
 ----------
 
-
 .. _gzip:
 
 Read or write compressed files
@@ -336,7 +320,6 @@ gzip compression by several LAMMPS commands, including
 
 **CMake variables**\ :
 
-
 .. code-block:: bash
 
    -D WITH_GZIP=value       # yes or no
@@ -345,7 +328,6 @@ gzip compression by several LAMMPS commands, including
 
 **Makefile.machine setting**\ :
 
-
 .. code-block:: make
 
    LMP_INC = -DLAMMPS_GZIP
@@ -365,16 +347,14 @@ found by LAMMPS during a run.
    I/O is also available using a compression library instead, which is
    what the :ref:`COMPRESS package <PKG-COMPRESS>` enables.
 
-
 ----------
 
-
 .. _align:
 
 Memory allocation alignment
 ---------------------------------------
 
-This setting enables the use of the posix\_memalign() call instead of
+This setting enables the use of the posix_memalign() call instead of
 malloc() when LAMMPS allocates large chunks or memory.  This can make
 vector instructions on CPUs more efficient, if dynamically allocated
 memory is aligned on larger-than-default byte boundaries.
@@ -385,33 +365,29 @@ aligned on 64-byte boundaries.
 
 **CMake variable**\ :
 
-
 .. code-block:: bash
 
    -D LAMMPS_MEMALIGN=value            # 0, 8, 16, 32, 64 (default)
 
-Use a LAMMPS\_MEMALIGN value of 0 to disable using posix\_memalign()
+Use a ``LAMMPS_MEMALIGN`` value of 0 to disable using posix_memalign()
 and revert to using the malloc() C-library function instead.  When
 compiling LAMMPS for Windows systems, malloc() will always be used
 and this setting ignored.
 
 **Makefile.machine setting**\ :
 
-
 .. code-block:: make
 
    LMP_INC = -DLAMMPS_MEMALIGN=value   # 8, 16, 32, 64
 
-Do not set -DLAMMPS\_MEMALIGN, if you want to have memory allocated
-with the malloc() function call instead. -DLAMMPS\_MEMALIGN **cannot**
+Do not set ``-DLAMMPS_MEMALIGN``, if you want to have memory allocated
+with the malloc() function call instead. ``-DLAMMPS_MEMALIGN`` **cannot**
 be used on Windows, as it does use different function calls for
 allocating aligned memory, that are not compatible with how LAMMPS
 manages its dynamical memory.
 
-
 ----------
 
-
 .. _longlong:
 
 Workaround for long long integers
@@ -424,22 +400,18 @@ those systems:
 
 **CMake variable**\ :
 
-
 .. code-block:: bash
 
    -D LAMMPS_LONGLONG_TO_LONG=value     # yes or no (default)
 
 **Makefile.machine setting**\ :
 
-
 .. code-block:: make
 
    LMP_INC = -DLAMMPS_LONGLONG_TO_LONG
 
-
 ----------
 
-
 .. _exceptions:
 
 Exception handling when using LAMMPS as a library
@@ -453,14 +425,12 @@ e.g. to Python. Of course the calling code has to be set up to
 
 **CMake variable**\ :
 
-
 .. code-block:: bash
 
    -D LAMMPS_EXCEPTIONS=value        # yes or no (default)
 
 **Makefile.machine setting**\ :
 
-
 .. code-block:: make
 
    LMP_INC = -DLAMMPS_EXCEPTIONS

doc/src/Build_windows.rst

@@ -6,10 +6,8 @@ Notes for building LAMMPS on Windows
 * :ref:`Using GNU GCC ported to Windows <gnu>`
 * :ref:`Using a cross-compiler <cross>`
 
-
 ----------
 
-
 .. _generic:
 
 General remarks
@@ -57,8 +55,8 @@ and the corresponding new code. A machine makefile for using cygwin for
 the old build system is provided. Using CMake for this mode of compilation
 is untested and not likely to work.
 
-When compiling for Windows do **not** set the -DLAMMPS\_MEMALIGN define
-in the LMP\_INC makefile variable and add -lwsock32 -lpsapi to the linker
+When compiling for Windows do **not** set the -DLAMMPS_MEMALIGN define
+in the LMP_INC makefile variable and add -lwsock32 -lpsapi to the linker
 flags in LIB makefile variable. Try adding -static-libgcc or -static or
 both to the linker flags when your resulting LAMMPS Windows executable
 complains about missing .dll files. The CMake configuration should set
@@ -85,10 +83,16 @@ traditional build system, but CMake has also been successfully tested
 using the mingw32-cmake and mingw64-cmake wrappers that are bundled
 with the cross-compiler environment on Fedora machines. A CMake preset
 selecting all packages compatible with this cross-compilation build
-is provided. You will likely need to disable the GPU package unless you
-download and install the contents of the pre-compiled `OpenCL ICD loader library <https://download.lammps.org/thirdparty/opencl-win-devel.tar.gz>`_
-into your MinGW64 cross-compiler environment. The cross-compilation
-currently will only produce non-MPI serial binaries.
+is provided.  The GPU package can only be compiled with OpenCL support
+and you need to download and install the pre-compiled
+`OpenCL ICD loader library <https://download.lammps.org/thirdparty/opencl-win-devel.tar.gz>`_
+into your MinGW64 cross-compiler environment.  With CMake this will be
+done transparently.  To compile with MPI support, a pre-compiled
+library and the corresponding header files are required.  There is
+`one package for 32-bit Windows <https://download.lammps.org/thirdparty/mpich2-win32-devel.tar.gz>`_
+and `a second package for 64-bit Windows <https://download.lammps.org/thirdparty/mpich2-win64-devel.tar.gz>`_.
+When building with CMake, the matching package will be downloaded
+automatically, but MPI support has to be explicitly enabled with ``-DBUILD_MPI=on``.
 
 Please keep in mind, though, that this only applies to **compiling** LAMMPS.
 Whether the resulting binaries do work correctly is not tested by the

doc/src/Commands.rst

@@ -4,7 +4,6 @@ Commands
 These pages describe how a LAMMPS input script is formatted and the
 commands in it are used to define a LAMMPS simulation.
 
-
 .. toctree::
    :maxdepth: 1
 

doc/src/Commands_bond.rst

@@ -99,7 +99,6 @@ have accelerated versions.  This is indicated by additional letters in
 parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
 OPT.
 
-
 .. table_from_list::
    :columns: 4
 

doc/src/Commands_fix.rst

@@ -119,6 +119,7 @@ OPT.
    * :doc:`npt/eff <fix_nh_eff>`
    * :doc:`npt/sphere (o) <fix_npt_sphere>`
    * :doc:`npt/uef <fix_nh_uef>`
+   * :doc:`numdiff <fix_numdiff>`
    * :doc:`nve (iko) <fix_nve>`
    * :doc:`nve/asphere (i) <fix_nve_asphere>`
    * :doc:`nve/asphere/noforce <fix_nve_asphere_noforce>`

doc/src/Commands_input.rst

@@ -16,7 +16,6 @@ simulation with all the settings.  Rather, the input script is read
 one line at a time and each command takes effect when it is read.
 Thus this sequence of commands:
 
-
 .. code-block:: LAMMPS
 
    timestep 0.5
@@ -25,7 +24,6 @@ Thus this sequence of commands:
 
 does something different than this sequence:
 
-
 .. code-block:: LAMMPS
 
    run      100
@@ -48,7 +46,7 @@ is to have the desired effect.  For example, the
 :doc:`read_data <read_data>` command initializes the system by setting
 up the simulation box and assigning atoms to processors.  If default
 values are not desired, the :doc:`processors <processors>` and
-:doc:`boundary <boundary>` commands need to be used before read\_data to
+:doc:`boundary <boundary>` commands need to be used before read_data to
 tell LAMMPS how to map processors to the simulation box.
 
 Many input script errors are detected by LAMMPS and an ERROR or

doc/src/Commands_pair.rst

@@ -77,6 +77,8 @@ OPT.
    * :doc:`coul/long/cs (g) <pair_cs>`
    * :doc:`coul/long/soft (o) <pair_fep_soft>`
    * :doc:`coul/msm (o) <pair_coul>`
+   * :doc:`coul/slater/cut <pair_coul_slater>`
+   * :doc:`coul/slater/long <pair_coul_slater>`   
    * :doc:`coul/shield <pair_coul_shield>`
    * :doc:`coul/streitz <pair_coul>`
    * :doc:`coul/wolf (ko) <pair_coul>`
@@ -95,7 +97,7 @@ OPT.
    * :doc:`eam/fs (gikot) <pair_eam>`
    * :doc:`edip (o) <pair_edip>`
    * :doc:`edip/multi <pair_edip>`
-   * :doc:`edpd <pair_meso>`
+   * :doc:`edpd <pair_mesodpd>`
    * :doc:`eff/cut <pair_eff>`
    * :doc:`eim (o) <pair_eim>`
    * :doc:`exp6/rx (k) <pair_exp6_rx>`
@@ -171,8 +173,8 @@ OPT.
    * :doc:`lubricate/poly (o) <pair_lubricate>`
    * :doc:`lubricateU <pair_lubricateU>`
    * :doc:`lubricateU/poly <pair_lubricateU>`
-   * :doc:`mdpd <pair_meso>`
-   * :doc:`mdpd/rhosum <pair_meso>`
+   * :doc:`mdpd <pair_mesodpd>`
+   * :doc:`mdpd/rhosum <pair_mesodpd>`
    * :doc:`meam/c <pair_meamc>`
    * :doc:`meam/spline (o) <pair_meam_spline>`
    * :doc:`meam/sw/spline <pair_meam_sw_spline>`
@@ -242,7 +244,7 @@ OPT.
    * :doc:`sw (giko) <pair_sw>`
    * :doc:`table (gko) <pair_table>`
    * :doc:`table/rx (k) <pair_table_rx>`
-   * :doc:`tdpd <pair_meso>`
+   * :doc:`tdpd <pair_mesodpd>`
    * :doc:`tersoff (giko) <pair_tersoff>`
    * :doc:`tersoff/mod (gko) <pair_tersoff_mod>`
    * :doc:`tersoff/mod/c (o) <pair_tersoff_mod>`

doc/src/Commands_parse.rst

@@ -86,7 +86,6 @@ LAMMPS:
 
    This can be useful for formatting print output to a desired precision:
 
-
    .. code-block:: LAMMPS
 
       print "Final energy per atom: $(pe/atoms:%10.3f) eV/atom"
@@ -102,7 +101,7 @@ LAMMPS:
       print           "B2 = ${b$a}"
 
    Nor can you specify an expression like "$($x-1.0)" for an immediate
-   variable, but you could use $(v\_x-1.0), since the latter is valid
+   variable, but you could use $(v_x-1.0), since the latter is valid
    syntax for an :doc:`equal-style variable <variable>`.
 
    See the :doc:`variable <variable>` command for more details of how
@@ -116,7 +115,7 @@ LAMMPS:
    underscores, or punctuation characters.
 
 .. _five:
-   
+
 5. The first word is the command name.  All successive words in the line
    are arguments.
 

doc/src/Commands_structure.rst

@@ -9,7 +9,7 @@ page.
 A LAMMPS input script typically has 4 parts:
 
 1. :ref:`Initialization <init>`
-2. :ref:`System definition <system>` 
+2. :ref:`System definition <system>`
 3. :ref:`Simulation settings <settings>`
 4. :ref:`Run a simulation <run>`
 

doc/src/Errors.rst

@@ -7,7 +7,6 @@ and warnings doc pages give complete lists of all the messages the
 code may generate (except those generated by USER packages), with
 additional details for many of them.
 
-
 .. toctree::
    :maxdepth: 1
 

doc/src/Errors_bugs.rst

@@ -4,7 +4,7 @@ Reporting bugs
 If you are confident that you have found a bug in LAMMPS, please follow the steps outlined below:
 
  * Check the `New features and bug fixes
-   <http://lammps.sandia.gov/bug.html>`_ section of the `LAMMPS WWW site
+   <https://lammps.sandia.gov/bug.html>`_ section of the `LAMMPS WWW site
    <lws_>`_ to see if the bug has already been addressed in a patch.
  * Check that your issue can be reproduced with the latest development
    version of LAMMPS.
@@ -14,7 +14,7 @@ If you are confident that you have found a bug in LAMMPS, please follow the step
    if your issue has already been reported and if it is still open.
  * Check the `GitHub Pull Requests page <https://github.com/lammps/pulls>`_
    if there is already a fix for your bug pending.
- * Check the `mailing list archives <http://lammps.sandia.gov/mail.html>`_
+ * Check the `mailing list archives <https://lammps.sandia.gov/mail.html>`_
    to see if the issue has been discussed before.
 
 If none of these steps yields any useful information, please file
@@ -41,5 +41,5 @@ is overlooked and then forgotten.  Issues on GitHub have to be explicitly
 closed, so that will *guarantee* that at least one LAMMPS developer will
 have looked at it.
 
-.. _lws: http://lammps.sandia.gov
+.. _lws: https://lammps.sandia.gov
 .. _gip: https://github.com/lammps/issues

doc/src/Errors_common.rst

@@ -38,8 +38,8 @@ input script command that it was processing.  Of course, LAMMPS cannot
 figure out your physics or numerical mistakes, like choosing too big a
 timestep, specifying erroneous force field coefficients, or putting 2
 atoms on top of each other!  If you run into errors that LAMMPS
-doesn't catch that you think it should flag, please send an email to
-the `developers <http://lammps.sandia.gov/authors.html>`_.
+does not catch that you think it should flag, please send an email to
+the `developers <https://lammps.sandia.gov/authors.html>`_.
 
 If you get an error message about an invalid command in your input
 script, you can determine what command is causing the problem by
@@ -63,25 +63,23 @@ is an integer or floating-point number, respectively, and reject the
 input with an error message (for instance, when an integer is required,
 but a floating-point number 1.0 is provided):
 
-
 .. parsed-literal::
 
    ERROR: Expected integer parameter instead of '1.0' in input script or data file
 
 Some commands allow for using variable references in place of numeric
 constants so that the value can be evaluated and may change over the
-course of a run.  This is typically done with the syntax *v\_name* for a
+course of a run.  This is typically done with the syntax *v_name* for a
 parameter, where name is the name of the variable. On the other hand,
-immediate variable expansion with the syntax $\ *name* is performed while
+immediate variable expansion with the syntax ${name} is performed while
 reading the input and before parsing commands,
 
 .. note::
 
-   Using a variable reference (i.e. *v\_name*) is only allowed if
+   Using a variable reference (i.e. *v_name*) is only allowed if
    the documentation of the corresponding command explicitly says it is.
    Otherwise, you will receive an error message of this kind:
 
-
 .. parsed-literal::
 
    ERROR: Expected floating point parameter instead of 'v_name' in input script or data file
@@ -98,13 +96,13 @@ cases:
 
 LAMMPS runs in the available memory a processor allows to be
 allocated.  Most reasonable MD runs are compute limited, not memory
-limited, so this shouldn't be a bottleneck on most platforms.  Almost
+limited, so this should not be a bottleneck on most platforms.  Almost
 all large memory allocations in the code are done via C-style malloc's
 which will generate an error message if you run out of memory.
 Smaller chunks of memory are allocated via C++ "new" statements.  If
 you are unlucky you could run out of memory just when one of these
 small requests is made, in which case the code will crash or hang (in
-parallel), since LAMMPS doesn't trap on those errors.
+parallel), since LAMMPS does not trap on those errors.
 
 Illegal arithmetic can cause LAMMPS to run slow or crash.  This is
 typically due to invalid physics and numerics that your simulation is

doc/src/Errors_warnings.rst

@@ -7,7 +7,6 @@ documentation for the offending command may help.  Warning messages
 also list the source file and line number where the warning was
 generated.  For example, a message like this:
 
-
 .. parsed-literal::
 
    WARNING: Bond atom missing in box size check (domain.cpp:187)
@@ -21,12 +20,8 @@ code or contact the author of the package.
 
 Doc page with :doc:`ERROR messages <Errors_messages>`
 
-
 ----------
 
-
-
-
 *Adjusting Coulombic cutoff for MSM, new cutoff = %g*
    The adjust/cutoff command is turned on and the Coulombic cutoff has been
    adjusted to match the user-specified accuracy.
@@ -42,7 +37,7 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
 
 *Angles are defined but no angle style is set*
    The topology contains angles, but there are no angle forces computed
-   since there was no angle\_style command.
+   since there was no angle_style command.
 
 *Atom style in data file differs from currently defined atom style*
    Self-explanatory.
@@ -67,7 +62,7 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
 
 *Bonds are defined but no bond style is set*
    The topology contains bonds, but there are no bond forces computed
-   since there was no bond\_style command.
+   since there was no bond_style command.
 
 *Bond/angle/dihedral extent > half of periodic box length*
    This is a restriction because LAMMPS can be confused about which image
@@ -88,8 +83,8 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
 *Both groups in compute group/group have a net charge; the Kspace boundary correction to energy will be non-zero*
    Self-explanatory.
 
-*Calling write\_dump before a full system init.*
-   The write\_dump command is used before the system has been fully
+*Calling write_dump before a full system init.*
+   The write_dump command is used before the system has been fully
    initialized as part of a 'run' or 'minimize' command. Not all dump
    styles and features are fully supported at this point and thus the
    command may fail or produce incomplete or incorrect output. Insert
@@ -136,11 +131,11 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
    degrees-of-freedom for the atoms in those partial rigid bodies will
    not be accounted for.
 
-*Create\_bonds max distance > minimum neighbor cutoff*
+*Create_bonds max distance > minimum neighbor cutoff*
    This means atom pairs for some atom types may not be in the neighbor
    list and thus no bond can be created between them.
 
-*Delete\_atoms cutoff > minimum neighbor cutoff*
+*Delete_atoms cutoff > minimum neighbor cutoff*
    This means atom pairs for some atom types may not be in the neighbor
    list and thus an atom in that pair cannot be deleted.
 
@@ -163,7 +158,7 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
 
 *Dihedrals are defined but no dihedral style is set*
    The topology contains dihedrals, but there are no dihedral forces computed
-   since there was no dihedral\_style command.
+   since there was no dihedral_style command.
 
 *Dump dcd/xtc timestamp may be wrong with fix dt/reset*
    If the fix changes the timestep, the dump dcd file will not
@@ -177,7 +172,7 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
 *Estimated error in splitting of dispersion coeffs is %g*
    Error is greater than 0.0001 percent.
 
-*Ewald/disp Newton solver failed, using old method to estimate g\_ewald*
+*Ewald/disp Newton solver failed, using old method to estimate g_ewald*
    Self-explanatory. Choosing a different cutoff value may help.
 
 *FENE bond too long*
@@ -192,6 +187,9 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
    A FENE bond has stretched dangerously far.  It's interaction strength
    will be truncated to attempt to prevent the bond from blowing up.
 
+*Fix halt condition for fix-id %s met on step %ld with value %g*
+   Self explanatory.
+
 *Fix SRD walls overlap but fix srd overlap not set*
    You likely want to set this in your input script.
 
@@ -214,8 +212,8 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
    This is probably an error, since you should not delete only one atom
    of a molecule.
 
-*Fix gcmc using full\_energy option*
-   Fix gcmc has automatically turned on the full\_energy option since it
+*Fix gcmc using full_energy option*
+   Fix gcmc has automatically turned on the full_energy option since it
    is required for systems like the one specified by the user. User input
    included one or more of the following: kspace, triclinic, a hybrid
    pair style, an eam pair style, or no "single" function for the pair
@@ -270,19 +268,19 @@ This will most likely cause errors in kinetic fluctuations.
 *Fixes cannot send data in Kokkos communication, switching to classic communication*
    This is current restriction with Kokkos.
 
-*For better accuracy use 'pair\_modify table 0'*
+*For better accuracy use 'pair_modify table 0'*
    The user-specified force accuracy cannot be achieved unless the table
-   feature is disabled by using 'pair\_modify table 0'.
+   feature is disabled by using 'pair_modify table 0'.
 
 *Geometric mixing assumed for 1/r\^6 coefficients*
    Self-explanatory.
 
-*Group for fix\_modify temp != fix group*
-   The fix\_modify command is specifying a temperature computation that
+*Group for fix_modify temp != fix group*
+   The fix_modify command is specifying a temperature computation that
    computes a temperature on a different group of atoms than the fix
    itself operates on.  This is probably not what you want to do.
 
-*H matrix size has been exceeded: m\_fill=%d H.m=%d\n*
+*H matrix size has been exceeded: m_fill=%d H.m=%d\n*
    This is the size of the matrix.
 
 *Ignoring unknown or incorrect info command flag*
@@ -304,7 +302,7 @@ This will most likely cause errors in kinetic fluctuations.
 
 *Impropers are defined but no improper style is set*
    The topology contains impropers, but there are no improper forces computed
-   since there was no improper\_style command.
+   since there was no improper_style command.
 
 *Inconsistent image flags*
    The image flags for a pair on bonded atoms appear to be inconsistent.
@@ -339,22 +337,22 @@ This will most likely cause errors in kinetic fluctuations.
 *KIM Model does not provide 'particleVirial'; virial per atom will be zero*
    Self-explanatory.
 
-*Kspace\_modify slab param < 2.0 may cause unphysical behavior*
-   The kspace\_modify slab parameter should be larger to insure periodic
+*Kspace_modify slab param < 2.0 may cause unphysical behavior*
+   The kspace_modify slab parameter should be larger to insure periodic
    grids padded with empty space do not overlap.
 
 *Less insertions than requested*
    The fix pour command was unsuccessful at finding open space
    for as many particles as it tried to insert.
 
-*Library error in lammps\_gather\_atoms*
+*Library error in lammps_gather_atoms*
    This library function cannot be used if atom IDs are not defined
    or are not consecutively numbered.
 
-*Library error in lammps\_scatter\_atoms*
+*Library error in lammps_scatter_atoms*
    This library function cannot be used if atom IDs are not defined or
    are not consecutively numbered, or if no atom map is defined.  See the
-   atom\_modify command for details about atom maps.
+   atom_modify command for details about atom maps.
 
 *Likewise 1-2 special neighbor interactions != 1.0*
    The topology contains bonds, but there is no bond style defined
@@ -377,15 +375,15 @@ This will most likely cause errors in kinetic fluctuations.
    pairs in the neighbor list in expectation of interactions for
    those pairs being computed from the dihedral style.
 
-*Lost atoms via change\_box: original %ld current %ld*
+*Lost atoms via change_box: original %ld current %ld*
    The command options you have used caused atoms to be lost.
 
-*Lost atoms via displace\_atoms: original %ld current %ld*
+*Lost atoms via displace_atoms: original %ld current %ld*
    The command options you have used caused atoms to be lost.
 
 *Lost atoms: original %ld current %ld*
    Lost atoms are checked for each time thermo output is done.  See the
-   thermo\_modify lost command for options.  Lost atoms usually indicate
+   thermo_modify lost command for options.  Lost atoms usually indicate
    bad dynamics, e.g. atoms have been blown far out of the simulation
    box, or moved further than one processor's sub-domain away before
    reneighboring.
@@ -408,8 +406,8 @@ This will most likely cause errors in kinetic fluctuations.
    This means the bonded atoms will not be excluded in pair-wise
    interactions.
 
-*Molecule template for create\_atoms has multiple molecules*
-   The create\_atoms command will only create molecules of a single type,
+*Molecule template for create_atoms has multiple molecules*
+   The create_atoms command will only create molecules of a single type,
    i.e. the first molecule in the template.
 
 *Molecule template for fix gcmc has multiple molecules*
@@ -474,21 +472,21 @@ This will most likely cause errors in kinetic fluctuations.
 *Neighbor exclusions used with KSpace solver may give inconsistent Coulombic energies*
    This is because excluding specific pair interactions also excludes
    them from long-range interactions which may not be the desired effect.
-   The special\_bonds command handles this consistently by insuring
+   The special_bonds command handles this consistently by insuring
    excluded (or weighted) 1-2, 1-3, 1-4 interactions are treated
    consistently by both the short-range pair style and the long-range
    solver.  This is not done for exclusions of charged atom pairs via the
-   neigh\_modify exclude command.
+   neigh_modify exclude command.
 
-*New thermo\_style command, previous thermo\_modify settings will be lost*
-   If a thermo\_style command is used after a thermo\_modify command, the
-   settings changed by the thermo\_modify command will be reset to their
-   default values.  This is because the thermo\_modify command acts on
-   the currently defined thermo style, and a thermo\_style command creates
+*New thermo_style command, previous thermo_modify settings will be lost*
+   If a thermo_style command is used after a thermo_modify command, the
+   settings changed by the thermo_modify command will be reset to their
+   default values.  This is because the thermo_modify command acts on
+   the currently defined thermo style, and a thermo_style command creates
    a new style.
 
 *No Kspace calculation with verlet/split*
-   The 2nd partition performs a kspace calculation so the kspace\_style
+   The 2nd partition performs a kspace calculation so the kspace_style
    command must be used.
 
 *No automatic unit conversion to XTC file format conventions possible for units lj*
@@ -512,7 +510,7 @@ This will most likely cause errors in kinetic fluctuations.
    of two and the number of grid points in one or more directions have been
    adjusted to meet this requirement.
 
-*OMP\_NUM\_THREADS environment is not set.*
+*OMP_NUM_THREADS environment is not set.*
    This environment variable must be set appropriately to use the
    USER-OMP package.
 
@@ -546,10 +544,10 @@ This will most likely cause errors in kinetic fluctuations.
 *Pair dpd needs newton pair on for momentum conservation*
    Self-explanatory.
 
-*Pair dsmc: num\_of\_collisions > number\_of\_A*
+*Pair dsmc: num_of_collisions > number_of_A*
    Collision model in DSMC is breaking down.
 
-*Pair dsmc: num\_of\_collisions > number\_of\_B*
+*Pair dsmc: num_of_collisions > number_of_B*
    Collision model in DSMC is breaking down.
 
 *Pair style in data file differs from currently defined pair style*
@@ -574,15 +572,15 @@ This will most likely cause errors in kinetic fluctuations.
    sub-domain before reneighboring is triggered.
 
 *Reducing PPPM order b/c stencil extends beyond nearest neighbor processor*
-   This may lead to a larger grid than desired.  See the kspace\_modify overlap
+   This may lead to a larger grid than desired.  See the kspace_modify overlap
    command to prevent changing of the PPPM order.
 
 *Reducing PPPMDisp Coulomb order b/c stencil extends beyond neighbor processor*
-   This may lead to a larger grid than desired.  See the kspace\_modify overlap
+   This may lead to a larger grid than desired.  See the kspace_modify overlap
    command to prevent changing of the PPPM order.
 
 *Reducing PPPMDisp dispersion order b/c stencil extends beyond neighbor processor*
-   This may lead to a larger grid than desired.  See the kspace\_modify overlap
+   This may lead to a larger grid than desired.  See the kspace_modify overlap
    command to prevent changing of the PPPM order.
 
 *Replacing a fix, but new group != old group*
@@ -595,19 +593,19 @@ This will most likely cause errors in kinetic fluctuations.
    dimension to be replicated; this may cause unwanted behavior.
 
 *Resetting reneighboring criteria during PRD*
-   A PRD simulation requires that neigh\_modify settings be delay = 0,
+   A PRD simulation requires that neigh_modify settings be delay = 0,
    every = 1, check = yes.  Since these settings were not in place,
    LAMMPS changed them and will restore them to their original values
    after the PRD simulation.
 
 *Resetting reneighboring criteria during TAD*
-   A TAD simulation requires that neigh\_modify settings be delay = 0,
+   A TAD simulation requires that neigh_modify settings be delay = 0,
    every = 1, check = yes.  Since these settings were not in place,
    LAMMPS changed them and will restore them to their original values
    after the PRD simulation.
 
 *Resetting reneighboring criteria during minimization*
-   Minimization requires that neigh\_modify settings be delay = 0, every =
+   Minimization requires that neigh_modify settings be delay = 0, every =
    1, check = yes.  Since these settings were not in place, LAMMPS
    changed them and will restore them to their original values after the
    minimization.
@@ -711,7 +709,7 @@ This will most likely cause errors in kinetic fluctuations.
    which does operate on group all, so this may be inconsistent.
 
 *Temperature for thermo pressure is not for group all*
-   User-assigned temperature to thermo via the thermo\_modify command does
+   User-assigned temperature to thermo via the thermo_modify command does
    not compute temperature for all atoms.  Since thermo computes a global
    pressure, the kinetic energy contribution from the temperature is
    assumed to also be for all atoms.  Thus the pressure printed by thermo
@@ -743,12 +741,12 @@ This will most likely cause errors in kinetic fluctuations.
    LAMMPS simulation may be inefficient as a result.
 
 *Use special bonds = 0,1,1 with bond style fene*
-   Most FENE models need this setting for the special\_bonds command.
+   Most FENE models need this setting for the special_bonds command.
 
 *Use special bonds = 0,1,1 with bond style fene/expand*
-   Most FENE models need this setting for the special\_bonds command.
+   Most FENE models need this setting for the special_bonds command.
 
-*Using a many-body potential with bonds/angles/dihedrals and special\_bond exclusions*
+*Using a many-body potential with bonds/angles/dihedrals and special_bond exclusions*
    This is likely not what you want to do.  The exclusion settings will
    eliminate neighbors in the neighbor list, which the many-body potential
    needs to calculated its terms correctly.
@@ -777,13 +775,13 @@ This will most likely cause errors in kinetic fluctuations.
 *Using largest cutoff for lj/long/coul/long*
    Self-explanatory.
 
-*Using largest cutoff for pair\_style lj/long/tip4p/long*
+*Using largest cutoff for pair_style lj/long/tip4p/long*
    Self-explanatory.
 
 *Using package gpu without any pair style defined*
    Self-explanatory.
 
-*Using pair potential shift with pair\_modify compute no*
+*Using pair potential shift with pair_modify compute no*
    The shift effects will thus not be computed.
 
 *Using pair tail corrections with nonperiodic system*
@@ -791,8 +789,8 @@ This will most likely cause errors in kinetic fluctuations.
    computed by integrating the density of a periodic system out to
    infinity.
 
-*Using pair tail corrections with pair\_modify compute no*
+*Using pair tail corrections with pair_modify compute no*
    The tail corrections will thus not be computed.
 
-*pair style reax is now deprecated and will soon be retired. Users should switch to pair\_style reax/c*
+*pair style reax is now deprecated and will soon be retired. Users should switch to pair_style reax/c*
    Self-explanatory.

doc/src/Examples.rst

@@ -18,7 +18,7 @@ files and image files.
 
 If you uncomment the :doc:`dump <dump>` command in the input script, a
 text dump file will be produced, which can be animated by various
-`visualization programs <http://lammps.sandia.gov/viz.html>`_.
+`visualization programs <https://lammps.sandia.gov/viz.html>`_.
 
 If you uncomment the :doc:`dump image <dump>` command in the input
 script, and assuming you have built LAMMPS with a JPG library, JPG
@@ -38,10 +38,8 @@ particular quantity.
 
 Lists of both kinds of directories are given below.
 
-
 ----------
 
-
 Lowercase directories
 ---------------------
 
@@ -134,7 +132,7 @@ Lowercase directories
 +-------------+------------------------------------------------------------------+
 | reax        | RDX and TATB models using the ReaxFF                             |
 +-------------+------------------------------------------------------------------+
-| rerun       | use of rerun and read\_dump commands                             |
+| rerun       | use of rerun and read_dump commands                              |
 +-------------+------------------------------------------------------------------+
 | rigid       | rigid bodies modeled as independent or coupled                   |
 +-------------+------------------------------------------------------------------+
@@ -157,8 +155,7 @@ Lowercase directories
 
 Here is how you can run and visualize one of the sample problems:
 
-
-.. parsed-literal::
+.. code-block:: bash
 
    cd indent
    cp ../../src/lmp_linux .           # copy LAMMPS executable to this dir
@@ -167,28 +164,25 @@ Here is how you can run and visualize one of the sample problems:
 Running the simulation produces the files *dump.indent* and
 *log.lammps*\ .  You can visualize the dump file of snapshots with a
 variety of 3rd-party tools highlighted on the
-`Visualization <http://lammps.sandia.gov/viz.html>`_ page of the LAMMPS
+`Visualization <https://lammps.sandia.gov/viz.html>`_ page of the LAMMPS
 web site.
 
 If you uncomment the :doc:`dump image <dump_image>` line(s) in the input
 script a series of JPG images will be produced by the run (assuming
 you built LAMMPS with JPG support; see the
-:doc:`Build\_settings <Build_settings>` doc page for details).  These can
+:doc:`Build_settings <Build_settings>` doc page for details).  These can
 be viewed individually or turned into a movie or animated by tools
 like ImageMagick or QuickTime or various Windows-based tools.  See the
 :doc:`dump image <dump_image>` doc page for more details.  E.g. this
 Imagemagick command would create a GIF file suitable for viewing in a
 browser.
 
+.. code-block:: bash
 
-.. parsed-literal::
-
-   % convert -loop 1 \*.jpg foo.gif
-
+   % convert -loop 1 *.jpg foo.gif
 
 ----------
 
-
 Uppercase directories
 ---------------------
 
@@ -201,7 +195,7 @@ Uppercase directories
 +------------+--------------------------------------------------------------------------------------------------+
 | ELASTIC    | compute elastic constants at zero temperature                                                    |
 +------------+--------------------------------------------------------------------------------------------------+
-| ELASTIC\_T | compute elastic constants at finite temperature                                                  |
+| ELASTIC_T  | compute elastic constants at finite temperature                                                  |
 +------------+--------------------------------------------------------------------------------------------------+
 | HEAT       | compute thermal conductivity for LJ and water via fix ehex                                       |
 +------------+--------------------------------------------------------------------------------------------------+
@@ -225,8 +219,8 @@ The USER directory has a large number of sub-directories which
 correspond by name to a USER package.  They contain scripts that
 illustrate how to use the command(s) provided in that package.  Many
 of the sub-directories have their own README files which give further
-instructions.  See the :doc:`Packages\_details <Packages_details>` doc
+instructions.  See the :doc:`Packages_details <Packages_details>` doc
 page for more info on specific USER packages.
 
 .. _openkim: https://openkim.org
-.. _lws: http://lammps.sandia.gov
+.. _lws: https://lammps.sandia.gov

doc/src/Howto.rst

@@ -3,7 +3,7 @@ Howto discussions
 
 These doc pages describe how to perform various tasks with LAMMPS,
 both for users and developers.  The
-`glossary <http://lammps.sandia.gov>`_ website page also lists MD
+`glossary <https://lammps.sandia.gov>`_ website page also lists MD
 terminology with links to corresponding LAMMPS manual pages.  The
 example input scripts included in the examples directory of the LAMMPS
 distribution and highlighted on the :doc:`Examples <Examples>` doc page
@@ -12,7 +12,6 @@ also show how to setup and run various kinds of simulations.
 Tutorials howto
 ===============
 
-
 .. toctree::
    :name: tutorials
    :maxdepth: 1
@@ -24,7 +23,6 @@ Tutorials howto
 General howto
 =============
 
-
 .. toctree::
    :name: general_howto
    :maxdepth: 1
@@ -40,7 +38,6 @@ General howto
 Settings howto
 ==============
 
-
 .. toctree::
    :name: settings_howto
    :maxdepth: 1
@@ -56,7 +53,6 @@ Settings howto
 Analysis howto
 ==============
 
-
 .. toctree::
    :name: analysis_howto
    :maxdepth: 1
@@ -72,7 +68,6 @@ Analysis howto
 Force fields howto
 ==================
 
-
 .. toctree::
    :name: force_howto
    :maxdepth: 1
@@ -85,7 +80,6 @@ Force fields howto
 Packages howto
 ==============
 
-
 .. toctree::
    :name: packages_howto
    :maxdepth: 1

doc/src/Howto_2d.rst

@@ -8,17 +8,16 @@ command.  This is the default.
 
 If using the :doc:`create box <create_box>` command to define a
 simulation box, set the z dimensions narrow, but finite, so that the
-create\_atoms command will tile the 3d simulation box with a single z
+create_atoms command will tile the 3d simulation box with a single z
 plane of atoms - e.g.
 
-
 .. code-block:: LAMMPS
 
    :doc:`create box <create_box>` 1 -10 10 -10 10 -0.25 0.25
 
 If using the :doc:`read data <read_data>` command to read in a file of
 atom coordinates, set the "zlo zhi" values to be finite but narrow,
-similar to the create\_box command settings just described.  For each
+similar to the create_box command settings just described.  For each
 atom in the file, assign a z coordinate so it falls inside the
 z-boundaries of the box - e.g. 0.0.
 

doc/src/Howto_bash.rst

@@ -3,10 +3,8 @@ Using LAMMPS with Bash on Windows
 
 **written by Richard Berger**
 
-
 ----------
 
-
 Starting with Windows 10 you can install Linux tools directly in Windows. This
 allows you to compile LAMMPS following the same procedure as on a real Ubuntu
 Linux installation. Software can be easily installed using the package manager
@@ -82,10 +80,8 @@ Congratulations, you have installed **Bash on Ubuntu on Windows**\ .
 
 .. image:: JPG/bow_tutorial_10.png
 
-
 ----------
 
-
 Compiling LAMMPS in Bash on Windows
 -----------------------------------
 
@@ -97,7 +93,6 @@ Installing prerequisite packages
 
 First upgrade all existing packages using
 
-
 .. code-block:: bash
 
    sudo apt update
@@ -106,7 +101,6 @@ First upgrade all existing packages using
 Next install the following packages, which include compilers and libraries
 needed for various LAMMPS features:
 
-
 .. code-block:: bash
 
    sudo apt install -y build-essential ccache gfortran openmpi-bin libopenmpi-dev libfftw3-dev libjpeg-dev libpng12-dev python-dev python-virtualenv libblas-dev liblapack-dev libhdf5-serial-dev hdf5-tools
@@ -126,17 +120,15 @@ Obtain a copy of the LAMMPS code and go into it using "cd"
 Option 1: Downloading LAMMPS tarball using wget
 """""""""""""""""""""""""""""""""""""""""""""""
 
-
 .. code-block:: bash
 
-   wget http://lammps.sandia.gov/tars/lammps-stable.tar.gz
+   wget https://lammps.sandia.gov/tars/lammps-stable.tar.gz
    tar xvzf lammps-stable.tar.gz
    cd lammps-31Mar17
 
 Option 2: Obtaining LAMMPS code from GitHub
 """""""""""""""""""""""""""""""""""""""""""
 
-
 .. code-block:: bash
 
    git clone https://github.com/lammps/lammps.git
@@ -150,39 +142,33 @@ At this point you can compile LAMMPS like on Ubuntu Linux.
 Compiling serial version
 """"""""""""""""""""""""
 
-
 .. code-block:: bash
 
    cd src/
    make -j 4 serial
 
-This will create an executable called lmp\_serial in the src/ directory
+This will create an executable called lmp_serial in the src/ directory
 
 Compiling MPI version
 """""""""""""""""""""
 
-
 .. code-block:: bash
 
    cd src/
    make -j 4 mpi
 
-This will create an executable called lmp\_mpi in the src/ directory
-
+This will create an executable called lmp_mpi in the src/ directory
 
 ----------
 
-
 Finally, please note the absolute path of your src folder. You can get this using
 
-
 .. code-block:: bash
 
    pwd
 
 or
 
-
 .. code-block:: bash
 
    echo $PWD
@@ -190,43 +176,37 @@ or
 To run any examples you need the location of the executable. For now, let us
 save this location in a temporary variable
 
-
 .. code-block:: bash
 
    LAMMPS_DIR=$PWD
 
-
 ----------
 
-
 Running an example script
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Once compiled you can execute some of the LAMMPS examples. Switch into the
 examples/melt folder
 
-
 .. code-block:: bash
 
    cd ../examples/melt
 
-The full path of the serial executable is $LAMMPS\_DIR/lmp\_serial, while the mpi
-version is $LAMMPS\_DIR/lmp\_mpi. You can run the melt example with either
+The full path of the serial executable is $LAMMPS_DIR/lmp_serial, while the mpi
+version is $LAMMPS_DIR/lmp_mpi. You can run the melt example with either
 version as follows:
 
-
 .. code-block:: bash
 
    $LAMMPS_DIR/lmp_serial -in in.melt
 
 or
 
-
 .. code-block:: bash
 
    mpirun -np 4 $LAMMPS_DIR/lmp_mpi -in in.melt
 
-Note the use of our variable $LAMMPS\_DIR, which expands into the full path of
+Note the use of our variable $LAMMPS_DIR, which expands into the full path of
 the LAMMPS src folder we saved earlier.
 
 Adding your executable directory to your PATH
@@ -235,21 +215,18 @@ Adding your executable directory to your PATH
 You can avoid having to type the full path of your LAMMPS binary by adding its
 parent folder to the PATH environment variable as follows:
 
-
 .. code-block:: bash
 
    export PATH=$LAMMPS_DIR:$PATH
 
 Input scripts can then be run like this:
 
-
 .. code-block:: bash
 
    lmp_serial -in in.melt
 
 or
 
-
 .. code-block:: bash
 
    mpirun -np 4 lmp_mpi -in in.melt
@@ -258,15 +235,13 @@ However, this PATH variable will not persist if you close your bash window.
 To persist this setting edit the $HOME/.bashrc file using your favorite editor
 and add this line
 
-
 .. code-block:: bash
 
    export PATH=/full/path/to/your/lammps/src:$PATH
 
 **Example:**
 
-For an executable lmp\_serial with a full path
-
+For an executable lmp_serial with a full path
 
 .. code-block:: bash
 
@@ -274,7 +249,6 @@ For an executable lmp\_serial with a full path
 
 the PATH variable should be
 
-
 .. code-block:: bash
 
    export PATH=/home/richard/lammps/src:$PATH

doc/src/Howto_bioFF.rst

@@ -20,12 +20,8 @@ force field.
 
 .. _charmm: http://www.scripps.edu/brooks
 
-
-
 .. _amber: http://amber.scripps.edu
 
-
-
 The interaction styles listed below compute force field formulas that
 are consistent with common options in CHARMM or AMBER.  See each
 command's documentation for the formula it computes.
@@ -114,33 +110,23 @@ documentation for the formula it computes.
 
 * :doc:`special_bonds <special_bonds>` dreiding
 
-
 ----------
 
-
 .. _howto-MacKerell:
 
-
-
 **(MacKerell)** MacKerell, Bashford, Bellott, Dunbrack, Evanseck, Field,
 Fischer, Gao, Guo, Ha, et al, J Phys Chem, 102, 3586 (1998).
 
 .. _howto-Cornell:
 
-
-
 **(Cornell)** Cornell, Cieplak, Bayly, Gould, Merz, Ferguson,
 Spellmeyer, Fox, Caldwell, Kollman, JACS 117, 5179-5197 (1995).
 
 .. _howto-Sun:
 
-
-
 **(Sun)** Sun, J. Phys. Chem. B, 102, 7338-7364 (1998).
 
 .. _howto-Mayo:
 
-
-
 **(Mayo)** Mayo, Olfason, Goddard III, J Phys Chem, 94, 8897-8909
 (1990).

doc/src/Howto_body.rst

@@ -33,10 +33,8 @@ style are described below.
 More styles may be added in the future.  See the :doc:`Modify body <Modify_body>` doc page for details on how to add a new body
 style to the code.
 
-
 ----------
 
-
 **When to use body particles:**
 
 You should not use body particles to model a rigid body made of
@@ -104,10 +102,8 @@ particles of different styles
 The pair styles defined for use with specific body styles are listed
 in the sections below.
 
-
 ----------
 
-
 **Specifics of body style nparticle:**
 
 The *nparticle* body style represents body particles as a rigid body
@@ -116,10 +112,9 @@ vanilla, prototypical example of a body particle, although as
 mentioned above, the :doc:`fix rigid <fix_rigid>` command already
 duplicates its functionality.
 
-The atom\_style body command for this body style takes two additional
+The atom_style body command for this body style takes two additional
 arguments:
 
-
 .. parsed-literal::
 
    atom_style body nparticle Nmin Nmax
@@ -133,7 +128,6 @@ When the :doc:`read_data <read_data>` command reads a data file for this
 body style, the following information must be provided for each entry
 in the *Bodies* section of the data file:
 
-
 .. parsed-literal::
 
    atom-ID 1 M
@@ -170,7 +164,6 @@ For output purposes via the :doc:`compute body/local <compute_body_local>` and :
 commands, this body style produces one datum for each of the N
 sub-particles in a body particle.  The datum has 3 values:
 
-
 .. parsed-literal::
 
    1 = x position of sub-particle
@@ -188,26 +181,23 @@ collection of spheres, one for each sub-particle.  The size of each
 sphere is determined by the *bflag1* parameter for the *body* keyword.
 The *bflag2* argument is ignored.
 
-
 ----------
 
-
 **Specifics of body style rounded/polygon:**
 
 The *rounded/polygon* body style represents body particles as a 2d
 polygon with a variable number of N vertices.  This style can only be
 used for 2d models; see the :doc:`boundary <boundary>` command.  See the
-"pair\_style body/rounded/polygon" doc page for a diagram of two
+"pair_style body/rounded/polygon" doc page for a diagram of two
 squares with rounded circles at the vertices.  Special cases for N = 1
 (circle) and N = 2 (rod with rounded ends) can also be specified.
 
 One use of this body style is for 2d discrete element models, as
 described in :ref:`Fraige <body-Fraige>`.
 
-Similar to body style *nparticle*\ , the atom\_style body command for
+Similar to body style *nparticle*\ , the atom_style body command for
 this body style takes two additional arguments:
 
-
 .. parsed-literal::
 
    atom_style body rounded/polygon Nmin Nmax
@@ -221,7 +211,6 @@ When the :doc:`read_data <read_data>` command reads a data file for this
 body style, the following information must be provided for each entry
 in the *Bodies* section of the data file:
 
-
 .. parsed-literal::
 
    atom-ID 1 M
@@ -262,7 +251,6 @@ orientation of the square is aligned with the xy coordinate axes which
 is consistent with the 6 moments of inertia: ixx iyy izz ixy ixz iyz =
 1 1 4 0 0 0. Note that only Izz matters in 2D simulations.
 
-
 .. parsed-literal::
 
    3 1 27
@@ -281,7 +269,6 @@ is consistent with the 6 moments of inertia: ixx iyy izz ixy ixz iyz =
 A rod in 2D, whose length is 4.0, mass 1.0, rounded at two ends
 by circles of diameter 0.5, is specified as follows:
 
-
 .. parsed-literal::
 
    1 1 13
@@ -293,7 +280,6 @@ by circles of diameter 0.5, is specified as follows:
 
 A disk, whose diameter is 3.0, mass 1.0, is specified as follows:
 
-
 .. parsed-literal::
 
    1 1 10
@@ -308,16 +294,14 @@ interactions.  The :doc:`fix wall/body/polygon <fix_wall_body_polygon>`
 command can be used with this body style to compute the interaction of
 body particles with a wall.
 
-
 ----------
 
-
 **Specifics of body style rounded/polyhedron:**
 
 The *rounded/polyhedron* body style represents body particles as a 3d
 polyhedron with a variable number of N vertices, E edges and F faces.
 This style can only be used for 3d models; see the
-:doc:`boundary <boundary>` command.  See the "pair\_style
+:doc:`boundary <boundary>` command.  See the "pair_style
 body/rounded/polygon" doc page for a diagram of a two 2d squares with
 rounded circles at the vertices.  A 3d cube with rounded spheres at
 the 8 vertices and 12 rounded edges would be similar.  Special cases
@@ -327,10 +311,9 @@ specified.
 This body style is for 3d discrete element models, as described in
 :ref:`Wang <body-Wang>`.
 
-Similar to body style *rounded/polygon*\ , the atom\_style body command
+Similar to body style *rounded/polygon*\ , the atom_style body command
 for this body style takes two additional arguments:
 
-
 .. parsed-literal::
 
    atom_style body rounded/polyhedron Nmin Nmax
@@ -344,7 +327,6 @@ When the :doc:`read_data <read_data>` command reads a data file for this
 body style, the following information must be provided for each entry
 in the *Bodies* section of the data file:
 
-
 .. parsed-literal::
 
    atom-ID 3 M
@@ -401,7 +383,6 @@ The orientation of the cube is aligned with the xyz coordinate axes
 which is consistent with the 6 moments of inertia: ixx iyy izz ixy ixz
 iyz = 0.667 0.667 0.667 0 0 0.
 
-
 .. parsed-literal::
 
    1 3 79
@@ -438,7 +419,6 @@ iyz = 0.667 0.667 0.667 0 0 0.
 A rod in 3D, whose length is 4.0, mass 1.0 and rounded at two ends
 by circles of diameter 0.5, is specified as follows:
 
-
 .. parsed-literal::
 
    1 1 13
@@ -450,7 +430,6 @@ by circles of diameter 0.5, is specified as follows:
 
 A sphere whose diameter is 3.0 and mass 1.0, is specified as follows:
 
-
 .. parsed-literal::
 
    1 1 10
@@ -465,15 +444,12 @@ be used with this body style to compute body/body interactions.  The
 used with this body style to compute the interaction of body particles
 with a wall.
 
-
 ----------
 
-
 For output purposes via the :doc:`compute body/local <compute_body_local>` and :doc:`dump local <dump>`
 commands, this body style produces one datum for each of the N
 sub-particles in a body particle.  The datum has 3 values:
 
-
 .. parsed-literal::
 
    1 = x position of vertex
@@ -495,20 +471,14 @@ tangent to the spheres).  The drawn diameter of each line segment is
 determined by the *bflag1* parameter for the *body* keyword.  The
 *bflag2* argument is ignored.
 
-
 ----------
 
-
 .. _body-Fraige:
 
-
-
 **(Fraige)** F. Y. Fraige, P. A. Langston, A. J. Matchett, J. Dodds,
 Particuology, 6, 455 (2008).
 
 .. _body-Wang:
 
-
-
 **(Wang)** J. Wang, H. S. Yu, P. A. Langston, F. Y. Fraige, Granular
 Matter, 13, 1 (2011).

doc/src/Howto_chunk.rst

@@ -110,7 +110,7 @@ of a center of mass, which requires summing mass\*position over the
 atoms and then dividing by summed mass.
 
 All of these computes produce a global vector or global array as
-output, wih one or more values per chunk.  The output can be used in
+output, with one or more values per chunk.  The output can be used in
 various ways:
 
 * As input to the :doc:`fix ave/time <fix_ave_time>` command, which can
@@ -150,7 +150,6 @@ properties:
 
 (1) Average velocity in each of 1000 2d spatial bins:
 
-
 .. code-block:: LAMMPS
 
    compute cc1 all chunk/atom bin/2d x 0.0 0.1 y lower 0.01 units reduced
@@ -159,7 +158,6 @@ properties:
 (2) Temperature in each spatial bin, after subtracting a flow
 velocity:
 
-
 .. code-block:: LAMMPS
 
    compute cc1 all chunk/atom bin/2d x 0.0 0.1 y lower 0.1 units reduced
@@ -168,7 +166,6 @@ velocity:
 
 (3) Center of mass of each molecule:
 
-
 .. code-block:: LAMMPS
 
    compute cc1 all chunk/atom molecule
@@ -177,7 +174,6 @@ velocity:
 
 (4) Total force on each molecule and ave/max across all molecules:
 
-
 .. code-block:: LAMMPS
 
    compute cc1 all chunk/atom molecule
@@ -189,7 +185,6 @@ velocity:
 
 (5) Histogram of cluster sizes:
 
-
 .. code-block:: LAMMPS
 
    compute cluster all cluster/atom 1.0

doc/src/Howto_client_server.rst

@@ -62,7 +62,7 @@ below.  The MESSAGE package also wraps a client/server library called
 CSlib which enables two codes to exchange messages in different ways,
 either via files, sockets, or MPI.  The CSlib is provided with LAMMPS
 in the lib/message dir.  The CSlib has its own
-`website <http://cslib.sandia.gov>`_ with documentation and test
+`website <https://cslib.sandia.gov>`_ with documentation and test
 programs.
 
 .. note::
@@ -93,22 +93,22 @@ client or server code:
 
 * examples/message
 * examples/COUPLE/README
-* examples/COUPLE/lammps\_mc
-* examples/COUPLE/lammps\_nwchem
-* examples/COUPLE/lammps\_vasp
+* examples/COUPLE/lammps_mc
+* examples/COUPLE/lammps_nwchem
+* examples/COUPLE/lammps_vasp
 
 The examples/message directory couples a client instance of LAMMPS to a
 server instance of LAMMPS.
 
-The files in the *lammps\_mc* folder show how to couple LAMMPS as
+The files in the *lammps_mc* folder show how to couple LAMMPS as
 a server to a simple Monte Carlo client code as the driver.
 
-The files in the *lammps\_nwchem* folder show how to couple LAMMPS
+The files in the *lammps_nwchem* folder show how to couple LAMMPS
 as a client code running MD timestepping to NWChem acting as a
 server providing quantum DFT forces, through a Python wrapper script
 on NWChem.
 
-The files in the *lammps\_vasp* folder show how to couple LAMMPS as
+The files in the *lammps_vasp* folder show how to couple LAMMPS as
 a client code running MD timestepping to VASP acting as a server
 providing quantum DFT forces, through a Python wrapper script on VASP.
 
@@ -134,7 +134,6 @@ together to exchange MPI messages between them.
 
 For message exchange in *file*\ , *zmq*\ , or *mpi/two* modes:
 
-
 .. code-block:: bash
 
    % mpirun -np 1 lmp_mpi -log log.client < in.client &
@@ -150,7 +149,6 @@ For message exchange in *mpi/one* mode:
 
 Launch both codes in a single mpirun command:
 
-
 .. code-block:: bash
 
    mpirun -np 2 lmp_mpi -mpicolor 0 -in in.message.client -log log.client : -np 4 lmp_mpi -mpicolor 1 -in in.message.server -log log.server

doc/src/Howto_coreshell.rst

@@ -24,7 +24,6 @@ shell of a core/shell pair should be bonded to each other with a
 harmonic bond that provides the spring force. For example, a data file
 for NaCl, as found in examples/coreshell, has this format:
 
-
 .. parsed-literal::
 
    432   atoms  # core and shell atoms
@@ -87,7 +86,6 @@ Ewald solvers can be used.
 For the NaCL example problem, these pair style and bond style settings
 are used:
 
-
 .. code-block:: LAMMPS
 
    pair_style      born/coul/long/cs 20.0 20.0
@@ -131,7 +129,6 @@ this temperature be output for the overall system.
 
 For the NaCl example, this can be done as follows:
 
-
 .. code-block:: LAMMPS
 
    group cores type 1 2
@@ -150,7 +147,6 @@ the default :doc:`temperature <compute_temp>` and specifying it as a
 second argument in :doc:`fix modify <fix_modify>` and
 :doc:`thermo_modify <thermo_modify>` resulting in:
 
-
 .. code-block:: LAMMPS
 
    (...)
@@ -174,7 +170,6 @@ the pairs.  This can be done by using the *bias* keyword of the
 :doc:`velocity create <velocity>` command and assigning the :doc:`compute temp/cs <compute_temp_cs>` command to the *temp* keyword of the
 :doc:`velocity <velocity>` command, e.g.
 
-
 .. code-block:: LAMMPS
 
    velocity all create 1427 134 bias yes temp CSequ
@@ -211,7 +206,6 @@ pairs as chunks.
 
 For example if core/shell pairs are the only molecules:
 
-
 .. code-block:: LAMMPS
 
    read_data NaCl_CS_x0.1_prop.data
@@ -222,7 +216,6 @@ For example if core/shell pairs are the only molecules:
 
 For example if core/shell pairs and other molecules are present:
 
-
 .. code-block:: LAMMPS
 
    fix csinfo all property/atom i_CSID                       # property/atom command
@@ -232,7 +225,6 @@ For example if core/shell pairs and other molecules are present:
 
 The additional section in the date file would be formatted like this:
 
-
 .. parsed-literal::
 
    CS-Info         # header of additional section
@@ -247,20 +239,14 @@ The additional section in the date file would be formatted like this:
    8   4
    (...)
 
-
 ----------
 
-
 .. _MitchellFincham:
 
-
-
 **(Mitchell and Fincham)** Mitchell, Fincham, J Phys Condensed Matter,
 5, 1031-1038 (1993).
 
 .. _MitchellFincham2:
 
-
-
 **(Fincham)** Fincham, Mackrodt and Mitchell, J Phys Condensed Matter,
 6, 393-404 (1994).

doc/src/Howto_couple.rst

@@ -12,10 +12,8 @@ LAMMPS can be coupled to other codes in at least 4 ways.  Each has
 advantages and disadvantages, which you will have to think about in the
 context of your application.
 
-
 ----------
 
-
 (1) Define a new :doc:`fix <fix>` command that calls the other code.  In
 this scenario, LAMMPS is the driver code.  During its timestepping,
 the fix is invoked, and can make library calls to the other code,
@@ -27,12 +25,8 @@ LAMMPS.
 
 .. _poems: http://www.rpi.edu/~anderk5/lab
 
-
-
-
 ----------
 
-
 (2) Define a new LAMMPS command that calls the other code.  This is
 conceptually similar to method (1), but in this case LAMMPS and the
 other code are on a more equal footing.  Note that now the other code
@@ -53,10 +47,8 @@ command writes and reads.
 See the :doc:`Modify command <Modify_command>` doc page for info on how
 to add a new command to LAMMPS.
 
-
 ----------
 
-
 (3) Use LAMMPS as a library called by another code.  In this case the
 other code is the driver and calls LAMMPS as needed.  Or a wrapper
 code could link and call both LAMMPS and another code as libraries.
@@ -72,21 +64,16 @@ examples/COUPLE/README for more details:
   library
 * plugin: simple driver program in C which invokes LAMMPS as a plugin
   from a shared library.
-* lammps\_quest: coupling of LAMMPS and `Quest <quest_>`_, to run classical
+* lammps_quest: coupling of LAMMPS and `Quest <quest_>`_, to run classical
   MD with quantum forces calculated by a density functional code
-* lammps\_spparks: coupling of LAMMPS and `SPPARKS <spparks_>`_, to couple
+* lammps_spparks: coupling of LAMMPS and `SPPARKS <spparks_>`_, to couple
   a kinetic Monte Carlo model for grain growth using MD to calculate
   strain induced across grain boundaries
 
-
 .. _quest: http://dft.sandia.gov/Quest
 
-
-
 .. _spparks: http://www.sandia.gov/~sjplimp/spparks.html
 
-
-
 The :doc:`Build basics <Build_basics>` doc page describes how to build
 LAMMPS as a library.  Once this is done, you can interface with LAMMPS
 either via C++, C, Fortran, or Python (or any other language that
@@ -102,7 +89,7 @@ The files src/library.cpp and library.h contain the C-style interface
 to LAMMPS.  See the :doc:`Howto library <Howto_library>` doc page for a
 description of the interface and how to extend it for your needs.
 
-Note that the lammps\_open() function that creates an instance of
+Note that the lammps_open() function that creates an instance of
 LAMMPS takes an MPI communicator as an argument.  This means that
 instance of LAMMPS will run on the set of processors in the
 communicator.  Thus the calling code can run LAMMPS on all or a subset
@@ -113,10 +100,8 @@ LAMMPS and half to the other code and run both codes simultaneously
 before syncing them up periodically.  Or it might instantiate multiple
 instances of LAMMPS to perform different calculations.
 
-
 ----------
 
-
 (4) Couple LAMMPS with another code in a client/server mode.  This is
 described on the :doc:`Howto client/server <Howto_client_server>` doc
 page.

doc/src/Howto_dispersion.rst

@@ -29,7 +29,7 @@ that provide fast and accurate simulations, there are two approaches,
 which both have their up- and downsides.
 
 The first approach is to set desired real-space an kspace accuracies
-via the *kspace\_modify force/disp/real* and *kspace\_modify
+via the *kspace_modify force/disp/real* and *kspace_modify
 force/disp/kspace* commands. Note that the accuracies have to be
 specified in force units and are thus dependent on the chosen unit
 settings. For real units, 0.0001 and 0.002 seem to provide reasonable
@@ -37,14 +37,14 @@ accurate and efficient computations for the real-space and kspace
 accuracies.  0.002 and 0.05 work well for most systems using lj
 units. PPPM parameters will be generated based on the desired
 accuracies. The upside of this approach is that it usually provides a
-good set of parameters and will work for both the *kspace\_modify diff
-ad* and *kspace\_modify diff ik* options.  The downside of the method
+good set of parameters and will work for both the *kspace_modify diff
+ad* and *kspace_modify diff ik* options.  The downside of the method
 is that setting the PPPM parameters will take some time during the
 initialization of the simulation.
 
 The second approach is to set the parameters for the pppm/disp
-explicitly using the *kspace\_modify mesh/disp*, *kspace\_modify
-order/disp*, and *kspace\_modify gewald/disp* commands. This approach
+explicitly using the *kspace_modify mesh/disp*, *kspace_modify
+order/disp*, and *kspace_modify gewald/disp* commands. This approach
 requires a more experienced user who understands well the impact of
 the choice of parameters on the simulation accuracy and
 performance. This approach provides a fast initialization of the
@@ -60,12 +60,12 @@ To avoid inaccurate or inefficient simulations, the pppm/disp stops
 simulations with an error message if no action is taken to control the
 PPPM parameters. If the automatic parameter generation is desired and
 real-space and kspace accuracies are desired to be equal, this error
-message can be suppressed using the *kspace\_modify disp/auto yes*
+message can be suppressed using the *kspace_modify disp/auto yes*
 command.
 
 A reasonable approach that combines the upsides of both methods is to
-make the first run using the *kspace\_modify force/disp/real* and
-*kspace\_modify force/disp/kspace* commands, write down the PPPM
+make the first run using the *kspace_modify force/disp/real* and
+*kspace_modify force/disp/kspace* commands, write down the PPPM
 parameters from the output, and specify these parameters using the
 second approach in subsequent runs (which have the same composition,
 force field, and approximately the same volume).
@@ -82,8 +82,8 @@ The second is that the mixing rule of the pair style has an impact on
 the computation time when using the pppm/disp. Fastest computations
 are achieved when using the geometric mixing rule. Using the
 arithmetic mixing rule substantially increases the computational cost.
-The computational overhead can be reduced using the *kspace\_modify
-mix/disp geom* and *kspace\_modify splittol* commands. The first
+The computational overhead can be reduced using the *kspace_modify
+mix/disp geom* and *kspace_modify splittol* commands. The first
 command simply enforces geometric mixing of the dispersion
 coefficients in kspace computations.  This introduces some error in
 the computations but will also significantly speed-up the
@@ -94,7 +94,7 @@ command, but will usually also not provide an equally good increase of
 efficiency.
 
 Finally, pppm/disp can also be used when no mixing rules apply.
-This can be achieved using the *kspace\_modify mix/disp none* command.
+This can be achieved using the *kspace_modify mix/disp none* command.
 Note that the code does not check automatically whether any mixing
 rule is fulfilled. If mixing rules do not apply, the user will have
 to specify this command explicitly.

doc/src/Howto_drude.rst

@@ -48,7 +48,7 @@ for a Langevin thermostat, or :doc:`fix drude/transform/\* <fix_drude_transform>
 thermostat. The former requires use of the command :doc:`comm_modify vel yes <comm_modify>`. The latter requires two separate integration
 fixes like *nvt* or *npt*\ . The correct temperatures of the reduced
 degrees of freedom can be calculated using the :doc:`compute temp/drude <compute_temp_drude>`. This requires also to use the
-command *comm\_modify vel yes*.
+command *comm_modify vel yes*.
 
 Short-range damping of the induced dipole interactions can be achieved
 using Thole functions through the :doc:`pair style thole <pair_thole>` in :doc:`pair_style hybrid/overlay <pair_hybrid>`
@@ -56,12 +56,8 @@ with a Coulomb pair style. It may be useful to use *coul/long/cs* or
 similar from the CORESHELL package if the core and Drude particle come
 too close, which can cause numerical issues.
 
-
 ----------
 
-
 .. _howto-Lamoureux:
 
-
-
 **(Lamoureux and Roux)** G. Lamoureux, B. Roux, J. Chem. Phys 119, 3025 (2003)

doc/src/Howto_drude2.rst

@@ -30,7 +30,6 @@ zero. The (half-)stiffness of the :doc:`harmonic bond <bond_harmonic>`
 :math:`K_D = k_D/2` and the Drude charge :math:`q_D` are related to the atom
 polarizability :math:`\alpha` by
 
-
 .. math::
 
    K_D = \frac 1 2\, \frac {q_D^2} \alpha
@@ -46,7 +45,6 @@ fields:
 * Alternately :ref:`Schroeder and Steinhauser <Schroeder>` suggest adopting a global charge :math:`q_D` = -1.0e and a global mass :math:`m_D` = 0.1 g/mol (or u) for all Drude particles, and to calculate the force constant for each type of core-Drude bond from equation (1). The timesteps used by these authors are between 0.5 and 2 fs, with the degrees of freedom of the Drude oscillators kept cold at 1 K.
 * In both these force fields hydrogen atoms are treated as non-polarizable.
 
-
 The motion of of the Drude particles can be calculated by minimizing
 the energy of the induced dipoles at each timestep, by an iterative,
 self-consistent procedure. The Drude particles can be massless and
@@ -78,15 +76,14 @@ important features:
 **Preparation of the data file**
 
 The data file is similar to a standard LAMMPS data file for
-*atom\_style full*.  The DPs and the *harmonic bonds* connecting them
+*atom_style full*.  The DPs and the *harmonic bonds* connecting them
 to their DC should appear in the data file as normal atoms and bonds.
 
 You can use the *polarizer* tool (Python script distributed with the
 USER-DRUDE package) to convert a non-polarizable data file (here
 *data.102494.lmp*\ ) to a polarizable data file (\ *data-p.lmp*\ )
 
-
-.. parsed-literal::
+.. code-block:: bash
 
    polarizer -q -f phenol.dff data.102494.lmp data-p.lmp
 
@@ -96,7 +93,6 @@ from *phenol.dff*\ , as well as the DC-DP bond constants.  The file
 *phenol.dff* contains the polarizabilities of the atom types
 and the mass of the Drude particles, for instance:
 
-
 .. parsed-literal::
 
    # units: kJ/mol, A, deg
@@ -113,7 +109,6 @@ have to be specified as comments at the end of lines of the *Masses*
 section.  You probably need to edit it to add these names. It should
 look like
 
-
 .. parsed-literal::
 
    Masses
@@ -124,10 +119,8 @@ look like
    4 1.008  # HA
    5 1.008  # HO
 
-
 ----------
 
-
 **Basic input file**
 
 The atom style should be set to (or derive from) *full*\ , so that you
@@ -138,7 +131,6 @@ script (the use of these lines will be explained below).  In order for
 LAMMPS to recognize that you are using Drude oscillators, you should
 use the fix *drude*\ . The command is
 
-
 .. code-block:: LAMMPS
 
    fix DRUDE all drude C C C N N D D D
@@ -159,7 +151,6 @@ command.  With our phenol, there is 1 more special neighbor for which
 space is required.  Otherwise LAMMPS crashes and gives the required
 value.
 
-
 .. code-block:: LAMMPS
 
    read_data data-p.lmp extra/special/per/atom 1
@@ -168,30 +159,27 @@ Let us assume we want to run a simple NVT simulation at 300 K.  Note
 that Drude oscillators need to be thermalized at a low temperature in
 order to approximate a self-consistent field (SCF), therefore it is not
 possible to simulate an NVE ensemble with this package.  Since dipoles
-are approximated by a charged DC-DP pair, the *pair\_style* must
+are approximated by a charged DC-DP pair, the *pair_style* must
 include Coulomb interactions, for instance *lj/cut/coul/long* with
-*kspace\_style pppm*. For example, with a cutoff of 10. and a precision
+*kspace_style pppm*. For example, with a cutoff of 10. and a precision
 1.e-4:
 
-
 .. code-block:: LAMMPS
 
    pair_style lj/cut/coul/long 10.0
    kspace_style pppm 1.0e-4
 
-As compared to the non-polarizable input file, *pair\_coeff* lines need
+As compared to the non-polarizable input file, *pair_coeff* lines need
 to be added for the DPs.  Since the DPs have no Lennard-Jones
-interactions, their :math:`\epsilon` is 0. so the only *pair\_coeff* line
+interactions, their :math:`\epsilon` is 0. so the only *pair_coeff* line
 that needs to be added is
 
-
 .. code-block:: LAMMPS
 
    pair_coeff * 6* 0.0 0.0 # All-DPs
 
 Now for the thermalization, the simplest choice is to use the :doc:`fix langevin/drude <fix_langevin_drude>`.
 
-
 .. code-block:: LAMMPS
 
    fix LANG all langevin/drude 300. 100 12435 1. 20 13977
@@ -205,7 +193,6 @@ atoms need to be in this fix's group.  LAMMPS will thermostat the DPs
 together with their DC.  For this, ghost atoms need to know their
 velocities. Thus you need to add the following command:
 
-
 .. code-block:: LAMMPS
 
    comm_modify vel yes
@@ -217,7 +204,6 @@ can add the *zero yes* option at the end of the fix line.
 If the fix *shake* is used to constrain the C-H bonds, it should be
 invoked after the fix *langevin/drude* for more accuracy.
 
-
 .. code-block:: LAMMPS
 
    fix SHAKE ATOMS shake 0.0001 20 0 t 4 5
@@ -231,16 +217,14 @@ Since the fix *langevin/drude* does not perform time integration (just
 modification of forces but no position/velocity updates), the fix
 *nve* should be used in conjunction.
 
-
 .. code-block:: LAMMPS
 
    fix NVE all nve
 
 Finally, do not forget to update the atom type elements if you use
-them in a *dump\_modify ... element ...* command, by adding the element
+them in a *dump_modify ... element ...* command, by adding the element
 type of the DPs. Here for instance
 
-
 .. code-block:: LAMMPS
 
    dump DUMP all custom 10 dump.lammpstrj id mol type element x y z ix iy iz
@@ -248,30 +232,26 @@ type of the DPs. Here for instance
 
 The input file should now be ready for use!
 
-You will notice that the global temperature *thermo\_temp* computed by
+You will notice that the global temperature *thermo_temp* computed by
 LAMMPS is not 300. K as wanted.  This is because LAMMPS treats DPs as
 standard atoms in his default compute.  If you want to output the
 temperatures of the DC-DP pair centers of mass and of the DPs relative
-to their DCs, you should use the :doc:`compute temp\_drude <compute_temp_drude>`
-
+to their DCs, you should use the :doc:`compute temp_drude <compute_temp_drude>`
 
 .. code-block:: LAMMPS
 
    compute TDRUDE all temp/drude
 
 And then output the correct temperatures of the Drude oscillators
-using *thermo\_style custom* with respectively *c\_TDRUDE[1]* and
-*c\_TDRUDE[2]*. These should be close to 300.0 and 1.0 on average.
-
+using *thermo_style custom* with respectively *c_TDRUDE[1]* and
+*c_TDRUDE[2]*. These should be close to 300.0 and 1.0 on average.
 
 .. code-block:: LAMMPS
 
    thermo_style custom step temp c_TDRUDE[1] c_TDRUDE[2]
 
-
 ----------
 
-
 **Thole screening**
 
 Dipolar interactions represented by point charges on springs may not
@@ -283,29 +263,27 @@ between nearby dipoles on the same molecule may be exaggerated.  Often,
 special bond relations prevent bonded neighboring atoms to see the
 charge of each other's DP, so that the problem does not always appear.
 It is possible to use screened dipole-dipole interactions by using the
-:doc:`*pair\_style thole* <pair_thole>`.  This is implemented as a
-correction to the Coulomb pair\_styles, which dampens at short distance
+:doc:`*pair_style thole* <pair_thole>`.  This is implemented as a
+correction to the Coulomb pair_styles, which dampens at short distance
 the interactions between the charges representing the induced dipoles.
 It is to be used as *hybrid/overlay* with any standard *coul* pair
 style.  In our example, we would use
 
-
 .. code-block:: LAMMPS
 
    pair_style hybrid/overlay lj/cut/coul/long 10.0 thole 2.6 10.0
 
-This tells LAMMPS that we are using two pair\_styles.  The first one is
+This tells LAMMPS that we are using two pair_styles.  The first one is
 as above (\ *lj/cut/coul/long 10.0*\ ).  The second one is a *thole*
-pair\_style with default screening factor 2.6 (:ref:`Noskov <Noskov2>`) and
+pair_style with default screening factor 2.6 (:ref:`Noskov <Noskov2>`) and
 cutoff 10.0.
 
 Since *hybrid/overlay* does not support mixing rules, the interaction
 coefficients of all the pairs of atom types with i < j should be
 explicitly defined.  The output of the *polarizer* script can be used
-to complete the *pair\_coeff* section of the input file.  In our
+to complete the *pair_coeff* section of the input file.  In our
 example, this will look like:
 
-
 .. code-block:: LAMMPS
 
    pair_coeff    1    1 lj/cut/coul/long    0.0700   3.550
@@ -346,31 +324,27 @@ For the *thole* pair style the coefficients are
 
 #. the atom polarizability in units of cubic length
 #. the screening factor of the Thole function (optional, default value
-   specified by the pair\_style command)
-#. the cutoff (optional, default value defined by the pair\_style command)
-
+   specified by the pair_style command)
+#. the cutoff (optional, default value defined by the pair_style command)
 
 The special neighbors have charge-charge and charge-dipole
-interactions screened by the *coul* factors of the *special\_bonds*
+interactions screened by the *coul* factors of the *special_bonds*
 command (0.0, 0.0, and 0.5 in the example above).  Without using the
-pair\_style *thole*\ , dipole-dipole interactions are screened by the
-same factor.  By using the pair\_style *thole*\ , dipole-dipole
+pair_style *thole*\ , dipole-dipole interactions are screened by the
+same factor.  By using the pair_style *thole*\ , dipole-dipole
 interactions are screened by Thole's function, whatever their special
 relationship (except within each DC-DP pair of course).  Consider for
-example 1-2 neighbors: using the pair\_style *thole*\ , their dipoles
+example 1-2 neighbors: using the pair_style *thole*\ , their dipoles
 will see each other (despite the *coul* factor being 0.) and the
 interactions between these dipoles will be damped by Thole's function.
 
-
 ----------
 
-
 **Thermostats and barostats**
 
 Using a Nose-Hoover barostat with the *langevin/drude* thermostat is
 straightforward using fix *nph* instead of *nve*\ .  For example:
 
-
 .. code-block:: LAMMPS
 
    fix NPH all nph iso 1. 1. 500
@@ -385,7 +359,6 @@ with respect to their DC. The *fix drude/transform/inverse* performs
 the reverse transformation.  For a NVT simulation, with the DCs and
 atoms at 300 K and the DPs at 1 K relative to their DC one would use
 
-
 .. code-block:: LAMMPS
 
    fix DIRECT all drude/transform/direct
@@ -395,7 +368,6 @@ atoms at 300 K and the DPs at 1 K relative to their DC one would use
 
 For our phenol example, the groups would be defined as
 
-
 .. code-block:: LAMMPS
 
    group ATOMS  type 1 2 3 4 5 # DCs and non-polarizable atoms
@@ -403,13 +375,12 @@ For our phenol example, the groups would be defined as
    group DRUDES type 6 7 8     # DPs
 
 Note that with the fixes *drude/transform*\ , it is not required to
-specify *comm\_modify vel yes* because the fixes do it anyway (several
+specify *comm_modify vel yes* because the fixes do it anyway (several
 times and for the forces also).  To avoid the flying ice cube artifact
 :ref:`(Lamoureux) <Lamoureux2>`, where the atoms progressively freeze and the
 center of mass of the whole system drifts faster and faster, the *fix
 momentum* can be used. For instance:
 
-
 .. code-block:: LAMMPS
 
    fix MOMENTUM all momentum 100 linear 1 1 1
@@ -421,10 +392,9 @@ DPs should be *nvt* (or vice versa).  Second, the *fix npt* computes a
 global pressure and thus a global temperature whatever the fix group.
 We do want the pressure to correspond to the whole system, but we want
 the temperature to correspond to the fix group only.  We must then use
-the *fix\_modify* command for this.  In the end, the block of
+the *fix_modify* command for this.  In the end, the block of
 instructions for thermostatting and barostatting will look like
 
-
 .. code-block:: LAMMPS
 
    compute TATOMS ATOMS temp
@@ -434,10 +404,8 @@ instructions for thermostatting and barostatting will look like
    fix NVT DRUDES nvt temp 1. 1. 20
    fix INVERSE all drude/transform/inverse
 
-
 ----------
 
-
 **Rigid bodies**
 
 You may want to simulate molecules as rigid bodies (but polarizable).
@@ -448,7 +416,6 @@ review the different thermostats and ensemble combinations.
 
 NVT ensemble using Langevin thermostat:
 
-
 .. code-block:: LAMMPS
 
    comm_modify vel yes
@@ -458,7 +425,6 @@ NVT ensemble using Langevin thermostat:
 
 NVT ensemble using Nose-Hoover thermostat:
 
-
 .. code-block:: LAMMPS
 
    fix DIRECT all drude/transform/direct
@@ -468,7 +434,6 @@ NVT ensemble using Nose-Hoover thermostat:
 
 NPT ensemble with Langevin thermostat:
 
-
 .. code-block:: LAMMPS
 
    comm_modify vel yes
@@ -478,7 +443,6 @@ NPT ensemble with Langevin thermostat:
 
 NPT ensemble using Nose-Hoover thermostat:
 
-
 .. code-block:: LAMMPS
 
    compute TATOM ATOMS temp
@@ -488,45 +452,31 @@ NPT ensemble using Nose-Hoover thermostat:
    fix NVT DRUDES nvt temp 1. 1. 20
    fix INVERSE all drude/transform/inverse
 
-
 ----------
 
-
 .. _Lamoureux2:
 
-
-
 **(Lamoureux)** Lamoureux and Roux, J Chem Phys, 119, 3025-3039 (2003)
 
 .. _Schroeder:
 
-
-
 **(Schroeder)**  Schroeder and Steinhauser, J Chem Phys, 133,
 154511 (2010).
 
 .. _Jiang2:
 
-
-
 **(Jiang)** Jiang, Hardy, Phillips, MacKerell, Schulten, and Roux,
  J Phys Chem Lett, 2, 87-92 (2011).
 
 .. _Thole2:
 
-
-
 **(Thole)** Chem Phys, 59, 341 (1981).
 
 .. _Noskov2:
 
-
-
 **(Noskov)** Noskov, Lamoureux and Roux, J Phys Chem B, 109, 6705 (2005).
 
 .. _SWM4-NDP:
 
-
-
 **(SWM4-NDP)** Lamoureux, Harder, Vorobyov, Roux, MacKerell, Chem Phys
 Let, 418, 245-249 (2006)

doc/src/Howto_elastic.rst

@@ -4,14 +4,14 @@ Calculate elastic constants
 Elastic constants characterize the stiffness of a material. The formal
 definition is provided by the linear relation that holds between the
 stress and strain tensors in the limit of infinitesimal deformation.
-In tensor notation, this is expressed as s\_ij = C\_ijkl \* e\_kl, where
-the repeated indices imply summation. s\_ij are the elements of the
-symmetric stress tensor. e\_kl are the elements of the symmetric strain
-tensor. C\_ijkl are the elements of the fourth rank tensor of elastic
+In tensor notation, this is expressed as s_ij = C_ijkl \* e_kl, where
+the repeated indices imply summation. s_ij are the elements of the
+symmetric stress tensor. e_kl are the elements of the symmetric strain
+tensor. C_ijkl are the elements of the fourth rank tensor of elastic
 constants. In three dimensions, this tensor has 3\^4=81 elements. Using
-Voigt notation, the tensor can be written as a 6x6 matrix, where C\_ij
-is now the derivative of s\_i w.r.t. e\_j. Because s\_i is itself a
-derivative w.r.t. e\_i, it follows that C\_ij is also symmetric, with at
+Voigt notation, the tensor can be written as a 6x6 matrix, where C_ij
+is now the derivative of s_i w.r.t. e_j. Because s_i is itself a
+derivative w.r.t. e_i, it follows that C_ij is also symmetric, with at
 most 7\*6/2 = 21 distinct elements.
 
 At zero temperature, it is easy to estimate these derivatives by
@@ -33,12 +33,8 @@ tensor. Another approach is to sample the triclinic cell fluctuations
 that occur in an NPT simulation. This method can also be slow to
 converge and requires careful post-processing :ref:`(Shinoda) <Shinoda1>`
 
-
 ----------
 
-
 .. _Shinoda1:
 
-
-
 **(Shinoda)** Shinoda, Shiga, and Mikami, Phys Rev B, 69, 134103 (2004).

doc/src/Howto_github.rst

@@ -22,10 +22,8 @@ and will reduce the time until the integration is complete. For more
 information on the requirements to have your code included into LAMMPS
 please see the :doc:`Modify contribute <Modify_contribute>` doc page.
 
-
 ----------
 
-
 **Making an account**
 
 First of all, you need a GitHub account. This is fairly simple, just
@@ -34,10 +32,8 @@ the "Sign up for GitHub" button. Once your account is created, you
 can sign in by clicking the button in the top left and filling in your
 username or e-mail address and password.
 
-
 ----------
 
-
 **Forking the repository**
 
 To get changes into LAMMPS, you need to first fork the `lammps/lammps`
@@ -63,10 +59,8 @@ At the same time, you can set things up, so you can include changes from
 upstream into your repository and thus keep it in sync with the ongoing
 LAMMPS development.
 
-
 ----------
 
-
 **Adding changes to your own fork**
 
 Additions to the upstream version of LAMMPS are handled using *feature
@@ -81,14 +75,12 @@ explained in more detail here: `feature branch workflow <https://www.atlassian.c
 First of all, create a clone of your version on github on your local
 machine via HTTPS:
 
-
 .. code-block:: bash
 
      $ git clone https://github.com/<your user name>/lammps.git <some name>
 
 or, if you have set up your GitHub account for using SSH keys, via SSH:
 
-
 .. code-block:: bash
 
      $ git clone git@github.com:<your user name>/lammps.git
@@ -108,7 +100,6 @@ test them without interfering with the repository on GitHub.
 To pull changes from upstream into this copy, you can go to the directory
 and use git pull:
 
-
 .. code-block:: bash
 
      $ cd mylammps
@@ -117,7 +108,6 @@ and use git pull:
 
 You can also add this URL as a remote:
 
-
 .. code-block:: bash
 
      $ git remote add lammps_upstream https://www.github.com/lammps/lammps
@@ -127,7 +117,6 @@ branch for the feature you want to work on. This tutorial contains the
 workflow that updated this tutorial, and hence we will call the branch
 "github-tutorial-update":
 
-
 .. code-block:: bash
 
     $ git checkout -b github-tutorial-update master
@@ -140,7 +129,6 @@ unrelated feature, you should switch branches!
 
 After everything is done, add the files to the branch and commit them:
 
-
 .. code-block:: bash
 
     $ git add doc/src/Howto_github.txt
@@ -165,14 +153,12 @@ After everything is done, add the files to the branch and commit them:
 After adding all files, the change set can be committed with some
 useful message that explains the change.
 
-
 .. code-block:: bash
 
      $ git commit -m 'Finally updated the github tutorial'
 
 After the commit, the changes can be pushed to the same branch on GitHub:
 
-
 .. code-block:: bash
 
    $ git push
@@ -181,7 +167,6 @@ Git will ask you for your user name and password on GitHub if you have
 not configured anything. If your local branch is not present on GitHub yet,
 it will ask you to add it by running
 
-
 .. code-block:: bash
 
      $ git push --set-upstream origin github-tutorial-update
@@ -192,22 +177,18 @@ password, the feature branch should be added to your fork on GitHub.
 If you want to make really sure you push to the right repository
 (which is good practice), you can provide it explicitly:
 
-
 .. code-block:: bash
 
    $ git push origin
 
 or using an explicit URL:
 
-
 .. code-block:: bash
 
    $ git push git@github.com:Pakketeretet2/lammps.git
 
-
 ----------
 
-
 **Filing a pull request**
 
 Up to this point in the tutorial, all changes were to *your* clones of
@@ -255,10 +236,8 @@ Now just write some nice comments and click on "Create pull request".
 .. image:: JPG/tutorial_create_new_pull_request2.png
    :align: center
 
-
 ----------
 
-
 **After filing a pull request**
 
 .. note::
@@ -308,10 +287,10 @@ After each push, the automated checks are run again.
 
 LAMMPS developers may add labels to your pull request to assign it to
 categories (mostly for bookkeeping purposes), but a few of them are
-important: needs\_work, work\_in\_progress, test-for-regression, and
+important: needs_work, work_in_progress, test-for-regression, and
 full-regression-test. The first two indicate, that your pull request
-is not considered to be complete. With "needs\_work" the burden is on
-exclusively on you; while "work\_in\_progress" can also mean, that a
+is not considered to be complete. With "needs_work" the burden is on
+exclusively on you; while "work_in_progress" can also mean, that a
 LAMMPS developer may want to add changes. Please watch the comments
 to the pull requests. The two "test" labels are used to trigger
 extended tests before the code is merged. This is sometimes done by
@@ -381,7 +360,7 @@ It looks something like this:
 .. image:: JPG/tutorial_reverse_pull_request.png
    :align: center
 
-For some reason, the highlighted button didn't work in my case, but I
+For some reason, the highlighted button did not work in my case, but I
 can go to my own repository and merge the pull request from there:
 
 .. image:: JPG/tutorial_reverse_pull_request2.png
@@ -408,7 +387,6 @@ Because the changes are OK with us, we are going to merge by clicking on
 Now, since in the meantime our local text for the tutorial also changed,
 we need to pull Axel's change back into our branch, and merge them:
 
-
 .. code-block:: bash
 
     $ git add Howto_github.txt
@@ -425,7 +403,6 @@ With Axel's changes merged in and some final text updates, our feature
 branch is now perfect as far as we are concerned, so we are going to
 commit and push again:
 
-
 .. code-block:: bash
 
     $ git add Howto_github.txt
@@ -438,10 +415,8 @@ This merge also shows up on the lammps GitHub page:
 .. image:: JPG/tutorial_reverse_pull_request7.png
    :align: center
 
-
 ----------
 
-
 **After a merge**
 
 When everything is fine, the feature branch is merged into the master branch:
@@ -456,7 +431,6 @@ It is in principle safe to delete them from your own fork. This helps
 keep it a bit more tidy. Note that you first have to switch to another
 branch!
 
-
 .. code-block:: bash
 
    $ git checkout master
@@ -472,7 +446,6 @@ first delete and then pull, everything should still be fine.
 Finally, if you delete the branch locally, you might want to push this
 to your remote(s) as well:
 
-
 .. code-block:: bash
 
    $ git push origin :github-tutorial-update
@@ -485,7 +458,7 @@ should be submitted, there is now also an "unstable" and a "stable"
 branch; these have the same content as "master", but are only updated
 after a patch release or stable release was made.
 Furthermore, the naming of the patches now follow the pattern
-"patch\_<Day><Month><Year>" to simplify comparisons between releases.
+"patch_<Day><Month><Year>" to simplify comparisons between releases.
 Finally, all patches and submissions are subject to automatic testing
 and code checks to make sure they at the very least compile.
 

doc/src/Howto_granular.rst

@@ -22,7 +22,7 @@ Use one of these 3 pair potentials, which compute forces and torques
 between interacting pairs of particles:
 
 * :doc:`pair_style <pair_style>` gran/history
-* :doc:`pair_style <pair_style>` gran/no\_history
+* :doc:`pair_style <pair_style>` gran/no_history
 * :doc:`pair_style <pair_style>` gran/hertzian
 
 These commands implement fix options specific to granular systems:

doc/src/Howto_kappa.rst

@@ -56,26 +56,20 @@ two preceding non-equilibrium methods, where energy flows continuously
 between hot and cold regions of the simulation box.
 
 The :doc:`compute heat/flux <compute_heat_flux>` command can calculate
-the needed heat flux and describes how to implement the Green\_Kubo
+the needed heat flux and describes how to implement the Green_Kubo
 formalism using additional LAMMPS commands, such as the :doc:`fix ave/correlate <fix_ave_correlate>` command to calculate the needed
 auto-correlation.  See the doc page for the :doc:`compute heat/flux <compute_heat_flux>` command for an example input script
 that calculates the thermal conductivity of solid Ar via the GK
 formalism.
 
-
 ----------
 
-
 .. _howto-Ikeshoji:
 
-
-
 **(Ikeshoji)** Ikeshoji and Hafskjold, Molecular Physics, 81, 251-261
 (1994).
 
 .. _howto-Wirnsberger:
 
-
-
 **(Wirnsberger)** Wirnsberger, Frenkel, and Dellago, J Chem Phys, 143, 124104
 (2015).

doc/src/Howto_library.rst

@@ -12,7 +12,7 @@ functions therein have a C-style argument list, but contain C++ code
 you could write yourself in a C++ application that was invoking LAMMPS
 directly.  The C++ code in the functions illustrates how to invoke
 internal LAMMPS operations.  Note that LAMMPS classes are defined
-within a LAMMPS namespace (LAMMPS\_NS) if you use them from another C++
+within a LAMMPS namespace (LAMMPS_NS) if you use them from another C++
 application.
 
 The examples/COUPLE and python/examples directories have example C++
@@ -34,7 +34,7 @@ interface LAMMPS to Fortran libraries, or the code uses static variables
 
 Another major issue to deal with is to correctly handle MPI.  Creating
 a LAMMPS instance requires passing an MPI communicator, or it assumes
-the MPI\_COMM\_WORLD communicator, which spans all MPI processor ranks.
+the MPI_COMM_WORLD communicator, which spans all MPI processor ranks.
 When creating multiple LAMMPS object instances from different threads,
 this communicator has to be different for each thread or else collisions
 can happen, or it has to be guaranteed, that only one thread at a time
@@ -58,7 +58,6 @@ details.
    The added functions can access or change any internal LAMMPS data you
    wish.
 
-
 .. code-block:: c
 
    void lammps_open(int, char **, MPI_Comm, void **)
@@ -71,11 +70,11 @@ details.
    void lammps_commands_string(void *, char *)
    void lammps_free(void *)
 
-The lammps\_open() function is used to initialize LAMMPS, passing in a
+The lammps_open() function is used to initialize LAMMPS, passing in a
 list of strings as if they were :doc:`command-line arguments <Run_options>` when LAMMPS is run in stand-alone mode
 from the command line, and a MPI communicator for LAMMPS to run under.
 It returns a ptr to the LAMMPS object that is created, and which is
-used in subsequent library calls.  The lammps\_open() function can be
+used in subsequent library calls.  The lammps_open() function can be
 called multiple times, to create multiple instances of LAMMPS.
 
 LAMMPS will run on the set of processors in the communicator.  This
@@ -87,14 +86,14 @@ half to the other code and run both codes simultaneously before
 syncing them up periodically.  Or it might instantiate multiple
 instances of LAMMPS to perform different calculations.
 
-The lammps\_open\_no\_mpi() function is similar except that no MPI
-communicator is passed from the caller.  Instead, MPI\_COMM\_WORLD is
+The lammps_open_no_mpi() function is similar except that no MPI
+communicator is passed from the caller.  Instead, MPI_COMM_WORLD is
 used to instantiate LAMMPS, and MPI is initialized if necessary.
 
-The lammps\_close() function is used to shut down an instance of LAMMPS
+The lammps_close() function is used to shut down an instance of LAMMPS
 and free all its memory.
 
-The lammps\_version() function can be used to determined the specific
+The lammps_version() function can be used to determined the specific
 version of the underlying LAMMPS code. This is particularly useful
 when loading LAMMPS as a shared library via dlopen(). The code using
 the library interface can than use this information to adapt to
@@ -102,8 +101,8 @@ changes to the LAMMPS command syntax between versions. The returned
 LAMMPS version code is an integer (e.g. 2 Sep 2015 results in
 20150902) that grows with every new LAMMPS version.
 
-The lammps\_file(), lammps\_command(), lammps\_commands\_list(), and
-lammps\_commands\_string() functions are used to pass one or more
+The lammps_file(), lammps_command(), lammps_commands_list(), and
+lammps_commands_string() functions are used to pass one or more
 commands to LAMMPS to execute, the same as if they were coming from an
 input script.
 
@@ -114,19 +113,19 @@ can interleave the command function calls with operations it performs,
 calls to extract information from or set information within LAMMPS, or
 calls to another code's library.
 
-The lammps\_file() function passes the filename of an input script.
-The lammps\_command() function passes a single command as a string.
-The lammps\_commands\_list() function passes multiple commands in a
-char\*\* list.  In both lammps\_command() and lammps\_commands\_list(),
+The lammps_file() function passes the filename of an input script.
+The lammps_command() function passes a single command as a string.
+The lammps_commands_list() function passes multiple commands in a
+char\*\* list.  In both lammps_command() and lammps_commands_list(),
 individual commands may or may not have a trailing newline.  The
-lammps\_commands\_string() function passes multiple commands
+lammps_commands_string() function passes multiple commands
 concatenated into one long string, separated by newline characters.
-In both lammps\_commands\_list() and lammps\_commands\_string(), a single
+In both lammps_commands_list() and lammps_commands_string(), a single
 command can be spread across multiple lines, if the last printable
 character of all but the last line is "&", the same as if the lines
 appeared in an input script.
 
-The lammps\_free() function is a clean-up function to free memory that
+The lammps_free() function is a clean-up function to free memory that
 the library allocated previously via other function calls.  See
 comments in src/library.cpp file for which other functions need this
 clean-up.
@@ -136,7 +135,6 @@ information from LAMMPS and setting value within LAMMPS.  Again, see
 the documentation in the src/library.cpp file for details, including
 which quantities can be queried by name:
 
-
 .. code-block:: c
 
    int lammps_extract_setting(void *, char *)
@@ -148,22 +146,21 @@ which quantities can be queried by name:
    void *lammps_extract_fix(void *, char *, int, int, int, int)
    void *lammps_extract_variable(void *, char *, char *)
 
-The extract\_setting() function returns info on the size
+The extract_setting() function returns info on the size
 of data types (e.g. 32-bit or 64-bit atom IDs) used
 by the LAMMPS executable (a compile-time choice).
 
 The other extract functions return a pointer to various global or
 per-atom quantities stored in LAMMPS or to values calculated by a
 compute, fix, or variable.  The pointer returned by the
-extract\_global() function can be used as a permanent reference to a
-value which may change.  For the extract\_atom() method, see the
+extract_global() function can be used as a permanent reference to a
+value which may change.  For the extract_atom() method, see the
 extract() method in the src/atom.cpp file for a list of valid per-atom
 properties.  New names could easily be added if the property you want
 is not listed.  For the other extract functions, the underlying
 storage may be reallocated as LAMMPS runs, so you need to re-call the
 function to assure a current pointer or returned value(s).
 
-
 .. code-block:: c
 
    double lammps_get_thermo(void *, char *)
@@ -172,22 +169,21 @@ function to assure a current pointer or returned value(s).
    int lammps_set_variable(void *, char *, char *)
    void lammps_reset_box(void *, double *, double *, double, double, double)
 
-The lammps\_get\_thermo() function returns the current value of a thermo
+The lammps_get_thermo() function returns the current value of a thermo
 keyword as a double precision value.
 
-The lammps\_get\_natoms() function returns the total number of atoms in
+The lammps_get_natoms() function returns the total number of atoms in
 the system and can be used by the caller to allocate memory for the
-lammps\_gather\_atoms() and lammps\_scatter\_atoms() functions.
+lammps_gather_atoms() and lammps_scatter_atoms() functions.
 
-The lammps\_set\_variable() function can set an existing string-style
+The lammps_set_variable() function can set an existing string-style
 variable to a new string value, so that subsequent LAMMPS commands can
 access the variable.
 
-The lammps\_reset\_box() function resets the size and shape of the
+The lammps_reset_box() function resets the size and shape of the
 simulation box, e.g. as part of restoring a previously extracted and
 saved state of a simulation.
 
-
 .. code-block:: c
 
    void lammps_gather_atoms(void *, char *, int, int, void *)
@@ -206,17 +202,17 @@ owned by different processors.
 .. warning::
 
    These functions are not compatible with the
-   -DLAMMPS\_BIGBIG setting when compiling LAMMPS.  Dummy functions
+   -DLAMMPS_BIGBIG setting when compiling LAMMPS.  Dummy functions
    that result in an error message and abort will be substituted
    instead of resulting in random crashes and memory corruption.
 
-The lammps\_gather\_atoms() function does this for all N atoms in the
+The lammps_gather_atoms() function does this for all N atoms in the
 system, ordered by atom ID, from 1 to N.  The
-lammps\_gather\_atoms\_concat() function does it for all N atoms, but
+lammps_gather_atoms_concat() function does it for all N atoms, but
 simply concatenates the subset of atoms owned by each processor.  The
 resulting vector is not ordered by atom ID.  Atom IDs can be requested
 by the same function if the caller needs to know the ordering.  The
-lammps\_gather\_subset() function allows the caller to request values
+lammps_gather_subset() function allows the caller to request values
 for only a subset of atoms (identified by ID).
 For all 3 gather function, per-atom image flags can be retrieved in 2 ways.
 If the count is specified as 1, they are returned
@@ -224,24 +220,23 @@ in a packed format with all three image flags stored in a single integer.
 If the count is specified as 3, the values are unpacked into xyz flags
 by the library before returning them.
 
-The lammps\_scatter\_atoms() function takes a list of values for all N
+The lammps_scatter_atoms() function takes a list of values for all N
 atoms in the system, ordered by atom ID, from 1 to N, and assigns
 those values to each atom in the system.  The
-lammps\_scatter\_atoms\_subset() function takes a subset of IDs as an
+lammps_scatter_atoms_subset() function takes a subset of IDs as an
 argument and only scatters those values to the owning atoms.
 
-
 .. code-block:: c
 
    void lammps_create_atoms(void *, int, tagint *, int *, double *, double *,
                             imageint *, int)
 
-The lammps\_create\_atoms() function takes a list of N atoms as input
+The lammps_create_atoms() function takes a list of N atoms as input
 with atom types and coords (required), an optionally atom IDs and
 velocities and image flags.  It uses the coords of each atom to assign
 it as a new atom to the processor that owns it.  This function is
 useful to add atoms to a simulation or (in tandem with
-lammps\_reset\_box()) to restore a previously extracted and saved state
+lammps_reset_box()) to restore a previously extracted and saved state
 of a simulation.  Additional properties for the new atoms can then be
-assigned via the lammps\_scatter\_atoms() or lammps\_extract\_atom()
+assigned via the lammps_scatter_atoms() or lammps_extract_atom()
 functions.

doc/src/Howto_manifold.rst

@@ -19,17 +19,17 @@ to the relevant fixes.
 +----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
 | cylinder       | R              | x\^2 + y\^2 - R\^2 = 0                                                                                                                 | Cylinder along z-axis, axis going through (0,0,0)                                                                                  |
 +----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
-| cylinder\_dent | R l a          | x\^2 + y\^2 - r(z)\^2 = 0, r(x) = R if \| z \| > l, r(z) = R - a\*(1 + cos(z/l))/2 otherwise                                           | A cylinder with a dent around z = 0                                                                                                |
+| cylinder_dent  | R l a          | x\^2 + y\^2 - r(z)\^2 = 0, r(x) = R if \| z \| > l, r(z) = R - a\*(1 + cos(z/l))/2 otherwise                                           | A cylinder with a dent around z = 0                                                                                                |
 +----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
 | dumbbell       | a A B c        | -( x\^2 + y\^2 ) + (a\^2 - z\^2/c\^2) \* ( 1 + (A\*sin(B\*z\^2))\^4) = 0                                                               | A dumbbell                                                                                                                         |
 +----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
 | ellipsoid      | a  b c         | (x/a)\^2 + (y/b)\^2 + (z/c)\^2 = 0                                                                                                     | An ellipsoid                                                                                                                       |
 +----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
-| gaussian\_bump | A l rc1 rc2    | if( x < rc1) -z + A \* exp( -x\^2 / (2 l\^2) ); else if( x < rc2 ) -z + a + b\*x + c\*x\^2 + d\*x\^3; else z                           | A Gaussian bump at x = y = 0, smoothly tapered to a flat plane z = 0.                                                              |
+| gaussian_bump  | A l rc1 rc2    | if( x < rc1) -z + A \* exp( -x\^2 / (2 l\^2) ); else if( x < rc2 ) -z + a + b\*x + c\*x\^2 + d\*x\^3; else z                           | A Gaussian bump at x = y = 0, smoothly tapered to a flat plane z = 0.                                                              |
 +----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
 | plane          | a b c x0 y0 z0 | a\*(x-x0) + b\*(y-y0) + c\*(z-z0) = 0                                                                                                  | A plane with normal (a,b,c) going through point (x0,y0,z0)                                                                         |
 +----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
-| plane\_wiggle  | a w            | z - a\*sin(w\*x) = 0                                                                                                                   | A plane with a sinusoidal modulation on z along x.                                                                                 |
+| plane_wiggle   | a w            | z - a\*sin(w\*x) = 0                                                                                                                   | A plane with a sinusoidal modulation on z along x.                                                                                 |
 +----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
 | sphere         | R              | x\^2 + y\^2 + z\^2 - R\^2 = 0                                                                                                          | A sphere of radius R                                                                                                               |
 +----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
@@ -37,7 +37,7 @@ to the relevant fixes.
 +----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
 | spine          | a, A, B, B2, c | -(x\^2 + y\^2) + (a\^2 - z\^2/f(z)\^2)\*(1 + (A\*sin(g(z)\*z\^2))\^4), f(z) = c if z > 0, 1 otherwise; g(z) = B if z > 0, B2 otherwise | An approximation to a dendritic spine                                                                                              |
 +----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
-| spine\_two     | a, A, B, B2, c | -(x\^2 + y\^2) + (a\^2 - z\^2/f(z)\^2)\*(1 + (A\*sin(g(z)\*z\^2))\^2), f(z) = c if z > 0, 1 otherwise; g(z) = B if z > 0, B2 otherwise | Another approximation to a dendritic spine                                                                                         |
+| spine_two      | a, A, B, B2, c | -(x\^2 + y\^2) + (a\^2 - z\^2/f(z)\^2)\*(1 + (A\*sin(g(z)\*z\^2))\^2), f(z) = c if z > 0, 1 otherwise; g(z) = B if z > 0, B2 otherwise | Another approximation to a dendritic spine                                                                                         |
 +----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
 | thylakoid      | wB LB lB       | Various, see :ref:`(Paquay) <Paquay1>`                                                                                                 | A model grana thylakoid consisting of two block-like compartments connected by a bridge of width wB, length LB and taper length lB |
 +----------------+----------------+----------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------+
@@ -46,7 +46,5 @@ to the relevant fixes.
 
 .. _Paquay1:
 
-
-
 **(Paquay)** Paquay and Kusters, Biophys. J., 110, 6, (2016).
 preprint available at `arXiv:1411.3019 <http://arxiv.org/abs/1411.3019/>`_.

doc/src/Howto_multiple.rst

@@ -8,7 +8,6 @@ If "multiple simulations" means continue a previous simulation for
 more timesteps, then you simply use the :doc:`run <run>` command
 multiple times.  For example, this script
 
-
 .. code-block:: LAMMPS
 
    units lj
@@ -27,7 +26,6 @@ If you wish to run totally different simulations, one after the other,
 the :doc:`clear <clear>` command can be used in between them to
 re-initialize LAMMPS.  For example, this script
 
-
 .. code-block:: LAMMPS
 
    units lj
@@ -48,7 +46,6 @@ For large numbers of independent simulations, you can use
 multiple times with different settings.  For example, this
 script, named in.polymer
 
-
 .. code-block:: LAMMPS
 
    variable d index run1 run2 run3 run4 run5 run6 run7 run8
@@ -65,7 +62,6 @@ file in each directory.  The same concept could be used to run the
 same system at 8 different temperatures, using a temperature variable
 and storing the output in different log and dump files, for example
 
-
 .. code-block:: LAMMPS
 
    variable a loop 8

doc/src/Howto_nemd.rst

@@ -43,13 +43,9 @@ NEMD simulations can also be used to measure transport properties of a fluid
 through a pore or channel. Simulations of steady-state flow can be performed
 using the :doc:`fix flow/gauss <fix_flow_gauss>` command.
 
-
 ----------
 
-
 .. _Daivis-nemd:
 
-
-
 **(Daivis and Todd)** Daivis and Todd, Nonequilibrium Molecular Dynamics (book),
 Cambridge University Press, https://doi.org/10.1017/9781139017848, (2017).

doc/src/Howto_output.rst

@@ -12,7 +12,6 @@ There are four basic kinds of LAMMPS output:
   screen.
 * :doc:`Restart files <restart>`.
 
-
 A simulation prints one set of thermodynamic output and (optionally)
 restart files.  It can generate any number of dump files and fix
 output files, depending on what :doc:`dump <dump>` and :doc:`fix <fix>`
@@ -69,11 +68,11 @@ notation, where ID in this case is the ID of a compute.  The leading
 "c\_" would be replaced by "f\_" for a fix, or "v\_" for a variable:
 
 +-------------+--------------------------------------------+
-| c\_ID       | entire scalar, vector, or array            |
+| c_ID        | entire scalar, vector, or array            |
 +-------------+--------------------------------------------+
-| c\_ID[I]    | one element of vector, one column of array |
+| c_ID[I]     | one element of vector, one column of array |
 +-------------+--------------------------------------------+
-| c\_ID[I][J] | one element of array                       |
+| c_ID[I][J]  | one element of array                       |
 +-------------+--------------------------------------------+
 
 In other words, using one bracket reduces the dimension of the data
@@ -93,7 +92,7 @@ The frequency and format of thermodynamic output is set by the
 :doc:`thermo_style <thermo_style>` command also specifies what values
 are calculated and written out.  Pre-defined keywords can be specified
 (e.g. press, etotal, etc).  Three additional kinds of keywords can
-also be specified (c\_ID, f\_ID, v\_name), where a :doc:`compute <compute>`
+also be specified (c_ID, f_ID, v_name), where a :doc:`compute <compute>`
 or :doc:`fix <fix>` or :doc:`variable <variable>` provides the value to be
 output.  In each case, the compute, fix, or variable must generate
 global values for input to the :doc:`thermo_style custom <dump>`
@@ -122,7 +121,7 @@ pre-defined formats (dump atom, dump xtc, etc).
 There is also a :doc:`dump custom <dump>` format where the user
 specifies what values are output with each atom.  Pre-defined atom
 attributes can be specified (id, x, fx, etc).  Three additional kinds
-of keywords can also be specified (c\_ID, f\_ID, v\_name), where a
+of keywords can also be specified (c_ID, f_ID, v_name), where a
 :doc:`compute <compute>` or :doc:`fix <fix>` or :doc:`variable <variable>`
 provides the values to be output.  In each case, the compute, fix, or
 variable must generate per-atom values for input to the :doc:`dump custom <dump>` command.
@@ -130,7 +129,7 @@ variable must generate per-atom values for input to the :doc:`dump custom <dump>
 There is also a :doc:`dump local <dump>` format where the user specifies
 what local values to output.  A pre-defined index keyword can be
 specified to enumerate the local values.  Two additional kinds of
-keywords can also be specified (c\_ID, f\_ID), where a
+keywords can also be specified (c_ID, f_ID), where a
 :doc:`compute <compute>` or :doc:`fix <fix>` or :doc:`variable <variable>`
 provides the values to be output.  In each case, the compute or fix
 must generate local values for input to the :doc:`dump local <dump>`

doc/src/Howto_pylammps.rst

@@ -6,19 +6,23 @@ PyLammps Tutorial
 Overview
 --------
 
-PyLammps is a Python wrapper class which can be created on its own or
-use an existing lammps Python object.  It creates a simpler,
-Python-like interface to common LAMMPS functionality, in contrast to
-the lammps.py wrapper on the C-style LAMMPS library interface which is
-written using Python ctypes.  The lammps.py wrapper is discussed on
-the :doc:`Python library <Python_library>` doc page.
+``PyLammps`` is a Python wrapper class for LAMMPS which can be created
+on its own or use an existing lammps Python object.  It creates a simpler,
+more "pythonic" interface to common LAMMPS functionality, in contrast to
+the ``lammps.py`` wrapper for the C-style LAMMPS library interface which
+is written using `Python ctypes <ctypes_>`_.  The ``lammps.py`` wrapper
+is discussed on the :doc:`Python library <Python_library>` doc page.
 
-Unlike the flat ctypes interface, PyLammps exposes a discoverable API.
-It no longer requires knowledge of the underlying C++ code
-implementation.  Finally, the IPyLammps wrapper builds on top of
-PyLammps and adds some additional features for IPython integration
-into IPython notebooks, e.g. for embedded visualization output from
-dump/image.
+Unlike the flat ``ctypes`` interface, PyLammps exposes a discoverable
+API.  It no longer requires knowledge of the underlying C++ code
+implementation.  Finally, the ``IPyLammps`` wrapper builds on top of
+``PyLammps`` and adds some additional features for
+`IPython integration <ipython_>`_ into `Jupyter notebooks <jupyter_>`_,
+e.g. for embedded visualization output from :doc:`dump style image <dump_image>`.
+
+.. _ctypes: https://docs.python.org/3/library/ctypes.html
+.. _ipython: https://ipython.org/
+.. _jupyter: https://jupyter.org/
 
 Comparison of lammps and PyLammps interfaces
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -26,7 +30,7 @@ Comparison of lammps and PyLammps interfaces
 lammps.lammps
 """""""""""""
 
-* uses C-Types
+* uses ``ctypes``
 * direct memory access to native C++ data
 * provides functions to send and receive data to LAMMPS
 * requires knowledge of how LAMMPS internally works (C pointers, etc)
@@ -34,7 +38,7 @@ lammps.lammps
 lammps.PyLammps
 """""""""""""""
 
-* higher-level abstraction built on top of original C-Types interface
+* higher-level abstraction built on top of original ctypes interface
 * manipulation of Python objects
 * communication with LAMMPS is hidden from API user
 * shorter, more concise Python
@@ -56,7 +60,6 @@ output support enabled.
 
 Step 1a: For the CMake based build system, the steps are:
 
-
 .. code-block:: bash
 
    mkdir $LAMMPS_DIR/build-shared
@@ -68,7 +71,6 @@ Step 1a: For the CMake based build system, the steps are:
 
 Step 1b: For the legacy, make based build system, the steps are:
 
-
 .. code-block:: bash
 
    cd $LAMMPS_DIR/src
@@ -85,7 +87,6 @@ Step 2: Installing the LAMMPS Python package
 PyLammps is part of the lammps Python package. To install it simply install
 that package into your current Python installation with:
 
-
 .. code-block:: bash
 
    make install-python
@@ -110,7 +111,6 @@ Benefits of using a virtualenv
 
 **Prerequisite (e.g. on Ubuntu)**
 
-
 .. code-block:: bash
 
    apt-get install python-virtualenv
@@ -118,7 +118,6 @@ Benefits of using a virtualenv
 Creating a virtualenv with lammps installed
 """""""""""""""""""""""""""""""""""""""""""
 
-
 .. code-block:: bash
 
    # create virtualenv named 'testing'
@@ -132,7 +131,6 @@ When using CMake and the shared library has already been build, you
 need to re-run CMake to update the location of the python executable
 to the location in the virtual environment with:
 
-
 .. code-block:: bash
 
    cmake . -DPYTHON_EXECUTABLE=$(which python)
@@ -154,7 +152,6 @@ Creating a new instance of PyLammps
 To create a PyLammps object you need to first import the class from the lammps
 module. By using the default constructor, a new *lammps* instance is created.
 
-
 .. code-block:: Python
 
    from lammps import PyLammps
@@ -162,7 +159,6 @@ module. By using the default constructor, a new *lammps* instance is created.
 
 You can also initialize PyLammps on top of this existing *lammps* object:
 
-
 .. code-block:: Python
 
    from lammps import lammps, PyLammps
@@ -177,7 +173,6 @@ the command method of the lammps object instance.
 
 For instance, let's take the following LAMMPS command:
 
-
 .. code-block:: LAMMPS
 
    region box block 0 10 0 5 -0.5 0.5
@@ -185,7 +180,6 @@ For instance, let's take the following LAMMPS command:
 In the original interface this command can be executed with the following
 Python code if *L* was a lammps instance:
 
-
 .. code-block:: Python
 
    L.command("region box block 0 10 0 5 -0.5 0.5")
@@ -193,7 +187,6 @@ Python code if *L* was a lammps instance:
 With the PyLammps interface, any command can be split up into arbitrary parts
 separated by white-space, passed as individual arguments to a region method.
 
-
 .. code-block:: Python
 
    L.region("box block", 0, 10, 0, 5, -0.5, 0.5)
@@ -206,7 +199,6 @@ The benefit of this approach is avoiding redundant command calls and easier
 parameterization. In the original interface parameterization needed to be done
 manually by creating formatted strings.
 
-
 .. code-block:: Python
 
    L.command("region box block %f %f %f %f %f %f" % (xlo, xhi, ylo, yhi, zlo, zhi))
@@ -214,7 +206,6 @@ manually by creating formatted strings.
 In contrast, methods of PyLammps accept parameters directly and will convert
 them automatically to a final command string.
 
-
 .. code-block:: Python
 
    L.region("box block", xlo, xhi, ylo, yhi, zlo, zhi)
@@ -225,8 +216,6 @@ System state
 In addition to dispatching commands directly through the PyLammps object, it
 also provides several properties which allow you to query the system state.
 
-
-
 L.system
    Is a dictionary describing the system such as the bounding box or number of atoms
 
@@ -260,8 +249,6 @@ L.dump
 L.groups
    List of groups present in the current system
 
-
-
 Working with LAMMPS variables
 -----------------------------
 
@@ -269,7 +256,6 @@ LAMMPS variables can be both defined and accessed via the PyLammps interface.
 
 To define a variable you can use the :doc:`variable <variable>` command:
 
-
 .. code-block:: Python
 
    L.variable("a index 2")
@@ -279,7 +265,6 @@ A dictionary of all variables is returned by L.variables
 you can access an individual variable by retrieving a variable object from the
 L.variables dictionary by name
 
-
 .. code-block:: Python
 
    a = L.variables['a']
@@ -287,7 +272,6 @@ L.variables dictionary by name
 The variable value can then be easily read and written by accessing the value
 property of this object.
 
-
 .. code-block:: Python
 
    print(a.value)
@@ -300,7 +284,6 @@ LAMMPS expressions can be immediately evaluated by using the eval method. The
 passed string parameter can be any expression containing global thermo values,
 variables, compute or fix data.
 
-
 .. code-block:: Python
 
    result = L.eval("ke") # kinetic energy
@@ -315,7 +298,6 @@ All atoms in the current simulation can be accessed by using the L.atoms list.
 Each element of this list is an object which exposes its properties (id, type,
 position, velocity, force, etc.).
 
-
 .. code-block:: Python
 
    # access first atom
@@ -329,7 +311,6 @@ position, velocity, force, etc.).
 
 Some properties can also be used to set:
 
-
 .. code-block:: Python
 
    # set position in 2D simulation
@@ -347,7 +328,6 @@ after a run via the L.runs list. This list contains a growing list of run data.
 The first element is the output of the first run, the second element that of
 the second run.
 
-
 .. code-block:: Python
 
    L.run(1000)
@@ -359,7 +339,6 @@ the second run.
 Each run contains a dictionary of all trajectories. Each trajectory is
 accessible through its thermo name:
 
-
 .. code-block:: Python
 
    L.runs[0].thermo.Step # list of time steps in first run
@@ -367,7 +346,6 @@ accessible through its thermo name:
 
 Together with matplotlib plotting data out of LAMMPS becomes simple:
 
-
 .. code-block:: Python
 
    import matplotlib.plot as plt
@@ -406,7 +384,6 @@ tutorials and showcasing your latest research.
 To launch an instance of Jupyter simply run the following command inside your
 Python environment (this assumes you followed the Quick Start instructions):
 
-
 .. code-block:: bash
 
    jupyter notebook
@@ -429,7 +406,6 @@ Four atoms are placed in the simulation and the dihedral potential is applied on
 them using a datafile. Then one of the atoms is rotated along the central axis by
 setting its position from Python, which changes the dihedral angle.
 
-
 .. code-block:: Python
 
    phi = [d \* math.pi / 180 for d in range(360)]
@@ -463,7 +439,6 @@ Initially, a 2D system is created in a state with minimal energy.
 
 It is then disordered by moving each atom by a random delta.
 
-
 .. code-block:: Python
 
    random.seed(27848)
@@ -483,7 +458,6 @@ It is then disordered by moving each atom by a random delta.
 Finally, the Monte Carlo algorithm is implemented in Python. It continuously
 moves random atoms by a random delta and only accepts certain moves.
 
-
 .. code-block:: Python
 
    estart = L.eval("pe")
@@ -536,7 +510,6 @@ Using PyLammps and mpi4py (Experimental)
 
 PyLammps can be run in parallel using mpi4py. This python package can be installed using
 
-
 .. code-block:: bash
 
    pip install mpi4py
@@ -544,7 +517,6 @@ PyLammps can be run in parallel using mpi4py. This python package can be install
 The following is a short example which reads in an existing LAMMPS input file and
 executes it in parallel.  You can find in.melt in the examples/melt folder.
 
-
 .. code-block:: Python
 
    from mpi4py import MPI
@@ -561,7 +533,6 @@ executes it in parallel.  You can find in.melt in the examples/melt folder.
 To run this script (melt.py) in parallel using 4 MPI processes we invoke the
 following mpirun command:
 
-
 .. code-block:: bash
 
    mpirun -np 4 python melt.py

doc/src/Howto_replica.rst

@@ -37,7 +37,6 @@ replica.  The processors assigned to each replica are determined at
 run-time by using the :doc:`-partition command-line switch <Run_options>` to launch LAMMPS on multiple partitions,
 which in this context are the same as replicas.  E.g.  these commands:
 
-
 .. code-block:: bash
 
    mpirun -np 16 lmp_linux -partition 8x2 -in in.temper

doc/src/Howto_restart.rst

@@ -21,7 +21,6 @@ Look at the *in.chain* input script provided in the *bench* directory
 of the LAMMPS distribution to see the original script that these 2
 scripts are based on.  If that script had the line
 
-
 .. code-block:: LAMMPS
 
    restart         50 tmp.restart
@@ -32,7 +31,6 @@ and tmp.restart.100) as it ran.
 This script could be used to read the 1st restart file and re-run the
 last 50 timesteps:
 
-
 .. code-block:: LAMMPS
 
    read_restart    tmp.restart.50
@@ -48,8 +46,8 @@ last 50 timesteps:
    run             50
 
 Note that the following commands do not need to be repeated because
-their settings are included in the restart file: *units, atom\_style,
-special\_bonds, pair\_style, bond\_style*.  However these commands do
+their settings are included in the restart file: *units, atom_style,
+special_bonds, pair_style, bond_style*.  However these commands do
 need to be used, since their settings are not in the restart file:
 *neighbor, fix, timestep*\ .
 
@@ -62,14 +60,12 @@ uses random numbers in a way that does not allow for perfect restarts.
 As an alternate approach, the restart file could be converted to a data
 file as follows:
 
-
 .. code-block:: LAMMPS
 
    lmp_g++ -r tmp.restart.50 tmp.restart.data
 
 Then, this script could be used to re-run the last 50 steps:
 
-
 .. code-block:: LAMMPS
 
    units           lj
@@ -93,7 +89,7 @@ Then, this script could be used to re-run the last 50 steps:
    run             50
 
 Note that nearly all the settings specified in the original *in.chain*
-script must be repeated, except the *pair\_coeff* and *bond\_coeff*
+script must be repeated, except the *pair_coeff* and *bond_coeff*
 commands since the new data file lists the force field coefficients.
 Also, the :doc:`reset_timestep <reset_timestep>` command is used to tell
 LAMMPS the current timestep.  This value is stored in restart files,

doc/src/Howto_spc.rst

@@ -15,38 +15,34 @@ atoms and the water molecule to run a rigid SPC model.
 | H mass = 1.008
 | O charge = -0.820
 | H charge = 0.410
-| LJ epsilon of OO = 0.1553
-| LJ sigma of OO = 3.166
-| LJ epsilon, sigma of OH, HH = 0.0
-| r0 of OH bond = 1.0
-| theta of HOH angle = 109.47
-| 
+| LJ :math:`\epsilon` of OO = 0.1553
+| LJ :math:`\sigma` of OO = 3.166
+| LJ :math:`\epsilon`, :math:`\sigma` of OH, HH = 0.0
+| :math:`r_0` of OH bond = 1.0
+| :math:`\theta` of HOH angle = 109.47\ :math:`^{\circ}`
+|
 
 Note that as originally proposed, the SPC model was run with a 9
-Angstrom cutoff for both LJ and Coulombic terms.  It can also be used
-with long-range Coulombics (Ewald or PPPM in LAMMPS), without changing
-any of the parameters above, though it becomes a different model in
-that mode of usage.
+Angstrom cutoff for both LJ and Coulomb terms.  It can also be used
+with long-range electrostatic solvers (e.g. Ewald or PPPM in LAMMPS)
+without changing any of the parameters above, although it becomes
+a different model in that mode of usage.
 
 The SPC/E (extended) water model is the same, except
 the partial charge assignments change:
 
 | O charge = -0.8476
 | H charge = 0.4238
-| 
+|
 
 See the :ref:`(Berendsen) <howto-Berendsen>` reference for more details on both
 the SPC and SPC/E models.
 
 Wikipedia also has a nice article on `water models <http://en.wikipedia.org/wiki/Water_model>`_.
 
-
 ----------
 
-
 .. _howto-Berendsen:
 
-
-
 **(Berendsen)** Berendsen, Grigera, Straatsma, J Phys Chem, 91,
 6269-6271 (1987).

doc/src/Howto_spherical.rst

@@ -38,7 +38,6 @@ The dipole style does not actually define finite-size particles, but
 is often used in conjunction with spherical particles, via a command
 like
 
-
 .. code-block:: LAMMPS
 
    atom_style hybrid sphere dipole
@@ -116,7 +115,7 @@ such interactions.  These are the various :doc:`pair styles <pair_style>` that g
 
 * :doc:`pair_style gran/history <pair_gran>`
 * :doc:`pair_style gran/hertzian <pair_gran>`
-* :doc:`pair_style gran/no\_history <pair_gran>`
+* :doc:`pair_style gran/no_history <pair_gran>`
 * :doc:`pair_style dipole/cut <pair_dipole>`
 * :doc:`pair_style gayberne <pair_gayberne>`
 * :doc:`pair_style resquared <pair_resquared>`

doc/src/Howto_spins.rst

@@ -56,13 +56,9 @@ the magnetic energy. The second command is :doc:`compute property/atom <compute_
 per atom magnetic quantities. Typically, the orientation of a given
 magnetic spin, or the magnetic force acting on this spin.
 
-
 ----------
 
-
 .. _Tranchida:
 
-
-
 **(Tranchida)** Tranchida, Plimpton, Thibaudeau and Thompson,
 Journal of Computational Physics, 372, 406-425, (2018).

doc/src/Howto_thermostat.rst

@@ -82,13 +82,9 @@ specify them explicitly via the :doc:`thermo_style custom <thermo_style>` comman
 :doc:`thermo_modify <thermo_modify>` command to re-define what
 temperature compute is used for default thermodynamic output.
 
-
 ----------
 
-
 .. _Daivis-thermostat:
 
-
-
 **(Daivis and Todd)** Daivis and Todd, Nonequilibrium Molecular Dynamics (book),
 Cambridge University Press, https://doi.org/10.1017/9781139017848, (2017).

doc/src/Howto_tip3p.rst

@@ -20,19 +20,19 @@ set to 0.0, it corresponds to the original 1983 TIP3P model
 | H mass = 1.008
 | O charge = -0.834
 | H charge = 0.417
-| LJ epsilon of OO = 0.1521
-| LJ sigma of OO = 3.1507
-| LJ epsilon of HH = 0.0460
-| LJ sigma of HH = 0.4000
-| LJ epsilon of OH = 0.0836
-| LJ sigma of OH = 1.7753
+| LJ :math:`\epsilon` of OO = 0.1521
+| LJ :math:`\sigma` of OO = 3.1507
+| LJ :math:`\epsilon` of HH = 0.0460
+| LJ :math:`\sigma` of HH = 0.4000
+| LJ :math:`\epsilon` of OH = 0.0836
+| LJ :math:`\sigma` of OH = 1.7753
 | K of OH bond = 450
-| r0 of OH bond = 0.9572
+| :math:`r_0` of OH bond = 0.9572
 | K of HOH angle = 55
-| theta of HOH angle = 104.52
-| 
+| :math:`\theta` of HOH angle = 104.52\ :math:`^{\circ}`
+|
 
-These are the parameters to use for TIP3P with a long-range Coulombic
+These are the parameters to use for TIP3P with a long-range Coulomb
 solver (e.g. Ewald or PPPM in LAMMPS), see :ref:`(Price) <Price1>` for
 details:
 
@@ -40,37 +40,29 @@ details:
 | H mass = 1.008
 | O charge = -0.830
 | H charge = 0.415
-| LJ epsilon of OO = 0.102
-| LJ sigma of OO = 3.188
-| LJ epsilon, sigma of OH, HH = 0.0
+| LJ :math:`\epsilon` of OO = 0.102
+| LJ :math:`\sigma` of OO = 3.188
+| LJ :math:`\epsilon`, :math:`\sigma` of OH, HH = 0.0
 | K of OH bond = 450
-| r0 of OH bond = 0.9572
+| :math:`r_0` of OH bond = 0.9572
 | K of HOH angle = 55
-| theta of HOH angle = 104.52
-| 
+| :math:`\theta` of HOH angle = 104.52\ :math:`^{\circ}`
+|
 
 Wikipedia also has a nice article on `water models <http://en.wikipedia.org/wiki/Water_model>`_.
 
-
 ----------
 
-
 .. _howto-tip3p:
 
-
-
 **(MacKerell)** MacKerell, Bashford, Bellott, Dunbrack, Evanseck, Field,
 Fischer, Gao, Guo, Ha, et al, J Phys Chem, 102, 3586 (1998).
 
 .. _Jorgensen1:
 
-
-
 **(Jorgensen)** Jorgensen, Chandrasekhar, Madura, Impey, Klein, J Chem
 Phys, 79, 926 (1983).
 
 .. _Price1:
 
-
-
 **(Price)** Price and Brooks, J Chem Phys, 121, 10096 (2004).

doc/src/Howto_tip4p.rst

@@ -11,7 +11,7 @@ angle style of *harmonic* or *charmm* should also be used.
 A TIP4P model is run with LAMMPS using either this command
 for a cutoff model:
 
-:doc:`pair_style lj/cut/tip4p/cut <pair_lj>`
+* :doc:`pair_style lj/cut/tip4p/cut <pair_lj>`
 
 or these two commands for a long-range model:
 
@@ -31,46 +31,46 @@ coefficients.
 | H mass = 1.008
 | O charge = -1.040
 | H charge = 0.520
-| r0 of OH bond = 0.9572
-| theta of HOH angle = 104.52
+| :math:`r_0` of OH bond = 0.9572
+| :math:`\theta` of HOH angle = 104.52\ :math:`^{\circ}`
 | OM distance = 0.15
-| LJ epsilon of O-O = 0.1550
-| LJ sigma of O-O = 3.1536
-| LJ epsilon, sigma of OH, HH = 0.0
-| Coulombic cutoff = 8.5
-| 
+| LJ :math:`\epsilon` of O-O = 0.1550
+| LJ :math:`\sigma` of O-O = 3.1536
+| LJ :math:`\epsilon`, :math:`\sigma` of OH, HH = 0.0
+| Coulomb cutoff = 8.5
+|
 
 For the TIP4/Ice model (J Chem Phys, 122, 234511 (2005);
-http://dx.doi.org/10.1063/1.1931662) these values can be used:
+https://doi.org/10.1063/1.1931662) these values can be used:
 
 | O mass = 15.9994
 | H mass =  1.008
 | O charge = -1.1794
 | H charge =  0.5897
-| r0 of OH bond = 0.9572
-| theta of HOH angle = 104.52
+| :math:`r_0` of OH bond = 0.9572
+| :math:`\theta` of HOH angle = 104.52\ :math:`^{\circ}`
 | OM distance = 0.1577
-| LJ epsilon of O-O = 0.21084
-| LJ sigma of O-O = 3.1668
-| LJ epsilon, sigma of OH, HH = 0.0
-| Coulombic cutoff = 8.5
-| 
+| LJ :math:`\epsilon` of O-O = 0.21084
+| LJ :math:`\sigma` of O-O = 3.1668
+| LJ :math:`\epsilon`, :math:`\sigma` of OH, HH = 0.0
+| Coulomb cutoff = 8.5
+|
 
 For the TIP4P/2005 model (J Chem Phys, 123, 234505 (2005);
-http://dx.doi.org/10.1063/1.2121687), these values can be used:
+https://doi.org/10.1063/1.2121687), these values can be used:
 
 | O mass = 15.9994
 | H mass =  1.008
 | O charge = -1.1128
 | H charge = 0.5564
-| r0 of OH bond = 0.9572
-| theta of HOH angle = 104.52
+| :math:`r_0` of OH bond = 0.9572
+| :math:`\theta` of HOH angle = 104.52\ :math:`^{\circ}`
 | OM distance = 0.1546
-| LJ epsilon of O-O = 0.1852
-| LJ sigma of O-O = 3.1589
-| LJ epsilon, sigma of OH, HH = 0.0
-| Coulombic cutoff = 8.5
-| 
+| LJ :math:`\epsilon` of O-O = 0.1852
+| LJ :math:`\sigma` of O-O = 3.1589
+| LJ :math:`\epsilon`, :math:`\sigma` of OH, HH = 0.0
+| Coulomb cutoff = 8.5
+|
 
 These are the parameters to use for TIP4P with a long-range Coulombic
 solver (e.g. Ewald or PPPM in LAMMPS):
@@ -79,13 +79,13 @@ solver (e.g. Ewald or PPPM in LAMMPS):
 | H mass = 1.008
 | O charge = -1.0484
 | H charge = 0.5242
-| r0 of OH bond = 0.9572
-| theta of HOH angle = 104.52
+| :math:`r_0` of OH bond = 0.9572
+| :math:`\theta` of HOH angle = 104.52\ :math:`^{\circ}`
 | OM distance = 0.1250
-| LJ epsilon of O-O = 0.16275
-| LJ sigma of O-O = 3.16435
-| LJ epsilon, sigma of OH, HH = 0.0
-| 
+| LJ :math:`\epsilon` of O-O = 0.16275
+| LJ :math:`\sigma` of O-O = 3.16435
+| LJ :math:`\epsilon`, :math:`\sigma` of OH, HH = 0.0
+|
 
 Note that the when using the TIP4P pair style, the neighbor list
 cutoff for Coulomb interactions is effectively extended by a distance
@@ -99,13 +99,9 @@ and Coulombic cutoffs are set in the :doc:`pair_style lj/cut/tip4p/long <pair_lj
 
 Wikipedia also has a nice article on `water models <http://en.wikipedia.org/wiki/Water_model>`_.
 
-
 ----------
 
-
 .. _Jorgensen5:
 
-
-
 **(Jorgensen)** Jorgensen, Chandrasekhar, Madura, Impey, Klein, J Chem
 Phys, 79, 926 (1983).

doc/src/Howto_triclinic.rst

@@ -78,7 +78,7 @@ The transformation is given by the following equation:
     \begin{pmatrix}
       \mathbf{B \times C}  \\
       \mathbf{C \times A}  \\
-      \mathbf{A \times B} 
+      \mathbf{A \times B}
     \end{pmatrix} \cdot \mathbf{X}
 
 where *V* is the volume of the box, **X** is the original vector quantity and
@@ -200,7 +200,6 @@ an orthogonal bounding box which encloses the triclinic simulation box
 is output, along with the 3 tilt factors (xy, xz, yz) of the triclinic
 box, formatted as follows:
 
-
 .. parsed-literal::
 
    ITEM: BOX BOUNDS xy xz yz
@@ -212,7 +211,6 @@ This bounding box is convenient for many visualization programs and is
 calculated from the 9 triclinic box parameters
 (xlo,xhi,ylo,yhi,zlo,zhi,xy,xz,yz) as follows:
 
-
 .. parsed-literal::
 
    xlo_bound = xlo + MIN(0.0,xy,xz,xy+xz)
@@ -223,7 +221,7 @@ calculated from the 9 triclinic box parameters
    zhi_bound = zhi
 
 These formulas can be inverted if you need to convert the bounding box
-back into the triclinic box parameters, e.g. xlo = xlo\_bound -
+back into the triclinic box parameters, e.g. xlo = xlo_bound -
 MIN(0.0,xy,xz,xy+xz).
 
 One use of triclinic simulation boxes is to model solid-state crystals

doc/src/Howto_viscosity.rst

@@ -62,7 +62,6 @@ simulation box.
 Here is an example input script that calculates the viscosity of
 liquid Ar via the GK formalism:
 
-
 .. code-block:: LAMMPS
 
    # Sample LAMMPS input script for viscosity of liquid Ar
@@ -131,13 +130,9 @@ time-integrated momentum fluxes play the role of Cartesian
 coordinates, whose mean-square displacement increases linearly
 with time at sufficiently long times.
 
-
 ----------
 
-
 .. _Daivis-viscosity:
 
-
-
 **(Daivis and Todd)** Daivis and Todd, Nonequilibrium Molecular Dynamics (book),
 Cambridge University Press, https://doi.org/10.1017/9781139017848, (2017).

doc/src/Howto_viz.rst

@@ -19,18 +19,14 @@ A Python-based toolkit distributed by our group can read native LAMMPS
 dump files, including custom dump files with additional columns of
 user-specified atom information, and convert them to various formats
 or pipe them into visualization software directly.  See the `Pizza.py WWW site <pizza_>`_ for details.  Specifically, Pizza.py can convert
-LAMMPS dump files into PDB, XYZ, `Ensight <ensight_>`_, and VTK formats.
+LAMMPS dump files into PDB, XYZ, `EnSight <ensight_>`_, and VTK formats.
 Pizza.py can pipe LAMMPS dump files directly into the Raster3d and
 RasMol visualization programs.  Pizza.py has tools that do interactive
 3d OpenGL visualization and one that creates SVG images of dump file
 snapshots.
 
-.. _pizza: http://www.sandia.gov/~sjplimp/pizza.html
+.. _pizza: https://pizza.sandia.gov
 
+.. _ensight: https://www.ansys.com/products/fluids/ansys-ensight
 
-
-.. _ensight: http://www.ensight.com
-
-
-
-.. _atomeye: http://mt.seas.upenn.edu/Archive/Graphics/A
+.. _atomeye: http://li.mit.edu/Archive/Graphics/A/

doc/src/Install.rst

@@ -8,7 +8,6 @@ have more flexibility as to what features to include or exclude in the
 build.  If you plan to :doc:`modify or extend LAMMPS <Modify>`, then you
 need the source code.
 
-
 .. toctree::
    :maxdepth: 1
 

doc/src/Install_conda.rst

@@ -1,7 +1,7 @@
 Download an executable for Linux or Mac via Conda
 =================================================
 
-Binaries are available for macOS or Linux via `Conda <conda_>`_.
+Binaries are available for MacOS or Linux via `Conda <conda_>`_.
 
 First, one must setup the Conda package manager on your system.  Follow the
 instructions to install `Miniconda <mini_conda_install_>`_, then create a conda

doc/src/Install_git.rst

@@ -16,8 +16,7 @@ commands explained below to communicate with the git servers on
 GitHub.  For people still using subversion (svn), GitHub also
 provides `limited support for subversion clients <svn_>`_.
 
-
-.. warning::
+.. note::
 
    As of October 2016, the official home of public LAMMPS development is
    on GitHub.  The previously advertised LAMMPS git repositories on
@@ -35,7 +34,6 @@ You can follow LAMMPS development on 3 different git branches:
 To access the git repositories on your box, use the clone command to
 create a local copy of the LAMMPS repository with a command like:
 
-
 .. code-block:: bash
 
    $ git clone -b unstable https://github.com/lammps/lammps.git mylammps
@@ -57,7 +55,6 @@ LAMMPS, as listed on :doc:`this page <Errors_bugs>`, you can stay
 up-to-date by typing the following git commands from within the
 "mylammps" directory:
 
-
 .. code-block:: bash
 
    $ git checkout unstable      # not needed if you always stay in this branch
@@ -92,7 +89,6 @@ Once you have updated your local files with a "git pull" (or "git
 checkout"), you still need to re-build LAMMPS if any source files have
 changed.  To do this, you should cd to the src directory and type:
 
-
 .. code-block:: bash
 
    $ make purge             # remove any deprecated src files

doc/src/Install_linux.rst

@@ -38,7 +38,7 @@ To install LAMMPS do the following once:
 
    $ sudo apt-get install lammps-daily
 
-This downloads an executable named "lmp\_daily" to your box, which
+This downloads an executable named "lmp_daily" to your box, which
 can then be used in the usual way to run input scripts:
 
 .. code-block:: bash
@@ -103,10 +103,10 @@ linking to the C library interface (lammps-devel, lammps-mpich-devel,
 lammps-openmpi-devel), the header for compiling programs using
 the C library interface (lammps-headers), and the LAMMPS python
 module for Python 3. All packages can be installed at the same
-time and the name of the LAMMPS executable is *lmp* and *lmp\_openmpi*
-or *lmp\_mpich* respectively.  By default, *lmp* will refer to the
+time and the name of the LAMMPS executable is *lmp* and *lmp_openmpi*
+or *lmp_mpich* respectively.  By default, *lmp* will refer to the
 serial executable, unless one of the MPI environment modules is loaded
-("module load mpi/mpich-x86\_64" or "module load mpi/openmpi-x86\_64").
+("module load mpi/mpich-x86_64" or "module load mpi/openmpi-x86_64").
 Then the corresponding parallel LAMMPS executable can be used.
 The same mechanism applies when loading the LAMMPS python module.
 
@@ -206,7 +206,6 @@ Gentoo Linux executable
 LAMMPS is part of Gentoo's main package tree and can be installed by
 typing:
 
-
 .. code-block:: bash
 
    % emerge --ask lammps
@@ -216,7 +215,6 @@ built on the your machine.
 
 Certain LAMMPS packages can be enable via USE flags, type
 
-
 .. code-block:: bash
 
    % equery uses lammps

doc/src/Install_mac.rst

@@ -10,18 +10,16 @@ GPU, KOKKOS, LATTE, MSCG, MESSAGE, MPIIO POEMS VORONOI.
 After installing Homebrew, you can install LAMMPS on your system with
 the following commands:
 
-
 .. code-block:: bash
 
    % brew install lammps
 
-This will install the executables "lammps\_serial" and "lammps\_mpi", as well as
+This will install the executables "lammps_serial" and "lammps_mpi", as well as
 the LAMMPS "doc", "potentials", "tools", "bench", and "examples" directories.
 
 Once LAMMPS is installed, you can test the installation with the
 Lennard-Jones benchmark file:
 
-
 .. code-block:: bash
 
    % brew test lammps -v
@@ -31,7 +29,6 @@ results in Homebrew also installing the `kim-api` binaries when LAMMPS is
 installed.  In order to use potentials from `openkim.org <openkim_>`_, you can
 install the `openkim-models` package
 
-
 .. code-block:: bash
 
    % brew install openkim-models
@@ -44,5 +41,4 @@ If you have problems with the installation you can post issues to
 Thanks to Derek Thomas (derekt at cello.t.u-tokyo.ac.jp) for setting
 up the Homebrew capability.
 
-
 .. _openkim: https://openkim.org

doc/src/Install_patch.rst

@@ -8,7 +8,7 @@ how to stay current are on the
 
 If you prefer to download a tarball, as described on the :doc:`Install git <Install_tarball>` doc page, you can stay current by
 downloading "patch files" when new patch releases are made.  A link to
-a patch file is posted on the `bug and feature page <http://lammps.sandia.gov/bug.html>`_ of the LAMMPS website, along
+a patch file is posted on the `bug and feature page <https://lammps.sandia.gov/bug.html>`_ of the LAMMPS website, along
 with a list of changed files and details about what is in the new patch
 release.  This page explains how to apply the patch file to your local
 LAMMPS directory.
@@ -32,9 +32,9 @@ up to date.
 * Apply the patch by typing the following command from your top-level
   LAMMPS directory, where the redirected file is the name of the patch
   file.
-  
+
   .. code-block:: bash
-  
+
      $ patch -bp1 < patch.12Dec16
 
 * A list of updated files print out to the screen.  The -b switch
@@ -46,9 +46,9 @@ up to date.
   successively, you only need to type this once at the end. The purge
   command removes deprecated src files if any were removed by the patch
   from package sub-directories.
-  
+
   .. code-block:: bash
-  
+
      $ make purge
      $ make package-update
 

doc/src/Install_tarball.rst

@@ -4,10 +4,10 @@ Download source and documentation as a tarball
 You can download a current LAMMPS tarball from the `download page <download_>`_
 of the `LAMMPS website <lws_>`_.
 
-.. _download: http://lammps.sandia.gov/download.html
-.. _bug: http://lammps.sandia.gov/bug.html
-.. _older: http://lammps.sandia.gov/tars
-.. _lws: http://lammps.sandia.gov
+.. _download: https://lammps.sandia.gov/download.html
+.. _bug: https://lammps.sandia.gov/bug.html
+.. _older: https://lammps.sandia.gov/tars
+.. _lws: https://lammps.sandia.gov
 
 You have two choices of tarballs, either the most recent stable
 release or the most current patch release.  Stable releases occur a
@@ -26,7 +26,7 @@ command:
 
 .. code-block:: bash
 
-   $ tar -xzvf lammps\*.tar.gz
+   $ tar -xzvf lammps*.tar.gz
 
 This will create a LAMMPS directory with the version date
 in its name, e.g. lammps-23Jun18.
@@ -40,7 +40,7 @@ a lammps-master dir:
 
 .. code-block:: bash
 
-   $ unzip lammps\*.zip
+   $ unzip lammps*.zip
 
 This version is the most up-to-date LAMMPS development version.  It
 will have the date of the most recent patch release (see the file
@@ -52,7 +52,6 @@ the next patch release tarball.
 
 ----------
 
-
 If you download a current LAMMPS tarball, one way to stay current as
 new patch tarballs are released, is to download a patch file which you
 can apply to your local directory to update it for each new patch

doc/src/Install_windows.rst

@@ -4,7 +4,9 @@ Download an executable for Windows
 Pre-compiled Windows installers which install LAMMPS executables on a
 Windows system can be downloaded from this site:
 
-`http://packages.lammps.org/windows.html <http://packages.lammps.org/windows.html>`_
+.. parsed-literal::
+
+  `http://packages.lammps.org/windows.html <http://packages.lammps.org/windows.html>`_
 
 Note that each installer package has a date in its name, which
 corresponds to the LAMMPS version of the same date.  Installers for
@@ -26,7 +28,7 @@ When you download the installer package, you run it on your Windows
 machine.  It will then prompt you with a dialog, where you can choose
 the installation directory, unpack and copy several executables,
 potential files, documentation pdfs, selected example files, etc.  It
-will then update a few system settings (e.g. PATH, LAMMPS\_POTENTIALS)
+will then update a few system settings (e.g. PATH, LAMMPS_POTENTIALS)
 and add an entry into the Start Menu (with references to the
 documentation, LAMMPS homepage and more).  From that menu, there is
 also a link to an uninstaller that removes the files and undoes the

doc/src/Intro.rst

@@ -3,7 +3,6 @@ Introduction
 
 These pages provide a brief introduction to LAMMPS.
 
-
 .. toctree::
    :maxdepth: 1
 

doc/src/Intro_authors.rst

@@ -11,25 +11,20 @@ University:
 * Richard Berger, richard.berger at temple.edu
 
 .. _sjp: http://www.cs.sandia.gov/~sjplimp
-.. _lws: http://lammps.sandia.gov
-
+.. _lws: https://lammps.sandia.gov
 
 Past developers include Paul Crozier and Mark Stevens, both at Sandia,
 and Ray Shan, now at Materials Design.
 
-
 ----------
 
-
-The `Authors page <http://lammps.sandia.gov/authors.html>`_ of the
+The `Authors page <https://lammps.sandia.gov/authors.html>`_ of the
 `LAMMPS website <lws_>`_ has a comprehensive list of all the individuals
 who have contributed code for a new feature or command or tool to
 LAMMPS.
 
-
 ----------
 
-
 The following folks deserve special recognition.  Many of the packages
 they have written are unique for an MD code and LAMMPS would not be as
 general-purpose as it is without their expertise and efforts.
@@ -49,11 +44,9 @@ general-purpose as it is without their expertise and efforts.
 * Ilya Valuev (JIHT), USER-AWPMD package for wave packet MD
 * Greg Wagner (Northwestern U), MEAM package for MEAM potential
 
-
 ----------
 
-
-As discussed on the `History page <http://lammps.sandia.gov/history.html>`_ of the website, LAMMPS
+As discussed on the `History page <https://lammps.sandia.gov/history.html>`_ of the website, LAMMPS
 originated as a cooperative project between DOE labs and industrial
 partners.  Folks involved in the design and testing of the original
 version of LAMMPS were the following:

doc/src/Intro_features.rst

@@ -16,10 +16,8 @@ classes of functionality:
 10. :ref:`Pre- and post-processing <prepost>`
 11. :ref:`Specialized features (beyond MD itself) <special>`
 
-
 ----------
 
-
 .. _general:
 
 General features
@@ -189,14 +187,10 @@ Pre- and post-processing
   plotting, and visualization for LAMMPS simulations.  Pizza.py is
   written in `Python <python_>`_ and is available for download from `the Pizza.py WWW site <pizza_>`_.
 
-.. _pizza: http://www.sandia.gov/~sjplimp/pizza.html
-
-
+.. _pizza: https://pizza.sandia.gov
 
 .. _python: http://www.python.org
 
-
-
 .. _special:
 
 Specialized features

doc/src/Intro_nonfeatures.rst

@@ -66,7 +66,7 @@ Here are suggestions on how to perform these tasks:
   on-the-fly via its :doc:`dump image <dump_image>` command and pass
   them to an external program, `FFmpeg <https://www.ffmpeg.org>`_ to generate
   movies from them.  For high-quality, interactive visualization there are
-  many excellent and free tools available.  See the `Other Codes page <http://lammps.sandia.gov/viz.html>`_ page of the LAMMPS website for
+  many excellent and free tools available.  See the `Other Codes page <https://lammps.sandia.gov/viz.html>`_ page of the LAMMPS website for
   visualization packages that can use LAMMPS output data.
 * **Plotting:** See the next bullet about Pizza.py as well as the
   :doc:`Python <Python_head>` doc page for examples of plotting LAMMPS
@@ -75,7 +75,7 @@ Here are suggestions on how to perform these tasks:
   it easier to analyze and plot.  See the :doc:`Tools <Tools>` doc page
   for more discussion of the various tools.
 * **Pizza.py:** Our group has also written a separate toolkit called
-  `Pizza.py <http://pizza.sandia.gov>`_ which can do certain kinds of
+  `Pizza.py <https://pizza.sandia.gov>`_ which can do certain kinds of
   setup, analysis, plotting, and visualization (via OpenGL) for LAMMPS
   simulations.  It thus provides some functionality for several of the
   above bullets.  Pizza.py is written in `Python <http://www.python.org>`_

doc/src/Intro_opensource.rst

@@ -15,16 +15,10 @@ distribution.
 
 .. _gnu: http://www.gnu.org/copyleft/gpl.html
 
-
-
 .. _gnuorg: http://www.gnu.org
 
-
-
 .. _opensource: http://www.opensource.org
 
-
-
 Here is a summary of what the GPL means for LAMMPS users:
 
 (1) Anyone is free to use, modify, or extend LAMMPS in any way they