patch 2Aug18

Collected small fixes for the next patch release

.github/CODEOWNERS

@@ -9,13 +9,51 @@ lib/kokkos/*          @stanmoore1
 lib/molfile/*         @akohlmey
 lib/qmmm/*            @akohlmey
 lib/vtk/*             @rbberger
+lib/kim/*             @ellio167
 
-# packages
-src/KOKKOS            @stanmoore1
-src/USER-CGSDK        @akohlmey
-src/USER-COLVARS      @giacomofiorin
-src/USER-OMP          @akohlmey
-src/USER-QMMM         @akohlmey
+# whole packages
+src/COMPRESS/*        @akohlmey
+src/GPU/*             @ndtrung81
+src/KOKKOS/*          @stanmoore1
+src/KIM/*             @ellio167
+src/LATTE/*           @cnegre
+src/SPIN/*            @julient31
+src/USER-CGDNA/*      @ohenrich
+src/USER-CGSDK/*      @akohlmey
+src/USER-COLVARS/*    @giacomofiorin
+src/USER-DPD/*        @timattox
+src/USER-INTEL/*      @wmbrownintel
+src/USER-MANIFOLD/*   @Pakketeretet2
+src/USER-MEAMC/*      @martok
+src/USER-MOFFF/*      @hheenen
+src/USER-MOLFILE/*    @akohlmey
+src/USER-NETCDF/*     @pastewka
+src/USER-PHONON/*     @lingtikong
+src/USER-OMP/*        @akohlmey
+src/USER-QMMM/*       @akohlmey
+src/USER-REAXC/*      @hasanmetin
+src/USER-TALLY/*      @akohlmey
+src/USER-UEF/*        @danicholson
+src/USER-VTK/*        @rbberger
+
+# individual files in packages
+src/GPU/pair_vashishta_gpu.*        @andeplane
+src/KOKKOS/pair_vashishta_kokkos.*  @andeplane
+src/MANYBODY/pair_vashishta_table.* @andeplane
+src/USER-MISC/fix_bond_react.*      @jrgissing
+src/USER-MISC/*_grem.*              @dstelter92
 
 # tools
 tools/msi2lmp/*       @akohlmey
+tools/emacs/*         @HaoZeke
+
+# cmake
+cmake/*               @junghans @rbberger
+
+# python
+python/*              @rbberger
+
+# docs
+doc/utils/*/*         @rbberger
+doc/Makefile          @rbberger
+doc/README            @rbberger

README

@@ -25,7 +25,7 @@ The LAMMPS distribution includes the following files and directories:
 README			   this file
 LICENSE			   the GNU General Public License (GPL)
 bench			   benchmark problems
-couple			   code coupling examples using LAMMPS as a library
+cmake			   CMake build system
 doc			   documentation
 examples		   simple test problems
 lib			   libraries LAMMPS can be linked with

cmake/Modules/FindFFTW2.cmake

@@ -1,22 +0,0 @@
-# - Find fftw2
-# Find the native FFTW2 headers and libraries.
-#
-#  FFTW2_INCLUDE_DIRS - where to find fftw2.h, etc.
-#  FFTW2_LIBRARIES    - List of libraries when using fftw2.
-#  FFTW2_FOUND        - True if fftw2 found.
-#
-
-find_path(FFTW2_INCLUDE_DIR fftw.h)
-
-find_library(FFTW2_LIBRARY NAMES fftw)
-
-set(FFTW2_LIBRARIES ${FFTW2_LIBRARY})
-set(FFTW2_INCLUDE_DIRS ${FFTW2_INCLUDE_DIR})
-
-include(FindPackageHandleStandardArgs)
-# handle the QUIETLY and REQUIRED arguments and set FFTW2_FOUND to TRUE
-# if all listed variables are TRUE
-
-find_package_handle_standard_args(FFTW2 DEFAULT_MSG FFTW2_LIBRARY FFTW2_INCLUDE_DIR)
-
-mark_as_advanced(FFTW2_INCLUDE_DIR FFTW2_LIBRARY )

cmake/Modules/FindFFTW3F.cmake

@@ -0,0 +1,25 @@
+# - Find fftw3f
+# Find the native FFTW3F headers and libraries.
+#
+#  FFTW3F_INCLUDE_DIRS - where to find fftw3f.h, etc.
+#  FFTW3F_LIBRARIES    - List of libraries when using fftw3f.
+#  FFTW3F_FOUND        - True if fftw3f found.
+#
+
+find_package(PkgConfig)
+
+pkg_check_modules(PC_FFTW3F fftw3f)
+find_path(FFTW3F_INCLUDE_DIR fftw3.h HINTS ${PC_FFTW3F_INCLUDE_DIRS})
+
+find_library(FFTW3F_LIBRARY NAMES fftw3f HINTS ${PC_FFTW3F_LIBRARY_DIRS})
+
+set(FFTW3F_LIBRARIES ${FFTW3F_LIBRARY})
+set(FFTW3F_INCLUDE_DIRS ${FFTW3F_INCLUDE_DIR})
+
+include(FindPackageHandleStandardArgs)
+# handle the QUIETLY and REQUIRED arguments and set FFTW3F_FOUND to TRUE
+# if all listed variables are TRUE
+
+find_package_handle_standard_args(FFTW3F DEFAULT_MSG FFTW3F_LIBRARY FFTW3F_INCLUDE_DIR)
+
+mark_as_advanced(FFTW3F_INCLUDE_DIR FFTW3F_LIBRARY )

cmake/Modules/FindMSCG.cmake

@@ -0,0 +1,22 @@
+# - Find mscg
+# Find the native MSCG headers and libraries.
+#
+#  MSCG_INCLUDE_DIRS - where to find mscg.h, etc.
+#  MSCG_LIBRARIES    - List of libraries when using mscg.
+#  MSCG_FOUND        - True if mscg found.
+#
+
+find_path(MSCG_INCLUDE_DIR mscg.h PATH_SUFFIXES mscg)
+
+find_library(MSCG_LIBRARY NAMES mscg)
+
+set(MSCG_LIBRARIES ${MSCG_LIBRARY})
+set(MSCG_INCLUDE_DIRS ${MSCG_INCLUDE_DIR})
+
+include(FindPackageHandleStandardArgs)
+# handle the QUIETLY and REQUIRED arguments and set MSCG_FOUND to TRUE
+# if all listed variables are TRUE
+
+find_package_handle_standard_args(MSCG DEFAULT_MSG MSCG_LIBRARY MSCG_INCLUDE_DIR)
+
+mark_as_advanced(MSCG_INCLUDE_DIR MSCG_LIBRARY )

cmake/Modules/StyleHeaderUtils.cmake

@@ -45,14 +45,10 @@ function(FindStyleHeadersExt path style_class extension headers sources)
 endfunction(FindStyleHeadersExt)
 
 function(CreateStyleHeader path filename)
-    math(EXPR N "${ARGC}-2")
-
     set(temp "")
-    if(N GREATER 0)
-        math(EXPR ARG_END   "${ARGC}-1")
- 
-        foreach(IDX RANGE 2 ${ARG_END})
-            list(GET ARGV ${IDX} FNAME)
+    if(ARGC GREATER 2)
+        list(REMOVE_AT ARGV 0 1)
+        foreach(FNAME ${ARGV})
             get_filename_component(FNAME ${FNAME} NAME)
             set(temp "${temp}#include \"${FNAME}\"\n")
         endforeach()
@@ -107,35 +103,6 @@ function(RegisterStyles search_path)
     FindStyleHeaders(${search_path} REGION_CLASS    region_    REGION    ) # region    ) # domain
 endfunction(RegisterStyles)
 
-function(RemovePackageHeader headers pkg_header)
-    get_property(hlist GLOBAL PROPERTY ${headers})
-    list(REMOVE_ITEM hlist ${pkg_header})
-    set_property(GLOBAL PROPERTY ${headers} "${hlist}")
-endfunction(RemovePackageHeader)
-
-function(DetectAndRemovePackageHeader fname)
-    RemovePackageHeader(ANGLE     ${fname})
-    RemovePackageHeader(ATOM_VEC  ${fname})
-    RemovePackageHeader(BODY      ${fname})
-    RemovePackageHeader(BOND      ${fname})
-    RemovePackageHeader(COMMAND   ${fname})
-    RemovePackageHeader(COMPUTE   ${fname})
-    RemovePackageHeader(DIHEDRAL  ${fname})
-    RemovePackageHeader(DUMP      ${fname})
-    RemovePackageHeader(FIX       ${fname})
-    RemovePackageHeader(IMPROPER  ${fname})
-    RemovePackageHeader(INTEGRATE ${fname})
-    RemovePackageHeader(KSPACE    ${fname})
-    RemovePackageHeader(MINIMIZE  ${fname})
-    RemovePackageHeader(NBIN      ${fname})
-    RemovePackageHeader(NPAIR     ${fname})
-    RemovePackageHeader(NSTENCIL  ${fname})
-    RemovePackageHeader(NTOPO     ${fname})
-    RemovePackageHeader(PAIR      ${fname})
-    RemovePackageHeader(READER    ${fname})
-    RemovePackageHeader(REGION    ${fname})
-endfunction(DetectAndRemovePackageHeader)
-
 function(RegisterStylesExt search_path extension sources)
     FindStyleHeadersExt(${search_path} ANGLE_CLASS     ${extension}  ANGLE     ${sources})
     FindStyleHeadersExt(${search_path} ATOM_CLASS      ${extension}  ATOM_VEC  ${sources})
@@ -181,3 +148,21 @@ function(GenerateStyleHeaders output_path)
     GenerateStyleHeader(${output_path} READER     reader    ) # read_dump
     GenerateStyleHeader(${output_path} REGION     region    ) # domain
 endfunction(GenerateStyleHeaders)
+
+function(DetectBuildSystemConflict lammps_src_dir)
+  if(ARGC GREATER 1)
+    list(REMOVE_AT ARGV 0)
+    foreach(SRC_FILE ${ARGV})
+        get_filename_component(FILENAME ${SRC_FILE} NAME)
+        if(EXISTS ${lammps_src_dir}/${FILENAME})
+            message(FATAL_ERROR "\n########################################################################\n"
+                                  "Found package(s) installed by the make-based build system\n"
+                                  "\n"
+                                  "Please run\n"
+                                  "make -C ${lammps_src_dir} no-all purge\n"
+                                  "to uninstall\n"
+                                  "########################################################################")
+        endif()
+    endforeach()
+  endif()
+endfunction(DetectBuildSystemConflict)

cmake/etc/profile.d/lammps.csh.in

@@ -0,0 +1,2 @@
+# set environment for LAMMPS executables to find potential files
+if ( "$?LAMMPS_POTENTIALS" == 0 ) setenv LAMMPS_POTENTIALS @LAMMPS_POTENTIALS_DIR@

cmake/etc/profile.d/lammps.sh.in

@@ -0,0 +1,2 @@
+# set environment for LAMMPS executables to find potential files
+export LAMMPS_POTENTIALS=${LAMMPS_POTENTIALS-@LAMMPS_POTENTIALS_DIR@}

cmake/pkgconfig/liblammps.pc.in

@@ -13,6 +13,6 @@ Description: Large-scale Atomic/Molecular Massively Parallel Simulator Library
 URL: http://lammps.sandia.gov
 Version:
 Requires:
-Libs: -L${libdir} -llammps@LAMMPS_MACHINE@
+Libs: -L${libdir} -llammps@LIB_SUFFIX@@
 Libs.private: -lm
 Cflags: -I${includedir} @LAMMPS_API_DEFINES@

cmake/presets/all_off.cmake

@@ -0,0 +1,22 @@
+set(STANDARD_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE GPU
+                      GRANULAR KIM KOKKOS KSPACE LATTE MANYBODY MC MEAM MISC
+                      MOLECULE MPIIO MSCG OPT PERI POEMS
+                      PYTHON QEQ REAX REPLICA RIGID SHOCK SNAP SRD VORONOI)
+
+set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVARS
+                  USER-DIFFRACTION USER-DPD USER-DRUDE USER-EFF USER-FEP USER-H5MD
+                  USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
+                  USER-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-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)
+
+set(ALL_PACKAGES ${STANDARD_PACKAGES} ${USER_PACKAGES})
+
+foreach(PKG ${ALL_PACKAGES})
+  set(PKG_${PKG} OFF CACHE BOOL "" FORCE)
+endforeach()

cmake/presets/all_on.cmake

@@ -0,0 +1,22 @@
+set(STANDARD_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE GPU
+                      GRANULAR KIM KOKKOS KSPACE LATTE MANYBODY MC MEAM MISC
+                      MOLECULE MPIIO MSCG OPT PERI POEMS
+                      PYTHON QEQ REAX REPLICA RIGID SHOCK SNAP SRD VORONOI)
+
+set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVARS
+                  USER-DIFFRACTION USER-DPD USER-DRUDE USER-EFF USER-FEP USER-H5MD
+                  USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
+                  USER-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-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)
+
+set(ALL_PACKAGES ${STANDARD_PACKAGES} ${USER_PACKAGES})
+
+foreach(PKG ${ALL_PACKAGES})
+  set(PKG_${PKG} ON CACHE BOOL "" FORCE)
+endforeach()

cmake/presets/manual_selection.cmake

@@ -0,0 +1,69 @@
+set(PKG_ASPHERE OFF CACHE BOOL "" FORCE)
+set(PKG_BODY OFF CACHE BOOL "" FORCE)
+set(PKG_CLASS2 OFF CACHE BOOL "" FORCE)
+set(PKG_COLLOID OFF CACHE BOOL "" FORCE)
+set(PKG_COMPRESS OFF CACHE BOOL "" FORCE)
+set(PKG_CORESHELL OFF CACHE BOOL "" FORCE)
+set(PKG_DIPOLE OFF CACHE BOOL "" FORCE)
+set(PKG_GPU OFF CACHE BOOL "" FORCE)
+set(PKG_GRANULAR OFF CACHE BOOL "" FORCE)
+set(PKG_KIM OFF CACHE BOOL "" FORCE)
+set(PKG_KOKKOS OFF CACHE BOOL "" FORCE)
+set(PKG_KSPACE OFF CACHE BOOL "" FORCE)
+set(PKG_LATTE OFF CACHE BOOL "" FORCE)
+set(PKG_LIB OFF CACHE BOOL "" FORCE)
+set(PKG_MANYBODY OFF CACHE BOOL "" FORCE)
+set(PKG_MC OFF CACHE BOOL "" FORCE)
+set(PKG_MEAM OFF CACHE BOOL "" FORCE)
+set(PKG_MISC OFF CACHE BOOL "" FORCE)
+set(PKG_MOLECULE OFF CACHE BOOL "" FORCE)
+set(PKG_MPIIO OFF CACHE BOOL "" FORCE)
+set(PKG_MSCG OFF CACHE BOOL "" FORCE)
+set(PKG_OPT OFF CACHE BOOL "" FORCE)
+set(PKG_PERI OFF CACHE BOOL "" FORCE)
+set(PKG_POEMS OFF CACHE BOOL "" FORCE)
+set(PKG_PYTHOFF OFF CACHE BOOL "" FORCE)
+set(PKG_QEQ OFF CACHE BOOL "" FORCE)
+set(PKG_REAX OFF CACHE BOOL "" FORCE)
+set(PKG_REPLICA OFF CACHE BOOL "" FORCE)
+set(PKG_RIGID OFF CACHE BOOL "" FORCE)
+set(PKG_SHOCK OFF CACHE BOOL "" FORCE)
+set(PKG_SNAP OFF CACHE BOOL "" FORCE)
+set(PKG_SRD OFF CACHE BOOL "" FORCE)
+set(PKG_VOROFFOI OFF CACHE BOOL "" FORCE)
+
+set(PKG_USER OFF CACHE BOOL "" FORCE)
+set(PKG_USER-ATC OFF CACHE BOOL "" FORCE)
+set(PKG_USER-AWPMD OFF CACHE BOOL "" FORCE)
+set(PKG_USER-BOCS OFF CACHE BOOL "" FORCE)
+set(PKG_USER-CGDNA OFF CACHE BOOL "" FORCE)
+set(PKG_USER-CGSDK OFF CACHE BOOL "" FORCE)
+set(PKG_USER-COLVARS OFF CACHE BOOL "" FORCE)
+set(PKG_USER-DIFFRACTIOFF OFF CACHE BOOL "" FORCE)
+set(PKG_USER-DPD OFF CACHE BOOL "" FORCE)
+set(PKG_USER-DRUDE OFF CACHE BOOL "" FORCE)
+set(PKG_USER-EFF OFF CACHE BOOL "" FORCE)
+set(PKG_USER-FEP OFF CACHE BOOL "" FORCE)
+set(PKG_USER-H5MD OFF CACHE BOOL "" FORCE)
+set(PKG_USER-INTEL OFF CACHE BOOL "" FORCE)
+set(PKG_USER-LB OFF CACHE BOOL "" FORCE)
+set(PKG_USER-MANIFOLD OFF CACHE BOOL "" FORCE)
+set(PKG_USER-MEAMC OFF CACHE BOOL "" FORCE)
+set(PKG_USER-MESO OFF CACHE BOOL "" FORCE)
+set(PKG_USER-MGPT OFF CACHE BOOL "" FORCE)
+set(PKG_USER-MISC OFF CACHE BOOL "" FORCE)
+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-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-SMD OFF CACHE BOOL "" FORCE)
+set(PKG_USER-SMTBQ OFF CACHE BOOL "" FORCE)
+set(PKG_USER-SPH OFF CACHE BOOL "" FORCE)
+set(PKG_USER-TALLY OFF CACHE BOOL "" FORCE)
+set(PKG_USER-UEF OFF CACHE BOOL "" FORCE)
+set(PKG_USER-VTK OFF CACHE BOOL "" FORCE)

cmake/presets/nolib.cmake

@@ -0,0 +1,22 @@
+set(STANDARD_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE GPU
+                      GRANULAR KIM KOKKOS KSPACE LATTE MANYBODY MC MEAM MISC
+                      MOLECULE MPIIO MSCG OPT PERI POEMS
+                      PYTHON QEQ REAX REPLICA RIGID SHOCK SNAP SRD VORONOI)
+
+set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVARS
+                  USER-DIFFRACTION USER-DPD USER-DRUDE USER-EFF USER-FEP USER-H5MD
+                  USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
+                  USER-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-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)
+
+set(ALL_PACKAGES ${STANDARD_PACKAGES} ${USER_PACKAGES})
+
+foreach(PKG ${PACKAGES_WITH_LIB})
+  set(PKG_${PKG} OFF CACHE BOOL "" FORCE)
+endforeach()

cmake/presets/std.cmake

@@ -0,0 +1,22 @@
+set(STANDARD_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE GPU
+                      GRANULAR KIM KOKKOS KSPACE LATTE MANYBODY MC MEAM MISC
+                      MOLECULE MPIIO MSCG OPT PERI POEMS
+                      PYTHON QEQ REAX REPLICA RIGID SHOCK SNAP SRD VORONOI)
+
+set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVARS
+                  USER-DIFFRACTION USER-DPD USER-DRUDE USER-EFF USER-FEP USER-H5MD
+                  USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
+                  USER-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-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)
+
+set(ALL_PACKAGES ${STANDARD_PACKAGES} ${USER_PACKAGES})
+
+foreach(PKG ${STANDARD_PACKAGES})
+  set(PKG_${PKG} ON CACHE BOOL "" FORCE)
+endforeach()

cmake/presets/std_nolib.cmake

@@ -0,0 +1,26 @@
+set(STANDARD_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE GPU
+                      GRANULAR KIM KOKKOS KSPACE LATTE MANYBODY MC MEAM MISC
+                      MOLECULE MPIIO MSCG OPT PERI POEMS
+                      PYTHON QEQ REAX REPLICA RIGID SHOCK SNAP SRD VORONOI)
+
+set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVARS
+                  USER-DIFFRACTION USER-DPD USER-DRUDE USER-EFF USER-FEP USER-H5MD
+                  USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
+                  USER-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-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)
+
+set(ALL_PACKAGES ${STANDARD_PACKAGES} ${USER_PACKAGES})
+
+foreach(PKG ${STANDARD_PACKAGES})
+  set(PKG_${PKG} ON CACHE BOOL "" FORCE)
+endforeach()
+
+foreach(PKG ${PACKAGES_WITH_LIB})
+  set(PKG_${PKG} OFF CACHE BOOL "" FORCE)
+endforeach()

cmake/presets/user.cmake

@@ -0,0 +1,22 @@
+set(STANDARD_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE GPU
+                      GRANULAR KIM KOKKOS KSPACE LATTE MANYBODY MC MEAM MISC
+                      MOLECULE MPIIO MSCG OPT PERI POEMS
+                      PYTHON QEQ REAX REPLICA RIGID SHOCK SNAP SRD VORONOI)
+
+set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVARS
+                  USER-DIFFRACTION USER-DPD USER-DRUDE USER-EFF USER-FEP USER-H5MD
+                  USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
+                  USER-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-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)
+
+set(ALL_PACKAGES ${STANDARD_PACKAGES} ${USER_PACKAGES})
+
+foreach(PKG ${USER_PACKAGES})
+  set(PKG_${PKG} ON CACHE BOOL "" FORCE)
+endforeach()

doc/Makefile

@@ -9,6 +9,7 @@ TXT2RST       = $(VENV)/bin/txt2rst
 ANCHORCHECK   = $(VENV)/bin/doc_anchor_check
 
 PYTHON        = $(shell which python3)
+VIRTUALENV     = virtualenv
 HAS_PYTHON3    = NO
 HAS_VIRTUALENV = NO
 
@@ -16,7 +17,13 @@ ifeq ($(shell which python3 >/dev/null 2>&1; echo $$?), 0)
 HAS_PYTHON3 = YES
 endif
 
+ifeq ($(shell which virtualenv-3 >/dev/null 2>&1; echo $$?), 0)
+VIRTUALENV     = virtualenv-3
+HAS_VIRTUALENV = YES
+endif
+
 ifeq ($(shell which virtualenv >/dev/null 2>&1; echo $$?), 0)
+VIRTUALENV     = virtualenv
 HAS_VIRTUALENV = YES
 endif
 
@@ -42,11 +49,11 @@ help:
 
 # ------------------------------------------
 
