Merge pull request #1246 from akohlmey/next-patch-release

Patch release 7 December 2018

.github/CODEOWNERS

@@ -29,6 +29,7 @@ src/USER-MEAMC/*      @martok
 src/USER-MOFFF/*      @hheenen
 src/USER-MOLFILE/*    @akohlmey
 src/USER-NETCDF/*     @pastewka
+src/USER-PLUMED/*     @gtribello
 src/USER-PHONON/*     @lingtikong
 src/USER-PTM/*        @pmla
 src/USER-OMP/*        @akohlmey
@@ -125,3 +126,6 @@ python/*              @rbberger
 doc/utils/*/*         @rbberger
 doc/Makefile          @rbberger
 doc/README            @rbberger
+
+# for releases
+src/version.h         @sjplimp

.github/CONTRIBUTING.md

@@ -6,7 +6,7 @@ The following is a set of guidelines as well as explanations of policies and wor
 
 Thus please also have a look at:
 * [The Section on submitting new features for inclusion in LAMMPS of the Manual](http://lammps.sandia.gov/doc/Section_modify.html#mod-15)
-* [The LAMMPS GitHub Tutorial in the Manual](http://lammps.sandia.gov/doc/tutorial_github.html)
+* [The LAMMPS GitHub Tutorial in the Manual](http://lammps.sandia.gov/doc/Howto_github.html)
 
 ## Table of Contents
 
@@ -62,7 +62,7 @@ To be able to submit an issue on GitHub, you have to register for an account (fo
 
 We encourage users to submit new features or modifications for LAMMPS to the core developers so they can be added to the LAMMPS distribution. The preferred way to manage and coordinate this is by submitting a pull request at the LAMMPS project on GitHub. For any larger modifications or programming project, you are encouraged to contact the LAMMPS developers ahead of time, in order to discuss implementation strategies and coding guidelines, that will make it easier to integrate your contribution and result in less work for everybody involved. You are also encouraged to search through the list of open issues on GitHub and submit a new issue for a planned feature, so you would not duplicate the work of others (and possibly get scooped by them) or have your work duplicated by others.
 
-How quickly your contribution will be integrated depends largely on how much effort it will cause to integrate and test it, how much it requires changes to the core code base, and of how much interest it is to the larger LAMMPS community. Please see below for a checklist of typical requirements. Once you have prepared everything, see [this tutorial](http://lammps.sandia.gov/doc/tutorial_github.html)
+How quickly your contribution will be integrated depends largely on how much effort it will cause to integrate and test it, how much it requires changes to the core code base, and of how much interest it is to the larger LAMMPS community. Please see below for a checklist of typical requirements. Once you have prepared everything, see [this tutorial](http://lammps.sandia.gov/doc/Howto_github.html)
  for instructions on how to submit your changes or new files through a GitHub pull request
 
 Here is a checklist of steps you need to follow to submit a single file or user package for our consideration. Following these steps will save both you and us time. See existing files in packages in the source directory for examples. If you are uncertain, please ask on the lammps-users mailing list.
@@ -102,11 +102,11 @@ For bug reports, the next step is that one of the core LAMMPS developers will se
 
 ### Pull Requests
 
-For submitting pull requests, there is a [detailed tutorial](http://lammps.sandia.gov/doc/tutorial_github.html) in the LAMMPS manual. Thus only a brief breakdown of the steps is presented here.
+For submitting pull requests, there is a [detailed tutorial](http://lammps.sandia.gov/doc/Howto_github.html) in the LAMMPS manual. Thus only a brief breakdown of the steps is presented here. Please note, that the LAMMPS developers are still reviewing and trying to improve the process. If you are unsure about something, do not hesitate to post a question on the lammps-users mailing list or contact one fo the core LAMMPS developers.
 Immediately after the submission, the LAMMPS continuing integration server at ci.lammps.org will download your submitted branch and perform a simple compilation test, i.e. will test whether your submitted code can be compiled under various conditions. It will also do a check on whether your included documentation translates cleanly. Whether these tests are successful or fail will be recorded. If a test fails, please inspect the corresponding output on the CI server and take the necessary steps, if needed, so that the code can compile cleanly again. The test will be re-run each the pull request is updated with a push to the remote branch on GitHub.
 Next a LAMMPS core developer will self-assign and do an overall technical assessment of the submission. If you are not yet registered as a LAMMPS collaborator, you will receive an invitation for that.
 You may also receive comments and suggestions on the overall submission or specific details. If permitted, additional changes may be pushed into your pull request branch or a pull request may be filed in your LAMMPS fork on GitHub to include those changes.
 The LAMMPS developer may then decide to assign the pull request to another developer (e.g. when that developer is more knowledgeable about the submitted feature or enhancement or has written the modified code). It may also happen, that additional developers are requested to provide a review and approve the changes. For submissions, that may change the general behavior of LAMMPS, or where a possibility of unwanted side effects exists, additional tests may be requested by the assigned developer.
-If the assigned developer is satisfied and considers the submission ready for inclusion into LAMMPS, the pull request will be assigned to the LAMMPS lead developer, Steve Plimpton (@sjplimp), who will then have the final decision on whether the submission will be included, additional changes are required or it will be ultimately rejected. After the pull request is merged, you may delete the pull request branch in your personal LAMMPS fork.
-Since the learning curve for git is quite steep for efficiently managing remote repositories, local and remote branches, pull requests and more, do not hesitate to ask questions, if you are not sure about how to do certain steps that are asked of you. Even if the changes asked of you do not make sense to you, they may be important for the LAMMPS developers. Please also note, that these all are guidelines and not set in stone.
+If the assigned developer is satisfied and considers the submission ready for inclusion into LAMMPS, the pull request will receive approvals and be merged into the master branch by one of the core LAMMPS developers. After the pull request is merged, you may delete the feature branch used for the pull request in your personal LAMMPS fork.
+Since the learning curve for git is quite steep for efficiently managing remote repositories, local and remote branches, pull requests and more, do not hesitate to ask questions, if you are not sure about how to do certain steps that are asked of you. Even if the changes asked of you do not make sense to you, they may be important for the LAMMPS developers. Please also note, that these all are guidelines and nothing set in stone. So depending on the nature of the contribution, the workflow may be adjusted.
 

.gitignore

@@ -22,6 +22,7 @@ log.cite
 .*.swp
 *.orig
 *.rej
+vgcore.*
 .vagrant
 \#*#
 .#*

cmake/CMakeLists.txt

@@ -11,6 +11,10 @@ get_filename_component(LAMMPS_LIB_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../lib
 get_filename_component(LAMMPS_LIB_BINARY_DIR ${CMAKE_BINARY_DIR}/lib ABSOLUTE)
 get_filename_component(LAMMPS_DOC_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../doc ABSOLUTE)
 
+# by default, install into $HOME/.local (not /usr/local), so that no root access (and sudo!!) is needed
+if (CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
+  set(CMAKE_INSTALL_PREFIX "$ENV{HOME}/.local" CACHE PATH "default install path" FORCE )
+endif()
 
 # To avoid conflicts with the conventional Makefile build system, we build everything here
 file(GLOB LIB_SOURCES ${LAMMPS_SOURCE_DIR}/[^.]*.cpp)
@@ -75,6 +79,7 @@ if(NOT CMAKE_BUILD_TYPE AND NOT CMAKE_CXX_FLAGS)
   #release comes with -O3 by default
   set(CMAKE_BUILD_TYPE Release CACHE STRING "Choose the type of build, options are: None Debug Release RelWithDebInfo MinSizeRel." FORCE)
 endif(NOT CMAKE_BUILD_TYPE AND NOT CMAKE_CXX_FLAGS)
+string(TOUPPER "${CMAKE_BUILD_TYPE}" BTYPE)
 
 # check for files auto-generated by make-based buildsystem
 # this is fast, so check for it all the time
@@ -171,8 +176,9 @@ set(DEFAULT_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS DIPOLE GRANULAR
   USER-BOCS USER-CGDNA USER-MESO 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-PTM USER-QTB USER-REAXC USER-SCAFACOS USER-SMD USER-SMTBQ
-  USER-SPH USER-TALLY USER-UEF USER-VTK USER-QUIP USER-QMMM)
+  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)
 set(ACCEL_PACKAGES USER-OMP KOKKOS OPT USER-INTEL GPU)
 set(OTHER_PACKAGES CORESHELL QEQ)
 foreach(PKG ${DEFAULT_PACKAGES})
@@ -193,6 +199,8 @@ if(PKG_MEAM OR PKG_USER-H5MD OR PKG_USER-QMMM OR PKG_USER-SCAFACOS)
   enable_language(C)
 endif()
 
+include_directories(${LAMMPS_SOURCE_DIR})
+
 # do MPI detection after language activation, if MPI for these language is required
 find_package(MPI QUIET)
 option(BUILD_MPI "Build MPI version" ${MPI_FOUND})
@@ -301,7 +309,7 @@ pkg_depends(USER-SCAFACOS MPI)
 
 find_package(OpenMP QUIET)
 option(BUILD_OMP "Build with OpenMP support" ${OpenMP_FOUND})
-if(BUILD_OMP OR PKG_USER-OMP OR PKG_KOKKOS OR PKG_USER-INTEL)
+if(BUILD_OMP OR PKG_KOKKOS OR PKG_USER-INTEL)
   find_package(OpenMP REQUIRED)
   set (CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${OpenMP_C_FLAGS}")
   set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${OpenMP_CXX_FLAGS}")
@@ -419,16 +427,30 @@ if(WITH_FFMPEG)
   add_definitions(-DLAMMPS_FFMPEG)
 endif()
 
+if(BUILD_SHARED_LIBS)
+  set(CONFIGURE_REQUEST_PIC "--with-pic")
+  set(CMAKE_REQUEST_PIC "-DCMAKE_POSITION_INDEPENDENT_CODE=${CMAKE_POSITION_INDEPENDENT_CODE}")
+  set(CUDA_REQUEST_PIC "-Xcompiler ${CMAKE_SHARED_LIBRARY_CXX_FLAGS}")
+else()
+  set(CONFIGURE_REQUEST_PIC)
+  set(CMAKE_REQUEST_PIC)
+  set(CUDA_REQUEST_PIC)
+endif()
+
+
 if(PKG_VORONOI)
-  option(DOWNLOAD_VORO "Download voro++ (instead of using the system's one)" OFF)
+  option(DOWNLOAD_VORO "Download and compile the Voro++ library instead of using an already installed one" OFF)
   if(DOWNLOAD_VORO)
+    message(STATUS "Voro++ download requested - we will build our own")
     include(ExternalProject)
 
     if(BUILD_SHARED_LIBS)
-        set(VORO_BUILD_OPTIONS "CFLAGS=-fPIC")
+      set(VORO_BUILD_CFLAGS "${CMAKE_SHARED_LIBRARY_CXX_FLAGS} ${CMAKE_CXX_FLAGS} ${CMAKE_CXX_FLAGS_${BTYPE}}")
     else()
-        set(VORO_BUILD_OPTIONS)
+      set(VORO_BUILD_CFLAGS "${CMAKE_CXX_FLAGS} ${CMAKE_CXX_FLAGS_${BTYPE}}")
     endif()
+    string(APPEND VORO_BUILD_CFLAGS ${CMAKE_CXX_FLAGS})
+    set(VORO_BUILD_OPTIONS CXX=${CMAKE_CXX_COMPILER} CFLAGS=${VORO_BUILD_CFLAGS})
 
     ExternalProject_Add(voro_build
       URL http://math.lbl.gov/voro++/download/dir/voro++-0.4.6.tar.gz
@@ -442,7 +464,7 @@ if(PKG_VORONOI)
   else()
     find_package(VORO)
     if(NOT VORO_FOUND)
-      message(FATAL_ERROR "VORO not found, help CMake to find it by setting VORO_LIBRARY and VORO_INCLUDE_DIR, or set DOWNLOAD_VORO=ON to download it")
+      message(FATAL_ERROR "Voro++ library not found. Help CMake to find it by setting VORO_LIBRARY and VORO_INCLUDE_DIR, or set DOWNLOAD_VORO=ON to download it")
     endif()
   endif()
   include_directories(${VORO_INCLUDE_DIRS})
@@ -450,18 +472,18 @@ if(PKG_VORONOI)
 endif()
 
 if(PKG_LATTE)
-  option(DOWNLOAD_LATTE "Download latte (instead of using the system's one)" OFF)
+  option(DOWNLOAD_LATTE "Download the LATTE library instead of using an already installed one" OFF)
   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()
-    message(STATUS "LATTE not found - we will build our own")
+    message(STATUS "LATTE download requested - we will build our own")
     include(ExternalProject)
     ExternalProject_Add(latte_build
       URL https://github.com/lanl/LATTE/archive/v1.2.1.tar.gz
       URL_MD5 85ac414fdada2d04619c8f936344df14
       SOURCE_SUBDIR cmake
-      CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=<INSTALL_DIR> -DCMAKE_POSITION_INDEPENDENT_CODE=${CMAKE_POSITION_INDEPENDENT_CODE}
+      CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=<INSTALL_DIR> ${CMAKE_REQUEST_PIC}
     )
     ExternalProject_get_property(latte_build INSTALL_DIR)
     set(LATTE_LIBRARIES ${INSTALL_DIR}/${CMAKE_INSTALL_LIBDIR}/liblatte.a)
@@ -469,7 +491,7 @@ if(PKG_LATTE)
   else()
     find_package(LATTE)
     if(NOT LATTE_FOUND)
-      message(FATAL_ERROR "LATTE not found, help CMake to find it by setting LATTE_LIBRARY, or set DOWNLOAD_LATTE=ON to download it")
+      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()
   list(APPEND LAMMPS_LINK_LIBS ${LATTE_LIBRARIES} ${LAPACK_LIBRARIES})
@@ -477,19 +499,17 @@ endif()
 
 if(PKG_USER-SCAFACOS)
   find_package(GSL REQUIRED)
-  option(DOWNLOAD_SCAFACOS "Download ScaFaCoS (instead of using the system's one)" OFF)
+  option(DOWNLOAD_SCAFACOS "Download ScaFaCoS library instead of using an already installed one" OFF)
   if(DOWNLOAD_SCAFACOS)
+    message(STATUS "ScaFaCoS download requested - we will build our own")
     include(ExternalProject)
     ExternalProject_Add(scafacos_build
       URL https://github.com/scafacos/scafacos/releases/download/v1.0.1/scafacos-1.0.1.tar.gz
       URL_MD5 bd46d74e3296bd8a444d731bb10c1738
-      CONFIGURE_COMMAND <SOURCE_DIR>/configure --prefix=<INSTALL_DIR> 
-                                               --disable-doc 
+      CONFIGURE_COMMAND <SOURCE_DIR>/configure --prefix=<INSTALL_DIR> --disable-doc
                                                --enable-fcs-solvers=fmm,p2nfft,direct,ewald,p3m
-                                               --with-internal-fftw
-                                               --with-internal-pfft
-                                               --with-internal-pnfft
-                                               $<$<BOOL:${BUILD_SHARED_LIBS}>:--with-pic>                                               
+                                               --with-internal-fftw --with-internal-pfft
+                                               --with-internal-pnfft ${CONFIGURE_REQUEST_PIC}
                                                FC=${CMAKE_MPI_Fortran_COMPILER}
                                                CXX=${CMAKE_MPI_CXX_COMPILER}
                                                CC=${CMAKE_MPI_C_COMPILER}
@@ -526,6 +546,54 @@ if(PKG_USER-SCAFACOS)
   include_directories(${SCAFACOS_INCLUDE_DIRS})
 endif()
 
+if(PKG_USER-PLUMED)
+  find_package(GSL REQUIRED)
+  set(PLUMED_MODE "static" CACHE STRING "Linkage mode for Plumed2 library")
+  set(PLUMED_MODE_VALUES static shared runtime)
+  set_property(CACHE PLUMED_MODE PROPERTY STRINGS ${PLUMED_MODE_VALUES})
+  validate_option(PLUMED_MODE PLUMED_MODE_VALUES)
+  string(TOUPPER ${PLUMED_MODE} PLUMED_MODE)
+
+  option(DOWNLOAD_PLUMED "Download Plumed package instead of using an already installed one" OFF)
+  if(DOWNLOAD_PLUMED)
+    message(STATUS "PLUMED download requested - we will build our own")
+    include(ExternalProject)
+    ExternalProject_Add(plumed_build
+      URL https://github.com/plumed/plumed2/releases/download/v2.4.3/plumed-src-2.4.3.tgz
+      URL_MD5 b1be7c48971627febc11c61b70767fc5
+      BUILD_IN_SOURCE 1
+      CONFIGURE_COMMAND <SOURCE_DIR>/configure --prefix=<INSTALL_DIR> ${CONFIGURE_REQUEST_PIC})
+    ExternalProject_get_property(plumed_build INSTALL_DIR)
+    set(PLUMED_INSTALL_DIR ${INSTALL_DIR})
+    list(APPEND LAMMPS_DEPS plumed_build)
+    if(PLUMED_MODE STREQUAL "STATIC")
+      add_definitions(-D__PLUMED_WRAPPER_CXX=1)
+      list(APPEND LAMMPS_LINK_LIBS ${PLUMED_INSTALL_DIR}/lib/plumed/obj/kernel.o
+        "${PLUMED_INSTALL_DIR}/lib/plumed/obj/PlumedStatic.o" ${GSL_LIBRARIES} ${CMAKE_DL_LIBS})
+    elseif(PLUMED_MODE STREQUAL "SHARED")
+      list(APPEND LAMMPS_LINK_LIBS ${PLUMED_INSTALL_DIR}/lib/libplumed.so ${CMAKE_DL_LIBS})
+    elseif(PLUMED_MODE STREQUAL "RUNTIME")
+      add_definitions(-D__PLUMED_HAS_DLOPEN=1 -D__PLUMED_DEFAULT_KERNEL=${PLUMED_INSTALL_DIR}/lib/libplumedKernel.so)
+      list(APPEND LAMMPS_LINK_LIBS ${PLUMED_INSTALL_DIR}/lib/libplumedWrapper.a -rdynamic ${CMAKE_DL_LIBS})
+    endif()
+    set(PLUMED_INCLUDE_DIRS "${PLUMED_INSTALL_DIR}/include")
+  else()
+    find_package(PkgConfig REQUIRED)
+    pkg_check_modules(PLUMED plumed REQUIRED)
+    if(PLUMED_MODE STREQUAL "STATIC")
+      add_definitions(-D__PLUMED_WRAPPER_CXX=1)
+      include(${PLUMED_LIBDIR}/plumed/src/lib/Plumed.cmake.static)
+    elseif(PLUMED_MODE STREQUAL "SHARED")
+      include(${PLUMED_LIBDIR}/plumed/src/lib/Plumed.cmake.shared)
+    elseif(PLUMED_MODE STREQUAL "RUNTIME")
+      add_definitions(-D__PLUMED_HAS_DLOPEN=1 -D__PLUMED_DEFAULT_KERNEL=${PLUMED_LIBDIR}/libplumedKernel.so)
+      include(${PLUMED_LIBDIR}/plumed/src/lib/Plumed.cmake.runtime)
+    endif()
+    list(APPEND LAMMPS_LINK_LIBS ${PLUMED_LOAD})
+  endif()
+  include_directories(${PLUMED_INCLUDE_DIRS})
+endif()
+
 if(PKG_USER-MOLFILE)
   add_library(molfile INTERFACE)
   target_include_directories(molfile INTERFACE ${LAMMPS_LIB_SOURCE_DIR}/molfile)
@@ -541,8 +609,9 @@ if(PKG_USER-NETCDF)
 endif()
 
 if(PKG_USER-SMD)
-  option(DOWNLOAD_EIGEN3 "Download Eigen3 (instead of using the system's one)" OFF)
+  option(DOWNLOAD_EIGEN3 "Download Eigen3 instead of using an already installed one)" OFF)
   if(DOWNLOAD_EIGEN3)
+    message(STATUS "Eigen3 download requested - we will build our own")
     include(ExternalProject)
     ExternalProject_Add(Eigen3_build
       URL http://bitbucket.org/eigen/eigen/get/3.3.4.tar.gz
@@ -582,8 +651,9 @@ if(PKG_USER-VTK)
 endif()
 
 if(PKG_KIM)
-  option(DOWNLOAD_KIM "Download kim-api (instead of using the system's one)" OFF)
+  option(DOWNLOAD_KIM "Download KIM-API v1 from OpenKIM instead of using an already installed one)" OFF)
   if(DOWNLOAD_KIM)
+    message(STATUS "KIM-API v1 download requested - we will build our own")
     include(ExternalProject)
     ExternalProject_Add(kim_build
       URL https://github.com/openkim/kim-api/archive/v1.9.5.tar.gz
@@ -598,7 +668,7 @@ if(PKG_KIM)
   else()
     find_package(KIM)
     if(NOT KIM_FOUND)
-      message(FATAL_ERROR "KIM not found, help CMake to find it by setting KIM_LIBRARY and KIM_INCLUDE_DIR, or set DOWNLOAD_KIM=ON to download it")
+      message(FATAL_ERROR "KIM-API v1 not found, help CMake to find it by setting KIM_LIBRARY and KIM_INCLUDE_DIR, or set DOWNLOAD_KIM=ON to download it")
     endif()
   endif()
   list(APPEND LAMMPS_LINK_LIBS ${KIM_LIBRARIES})
@@ -611,12 +681,7 @@ if(PKG_MESSAGE)
       ${LAMMPS_LIB_SOURCE_DIR}/message/cslib/[^.]*.c
       ${LAMMPS_LIB_SOURCE_DIR}/message/cslib/[^.]*.cpp)
 
-  if(BUILD_SHARED_LIBS)
-      add_library(cslib SHARED ${cslib_SOURCES})
-  else()
   add_library(cslib STATIC ${cslib_SOURCES})
-  endif()
-
   if(BUILD_MPI)
     target_compile_definitions(cslib PRIVATE -DMPI_YES)
     set_target_properties(cslib PROPERTIES OUTPUT_NAME "csmpi")
@@ -641,10 +706,10 @@ endif()
 
 if(PKG_MSCG)
   find_package(GSL REQUIRED)
-  option(DOWNLOAD_MSCG "Download latte (instead of using the system's one)" OFF)
+  option(DOWNLOAD_MSCG "Download MSCG library instead of using an already installed one)" OFF)
   if(DOWNLOAD_MSCG)
     if (CMAKE_VERSION VERSION_LESS "3.7") # due to SOURCE_SUBDIR
-      message(FATAL_ERROR "For downlading LATTE you need at least cmake-3.7")
+      message(FATAL_ERROR "For downlading MSCG you need at least cmake-3.7")
     endif()
     include(ExternalProject)
     if(NOT LAPACK_FOUND)
@@ -654,7 +719,7 @@ 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> -DCMAKE_POSITION_INDEPENDENT_CODE=${CMAKE_POSITION_INDEPENDENT_CODE} ${EXTRA_MSCG_OPTS}
+      CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=<INSTALL_DIR> ${CMAKE_REQUEST_PIC} ${EXTRA_MSCG_OPTS}
       BUILD_COMMAND make mscg INSTALL_COMMAND ""
       )
     ExternalProject_get_property(mscg_build BINARY_DIR)
@@ -702,7 +767,7 @@ 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
+  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)
@@ -740,6 +805,13 @@ foreach(PKG ${DEFAULT_PACKAGES})
   endif()
 endforeach()
 
+# packages that need defines set
+foreach(PKG MPIIO)
+  if(PKG_${PKG})
+    add_definitions(-DLMP_${PKG})
+  endif()
+endforeach()
+
 # dedicated check for entire contents of accelerator packages
 foreach(PKG ${ACCEL_PACKAGES})
   set(${PKG}_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/${PKG})
@@ -768,7 +840,7 @@ foreach(SIMPLE_LIB REAX MEAM POEMS USER-ATC USER-AWPMD USER-COLVARS USER-H5MD
     if(PKG_LIB STREQUAL awpmd)
       target_include_directories(awpmd PUBLIC ${LAMMPS_LIB_SOURCE_DIR}/awpmd/systems/interact ${LAMMPS_LIB_SOURCE_DIR}/awpmd/ivutils/include)
     elseif(PKG_LIB STREQUAL h5md)
-      target_include_directories(h5md PUBLIC ${LAMMPS_LIB_SOURCE_DIR}/h5md/include)
+      target_include_directories(h5md PUBLIC ${LAMMPS_LIB_SOURCE_DIR}/h5md/include ${HDF5_INCLUDE_DIRS})
     elseif(PKG_LIB STREQUAL colvars)
       target_compile_options(colvars PRIVATE -DLEPTON)
       target_include_directories(colvars PRIVATE ${LAMMPS_LIB_SOURCE_DIR}/colvars/lepton/include)
@@ -791,6 +863,7 @@ if(PKG_USER-H5MD)
   find_package(HDF5 REQUIRED)
   target_link_libraries(h5md ${HDF5_LIBRARIES})
   target_include_directories(h5md PRIVATE ${HDF5_INCLUDE_DIRS})
+  include_directories(${HDF5_INCLUDE_DIRS})
 endif()
 
 
@@ -876,6 +949,20 @@ if(PKG_USER-OMP)
     include_directories(${USER-OMP_SOURCES_DIR})
 endif()
 
+# Fix rigid/meso requires RIGID to be installed
+if(PKG_USER-SDPD)
+  set(USER-SDPD_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/USER-SDPD)
+
+  get_property(hlist GLOBAL PROPERTY FIX)
+  if(NOT PKG_RIGID)
+    list(REMOVE_ITEM hlist ${USER-SDPD_SOURCES_DIR}/fix_rigid_meso.h)
+    list(REMOVE_ITEM LIB_SOURCES ${USER-SDPD_SOURCES_DIR}/fix_rigid_meso.cpp)
+  endif()
+  set_property(GLOBAL PROPERTY FIX "${hlist}")
+
+  include_directories(${USER-SDPD_SOURCES_DIR})
+endif()
+
 if(PKG_KOKKOS)
   set(LAMMPS_LIB_KOKKOS_SRC_DIR ${LAMMPS_LIB_SOURCE_DIR}/kokkos)
   set(LAMMPS_LIB_KOKKOS_BIN_DIR ${LAMMPS_LIB_BINARY_DIR}/kokkos)
@@ -953,7 +1040,7 @@ if(PKG_USER-INTEL)
     endif()
 
     if(CMAKE_CXX_COMPILER_VERSION VERSION_LESS 16)
-        message(FATAL_ERROR "USER-INTEL is needed at least 2016 intel compiler, found ${CMAKE_CXX_COMPILER_VERSION}")
+        message(FATAL_ERROR "USER-INTEL needs at least a 2016 intel compiler, found ${CMAKE_CXX_COMPILER_VERSION}")
     endif()
 
     if(NOT BUILD_OMP)
@@ -1053,11 +1140,11 @@ if(PKG_GPU)
       find_package(CUDA REQUIRED)
       find_program(BIN2C bin2c)
       if(NOT BIN2C)
-        message(FATAL_ERROR "Couldn't find bin2c, use -DBIN2C helping cmake to find it.")
+        message(FATAL_ERROR "Could not find bin2c, use -DBIN2C=/path/to/bin2c to help cmake finding it.")
       endif()
       option(CUDPP_OPT "Enable CUDPP_OPT" ON)
 
-      set(GPU_ARCH "sm_30" CACHE STRING "LAMMPS GPU CUDA SM architecture (e.g. sm_60)")
+      set(GPU_ARCH "sm_30" CACHE STRING "LAMMPS GPU CUDA SM primary architecture (e.g. sm_60)")
 
       file(GLOB GPU_LIB_CU ${LAMMPS_LIB_SOURCE_DIR}/gpu/[^.]*.cu ${CMAKE_CURRENT_SOURCE_DIR}/gpu/[^.]*.cu)
       list(REMOVE_ITEM GPU_LIB_CU ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_pppm.cu)
@@ -1070,11 +1157,39 @@ if(PKG_GPU)
         file(GLOB GPU_LIB_CUDPP_CU ${LAMMPS_LIB_SOURCE_DIR}/gpu/cudpp_mini/[^.]*.cu)
       endif()
 
-      cuda_compile_cubin(GPU_GEN_OBJS ${GPU_LIB_CU} OPTIONS
-                   -DUNIX -O3 -Xptxas -v --use_fast_math -DNV_KERNEL -DUCL_CUDADR -arch=${GPU_ARCH} -D_${GPU_PREC_SETTING})
+      # build arch/gencode commands for nvcc based on CUDA toolkit version and use choice
+      # --arch translates directly instead of JIT, so this should be for the preferred or most common architecture
+      set(GPU_CUDA_GENCODE "-arch=${GPU_ARCH} ")
+      # Fermi (GPU Arch 2.x) is supported by CUDA 3.2 to CUDA 8.0
+      if((CUDA_VERSION VERSION_GREATER "3.1") AND (CUDA_VERSION VERSION_LESS "9.0"))
+        string(APPEND GPU_CUDA_GENCODE "-gencode arch=compute_20,code=[sm_20,compute_20] ")
+      endif()
+      # Kepler (GPU Arch 3.x) is supported by CUDA 5 and later
+      if(CUDA_VERSION VERSION_GREATER "4.9")
+        string(APPEND GPU_CUDA_GENCODE "-gencode arch=compute_30,code=[sm_30,compute_30] -gencode arch=compute_35,code=[sm_35,compute_35] ")
+      endif()
+      # Maxwell (GPU Arch 5.x) is supported by CUDA 6 and later
+      if(CUDA_VERSION VERSION_GREATER "5.9")
+        string(APPEND GPU_CUDA_GENCODE "-gencode arch=compute_50,code=[sm_50,compute_50] -gencode arch=compute_52,code=[sm_52,compute_52] ")
+      endif()
+      # Pascal (GPU Arch 6.x) is supported by CUDA 8 and later
+      if(CUDA_VERSION VERSION_GREATER "7.9")
+        string(APPEND GPU_CUDA_GENCODE "-gencode arch=compute_60,code=[sm_60,compute_60] -gencode arch=compute_61,code=[sm_61,compute_61] ")
+      endif()
+      # Volta (GPU Arch 7.0) is supported by CUDA 9 and later
+      if(CUDA_VERSION VERSION_GREATER "8.9")
+        string(APPEND GPU_CUDA_GENCODE "-gencode arch=compute_70,code=[sm_70,compute_70] ")
+      endif()
+      # Turing (GPU Arch 7.5) is supported by CUDA 10 and later
+      if(CUDA_VERSION VERSION_GREATER "9.9")
+        string(APPEND GPU_CUDA_GENCODE "-gencode arch=compute_75,code=[sm_75,compute_75] ")
+      endif()
 
-      cuda_compile(GPU_OBJS ${GPU_LIB_CUDPP_CU} OPTIONS $<$<BOOL:${BUILD_SHARED_LIBS}>:-Xcompiler=-fPIC>
-                   -DUNIX -O3 -Xptxas -v --use_fast_math -DUCL_CUDADR -arch=${GPU_ARCH} -D_${GPU_PREC_SETTING})
+      cuda_compile_fatbin(GPU_GEN_OBJS ${GPU_LIB_CU} OPTIONS
+              -DUNIX -O3 --use_fast_math -Wno-deprecated-gpu-targets -DNV_KERNEL -DUCL_CUDADR ${GPU_CUDA_GENCODE} -D_${GPU_PREC_SETTING})
+
+      cuda_compile(GPU_OBJS ${GPU_LIB_CUDPP_CU} OPTIONS ${CUDA_REQUEST_PIC}
+              -DUNIX -O3 --use_fast_math -Wno-deprecated-gpu-targets -DUCL_CUDADR ${GPU_CUDA_GENCODE} -D_${GPU_PREC_SETTING})
 
       foreach(CU_OBJ ${GPU_GEN_OBJS})
         get_filename_component(CU_NAME ${CU_OBJ} NAME_WE)
@@ -1166,7 +1281,6 @@ set(LAMMPS_STYLE_HEADERS_DIR ${CMAKE_CURRENT_BINARY_DIR}/styles)
 
 GenerateStyleHeaders(${LAMMPS_STYLE_HEADERS_DIR})
 
-include_directories(${LAMMPS_SOURCE_DIR})
 include_directories(${LAMMPS_STYLE_HEADERS_DIR})
 
 ######################################
@@ -1344,7 +1458,6 @@ foreach(PKG ${DEFAULT_PACKAGES} ${ACCEL_PACKAGES} ${OTHER_PACKAGES})
   endif()
 endforeach()
 
-string(TOUPPER "${CMAKE_BUILD_TYPE}" BTYPE)
 get_directory_property(CPPFLAGS DIRECTORY ${CMAKE_SOURCE_DIR} COMPILE_DEFINITIONS)
 include(FeatureSummary)
 feature_summary(DESCRIPTION "The following packages have been found:" WHAT PACKAGES_FOUND)

cmake/README.md

@@ -195,6 +195,7 @@ cmake -C ../cmake/presets/std_nolib.cmake -D PKG_GPU=on ../cmake
   <td><code>CMAKE_INSTALL_PREFIX</code></td>
   <td>Install location where LAMMPS files will be copied to. In the Unix/Linux case with Makefiles this controls what `make install` will do.</td>
   <td>
+   Default setting is <code>$HOME/.local</code>.
   </td>
 </tr>
 <tr>
@@ -1492,6 +1493,11 @@ target API.
   </dl>
   </td>
 </tr>
+<tr>
+  <td><code>BIN2C</code> (CUDA only)</td>
+  <td>Path to bin2c executable, will automatically pick up the first one in your $PATH.</td>
+  <td>(automatic)</td>
+</tr>
 </tbody>
 </table>
 
@@ -1647,9 +1653,8 @@ requires `gzip` to be in your `PATH`
 </tr>
 <tr>
   <td><code>GZIP_EXECUTABLE</code></td>
-  <td></td>
-  <td>
-  </td>
+  <td>Path to gzip executable, will automatically pick up the first one in your $PATH.</td>
+  <td>(automatic)</td>
 </tr>
 </tbody>
 </table>
@@ -1679,9 +1684,8 @@ requires `ffmpeg` to be in your `PATH`
 </tr>
 <tr>
   <td><code>FFMPEG_EXECUTABLE</code></td>
-  <td></td>
-  <td>
-  </td>
+  <td>Path to ffmpeg executable, will automatically pick up the first one in your $PATH.</td>
+  <td>(automatic)</td>
 </tr>
 </tbody>
 </table>

cmake/pkgconfig/liblammps.pc.in

@@ -1,9 +1,29 @@
 # pkg-config file for lammps
 # https://people.freedesktop.org/~dbn/pkg-config-guide.html
-# Usage: cc `pkg-config --cflags --libs liblammps` -o myapp myapp.c
-# after you added @CMAKE_INSTALL_FULL_LIBDIR@/pkg-config to PKG_CONFIG_PATH,
+
+# Add the directory where lammps.pc got installed to your PKG_CONFIG_PATH
 # e.g. export PKG_CONFIG_PATH=@CMAKE_INSTALL_FULL_LIBDIR@/pkgconfig
 
+# Use this on commandline with:
+# c++ `pkg-config --cflags --libs lammps` -o myapp myapp.cpp
+
+# Use this in a Makefile:
+# myapp: myapp.cpp
+# 	$(CC) `pkg-config --cflags --libs lammps` -o $@ $<
+
+# Use this in autotools:
+# configure.ac:
+# PKG_CHECK_MODULES([LAMMPS], [lammps])
+# Makefile.am:
+# myapp_CFLAGS = $(LAMMPS_CFLAGS)
+# myapp_LDADD = $(LAMMPS_LIBS)
+
+# Use this in CMake:
+# CMakeLists.txt:
+# find_package(PkgConfig)
+# pkg_check_modules(LAMMPS IMPORTED_TARGET lammps)
+# target_link_libraries(<lib> PkgConfig::LAMMPS)
+
 prefix=@CMAKE_INSTALL_PREFIX@
 libdir=@CMAKE_INSTALL_FULL_LIBDIR@
 includedir=@CMAKE_INSTALL_FULL_INCLUDEDIR@

cmake/presets/all_off.cmake

@@ -8,12 +8,12 @@ set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVA
                   USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
                   USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
                   USER-NETCDF USER-OMP USER-PHONON USER-QMMM USER-QTB
-                  USER-QUIP USER-REAXC USER-SMD USER-SMTBQ USER-SPH USER-TALLY
+                  USER-QUIP USER-REAXC USER-SDPD USER-SMD USER-SMTBQ USER-SPH USER-TALLY
                   USER-UEF USER-VTK)
 
 set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MEAM MPIIO MSCG POEMS PYTHON REAX VORONOI
                       USER-ATC USER-AWPMD USER-COLVARS USER-H5MD USER-LB USER-MOLFILE
-                      USER-NETCDF USER-QMMM USER-QUIP USER-SMD USER-VTK)
+                      USER-NETCDF USER-PLUMED USER-QMMM USER-QUIP USER-SMD USER-VTK)
 
 set(ALL_PACKAGES ${STANDARD_PACKAGES} ${USER_PACKAGES})
 

cmake/presets/all_on.cmake

@@ -8,12 +8,12 @@ set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVA
                   USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
                   USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
                   USER-NETCDF USER-OMP USER-PHONON USER-QMMM USER-QTB
-                  USER-QUIP USER-REAXC USER-SMD USER-SMTBQ USER-SPH USER-TALLY
+                  USER-QUIP USER-REAXC USER-SDPD USER-SMD USER-SMTBQ USER-SPH USER-TALLY
                   USER-UEF USER-VTK)
 
 set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MEAM MPIIO MSCG POEMS PYTHON REAX VORONOI
                       USER-ATC USER-AWPMD USER-COLVARS USER-H5MD USER-LB USER-MOLFILE
-                      USER-NETCDF USER-QMMM USER-QUIP USER-SMD USER-VTK)
+                      USER-NETCDF USER-PLUMED USER-QMMM USER-QUIP USER-SMD USER-VTK)
 
 set(ALL_PACKAGES ${STANDARD_PACKAGES} ${USER_PACKAGES})
 

cmake/presets/manual_selection.cmake

@@ -56,11 +56,13 @@ set(PKG_USER-MOFFF OFF CACHE BOOL "" FORCE)
 set(PKG_USER-MOLFILE OFF CACHE BOOL "" FORCE)
 set(PKG_USER-NETCDF OFF CACHE BOOL "" FORCE)
 set(PKG_USER-OMP OFF CACHE BOOL "" FORCE)
-set(PKG_USER-PHOFFOFF OFF CACHE BOOL "" FORCE)
+set(PKG_USER-PHONON OFF CACHE BOOL "" FORCE)
+set(PKG_USER-PLUMED OFF CACHE BOOL "" FORCE)
 set(PKG_USER-QMMM OFF CACHE BOOL "" FORCE)
 set(PKG_USER-QTB OFF CACHE BOOL "" FORCE)
 set(PKG_USER-QUIP OFF CACHE BOOL "" FORCE)
 set(PKG_USER-REAXC OFF CACHE BOOL "" FORCE)
+set(PKG_USER-SDPD OFF CACHE BOOL "" FORCE)
 set(PKG_USER-SMD OFF CACHE BOOL "" FORCE)
 set(PKG_USER-SMTBQ OFF CACHE BOOL "" FORCE)
 set(PKG_USER-SPH OFF CACHE BOOL "" FORCE)

cmake/presets/nolib.cmake

@@ -8,12 +8,12 @@ set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVA
                   USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
                   USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
                   USER-NETCDF USER-OMP USER-PHONON USER-QMMM USER-QTB
-                  USER-QUIP USER-REAXC USER-SMD USER-SMTBQ USER-SPH USER-TALLY
+                  USER-QUIP USER-REAXC USER-SDPD USER-SMD USER-SMTBQ USER-SPH USER-TALLY
                   USER-UEF USER-VTK)
 
 set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MEAM MPIIO MSCG POEMS PYTHON REAX VORONOI
                       USER-ATC USER-AWPMD USER-COLVARS USER-H5MD USER-LB USER-MOLFILE
-                      USER-NETCDF USER-QMMM USER-QUIP USER-SMD USER-VTK)
+                      USER-NETCDF USER-PLUMED USER-QMMM USER-QUIP USER-SMD USER-VTK)
 
 set(ALL_PACKAGES ${STANDARD_PACKAGES} ${USER_PACKAGES})
 

cmake/presets/std.cmake

@@ -8,7 +8,7 @@ set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVA
                   USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
                   USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
                   USER-NETCDF USER-OMP USER-PHONON USER-QMMM USER-QTB
-                  USER-QUIP USER-REAXC USER-SMD USER-SMTBQ USER-SPH USER-TALLY
+                  USER-QUIP USER-REAXC USER-SDPD USER-SMD USER-SMTBQ USER-SPH USER-TALLY
                   USER-UEF USER-VTK)
 
 set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MEAM MPIIO MSCG POEMS PYTHON REAX VORONOI

cmake/presets/std_nolib.cmake

@@ -8,7 +8,7 @@ set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVA
                   USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
                   USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
                   USER-NETCDF USER-OMP USER-PHONON USER-QMMM USER-QTB
-                  USER-QUIP USER-REAXC USER-SMD USER-SMTBQ USER-SPH USER-TALLY
+                  USER-QUIP USER-REAXC USER-SDPD USER-SMD USER-SMTBQ USER-SPH USER-TALLY
                   USER-UEF USER-VTK)
 
 set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MEAM MPIIO MSCG POEMS PYTHON REAX VORONOI

cmake/presets/user.cmake

@@ -8,12 +8,12 @@ set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVA
                   USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
                   USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
                   USER-NETCDF USER-OMP USER-PHONON USER-QMMM USER-QTB
-                  USER-QUIP USER-REAXC USER-SMD USER-SMTBQ USER-SPH USER-TALLY
+                  USER-QUIP USER-REAXC USER-SDPD USER-SMD USER-SMTBQ USER-SPH USER-TALLY
                   USER-UEF USER-VTK)
 
 set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MEAM MPIIO MSCG POEMS PYTHON REAX VORONOI
                       USER-ATC USER-AWPMD USER-COLVARS USER-H5MD USER-LB USER-MOLFILE
-                      USER-NETCDF USER-QMMM USER-QUIP USER-SMD USER-VTK)
+                      USER-NETCDF USER-PLUMED USER-QMMM USER-QUIP USER-SMD USER-VTK)
 
 set(ALL_PACKAGES ${STANDARD_PACKAGES} ${USER_PACKAGES})
 

doc/Makefile

@@ -1,7 +1,7 @@
 # Makefile for LAMMPS documentation
 
 SHELL         = /bin/bash
-SHA1          = $(shell echo $USER-$PWD | python utils/sha1sum.py)
+SHA1          = $(shell echo ${USER}-${PWD} | python utils/sha1sum.py)
 BUILDDIR      = /tmp/lammps-docs-$(SHA1)
 RSTDIR        = $(BUILDDIR)/rst
 VENV          = $(BUILDDIR)/docenv
@@ -176,7 +176,6 @@ $(VENV):
 		$(VIRTUALENV) -p $(PYTHON) $(VENV); \
 		. $(VENV)/bin/activate; \
 		pip install Sphinx; \
-		pip install sphinxcontrib-images; \
 		deactivate;\
 	)
 

doc/github-development-workflow.md

@@ -0,0 +1,192 @@
+# Outline of the GitHub Development Workflow
+
+This purpose of this document is to provide a point of reference for the
+core LAMMPS developers and other LAMMPS contributors to understand the
+choices the LAMMPS developers have agreed on. Git and GitHub provide the
+tools, but do not set policies, so it is up to the developers to come to
+an agreement as to how to define and interpret policies. This document
+is likely to change as our experiences and needs change and we try to
+adapt accordingly. Last change 2018-11-15.
+
+## Table of Contents
+
+  * [GitHub Merge Management](#github-merge-management)
+  * [Pull Requests](#pull-requests)
+    * [Pull Request Assignments](#pull-request-assignments)
+    * [Pull Request Reviews](#pull-request-reviews)
+    * [Pull Request Discussions](#pull-request-discussions)
+    * [Checklist for Pull Requests](#checklist-for-pull-requests)
+  * [GitHub Issues](#github-issues)
+  * [Milestones and Release Planning](#milestones-and-release-planning)
+
+## GitHub Merge Management
+
+In the interest of consistency, ONLY ONE of the core LAMMPS developers
+should doing the merging itself.  This is currently
+[@akohlmey](https://github.com/akohlmey) (Axel Kohlmeyer).
+If this assignment needs to be changed, it shall be done right after a
+stable release.  If the currently assigned developer cannot merge outstanding pull 
+requests in a timely manner, or in other extenuating circumstances, 
+other core LAMMPS developers with merge rights can merge pull requests,
+when necessary. 
+
+## Pull Requests
+
+ALL changes to the LAMMPS code and documentation, however trivial, MUST
+be submitted as a pull request to GitHub. All changes to the "master"
+branch must be made exclusively through merging pull requests. The
+"unstable" and "stable" branches, respectively are only to be updated
+upon patch or stable releases with fast-forward merges based on the
+associated tags. Pull requests may also be submitted to (long-running)
+feature branches created by LAMMPS developers inside the LAMMPS project,
+if needed. Those are not subject to the merge and review restrictions
+discussed in this document, though, but get managed as needed on a
+case-by-case basis.
+
+### Pull Request Assignments
+
+Pull requests can be "chaperoned" by one of the LAMMPS core developers.
+This is indicated by who the pull request is assigned to. LAMMPS core
+developers can self-assign or they can decide to assign a pull request
+to a different LAMMPS developer. Being assigned to a pull request means,
+that this pull request may need some work and the assignee is tasked to
+determine what this might be needed or not, and may either implement the
+required changes or ask the submitter of the pull request to implement
+them.  Even though, all LAMMPS developers may have write access to pull
+requests (if enabled by the submitter, which is the default), only the
+submitter or the assignee of a pull request may do so.  During this
+period the `work_in_progress` label shall be applied to the pull
+request.  The assignee gets to decide what happens to the pull request
+next, e.g. whether it should be assigned to a different developer for
+additional checks and changes, or is recommended to be merged.  Removing
+the `work_in_progress` label and assigning the pull request to the
+developer tasked with merging signals that a pull request is ready to be
+merged.
+
+### Pull Request Reviews
+
+People can be assigned to review a pull request in two ways:
+
+  * They can be assigned manually to review a pull request
+    by the submitter or a LAMMPS developer
+  * They can be automatically assigned, because a developers matches
+    a file pattern in the `.github/CODEOWNERS` file, which associates
+    developers with the code they contributed and maintain.
+
+Reviewers are requested to state their appraisal of the proposed changes
+and either approve or request changes. People may unassign themselves
+from review, if they feel not competent about the changes proposed. At
+least one review from a LAMMPS developer with write access is required
+before merging in addition to the automated compilation tests.  The
+feature, that reviews from code owners are "hard" reviews (i.e. they
+must all be approved before merging is allowed), is currently disabled
+and it is in the discretion of the merge maintainer to assess when
+a sufficient degree of approval has been reached.  Reviews may be
+(automatically) dismissed, when the reviewed code has been changed,
+and then approval is required a second time.
+
+### Pull Request Discussions
+
+All discussions about a pull request should be kept as much as possible
+on the pull request discussion page on GitHub, so that other developers
+can later review the entire discussion after the fact and understand the
+rationale behind choices made.  Exceptions to this policy are technical
+discussions, that are centered on tools or policies themselves
+(git, github, c++) rather than on the content of the pull request.
+
+### Checklist for Pull Requests
+
+Here are some items to check:
+  * source and text files should not have CR/LF line endings (use dos2unix to remove)
+  * every new command or style should have documentation. The names of
+  source files (c++ and manual) should follow the name of the style.
+  (example: `src/fix_nve.cpp`, `src/fix_nve.h` for `fix nve` command,
+  implementing the class `FixNVE`, documented in `doc/src/fix_nve.txt`)
+  * all new style names should be lower case, the must be no dashes,
+  blanks, or underscores separating words, only forward slashes.
+  * new style docs should be added to the "overview" files in
+  `doc/src/Commands_*.txt`, `doc/src/{fixes,computes,pairs,bonds,...}.txt`
+  and `doc/src/lammps.book`
+  * check whether manual cleanly translates with `make html` and `make pdf`
+  * check spelling of manual with `make spelling` in doc folder
+  * new source files in packages should be added to `src/.gitignore`
+  * removed or renamed files in packages should be added to `src/Purge.list`
+  * C++ source files should use C++ style include files for accessing
+  C-library APIs, e.g. `#include <cstdlib>` instead of `#include <stdlib.h>`.
+  And they should use angular brackets instead of double quotes. Full list:
+    * assert.h -> cassert
+    * ctype.h -> cctype
+    * errno.h -> cerrno
+    * float.h -> cfloat
+    * limits.h -> climits
+    * math.h -> cmath
+    * omplex.h -> complex
+    * setjmp.h -> csetjmp
+    * signal.h -> csignal
+    * stddef.h -> cstddef
+    * stdint.h -> cstdint
+    * stdio.h -> cstdio
+    * stdlib.h -> cstdlib
+    * string.h -> cstring
+    * time.h -> ctime
+  Do not replace (as they are C++-11): `inttypes.h` and `stdint.h`.
+  * Code should follow the C++-98 standard. C++-11 is only accepted
+  in individual special purpose packages
+  * indentation is two spaces per level
+  * there should be no tabs and no trailing whitespace
+  * header files, especially of new styles, should not include any
+  other headers, except the header with the base class or cstdio.
+  Forward declarations should be used instead when possible.
+  * iostreams should be avoided. LAMMPS uses stdio from the C-library.
+  * use of STL in headers and class definitions should be avoided.
+  * static class members should be avoided at all cost.
+  * anything storing atom IDs should be using `tagint` and not `int`.
+  This can be flagged by the compiler only for pointers and only when
+  compiling LAMMPS with `-DLAMMPS_BIGBIG`.
+  * when including both `lmptype.h` (and using defines or macros from it)
+  and `mpi.h`, `lmptype.h` must be included first.
+  * when pair styles are added, check if settings for flags like
+  `single_enable`, `writedata`, `reinitflag`, `manybody_flag`
+  and others are correctly set and supported.
+
+## GitHub Issues
+
+The GitHub issue tracker is the location where the LAMMPS developers
+and other contributors or LAMMPS users can report issues or bugs with
+the LAMMPS code or request new features to be added. Feature requests
+are usually indicated by a `[Feature Request]` marker in the subject.
+Issues are assigned to a person, if this person is working on this
+feature or working to resolve an issue. Issues that have nobody working
+on them at the moment, have the label `volunteer needed` attached.
+
+When an issue, say `#125` is resolved by a specific pull request,
+the comment for the pull request shall contain the text `closes #125`
+or `fixes #125`, so that the issue is automatically deleted when
+the pull request is merged.
+
+## Milestones and Release Planning
+
+LAMMPS uses a continuous release development model with incremental
+changes, i.e. significant effort is made - including automated pre-merge
+testing - that the code in the branch "master" does not get broken.
+More extensive testing (including regression testing) is performed after
+code is merged to the "master" branch. There are patch releases of
+LAMMPS every 1-3 weeks at a point, when the LAMMPS developers feel, that
+a sufficient amount of changes have happened, and the post-merge testing
+has been successful. These patch releases are marked with a
+`patch_<version date>` tag and the "unstable" branch follows only these
+versions (and thus is always supposed to be of production quality,
+unlike "master", which may be temporary broken, in the case of larger
+change sets or unexpected incompatibilities or side effects.
+
+About 3-4 times each year, there are going to be "stable" releases
+of LAMMPS.  These have seen additional, manual testing and review of
+results from testing with instrumented code and static code analysis.
+Also, in the last 2-3 patch releases before a stable release are
+"release candidate" versions which only contain bugfixes and
+documentation updates.  For release planning and the information of
+code contributors, issues and pull requests being actively worked on
+are assigned a "milestone", which corresponds to the next stable
+release or the stable release after that, with a tentative release
+date.
+

doc/src/Build_basics.txt

@@ -137,9 +137,9 @@ simply loading the appropriate module before building LAMMPS.
 -D CMAKE_C_COMPILER=name              # name of C compiler
 -D CMAKE_Fortran_COMPILER=name        # name of Fortran compiler :pre
 
--D CMAKE_CXX_FlAGS=string             # flags to use with C++ compiler
--D CMAKE_C_FlAGS=string               # flags to use with C compiler
--D CMAKE_Fortran_FlAGS=string         # flags to use with Fortran compiler :pre
+-D CMAKE_CXX_FLAGS=string             # flags to use with C++ compiler
+-D CMAKE_C_FLAGS=string               # flags to use with C compiler
+-D CMAKE_Fortran_FLAGS=string         # flags to use with Fortran compiler :pre
 
 By default CMake will use a compiler it finds and it will add
 optimization flags appropriate to that compiler and any "accelerator
@@ -292,7 +292,7 @@ This will create a lammps/doc/html dir with the HTML doc pages so that
 you can browse them locally on your system.  Type "make" from the
 lammps/doc dir to see other options.
 
-NOTE: You can also download a tarball of the documention for the
+NOTE: 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.
 

doc/src/Build_cmake.txt

@@ -44,7 +44,7 @@ LAMMPS or need to re-compile LAMMPS repeatedly, installation of the
 ccache (= Compiler Cache) software may speed up compilation even more.
 
 After compilation, you can optionally copy the LAMMPS executable and
-library into your system folders (by default under /usr/local) with:
+library into your system folders (by default under $HOME/.local) with:
 
 make install    # optional, copy LAMMPS executable & library elsewhere :pre
 

doc/src/Build_extras.txt

@@ -45,6 +45,7 @@ This is the list of packages that may require additional steps.
 "USER-INTEL"_#user-intel,
 "USER-MOLFILE"_#user-molfile,
 "USER-NETCDF"_#user-netcdf,
+"USER-PLUMED"_#user-plumed,
 "USER-OMP"_#user-omp,
 "USER-QMMM"_#user-qmmm,
 "USER-QUIP"_#user-quip,
@@ -86,22 +87,30 @@ which GPU hardware to build for.
                       # value = double or mixed (default) or single
 -D OCL_TUNE=value     # hardware choice for GPU_API=opencl
                       # generic (default) or intel (Intel CPU) or fermi, kepler, cypress (NVIDIA)
--D GPU_ARCH=value     # hardware choice for GPU_API=cuda
+-D GPU_ARCH=value     # primary GPU hardware choice for GPU_API=cuda
                       # value = sm_XX, see below
                       # default is Cuda-compiler dependent, but typically sm_20
--D CUDPP_OPT=value    # optimization setting for GPU_API=cudea
+-D CUDPP_OPT=value    # optimization setting for GPU_API=cuda
                       # enables CUDA Performance Primitives Optimizations
                       # yes (default) or no :pre
 
 GPU_ARCH settings for different GPU hardware is as follows:
 
-sm_20 for Fermi (C2050/C2070, deprecated as of CUDA 8.0) or GeForce GTX 580 or similar
-sm_30 for Kepler (K10)
-sm_35 for Kepler (K40) or GeForce GTX Titan or similar
-sm_37 for Kepler (dual K80)
-sm_50 for Maxwell
-sm_60 for Pascal (P100)
-sm_70 for Volta :ul
+sm_20 or sm_21 for Fermi (supported by CUDA 3.2 until CUDA 7.5)
+sm_30 or sm_35 or sm_37 for Kepler (supported since CUDA 5)
+sm_50 or sm_52 for Maxwell (supported since CUDA 6)
+sm_60 or sm_61 for Pascal (supported since CUDA 8)
+sm_70 for Volta (supported since CUDA 9)
+sm_75 for Turing (supported since CUDA 10) :ul
+
+A more detailed list can be found, for example,
+at "Wikipedia's CUDA article"_https://en.wikipedia.org/wiki/CUDA#GPUs_supported
+
+CMake can detect which version of the CUDA toolkit is used and thus can
+include support for [all] major GPU architectures supported by this toolkit.
+Thus the GPU_ARCH setting is merely an optimization, to have code for
+the preferred GPU architecture directly included rather than having to wait
+for the JIT compiler of the CUDA driver to translate it.
 
 [Traditional make]:
 
@@ -136,6 +145,11 @@ CUDA_ARCH = sm_XX, what GPU hardware you have, same as CMake GPU_ARCH above
 CUDA_PRECISION = precision (double, mixed, single)
 EXTRAMAKE = which Makefile.lammps.* file to copy to Makefile.lammps :ul
 
+The file Makefile.linux_multi is set up to include support for multiple
+GPU architectures as supported by the CUDA toolkit in use. This is done
+through using the "--gencode " flag, which can be used multiple times and
+thus support all GPU architectures supported by your CUDA compiler.
+
 If the library build is successful, 3 files should be created:
 lib/gpu/libgpu.a, lib/gpu/nvc_get_devices, and
 lib/gpu/Makefile.lammps.  The latter has settings that enable LAMMPS
@@ -149,6 +163,7 @@ re-build LAMMPS.  This is because the compilation of files in the GPU
 package uses the library settings from the lib/gpu/Makefile.machine
 used to build the GPU library.
 
+
 :line
 
 KIM package :h4,link(kim)
@@ -712,6 +727,114 @@ a corresponding Makefile.lammps.machine file.
 
 :line
 
+USER-PLUMED package :h4,link(user-plumed)
+
+Before building LAMMPS with this package, you must first build PLUMED.
+PLUMED can be built as part of the LAMMPS build or installed separately
+from LAMMPS using the generic "plumed installation instructions"_plumedinstall.
+:link(plumedinstall,http://plumed.github.io/doc-master/user-doc/html/_installation.html)
+
+PLUMED can be linked into MD codes in three different modes: static,
+shared, and runtime.  With the "static" mode, all the code that PLUMED
+requires is linked statically into LAMMPS. LAMMPS is then fully
+independent from the PLUMED installation, but you have to rebuild/relink
+it in order to update the PLUMED code inside it.  With the "shared"
+linkage mode, LAMMPS is linked to a shared library that contains the
+PLUMED code.  This library should preferably be installed in a globally
+accessible location. When PLUMED is linked in this way the same library
+can be used by multiple MD packages.  Furthermore, the PLUMED library
+LAMMPS uses can be updated without the need for a recompile of LAMMPS
+for as long as the shared PLUMED library is ABI-compatible.
+
+The third linkage mode is "runtime" which allows the user to specify
+which PLUMED kernel should be used at runtime by using the PLUMED_KERNEL
+environment variable. This variable should point to the location of the
+libplumedKernel.so dynamical shared object, which is then loaded at
+runtime. This mode of linking is particularly convenient for doing
+PLUMED development and comparing multiple PLUMED versions as these sorts
+of comparisons can be done without recompiling the hosting MD code. All
+three linkage modes are supported by LAMMPS on selected operating
+systems (e.g. Linux) and using either CMake or traditional make
+build. The "static" mode should be the most portable, while the
+"runtime" mode support in LAMMPS makes the most assumptions about
+operating system and compiler environment. If one mode does not work,
+try a different one, switch to a different build system, consider a
+global PLUMED installation or consider downloading PLUMED during the
+LAMMPS build.
+
+[CMake build]:
+
+When the "-D PKG_USER-PLUMED" flag is included in the cmake command you
+must ensure that GSL is installed in locations that are specified in
+your environment.  There are then two additional commands that control
+the manner in which PLUMED is obtained and linked into LAMMPS.
+
+-D DOWNLOAD_PLUMED=value   # download PLUMED for build, value = no (default) or yes
+-D PLUMED_MODE=value       # Linkage mode for PLUMED, value = static (default), shared, or runtime :pre
+
+If DOWNLOAD_PLUMED is set to "yes", the PLUMED library will be
+downloaded (the version of PLUMED that will be downloaded is hard-coded
+to a vetted version of PLUMED, usually a recent stable release version)
+and built inside the CMake build directory.  If DOWNLOAD_PLUMED is set
+to "no" (the default), CMake will try to detect and link to an installed
+version of PLUMED.  For this to work, the PLUMED library has to be
+installed into a location where the pkg-config tool can find it or the
+PKG_CONFIG_PATH environment variable has to be set up accordingly.
+PLUMED should be installed in such a location if you compile it using
+the default make; make install commands.
+
+The PLUMED_MODE setting determines the linkage mode for the PLUMED
+library.  The allowed values for this flag are "static" (default),
+"shared", or "runtime".  For a discussion of PLUMED linkage modes,
+please see above.  When DOWNLOAD_PLUMED is enabled the static linkage
+mode is recommended.
+
+[Traditional make]:
+
+PLUMED needs to be installed before the USER-PLUMED package is installed
+so that LAMMPS can find the right settings when compiling and linking
+the LAMMPS executable.  You can either download and build PLUMED inside
+the LAMMPS plumed library folder or use a previously installed PLUMED
+library and point LAMMPS to its location. You also have to choose the
+linkage mode: "static" (default), "shared" or "runtime".  For a
+discussion of PLUMED linkage modes, please see above.
+
+Download/compilation/configuration of the plumed library can be done
+from the src folder through the following make args:
+
+make lib-plumed                         # print help message
+make lib-plumed args="-b"               # download and build PLUMED in lib/plumed/plumed2
+make lib-plumed args="-p $HOME/.local"  # use existing PLUMED installation in $HOME/.local
+make lib-plumed args="-p /usr/local -m shared"  # use existing PLUMED installation in
+                                                # /usr/local and use shared linkage mode
+:pre
+
+Note that 2 symbolic (soft) links, "includelink" and "liblink" are
+created in lib/plumed that point to the location of the PLUMED build to
+use. A new file lib/plumed/Makefile.lammps is also created with settings
+suitable for LAMMPS to compile and link PLUMED using the desired linkage
+mode. After this step is completed, you can install the USER-PLUMED
+package and compile LAMMPS in the usual manner:
+
+make yes-user-plumed
+make machine :pre
+
+Once this compilation completes you should be able to run LAMMPS in the
+usual way.  For shared linkage mode, libplumed.so must be found by the
+LAMMPS executable, which on many operating systems means, you have to
+set the LD_LIBRARY_PATH environment variable accordingly.
+
+Support for the different linkage modes in LAMMPS varies for different
+operating systems, using the static linkage is expected to be the most
+portable, and thus set to be the default.
+
+If you want to change the linkage mode, you have to re-run "make
+lib-plumed" with the desired settings [and] do a re-install if the
+USER-PLUMED package with "make yes-user-plumed" to update the required
+makefile settings with the changes in the lib/plumed folder.
+
+:line
+
 USER-H5MD package :h4,link(user-h5md)
 
 To build with this package you must have the HDF5 software package

doc/src/Build_package.txt

@@ -56,6 +56,7 @@ packages:
 "USER-INTEL"_Build_extras.html#user-intel,
 "USER-MOLFILE"_Build_extras.html#user-molfile,
 "USER-NETCDF"_Build_extras.html#user-netcdf,
+"USER-PLUMED"_Build_extras.html#user-plumed,
 "USER-OMP"_Build_extras.html#user-omp,
 "USER-QMMM"_Build_extras.html#user-qmmm,
 "USER-QUIP"_Build_extras.html#user-quip,

doc/src/Build_settings.txt

@@ -139,7 +139,7 @@ adequate.
 [Makefile.machine setting]:
 
 LMP_INC = -DLAMMPS_SMALLBIG    # or -DLAMMPS_BIGBIG or -DLAMMPS_SMALLSMALL :pre
-                               # default is LAMMMPS_SMALLBIG if not specified
+                               # default is LAMMPS_SMALLBIG if not specified
 [CMake and make info]:
 
 The default "smallbig" setting allows for simulations with:

doc/src/Build_windows.txt

@@ -66,7 +66,7 @@ In case of problems, you are recommended to contact somebody with
 experience in using cygwin.  If you do come across portability problems
 requiring changes to the LAMMPS source code, or figure out corrections
 yourself, please report them on the lammps-users mailing list, or file
-them as an issue or pull request on the LAMMPS github project.
+them as an issue or pull request on the LAMMPS GitHub project.
 
 
 Using a cross-compiler :h4,link(cross)

doc/src/Commands.txt

@@ -42,7 +42,7 @@ END_RST -->
 "Input script structure"_Commands_structure.html
 "Commands by category"_Commands_category.html :all(b)
 
-"All commands"_Commands_all.html 
+"General commands"_Commands_all.html
 "Fix commands"_Commands_fix.html
 "Compute commands"_Commands_compute.html
 "Pair commands"_Commands_pair.html

doc/src/Commands_all.txt

@@ -7,7 +7,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 
 :line
 
-"All commands"_Commands_all.html,
+"General commands"_Commands_all.html,
 "Fix styles"_Commands_fix.html,
 "Compute styles"_Commands_compute.html,
 "Pair styles"_Commands_pair.html,
@@ -17,9 +17,9 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 "Improper styles"_Commands_bond.html#improper,
 "KSpace styles"_Commands_kspace.html :tb(c=3,ea=c)
 
-All commands :h3
+General commands :h3
 
-An alphabetic list of all LAMMPS commands.
+An alphabetic list of all general LAMMPS commands.
 
 "angle_coeff"_angle_coeff.html,
 "angle_style"_angle_style.html,
@@ -59,6 +59,7 @@ An alphabetic list of all LAMMPS commands.
 "fix_modify"_fix_modify.html,
 "group"_group.html,
 "group2ndx"_group2ndx.html,
+"hyper"_hyper.html,
 "if"_if.html,
 "info"_info.html,
 "improper_coeff"_improper_coeff.html,

doc/src/Commands_bond.txt

@@ -5,7 +5,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 :link(ld,Manual.html)
 :link(lc,Commands_all.html)
 
-"All commands"_Commands_all.html,
+"General commands"_Commands_all.html,
 "Fix styles"_Commands_fix.html,
 "Compute styles"_Commands_compute.html,
 "Pair styles"_Commands_pair.html,

doc/src/Commands_category.txt

@@ -10,10 +10,9 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 Commands by category :h3
 
 This page lists most of the LAMMPS commands, grouped by category.  The
-"Commands all"_Commands_all.html doc page lists all commands
-alphabetically.  It also includes long lists of style options for
-entries that appear in the following categories as a single command
-(fix, compute, pair, etc).
+"General commands"_Commands_all.html doc page lists all general commands
+alphabetically.  Style options for entries like fix, compute, pair etc.
+have their own pages where they are listed alphabetically.
 
 Initialization:
 

doc/src/Commands_compute.txt

@@ -7,7 +7,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 
 :line
 
-"All commands"_Commands_all.html,
+"General commands"_Commands_all.html,
 "Fix styles"_Commands_fix.html,
 "Compute styles"_Commands_compute.html,
 "Pair styles"_Commands_pair.html,

doc/src/Commands_fix.txt

@@ -7,7 +7,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 
 :line
 
-"All commands"_Commands_all.html,
+"General commands"_Commands_all.html,
 "Fix styles"_Commands_fix.html,
 "Compute styles"_Commands_compute.html,
 "Pair styles"_Commands_pair.html,
@@ -78,6 +78,8 @@ OPT.
 "grem"_fix_grem.html,
 "halt"_fix_halt.html,
 "heat"_fix_heat.html,
+"hyper/global"_fix_hyper_global.html,
+"hyper/local"_fix_hyper_local.html,
 "imd"_fix_imd.html,
 "indent"_fix_indent.html,
 "ipi"_fix_ipi.html,
@@ -94,6 +96,7 @@ OPT.
 "lineforce"_fix_lineforce.html,
 "manifoldforce"_fix_manifoldforce.html,
 "meso"_fix_meso.html,
+"meso/move"_fix_meso_move.html,
 "meso/stationary"_fix_meso_stationary.html,
 "momentum (k)"_fix_momentum.html,
 "move"_fix_move.html,
@@ -107,7 +110,7 @@ OPT.
 "nph/asphere (o)"_fix_nph_asphere.html,
 "nph/body"_fix_nph_body.html,
 "nph/eff"_fix_nh_eff.html,
-"nph/sphere (ko)"_fix_nph_sphere.html,
+"nph/sphere (o)"_fix_nph_sphere.html,
 "nphug (o)"_fix_nphug.html,
 "npt (iko)"_fix_nh.html,
 "npt/asphere (o)"_fix_npt_asphere.html,
@@ -127,7 +130,7 @@ OPT.
 "nve/line"_fix_nve_line.html,
 "nve/manifold/rattle"_fix_nve_manifold_rattle.html,
 "nve/noforce"_fix_nve_noforce.html,
-"nve/sphere (o)"_fix_nve_sphere.html,
+"nve/sphere (ko)"_fix_nve_sphere.html,
 "nve/spin"_fix_nve_spin.html,
 "nve/tri"_fix_nve_tri.html,
 "nvk"_fix_nvk.html,
@@ -146,6 +149,7 @@ OPT.
 "phonon"_fix_phonon.html,
 "pimd"_fix_pimd.html,
 "planeforce"_fix_planeforce.html,
+"plumed"_fix_plumed.html,
 "poems"_fix_poems.html,
 "pour"_fix_pour.html,
 "precession/spin"_fix_precession_spin.html,
@@ -172,6 +176,7 @@ OPT.
 "restrain"_fix_restrain.html,
 "rhok"_fix_rhok.html,
 "rigid (o)"_fix_rigid.html,
+"rigid/meso"_fix_rigid_meso.html,
 "rigid/nph (o)"_fix_rigid.html,
 "rigid/nph/small"_fix_rigid.html,
 "rigid/npt (o)"_fix_rigid.html,
@@ -230,4 +235,4 @@ OPT.
 "wall/reflect (k)"_fix_wall_reflect.html,
 "wall/region"_fix_wall_region.html,
 "wall/region/ees"_fix_wall_ees.html,
-"wall/srd"_fix_wall_srd.html :tb(c=8,ea=c)
+"wall/srd"_fix_wall_srd.html :tb(c=6,ea=c)

doc/src/Commands_kspace.txt

@@ -7,7 +7,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 
 :line
 
-"All commands"_Commands_all.html,
+"General commands"_Commands_all.html,
 "Fix styles"_Commands_fix.html,
 "Compute styles"_Commands_compute.html,
 "Pair styles"_Commands_pair.html,

doc/src/Commands_pair.txt

@@ -7,7 +7,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 
 :line
 
-"All commands"_Commands_all.html,
+"General commands"_Commands_all.html,
 "Fix styles"_Commands_fix.html,
 "Compute styles"_Commands_compute.html,
 "Pair styles"_Commands_pair.html,
@@ -198,6 +198,7 @@ OPT.
 "reax/c (ko)"_pair_reaxc.html,
 "rebo (io)"_pair_airebo.html,
 "resquared (go)"_pair_resquared.html,
+"sdpd/taitwater/isothermal"_pair_sdpd_taitwater_isothermal.html,
 "smd/hertz"_pair_smd_hertz.html,
 "smd/tlsph"_pair_smd_tlsph.html,
 "smd/tri_surface"_pair_smd_triangulated_surface.html,

doc/src/Commands_parse.txt

@@ -91,7 +91,7 @@ See the "variable"_variable.html command for more details of how
 strings are assigned to variables and evaluated, and how they can be
 used in input script commands.
 
-(4) The line is broken into "words" separated by whitespace (tabs,
+(4) The line is broken into "words" separated by white-space (tabs,
 spaces).  Note that words can thus contain letters, digits,
 underscores, or punctuation characters.
 

doc/src/Developer/.gitignore

@@ -0,0 +1,3 @@
+/developer.aux
+/developer.log
+/developer.toc

doc/src/Errors_messages.txt

@@ -279,12 +279,6 @@ multibody joint).  The bodies you have defined exceed this limit. :dd
 This is an internal LAMMPS error.  Please report it to the
 developers. :dd
 
-{Atom sorting has bin size = 0.0} :dt
-
-The neighbor cutoff is being used as the bin size, but it is zero.
-Thus you must explicitly list a bin size in the atom_modify sort
-command or turn off sorting. :dd
-
 {Atom style hybrid cannot have hybrid as an argument} :dt
 
 Self-explanatory. :dd
@@ -421,9 +415,9 @@ This is an internal error.  It should normally not occur. :dd
 
 This is an internal error.  It should normally not occur. :dd
 
-{Bad real space Coulomb cutoff in fix tune/kspace} :dt
+{Bad real space Coulombic cutoff in fix tune/kspace} :dt
 
-Fix tune/kspace tried to find the optimal real space Coulomb cutoff using
+Fix tune/kspace tried to find the optimal real space Coulombic cutoff using
 the Newton-Rhaphson method, but found a non-positive or NaN cutoff :dd
 
 {Balance command before simulation box is defined} :dt
@@ -460,7 +454,7 @@ compute. :dd
 
 {Big particle in fix srd cannot be point particle} :dt
 
-Big particles must be extended spheriods or ellipsoids. :dd
+Big particles must be extended spheroids or ellipsoids. :dd
 
 {Bigint setting in lmptype.h is invalid} :dt
 
@@ -780,7 +774,7 @@ Cannot use tilt factors unless the simulation box is non-orthogonal. :dd
 
 Self-explanatory. :dd
 
-{Cannot change box z boundary to nonperiodic for a 2d simulation} :dt
+{Cannot change box z boundary to non-periodic for a 2d simulation} :dt
 
 Self-explanatory. :dd
 
@@ -1288,7 +1282,7 @@ are defined. :dd
 You cannot reset the timestep when a fix that keeps track of elapsed
 time is in place. :dd
 
-{Cannot run 2d simulation with nonperiodic Z dimension} :dt
+{Cannot run 2d simulation with non-periodic Z dimension} :dt
 
 Use the boundary command to make the z dimension periodic in order to
 run a 2d simulation. :dd
@@ -2116,29 +2110,29 @@ Self-explanatory. :dd
 Fix setforce cannot be used in this manner.  Use fix addforce
 instead. :dd
 
-{Cannot use nonperiodic boundares with fix ttm} :dt
+{Cannot use non-periodic boundares with fix ttm} :dt
 
 This fix requires a fully periodic simulation box. :dd
 
-{Cannot use nonperiodic boundaries with Ewald} :dt
+{Cannot use non-periodic boundaries with Ewald} :dt
 
 For kspace style ewald, all 3 dimensions must have periodic boundaries
 unless you use the kspace_modify command to define a 2d slab with a
 non-periodic z dimension. :dd
 
-{Cannot use nonperiodic boundaries with EwaldDisp} :dt
+{Cannot use non-periodic boundaries with EwaldDisp} :dt
 
 For kspace style ewald/disp, all 3 dimensions must have periodic
 boundaries unless you use the kspace_modify command to define a 2d
 slab with a non-periodic z dimension. :dd
 
-{Cannot use nonperiodic boundaries with PPPM} :dt
+{Cannot use non-periodic boundaries with PPPM} :dt
 
 For kspace style pppm, all 3 dimensions must have periodic boundaries
 unless you use the kspace_modify command to define a 2d slab with a
 non-periodic z dimension. :dd
 
-{Cannot use nonperiodic boundaries with PPPMDisp} :dt
+{Cannot use non-periodic boundaries with PPPMDisp} :dt
 
 For kspace style pppm/disp, all 3 dimensions must have periodic
 boundaries unless you use the kspace_modify command to define a 2d
@@ -3351,21 +3345,21 @@ probably due to errors in the Python code. :dd
 The default minimum order is 2.  This can be reset by the
 kspace_modify minorder command. :dd
 
-{Coulomb cut not supported in pair_style buck/long/coul/coul} :dt
+{Coulombic cutoff not supported in pair_style buck/long/coul/coul} :dt
 
 Must use long-range Coulombic interactions. :dd
 
-{Coulomb cut not supported in pair_style lj/long/coul/long} :dt
+{Coulombic cutoff not supported in pair_style lj/long/coul/long} :dt
 
 Must use long-range Coulombic interactions. :dd
 
-{Coulomb cut not supported in pair_style lj/long/tip4p/long} :dt
+{Coulombic cutoff not supported in pair_style lj/long/tip4p/long} :dt
 
 Must use long-range Coulombic interactions. :dd
 
-{Coulomb cutoffs of pair hybrid sub-styles do not match} :dt
+{Coulombic cutoffs of pair hybrid sub-styles do not match} :dt
 
-If using a Kspace solver, all Coulomb cutoffs of long pair styles must
+If using a Kspace solver, all Coulombic cutoffs of long pair styles must
 be the same. :dd
 
 {Coulombic cut not supported in pair_style lj/long/dipole/long} :dt
@@ -5938,9 +5932,9 @@ map command will force an atom map to be created. :dd
 
 Self-explanatory. :dd
 
-{Input line quote not followed by whitespace} :dt
+{Input line quote not followed by white-space} :dt
 
-An end quote must be followed by whitespace. :dd
+An end quote must be followed by white-space. :dd
 
 {Insertion region extends outside simulation box} :dt
 
@@ -7014,7 +7008,7 @@ The kspace accuracy designated in the input must be greater than zero. :dd
 
 {KSpace accuracy too large to estimate G vector} :dt
 
-Reduce the accuracy request or specify gwald explicitly
+Reduce the accuracy request or specify gewald explicitly
 via the kspace_modify command. :dd
 
 {KSpace accuracy too low} :dt
@@ -8014,7 +8008,7 @@ Self-explanatory. :dd
 
 {Package command after simulation box is defined} :dt
 
-The package command cannot be used afer a read_data, read_restart, or
+The package command cannot be used after a read_data, read_restart, or
 create_box command. :dd
 
 {Package gpu command without GPU package installed} :dt
@@ -9198,7 +9192,7 @@ creates one large file for all processors. :dd
 {Restart file byte ordering is not recognized} :dt
 
 The file does not appear to be a LAMMPS restart file since it doesn't
-contain a recognized byte-orderomg flag at the beginning. :dd
+contain a recognized byte-ordering flag at the beginning. :dd
 
 {Restart file byte ordering is swapped} :dt
 

doc/src/Errors_warnings.txt

@@ -757,7 +757,7 @@ Self-explanatory. :dd
 
 This may indicate the shell command did not operate as expected. :dd
 
-{Should not allow rigid bodies to bounce off relecting walls} :dt
+{Should not allow rigid bodies to bounce off reflecting walls} :dt
 
 LAMMPS allows this, but their dynamics are not computed correctly. :dd
 
@@ -850,10 +850,10 @@ Most FENE models need this setting for the special_bonds command. :dd
 
 Most FENE models need this setting for the special_bonds command. :dd
 
-{Using a manybody potential with bonds/angles/dihedrals and special_bond exclusions} :dt
+{Using a many-body potential with bonds/angles/dihedrals and special_bond exclusions} :dt
 
 This is likely not what you want to do.  The exclusion settings will
-eliminate neighbors in the neighbor list, which the manybody potential
+eliminate neighbors in the neighbor list, which the many-body potential
 needs to calculated its terms correctly. :dd
 
 {Using compute temp/deform with inconsistent fix deform remap option} :dt

doc/src/Examples.txt

@@ -78,7 +78,7 @@ micelle:  self-assembly of small lipid-like molecules into 2d bilayers
 min:      energy minimization of 2d LJ melt
 mscg:     parameterize a multi-scale coarse-graining (MSCG) model
 msst:     MSST shock dynamics
-nb3b:     use of nonbonded 3-body harmonic pair style
+nb3b:     use of non-bonded 3-body harmonic pair style
 neb:      nudged elastic band (NEB) calculation for barrier finding
 nemd:     non-equilibrium MD of 2d sheared system
 obstacle: flow around two voids in a 2d channel

doc/src/Howto.txt

@@ -45,7 +45,7 @@ General howto :h3
 <!-- RST
 
 .. toctree::
-   :name: general
+   :name: general_howto
    :maxdepth: 1
 
    Howto_restart

doc/src/Howto_barostat.txt

@@ -19,7 +19,7 @@ barostat attempts to equilibrate the system to the requested T and/or
 P.
 
 Barostatting in LAMMPS is performed by "fixes"_fix.html.  Two
-barosttating methods are currently available: Nose-Hoover (npt and
+barostatting methods are currently available: Nose-Hoover (npt and
 nph) and Berendsen:
 
 "fix npt"_fix_nh.html

doc/src/Howto_chunk.txt

@@ -22,8 +22,8 @@ commands, to calculate various properties of a system:
 "fix ave/chunk"_fix_ave_chunk.html
 any of the "compute */chunk"_compute.html commands :ul
 
-Here, each of the 4 kinds of chunk-related commands is briefly
-overviewed.  Then some examples are given of how to compute different
+Here a brief overview for each of the 4 kinds of chunk-related commands
+is provided.  Then some examples are given of how to compute different
 properties with chunk commands.
 
 Compute chunk/atom command: :h4

doc/src/Howto_client_server.txt

@@ -64,7 +64,7 @@ client or server.
 "server mc"_server_mc.html = LAMMPS is a server for computing a Monte Carlo energy :ul
 
 The server doc files give details of the message protocols
-for data that is exchanged bewteen the client and server.
+for data that is exchanged between the client and server.
 
 These example directories illustrate how to use LAMMPS as either a
 client or server code:
@@ -87,7 +87,7 @@ DFT forces, thru a Python wrapper script on VASP.
 Here is how to launch a client and server code together for any of the
 4 modes of message exchange that the "message"_message.html command
 and the CSlib support.  Here LAMMPS is used as both the client and
-server code.  Another code could be subsitituted for either.
+server code.  Another code could be substituted for either.
 
 The examples below show launching both codes from the same window (or
 batch script), using the "&" character to launch the first code in the

doc/src/Howto_coreshell.txt

@@ -19,7 +19,7 @@ polarizable"_Howto_polarizable.html doc page for a discussion of all
 the polarizable models available in LAMMPS.
 
 Technically, shells are attached to the cores by a spring force f =
-k*r where k is a parametrized spring constant and r is the distance
+k*r where k is a parameterized spring constant and r is the distance
 between the core and the shell. The charges of the core and the shell
 add up to the ion charge, thus q(ion) = q(core) + q(shell). This
 setup introduces the ion polarizability (alpha) given by
@@ -111,7 +111,7 @@ the core and shell particles corresponds to the polarization,
 hereby an instantaneous relaxation of the shells is approximated
 and a fast core/shell spring frequency ensures a nearly constant
 internal kinetic energy during the simulation.
-Thermostats can alter this polarization behaviour, by scaling the
+Thermostats can alter this polarization behavior, by scaling the
 internal kinetic energy, meaning the shell will not react freely to
 its electrostatic environment.
 Therefore it is typically desirable to decouple the relative motion of
@@ -165,7 +165,7 @@ fix_modify press_bar temp CSequ press thermo_press_lmp  # pressure modification
 If "compute temp/cs"_compute_temp_cs.html is used, the decoupled
 relative motion of the core and the shell should in theory be
 stable.  However numerical fluctuation can introduce a small
-momentum to the system, which is noticable over long trajectories.
+momentum to the system, which is noticeable over long trajectories.
 Therefore it is recommendable to use the "fix
 momentum"_fix_momentum.html command in combination with "compute
 temp/cs"_compute_temp_cs.html when equilibrating the system to

doc/src/Howto_dispersion.txt

@@ -74,7 +74,7 @@ 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
-parameters from the outut, and specify these parameters using the
+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).
 

doc/src/Howto_drude.txt

@@ -17,7 +17,7 @@ for a discussion of all the polarizable models available in LAMMPS.
 The Drude model has a number of features aimed at its use in
 molecular systems ("Lamoureux and Roux"_#howto-Lamoureux):
 
-Thermostating of the additional degrees of freedom associated with the
+Thermostatting of the additional degrees of freedom associated with the
 induced dipoles at very low temperature, in terms of the reduced
 coordinates of the Drude particles with respect to their cores. This
 makes the trajectory close to that of relaxed induced dipoles. :ulb,l

doc/src/Howto_drude2.txt

@@ -82,7 +82,7 @@ decouple the degrees of freedom associated with the Drude oscillators
 from those of the normal atoms. Thermalizing the Drude dipoles at
 temperatures comparable to the rest of the simulation leads to several
 problems (kinetic energy transfer, very short timestep, etc.), which
-can be remediate by the "cold Drude" technique ("Lamoureux and
+can be remedied by the "cold Drude" technique ("Lamoureux and
 Roux"_#Lamoureux2).
 
 Two closely related models are used to represent polarization through
@@ -213,7 +213,7 @@ of mass of the DC-DP pairs, with relaxation time 100 and with random
 seed 12345.  This fix applies also a Langevin thermostat at temperature
 1. to the relative motion of the DPs around their DCs, with relaxation
 time 20 and random seed 13977.  Only the DCs and non-polarizable
-atoms need to be in this fix's group.  LAMMPS will thermostate the DPs
+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:
 
@@ -360,7 +360,7 @@ fix NPH all nph iso 1. 1. 500 :pre
 It is also possible to use a Nose-Hoover instead of a Langevin
 thermostat.  This requires to use "{fix
 drude/transform}"_fix_drude_transform.html just before and after the
-time intergation fixes.  The {fix drude/transform/direct} converts the
+time integration fixes.  The {fix drude/transform/direct} converts the
 atomic masses, positions, velocities and forces into a reduced
 representation, where the DCs transform into the centers of mass of
 the DC-DP pairs and the DPs transform into their relative position
@@ -396,7 +396,7 @@ 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
-instructions for thermostating and barostating will look like
+instructions for thermostatting and barostatting will look like
 
 compute TATOMS ATOMS temp
 fix DIRECT all drude/transform/direct

doc/src/Howto_elastic.txt

@@ -30,7 +30,7 @@ examples/elastic directory described on the "Examples"_Examples.html
 doc page.
 
 Calculating elastic constants at finite temperature is more
-challenging, because it is necessary to run a simulation that perfoms
+challenging, because it is necessary to run a simulation that performs
 time averages of differential properties. One way to do this is to
 measure the change in average stress tensor in an NVT simulations when
 the cell volume undergoes a finite deformation. In order to balance

doc/src/Howto_github.txt

@@ -96,7 +96,7 @@ machine to a directory with the name you chose. If none is given, it will
 default to "lammps". Typical names are "mylammps" or something similar.
 
 You can use this local clone to make changes and
-test them without interfering with the repository on Github.
+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:
@@ -150,7 +150,7 @@ After the commit, the changes can be pushed to the same branch on GitHub:
 $ git push :pre
 
 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,
+not configured anything. If your local branch is not present on GitHub yet,
 it will ask you to add it by running
 
   $ git push --set-upstream origin github-tutorial-update :pre
@@ -254,20 +254,53 @@ them, or if a developer has requested that something needs to be changed
 before the feature can be accepted into the official LAMMPS version.
 After each push, the automated checks are run again.
 
+[Labels]
+
+LAMMPS developers may add labels to your pull request to assign it to
+categories (mostly for bookkeeping purposes), but a few of them are
+important: needs_work, work_in_progress, test-for-regression, and
+full-regression-test. The first two indicate, that your pull request
+is not considered to be complete. With "needs_work" the burden is on
+exclusively on you; while "work_in_progress" can also mean, that a
+LAMMPS developer may want to add changes. Please watch the comments
+to the pull requests. The two "test" labels are used to trigger
+extended tests before the code is merged. This is sometimes done by
+LAMMPS developers, if they suspect that there may be some subtle
+side effects from your changes. It is not done by default, because
+those tests are very time consuming.
+
+[Reviews]
+
+As of Summer 2018, a pull request needs at least 1 approving review
+from a LAMMPS developer with write access to the repository.
+In case your changes touch code that certain developers are associated
+with, they are auto-requested by the GitHub software.  Those associations
+are set in the file
+".github/CODEOWNERS"_https://github.com/lammps/lammps/blob/master/.github/CODEOWNERS
+Thus if you want to be automatically notified to review when anybody
+changes files or packages, that you have contributed to LAMMPS, you can
+add suitable patterns to that file, or a LAMMPS developer may add you.
+
+Otherwise, you can also manually request reviews from specific developers,
+or LAMMPS developers - in their assessment of your pull request - may
+determine who else should be reviewing your contribution and add that person.
+Through reviews, LAMMPS developers also may request specific changes from you.
+If those are not addressed, your pull requests cannot be merged.
+
 [Assignees]
 
-There is an assignee label for pull requests. If the request has not
+There is an assignee property for pull requests. If the request has not
 been reviewed by any developer yet, it is not assigned to anyone. After
 revision, a developer can choose to assign it to either a) you, b) a
-LAMMPS developer (including him/herself) or c) Steve Plimpton (sjplimp).
+LAMMPS developer (including him/herself) or c) Axel Kohlmeyer (akohlmey).
 
 Case a) happens if changes are required on your part :ulb,l
 Case b) means that at the moment, it is being tested and reviewed by a
 LAMMPS developer with the expectation that some changes would be required.
 After the review, the developer can choose to implement changes directly
 or suggest them to you. :l
-Case c) means that the pull request has been assigned to the lead
-developer Steve Plimpton and means it is considered ready for merging. :ule,l
+Case c) means that the pull request has been assigned to the developer
+overseeing the merging of pull requests into the master branch. :ule,l
 
 In this case, Axel assigned the tutorial to Steve:
 
@@ -336,7 +369,7 @@ commit and push again:
  $ git commit -m "Merged Axel's suggestions and updated text"
  $ git push git@github.com:Pakketeretet2/lammps :pre
 
-This merge also shows up on the lammps Github page:
+This merge also shows up on the lammps GitHub page:
 
 :c,image(JPG/tutorial_reverse_pull_request7.png)
 
@@ -381,3 +414,6 @@ Furthermore, the naming of the patches now follow the pattern
 "patch_<Day><Month><Year>" to simplify comparisons between releases.
 Finally, all patches and submissions are subject to automatic testing
 and code checks to make sure they at the very least compile.
+
+A discussion of the LAMMPS developer GitHub workflow can be found in the file
+"doc/github-development-workflow.md"_https://github.com/lammps/lammps/blob/master/doc/github-development-workflow.md

doc/src/Howto_manifold.txt

@@ -31,8 +31,8 @@ plane @ a b c x0 y0 z0 @ a*(x-x0) + b*(y-y0) + c*(z-z0) = 0 @ A plane with norma
 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
 supersphere @ R q @ | x |^q + | y |^q + | z |^q - R^q = 0 @ A supersphere of hyperradius R
-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 dendtritic 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 dendtritic spine
+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
 thylakoid @ wB LB lB @ Various, see "(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
 torus @ R r  @  (R - sqrt( x^2 + y^2 ) )^2 + z^2 - r^2  @ A torus with large radius R and small radius r, centered on (0,0,0) :tb(s=@)
 

doc/src/Howto_nemd.txt

@@ -55,5 +55,5 @@ using the "fix flow/gauss"_fix_flow_gauss.html command.
 :line
 
 :link(Daivis-nemd)
-[(Daivis and Todd)] Daivis and Todd, Nonequilibrium Molecular Dyanmics (book),
+[(Daivis and Todd)] Daivis and Todd, Nonequilibrium Molecular Dynamics (book),
 Cambridge University Press, https://doi.org/10.1017/9781139017848, (2017).

doc/src/Howto_polarizable.txt

@@ -45,8 +45,8 @@ high symmetry around each site leads to stable trajectories of the
 core-shell pairs. However, bonded atoms in molecules can be so close
 that a core would interact too strongly or even capture the Drude
 particle of a neighbor. The Drude dipole model is relatively more
-complex in order to remediate this and other issues. Specifically, the
-Drude model includes specific thermostating of the core-Drude pairs
+complex in order to remedy this and other issues. Specifically, the
+Drude model includes specific thermostatting of the core-Drude pairs
 and short-range damping of the induced dipoles.
 
 The three polarization methods can be implemented through a
@@ -77,5 +77,5 @@ motion of the Drude particles with respect to their cores is kept
 approaching the self-consistent regime.  In both models the
 temperature is regulated using the velocities of the center of mass of
 core+shell (or Drude) pairs, but in the Drude model the actual
-relative core-Drude particle motion is thermostated separately as
+relative core-Drude particle motion is thermostatted separately as
 well.

doc/src/Howto_pylammps.txt

@@ -141,16 +141,16 @@ Python code if {L} was a lammps instance:
 L.command("region box block 0 10 0 5 -0.5 0.5") :pre
 
 With the PyLammps interface, any command can be split up into arbitrary parts
-separated by whitespace, passed as individual arguments to a region method.
+separated by white-space, passed as individual arguments to a region method.
 
 L.region("box block", 0, 10, 0, 5, -0.5, 0.5) :pre
 
 Note that each parameter is set as Python literal floating-point number. In the
 PyLammps interface, each command takes an arbitrary parameter list and transparently
-merges it to a single command string, separating individual parameters by whitespace.
+merges it to a single command string, separating individual parameters by white-space.
 
 The benefit of this approach is avoiding redundant command calls and easier
-parameterization. In the original interface parametrization needed to be done
+parameterization. In the original interface parameterization needed to be done
 manually by creating formatted strings.
 
 L.command("region box block %f %f %f %f %f %f" % (xlo, xhi, ylo, yhi, zlo, zhi)) :pre
@@ -328,7 +328,7 @@ jupyter notebook :pre
 IPyLammps Examples :h4
 
 Examples of IPython notebooks can be found in the python/examples/pylammps
-subdirectory. To open these notebooks launch {jupyter notebook} inside this
+sub-directory. To open these notebooks launch {jupyter notebook} inside this
 directory and navigate to one of them. If you compiled and installed
 a LAMMPS shared library with exceptions, PNG, JPEG and FFMPEG support
 you should be able to rerun all of these notebooks.

doc/src/Howto_replica.txt

@@ -9,7 +9,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 
 Multi-replica simulations :h3
 
-Several commands in LAMMPS run mutli-replica simulations, meaning
+Several commands in LAMMPS run multi-replica simulations, meaning
 that multiple instances (replicas) of your simulation are run
 simultaneously, with small amounts of data exchanged between replicas
 periodically.

doc/src/Howto_spc.txt

@@ -30,7 +30,7 @@ r0 of OH bond = 1.0
 theta of HOH angle = 109.47 :all(b),p
 
 Note that as originally proposed, the SPC model was run with a 9
-Angstrom cutoff for both LJ and Coulommbic terms.  It can also be used
+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.

doc/src/Howto_spherical.txt

@@ -35,7 +35,7 @@ There are several "atom styles"_atom_style.html that allow for
 definition of finite-size particles: sphere, dipole, ellipsoid, line,
 tri, peri, and body.
 
-The sphere style defines particles that are spheriods and each
+The sphere style defines particles that are spheroids and each
 particle can have a unique diameter and mass (or density).  These
 particles store an angular velocity (omega) and can be acted upon by
 torque.  The "set" command can be used to modify the diameter and mass
@@ -236,7 +236,7 @@ particles are point masses.
 Also note that body particles cannot be modeled with the "fix
 rigid"_fix_rigid.html command.  Body particles are treated by LAMMPS
 as single particles, though they can store internal state, such as a
-list of sub-particles.  Individual body partices are typically treated
+list of sub-particles.  Individual body particles are typically treated
 as rigid bodies, and their motion integrated with a command like "fix
 nve/body"_fix_nve_body.html.  Interactions between pairs of body
 particles are computed via a command like "pair_style

doc/src/Howto_spins.txt

@@ -36,7 +36,7 @@ A Langevin thermostat can be applied to those magnetic spins using
 "fix langevin/spin"_fix_langevin_spin.html. Typically, this thermostat
 can be coupled to another Langevin thermostat applied to the atoms
 using "fix langevin"_fix_langevin.html in order to simulate
-thermostated spin-lattice system. 
+thermostatted spin-lattice system.
 
 The magnetic Gilbert damping can also be applied using "fix
 langevin/spin"_fix_langevin_spin.html. It allows to either dissipate

doc/src/Howto_thermostat.txt

@@ -96,5 +96,5 @@ temperature compute is used for default thermodynamic output.
 :line
 
 :link(Daivis-thermostat)
-[(Daivis and Todd)] Daivis and Todd, Nonequilibrium Molecular Dyanmics (book),
+[(Daivis and Todd)] Daivis and Todd, Nonequilibrium Molecular Dynamics (book),
 Cambridge University Press, https://doi.org/10.1017/9781139017848, (2017).

doc/src/Howto_triclinic.txt

@@ -200,7 +200,7 @@ used with non-orthogonal basis vectors to define a lattice that will
 tile a triclinic simulation box via the
 "create_atoms"_create_atoms.html command.
 
-A second use is to run Parinello-Rahman dynamics via the "fix
+A second use is to run Parrinello-Rahman dynamics via the "fix
 npt"_fix_nh.html command, which will adjust the xy, xz, yz tilt
 factors to compensate for off-diagonal components of the pressure
 tensor.  The analog for an "energy minimization"_minimize.html is

doc/src/Howto_viscosity.txt

@@ -140,5 +140,5 @@ with time at sufficiently long times.
 :line
 
 :link(Daivis-viscosity)
-[(Daivis and Todd)] Daivis and Todd, Nonequilibrium Molecular Dyanmics (book),
+[(Daivis and Todd)] Daivis and Todd, Nonequilibrium Molecular Dynamics (book),
 Cambridge University Press, https://doi.org/10.1017/9781139017848, (2017).

doc/src/Intro_authors.txt

@@ -48,7 +48,7 @@ Trung Ngyuen (Northwestern U), GPU and RIGID and BODY packages
 Mike Parks (Sandia), PERI package for Peridynamics
 Roy Pollock (LLNL), Ewald and PPPM solvers
 Christian Trott (Sandia), USER-CUDA and KOKKOS packages
-Ilya Valuev (JIHT), USER-AWPMD package for wave-packet MD
+Ilya Valuev (JIHT), USER-AWPMD package for wave packet MD
 Greg Wagner (Northwestern U), MEAM package for MEAM potential :ul
 
 :line

doc/src/Intro_features.txt

@@ -68,7 +68,7 @@ commands)
   pairwise potentials: Lennard-Jones, Buckingham, Morse, Born-Mayer-Huggins, \
     Yukawa, soft, class 2 (COMPASS), hydrogen bond, tabulated
   charged pairwise potentials: Coulombic, point-dipole
-  manybody potentials: EAM, Finnis/Sinclair EAM, modified EAM (MEAM), \
+  many-body potentials: EAM, Finnis/Sinclair EAM, modified EAM (MEAM), \
     embedded ion method (EIM), EDIP, ADP, Stillinger-Weber, Tersoff, \
     REBO, AIREBO, ReaxFF, COMB, SNAP, Streitz-Mintmire, 3-body polymorphic
   long-range interactions for charge, point-dipoles, and LJ dispersion: \
@@ -114,7 +114,7 @@ Ensembles, constraints, and boundary conditions :h4,link(ensemble)
 
   2d or 3d systems
   orthogonal or non-orthogonal (triclinic symmetry) simulation domains
-  constant NVE, NVT, NPT, NPH, Parinello/Rahman integrators
+  constant NVE, NVT, NPT, NPH, Parrinello/Rahman integrators
   thermostatting options for groups and geometric regions of atoms
   pressure control via Nose/Hoover or Berendsen barostatting in 1 to 3 dimensions
   simulation box deformation (tensile and shear)

doc/src/Intro_nonfeatures.txt

@@ -13,15 +13,19 @@ LAMMPS is designed to be a fast, parallel engine for molecular
 dynamics (MD) simulations.  It provides only a modest amount of
 functionality for setting up simulations and analyzing their output.
 
-Specifically, LAMMPS does not:
+Specifically, LAMMPS was not conceived and designed for:
 
-run thru a GUI
-build molecular systems
+being run thru a GUI
+build molecular systems, or building molecular topologies
 assign force-field coefficients automagically
-perform sophisticated analyses of your MD simulation
+perform sophisticated analysis of your MD simulation
 visualize your MD simulation interactively
 plot your output data :ul
 
+Although over the years these limitations have been somewhat
+reduced through features added to LAMMPS or external tools
+that either interface with LAMMPS or extend LAMMPS.
+
 Here are suggestions on how to perform these tasks:
 
 GUI: LAMMPS can be built as a library and a Python wrapper that wraps
@@ -29,7 +33,7 @@ the library interface is provided.  Thus, GUI interfaces can be
 written in Python (or C or C++ if desired) that run LAMMPS and
 visualize or plot its output.  Examples of this are provided in the
 python directory and described on the "Python"_Python_head.html doc
-page. :ulb,l
+page.  Also, there are several external wrappers or GUI front ends.:ulb,l
 
 Builder: Several pre-processing tools are packaged with LAMMPS.  Some
 of them convert input files in formats produced by other MD codes such
@@ -40,28 +44,36 @@ molecular builder that will generate complex molecular models.  See
 the "Tools"_Tools.html doc page for details on tools packaged with
 LAMMPS.  The "Pre/post processing
 page"_http:/lammps.sandia.gov/prepost.html of the LAMMPS website
-describes a variety of 3rd party tools for this task. :l
+describes a variety of 3rd party tools for this task.  Furthermore,
+some LAMMPS internal commands to reconstruct topology, as well as
+the option to insert molecule templates instead of atoms.:l
 
 Force-field assignment: The conversion tools described in the previous
 bullet for CHARMM, AMBER, and Insight will also assign force field
 coefficients in the LAMMPS format, assuming you provide CHARMM, AMBER,
-or Accelerys force field files. :l
+or BIOVIA (formerly Accelrys) force field files. :l
 
-Simulation analyses: If you want to perform analyses on-the-fly as
+Simulation analysis: If you want to perform analysis on-the-fly as
 your simulation runs, see the "compute"_compute.html and
 "fix"_fix.html doc pages, which list commands that can be used in a
 LAMMPS input script.  Also see the "Modify"_Modify.html doc page for
 info on how to add your own analysis code or algorithms to LAMMPS.
 For post-processing, LAMMPS output such as "dump file
 snapshots"_dump.html can be converted into formats used by other MD or
-post-processing codes.  Some post-processing tools packaged with
+post-processing codes.  To some degree, that conversion can be done
+directly inside of LAMMPS by interfacing to the VMD molfile plugins.
+The "rerun"_rerun.html command also allows to do some post-processing
+of existing trajectories, and through being able to read a variety
+of file formats, this can also be used for analyzing trajectories
+from other MD codes.  Some post-processing tools packaged with
 LAMMPS will do these conversions.  Scripts provided in the
 tools/python directory can extract and massage data in dump files to
 make it easier to import into other programs.  See the
 "Tools"_Tools.html doc page for details on these various options. :l
 
 Visualization: LAMMPS can produce JPG or PNG snapshot images
-on-the-fly via its "dump image"_dump_image.html command.  For
+on-the-fly via its "dump image"_dump_image.html command and pass
+them to an external program FFmpeg 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

doc/src/Manual.txt

@@ -1,7 +1,7 @@
 <!-- HTML_ONLY -->
 <HEAD>
 <TITLE>LAMMPS Users Manual</TITLE>
-<META NAME="docnumber" CONTENT="24 Oct 2018 version">
+<META NAME="docnumber" CONTENT="7 Dec 2018 version">
 <META NAME="author" CONTENT="http://lammps.sandia.gov - Sandia National Laboratories">
 <META NAME="copyright" CONTENT="Copyright (2003) Sandia Corporation. This software and manual is distributed under the GNU General Public License.">
 </HEAD>
@@ -21,7 +21,7 @@
 :line
 
 LAMMPS Documentation :c,h1
-24 Oct 2018 version :c,h2
+7 Dec 2018 version :c,h2
 
 "What is a LAMMPS version?"_Manual_version.html
 

doc/src/Modify_contribute.txt

@@ -33,7 +33,7 @@ how much effort it will cause to integrate and test it, how much it
 requires changes to the core codebase, and of how much interest it is
 to the larger LAMMPS community.  Please see below for a checklist of
 typical requirements. Once you have prepared everything, see the
-"Howto github"_Howto_github.html doc page for instructions on how to
+"Using GitHub with LAMMPS Howto"_Howto_github.html doc page for instructions on how to
 submit your changes or new files through a GitHub pull request. If you
 prefer to submit patches or full files, you should first make certain,
 that your code works correctly with the latest patch-level version of

doc/src/Modify_pair.txt

@@ -10,7 +10,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 Pair styles :h3
 
 Classes that compute pairwise interactions are derived from the Pair
-class.  In LAMMPS, pairwise calculation include manybody potentials
+class.  In LAMMPS, pairwise calculation include many-body potentials
 such as EAM or Tersoff where particles interact without a static bond
 topology.  New styles can be created to add new pair potentials to
 LAMMPS.

doc/src/Modify_region.txt

@@ -20,6 +20,6 @@ Here is a brief description of methods you define in your new derived
 class.  See region.h for details.
 
 inside: determine whether a point is in the region
-surface_interior: determine if a point is within a cutoff distance inside of surc
-surface_exterior: determine if a point is within a cutoff distance outside of surf
+surface_interior: determine if a point is within a cutoff distance inside of surface
+surface_exterior: determine if a point is within a cutoff distance outside of surface
 shape_update : change region shape if set by time-dependent variable :tb(s=:)

doc/src/Packages_details.txt

@@ -89,12 +89,14 @@ as contained in the file name.
 "USER-NETCDF"_#PKG-USER-NETCDF,
 "USER-OMP"_#PKG-USER-OMP,
 "USER-PHONON"_#PKG-USER-PHONON,
+"USER-PLUMED"_#PKG-USER-PLUMED,
 "USER-PTM"_#PKG-USER-PTM,
 "USER-QMMM"_#PKG-USER-QMMM,
 "USER-QTB"_#PKG-USER-QTB,
 "USER-QUIP"_#PKG-USER-QUIP,
 "USER-REAXC"_#PKG-USER-REAXC,
 "USER-SCAFACOS"_#PKG-USER-SCAFACOS,
+"USER-SDPD"_#PKG-USER-SDPD,
 "USER-SMD"_#PKG-USER-SMD,
 "USER-SMTBQ"_#PKG-USER-SMTBQ,
 "USER-SPH"_#PKG-USER-SPH,
@@ -492,7 +494,7 @@ MANYBODY package :link(PKG-MANYBODY),h4
 
 [Contents:]
 
-A variety of manybody and bond-order potentials.  These include
+A variety of many-body and bond-order potentials.  These include
 (AI)REBO, BOP, EAM, EIM, Stillinger-Weber, and Tersoff potentials.
 
 [Supporting info:]
@@ -516,7 +518,7 @@ MC package :link(PKG-MC),h4
 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.
+(GCMC) in conjunction with dynamics.
 
 [Supporting info:]
 
@@ -1186,7 +1188,7 @@ the NAMD MD code, but with portability in mind.  Axel Kohlmeyer
 [Install:]
 
 This package has "specific installation
-instructions"_Build_extras.html#gpu on the "Build
+instructions"_Build_extras.html#user-colvars on the "Build
 extras"_Build_extras.html doc page.
 
 [Supporting info:]
@@ -1200,6 +1202,36 @@ examples/USER/colvars :ul
 
 :line
 
+USER-PLUMED package :link(PKG-USER-PLUMED),h4
+
+[Contents:]
+
+The fix plumed command allows you to use the PLUMED free energy plugin
+for molecular dynamics to analyze and bias your LAMMPS trajectory on
+the fly.  The PLUMED library is called from within the LAMMPS input
+script by using the "fix plumed _fix_plumed.html command.
+
+[Authors:] The "PLUMED library"_#PLUMED is written and maintained by
+Massimilliano Bonomi, Giovanni Bussi, Carlo Camiloni and Gareth
+Tribello.
+
+:link(PLUMED,http://www.plumed.org)
+
+[Install:]
+
+This package has "specific installation
+instructions"_Build_extras.html#gpu on the "Build
+extras"_Build_extras.html doc page.
+
+[Supporting info:]
+
+src/USER-PLUMED/README
+lib/plumed/README
+"fix plumed"_fix_plumed.html
+examples/USER/plumed :ul
+
+:line
+
 USER-DIFFRACTION package :link(PKG-USER-DIFFRACTION),h4
 
 [Contents:]
@@ -1916,6 +1948,31 @@ examples/USER/scafacos :ul
 
 :line
 
+USER-SDPD package :link(PKG-USER-SDPD),h4
+
+[Contents:]
+
+A pair style for smoothed dissipative particle dynamics (SDPD), which
+is an extension of smoothed particle hydrodynamics (SPH) to mesoscale
+where thermal fluctuations are important (see the
+"USER-SPH package"_#PKG-USER-SPH).
+Also two fixes for moving and rigid body integration of SPH/SDPD particles
+(particles of atom_style meso).
+
+[Author:] Morteza Jalalvand (Institute for Advanced Studies in Basic
+Sciences, Iran).
+
+[Supporting info:]
+
+src/USER-SDPD: filenames -> commands
+src/USER-SDPD/README
+"pair_style sdpd/taitwater/isothermal"_pair_sdpd_taitwater_isothermal.html
+"fix meso/move"_fix_meso_move.html
+"fix rigid/meso"_fix_rigid_meso.html
+examples/USER/sdpd :ul
+
+:line
+
 USER-SMD package :link(PKG-USER-SMD),h4
 
 [Contents:]

doc/src/Packages_user.txt

@@ -38,8 +38,8 @@ int = internal library: provided with LAMMPS, but you may need to build it
 ext = external library: you will need to download and install it on your machine :ul
 
 Package, Description, Doc page, Example, Library
-"USER-ATC"_Packages_details.html#PKG-USER-ATC, atom-to-continuum coupling, "fix atc"_fix_atc.html, USER/atc, int
-"USER-AWPMD"_Packages_details.html#PKG-USER-AWPMD, wave-packet MD, "pair_style awpmd/cut"_pair_awpmd.html, USER/awpmd, int
+"USER-ATC"_Packages_details.html#PKG-USER-ATC, Atom-to-Continuum coupling, "fix atc"_fix_atc.html, USER/atc, int
+"USER-AWPMD"_Packages_details.html#PKG-USER-AWPMD, wave packet MD, "pair_style awpmd/cut"_pair_awpmd.html, USER/awpmd, int
 "USER-BOCS"_Packages_details.html#PKG-USER-BOCS, BOCS bottom up coarse graining, "fix bocs"_fix_bocs.html, USER/bocs, no
 "USER-CGDNA"_Packages_details.html#PKG-USER-CGDNA, coarse-grained DNA force fields, src/USER-CGDNA/README, USER/cgdna, no
 "USER-CGSDK"_Packages_details.html#PKG-USER-CGSDK, SDK coarse-graining model, "pair_style lj/sdk"_pair_sdk.html, USER/cgsdk, no
@@ -62,16 +62,20 @@ Package, Description, Doc page, Example, Library
 "USER-NETCDF"_Packages_details.html#PKG-USER-NETCDF, dump output via NetCDF,"dump netcdf"_dump_netcdf.html, n/a, ext
 "USER-OMP"_Packages_details.html#PKG-USER-OMP, OpenMP-enabled styles,"Speed omp"_Speed_omp.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, no
 "USER-PHONON"_Packages_details.html#PKG-USER-PHONON, phonon dynamical matrix,"fix phonon"_fix_phonon.html, USER/phonon, no
+"USER-PLUMED"_Packages_details.html#PKG-USER-PLUMED, "PLUMED"_#PLUMED free energy library,"fix plumed"_fix_plumed.html, USER/plumed, ext
 "USER-PTM"_Packages_details.html#PKG-USER-PTM, Polyhedral Template Matching,"compute ptm/atom"_compute_ptm_atom.html, n/a, no
 "USER-QMMM"_Packages_details.html#PKG-USER-QMMM, QM/MM coupling,"fix qmmm"_fix_qmmm.html, USER/qmmm, ext
 "USER-QTB"_Packages_details.html#PKG-USER-QTB, quantum nuclear effects,"fix qtb"_fix_qtb.html "fix qbmsst"_fix_qbmsst.html, qtb, no
 "USER-QUIP"_Packages_details.html#PKG-USER-QUIP, QUIP/libatoms interface,"pair_style quip"_pair_quip.html, USER/quip, ext
 "USER-REAXC"_Packages_details.html#PKG-USER-REAXC, ReaxFF potential (C/C++) ,"pair_style reaxc"_pair_reaxc.html, reax, no
 "USER-SCAFACOS"_Packages_details.html#PKG-USER-SCAFACOS, wrapper on ScaFaCoS solver,"kspace_style scafacos"_kspace_style.html, USER/scafacos, ext
+"USER-SDPD"_Packages_details.html#PKG-USER-SDPD, smoothed dissipative particle dynamics,"pair_style sdpd/taitwater/isothermal"_pair_sdpd_taitwater_isothermal.html, USER/sdpd, no
 "USER-SMD"_Packages_details.html#PKG-USER-SMD, smoothed Mach dynamics,"SMD User Guide"_PDF/SMD_LAMMPS_userguide.pdf, USER/smd, ext
 "USER-SMTBQ"_Packages_details.html#PKG-USER-SMTBQ, second moment tight binding QEq potential,"pair_style smtbq"_pair_smtbq.html, USER/smtbq, no
 "USER-SPH"_Packages_details.html#PKG-USER-SPH, smoothed particle hydrodynamics,"SPH User Guide"_PDF/SPH_LAMMPS_userguide.pdf, USER/sph, no
 "USER-TALLY"_Packages_details.html#PKG-USER-TALLY, pairwise tally computes,"compute XXX/tally"_compute_tally.html, USER/tally, no
 "USER-UEF"_Packages_details.html#PKG-USER-UEF, extensional flow,"fix nvt/uef"_fix_nh_uef.html, USER/uef, no
 "USER-VTK"_Packages_details.html#PKG-USER-VTK, dump output via VTK, "compute vtk"_dump_vtk.html, n/a, ext :tb(ea=c,ca1=l)
+
 :link(MOFplus,https://www.mofplus.org/content/show/MOF-FF)
+:link(PLUMED,http://www.plumed.org)

doc/src/Python_call.txt

@@ -79,7 +79,7 @@ of Python and your machine to successfully build LAMMPS.  See the
 lib/python/README file for more info.
 
 If you want to write Python code with callbacks to LAMMPS, then you
-must also follow the steps overviewed in the "Python
+must also follow the steps summarized in the "Python
 run"_Python_run.html doc page.  I.e. you must build LAMMPS as a shared
 library and insure that Python can find the python/lammps.py file and
 the shared library.

doc/src/Python_examples.txt

@@ -46,7 +46,7 @@ http://mt.seas.upenn.edu/Archive/Graphics/A3/A3.html :pre
 :link(atomeye,http://mt.seas.upenn.edu/Archive/Graphics/A)
 :link(atomeye3,http://mt.seas.upenn.edu/Archive/Graphics/A3/A3.html)
 
-The latter link is to AtomEye 3 which has the scriping
+The latter link is to AtomEye 3 which has the scripting
 capability needed by these Python scripts.
 
 Note that for PyMol, you need to have built and installed the

doc/src/Run_options.txt

@@ -354,29 +354,31 @@ the LAMMPS simulation domain.
 
 :line
 
-[-restart2data restartfile (remap) datafile keyword value ...] :link(restart2data)
+[-restart2data restartfile \[remap\] datafile keyword value ...]
+:link(restart2data)
 
 Convert the restart file into a data file and immediately exit.  This
 is the same operation as if the following 2-line input script were
 run:
 
-read_restart restartfile (remap)
+read_restart restartfile \[remap\]
 write_data datafile keyword value ... :pre
 
-Note that the specified restartfile and/or datafile can have the
-wild-card character "*".  The restartfile can also have the wild-card
+The specified restartfile and/or datafile name may contain the wild-card
+character "*".  The restartfile name may also contain the wild-card
 character "%".  The meaning of these characters is explained on the
 "read_restart"_read_restart.html and "write_data"_write_data.html doc
 pages.  The use of "%" means that a parallel restart file can be read.
-Note that a filename such as file.* will need to be enclosed in quotes
-to avoid shell expansion of the "*" character.
+Note that a filename such as file.* may need to be enclosed in quotes or
+the "*" character prefixed with a backslash ("\") to avoid shell
+expansion of the "*" character.
 
-Note that following restartfile, the optional word "remap" can be
-used.  This has the effect of adding it to the
-"read_restart"_read_restart.html command, as explained on its doc
-page.  This is useful if reading the restart file triggers an error
-that atoms have been lost.  In that case, use of the remap flag should
-allow the data file to still be produced.
+Following restartfile argument, the optional word "remap" may be used.
+This has the same effect like adding it to a
+"read_restart"_read_restart.html command, and operates as explained on
+its doc page.  This is useful if reading the restart file triggers an
+error that atoms have been lost.  In that case, use of the remap flag
+should allow the data file to still be produced.
 
 The syntax following restartfile (or remap), namely
 
@@ -388,29 +390,30 @@ optional keyword/value settings.
 
 :line
 
-[-restart2dump restartfile {remap} group-ID dumpstyle dumpfile arg1 arg2 ...] :link(restart2dump)
+[-restart2dump restartfile \[remap\] group-ID dumpstyle dumpfile arg1 arg2 ...] :link(restart2dump)
 
 Convert the restart file into a dump file and immediately exit.  This
 is the same operation as if the following 2-line input script were
 run:
 
-read_restart restartfile (remap)
+read_restart restartfile \[remap\]
 write_dump group-ID dumpstyle dumpfile arg1 arg2 ... :pre
 
-Note that the specified restartfile and dumpfile can have wild-card
-characters ("*","%") as explained on the
+Note that the specified restartfile and dumpfile names may contain
+wild-card characters ("*","%") as explained on the
 "read_restart"_read_restart.html and "write_dump"_write_dump.html doc
 pages.  The use of "%" means that a parallel restart file and/or
 parallel dump file can be read and/or written.  Note that a filename
-such as file.* will need to be enclosed in quotes to avoid shell
-expansion of the "*" character.
+such as file.* may need to be enclosed in quotes or the "*" character
+prefixed with a backslash ("\") to avoid shell expansion of the "*"
+character.
 
-Note that following restartfile, the optional word "remap" can be
-used.  This has the effect as adding it to the
-"read_restart"_read_restart.html command, as explained on its doc
-page.  This is useful if reading the restart file triggers an error
-that atoms have been lost.  In that case, use of the remap flag should
-allow the dump file to still be produced.
+Note that following the restartfile argument, the optional word "remap"
+can be used.  This has the effect as adding it to the
+"read_restart"_read_restart.html command, as explained on its doc page.
+This is useful if reading the restart file triggers an error that atoms
+have been lost.  In that case, use of the remap flag should allow the
+dump file to still be produced.
 
 The syntax following restartfile (or remap), namely
 

doc/src/Run_windows.txt

@@ -41,7 +41,7 @@ path for the default location of this MPI package. After the
 installation of the MPICH2 software, it needs to be integrated into
 the system.  For this you need to start a Command Prompt in
 {Administrator Mode} (right click on the icon and select it). Change
-into the MPICH2 installation directory, then into the subdirectory
+into the MPICH2 installation directory, then into the sub-directory
 [bin] and execute [smpd.exe -install]. Exit the command window.
 
 Get a new, regular command prompt by going to Start->Run... ,

doc/src/Speed.txt

@@ -19,7 +19,7 @@ using code options that implement alternate algorithms that can
 speed-up a simulation.  The second is to use one of the several
 accelerator packages provided with LAMMPS that contain code optimized
 for certain kinds of hardware, including multi-core CPUs, GPUs, and
-Intel Xeon Phi coprocessors.
+Intel Xeon Phi co-processors.
 
 The "Benchmark page"_http://lammps.sandia.gov/bench.html of the LAMMPS
 web site gives performance results for the various accelerator

doc/src/Speed_intel.txt

@@ -14,11 +14,11 @@ Corporation.  It provides two methods for accelerating simulations,
 depending on the hardware you have.  The first is acceleration on
 Intel CPUs by running in single, mixed, or double precision with
 vectorization.  The second is acceleration on Intel Xeon Phi
-coprocessors via offloading neighbor list and non-bonded force
+co-processors via offloading neighbor list and non-bonded force
 calculations to the Phi.  The same C++ code is used in both cases.
-When offloading to a coprocessor from a CPU, the same routine is run
+When offloading to a co-processor from a CPU, the same routine is run
 twice, once on the CPU and once with an offload flag. This allows
-LAMMPS to run on the CPU cores and coprocessor cores simultaneously.
+LAMMPS to run on the CPU cores and co-processor cores simultaneously.
 
 [Currently Available USER-INTEL Styles:]
 
@@ -47,7 +47,7 @@ These are scalable in size; the results given are with 512K
 particles (524K for Liquid Crystal). Most of the simulations are
 standard LAMMPS benchmarks (indicated by the filename extension in
 parenthesis) with modifications to the run length and to add a
-warmup run (for use with offload benchmarks).
+warm-up run (for use with offload benchmarks).
 
 :c,image(JPG/user_intel.png)
 
@@ -134,19 +134,19 @@ Do not use thread affinity (set KMP_AFFINITY=none) :l
 The "newton off" setting may provide better scalability :l
 :ule
 
-For Intel Xeon Phi coprocessors (Offload):
+For Intel Xeon Phi co-processors (Offload):
 
-Edit src/MAKE/OPTIONS/Makefile.intel_coprocessor as necessary :ulb,l
+Edit src/MAKE/OPTIONS/Makefile.intel_co-processor as necessary :ulb,l
 "-pk intel N omp 1" added to command-line where N is the number of
-coprocessors per node. :l
+co-processors per node. :l
 :ule
 
 :line
 
 [Required hardware/software:]
 
-In order to use offload to coprocessors, an Intel Xeon Phi
-coprocessor and an Intel compiler are required. For this, the
+In order to use offload to co-processors, an Intel Xeon Phi
+co-processor and an Intel compiler are required. For this, the
 recommended version of the Intel compiler is 14.0.1.106 or
 versions 15.0.2.044 and higher.
 
@@ -214,7 +214,7 @@ Makefile.intel_cpu_intelmpi # Intel Compiler, Intel MPI, No Offload
 Makefile.knl                # Intel Compiler, Intel MPI, No Offload
 Makefile.intel_cpu_mpich    # Intel Compiler, MPICH, No Offload
 Makefile.intel_cpu_openpmi  # Intel Compiler, OpenMPI, No Offload
-Makefile.intel_coprocessor  # Intel Compiler, Intel MPI, Offload :pre
+Makefile.intel_co-processor  # Intel Compiler, Intel MPI, Offload :pre
 
 Makefile.knl is identical to Makefile.intel_cpu_intelmpi except that
 it explicitly specifies that vectorization should be for Intel Xeon
@@ -227,9 +227,9 @@ source /opt/intel/parallel_studio_xe_2016.3.067/psxevars.sh
 # or psxevars.csh for C-shell
 make intel_cpu_intelmpi :pre
 
-Note that if you build with support for a Phi coprocessor, the same
-binary can be used on nodes with or without coprocessors installed.
-However, if you do not have coprocessors on your system, building
+Note that if you build with support for a Phi co-processor, the same
+binary can be used on nodes with or without co-processors installed.
+However, if you do not have co-processors on your system, building
 without offload support will produce a smaller binary.
 
 The general requirements for Makefiles with the USER-INTEL package
@@ -272,7 +272,7 @@ Advanced performance tuning options are also described below to get
 the best performance.
 
 When running on a single node (including runs using offload to a
-coprocessor), best performance is normally obtained by using 1 MPI
+co-processor), best performance is normally obtained by using 1 MPI
 task per physical core and additional OpenMP threads with SMT. For
 Intel Xeon processors, 2 OpenMP threads should be used for SMT.
 For Intel Xeon Phi CPUs, 2 or 4 OpenMP threads should be used
@@ -290,7 +290,7 @@ NOTE: Setting core affinity is often used to pin MPI tasks and OpenMP
 threads to a core or group of cores so that memory access can be
 uniform. Unless disabled at build time, affinity for MPI tasks and
 OpenMP threads on the host (CPU) will be set by default on the host
-{when using offload to a coprocessor}. In this case, it is unnecessary
+{when using offload to a co-processor}. In this case, it is unnecessary
 to use other methods to control affinity (e.g. taskset, numactl,
 I_MPI_PIN_DOMAIN, etc.). This can be disabled with the {no_affinity}
 option to the "package intel"_package.html command or by disabling the
@@ -310,15 +310,15 @@ editing the input script. This switch will automatically append
 options for the USER-INTEL package.  The default package command will
 specify that USER-INTEL calculations are performed in mixed precision,
 that the number of OpenMP threads is specified by the OMP_NUM_THREADS
-environment variable, and that if coprocessors are present and the
-binary was built with offload support, that 1 coprocessor per node
+environment variable, and that if co-processors are present and the
+binary was built with offload support, that 1 co-processor per node
 will be used with automatic balancing of work between the CPU and the
-coprocessor.
+co-processor.
 
 You can specify different options for the USER-INTEL package by using
 the "-pk intel Nphi" "command-line switch"_Run_options.html with
 keyword/value pairs as specified in the documentation. Here, Nphi = #
-of Xeon Phi coprocessors/node (ignored without offload
+of Xeon Phi co-processors/node (ignored without offload
 support). Common options to the USER-INTEL package include {omp} to
 override any OMP_NUM_THREADS setting and specify the number of OpenMP
 threads, {mode} to set the floating-point precision mode, and {lrt} to
@@ -332,7 +332,7 @@ Examples (see documentation for your MPI/Machine for differences in
 launching MPI applications):
 
 mpirun -np 72 -ppn 36 lmp_machine -sf intel -in in.script                                 # 2 nodes, 36 MPI tasks/node, $OMP_NUM_THREADS OpenMP Threads
-mpirun -np 72 -ppn 36 lmp_machine -sf intel -in in.script -pk intel 0 omp 2 mode double   # Don't use any coprocessors that might be available, use 2 OpenMP threads for each task, use double precision :pre
+mpirun -np 72 -ppn 36 lmp_machine -sf intel -in in.script -pk intel 0 omp 2 mode double   # Don't use any co-processors that might be available, use 2 OpenMP threads for each task, use double precision :pre
 
 [Or run with the USER-INTEL package by editing an input script:]
 
@@ -364,7 +364,7 @@ intel"_package.html command that can improve performance when using
 "PPPM"_kspace_style.html for long-range electrostatics on processors
 with SMT. It generates an extra pthread for each MPI task. The thread
 is dedicated to performing some of the PPPM calculations and MPI
-communications. This feature requires setting the preprocessor flag
+communications. This feature requires setting the pre-processor flag
 -DLMP_INTEL_USELRT in the makefile when compiling LAMMPS. It is unset
 in the default makefiles ({Makefile.mpi} and {Makefile.serial}) but
 it is set in all makefiles tuned for the USER-INTEL package.  On Intel
@@ -422,29 +422,29 @@ that MPI runs are performed in MCDRAM.
 
 The default settings for offload should give good performance.
 
-When using LAMMPS with offload to Intel coprocessors, best performance
+When using LAMMPS with offload to Intel co-processors, best performance
 will typically be achieved with concurrent calculations performed on
-both the CPU and the coprocessor. This is achieved by offloading only
-a fraction of the neighbor and pair computations to the coprocessor or
+both the CPU and the co-processor. This is achieved by offloading only
+a fraction of the neighbor and pair computations to the co-processor or
 using "hybrid"_pair_hybrid.html pair styles where only one style uses
 the "intel" suffix. For simulations with long-range electrostatics or
 bond, angle, dihedral, improper calculations, computation and data
-transfer to the coprocessor will run concurrently with computations
+transfer to the co-processor will run concurrently with computations
 and MPI communications for these calculations on the host CPU. This
 is illustrated in the figure below for the rhodopsin protein benchmark
 running on E5-2697v2 processors with a Intel Xeon Phi 7120p
-coprocessor. In this plot, the vertical access is time and routines
+co-processor. In this plot, the vertical access is time and routines
 running at the same time are running concurrently on both the host and
-the coprocessor.
+the co-processor.
 
 :c,image(JPG/offload_knc.png)
 
 The fraction of the offloaded work is controlled by the {balance}
 keyword in the "package intel"_package.html command. A balance of 0
 runs all calculations on the CPU.  A balance of 1 runs all
-supported calculations on the coprocessor.  A balance of 0.5 runs half
-of the calculations on the coprocessor.  Setting the balance to -1
-(the default) will enable dynamic load balancing that continously
+supported calculations on the co-processor.  A balance of 0.5 runs half
+of the calculations on the co-processor.  Setting the balance to -1
+(the default) will enable dynamic load balancing that continuously
 adjusts the fraction of offloaded work throughout the simulation.
 Because data transfer cannot be timed, this option typically produces
 results within 5 to 10 percent of the optimal fixed balance.
@@ -455,23 +455,23 @@ near-optimal setting that will carry over to additional runs.
 
 The default for the "package intel"_package.html command is to have
 all the MPI tasks on a given compute node use a single Xeon Phi
-coprocessor.  In general, running with a large number of MPI tasks on
+co-processor.  In general, running with a large number of MPI tasks on
 each node will perform best with offload.  Each MPI task will
 automatically get affinity to a subset of the hardware threads
-available on the coprocessor.  For example, if your card has 61 cores,
+available on the co-processor.  For example, if your card has 61 cores,
 with 60 cores available for offload and 4 hardware threads per core
 (240 total threads), running with 24 MPI tasks per node will cause
-each MPI task to use a subset of 10 threads on the coprocessor.  Fine
+each MPI task to use a subset of 10 threads on the co-processor.  Fine
 tuning of the number of threads to use per MPI task or the number of
 threads to use per core can be accomplished with keyword settings of
 the "package intel"_package.html command.
 
 The USER-INTEL package has two modes for deciding which atoms will be
-handled by the coprocessor.  This choice is controlled with the {ghost}
+handled by the co-processor.  This choice is controlled with the {ghost}
 keyword of the "package intel"_package.html command.  When set to 0,
 ghost atoms (atoms at the borders between MPI tasks) are not offloaded
 to the card.  This allows for overlap of MPI communication of forces
-with computation on the coprocessor when the "newton"_newton.html
+with computation on the co-processor when the "newton"_newton.html
 setting is "on".  The default is dependent on the style being used,
 however, better performance may be achieved by setting this option
 explicitly.
@@ -482,21 +482,21 @@ cores.  This is due to the fact that additional threads are generated
 internally to handle the asynchronous offload tasks.
 
 If pair computations are being offloaded to an Intel Xeon Phi
-coprocessor, a diagnostic line is printed to the screen (not to the
+co-processor, a diagnostic line is printed to the screen (not to the
 log file), during the setup phase of a run, indicating that offload
-mode is being used and indicating the number of coprocessor threads
+mode is being used and indicating the number of co-processor threads
 per MPI task.  Additionally, an offload timing summary is printed at
 the end of each run.  When offloading, the frequency for "atom
 sorting"_atom_modify.html is changed to 1 so that the per-atom data is
 effectively sorted at every rebuild of the neighbor lists. All the
-available coprocessor threads on each Phi will be divided among MPI
+available co-processor threads on each Phi will be divided among MPI
 tasks, unless the {tptask} option of the "-pk intel" "command-line
-switch"_Run_options.html is used to limit the coprocessor threads per
+switch"_Run_options.html is used to limit the co-processor threads per
 MPI task.
 
 [Restrictions:]
 
-When offloading to a coprocessor, "hybrid"_pair_hybrid.html styles
+When offloading to a co-processor, "hybrid"_pair_hybrid.html styles
 that require skip lists for neighbor builds cannot be offloaded.
 Using "hybrid/overlay"_pair_hybrid.html is allowed.  Only one intel
 accelerated style may be used with hybrid styles when offloading.
@@ -510,7 +510,7 @@ supported.
 
 [References:]
 
-Brown, W.M., Carrillo, J.-M.Y., Mishra, B., Gavhane, N., Thakker, F.M., De Kraker, A.R., Yamada, M., Ang, J.A., Plimpton, S.J., "Optimizing Classical Molecular Dynamics in LAMMPS," in Intel Xeon Phi Processor High Performance Programming: Knights Landing Edition, J. Jeffers, J. Reinders, A. Sodani, Eds. Morgan Kaufmann. :ulb,l
+Brown, W.M., Carrillo, J.-M.Y., Mishra, B., Gavhane, N., Thakkar, F.M., De Kraker, A.R., Yamada, M., Ang, J.A., Plimpton, S.J., "Optimizing Classical Molecular Dynamics in LAMMPS," in Intel Xeon Phi Processor High Performance Programming: Knights Landing Edition, J. Jeffers, J. Reinders, A. Sodani, Eds. Morgan Kaufmann. :ulb,l
 
 Brown, W. M., Semin, A., Hebenstreit, M., Khvostov, S., Raman, K., Plimpton, S.J. "Increasing Molecular Dynamics Simulation Rates with an 8-Fold Increase in Electrical Power Efficiency."_http://dl.acm.org/citation.cfm?id=3014915 2016 High Performance Computing, Networking, Storage and Analysis, SC16: International Conference (pp. 82-95). :l
 

doc/src/Speed_kokkos.txt

@@ -17,7 +17,7 @@ different backend languages such as CUDA, OpenMP, or Pthreads.  The
 Kokkos library also provides data abstractions to adjust (at compile
 time) the memory layout of data structures like 2d and 3d arrays to
 optimize performance on different hardware. For more information on
-Kokkos, see "Github"_https://github.com/kokkos/kokkos. Kokkos is part
+Kokkos, see "GitHub"_https://github.com/kokkos/kokkos. Kokkos is part
 of "Trilinos"_http://trilinos.sandia.gov/packages/kokkos. The Kokkos
 library was written primarily by Carter Edwards, Christian Trott, and
 Dan Sunderland (all Sandia).
@@ -133,15 +133,15 @@ thread-level write conflicts in the force arrays (and other data
 structures as necessary). Data duplication is typically fastest for
 small numbers of threads (i.e. 8 or less) but does increase memory
 footprint and is not scalable to large numbers of threads. An
-alternative to data duplication is to use thread-level atomics, which 
-don't require duplication. The use of atomics can be forced by compiling 
-with the "-DLMP_KOKKOS_USE_ATOMICS" compile switch. Most but not all 
-Kokkos-enabled pair_styles support data duplication. Alternatively, full 
-neighbor lists avoid the need for duplication or atomics but require 
-more compute operations per atom. When using the Kokkos Serial backend 
-or the OpenMP backend with a single thread, no duplication or atomics are 
-used. For CUDA and half neighbor lists, the KOKKOS package always uses 
-atomics.
+alternative to data duplication is to use thread-level atomic operations
+which do not require data duplication. The use of atomic operations can
+be enforced by compiling LAMMPS with the "-DLMP_KOKKOS_USE_ATOMICS"
+pre-processor flag. Most but not all Kokkos-enabled pair_styles support
+data duplication. Alternatively, full neighbor lists avoid the need for
+duplication or atomic operations but require more compute operations per
+atom.  When using the Kokkos Serial back end or the OpenMP back end with
+a single thread, no duplication or atomic operations are used. For CUDA
+and half neighbor lists, the KOKKOS package always uses atomic operations.
 
 [Core and Thread Affinity:]
 
@@ -193,7 +193,7 @@ threads/task as Nt. The product of these two values should be N, i.e.
 NOTE: The default for the "package kokkos"_package.html command is to
 use "full" neighbor lists and set the Newton flag to "off" for both
 pairwise and bonded interactions. When running on KNL, this will
-typically be best for pair-wise potentials. For manybody potentials,
+typically be best for pair-wise potentials. For many-body potentials,
 using "half" neighbor lists and setting the Newton flag to "on" may be
 faster. It can also be faster to use non-threaded communication.  Use
 the "-pk kokkos" "command-line switch"_Run_options.html to change the
@@ -207,7 +207,7 @@ mpirun -np 64 lmp_kokkos_phi -k on t 4 -sf kk -pk kokkos newton on neigh half co
 NOTE: MPI tasks and threads should be bound to cores as described
 above for CPUs.
 
-NOTE: To build with Kokkos support for Intel Xeon Phi coprocessors
+NOTE: To build with Kokkos support for Intel Xeon Phi co-processors
 such as Knight's Corner (KNC), your system must be configured to use
 them in "native" mode, not "offload" mode like the USER-INTEL package
 supports.

doc/src/Speed_omp.txt

@@ -131,7 +131,7 @@ effect worsens when using an increasing number of nodes. :l
 The system has a spatially inhomogeneous particle density which does
 not map well to the "domain decomposition scheme"_processors.html or
 "load-balancing"_balance.html options that LAMMPS provides.  This is
-because multi-threading achives parallelism over the number of
+because multi-threading achieves parallelism over the number of
 particles, not via their distribution in space. :l
 
 A machine is being used in "capability mode", i.e. near the point
@@ -143,7 +143,7 @@ the performance-limiting factor.  Using multi-threading allows less
 MPI tasks to be invoked and can speed-up the long-range solver, while
 increasing overall performance by parallelizing the pairwise and
 bonded calculations via OpenMP.  Likewise additional speedup can be
-sometimes be achived by increasing the length of the Coulombic cutoff
+sometimes be achieved by increasing the length of the Coulombic cutoff
 and thus reducing the work done by the long-range solver.  Using the
 "run_style verlet/split"_run_style.html command, which is compatible
 with the USER-OMP package, is an alternative way to reduce the number

doc/src/Speed_packages.txt

@@ -14,7 +14,7 @@ Accelerated versions of various "pair_style"_pair_style.html,
 been added to LAMMPS, which will typically run faster than the
 standard non-accelerated versions.  Some require appropriate hardware
 to be present on your system, e.g. GPUs or Intel Xeon Phi
-coprocessors.
+co-processors.
 
 All of these commands are in packages provided with LAMMPS.  An
 overview of packages is give on the "Packages"_Packages.html doc
@@ -161,7 +161,7 @@ package. These styles support vectorized single and mixed precision
 calculations, in addition to full double precision.  In extreme cases,
 this can provide speedups over 3.5x on CPUs.  The package also
 supports acceleration in "offload" mode to Intel(R) Xeon Phi(TM)
-coprocessors.  This can result in additional speedup over 2x depending
+co-processors.  This can result in additional speedup over 2x depending
 on the hardware configuration. :l
 
 Styles with a "kk" suffix are part of the KOKKOS package, and can be

doc/src/Tools.txt

@@ -163,7 +163,7 @@ for the "chain benchmark"_Speed_bench.html.
 
 colvars tools :h4,link(colvars)
 
-The colvars directory contains a collection of tools for postprocessing
+The colvars directory contains a collection of tools for post-processing
 data produced by the colvars collective variable library.
 To compile the tools, edit the makefile for your system and run "make".
 
@@ -406,8 +406,8 @@ supports it.  It has its own WWW page at
 msi2lmp tool :h4,link(msi)
 
 The msi2lmp sub-directory contains a tool for creating LAMMPS template
-input and data files from BIOVIA's Materias Studio files (formerly Accelrys'
-Insight MD code, formerly MSI/Biosym and its Discover MD code).
+input and data files from BIOVIA's Materias Studio files (formerly
+Accelrys' Insight MD code, formerly MSI/Biosym and its Discover MD code).
 
 This tool was written by John Carpenter (Cray), Michael Peachey
 (Cray), and Steve Lustig (Dupont). Several people contributed changes

doc/src/angle_coeff.txt

@@ -60,26 +60,14 @@ doc page for details.
 
 :line
 
-Here is an alphabetic list of angle styles defined in LAMMPS.  Click on
-the style to display the formula it computes and coefficients
-specified by the associated "angle_coeff"_angle_coeff.html command.
-
-Note that there are also additional angle styles submitted by users
-which are included in the LAMMPS distribution.  The full list of all
-angle styles is on the "Commands bond"_Commands_bond.html#angle doc
+The list of all angle styles defined in LAMMPS is given on the
+"angle_style"_angle_style.html doc page.  They are also listed in more
+compact form on the "Commands angle"_Commands_bond.html#angle doc
 page.
 
-"angle_style none"_angle_none.html - turn off angle interactions
-"angle_style hybrid"_angle_hybrid.html - define multiple styles of angle interactions :ul
-
-"angle_style charmm"_angle_charmm.html - CHARMM angle
-"angle_style class2"_angle_class2.html - COMPASS (class 2) angle
-"angle_style cosine"_angle_cosine.html - cosine angle potential
-"angle_style cosine/delta"_angle_cosine_delta.html - difference of cosines angle potential
-"angle_style cosine/periodic"_angle_cosine_periodic.html - DREIDING angle
-"angle_style cosine/squared"_angle_cosine_squared.html - cosine squared angle potential
-"angle_style harmonic"_angle_harmonic.html - harmonic angle
-"angle_style table"_angle_table.html - tabulated by angle :ul
+On either of those pages, click on the style to display the formula it
+computes and its coefficients as specified by the associated
+angle_coeff command.
 
 :line
 

doc/src/angle_sdk.txt

@@ -28,7 +28,7 @@ The {sdk} angle style is a combination of the harmonic angle potential,
 where theta0 is the equilibrium value of the angle and K a prefactor,
 with the {repulsive} part of the non-bonded {lj/sdk} pair style
 between the atoms 1 and 3.  This angle potential is intended for
-coarse grained MD simulations with the CMM parametrization using the
+coarse grained MD simulations with the CMM parameterization using the
 "pair_style lj/sdk"_pair_sdk.html.  Relative to the pair_style
 {lj/sdk}, however, the energy is shifted by {epsilon}, to avoid sudden
 jumps.  Note that the usual 1/2 factor is included in K.

doc/src/angle_style.txt

@@ -57,10 +57,15 @@ Here is an alphabetic list of angle styles defined in LAMMPS.  Click on
 the style to display the formula it computes and coefficients
 specified by the associated "angle_coeff"_angle_coeff.html command.
 
-Note that there are also additional angle styles submitted by users
-which are included in the LAMMPS distribution.  The full list of all
-angle styles are is on the "Commands bond"_Commands_bond.html#angle
-doc page.
+Click on the style to display the formula it computes, any additional
+arguments specified in the angle_style command, and coefficients
+specified by the associated "angle_coeff"_angle_coeff.html command.
+
+There are also additional accelerated pair styles included in the
+LAMMPS distribution for faster performance on CPUs, GPUs, and KNLs.
+The individual style names on the "Commands
+angle"_Commands_bond.html#angle doc page are followed by one or more
+of (g,i,k,o,t) to indicate which accelerated styles exist.
 
 "none"_angle_none.html - turn off angle interactions
 "zero"_angle_zero.html - topology but no interactions

doc/src/atom_modify.txt

@@ -166,7 +166,8 @@ info), a map is used.  The default map style is array if no atom ID is
 larger than 1 million, otherwise the default is hash.  By default, a
 "first" group is not defined.  By default, sorting is enabled with a
 frequency of 1000 and a binsize of 0.0, which means the neighbor
-cutoff will be used to set the bin size.
+cutoff will be used to set the bin size. If no neighbor cutoff is
+defined, sorting will be turned off.
 
 :line
 

doc/src/atom_style.txt

@@ -87,7 +87,7 @@ quantities.
 {line} | end points, angular velocity | rigid bodies |
 {meso} | rho, e, cv | SPH particles |
 {molecular} | bonds, angles, dihedrals, impropers | uncharged molecules |
-{peri} | mass, volume | mesocopic Peridynamic models |
+{peri} | mass, volume | mesoscopic Peridynamic models |
 {smd} | volume, kernel diameter, contact radius, mass | solid and fluid SPH particles |
 {sphere} | diameter, mass, angular velocity | granular models |
 {spin} | magnetic moment | system with magnetic particles |

doc/src/balance.txt

@@ -247,7 +247,7 @@ to {Niter} times.  After each dimension finishes, the imbalance factor
 is re-computed, and the balancing operation halts if the {stopthresh}
 criterion is met.
 
-A rebalance operation in a single dimension is performed using a
+A re-balance operation in a single dimension is performed using a
 recursive multisectioning algorithm, where the position of each
 cutting plane (line in 2d) in the dimension is adjusted independently.
 This is similar to a recursive bisectioning for a single value, except
@@ -261,11 +261,11 @@ information, so that they become closer together over time.  Thus as
 the recursion progresses, the count of particles on either side of the
 plane gets closer to the target value.
 
-Once the rebalancing is complete and final processor sub-domains
+Once the re-balancing is complete and final processor sub-domains
 assigned, particles are migrated to their new owning processor, and
 the balance procedure ends.
 
-NOTE: At each rebalance operation, the bisectioning for each cutting
+NOTE: At each re-balance operation, the bisectioning for each cutting
 plane (line in 2d) typically starts with low and high bounds separated
 by the extent of a processor's sub-domain in one dimension.  The size
 of this bracketing region shrinks by 1/2 every iteration.  Thus if
@@ -348,7 +348,7 @@ specified groups, its weight is not changed.  If it belongs to
 multiple groups, its weight is the product of the weight factors.
 
 This weight style is useful in combination with pair style
-"hybrid"_pair_hybrid.html, e.g. when combining a more costly manybody
+"hybrid"_pair_hybrid.html, e.g. when combining a more costly many-body
 potential with a fast pair-wise potential.  It is also useful when
 using "run_style respa"_run_style.html where some portions of the
 system have many bonded interactions and others none.  It assumes that
@@ -510,10 +510,13 @@ each processor, instead of 4, and "SQUARES" replaced by "CUBES".
 For 2d simulations, the {z} style cannot be used.  Nor can a "z"
 appear in {dimstr} for the {shift} style.
 
+Balancing through recursive bisectioning ({rcb} style) requires
+"comm_style tiled"_comm_style.html
+
 [Related commands:]
 
 "group"_group.html, "processors"_processors.html,
-"fix balance"_fix_balance.html
+"fix balance"_fix_balance.html, "comm_style"_comm_style.html
 
 [Default:] none
 :link(pizza,http://pizza.sandia.gov)

doc/src/bond_coeff.txt

@@ -56,25 +56,13 @@ corresponds to the 1st example above would be listed as
 
 :line
 
-Here is an alphabetic list of bond styles defined in LAMMPS.  Click on
-the style to display the formula it computes and coefficients
-specified by the associated "bond_coeff"_bond_coeff.html command.
+The list of all bond styles defined in LAMMPS is given on the
+"bond_style"_bond_style.html doc page.  They are also listed in more
+compact form on the "Commands bond"_Commands_bond.html doc page.
 
-Note that here are also additional bond styles submitted by users
-which are included in the LAMMPS distribution.  The full list of all
-bond styles is on the "Commands bond"_Commands_bond.html doc page.
-
-"bond_style none"_bond_none.html - turn off bonded interactions
-"bond_style hybrid"_bond_hybrid.html - define multiple styles of bond interactions :ul
-
-"bond_style class2"_bond_class2.html - COMPASS (class 2) bond
-"bond_style fene"_bond_fene.html - FENE (finite-extensible non-linear elastic) bond
-"bond_style fene/expand"_bond_fene_expand.html - FENE bonds with variable size particles
-"bond_style harmonic"_bond_harmonic.html - harmonic bond
-"bond_style morse"_bond_morse.html - Morse bond
-"bond_style nonlinear"_bond_nonlinear.html - nonlinear bond
-"bond_style quartic"_bond_quartic.html - breakable quartic bond
-"bond_style table"_bond_table.html - tabulated by bond length :ul
+On either of those pages, click on the style to display the formula it
+computes and its coefficients as specified by the associated
+bond_coeff command.
 
 :line
 

doc/src/bond_oxdna.txt

@@ -52,7 +52,7 @@ hydrogen-bonding interaction {oxdna/hbond} (see also documentation of
 "(Snodin)"_#oxdna2 bond style the analogous pair styles and an
 additional Debye-Hueckel pair style {oxdna2/dh} have to be defined.
 The coefficients in the above example have to be kept fixed and cannot
-be changed without reparametrizing the entire model.
+be changed without reparameterizing the entire model.
 
 Example input and data files for DNA duplexes can be found in
 examples/USER/cgdna/examples/oxDNA/ and /oxDNA2/.  A simple python

doc/src/bond_style.txt

@@ -65,9 +65,15 @@ Here is an alphabetic list of bond styles defined in LAMMPS.  Click on
 the style to display the formula it computes and coefficients
 specified by the associated "bond_coeff"_bond_coeff.html command.
 
-Note that there are also additional bond styles submitted by users
-which are included in the LAMMPS distribution.  The full list of all
-bond styles is on the "Commands bond"_Commands_bond.html doc page.
+Click on the style to display the formula it computes, any additional
+arguments specified in the bond_style command, and coefficients
+specified by the associated "bond_coeff"_bond_coeff.html command.
+
+There are also additional accelerated pair styles included in the
+LAMMPS distribution for faster performance on CPUs, GPUs, and KNLs.
+The individual style names on the "Commands bond"_Commands_bond.html
+doc page are followed by one or more of (g,i,k,o,t) to indicate which
+accelerated styles exist.
 
 "none"_bond_none.html - turn off bonded interactions
 "zero"_bond_zero.html - topology but no interactions

doc/src/comm_modify.txt

@@ -154,6 +154,6 @@ Communication mode {multi} is currently only available for
 
 [Default:]
 
-The option defauls are mode = single, group = all, cutoff = 0.0, vel =
+The option defaults are mode = single, group = all, cutoff = 0.0, vel =
 no.  The cutoff default of 0.0 means that ghost cutoff = neighbor
 cutoff = pairwise force cutoff + neighbor skin.

doc/src/comm_style.txt

@@ -51,7 +51,10 @@ decomposition will be the same, as described by
 commands.  The decomposition can be changed via the
 "balance"_balance.html or "fix balance"_fix_balance.html commands.
 
-[Restrictions:] none
+[Restrictions:]
+
+Communication style {tiled} cannot be used with {triclinic} simulation
+cells.
 
 [Related commands:]
 

doc/src/commands_list.txt

@@ -44,6 +44,7 @@ Commands :h1
    fix_modify
    group
    group2ndx
+   hyper
    if
    improper_coeff
    improper_style

doc/src/compute.txt

@@ -164,11 +164,6 @@ and what it does.  Here is an alphabetic list of compute styles
 available in LAMMPS.  They are also listed in more compact form on the
 "Commands compute"_Commands_compute.html doc page.
 
-There are also additional compute styles (not listed here) submitted
-by users which are included in the LAMMPS distribution.  The full list
-of all compute styles is on the "Commands
-compute"_Commands_compute.html doc page.
-
 There are also additional accelerated compute styles included in the
 LAMMPS distribution for faster performance on CPUs, GPUs, and KNLs.
 The individual style names on the "Commands
@@ -176,6 +171,7 @@ compute"_Commands_compute.html doc page are followed by one or more of
 (g,i,k,o,t) to indicate which accelerated styles exist.
 
 "ackland/atom"_compute_ackland_atom.html -
+"adf"_compute_adf.html - angular distribution function of triples of atoms
 "aggregate/atom"_compute_cluster_atom.html - aggregate ID for each atom
 "angle"_compute_angle.html -
 "angle/local"_compute_angle_local.html -
@@ -308,7 +304,7 @@ compute"_Commands_compute.html doc page are followed by one or more of
 "temp/uef"_compute_temp_uef.html -
 "ti"_compute_ti.html - thermodynamic integration free energy values
 "torque/chunk"_compute_torque_chunk.html - torque applied on each chunk
-"vacf"_compute_vacf.html - velocity-autocorrelation function of group of atoms
+"vacf"_compute_vacf.html - velocity auto-correlation function of group of atoms
 "vcm/chunk"_compute_vcm_chunk.html - velocity of center-of-mass for each chunk
 "voronoi/atom"_compute_voronoi_atom.html - Voronoi volume and neighbors for each atom
 "xrd"_compute_xrd.html - :ul

doc/src/compute_adf.txt

@@ -112,7 +112,7 @@ just a few dozen angles.
 Angles for each ADF are generated by double-looping over the list of
 neighbors of each central atom I,
 just as they would be in the force calculation for
-a threebody potential such as "Stillinger-Weber"_pair_sw.html.  
+a three-body potential such as "Stillinger-Weber"_pair_sw.html.
 The angle formed by central atom I and neighbor atoms J and K is included in an
 ADF if the following criteria are met:
 

doc/src/compute_basal_atom.txt

@@ -28,7 +28,7 @@ The results enable efficient identification and characterization of
 twins and grains in hexagonal close-packed structures.
 
 The output of the compute is thus the 3 components of a unit vector
-associdate with each atom.  The components are set to 0.0 for
+associated with each atom.  The components are set to 0.0 for
 atoms not in the group.
 
 Details of the calculation are given in "(Barrett)"_#Barrett.

doc/src/compute_bond_local.txt

@@ -68,7 +68,7 @@ in the bond, which is simply 1/2 m1 v1^2 + 1/2 m2 v2^2, where v1 and
 v2 are the magnitude of the velocity of the 2 atoms along the bond
 direction, after the COM velocity has been subtracted from each.
 
-The value {engrot} is the rotationsl kinetic energy of the two atoms
+The value {engrot} is the rotational kinetic energy of the two atoms
 in the bond, which is simply 1/2 m1 v1^2 + 1/2 m2 v2^2, where v1 and
 v2 are the magnitude of the velocity of the 2 atoms perpendicular to
 the bond direction, after the COM velocity has been subtracted from

doc/src/compute_chunk_atom.txt

@@ -210,7 +210,7 @@ between {crmin} and {crmax}.  For example, if {crmin} = 1.0 and
 {crmax} = 10.0 and {ncbin} = 9, then the first bin spans 1.0 < r <
 2.0, and the last bin spans 9.0 < r 10.0.  The geometry of the bins in
 the radial dimensions is the same whether the simulation box is
-orthogonal or triclinic; i.e. the concetric circles are not tilted or
+orthogonal or triclinic; i.e. the concentric circles are not tilted or
 scaled differently in the two different dimensions to transform them
 into ellipses.
 

doc/src/compute_cna_atom.txt

@@ -33,7 +33,7 @@ Currently, there are five kinds of CNA patterns LAMMPS recognizes:
 fcc = 1
 hcp = 2
 bcc = 3
-icosohedral = 4
+icosahedral = 4
 unknown = 5 :ul
 
 The value of the CNA pattern will be 0 for atoms not in the specified

doc/src/compute_damage_atom.txt

@@ -26,7 +26,7 @@ in a group.  This is a quantity relevant for "Peridynamics
 models"_pair_peri.html.  See "this document"_PDF/PDLammps_overview.pdf
 for an overview of LAMMPS commands for Peridynamics modeling.
 
-The "damage" of a Peridymaics particles is based on the bond breakage
+The "damage" of a Peridynamics particles is based on the bond breakage
 between the particle and its neighbors.  If all the bonds are broken
 the particle is considered to be fully damaged.
 

doc/src/compute_displace_atom.txt

@@ -57,7 +57,7 @@ correctly with time=0 atom coordinates from the restart file.
 
 :line
 
-The {refresh} option can be used in conjuction with the "dump_modify
+The {refresh} option can be used in conjunction with the "dump_modify
 refresh" command to generate incremental dump files.
 
 The definition and motivation of an incremental dump file is as

doc/src/compute_heat_flux.txt

@@ -82,11 +82,11 @@ first term in the equation for J above.
 
 The heat flux can be output every so many timesteps (e.g. via the
 "thermo_style custom"_thermo_style.html command).  Then as a
-post-processing operation, an autocorrelation can be performed, its
+post-processing operation, an auto-correlation can be performed, its
 integral estimated, and the Green-Kubo formula above evaluated.
 
 The "fix ave/correlate"_fix_ave_correlate.html command can calculate
-the autocorrelation.  The trap() function in the
+the auto-correlation.  The trap() function in the
 "variable"_variable.html command can calculate the integral.
 
 An example LAMMPS input script for solid Ar is appended below.  The

doc/src/compute_msd.txt

@@ -50,7 +50,7 @@ The value of the displacement will be
 
 If the {com} option is set to {yes} then the effect of any drift in
 the center-of-mass of the group of atoms is subtracted out before the
-displacment of each atom is calculated.
+displacement of each atom is calculated.
 
 If the {average} option is set to {yes} then the reference position of
 an atom is based on the average position of that atom, corrected for

doc/src/compute_msd_nongauss.txt

@@ -48,7 +48,7 @@ others.
 
 If the {com} option is set to {yes} then the effect of any drift in
 the center-of-mass of the group of atoms is subtracted out before the
-displacment of each atom is calculated.
+displacement of each atom is calculated.
 
 See the "compute msd"_compute_msd.html doc page for further important
 NOTEs, which also apply to this compute.

doc/src/compute_pair.txt

@@ -15,7 +15,7 @@ compute ID group-ID pair pstyle \[nstyle\] \[evalue\]  :pre
 ID, group-ID are documented in "compute"_compute.html command :ulb,l
 pair = style name of this compute command :l
 pstyle = style name of a pair style that calculates additional values :l
-nsub = {n}-instance of a substyle, if a pair style is used multiple times in a hybrid style :l
+nsub = {n}-instance of a sub-style, if a pair style is used multiple times in a hybrid style :l
 {evalue} = {epair} or {evdwl} or {ecoul} or blank (optional) :l
 :ule
 

doc/src/compute_plasticity_atom.txt

@@ -30,7 +30,7 @@ The plasticity for a Peridynamic particle is the so-called consistency
 parameter (lambda).  For elastic deformation lambda = 0, otherwise
 lambda > 0 for plastic deformation.  For details, see
 "(Mitchell)"_#Mitchell and the PDF doc included in the LAMMPS
-distro in "doc/PDF/PDLammps_EPS.pdf"_PDF/PDLammps_EPS.pdf.
+distribution in "doc/PDF/PDLammps_EPS.pdf"_PDF/PDLammps_EPS.pdf.
 
 This command can be invoked for one of the Peridynamic "pair
 styles"_pair_peri.html: peri/eps.