-clean-all:
+clean-all: clean
 	rm -rf $(BUILDDIR)/* utils/txt2html/txt2html.exe
 
 clean:
-	rm -rf $(RSTDIR) html
+	rm -rf $(RSTDIR) html old epub
 	rm -rf spelling
 
 clean-spelling:
@@ -150,7 +157,7 @@ $(RSTDIR)/%.rst : src/%.txt $(TXT2RST)
 	@(\
 		mkdir -p $(RSTDIR) ; \
 		. $(VENV)/bin/activate ;\
-		txt2rst $< > $@ ;\
+		txt2rst -v $< > $@ ;\
 		deactivate ;\
 	)
 
@@ -158,7 +165,7 @@ $(VENV):
 	@if [ "$(HAS_PYTHON3)" == "NO" ] ; then echo "Python3 was not found! Please check README.md for further instructions" 1>&2; exit 1; fi
 	@if [ "$(HAS_VIRTUALENV)" == "NO" ] ; then echo "virtualenv was not found! Please check README.md for further instructions" 1>&2; exit 1; fi
 	@( \
-		virtualenv -p $(PYTHON) $(VENV); \
+		$(VIRTUALENV) -p $(PYTHON) $(VENV); \
 		. $(VENV)/bin/activate; \
 		pip install Sphinx; \
 		pip install sphinxcontrib-images; \

doc/src/Developer/developer.tex

@@ -449,15 +449,15 @@ Writing fixes is a flexible way of extending LAMMPS.  Users can
 implement many things using fixes:
 
 \begin{itemize}
-\item changing particles attributes (positions, velocities, forces, etc.). 
+\item changing particles attributes (positions, velocities, forces, etc.).
 Example: FixFreeze.
 \item reading/writing data. Example: FixRestart.
 \item implementing boundary conditions. Example: FixWall.
-\item saving information about particles for future use (previous positions, 
+\item saving information about particles for future use (previous positions,
 for instance). Example: FixStoreState.
 \end{itemize}
 
-All fixes are derived from class Fix and must have constructor with the 
+All fixes are derived from class Fix and must have constructor with the
 signature: FixMine(class LAMMPS *, int, char **).
 
 Every fix must be registered in LAMMPS by writing the following lines
@@ -476,9 +476,9 @@ is the name of the class. This code allows LAMMPS to find your fix
 when it parses input script. In addition, your fix header must be
 included in the file "style\_fix.h". In case if you use LAMMPS make,
 this file is generated automatically - all files starting with prefix
-fix\_ are included, so call your header the same way. Otherwise, don<EFBFBD>t
+fix\_ are included, so call your header the same way. Otherwise, don't
 forget to add your include into "style\_fix.h".
- 
+
 Let's write a simple fix which will print average velocity at the end
 of each timestep. First of all, implement a constructor:
 
@@ -487,11 +487,11 @@ of each timestep. First of all, implement a constructor:
 FixPrintVel::FixPrintVel(LAMMPS *lmp, int narg, char **arg)
 : Fix(lmp, narg, arg)
 {
-  if (narg < 4) 
+  if (narg < 4)
       error->all(FLERR,"Illegal fix print command");
- 
+
   nevery = atoi(arg[3]);
-  if (nevery <= 0) 
+  if (nevery <= 0)
       error->all(FLERR,"Illegal fix print command");
 }
   \end{verbatim}
@@ -545,7 +545,7 @@ void FixPrintVel::end_of_step()
 {
   // for add3, scale3
   using namespace MathExtra;
-  
+
   double** v = atom->v;
   int nlocal = atom->nlocal;
   double localAvgVel[4]; // 4th element for particles count
@@ -559,7 +559,7 @@ void FixPrintVel::end_of_step()
   MPI_Allreduce(localAvgVel, globalAvgVel, 4, MPI_DOUBLE, MPI_SUM, world);
   scale3(1.0 / globalAvgVel[3], globalAvgVel);
   if (comm->me == 0) {
-    printf("\%e, \%e, \%e\n", 
+    printf("\%e, \%e, \%e\n",
       globalAvgVel[0], globalAvgVel[1], globalAvgVel[2]);
   }
 }
@@ -607,14 +607,15 @@ this situation there are several methods which should be implemented:
 
 \begin{itemize}
 \item \verb|double memory_usage| - return how much memory fix uses
-\item \verb|void grow_arrays(int)| - do reallocation of the per particle arrays 
+\item \verb|void grow_arrays(int)| - do reallocation of the per particle arrays
   in your fix
-\item \verb|void copy_arrays(int i, int j)| - copy i-th per-particle information 
-  to j-th. Used when atoms sorting is performed
+\item \verb|void copy_arrays(int i, int j, int delflag)| - copy i-th per-particle
+  information to j-th. Used when atoms sorting is performed. if delflag is set
+  and atom j owns a body, move the body information to atom i.
 \item \verb|void set_arrays(int i)| - sets i-th particle related information to zero
 \end{itemize}
 
-Note, that if your class implements these methods, it must call add calls of 
+Note, that if your class implements these methods, it must call add calls of
 add\_callback and delete\_callback to constructor and destructor:
 
 \begin{center}
@@ -654,7 +655,7 @@ void FixSavePos::grow_arrays(int nmax)
     memory->grow(this->x, nmax, 3, "FixSavePos:x");
 }
 
-void FixSavePos::copy_arrays(int i, int j)
+void FixSavePos::copy_arrays(int i, int j, int delflag)
 {
     memcpy(this->x[j], this->x[i], sizeof(double) * 3);
 }
@@ -670,7 +671,7 @@ int FixSavePos::pack_exchange(int i, double *buf)
   buf[m++] = x[i][0];
   buf[m++] = x[i][1];
   buf[m++] = x[i][2];
-  
+
   return m;
 }
 

doc/src/Eqs/dihedral_table_cut.tex

@@ -0,0 +1,11 @@
+\documentclass[12pt]{article}
+\pagestyle{empty}
+\begin{document}
+
+\begin{eqnarray*}
+        f(\theta) & = & K \qquad\qquad\qquad\qquad\qquad\qquad \theta < \theta_1 \\
+        f(\theta) & = & K \left(1-\frac{(\theta - \theta_1)^2}{(\theta_2 - \theta_1)^2}\right) \qquad \theta_1 < \theta < \theta_2
+\end{eqnarray*}
+
+\end{document}
+

doc/src/Eqs/fix_integration_spin_stdecomposition.tex

@@ -0,0 +1,40 @@
+\documentclass[preview]{standalone}
+\usepackage{varwidth}
+\usepackage[utf8x]{inputenc}
+\usepackage{amsmath,amssymb,amsthm,bm,tikz}
+\usetikzlibrary{automata,arrows,shapes,snakes}
+\begin{document}
+\begin{varwidth}{50in}
+\begin{tikzpicture}
+
+%Global
+\node (v1) at (0,6.0) [draw,thick,minimum width=0.2cm,minimum height=0.2cm] { $\bm{v} \leftarrow \bm{v}+L_v.\Delta t/2$ };
+\node (s1) at (0,4.5) [draw,thick,minimum width=0.2cm,minimum height=0.2cm] { $\bm{s} \leftarrow \bm{s}+L_s.\Delta t/2$ };
+\node (r)  at (0,3.0) [draw,thick,minimum width=0.2cm,minimum height=0.2cm] { $\bm{r} \leftarrow \bm{r}+L_r.\Delta t$ };
+\node (s2) at (0,1.5) [draw,thick,minimum width=0.2cm,minimum height=0.2cm] { $\bm{s} \leftarrow \bm{s}+L_s.\Delta t/2$ };
+\node (v2) at (0,0.0) [draw,thick,minimum width=0.2cm,minimum height=0.2cm] { $\bm{v} \leftarrow \bm{v}+L_v.\Delta t/2$ };
+
+\draw[line width=2pt, ->] (v1) -- (s1);
+\draw[line width=2pt, ->] (s1) -- (r);
+\draw[line width=2pt, ->] (r) -- (s2);
+\draw[line width=2pt, ->] (s2) -- (v2);
+
+%Spin
+\node (s01) at (6,6.0) [draw,thick,minimum width=0.2cm,minimum height=0.2cm] {$\bm{s}_0 \leftarrow \bm{s}_0+L_{s_0}.\Delta t/4$ };
+\node (sN1) at (6,4.5) [draw,thick,minimum width=0.2cm,minimum height=0.2cm] {$\bm{s}_{\rm N-1}\leftarrow\bm{s}_{\rm N-1}+L_{s_{\rm N-1}}.\Delta t/4$};
+\node (sN)  at (6,3.0) [draw,thick,minimum width=0.2cm,minimum height=0.2cm] {$\bm{s}_{\rm N} \leftarrow \bm{s}_{\rm N}+L_{s_{\rm N}}.\Delta t/2$ };
+\node (sN2) at (6,1.5) [draw,thick,minimum width=0.2cm,minimum height=0.2cm] {$\bm{s}_{\rm N-1}\leftarrow\bm{s}_{\rm N-1}+L_{s_{\rm N-1}}.\Delta t/4$};
+\node (s02) at (6,0.0) [draw,thick,minimum width=0.2cm,minimum height=0.2cm] {$\bm{s}_0 \leftarrow \bm{s}_0+L_{s_0}.\Delta t/4$ };
+
+\draw[line width=2pt,dashed, ->] (s01) -- (sN1);
+\draw[line width=2pt, ->] (sN1) -- (sN);
+\draw[line width=2pt, ->] (sN) -- (sN2);
+\draw[line width=2pt,dashed, ->] (sN2) -- (s02);
+
+%from Global to Spin
+\draw[line width=2pt, dashed, ->] (s1) -- (s01.west);
+\draw[line width=2pt, dashed, ->] (s1) -- (s02.west);
+
+\end{tikzpicture}
+\end{varwidth}
+\end{document}

doc/src/Eqs/fix_langevin_spin_sLLG.tex

@@ -0,0 +1,14 @@
+\documentclass[preview]{standalone}
+\usepackage{varwidth}
+\usepackage[utf8x]{inputenc}
+\usepackage{amsmath, amssymb, graphics, setspace}
+
+\begin{document}
+\begin{varwidth}{50in}
+  \begin{equation}
+    \frac{d \vec{s}_{i}}{dt} = \frac{1}{\left(1+\lambda^2 \right)} \left( \left(
+    \vec{\omega}_{i} +\vec{\eta} \right) \times \vec{s}_{i} + \lambda\, \vec{s}_{i}
+  \times\left( \vec{\omega}_{i} \times\vec{s}_{i} \right) \right), \nonumber
+  \end{equation}
+\end{varwidth}
+\end{document}

doc/src/Eqs/force_spin_aniso.tex

@@ -0,0 +1,11 @@
+\documentclass[preview]{standalone}
+\usepackage{varwidth}
+\usepackage[utf8x]{inputenc}
+\usepackage{amsmath,amssymb,amsthm,bm}
+\begin{document}
+\begin{varwidth}{50in}
+  \begin{equation}
+    \bm{H}_{aniso}  = -\sum_{{ i}=1}^{N} K_{an}(\bm{r}_{i})\, \left( \vec{s}_{i} \cdot \vec{n}_{i} \right)^2, \nonumber
+  \end{equation}
+\end{varwidth}
+\end{document}

doc/src/Eqs/force_spin_zeeman.tex

@@ -0,0 +1,11 @@
+\documentclass[preview]{standalone}
+\usepackage{varwidth}
+\usepackage[utf8x]{inputenc}
+\usepackage{amsmath,amssymb,amsthm,bm}
+\begin{document}
+\begin{varwidth}{50in}
+  \begin{equation}
+    \bm{H}_{zeeman} = -\mu_{B}\mu_0\sum_{i=0}^{N}g_{i} \vec{s}_{i} \cdot \vec{H}_{ext} \nonumber 
+  \end{equation}
+\end{varwidth}
+\end{document}

doc/src/Eqs/pair_body_rounded.tex

@@ -0,0 +1,13 @@
+\documentstyle[12pt]{article}
+
+\begin{document}
+
+\begin{eqnarray*}
+ F_n &=& k_n \delta_n - c_n v_n, \qquad \delta_n \le 0 \\
+     &=& -k_{na} \delta_n - c_n v_n, \qquad 0 < \delta_n \le r_c \\
+     &=& 0 \qquad \qquad \qquad \qquad \delta_n > r_c \\
+ F_t &=& \mu k_n \delta_n - c_t v_t, \qquad \delta_n \le 0 \\
+     &=& 0 \qquad \qquad \qquad \qquad \delta_n > 0
+\end{eqnarray*}
+
+\end{document}

doc/src/Eqs/pair_entropy.tex

@@ -0,0 +1,10 @@
+\documentclass[12pt]{article}
+
+\begin{document}
+\thispagestyle{empty}
+
+$$
+   s_S^i=-2\pi\rho k_B \int\limits_0^{r_m} \left [ g(r) \ln g(r) - g(r) + 1 \right ] r^2 dr ,
+$$
+
+\end{document}

doc/src/Eqs/pair_entropy2.tex

@@ -0,0 +1,10 @@
+\documentclass[12pt]{article}
+
+\begin{document}
+\thispagestyle{empty}
+
+$$
+   g_m^i(r) = \frac{1}{4 \pi \rho r^2} \sum\limits_{j} \frac{1}{\sqrt{2 \pi \sigma^2}} e^{-(r-r_{ij})^2/(2\sigma^2)} ,
+$$
+
+\end{document}

doc/src/Eqs/pair_entropy3.tex

@@ -0,0 +1,10 @@
+\documentclass[12pt]{article}
+
+\begin{document}
+\thispagestyle{empty}
+
+$$
+  \bar{s}_S^i  = \frac{\sum_j s_S^j + s_S^i}{N + 1} ,
+$$
+
+\end{document}

doc/src/Eqs/pair_spin_dmi_forces.tex

@@ -0,0 +1,14 @@
+\documentclass[preview]{standalone}
+\usepackage{varwidth}
+\usepackage[utf8x]{inputenc}
+\usepackage{amsmath,amssymb,amsthm,bm}
+\begin{document}
+\begin{varwidth}{50in}
+  \begin{equation}
+    \vec{\omega}_i = -\frac{1}{\hbar} \sum_{j}^{Neighb} \vec{s}_{j}\times \left(\vec{e}_{ij}\times \vec{D} \right) 
+    ~~{\rm and}~~
+    \vec{F}_i = -\sum_{j}^{Neighb} \frac{1}{r_{ij}} \vec{D} \times \left( \vec{s}_{i}\times \vec{s}_{j} \right) 
+    , \nonumber
+  \end{equation}
+\end{varwidth}
+\end{document}

doc/src/Eqs/pair_spin_dmi_interaction.tex

@@ -0,0 +1,16 @@
+\documentclass[preview]{standalone}
+\usepackage{varwidth}
+\usepackage[utf8x]{inputenc}
+\usepackage{amsmath,amssymb,amsthm,bm}
+\begin{document}
+\begin{varwidth}{50in}
+  \begin{equation}
+    \bm{H}_{dm} = \sum_{{ i,j}=1,i\neq j}^{N} 
+    \left( \vec{e}_{ij} \times \vec{D} \right)
+    \cdot\left(\vec{s}_{i}\times \vec{s}_{j}\right), 
+    \nonumber
+  \end{equation}
+\end{varwidth}
+\end{document}
+    \vec{D}\left(r_{ij}\right) 
+    {\rm ~and~}  \vec{D}\left(r_{ij}\right) = \vec{e}_{ij} \times \vec{D}  

doc/src/Eqs/pair_spin_exchange_forces.tex

@@ -0,0 +1,16 @@
+\documentclass[preview]{standalone}
+\usepackage{varwidth}
+\usepackage[utf8x]{inputenc}
+\usepackage{amsmath,amssymb,amsthm,bm}
+\begin{document}
+\begin{varwidth}{50in}
+  \begin{equation}
+    \vec{\omega}_{i} = \frac{1}{\hbar} \sum_{j}^{Neighb} {J} 
+    \left(r_{ij} \right)\,\vec{s}_{j} 
+    ~~{\rm and}~~ 
+    \vec{F}_{i} = \sum_{j}^{Neighb} \frac{\partial {J} \left(r_{ij} \right)}{
+    \partial r_{ij}} \left( \vec{s}_{i}\cdot \vec{s}_{j} \right) \vec{e}_{ij}  
+    \nonumber
+  \end{equation}
+\end{varwidth}
+\end{document}

doc/src/Eqs/pair_spin_exchange_function.tex

@@ -0,0 +1,13 @@
+\documentclass[preview]{standalone}
+\usepackage{varwidth}
+\usepackage[utf8x]{inputenc}
+\usepackage{amsmath, amssymb, graphics, setspace}
+
+\begin{document}
+\begin{varwidth}{50in}
+  \begin{equation}
+    {J}\left( r_{ij} \right) = 4 a \left( \frac{r_{ij}}{d}  \right)^2 \left( 1 - b \left( \frac{r_{ij}}{d}  \right)^2 \right) e^{-\left( \frac{r_{ij}}{d}  
+    \right)^2 }\Theta (R_c - r_{ij}) \nonumber
+  \end{equation}
+\end{varwidth}
+\end{document}

doc/src/Eqs/pair_spin_exchange_interaction.tex

@@ -0,0 +1,11 @@
+\documentclass[preview]{standalone}
+\usepackage{varwidth}
+\usepackage[utf8x]{inputenc}
+\usepackage{amsmath,amssymb,amsthm,bm}
+\begin{document}
+\begin{varwidth}{50in}
+  \begin{equation}
+    \bm{H}_{ex} ~=~ -\sum_{i,j,i\neq j}^{N} {J} \left(r_{ij} \right)\, \vec{s}_{i}\cdot \vec{s}_{j} \nonumber
+  \end{equation}
+\end{varwidth}
+\end{document}

doc/src/Eqs/pair_spin_me_forces.tex

@@ -0,0 +1,13 @@
+\documentclass[preview]{standalone}
+\usepackage{varwidth}
+\usepackage[utf8x]{inputenc}
+\usepackage{amsmath,amssymb,amsthm,bm}
+\begin{document}
+\begin{varwidth}{50in}
+  \begin{equation}
+    \vec{F}^{i} = -\sum_{j}^{Neighbor} \left( \vec{s}_{i}\times \vec{s}_{j} \right)
+    \times \vec{E} ~~{\rm and}~~ \vec{\omega}^{i} = -\frac{1}{\hbar} 
+    \sum_{j}^{Neighbor} \vec{s}_j \times \left(\vec{E}\times r_{ij} \right),\nonumber
+  \end{equation}
+\end{varwidth}
+\end{document}

doc/src/Eqs/pair_spin_me_interaction.tex

@@ -0,0 +1,12 @@
+\documentclass[preview]{standalone}
+\usepackage{varwidth}
+\usepackage[utf8x]{inputenc}
+\usepackage{amsmath,amssymb,amsthm,bm}
+\begin{document}
+\begin{varwidth}{50in}
+  \begin{equation}
+    \vec{\omega}_i = -\frac{1}{\hbar} \sum_{j}^{Neighb} \vec{s}_{j}\times\vec{D}(r_{ij}) ~~{\rm and}~~
+    \vec{F}_i = -\sum_{j}^{Neighb} \frac{\partial D(r_{ij})}{\partial r_{ij}} \left(\vec{s}_{i}\times \vec{s}_{j} \right) \cdot \vec{r}_{ij}, \nonumber
+  \end{equation}
+\end{varwidth}
+\end{document}

doc/src/Eqs/pair_spin_neel_functions.tex

@@ -0,0 +1,13 @@
+\documentclass[preview]{standalone}
+\usepackage{varwidth}
+\usepackage[utf8x]{inputenc}
+\usepackage{amsmath,amssymb,amsthm,bm}
+\begin{document}
+\begin{varwidth}{50in}
+  \begin{eqnarray}
+    g_1(r_{ij}) &=& g(r_{ij}) + \frac{12}{35} q(r_{ij}) \nonumber \\
+    q_1(r_{ij}) &=& \frac{9}{5} q(r_{ij}) \nonumber \\
+    q_2(r_{ij}) &=& - \frac{2}{5} q(r_{ij}) \nonumber
+  \end{eqnarray}
+\end{varwidth}
+\end{document}

doc/src/Eqs/pair_spin_neel_interaction.tex

@@ -0,0 +1,16 @@
+\documentclass[preview]{standalone}
+\usepackage{varwidth}
+\usepackage[utf8x]{inputenc}
+\usepackage{amsmath,amssymb,amsthm,bm}
+\begin{document}
+\begin{varwidth}{50in}
+  \begin{equation}
+    \mathcal{H}_{N\acute{e}el}=-\sum_{{ i,j=1,i\neq j}}^N g_1(r_{ij})\left(({\bm e}_{ij}\cdot {\bm s}_{i})({\bm e}_{ij}
+    \cdot {\bm s}_{j})-\frac{{\bm s}_{i}\cdot{\bm s}_{j}}{3} \right)
+    +q_1(r_{ij})\left( ({\bm e}_{ij}\cdot {\bm s}_{i})^2 -\frac{{\bm s}_{i}\cdot{\bm s}_{j}}{3}\right)
+    \left( ({\bm e}_{ij}\cdot {\bm s}_{i})^2 -\frac{{\bm s}_{i}\cdot{\bm s}_{j}}{3} \right)
+    + q_2(r_{ij}) \Big( ({\bm e}_{ij}\cdot {\bm s}_{i}) ({\bm e}_{ij}\cdot {\bm s}_{j})^3 + ({\bm e}_{ij}\cdot
+    {\bm s}_{j}) ({\bm e}_{ij}\cdot {\bm s}_{i})^3\Big) \nonumber
+  \end{equation}
+\end{varwidth}
+\end{document}

doc/src/Errors.txt

@@ -0,0 +1,37 @@
+"Previous Section"_Python.html - "LAMMPS WWW Site"_lws -
+"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
+Section"_Section_history.html :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+Errors :h2
+
+These doc pages describe the errors you can encounter when using
+LAMMPS.  The common problems include conceptual issues.  The messages
+and warnings doc pages give complete lists of all the messages the
+code may generate (except those generated by USER packages), with
+additional details for many of them.
+
+<!-- RST
+
+.. toctree::
+
+   Errors_common
+   Errors_bugs
+   Errors_messages
+   Errors_warnings
+
+END_RST -->
+
+<!-- HTML_ONLY -->
+
+"Common problems"_Errors_common.html
+"Reporting bugs"_Errors_bugs.html
+"Error messages"_Errors_messages.html 
+"Warning messages"_Errors_warnings.html :all(b)
+
+<!-- END_HTML_ONLY -->

doc/src/Errors_bugs.txt

@@ -0,0 +1,35 @@
+"Higher level section"_Errors.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+Reporting bugs :h3
+
+If you are confident that you have found a bug in LAMMPS, follow these
+steps.
+
+Check the "New features and bug
+fixes"_http://lammps.sandia.gov/bug.html section of the "LAMMPS WWW
+site"_lws to see if the bug has already been reported or fixed or the
+"Unfixed bug"_http://lammps.sandia.gov/unbug.html to see if a fix is
+pending.
+
+Check the "mailing list"_http://lammps.sandia.gov/mail.html to see if
+it has been discussed before.
+
+If not, send an email to the mailing list describing the problem with
+any ideas you have as to what is causing it or where in the code the
+problem might be.  The developers will ask for more info if needed,
+such as an input script or data files.
+
+The most useful thing you can do to help us fix the bug is to isolate
+the problem.  Run it on the smallest number of atoms and fewest number
+of processors and with the simplest input script that reproduces the
+bug and try to identify what command or combination of commands is
+causing the problem.
+
+NOTE: this page needs to have GitHub issues info added

doc/src/Errors_common.txt

@@ -0,0 +1,123 @@
+"Higher level section"_Errors.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+Common problems :h3
+
+If two LAMMPS runs do not produce the exact same answer on different
+machines or different numbers of processors, this is typically not a
+bug.  In theory you should get identical answers on any number of
+processors and on any machine.  In practice, numerical round-off can
+cause slight differences and eventual divergence of molecular dynamics
+phase space trajectories within a few 100s or few 1000s of timesteps.
+However, the statistical properties of the two runs (e.g. average
+energy or temperature) should still be the same.
+
+If the "velocity"_velocity.html command is used to set initial atom
+velocities, a particular atom can be assigned a different velocity
+when the problem is run on a different number of processors or on
+different machines.  If this happens, the phase space trajectories of
+the two simulations will rapidly diverge.  See the discussion of the
+{loop} option in the "velocity"_velocity.html command for details and
+options that avoid this issue.
+
+Similarly, the "create_atoms"_create_atoms.html command generates a
+lattice of atoms.  For the same physical system, the ordering and
+numbering of atoms by atom ID may be different depending on the number
+of processors.
+
+Some commands use random number generators which may be setup to
+produce different random number streams on each processor and hence
+will produce different effects when run on different numbers of
+processors.  A commonly-used example is the "fix
+langevin"_fix_langevin.html command for thermostatting.
+
+A LAMMPS simulation typically has two stages, setup and run.  Most
+LAMMPS errors are detected at setup time; others like a bond
+stretching too far may not occur until the middle of a run.
+
+LAMMPS tries to flag errors and print informative error messages so
+you can fix the problem.  For most errors it will also print the last
+input script command that it was processing.  Of course, LAMMPS cannot
+figure out your physics or numerical mistakes, like choosing too big a
+timestep, specifying erroneous force field coefficients, or putting 2
+atoms on top of each other!  If you run into errors that LAMMPS
+doesn't catch that you think it should flag, please send an email to
+the "developers"_http://lammps.sandia.gov/authors.html.
+
+If you get an error message about an invalid command in your input
+script, you can determine what command is causing the problem by
+looking in the log.lammps file or using the "echo command"_echo.html
+to see it on the screen.  If you get an error like "Invalid ...
+style", with ... being fix, compute, pair, etc, it means that you
+mistyped the style name or that the command is part of an optional
+package which was not compiled into your executable.  The list of
+available styles in your executable can be listed by using "the -h
+command-line argument"_Section_start.html#start_6.  The installation
+and compilation of optional packages is explained in the "installation
+instructions"_Section_start.html#start_3.
+
+For a given command, LAMMPS expects certain arguments in a specified
+order.  If you mess this up, LAMMPS will often flag the error, but it
+may also simply read a bogus argument and assign a value that is
+valid, but not what you wanted.  E.g. trying to read the string "abc"
+as an integer value of 0.  Careful reading of the associated doc page
+for the command should allow you to fix these problems. In most cases,
+where LAMMPS expects to read a number, either integer or floating point,
+it performs a stringent test on whether the provided input actually
+is an integer or floating-point number, respectively, and reject the
+input with an error message (for instance, when an integer is required,
+but a floating-point number 1.0 is provided):
+
+ERROR: Expected integer parameter in input script or data file :pre
+
+Some commands allow for using variable references in place of numeric
+constants so that the value can be evaluated and may change over the
+course of a run.  This is typically done with the syntax {v_name} for a
+parameter, where name is the name of the variable. On the other hand,
+immediate variable expansion with the syntax ${name} is performed while
+reading the input and before parsing commands,
+
+NOTE: Using a variable reference (i.e. {v_name}) is only allowed if
+the documentation of the corresponding command explicitly says it is.
+
+Generally, LAMMPS will print a message to the screen and logfile and
+exit gracefully when it encounters a fatal error.  Sometimes it will
+print a WARNING to the screen and logfile and continue on; you can
+decide if the WARNING is important or not.  A WARNING message that is
+generated in the middle of a run is only printed to the screen, not to
+the logfile, to avoid cluttering up thermodynamic output.  If LAMMPS
+crashes or hangs without spitting out an error message first then it
+could be a bug (see "this section"_#err_2) or one of the following
+cases:
+
+LAMMPS runs in the available memory a processor allows to be
+allocated.  Most reasonable MD runs are compute limited, not memory
+limited, so this shouldn't be a bottleneck on most platforms.  Almost
+all large memory allocations in the code are done via C-style malloc's
+which will generate an error message if you run out of memory.
+Smaller chunks of memory are allocated via C++ "new" statements.  If
+you are unlucky you could run out of memory just when one of these
+small requests is made, in which case the code will crash or hang (in
+parallel), since LAMMPS doesn't trap on those errors.
+
+Illegal arithmetic can cause LAMMPS to run slow or crash.  This is
+typically due to invalid physics and numerics that your simulation is
+computing.  If you see wild thermodynamic values or NaN values in your
+LAMMPS output, something is wrong with your simulation.  If you
+suspect this is happening, it is a good idea to print out
+thermodynamic info frequently (e.g. every timestep) via the
+"thermo"_thermo.html so you can monitor what is happening.
+Visualizing the atom movement is also a good idea to insure your model
+is behaving as you expect.
+
+In parallel, one way LAMMPS can hang is due to how different MPI
+implementations handle buffering of messages.  If the code hangs
+without an error message, it may be that you need to specify an MPI
+setting or two (usually via an environment variable) to enable
+buffering or boost the sizes of messages that can be buffered.

doc/src/Errors_warnings.txt

@@ -0,0 +1,934 @@
+"Higher level section"_Errors.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+Warning messages :h3
+
+This is an alphabetic list of the WARNING messages LAMMPS prints out
+and the reason why.  If the explanation here is not sufficient, the
+documentation for the offending command may help.  Warning messages
+also list the source file and line number where the warning was
+generated.  For example, a message lile this:
+
+WARNING: Bond atom missing in box size check (domain.cpp:187) :pre
+
+means that line #187 in the file src/domain.cpp generated the error.
+Looking in the source code may help you figure out what went wrong.
+
+Note that warning messages from "user-contributed
+packages"_Packages_user.html are not listed here.  If such a warning
+occurs and is not self-explanatory, you'll need to look in the source
+code or contact the author of the package.
+
+Doc page with "ERROR messages"_Errors_messages.html
+
+:line
+
+:dlb
+
+{Adjusting Coulombic cutoff for MSM, new cutoff = %g} :dt
+
+The adjust/cutoff command is turned on and the Coulombic cutoff has been
+adjusted to match the user-specified accuracy. :dd
+
+{Angle atoms missing at step %ld} :dt
+
+One or more of 3 atoms needed to compute a particular angle are
+missing on this processor.  Typically this is because the pairwise
+cutoff is set too short or the angle has blown apart and an atom is
+too far away. :dd
+
+{Angle style in data file differs from currently defined angle style} :dt
+
+Self-explanatory. :dd
+
+{Atom style in data file differs from currently defined atom style} :dt
+
+Self-explanatory. :dd
+
+{Bond atom missing in box size check} :dt
+
+The 2nd atoms needed to compute a particular bond is missing on this
+processor.  Typically this is because the pairwise cutoff is set too
+short or the bond has blown apart and an atom is too far away. :dd
+
+{Bond atom missing in image check} :dt
+
+The 2nd atom in a particular bond is missing on this processor.
+Typically this is because the pairwise cutoff is set too short or the
+bond has blown apart and an atom is too far away. :dd
+
+{Bond atoms missing at step %ld} :dt
+
+The 2nd atom needed to compute a particular bond is missing on this
+processor.  Typically this is because the pairwise cutoff is set too
+short or the bond has blown apart and an atom is too far away. :dd
+
+{Bond style in data file differs from currently defined bond style} :dt
+
+Self-explanatory. :dd
+
+{Bond/angle/dihedral extent > half of periodic box length} :dt
+
+This is a restriction because LAMMPS can be confused about which image
+of an atom in the bonded interaction is the correct one to use.
+"Extent" in this context means the maximum end-to-end length of the
+bond/angle/dihedral.  LAMMPS computes this by taking the maximum bond
+length, multiplying by the number of bonds in the interaction (e.g. 3
+for a dihedral) and adding a small amount of stretch. :dd
+
+{Both groups in compute group/group have a net charge; the Kspace boundary correction to energy will be non-zero} :dt
+
+Self-explanatory. :dd
+
+{Calling write_dump before a full system init.} :dt
+
+The write_dump command is used before the system has been fully
+initialized as part of a 'run' or 'minimize' command. Not all dump
+styles and features are fully supported at this point and thus the
+command may fail or produce incomplete or incorrect output. Insert
+a "run 0" command, if a full system init is required. :dd
+
+{Cannot count rigid body degrees-of-freedom before bodies are fully initialized} :dt
+
+This means the temperature associated with the rigid bodies may be
+incorrect on this timestep. :dd
+
+{Cannot count rigid body degrees-of-freedom before bodies are initialized} :dt
+
+This means the temperature associated with the rigid bodies may be
+incorrect on this timestep. :dd
+
+{Cannot include log terms without 1/r terms; setting flagHI to 1} :dt
+
+Self-explanatory. :dd
+
+{Cannot include log terms without 1/r terms; setting flagHI to 1.} :dt
+
+Self-explanatory. :dd
+
+{Charges are set, but coulombic solver is not used} :dt
+
+Self-explanatory. :dd
+
+{Charges did not converge at step %ld: %lg} :dt
+
+Self-explanatory. :dd
+
+{Communication cutoff is too small for SNAP micro load balancing, increased to %lf} :dt
+
+Self-explanatory. :dd
+
+{Compute cna/atom cutoff may be too large to find ghost atom neighbors} :dt
+
+The neighbor cutoff used may not encompass enough ghost atoms
+to perform this operation correctly. :dd
+
+{Computing temperature of portions of rigid bodies} :dt
+
+The group defined by the temperature compute does not encompass all
+the atoms in one or more rigid bodies, so the change in
+degrees-of-freedom for the atoms in those partial rigid bodies will
+not be accounted for. :dd
+
+{Create_bonds max distance > minimum neighbor cutoff} :dt
+
+This means atom pairs for some atom types may not be in the neighbor
+list and thus no bond can be created between them. :dd
+
+{Delete_atoms cutoff > minimum neighbor cutoff} :dt
+
+This means atom pairs for some atom types may not be in the neighbor
+list and thus an atom in that pair cannot be deleted. :dd
+
+{Dihedral atoms missing at step %ld} :dt
+
+One or more of 4 atoms needed to compute a particular dihedral are
+missing on this processor.  Typically this is because the pairwise
+cutoff is set too short or the dihedral has blown apart and an atom is
+too far away. :dd
+
+{Dihedral problem} :dt
+
+Conformation of the 4 listed dihedral atoms is extreme; you may want
+to check your simulation geometry. :dd
+
+{Dihedral problem: %d %ld %d %d %d %d} :dt
+
+Conformation of the 4 listed dihedral atoms is extreme; you may want
+to check your simulation geometry. :dd
+
+{Dihedral style in data file differs from currently defined dihedral style} :dt
+
+Self-explanatory. :dd
+
+{Dump dcd/xtc timestamp may be wrong with fix dt/reset} :dt
+
+If the fix changes the timestep, the dump dcd file will not
+reflect the change. :dd
+
+{Energy due to X extra global DOFs will be included in minimizer energies} :dt
+
+When using fixes like box/relax, the potential energy used by the minimizer
+is augmented by an additional energy provided by the fix. Thus the printed
+converged energy may be different from the total potential energy. :dd
+
+{Energy tally does not account for 'zero yes'} :dt
+
+The energy removed by using the 'zero yes' flag is not accounted
+for in the energy tally and thus energy conservation cannot be
+monitored in this case. :dd
+
+{Estimated error in splitting of dispersion coeffs is %g} :dt
+
+Error is greater than 0.0001 percent. :dd
+
+{Ewald/disp Newton solver failed, using old method to estimate g_ewald} :dt
+
+Self-explanatory. Choosing a different cutoff value may help. :dd
+
+{FENE bond too long} :dt
+
+A FENE bond has stretched dangerously far.  It's interaction strength
+will be truncated to attempt to prevent the bond from blowing up. :dd
+
+{FENE bond too long: %ld %d %d %g} :dt
+
+A FENE bond has stretched dangerously far.  It's interaction strength
+will be truncated to attempt to prevent the bond from blowing up. :dd
+
+{FENE bond too long: %ld %g} :dt
+
+A FENE bond has stretched dangerously far.  It's interaction strength
+will be truncated to attempt to prevent the bond from blowing up. :dd
+
+{Fix SRD walls overlap but fix srd overlap not set} :dt
+
+You likely want to set this in your input script. :dd
+
+{Fix bond/swap will ignore defined angles} :dt
+
+See the doc page for fix bond/swap for more info on this
+restriction. :dd
+
+{Fix deposit near setting < possible overlap separation %g} :dt
+
+This test is performed for finite size particles with a diameter, not
+for point particles.  The near setting is smaller than the particle
+diameter which can lead to overlaps. :dd
+
+{Fix evaporate may delete atom with non-zero molecule ID} :dt
+
+This is probably an error, since you should not delete only one atom
+of a molecule. :dd
+
+{Fix gcmc using full_energy option} :dt
+
+Fix gcmc has automatically turned on the full_energy option since it
+is required for systems like the one specified by the user. User input
+included one or more of the following: kspace, triclinic, a hybrid
+pair style, an eam pair style, or no "single" function for the pair
+style. :dd
+
+{Fix property/atom mol or charge w/out ghost communication} :dt
+
+A model typically needs these properties defined for ghost atoms. :dd
+
+{Fix qeq CG convergence failed (%g) after %d iterations at %ld step} :dt
+
+Self-explanatory. :dd
+
+{Fix qeq has non-zero lower Taper radius cutoff} :dt
+
+Absolute value must be <= 0.01. :dd
+
+{Fix qeq has very low Taper radius cutoff} :dt
+
+Value should typically be >= 5.0. :dd
+
+{Fix qeq/dynamic tolerance may be too small for damped dynamics} :dt
+
+Self-explanatory. :dd
+
+{Fix qeq/fire tolerance may be too small for damped fires} :dt
+
+Self-explanatory. :dd
+
+{Fix rattle should come after all other integration fixes} :dt
+
+This fix is designed to work after all other integration fixes change
+atom positions.  Thus it should be the last integration fix specified.
+If not, it will not satisfy the desired constraints as well as it
+otherwise would. :dd
+
+{Fix recenter should come after all other integration fixes} :dt
+
+Other fixes may change the position of the center-of-mass, so
+fix recenter should come last. :dd
+
+{Fix srd SRD moves may trigger frequent reneighboring} :dt
+
+This is because the SRD particles may move long distances. :dd
+
+{Fix srd grid size > 1/4 of big particle diameter} :dt
+
+This may cause accuracy problems. :dd
+
+{Fix srd particle moved outside valid domain} :dt
+
+This may indicate a problem with your simulation parameters. :dd
+
+{Fix srd particles may move > big particle diameter} :dt
+
+This may cause accuracy problems. :dd
+
+{Fix srd viscosity < 0.0 due to low SRD density} :dt
+
+This may cause accuracy problems. :dd
+
+{Fix thermal/conductivity comes before fix ave/spatial} :dt
+
+The order of these 2 fixes in your input script is such that fix
+thermal/conductivity comes first.  If you are using fix ave/spatial to
+measure the temperature profile induced by fix viscosity, then this
+may cause a glitch in the profile since you are averaging immediately
+after swaps have occurred.  Flipping the order of the 2 fixes
+typically helps. :dd
+
+{Fix viscosity comes before fix ave/spatial} :dt
+
+The order of these 2 fixes in your input script is such that
+fix viscosity comes first.  If you are using fix ave/spatial
+to measure the velocity profile induced by fix viscosity, then
+this may cause a glitch in the profile since you are averaging
+immediately after swaps have occurred.  Flipping the order
+of the 2 fixes typically helps. :dd
+
+{Fixes cannot send data in Kokkos communication, switching to classic communication} :dt
+
+This is current restriction with Kokkos. :dd
+
+{For better accuracy use 'pair_modify table 0'} :dt
+
+The user-specified force accuracy cannot be achieved unless the table
+feature is disabled by using 'pair_modify table 0'. :dd
+
+{Geometric mixing assumed for 1/r^6 coefficients} :dt
+
+Self-explanatory. :dd
+
+{Group for fix_modify temp != fix group} :dt
+
+The fix_modify command is specifying a temperature computation that
+computes a temperature on a different group of atoms than the fix
+itself operates on.  This is probably not what you want to do. :dd
+
+{H matrix size has been exceeded: m_fill=%d H.m=%d\n} :dt
+
+This is the size of the matrix. :dd
+
+{Ignoring unknown or incorrect info command flag} :dt
+
+Self-explanatory.  An unknown argument was given to the info command.
+Compare your input with the documentation. :dd
+
+{Improper atoms missing at step %ld} :dt
+
+One or more of 4 atoms needed to compute a particular improper are
+missing on this processor.  Typically this is because the pairwise
+cutoff is set too short or the improper has blown apart and an atom is
+too far away. :dd
+
+{Improper problem: %d %ld %d %d %d %d} :dt
+
+Conformation of the 4 listed improper atoms is extreme; you may want
+to check your simulation geometry. :dd
+
+{Improper style in data file differs from currently defined improper style} :dt
+
+Self-explanatory. :dd
+
+{Inconsistent image flags} :dt
+
+The image flags for a pair on bonded atoms appear to be inconsistent.
+Inconsistent means that when the coordinates of the two atoms are
+unwrapped using the image flags, the two atoms are far apart.
+Specifically they are further apart than half a periodic box length.
+Or they are more than a box length apart in a non-periodic dimension.
+This is usually due to the initial data file not having correct image
+flags for the 2 atoms in a bond that straddles a periodic boundary.
+They should be different by 1 in that case.  This is a warning because
+inconsistent image flags will not cause problems for dynamics or most
+LAMMPS simulations.  However they can cause problems when such atoms
+are used with the fix rigid or replicate commands.  Note that if you
+have an infinite periodic crystal with bonds then it is impossible to
+have fully consistent image flags, since some bonds will cross
+periodic boundaries and connect two atoms with the same image
+flag. :dd
+
+{KIM Model does not provide 'energy'; Potential energy will be zero} :dt
+
+Self-explanatory. :dd
+
+{KIM Model does not provide 'forces'; Forces will be zero} :dt
+
+Self-explanatory. :dd
+
+{KIM Model does not provide 'particleEnergy'; energy per atom will be zero} :dt
+
+Self-explanatory. :dd
+
+{KIM Model does not provide 'particleVirial'; virial per atom will be zero} :dt
+
+Self-explanatory. :dd
+
+{Kspace_modify slab param < 2.0 may cause unphysical behavior} :dt
+
+The kspace_modify slab parameter should be larger to insure periodic
+grids padded with empty space do not overlap. :dd
+
+{Less insertions than requested} :dt
+
+The fix pour command was unsuccessful at finding open space
+for as many particles as it tried to insert. :dd
+
+{Library error in lammps_gather_atoms} :dt
+
+This library function cannot be used if atom IDs are not defined
+or are not consecutively numbered. :dd
+
+{Library error in lammps_scatter_atoms} :dt
+
+This library function cannot be used if atom IDs are not defined or
+are not consecutively numbered, or if no atom map is defined.  See the
+atom_modify command for details about atom maps. :dd
+
+{Lost atoms via change_box: original %ld current %ld} :dt
+
+The command options you have used caused atoms to be lost. :dd
+
+{Lost atoms via displace_atoms: original %ld current %ld} :dt
+
+The command options you have used caused atoms to be lost. :dd
+
+{Lost atoms: original %ld current %ld} :dt
+
+Lost atoms are checked for each time thermo output is done.  See the
+thermo_modify lost command for options.  Lost atoms usually indicate
+bad dynamics, e.g. atoms have been blown far out of the simulation
+box, or moved further than one processor's sub-domain away before
+reneighboring. :dd
+
+{MSM mesh too small, increasing to 2 points in each direction} :dt
+
+Self-explanatory. :dd
+
+{Mismatch between velocity and compute groups} :dt
+
+The temperature computation used by the velocity command will not be
+on the same group of atoms that velocities are being set for. :dd
+
+{Mixing forced for lj coefficients} :dt
+
+Self-explanatory. :dd
+
+{Molecule attributes do not match system attributes} :dt
+
+An attribute is specified (e.g. diameter, charge) that is
+not defined for the specified atom style. :dd
+
+{Molecule has bond topology but no special bond settings} :dt
+
+This means the bonded atoms will not be excluded in pair-wise
+interactions. :dd
+
+{Molecule template for create_atoms has multiple molecules} :dt
+
+The create_atoms command will only create molecules of a single type,
+i.e. the first molecule in the template. :dd
+
+{Molecule template for fix gcmc has multiple molecules} :dt
+
+The fix gcmc command will only create molecules of a single type,
+i.e. the first molecule in the template. :dd
+
+{Molecule template for fix shake has multiple molecules} :dt
+
+The fix shake command will only recognize molecules of a single
+type, i.e. the first molecule in the template. :dd
+
+{More than one compute centro/atom} :dt
+
+It is not efficient to use compute centro/atom more than once. :dd
+
+{More than one compute cluster/atom} :dt
+
+It is not efficient to use compute cluster/atom  more than once. :dd
+
+{More than one compute cna/atom defined} :dt
+
+It is not efficient to use compute cna/atom  more than once. :dd
+
+{More than one compute contact/atom} :dt
+
+It is not efficient to use compute contact/atom more than once. :dd
+
+{More than one compute coord/atom} :dt
+
+It is not efficient to use compute coord/atom more than once. :dd
+
+{More than one compute damage/atom} :dt
+
+It is not efficient to use compute ke/atom more than once. :dd
+
+{More than one compute dilatation/atom} :dt
+
+Self-explanatory. :dd
+
+{More than one compute erotate/sphere/atom} :dt
+
+It is not efficient to use compute erorate/sphere/atom more than once. :dd
+
+{More than one compute hexorder/atom} :dt
+
+It is not efficient to use compute hexorder/atom more than once. :dd
+
+{More than one compute ke/atom} :dt
+
+It is not efficient to use compute ke/atom more than once. :dd
+
+{More than one compute orientorder/atom} :dt
+
+It is not efficient to use compute orientorder/atom more than once. :dd
+
+{More than one compute plasticity/atom} :dt
+
+Self-explanatory. :dd
+
+{More than one compute sna/atom} :dt
+
+Self-explanatory. :dd
+
+{More than one compute snad/atom} :dt
+
+Self-explanatory. :dd
+
+{More than one compute snav/atom} :dt
+
+Self-explanatory. :dd
+
+{More than one fix poems} :dt
+
+It is not efficient to use fix poems more than once. :dd
+
+{More than one fix rigid} :dt
+
+It is not efficient to use fix rigid more than once. :dd
+
+{Neighbor exclusions used with KSpace solver may give inconsistent Coulombic energies} :dt
+
+This is because excluding specific pair interactions also excludes
+them from long-range interactions which may not be the desired effect.
+The special_bonds command handles this consistently by insuring
+excluded (or weighted) 1-2, 1-3, 1-4 interactions are treated
+consistently by both the short-range pair style and the long-range
+solver.  This is not done for exclusions of charged atom pairs via the
+neigh_modify exclude command. :dd
+
+{New thermo_style command, previous thermo_modify settings will be lost} :dt
+
+If a thermo_style command is used after a thermo_modify command, the
+settings changed by the thermo_modify command will be reset to their
+default values.  This is because the thermo_modify command acts on
+the currently defined thermo style, and a thermo_style command creates
+a new style. :dd
+
+{No Kspace calculation with verlet/split} :dt
+
+The 2nd partition performs a kspace calculation so the kspace_style
+command must be used. :dd
+
+{No automatic unit conversion to XTC file format conventions possible for units lj} :dt
+
+This means no scaling will be performed. :dd
+
+{No fixes defined, atoms won't move} :dt
+
+If you are not using a fix like nve, nvt, npt then atom velocities and
+coordinates will not be updated during timestepping. :dd
+
+{No joints between rigid bodies, use fix rigid instead} :dt
+
+The bodies defined by fix poems are not connected by joints.  POEMS
+will integrate the body motion, but it would be more efficient to use
+fix rigid. :dd
+
+{Not using real units with pair reax} :dt
+
+This is most likely an error, unless you have created your own ReaxFF
+parameter file in a different set of units. :dd
+
+{Number of MSM mesh points changed to be a multiple of 2} :dt
+
+MSM requires that the number of grid points in each direction be a multiple
+of two and the number of grid points in one or more directions have been
+adjusted to meet this requirement. :dd
+
+{OMP_NUM_THREADS environment is not set.} :dt
+
+This environment variable must be set appropriately to use the
+USER-OMP package. :dd
+
+{One or more atoms are time integrated more than once} :dt
+
+This is probably an error since you typically do not want to
+advance the positions or velocities of an atom more than once
+per timestep. :dd
+
+{One or more chunks do not contain all atoms in molecule} :dt
+
+This may not be what you intended. :dd
+
+{One or more dynamic groups may not be updated at correct point in timestep} :dt
+
+If there are other fixes that act immediately after the initial stage
+of time integration within a timestep (i.e. after atoms move), then
+the command that sets up the dynamic group should appear after those
+fixes.  This will insure that dynamic group assignments are made
+after all atoms have moved. :dd
+
+{One or more respa levels compute no forces} :dt
+
+This is computationally inefficient. :dd
+
+{Pair COMB charge %.10f with force %.10f hit max barrier} :dt
+
+Something is possibly wrong with your model. :dd
+
+{Pair COMB charge %.10f with force %.10f hit min barrier} :dt
+
+Something is possibly wrong with your model. :dd
+
+{Pair brownian needs newton pair on for momentum conservation} :dt
+
+Self-explanatory. :dd
+
+{Pair dpd needs newton pair on for momentum conservation} :dt
+
+Self-explanatory. :dd
+
+{Pair dsmc: num_of_collisions > number_of_A} :dt
+
+Collision model in DSMC is breaking down. :dd
+
+{Pair dsmc: num_of_collisions > number_of_B} :dt
+
+Collision model in DSMC is breaking down. :dd
+
+{Pair style in data file differs from currently defined pair style} :dt
+
+Self-explanatory. :dd
+
+{Pair style restartinfo set but has no restart support} :dt
+
+This pair style has a bug, where it does not support reading and
+writing information to a restart file, but does not set the member
+variable "restartinfo" to 0 as required in that case. :dd
+
+{Particle deposition was unsuccessful} :dt
+
+The fix deposit command was not able to insert as many atoms as
+needed.  The requested volume fraction may be too high, or other atoms
+may be in the insertion region. :dd
+
+{Proc sub-domain size < neighbor skin, could lead to lost atoms} :dt
+
+The decomposition of the physical domain (likely due to load
+balancing) has led to a processor's sub-domain being smaller than the
+neighbor skin in one or more dimensions.  Since reneighboring is
+triggered by atoms moving the skin distance, this may lead to lost
+atoms, if an atom moves all the way across a neighboring processor's
+sub-domain before reneighboring is triggered. :dd
+
+{Reducing PPPM order b/c stencil extends beyond nearest neighbor processor} :dt
+
+This may lead to a larger grid than desired.  See the kspace_modify overlap
+command to prevent changing of the PPPM order. :dd
+
+{Reducing PPPMDisp Coulomb order b/c stencil extends beyond neighbor processor} :dt
+
+This may lead to a larger grid than desired.  See the kspace_modify overlap
+command to prevent changing of the PPPM order. :dd
+
+{Reducing PPPMDisp dispersion order b/c stencil extends beyond neighbor processor} :dt
+
+This may lead to a larger grid than desired.  See the kspace_modify overlap
+command to prevent changing of the PPPM order. :dd
+
+{Replacing a fix, but new group != old group} :dt
+
+The ID and style of a fix match for a fix you are changing with a fix
+command, but the new group you are specifying does not match the old
+group. :dd
+
+{Replicating in a non-periodic dimension} :dt
+
+The parameters for a replicate command will cause a non-periodic
+dimension to be replicated; this may cause unwanted behavior. :dd
+
+{Resetting reneighboring criteria during PRD} :dt
+
+A PRD simulation requires that neigh_modify settings be delay = 0,
+every = 1, check = yes.  Since these settings were not in place,
+LAMMPS changed them and will restore them to their original values
+after the PRD simulation. :dd
+
+{Resetting reneighboring criteria during TAD} :dt
+
+A TAD simulation requires that neigh_modify settings be delay = 0,
+every = 1, check = yes.  Since these settings were not in place,
+LAMMPS changed them and will restore them to their original values
+after the PRD simulation. :dd
+
+{Resetting reneighboring criteria during minimization} :dt
+
+Minimization requires that neigh_modify settings be delay = 0, every =
+1, check = yes.  Since these settings were not in place, LAMMPS
+changed them and will restore them to their original values after the
+minimization. :dd
+
+{Restart file used different # of processors} :dt
+
+The restart file was written out by a LAMMPS simulation running on a
+different number of processors.  Due to round-off, the trajectories of
+your restarted simulation may diverge a little more quickly than if
+you ran on the same # of processors. :dd
+
+{Restart file used different 3d processor grid} :dt
+
+The restart file was written out by a LAMMPS simulation running on a
+different 3d grid of processors.  Due to round-off, the trajectories
+of your restarted simulation may diverge a little more quickly than if
+you ran on the same # of processors. :dd
+
+{Restart file used different boundary settings, using restart file values} :dt
+
+Your input script cannot change these restart file settings. :dd
+
+{Restart file used different newton bond setting, using restart file value} :dt
+
+The restart file value will override the setting in the input script. :dd
+
+{Restart file used different newton pair setting, using input script value} :dt
+
+The input script value will override the setting in the restart file. :dd
+
+{Restrain problem: %d %ld %d %d %d %d} :dt
+
+Conformation of the 4 listed dihedral atoms is extreme; you may want
+to check your simulation geometry. :dd
+
+{Running PRD with only one replica} :dt
+
+This is allowed, but you will get no parallel speed-up. :dd
+
+{SRD bin shifting turned on due to small lamda} :dt
+
+This is done to try to preserve accuracy. :dd
+
+{SRD bin size for fix srd differs from user request} :dt
+
+Fix SRD had to adjust the bin size to fit the simulation box.  See the
+cubic keyword if you want this message to be an error vs warning. :dd
+
+{SRD bins for fix srd are not cubic enough} :dt
+
+The bin shape is not within tolerance of cubic.  See the cubic
+keyword if you want this message to be an error vs warning. :dd
+
+{SRD particle %d started inside big particle %d on step %ld bounce %d} :dt
+
+See the inside keyword if you want this message to be an error vs
+warning. :dd
+
+{SRD particle %d started inside wall %d on step %ld bounce %d} :dt
+
+See the inside keyword if you want this message to be an error vs
+warning. :dd
+
+{Shake determinant < 0.0} :dt
+
+The determinant of the quadratic equation being solved for a single
+cluster specified by the fix shake command is numerically suspect.  LAMMPS
+will set it to 0.0 and continue. :dd
+
+{Shell command '%s' failed with error '%s'} :dt
+
+Self-explanatory. :dd
+
+{Shell command returned with non-zero status} :dt
+
+This may indicate the shell command did not operate as expected. :dd
+
+{Should not allow rigid bodies to bounce off relecting walls} :dt
+
+LAMMPS allows this, but their dynamics are not computed correctly. :dd
+
+{Should not use fix nve/limit with fix shake or fix rattle} :dt
+
+This will lead to invalid constraint forces in the SHAKE/RATTLE
+computation. :dd
+
+{Simulations might be very slow because of large number of structure factors} :dt
+
+Self-explanatory. :dd
+
+{Slab correction not needed for MSM} :dt
+
+Slab correction is intended to be used with Ewald or PPPM and is not needed by MSM. :dd
+
+{System is not charge neutral, net charge = %g} :dt
+
+The total charge on all atoms on the system is not 0.0.
+For some KSpace solvers this is only a warning. :dd
+
+{Table inner cutoff >= outer cutoff} :dt
+
+You specified an inner cutoff for a Coulombic table that is longer
+than the global cutoff.  Probably not what you wanted. :dd
+
+{Temperature for MSST is not for group all} :dt
+
+User-assigned temperature to MSST fix does not compute temperature for
+all atoms.  Since MSST computes a global pressure, the kinetic energy
+contribution from the temperature is assumed to also be for all atoms.
+Thus the pressure used by MSST could be inaccurate. :dd
+
+{Temperature for NPT is not for group all} :dt
+
+User-assigned temperature to NPT fix does not compute temperature for
+all atoms.  Since NPT computes a global pressure, the kinetic energy
+contribution from the temperature is assumed to also be for all atoms.
+Thus the pressure used by NPT could be inaccurate. :dd
+
+{Temperature for fix modify is not for group all} :dt
+
+The temperature compute is being used with a pressure calculation
+which does operate on group all, so this may be inconsistent. :dd
+
+{Temperature for thermo pressure is not for group all} :dt
+
+User-assigned temperature to thermo via the thermo_modify command does
+not compute temperature for all atoms.  Since thermo computes a global
+pressure, the kinetic energy contribution from the temperature is
+assumed to also be for all atoms.  Thus the pressure printed by thermo
+could be inaccurate. :dd
+
+{The fix ave/spatial command has been replaced by the more flexible fix ave/chunk and compute chunk/atom commands -- fix ave/spatial will be removed in the summer of 2015} :dt
+
+Self-explanatory. :dd
+
+{The minimizer does not re-orient dipoles when using fix efield} :dt
+
+This means that only the atom coordinates will be minimized,
+not the orientation of the dipoles. :dd
+
+{Too many common neighbors in CNA %d times} :dt
+
+More than the maximum # of neighbors was found multiple times.  This
+was unexpected. :dd
+
+{Too many inner timesteps in fix ttm} :dt
+
+Self-explanatory. :dd
+
+{Too many neighbors in CNA for %d atoms} :dt
+
+More than the maximum # of neighbors was found multiple times.  This
+was unexpected. :dd
+
+{Triclinic box skew is large} :dt
+
+The displacement in a skewed direction is normally required to be less
+than half the box length in that dimension.  E.g. the xy tilt must be
+between -half and +half of the x box length.  You have relaxed the
+constraint using the box tilt command, but the warning means that a
+LAMMPS simulation may be inefficient as a result. :dd
+
+{Use special bonds = 0,1,1 with bond style fene} :dt
+
+Most FENE models need this setting for the special_bonds command. :dd
+
+{Use special bonds = 0,1,1 with bond style fene/expand} :dt
+
+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
+
+This is likely not what you want to do.  The exclusion settings will
+eliminate neighbors in the neighbor list, which the manybody potential
+needs to calculated its terms correctly. :dd
+
+{Using compute temp/deform with inconsistent fix deform remap option} :dt
+
+Fix nvt/sllod assumes deforming atoms have a velocity profile provided
+by "remap v" or "remap none" as a fix deform option. :dd
+
+{Using compute temp/deform with no fix deform defined} :dt
+
+This is probably an error, since it makes little sense to use
+compute temp/deform in this case. :dd
+
+{Using fix srd with box deformation but no SRD thermostat} :dt
+
+The deformation will heat the SRD particles so this can
+be dangerous. :dd
+
+{Using kspace solver on system with no charge} :dt
+
+Self-explanatory. :dd
+
+{Using largest cut-off for lj/long/dipole/long long long} :dt
+
+Self-explanatory. :dd
+
+{Using largest cutoff for buck/long/coul/long} :dt
+
+Self-explanatory. :dd
+
+{Using largest cutoff for lj/long/coul/long} :dt
+
+Self-explanatory. :dd
+
+{Using largest cutoff for pair_style lj/long/tip4p/long} :dt
+
+Self-explanatory. :dd
+
+{Using package gpu without any pair style defined} :dt
+
+Self-explanatory. :dd
+
+{Using pair potential shift with pair_modify compute no} :dt
+
+The shift effects will thus not be computed. :dd
+
+{Using pair tail corrections with nonperiodic system} :dt
+
+This is probably a bogus thing to do, since tail corrections are
+computed by integrating the density of a periodic system out to
+infinity. :dd
+
+{Using pair tail corrections with pair_modify compute no} :dt
+
+The tail corrections will thus not be computed. :dd
+
+{pair style reax is now deprecated and will soon be retired. Users should switch to pair_style reax/c} :dt
+
+Self-explanatory. :dd
+
+:dle

doc/src/Examples.txt

@@ -1,4 +1,6 @@
-"Previous Section"_Section_howto.html - "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Section_perf.html :c
+"Previous Section"_Section_howto.html - "LAMMPS WWW Site"_lws -
+"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
+Section"_Section_perf.html :c
 
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
@@ -6,7 +8,7 @@
 
 :line
 
-7. Example problems :h2
+Example scripts :h3
 
 The LAMMPS distribution includes an examples sub-directory with many
 sample problems.  Many are 2d models that run quickly are are
@@ -46,7 +48,7 @@ Lists of both kinds of directories are given below.
 
 :line
 
-Lowercase directories :h3
+Lowercase directories :h4
 
 accelerate: run with various acceleration options (OpenMP, GPU, Phi)
 airebo:   polyethylene with AIREBO potential
@@ -122,7 +124,7 @@ browser.
 
 :line
 
-Uppercase directories :h3
+Uppercase directories :h4
 
 ASPHERE: various aspherical particle models, using ellipsoids, rigid bodies, line/triangle particles, etc
 COUPLE: examples of how to use LAMMPS as a library
@@ -141,5 +143,5 @@ The USER directory has a large number of sub-directories which
 correspond by name to a USER package.  They contain scripts that
 illustrate how to use the command(s) provided in that package.  Many
 of the sub-directories have their own README files which give further
-instructions.  See the "Section 4"_Section_packages.html doc
+instructions.  See the "Packages_details"_Packages_details.html doc
 page for more info on specific USER packages.

doc/src/Manual.txt

@@ -1,7 +1,7 @@
 <!-- HTML_ONLY -->
-<HEAD>
+<
 <TITLE>LAMMPS Users Manual</TITLE>
-<META NAME="docnumber" CONTENT="30 Mar 2018 version">
+<META NAME="docnumber" CONTENT="2 Aug 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>
@@ -19,7 +19,7 @@
 :line
 
 LAMMPS Documentation :c,h1
-30 Mar 2018 version :c,h2
+2 Aug 2018 version :c,h2
 
 Version info: :h3
 
@@ -111,15 +111,14 @@ it gives quick access to documentation for all LAMMPS commands.
    Section_intro
    Section_start
    Section_commands
-   Section_packages
-   Section_accelerate
+   Packages
+   Speed
    Section_howto
-   Section_example
-   Section_perf
-   Section_tools
-   Section_modify
-   Section_python
-   Section_errors
+   Examples
+   Tools
+   Modify
+   Python
+   Errors
    Section_history
 
 .. toctree::
@@ -167,19 +166,8 @@ END_RST -->
   3.3 "Input script structure"_cmd_3 :b
   3.4 "Commands listed by category"_cmd_4 :b
   3.5 "Commands listed alphabetically"_cmd_5 :ule,b
-"Packages"_Section_packages.html :l
-  4.1 "Standard packages"_pkg_1 :ulb,b
-  4.2 "User packages"_pkg_2 :ule,b
-"Accelerating LAMMPS performance"_Section_accelerate.html :l
-  5.1 "Measuring performance"_acc_1 :ulb,b
-  5.2 "Algorithms and code options to boost performace"_acc_2 :b
-  5.3 "Accelerator packages with optimized styles"_acc_3 :b
-    5.3.1 "GPU package"_accelerate_gpu.html :b
-    5.3.2 "USER-INTEL package"_accelerate_intel.html :b
-    5.3.3 "KOKKOS package"_accelerate_kokkos.html :b
-    5.3.4 "USER-OMP package"_accelerate_omp.html :b
-    5.3.5 "OPT package"_accelerate_opt.html :b
-  5.4 "Comparison of various accelerator packages"_acc_4 :ule,b
+"Optional packages"_Packages.html :l
+"Accelerate performance"_Speed.html :l
 "How-to discussions"_Section_howto.html :l
   6.1 "Restarting a simulation"_howto_1 :ulb,b
   6.2 "2d simulations"_howto_2 :b
@@ -208,38 +196,11 @@ END_RST -->
   6.25 "Polarizable models"_howto_25 :b
   6.26 "Adiabatic core/shell model"_howto_26 :b
   6.27 "Drude induced dipoles"_howto_27 :ule,b
-"Example problems"_Section_example.html :l
-"Performance & scalability"_Section_perf.html :l
-"Additional tools"_Section_tools.html :l
-"Modifying & extending LAMMPS"_Section_modify.html :l
-  10.1 "Atom styles"_mod_1 :ulb,b
-  10.2 "Bond, angle, dihedral, improper potentials"_mod_2 :b
-  10.3 "Compute styles"_mod_3 :b
-  10.4 "Dump styles"_mod_4 :b
-  10.5 "Dump custom output options"_mod_5 :b
-  10.6 "Fix styles"_mod_6 :b
-  10.7 "Input script commands"_mod_7 :b
-  10.8 "Kspace computations"_mod_8 :b
-  10.9 "Minimization styles"_mod_9 :b
-  10.10 "Pairwise potentials"_mod_10 :b
-  10.11 "Region styles"_mod_11 :b
-  10.12 "Body styles"_mod_12 :b
-  10.13 "Thermodynamic output options"_mod_13 :b
-  10.14 "Variable options"_mod_14 :b
-  10.15 "Submitting new features for inclusion in LAMMPS"_mod_15 :ule,b
-"Python interface"_Section_python.html :l
-  11.1 "Overview of running LAMMPS from Python"_py_1 :ulb,b
-  11.2 "Overview of using Python from a LAMMPS script"_py_2 :b
-  11.3 "Building LAMMPS as a shared library"_py_3 :b
-  11.4 "Installing the Python wrapper into Python"_py_4 :b
-  11.5 "Extending Python with MPI to run in parallel"_py_5 :b
-  11.6 "Testing the Python-LAMMPS interface"_py_6 :b
-  11.7 "Using LAMMPS from Python"_py_7 :b
-  11.8 "Example Python scripts that use LAMMPS"_py_8 :ule,b
-"Errors"_Section_errors.html :l
-  12.1 "Common problems"_err_1 :ulb,b
-  12.2 "Reporting bugs"_err_2 :b
-  12.3 "Error & warning messages"_err_3 :ule,b
+"Example scripts"_Examples.html :l
+"Auxiliary tools"_Tools.html :l
+"Modify & extend LAMMPS"_Modify.html :l
+"Use Python with LAMMPS"_Python.html :l
+"Errors"_Errors.html :l
 "Future and history"_Section_history.html :l
   13.1 "Coming attractions"_hist_1 :ulb,b
   13.2 "Past versions"_hist_2 :ule,b
@@ -266,14 +227,6 @@ END_RST -->
 :link(cmd_4,Section_commands.html#cmd_4)
 :link(cmd_5,Section_commands.html#cmd_5)
 
-:link(pkg_1,Section_packages.html#pkg_1)
-:link(pkg_2,Section_packages.html#pkg_2)
-
-:link(acc_1,Section_accelerate.html#acc_1)
-:link(acc_2,Section_accelerate.html#acc_2)
-:link(acc_3,Section_accelerate.html#acc_3)
-:link(acc_4,Section_accelerate.html#acc_4)
-
 :link(howto_1,Section_howto.html#howto_1)
 :link(howto_2,Section_howto.html#howto_2)
 :link(howto_3,Section_howto.html#howto_3)
@@ -302,33 +255,6 @@ END_RST -->
 :link(howto_26,Section_howto.html#howto_26)
 :link(howto_27,Section_howto.html#howto_27)
 
-:link(mod_1,Section_modify.html#mod_1)
-:link(mod_2,Section_modify.html#mod_2)
-:link(mod_3,Section_modify.html#mod_3)
-:link(mod_4,Section_modify.html#mod_4)
-:link(mod_5,Section_modify.html#mod_5)
-:link(mod_6,Section_modify.html#mod_6)
-:link(mod_7,Section_modify.html#mod_7)
-:link(mod_8,Section_modify.html#mod_8)
-:link(mod_9,Section_modify.html#mod_9)
-:link(mod_10,Section_modify.html#mod_10)
-:link(mod_11,Section_modify.html#mod_11)
-:link(mod_12,Section_modify.html#mod_12)
-:link(mod_13,Section_modify.html#mod_13)
-:link(mod_14,Section_modify.html#mod_14)
-:link(mod_15,Section_modify.html#mod_15)
-
-:link(py_1,Section_python.html#py_1)
-:link(py_2,Section_python.html#py_2)
-:link(py_3,Section_python.html#py_3)
-:link(py_4,Section_python.html#py_4)
-:link(py_5,Section_python.html#py_5)
-:link(py_6,Section_python.html#py_6)
-
-:link(err_1,Section_errors.html#err_1)
-:link(err_2,Section_errors.html#err_2)
-:link(err_3,Section_errors.html#err_3)
-
 :link(hist_1,Section_history.html#hist_1)
 :link(hist_2,Section_history.html#hist_2)
 <!-- END_HTML_ONLY -->

doc/src/Modify.txt

@@ -0,0 +1,76 @@
+"Previous Section"_Tools.html - "LAMMPS WWW Site"_lws -
+"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
+Section"_Python.html :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+Modify & extend LAMMPS :h2
+
+LAMMPS is designed in a modular fashion so as to be easy to modify and
+extend with new functionality.  In fact, about 95% of its source code
+is add-on files.  These doc pages give basic instructions on how to do
+this.
+
+If you add a new feature to LAMMPS and think it will be of interest to
+general users, we encourage you to submit it for inclusion in LAMMPS
+as a pull request on our "GitHub
+site"_https://github.com/lammps/lammps, after reading the "Modify
+contribute"_Modify_contribute.html doc page.
+
+<!-- RST
+
+.. toctree::
+
+   Modify_overview
+   Modify_contribute
+
+.. toctree::
+
+   Modify_atom
+   Modify_pair
+   Modify_bond
+   Modify_compute
+   Modify_fix
+   Modify_command
+
+.. toctree::
+
+   Modify_dump
+   Modify_kspace
+   Modify_min
+   Modify_region
+   Modify_body
+
+.. toctree::
+
+   Modify_thermo
+   Modify_variable
+
+END_RST -->
+
+<!-- HTML_ONLY -->
+
+"Overview"_Modify_overview.html
+"Submitting new features for inclusion in LAMMPS"_Modify_contribute.html :all(b)
+
+"Atom styles"_Modify_atom.html
+"Pair styles"_Modify_pair.html
+"Bond, angle, dihedral, improper styles"_Modify_bond.html
+"Compute styles"_Modify_compute.html
+"Fix styles"_Modify_fix.html
+"Input script command styles"_Modify_command.html :all(b)
+
+"Dump styles"_Modify_dump.html
+"Kspace styles"_Modify_kspace.html
+"Minimization styles"_Modify_min.html
+"Region styles"_Modify_region.html
+"Body styles"_Modify_body.html :all(b)
+
+"Thermodynamic output options"_Modify_thermo.html
+"Variable options"_Modify_variable.html :all(b)
+
+<!-- END_HTML_ONLY -->

doc/src/Modify_atom.txt

@@ -0,0 +1,90 @@
+"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+Atom styles :h3
+
+Classes that define an "atom style"_atom_style.html are derived from
+the AtomVec class and managed by the Atom class.  The atom style
+determines what attributes are associated with an atom.  A new atom
+style can be created if one of the existing atom styles does not
+define all the attributes you need to store and communicate with
+atoms.
+
+Atom_vec_atomic.cpp is a simple example of an atom style.
+
+Here is a brief description of methods you define in your new derived
+class.  See atom_vec.h for details.
+
+init: one time setup (optional)
+grow: re-allocate atom arrays to longer lengths (required)
+grow_reset: make array pointers in Atom and AtomVec classes consistent (required)
+copy: copy info for one atom to another atom's array locations (required)
+pack_comm: store an atom's info in a buffer communicated every timestep (required)
+pack_comm_vel: add velocity info to communication buffer (required)
+pack_comm_hybrid: store extra info unique to this atom style (optional)
+unpack_comm: retrieve an atom's info from the buffer (required)
+unpack_comm_vel: also retrieve velocity info (required)
+unpack_comm_hybrid: retrieve extra info unique to this atom style (optional)
+pack_reverse: store an atom's info in a buffer communicating partial forces  (required)
+pack_reverse_hybrid: store extra info unique to this atom style (optional)
+unpack_reverse: retrieve an atom's info from the buffer (required)
+unpack_reverse_hybrid: retrieve extra info unique to this atom style (optional)
+pack_border: store an atom's info in a buffer communicated on neighbor re-builds (required)
+pack_border_vel: add velocity info to buffer (required)
+pack_border_hybrid: store extra info unique to this atom style (optional)
+unpack_border: retrieve an atom's info from the buffer (required)
+unpack_border_vel: also retrieve velocity info (required)
+unpack_border_hybrid: retrieve extra info unique to this atom style (optional)
+pack_exchange: store all an atom's info to migrate to another processor (required)
+unpack_exchange: retrieve an atom's info from the buffer (required)
+size_restart: number of restart quantities associated with proc's atoms (required)
+pack_restart: pack atom quantities into a buffer (required)
+unpack_restart: unpack atom quantities from a buffer (required)
+create_atom: create an individual atom of this style (required)
+data_atom: parse an atom line from the data file (required)
+data_atom_hybrid: parse additional atom info unique to this atom style (optional)
+data_vel: parse one line of velocity information from data file (optional)
+data_vel_hybrid: parse additional velocity data unique to this atom style (optional)
+memory_usage: tally memory allocated by atom arrays (required) :tb(s=:)
+
+The constructor of the derived class sets values for several variables
+that you must set when defining a new atom style, which are documented
+in atom_vec.h.  New atom arrays are defined in atom.cpp.  Search for
+the word "customize" and you will find locations you will need to
+modify.
+
+NOTE: It is possible to add some attributes, such as a molecule ID, to
+atom styles that do not have them via the "fix
+property/atom"_fix_property_atom.html command.  This command also
+allows new custom attributes consisting of extra integer or
+floating-point values to be added to atoms.  See the "fix
+property/atom"_fix_property_atom.html doc page for examples of cases
+where this is useful and details on how to initialize, access, and
+output the custom values.
+
+New "pair styles"_pair_style.html, "fixes"_fix.html, or
+"computes"_compute.html can be added to LAMMPS, as discussed below.
+The code for these classes can use the per-atom properties defined by
+fix property/atom.  The Atom class has a find_custom() method that is
+useful in this context:
+
+int index = atom->find_custom(char *name, int &flag); :pre
+
+The "name" of a custom attribute, as specified in the "fix
+property/atom"_fix_property_atom.html command, is checked to verify
+that it exists and its index is returned.  The method also sets flag =
+0/1 depending on whether it is an integer or floating-point attribute.
+The vector of values associated with the attribute can then be
+accessed using the returned index as
+
+int *ivector = atom->ivector\[index\];
+double *dvector = atom->dvector\[index\]; :pre
+
+Ivector or dvector are vectors of length Nlocal = # of owned atoms,
+which store the attributes of individual atoms.

doc/src/Modify_body.txt

@@ -0,0 +1,35 @@
+"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+Body styles :h3
+
+Classes that define body particles are derived from the Body class.
+Body particles can represent complex entities, such as surface meshes
+of discrete points, collections of sub-particles, deformable objects,
+etc.
+
+See "Section 6.14"_Section_howto.html#howto_14 of the manual for
+an overview of using body particles and the "body"_body.html doc page
+for details on the various body styles LAMMPS supports.  New styles
+can be created to add new kinds of body particles to LAMMPS.
+
+Body_nparticle.cpp is an example of a body particle that is treated as
+a rigid body containing N sub-particles.
+
+Here is a brief description of methods you define in your new derived
+class.  See body.h for details.
+
+data_body: process a line from the Bodies section of a data file
+noutrow: number of sub-particles output is generated for
+noutcol: number of values per-sub-particle output is generated for
+output: output values for the Mth sub-particle
+pack_comm_body: body attributes to communicate every timestep
+unpack_comm_body: unpacking of those attributes
+pack_border_body: body attributes to communicate when reneighboring is done
+unpack_border_body: unpacking of those attributes :tb(s=:)

doc/src/Modify_bond.txt

@@ -0,0 +1,33 @@
+"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+Bond, angle, dihedral, improper styles :h3
+
+Classes that compute molecular interactions are derived from the Bond,
+Angle, Dihedral, and Improper classes.  New styles can be created to
+add new potentials to LAMMPS.
+
+Bond_harmonic.cpp is the simplest example of a bond style.  Ditto for
+the harmonic forms of the angle, dihedral, and improper style
+commands.
+
+Here is a brief description of common methods you define in your
+new derived class.  See bond.h, angle.h, dihedral.h, and improper.h
+for details and specific additional methods.
+
+init: check if all coefficients are set, calls {init_style} (optional)
+init_style: check if style specific conditions are met (optional)
+compute: compute the molecular interactions (required)
+settings: apply global settings for all types (optional)
+coeff: set coefficients for one type (required)
+equilibrium_distance: length of bond, used by SHAKE (required, bond only)
+equilibrium_angle: opening of angle, used by SHAKE (required, angle only)
+write & read_restart: writes/reads coeffs to restart files (required)
+single: force and energy of a single bond or angle (required, bond or angle only)
+memory_usage: tally memory allocated by the style (optional) :tb(s=:)

doc/src/Modify_command.txt

@@ -0,0 +1,27 @@
+"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+Input script command style :h3
+
+New commands can be added to LAMMPS input scripts by adding new
+classes that have a "command" method.  For example, the create_atoms,
+read_data, velocity, and run commands are all implemented in this
+fashion.  When such a command is encountered in the LAMMPS input
+script, LAMMPS simply creates a class with the corresponding name,
+invokes the "command" method of the class, and passes it the arguments
+from the input script.  The command method can perform whatever
+operations it wishes on LAMMPS data structures.
+
+The single method your new class must define is as follows:
+
+command: operations performed by the new command :tb(s=:)
+
+Of course, the new class can define other methods and variables as
+needed.
+

doc/src/Modify_compute.txt

@@ -0,0 +1,49 @@
+"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+Compute styles :h3
+
+Classes that compute scalar and vector quantities like temperature
+and the pressure tensor, as well as classes that compute per-atom
+quantities like kinetic energy and the centro-symmetry parameter
+are derived from the Compute class.  New styles can be created
+to add new calculations to LAMMPS.
+
+Compute_temp.cpp is a simple example of computing a scalar
+temperature.  Compute_ke_atom.cpp is a simple example of computing
+per-atom kinetic energy.
+
+Here is a brief description of methods you define in your new derived
+class.  See compute.h for details.
+
+init: perform one time setup (required)
+init_list: neighbor list setup, if needed (optional)
+compute_scalar: compute a scalar quantity (optional)
+compute_vector: compute a vector of quantities (optional)
+compute_peratom: compute one or more quantities per atom (optional)
+compute_local: compute one or more quantities per processor (optional)
+pack_comm: pack a buffer with items to communicate (optional)
+unpack_comm: unpack the buffer (optional)
+pack_reverse: pack a buffer with items to reverse communicate (optional)
+unpack_reverse: unpack the buffer (optional)
+remove_bias: remove velocity bias from one atom (optional)
+remove_bias_all: remove velocity bias from all atoms in group (optional)
+restore_bias: restore velocity bias for one atom after remove_bias (optional)
+restore_bias_all: same as before, but for all atoms in group (optional)
+pair_tally_callback: callback function for {tally}-style computes (optional).
+memory_usage: tally memory usage (optional) :tb(s=:)
+
+Tally-style computes are a special case, as their computation is done
+in two stages: the callback function is registered with the pair style
+and then called from the Pair::ev_tally() function, which is called for
+each pair after force and energy has been computed for this pair. Then
+the tallied values are retrieved with the standard compute_scalar or
+compute_vector or compute_peratom methods. The USER-TALLY package
+provides {examples}_compute_tally.html for utilizing this mechanism.
+

doc/src/Modify_contribute.txt

@@ -0,0 +1,210 @@
+"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+Submitting new features for inclusion in LAMMPS :h3
+
+We encourage users to submit new features or modifications for LAMMPS
+to "the core developers"_http://lammps.sandia.gov/authors.html so they
+can be added to the LAMMPS distribution. The preferred way to manage
+and coordinate this is as of Fall 2016 via the LAMMPS project on
+"GitHub"_https://github.com/lammps/lammps. An alternative is to
+contact the LAMMPS developers or the indicated developer of a package
+or feature directly and send in your contribution via e-mail.
+
+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"_https://github.com/lammps/lammps/issues 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 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 "this
+tutorial"_tutorial_github.html 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 LAMMPS and
+contains all bugfixes from it. Then create a gzipped tar file of all
+changed or added files or a corresponding patch file using 'diff -u'
+or 'diff -c' and compress it with gzip. Please only use gzip
+compression, as this works well on all platforms.
+
+If the new features/files are broadly useful we may add them as core
+files to LAMMPS or as part of a "standard
+package"_Section_start.html#start_3.  Else we will add them as a
+user-contributed file or package.  Examples of user packages are in
+src sub-directories that start with USER.  The USER-MISC package is
+simply a collection of (mostly) unrelated single files, which is the
+simplest way to have your contribution quickly added to the LAMMPS
+distribution.  You can see a list of the both standard and user
+packages by typing "make package" in the LAMMPS src directory.
+
+Note that by providing us files to release, you are agreeing to make
+them open-source, i.e. we can release them under the terms of the GPL,
+used as a license for the rest of LAMMPS.  See "Section
+1.4"_Section_intro.html#intro_4 for details.
+
+With user packages and files, all we are really providing (aside from
+the fame and fortune that accompanies having your name in the source
+code and on the "Authors page"_http://lammps.sandia.gov/authors.html
+of the "LAMMPS WWW site"_lws), is a means for you to distribute your
+work to the LAMMPS user community, and a mechanism for others to
+easily try out your new feature.  This may help you find bugs or make
+contact with new collaborators.  Note that you're also implicitly
+agreeing to support your code which means answer questions, fix bugs,
+and maintain it if LAMMPS changes in some way that breaks it (an
+unusual event).
+
+NOTE: If you prefer to actively develop and support your add-on
+feature yourself, then you may wish to make it available for download
+from your own website, as a user package that LAMMPS users can add to
+their copy of LAMMPS.  See the "Offsite LAMMPS packages and
+tools"_http://lammps.sandia.gov/offsite.html page of the LAMMPS web
+site for examples of groups that do this.  We are happy to advertise
+your package and web site from that page.  Simply email the
+"developers"_http://lammps.sandia.gov/authors.html with info about
+your package and we will post it there.
+
+The previous sections of this doc page describe how to add new "style"
+files of various kinds to LAMMPS.  Packages are simply collections of
+one or more new class files which are invoked as a new style within a
+LAMMPS input script.  If designed correctly, these additions typically
+do not require changes to the main core of LAMMPS; they are simply
+add-on files.  If you think your new feature requires non-trivial
+changes in core LAMMPS files, you'll need to "communicate with the
+developers"_http://lammps.sandia.gov/authors.html, since we may or may
+not want to make those changes.  An example of a trivial change is
+making a parent-class method "virtual" when you derive a new child
+class from it.
+
+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 src dir for
+examples. If you are uncertain, please ask.
+
+All source files you provide must compile with the most current
+version of LAMMPS with multiple configurations. In particular you
+need to test compiling LAMMPS from scratch with -DLAMMPS_BIGBIG
+set in addition to the default -DLAMMPS_SMALLBIG setting. Your code
+will need to work correctly in serial and in parallel using MPI. :ulb,l
+
+For consistency with the rest of LAMMPS and especially, if you want
+your contribution(s) to be added to main LAMMPS code or one of its
+standard packages, it needs to be written in a style compatible with
+other LAMMPS source files. This means: 2-character indentation per
+level, [no tabs], no lines over 80 characters. I/O is done via
+the C-style stdio library, class header files should not import any
+system headers outside <stdio.h>, STL containers should be avoided
+in headers, and forward declarations used where possible or needed.
+All added code should be placed into the LAMMPS_NS namespace or a
+sub-namespace; global or static variables should be avoided, as they
+conflict with the modular nature of LAMMPS and the C++ class structure.
+Header files must [not] import namespaces with {using}.
+This all is so the developers can more easily understand, integrate,
+and maintain your contribution and reduce conflicts with other parts
+of LAMMPS.  This basically means that the code accesses data
+structures, performs its operations, and is formatted similar to other
+LAMMPS source files, including the use of the error class for error
+and warning messages. :l
+
+If you want your contribution to be added as a user-contributed
+feature, and it's a single file (actually a *.cpp and *.h file) it can
+rapidly be added to the USER-MISC directory.  Send us the one-line
+entry to add to the USER-MISC/README file in that dir, along with the
+2 source files.  You can do this multiple times if you wish to
+contribute several individual features.  :l
+
+If you want your contribution to be added as a user-contribution and
+it is several related features, it is probably best to make it a user
+package directory with a name like USER-FOO.  In addition to your new
+files, the directory should contain a README text file.  The README
+should contain your name and contact information and a brief
+description of what your new package does.  If your files depend on
+other LAMMPS style files also being installed (e.g. because your file
+is a derived class from the other LAMMPS class), then an Install.sh
+file is also needed to check for those dependencies.  See other README
+and Install.sh files in other USER directories as examples.  Send us a
+tarball of this USER-FOO directory. :l
+
+Your new source files need to have the LAMMPS copyright, GPL notice,
+and your name and email address at the top, like other
+user-contributed LAMMPS source files.  They need to create a class
+that is inside the LAMMPS namespace.  If the file is for one of the
+
+USER packages, including USER-MISC, then we are not as picky about the
+coding style (see above).  I.e. the files do not need to be in the
+same stylistic format and syntax as other LAMMPS files, though that
+would be nice for developers as well as users who try to read your
+code. :l
+
+You [must] also create a [documentation] file for each new command or
+style you are adding to LAMMPS. For simplicity and convenience, the
+documentation of groups of closely related commands or styles may be
+combined into a single file.  This will be one file for a single-file
+feature.  For a package, it might be several files.  These are simple
+text files with a specific markup language, that are then auto-converted
+to HTML and PDF. The tools for this conversion are included in the
+source distribution, and the translation can be as simple as doing
+"make html pdf" in the doc folder.
+Thus the documentation source files must be in the same format and
+style as other *.txt files in the lammps/doc/src directory for similar
+commands and styles; use one or more of them as a starting point.
+A description of the markup can also be found in
+lammps/doc/utils/txt2html/README.html
+As appropriate, the text files can include links to equations
+(see doc/Eqs/*.tex for examples, we auto-create the associated JPG
+files), or figures (see doc/JPG for examples), or even additional PDF
+files with further details (see doc/PDF for examples).  The doc page
+should also include literature citations as appropriate; see the
+bottom of doc/fix_nh.txt for examples and the earlier part of the same
+file for how to format the cite itself.  The "Restrictions" section of
+the doc page should indicate that your command is only available if
+LAMMPS is built with the appropriate USER-MISC or USER-FOO package.
+See other user package doc files for examples of how to do this. The
+prerequisite for building the HTML format files are Python 3.x and
+virtualenv, the requirement for generating the PDF format manual
+is the "htmldoc"_http://www.htmldoc.org/ software. Please run at least
+"make html" and carefully inspect and proofread the resulting HTML format
+doc page before submitting your code. :l
+
+For a new package (or even a single command) you should include one or
+more example scripts demonstrating its use.  These should run in no
+more than a couple minutes, even on a single processor, and not require
+large data files as input.  See directories under examples/USER for
+examples of input scripts other users provided for their packages.
+These example inputs are also required for validating memory accesses
+and testing for memory leaks with valgrind :l
+
+If there is a paper of yours describing your feature (either the
+algorithm/science behind the feature itself, or its initial usage, or
+its implementation in LAMMPS), you can add the citation to the *.cpp
+source file.  See src/USER-EFF/atom_vec_electron.cpp for an example.
+A LaTeX citation is stored in a variable at the top of the file and a
+single line of code that references the variable is added to the
+constructor of the class.  Whenever a user invokes your feature from
+their input script, this will cause LAMMPS to output the citation to a
+log.cite file and prompt the user to examine the file.  Note that you
+should only use this for a paper you or your group authored.
+E.g. adding a cite in the code for a paper by Nose and Hoover if you
+write a fix that implements their integrator is not the intended
+usage.  That kind of citation should just be in the doc page you
+provide. :l
+:ule
+
+Finally, as a general rule-of-thumb, the more clear and
+self-explanatory you make your documentation and README files, and the
+easier you make it for people to get started, e.g. by providing example
+scripts, the more likely it is that users will try out your new feature.

doc/src/Modify_dump.txt

@@ -0,0 +1,35 @@
+"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+Dump styles :h3
+
+Classes that dump per-atom info to files are derived from the Dump
+class.  To dump new quantities or in a new format, a new derived dump
+class can be added, but it is typically simpler to modify the
+DumpCustom class contained in the dump_custom.cpp file.
+
+Dump_atom.cpp is a simple example of a derived dump class.
+
+Here is a brief description of methods you define in your new derived
+class.  See dump.h for details.
+
+write_header: write the header section of a snapshot of atoms
+count: count the number of lines a processor will output
+pack: pack a proc's output data into a buffer
+write_data: write a proc's data to a file :tb(s=:)
+
+See the "dump"_dump.html command and its {custom} style for a list of
+keywords for atom information that can already be dumped by
+DumpCustom.  It includes options to dump per-atom info from Compute
+classes, so adding a new derived Compute class is one way to calculate
+new quantities to dump.
+
+Note that new keywords for atom properties are not typically
+added to the "dump custom"_dump.html command.  Instead they are added
+to the "compute property/atom"_compute_property_atom.html command.

doc/src/Modify_fix.txt

@@ -0,0 +1,107 @@
+"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+Fix styles :h3
+
+In LAMMPS, a "fix" is any operation that is computed during
+timestepping that alters some property of the system.  Essentially
+everything that happens during a simulation besides force computation,
+neighbor list construction, and output, is a "fix".  This includes
+time integration (update of coordinates and velocities), force
+constraints or boundary conditions (SHAKE or walls), and diagnostics
+(compute a diffusion coefficient).  New styles can be created to add
+new options to LAMMPS.
+
+Fix_setforce.cpp is a simple example of setting forces on atoms to
+prescribed values.  There are dozens of fix options already in LAMMPS;
+choose one as a template that is similar to what you want to
+implement.
+
+Here is a brief description of methods you can define in your new
+derived class.  See fix.h for details.
+
+setmask: determines when the fix is called during the timestep (required)
+init: initialization before a run (optional)
+setup_pre_exchange: called before atom exchange in setup (optional)
+setup_pre_force: called before force computation in setup (optional)
+setup: called immediately before the 1st timestep and after forces are computed (optional)
+min_setup_pre_force: like setup_pre_force, but for minimizations instead of MD runs (optional)
+min_setup: like setup, but for minimizations instead of MD runs (optional)
+initial_integrate: called at very beginning of each timestep (optional)
+pre_exchange: called before atom exchange on re-neighboring steps (optional)
+pre_neighbor: called before neighbor list build (optional)
+pre_force: called before pair & molecular forces are computed (optional)
+post_force: called after pair & molecular forces are computed and communicated (optional)
+final_integrate: called at end of each timestep (optional)
+end_of_step: called at very end of timestep (optional)
+write_restart: dumps fix info to restart file (optional)
+restart: uses info from restart file to re-initialize the fix (optional)
+grow_arrays: allocate memory for atom-based arrays used by fix (optional)
+copy_arrays: copy atom info when an atom migrates to a new processor (optional)
+pack_exchange: store atom's data in a buffer (optional)
+unpack_exchange: retrieve atom's data from a buffer (optional)
+pack_restart: store atom's data for writing to restart file (optional)
+unpack_restart: retrieve atom's data from a restart file buffer (optional)
+size_restart: size of atom's data (optional)
+maxsize_restart: max size of atom's data (optional)
+setup_pre_force_respa: same as setup_pre_force, but for rRESPA (optional)
+initial_integrate_respa: same as initial_integrate, but for rRESPA (optional)
+post_integrate_respa: called after the first half integration step is done in rRESPA (optional)
+pre_force_respa: same as pre_force, but for rRESPA (optional)
+post_force_respa: same as post_force, but for rRESPA (optional)
+final_integrate_respa: same as final_integrate, but for rRESPA (optional)
+min_pre_force: called after pair & molecular forces are computed in minimizer (optional)
+min_post_force: called after pair & molecular forces are computed and communicated in minimizer (optional)
+min_store: store extra data for linesearch based minimization on a LIFO stack (optional)
+min_pushstore: push the minimization LIFO stack one element down (optional)
+min_popstore: pop the minimization LIFO stack one element up (optional)
+min_clearstore: clear minimization LIFO stack (optional)
+min_step: reset or move forward on line search minimization (optional)
+min_dof: report number of degrees of freedom {added} by this fix in minimization (optional)
+max_alpha: report maximum allowed step size during linesearch minimization (optional)
+pack_comm: pack a buffer to communicate a per-atom quantity (optional)
+unpack_comm: unpack a buffer to communicate a per-atom quantity (optional)
+pack_reverse_comm: pack a buffer to reverse communicate a per-atom quantity (optional)
+unpack_reverse_comm: unpack a buffer to reverse communicate a per-atom quantity (optional)
+dof: report number of degrees of freedom {removed} by this fix during MD (optional)
+compute_scalar: return a global scalar property that the fix computes (optional)
+compute_vector: return a component of a vector property that the fix computes (optional)
+compute_array: return a component of an array property that the fix computes (optional)
+deform: called when the box size is changed (optional)
+reset_target: called when a change of the target temperature is requested during a run (optional)
+reset_dt: is called when a change of the time step is requested during a run (optional)
+modify_param: called when a fix_modify request is executed (optional)
+memory_usage: report memory used by fix (optional)
+thermo: compute quantities for thermodynamic output (optional) :tb(s=:)
+
+Typically, only a small fraction of these methods are defined for a
+particular fix.  Setmask is mandatory, as it determines when the fix
+will be invoked during the timestep.  Fixes that perform time
+integration ({nve}, {nvt}, {npt}) implement initial_integrate() and
+final_integrate() to perform velocity Verlet updates.  Fixes that
+constrain forces implement post_force().
+
+Fixes that perform diagnostics typically implement end_of_step().  For
+an end_of_step fix, one of your fix arguments must be the variable
+"nevery" which is used to determine when to call the fix and you must
+set this variable in the constructor of your fix.  By convention, this
+is the first argument the fix defines (after the ID, group-ID, style).
+
+If the fix needs to store information for each atom that persists from
+timestep to timestep, it can manage that memory and migrate the info
+with the atoms as they move from processors to processor by
+implementing the grow_arrays, copy_arrays, pack_exchange, and
+unpack_exchange methods.  Similarly, the pack_restart and
+unpack_restart methods can be implemented to store information about
+the fix in restart files.  If you wish an integrator or force
+constraint fix to work with rRESPA (see the "run_style"_run_style.html
+command), the initial_integrate, post_force_integrate, and
+final_integrate_respa methods can be implemented.  The thermo method
+enables a fix to contribute values to thermodynamic output, as printed
+quantities and/or to be summed to the potential energy of the system.

doc/src/Modify_kspace.txt

@@ -0,0 +1,25 @@
+"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+Kspace styles :h3
+
+Classes that compute long-range Coulombic interactions via K-space
+representations (Ewald, PPPM) are derived from the KSpace class.  New
+styles can be created to add new K-space options to LAMMPS.
+
+Ewald.cpp is an example of computing K-space interactions.
+
+Here is a brief description of methods you define in your new derived
+class.  See kspace.h for details.
+
+init: initialize the calculation before a run
+setup: computation before the 1st timestep of a run
+compute: every-timestep computation
+memory_usage: tally of memory usage :tb(s=:)
+

doc/src/Modify_min.txt

@@ -0,0 +1,23 @@
+"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+Minimization styles :h3
+
+Classes that perform energy minimization derived from the Min class.
+New styles can be created to add new minimization algorithms to
+LAMMPS.
+
+Min_cg.cpp is an example of conjugate gradient minimization.
+
+Here is a brief description of methods you define in your new derived
+class.  See min.h for details.
+
+init: initialize the minimization before a run
+run: perform the minimization
+memory_usage: tally of memory usage :tb(s=:)

doc/src/Modify_overview.txt

@@ -0,0 +1,101 @@
+"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+Overview :h3
+
+The best way to add a new feature to LAMMPS is to find a similar
+featureand look at the corresponding source and header files to figure
+out what it does.  You will need some knowledge of C++ to be able to
+understand the hi-level structure of LAMMPS and its class
+organization, but functions (class methods) that do actual
+computations are written in vanilla C-style code and operate on simple
+C-style data structures (vectors and arrays).
+
+Most of the new features described on the "Modify"_Modify.html doc
+page require you to write a new C++ derived class (except for
+exceptions described below, where you can make small edits to existing
+files).  Creating a new class requires 2 files, a source code file
+(*.cpp) and a header file (*.h).  The derived class must provide
+certain methods to work as a new option.  Depending on how different
+your new feature is compared to existing features, you can either
+derive from the base class itself, or from a derived class that
+already exists.  Enabling LAMMPS to invoke the new class is as simple
+as putting the two source files in the src dir and re-building LAMMPS.
+
+The advantage of C++ and its object-orientation is that all the code
+and variables needed to define the new feature are in the 2 files you
+write, and thus shouldn't make the rest of LAMMPS more complex or
+cause side-effect bugs.
+
+Here is a concrete example.  Suppose you write 2 files pair_foo.cpp
+and pair_foo.h that define a new class PairFoo that computes pairwise
+potentials described in the classic 1997 "paper"_#Foo by Foo, et al.
+If you wish to invoke those potentials in a LAMMPS input script with a
+command like
+
+pair_style foo 0.1 3.5 :pre
+
+then your pair_foo.h file should be structured as follows:
+
+#ifdef PAIR_CLASS
+PairStyle(foo,PairFoo)
+#else
+...
+(class definition for PairFoo)
+...
+#endif :pre
+
+where "foo" is the style keyword in the pair_style command, and
+PairFoo is the class name defined in your pair_foo.cpp and pair_foo.h
+files.
+
+When you re-build LAMMPS, your new pairwise potential becomes part of
+the executable and can be invoked with a pair_style command like the
+example above.  Arguments like 0.1 and 3.5 can be defined and
+processed by your new class.
+
+As illustrated by this pairwise example, many kinds of options are
+referred to in the LAMMPS documentation as the "style" of a particular
+command.
+
+The "Modify page"_Modify.html lists all the common styles in LAMMPS,
+and discusses the header file for the base class that these styles are
+derived from.  Public variables in that file are ones used and set by
+the derived classes which are also used by the base class.  Sometimes
+they are also used by the rest of LAMMPS.  Virtual functions in the
+base class header file which are set = 0 are ones you must define in
+your new derived class to give it the functionality LAMMPS expects.
+Virtual functions that are not set to 0 are functions you can
+optionally define.
+
+Additionally, new output options can be added directly to the
+thermo.cpp, dump_custom.cpp, and variable.cpp files.  These are also
+listed on the "Modify page"_Modify.html.
+
+Here are additional guidelines for modifying LAMMPS and adding new
+functionality:
+
+Think about whether what you want to do would be better as a pre- or
+post-processing step.  Many computations are more easily and more
+quickly done that way. :ulb,l
+
+Don't do anything within the timestepping of a run that isn't
+parallel.  E.g. don't accumulate a bunch of data on a single processor
+and analyze it.  You run the risk of seriously degrading the parallel
+efficiency. :l
+
+If your new feature reads arguments or writes output, make sure you
+follow the unit conventions discussed by the "units"_units.html
+command. :l
+:ule
+
+:line
+
+:link(Foo)
+[(Foo)] Foo, Morefoo, and Maxfoo, J of Classic Potentials, 75, 345 (1997).

doc/src/Modify_pair.txt

@@ -0,0 +1,33 @@
+"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+Pair styles :h3
+
+Classes that compute pairwise interactions are derived from the Pair
+class.  In LAMMPS, pairwise calculation include manybody 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.
+
+Pair_lj_cut.cpp is a simple example of a Pair class, though it
+includes some optional methods to enable its use with rRESPA.
+
+Here is a brief description of the class methods in pair.h:
+
+compute: workhorse routine that computes pairwise interactions
+settings: reads the input script line with arguments you define
+coeff: set coefficients for one i,j type pair
+init_one: perform initialization for one i,j type pair
+init_style: initialization specific to this pair style
+write & read_restart: write/read i,j pair coeffs to restart files
+write & read_restart_settings: write/read global settings to restart files
+single: force and energy of a single pairwise interaction between 2 atoms
+compute_inner/middle/outer: versions of compute used by rRESPA :tb(s=:)
+
+The inner/middle/outer routines are optional.

doc/src/Modify_region.txt

@@ -0,0 +1,25 @@
+"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+Region styles :h3
+
+Classes that define geometric regions are derived from the Region
+class.  Regions are used elsewhere in LAMMPS to group atoms, delete
+atoms to create a void, insert atoms in a specified region, etc.  New
+styles can be created to add new region shapes to LAMMPS.
+
+Region_sphere.cpp is an example of a spherical region.
+
+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
+shape_update : change region shape if set by time-dependent variable :tb(s=:)

doc/src/Modify_thermo.txt

@@ -0,0 +1,35 @@
+"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+Thermodynamic output options :h3
+
+There is one class that computes and prints thermodynamic information
+to the screen and log file; see the file thermo.cpp.
+
+There are two styles defined in thermo.cpp: "one" and "multi".  There
+is also a flexible "custom" style which allows the user to explicitly
+list keywords for quantities to print when thermodynamic info is
+output.  See the "thermo_style"_thermo_style.html command for a list
+of defined quantities.
+
+The thermo styles (one, multi, etc) are simply lists of keywords.
+Adding a new style thus only requires defining a new list of keywords.
+Search for the word "customize" with references to "thermo style" in
+thermo.cpp to see the two locations where code will need to be added.
+
+New keywords can also be added to thermo.cpp to compute new quantities
+for output.  Search for the word "customize" with references to
+"keyword" in thermo.cpp to see the several locations where code will
+need to be added.
+
+Note that the "thermo_style custom"_thermo.html command already allows
+for thermo output of quantities calculated by "fixes"_fix.html,
+"computes"_compute.html, and "variables"_variable.html.  Thus, it may
+be simpler to compute what you wish via one of those constructs, than
+by adding a new keyword to the thermo command.

doc/src/Modify_variable.txt

@@ -0,0 +1,46 @@
+"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+Variable options :h3
+
+There is one class that computes and stores "variable"_variable.html
+information in LAMMPS; see the file variable.cpp.  The value
+associated with a variable can be periodically printed to the screen
+via the "print"_print.html, "fix print"_fix_print.html, or
+"thermo_style custom"_thermo_style.html commands.  Variables of style
+"equal" can compute complex equations that involve the following types
+of arguments:
+
+thermo keywords = ke, vol, atoms, ...
+other variables = v_a, v_myvar, ...
+math functions = div(x,y), mult(x,y), add(x,y), ...
+group functions = mass(group), xcm(group,x), ...
+atom values = x\[123\], y\[3\], vx\[34\], ...
+compute values = c_mytemp\[0\], c_thermo_press\[3\], ... :pre
+
+Adding keywords for the "thermo_style custom"_thermo_style.html
+command (which can then be accessed by variables) is discussed on the
+"Modify thermo"_Modify_thermo.html doc page.
+
+Adding a new math function of one or two arguments can be done by
+editing one section of the Variable::evaluate() method.  Search for
+the word "customize" to find the appropriate location.
+
+Adding a new group function can be done by editing one section of the
+Variable::evaluate() method.  Search for the word "customize" to find
+the appropriate location.  You may need to add a new method to the
+Group class as well (see the group.cpp file).
+
+Accessing a new atom-based vector can be done by editing one section
+of the Variable::evaluate() method.  Search for the word "customize"
+to find the appropriate location.
+
+Adding new "compute styles"_compute.html (whose calculated values can
+then be accessed by variables) is discussed on the "Modify
+compute"_Modify_compute.html doc page.

doc/src/Packages.txt

@@ -0,0 +1,39 @@
+"Previous Section"_Section_commands.html - "LAMMPS WWW Site"_lws -
+"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
+Section"_Speed.html :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+Optional packages :h2
+
+This section gives an overview of the optional packages that extend
+LAMMPS functionality.  Packages are groups of files that enable a
+specific set of features.  For example, force fields for molecular
+systems or rigid-body constraint are in packages.  You can see the
+list of all packages and "make" commands to manage them by typing
+"make package" from within the src directory of the LAMMPS
+distribution.  "Section 2.3"_Section_start.html#start_3 gives general
+info on how to install and un-install packages as part of the LAMMPS
+build process.
+
+<!-- RST
+
+.. toctree::
+
+   Packages_standard
+   Packages_user
+   Packages_details
+
+END_RST -->
+
+<!-- HTML_ONLY -->
+
+"Standard packages"_Packages_standard.html
+"User packages"_Packages_user.html
+"Details on each package"_Packages_details.html :ul
+
+<!-- END_HTML_ONLY -->

doc/src/Packages_details.txt

@@ -1,6 +1,5 @@
-"Previous Section"_Section_commands.html - "LAMMPS WWW Site"_lws -
-"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
-Section"_Section_accelerate.html :c
+"Higher level section"_Packages.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
 
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
@@ -8,151 +7,89 @@ Section"_Section_accelerate.html :c
 
 :line
 
-4. Packages :h2
+Package details :h3
 
-This section gives an overview of the optional packages that extend
-LAMMPS functionality with instructions on how to build LAMMPS with
-each of them.  Packages are groups of files that enable a specific set
-of features.  For example, force fields for molecular systems or
-granular systems are in packages.  You can see the list of all
-packages and "make" commands to manage them by typing "make package"
-from within the src directory of the LAMMPS distribution.  "Section
-2.3"_Section_start.html#start_3 gives general info on how to install
-and un-install packages as part of the LAMMPS build process.
-
-There are two kinds of packages in LAMMPS, standard and user packages:
-
-"Table of standard packages"_#table_standard
-"Table of user packages"_#table_user :ul
-
-Either of these kinds of packages may work as is, may require some
-additional code compiled located in the lib folder, or may require
-an external library to be downloaded, compiled, installed, and LAMMPS
-configured to know about its location and additional compiler flags.
-You can often do the build of the internal or external libraries
-in one step by typing "make lib-name args='...'" from the src dir,
-with appropriate arguments included in args='...'. If you just type
-"make lib-name" you should see a help message about supported flags
-and some examples. For more details about this, please study the
-tables below and the sections about the individual packages.
-
-Standard packages are supported by the LAMMPS developers and are
-written in a syntax and style consistent with the rest of LAMMPS.
-This means the developers will answer questions about them, debug and
-fix them if necessary, and keep them compatible with future changes to
-LAMMPS.
-
-User packages have been contributed by users, and begin with the
-"user" prefix.  If they are a single command (single file), they are
-typically in the user-misc package.  User packages don't necessarily
-meet the requirements of the standard packages. This means the
-developers will try to keep things working and usually can answer
-technical questions about compiling the package. If you have problems
-using a feature provided in a user package, you may need to contact
-the contributor directly to get help.  Information on how to submit
-additions you make to LAMMPS as single files or as a standard or user
-package are given in "this section"_Section_modify.html#mod_15 of the
-manual.
-
-Following the next two tables is a sub-section for each package.  It
-lists authors (if applicable) and summarizes the package contents.  It
-has specific instructions on how to install the package, including (if
-necessary) downloading or building any extra library it requires. It
-also gives links to documentation, example scripts, and
-pictures/movies (if available) that illustrate use of the package.
+Here is a brief description of all the standard and user packages in
+LAMMPS.  It lists authors (if applicable) and summarizes the package
+contents.  It has specific instructions on how to install the package,
+including, if necessary, info on how to download or build any extra
+library it requires.  It also gives links to documentation, example
+scripts, and pictures/movies (if available) that illustrate use of the
+package.
 
 NOTE: To see the complete list of commands a package adds to LAMMPS,
-just look at the files in its src directory, e.g. "ls src/GRANULAR".
-Files with names that start with fix, compute, atom, pair, bond,
-angle, etc correspond to commands with the same style names.
+you can examine the files in its src directory, e.g. "ls
+src/GRANULAR".  Files with names that start with fix, compute, atom,
+pair, bond, angle, etc correspond to commands with the same style name
+as contained in the file name.
 
-In these two tables, the "Example" column is a sub-directory in the
-examples directory of the distribution which has an input script that
-uses the package.  E.g. "peptide" refers to the examples/peptide
-directory; USER/atc refers to the examples/USER/atc directory.  The
-"Library" column indicates whether an extra library is needed to build
-and use the package:
+"ASPHERE"_#ASPHERE,
+"BODY"_#BODY,
+"CLASS2"_#CLASS2,
+"COLLOID"_#COLLOID,
+"COMPRESS"_#COMPRESS,
+"CORESHELL"_#CORESHELL,
+"DIPOLE"_#DIPOLE,
+"GPU"_#GPU,
+"GRANULAR"_#GRANULAR,
+"KIM"_#KIM,
+"KOKKOS"_#KOKKOS,
+"KSPACE"_#KSPACE,
+"LATTE"_#LATTE,
+"MANYBODY"_#MANYBODY,
+"MC"_#MC,
+"MEAM"_#MEAM,
+"MISC"_#MISC,
+"MOLECULE"_#MOLECULE,
+"MPIIO"_#MPIIO,
+"MSCG"_#MSCG,
+"OPT"_#OPT,
+"PERI"_#PERI,
+"POEMS"_#POEMS,
+"PYTHON"_#PYTHON,
+"QEQ"_#QEQ,
+"REAX"_#REAX,
+"REPLICA"_#REPLICA,
+"RIGID"_#RIGID,
+"SHOCK"_#SHOCK,
+"SNAP"_#SNAP,
+"SRD"_#SRD,
+"VORONOI"_#VORONOI :tb(c=6,ea=c)
 
-dash = no library
-sys = system library: you likely have it on your machine
-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
-
-:line
-:line
-
-[Standard packages] :link(table_standard),p
-
-Package, Description, Doc page, Example, Library
-"ASPHERE"_#ASPHERE, aspherical particle models, "Section 6.6.14"_Section_howto.html#howto_14, ellipse, -
-"BODY"_#BODY, body-style particles, "body"_body.html, body, -
-"CLASS2"_#CLASS2, class 2 force fields, "pair_style lj/class2"_pair_class2.html, -, -
-"COLLOID"_#COLLOID, colloidal particles, "atom_style colloid"_atom_style.html, colloid, -
-"COMPRESS"_#COMPRESS, I/O compression, "dump */gz"_dump.html, -, sys
-"CORESHELL"_#CORESHELL, adiabatic core/shell model, "Section 6.6.25"_Section_howto.html#howto_25, coreshell, -
-"DIPOLE"_#DIPOLE, point dipole particles, "pair_style dipole/cut"_pair_dipole.html, dipole, -
-"GPU"_#GPU, GPU-enabled styles, "Section 5.3.1"_accelerate_gpu.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, int
-"GRANULAR"_#GRANULAR, granular systems, "Section 6.6.6"_Section_howto.html#howto_6, pour, -
-"KIM"_#KIM, OpenKIM wrapper, "pair_style kim"_pair_kim.html, kim, ext
-"KOKKOS"_#KOKKOS, Kokkos-enabled styles, "Section 5.3.3"_accelerate_kokkos.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, -
-"KSPACE"_#KSPACE, long-range Coulombic solvers, "kspace_style"_kspace_style.html, peptide, -
-"LATTE"_#LATTE, quantum DFTB forces via LATTE, "fix latte"_fix_latte.html, latte, ext
-"MANYBODY"_#MANYBODY, many-body potentials, "pair_style tersoff"_pair_tersoff.html, shear, -
-"MC"_#MC, Monte Carlo options, "fix gcmc"_fix_gcmc.html, -, -
-"MEAM"_#MEAM, modified EAM potential, "pair_style meam"_pair_meam.html, meam, int
-"MISC"_#MISC, miscellanous single-file commands, -, -, -
-"MOLECULE"_#MOLECULE, molecular system force fields, "Section 6.6.3"_Section_howto.html#howto_3, peptide, -
-"MPIIO"_#MPIIO, MPI parallel I/O dump and restart, "dump"_dump.html, -, -
-"MSCG"_#MSCG, multi-scale coarse-graining wrapper, "fix mscg"_fix_mscg.html, mscg, ext
-"OPT"_#OPT, optimized pair styles, "Section 5.3.5"_accelerate_opt.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, -
-"PERI"_#PERI, Peridynamics models, "pair_style peri"_pair_peri.html, peri, -
-"POEMS"_#POEMS, coupled rigid body motion, "fix poems"_fix_poems.html, rigid, int
-"PYTHON"_#PYTHON, embed Python code in an input script, "python"_python.html, python, sys
-"QEQ"_#QEQ, QEq charge equilibration, "fix qeq"_fix_qeq.html, qeq, -
-"REAX"_#REAX, ReaxFF potential (Fortran), "pair_style reax"_pair_reax.html, reax, int
-"REPLICA"_#REPLICA, multi-replica methods, "Section 6.6.5"_Section_howto.html#howto_5, tad, -
-"RIGID"_#RIGID, rigid bodies and constraints, "fix rigid"_fix_rigid.html, rigid, -
-"SHOCK"_#SHOCK, shock loading methods, "fix msst"_fix_msst.html, -, -
-"SNAP"_#SNAP, quantum-fitted potential, "pair_style snap"_pair_snap.html, snap, -
-"SRD"_#SRD, stochastic rotation dynamics, "fix srd"_fix_srd.html, srd, -
-"VORONOI"_#VORONOI, Voronoi tesselation, "compute voronoi/atom"_compute_voronoi_atom.html, -, ext :tb(ea=c,ca1=l)
-
-[USER packages] :link(table_user),p
-
-Package, Description, Doc page, Example, Library
-"USER-ATC"_#USER-ATC, atom-to-continuum coupling, "fix atc"_fix_atc.html, USER/atc, int
-"USER-AWPMD"_#USER-AWPMD, wave-packet MD, "pair_style awpmd/cut"_pair_awpmd.html, USER/awpmd, int
-"USER-CGDNA"_#USER-CGDNA, coarse-grained DNA force fields, src/USER-CGDNA/README, USER/cgdna, -
-"USER-CGSDK"_#USER-CGSDK, SDK coarse-graining model, "pair_style lj/sdk"_pair_sdk.html, USER/cgsdk, -
-"USER-COLVARS"_#USER-COLVARS, collective variables library, "fix colvars"_fix_colvars.html, USER/colvars, int
-"USER-DIFFRACTION"_#USER-DIFFRACTION, virtual x-ray and electron diffraction,"compute xrd"_compute_xrd.html, USER/diffraction, -
-"USER-DPD"_#USER-DPD, reactive dissipative particle dynamics, src/USER-DPD/README, USER/dpd, -
-"USER-DRUDE"_#USER-DRUDE, Drude oscillators, "tutorial"_tutorial_drude.html, USER/drude, -
-"USER-EFF"_#USER-EFF, electron force field,"pair_style eff/cut"_pair_eff.html, USER/eff, -
-"USER-FEP"_#USER-FEP, free energy perturbation,"compute fep"_compute_fep.html, USER/fep, -
-"USER-H5MD"_#USER-H5MD, dump output via HDF5,"dump h5md"_dump_h5md.html, -, ext
-"USER-INTEL"_#USER-INTEL, optimized Intel CPU and KNL styles,"Section 5.3.2"_accelerate_intel.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, -
-"USER-LB"_#USER-LB, Lattice Boltzmann fluid,"fix lb/fluid"_fix_lb_fluid.html, USER/lb, -
-"USER-MANIFOLD"_#USER-MANIFOLD, motion on 2d surfaces,"fix manifoldforce"_fix_manifoldforce.html, USER/manifold, -
-"USER-MEAMC"_#USER-MEAMC, modified EAM potential (C++), "pair_style meam/c"_pair_meam.html, meam, -
-"USER-MESO"_#USER-MESO, mesoscale DPD models, "pair_style edpd"_pair_meso.html, USER/meso, -
-"USER-MGPT"_#USER-MGPT, fast MGPT multi-ion potentials, "pair_style mgpt"_pair_mgpt.html, USER/mgpt, -
-"USER-MISC"_#USER-MISC, single-file contributions, USER-MISC/README, USER/misc, -
-"USER-MOFFF"_#USER-MOFFF, styles for "MOF-FF"_MOFplus force field, "pair_style buck6d/coul/gauss"_pair_buck6d_coul_gauss.html, USER/mofff, -
-"USER-MOLFILE"_#USER-MOLFILE, "VMD"_vmd_home molfile plug-ins,"dump molfile"_dump_molfile.html, -, ext
-"USER-NETCDF"_#USER-NETCDF, dump output via NetCDF,"dump netcdf"_dump_netcdf.html, -, ext
-"USER-OMP"_#USER-OMP, OpenMP-enabled styles,"Section 5.3.4"_accelerate_omp.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, -
-"USER-PHONON"_#USER-PHONON, phonon dynamical matrix,"fix phonon"_fix_phonon.html, USER/phonon, -
-"USER-QMMM"_#USER-QMMM, QM/MM coupling,"fix qmmm"_fix_qmmm.html, USER/qmmm, ext
-"USER-QTB"_#USER-QTB, quantum nuclear effects,"fix qtb"_fix_qtb.html "fix qbmsst"_fix_qbmsst.html, qtb, -
-"USER-QUIP"_#USER-QUIP, QUIP/libatoms interface,"pair_style quip"_pair_quip.html, USER/quip, ext
-"USER-REAXC"_#USER-REAXC, ReaxFF potential (C/C++) ,"pair_style reaxc"_pair_reaxc.html, reax, -
-"USER-SMD"_#USER-SMD, smoothed Mach dynamics,"SMD User Guide"_PDF/SMD_LAMMPS_userguide.pdf, USER/smd, ext
-"USER-SMTBQ"_#USER-SMTBQ, second moment tight binding QEq potential,"pair_style smtbq"_pair_smtbq.html, USER/smtbq, -
-"USER-SPH"_#USER-SPH, smoothed particle hydrodynamics,"SPH User Guide"_PDF/SPH_LAMMPS_userguide.pdf, USER/sph, -
-"USER-TALLY"_#USER-TALLY, pairwise tally computes,"compute XXX/tally"_compute_tally.html, USER/tally, -
-"USER-UEF"_#USER-UEF, extensional flow,"fix nvt/uef"_fix_nh_uef.html, USER/uef, -
-"USER-VTK"_#USER-VTK, dump output via VTK, "compute vtk"_dump_vtk.html, -, ext :tb(ea=c,ca1=l)
+"USER-ATC"_#USER-ATC,
+"USER-AWPMD"_#USER-AWPMD,
+"USER-BOCS"_#USER-BOCS,
+"USER-CGDNA"_#USER-CGDNA,
+"USER-CGSDK"_#USER-CGSDK,
+"USER-COLVARS"_#USER-COLVARS,
+"USER-DIFFRACTION"_#USER-DIFFRACTION,
+"USER-DPD"_#USER-DPD,
+"USER-DRUDE"_#USER-DRUDE,
+"USER-EFF"_#USER-EFF,
+"USER-FEP"_#USER-FEP,
+"USER-H5MD"_#USER-H5MD,
+"USER-INTEL"_#USER-INTEL,
+"USER-LB"_#USER-LB,
+"USER-MANIFOLD"_#USER-MANIFOLD,
+"USER-MEAMC"_#USER-MEAMC,
+"USER-MESO"_#USER-MESO,
+"USER-MGPT"_#USER-MGPT,
+"USER-MISC"_#USER-MISC,
+"USER-MOFFF"_#USER-MOFFF,
+"USER-MOLFILE"_#USER-MOLFILE,
+"USER-NETCDF"_#USER-NETCDF,
+"USER-OMP"_#USER-OMP,
+"USER-PHONON"_#USER-PHONON,
+"USER-QMMM"_#USER-QMMM,
+"USER-QTB"_#USER-QTB,
+"USER-QUIP"_#USER-QUIP,
+"USER-REAXC"_#USER-REAXC,
+"USER-SMD"_#USER-SMD,
+"USER-SMTBQ"_#USER-SMTBQ,
+"USER-SPH"_#USER-SPH,
+"USER-TALLY"_#USER-TALLY,
+"USER-UEF"_#USER-UEF,
+"USER-VTK"_#USER-VTK :tb(c=6,ea=c)
 
 :line
 :line
@@ -379,14 +316,14 @@ GPU package :link(GPU),h4
 [Contents:]
 
 Dozens of pair styles and a version of the PPPM long-range Coulombic
-solver optimized for GPUs.  All such styles have a "gpu" as a
-suffix in their style name. The GPU code can be compiled with either
-CUDA or OpenCL, however the OpenCL variants are no longer actively
-maintained and only the CUDA versions are regularly tested.
-"Section 5.3.1"_accelerate_gpu.html gives details of what
-hardware and GPU software is required on your system,
-and details on how to build and use this package.  Its styles can be
-invoked at run time via the "-sf gpu" or "-suffix gpu" "command-line
+solver optimized for GPUs.  All such styles have a "gpu" as a suffix
+in their style name. The GPU code can be compiled with either CUDA or
+OpenCL, however the OpenCL variants are no longer actively maintained
+and only the CUDA versions are regularly tested.  The "Speed
+gpu"_Speed_gpu.html doc page gives details of what hardware and GPU
+software is required on your system, and details on how to build and
+use this package.  Its styles can be invoked at run time via the "-sf
+gpu" or "-suffix gpu" "command-line
 switches"_Section_start.html#start_6.  See also the "KOKKOS"_#KOKKOS
 package, which has GPU-enabled styles.
 
@@ -452,8 +389,8 @@ GPU library.
 src/GPU: filenames -> commands
 src/GPU/README
 lib/gpu/README
-"Section 5.3"_Section_accelerate.html#acc_3
-"Section 5.3.1"_accelerate_gpu.html
+"Speed packages"_Speed_packages.html
+"Speed gpu"_Speed_gpu.html.html
 "Section 2.6 -sf gpu"_Section_start.html#start_6
 "Section 2.6 -pk gpu"_Section_start.html#start_6
 "package gpu"_package.html
@@ -578,10 +515,10 @@ Dozens of atom, pair, bond, angle, dihedral, improper, fix, compute
 styles adapted to compile using the Kokkos library which can convert
 them to OpenMP or CUDA code so that they run efficiently on multicore
 CPUs, KNLs, or GPUs.  All the styles have a "kk" as a suffix in their
-style name.  "Section 5.3.3"_accelerate_kokkos.html gives details of
-what hardware and software is required on your system, and how to
-build and use this package.  Its styles can be invoked at run time via
-the "-sf kk" or "-suffix kk" "command-line
+style name.  The "Speed kokkos"_Speed_kokkos.html doc page gives
+details of what hardware and software is required on your system, and
+how to build and use this package.  Its styles can be invoked at run
+time via the "-sf kk" or "-suffix kk" "command-line
 switches"_Section_start.html#start_6.  Also see the "GPU"_#GPU,
 "OPT"_#OPT, "USER-INTEL"_#USER-INTEL, and "USER-OMP"_#USER-OMP
 packages, which have styles optimized for CPUs, KNLs, and GPUs.
@@ -648,8 +585,8 @@ make machine :pre
 src/KOKKOS: filenames -> commands
 src/KOKKOS/README
 lib/kokkos/README
-"Section 5.3"_Section_accelerate.html#acc_3
-"Section 5.3.3"_accelerate_kokkos.html
+"Speed packages"_Speed_packages.html
+"Speed kokkos"_Speed_kokkos.html
 "Section 2.6 -k on ..."_Section_start.html#start_6
 "Section 2.6 -sf kk"_Section_start.html#start_6
 "Section 2.6 -pk kokkos"_Section_start.html#start_6
@@ -1047,9 +984,9 @@ OPT package :link(OPT),h4
 A handful of pair styles which are optimized for improved CPU
 performance on single or multiple cores.  These include EAM, LJ,
 CHARMM, and Morse potentials.  The styles have an "opt" suffix in
-their style name.  "Section 5.3.5"_accelerate_opt.html gives details
-of how to build and use this package.  Its styles can be invoked at
-run time via the "-sf opt" or "-suffix opt" "command-line
+their style name.  The "Speed opt"_Speed_opt.html doc page gives
+details of how to build and use this package.  Its styles can be
+invoked at run time via the "-sf opt" or "-suffix opt" "command-line
 switches"_Section_start.html#start_6.  See also the "KOKKOS"_#KOKKOS,
 "USER-INTEL"_#USER-INTEL, and "USER-OMP"_#USER-OMP packages, which
 have styles optimized for CPU performance.
@@ -1075,8 +1012,8 @@ CCFLAGS: add -restrict for Intel compilers :ul
 [Supporting info:]
 
 src/OPT: filenames -> commands
-"Section 5.3"_Section_accelerate.html#acc_3
-"Section 5.3.5"_accelerate_opt.html
+"Speed packages"_Speed_packages.html
+"Speed opt"_Speed_opt.html
 "Section 2.6 -sf opt"_Section_start.html#start_6
 Pair Styles section of "Section 3.5"_Section_commands.html#cmd_5 for pair styles followed by (t)
 "Benchmarks page"_http://lammps.sandia.gov/bench.html of web site :ul
@@ -1625,6 +1562,43 @@ examples/USER/awpmd :ul
 
 :line
 
+USER-BOCS package :link(USER-BOCS),h4
+
+[Contents:]
+
+This package provides "fix bocs"_fix_bocs.html, a modified version
+of "fix npt"_fix_nh.html which includes the pressure correction to
+the barostat as outlined in:
+
+N. J. H. Dunn and W. G. Noid, "Bottom-up coarse-grained models that 
+accurately describe the structure, pressure, and compressibility of
+molecular liquids," J. Chem. Phys. 143, 243148 (2015).
+
+[Authors:] Nicholas J. H. Dunn and Michael R. DeLyser (The Pennsylvania State University)
+
+[Install or un-install:]
+
+make yes-user-bocs
+make machine :pre
+
+make no-user-bocs
+make machine :pre
+
+[Supporting info:]
+
+The USER-BOCS user package for LAMMPS is part of the BOCS software package:
+"https://github.com/noid-group/BOCS"_https://github.com/noid-group/BOCS
+
+See the following reference for information about the entire package:
+
+Dunn, NJH; Lebold, KM; DeLyser, MR; Rudzinski, JF; Noid, WG.
+"BOCS: Bottom-Up Open-Source Coarse-Graining Software."
+J. Phys. Chem. B. 122, 13, 3363-3377 (2018).
+
+Example inputs are in the examples/USER/bocs folder.
+
+:line
+
 USER-CGDNA package :link(USER-CGDNA),h4
 
 [Contents:]
@@ -1995,8 +1969,8 @@ USER-INTEL package :link(USER-INTEL),h4
 
 Dozens of pair, fix, bond, angle, dihedral, improper, and kspace
 styles which are optimized for Intel CPUs and KNLs (Knights Landing).
-All of them have an "intel" in their style name.  "Section
-5.3.2"_accelerate_intel.html gives details of what hardware and
+All of them have an "intel" in their style name.  The "Speed
+intel"_Speed_intel.html doc page gives details of what hardware and
 compilers are required on your system, and how to build and use this
 package.  Its styles can be invoked at run time via the "-sf intel" or
 "-suffix intel" "command-line switches"_Section_start.html#start_6.
@@ -2046,7 +2020,7 @@ hardware target, to produce a separate executable.
 
 You should also typically install the USER-OMP package, as it can be
 used in tandem with the USER-INTEL package to good effect, as
-explained in "Section 5.3.2"_accelerate_intel.html.
+explained on the "Speed intel"_Speed_intel.html doc page.
 
 make yes-user-intel yes-user-omp
 make machine :pre
@@ -2058,8 +2032,8 @@ make machine :pre
 
 src/USER-INTEL: filenames -> commands
 src/USER-INTEL/README
-"Section 5.3"_Section_accelerate.html#acc_3
-"Section 5.3.2"_accelerate_gpu.html
+"Speed packages"_Speed_packages.html
+"Speed intel"_Speed_intel.html
 "Section 2.6 -sf intel"_Section_start.html#start_6
 "Section 2.6 -pk intel"_Section_start.html#start_6
 "package intel"_package.html
@@ -2405,10 +2379,10 @@ USER-OMP package :link(USER-OMP),h4
 Hundreds of pair, fix, compute, bond, angle, dihedral, improper, and
 kspace styles which are altered to enable threading on many-core CPUs
 via OpenMP directives.  All of them have an "omp" in their style name.
-"Section 5.3.4"_accelerate_omp.html gives details of what hardware and
-compilers are required on your system, and how to build and use this
-package.  Its styles can be invoked at run time via the "-sf omp" or
-"-suffix omp" "command-line switches"_Section_start.html#start_6.
+The "Speed omp"_Speed_omp.html doc page gives details of what hardware
+and compilers are required on your system, and how to build and use
+this package.  Its styles can be invoked at run time via the "-sf omp"
+or "-suffix omp" "command-line switches"_Section_start.html#start_6.
 Also see the "KOKKOS"_#KOKKOS, "OPT"_#OPT, and
 "USER-INTEL"_#USER-INTEL packages, which have styles optimized for
 CPUs.
@@ -2443,8 +2417,8 @@ LINKFLAGS: add -fopenmp :ul
 
 src/USER-OMP: filenames -> commands
 src/USER-OMP/README
-"Section 5.3"_Section_accelerate.html#acc_3
-"Section 5.3.4"_accelerate_omp.html
+"Speed packages"_Speed_packages.html
+"Speed omp"_Speed_omp.html
 "Section 2.6 -sf omp"_Section_start.html#start_6
 "Section 2.6 -pk omp"_Section_start.html#start_6
 "package omp"_package.html

doc/src/Packages_standard.txt

@@ -0,0 +1,65 @@
+"Higher level section"_Packages.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+Standard packages :h3
+
+This is the list of standard packages in LAMMPS.  The link for each
+package name gives more details.
+
+Standard packages are supported by the LAMMPS developers and are
+written in a syntax and style consistent with the rest of LAMMPS.
+This means the developers will answer questions about them, debug and
+fix them if necessary, and keep them compatible with future changes to
+LAMMPS.
+
+The "Example" column is a sub-directory in the examples directory of
+the distribution which has an input script that uses the package.
+E.g. "peptide" refers to the examples/peptide directory; USER/atc
+refers to the examples/USER/atc directory.  The "Library" column
+indicates whether an extra library is needed to build and use the
+package:
+
+dash = no library
+sys = system library: you likely have it on your machine
+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
+"ASPHERE"_Packages_details.html#ASPHERE, aspherical particle models, "Section 6.6.14"_Section_howto.html#howto_14, ellipse, -
+"BODY"_Packages_details.html#BODY, body-style particles, "body"_body.html, body, -
+"CLASS2"_Packages_details.html#CLASS2, class 2 force fields, "pair_style lj/class2"_pair_class2.html, -, -
+"COLLOID"_Packages_details.html#COLLOID, colloidal particles, "atom_style colloid"_atom_style.html, colloid, -
+"COMPRESS"_Packages_details.html#COMPRESS, I/O compression, "dump */gz"_dump.html, -, sys
+"CORESHELL"_Packages_details.html#CORESHELL, adiabatic core/shell model, "Section 6.6.25"_Section_howto.html#howto_25, coreshell, -
+"DIPOLE"_Packages_details.html#DIPOLE, point dipole particles, "pair_style dipole/cut"_pair_dipole.html, dipole, -
+"GPU"_Packages_details.html#GPU, GPU-enabled styles, "Section gpu"_Speed_gpu.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, int
+"GRANULAR"_Packages_details.html#GRANULAR, granular systems, "Section 6.6.6"_Section_howto.html#howto_6, pour, -
+"KIM"_Packages_details.html#KIM, OpenKIM wrapper, "pair_style kim"_pair_kim.html, kim, ext
+"KOKKOS"_Packages_details.html#KOKKOS, Kokkos-enabled styles, "Speed kokkos"_Speed_kokkos.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, -
+"KSPACE"_Packages_details.html#KSPACE, long-range Coulombic solvers, "kspace_style"_kspace_style.html, peptide, -
+"LATTE"_Packages_details.html#LATTE, quantum DFTB forces via LATTE, "fix latte"_fix_latte.html, latte, ext
+"MANYBODY"_Packages_details.html#MANYBODY, many-body potentials, "pair_style tersoff"_pair_tersoff.html, shear, -
+"MC"_Packages_details.html#MC, Monte Carlo options, "fix gcmc"_fix_gcmc.html, -, -
+"MEAM"_Packages_details.html#MEAM, modified EAM potential, "pair_style meam"_pair_meam.html, meam, int
+"MISC"_Packages_details.html#MISC, miscellanous single-file commands, -, -, -
+"MOLECULE"_Packages_details.html#MOLECULE, molecular system force fields, "Section 6.6.3"_Section_howto.html#howto_3, peptide, -
+"MPIIO"_Packages_details.html#MPIIO, MPI parallel I/O dump and restart, "dump"_dump.html, -, -
+"MSCG"_Packages_details.html#MSCG, multi-scale coarse-graining wrapper, "fix mscg"_fix_mscg.html, mscg, ext
+"OPT"_Packages_details.html#OPT, optimized pair styles, "Speed opt"_Speed_opt.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, -
+"PERI"_Packages_details.html#PERI, Peridynamics models, "pair_style peri"_pair_peri.html, peri, -
+"POEMS"_Packages_details.html#POEMS, coupled rigid body motion, "fix poems"_fix_poems.html, rigid, int
+"PYTHON"_Packages_details.html#PYTHON, embed Python code in an input script, "python"_python.html, python, sys
+"QEQ"_Packages_details.html#QEQ, QEq charge equilibration, "fix qeq"_fix_qeq.html, qeq, -
+"REAX"_Packages_details.html#REAX, ReaxFF potential (Fortran), "pair_style reax"_pair_reax.html, reax, int
+"REPLICA"_Packages_details.html#REPLICA, multi-replica methods, "Section 6.6.5"_Section_howto.html#howto_5, tad, -
+"RIGID"_Packages_details.html#RIGID, rigid bodies and constraints, "fix rigid"_fix_rigid.html, rigid, -
+"SHOCK"_Packages_details.html#SHOCK, shock loading methods, "fix msst"_fix_msst.html, -, -
+"SNAP"_Packages_details.html#SNAP, quantum-fitted potential, "pair_style snap"_pair_snap.html, snap, -
+"SRD"_Packages_details.html#SRD, stochastic rotation dynamics, "fix srd"_fix_srd.html, srd, -
+"VORONOI"_Packages_details.html#VORONOI, Voronoi tesselation, "compute voronoi/atom"_compute_voronoi_atom.html, -, ext :tb(ea=c,ca1=l)

doc/src/Packages_user.txt

@@ -0,0 +1,74 @@
+"Higher level section"_Packages.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+User packages :h3
+
+This is a list of user packages in LAMMPS.  The link for each package
+name gives more details.
+
+User packages have been contributed by users, and begin with the
+"user" prefix.  If a contribution is a single command (single file),
+it is typically in the user-misc package.  User packages don't
+necessarily meet the requirements of the "standard
+packages"_Packages_standard.html. This means the developers will try
+to keep things working and usually can answer technical questions
+about compiling the package. If you have problems using a specific
+feature provided in a user package, you may need to contact the
+contributor directly to get help.  Information on how to submit
+additions you make to LAMMPS as single files or as a standard or user
+package is explained on the "Modify contribute"_Modify_contribute.html
+doc page.
+
+The "Example" column is a sub-directory in the examples directory of
+the distribution which has an input script that uses the package.
+E.g. "peptide" refers to the examples/peptide directory; USER/atc
+refers to the examples/USER/atc directory.  The "Library" column
+indicates whether an extra library is needed to build and use the
+package:
+
+dash = no library
+sys = system library: you likely have it on your machine
+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#USER-ATC, atom-to-continuum coupling, "fix atc"_fix_atc.html, USER/atc, int
+"USER-AWPMD"_Packages_details.html#USER-AWPMD, wave-packet MD, "pair_style awpmd/cut"_pair_awpmd.html, USER/awpmd, int
+"USER-BOCS"_Packages_details.html#USER-BOCS, BOCS bottom up coarse graining, "fix bocs"_fix_bocs.html, USER/bocs, -
+"USER-CGDNA"_Packages_details.html#USER-CGDNA, coarse-grained DNA force fields, src/USER-CGDNA/README, USER/cgdna, -
+"USER-CGSDK"_Packages_details.html#USER-CGSDK, SDK coarse-graining model, "pair_style lj/sdk"_pair_sdk.html, USER/cgsdk, -
+"USER-COLVARS"_Packages_details.html#USER-COLVARS, collective variables library, "fix colvars"_fix_colvars.html, USER/colvars, int
+"USER-DIFFRACTION"_Packages_details.html#USER-DIFFRACTION, virtual x-ray and electron diffraction,"compute xrd"_compute_xrd.html, USER/diffraction, -
+"USER-DPD"_Packages_details.html#USER-DPD, reactive dissipative particle dynamics, src/USER-DPD/README, USER/dpd, -
+"USER-DRUDE"_Packages_details.html#USER-DRUDE, Drude oscillators, "tutorial"_tutorial_drude.html, USER/drude, -
+"USER-EFF"_Packages_details.html#USER-EFF, electron force field,"pair_style eff/cut"_pair_eff.html, USER/eff, -
+"USER-FEP"_Packages_details.html#USER-FEP, free energy perturbation,"compute fep"_compute_fep.html, USER/fep, -
+"USER-H5MD"_Packages_details.html#USER-H5MD, dump output via HDF5,"dump h5md"_dump_h5md.html, -, ext
+"USER-INTEL"_Packages_details.html#USER-INTEL, optimized Intel CPU and KNL styles,"Speed intel"_Speed_intel.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, -
+"USER-LB"_Packages_details.html#USER-LB, Lattice Boltzmann fluid,"fix lb/fluid"_fix_lb_fluid.html, USER/lb, -
+"USER-MANIFOLD"_Packages_details.html#USER-MANIFOLD, motion on 2d surfaces,"fix manifoldforce"_fix_manifoldforce.html, USER/manifold, -
+"USER-MEAMC"_Packages_details.html#USER-MEAMC, modified EAM potential (C++), "pair_style meam/c"_pair_meam.html, meam, -
+"USER-MESO"_Packages_details.html#USER-MESO, mesoscale DPD models, "pair_style edpd"_pair_meso.html, USER/meso, -
+"USER-MGPT"_Packages_details.html#USER-MGPT, fast MGPT multi-ion potentials, "pair_style mgpt"_pair_mgpt.html, USER/mgpt, -
+"USER-MISC"_Packages_details.html#USER-MISC, single-file contributions, USER-MISC/README, USER/misc, -
+"USER-MOFFF"_Packages_details.html#USER-MOFFF, styles for "MOF-FF"_MOFplus force field, "pair_style buck6d/coul/gauss"_pair_buck6d_coul_gauss.html, USER/mofff, -
+"USER-MOLFILE"_Packages_details.html#USER-MOLFILE, "VMD"_vmd_home molfile plug-ins,"dump molfile"_dump_molfile.html, -, ext
+"USER-NETCDF"_Packages_details.html#USER-NETCDF, dump output via NetCDF,"dump netcdf"_dump_netcdf.html, -, ext
+"USER-OMP"_Packages_details.html#USER-OMP, OpenMP-enabled styles,"Speed omp"_Speed_omp.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, -
+"USER-PHONON"_Packages_details.html#USER-PHONON, phonon dynamical matrix,"fix phonon"_fix_phonon.html, USER/phonon, -
+"USER-QMMM"_Packages_details.html#USER-QMMM, QM/MM coupling,"fix qmmm"_fix_qmmm.html, USER/qmmm, ext
+"USER-QTB"_Packages_details.html#USER-QTB, quantum nuclear effects,"fix qtb"_fix_qtb.html "fix qbmsst"_fix_qbmsst.html, qtb, -
+"USER-QUIP"_Packages_details.html#USER-QUIP, QUIP/libatoms interface,"pair_style quip"_pair_quip.html, USER/quip, ext
+"USER-REAXC"_Packages_details.html#USER-REAXC, ReaxFF potential (C/C++) ,"pair_style reaxc"_pair_reaxc.html, reax, -
+"USER-SMD"_Packages_details.html#USER-SMD, smoothed Mach dynamics,"SMD User Guide"_PDF/SMD_LAMMPS_userguide.pdf, USER/smd, ext
+"USER-SMTBQ"_Packages_details.html#USER-SMTBQ, second moment tight binding QEq potential,"pair_style smtbq"_pair_smtbq.html, USER/smtbq, -
+"USER-SPH"_Packages_details.html#USER-SPH, smoothed particle hydrodynamics,"SPH User Guide"_PDF/SPH_LAMMPS_userguide.pdf, USER/sph, -
+"USER-TALLY"_Packages_details.html#USER-TALLY, pairwise tally computes,"compute XXX/tally"_compute_tally.html, USER/tally, -
+"USER-UEF"_Packages_details.html#USER-UEF, extensional flow,"fix nvt/uef"_fix_nh_uef.html, USER/uef, -
+"USER-VTK"_Packages_details.html#USER-VTK, dump output via VTK, "compute vtk"_dump_vtk.html, -, ext :tb(ea=c,ca1=l)

doc/src/Python.txt

@@ -0,0 +1,79 @@
+"Previous Section"_Modify.html - "LAMMPS WWW Site"_lws -
+"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
+Section"_Errors.html :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+Use Python with LAMMPS :h2
+
+These doc pages describe various ways that LAMMPS and Python can be
+used together.
+
+<!-- RST
+
+.. toctree::
+
+   Python_overview
+
+.. toctree::
+
+   Python_run
+   Python_shlib
+   Python_install
+   Python_mpi
+   Python_test
+   Python_library
+   Python_pylammps
+   Python_examples
+
+.. toctree::
+
+   Python_call
+
+END_RST -->
+
+<!-- HTML_ONLY -->
+
+"Overview of Python and LAMMPS"_Python_overview.html :all(b)
+
+"Run LAMMPS from Python"_Python_run.html
+"Build LAMMPS as a shared library"_Python_shlib.html
+"Install LAMMPS in Python"_Python_install.html
+"Extend Python to run in parallel"_Python_mpi.html
+"Test the Python/LAMMPS interface"_Python_test.html
+"Python library interface"_Python_library.html
+"PyLammps interface"_Python_pylammps.html
+"Example Python scripts that use LAMMPS"_Python_examples.html :all(b)
+
+"Call Python from a LAMMPS input script"_Python_call.html :all(b)
+
+<!-- END_HTML_ONLY -->
+
+If you're not familiar with "Python"_http://www.python.org, it's a
+powerful scripting and programming language which can do most
+everything that lower-level languages like C or C++ can do in fewer
+lines of code.  The only drawback is slower execution speed.  Python
+is also easy to use as a "glue" language to drive a program through
+its library interface, or to hook multiple pieces of software
+together, such as a simulation code plus a visualization tool, or to
+run a coupled multiscale or multiphysics model.
+
+See the "Howto_couple"_Howto_couple.html doc page for more ideas about
+coupling LAMMPS to other codes.  See the "Howto
+library"_Howto_library.html doc page for a description of the LAMMPS
+library interface provided in src/library.h and src/library.h.  That
+interface is exposed to Python either when calling LAMMPS from Python
+or when calling Python from a LAMMPS input script and then calling
+back to LAMMPS from Python code.  The library interface is designed to
+be easy to add funcionality to.  Thus the Python interface to LAMMPS
+is also easy to extend as well.
+
+If you create interesting Python scripts that run LAMMPS or
+interesting Python functions that can be called from a LAMMPS input
+script, that you think would be genearlly useful, please post them as
+a pull request to our "GitHub site"_https://github.com/lammps/lammps,
+and they can be added to the LAMMPS distribution or webpage.

doc/src/Python_call.txt

@@ -0,0 +1,85 @@
+"Higher level section"_Python.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+Call Python from a LAMMPS input script :h3
+
+LAMMPS has several commands which can be used to invoke Python
+code directly from an input script:
+
+"python"_python.html
+"variable python"_variable.html
+"fix python/invoke"_fix_python_invoke.html
+"pair_style python"_pair_python.html :ul
+
+The "python"_python.html command which can be used to define and
+execute a Python function that you write the code for.  The Python
+function can also be assigned to a LAMMPS python-style variable via
+the "variable"_variable.html command.  Each time the variable is
+evaluated, either in the LAMMPS input script itself, or by another
+LAMMPS command that uses the variable, this will trigger the Python
+function to be invoked.
+
+The Python code for the function can be included directly in the input
+script or in an auxiliary file.  The function can have arguments which
+are mapped to LAMMPS variables (also defined in the input script) and
+it can return a value to a LAMMPS variable.  This is thus a mechanism
+for your input script to pass information to a piece of Python code,
+ask Python to execute the code, and return information to your input
+script.
+
+Note that a Python function can be arbitrarily complex.  It can import
+other Python modules, instantiate Python classes, call other Python
+functions, etc.  The Python code that you provide can contain more
+code than the single function.  It can contain other functions or
+Python classes, as well as global variables or other mechanisms for
+storing state between calls from LAMMPS to the function.
+
+The Python function you provide can consist of "pure" Python code that
+only performs operations provided by standard Python.  However, the
+Python function can also "call back" to LAMMPS through its
+Python-wrapped library interface, in the manner described in the
+"Python run"_Python_run.html doc page.  This means it can issue LAMMPS
+input script commands or query and set internal LAMMPS state.  As an
+example, this can be useful in an input script to create a more
+complex loop with branching logic, than can be created using the
+simple looping and branching logic enabled by the "next"_next.html and
+"if"_if.html commands.
+
+See the "python"_python.html doc page and the "variable"_variable.html
+doc page for its python-style variables for more info, including
+examples of Python code you can write for both pure Python operations
+and callbacks to LAMMPS.
+
+The "fix python/invoke"_fix_python_invoke.html command can execute
+Python code at selected timesteps during a simulation run.
+
+The "pair_style python"_pair_python command allows you to define
+pairwise potentials as python code which encodes a single pairwise
+interaction.  This is useful for rapid-developement and debugging of a
+new potential.
+
+To use any of these commands, you only need to build LAMMPS with the
+PYTHON package installed:
+
+make yes-python
+make machine :pre
+
+Note that this will link LAMMPS with the Python library on your
+system, which typically requires several auxiliary system libraries to
+also be linked.  The list of these libraries and the paths to find
+them are specified in the lib/python/Makefile.lammps file.  You need
+to insure that file contains the correct information for your version
+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
+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

@@ -0,0 +1,81 @@
+"Higher level section"_Python.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+Example Python scripts that use LAMMPS :h3
+
+These are the Python scripts included as demos in the python/examples
+directory of the LAMMPS distribution, to illustrate the kinds of
+things that are possible when Python wraps LAMMPS.  If you create your
+own scripts, send them to us and we can include them in the LAMMPS
+distribution.
+
+trivial.py, read/run a LAMMPS input script thru Python,
+demo.py, invoke various LAMMPS library interface routines,
+simple.py, run in parallel, similar to examples/COUPLE/simple/simple.cpp,
+split.py, same as simple.py but running in parallel on a subset of procs,
+gui.py, GUI go/stop/temperature-slider to control LAMMPS,
+plot.py, real-time temperature plot with GnuPlot via Pizza.py,
+viz_tool.py, real-time viz via some viz package,
+vizplotgui_tool.py, combination of viz_tool.py and plot.py and gui.py :tb(c=2)
+
+:line
+
+For the viz_tool.py and vizplotgui_tool.py commands, replace "tool"
+with "gl" or "atomeye" or "pymol" or "vmd", depending on what
+visualization package you have installed.
+
+Note that for GL, you need to be able to run the Pizza.py GL tool,
+which is included in the pizza sub-directory.  See the "Pizza.py doc
+pages"_pizza for more info:
+
+:link(pizza,http://www.sandia.gov/~sjplimp/pizza.html)
+
+Note that for AtomEye, you need version 3, and there is a line in the
+scripts that specifies the path and name of the executable.  See the
+AtomEye WWW pages "here"_atomeye or "here"_atomeye3 for more details:
+
+http://mt.seas.upenn.edu/Archive/Graphics/A
+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
+capability needed by these Python scripts.
+
+Note that for PyMol, you need to have built and installed the
+open-source version of PyMol in your Python, so that you can import it
+from a Python script.  See the PyMol WWW pages "here"_pymolhome or
+"here"_pymolopen for more details:
+
+http://www.pymol.org
+http://sourceforge.net/scm/?type=svn&group_id=4546 :pre
+
+:link(pymolhome,http://www.pymol.org)
+:link(pymolopen,http://sourceforge.net/scm/?type=svn&group_id=4546)
+
+The latter link is to the open-source version.
+
+Note that for VMD, you need a fairly current version (1.8.7 works for
+me) and there are some lines in the pizza/vmd.py script for 4 PIZZA
+variables that have to match the VMD installation on your system.
+
+:line
+
+See the python/README file for instructions on how to run them and the
+source code for individual scripts for comments about what they do.
+
+Here are screenshots of the vizplotgui_tool.py script in action for
+different visualization package options.  Click to see larger images:
+
+:image(JPG/screenshot_gl_small.jpg,JPG/screenshot_gl.jpg)
+:image(JPG/screenshot_atomeye_small.jpg,JPG/screenshot_atomeye.jpg)
+:image(JPG/screenshot_pymol_small.jpg,JPG/screenshot_pymol.jpg)
+:image(JPG/screenshot_vmd_small.jpg,JPG/screenshot_vmd.jpg)
+

doc/src/Python_install.txt

@@ -0,0 +1,74 @@
+"Higher level section"_Python.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+Installing LAMMPS in Python :h3
+
+For Python to invoke LAMMPS, there are 2 files it needs to know about:
+
+python/lammps.py
+src/liblammps.so :ul
+
+Lammps.py is the Python wrapper on the LAMMPS library interface.
+Liblammps.so is the shared LAMMPS library that Python loads, as
+described above.
+
+You can insure Python can find these files in one of two ways:
+
+set two environment variables
+run the python/install.py script :ul
+
+If you set the paths to these files as environment variables, you only
+have to do it once.  For the csh or tcsh shells, add something like
+this to your ~/.cshrc file, one line for each of the two files:
+
+setenv PYTHONPATH $\{PYTHONPATH\}:/home/sjplimp/lammps/python
+setenv LD_LIBRARY_PATH $\{LD_LIBRARY_PATH\}:/home/sjplimp/lammps/src :pre
+
+If you use the python/install.py script, you need to invoke it every
+time you rebuild LAMMPS (as a shared library) or make changes to the
+python/lammps.py file.
+
+You can invoke install.py from the python directory as
+
+% python install.py \[libdir\] \[pydir\] :pre
+
+The optional libdir is where to copy the LAMMPS shared library to; the
+default is /usr/local/lib.  The optional pydir is where to copy the
+lammps.py file to; the default is the site-packages directory of the
+version of Python that is running the install script.
+
+Note that libdir must be a location that is in your default
+LD_LIBRARY_PATH, like /usr/local/lib or /usr/lib.  And pydir must be a
+location that Python looks in by default for imported modules, like
+its site-packages dir.  If you want to copy these files to
+non-standard locations, such as within your own user space, you will
+need to set your PYTHONPATH and LD_LIBRARY_PATH environment variables
+accordingly, as above.
+
+If the install.py script does not allow you to copy files into system
+directories, prefix the python command with "sudo".  If you do this,
+make sure that the Python that root runs is the same as the Python you
+run.  E.g. you may need to do something like
+
+% sudo /usr/local/bin/python install.py \[libdir\] \[pydir\] :pre
+
+You can also invoke install.py from the make command in the src
+directory as
+
+% make install-python :pre
+
+In this mode you cannot append optional arguments.  Again, you may
+need to prefix this with "sudo".  In this mode you cannot control
+which Python is invoked by root.
+
+Note that if you want Python to be able to load different versions of
+the LAMMPS shared library (see "this section"_#py_5 below), you will
+need to manually copy files like liblammps_g++.so into the appropriate
+system directory.  This is not needed if you set the LD_LIBRARY_PATH
+environment variable as described above.

doc/src/Python_library.txt

@@ -0,0 +1,256 @@
+"Higher level section"_Python.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+Python library interface :h3
+
+As described previously, the Python interface to LAMMPS consists of a
+Python "lammps" module, the source code for which is in
+python/lammps.py, which creates a "lammps" object, with a set of
+methods that can be invoked on that object.  The sample Python code
+below assumes you have first imported the "lammps" module in your
+Python script, as follows:
+
+from lammps import lammps :pre
+
+These are the methods defined by the lammps module.  If you look at
+the files src/library.cpp and src/library.h you will see they
+correspond one-to-one with calls you can make to the LAMMPS library
+from a C++ or C or Fortran program, and which are described in
+"Section 6.19"_Section_howto.html#howto_19 of the manual.
+
+The python/examples directory has Python scripts which show how Python
+can run LAMMPS, grab data, change it, and put it back into LAMMPS.
+
+lmp = lammps()           # create a LAMMPS object using the default liblammps.so library
+                         # 4 optional args are allowed: name, cmdargs, ptr, comm
+lmp = lammps(ptr=lmpptr) # use lmpptr as previously created LAMMPS object
+lmp = lammps(comm=split) # create a LAMMPS object with a custom communicator, requires mpi4py 2.0.0 or later
+lmp = lammps(name="g++")   # create a LAMMPS object using the liblammps_g++.so library
+lmp = lammps(name="g++",cmdargs=list)    # add LAMMPS command-line args, e.g. list = \["-echo","screen"\] :pre
+
+lmp.close()              # destroy a LAMMPS object :pre
+
+version = lmp.version()  # return the numerical version id, e.g. LAMMPS 2 Sep 2015 -> 20150902 :pre
+
+lmp.file(file)           # run an entire input script, file = "in.lj"
+lmp.command(cmd)         # invoke a single LAMMPS command, cmd = "run 100"
+lmp.commands_list(cmdlist)     # invoke commands in cmdlist = ["run 10", "run 20"]
+lmp.commands_string(multicmd)  # invoke commands in multicmd = "run 10\nrun 20" :pre
+
+size = lmp.extract_setting(name)     # return data type info :pre
+
+xlo = lmp.extract_global(name,type)  # extract a global quantity
+                                     # name = "boxxlo", "nlocal", etc
+                                     # type = 0 = int
+                                     #        1 = double :pre
+
+boxlo,boxhi,xy,yz,xz,periodicity,box_change = lmp.extract_box()  # extract box info :pre
+
+coords = lmp.extract_atom(name,type)      # extract a per-atom quantity
+                                          # name = "x", "type", etc
+                                          # type = 0 = vector of ints
+                                          #        1 = array of ints
+                                          #        2 = vector of doubles
+                                          #        3 = array of doubles :pre
+
+eng = lmp.extract_compute(id,style,type)  # extract value(s) from a compute
+v3 = lmp.extract_fix(id,style,type,i,j)   # extract value(s) from a fix
+                                          # id = ID of compute or fix
+                                          # style = 0 = global data
+                                          #         1 = per-atom data
+                                          #         2 = local data
+                                          # type = 0 = scalar
+                                          #        1 = vector
+                                          #        2 = array
+                                          # i,j = indices of value in global vector or array :pre
+
+var = lmp.extract_variable(name,group,flag)  # extract value(s) from a variable
+                                             # name = name of variable
+                                             # group = group ID (ignored for equal-style variables)
+                                             # flag = 0 = equal-style variable
+                                             #        1 = atom-style variable :pre
+
+value = lmp.get_thermo(name)              # return current value of a thermo keyword
+natoms = lmp.get_natoms()                 # total # of atoms as int :pre
+
+flag = lmp.set_variable(name,value)       # set existing named string-style variable to value, flag = 0 if successful
+lmp.reset_box(boxlo,boxhi,xy,yz,xz)       # reset the simulation box size :pre
+
+data = lmp.gather_atoms(name,type,count)  # return per-atom property of all atoms gathered into data, ordered by atom ID
+                                          # name = "x", "charge", "type", etc
+data = lmp.gather_atoms_concat(name,type,count)  # ditto, but concatenated atom values from each proc (unordered)
+data = lmp.gather_atoms_subset(name,type,count,ndata,ids)  # ditto, but for subset of Ndata atoms with IDs :pre
+
+lmp.scatter_atoms(name,type,count,data)   # scatter per-atom property to all atoms from data, ordered by atom ID
+                                          # name = "x", "charge", "type", etc
+                                          # count = # of per-atom values, 1 or 3, etc :pre
+lmp.scatter_atoms_subset(name,type,count,ndata,ids,data)  # ditto, but for subset of Ndata atoms with IDs :pre
+
+lmp.create_atoms(n,ids,types,x,v,image,shrinkexceed)   # create N atoms with IDs, types, x, v, and image flags :pre
+
+:line
+
+The lines
+
+from lammps import lammps
+lmp = lammps() :pre
+
+create an instance of LAMMPS, wrapped in a Python class by the lammps
+Python module, and return an instance of the Python class as lmp.  It
+is used to make all subsequent calls to the LAMMPS library.
+
+Additional arguments to lammps() can be used to tell Python the name
+of the shared library to load or to pass arguments to the LAMMPS
+instance, the same as if LAMMPS were launched from a command-line
+prompt.
+
+If the ptr argument is set like this:
+
+lmp = lammps(ptr=lmpptr) :pre
+
+then lmpptr must be an argument passed to Python via the LAMMPS
+"python"_python.html command, when it is used to define a Python
+function that is invoked by the LAMMPS input script.  This mode of
+calling Python from LAMMPS is described in the "Python
+call"_Python_call.html doc page.  The variable lmpptr refers to the
+instance of LAMMPS that called the embedded Python interpreter.  Using
+it as an argument to lammps() allows the returned Python class
+instance "lmp" to make calls to that instance of LAMMPS.  See the
+"python"_python.html command doc page for examples using this syntax.
+
+Note that you can create multiple LAMMPS objects in your Python
+script, and coordinate and run multiple simulations, e.g.
+
+from lammps import lammps
+lmp1 = lammps()
+lmp2 = lammps()
+lmp1.file("in.file1")
+lmp2.file("in.file2") :pre
+
+The file(), command(), commands_list(), commands_string() methods
+allow an input script, a single command, or multiple commands to be
+invoked.
+
+The extract_setting(), extract_global(), extract_box(),
+extract_atom(), extract_compute(), extract_fix(), and
+extract_variable() methods return values or pointers to data
+structures internal to LAMMPS.
+
+For extract_global() see the src/library.cpp file for the list of
+valid names.  New names could easily be added.  A double or integer is
+returned.  You need to specify the appropriate data type via the type
+argument.
+
+For extract_atom(), a pointer to internal LAMMPS atom-based data is
+returned, which you can use via normal Python subscripting.  See the
+extract() method in the src/atom.cpp file for a list of valid names.
+Again, new names could easily be added if the property you want is not
+listed.  A pointer to a vector of doubles or integers, or a pointer to
+an array of doubles (double **) or integers (int **) is returned.  You
+need to specify the appropriate data type via the type argument.
+
+For extract_compute() and extract_fix(), the global, per-atom, or
+local data calculated by the compute or fix can be accessed.  What is
+returned depends on whether the compute or fix calculates a scalar or
+vector or array.  For a scalar, a single double value is returned.  If
+the compute or fix calculates a vector or array, a pointer to the
+internal LAMMPS data is returned, which you can use via normal Python
+subscripting.  The one exception is that for a fix that calculates a
+global vector or array, a single double value from the vector or array
+is returned, indexed by I (vector) or I and J (array).  I,J are
+zero-based indices.  The I,J arguments can be left out if not needed.
+See "Section 6.15"_Section_howto.html#howto_15 of the manual for a
+discussion of global, per-atom, and local data, and of scalar, vector,
+and array data types.  See the doc pages for individual
+"computes"_compute.html and "fixes"_fix.html for a description of what
+they calculate and store.
+
+For extract_variable(), an "equal-style or atom-style
+variable"_variable.html is evaluated and its result returned.
+
+For equal-style variables a single double value is returned and the
+group argument is ignored.  For atom-style variables, a vector of
+doubles is returned, one value per atom, which you can use via normal
+Python subscripting. The values will be zero for atoms not in the
+specified group.
+
+The get_thermo() method returns returns the current value of a thermo
+keyword as a float.
+
+The get_natoms() method returns the total number of atoms in the
+simulation, as an int.
+
+The set_variable() methosd sets an existing string-style variable to a
+new string value, so that subsequent LAMMPS commands can access the
+variable.
+
+The reset_box() emthods resets the size and shape of the simulation
+box, e.g. as part of restoring a previously extracted and saved state
+of a simulation.
+
+The gather methods collect peratom info of the requested type (atom
+coords, atom types, forces, etc) from all processors, and returns the
+same vector of values to each callling processor.  The scatter
+functions do the inverse.  They distribute a vector of peratom values,
+passed by all calling processors, to invididual atoms, which may be
+owned by different processos.
+
+Note that the data returned by the gather methods,
+e.g. gather_atoms("x"), is different from the data structure returned
+by extract_atom("x") in four ways.  (1) Gather_atoms() returns a
+vector which you index as x\[i\]; extract_atom() returns an array
+which you index as x\[i\]\[j\].  (2) Gather_atoms() orders the atoms
+by atom ID while extract_atom() does not.  (3) Gather_atoms() returns
+a list of all atoms in the simulation; extract_atoms() returns just
+the atoms local to each processor.  (4) Finally, the gather_atoms()
+data structure is a copy of the atom coords stored internally in
+LAMMPS, whereas extract_atom() returns an array that effectively
+points directly to the internal data.  This means you can change
+values inside LAMMPS from Python by assigning a new values to the
+extract_atom() array.  To do this with the gather_atoms() vector, you
+need to change values in the vector, then invoke the scatter_atoms()
+method.
+
+For the scatter methods, the array of coordinates passed to must be a
+ctypes vector of ints or doubles, allocated and initialized something
+like this:
+
+from ctypes import *
+natoms = lmp.get_natoms()
+n3 = 3*natoms
+x = (n3*c_double)()
+x\[0\] = x coord of atom with ID 1
+x\[1\] = y coord of atom with ID 1
+x\[2\] = z coord of atom with ID 1
+x\[3\] = x coord of atom with ID 2
+...
+x\[n3-1\] = z coord of atom with ID natoms
+lmp.scatter_atoms("x",1,3,x) :pre
+
+Alternatively, you can just change values in the vector returned by
+the gather methods, since they are also ctypes vectors.
+
+:line
+
+As noted above, these Python class methods correspond one-to-one with
+the functions in the LAMMPS library interface in src/library.cpp and
+library.h.  This means you can extend the Python wrapper via the
+following steps:
+
+Add a new interface function to src/library.cpp and
+src/library.h. :ulb,l
+
+Rebuild LAMMPS as a shared library. :l
+
+Add a wrapper method to python/lammps.py for this interface
+function. :l
+
+You should now be able to invoke the new interface function from a
+Python script. :l
+:ule

doc/src/Python_mpi.txt

@@ -0,0 +1,67 @@
+"Higher level section"_Python.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+Extending Python to run in parallel :h3
+
+If you wish to run LAMMPS in parallel from Python, you need to extend
+your Python with an interface to MPI.  This also allows you to
+make MPI calls directly from Python in your script, if you desire.
+
+We recommend use of mpi4py:
+
+"PyPar"_https://github.com/daleroberts/pypar :ul
+
+As of version 2.0.0 it allows passing a custom MPI communicator to
+the LAMMPS constructor, which means one can easily run one or more
+LAMMPS instances on subsets of the total MPI ranks.
+
+To install mpi4py (version mpi4py-2.0.0 as of Oct 2015), unpack it
+and from its main directory, type
+
+python setup.py build
+sudo python setup.py install :pre
+
+Again, the "sudo" is only needed if required to copy mpi4py files into
+your Python distribution's site-packages directory. To install with
+user privilege into the user local directory type
+
+python setup.py install --user :pre
+
+If you have successfully installed mpi4py, you should be able to run
+Python and type
+
+from mpi4py import MPI :pre
+
+without error.  You should also be able to run python in parallel
+on a simple test script
+
+% mpirun -np 4 python test.py :pre
+
+where test.py contains the lines
+
+from mpi4py import MPI
+comm = MPI.COMM_WORLD
+print "Proc %d out of %d procs" % (comm.Get_rank(),comm.Get_size()) :pre
+
+and see one line of output for each processor you run on.
+
+NOTE: To use mpi4py and LAMMPS in parallel from Python, you must
+insure both are using the same version of MPI.  If you only have one
+MPI installed on your system, this is not an issue, but it can be if
+you have multiple MPIs.  Your LAMMPS build is explicit about which MPI
+it is using, since you specify the details in your lo-level
+src/MAKE/Makefile.foo file.  Mpi4py uses the "mpicc" command to find
+information about the MPI it uses to build against.  And it tries to
+load "libmpi.so" from the LD_LIBRARY_PATH.  This may or may not find
+the MPI library that LAMMPS is using.  If you have problems running
+both mpi4py and LAMMPS together, this is an issue you may need to
+address, e.g. by moving other MPI installations so that mpi4py finds
+the right one.
+
+

doc/src/Python_overview.txt

@@ -0,0 +1,35 @@
+"Previous Section"_Examples.html - "LAMMPS WWW Site"_lws -
+"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
+Section"_Tools.html :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands.html#comm)
+
+:line
+
+Overview of Python and LAMMPS :h3
+
+LAMMPS can work together with Python in three ways.  First, Python can
+wrap LAMMPS through the its "library interface"_Howto_library.html, so
+that a Python script can create one or more instances of LAMMPS and
+launch one or more simulations.  In Python lingo, this is "extending"
+Python with LAMMPS.
+
+Second, a lower-level Python interface can be used indirectly through
+provided PyLammps and IPyLammps wrapper classes, written in Python.
+These wrappers try to simplify the usage of LAMMPS in Python by
+providing an object-based interface to common LAMMPS functionality.
+They also reduces the amount of code necessary to parameterize LAMMPS
+scripts through Python and make variables and computes directly
+accessible.
+
+Third, LAMMPS can use the Python interpreter, so that a LAMMPS
+input script can invoke Python code directly, and pass information
+back-and-forth between the input script and Python functions you
+write.  This Python code can also callback to LAMMPS to query or change
+its attributes.  In Python lingo, this is "embedding" Python in
+LAMMPS.  When used in this mode, Python can perform operations that
+the simple LAMMPS input script syntax cannot.
+
+

doc/src/Python_pylammps.txt

@@ -0,0 +1,14 @@
+"Higher level section"_Python.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+PyLammps interface :h3
+
+PyLammps is a Python wrapper class which can be created on its own or
+use an existing lammps Python object.  It has its own "PyLammps
+Tutorial"_tutorial_pylammps.html doc page.

doc/src/Python_run.txt

@@ -0,0 +1,40 @@
+"Higher level section"_Python.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+Run LAMMPS from Python :h3
+
+The LAMMPS distribution includes a python directory with all you need
+to run LAMMPS from Python.  The python/lammps.py file wraps the LAMMPS
+library interface, with one wrapper function per LAMMPS library
+function.  This file makes it is possible to do the following either
+from a Python script, or interactively from a Python prompt: create
+one or more instances of LAMMPS, invoke LAMMPS commands or give it an
+input script, run LAMMPS incrementally, extract LAMMPS results, an
+modify internal LAMMPS variables.  From a Python script you can do
+this in serial or parallel.  Running Python interactively in parallel
+does not generally work, unless you have a version of Python that
+extends Python to enable multiple instances of Python to read what you
+type.
+
+To do all of this, you must first build LAMMPS as a shared library,
+then insure that your Python can find the python/lammps.py file and
+the shared library.
+
+Two advantages of using Python to run LAMMPS are how concise the
+language is, and that it can be run interactively, enabling rapid
+development and debugging.  If you use it to mostly invoke costly
+operations within LAMMPS, such as running a simulation for a
+reasonable number of timesteps, then the overhead cost of invoking
+LAMMPS thru Python will be negligible.
+
+The Python wrapper for LAMMPS uses the "ctypes" package in Python,
+which auto-generates the interface code needed between Python and a
+set of C-style library functions.  Ctypes is part of standard Python
+for versions 2.5 and later.  You can check which version of Python you
+have by simply typing "python" at a shell prompt.

doc/src/Python_shlib.txt

@@ -0,0 +1,34 @@
+"Higher level section"_Python.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+Build LAMMPS as a shared library :h3
+
+Instructions on how to build LAMMPS as a shared library are given in
+"Section 2.4"_Section_start.html#start_4.  A shared library is one
+that is dynamically loadable, which is what Python requires to wrap
+LAMMPS.  On Linux this is a library file that ends in ".so", not ".a".
+
+From the src directory, type
+
+make foo mode=shlib :pre
+
+where foo is the machine target name, such as mpi or serial.
+This should create the file liblammps_foo.so in the src directory, as
+well as a soft link liblammps.so, which is what the Python wrapper will
+load by default.  Note that if you are building multiple machine
+versions of the shared library, the soft link is always set to the
+most recently built version.
+
+NOTE: If you are building LAMMPS with an MPI or FFT library or other
+auxiliary libraries (used by various packages), then all of these
+extra libraries must also be shared libraries.  If the LAMMPS
+shared-library build fails with an error complaining about this, see
+"Section 2.4"_Section_start.html#start_4 for more details.
+
+Also include CMake info on this

doc/src/Python_test.txt

@@ -0,0 +1,131 @@
+"Higher level section"_Python.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+Test the Python/LAMMPS interface :h3
+
+To test if LAMMPS is callable from Python, launch Python interactively
+and type:
+
+>>> from lammps import lammps
+>>> lmp = lammps() :pre
+
+If you get no errors, you're ready to use LAMMPS from Python.  If the
+2nd command fails, the most common error to see is
+
+OSError: Could not load LAMMPS dynamic library :pre
+
+which means Python was unable to load the LAMMPS shared library.  This
+typically occurs if the system can't find the LAMMPS shared library or
+one of the auxiliary shared libraries it depends on, or if something
+about the library is incompatible with your Python.  The error message
+should give you an indication of what went wrong.
+
+You can also test the load directly in Python as follows, without
+first importing from the lammps.py file:
+
+>>> from ctypes import CDLL
+>>> CDLL("liblammps.so") :pre
+
+If an error occurs, carefully go thru the steps in "Section
+2.4"_Section_start.html#start_4 and above about building a shared
+library and about insuring Python can find the necessary two files
+it needs.
+
+[Test LAMMPS and Python in serial:] :h4
+
+To run a LAMMPS test in serial, type these lines into Python
+interactively from the bench directory:
+
+>>> from lammps import lammps
+>>> lmp = lammps()
+>>> lmp.file("in.lj") :pre
+
+Or put the same lines in the file test.py and run it as
+
+% python test.py :pre
+
+Either way, you should see the results of running the in.lj benchmark
+on a single processor appear on the screen, the same as if you had
+typed something like:
+
+lmp_g++ -in in.lj :pre
+
+[Test LAMMPS and Python in parallel:] :h4
+
+To run LAMMPS in parallel, assuming you have installed the
+"PyPar"_https://github.com/daleroberts/pypar package as discussed
+above, create a test.py file containing these lines:
+
+import pypar
+from lammps import lammps
+lmp = lammps()
+lmp.file("in.lj")
+print "Proc %d out of %d procs has" % (pypar.rank(),pypar.size()),lmp
+pypar.finalize() :pre
+
+To run LAMMPS in parallel, assuming you have installed the
+"mpi4py"_https://bitbucket.org/mpi4py/mpi4py package as discussed
+above, create a test.py file containing these lines:
+
+from mpi4py import MPI
+from lammps import lammps
+lmp = lammps()
+lmp.file("in.lj")
+me = MPI.COMM_WORLD.Get_rank()
+nprocs = MPI.COMM_WORLD.Get_size()
+print "Proc %d out of %d procs has" % (me,nprocs),lmp
+MPI.Finalize() :pre
+
+You can either script in parallel as:
+
+% mpirun -np 4 python test.py :pre
+
+and you should see the same output as if you had typed
+
+% mpirun -np 4 lmp_g++ -in in.lj :pre
+
+Note that if you leave out the 3 lines from test.py that specify PyPar
+commands you will instantiate and run LAMMPS independently on each of
+the P processors specified in the mpirun command.  In this case you
+should get 4 sets of output, each showing that a LAMMPS run was made
+on a single processor, instead of one set of output showing that
+LAMMPS ran on 4 processors.  If the 1-processor outputs occur, it
+means that PyPar is not working correctly.
+
+Also note that once you import the PyPar module, PyPar initializes MPI
+for you, and you can use MPI calls directly in your Python script, as
+described in the PyPar documentation.  The last line of your Python
+script should be pypar.finalize(), to insure MPI is shut down
+correctly.
+
+[Running Python scripts:] :h4
+
+Note that any Python script (not just for LAMMPS) can be invoked in
+one of several ways:
+
+% python foo.script
+% python -i foo.script
+% foo.script :pre
+
+The last command requires that the first line of the script be
+something like this:
+
+#!/usr/local/bin/python
+#!/usr/local/bin/python -i :pre
+
+where the path points to where you have Python installed, and that you
+have made the script file executable:
+
+% chmod +x foo.script :pre
+
+Without the "-i" flag, Python will exit when the script finishes.
+With the "-i" flag, you will be left in the Python interpreter when
+the script finishes, so you can type subsequent commands.  As
+mentioned above, you can only run Python interactively when running
+Python on a single processor, not in parallel.

doc/src/Section_accelerate.txt

@@ -1,391 +0,0 @@
-"Previous Section"_Section_packages.html - "LAMMPS WWW Site"_lws -
-"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
-Section"_Section_howto.html :c
-
-:link(lws,http://lammps.sandia.gov)
-:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
-
-:line
-
-5. Accelerating LAMMPS performance :h2
-
-This section describes various methods for improving LAMMPS
-performance for different classes of problems running on different
-kinds of machines.
-
-There are two thrusts to the discussion that follows.  The
-first is 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.
-
-5.1 "Measuring performance"_#acc_1 :ulb,l
-5.2 "Algorithms and code options to boost performace"_#acc_2 :l
-5.3 "Accelerator packages with optimized styles"_#acc_3 :l
-    5.3.1 "GPU package"_accelerate_gpu.html :l
-    5.3.2 "USER-INTEL package"_accelerate_intel.html :l
-    5.3.3 "KOKKOS package"_accelerate_kokkos.html :l
-    5.3.4 "USER-OMP package"_accelerate_omp.html :l
-    5.3.5 "OPT package"_accelerate_opt.html :l
-5.4 "Comparison of various accelerator packages"_#acc_4 :l
-:ule
-
-The "Benchmark page"_http://lammps.sandia.gov/bench.html of the LAMMPS
-web site gives performance results for the various accelerator
-packages discussed in Section 5.2, for several of the standard LAMMPS
-benchmark problems, as a function of problem size and number of
-compute nodes, on different hardware platforms.
-
-:line
-:line
-
-5.1 Measuring performance :h3,link(acc_1)
-
-Before trying to make your simulation run faster, you should
-understand how it currently performs and where the bottlenecks are.
-
-The best way to do this is run the your system (actual number of
-atoms) for a modest number of timesteps (say 100 steps) on several
-different processor counts, including a single processor if possible.
-Do this for an equilibrium version of your system, so that the
-100-step timings are representative of a much longer run.  There is
-typically no need to run for 1000s of timesteps to get accurate
-timings; you can simply extrapolate from short runs.
-
-For the set of runs, look at the timing data printed to the screen and
-log file at the end of each LAMMPS run.  "This
-section"_Section_start.html#start_7 of the manual has an overview.
-
-Running on one (or a few processors) should give a good estimate of
-the serial performance and what portions of the timestep are taking
-the most time.  Running the same problem on a few different processor
-counts should give an estimate of parallel scalability.  I.e. if the
-simulation runs 16x faster on 16 processors, its 100% parallel
-efficient; if it runs 8x faster on 16 processors, it's 50% efficient.
-
-The most important data to look at in the timing info is the timing
-breakdown and relative percentages.  For example, trying different
-options for speeding up the long-range solvers will have little impact
-if they only consume 10% of the run time.  If the pairwise time is
-dominating, you may want to look at GPU or OMP versions of the pair
-style, as discussed below.  Comparing how the percentages change as
-you increase the processor count gives you a sense of how different
-operations within the timestep are scaling.  Note that if you are
-running with a Kspace solver, there is additional output on the
-breakdown of the Kspace time.  For PPPM, this includes the fraction
-spent on FFTs, which can be communication intensive.
-
-Another important detail in the timing info are the histograms of
-atoms counts and neighbor counts.  If these vary widely across
-processors, you have a load-imbalance issue.  This often results in
-inaccurate relative timing data, because processors have to wait when
-communication occurs for other processors to catch up.  Thus the
-reported times for "Communication" or "Other" may be higher than they
-really are, due to load-imbalance.  If this is an issue, you can
-uncomment the MPI_Barrier() lines in src/timer.cpp, and recompile
-LAMMPS, to obtain synchronized timings.
-
-:line
-
-5.2 General strategies :h3,link(acc_2)
-
-NOTE: this section 5.2 is still a work in progress
-
-Here is a list of general ideas for improving simulation performance.
-Most of them are only applicable to certain models and certain
-bottlenecks in the current performance, so let the timing data you
-generate be your guide.  It is hard, if not impossible, to predict how
-much difference these options will make, since it is a function of
-problem size, number of processors used, and your machine.  There is
-no substitute for identifying performance bottlenecks, and trying out
-various options.
-
-rRESPA
-2-FFT PPPM
-Staggered PPPM
-single vs double PPPM
-partial charge PPPM
-verlet/split run style
-processor command for proc layout and numa layout
-load-balancing: balance and fix balance :ul
-
-2-FFT PPPM, also called {analytic differentiation} or {ad} PPPM, uses
-2 FFTs instead of the 4 FFTs used by the default {ik differentiation}
-PPPM. However, 2-FFT PPPM also requires a slightly larger mesh size to
-achieve the same accuracy as 4-FFT PPPM. For problems where the FFT
-cost is the performance bottleneck (typically large problems running
-on many processors), 2-FFT PPPM may be faster than 4-FFT PPPM.
-
-Staggered PPPM performs calculations using two different meshes, one
-shifted slightly with respect to the other.  This can reduce force
-aliasing errors and increase the accuracy of the method, but also
-doubles the amount of work required. For high relative accuracy, using
-staggered PPPM allows one to half the mesh size in each dimension as
-compared to regular PPPM, which can give around a 4x speedup in the
-kspace time. However, for low relative accuracy, using staggered PPPM
-gives little benefit and can be up to 2x slower in the kspace
-time. For example, the rhodopsin benchmark was run on a single
-processor, and results for kspace time vs. relative accuracy for the
-different methods are shown in the figure below.  For this system,
-staggered PPPM (using ik differentiation) becomes useful when using a
-relative accuracy of slightly greater than 1e-5 and above.
-
-:c,image(JPG/rhodo_staggered.jpg)
-
-NOTE: Using staggered PPPM may not give the same increase in accuracy
-of energy and pressure as it does in forces, so some caution must be
-used if energy and/or pressure are quantities of interest, such as
-when using a barostat.
-
-:line
-
-5.3 Packages with optimized styles :h3,link(acc_3)
-
-Accelerated versions of various "pair_style"_pair_style.html,
-"fixes"_fix.html, "computes"_compute.html, and other commands have
-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.
-
-All of these commands are in packages provided with LAMMPS.  An
-overview of packages is give in "Section
-packages"_Section_packages.html.
-
-These are the accelerator packages
-currently in LAMMPS, either as standard or user packages:
-
-"GPU Package"_accelerate_gpu.html : for NVIDIA GPUs as well as OpenCL support
-"USER-INTEL Package"_accelerate_intel.html : for Intel CPUs and Intel Xeon Phi
-"KOKKOS Package"_accelerate_kokkos.html : for Nvidia GPUs, Intel Xeon Phi, and OpenMP threading
-"USER-OMP Package"_accelerate_omp.html : for OpenMP threading and generic CPU optimizations
-"OPT Package"_accelerate_opt.html : generic CPU optimizations :tb(s=:)
-
-<!-- RST
-
-.. toctree::
-   :maxdepth: 1
-   :hidden:
-
-   accelerate_gpu
-   accelerate_intel
-   accelerate_kokkos
-   accelerate_omp
-   accelerate_opt
-
-END_RST -->
-
-Inverting this list, LAMMPS currently has acceleration support for
-three kinds of hardware, via the listed packages:
-
-Many-core CPUs : "USER-INTEL"_accelerate_intel.html, "KOKKOS"_accelerate_kokkos.html, "USER-OMP"_accelerate_omp.html, "OPT"_accelerate_opt.html packages
-NVIDIA GPUs : "GPU"_accelerate_gpu.html, "KOKKOS"_accelerate_kokkos.html packages
-Intel Phi : "USER-INTEL"_accelerate_intel.html, "KOKKOS"_accelerate_kokkos.html packages :tb(s=:)
-
-Which package is fastest for your hardware may depend on the size
-problem you are running and what commands (accelerated and
-non-accelerated) are invoked by your input script.  While these doc
-pages include performance guidelines, there is no substitute for
-trying out the different packages appropriate to your hardware.
-
-Any accelerated style has the same name as the corresponding standard
-style, except that a suffix is appended.  Otherwise, the syntax for
-the command that uses the style is identical, their functionality is
-the same, and the numerical results it produces should also be the
-same, except for precision and round-off effects.
-
-For example, all of these styles are accelerated variants of the
-Lennard-Jones "pair_style lj/cut"_pair_lj.html:
-
-"pair_style lj/cut/gpu"_pair_lj.html
-"pair_style lj/cut/intel"_pair_lj.html
-"pair_style lj/cut/kk"_pair_lj.html
-"pair_style lj/cut/omp"_pair_lj.html
-"pair_style lj/cut/opt"_pair_lj.html :ul
-
-To see what accelerate styles are currently available, see
-"Section 3.5"_Section_commands.html#cmd_5 of the manual.  The
-doc pages for individual commands (e.g. "pair lj/cut"_pair_lj.html or
-"fix nve"_fix_nve.html) also list any accelerated variants available
-for that style.
-
-To use an accelerator package in LAMMPS, and one or more of the styles
-it provides, follow these general steps.  Details vary from package to
-package and are explained in the individual accelerator doc pages,
-listed above:
-
-build the accelerator library |
-  only for GPU package |
-install the accelerator package |
-  make yes-opt, make yes-user-intel, etc |
-add compile/link flags to Makefile.machine in src/MAKE |
-  only for USER-INTEL, KOKKOS, USER-OMP, OPT packages |
-re-build LAMMPS |
-  make machine |
-prepare and test a regular LAMMPS simulation |
-  lmp_machine -in in.script; mpirun -np 32 lmp_machine -in in.script |
-enable specific accelerator support via '-k on' "command-line switch"_Section_start.html#start_6, |
-  only needed for KOKKOS package |
-set any needed options for the package via "-pk" "command-line switch"_Section_start.html#start_6 or "package"_package.html command, |
-  only if defaults need to be changed |
-use accelerated styles in your input via "-sf" "command-line switch"_Section_start.html#start_6 or "suffix"_suffix.html command | lmp_machine -in in.script -sf gpu
-:tb(c=2,s=|)
-
-Note that the first 4 steps can be done as a single command with
-suitable make command invocations. This is discussed in "Section
-4"_Section_packages.html of the manual, and its use is
-illustrated in the individual accelerator sections.  Typically these
-steps only need to be done once, to create an executable that uses one
-or more accelerator packages.
-
-The last 4 steps can all be done from the command-line when LAMMPS is
-launched, without changing your input script, as illustrated in the
-individual accelerator sections.  Or you can add
-"package"_package.html and "suffix"_suffix.html commands to your input
-script.
-
-NOTE: With a few exceptions, you can build a single LAMMPS executable
-with all its accelerator packages installed.  Note however that the
-USER-INTEL and KOKKOS packages require you to choose one of their
-hardware options when building for a specific platform.  I.e. CPU or
-Phi option for the USER-INTEL package.  Or the OpenMP, Cuda, or Phi
-option for the KOKKOS package.
-
-These are the exceptions.  You cannot build a single executable with:
-
-both the USER-INTEL Phi and KOKKOS Phi options
-the USER-INTEL Phi or Kokkos Phi option, and the GPU package :ul
-
-See the examples/accelerate/README and make.list files for sample
-Make.py commands that build LAMMPS with any or all of the accelerator
-packages.  As an example, here is a command that builds with all the
-GPU related packages installed (GPU, KOKKOS with Cuda), including
-settings to build the needed auxiliary GPU libraries for Kepler GPUs:
-
-Make.py -j 16 -p omp gpu kokkos -cc nvcc wrap=mpi \
-  -gpu mode=double arch=35 -kokkos cuda arch=35 lib-all file mpi :pre
-
-The examples/accelerate directory also has input scripts that can be
-used with all of the accelerator packages.  See its README file for
-details.
-
-Likewise, the bench directory has FERMI and KEPLER and PHI
-sub-directories with Make.py commands and input scripts for using all
-the accelerator packages on various machines.  See the README files in
-those dirs.
-
-As mentioned above, the "Benchmark
-page"_http://lammps.sandia.gov/bench.html of the LAMMPS web site gives
-performance results for the various accelerator packages for several
-of the standard LAMMPS benchmark problems, as a function of problem
-size and number of compute nodes, on different hardware platforms.
-
-Here is a brief summary of what the various packages provide.  Details
-are in the individual accelerator sections.
-
-Styles with a "gpu" suffix are part of the GPU package, and can be run
-on NVIDIA GPUs.  The speed-up on a GPU depends on a variety of
-factors, discussed in the accelerator sections. :ulb,l
-
-Styles with an "intel" suffix are part of the USER-INTEL
-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
-on the hardware configuration. :l
-
-Styles with a "kk" suffix are part of the KOKKOS package, and can be
-run using OpenMP on multicore CPUs, on an NVIDIA GPU, or on an Intel
-Xeon Phi in "native" mode.  The speed-up depends on a variety of
-factors, as discussed on the KOKKOS accelerator page. :l
-
-Styles with an "omp" suffix are part of the USER-OMP package and allow
-a pair-style to be run in multi-threaded mode using OpenMP.  This can
-be useful on nodes with high-core counts when using less MPI processes
-than cores is advantageous, e.g. when running with PPPM so that FFTs
-are run on fewer MPI processors or when the many MPI tasks would
-overload the available bandwidth for communication. :l
-
-Styles with an "opt" suffix are part of the OPT package and typically
-speed-up the pairwise calculations of your simulation by 5-25% on a
-CPU. :l
-:ule
-
-The individual accelerator package doc pages explain:
-
-what hardware and software the accelerated package requires
-how to build LAMMPS with the accelerated package
-how to run with the accelerated package either via command-line switches or modifying the input script
-speed-ups to expect
-guidelines for best performance
-restrictions :ul
-
-:line
-
-5.4 Comparison of various accelerator packages :h3,link(acc_4)
-
-NOTE: this section still needs to be re-worked with additional KOKKOS
-and USER-INTEL information.
-
-The next section compares and contrasts the various accelerator
-options, since there are multiple ways to perform OpenMP threading,
-run on GPUs, and run on Intel Xeon Phi coprocessors.
-
-All 3 of these packages accelerate a LAMMPS calculation using NVIDIA
-hardware, but they do it in different ways.
-
-As a consequence, for a particular simulation on specific hardware,
-one package may be faster than the other.  We give guidelines below,
-but the best way to determine which package is faster for your input
-script is to try both of them on your machine.  See the benchmarking
-section below for examples where this has been done.
-
-[Guidelines for using each package optimally:]
-
-The GPU package allows you to assign multiple CPUs (cores) to a single
-GPU (a common configuration for "hybrid" nodes that contain multicore
-CPU(s) and GPU(s)) and works effectively in this mode. :ulb,l
-
-The GPU package moves per-atom data (coordinates, forces)
-back-and-forth between the CPU and GPU every timestep.  The
-KOKKOS/CUDA package only does this on timesteps when a CPU calculation
-is required (e.g. to invoke a fix or compute that is non-GPU-ized).
-Hence, if you can formulate your input script to only use GPU-ized
-fixes and computes, and avoid doing I/O too often (thermo output, dump
-file snapshots, restart files), then the data transfer cost of the
-KOKKOS/CUDA package can be very low, causing it to run faster than the
-GPU package. :l
-
-The GPU package is often faster than the KOKKOS/CUDA package, if the
-number of atoms per GPU is smaller.  The crossover point, in terms of
-atoms/GPU at which the KOKKOS/CUDA package becomes faster depends
-strongly on the pair style.  For example, for a simple Lennard Jones
-system the crossover (in single precision) is often about 50K-100K
-atoms per GPU.  When performing double precision calculations the
-crossover point can be significantly smaller. :l
-
-Both packages compute bonded interactions (bonds, angles, etc) on the
-CPU.  If the GPU package is running with several MPI processes
-assigned to one GPU, the cost of computing the bonded interactions is
-spread across more CPUs and hence the GPU package can run faster. :l
-
-When using the GPU package with multiple CPUs assigned to one GPU, its
-performance depends to some extent on high bandwidth between the CPUs
-and the GPU.  Hence its performance is affected if full 16 PCIe lanes
-are not available for each GPU.  In HPC environments this can be the
-case if S2050/70 servers are used, where two devices generally share
-one PCIe 2.0 16x slot.  Also many multi-GPU mainboards do not provide
-full 16 lanes to each of the PCIe 2.0 16x slots. :l
-:ule
-
-[Differences between the two packages:]
-
-The GPU package accelerates only pair force, neighbor list, and PPPM
-calculations. :ulb,l
-
-The GPU package requires neighbor lists to be built on the CPU when using
-exclusion lists, hybrid pair styles, or a triclinic simulation box. :l
-:ule

doc/src/Section_commands.txt

@@ -1,4 +1,4 @@
-"Previous Section"_Section_start.html - "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Section_packages.html :c
+"Previous Section"_Section_start.html - "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Packages.html :c
 
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
@@ -67,7 +67,7 @@ values are not desired, the "processors"_processors.html and
 tell LAMMPS how to map processors to the simulation box.
 
 Many input script errors are detected by LAMMPS and an ERROR or
-WARNING message is printed.  "This section"_Section_errors.html gives
+WARNING message is printed.  The "Errors"_Errors.html doc page gives
 more information on what errors mean.  The documentation for each
 command lists restrictions on how the command can be used.
 
@@ -129,6 +129,17 @@ region 1 block $((xlo+xhi)/2+sqrt(v_area)) 2 INF INF EDGE EDGE :pre
 
 so that you do not have to define (or discard) a temporary variable X.
 
+Additionally, the "immediate" variable expression may be followed by a
+colon, followed by a C-style format string, e.g. ":%f" or ":%.10g".
+The format string must be appropriate for a double-precision
+floating-point value.  The format string is used to output the result
+of the variable expression evaluation.  If a format string is not
+specified a high-precision "%.20g" is used as the default.
+
+This can be useful for formatting print output to a desired precion:
+
+print "Final energy per atom: $(pe/atoms:%10.3f) eV/atom" :pre
+
 Note that neither the curly-bracket or immediate form of variables can
 contain nested $ characters for other variables to substitute for.
 Thus you cannot do this:
@@ -193,10 +204,10 @@ allowed, but that should be sufficient for most use cases.
 3.3 Input script structure :h3,link(cmd_3)
 
 This section describes the structure of a typical LAMMPS input script.
-The "examples" directory in the LAMMPS distribution contains many
-sample input scripts; the corresponding problems are discussed in
-"Section 7"_Section_example.html, and animated on the "LAMMPS
-WWW Site"_lws.
+The examples directory in the LAMMPS distribution contains many sample
+input scripts; the corresponding problems are discussed on the
+"Examples"_Examples.html doc page, and animated on the "LAMMPS WWW
+Site"_lws.
 
 A LAMMPS input script typically has 4 parts:
 
@@ -543,8 +554,8 @@ Fix styles :h3
 See the "fix"_fix.html command for one-line descriptions of each style
 or click on the style itself for a full description.  Some of the
 styles have accelerated versions, which can be used if LAMMPS is built
-with the "appropriate accelerated package"_Section_accelerate.html.
-This is indicated by additional letters in parenthesis: g = GPU, i =
+with the "appropriate accelerated package"_Speed_packages.html.  This
+is indicated by additional letters in parenthesis: g = GPU, i =
 USER-INTEL, k = KOKKOS, o = USER-OMP, t = OPT.
 
 "adapt"_fix_adapt.html,
@@ -571,7 +582,7 @@ USER-INTEL, k = KOKKOS, o = USER-OMP, t = OPT.
 "dt/reset"_fix_dt_reset.html,
 "efield"_fix_efield.html,
 "ehex"_fix_ehex.html,
-"enforce2d"_fix_enforce2d.html,
+"enforce2d (k)"_fix_enforce2d.html,
 "evaporate"_fix_evaporate.html,
 "external"_fix_external.html,
 "freeze"_fix_freeze.html,
@@ -583,6 +594,7 @@ USER-INTEL, k = KOKKOS, o = USER-OMP, t = OPT.
 "indent"_fix_indent.html,
 "latte"_fix_latte.html,
 "langevin (k)"_fix_langevin.html,
+"langevin/spin"_fix_langevin_spin.hmtl,
 "lineforce"_fix_lineforce.html,
 "momentum (k)"_fix_momentum.html,
 "move"_fix_move.html,
@@ -606,6 +618,7 @@ USER-INTEL, k = KOKKOS, o = USER-OMP, t = OPT.
 "nve/line"_fix_nve_line.html,
 "nve/noforce"_fix_nve_noforce.html,
 "nve/sphere (o)"_fix_nve_sphere.html,
+"nve/spin"_fix_nve_spin.html,
 "nve/tri"_fix_nve_tri.html,
 "nvt (iko)"_fix_nh.html,
 "nvt/asphere (o)"_fix_nvt_asphere.html,
@@ -618,6 +631,7 @@ USER-INTEL, k = KOKKOS, o = USER-OMP, t = OPT.
 "planeforce"_fix_planeforce.html,
 "poems"_fix_poems.html,
 "pour"_fix_pour.html,
+"precession/spin"_fix_precession_spin.html,
 "press/berendsen"_fix_press_berendsen.html,
 "print"_fix_print.html,
 "property/atom (k)"_fix_property_atom.html,
@@ -664,6 +678,8 @@ USER-INTEL, k = KOKKOS, o = USER-OMP, t = OPT.
 "vector"_fix_vector.html,
 "viscosity"_fix_viscosity.html,
 "viscous"_fix_viscous.html,
+"wall/body/polygon"_fix_wall_body_polygon.html,
+"wall/body/polyhedron"_fix_wall_body_polyhedron.html,
 "wall/colloid"_fix_wall.html,
 "wall/gran"_fix_wall_gran.html,
 "wall/gran/region"_fix_wall_gran_region.html,
@@ -684,6 +700,7 @@ package"_Section_start.html#start_3.
 "addtorque"_fix_addtorque.html,
 "atc"_fix_atc.html,
 "ave/correlate/long"_fix_ave_correlate_long.html,
+"bond/react"_fix_bond_react.html,
 "colvars"_fix_colvars.html,
 "dpd/energy (k)"_fix_dpd_energy.html,
 "drude"_fix_drude.html,
@@ -758,9 +775,9 @@ See the "compute"_compute.html command for one-line descriptions of
 each style or click on the style itself for a full description.  Some
 of the styles have accelerated versions, which can be used if LAMMPS
 is built with the "appropriate accelerated
-package"_Section_accelerate.html.  This is indicated by additional
-letters in parenthesis: g = GPU, i = USER-INTEL, k =
-KOKKOS, o = USER-OMP, t = OPT.
+package"_Speed_packages.html.  This is indicated by additional letters
+in parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
+OPT.
 
 "aggregate/atom"_compute_cluster_atom.html,
 "angle"_compute_angle.html,
@@ -823,6 +840,7 @@ KOKKOS, o = USER-OMP, t = OPT.
 "sna/atom"_compute_sna_atom.html,
 "snad/atom"_compute_sna_atom.html,
 "snav/atom"_compute_sna_atom.html,
+"spin"_compute_spin.html,
 "stress/atom"_compute_stress_atom.html,
 "temp (k)"_compute_temp.html,
 "temp/asphere"_compute_temp_asphere.html,
@@ -851,6 +869,7 @@ package"_Section_start.html#start_3.
 "dpd"_compute_dpd.html,
 "dpd/atom"_compute_dpd_atom.html,
 "edpd/temp/atom"_compute_edpd_temp_atom.html,
+"entropy/atom"_compute_entropy_atom.html,
 "fep"_compute_fep.html,
 "force/tally"_compute_tally.html,
 "heat/flux/tally"_compute_tally.html,
@@ -901,9 +920,9 @@ See the "pair_style"_pair_style.html command for an overview of pair
 potentials.  Click on the style itself for a full description.  Many
 of the styles have accelerated versions, which can be used if LAMMPS
 is built with the "appropriate accelerated
-package"_Section_accelerate.html.  This is indicated by additional
-letters in parenthesis: g = GPU, i = USER-INTEL, k =
-KOKKOS, o = USER-OMP, t = OPT.
+package"_Speed_packages.html.  This is indicated by additional letters
+in parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
+OPT.
 
 "none"_pair_none.html,
 "zero"_pair_zero.html,
@@ -913,7 +932,9 @@ KOKKOS, o = USER-OMP, t = OPT.
 "airebo (oi)"_pair_airebo.html,
 "airebo/morse (oi)"_pair_airebo.html,
 "beck (go)"_pair_beck.html,
-"body"_pair_body.html,
+"body/nparticle"_pair_body_nparticle.html,
+"body/rounded/polygon"_pair_body_rounded/polygon.html,
+"body/rounded/polyhedron"_pair_body_rounded/polyhedron.html,
 "bop"_pair_bop.html,
 "born (go)"_pair_born.html,
 "born/coul/dsf"_pair_born.html,
@@ -948,6 +969,7 @@ KOKKOS, o = USER-OMP, t = OPT.
 "dsmc"_pair_dsmc.html,
 "eam (gikot)"_pair_eam.html,
 "eam/alloy (gikot)"_pair_eam.html,
+"eam/cd (o)"_pair_eam.html,
 "eam/fs (gikot)"_pair_eam.html,
 "eim (o)"_pair_eim.html,
 "gauss (go)"_pair_gauss.html,
@@ -1016,6 +1038,10 @@ KOKKOS, o = USER-OMP, t = OPT.
 "snap (k)"_pair_snap.html,
 "soft (go)"_pair_soft.html,
 "sw (giko)"_pair_sw.html,
+"spin/dmi"_pair_spin_dmi.html,
+"spin/exchange"_pair_spin_exchange.html,
+"spin/magelec"_pair_spin_magelec.html,
+"spin/neel"_pair_spin_neel.html,
 "table (gko)"_pair_table.html,
 "tersoff (giko)"_pair_tersoff.html,
 "tersoff/mod (gko)"_pair_tersoff_mod.html,
@@ -1044,7 +1070,6 @@ package"_Section_start.html#start_3.
 "coul/shield"_pair_coul_shield.html,
 "dpd/fdt"_pair_dpd_fdt.html,
 "dpd/fdt/energy (k)"_pair_dpd_fdt.html,
-"eam/cd (o)"_pair_eam.html,
 "edip (o)"_pair_edip.html,
 "edip/multi"_pair_edip.html,
 "edpd"_pair_meso.html,
@@ -1117,9 +1142,9 @@ See the "bond_style"_bond_style.html command for an overview of bond
 potentials.  Click on the style itself for a full description.  Some
 of the styles have accelerated versions, which can be used if LAMMPS
 is built with the "appropriate accelerated
-package"_Section_accelerate.html.  This is indicated by additional
-letters in parenthesis: g = GPU, i = USER-INTEL, k =
-KOKKOS, o = USER-OMP, t = OPT.
+package"_Speed_packages.html.  This is indicated by additional letters
+in parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
+OPT.
 
 "none"_bond_none.html,
 "zero"_bond_zero.html,
@@ -1151,9 +1176,9 @@ See the "angle_style"_angle_style.html command for an overview of
 angle potentials.  Click on the style itself for a full description.
 Some of the styles have accelerated versions, which can be used if
 LAMMPS is built with the "appropriate accelerated
-package"_Section_accelerate.html.  This is indicated by additional
-letters in parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o =
-USER-OMP, t = OPT.
+package"_Speed_packages.html.  This is indicated by additional letters
+in parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
+OPT.
 
 "none"_angle_none.html,
 "zero"_angle_zero.html,
@@ -1187,7 +1212,7 @@ See the "dihedral_style"_dihedral_style.html command for an overview
 of dihedral potentials.  Click on the style itself for a full
 description.  Some of the styles have accelerated versions, which can
 be used if LAMMPS is built with the "appropriate accelerated
-package"_Section_accelerate.html.  This is indicated by additional
+package"_Speed_packages.html.  This is indicated by additional
 letters in parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o =
 USER-OMP, t = OPT.
 
@@ -1211,7 +1236,8 @@ package"_Section_start.html#start_3.
 "nharmonic (o)"_dihedral_nharmonic.html,
 "quadratic (o)"_dihedral_quadratic.html,
 "spherical (o)"_dihedral_spherical.html,
-"table (o)"_dihedral_table.html :tb(c=4,ea=c)
+"table (o)"_dihedral_table.html,
+"table/cut"_dihedral_table_cut.html :tb(c=4,ea=c)
 
 :line
 
@@ -1221,9 +1247,9 @@ See the "improper_style"_improper_style.html command for an overview
 of improper potentials.  Click on the style itself for a full
 description.  Some of the styles have accelerated versions, which can
 be used if LAMMPS is built with the "appropriate accelerated
-package"_Section_accelerate.html.  This is indicated by additional
-letters in parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o =
-USER-OMP, t = OPT.
+package"_Speed_packages.html.  This is indicated by additional letters
+in parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
+OPT.
 
 "none"_improper_none.html,
 "zero"_improper_zero.html,
@@ -1250,9 +1276,9 @@ See the "kspace_style"_kspace_style.html command for an overview of
 Kspace solvers.  Click on the style itself for a full description.
 Some of the styles have accelerated versions, which can be used if
 LAMMPS is built with the "appropriate accelerated
-package"_Section_accelerate.html.  This is indicated by additional
-letters in parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o =
-USER-OMP, t = OPT.
+package"_Speed_packages.html.  This is indicated by additional letters
+in parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
+OPT.
 
 "ewald (o)"_kspace_style.html,
 "ewald/disp"_kspace_style.html,