Merge pull request #1048 from lammps/doc-reorg-start

Documentation Refactoring: Section Start
2018-08-15 15:25:17 -06:00
parent 6cc653f631 46f1e63a19
commit ccacf0d4bb
484 changed files with 6654 additions and 5423 deletions
--- a/cmake/CMakeLists.txt
+++ b/cmake/CMakeLists.txt
@ -17,6 +17,32 @@ file(GLOB LIB_SOURCES ${LAMMPS_SOURCE_DIR}/*.cpp)
 file(GLOB LMP_SOURCES ${LAMMPS_SOURCE_DIR}/main.cpp)
 list(REMOVE_ITEM LIB_SOURCES ${LMP_SOURCES})
 # Utility functions
 function(list_to_bulletpoints result)
    list(REMOVE_AT ARGV 0)
    set(temp "")
    foreach(item ${ARGV})
        set(temp "${temp}* ${item}\n")
    endforeach()
    set(${result} "${temp}" PARENT_SCOPE)
 endfunction(list_to_bulletpoints)
 function(validate_option name values)
    string(TOLOWER ${${name}} needle_lower)
    string(TOUPPER ${${name}} needle_upper)
    list(FIND ${values} ${needle_lower} IDX_LOWER)
    list(FIND ${values} ${needle_upper} IDX_UPPER)
    if(${IDX_LOWER} LESS 0 AND ${IDX_UPPER} LESS 0)
        list_to_bulletpoints(POSSIBLE_VALUE_LIST ${${values}})
        message(FATAL_ERROR "\n########################################################################\n"
                            "Invalid value '${${name}}' for option ${name}\n"
                            "\n"
                            "Possible values are:\n"
                            "${POSSIBLE_VALUE_LIST}"
                            "########################################################################")
    endif()
 endfunction(validate_option)
 # Cmake modules/macros are in a subdirectory to keep this file cleaner
 set(CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR}/Modules)
@ -106,8 +132,6 @@ if(NOT BUILD_EXE AND NOT BUILD_LIB)
  message(FATAL_ERROR "You need to at least enable one of two following options: BUILD_LIB or BUILD_EXE")
 endif()
 option(DEVELOPER_MODE "Enable developer mode" OFF)
 mark_as_advanced(DEVELOPER_MODE)
 option(CMAKE_VERBOSE_MAKEFILE "Generate verbose Makefiles" OFF)
 include(GNUInstallDirs)
@ -133,15 +157,21 @@ else()
  list(APPEND LAMMPS_LINK_LIBS mpi_stubs)
 endif()
-set(LAMMPS_SIZE_LIMIT "LAMMPS_SMALLBIG" CACHE STRING "Lammps size limit")
+
-set_property(CACHE LAMMPS_SIZE_LIMIT PROPERTY STRINGS LAMMPS_SMALLBIG LAMMPS_BIGBIG LAMMPS_SMALLSMALL)
+set(LAMMPS_SIZES "smallbig" CACHE STRING "LAMMPS size limit")
-add_definitions(-D${LAMMPS_SIZE_LIMIT})
+set(LAMMPS_SIZES_VALUES smallbig bigbig smallsmall)
-set(LAMMPS_API_DEFINES "${LAMMPS_API_DEFINES} -D${LAMMPS_SIZE_LIMIT}")
+set_property(CACHE LAMMPS_SIZES PROPERTY STRINGS ${LAMMPS_SIZES_VALUES})
 validate_option(LAMMPS_SIZES LAMMPS_SIZES_VALUES)
 string(TOUPPER ${LAMMPS_SIZES} LAMMPS_SIZES)
 add_definitions(-DLAMMPS_${LAMMPS_SIZES})
 set(LAMMPS_API_DEFINES "${LAMMPS_API_DEFINES} -DLAMMPS_${LAMMPS_SIZES}")
 # posix_memalign is not available on Windows
 if(NOT ${CMAKE_SYSTEM_NAME} STREQUAL "Windows")
-  set(LAMMPS_MEMALIGN "64" CACHE STRING "enables the use of the posix_memalign() call instead of malloc() when large chunks or memory are allocated by LAMMPS")
+  set(LAMMPS_MEMALIGN "64" CACHE STRING "enables the use of the posix_memalign() call instead of malloc() when large chunks or memory are allocated by LAMMPS. Set to 0 to disable")
-  add_definitions(-DLAMMPS_MEMALIGN=${LAMMPS_MEMALIGN})
+  if(NOT ${LAMMPS_MEMALIGN} STREQUAL "0")
    add_definitions(-DLAMMPS_MEMALIGN=${LAMMPS_MEMALIGN})
  endif()
 endif()
 option(LAMMPS_EXCEPTIONS "enable the use of C++ exceptions for error messages (useful for library interface)" OFF)
@ -216,10 +246,12 @@ if(PKG_KSPACE)
  if(${FFTW}_FOUND)
    set(FFT "${FFTW}" CACHE STRING "FFT library for KSPACE package")
  else()
-    set(FFT "KISSFFT" CACHE STRING "FFT library for KSPACE package")
+    set(FFT "KISS" CACHE STRING "FFT library for KSPACE package")
  endif()
-  set_property(CACHE FFT PROPERTY STRINGS KISSFFT ${FFTW} MKL)
+  set(FFT_VALUES KISS ${FFTW} MKL)
-  if(NOT FFT STREQUAL "KISSFFT")
+  set_property(CACHE FFT PROPERTY STRINGS ${FFT_VALUES})
  validate_option(FFT FFT_VALUES)
  if(NOT FFT STREQUAL "KISS")
    find_package(${FFT} REQUIRED)
    if(NOT FFT STREQUAL "FFTW3F")
      add_definitions(-DFFT_FFTW)
@ -228,11 +260,16 @@ if(PKG_KSPACE)
    endif()
    include_directories(${${FFT}_INCLUDE_DIRS})
    list(APPEND LAMMPS_LINK_LIBS ${${FFT}_LIBRARIES})
  else()
    add_definitions(-DFFT_KISS)
  endif()
-  set(PACK_OPTIMIZATION "PACK_ARRAY" CACHE STRING "Optimization for FFT")
+  set(FFT_PACK "array" CACHE STRING "Optimization for FFT")
-  set_property(CACHE PACK_OPTIMIZATION PROPERTY STRINGS PACK_ARRAY PACK_POINTER PACK_MEMCPY)
+  set(FFT_PACK_VALUES array pointer memcpy)
-  if(NOT PACK_OPTIMIZATION STREQUAL "PACK_ARRAY")
+  set_property(CACHE FFT_PACK PROPERTY STRINGS ${FFT_PACK_VALUES})
-    add_definitions(-D${PACK_OPTIMIZATION})
+  validate_option(FFT_PACK FFT_PACK_VALUES)
  if(NOT FFT_PACK STREQUAL "array")
    string(TOUPPER ${FFT_PACK} FFT_PACK)
    add_definitions(-DFFT_PACK_${FFT_PACK})
  endif()
 endif()
@ -374,8 +411,8 @@ if(PKG_USER-NETCDF)
 endif()
 if(PKG_USER-SMD)
-  option(DOWNLOAD_Eigen3 "Download Eigen3 (instead of using the system's one)" OFF)
+  option(DOWNLOAD_EIGEN3 "Download Eigen3 (instead of using the system's one)" OFF)
-  if(DOWNLOAD_Eigen3)
+  if(DOWNLOAD_EIGEN3)
    include(ExternalProject)
    ExternalProject_Add(Eigen3_build
      URL http://bitbucket.org/eigen/eigen/get/3.3.4.tar.gz 
@ -388,7 +425,7 @@ if(PKG_USER-SMD)
  else()
    find_package(Eigen3)
    if(NOT Eigen3_FOUND)
-      message(FATAL_ERROR "Eigen3 not found, help CMake to find it by setting EIGEN3_INCLUDE_DIR, or set DOWNLOAD_Eigen3=ON to download it")
+      message(FATAL_ERROR "Eigen3 not found, help CMake to find it by setting EIGEN3_INCLUDE_DIR, or set DOWNLOAD_EIGEN3=ON to download it")
    endif()
  endif()
  include_directories(${EIGEN3_INCLUDE_DIR})
@ -499,12 +536,13 @@ include(CheckLibraryExists)
 if (CMAKE_VERSION VERSION_LESS "3.4")
  enable_language(C) # check_library_exists isn't supported without a c compiler before v3.4
 endif()
-foreach(FUNC sin cos)
+# RB: disabled this check because it breaks with KOKKOS CUDA enabled
-  check_library_exists(${MATH_LIBRARIES} ${FUNC} "" FOUND_${FUNC}_${MATH_LIBRARIES})
+#foreach(FUNC sin cos)
-  if(NOT FOUND_${FUNC}_${MATH_LIBRARIES})
+#  check_library_exists(${MATH_LIBRARIES} ${FUNC} "" FOUND_${FUNC}_${MATH_LIBRARIES})
-    message(FATAL_ERROR "Could not find needed math function - ${FUNC}")
+#  if(NOT FOUND_${FUNC}_${MATH_LIBRARIES})
-  endif(NOT FOUND_${FUNC}_${MATH_LIBRARIES})
+#    message(FATAL_ERROR "Could not find needed math function - ${FUNC}")
-endforeach(FUNC)
+#  endif(NOT FOUND_${FUNC}_${MATH_LIBRARIES})
 #endforeach(FUNC)
 list(APPEND LAMMPS_LINK_LIBS ${MATH_LIBRARIES})
 ######################################
@ -729,33 +767,54 @@ if(PKG_OPT)
 endif()
 if(PKG_USER-INTEL)
-    if(NOT DEVELOPER_MODE)
+    find_package(TBB REQUIRED)
-      if(NOT CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
+    find_package(MKL REQUIRED)
-        message(FATAL_ERROR "USER-INTEL is only useful together with intel compiler")
+
-      endif()
+    if(NOT CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
-      if(CMAKE_CXX_COMPILER_VERSION VERSION_LESS 16)
+      message(FATAL_ERROR "USER-INTEL is only useful together with intel compiler")
    endif()
    if(CMAKE_CXX_COMPILER_VERSION VERSION_LESS 16)
        message(FATAL_ERROR "USER-INTEL is needed at least 2016 intel compiler, found ${CMAKE_CXX_COMPILER_VERSION}")
      endif()
    endif()
-    option(INJECT_KNL_FLAG "Inject flags for KNL build" OFF)
+
-    if(INJECT_KNL_FLAG)
+    if(NOT BUILD_OMP)
-      set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -xMIC-AVX512")
+        message(FATAL_ERROR "USER-INTEL requires OpenMP")
    endif()
-    option(INJECT_INTEL_FLAG "Inject OMG fast flags for USER-INTEL" ON)
+
-    if(INJECT_INTEL_FLAG AND CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
+    if(NOT ${LAMMPS_MEMALIGN} STREQUAL "64")
        message(FATAL_ERROR "USER-INTEL is only useful with LAMMPS_MEMALIGN=64")
    endif()
    set(INTEL_ARCH "cpu" CACHE STRING "Architectures used by USER-INTEL (cpu or knl)")
    set(INTEL_ARCH_VALUES cpu knl)
    set_property(CACHE INTEL_ARCH PROPERTY STRINGS ${INTEL_ARCH_VALUES})
    validate_option(INTEL_ARCH INTEL_ARCH_VALUES)
    if(INTEL_ARCH STREQUAL "knl")
      set(CMAKE_EXE_LINKER_FLAGS  "${CMAKE_EXE_LINKER_FLAGS} -xHost -qopenmp -qoffload")
      set(MIC_OPTIONS "-qoffload-option,mic,compiler,\"-fp-model fast=2 -mGLOB_default_function_attrs=\\\"gather_scatter_loop_unroll=4\\\"\"")
      add_compile_options(-xMIC-AVX512 -qoffload -fno-alias -ansi-alias -restrict -qoverride-limits ${MIC_OPTIONS})
      add_definitions(-DLMP_INTEL_OFFLOAD)
    else()
      if(CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.3 OR CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.4)
        set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -xCOMMON-AVX512")
      else()
        set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -xHost")
      endif()
      include(CheckCXXCompilerFlag)
-      foreach(_FLAG -qopenmp -qno-offload -fno-alias -ansi-alias -restrict -DLMP_INTEL_USELRT -DLMP_USE_MKL_RNG -O2 "-fp-model fast=2" -no-prec-div -qoverride-limits -qopt-zmm-usage=high)
+      foreach(_FLAG -O2 -fp-model fast=2 -no-prec-div -qoverride-limits -qopt-zmm-usage=high -qno-offload -fno-alias -ansi-alias -restrict)
        check_cxx_compiler_flag("${__FLAG}" COMPILER_SUPPORTS${_FLAG})
        if(COMPILER_SUPPORTS${_FLAG})
-          set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${_FLAG}")
+          add_compile_options(${_FLAG})
        endif()
      endforeach()
    endif()
    add_definitions(-DLMP_INTEL_USELRT -DLMP_USE_MKL_RNG)
    list(APPEND LAMMPS_LINK_LIBS ${TBB_MALLOC_LIBRARIES} ${MKL_LIBRARIES})
    set(USER-INTEL_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/USER-INTEL)
    set(USER-INTEL_SOURCES ${USER-INTEL_SOURCES_DIR}/intel_preprocess.h
                           ${USER-INTEL_SOURCES_DIR}/intel_buffers.h
@ -788,11 +847,25 @@ if(PKG_GPU)
                    ${GPU_SOURCES_DIR}/fix_gpu.h
                    ${GPU_SOURCES_DIR}/fix_gpu.cpp)
-    set(GPU_API "OpenCL" CACHE STRING "API used by GPU package")
+    set(GPU_API "opencl" CACHE STRING "API used by GPU package")
-    set_property(CACHE GPU_API PROPERTY STRINGS OpenCL CUDA)
+    set(GPU_API_VALUES opencl cuda)
    set_property(CACHE GPU_API PROPERTY STRINGS ${GPU_API_VALUES})
    validate_option(GPU_API GPU_API_VALUES)
    string(TOUPPER ${GPU_API} GPU_API)
-    set(GPU_PREC "SINGLE_DOUBLE" CACHE STRING "LAMMPS GPU precision size")
+    set(GPU_PREC "mixed" CACHE STRING "LAMMPS GPU precision")
-    set_property(CACHE GPU_PREC PROPERTY STRINGS SINGLE_DOUBLE SINGLE_SINGLE DOUBLE_DOUBLE)
+    set(GPU_PREC_VALUES double mixed single)
    set_property(CACHE GPU_PREC PROPERTY STRINGS ${GPU_PREC_VALUES})
    validate_option(GPU_PREC GPU_PREC_VALUES)
    string(TOUPPER ${GPU_PREC} GPU_PREC)
    if(GPU_PREC STREQUAL "DOUBLE")
      set(GPU_PREC_SETTING "DOUBLE_DOUBLE")
    elseif(GPU_PREC STREQUAL "MIXED")
      set(GPU_PREC_SETTING "SINGLE_DOUBLE")
    elseif(GPU_PREC STREQUAL "SINGLE")
      set(GPU_PREC_SETTING "SINGLE_SINGLE")
    endif()
    file(GLOB GPU_LIB_SOURCES ${LAMMPS_LIB_SOURCE_DIR}/gpu/*.cpp)
    file(MAKE_DIRECTORY ${LAMMPS_LIB_BINARY_DIR}/gpu)
@ -805,7 +878,7 @@ if(PKG_GPU)
      endif()
      option(CUDPP_OPT "Enable CUDPP_OPT" ON)
-      set(GPU_ARCH "sm_30" CACHE STRING "LAMMPS GPU CUDA SM architecture (e.g.  sm_60)")
+      set(GPU_ARCH "sm_30" CACHE STRING "LAMMPS GPU CUDA SM architecture (e.g. sm_60)")
      file(GLOB GPU_LIB_CU ${LAMMPS_LIB_SOURCE_DIR}/gpu/*.cu ${CMAKE_CURRENT_SOURCE_DIR}/gpu/*.cu)
      list(REMOVE_ITEM GPU_LIB_CU ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_pppm.cu)
@ -819,10 +892,10 @@ if(PKG_GPU)
      endif()
      cuda_compile_cubin(GPU_GEN_OBJS ${GPU_LIB_CU} OPTIONS
-                   -DUNIX -O3 -Xptxas -v --use_fast_math -DNV_KERNEL -DUCL_CUDADR -arch=${GPU_ARCH} -D_${GPU_PREC})
+                   -DUNIX -O3 -Xptxas -v --use_fast_math -DNV_KERNEL -DUCL_CUDADR -arch=${GPU_ARCH} -D_${GPU_PREC_SETTING})
      cuda_compile(GPU_OBJS ${GPU_LIB_CUDPP_CU} OPTIONS $<$<BOOL:${BUILD_SHARED_LIBS}>:-Xcompiler=-fPIC>
-                   -DUNIX -O3 -Xptxas -v --use_fast_math -DUCL_CUDADR -arch=${GPU_ARCH} -D_${GPU_PREC})
+                   -DUNIX -O3 -Xptxas -v --use_fast_math -DUCL_CUDADR -arch=${GPU_ARCH} -D_${GPU_PREC_SETTING})
      foreach(CU_OBJ ${GPU_GEN_OBJS})
        get_filename_component(CU_NAME ${CU_OBJ} NAME_WE)
@ -839,7 +912,7 @@ if(PKG_GPU)
      add_library(gpu STATIC ${GPU_LIB_SOURCES} ${GPU_LIB_CUDPP_SOURCES} ${GPU_OBJS})
      target_link_libraries(gpu ${CUDA_LIBRARIES} ${CUDA_CUDA_LIBRARY})
      target_include_directories(gpu PRIVATE ${LAMMPS_LIB_BINARY_DIR}/gpu ${CUDA_INCLUDE_DIRS})
-      target_compile_definitions(gpu PRIVATE -D_${GPU_PREC} -DMPI_GERYON -DUCL_NO_EXIT)
+      target_compile_definitions(gpu PRIVATE -D_${GPU_PREC_SETTING} -DMPI_GERYON -DUCL_NO_EXIT)
      if(CUDPP_OPT)
        target_include_directories(gpu PRIVATE ${LAMMPS_LIB_SOURCE_DIR}/gpu/cudpp_mini)
        target_compile_definitions(gpu PRIVATE -DUSE_CUDPP)
@ -853,10 +926,13 @@ if(PKG_GPU)
      target_include_directories(nvc_get_devices PRIVATE ${CUDA_INCLUDE_DIRS})
-    elseif(GPU_API STREQUAL "OpenCL")
+    elseif(GPU_API STREQUAL "OPENCL")
      find_package(OpenCL REQUIRED)
-      set(OCL_TUNE "GENERIC" CACHE STRING "OpenCL Device Tuning")
+      set(OCL_TUNE "generic" CACHE STRING "OpenCL Device Tuning")
-      set_property(CACHE OCL_TUNE PROPERTY STRINGS INTEL FERMI KEPLER CYPRESS GENERIC)
+      set(OCL_TUNE_VALUES intel fermi kepler cypress generic)
      set_property(CACHE OCL_TUNE PROPERTY STRINGS ${OCL_TUNE_VALUES})
      validate_option(OCL_TUNE OCL_TUNE_VALUES)
      string(TOUPPER ${OCL_TUNE} OCL_TUNE)
      include(OpenCLUtils)
      set(OCL_COMMON_HEADERS ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_preprocessor.h ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_aux_fun1.h)
@ -878,7 +954,7 @@ if(PKG_GPU)
      add_library(gpu STATIC ${GPU_LIB_SOURCES})
      target_link_libraries(gpu ${OpenCL_LIBRARIES})
      target_include_directories(gpu PRIVATE ${CMAKE_CURRENT_BINARY_DIR}/gpu ${OpenCL_INCLUDE_DIRS})
-      target_compile_definitions(gpu PRIVATE -D_${GPU_PREC} -D${OCL_TUNE}_OCL -DMPI_GERYON -DUCL_NO_EXIT)
+      target_compile_definitions(gpu PRIVATE -D_${GPU_PREC_SETTING} -D${OCL_TUNE}_OCL -DMPI_GERYON -DUCL_NO_EXIT)
      target_compile_definitions(gpu PRIVATE -DUSE_OPENCL)
      list(APPEND LAMMPS_LINK_LIBS gpu)
@ -1131,7 +1207,7 @@ if(PKG_GPU)
  message(STATUS "GPU Api: ${GPU_API}")
  if(GPU_API STREQUAL "CUDA")
    message(STATUS "GPU Arch: ${GPU_ARCH}")
-  elseif(GPU_API STREQUAL "OpenCL")
+  elseif(GPU_API STREQUAL "OPENCL")
    message(STATUS "OCL Tune: ${OCL_TUNE}")
  endif()
  message(STATUS "GPU Precision: ${GPU_PREC}")
--- a/cmake/Modules/FindQUIP.cmake
+++ b/cmake/Modules/FindQUIP.cmake
@ -1,8 +1,8 @@
 # - Find quip
 # Find the native QUIP libraries.
 #
-#  QUIP_LIBRARIES    - List of libraries when using fftw3.
+#  QUIP_LIBRARIES    - List of libraries of the QUIP package
-#  QUIP_FOUND        - True if fftw3 found.
+#  QUIP_FOUND        - True if QUIP library was found.
 #
 find_library(QUIP_LIBRARY NAMES quip)
--- a/cmake/Modules/FindTBB.cmake
+++ b/cmake/Modules/FindTBB.cmake
@ -0,0 +1,46 @@
 # - Find parts of TBB
 # Find the native TBB headers and libraries.
 #
 #  TBB_INCLUDE_DIRS - where to find tbb.h, etc.
 #  TBB_LIBRARIES    - List of libraries when using tbb.
 #  TBB_FOUND        - True if tbb found.
 #
 ########################################################
 # TBB
 # TODO use more generic FindTBB
 find_path(TBB_INCLUDE_DIR NAMES tbb/tbb.h PATHS $ENV{TBBROOT}/include)
 find_library(TBB_LIBRARY NAMES tbb PATHS $ENV{TBBROOT}/lib/intel64/gcc4.7
                                         $ENV{TBBROOT}/lib/intel64/gcc4.4
                                         $ENV{TBBROOT}/lib/intel64/gcc4.1)
 set(TBB_LIBRARIES ${TBB_LIBRARY})
 set(TBB_INCLUDE_DIRS ${TBB_INCLUDE_DIR})
 include(FindPackageHandleStandardArgs)
 # handle the QUIETLY and REQUIRED arguments and set TBB_FOUND to TRUE
 # if all listed variables are TRUE
 find_package_handle_standard_args(TBB DEFAULT_MSG TBB_LIBRARY TBB_INCLUDE_DIR)
 mark_as_advanced(TBB_INCLUDE_DIR TBB_LIBRARY )
 ########################################################
 # TBB Malloc
 find_path(TBB_MALLOC_INCLUDE_DIR NAMES tbb/tbb.h PATHS $ENV{TBBROOT}/include)
 find_library(TBB_MALLOC_LIBRARY NAMES tbbmalloc PATHS $ENV{TBBROOT}/lib/intel64/gcc4.7
                                                      $ENV{TBBROOT}/lib/intel64/gcc4.4
                                                      $ENV{TBBROOT}/lib/intel64/gcc4.1)
 set(TBB_MALLOC_LIBRARIES ${TBB_MALLOC_LIBRARY})
 set(TBB_MALLOC_INCLUDE_DIRS ${TBB_MALLOC_INCLUDE_DIR})
 include(FindPackageHandleStandardArgs)
 # handle the QUIETLY and REQUIRED arguments and set TBB_MALLOC_FOUND to TRUE
 # if all listed variables are TRUE
 find_package_handle_standard_args(TBB_MALLOC DEFAULT_MSG TBB_MALLOC_LIBRARY TBB_MALLOC_INCLUDE_DIR)
 mark_as_advanced(TBB_MALLOC_INCLUDE_DIR TBB_MALLOC_LIBRARY )
--- a/cmake/README.md
+++ b/cmake/README.md
@ -62,7 +62,7 @@ should get you started.
 git clone https://github.com/lammps/lammps.git
 mkdir lammps/build
 cd lammps/build
-cmake ../cmake [-DOPTION_A=VALUE_A -DOPTION_B=VALUE_B ...]
+cmake [-D OPTION_A=VALUE_A -D OPTION_B=VALUE_B ...] ../cmake
 make
 ```
@ -174,7 +174,7 @@ presets can be found in the `cmake/presets` folder.
 # build LAMMPS with all "standard" packages which don't use libraries and enable GPU package
 mkdir build
 cd build
-cmake -C ../cmake/presets/std_nolib.cmake ../cmake -DPKG_GPU=on
+cmake -C ../cmake/presets/std_nolib.cmake -D PKG_GPU=on ../cmake
 ```
 # Reference
@ -265,6 +265,16 @@ cmake -C ../cmake/presets/std_nolib.cmake ../cmake -DPKG_GPU=on
  </dl>
  </td>
 </tr>
 <tr>
  <td><code>BUILD_LIB</code></td>
  <td>control whether to build LAMMPS as a library</td>
  <td>
  <dl>
    <dt><code>off</code> (default)</dt>
    <dt><code>on</code></dt>
  </dl>
  </td>
 </tr>
 <tr>
  <td><code>BUILD_SHARED_LIBS</code></td>
  <td>control whether to build LAMMPS as a shared-library</td>
@ -315,8 +325,8 @@ cmake -C ../cmake/presets/std_nolib.cmake ../cmake -DPKG_GPU=on
  `mpicxx` in your path and use this MPI implementation.</td>
  <td>
  <dl>
-    <dt><code>off</code> (default)</dt>
+    <dt><code>on</code> (default, if found)</dt>
-    <dt><code>on</code></dt>
+    <dt><code>off</code></dt>
  </dl>
  </td>
 </tr>
@ -325,8 +335,8 @@ cmake -C ../cmake/presets/std_nolib.cmake ../cmake -DPKG_GPU=on
  <td>control whether to build LAMMPS with OpenMP support.</td>
  <td>
  <dl>
-    <dt><code>off</code> (default)</dt>
+    <dt><code>on</code> (default, if found)</dt>
-    <dt><code>on</code></dt>
+    <dt><code>off</code></dt>
  </dl>
  </td>
 </tr>
@ -1271,7 +1281,7 @@ providing the identical features and USER interface.</strong></p>
  </td>
  <td>
  <dl>
-    <dt><code>KISSFFT</code></dt>
+    <dt><code>KISS</code></dt>
    <dt><code>FFTW3</code></dt>
    <dt><code>FFTW2</code></dt>
    <dt><code>MKL</code></dt>
@ -1279,13 +1289,13 @@ providing the identical features and USER interface.</strong></p>
  </td>
 </tr>
 <tr>
-  <td><code>PACK_ARRAY</code></td>
+  <td><code>FFT_PACK</code></td>
  <td>Optimization for FFT</td>
  <td>
  <dl>
-    <dt><code>PACK_ARRAY</code></dt>
+    <dt><code>array (default)</code></dt>
-    <dt><code>PACK_POINTER</code></dt>
+    <dt><code>pointer</code></dt>
-    <dt><code>PACK_MEMCPY</code></dt>
+    <dt><code>memcpy</code></dt>
  </dl>
  </td>
 </tr>
@ -1377,6 +1387,29 @@ TODO
 ### PYTHON Package
 ### USER-INTEL Package
 <table>
 <thead>
 <tr>
  <th>Option</th>
  <th>Description</th>
  <th>Values</th>
 </tr>
 </thead>
 <tbody>
 <tr>
  <td><code>INTEL_ARCH</code></td>
  <td>Target architecture for USER-INTEL package</td>
  <td>
  <dl>
    <dt><code>cpu</code> (default)</dt>
    <dt><code>knl</code></dt>
  </dl>
  </td>
 </tr>
 </tbody>
 </table>
 ### GPU Package
 The GPU package builds a support library which can either use OpenCL or CUDA as
@ -1396,8 +1429,8 @@ target API.
  <td>API used by GPU package</td>
  <td>
  <dl>
-    <dt><code>OpenCL</code> (default)</dt>
+    <dt><code>opencl</code> (default)</dt>
-    <dt><code>CUDA</code></dt>
+    <dt><code>cuda</code></dt>
  </dl>
  </td>
 </tr>
@ -1406,9 +1439,9 @@ target API.
  <td>Precision size used by GPU package kernels</td>
  <td>
  <dl>
-    <dt><code>SINGLE_DOUBLE</code></dt>
+    <dt><code>mixed</code> (default)</dt>
-    <dt><code>SINGLE_SINGLE</code></dt>
+    <dt><code>single</code></dt>
-    <dt><code>DOUBLE_DOUBLE</code></dt>
+    <dt><code>double</code></dt>
  </dl>
  </td>
 </tr>
@ -1417,12 +1450,12 @@ target API.
  <td>Tuning target for OpenCL driver code</td>
  <td>
  <dl>
-    <dt><code>GENERIC</code> (default)</dt>
+    <dt><code>generic</code> (default)</dt>
-    <dt><code>INTEL</code> (Intel CPU)</dt>
+    <dt><code>intel</code> (Intel CPU)</dt>
-    <dt><code>PHI</code> (Intel Xeon Phi)</dt>
+    <dt><code>phi</code> (Intel Xeon Phi)</dt>
-    <dt><code>FERMI</code> (NVIDIA)</dt>
+    <dt><code>fermi</code> (NVIDIA)</dt>
-    <dt><code>KEPLER</code> (NVIDIA)</dt>
+    <dt><code>kepler</code> (NVIDIA)</dt>
-    <dt><code>CYPRESS</code> (AMD)</dt>
+    <dt><code>cypress</code> (AMD)</dt>
  </dl>
  </td>
 </tr>
@ -1517,6 +1550,16 @@ Requires a Eigen3 installation
 </tr>
 </thead>
 <tbody>
 <tr>
  <td><code>WITH_JPEG</code></td>
  <td>Enables/Disable JPEG support in LAMMPS</td>
  <td>
  <dl>
    <dt><code>yes</code> (default, if found)</dt>
    <dt><code>no</code></dt>
  </dl>
  </td>
 </tr>
 <tr>
  <td><code>JPEG_INCLUDE_DIR</code></td>
  <td></td>
@ -1544,6 +1587,16 @@ Requires a Eigen3 installation
 </tr>
 </thead>
 <tbody>
 <tr>
  <td><code>WITH_PNG</code></td>
  <td>Enables/Disable PNG support in LAMMPS</td>
  <td>
  <dl>
    <dt><code>yes</code> (default, if found)</dt>
    <dt><code>no</code></dt>
  </dl>
  </td>
 </tr>
 <tr>
  <td><code>PNG_INCLUDE_DIR</code></td>
  <td></td>
@ -1572,6 +1625,16 @@ requires `gzip` to be in your `PATH`
 </tr>
 </thead>
 <tbody>
 <tr>
  <td><code>WITH_GZIP</code></td>
  <td>Enables/Disable GZIP support in LAMMPS</td>
  <td>
  <dl>
    <dt><code>yes</code> (default, if found)</dt>
    <dt><code>no</code></dt>
  </dl>
  </td>
 </tr>
 <tr>
  <td><code>GZIP_EXECUTABLE</code></td>
  <td></td>
@ -1594,6 +1657,16 @@ requires `ffmpeg` to be in your `PATH`
 </tr>
 </thead>
 <tbody>
 <tr>
  <td><code>WITH_FFMPEG</code></td>
  <td>Enables/Disable FFMPEG support in LAMMPS</td>
  <td>
  <dl>
    <dt><code>yes</code> (default, if found)</dt>
    <dt><code>no</code></dt>
  </dl>
  </td>
 </tr>
 <tr>
  <td><code>FFMPEG_EXECUTABLE</code></td>
  <td></td>
@ -1606,8 +1679,13 @@ requires `ffmpeg` to be in your `PATH`
 ## Compilers
-By default, `cmake` will use your environment C/C++/Fortran compilers for a build. It uses the `CC`, `CXX` and `FC` environment variables to detect which compilers should be used. However, these values
+By default, `cmake` will use your environment C/C++/Fortran compilers for a
-will be cached after the first run of `cmake`. Subsequent runs of `cmake` will ignore changes in these environment variables. To ensure the correct values are used you avoid the cache by setting the `CMAKE_C_COMPILER`, `CMAKE_CXX_COMPILER`, `CMAKE_Fortran_COMPILER` options directly.
+build. It uses the `CC`, `CXX` and `FC` environment variables to detect which
 compilers should be used. However, these values will be cached after the first
 run of `cmake`. Subsequent runs of `cmake` will ignore changes in these
 environment variables. To ensure the correct values are used you avoid the
 cache by setting the `CMAKE_C_COMPILER`, `CMAKE_CXX_COMPILER`,
 `CMAKE_Fortran_COMPILER` options directly.
 <table>
 <thead>
@ -1643,20 +1721,20 @@ will be cached after the first run of `cmake`. Subsequent runs of `cmake` will i
 ### Building with GNU Compilers
 ```bash
-cmake ../cmake -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ -DCMAKE_Fortran_COMPILER=gfortran
+cmake -D CMAKE_C_COMPILER=gcc -D CMAKE_CXX_COMPILER=g++ -D CMAKE_Fortran_COMPILER=gfortran ../cmake
 ```
 ### Building with Intel Compilers
 ```bash
-cmake ../cmake -DCMAKE_C_COMPILER=icc -DCMAKE_CXX_COMPILER=icpc -DCMAKE_Fortran_COMPILER=ifort
+cmake -D CMAKE_C_COMPILER=icc -D CMAKE_CXX_COMPILER=icpc -D CMAKE_Fortran_COMPILER=ifort ../cmake
 ```
 ### Building with LLVM/Clang Compilers
 ```bash
-cmake ../cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_Fortran_COMPILER=flang
+cmake -D CMAKE_C_COMPILER=clang -D CMAKE_CXX_COMPILER=clang++ -D CMAKE_Fortran_COMPILER=flang ../cmake
 ```
--- a/doc/src/Build.txt
+++ b/doc/src/Build.txt
@ -0,0 +1,58 @@
 "Previous Section"_Install.html - "LAMMPS WWW Site"_lws - "LAMMPS
 Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Run.html :c
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
 :link(lc,Commands_all.html)
 :line
 Build LAMMPS :h2
 LAMMPS can be built as an executable or library from source code via
 either traditional makefiles (which may require manual editing)
 for use with GNU make or gmake, or a build environment generated by CMake
 (Unix Makefiles, Xcode, Visual Studio, KDevelop or more).  As an
 alternative you can download a package with pre-built executables
 as described on the "Install"_Install.html doc page.
 <!-- RST
 .. toctree::
   :maxdepth: 1
   Build_cmake
   Build_make
   Build_link
 .. toctree::
   :maxdepth: 1
   Build_basics
   Build_settings
   Build_package
 .. toctree::
   :maxdepth: 1
   Build_extras
 END_RST -->
 <!-- HTML_ONLY -->
 "Build LAMMPS with CMake"_Build_cmake.html
 "Build LAMMPS with make"_Build_make.html
 "Link LAMMPS as a library to another code"_Build_link.html :all(b)
 Build options:
 "Basic build options: serial/parallel, compilers, executable/library"_Build_basics.html
 "Optional build settings"_Build_settings.html :all(b)
 "Include packages in build"_Build_package.html
 "Packages with extra build options"_Build_extras.html :all(b)
 If you have problems building LAMMPS, it is often due to software
 issues on your local machine.  If you can, find a local expert to
 help.  If you're still stuck, send an email to the "LAMMPS mail
 list"_http://lammps.sandia.gov/mail.html.
--- a/doc/src/Build_basics.txt
+++ b/doc/src/Build_basics.txt
@ -0,0 +1,315 @@
 "Higher level section"_Build.html - "LAMMPS WWW Site"_lws - "LAMMPS
 Documentation"_ld - "LAMMPS Commands"_lc :c
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
 :link(lc,Commands_all.html)
 :line
 Basic build options :h3
 The following topics are covered on this page, for building both with
 CMake and make:
 "Serial vs parallel build"_#serial
 "Choice of compiler and compile/link options"_#compile
 "Build LAMMPS as an executable or a library"_#exe
 "Build the LAMMPS documentation"_#doc
 "Install LAMMPS after a build"_#install :ul
 :line
 Serial vs parallel build :h3,link(serial)
 LAMMPS can be built to run in parallel using the ubiquitous "MPI
 (message-passing
 interface)"_https://en.wikipedia.org/wiki/Message_Passing_Interface
 library.  Or it can built to run on a single processor (serial)
 without MPI.  It can also be built with support for OpenMP threading
 (see more discussion below).
 [CMake variables]:
 -D BUILD_MPI=value        # yes or no, default is yes if CMake finds MPI, else no
 -D BUILD_OMP=value        # yes or no (default)
 -D LAMMPS_MACHINE=name    # name = mpi, serial, mybox, titan, laptop, etc
                          # no default value :pre
 The executable created by CMake (after running make) is lmp_name.  If
 the LAMMPS_MACHINE variable is not specified, the executable is just
 lmp.  Using BUILD_MPI=no will produce a serial executable.
 [Traditional make]:
 cd lammps/src
 make mpi                # parallel build, produces lmp_mpi using Makefile.mpi
 make serial             # serial build, produces lmp_serial using Makefile/serial
 make mybox :pre         # uses Makefile.mybox to produce lmp_mybox :pre
 Serial build (see src/MAKE/Makefile.serial):
 MPI_INC =       -I../STUBS 
 MPI_PATH =      -L../STUBS
 MPI_LIB =	-lmpi_stubs :pre
 For a parallel build, if MPI is installed on your system in the usual
 place (e.g. under /usr/local), you do not need to specify the 3
 variables MPI_INC, MPI_PATH, MPI_LIB.  The MPI wrapper on the compiler
 (e.g. mpicxx, mpiCC) knows where to find the needed include and
 library files.  Failing this, these 3 variables can be used to specify
 where the mpi.h file (MPI_INC), and the MPI library files (MPI_PATH)
 are found, and the name of the library files (MPI_LIB).
 For a serial build, you need to specify the 3 varaibles, as shown
 above.
 For a serial LAMMPS build, use the dummy MPI library provided in
 src/STUBS.  You also need to build the STUBS library for your platform
 before making LAMMPS itself.  A "make serial" build does this for.
 Otherwise, type "make mpi-stubs" from the src directory, or "make"
 from the src/STUBS dir.  If the build fails, you will need to edit the
 STUBS/Makefile for your platform.
 The file STUBS/mpi.c provides a CPU timer function called MPI_Wtime()
 that calls gettimeofday() .  If your system doesn't support
 gettimeofday() , you'll need to insert code to call another timer.
 Note that the ANSI-standard function clock() rolls over after an hour
 or so, and is therefore insufficient for timing long LAMMPS
 simulations.
 [CMake and make info]:
 If you are installing MPI yourself, we recommend MPICH2 from Argonne
 National Laboratory or OpenMPI.  MPICH can be downloaded from the
 "Argonne MPI site"_http://www.mcs.anl.gov/research/projects/mpich2/.
 OpenMPI can be downloaded from the "OpenMPI
 site"_http://www.open-mpi.org.  Other MPI packages should also work.
 If you are running on a large parallel machine, your system admins or
 the vendor should have already installed a version of MPI, which is
 likely to be faster than a self-installed MPICH or OpenMPI, so find
 out how to build and link with it.
 The majority of OpenMP (threading) support in LAMMPS is provided by
 the USER-OMP package; see the "Speed omp"_Speed_omp.html doc page for
 details. The USER-INTEL package also provides OpenMP support (it is
 compatible with USER-OMP) and adds vectorization support when compiled
 with the Intel compilers on top of that. Also, the KOKKOS package can
 be compiled for using OpenMP threading.
 However, there are a few commands in LAMMPS that have native OpenMP
 support.  These are commands in the MPIIO, SNAP, USER-DIFFRACTION, and
 USER-DPD packages.  In addition some packages support OpenMP threading
 indirectly through the libraries they interface to: e.g. LATTE and
 USER-COLVARS.  See the "Packages details"_Packages_details.html doc
 page for more info on these packages and the doc pages for their
 respective commands for OpenMP threading info.
 For CMake, if you use BUILD_OMP=yes, you can use these packages and
 turn on their native OpenMP support and turn on their native OpenMP
 support at run time, by setting the OMP_NUM_THREADS environment
 variable before you launch LAMMPS.
 For building via conventional make, the CCFLAGS and LINKFLAGS
 variables in Makefile.machine need to include the compiler flag that
 enables OpenMP. For GNU compilers it is -fopenmp.  For (recent) Intel
 compilers it is -qopenmp.  If you are using a different compiler,
 please refer to its documentation.
 :line
 Choice of compiler and compile/link options :h3,link(compile)
 The choice of compiler and compiler flags can be important for
 performance.  Vendor compilers can produce faster code than
 open-source compilers like GNU.  On boxes with Intel CPUs, we suggest
 trying the "Intel C++ compiler"_intel.
 :link(intel,https://software.intel.com/en-us/intel-compilers)
 On parallel clusters or supercomputers which use "modules" for their
 compile/link environments, you can often access different compilers by
 simply loading the appropriate module before building LAMMPS.
 [CMake variables]:
 -D CMAKE_CXX_COMPILER=name            # name of C++ compiler
 -D CMAKE_C_COMPILER=name              # name of C compiler
 -D CMAKE_Fortran_COMPILER=name        # name of Fortran compiler :pre
 -D CMAKE_CXX_FlAGS=string             # flags to use with C++ compiler
 -D CMAKE_C_FlAGS=string               # flags to use with C compiler
 -D CMAKE_Fortran_FlAGS=string         # flags to use with Fortran compiler :pre
 By default CMake will use a compiler it finds and it will add
 optimization flags appropriate to that compiler and any "accelerator
 packages"_Speed_packages.html you have included in the build.
 You can tell CMake to look for a specific compiler with these varaible
 settings.  Likewise you can specify the FLAGS variables if you want to
 experiment with alternate optimization flags.  You should specify all
 3 compilers, so that the small number of LAMMPS source files written
 in C or Fortran are built with a compiler consistent with the one used
 for all the C++ files:
 Building with GNU Compilers:
 cmake ../cmake -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ -DCMAKE_Fortran_COMPILER=gfortran
 Building with Intel Compilers:
 cmake ../cmake -DCMAKE_C_COMPILER=icc -DCMAKE_CXX_COMPILER=icpc -DCMAKE_Fortran_COMPILER=ifort
 Building with LLVM/Clang Compilers:
 cmake ../cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_Fortran_COMPILER=flang :pre
 NOTE: When the cmake command completes, it prints info to the screen
 as to which compilers it is using, and what flags will be used in the
 compilation.  Note that if the top-level compiler is mpicxx, it is
 simply a wrapper on a real compiler.  The underlying compiler info is
 what will be listed in the CMake output.  You should check to insure
 you are using the compiler and optimization flags are the ones you
 want.
 [Makefile.machine settings]:
 Parallel build (see src/MAKE/Makefile.mpi):
 CC =		mpicxx
 CCFLAGS =	-g -O3 
 LINK =		mpicxx
 LINKFLAGS =	-g -O :pre
 Serial build (see src/MAKE/Makefile.serial):
 CC =		g++
 CCFLAGS =	-g -O3
 LINK =		g++
 LINKFLAGS =	-g -O :pre
 The "compiler/linker settings" section of a Makefile.machine lists
 compiler and linker settings for your C++ compiler, including
 optimization flags.  You should always use mpicxx or mpiCC for
 a parallel build, since these compiler wrappers will include
 a variety of settings appropriate for your MPI installation.
 NOTE: If you build LAMMPS with any "accelerator
 packages"_Speed_packages.html included, they have specific
 optimization flags that are either required or recommended for optimal
 performance.  You need to include these in the CCFLAGS and LINKFLAGS
 settings above.  For details, see the individual package doc pages
 listed on the "Speed packages"_Speed_packages.html doc page.  Or
 examine these files in the src/MAKE/OPTIONS directory.  They
 correspond to each of the 5 accelerator packages and their hardware
 variants:
 Makefile.opt                   # OPT package
 Makefile.omp                   # USER-OMP package
 Makefile.intel_cpu             # USER-INTEL package for CPUs
 Makefile.intel_coprocessor     # USER-INTEL package for KNLs
 Makefile.gpu                   # GPU package
 Makefile.kokkos_cuda_mpi       # KOKKOS package for GPUs
 Makefile.kokkos_omp            # KOKKOS package for CPUs (OpenMP)
 Makefile.kokkos_phi            # KOKKOS package for KNLs (OpenMP) :pre
 :line
 Build LAMMPS as an executable or a library :h3,link(exe)
 LAMMPS can be built as either an executable or as a static or shared
 library.  The LAMMPS library can be called from another application or
 a scripting language.  See the "Howto couple"_Howto_couple.html doc
 page for more info on coupling LAMMPS to other codes.  See the
 "Python"_Python doc page for more info on wrapping and running LAMMPS
 from Python via its library interface.
 [CMake variables]:
 -D BUILD_EXE=value           # yes (default) or no
 -D BUILD_LIB=value           # yes or no (default)
 -D BUILD_SHARED_LIBS=value   # yes or no (default) :pre
 Setting BUILD_EXE=no will not produce an executable.  Setting
 BUILD_LIB=yes will produce a static library named liblammps.a.
 Setting both BUILD_LIB=yes and BUILD_SHARED_LIBS=yes will produce a
 shared library named liblammps.so.
 [Traditional make]:
 cd lammps/src
 make machine               # build LAMMPS executable lmp_machine
 make mode=lib machine      # build LAMMPS static lib liblammps_machine.a
 make mode=shlib machine    # build LAMMPS shared lib liblammps_machine.so :pre
 The two library builds also create generic soft links, named
 liblammps.a and liblammps.so, which point to the liblammps_machine
 files.
 [CMake and make info]:
 Note that for a shared library to be usable by a calling program, all
 the auxiliary libraries it depends on must also exist as shared
 libraries.  This will be the case for libraries included with LAMMPS,
 such as the dummy MPI library in src/STUBS or any package libraries in
 the lib/packages directroy, since they are always built as shared
 libraries using the -fPIC switch.  However, if a library like MPI or
 FFTW does not exist as a shared library, the shared library build will
 generate an error.  This means you will need to install a shared
 library version of the auxiliary library.  The build instructions for
 the library should tell you how to do this.
 As an example, here is how to build and install the "MPICH
 library"_mpich, a popular open-source version of MPI, distributed by
 Argonne National Lab, as a shared library in the default
 /usr/local/lib location:
 :link(mpich,http://www-unix.mcs.anl.gov/mpi)
 ./configure --enable-shared
 make
 make install :pre
 You may need to use "sudo make install" in place of the last line if
 you do not have write privileges for /usr/local/lib.  The end result
 should be the file /usr/local/lib/libmpich.so.
 :line
 Build the LAMMPS documentation :h3,link(doc)
 [CMake variable]:
 -D BUILD_DOC=value       # yes or no (default) :pre
 This will create the HTML doc pages within the CMake build directory.
 The reason to do this is if you want to "install" LAMMPS on a system
 after the CMake build via "make install", and include the doc pages in
 the install.
 [Traditional make]:
 cd lammps/doc
 make html       # html doc pages
 make pdf        # single Manual.pdf file :pre
 This will create a lammps/doc/html dir with the HTML doc pages so that
 you can browse them locally on your system.  Type "make" from the
 lammps/doc dir to see other options.
 :line
 Install LAMMPS after a build :h3,link(install)
 After building LAMMPS, you may wish to copy the LAMMPS executable of
 library, along with other LAMMPS files (library header, doc files) to
 a globally visible place on your system, for others to access.  Note
 that you may need super-user priveleges (e.g. sudo) if the directory
 you want to copy files to is protected.
 [CMake variable]:
 cmake -D CMAKE_INSTALL_PREFIX=path \[options ...\] ../cmake
 make                        # perform make after CMake command
 make install                # perform the installation into prefix :pre
 [Traditional make]:
 There is no "install" option in the src/Makefile for LAMMPS.  If you
 wish to do this you will need to first build LAMMPS, then manually
 copy the desired LAMMPS files to the appropriate system directories.
--- a/doc/src/Build_cmake.txt
+++ b/doc/src/Build_cmake.txt
@ -0,0 +1,197 @@
 "Higher level section"_Build.html - "LAMMPS WWW Site"_lws - "LAMMPS
 Documentation"_ld - "LAMMPS Commands"_lc :c
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
 :link(lc,Commands_all.html)
 :line
 Build LAMMPS with CMake :h3
 This page is a short summary of how to use CMake to build LAMMPS.
 Details on CMake variables that enable specific LAMMPS build options
 are given on the pages linked to from the "Build"_Build.html doc page.
 Richard Berger (Temple U) has also written a more comprehensive guide
 for how to use CMake to build LAMMPS.  If you are new to CMake it is a
 good place to start:
 "Bulding LAMMPS using
 CMake"_https://github.com/lammps/lammps/blob/master/cmake/README.md
 :line
 Building LAMMPS with CMake is a two-step process.  First you use CMake
 to create a build environment in a new directory.  On Linux systems,
 this will be based on makefiles for use with make.  Then you use the
 make command to build LAMMPS, which uses the created
 Makefile(s). Example:
 cd lammps                        # change to the LAMMPS distribution directory
 mkdir build; cd build            # create a new directory (folder) for build       
 cmake ../cmake \[options ...\]   # configuration with (command-line) cmake
 make                             # compilation :pre
 The cmake command will detect available features, enable selected
 packages and options, and will generate the build environment.  The make
 command will then compile and link LAMMPS, producing (by default) an
 executable called "lmp" and a library called "liblammps.a" in the
 "build" folder.
 If your machine has multiple CPU cores (most do these days), using a
 command like "make -jN" (with N being the number of available local
 CPU cores) can be much faster.  If you plan to do development on
 LAMMPS or need to recompile LAMMPS repeatedly, installation of the
 ccache (= Compiler Cache) software may speed up compilation even more.
 After compilation, you can optionally copy the LAMMPS executable and
 library into your system folders (by default under /usr/local) with:
 make install    # optional, copy LAMMPS executable & library elsewhere :pre
 :line
 There are 3 variants of CMake: a command-line verison (cmake), a text mode
 UI version (ccmake), and a graphical GUI version (cmake-GUI).  You can use
 any of them interchangeably to configure and create the LAMMPS build
 environment.  On Linux all the versions produce a Makefile as their
 output.  See more details on each below.
 You can specify a variety of options with any of the 3 versions, which
 affect how the build is performed and what is included in the LAMMPS
 executable.  Links to pages explaining all the options are listed on
 the "Build"_Build.html doc page.
 You must perform the CMake build system generation and compilation in
 a new directory you create.  It can be anywhere on your local machine.
 In these Build pages we assume that you are building in a directory
 called "lammps/build".  You can perform separate builds independently
 with different options, so long as you perform each of them in a
 separate directory you create.  All the auxiliary files created by one
 build process (executable, object files, log files, etc) are stored in
 this directory or sub-directories within it that CMake creates.
 NOTE: To perform a CMake build, no packages can be installed or a
 build been previously attempted in the LAMMPS src directory by using
 "make" commands to "perform a conventional LAMMPS
 build"_Build_make.html.  CMake detects if this is the case and
 generates an error, telling you to type "make no-all purge" in the src
 directory to un-install all packages.  The purge removes all the *.h
 files auto-generated by make.
 You must have CMake version 2.8 or later on your system to build
 LAMMPS.  If you include the GPU or KOKKOS packages, CMake version 3.2
 or later is required.  Installation instructions for CMake are below.
 After the initial build, if you edit LAMMPS source files, or add your
 own new files to the source directory, you can just re-type make from
 your build directory and it will re-compile only the files that have
 changed.  If you want to change CMake options you can run cmake (or
 ccmake or cmake-gui) again from the same build directory and alter
 various options; see details below.  Or you can remove the entire build
 folder, recreate the directory and start over.
 :line
 [Command-line version of CMake]:
 cmake \[options ...\] /path/to/lammps/cmake  # build from any dir
 cmake \[options ...\] ../cmake               # build from lammps/build :pre
 The cmake command takes one required argument, which is the LAMMPS
 cmake directory which contains the CMakeLists.txt file.
 The argument can be preceeded or followed by various CMake
 command-line options.  Several useful ones are:
 -D CMAKE_INSTALL_PREFIX=path  # where to install LAMMPS executable/lib if desired
 -D CMAKE_BUILD_TYPE=type      # type = Release or Debug
 -G output                     # style of output CMake generates
 -DVARIABLE=value              # setting for a LAMMPS feature to enable
 -D VARIABLE=value             # ditto, but cannot come after CMakeLists.txt dir :pre
 All the LAMMPS-specific -D variables that a LAMMPS build supports are
 described on the pages linked to from the "Build"_Build.html doc page.
 All of these variable names are upper-case and their values are
 lower-case, e.g. -D LAMMPS_SIZES=smallbig.  For boolean values, any of
 these forms can be used: yes/no, on/off, 1/0.
 On Unix/Linux machines, CMake generates a Makefile by default to
 perform the LAMMPS build.  Alternate forms of build info can be
 generated via the -G switch, e.g. Visual Studio on a Windows machine,
 Xcode on MacOS, or KDevelop on Linux.  Type "cmake --help" to see the
 "Generator" styles of output your system supports.
 NOTE: When CMake runs, it prints configuration info to the screen.
 You should review this to verify all the features you requested were
 enabled, including packages.  You can also see what compilers and
 compile options will be used for the build.  Any errors in CMake
 variable syntax will also be flagged, e.g. mis-typed variable names or
 variable values.
 CMake creates a CMakeCache.txt file when it runs.  This stores all the
 settings, so that when running CMake again you can use the current
 folder '.' instead of the path to the LAMMPS cmake folder as the
 required argument to the CMake command. Either way the existing
 settings will be inherited unless the CMakeCache.txt file is removed.
 If you later want to change a setting you can rerun cmake in the build
 directory with different setting. Please note that some automatically
 detected variables will not change their value when you rerun cmake.
 In these cases it is usually better to first remove all the
 files/directories in the build directory, or start with a fresh build
 directory.
 :line
 [Curses version (terminal-style menu) of CMake]:
 ccmake ../cmake :pre
 You initiate the configuration and build environment generation steps
 separately. For the first you have to type [c], for the second you
 have to type [g]. You may need to type [c] multiple times, and may be
 required to edit some of the entries of CMake configuration variables
 in between.  Please see the "ccmake
 manual"_https://cmake.org/cmake/help/latest/manual/ccmake.1.html for
 more information.
 :line
 [GUI version of CMake]:
 cmake-gui ../cmake :pre
 You initiate the configuration and build environment generation steps
 separately. For the first you have to click on the [Configure] button,
 for the second you have to click on the [Generate] button.  You may
 need to click on [Configure] multiple times, and may be required to
 edit some of the entries of CMake configuration variables in between.
 Please see the "cmake-gui
 manual"_https://cmake.org/cmake/help/latest/manual/cmake-gui.1.html
 for more information.
 :line
 [Installing CMake]
 Check if your machine already has CMake installed:
 which cmake             # do you have it?
 which cmake3            # version 3 may have this name
 cmake --version         # what specific version you have :pre
 On clusters or supercomputers which use environment modules to manage
 software packages, do this:
 module list            # is a cmake module already loaded?
 module avail           # is a cmake module available?
 module load cmake3     # load cmake module with appropriate name :pre
 Most Linux distributions offer precompiled cmake packages through
 their package management system. If you do not have CMake or a new
 enough version, you can download the latest version at
 "https://cmake.org/download/"_https://cmake.org/download/.
 Instructions on how to install it on various platforms can be found
 "on this page"_https://cmake.org/install/.
--- a/doc/src/Build_extras.txt
+++ b/doc/src/Build_extras.txt
@ -0,0 +1,923 @@
 "Higher level section"_Build.html - "LAMMPS WWW Site"_lws - "LAMMPS
 Documentation"_ld - "LAMMPS Commands"_lc :c
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
 :link(lc,Commands_all.html)
 :line
 Packages with extra build options :h3
 When building with some packages, additional steps may be required,
 in addition to:
 -D PKG_NAME=yes    # CMake
 make yes-name      # make :pre
 as described on the "Build_package"_Build_package.html doc page.
 For a CMake build there may be additional optional or required
 variables to set.  For a build with make, a provided library under the
 lammps/lib directory may need to be built first.  Or an external
 library may need to exist on your system or be downloaded and built.
 You may need to tell LAMMPS where it is found on your system.
 This is the list of packages that may require additional steps.
 "GPU"_#gpu,
 "KIM"_#kim,
 "KOKKOS"_#kokkos,
 "LATTE"_#latte,
 "MEAM"_#meam,
 "MSCG"_#mscg,
 "OPT"_#opt,
 "POEMS"_#poems,
 "PYTHON"_#python,
 "REAX"_#reax,
 "VORONOI"_#voronoi,
 "USER-ATC"_#user-atc,
 "USER-AWPMD"_#user-awpmd,
 "USER-COLVARS"_#user-colvars,
 "USER-H5MD"_#user-h5md,
 "USER-INTEL"_#user-intel,
 "USER-MOLFILE"_#user-molfile,
 "USER-NETCDF"_#user-netcdf,
 "USER-OMP"_#user-omp,
 "USER-QMMM"_#user-qmmm,
 "USER-QUIP"_#user-quip,
 "USER-SMD"_#user-smd,
 "USER-VTK"_#user-vtk :tb(c=6,ea=c)
 :line
 COMPRESS package :h4,link(compress)
 To build with this package you must have the zlib compression library
 available on your system.
 [CMake build]:
 If CMake cannot find the library, you can set these variables:
 -D ZLIB_INCLUDE_DIR=path    # path to zlib.h header file 
 -D ZLIB_LIBRARIES=path      # path to libz.a (.so) file :pre
 [Traditional make]:
 If make cannot find the library, you can edit the
 lib/compress/Makefile.lammps file to specify the paths and library
 name.
 :line
 GPU package :h4,link(gpu)
 To build with this package, you must choose options for precision and
 which GPU hardware to build for.
 [CMake build]:
 -D GPU_API=value      # value = opencl (default) or cuda
 -D GPU_PREC=value     # precision setting
                      # value = double or mixed (default) or single
 -D OCL_TUNE=value     # hardware choice for GPU_API=opencl
                      # generic (default) or intel (Intel CPU) or fermi, kepler, cypress (NVIDIA)
 -D GPU_ARCH=value     # hardware choice for GPU_API=cuda
                      # value = sm_XX, see below
                      # default is Cuda-compiler dependent, but typically sm_20
 -D CUDPP_OPT=value    # optimization setting for GPU_API=cudea
                      # enables CUDA Performance Primitives Optimizations
                      # yes (default) or no :pre
 GPU_ARCH settings for different GPU hardware is as follows:
 sm_20 for Fermi (C2050/C2070, deprecated as of CUDA 8.0) or GeForce GTX 580 or similar
 sm_30 for Kepler (K10)
 sm_35 for Kepler (K40) or GeForce GTX Titan or similar
 sm_37 for Kepler (dual K80)
 sm_50 for Maxwell
 sm_60 for Pascal (P100)
 sm_70 for Volta :ul
 [Traditional make]:
 Before building LAMMPS, you must build the GPU library in lib/gpu.
 You can do this manually if you prefer; follow the instructions in
 lib/gpu/README.  Note that the GPU library uses MPI calls, so you must
 use the same MPI library (or the STUBS library) settings as the main
 LAMMPS code.  This also applies to the -DLAMMPS_BIGBIG,
 -DLAMMPS_SMALLBIG, or -DLAMMPS_SMALLSMALL settings in whichever
 Makefile you use.
 You can also build the library in one step from the lammps/src dir,
 using a command like these, which simply invoke the lib/gpu/Install.py
 script with the specified args:
 make lib-gpu               # print help message
 make lib-gpu args="-b"     # build GPU library with default Makefile.linux
 make lib-gpu args="-m xk7 -p single -o xk7.single"  # create new Makefile.xk7.single, altered for single-precision
 make lib-gpu args="-m mpi -a sm_60 -p mixed -b" # build GPU library with mixed precision and P100 using other settings in Makefile.mpi :pre
 Note that this procedure starts with a Makefile.machine in lib/gpu, as
 specified by the "-m" switch.  For your convenience, machine makefiles
 for "mpi" and "serial" are provided, which have the same settings as
 the corresponding machine makefiles in the main LAMMPS source
 folder. In addition you can alter 4 important settings in the
 Makefile.machine you start from via the corresponding -h, -a, -p, -e
 switches (as in the examples above), and also save a copy of the new
 Makefile if desired:
 CUDA_HOME = where NVIDIA CUDA software is installed on your system
 CUDA_ARCH = sm_XX, what GPU hardware you have, same as CMake GPU_ARCH above
 CUDA_PRECISION = precision (double, mixed, single)
 EXTRAMAKE = which Makefile.lammps.* file to copy to Makefile.lammps :ul
 If the library build is successful, 3 files should be created:
 lib/gpu/libgpu.a, lib/gpu/nvc_get_devices, and
 lib/gpu/Makefile.lammps.  The latter has settings that enable LAMMPS
 to link with CUDA libraries.  If the settings in Makefile.lammps for
 your machine are not correct, the LAMMPS build will fail, and
 lib/gpu/Makefile.lammps may need to be edited.
 NOTE: If you re-build the GPU library in lib/gpu, you should always
 un-install the GPU package in lammps/src, then re-install it and
 re-build LAMMPS.  This is because the compilation of files in the GPU
 package uses the library settings from the lib/gpu/Makefile.machine
 used to build the GPU library.
 :line
 KIM package :h4,link(kim)
 To build with this package, the KIM library must be downloaded and
 built on your system.  It must include the KIM models that you want to
 use with LAMMPS.
 Note that in LAMMPS lingo, a KIM model driver is a pair style
 (e.g. EAM or Tersoff).  A KIM model is a pair style for a particular
 element or alloy and set of parameters, e.g. EAM for Cu with a
 specific EAM potential file.  Also note that installing the KIM API
 library with all its models, may take around 30 min to build.  Of
 course you only need to do that once.
 See the list of KIM model drivers here:
 https://openkim.org/kim-items/model-drivers/alphabetical
 See the list of all KIM models here:
 https://openkim.org/kim-items/models/by-model-drivers
 See the list of example KIM models included by default here:
 https://openkim.org/kim-api on the "What is in the KIM API source
 package?" page.
 [CMake build]:
 -D DOWNLOAD_KIM=value    # download OpenKIM API v1 for build, value = no (default) or yes
 -D KIM_LIBRARY=path      # path to KIM shared library (only needed if a custom location) 
 -D KIM_INCLUDE_DIR=path  # path to KIM include directory (only needed if a custom location) :pre
 [Traditional make]:
 You can download and build the KIM library manually if you prefer;
 follow the instructions in lib/kim/README.  You can also do it in one
 step from the lammps/src dir, using a command like these, which simply
 invoke the lib/kim/Install.py script with the specified args.
 make lib-kim              # print help message
 make lib-kim args="-b "   # (re-)install KIM API lib with only example models
 make lib-kim args="-b -a Glue_Ercolessi_Adams_Al__MO_324507536345_001"  # ditto plus one model
 make lib-kim args="-b -a everything"     # install KIM API lib with all models
 make lib-kim args="-n -a EAM_Dynamo_Ackland_W__MO_141627196590_002"       # add one model or model driver
 make lib-kim args="-p /usr/local/kim-api" # use an existing KIM API installation at the provided location
 make lib-kim args="-p /usr/local/kim-api -a EAM_Dynamo_Ackland_W__MO_141627196590_002" # ditto but add one model or driver :pre
 :line
 KOKKOS package :h4,link(kokkos)
 To build with this package, you must choose which hardware you want to
 build for, either CPUs (multi-threading via OpenMP) or KNLs (OpenMP)
 or GPUs (NVIDIA Cuda).
 For a CMake or make build, these are the possible choices for the
 KOKKOS_ARCH settings described below.  Note that for CMake, these are
 really Kokkos variables, not LAMMPS variables.  Hence you must use
 case-sensitive values, e.g. BDW, not bdw.
 ARMv80 = ARMv8.0 Compatible CPU
 ARMv81 = ARMv8.1 Compatible CPU
 ARMv8-ThunderX = ARMv8 Cavium ThunderX CPU
 BGQ = IBM Blue Gene/Q CPUs
 Power8 = IBM POWER8 CPUs
 Power9 = IBM POWER9 CPUs
 SNB = Intel Sandy/Ivy Bridge CPUs
 HSW = Intel Haswell CPUs
 BDW = Intel Broadwell Xeon E-class CPUs
 SKX = Intel Sky Lake Xeon E-class HPC CPUs (AVX512)
 KNC = Intel Knights Corner Xeon Phi
 KNL = Intel Knights Landing Xeon Phi
 Kepler30 = NVIDIA Kepler generation CC 3.0
 Kepler32 = NVIDIA Kepler generation CC 3.2
 Kepler35 = NVIDIA Kepler generation CC 3.5
 Kepler37 = NVIDIA Kepler generation CC 3.7
 Maxwell50 = NVIDIA Maxwell generation CC 5.0
 Maxwell52 = NVIDIA Maxwell generation CC 5.2
 Maxwell53 = NVIDIA Maxwell generation CC 5.3
 Pascal60 = NVIDIA Pascal generation CC 6.0
 Pascal61 = NVIDIA Pascal generation CC 6.1 :ul
 [CMake build]:
 For multicore CPUs using OpenMP, set these 2 variables.
 -D KOKKOS_ARCH=archCPU         # archCPU = CPU from list above :pre
 -D KOKKOS_ENABLE_OPENMP=yes :pre
 For Intel KNLs using OpenMP, set these 2 variables:
 -D KOKKOS_ARCH=KNL
 -D KOKKOS_ENABLE_OPENMP=yes :pre
 For NVIDIA GPUs using CUDA, set these 4 variables:
 -D KOKKOS_ARCH="archCPU;archGPU"   # archCPU = CPU from list above that is hosting the GPU
                                   # archGPU = GPU from list above
 -D KOKKOS_ENABLE_CUDA=yes
 -D KOKKOS_ENABLE_OPENMP=yes 
 -D CMAKE_CXX_COMPILER=wrapper      # wrapper = full path to Cuda nvcc wrapper :pre
 The wrapper value is the Cuda nvcc compiler wrapper provided in the
 Kokkos library: lib/kokkos/bin/nvcc_wrapper.  The setting should
 include the full path name to the wrapper, e.g.
 -D CMAKE_CXX_COMPILER=/home/username/lammps/lib/kokkos/bin/nvcc_wrapper :pre
 [Traditional make]:
 Choose which hardware to support in Makefile.machine via
 KOKKOS_DEVICES and KOKKOS_ARCH settings.  See the
 src/MAKE/OPTIONS/Makefile.kokkos* files for examples.
 For multicore CPUs using OpenMP:
 KOKKOS_DEVICES = OpenMP
 KOKKOS_ARCH = archCPU      # archCPU = CPU from list above :pre
 For Intel KNLs using OpenMP:
 KOKKOS_DEVICES = OpenMP
 KOKKOS_ARCH = KNL :pre
 For NVIDIA GPUs using CUDA:
 KOKKOS_DEVICES = Cuda
 KOKKOS_ARCH = archCPU,archGPU    # archCPU = CPU from list above that is hosting the GPU
                                 # archGPU = GPU from list above :pre
 For GPUs, you also need these 2 lines in your Makefile.machine before
 the CC line is defined, in this case for use with OpenMPI mpicxx.  The
 2 lines define a nvcc wrapper compiler, which will use nvcc for
 compiling CUDA files and use a C++ compiler for non-Kokkos, non-CUDA
 files.
 KOKKOS_ABSOLUTE_PATH = $(shell cd $(KOKKOS_PATH); pwd)
 export OMPI_CXX = $(KOKKOS_ABSOLUTE_PATH)/config/nvcc_wrapper
 CC =		mpicxx :pre
 :line
 LATTE package :h4,link(latte)
 To build with this package, you must download and build the LATTE
 library.
 [CMake build]:
 -D DOWNLOAD_LATTE=value    # download LATTE for build, value = no (default) or yes
 -D LATTE_LIBRARY=path      # path to LATTE shared library (only needed if a custom location) :pre
 [Traditional make]:
 You can download and build the LATTE library manually if you prefer;
 follow the instructions in lib/latte/README.  You can also do it in
 one step from the lammps/src dir, using a command like these, which
 simply invokes the lib/latte/Install.py script with the specified
 args:
 make lib-latte                          # print help message
 make lib-latte args="-b"                # download and build in lib/latte/LATTE-master
 make lib-latte args="-p $HOME/latte"    # use existing LATTE installation in $HOME/latte
 make lib-latte args="-b -m gfortran"    # download and build in lib/latte and 
                                        #   copy Makefile.lammps.gfortran to Makefile.lammps
 :pre
 Note that 3 symbolic (soft) links, "includelink" and "liblink" and
 "filelink.o", are created in lib/latte to point into the LATTE home
 dir.  When LAMMPS itself is built it will use these links.  You should
 also check that the Makefile.lammps file you create is appropriate for
 the compiler you use on your system to build LATTE.
 :line
 MEAM package :h4,link(meam)
 NOTE: the use of the MEAM package is discouraged, as it has been
 superseded by the USER-MEAMC package, which is a direct translation of
 the Fortran code in the MEAM library to C++. The code in USER-MEAMC
 should be functionally equivalent to the MEAM package, fully supports
 use of "pair_style hybrid"_pair_hybrid.html (the MEAM packaged doesn
 not), and has optimizations that make it significantly faster than the
 MEAM package.
 [CMake build]:
 No additional settings are needed besides "-D PKG_MEAM=yes".
 [Traditional make]:
 Before building LAMMPS, you must build the MEAM library in lib/meam.
 You can build the MEAM library manually if you prefer; follow the
 instructions in lib/meam/README.  You can also do it in one step from
 the lammps/src dir, using a command like these, which simply invoke
 the lib/meam/Install.py script with the specified args:
 make lib-meam                  # print help message
 make lib-meam args="-m mpi"    # build with default Fortran compiler compatible with your MPI library
 make lib-meam args="-m serial" # build with compiler compatible with "make serial" (GNU Fortran)
 make lib-meam args="-m ifort"  # build with Intel Fortran compiler using Makefile.ifort :pre
 The build should produce two files: lib/meam/libmeam.a and
 lib/meam/Makefile.lammps.  The latter is copied from an existing
 Makefile.lammps.* and has settings needed to link C++ (LAMMPS) with
 Fortran (MEAM library).  Typically the two compilers used for LAMMPS
 and the MEAM library need to be consistent (e.g. both Intel or both
 GNU compilers).  If necessary, you can edit/create a new
 lib/meam/Makefile.machine file for your system, which should define an
 EXTRAMAKE variable to specify a corresponding Makefile.lammps.machine
 file.
 :line
 MSCG package :h4,link(mscg)
 To build with this package, you must download and build the MS-CG
 library.  Building the MS-CG library and using it from LAMMPS requires
 a C++11 compatible compiler and that the GSL (GNU Scientific Library)
 headers and libraries are installed on your machine.  See the
 lib/mscg/README and MSCG/Install files for more details.
 [CMake build]:
 -D DOWNLOAD_MSCG=value    # download MSCG for build, value = no (default) or yes
 -D MSCG_LIBRARY=path      # path to MSCG shared library (only needed if a custom location) 
 -D MSCG_INCLUDE_DIR=path  # path to MSCG include directory (only needed if a custom location) :pre
 [Traditional make]:
 You can download and build the MS-CG library manually if you prefer;
 follow the instructions in lib/mscg/README.  You can also do it in one
 step from the lammps/src dir, using a command like these, which simply
 invoke the lib/mscg/Install.py script with the specified args:
 make lib-mscg             # print help message
 make lib-mscg args="-b -m serial"   # download and build in lib/mscg/MSCG-release-master
                                    # with the settings compatible with "make serial"
 make lib-mscg args="-b -m mpi"      # download and build in lib/mscg/MSCG-release-master
                                    # with the settings compatible with "make mpi"
 make lib-mscg args="-p /usr/local/mscg-release" # use the existing MS-CG installation in /usr/local/mscg-release :pre
 Note that 2 symbolic (soft) links, "includelink" and "liblink", will
 be created in lib/mscg to point to the MS-CG src/installation dir.
 When LAMMPS is built in src it will use these links.  You should not
 need to edit the lib/mscg/Makefile.lammps file.
 :line
 OPT package :h4,link(opt)
 [CMake build]:
 No additional settings are needed besides "-D PKG_OPT=yes".
 [Traditional make]:
 The compile flag "-restrict" must be used to build LAMMPS with the OPT
 package when using Intel compilers.  It should be added to the CCFLAGS
 line of your Makefile.machine.  See src/MAKE/OPTIONS/Makefile.opt for
 an example.
 :line
 POEMS package :h4,link(poems)
 [CMake build]:
 No additional settings are needed besides "-D PKG_OPT=yes".
 [Traditional make]:
 Before building LAMMPS, you must build the POEMS library in lib/poems.
 You can do this manually if you prefer; follow the instructions in
 lib/poems/README.  You can also do it in one step from the lammps/src
 dir, using a command like these, which simply invoke the
 lib/poems/Install.py script with the specified args:
 make lib-poems                   # print help message
 make lib-poems args="-m serial"  # build with GNU g++ compiler (settings as with "make serial")
 make lib-poems args="-m mpi"     # build with default MPI C++ compiler (settings as with "make mpi")
 make lib-poems args="-m icc"     # build with Intel icc compiler :pre
 The build should produce two files: lib/poems/libpoems.a and
 lib/poems/Makefile.lammps.  The latter is copied from an existing
 Makefile.lammps.* and has settings needed to build LAMMPS with the
 POEMS library (though typically the settings are just blank).  If
 necessary, you can edit/create a new lib/poems/Makefile.machine file
 for your system, which should define an EXTRAMAKE variable to specify
 a corresponding Makefile.lammps.machine file.
 :line
 PYTHON package :h4,link(python)
 Building with the PYTHON package requires you have a Python shared
 library available on your system, which needs to be a Python 2
 version, 2.6 or later.  Python 3 is not yet supported.  See
 lib/python/README for more details.
 [CMake build]:
 -D PYTHON_EXECUTABLE=path   # path to Python executable to use :pre
 Without this setting, CMake will ues the default Python on your
 system.  To use a different Python version, you can either create a
 virtualenv, activate it and then run cmake.  Or you can set the
 PYTHON_EXECUTABLE variable to specify which Python interpreter should
 be used.  Note note that you will also need to have the development
 headers installed for this version, e.g. python2-devel.
 [Traditional make]:
 The build uses the lib/python/Makefile.lammps file in the compile/link
 process to find Python.  You should only need to create a new
 Makefile.lammps.* file (and copy it to Makefile.lammps) if the LAMMPS
 build fails.
 :line
 REAX package :h4,link(reax)
 NOTE: the use of the REAX package and its "pair_style
 reax"_pair_reax.html command is discouraged, as it is no longer
 maintained.  Please use the USER-REAXC package and its "pair_style
 reax/c"_pair_reaxc.html command instead, and possibly its KOKKOS
 enabled variant (pair_style reax/c/kk), which has a more robust memory
 management.  See the "pair_style reax/c"_pair_reaxc.html doc page for
 details.
 [CMake build]:
 No additional settings are needed besides "-D PKG_REAX=yes".
 [Traditional make]:
 Before building LAMMPS, you must build the REAX library in lib/reax.
 You can do this manually if you prefer; follow the instructions in
 lib/reax/README.  You can also do it in one step from the lammps/src
 dir, using a command like these, which simply invoke the
 lib/reax/Install.py script with the specified args:
 make lib-reax                    # print help message
 make lib-reax args="-m serial"   # build with GNU Fortran compiler (settings as with "make serial")
 make lib-reax args="-m mpi"      # build with default MPI Fortran compiler (settings as with "make mpi")
 make lib-reax args="-m ifort"    # build with Intel ifort compiler :pre
 The build should produce two files: lib/reax/libreax.a and
 lib/reax/Makefile.lammps.  The latter is copied from an existing
 Makefile.lammps.* and has settings needed to link C++ (LAMMPS) with
 Fortran (REAX library).  Typically the two compilers used for LAMMPS
 and the REAX library need to be consistent (e.g. both Intel or both
 GNU compilers).  If necessary, you can edit/create a new
 lib/reax/Makefile.machine file for your system, which should define an
 EXTRAMAKE variable to specify a corresponding Makefile.lammps.machine
 file.
 :line
 VORONOI package :h4,link(voronoi)
 To build with this package, you must download and build the "Voro++
 library"_voro_home.
 :link(voro_home,http://math.lbl.gov/voro++)
 [CMake build]:
 -D DOWNLOAD_VORO=value    # download Voro++ for build, value = no (default) or yes
 -D VORO_LIBRARY=path      # (only needed if at custom location) path to VORO shared library
 -D VORO_INCLUDE_DIR=path  # (only needed if at custom location) path to VORO include directory :pre
 [Traditional make]:
 You can download and build the Voro++ library manually if you prefer;
 follow the instructions in lib/voronoi/README.  You can also do it in
 one step from the lammps/src dir, using a command like these, which
 simply invoke the lib/voronoi/Install.py script with the specified
 args:
 make lib-voronoi                          # print help message
 make lib-voronoi args="-b"                # download and build the default version in lib/voronoi/voro++-<version>
 make lib-voronoi args="-p $HOME/voro++"   # use existing Voro++ installation in $HOME/voro++
 make lib-voronoi args="-b -v voro++0.4.6" # download and build the 0.4.6 version in lib/voronoi/voro++-0.4.6 :pre
 Note that 2 symbolic (soft) links, "includelink" and "liblink", are
 created in lib/voronoi to point to the Voro++ src dir.  When LAMMPS
 builds in src it will use these links.  You should not need to edit
 the lib/voronoi/Makefile.lammps file.
 :line
 USER-ATC package :h4,link(user-atc)
 The USER-ATC package requires the MANYBODY package also be installed.
 [CMake build]:
 No additional settings are needed besides "-D PKG_REAX=yes" and "-D
 PKG_MANYBODY=yes".
 [Traditional make]:
 Before building LAMMPS, you must build the ATC library in lib/atc.
 You can do this manually if you prefer; follow the instructions in
 lib/atc/README.  You can also do it in one step from the lammps/src
 dir, using a command like these, which simply invoke the
 lib/atc/Install.py script with the specified args:
 make lib-atc                      # print help message
 make lib-atc args="-m serial"     # build with GNU g++ compiler and MPI STUBS (settings as with "make serial")
 make lib-atc args="-m mpi"        # build with default MPI compiler (settings as with "make mpi")
 make lib-atc args="-m icc"        # build with Intel icc compiler :pre
 The build should produce two files: lib/atc/libatc.a and
 lib/atc/Makefile.lammps.  The latter is copied from an existing
 Makefile.lammps.* and has settings needed to build LAMMPS with the ATC
 library.  If necessary, you can edit/create a new
 lib/atc/Makefile.machine file for your system, which should define an
 EXTRAMAKE variable to specify a corresponding Makefile.lammps.machine
 file.
 Note that the Makefile.lammps file has settings for the BLAS and
 LAPACK linear algebra libraries.  As explained in lib/atc/README these
 can either exist on your system, or you can use the files provided in
 lib/linalg.  In the latter case you also need to build the library in
 lib/linalg with a command like these:
 make lib-linalg                     # print help message
 make lib-linalg args="-m serial"    # build with GNU Fortran compiler (settings as with "make serial")
 make lib-linalg args="-m mpi"       # build with default MPI Fortran compiler (settings as with "make mpi")
 make lib-linalg args="-m gfortran"  # build with GNU Fortran compiler :pre
 :line
 USER-AWPMD package :h4,link(user-awpmd)
 [CMake build]:
 No additional settings are needed besides "-D PKG_USER-AQPMD=yes".
 [Traditional make]:
 Before building LAMMPS, you must build the AWPMD library in lib/awpmd.
 You can do this manually if you prefer; follow the instructions in
 lib/awpmd/README.  You can also do it in one step from the lammps/src
 dir, using a command like these, which simply invoke the
 lib/awpmd/Install.py script with the specified args:
 make lib-awpmd                   # print help message
 make lib-awpmd args="-m serial"  # build with GNU g++ compiler and MPI STUBS (settings as with "make serial")
 make lib-awpmd args="-m mpi"     # build with default MPI compiler (settings as with "make mpi")
 make lib-awpmd args="-m icc"     # build with Intel icc compiler :pre
 The build should produce two files: lib/awpmd/libawpmd.a and
 lib/awpmd/Makefile.lammps.  The latter is copied from an existing
 Makefile.lammps.* and has settings needed to build LAMMPS with the
 AWPMD library.  If necessary, you can edit/create a new
 lib/awpmd/Makefile.machine file for your system, which should define
 an EXTRAMAKE variable to specify a corresponding
 Makefile.lammps.machine file.
 Note that the Makefile.lammps file has settings for the BLAS and
 LAPACK linear algebra libraries.  As explained in lib/awpmd/README
 these can either exist on your system, or you can use the files
 provided in lib/linalg.  In the latter case you also need to build the
 library in lib/linalg with a command like these:
 make lib-linalg                     # print help message
 make lib-linalg args="-m serial"    # build with GNU Fortran compiler (settings as with "make serial")
 make lib-linalg args="-m mpi"       # build with default MPI Fortran compiler (settings as with "make mpi")
 make lib-linalg args="-m gfortran"  # build with GNU Fortran compiler :pre
 :line
 USER-COLVARS package :h4,link(user-colvars)
 [CMake build]:
 No additional settings are needed besides "-D PKG_USER-COLVARS=yes".
 [Traditional make]:
 Before building LAMMPS, you must build the COLVARS library in
 lib/colvars.  You can do this manually if you prefer; follow the
 instructions in lib/colvars/README.  You can also do it in one step
 from the lammps/src dir, using a command like these, which simply
 invoke the lib/colvars/Install.py script with the specified args:
 make lib-colvars                      # print help message
 make lib-colvars args="-m serial"     # build with GNU g++ compiler (settings as with "make serial")
 make lib-colvars args="-m mpi"        # build with default MPI compiler (settings as with "make mpi")
 make lib-colvars args="-m g++-debug"  # build with GNU g++ compiler and colvars debugging enabled :pre
 The build should produce two files: lib/colvars/libcolvars.a and
 lib/colvars/Makefile.lammps.  The latter is copied from an existing
 Makefile.lammps.* and has settings needed to build LAMMPS with the
 COLVARS library (though typically the settings are just blank).  If
 necessary, you can edit/create a new lib/colvars/Makefile.machine file
 for your system, which should define an EXTRAMAKE variable to specify
 a corresponding Makefile.lammps.machine file.
 :line
 USER-H5MD package :h4,link(user-h5md)
 To build with this package you must have the HDF5 software package
 installed on your system, which should include the h5cc compiler and
 the HDF5 library.
 [CMake build]:
 No additional settings are needed besides "-D PKG_USER-H5MD=yes".
 This should autodetect the H5MD library on your system.  Several
 advanced CMake H5MD options exist if you need to specify where it is
 installed.  Use the ccmake (terminal window) or cmake-gui (graphical)
 tools to see these options and set them interactively from their user
 interfaces.
 [Traditional make]:
 Before building LAMMPS, you must build the CH5MD library in lib/h5md.
 You can do this manually if you prefer; follow the instructions in
 lib/h5md/README.  You can also do it in one step from the lammps/src
 dir, using a command like these, which simply invoke the
 lib/h5md/Install.py script with the specified args:
 make lib-h5md                     # print help message
 make lib-hm5d args="-m h5cc"      # build with h5cc compiler :pre
 The build should produce two files: lib/h5md/libch5md.a and
 lib/h5md/Makefile.lammps.  The latter is copied from an existing
 Makefile.lammps.* and has settings needed to build LAMMPS with the
 system HDF5 library.  If necessary, you can edit/create a new
 lib/h5md/Makefile.machine file for your system, which should define an
 EXTRAMAKE variable to specify a corresponding Makefile.lammps.machine
 file.
 :line
 USER-INTEL package :h4,link(user-intel)
 To build with this package, you must choose which hardware you want to
 build for, either Intel CPUs or Intel KNLs.  You should also typically
 "install the USER-OMP package"_#user-omp, as it can be used in tandem
 with the USER-INTEL package to good effect, as explained on the "Speed
 intel"_Speed_intel.html doc page.
 [CMake build]:
 -D INTEL_ARCH=value     # value = cpu (default) or knl
 -D BUILD_OMP=yes        # also required to build with the USER-INTEl package :pre
 Requires an Intel compiler as well as the Intel TBB and MKL libraries.
 [Traditional make]:
 Choose which hardware to compile for in Makefile.machine via the
 following settings.  See src/MAKE/OPTIONS/Makefile.intel_cpu* and
 Makefile.knl files for examples.
 For CPUs:
 OPTFLAGS =      -xHost -O2 -fp-model fast=2 -no-prec-div -qoverride-limits -qopt-zmm-usage=high
 CCFLAGS =	-g -qopenmp -DLAMMPS_MEMALIGN=64 -no-offload \
                -fno-alias -ansi-alias -restrict $(OPTFLAGS)
 LINKFLAGS =	-g -qopenmp $(OPTFLAGS)
 LIB =           -ltbbmalloc :pre
 For KNLs:
 OPTFLAGS =      -xMIC-AVX512 -O2 -fp-model fast=2 -no-prec-div -qoverride-limits
 CCFLAGS =	-g -qopenmp -DLAMMPS_MEMALIGN=64 -no-offload \
                -fno-alias -ansi-alias -restrict $(OPTFLAGS)
 LINKFLAGS =	-g -qopenmp $(OPTFLAGS)
 LIB =           -ltbbmalloc :pre
 :line
 USER-MOLFILE package :h4,link(user-molfile)
 [CMake build]:
 No additional settings are needed besides "-D PKG_USER-MOLFILE=yes".
 [Traditional make]:
 The lib/molfile/Makefile.lammps file has a setting for a dynamic
 loading library libdl.a that is typically present on all systems.  It
 is required for LAMMPS to link with this package.  If the setting is
 not valid for your system, you will need to edit the Makefile.lammps
 file.  See lib/molfile/README and lib/molfile/Makefile.lammps for
 details.
 :line
 USER-NETCDF package :h4,link(user-netcdf)
 To build with this package you must have the NetCDF library installed
 on your system.
 [CMake build]:
 No additional settings are needed besides "-D PKG_USER-NETCDF=yes".
 This should autodetect the NETCDF library if it is installed on your
 system at standard locations.  Several advanced CMake NETCDF options
 exist if you need to specify where it was installed.  Use the ccmake
 (terminal window) or cmake-gui (graphical) tools to see these options
 and set them interactively from their user interfaces.
 [Traditional make]:
 The lib/netcdf/Makefile.lammps file has settings for NetCDF include
 and library files which LAMMPS needs to build with this package.  If
 the settings are not valid for your system, you will need to edit the
 Makefile.lammps file.  See lib/netcdf/README for details.
 :line
 USER-OMP package :h4,link(user-omp)
 [CMake build]:
 No additional settings are required besides "-D PKG_USER-OMP=yes".  If
 CMake detects OpenMP support, the USER-OMP code will be compiled with
 multi-threading support enabled, otherwise as optimized serial code.
 [Traditional make]:
 To enable multi-threading support in the USER-OMP package (and other
 styles supporting OpenMP) the following compile and link flags must
 be added to your Makefile.machine file.
 See src/MAKE/OPTIONS/Makefile.omp for an example.
 CCFLAGS: -fopenmp               # for GNU Compilers
 CCFLAGS: -qopenmp -restrict     # for Intel compilers on Linux
 LINKFLAGS: -fopenmp             # for GNU Compilers
 LINKFLAGS: -qopenmp             # for Intel compilers on Linux :pre
 For other platforms and compilers, please consult the documentation
 about OpenMP support for your compiler.
 :line
 USER-QMMM package :h4,link(user-qmmm)
 NOTE: The LAMMPS executable these steps produce is not yet functional
 for a QM/MM simulation.  You must also build Quantum ESPRESSO and
 create a new executable (pwqmmm.x) which links LAMMPS and Quantum
 ESPRESSO together.  These are steps 3 and 4 described in the
 lib/qmmm/README file.  Unfortunately, the Quantum ESPRESSO developers
 have been breaking the interface that the QM/MM code in LAMMPS is using,
 so that currently (Summer 2018) using this feature requires either
 correcting the library interface feature in recent Quantum ESPRESSO
 releases, or using an outdated version of QE. The last version of
 Quantum ESPRESSO known to work with this QM/MM interface was version
 5.4.1 from 2016.
 [CMake build]:
 The CMake build system currently does not support building the full
 QM/MM-capable hybrid executable of LAMMPS and QE called pwqmmm.x.  
 You must use the traditional make build for this package.
 [Traditional make]:
 Before building LAMMPS, you must build the QMMM library in lib/qmmm.
 You can do this manually if you prefer; follow the first two steps
 explained in lib/qmmm/README.  You can also do it in one step from the
 lammps/src dir, using a command like these, which simply invoke the
 lib/qmmm/Install.py script with the specified args:
 make lib-qmmm                      # print help message
 make lib-qmmm args="-m serial"     # build with GNU Fortran compiler (settings as in "make serial")
 make lib-qmmm args="-m mpi"        # build with default MPI compiler (settings as in "make mpi")
 make lib-qmmm args="-m gfortran"   # build with GNU Fortran compiler :pre
 The build should produce two files: lib/qmmm/libqmmm.a and
 lib/qmmm/Makefile.lammps.  The latter is copied from an existing
 Makefile.lammps.* and has settings needed to build LAMMPS with the
 QMMM library (though typically the settings are just blank).  If
 necessary, you can edit/create a new lib/qmmm/Makefile.machine file
 for your system, which should define an EXTRAMAKE variable to specify
 a corresponding Makefile.lammps.machine file.
 You can then install QMMM package and build LAMMPS in the usual
 manner.  After completing the LAMMPS build and compiling Quantum
 ESPRESSO with external library support, go back to the lib/qmmm folder
 and follow the instructions on the README file to build the combined
 LAMMPS/QE QM/MM executable (pwqmmm.x) in the lib/qmmm folder.
 :line
 USER-QUIP package :h4,link(user-quip)
 To build with this package, you must download and build the QUIP
 library.  It can be obtained from GitHub.  For support of GAP
 potentials, additional files with specific licensing conditions need
 to be downloaded and configured.  See step 1 and step 1.1 in the
 lib/quip/README file for details on how to do this.
 [CMake build]:
 -D QUIP_LIBRARIES=path    # path to libquip.a (only needed if a custom location) 
 CMake will not download and build the QUIP library.  But once you have
 done that, a CMake build of LAMMPS with "-D PKG_USER-QUIP=yes" should
 work.  Set QUIP_LIBRARIES if CMake cannot find the QUIP library.
 [Traditional make]:
 The download/build procedure for the QUIP library, described in
 lib/quip/README file requires setting two environment variables,
 QUIP_ROOT and QUIP_ARCH.  These are accessed by the
 lib/quip/Makefile.lammps file which is used when you compile and link
 LAMMPS with this package.  You should only need to edit
 Makefile.lammps if the LAMMPS build can not use its settings to
 successfully build on your system.
 :line
 USER-SMD package :h4,link(user-smd)
 To build with this package, you must download the Eigen3 library.
 Eigen3 is a template library, so you do not need to build it.
 [CMake build]:
 -D DOWNLOAD_EIGEN3            # download Eigen3, value = no (default) or yes
 -D EIGEN3_INCLUDE_DIR=path    # path to Eigen library (only needed if a custom location) :pre
 Set EIGEN3_INCLUDE_DIR if CMake cannot find the Eigen3 library.
 [Traditional make]:
 You can download the Eigen3 library manually if you prefer; follow the
 instructions in lib/smd/README.  You can also do it in one step from
 the lammps/src dir, using a command like these, which simply invoke
 the lib/smd/Install.py script with the specified args:
 make lib-smd                         # print help message
 make lib-smd args="-b"               # download to lib/smd/eigen3
 make lib-smd args="-p /usr/include/eigen3"    # use existing Eigen installation in /usr/include/eigen3 :pre
 Note that a symbolic (soft) link named "includelink" is created in
 lib/smd to point to the Eigen dir.  When LAMMPS builds it will use
 this link.  You should not need to edit the lib/smd/Makefile.lammps
 file.
 :line
 USER-VTK package :h4,link(user-vtk)
 To build with this package you must have the VTK library installed on
 your system.
 [CMake build]:
 No additional settings are needed besides "-D PKG_USER-VTK=yes".
 This should autodetect the VTK library if it is installed on your
 system at standard locations.  Several advanced VTK options exist if
 you need to specify where it was installed.  Use the ccmake (terminal
 window) or cmake-gui (graphical) tools to see these options and set
 them interactively from their user interfaces.
 [Traditional make]:
 The lib/vtk/Makefile.lammps file has settings for accessing VTK files
 and its library, which LAMMPS needs to build with this package.  If
 the settings are not valid for your system, check if one of the other
 lib/vtk/Makefile.lammps.* files is compatible and copy it to
 Makefile.lammps.  If none of the provided files work, you will need to
 edit the Makefile.lammps file.  See lib/vtk/README for details.
--- a/doc/src/Build_link.txt
+++ b/doc/src/Build_link.txt
@ -0,0 +1,85 @@
 "Higher level section"_Build.html - "LAMMPS WWW Site"_lws - "LAMMPS
 Documentation"_ld - "LAMMPS Commands"_lc :c
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
 :link(lc,Commands_all.html)
 :line
 Link LAMMPS as a library to another code :h3
 LAMMPS can be used as a library by another application, including
 Python scripts.  The files src/library.cpp and library.h define the
 C-style API for using LAMMPS as a library.  See the "Howto
 library"_Howto_library.html doc page for a description of the
 interface and how to extend it for your needs.
 The "Build basics"_Build_basics.html doc page explains how to build
 LAMMPS as either a shared or static library.  This results in one of
 these 2 files:
 liblammps.so      # shared library
 liblammps.a       # static library
 :line
 [Link with LAMMPS as a static library]:
 The calling application can link to LAMMPS as a static library with a
 link command like this:
 g++ caller.o -L/home/sjplimp/lammps/src -llammps -o caller
 The -L argument is the path to where the liblammps.a file is.  The
 -llammps argument is shorthand for the file liblammps.a.
 :line
 [Link with LAMMPS as a shared library]:
 If you wish to link to liblammps.so, the operating system finds shared
 libraries to load at run-time using the environment variable
 LD_LIBRARY_PATH.  To enable this you can do one of two things:
 (1) Copy the liblammps.so file to a location the system can find it,
 such as /usr/local/lib.  I.e. a directory already listed in your
 LD_LIBRARY_PATH variable.  You can type
 printenv LD_LIBRARY_PATH :pre
 to see what directories are in that list.
 (2) Add the LAMMPS src directory (or the directory you perform CMake
 build in) to your LD_LIBRARY_PATH, so that the current version of the
 shared library is always available to programs that use it.
 For the csh or tcsh shells, you would add something like this to your
 ~/.cshrc file:
 setenv LD_LIBRARY_PATH $\{LD_LIBRARY_PATH\}:/home/sjplimp/lammps/src :pre
 :line
 [Calling the LAMMPS library]:
 Either flavor of library (static or shared) allows one or more LAMMPS
 objects to be instantiated from the calling program.
 When used from a C++ program, all of LAMMPS is wrapped in a LAMMPS_NS
 namespace; you can safely use any of its classes and methods from
 within the calling code, as needed.
 When used from a C or Fortran program, the library has a simple
 C-style interface, provided in src/library.cpp and src/library.h.
 See the "Python library"_Python_library.html doc page for a
 description of the Python interface to LAMMPS, which wraps the C-style
 interface.
 See the sample codes in examples/COUPLE/simple for examples of C++ and
 C and Fortran codes that invoke LAMMPS thru its library interface.
 Other examples in the COUPLE directory use coupling ideas discussed on
 the "Howto couple"_Howto_couple.html doc page.
--- a/doc/src/Build_make.txt
+++ b/doc/src/Build_make.txt
@ -0,0 +1,85 @@
 "Higher level section"_Build.html - "LAMMPS WWW Site"_lws - "LAMMPS
 Documentation"_ld - "LAMMPS Commands"_lc :c
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
 :link(lc,Commands_all.html)
 :line
 Build LAMMPS with make :h3
 Building LAMMPS with traditional makefiles requires that you have a
 Makefile."machine" file appropriate for your system in the src/MAKE,
 src/MAKE/MACHINES, src/MAKE/OPTIONS, or src/MAKE/MINE directory (see
 below).  It can include various options for customizing your LAMMPS
 build with a number of global compilation options and features.
 To include LAMMPS packages (i.e. optional commands and styles) you
 must install them first, as discussed on the "Build
 package"_Build_package.html doc page.  If the packages require
 provided or external libraries, you must build those libraries before
 building LAMMPS.  Building "LAMMPS with CMake"_Build_cmake.html can
 automate all of this for many types of machines, especially
 workstations, desktops and laptops, so we suggest you try it first.
 These commands perform a default LAMMPS build, producing the LAMMPS
 executable lmp_serial or lmp_mpi in lammps/src:
 cd lammps/src
 make serial     # build a serial LAMMPS executable
 make mpi        # build a parallel LAMMPS executable with MPI
 make            # see a variety of make options :pre
 This initial compilation can take a long time, since LAMMPS is a large
 project with many features. If your machine has multiple CPU cores
 (most do these days), using a command like "make -jN mpi" (with N =
 the number of available CPU cores) can be much faster.  If you plan to
 do development on LAMMPS or need to recompile LAMMPS repeatedly, the
 installation of the ccache (= Compiler Cache) software may speed up
 compilation even more.
 After the initial build, whenever you edit LAMMPS source files, or add
 or remove new files to the source directory (e.g. by installing or
 uninstalling packages), you must recompile and relink the LAMMPS
 executable with the same "make" command.  This makefiles dependencies
 should insure that only the subset of files that need to be are
 recompiled.
 NOTE: When you build LAMMPS for the first time, a long list of *.d
 files will be printed out rapidly.  This is not an error; it is the
 Makefile doing its normal creation of dependencies.
 :line
 The lammps/src/MAKE tree contains all the Makefile.machine files
 included in the LAMMPS distribution.  Typing "make machine" uses
 Makefile.machine.  Thus the "make serial" or "make mpi" lines above
 use Makefile.serial and Makefile.mpi.  Others are in these dirs:
 OPTIONS      # Makefiles which enable specific options
 MACHINES     # Makefiles for specific machines
 MINE         # customized Makefiles you create (you may need to create this folder) :pre
 Typing "make" lists all the available Makefile.machine files.  A file
 with the same name can appear in multiple folders (not a good idea).
 The order the dirs are searched is as follows: src/MAKE/MINE,
 src/MAKE, src/MAKE/OPTIONS, src/MAKE/MACHINES.  This gives preference
 to a customized file you put in src/MAKE/MINE.
 Makefiles you may wish to try include these (some require a package
 first be installed).  Many of these include specific compiler flags
 for optimized performance.  Please note, however, that some of these
 customized machine Makefile are contributed by users.  Since both
 compilers, OS configs, and LAMMPS itself keep changing, their settings
 may become outdated:
 make mac             # build serial LAMMPS on a Mac
 make mac_mpi         # build parallel LAMMPS on a Mac
 make intel_cpu       # build with the USER-INTEL package optimized for CPUs
 make knl             # build with the USER-INTEL package optimized for KNLs
 make opt             # build with the OPT package optimized for CPUs
 make omp             # build with the USER-OMP package optimized for OpenMP
 make kokkos_omp      # build with the KOKKOS package for OpenMP
 make kokkos_cuda_mpi # build with the KOKKOS package for GPUs
 make kokkos_phi      # build with the KOKKOS package for KNLs :pre
--- a/doc/src/Build_package.txt
+++ b/doc/src/Build_package.txt
@ -0,0 +1,222 @@
 "Higher level section"_Build.html - "LAMMPS WWW Site"_lws - "LAMMPS
 Documentation"_ld - "LAMMPS Commands"_lc :c
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
 :link(lc,Commands_all.html)
 :line
 Include packages in build :h3
 In LAMMPS, a package is a group of files that enable a specific set of
 features.  For example, force fields for molecular systems or
 rigid-body constraints are in packages.  In the src directory, each
 package is a sub-directory with the package name in capital letters.
 An overview of packages is given on the "Packages"_Packages.html doc
 page.  Brief overviews of each package are on the "Packages
 details"_Packages_details.html doc page.
 When building LAMMPS, you can choose to include or exclude each
 package.  In general there is no need to include a package if you
 never plan to use its features.
 If you get a run-time error that a LAMMPS command or style is
 "Unknown", it is often because the command is contained in a package,
 and your build did not include that package.  Running LAMMPS with the
 "-h command-line switch"_Run_options.html will print all the included
 packages and commands for that executable.
 For the majority of packages, if you follow the single step below to
 include it, you can then build LAMMPS exactly the same as you would
 without any packages installed.  A few packages may require additional
 steps, as explained on the "Build extras"_Build_extras.html doc page.
 These links take you to the extra instructions for those select
 packages:
 "GPU"_Build_extras.html#gpu,
 "KIM"_Build_extras.html#kim,
 "KOKKOS"_Build_extras.html#kokkos,
 "LATTE"_Build_extras.html#latte,
 "MEAM"_Build_extras.html#meam,
 "MSCG"_Build_extras.html#mscg,
 "OPT"_Build_extras.html#opt,
 "POEMS"_Build_extras.html#poems,
 "PYTHON"_Build_extras.html#python,
 "REAX"_Build_extras.html#reax,
 "VORONOI"_Build_extras.html#voronoi,
 "USER-ATC"_Build_extras.html#user-atc,
 "USER-AWPMD"_Build_extras.html#user-awpmd,
 "USER-COLVARS"_Build_extras.html#user-colvars,
 "USER-H5MD"_Build_extras.html#user-h5md,
 "USER-INTEL"_Build_extras.html#user-intel,
 "USER-MOLFILE"_Build_extras.html#user-molfile,
 "USER-NETCDF"_Build_extras.html#user-netcdf,
 "USER-OMP"_Build_extras.html#user-omp,
 "USER-QMMM"_Build_extras.html#user-qmmm,
 "USER-QUIP"_Build_extras.html#user-quip,
 "USER-SMD"_Build_extras.html#user-smd,
 "USER-VTK"_Build_extras.html#user-vtk :tb(c=6,ea=c)
 The mechanism for including packages is simple but different for CMake
 versus make.
 [CMake variables]:
 -D PKG_NAME=value          # yes or no (default) :pre
 Examples:
 -D PKG_MANYBODY=yes
 -D PKG_USER-INTEL=yes :pre
 All standard and user packages are included the same way.  Note that
 USER packages have a hyphen between USER and the rest of the package
 name, not an underscore.
 See the shortcut section below for how to install many packages at
 once with CMake.
 NOTE: If you toggle back and forth between building with CMake vs
 make, no packages in the src directory can be installed when you
 invoke cmake.  CMake will give an error if that is not the case,
 indicating how you can un-install all packages in the src dir.
 [Traditional make]:
 cd lammps/src
 make ps                    # check which packages are currently installed
 make yes-name              # install a package with name
 make no-name               # un-install a package with name
 make mpi                   # build LAMMPS with whatever packages are now installed :pre
 Examples:
 make no-rigid
 make yes-user-intel :pre
 All standard and user packages are included the same way.
 See the shortcut section below for how to install many packages at
 once with make.
 NOTE: You must always re-build LAMMPS (via make) after installing or
 un-installing a package, for the action to take effect.
 NOTE: You cannot install or un-install packages and build LAMMPS in a
 single make command with multiple targets, e.g. make yes-colloid mpi.
 This is because the make procedure creates a list of source files that
 will be out-of-date for the build if the package configuration changes
 within the same command.  You can include or exclude multiple packages
 in a single make command, e.g. make yes-colloid no-manybody.
 [CMake and make info]:
 Any package can be included or excluded in a LAMMPS build, independent
 of all other packages.  However, some packages include files derived
 from files in other packages.  LAMMPS checks for this and does the
 right thing.  Individual files are only included if their dependencies
 are already included.  Likewise, if a package is excluded, other files
 dependent on that package are also excluded.
 When you download a LAMMPS tarball or download LAMMPS source files
 from the Git or SVN repositories, no packages are pre-installed in the
 src directory.
 NOTE: Prior to Aug 2018, if you downloaded a tarball, 3 packages
 (KSPACE, MANYBODY, MOLECULE) were pre-installed in the src directory.
 That is no longer the case, so that CMake will build as-is without the
 need to un-install those packages.
 :line
 [CMake shortcuts for installing many packages]:
 Instead of specifying all the CMake options via the command-line,
 CMake allows initializing the variable cache using script files. These
 are regular CMake files which can manipulate and set variables, and
 can also contain control flow constructs.
 LAMMPS includes several of these files to define configuration
 "presets", similar to the options that exist for the Make based
 system. Using these files you can enable/disable portions of the
 available packages in LAMMPS. If you need a custom preset you can take
 one of them as a starting point and customize it to your needs.
 cmake -C ../cmake/presets/all_on.cmake \[OPTIONS\] ../cmake | enable all packages
 cmake -C ../cmake/presets/all_off.cmake \[OPTIONS\] ../cmake | disable all packages
 cmake -C ../cmake/presets/std.cmake \[OPTIONS\] ../cmake | enable standard packages
 cmake -C ../cmake/presets/user.cmake \[OPTIONS\] ../cmake | enable user packages
 cmake -C ../cmake/presets/std_nolib.cmake \[OPTIONS\] ../cmake | enable standard packages that do not require extra libraries
 cmake -C ../cmake/presets/nolib.cmake \[OPTIONS\] ../cmake | disable all packages that do not require extra libraries
 cmake -C ../cmake/presets/manual_selection.cmake \[OPTIONS\] ../cmake | example of how to create a manual selection of packages :tb(s=|,a=l)
 NOTE: Running cmake this way manipulates the variable cache in your
 current build directory. You can combine presets and options with
 multiple cmake runs.
 [Example:]
 # build LAMMPS with all "standard" packages which don't
 # use libraries and enable GPU package
 mkdir build
 cd build
 cmake -C ../cmake/presets/std_nolib.cmake -D PKG_GPU=on ../cmake :pre
 :line
 [Make shortcuts for installing many packages]:
 The following commands are useful for managing package source files
 and their installation when building LAMMPS via traditional make.
 Just type "make" in lammps/src to see a one-line summary.
 These commands install/un-install sets of packages:
 make yes-all | install all packages
 make no-all | un-install all packages
 make yes-standard or make yes-std | install standard packages
 make no-standard or make no-std| un-install standard packages
 make yes-user | install user packages
 make no-user | un-install user packages
 make yes-lib | install packages that require extra libraries
 make no-lib | un-install packages that require extra libraries
 make yes-ext | install packages that require external libraries
 make no-ext | un-install packages that require external libraries :tb(s=|,a=l)
 which install/un-install various sets of packages.  Typing "make
 package" will list all the these commands.
 NOTE: Installing or un-installing a package works by simply copying
 files back and forth between the main src directory and
 sub-directories with the package name (e.g. src/KSPACE, src/USER-ATC),
 so that the files are included or excluded when LAMMPS is built.
 The following make commands help manage files that exist in both the
 src directory and in package sub-directories.  You do not normally
 need to use these commands unless you are editing LAMMPS files or are
 "installing a patch"_Install_patch.html downloaded from the LAMMPS web
 site.
 Type "make package-status" or "make ps" to show which packages are
 currently installed.  For those that are installed, it will list any
 files that are different in the src directory and package
 sub-directory.
 Type "make package-installed" or "make pi" to show which packages are
 currently installed, without listing the status of packages that are
 not installed.
 Type "make package-update" or "make pu" to overwrite src files with
 files from the package sub-directories if the package is installed.
 It should be used after a "patch has been applied"_Install_patch.html,
 since patches only update the files in the package sub-directory, but
 not the src files.
 Type "make package-overwrite" to overwrite files in the package
 sub-directories with src files.
 Type "make package-diff" to list all differences between pairs of
 files in both the src dir and a package dir.
--- a/doc/src/Build_settings.txt
+++ b/doc/src/Build_settings.txt
@ -0,0 +1,341 @@
 "Higher level section"_Build.html - "LAMMPS WWW Site"_lws - "LAMMPS
 Documentation"_ld - "LAMMPS Commands"_lc :c
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
 :link(lc,Commands_all.html)
 :line
 Optional build settings :h3
 LAMMPS can be built with several optional settings.  Each sub-section
 explain how to do this for building both with CMake and make.
 "FFT library"_#fft for use with the "kspace_style pppm"_kspace_style.html command
 "Size of LAMMPS data types"_#size
 "Read or write compressed files"_#gzip
 "Output of JPG and PNG files"_#graphics via the "dump image"_dump_image.html command
 "Output of movie files"_#graphics via the "dump_movie"_dump_image.html command
 "Memory allocation alignment"_#align
 "Workaround for long long integers"_#longlong
 "Error handling exceptions"_#exceptions when using LAMMPS as a library :all(b)
 :line
 FFT library :h3,link(fft)
 When the KSPACE package is included in a LAMMPS build, the
 "kspace_style pppm"_kspace_style.html command performs 3d FFTs which
 require use of an FFT library to compute 1d FFTs.  The KISS FFT
 library is included with LAMMPS but other libraries can be faster.
 LAMMPS can use them if they are available on your system.
 [CMake variables]:
 -D FFT=value              # FFTW3 or MKL or KISS, default is FFTW3 if found, else KISS
 -D FFT_SINGLE=value       # yes or no (default), no = double precision
 -D FFT_PACK=value         # array (default) or pointer or memcpy :pre
 NOTE: The values for the FFT variable must be in upper-case.  This is
 an exception to the rule that all CMake variables can be specified
 with lower-case values.
 Usually these settings are all that is needed.  If CMake cannot find
 the FFT library, you can set these variables:
 -D FFTW3_INCLUDE_DIRS=path  # path to FFTW3 include files
 -D FFTW3_LIBRARIES=path     # path to FFTW3 libraries
 -D MKL_INCLUDE_DIRS=path    # ditto for Intel MKL library
 -D MKL_LIBRARIES=path :pre
 [Makefile.machine settings]:
 FFT_INC = -DFFT_FFTW3         # -DFFT_FFTW3, -DFFT_FFTW (same as -DFFT_FFTW3), -DFFT_MKL, or -DFFT_KISS
                              # default is KISS if not specified
 FFT_INC = -DFFT_SINGLE        # do not specify for double precision
 FFT_INC = -DFFT_PACK_ARRAY    # or -DFFT_PACK_POINTER or -DFFT_PACK_MEMCPY :pre
                              # default is FFT_PACK_ARRAY if not specified
 FFT_INC =    	-I/usr/local/include
 FFT_PATH =      -L/usr/local/lib
 FFT_LIB =	-lfftw3             # FFTW3 double precision
 FFT_LIB =	-lfftw3 -lfftw3f    # FFTW3 single precision
 FFT_LIB =       -lmkl_intel_lp64 -lmkl_sequential -lmkl_core  # MKL with Intel compiler
 FFT_LIB =       -lmkl_gf_lp64 -lmkl_sequential -lmkl_core     # MKL with GNU compier :pre
 As with CMake, you do not need to set paths in FFT_INC or FFT_PATH, if
 make can find the FFT header and library files.  You must specify
 FFT_LIB with the appropriate FFT libraries to include in the link.
 [CMake and make info]:
 The "KISS FFT library"_http://kissfft.sf.net is included in the LAMMPS
 distribution.  It is portable across all platforms.  Depending on the
 size of the FFTs and the number of processors used, the other
 libraries listed here can be faster.  
 However, note that long-range Coulombics are only a portion of the
 per-timestep CPU cost, FFTs are only a portion of long-range
 Coulombics, and 1d FFTs are only a portion of the FFT cost (parallel
 communication can be costly).  A breakdown of these timings is printed
 to the screen at the end of a run using the "kspace_style
 pppm"_kspace_style.html command.  The "Run output"_doc page gives more
 details.
 FFTW is a fast, portable FFT library that should also work on any
 platform and can be faster than the KISS FFT library.  You can
 download it from "www.fftw.org"_http://www.fftw.org.  LAMMPS requires
 version 3.X; the legacy version 2.1.X is no longer supported.
 Building FFTW for your box should be as simple as ./configure; make;
 make install.  The install command typically requires root privileges
 (e.g. invoke it via sudo), unless you specify a local directory with
 the "--prefix" option of configure.  Type "./configure --help" to see
 various options. 
 The Intel MKL math library is part of the Intel compiler suite.  It
 can be used with the Intel or GNU compiler (see FFT_LIB setting above).
 Performing 3d FFTs in parallel can be time consuming due to data
 access and required communication.  This cost can be reduced by
 performing single-precision FFTs instead of double precision.  Single
 precision means the real and imaginary parts of a complex datum are
 4-byte floats.  Double precesion means they are 8-byte doubles.  Note
 that Fourier transform and related PPPM operations are somewhat less
 sensitive to floating point truncation errors and thus the resulting
 error is less than the difference in precision. Using the -DFFT_SINGLE
 setting trades off a little accuracy for reduced memory use and
 parallel communication costs for transposing 3d FFT data.
 When using -DFFT_SINGLE with FFTW3 you may need to build the FFTW
 library a second time with support for single-precision.
 For FFTW3, do the following, which should produce the additional
 library libfftw3f.a
 make clean
 ./configure --enable-single; make; make install :pre
 Performing 3d FFTs requires communication to transpose the 3d FFT
 grid.  The data packing/unpacking for this can be done in one of 3
 modes (ARRAY, POINTER, MEMCPY) as set by the FFT_PACK syntax above.
 Depending on the machine, the size of the FFT grid, the number of
 processors used, one option may be slightly faster.  The default is
 ARRAY mode.
 :line
 Size of LAMMPS data types :h3,link(size)
 LAMMPS has a few integer data types which can be defined as 4-byte or
 8-byte integers.  The default setting of "smallbig" is almost always
 adequate.
 [CMake variable]:
 -D LAMMPS_SIZES=value   # smallbig (default) or bigbig or smallsmall :pre
 [Makefile.machine setting]:
 LMP_INC = -DLAMMPS_SMALLBIG    # or -DLAMMPS_BIGBIG or -DLAMMPS_SMALLSMALL :pre
                               # default is LAMMMPS_SMALLBIG if not specified
 [CMake and make info]:
 The default "smallbig" setting allows for simulations with:
 total atom count = 2^63 atoms (about 9e18)
 total timesteps = 2^63 (about 9e18)
 atom IDs = 2^31 (about 2 billion)
 image flags = roll over at 512 :ul
 The "bigbig" setting increases the latter two limits.  It allows for:
 total atom count = 2^63 atoms (about 9e18)
 total timesteps = 2^63 (about 9e18)
 atom IDs = 2^63 (about 9e18)
 image flags = roll over at about 1 million (2^20) :ul
 The "smallsmall" setting is only needed if your machine does not
 support 8-byte integers.  It allows for:
 total atom count = 2^31 atoms (about 2 billion)
 total timesteps = 2^31 (about 2 billion)
 atom IDs = 2^31 (about 2 billion)
 image flags = roll over at 512 (2^9) :ul
 Atom IDs are not required for atomic systems which do not store bond
 topology information, though IDs are enabled by default.  The
 "atom_modify id no"_atom_modify.html command will turn them off.  Atom
 IDs are required for molecular systems with bond topology (bonds,
 angles, dihedrals, etc).  Thus if you model a molecular system with
 more than 2 billion atoms, you need the "bigbig" setting.
 Image flags store 3 values per atom which count the number of times an
 atom has moved through the periodic box in each dimension.  See the
 "dump"_dump.html doc page for a discussion.  If an atom moves through
 the periodic box more than this limit, the value will "roll over",
 e.g. from 511 to -512, which can cause diagnostics like the
 mean-squared displacement, as calculated by the "compute
 msd"_compute_msd.html command, to be faulty.
 Note that the USER-ATC package is not currently compatible with the
 "bigbig" setting.
 Also note that the GPU package requires its lib/gpu library to be
 compiled with the same size setting, or the link will fail.  A CMake
 build does this automatically.  When building with make, the setting
 in whichever lib/gpu/Makefile is used must be the same as above.
 :line
 Output of JPG, PNG, and movie files :h3,link(graphics)
 The "dump image"_dump_image.html command has options to output JPEG or
 PNG image files.  Likewise the "dump movie"_dump_image.html command
 ouputs movie files in MPEG format.  Using these options requires the
 following settings:
 [CMake variables]:
 -D WITH_JPEG=value      # yes or no
                          # default = yes if CMake finds JPEG files, else no
 -D WITH_PNG=value       # yes or no
                          # default = yes if CMake finds PNG and ZLIB files, else no
 -D WITH_FFMPEG=value    # yes or no
                          # default = yes if CMake can find ffmpeg, else no :pre
 Usually these settings are all that is needed.  If CMake cannot find
 the graphics header, library, executuable files, you can set these
 variables:
 -D JPEG_INCLUDE_DIR=path    # path to jpeglib.h header file 
 -D JPEG_LIBRARIES=path      # path to libjpeg.a (.so) file 
 -D PNG_INCLUDE_DIR=path     # path to png.h header file 
 -D PNG_LIBRARIES=path       # path to libpng.a (.so) file 
 -D ZLIB_INCLUDE_DIR=path    # path to zlib.h header file 
 -D ZLIB_LIBRARIES=path      # path to libz.a (.so) file 
 -D FFMPEG_EXECUTABLE=path   # path to ffmpeg executable :pre
 [Makefile.machine settings]:
 LMP_INC = -DLAMMPS_JPEG
 LMP_INC = -DLAMMPS_PNG
 LMP_INC = -DLAMMPS_FFMPEG :pre
 JPG_INC = -I/usr/local/include   # path to jpeglib.h, png.h, zlib.h header files if make cannot find them
 JPG_PATH = -L/usr/lib            # paths to libjpeg.a, libpng.a, libz.a (.so) files if make cannot find them
 JPG_LIB = -ljpeg -lpng -lz       # library names :pre
 As with CMake, you do not need to set JPG_INC or JPG_PATH, if make can
 find the graphics header and library files.  You must specify JPG_LIB
 with a list of graphics libraries to include in the link.  You must
 insure ffmpeg is in a directory where LAMMPS can find it at runtime,
 i.e. a dir in your PATH environment variable.
 [CMake and make info]:
 Using ffmpeg to output movie files requires that your machine
 supports the "popen" function in the standard runtime library.
 NOTE: On some clusters with high-speed networks, using the fork()
 library calls (required by popen()) can interfere with the fast
 communication library and lead to simulations using ffmpeg to hang or
 crash.
 :line
 Read or write compressed files :h3,link(gzip)
 If this option is enabled, large files can be read or written with
 gzip compression by several LAMMPS commands, including
 "read_data"_read_data.html, "rerun"_rerun.html, and "dump"_dump.html.
 [CMake variables]:
 -D WITH_GZIP=value       # yes or no
                         # default is yes if CMake can find gzip, else no
 -D GZIP_EXECUTABLE=path  # path to gzip executable if CMake cannot find it :pre
 [Makefile.machine setting]:
 LMP_INC = -DLAMMPS_GZIP :pre
 [CMake and make info]:
 This option requires that your machine supports the "popen()" function
 in the standard runtime library and that a gzip executable can be
 found by LAMMPS during a run.
 NOTE: On some clusters with high-speed networks, using the fork()
 library calls (required by popen()) can interfere with the fast
 communication library and lead to simulations using compressed output
 or input to hang or crash. For selected operations, compressed file
 I/O is also available using a compression library instead, which is
 what the "COMPRESS package"_Packages_details.html#PKG-COMPRESS enables.
 :line
 Memory allocation alignment :h3,link(align)
 This setting enables the use of the posix_memalign() call instead of
 malloc() when LAMMPS allocates large chunks or memory.  This can make
 vector instructions on CPUs more efficient, if dynamically allocated
 memory is aligned on larger-than-default byte boundaries.
 On most current systems, the malloc() implementation returns
 pointers that are aligned to 16-byte boundaries. Using SSE vector
 instructions efficiently, however, requires memory blocks being
 aligned on 64-byte boundaries.
 [CMake variable]:
 -D LAMMPS_MEMALIGN=value            # 0, 8, 16, 32, 64 (default) :pre
 Use a LAMMPS_MEMALIGN value of 0 to disable using posix_memalign()
 and revert to using the malloc() C-library function instead.  When
 compiling LAMMPS for Windows systems, malloc() will always be used
 and this setting ignored.
 [Makefile.machine setting]:
 LMP_INC = -DLAMMPS_MEMALIGN=value   # 8, 16, 32, 64 :pre
 Do not set -DLAMMPS_MEMALIGN, if you want to have memory allocated
 with the malloc() function call instead. -DLAMMPS_MEMALIGN [cannot]
 be used on Windows, as it does use different function calls for
 allocating aligned memory, that are not compatible with how LAMMPS
 manages its dynamical memory.
 :line
 Workaround for long long integers :h3,link(longlong)
 If your system or MPI version does not recognize "long long" data
 types, the following setting will be needed.  It converts "long long"
 to a "long" data type, which should be the desired 8-byte integer on
 those systems:
 [CMake variable]:
 -D LAMMPS_LONGLONG_TO_LONG=value     # yes or no (default) :pre
 [Makefile.machine setting]:
 LMP_INC = -DLAMMPS_LONGLONG_TO_LONG :pre
 :line
 Exception handling when using LAMMPS as a library :h3,link(exceptions)
 This setting is useful when external codes drive LAMMPS as a library.
 With this option enabled LAMMPS errors do not kill the caller.
 Instead, the call stack is unwound and control returns to the caller,
 e.g. to Python.
 [CMake variable]:
 -D LAMMPS_EXCEPTIONS=value        # yes or no (default) :pre
 [Makefile.machine setting]:
 LMP_INC = -DLAMMPS_EXCEPTIONS :pre
--- a/doc/src/Commands.txt
+++ b/doc/src/Commands.txt
@ -16,6 +16,7 @@ commands in it are used to define a LAMMPS simulation.
 <!-- RST
 .. toctree::
   :maxdepth: 1
   Commands_input
   Commands_parse
@ -23,6 +24,7 @@ commands in it are used to define a LAMMPS simulation.
   Commands_category
 .. toctree::
   :maxdepth: 1
   Commands_all
   Commands_fix
--- a/doc/src/Commands_bond.txt
+++ b/doc/src/Commands_bond.txt
@ -9,7 +9,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 "Fix styles"_Commands_fix.html,
 "Compute styles"_Commands_compute.html,
 "Pair styles"_Commands_pair.html,
-"Bond styles"_Commands_bond.html,
+"Bond styles"_Commands_bond.html#bond,
 "Angle styles"_Commands_bond.html#angle,
 "Dihedral styles"_Commands_bond.html#dihedral,
 "Improper styles"_Commands_bond.html#improper,
--- a/doc/src/Errors.txt
+++ b/doc/src/Errors.txt
@ -1,4 +1,4 @@
-"Previous Section"_Python.html - "LAMMPS WWW Site"_lws -
+"Previous Section"_Python_head.html - "LAMMPS WWW Site"_lws -
 "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
 Section"_Manual.html :c
@ -19,6 +19,7 @@ additional details for many of them.
 <!-- RST
 .. toctree::
   :maxdepth: 1
   Errors_common
   Errors_bugs
--- a/doc/src/Errors_common.txt
+++ b/doc/src/Errors_common.txt
@ -58,9 +58,9 @@ 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
+command-line swith"_Run_options.html.  The installation and
-and compilation of optional packages is explained in the "installation
+compilation of optional packages is explained on the "Build
-instructions"_Section_start.html#start_3.
+packages"_Build_package.html doc page.
 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
@ -93,7 +93,7 @@ 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
+could be a bug (see "this section"_Errors_bugs.html) or one of the following
 cases:
 LAMMPS runs in the available memory a processor allows to be
--- a/doc/src/Errors_messages.txt
+++ b/doc/src/Errors_messages.txt
@ -7911,8 +7911,8 @@ Atom IDs must be positive integers. :dd
 {One or more atom IDs is too big} :dt
 The limit on atom IDs is set by the SMALLBIG, BIGBIG, SMALLSMALL
-setting in your Makefile.  See Section_start 2.2 of the manual for
+setting in your LAMMPS build.  See the "Build
-more details. :dd
+settings"_Build_settings.html doc page for more info. :dd
 {One or more atom IDs is zero} :dt
--- a/doc/src/Examples.txt
+++ b/doc/src/Examples.txt
@ -112,10 +112,10 @@ web site.
 If you uncomment the "dump image"_dump_image.html line(s) in the input
 script a series of JPG images will be produced by the run (assuming
-you built LAMMPS with JPG support; see "Section
+you built LAMMPS with JPG support; see the
-2.2"_Section_start.html#start_2 for details).  These can be viewed
+"Build_settings"_Build_settings.html doc page for details).  These can
-individually or turned into a movie or animated by tools like
+be viewed individually or turned into a movie or animated by tools
-ImageMagick or QuickTime or various Windows-based tools.  See the
+like ImageMagick or QuickTime or various Windows-based tools.  See the
 "dump image"_dump_image.html doc page for more details.  E.g. this
 Imagemagick command would create a GIF file suitable for viewing in a
 browser.
--- a/doc/src/Howto.txt
+++ b/doc/src/Howto.txt
@ -22,12 +22,14 @@ also show how to setup and run various kinds of simulations.
 <!-- RST
 .. toctree::
   :maxdepth: 1
   Howto_github
   Howto_pylammps
   Howto_bash
 .. toctree::
   :maxdepth: 1
   Howto_restart
   Howto_viz
@ -37,11 +39,13 @@ also show how to setup and run various kinds of simulations.
   Howto_couple
 .. toctree::
   :maxdepth: 1
   Howto_output
   Howto_chunk
 .. toctree::
   :maxdepth: 1
   Howto_2d
   Howto_triclinic
@ -52,6 +56,7 @@ also show how to setup and run various kinds of simulations.
   Howto_dispersion
 .. toctree::
   :maxdepth: 1
   Howto_temperature
   Howto_thermostat
@ -62,6 +67,7 @@ also show how to setup and run various kinds of simulations.
   Howto_diffusion
 .. toctree::
   :maxdepth: 1
   Howto_bioFF
   Howto_tip3p
@ -69,6 +75,7 @@ also show how to setup and run various kinds of simulations.
   Howto_spc
 .. toctree::
   :maxdepth: 1
   Howto_body
   Howto_polarizable
@ -84,7 +91,7 @@ END_RST -->
 "Using GitHub with LAMMPS"_Howto_github.html
 "PyLAMMPS interface to LAMMPS"_Howto_pylammps.html
-"Using LAMMPS with bash on Windows"_Howto_bash.html
+"Using LAMMPS with bash on Windows"_Howto_bash.html :all(b)
 "Restart a simulation"_Howto_restart.html
 "Visualize LAMMPS snapshots"_Howto_viz.html
@ -121,8 +128,8 @@ END_RST -->
 "Polarizable models"_Howto_polarizable.html
 "Adiabatic core/shell model"_Howto_coreshell.html
 "Drude induced dipoles"_Howto_drude.html
-"Drude induced dipoles (extended)"_Howto_drude2.html :all(b)
+"Drude induced dipoles (extended)"_Howto_drude2.html
 "Manifolds (surfaces)"_Howto_manifold.html
-"Magnetic spins"_Howto_spins.html
+"Magnetic spins"_Howto_spins.html :all(b)
 <!-- END_HTML_ONLY -->
--- a/doc/src/Howto_bioFF.txt
+++ b/doc/src/Howto_bioFF.txt
@ -96,6 +96,10 @@ documentation for the formula it computes.
 [(MacKerell)] MacKerell, Bashford, Bellott, Dunbrack, Evanseck, Field,
 Fischer, Gao, Guo, Ha, et al, J Phys Chem, 102, 3586 (1998).
 :link(howto-Cornell)
 [(Cornell)] Cornell, Cieplak, Bayly, Gould, Merz, Ferguson,
 Spellmeyer, Fox, Caldwell, Kollman, JACS 117, 5179-5197 (1995).
 :link(howto-Mayo)
 [(Mayo)] Mayo, Olfason, Goddard III, J Phys Chem, 94, 8897-8909
 (1990).
--- a/doc/src/Howto_coreshell.txt
+++ b/doc/src/Howto_coreshell.txt
@ -119,7 +119,7 @@ the core/shell pair, which is an imaginary degree of freedom, from the
 real physical system.  To do that, the "compute
 temp/cs"_compute_temp_cs.html command can be used, in conjunction with
 any of the thermostat fixes, such as "fix nvt"_fix_nh.html or "fix
-langevin"_fix_langevin.  This compute uses the center-of-mass velocity
+langevin"_fix_langevin.html.  This compute uses the center-of-mass velocity
 of the core/shell pairs to calculate a temperature, and insures that
 velocity is what is rescaled for thermostatting purposes.  This
 compute also works for a system with both core/shell pairs and
@ -150,9 +150,9 @@ The pressure for the core/shell system is computed via the regular
 LAMMPS convention by "treating the cores and shells as individual
 particles"_#MitchellFincham2. For the thermo output of the pressure
 as well as for the application of a barostat, it is necessary to
-use an additional "pressure"_compute_pressure compute based on the
+use an additional "pressure"_compute_pressure.html compute based on
-default "temperature"_compute_temp and specifying it as a second
+the default "temperature"_compute_temp.html and specifying it as a
-argument in "fix modify"_fix_modify.html and
+second argument in "fix modify"_fix_modify.html and
 "thermo_modify"_thermo_modify.html resulting in:
 (...)
--- a/doc/src/Howto_couple.txt
+++ b/doc/src/Howto_couple.txt
@ -77,17 +77,16 @@ strain induced across grain boundaries :l
 :link(quest,http://dft.sandia.gov/Quest)
 :link(spparks,http://www.sandia.gov/~sjplimp/spparks.html)
-"This section"_Section_start.html#start_5 of the documentation
+The "Build basics"_Build_basics.html doc page describes how to build
-describes how to build LAMMPS as a library.  Once this is done, you
+LAMMPS as a library.  Once this is done, you can interface with LAMMPS
-can interface with LAMMPS either via C++, C, Fortran, or Python (or
+either via C++, C, Fortran, or Python (or any other language that
-any other language that supports a vanilla C-like interface).  For
+supports a vanilla C-like interface).  For example, from C++ you could
-example, from C++ you could create one (or more) "instances" of
+create one (or more) "instances" of LAMMPS, pass it an input script to
-LAMMPS, pass it an input script to process, or execute individual
+process, or execute individual commands, all by invoking the correct
-commands, all by invoking the correct class methods in LAMMPS.  From C
+class methods in LAMMPS.  From C or Fortran you can make function
-or Fortran you can make function calls to do the same things.  See the
+calls to do the same things.  See the "Python"_Python_head.html doc
-"Python"_Python.html doc pages for a description of the Python wrapper
+pages for a description of the Python wrapper provided with LAMMPS
-provided with LAMMPS that operates through the LAMMPS library
+that operates through the LAMMPS library interface.
 interface.
 The files src/library.cpp and library.h contain the C-style interface
 to LAMMPS.  See the "Howto library"_Howto_library.html doc page for a
--- a/doc/src/Howto_granular.txt
+++ b/doc/src/Howto_granular.txt
@ -53,5 +53,5 @@ computations between frozen atoms by using this command:
 NOTE: By default, for 2d systems, granular particles are still modeled
 as 3d spheres, not 2d discs (circles), meaning their moment of inertia
 will be the same as in 3d.  If you wish to model granular particles in
-2d as 2d discs, see the note on this topic on the "Howto 2d"_Howto_2d
+2d as 2d discs, see the note on this topic on the "Howto 2d"_Howto_2d.html
 doc page, where 2d simulations are discussed.
--- a/doc/src/Howto_library.txt
+++ b/doc/src/Howto_library.txt
@ -9,10 +9,10 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 Library interface to LAMMPS :h3
-As described in "Section 2.5"_Section_start.html#start_5, LAMMPS can
+As described on the "Build basics"_Build_basics.html doc page, LAMMPS
-be built as a library, so that it can be called by another code, used
+can be built as a library, so that it can be called by another code,
-in a "coupled manner"_Howto_couple.html with other codes, or driven
+used in a "coupled manner"_Howto_couple.html with other codes, or
-through a "Python interface"_Python.html.
+driven through a "Python interface"_Python_head.html.
 All of these methodologies use a C-style interface to LAMMPS that is
 provided in the files src/library.cpp and src/library.h.  The
@ -35,8 +35,8 @@ details.
 NOTE: You can write code for additional functions as needed to define
 how your code talks to LAMMPS and add them to src/library.cpp and
-src/library.h, as well as to the "Python interface"_Python.html.  The
+src/library.h, as well as to the "Python interface"_Python_head.html.
-added functions can access or change any internal LAMMPS data you
+The added functions can access or change any internal LAMMPS data you
 wish.
 void lammps_open(int, char **, MPI_Comm, void **)
@ -51,12 +51,11 @@ void lammps_free(void *) :pre
 The lammps_open() function is used to initialize LAMMPS, passing in a
 list of strings as if they were "command-line
-arguments"_Section_start.html#start_6 when LAMMPS is run in
+arguments"_Run_options.html when LAMMPS is run in stand-alone mode
-stand-alone mode from the command line, and a MPI communicator for
+from the command line, and a MPI communicator for LAMMPS to run under.
-LAMMPS to run under.  It returns a ptr to the LAMMPS object that is
+It returns a ptr to the LAMMPS object that is created, and which is
-created, and which is used in subsequent library calls.  The
+used in subsequent library calls.  The lammps_open() function can be
-lammps_open() function can be called multiple times, to create
+called multiple times, to create multiple instances of LAMMPS.
 multiple instances of LAMMPS.
 LAMMPS will run on the set of processors in the communicator.  This
 means the calling code can run LAMMPS on all or a subset of
--- a/doc/src/Howto_multiple.txt
+++ b/doc/src/Howto_multiple.txt
@ -80,8 +80,7 @@ jump in.polymer :pre
 All of the above examples work whether you are running on 1 or
 multiple processors, but assumed you are running LAMMPS on a single
 partition of processors.  LAMMPS can be run on multiple partitions via
-the "-partition" command-line switch as described in "this
+the "-partition command-line switch"_Run_options.html.
 section"_Section_start.html#start_6 of the manual.
 In the last 2 examples, if LAMMPS were run on 3 partitions, the same
 scripts could be used if the "index" and "loop" variables were
--- a/doc/src/Howto_replica.txt
+++ b/doc/src/Howto_replica.txt
@ -29,29 +29,28 @@ runs different replicas at a series of temperature to facilitate
 rare-event sampling.
 These commands can only be used if LAMMPS was built with the REPLICA
-package.  See the "Making LAMMPS"_Section_start.html#start_3 section
+package.  See the "Build package"_Build_package.html doc page for more
-for more info on packages.
+info.
 PIMD runs different replicas whose individual particles are coupled
 together by springs to model a system or ring-polymers.
 This commands can only be used if LAMMPS was built with the USER-MISC
-package.  See the "Making LAMMPS"_Section_start.html#start_3 section
+package.  See the "Build package"_Build_package.html doc page for more
-for more info on packages.
+info.
 In all these cases, you must run with one or more processors per
 replica.  The processors assigned to each replica are determined at
 run-time by using the "-partition command-line
-switch"_Section_start.html#start_6 to launch LAMMPS on multiple
+switch"_Run_options.html to launch LAMMPS on multiple partitions,
-partitions, which in this context are the same as replicas.  E.g.
+which in this context are the same as replicas.  E.g.  these commands:
 these commands:
 mpirun -np 16 lmp_linux -partition 8x2 -in in.temper
 mpirun -np 8 lmp_linux -partition 8x1 -in in.neb :pre
 would each run 8 replicas, on either 16 or 8 processors.  Note the use
-of the "-in command-line switch"_Section_start.html#start_6 to specify
+of the "-in command-line switch"_Run_options.html to specify the input
-the input script which is required when running in multi-replica mode.
+script which is required when running in multi-replica mode.
 Also note that with MPI installed on a machine (e.g. your desktop),
 you can run on more (virtual) processors than you have physical
--- a/doc/src/Howto_restart.txt
+++ b/doc/src/Howto_restart.txt
@ -16,8 +16,8 @@ restart files can be saved to disk using the "restart"_restart.html
 command.  At a later time, these binary files can be read via a
 "read_restart"_read_restart.html command in a new script.  Or they can
 be converted to text data files using the "-r command-line
-switch"_Section_start.html#start_6 and read by a
+switch"_Run_options.html and read by a "read_data"_read_data.html
-"read_data"_read_data.html command in a new script.
+command in a new script.
 Here we give examples of 2 scripts that read either a binary restart
 file or a converted data file and then issue a new run command to
--- a/doc/src/Howto_temperature.txt
+++ b/doc/src/Howto_temperature.txt
@ -17,7 +17,10 @@ aggregate motion of particles) and its thermal velocity.  The sum of
 the two is the particle's total velocity, but the latter is often what
 is wanted to compute a temperature.
-LAMMPS has several options for computing temperatures, any of which can be used in "thermostatting"_Howto_thermostat.html and "barostatting"_Howto_barostat.html.  These "compute commands"_compute.html calculate temperature:
+LAMMPS has several options for computing temperatures, any of which
 can be used in "thermostatting"_Howto_thermostat.html and
 "barostatting"_Howto_barostat.html.  These "compute
 commands"_compute.html calculate temperature:
 "compute temp"_compute_temp.html
 "compute temp/sphere"_compute_temp_sphere.html
@ -35,6 +38,6 @@ velocities) that are removed when computing the thermal temperature.
 temp/asphere"_compute_temp_asphere.html compute kinetic energy for
 finite-size particles that includes rotational degrees of freedom.
 They both allow for velocity biases indirectly, via an optional extra
-argument which is another temperature compute that subtracts a velocity bias.
+argument which is another temperature compute that subtracts a
-This allows the translational velocity of spherical or aspherical
+velocity bias.  This allows the translational velocity of spherical or
-particles to be adjusted in prescribed ways.
+aspherical particles to be adjusted in prescribed ways.
--- a/doc/src/Howto_tip4p.txt
+++ b/doc/src/Howto_tip4p.txt
@ -31,7 +31,7 @@ using the "fix shake"_fix_shake.html command.
 These are the additional parameters (in real units) to set for O and H
 atoms and the water molecule to run a rigid TIP4P model with a cutoff
-"(Jorgensen)"_#Jorgensen1.  Note that the OM distance is specified in
+"(Jorgensen)"_#Jorgensen5.  Note that the OM distance is specified in
 the "pair_style"_pair_style.html command, not as part of the pair
 coefficients.
@ -107,6 +107,6 @@ models"_http://en.wikipedia.org/wiki/Water_model.
 :line
-:link(Jorgensen1)
+:link(Jorgensen5)
 [(Jorgensen)] Jorgensen, Chandrasekhar, Madura, Impey, Klein, J Chem
 Phys, 79, 926 (1983).
--- a/doc/src/Install.txt
+++ b/doc/src/Install.txt
@ -0,0 +1,65 @@
 "Previous Section"_Intro.html - "LAMMPS WWW Site"_lws - "LAMMPS
 Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Build.html
 :c
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
 :link(lc,Commands_all.html)
 :line
 Install LAMMPS :h2
 You can download LAMMPS as an executable or as source code.
 With source code, you also have to "build LAMMPS"_Build.html.  But you
 have more flexibility as to what features to include or exclude in the
 build.  If you plan to "modify or extend LAMMPS"_Modify.html, then you
 need the source code.
 <!-- RST
 .. toctree::
   :maxdepth: 1
   Install_linux
   Install_mac
   Install_windows
   Install_tarball
   Install_git
   Install_svn
   Install_patch
 END_RST -->
 <!-- HTML_ONLY -->
 "Download an executable for Linux"_Install_linux.html
 "Download an executable for Mac"_Install_mac.html
 "Download an executable for Windows"_Install_windows.html :all(b)
 "Download source as a tarball"_Install_tarball.html
 "Donwload source via Git"_Install_git.html
 "Donwload source via SVN"_Install_svn.html
 "Install patch files"_Install_patch.html :all(b)
 <!-- END_HTML_ONLY -->
 These are the files and sub-directories in the LAMMPS distribution:
 README: text file
 LICENSE: GNU General Public License (GPL)
 bench: benchmark problems
 cmake: CMake build files
 doc: documentation
 examples: simple test problems
 lib: additional provided or external libraries
 potentials: interatomic potential files
 python: Python wrapper on LAMMPS
 src: source files
 tools: pre- and post-processing tools :tb(s=:,a=l)
 You will have all of these if you download source.  You will only have
 some of them if you download executables, as explained on the pages
 listed above.
--- a/doc/src/Install_git.txt
+++ b/doc/src/Install_git.txt
@ -0,0 +1,120 @@
 "Higher level section"_Install.html - "LAMMPS WWW Site"_lws - "LAMMPS
 Documentation"_ld - "LAMMPS Commands"_lc :c
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
 :link(lc,Commands_all.html)
 :line
 Download source via Git :h3
 All LAMMPS development is coordinated through the "LAMMPS GitHub
 site".  If you clone the LAMMPS repository onto your local machine, it
 has several advantages:
 You can stay current with changes to LAMMPS with a single git
 command. :ulb,l
 You can create your own development branches to add code to LAMMPS. :l
 You can submit your new features back to GitHub for inclusion in
 LAMMPS. :l,ule
 You must have "Git"_git installed on your system to communicate with
 the public Git server for LAMMPS.
 IMPORTANT NOTE: As of Oct 2016, the official home of public LAMMPS
 development is on GitHub.  The previously advertised LAMMPS git
 repositories on git.lammps.org and bitbucket.org are now deprecated,
 may not be up-to-date, and may go away at any time.
 :link(git,http://git-scm.com)
 You can follow LAMMPS development on 3 different Git branches:
 [stable]   :  this branch is updated with every stable release
 [unstable] :  this branch is updated with every patch release
 [master]   :  this branch continuously follows ongoing development :ul
 To access the Git repositories on your box, use the clone command to
 create a local copy of the LAMMPS repository with a command like:
 git clone -b unstable https://github.com/lammps/lammps.git mylammps :pre
 where "mylammps" is the name of the directory you wish to create on
 your machine and "unstable" is one of the 3 branches listed above.
 (Note that you actually download all 3 branches; you can switch
 between them at any time using "git checkout <branchname>".)
 Once the command completes, your directory will contain the same files
 as if you unpacked a current LAMMPS tarball, with two exceptions:
 1) No LAMMPS packages are initially installed in the src dir (a few
 packages are installed by default in the tarball src dir).  You can
 install whichever packages you wish before building LAMMPS; type "make
 package" from the src dir to see the options, and the
 "Packages"_Packages.html doc page for a discussion of packages.
 2) The HTML documentation files are not included.  They can be fetched
 from the LAMMPS website by typing "make fetch" in the doc directory.
 Or they can be generated from the content provided in doc/src by
 typing "make html" from the the doc directory.
 After initial cloning, as bug fixes and new features are added to
 LAMMPS, as listed on "this page"_Errors_bugs.html, you can stay
 up-to-date by typing the following Git commands from within the
 "mylammps" directory:
 git checkout unstable      # not needed if you always stay in this branch
 git checkout stable        # use one of the 3 checkout commands
 git checkout master
 git pull :pre
 Doing a "pull" will not change any files you have added to the LAMMPS
 directory structure.  It will also not change any existing LAMMPS
 files you have edited, unless those files have changed in the
 repository.  In that case, Git will attempt to merge the new
 repository file with your version of the file and tell you if there
 are any conflicts.  See the Git documentation for details.
 If you want to access a particular previous release version of LAMMPS,
 you can instead "checkout" any version with a published tag. See the
 output of "git tag -l" for the list of tags.  The Git command to do
 this is as follows.
 git checkout tagID :pre
 Stable versions and what tagID to use for a particular stable version
 are discussed on "this page"_Errors_bugs.html.  Note that this command
 will print some warnings, because in order to get back to the latest
 revision and to be able to update with "git pull" again, you first
 will need to first type "git checkout unstable" (or check out any
 other desired branch).
 Once you have updated your local files with a "git pull" (or "git
 checkout"), you still need to re-build LAMMPS if any source files have
 changed.  To do this, you should cd to the src directory and type:
 make purge             # remove any deprecated src files
 make package-update    # sync package files with src files
 make foo               # re-build for your machine (mpi, serial, etc) :pre
 just as described on the "Install patch"_Install_patch.html doc page,
 after a patch has been installed.
 IMPORTANT NOTE: If you wish to edit/change a src file that is from a
 package, you should edit the version of the file inside the package
 sub-directory with src, then re-install the package.  The version in
 the src dir is merely a copy and will be wiped out if you type "make
 package-update".
 IMPORTANT NOTE: The GitHub servers support both the "git://" and
 "https://" access protocols for anonymous read-only access.  If you
 have a correspondingly configured GitHub account, you may also use SSH
 with "git@github.com:/lammps/lammps.git".
 The LAMMPS GitHub project is managed by Christoph Junghans (LANL,
 junghans at lanl.gov), Axel Kohlmeyer (Temple U, akohlmey at
 gmail.com) and Richard Berger (Temple U, richard.berger at
 temple.edu).
--- a/doc/src/Install_linux.txt
+++ b/doc/src/Install_linux.txt
@ -0,0 +1,119 @@
 "Higher level section"_Install.html - "LAMMPS WWW Site"_lws - "LAMMPS
 Documentation"_ld - "LAMMPS Commands"_lc :c
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
 :link(lc,Commands_all.html)
 :line
 Download an executable for Linux :h3
 Binaries are available for many different versions of Linux:
 "Pre-built binary RPMs for Fedora/RedHat/CentOS/openSUSE"_#rpm
 "Pre-built Ubuntu Linux executables"_#ubuntu
 "Pre-built Gentoo Linux executable"_#gentoo :all(b)
 :line
 Pre-built binary RPMs for Fedora/RedHat/CentOS/openSUSE :h4,link(rpm)
 Pre-built LAMMPS executables for various Linux distributions
 can be downloaded as binary RPM files from this site:
 "http://rpm.lammps.org"_http://rpm.lammps.org
 There are multiple package variants supporting serial, parallel and
 Python wrapper versions.  The LAMMPS binaries contain all optional
 packages included in the source distribution except: GPU, KIM, REAX,
 and USER-INTEL.
 Installation instructions for the various versions are here:
 "http://rpm.lammps.org/install.html"_http://rpm.lammps.org/install.html
 The instructions show how to enable the repository in the respective
 system's package management system.  Installing and updating are then
 straightforward and automatic.  
 Thanks to Axel Kohlmeyer (Temple U, akohlmey at gmail.com) for setting
 up this RPM capability.
 :line
 Pre-built Ubuntu Linux executables :h4,link(ubuntu)
 A pre-built LAMMPS executable suitable for running on the latest
 Ubuntu Linux versions, can be downloaded as a Debian package.  This
 allows you to install LAMMPS with a single command, and stay
 up-to-date with the current version of LAMMPS by simply updating your
 operating system.
 To install the appropriate personal-package archive (PPA), do the
 following once:
 sudo add-apt-repository ppa:gladky-anton/lammps
 sudo apt-get update :pre
 To install LAMMPS do the following once:
 sudo apt-get install lammps-daily :pre
 This downloads an executable named "lammps-daily" to your box, which
 can then be used in the usual way to run input scripts:
 lammps-daily < in.lj :pre
 To update LAMMPS to the most current version, do the following:
 sudo apt-get update :pre
 which will also update other packages on your system.
 To get a copy of the current documentation and examples:
 sudo apt-get install lammps-daily-doc :pre
 which will download the doc files in
 /usr/share/doc/lammps-daily-doc/doc and example problems in
 /usr/share/doc/lammps-doc/examples.
 Note that you may still wish to download the tarball to get potential
 files and auxiliary tools.
 To un-install LAMMPS, do the following:
 sudo apt-get remove lammps-daily :pre
 Note that the lammps-daily executable is built with the following
 sequence of make commands, as if you had done the same with the
 unpacked tarball files in the src directory:
 make yes-all; make no-lib; make openmpi
 Thus it builds with FFTW3 and OpenMPI.
 Thanks to Anton Gladky (gladky.anton at gmail.com) for setting up this
 Ubuntu package capability.
 :line
 Pre-built Gentoo Linux executable :h4,link(gentoo)
 LAMMPS is part of Gentoo's main package tree and can be installed by
 typing:
 % emerge --ask lammps :pre
 Note that in Gentoo the LAMMPS source is downloaded and the package is
 built on the your machine.
 Certain LAMMPS packages can be enable via USE flags, type
 % equery uses lammps :pre
 for details.
 Thanks to Nicolas Bock and Christoph Junghans (LANL) for setting up
 this Gentoo capability.
--- a/doc/src/Install_mac.txt
+++ b/doc/src/Install_mac.txt
@ -0,0 +1,55 @@
 "Higher level section"_Install.html - "LAMMPS WWW Site"_lws - "LAMMPS
 Documentation"_ld - "LAMMPS Commands"_lc :c
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
 :link(lc,Commands_all.html)
 :line
 Download an executable for Mac :h3
 LAMMPS can be downloaded, built, and configured for OS X on a Mac with
 "Homebrew"_homebrew.  Only four of the LAMMPS packages are unavailable
 at this time because of additional needs not yet met: KIM, GPU,
 USER-INTEL, USER-ATC.
 After installing Homebrew, you can install LAMMPS on your system with
 the following commands:
 % brew tap homebrew/science
 % brew install lammps              # serial version
 % brew install lammps --with-mpi   # mpi support :pre
 This will install the executable "lammps", a python module named
 "lammps", and additional resources with all the standard packages.  To
 get the location of the additional resources type this:
 % brew info lammps :pre
 This command also tells you additional installation options available.
 The user-packages are available as options, just install them like
 this example for the USER-OMP package:
 % brew install lammps --enable-user-omp :pre
 It is usually best to install LAMMPS with the most up to date source
 files, which can be done with the "--HEAD" option:
 % brew install lammps --HEAD :pre
 To re-install the LAMMPS HEAD, run this command occasionally (make sure
 to use the desired options).
 % brew install --force lammps --HEAD $\{options\} :pre
 Once LAMMPS is installed, you can test the installation with the
 Lennard-Jones benchmark file:
 % brew test lammps -v :pre
 If you have problems with the installation you can post issues to
 "this link"_https://github.com/Homebrew/homebrew-science/issues.
 Thanks to Derek Thomas (derekt at cello.t.u-tokyo.ac.jp) for setting
 up the Homebrew capability.
--- a/doc/src/Install_patch.txt
+++ b/doc/src/Install_patch.txt
@ -0,0 +1,67 @@
 "Higher level section"_Install.html - "LAMMPS WWW Site"_lws - "LAMMPS
 Documentation"_ld - "LAMMPS Commands"_lc :c
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
 :link(lc,Commands_all.html)
 :line
 Applying patches :h3
 It is easy to stay current with the most recent LAMMPS patch releases
 if you use Git or SVN to track LAMMPS development.  Instructions for
 how to stay current are on the "Install git"_Install_git.html and
 "Install svn"_Install_svn.html doc pages.
 If you prefer to download a tarball, as described on the "Install
 git"_Install_tarball.html doc page, you can stay current by
 downloading "patch files" when new patch releases are made.  A link to
 a patch file is posted on the "bug and feature page"_bug of the
 website, along with a list of changed files and details about what is
 in the new patch release.  This page explains how to apply the patch
 file to your local LAMMPS directory.
 NOTE: You should not apply patch files to a local Git or SVN repo of
 LAMMPS, only to an unpacked tarball.  Use Git and SVN commands to
 update repo versions of LAMMPS.
 Here are the steps to apply a patch file.  Note that if your version
 of LAMMPS is several patch releases behind, you need to apply all the
 intervening patch files in succession to bring your version of LAMMPS
 up to date.
 Download the patch file.  You may have to shift-click in your browser
 to download the file instead of display it.  Patch files have names
 like patch.12Dec16. :ulb,l
 Put the patch file in your top-level LAMMPS directory, where the
 LICENSE and README files are. :l
 Apply the patch by typing the following command from your top-level
 LAMMPS directory, where the redirected file is the name of the patch
 file. :l
 patch -bp1 < patch.12Dec16 :pre
 A list of updated files print out to the screen.  The -b switch
 creates backup files of your originals (e.g. src/force.cpp.orig), so
 you can manually undo the patch if something goes wrong. :l
 Type the following from the src directory, to enforce consistency
 between the src and package directories.  This is OK to do even if you
 don't use one or more packages.  If you are applying several patches
 successively, you only need to type this once at the end. The purge
 command removes deprecated src files if any were removed by the patch
 from package sub-directories. :l
 make purge
 make package-update :pre
 Re-build LAMMPS via the "make" command. :l,ule
 IMPORTANT NOTE: If you wish to edit/change a src file that is from a
 package, you should edit the version of the file inside the package
 sub-dir of src, then re-install the package.  The version in the src
 dir is merely a copy and will be wiped out if you type "make
 package-update".
--- a/doc/src/Install_svn.txt
+++ b/doc/src/Install_svn.txt
@ -0,0 +1,95 @@
 "Higher level section"_Install.html - "LAMMPS WWW Site"_lws - "LAMMPS
 Documentation"_ld - "LAMMPS Commands"_lc :c
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
 :link(lc,Commands_all.html)
 :line
 Download source via SVN :h3
 IMPORTANT NOTE: As of Oct 2016, SVN support is now implemented via a
 git-to-subversion interface service on GitHub and no longer through a
 mirror of the internal SVN repository at Sandia.
 You must have the "Subversion (SVN) client software"_svn installed on
 your system to communicate with the Git server in this mode.
 :link(svn,http://subversion.apache.org)
 You can follow LAMMPS development on 3 different SVN branches:
 [stable]   :  this branch is updated with every stable release
 [unstable] :  this branch is updated with every patch release
 [master]   :  this branch continuously follows ongoing development :ul
 The corresponding command lines to do an initial checkout are as
 follows.  (Note that unlike Git, you must perform a separate checkout
 into a unique directory for each of the 3 branches.)
 svn checkout https://github.com/lammps/lammps.git/branches/unstable mylammps
 svn checkout https://github.com/lammps/lammps.git/branches/stable mylammps
 svn checkout https://github.com/lammps/lammps.git/trunk mylammps :pre
 where "mylammps" is the name of the directory you wish to create on
 your machine.
 Once the command completes, your directory will contain the same files
 as if you unpacked a current LAMMPS tarball, with two exceptions:
 1) No LAMMPS packages are initially installed in the src dir (a few
 packages are installed by default in the tarball src dir).  You can
 install whichever packages you wish before building LAMMPS; type "make
 package" from the src dir to see the options, and the
 "Packages"_Packages.html doc page for a discussion of packages.
 2) The HTML documentation files are not included.  They can be fetched
 from the LAMMPS website by typing "make fetch" in the doc directory.
 Or they can be generated from the content provided in doc/src by
 typing "make html" from the the doc directory.
 After initial checkout, as bug fixes and new features are added to
 LAMMPS, as listed on "this page"_Errors_bugs.html, you can stay
 up-to-date by typing the following SVN commands from within the
 "mylammps" directory:
 svn update :pre
 You can also check if there are any updates by typing:
 svn -qu status :pre
 Doing an "update" will not change any files you have added to the
 LAMMPS directory structure.  It will also not change any existing
 LAMMPS files you have edited, unless those files have changed in the
 repository.  In that case, SVN will attempt to merge the new
 repository file with your version of the file and tell you if there
 are any conflicts.  See the SVN documentation for details.
 Please refer to the "subversion client support help pages on
 GitHub"_https://help.github.com/articles/support-for-subversion-clients
 if you want to use advanced features like accessing particular
 previous release versions via tags.
 Once you have updated your local files with an "svn update" (or "svn
 co"), you still need to re-build LAMMPS if any source files have
 changed.  To do this, you should cd to the src directory and type:
 make purge             # remove any deprecated src files
 make package-update    # sync package files with src files
 make foo               # re-build for your machine (mpi, serial, etc) :pre
 just as described on the "Install patch"_Install_patch.html doc page,
 after a patch has been installed.
 IMPORTANT NOTE: If you wish to edit/change a src file that is from a
 package, you should edit the version of the file inside the package
 sub-directory with src, then re-install the package.  The version in
 the src dir is merely a copy and will be wiped out if you type "make
 package-update".
 The LAMMPS GitHub project is managed by Christoph Junghans (LANL,
 junghans at lanl.gov), Axel Kohlmeyer (Temple U, akohlmey at
 gmail.com) and Richard Berger (Temple U, richard.berger at
 temple.edu).
--- a/doc/src/Install_tarball.txt
+++ b/doc/src/Install_tarball.txt
@ -0,0 +1,64 @@
 "Higher level section"_Install.html - "LAMMPS WWW Site"_lws - "LAMMPS
 Documentation"_ld - "LAMMPS Commands"_lc :c
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
 :link(lc,Commands_all.html)
 :line
 Download source as a tarball :h3
 You can download a current LAMMPS tarball from the "download page"_download
 of the "LAMMPS website"_lws.
 :link(download,http://lammps.sandia.gov/download.html)
 :link(bug,http://lammps.sandia.gov/bug.html)
 :link(older,http://lammps.sandia.gov/tars)
 You have two choices of tarballs, either the most recent stable
 release or the most current patch release.  Stable releases occur a
 few times per year, and undergo more testing before release.  Patch
 releases occur a couple times per month.  The new contents in all
 releases are listed on the "bug and feature page"_bug of the website.
 Older versions of LAMMPS can also be downloaded from "this
 page"_older.
 Once you have a tarball, unzip and untar it with the following
 command:
 tar -xzvf lammps*.tar.gz :pre
 This will create a LAMMPS directory with the version date
 in its name, e.g. lammps-23Jun18.
 :line
 You can also download a zip file via the "Clone or download" button on
 the "LAMMPS GitHub site"_git.  The file name will be lammps-master.zip
 which can be unzipped with the following command, to create
 a lammps-master dir:
 unzip lammps*.zip :pre
 This version is the most up-to-date LAMMPS development version.  It
 will have the date of the most recent patch release (see the file
 src/version.h).  But it will also include any new bug-fixes or
 features added since the last patch release.  They will be included in
 the next patch release tarball.
 :link(git,https://github.com/lammps/lammps)
 :line
 If you download a current LAMMPS tarball, one way to stay current as
 new patch tarballs are released, is to download a patch file which you
 can apply to your local directory to update it for each new patch
 release.  (Or of course you could just download the newest tarball
 periodically.)
 The patch files are posted on the "bug and feature page"_bug of the
 website, along with a list of changed files and details about what is
 in the new patch release.  Instructions for applying a patch file are
 on the "Install patch"_Install_patch.html doc page.
--- a/doc/src/Install_windows.txt
+++ b/doc/src/Install_windows.txt
@ -0,0 +1,52 @@
 "Higher level section"_Install.html - "LAMMPS WWW Site"_lws - "LAMMPS
 Documentation"_ld - "LAMMPS Commands"_lc :c
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
 :link(lc,Commands_all.html)
 :line
 Download an executable for Windows :h3
 Pre-compiled Windows installers which install LAMMPS executables on a
 Windows system can be downloaded from this site:
 "http://rpm.lammps.org/windows.html"_http://rpm.lammps.org/windows.html
 Note that each installer package has a date in its name, which
 corresponds to the LAMMPS version of the same date.  Installers for
 current and older versions of LAMMPS are available.  32-bit and 64-bit
 installers are available, and each installer contains both a serial
 and parallel executable.  The installer site also explains how to
 install the Windows MPI package (MPICH2 from Argonne National Labs),
 needed to run in parallel.
 The LAMMPS binaries contain all optional packages included in the
 source distribution except: KIM, REAX, KOKKOS, USER-INTEL,
 and USER-QMMM.  The serial version also does not include the MPIIO and
 USER-LB packages.  GPU support is provided for OpenCL.
 The installer site also has instructions on how to run LAMMPS under
 Windows, once it is installed, in both serial and parallel.
 When you download the installer package, you run it on your Windows
 machine.  It will then prompt you with a dialog, where you can choose
 the installation directory, unpack and copy several executables,
 potential files, documentation pdfs, selected example files, etc.  It
 will then update a few system settings (e.g. PATH, LAMMPS_POTENTIALS)
 and add an entry into the Start Menu (with references to the
 documentation, LAMMPS homepage and more).  From that menu, there is
 also a link to an uninstaller that removes the files and undoes the
 environment manipulations.
 Note that to update to a newer version of LAMMPS, you should typically
 uninstall the version you currently have, download a new installer,
 and go thru the install procedure described above.  I.e. the same
 procedure for installing/updating most Windows programs.  You can
 install multiple versions of LAMMPS (in different directories), but
 only the executable for the last-installed package will be found
 automatically, so this should only be done for debugging purposes.
 Thanks to Axel Kohlmeyer (Temple U, akohlmey at gmail.com) for setting
 up this Windows capability.
--- a/doc/src/Intro.txt
+++ b/doc/src/Intro.txt
@ -15,8 +15,10 @@ These pages provide a brief introduction to LAMMPS.
 <!-- RST
 .. toctree::
   :maxdepth: 1
   Intro_overview
   Manual_version
   Intro_features
   Intro_nonfeatures
   Intro_opensource
--- a/doc/src/Intro_authors.txt
+++ b/doc/src/Intro_authors.txt
@ -58,12 +58,12 @@ Terry Stouch (Lexicon Pharmaceuticals, formerly at Bristol Myers Squibb)
 Steve Lustig (Dupont)
 Jim Belak and Roy Pollock (LLNL) :ul
 :line
 :line
 Here is a timeline for when various individuals contributed to a new
 feature or command or tool added to LAMMPS:
 Aug18 : CMake build option for LAMMPS : Christoph Junghans (LANL), Richard Berger, and Axel Kohlmeyer (Temple U)
 Jul18 : DEM polygonal and polyhedron particles : Trung Nguyen (Northwestern U)
 Jun18 : SPIN package : Julien Tranchida (Sandia and CEA)
 Jun18 : compute entropy/atom : Pablo Piaggi (EPLF, Switzerland)
@ -239,7 +239,7 @@ Aug11 : angle_style cosine/shift and cosine/shift/exp : Carsten Svaneborg
 Aug11 : dihedral_style cosine/shift/exp : Carsten Svaneborg
 Aug11 : pair_style dipole/sf : Mario Orsi
 Aug11 : fix addtorque and compute temp/rotate : Laurent Joly (U Lyon)
-Aug11 : FFT support via FFTW3, MKL, ACML, KISSFFT libraries : \
+Aug11 : FFT support via FFTW3, MKL, ACML, KISS FFT libraries : \
  Axel Kohlmeyer (Temple U)
 Jun11 : pair_style adp : Chris Weinberger (Sandia), Stephen Foiles (Sandia), \
  Chandra Veer Singh (Cornell)
--- a/doc/src/Intro_features.txt
+++ b/doc/src/Intro_features.txt
@ -20,7 +20,7 @@ classes of functionality:
 "Integrators"_#integrate
 "Diagnostics"_#diag
 "Output"_#output
-"Multi-replica models"_#replica
+"Multi-replica models"_#replica1
 "Pre- and post-processing"_#prepost
 "Specialized features (beyond MD itself)"_#special :ul
@ -154,7 +154,7 @@ Output :h4,link(output)
  time averaging of system-wide quantities
  atom snapshots in native, XYZ, XTC, DCD, CFG formats :ul
-Multi-replica models :h4,link(replica)
+Multi-replica models :h4,link(replica1)
 "nudged elastic band"_neb.html
 "parallel replica dynamics"_prd.html
--- a/doc/src/Intro_nonfeatures.txt
+++ b/doc/src/Intro_nonfeatures.txt
@ -28,7 +28,7 @@ GUI: LAMMPS can be built as a library and a Python wrapper that wraps
 the library interface is provided.  Thus, GUI interfaces can be
 written in Python (or C or C++ if desired) that run LAMMPS and
 visualize or plot its output.  Examples of this are provided in the
-python directory and described on the "Python"_Python.html doc
+python directory and described on the "Python"_Python_head.html doc
 page. :ulb,l
 Builder: Several pre-processing tools are packaged with LAMMPS.  Some
@ -55,9 +55,9 @@ info on how to add your own analysis code or algorithms to LAMMPS.
 For post-processing, LAMMPS output such as "dump file
 snapshots"_dump.html can be converted into formats used by other MD or
 post-processing codes.  Some post-processing tools packaged with
-LAMMPS will do these conversions.  Scripts provided with the {python}
+LAMMPS will do these conversions.  Scripts provided in the
-tool in the tools directory can extract and massage data in dump files
+tools/python directory can extract and massage data in dump files to
-to make it easier to import into other programs.  See the
+make it easier to import into other programs.  See the
 "Tools"_Tools.html doc page for details on these various options. :l
 Visualization: LAMMPS can produce JPG or PNG snapshot images
@ -68,11 +68,11 @@ page"_http://lammps.sandia.gov/viz.html page of the LAMMPS website for
 visualization packages that can use LAMMPS output data. :l
 Plotting: See the next bullet about Pizza.py as well as the
-"Python"_Python.html doc page for examples of plotting LAMMPS output.
+"Python"_Python_head.html doc page for examples of plotting LAMMPS
-Scripts provided with the {python} tool in the tools directory will
+output.  Scripts provided with the {python} tool in the tools
-extract and massage data in log and dump files to make it easier to
+directory will extract and massage data in log and dump files to make
-analyze and plot.  See the "Tools"_Tools.html doc page for more
+it easier to analyze and plot.  See the "Tools"_Tools.html doc page
-discussion of the various tools. :l
+for more discussion of the various tools. :l
 Pizza.py: Our group has also written a separate toolkit called
 "Pizza.py"_http://pizza.sandia.gov which can do certain kinds of
--- a/doc/src/Manual.txt
+++ b/doc/src/Manual.txt
@ -8,6 +8,8 @@
 <BODY>
 <H1></H1>
 <!-- END_HTML_ONLY -->
 "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
@ -18,8 +20,6 @@
 :line
 <H1></H1>
 LAMMPS Documentation :c,h1
 2 Aug 2018 version :c,h2
@ -47,9 +47,9 @@ all LAMMPS development is coordinated.
 "PDF file"_Manual.pdf of the entire manual, generated by
 "htmldoc"_http://freecode.com/projects/htmldoc
-The content for this manual is part of the LAMMPS distribution.
+The content for this manual is part of the LAMMPS distribution.  You
-You can build a local copy of the Manual as HTML pages or a PDF file,
+can build a local copy of the Manual as HTML pages or a PDF file, by
-by following the steps on the "this page"_Build_manual.html.
+following the steps on the "Manual build"_Manual_build.html doc page.
 There is also a "Developer.pdf"_Developer.pdf document which gives
 a brief description of the basic code structure of LAMMPS.
@ -72,7 +72,9 @@ every LAMMPS command.
   :includehidden:
   Intro
-   Section_start
+   Install
   Build
   Run
   Commands
   Packages
   Speed
@ -80,15 +82,16 @@ every LAMMPS command.
   Examples
   Tools
   Modify
-   Python
+   Python_head
   Errors
   Manual_build
 .. toctree::
   :caption: Index
   :name: index
   :hidden:
-   commands
+   commands_list
   fixes
   computes
   pairs
@ -107,15 +110,9 @@ END_RST -->
 <!-- HTML_ONLY -->
 "Introduction"_Intro.html :olb,l
-"Getting started"_Section_start.html :l
+"Install LAMMPS"_Install.html :l
-  2.1 "What's in the LAMMPS distribution"_start_1 :ulb,b
+"Build LAMMPS"_Build.html :l
-  2.2 "Making LAMMPS"_start_2 :b
+"Run LAMMPS"_Run.html :l
  2.3 "Making LAMMPS with optional packages"_start_3 :b
  2.4 "Building LAMMPS as a library"_start_4 :b
  2.5 "Running LAMMPS"_start_5 :b
  2.6 "Command-line options"_start_6 :b
  2.7 "Screen output"_start_7 :b
  2.8 "Tips for users of previous versions"_start_8 :ule,b
 "Commands"_Commands.html :l
 "Optional packages"_Packages.html :l
 "Accelerate performance"_Speed.html :l
@ -123,19 +120,11 @@ END_RST -->
 "Example scripts"_Examples.html :l
 "Auxiliary tools"_Tools.html :l
 "Modify & extend LAMMPS"_Modify.html :l
-"Use Python with LAMMPS"_Python.html :l
+"Use Python with LAMMPS"_Python_head.html :l
 "Errors"_Errors.html :l
 "Building the LAMMPS manual"_Manual_build.html :l
 :ole
 :link(start_1,Section_start.html#start_1)
 :link(start_2,Section_start.html#start_2)
 :link(start_3,Section_start.html#start_3)
 :link(start_4,Section_start.html#start_4)
 :link(start_5,Section_start.html#start_5)
 :link(start_6,Section_start.html#start_6)
 :link(start_7,Section_start.html#start_7)
 :link(start_8,Section_start.html#start_8)
 <!-- END_HTML_ONLY -->
 </BODY>
--- a/doc/src/Manual_build.txt
+++ b/doc/src/Manual_build.txt
@ -0,0 +1,124 @@
 "Previous Section"_Errors.html - "LAMMPS WWW Site"_lws -
 "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
 Section"_Manual.html :c
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
 :link(lc,Commands_all.html)
 :line
 Building the LAMMPS manual :h2
 Depending on how you obtained LAMMPS, the doc directory has 
 2 or 3 sub-directories and optionally 2 PDF files and an ePUB file:
 src             # content files for LAMMPS documentation
 html            # HTML version of the LAMMPS manual (see html/Manual.html)
 tools           # tools and settings for building the documentation
 Manual.pdf      # large PDF version of entire manual
 Developer.pdf   # small PDF with info about how LAMMPS is structured
 LAMMPS.epub     # Manual in ePUB format :pre
 If you downloaded LAMMPS as a tarball from the web site, all these
 directories and files should be included.
 If you downloaded LAMMPS from the public SVN or Git repositories, then
 the HTML and PDF files are not included.  Instead you need to create
 them, in one of three ways:
 (a) You can "fetch" the current HTML and PDF files from the LAMMPS web
 site.  Just type "make fetch".  This should create a html_www dir and
 Manual_www.pdf/Developer_www.pdf files.  Note that if new LAMMPS
 features have been added more recently than the date of your version,
 the fetched documentation will include those changes (but your source
 code will not, unless you update your local repository).
 (b) You can build the HTML and PDF files yourself, by typing "make
 html" followed by "make pdf".  Note that the PDF make requires the
 HTML files already exist.  This requires various tools including
 Sphinx, which the build process will attempt to download and install
 on your system, if not already available.  See more details below.
 (c) You can genererate an older, simpler, less-fancy style of HTML
 documentation by typing "make old".  This will create an "old"
 directory.  This can be useful if (b) does not work on your box for
 some reason, or you want to quickly view the HTML version of a doc
 page you have created or edited yourself within the src directory.
 E.g. if you are planning to submit a new feature to LAMMPS.
 :line
 The generation of all documentation is managed by the Makefile in
 the doc dir.
 Documentation Build Options: :pre
 make html         # generate HTML in html dir using Sphinx
 make pdf          # generate 2 PDF files (Manual.pdf,Developer.pdf)
                  #   in doc dir via htmldoc and pdflatex
 make old          # generate old-style HTML pages in old dir via txt2html
 make fetch        # fetch HTML doc pages and 2 PDF files from web site
                  #   as a tarball and unpack into html dir and 2 PDFs
 make epub         # generate LAMMPS.epub in ePUB format using Sphinx 
 make clean        # remove intermediate RST files created by HTML build
 make clean-all    # remove entire build folder and any cached data :pre
 :line
 Installing prerequisites for HTML build :h3
 To run the HTML documention build toolchain, Python 3 and virtualenv
 have to be installed.  Here are instructions for common setups:
 Ubuntu :h4
 sudo apt-get install python-virtualenv :pre
 Fedora (up to version 21) and Red Hat Enterprise Linux or CentOS (up to version 7.x) :h4
 sudo yum install python3-virtualenv :pre
 Fedora (since version 22) :h4
 sudo dnf install python3-virtualenv pre
 MacOS X :h4
 Python 3 :h5
 Download the latest Python 3 MacOS X package from
 "https://www.python.org"_https://www.python.org
 and install it.  This will install both Python 3
 and pip3.
 virtualenv :h5
 Once Python 3 is installed, open a Terminal and type
 pip3 install virtualenv :pre
 This will install virtualenv from the Python Package Index.
 :line
 Installing prerequisites for PDF build
 [TBA]
 :line
 Installing prerequisites for epub build :h3
 ePUB :h4
 Same as for HTML. This uses the same tools and configuration
 files as the HTML tree.
 For converting the generated ePUB file to a mobi format file
 (for e-book readers like Kindle, that cannot read ePUB), you
 also need to have the 'ebook-convert' tool from the "calibre"
 software installed. "http://calibre-ebook.com/"_http://calibre-ebook.com/
 You first create the ePUB file with 'make epub' and then do:
 ebook-convert LAMMPS.epub LAMMPS.mobi :pre
--- a/doc/src/Manual_version.txt
+++ b/doc/src/Manual_version.txt
@ -7,7 +7,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 :line
-What does a LAMMPS version mean: :h3
+What does a LAMMPS version mean :h3
 The LAMMPS "version" is the date when it was released, such as 1 May
 2014. LAMMPS is updated continuously.  Whenever we fix a bug or add a
--- a/doc/src/Modify.txt
+++ b/doc/src/Modify.txt
@ -1,6 +1,6 @@
 "Previous Section"_Tools.html - "LAMMPS WWW Site"_lws -
 "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
-Section"_Python.html :c
+Section"_Python_head.html :c
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
@ -24,11 +24,13 @@ contribute"_Modify_contribute.html doc page.
 <!-- RST
 .. toctree::
   :maxdepth: 1
   Modify_overview
   Modify_contribute
 .. toctree::
   :maxdepth: 1
   Modify_atom
   Modify_pair
@ -38,6 +40,7 @@ contribute"_Modify_contribute.html doc page.
   Modify_command
 .. toctree::
   :maxdepth: 1
   Modify_dump
   Modify_kspace
@ -46,6 +49,7 @@ contribute"_Modify_contribute.html doc page.
   Modify_body
 .. toctree::
   :maxdepth: 1
   Modify_thermo
   Modify_variable
--- a/doc/src/Modify_contribute.txt
+++ b/doc/src/Modify_contribute.txt
@ -44,13 +44,14 @@ 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
+package"_Packages_standard.html.  Else we will add them as a
-user-contributed file or package.  Examples of user packages are in
+user-contributed file or "user package"_Packages_user.html.  Examples
-src sub-directories that start with USER.  The USER-MISC package is
+of user packages are in src sub-directories that start with USER.  The
-simply a collection of (mostly) unrelated single files, which is the
+USER-MISC package is simply a collection of (mostly) unrelated single
-simplest way to have your contribution quickly added to the LAMMPS
+files, which is the simplest way to have your contribution quickly
-distribution.  You can see a list of the both standard and user
+added to the LAMMPS distribution.  All the standard and user packages
-packages by typing "make package" in the LAMMPS src directory.
+are listed and described on the "Packages
 details"_Packages_details.html doc page.
 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,
--- a/doc/src/Packages.txt
+++ b/doc/src/Packages.txt
@ -13,16 +13,17 @@ 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
+systems or rigid-body constraints 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
+distribution.  The "Build package"_Build_package.html doc page gives
-info on how to install and un-install packages as part of the LAMMPS
+general info on how to install and un-install packages as part of the
-build process.
+LAMMPS build process.
 <!-- RST
 .. toctree::
   :maxdepth: 1
   Packages_standard
   Packages_user
--- a/doc/src/Packages_details.txt
+++ b/doc/src/Packages_details.txt
--- a/doc/src/Packages_standard.txt
+++ b/doc/src/Packages_standard.txt
@ -31,35 +31,36 @@ 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, "Howto spherical"_Howto_spherical.html, ellipse, -
+"ASPHERE"_Packages_details.html#PKG-ASPHERE, aspherical particle models, "Howto spherical"_Howto_spherical.html, ellipse, -
-"BODY"_Packages_details.html#BODY, body-style particles, "Howto body"_Howto_body.html, body, -
+"BODY"_Packages_details.html#PKG-BODY, body-style particles, "Howto body"_Howto_body.html, body, -
-"CLASS2"_Packages_details.html#CLASS2, class 2 force fields, "pair_style lj/class2"_pair_class2.html, -, -
+"CLASS2"_Packages_details.html#PKG-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, -
+"COLLOID"_Packages_details.html#PKG-COLLOID, colloidal particles, "atom_style colloid"_atom_style.html, colloid, -
-"COMPRESS"_Packages_details.html#COMPRESS, I/O compression, "dump */gz"_dump.html, -, sys
+"COMPRESS"_Packages_details.html#PKG-COMPRESS, I/O compression, "dump */gz"_dump.html, -, sys
-"CORESHELL"_Packages_details.html#CORESHELL, adiabatic core/shell model, "Howto coreshell"_Howto_coreshell.html, coreshell, -
+"CORESHELL"_Packages_details.html#PKG-CORESHELL, adiabatic core/shell model, "Howto coreshell"_Howto_coreshell.html, coreshell, -
-"DIPOLE"_Packages_details.html#DIPOLE, point dipole particles, "pair_style dipole/cut"_pair_dipole.html, dipole, -
+"DIPOLE"_Packages_details.html#PKG-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
+"GPU"_Packages_details.html#PKG-GPU, GPU-enabled styles, "Section gpu"_Speed_gpu.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, int
-"GRANULAR"_Packages_details.html#GRANULAR, granular systems, "Howto granular"_Howto_granular.html, pour, -
+"GRANULAR"_Packages_details.html#PKG-GRANULAR, granular systems, "Howto granular"_Howto_granular.html, pour, -
-"KIM"_Packages_details.html#KIM, OpenKIM wrapper, "pair_style kim"_pair_kim.html, kim, ext
+"KIM"_Packages_details.html#PKG-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, -
+"KOKKOS"_Packages_details.html#PKG-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, -
+"KSPACE"_Packages_details.html#PKG-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
+"LATTE"_Packages_details.html#PKG-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, -
+"MANYBODY"_Packages_details.html#PKG-MANYBODY, many-body potentials, "pair_style tersoff"_pair_tersoff.html, shear, -
-"MC"_Packages_details.html#MC, Monte Carlo options, "fix gcmc"_fix_gcmc.html, -, -
+"MC"_Packages_details.html#PKG-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
+"MEAM"_Packages_details.html#PKG-MEAM, modified EAM potential, "pair_style meam"_pair_meam.html, meam, int
-"MISC"_Packages_details.html#MISC, miscellanous single-file commands, -, -, -
+"MISC"_Packages_details.html#PKG-MISC, miscellanous single-file commands, -, -, -
-"MOLECULE"_Packages_details.html#MOLECULE, molecular system force fields, "Howto bioFF"_Howto_bioFF.html, peptide, -
+"MOLECULE"_Packages_details.html#PKG-MOLECULE, molecular system force fields, "Howto bioFF"_Howto_bioFF.html, peptide, -
-"MPIIO"_Packages_details.html#MPIIO, MPI parallel I/O dump and restart, "dump"_dump.html, -, -
+"MPIIO"_Packages_details.html#PKG-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
+"MSCG"_Packages_details.html#PKG-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, -
+"OPT"_Packages_details.html#PKG-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, -
+"PERI"_Packages_details.html#PKG-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
+"POEMS"_Packages_details.html#PKG-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
+"PYTHON"_Packages_details.html#PKG-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, -
+"QEQ"_Packages_details.html#PKG-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
+"REAX"_Packages_details.html#PKG-REAX, ReaxFF potential (Fortran), "pair_style reax"_pair_reax.html, reax, int
-"REPLICA"_Packages_details.html#REPLICA, multi-replica methods, "Howto replica"_Howto_replica.html, tad, -
+"REPLICA"_Packages_details.html#PKG-REPLICA2, multi-replica methods, "Howto replica"_Howto_replica.html, tad, -
-"RIGID"_Packages_details.html#RIGID, rigid bodies and constraints, "fix rigid"_fix_rigid.html, rigid, -
+"RIGID"_Packages_details.html#PKG-RIGID, rigid bodies and constraints, "fix rigid"_fix_rigid.html, rigid, -
-"SHOCK"_Packages_details.html#SHOCK, shock loading methods, "fix msst"_fix_msst.html, -, -
+"SHOCK"_Packages_details.html#PKG-SHOCK, shock loading methods, "fix msst"_fix_msst.html, -, -
-"SNAP"_Packages_details.html#SNAP, quantum-fitted potential, "pair_style snap"_pair_snap.html, snap, -
+"SNAP"_Packages_details.html#PKG-SNAP, quantum-fitted potential, "pair_style snap"_pair_snap.html, snap, -
-"SPIN"_#SPIN, magnetic atomic spin dynamics, "Howto spin"_Howto_spin.html, SPIN, -"SRD"_Packages_details.html#SRD, stochastic rotation dynamics, "fix srd"_fix_srd.html, srd, -
+"SPIN"_Packages_details.html#PKG-SPIN, magnetic atomic spin dynamics, "Howto spins"_Howto_spins.html, SPIN, -
-"VORONOI"_Packages_details.html#VORONOI, Voronoi tesselation, "compute voronoi/atom"_compute_voronoi_atom.html, -, ext :tb(ea=c,ca1=l)
+"SRD"_Packages_details.html#PKG-SRD, stochastic rotation dynamics, "fix srd"_fix_srd.html, srd, -
 "VORONOI"_Packages_details.html#PKG-VORONOI, Voronoi tesselation, "compute voronoi/atom"_compute_voronoi_atom.html, -, ext :tb(ea=c,ca1=l)
--- a/doc/src/Packages_user.txt
+++ b/doc/src/Packages_user.txt
@ -38,37 +38,37 @@ 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-ATC"_Packages_details.html#PKG-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-AWPMD"_Packages_details.html#PKG-USER-AWPMD, wave-packet MD, "pair_style awpmd/cut"_pair_awpmd.html, USER/awpmd, int
-"USER-BOCS"_Packages_details.html#USER-BOCS, BOCS bottom up coarse graining, "fix bocs"_fix_bocs.html, USER/bocs, -
+"USER-BOCS"_Packages_details.html#PKG-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-CGDNA"_Packages_details.html#PKG-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-CGSDK"_Packages_details.html#PKG-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-COLVARS"_Packages_details.html#PKG-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-DIFFRACTION"_Packages_details.html#PKG-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-DPD"_Packages_details.html#PKG-USER-DPD, reactive dissipative particle dynamics, src/USER-DPD/README, USER/dpd, -
-"USER-DRUDE"_Packages_details.html#USER-DRUDE, Drude oscillators, "Howto drude"_Howto_drude.html, USER/drude, -
+"USER-DRUDE"_Packages_details.html#PKG-USER-DRUDE, Drude oscillators, "Howto drude"_Howto_drude.html, USER/drude, -
-"USER-EFF"_Packages_details.html#USER-EFF, electron force field,"pair_style eff/cut"_pair_eff.html, USER/eff, -
+"USER-EFF"_Packages_details.html#PKG-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-FEP"_Packages_details.html#PKG-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-H5MD"_Packages_details.html#PKG-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-INTEL"_Packages_details.html#PKG-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-LB"_Packages_details.html#PKG-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-MANIFOLD"_Packages_details.html#PKG-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-MEAMC"_Packages_details.html#PKG-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-MESO"_Packages_details.html#PKG-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-MGPT"_Packages_details.html#PKG-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-MISC"_Packages_details.html#PKG-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-MOFFF"_Packages_details.html#PKG-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-MOLFILE"_Packages_details.html#PKG-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-NETCDF"_Packages_details.html#PKG-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-OMP"_Packages_details.html#PKG-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-PHONON"_Packages_details.html#PKG-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-QMMM"_Packages_details.html#PKG-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-QTB"_Packages_details.html#PKG-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-QUIP"_Packages_details.html#PKG-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-REAXC"_Packages_details.html#PKG-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-SMD"_Packages_details.html#PKG-USER-SMD, smoothed Mach dynamics,"SMD User Guide"_PDF/SMD_LAMMPS_userguide.pdf, USER/smd, ext
-"USER-SMTBQ"_Packages_details.html#USER-SMTBQ, second moment tight binding QEq potential,"pair_style smtbq"_pair_smtbq.html, USER/smtbq, -
+"USER-SMTBQ"_Packages_details.html#PKG-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-SPH"_Packages_details.html#PKG-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-TALLY"_Packages_details.html#PKG-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-UEF"_Packages_details.html#PKG-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)
+"USER-VTK"_Packages_details.html#PKG-USER-VTK, dump output via VTK, "compute vtk"_dump_vtk.html, -, ext :tb(ea=c,ca1=l)
--- a/doc/src/Python_call.txt
+++ b/doc/src/Python_call.txt
@ -1,5 +1,5 @@
-"Higher level section"_Python.html - "LAMMPS WWW Site"_lws - "LAMMPS
+"Higher level section"_Python_head.html - "LAMMPS WWW Site"_lws -
-Documentation"_ld - "LAMMPS Commands"_lc :c
+"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
--- a/doc/src/Python_examples.txt
+++ b/doc/src/Python_examples.txt
@ -1,5 +1,5 @@
-"Higher level section"_Python.html - "LAMMPS WWW Site"_lws - "LAMMPS
+"Higher level section"_Python_head.html - "LAMMPS WWW Site"_lws -
-Documentation"_ld - "LAMMPS Commands"_lc :c
+"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
--- a/doc/src/Python_head.txt
+++ b/doc/src/Python_head.txt
@ -16,10 +16,12 @@ used together.
 <!-- RST
 .. toctree::
   :maxdepth: 1
   Python_overview
 .. toctree::
   :maxdepth: 1
   Python_run
   Python_shlib
@ -31,6 +33,7 @@ used together.
   Python_examples
 .. toctree::
   :maxdepth: 1
   Python_call
--- a/doc/src/Python_install.txt
+++ b/doc/src/Python_install.txt
@ -1,5 +1,5 @@
-"Higher level section"_Python.html - "LAMMPS WWW Site"_lws - "LAMMPS
+"Higher level section"_Python_head.html - "LAMMPS WWW Site"_lws -
-Documentation"_ld - "LAMMPS Commands"_lc :c
+"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
@ -68,7 +68,7 @@ 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
+the LAMMPS shared library (see "this section"_Python_shlib.html), 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.
--- a/doc/src/Python_library.txt
+++ b/doc/src/Python_library.txt
@ -1,5 +1,5 @@
-"Higher level section"_Python.html - "LAMMPS WWW Site"_lws - "LAMMPS
+"Higher level section"_Python_head.html - "LAMMPS WWW Site"_lws -
-Documentation"_ld - "LAMMPS Commands"_lc :c
+"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
--- a/doc/src/Python_mpi.txt
+++ b/doc/src/Python_mpi.txt
@ -1,5 +1,5 @@
-"Higher level section"_Python.html - "LAMMPS WWW Site"_lws - "LAMMPS
+"Higher level section"_Python_head.html - "LAMMPS WWW Site"_lws -
-Documentation"_ld - "LAMMPS Commands"_lc :c
+"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
--- a/doc/src/Python_pylammps.txt
+++ b/doc/src/Python_pylammps.txt
@ -1,5 +1,5 @@
-"Higher level section"_Python.html - "LAMMPS WWW Site"_lws - "LAMMPS
+"Higher level section"_Python_head.html - "LAMMPS WWW Site"_lws -
-Documentation"_ld - "LAMMPS Commands"_lc :c
+"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
--- a/doc/src/Python_run.txt
+++ b/doc/src/Python_run.txt
@ -1,5 +1,5 @@
-"Higher level section"_Python.html - "LAMMPS WWW Site"_lws - "LAMMPS
+"Higher level section"_Python_head.html - "LAMMPS WWW Site"_lws -
-Documentation"_ld - "LAMMPS Commands"_lc :c
+"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
--- a/doc/src/Python_shlib.txt
+++ b/doc/src/Python_shlib.txt
@ -1,5 +1,5 @@
-"Higher level section"_Python.html - "LAMMPS WWW Site"_lws - "LAMMPS
+"Higher level section"_Python_head.html - "LAMMPS WWW Site"_lws -
-Documentation"_ld - "LAMMPS Commands"_lc :c
+"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
@ -9,10 +9,13 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 Build LAMMPS as a shared library :h3
-Instructions on how to build LAMMPS as a shared library are given in
+Build LAMMPS as a shared library using make :h4
-"Section 2.4"_Section_start.html#start_4.  A shared library is one
+
-that is dynamically loadable, which is what Python requires to wrap
+Instructions on how to build LAMMPS as a shared library are given on
-LAMMPS.  On Linux this is a library file that ends in ".so", not ".a".
+the "Build_basics"_Build_basics.html doc page.  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
@ -29,6 +32,42 @@ 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.
+the "Build_basics"_Build_basics.html doc page.
-Also include CMake info on this
+Build LAMMPS as a shared library using CMake :h4
 When using CMake the following two options are necessary to generate the LAMMPS
 shared library:
 -D BUILD_LIB=on            # enable building LAMMPS as a library
 -D BUILD_SHARED_LIBS=on    # enable building of LAMMPS shared library (both options are needed!) :pre
 What this does is create a liblammps.so which contains the majority of LAMMPS
 code. The generated lmp binary also dynamically links to this library. This
 means that either this liblammps.so file has to be in the same directory, a system
 library path (e.g. /usr/lib64/) or in the LD_LIBRARY_PATH.
 If you want to use the shared library with Python the recommended way is to create a virtualenv and use it as
 CMAKE_INSTALL_PREFIX.
 # create virtualenv
 virtualenv --python=$(which python3) myenv3
 source myenv3/bin/activate :pre
 # build library
 mkdir build
 cd build
 cmake -D PKG_PYTHON=on -D BUILD_LIB=on -D BUILD_SHARED_LIBS=on -D CMAKE_INSTALL_PREFIX=$VIRTUAL_ENV ../cmake
 make -j 4 :pre
 # install into prefix
 make install :pre
 This will also install the Python module into your virtualenv. Since virtualenv
 doesn't change your LD_LIBRARY_PATH, you still need to add its lib64 folder to
 it, which contains the installed liblammps.so.
 export LD_LIBRARY_PATH=$VIRTUAL_ENV/lib64:$LD_LIBRARY_PATH :pre
 Starting Python outside (!) of your build directory, but with the virtualenv
 enabled and with the LD_LIBRARY_PATH set gives you access to LAMMPS via Python.
--- a/doc/src/Python_test.txt
+++ b/doc/src/Python_test.txt
@ -1,5 +1,5 @@
-"Higher level section"_Python.html - "LAMMPS WWW Site"_lws - "LAMMPS
+"Higher level section"_Python_head.html - "LAMMPS WWW Site"_lws -
-Documentation"_ld - "LAMMPS Commands"_lc :c
+"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
@ -32,10 +32,10 @@ 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
+If an error occurs, carefully go thru the steps on the
-2.4"_Section_start.html#start_4 and above about building a shared
+"Build_basics"_Build_basics.html doc page about building a shared
-library and about insuring Python can find the necessary two files
+library and the "Python_install"_Python_install.html doc page about
-it needs.
+insuring Python can find the necessary two files it needs.
 [Test LAMMPS and Python in serial:] :h4
--- a/doc/src/Run.txt
+++ b/doc/src/Run.txt
@ -0,0 +1,38 @@
 "Previous Section"_Build.html - "LAMMPS WWW Site"_lws - "LAMMPS
 Documentation"_ld - "LAMMPS Commands"_lc - "Next
 Section"_Commands.html :c
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
 :link(lc,Commands_all.html)
 :line
 Run LAMMPS :h2
 These pages explain how to run LAMMPS once you have "installed an
 executable"_Install.html or "downloaded the source code"_Install.html
 and "built an executable"_Build.html.  The "Commands"_Commands.html
 doc page describes how input scripts are structured and the commands
 they can contain.
 <!-- RST
 .. toctree::
   :maxdepth: 1
   Run_basics
   Run_options
   Run_output
   Run_windows
 END_RST -->
 <!-- HTML_ONLY -->
 "Basics of running LAMMPS"_Run_basics.html
 "Command-line options"_Run_options.html
 "Screen and logfile output"_Run_output.html
 "Running LAMMPS on Windows"_Run_windows.html :all(b)
 <!-- END_HTML_ONLY -->
--- a/doc/src/Run_basics.txt
+++ b/doc/src/Run_basics.txt
@ -0,0 +1,89 @@
 "Higher level section"_Run.html - "LAMMPS WWW Site"_lws - "LAMMPS
 Documentation"_ld - "LAMMPS Commands"_lc :c
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
 :link(lc,Commands_all.html)
 :line
 Basics of running LAMMPS :h3
 LAMMPS is run from the command line, reading commands from a
 file via the -in command line flag, or from standard input.
 Using the "-in in.file" variant is recommended:
 lmp_serial < in.file
 lmp_serial -in in.file
 /path/to/lammps/src/lmp_serial < in.file
 mpirun -np 4 lmp_mpi -in in.file
 mpirun -np 8 /path/to//lammps/src/lmp_mpi -in in.file
 mpirun -np 6 /usr/local/bin/lmp -in in.file :pre
 You normally run the LAMMPS command in the directory where your
 input script is located.  That is also where output files are
 produced by default, unless you provide specific other paths in
 your input script or on the command line.  As in some of the
 examples above, the LAMMPS executable itself can be placed elsewhere.
 NOTE: The redirection operator "<" will not always work when running
 in parallel with mpirun; for those systems the -in form is required.
 As LAMMPS runs it prints info to the screen and a logfile named
 log.lammps.  More info about output is given on the "Run
 output"_Run_output.html doc page.
 If LAMMPS encounters errors in the input script or while running a
 simulation it will print an ERROR message and stop or a WARNING
 message and continue.  See the "Errors"_Errors.html doc page for a
 discussion of the various kinds of errors LAMMPS can or can't detect,
 a list of all ERROR and WARNING messages, and what to do about them.
 :line
 LAMMPS can run the same problem on any number of processors, including
 a single processor.  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.  See the "Errors
 common"_Errors_common.html doc page for discussion of this.
 LAMMPS can run as large a problem as will fit in the physical memory
 of one or more processors.  If you run out of memory, you must run on
 more processors or define a smaller problem.
 If you run LAMMPS in parallel via mpirun, you should be aware of the
 "processors"_processors.html command which controls how MPI tasks are
 mapped to the simulation box, as well as mpirun options that control
 how MPI tasks are assigned to physical cores of the node(s) of the
 machine you are running on.  These settings can improve performance,
 though the defaults are often adequate.
 For example, it is often important to bind MPI tasks (processes) to
 physical cores (processor affinity), so that the operating system does
 not migrate them during a simulation.  If this is not the default
 behavior on your machine, the mpirun option "--bind-to core" (OpenMPI)
 or "-bind-to core" (MPICH) can be used.
 If the LAMMPS command(s) you are using support multi-threading, you
 can set the number of threads per MPI task via the environment
 variable OMP_NUM_THREADS, before you launch LAMMPS:
 export OMP_NUM_THREADS=2     # bash
 setenv OMP_NUM_THREADS 2     # csh or tcsh :pre
 This can also be done via the "package"_package.html command or via
 the "-pk command-line switch"_Run_options.html which invokes the
 package command.  See the "package"_package.html command or
 "Speed"_Speed.html doc pages for more details about which accerlarator
 packages and which commands support multi-threading.
 :line
 You can experiment with running LAMMPS using any of the input scripts
 provided in the examples or bench directory.  Input scripts are named
 in.* and sample outputs are named log.*.P where P is the number of
 processors it was run on.
 Some of the examples or benchmarks require LAMMPS to be built with
 optional packages.
--- a/doc/src/Run_options.txt
+++ b/doc/src/Run_options.txt
@ -0,0 +1,469 @@
 "Higher level section"_Run.html - "LAMMPS WWW Site"_lws - "LAMMPS
 Documentation"_ld - "LAMMPS Commands"_lc :c
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
 :link(lc,Commands_all.html)
 :line
 Command-line options :h3
 At run time, LAMMPS recognizes several optional command-line switches
 which may be used in any order.  Either the full word or a one-or-two
 letter abbreviation can be used:
 "-e or -echo"_#echo
 "-h or -help"_#help
 "-i or -in"_#file
 "-k or -kokkos"_#run-kokkos
 "-l or -log"_#log
 "-nc or -nocite"_#nocite
 "-pk or -package"_#package
 "-p or -partition"_#partition
 "-pl or -plog"_#plog
 "-ps or -pscreen"_#pscreen
 "-r or -restart"_#restart
 "-ro or -reorder"_#reorder
 "-sc or -screen"_#screen
 "-sf or -suffix"_#suffix
 "-v or -var"_#var :ul
 For example, the lmp_mpi executable might be launched as follows:
 mpirun -np 16 lmp_mpi -v f tmp.out -l my.log -sc none -i in.alloy
 mpirun -np 16 lmp_mpi -var f tmp.out -log my.log -screen none -in in.alloy :pre
 :line
 [-echo style] :link(echo)
 Set the style of command echoing.  The style can be {none} or {screen}
 or {log} or {both}.  Depending on the style, each command read from
 the input script will be echoed to the screen and/or logfile.  This
 can be useful to figure out which line of your script is causing an
 input error.  The default value is {log}.  The echo style can also be
 set by using the "echo"_echo.html command in the input script itself.
 :line
 [-help] :link(help)
 Print a brief help summary and a list of options compiled into this
 executable for each LAMMPS style (atom_style, fix, compute,
 pair_style, bond_style, etc).  This can tell you if the command you
 want to use was included via the appropriate package at compile time.
 LAMMPS will print the info and immediately exit if this switch is
 used.
 :line
 [-in file] :link(file)
 Specify a file to use as an input script.  This is an optional switch
 when running LAMMPS in one-partition mode.  If it is not specified,
 LAMMPS reads its script from standard input, typically from a script
 via I/O redirection; e.g. lmp_linux < in.run.  I/O redirection should
 also work in parallel, but if it does not (in the unlikely case that
 an MPI implementation does not support it), then use the -in flag.
 Note that this is a required switch when running LAMMPS in
 multi-partition mode, since multiple processors cannot all read from
 stdin.
 :line
 [-kokkos on/off keyword/value ...] :link(run-kokkos)
 Explicitly enable or disable KOKKOS support, as provided by the KOKKOS
 package.  Even if LAMMPS is built with this package, as described
 in "Speed kokkos"_Speed_kokkos.html, this switch must be set to enable
 running with the KOKKOS-enabled styles the package provides.  If the
 switch is not set (the default), LAMMPS will operate as if the KOKKOS
 package were not installed; i.e. you can run standard LAMMPS or with
 the GPU or USER-OMP packages, for testing or benchmarking purposes.
 Additional optional keyword/value pairs can be specified which
 determine how Kokkos will use the underlying hardware on your
 platform.  These settings apply to each MPI task you launch via the
 "mpirun" or "mpiexec" command.  You may choose to run one or more MPI
 tasks per physical node.  Note that if you are running on a desktop
 machine, you typically have one physical node.  On a cluster or
 supercomputer there may be dozens or 1000s of physical nodes.
 Either the full word or an abbreviation can be used for the keywords.
 Note that the keywords do not use a leading minus sign.  I.e. the
 keyword is "t", not "-t".  Also note that each of the keywords has a
 default setting.  Examples of when to use these options and what
 settings to use on different platforms is given on the "Speed
 kokkos"_Speed_kokkos.html doc page.
 d or device
 g or gpus
 t or threads
 n or numa :ul
 device Nd :pre
 This option is only relevant if you built LAMMPS with CUDA=yes, you
 have more than one GPU per node, and if you are running with only one
 MPI task per node.  The Nd setting is the ID of the GPU on the node to
 run on.  By default Nd = 0.  If you have multiple GPUs per node, they
 have consecutive IDs numbered as 0,1,2,etc.  This setting allows you
 to launch multiple independent jobs on the node, each with a single
 MPI task per node, and assign each job to run on a different GPU.
 gpus Ng Ns :pre
 This option is only relevant if you built LAMMPS with CUDA=yes, you
 have more than one GPU per node, and you are running with multiple MPI
 tasks per node (up to one per GPU).  The Ng setting is how many GPUs
 you will use.  The Ns setting is optional.  If set, it is the ID of a
 GPU to skip when assigning MPI tasks to GPUs.  This may be useful if
 your desktop system reserves one GPU to drive the screen and the rest
 are intended for computational work like running LAMMPS.  By default
 Ng = 1 and Ns is not set.
 Depending on which flavor of MPI you are running, LAMMPS will look for
 one of these 3 environment variables
 SLURM_LOCALID (various MPI variants compiled with SLURM support)
 MV2_COMM_WORLD_LOCAL_RANK (Mvapich)
 OMPI_COMM_WORLD_LOCAL_RANK (OpenMPI) :pre
 which are initialized by the "srun", "mpirun" or "mpiexec" commands.
 The environment variable setting for each MPI rank is used to assign a
 unique GPU ID to the MPI task.
 threads Nt :pre
 This option assigns Nt number of threads to each MPI task for
 performing work when Kokkos is executing in OpenMP or pthreads mode.
 The default is Nt = 1, which essentially runs in MPI-only mode.  If
 there are Np MPI tasks per physical node, you generally want Np*Nt =
 the number of physical cores per node, to use your available hardware
 optimally.  This also sets the number of threads used by the host when
 LAMMPS is compiled with CUDA=yes.
 numa Nm :pre
 This option is only relevant when using pthreads with hwloc support.
 In this case Nm defines the number of NUMA regions (typically sockets)
 on a node which will be utilized by a single MPI rank.  By default Nm
 = 1.  If this option is used the total number of worker-threads per
 MPI rank is threads*numa.  Currently it is always almost better to
 assign at least one MPI rank per NUMA region, and leave numa set to
 its default value of 1. This is because letting a single process span
 multiple NUMA regions induces a significant amount of cross NUMA data
 traffic which is slow.
 :line
 [-log file] :link(log)
 Specify a log file for LAMMPS to write status information to.  In
 one-partition mode, if the switch is not used, LAMMPS writes to the
 file log.lammps.  If this switch is used, LAMMPS writes to the
 specified file.  In multi-partition mode, if the switch is not used, a
 log.lammps file is created with hi-level status information.  Each
 partition also writes to a log.lammps.N file where N is the partition
 ID.  If the switch is specified in multi-partition mode, the hi-level
 logfile is named "file" and each partition also logs information to a
 file.N.  For both one-partition and multi-partition mode, if the
 specified file is "none", then no log files are created.  Using a
 "log"_log.html command in the input script will override this setting.
 Option -plog will override the name of the partition log files file.N.
 :line
 [-nocite] :link(nocite)
 Disable writing the log.cite file which is normally written to list
 references for specific cite-able features used during a LAMMPS run.
 See the "citation page"_http://lammps.sandia.gov/cite.html for more
 details.
 :line
 [-package style args ....] :link(package)
 Invoke the "package"_package.html command with style and args.  The
 syntax is the same as if the command appeared at the top of the input
 script.  For example "-package gpu 2" or "-pk gpu 2" is the same as
 "package gpu 2"_package.html in the input script.  The possible styles
 and args are documented on the "package"_package.html doc page.  This
 switch can be used multiple times, e.g. to set options for the
 USER-INTEL and USER-OMP packages which can be used together.
 Along with the "-suffix" command-line switch, this is a convenient
 mechanism for invoking accelerator packages and their options without
 having to edit an input script.
 :line
 [-partition 8x2 4 5 ...] :link(partition)
 Invoke LAMMPS in multi-partition mode.  When LAMMPS is run on P
 processors and this switch is not used, LAMMPS runs in one partition,
 i.e. all P processors run a single simulation.  If this switch is
 used, the P processors are split into separate partitions and each
 partition runs its own simulation.  The arguments to the switch
 specify the number of processors in each partition.  Arguments of the
 form MxN mean M partitions, each with N processors.  Arguments of the
 form N mean a single partition with N processors.  The sum of
 processors in all partitions must equal P.  Thus the command
 "-partition 8x2 4 5" has 10 partitions and runs on a total of 25
 processors.
 Running with multiple partitions can be useful for running
 "multi-replica simulations"_Howto_replica.html, where each replica
 runs on on one or a few processors.  Note that with MPI installed on a
 machine (e.g. your desktop), you can run on more (virtual) processors
 than you have physical processors.
 To run multiple independent simulations from one input script, using
 multiple partitions, see the "Howto multiple"_Howto_multiple.html doc
 page.  World- and universe-style "variables"_variable.html are useful
 in this context.
 :line
 [-plog file] :link(plog)
 Specify the base name for the partition log files, so partition N
 writes log information to file.N. If file is none, then no partition
 log files are created.  This overrides the filename specified in the
 -log command-line option.  This option is useful when working with
 large numbers of partitions, allowing the partition log files to be
 suppressed (-plog none) or placed in a sub-directory (-plog
 replica_files/log.lammps) If this option is not used the log file for
 partition N is log.lammps.N or whatever is specified by the -log
 command-line option.
 :line
 [-pscreen file] :link(pscreen)
 Specify the base name for the partition screen file, so partition N
 writes screen information to file.N. If file is none, then no
 partition screen files are created.  This overrides the filename
 specified in the -screen command-line option.  This option is useful
 when working with large numbers of partitions, allowing the partition
 screen files to be suppressed (-pscreen none) or placed in a
 sub-directory (-pscreen replica_files/screen).  If this option is not
 used the screen file for partition N is screen.N or whatever is
 specified by the -screen command-line option.
 :line
 [-restart restartfile {remap} datafile keyword value ...] :link(restart)
 Convert the restart file into a data file and immediately exit.  This
 is the same operation as if the following 2-line input script were
 run:
 read_restart restartfile {remap}
 write_data datafile keyword value ... :pre
 Note that the specified restartfile and datafile can have wild-card
 characters ("*",%") as described by the
 "read_restart"_read_restart.html and "write_data"_write_data.html
 commands.  But a filename such as file.* will need to be enclosed in
 quotes to avoid shell expansion of the "*" character.
 Note that following restartfile, the optional flag {remap} can be
 used.  This has the same effect as adding it to the
 "read_restart"_read_restart.html command, as explained on its doc
 page.  This is only useful if the reading of the restart file triggers
 an error that atoms have been lost.  In that case, use of the remap
 flag should allow the data file to still be produced.
 Also note that following datafile, the same optional keyword/value
 pairs can be listed as used by the "write_data"_write_data.html
 command.
 :line
 [-reorder] :link(reorder)
 This option has 2 forms:
 -reorder nth N
 -reorder custom filename :pre
 Reorder the processors in the MPI communicator used to instantiate
 LAMMPS, in one of several ways.  The original MPI communicator ranks
 all P processors from 0 to P-1.  The mapping of these ranks to
 physical processors is done by MPI before LAMMPS begins.  It may be
 useful in some cases to alter the rank order.  E.g. to insure that
 cores within each node are ranked in a desired order.  Or when using
 the "run_style verlet/split"_run_style.html command with 2 partitions
 to insure that a specific Kspace processor (in the 2nd partition) is
 matched up with a specific set of processors in the 1st partition.
 See the "Speed tips"_Speed_tips.html doc page for more details.
 If the keyword {nth} is used with a setting {N}, then it means every
 Nth processor will be moved to the end of the ranking.  This is useful
 when using the "run_style verlet/split"_run_style.html command with 2
 partitions via the -partition command-line switch.  The first set of
 processors will be in the first partition, the 2nd set in the 2nd
 partition.  The -reorder command-line switch can alter this so that
 the 1st N procs in the 1st partition and one proc in the 2nd partition
 will be ordered consecutively, e.g. as the cores on one physical node.
 This can boost performance.  For example, if you use "-reorder nth 4"
 and "-partition 9 3" and you are running on 12 processors, the
 processors will be reordered from
 0 1 2 3 4 5 6 7 8 9 10 11 :pre
 to
 0 1 2 4 5 6 8 9 10 3 7 11 :pre
 so that the processors in each partition will be
 0 1 2 4 5 6 8 9 10
 3 7 11 :pre
 See the "processors" command for how to insure processors from each
 partition could then be grouped optimally for quad-core nodes.
 If the keyword is {custom}, then a file that specifies a permutation
 of the processor ranks is also specified.  The format of the reorder
 file is as follows.  Any number of initial blank or comment lines
 (starting with a "#" character) can be present.  These should be
 followed by P lines of the form:
 I J :pre
 where P is the number of processors LAMMPS was launched with.  Note
 that if running in multi-partition mode (see the -partition switch
 above) P is the total number of processors in all partitions.  The I
 and J values describe a permutation of the P processors.  Every I and
 J should be values from 0 to P-1 inclusive.  In the set of P I values,
 every proc ID should appear exactly once.  Ditto for the set of P J
 values.  A single I,J pairing means that the physical processor with
 rank I in the original MPI communicator will have rank J in the
 reordered communicator.
 Note that rank ordering can also be specified by many MPI
 implementations, either by environment variables that specify how to
 order physical processors, or by config files that specify what
 physical processors to assign to each MPI rank.  The -reorder switch
 simply gives you a portable way to do this without relying on MPI
 itself.  See the "processors out"_processors.html command for how
 to output info on the final assignment of physical processors to
 the LAMMPS simulation domain.
 :line
 [-screen file] :link(screen)
 Specify a file for LAMMPS to write its screen information to.  In
 one-partition mode, if the switch is not used, LAMMPS writes to the
 screen.  If this switch is used, LAMMPS writes to the specified file
 instead and you will see no screen output.  In multi-partition mode,
 if the switch is not used, hi-level status information is written to
 the screen.  Each partition also writes to a screen.N file where N is
 the partition ID.  If the switch is specified in multi-partition mode,
 the hi-level screen dump is named "file" and each partition also
 writes screen information to a file.N.  For both one-partition and
 multi-partition mode, if the specified file is "none", then no screen
 output is performed. Option -pscreen will override the name of the
 partition screen files file.N.
 :line
 [-suffix style args] :link(suffix)
 Use variants of various styles if they exist.  The specified style can
 be {cuda}, {gpu}, {intel}, {kk}, {omp}, {opt}, or {hybrid}.  These
 refer to optional packages that LAMMPS can be built with, as described
 in "Accelerate performance"_Speed.html.  The "gpu" style corresponds to the
 GPU package, the "intel" style to the USER-INTEL package, the "kk"
 style to the KOKKOS package, the "opt" style to the OPT package, and
 the "omp" style to the USER-OMP package. The hybrid style is the only
 style that accepts arguments. It allows for two packages to be
 specified. The first package specified is the default and will be used
 if it is available. If no style is available for the first package,
 the style for the second package will be used if available. For
 example, "-suffix hybrid intel omp" will use styles from the
 USER-INTEL package if they are installed and available, but styles for
 the USER-OMP package otherwise.
 Along with the "-package" command-line switch, this is a convenient
 mechanism for invoking accelerator packages and their options without
 having to edit an input script.
 As an example, all of the packages provide a "pair_style
 lj/cut"_pair_lj.html variant, with style names lj/cut/gpu,
 lj/cut/intel, lj/cut/kk, lj/cut/omp, and lj/cut/opt.  A variant style
 can be specified explicitly in your input script, e.g. pair_style
 lj/cut/gpu.  If the -suffix switch is used the specified suffix
 (gpu,intel,kk,omp,opt) is automatically appended whenever your input
 script command creates a new "atom"_atom_style.html,
 "pair"_pair_style.html, "fix"_fix.html, "compute"_compute.html, or
 "run"_run_style.html style.  If the variant version does not exist,
 the standard version is created.
 For the GPU package, using this command-line switch also invokes the
 default GPU settings, as if the command "package gpu 1" were used at
 the top of your input script.  These settings can be changed by using
 the "-package gpu" command-line switch or the "package
 gpu"_package.html command in your script.
 For the USER-INTEL package, using this command-line switch also
 invokes the default USER-INTEL settings, as if the command "package
 intel 1" were used at the top of your input script.  These settings
 can be changed by using the "-package intel" command-line switch or
 the "package intel"_package.html command in your script. If the
 USER-OMP package is also installed, the hybrid style with "intel omp"
 arguments can be used to make the omp suffix a second choice, if a
 requested style is not available in the USER-INTEL package.  It will
 also invoke the default USER-OMP settings, as if the command "package
 omp 0" were used at the top of your input script.  These settings can
 be changed by using the "-package omp" command-line switch or the
 "package omp"_package.html command in your script.
 For the KOKKOS package, using this command-line switch also invokes
 the default KOKKOS settings, as if the command "package kokkos" were
 used at the top of your input script.  These settings can be changed
 by using the "-package kokkos" command-line switch or the "package
 kokkos"_package.html command in your script.
 For the OMP package, using this command-line switch also invokes the
 default OMP settings, as if the command "package omp 0" were used at
 the top of your input script.  These settings can be changed by using
 the "-package omp" command-line switch or the "package
 omp"_package.html command in your script.
 The "suffix"_suffix.html command can also be used within an input
 script to set a suffix, or to turn off or back on any suffix setting
 made via the command line.
 :line
 [-var name value1 value2 ...] :link(var)
 Specify a variable that will be defined for substitution purposes when
 the input script is read.  This switch can be used multiple times to
 define multiple variables.  "Name" is the variable name which can be a
 single character (referenced as $x in the input script) or a full
 string (referenced as $\{abc\}).  An "index-style
 variable"_variable.html will be created and populated with the
 subsequent values, e.g. a set of filenames.  Using this command-line
 option is equivalent to putting the line "variable name index value1
 value2 ..."  at the beginning of the input script.  Defining an index
 variable as a command-line argument overrides any setting for the same
 index variable in the input script, since index variables cannot be
 re-defined.  
 See the "variable"_variable.html command for more info on defining
 index and other kinds of variables and the "Commands
 parse"_Commands_parse.html page for more info on using variables in
 input scripts.
 NOTE: Currently, the command-line parser looks for arguments that
 start with "-" to indicate new switches.  Thus you cannot specify
 multiple variable values if any of them start with a "-", e.g. a
 negative numeric value.  It is OK if the first value1 starts with a
 "-", since it is automatically skipped.
--- a/doc/src/Run_output.txt
+++ b/doc/src/Run_output.txt
@ -0,0 +1,176 @@
 "Higher level section"_Run.html - "LAMMPS WWW Site"_lws - "LAMMPS
 Documentation"_ld - "LAMMPS Commands"_lc :c
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
 :link(lc,Commands_all.html)
 :line
 Screen and logfile output :h3
 As LAMMPS reads an input script, it prints information to both the
 screen and a log file about significant actions it takes to setup a
 simulation.  When the simulation is ready to begin, LAMMPS performs
 various initializations, and prints info about the run it is about to
 perform, including the amount of memory (in MBytes per processor) that
 the simulation requires.  It also prints details of the initial
 thermodynamic state of the system.  During the run itself,
 thermodynamic information is printed periodically, every few
 timesteps.  When the run concludes, LAMMPS prints the final
 thermodynamic state and a total run time for the simulation.  It also
 appends statistics about the CPU time and storage requirements for the
 simulation.  An example set of statistics is shown here:
 Loop time of 2.81192 on 4 procs for 300 steps with 2004 atoms :pre
 Performance: 18.436 ns/day  1.302 hours/ns  106.689 timesteps/s
 97.0% CPU use with 4 MPI tasks x no OpenMP threads :pre
 MPI task timings breakdown:
 Section |  min time  |  avg time  |  max time  |%varavg| %total
 ---------------------------------------------------------------
 Pair    | 1.9808     | 2.0134     | 2.0318     |   1.4 | 71.60
 Bond    | 0.0021894  | 0.0060319  | 0.010058   |   4.7 |  0.21
 Kspace  | 0.3207     | 0.3366     | 0.36616    |   3.1 | 11.97
 Neigh   | 0.28411    | 0.28464    | 0.28516    |   0.1 | 10.12
 Comm    | 0.075732   | 0.077018   | 0.07883    |   0.4 |  2.74
 Output  | 0.00030518 | 0.00042665 | 0.00078821 |   1.0 |  0.02
 Modify  | 0.086606   | 0.086631   | 0.086668   |   0.0 |  3.08
 Other   |            | 0.007178   |            |       |  0.26 :pre
 Nlocal:    501 ave 508 max 490 min
 Histogram: 1 0 0 0 0 0 1 1 0 1
 Nghost:    6586.25 ave 6628 max 6548 min
 Histogram: 1 0 1 0 0 0 1 0 0 1
 Neighs:    177007 ave 180562 max 170212 min
 Histogram: 1 0 0 0 0 0 0 1 1 1 :pre
 Total # of neighbors = 708028
 Ave neighs/atom = 353.307
 Ave special neighs/atom = 2.34032
 Neighbor list builds = 26
 Dangerous builds = 0 :pre
 :line
 The first section provides a global loop timing summary. The {loop
 time} is the total wall-clock time for the simulation to run.  The
 {Performance} line is provided for convenience to help predict how
 long it will take to run a desired physical simulation.  The {CPU use}
 line provides the CPU utilization per MPI task; it should be close to
 100% times the number of OpenMP threads (or 1 of not using OpenMP).
 Lower numbers correspond to delays due to file I/O or insufficient
 thread utilization.
 :line
 The {MPI task} section gives the breakdown of the CPU run time (in
 seconds) into major categories:
 {Pair} = non-bonded force computations
 {Bond} = bonded interactions: bonds, angles, dihedrals, impropers
 {Kspace} = long-range interactions: Ewald, PPPM, MSM
 {Neigh} = neighbor list construction
 {Comm} = inter-processor communication of atoms and their properties
 {Output} = output of thermodynamic info and dump files
 {Modify} = fixes and computes invoked by fixes
 {Other} = all the remaining time :ul
 For each category, there is a breakdown of the least, average and most
 amount of wall time any processor spent on this category of
 computation.  The "%varavg" is the percentage by which the max or min
 varies from the average.  This is an indication of load imbalance.  A
 percentage close to 0 is perfect load balance.  A large percentage is
 imbalance.  The final "%total" column is the percentage of the total
 loop time is spent in this category.
 When using the "timer full"_timer.html setting, an additional column
 is added that also prints the CPU utilization in percent. In addition,
 when using {timer full} and the "package omp"_package.html command are
 active, a similar timing summary of time spent in threaded regions to
 monitor thread utilization and load balance is provided. A new {Thread
 timings} section is also added, which lists the time spent in reducing
 the per-thread data elements to the storage for non-threaded
 computation. These thread timings are measured for the first MPI rank
 only and and thus, because the breakdown for MPI tasks can change from
 MPI rank to MPI rank, this breakdown can be very different for
 individual ranks. Here is an example output for this section:
 Thread timings breakdown (MPI rank 0):
 Total threaded time 0.6846 / 90.6%
 Section |  min time  |  avg time  |  max time  |%varavg| %total
 ---------------------------------------------------------------
 Pair    | 0.5127     | 0.5147     | 0.5167     |   0.3 | 75.18
 Bond    | 0.0043139  | 0.0046779  | 0.0050418  |   0.5 |  0.68
 Kspace  | 0.070572   | 0.074541   | 0.07851    |   1.5 | 10.89
 Neigh   | 0.084778   | 0.086969   | 0.089161   |   0.7 | 12.70
 Reduce  | 0.0036485  | 0.003737   | 0.0038254  |   0.1 |  0.55 :pre
 :line
 The third section above lists the number of owned atoms (Nlocal),
 ghost atoms (Nghost), and pair-wise neighbors stored per processor.
 The max and min values give the spread of these values across
 processors with a 10-bin histogram showing the distribution. The total
 number of histogram counts is equal to the number of processors.
 :line
 The last section gives aggregate statistics (across all processors)
 for pair-wise neighbors and special neighbors that LAMMPS keeps track
 of (see the "special_bonds"_special_bonds.html command).  The number
 of times neighbor lists were rebuilt is tallied, as is the number of
 potentially {dangerous} rebuilds.  If atom movement triggered neighbor
 list rebuilding (see the "neigh_modify"_neigh_modify.html command),
 then dangerous reneighborings are those that were triggered on the
 first timestep atom movement was checked for.  If this count is
 non-zero you may wish to reduce the delay factor to insure no force
 interactions are missed by atoms moving beyond the neighbor skin
 distance before a rebuild takes place.
 :line
 If an energy minimization was performed via the
 "minimize"_minimize.html command, additional information is printed,
 e.g.
 Minimization stats:
  Stopping criterion = linesearch alpha is zero
  Energy initial, next-to-last, final =
         -6372.3765206     -8328.46998942     -8328.46998942
  Force two-norm initial, final = 1059.36 5.36874
  Force max component initial, final = 58.6026 1.46872
  Final line search alpha, max atom move = 2.7842e-10 4.0892e-10
  Iterations, force evaluations = 701 1516 :pre
 The first line prints the criterion that determined minimization was
 converged. The next line lists the initial and final energy, as well
 as the energy on the next-to-last iteration.  The next 2 lines give a
 measure of the gradient of the energy (force on all atoms).  The
 2-norm is the "length" of this 3N-component force vector; the largest
 component (x, y, or z) of force (infinity-norm) is also given.  Then
 information is provided about the line search and statistics on how
 many iterations and force-evaluations the minimizer required.
 Multiple force evaluations are typically done at each iteration to
 perform a 1d line minimization in the search direction.  See the
 "minimize"_minimize.html doc page for more details.
 :line
 If a "kspace_style"_kspace_style.html long-range Coulombics solver
 that performs FFTs was used during the run (PPPM, Ewald), then
 additional information is printed, e.g.
 FFT time (% of Kspce) = 0.200313 (8.34477)
 FFT Gflps 3d 1d-only = 2.31074 9.19989 :pre
 The first line is the time spent doing 3d FFTs (several per timestep)
 and the fraction it represents of the total KSpace time (listed
 above).  Each 3d FFT requires computation (3 sets of 1d FFTs) and
 communication (transposes).  The total flops performed is 5Nlog_2(N),
 where N is the number of points in the 3d grid.  The FFTs are timed
 with and without the communication and a Gflop rate is computed.  The
 3d rate is with communication; the 1d rate is without (just the 1d
 FFTs).  Thus you can estimate what fraction of your FFT time was spent
 in communication, roughly 75% in the example above.
--- a/doc/src/Run_windows.txt
+++ b/doc/src/Run_windows.txt
@ -0,0 +1,73 @@
 "Higher level section"_Run.html - "LAMMPS WWW Site"_lws - "LAMMPS
 Documentation"_ld - "LAMMPS Commands"_lc :c
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
 :link(lc,Commands_all.html)
 :line
 Running LAMMPS on Windows :h3
 To run a serial (non-MPI) executable, follow these steps:
 Get a command prompt by going to Start->Run... ,
 then typing "cmd". :ulb,l
 Move to the directory where you have your input script,
 (e.g. by typing: cd "Documents"). :l
 At the command prompt, type "lmp_serial -in in.file", where
 in.file is the name of your LAMMPS input script. :l,ule
 Note that the serial executable includes support for multi-threading
 parallelization from the styles in the USER-OMP packages.  To run with
 4 threads, you can type this:
 lmp_serial -in in.lj -pk omp 4 -sf omp :pre
 :line
 For the MPI executable, which allows you to run LAMMPS under Windows
 in parallel, follow these steps.
 Download and install a compatible MPI library binary package:
 for 32-bit Windows: "mpich2-1.4.1p1-win-ia32.msi"_download.lammps.org/thirdparty/mpich2-1.4.1p1-win-ia32.msi
 for 64-bit Windows: "mpich2-1.4.1p1-win-x86-64.msi"_download.lammps.org/thirdparty/mpich2-1.4.1p1-win-x86-64.msi :ul
 The LAMMPS Windows installer packages will automatically adjust your
 path for the default location of this MPI package. After the
 installation of the MPICH2 software, it needs to be integrated into
 the system.  For this you need to start a Command Prompt in
 {Administrator Mode} (right click on the icon and select it). Change
 into the MPICH2 installation directory, then into the subdirectory
 [bin] and execute [smpd.exe -install]. Exit the command window.
 Get a new, regular command prompt by going to Start->Run... ,
 then typing "cmd". :ulb,l
 Move to the directory where you have your input file
 (e.g. by typing: cd "Documents"). :l,ule
 Then type something like this:
 mpiexec -localonly 4 lmp_mpi -in in.file
 mpiexec -np 4 lmp_mpi -in in.file :pre
 where in.file is the name of your LAMMPS input script. For the latter
 case, you may be prompted to enter your password.
 In this mode, output may not immediately show up on the screen, so if
 your input script takes a long time to execute, you may need to be
 patient before the output shows up.
 The parallel executable can also run on a single processor by typing
 something like this:
 lmp_mpi -in in.lj :pre
 Note that the parallel executable also includes OpenMP
 multi-threading, which can be combined with MPI using something like:
 mpiexec -localonly 2 lmp_mpi -in in.lj -pk omp 2 -sf omp :pre
--- a/doc/src/Section_start.txt
+++ b/doc/src/Section_start.txt
--- a/doc/src/Speed.txt
+++ b/doc/src/Speed.txt
@ -31,15 +31,18 @@ hardware platforms.
 <!-- RST
 .. toctree::
   :maxdepth: 1
   Speed_bench
   Speed_measure
 .. toctree::
   :maxdepth: 1
   Speed_tips
 .. toctree::
   :maxdepth: 1
   Speed_packages
   Speed_compare
--- a/doc/src/Speed_gpu.txt
+++ b/doc/src/Speed_gpu.txt
@ -43,89 +43,22 @@ same functionality can eventually be supported on a variety of GPU
 hardware. :l
 :ule
 Here is a quick overview of how to enable and use the GPU package:
 build the library in lib/gpu for your GPU hardware with the desired precision settings
 install the GPU package and build LAMMPS as usual
 use the mpirun command to set the number of MPI tasks/node which determines the number of MPI tasks/GPU
 specify the # of GPUs per node
 use GPU styles in your input script :ul
 The latter two steps can be done using the "-pk gpu" and "-sf gpu"
 "command-line switches"_Section_start.html#start_6 respectively.  Or
 the effect of the "-pk" or "-sf" switches can be duplicated by adding
 the "package gpu"_package.html or "suffix gpu"_suffix.html commands
 respectively to your input script.
 [Required hardware/software:]
 To use this package, you currently need to have an NVIDIA GPU and
 install the NVIDIA CUDA software on your system:
-Check if you have an NVIDIA GPU: cat /proc/driver/nvidia/gpus/0/information
+Check if you have an NVIDIA GPU: cat
-Go to http://www.nvidia.com/object/cuda_get.html
+/proc/driver/nvidia/gpus/0/information Go to
-Install a driver and toolkit appropriate for your system (SDK is not necessary)
+http://www.nvidia.com/object/cuda_get.html Install a driver and
-Run lammps/lib/gpu/nvc_get_devices (after building the GPU library, see below) to list supported devices and properties :ul
+toolkit appropriate for your system (SDK is not necessary) Run
 lammps/lib/gpu/nvc_get_devices (after building the GPU library, see
 below) to list supported devices and properties :ul
 [Building LAMMPS with the GPU package:]
-This requires two steps (a,b): build the GPU library, then build
+See the "Build extras"_Build_extras.html#gpu doc page for
-LAMMPS with the GPU package.  You can do both these steps in one line
+instructions.
 as described on the "Packages details"_Packages_details.html#GPU doc
 page.
 Or you can follow these two (a,b) steps:
 (a) Build the GPU library
 The GPU library is in lammps/lib/gpu.  Select a Makefile.machine (in
 lib/gpu) appropriate for your system.  You should pay special
 attention to 3 settings in this makefile.
 CUDA_HOME = needs to be where NVIDIA CUDA software is installed on your system
 CUDA_ARCH = needs to be appropriate to your GPUs
 CUDA_PREC = precision (double, mixed, single) you desire :ul
 See lib/gpu/Makefile.linux.double for examples of the ARCH settings
 for different GPU choices, e.g. Fermi vs Kepler.  It also lists the
 possible precision settings:
 CUDA_PREC = -D_SINGLE_SINGLE  # single precision for all calculations
 CUDA_PREC = -D_DOUBLE_DOUBLE  # double precision for all calculations
 CUDA_PREC = -D_SINGLE_DOUBLE  # accumulation of forces, etc, in double :pre
 The last setting is the mixed mode referred to above.  Note that your
 GPU must support double precision to use either the 2nd or 3rd of
 these settings.
 To build the library, type:
 make -f Makefile.machine :pre
 If successful, it will produce the files libgpu.a and Makefile.lammps.
 The latter file has 3 settings that need to be appropriate for the
 paths and settings for the CUDA system software on your machine.
 Makefile.lammps is a copy of the file specified by the EXTRAMAKE
 setting in Makefile.machine.  You can change EXTRAMAKE or create your
 own Makefile.lammps.machine if needed.
 Note that to change the precision of the GPU library, you need to
 re-build the entire library.  Do a "clean" first, e.g. "make -f
 Makefile.linux clean", followed by the make command above.
 (b) Build LAMMPS with the GPU package
 cd lammps/src
 make yes-gpu
 make machine :pre
 No additional compile/link flags are needed in Makefile.machine.
 Note that if you change the GPU library precision (discussed above)
 and rebuild the GPU library, then you also need to re-install the GPU
 package and re-build LAMMPS, so that all affected files are
 re-compiled and linked to the new GPU library.
 [Run with the GPU package from the command line:]
@ -143,10 +76,10 @@ automatically if you create more MPI tasks/node than there are
 GPUs/mode.  E.g. with 8 MPI tasks/node and 2 GPUs, each GPU will be
 shared by 4 MPI tasks.
-Use the "-sf gpu" "command-line switch"_Section_start.html#start_6,
+Use the "-sf gpu" "command-line switch"_Run_options.html, which will
-which will automatically append "gpu" to styles that support it.  Use
+automatically append "gpu" to styles that support it.  Use the "-pk
-the "-pk gpu Ng" "command-line switch"_Section_start.html#start_6 to
+gpu Ng" "command-line switch"_Run_options.html to set Ng = # of
-set Ng = # of GPUs/node to use.
+GPUs/node to use.
 lmp_machine -sf gpu -pk gpu 1 -in in.script                         # 1 MPI task uses 1 GPU
 mpirun -np 12 lmp_machine -sf gpu -pk gpu 2 -in in.script           # 12 MPI tasks share 2 GPUs on a single 16-core (or whatever) node
@ -180,8 +113,8 @@ pair_style lj/cut/gpu 2.5 :pre
 You must also use the "package gpu"_package.html command to enable the
 GPU package, unless the "-sf gpu" or "-pk gpu" "command-line
-switches"_Section_start.html#start_6 were used.  It specifies the
+switches"_Run_options.html were used.  It specifies the number of
-number of GPUs/node to use, as well as other options.
+GPUs/node to use, as well as other options.
 [Speed-ups to expect:]
--- a/doc/src/Speed_intel.txt
+++ b/doc/src/Speed_intel.txt
@ -203,16 +203,12 @@ cat /proc/cpuinfo :pre
 [Building LAMMPS with the USER-INTEL package:]
-NOTE: See the src/USER-INTEL/README file for additional flags that
+See the "Build extras"_Build_extras.html#user-intel doc page for
-might be needed for best performance on Intel server processors
+instructions.  Some additional details are covered here.
 code-named "Skylake".
-The USER-INTEL package must be installed into the source directory:
+For building with make, several example Makefiles for building with
-
+the Intel compiler are included with LAMMPS in the src/MAKE/OPTIONS/
-make yes-user-intel :pre
+directory:
 Several example Makefiles for building with the Intel compiler are
 included with LAMMPS in the src/MAKE/OPTIONS/ directory:
 Makefile.intel_cpu_intelmpi # Intel Compiler, Intel MPI, No Offload
 Makefile.knl                # Intel Compiler, Intel MPI, No Offload
@ -221,20 +217,16 @@ Makefile.intel_cpu_openpmi  # Intel Compiler, OpenMPI, No Offload
 Makefile.intel_coprocessor  # Intel Compiler, Intel MPI, Offload :pre
 Makefile.knl is identical to Makefile.intel_cpu_intelmpi except that
-it explicitly specifies that vectorization should be for Intel
+it explicitly specifies that vectorization should be for Intel Xeon
-Xeon Phi x200 processors making it easier to cross-compile. For
+Phi x200 processors making it easier to cross-compile. For users with
-users with recent installations of Intel Parallel Studio, the
+recent installations of Intel Parallel Studio, the process can be as
-process can be as simple as:
+simple as:
 make yes-user-intel
 source /opt/intel/parallel_studio_xe_2016.3.067/psxevars.sh
 # or psxevars.csh for C-shell
 make intel_cpu_intelmpi :pre
 Alternatively this can be done as a single command with suitable make
 command invocations, as described on the "Packages
 details"_Packages_details.html#USER-INTEL doc page.
 Note that if you build with support for a Phi coprocessor, the same
 binary can be used on nodes with or without coprocessors installed.
 However, if you do not have coprocessors on your system, building
@ -253,6 +245,10 @@ required for CCFLAGS and "-qoffload" is required for LINKFLAGS. Other
 recommended CCFLAG options for best performance are "-O2 -fno-alias
 -ansi-alias -qoverride-limits fp-model fast=2 -no-prec-div".
 NOTE: See the src/USER-INTEL/README file for additional flags that
 might be needed for best performance on Intel server processors
 code-named "Skylake".
 NOTE: The vectorization and math capabilities can differ depending on
 the CPU. For Intel compilers, the "-x" flag specifies the type of
 processor for which to optimize. "-xHost" specifies that the compiler
@ -306,31 +302,31 @@ Hyper-Threading technology disabled.
 [Run with the USER-INTEL package from the command line:]
 To enable USER-INTEL optimizations for all available styles used in
-the input script, the "-sf intel"
+the input script, the "-sf intel" "command-line
-"command-line switch"_Section_start.html#start_6 can be used without
+switch"_Run_options.html can be used without any requirement for
-any requirement for editing the input script. This switch will
+editing the input script. This switch will automatically append
-automatically append "intel" to styles that support it. It also
+"intel" to styles that support it. It also invokes a default command:
-invokes a default command: "package intel 1"_package.html. This
+"package intel 1"_package.html. This package command is used to set
-package command is used to set options for the USER-INTEL package.
+options for the USER-INTEL package.  The default package command will
-The default package command will specify that USER-INTEL calculations
+specify that USER-INTEL calculations are performed in mixed precision,
-are performed in mixed precision, that the number of OpenMP threads
+that the number of OpenMP threads is specified by the OMP_NUM_THREADS
-is specified by the OMP_NUM_THREADS environment variable, and that
+environment variable, and that if coprocessors are present and the
-if coprocessors are present and the binary was built with offload
+binary was built with offload support, that 1 coprocessor per node
-support, that 1 coprocessor per node will be used with automatic
+will be used with automatic balancing of work between the CPU and the
-balancing of work between the CPU and the coprocessor.
+coprocessor.
 You can specify different options for the USER-INTEL package by using
-the "-pk intel Nphi" "command-line switch"_Section_start.html#start_6
+the "-pk intel Nphi" "command-line switch"_Run_options.html with
-with keyword/value pairs as specified in the documentation. Here,
+keyword/value pairs as specified in the documentation. Here, Nphi = #
-Nphi = # of Xeon Phi coprocessors/node (ignored without offload
+of Xeon Phi coprocessors/node (ignored without offload
 support). Common options to the USER-INTEL package include {omp} to
 override any OMP_NUM_THREADS setting and specify the number of OpenMP
-threads, {mode} to set the floating-point precision mode, and
+threads, {mode} to set the floating-point precision mode, and {lrt} to
-{lrt} to enable Long-Range Thread mode as described below. See the
+enable Long-Range Thread mode as described below. See the "package
-"package intel"_package.html command for details, including the
+intel"_package.html command for details, including the default values
-default values used for all its options if not specified, and how to
+used for all its options if not specified, and how to set the number
-set the number of OpenMP threads via the OMP_NUM_THREADS environment
+of OpenMP threads via the OMP_NUM_THREADS environment variable if
-variable if desired.
+desired.
 Examples (see documentation for your MPI/Machine for differences in
 launching MPI applications):
@ -390,19 +386,18 @@ lj/cut or when using LRT mode on processors supporting AVX-512.
 Not all styles are supported in the USER-INTEL package. You can mix
 the USER-INTEL package with styles from the "OPT"_Speed_opt.html
-package or the "USER-OMP package"_Speed_omp.html. Of course,
+package or the "USER-OMP package"_Speed_omp.html. Of course, this
-this requires that these packages were installed at build time. This
+requires that these packages were installed at build time. This can
-can performed automatically by using "-sf hybrid intel opt" or
+performed automatically by using "-sf hybrid intel opt" or "-sf hybrid
-"-sf hybrid intel omp" command-line options. Alternatively, the "opt"
+intel omp" command-line options. Alternatively, the "opt" and "omp"
-and "omp" suffixes can be appended manually in the input script. For
+suffixes can be appended manually in the input script. For the latter,
-the latter, the "package omp"_package.html command must be in the
+the "package omp"_package.html command must be in the input script or
-input script or the "-pk omp Nt" "command-line
+the "-pk omp Nt" "command-line switch"_Run_options.html must be used
-switch"_Section_start.html#start_6 must be used where Nt is the
+where Nt is the number of OpenMP threads. The number of OpenMP threads
-number of OpenMP threads. The number of OpenMP threads should not be
+should not be set differently for the different packages. Note that
-set differently for the different packages. Note that the "suffix
+the "suffix hybrid intel omp"_suffix.html command can also be used
-hybrid intel omp"_suffix.html command can also be used within the
+within the input script to automatically append the "omp" suffix to
-input script to automatically append the "omp" suffix to styles when
+styles when USER-INTEL styles are not available.
 USER-INTEL styles are not available.
 NOTE: For simulations on higher node counts, add "processors * * * 
 grid numa"_processors.html" to the beginning of the input script for
@ -496,8 +491,8 @@ sorting"_atom_modify.html is changed to 1 so that the per-atom data is
 effectively sorted at every rebuild of the neighbor lists. All the
 available coprocessor threads on each Phi will be divided among MPI
 tasks, unless the {tptask} option of the "-pk intel" "command-line
-switch"_Section_start.html#start_6 is used to limit the coprocessor
+switch"_Run_options.html is used to limit the coprocessor threads per
-threads per MPI task.
+MPI task.
 [Restrictions:]
--- a/doc/src/Speed_kokkos.txt
+++ b/doc/src/Speed_kokkos.txt
@ -37,100 +37,29 @@ task). These are Serial (MPI-only for CPUs and Intel Phi), OpenMP
 GPUs). You choose the mode at build time to produce an executable
 compatible with specific hardware.
 [Building LAMMPS with the KOKKOS package:]
 NOTE: Kokkos support within LAMMPS must be built with a C++11 compatible
 compiler. This means GCC version 4.7.2 or later, Intel 14.0.4 or later, or
 Clang 3.5.2 or later is required.
 The recommended method of building the KOKKOS package is to start with
 the provided Kokkos Makefiles in /src/MAKE/OPTIONS/. You may need to
 modify the KOKKOS_ARCH variable in the Makefile to match your specific
 hardware. For example:
 for Sandy Bridge CPUs, set KOKKOS_ARCH=SNB
 for Broadwell CPUs, set KOKKOS_ARCH=BWD
 for K80 GPUs, set KOKKOS_ARCH=Kepler37
 for P100 GPUs and Power8 CPUs, set KOKKOS_ARCH=Pascal60,Power8 :ul
 See the [Advanced Kokkos Options] section below for a listing of all
 KOKKOS_ARCH options.
 [Compile for CPU-only (MPI only, no threading):]
 use a C++11 compatible compiler and set KOKKOS_ARCH variable in
 /src/MAKE/OPTIONS/Makefile.kokkos_mpi_only as described above. Then do the
 following:
 cd lammps/src
 make yes-kokkos
 make kokkos_mpi_only :pre
 [Compile for CPU-only (MPI plus OpenMP threading):]
 NOTE: To build with Kokkos support for OpenMP threading, your compiler
 must support the OpenMP interface. You should have one or more
 multi-core CPUs so that multiple threads can be launched by each MPI
 task running on a CPU.
 Use a C++11 compatible compiler and set KOKKOS_ARCH variable in
 /src/MAKE/OPTIONS/Makefile.kokkos_omp as described above.  Then do the
 following:
 cd lammps/src
 make yes-kokkos
 make kokkos_omp :pre
 [Compile for Intel KNL Xeon Phi (Intel Compiler, OpenMPI):]
 use a C++11 compatible compiler and do the following:
 cd lammps/src
 make yes-kokkos
 make kokkos_phi :pre
 [Compile for CPUs and GPUs (with OpenMPI or MPICH):]
 NOTE: To build with Kokkos support for NVIDIA GPUs, NVIDIA CUDA
 software version 7.5 or later must be installed on your system. See
 the discussion for the "GPU package"_Speed_gpu.html for details of how
 to check and do this.
 NOTE: Kokkos with CUDA currently implicitly assumes, that the MPI
-library is CUDA-aware and has support for GPU-direct. This is not always
+library is CUDA-aware and has support for GPU-direct. This is not
-the case, especially when using pre-compiled MPI libraries provided by
+always the case, especially when using pre-compiled MPI libraries
-a Linux distribution. This is not a problem when using only a single
+provided by a Linux distribution. This is not a problem when using
-GPU and a single MPI rank on a desktop. When running with multiple
+only a single GPU and a single MPI rank on a desktop. When running
-MPI ranks, you may see segmentation faults without GPU-direct support.
+with multiple MPI ranks, you may see segmentation faults without
-These can be avoided by adding the flags '-pk kokkos gpu/direct off'
+GPU-direct support.  These can be avoided by adding the flags "-pk
-to the LAMMPS command line or by using the command
+kokkos gpu/direct off"_Run_options.html to the LAMMPS command line or
-"package kokkos gpu/direct off"_package.html in the input file.
+by using the command "package kokkos gpu/direct off"_package.html in
 the input file.
-Use a C++11 compatible compiler and set KOKKOS_ARCH variable in
+[Building LAMMPS with the KOKKOS package:]
 /src/MAKE/OPTIONS/Makefile.kokkos_cuda_mpi for both GPU and CPU as
 described above.  Then do the following:
-cd lammps/src
+See the "Build extras"_Build_extras.html#kokkos doc page for instructions.
 make yes-kokkos
 make kokkos_cuda_mpi :pre
 [Alternative Methods of Compiling:]
 Alternatively, the KOKKOS package can be built by specifying Kokkos variables
 on the make command line. For example:
 make mpi KOKKOS_DEVICES=OpenMP KOKKOS_ARCH=SNB     # set the KOKKOS_DEVICES and KOKKOS_ARCH variable explicitly
 make kokkos_cuda_mpi KOKKOS_ARCH=Pascal60,Power8   # set the KOKKOS_ARCH variable explicitly :pre
 Setting the KOKKOS_DEVICES and KOKKOS_ARCH variables on the make
 command line requires a GNU-compatible make command. Try "gmake" if
 your system's standard make complains.
 NOTE: If you build using make line variables and re-build LAMMPS twice
 with different KOKKOS options and the *same* target, then you *must*
 perform a "make clean-all" or "make clean-machine" before each
 build. This is to force all the KOKKOS-dependent files to be
 re-compiled with the new options.
 [Running LAMMPS with the KOKKOS package:]
@ -152,12 +81,11 @@ mpirun -np 2 lmp_kokkos_omp -k on t 8 -sf kk -in in.lj          # 1 node,  2 MPI
 mpirun -np 32 -ppn 4 lmp_kokkos_omp -k on t 4 -sf kk -in in.lj  # 8 nodes, 4 MPI tasks/node, 4 threads/task :pre
 To run using the KOKKOS package, use the "-k on", "-sf kk" and "-pk
-kokkos" "command-line switches"_Section_start.html#start_7 in your
+kokkos" "command-line switches"_Run_options.html in your mpirun
-mpirun command.  You must use the "-k on" "command-line
+command.  You must use the "-k on" "command-line
-switch"_Section_start.html#start_7 to enable the KOKKOS package. It
+switch"_Run_options.html to enable the KOKKOS package. It takes
-takes additional arguments for hardware settings appropriate to your
+additional arguments for hardware settings appropriate to your system.
-system. Those arguments are "documented
+For OpenMP use:
 here"_Section_start.html#start_7. For OpenMP use:
 -k on t Nt :pre
@ -172,11 +100,11 @@ command (with no additional arguments) which sets various KOKKOS
 options to default values, as discussed on the "package"_package.html
 command doc page.
-The "-sf kk" "command-line switch"_Section_start.html#start_7 will
+The "-sf kk" "command-line switch"_Run_options.html will automatically
-automatically append the "/kk" suffix to styles that support it.  In
+append the "/kk" suffix to styles that support it.  In this manner no
-this manner no modification to the input script is
+modification to the input script is needed. Alternatively, one can run
-needed. Alternatively, one can run with the KOKKOS package by editing
+with the KOKKOS package by editing the input script as described
-the input script as described below.
+below.
 NOTE: The default for the "package kokkos"_package.html command is to
 use "full" neighbor lists and set the Newton flag to "off" for both
@ -184,10 +112,10 @@ pairwise and bonded interactions. However, when running on CPUs, it
 will typically be faster to use "half" neighbor lists and set the
 Newton flag to "on", just as is the case for non-accelerated pair
 styles. It can also be faster to use non-threaded communication.  Use
-the "-pk kokkos" "command-line switch"_Section_start.html#start_7 to
+the "-pk kokkos" "command-line switch"_Run_options.html to change the
-change the default "package kokkos"_package.html options. See its doc
+default "package kokkos"_package.html options. See its doc page for
-page for details and default settings. Experimenting with its options
+details and default settings. Experimenting with its options can
-can provide a speed-up for specific calculations. For example:
+provide a speed-up for specific calculations. For example:
 mpirun -np 16 lmp_kokkos_mpi_only -k on -sf kk -pk kokkos newton on neigh half comm no -in in.lj       # Newton on, Half neighbor list, non-threaded comm :pre
@ -247,10 +175,10 @@ pairwise and bonded interactions. When running on KNL, this will
 typically be best for pair-wise potentials. For manybody potentials,
 using "half" neighbor lists and setting the Newton flag to "on" may be
 faster. It can also be faster to use non-threaded communication.  Use
-the "-pk kokkos" "command-line switch"_Section_start.html#start_7 to
+the "-pk kokkos" "command-line switch"_Run_options.html to change the
-change the default "package kokkos"_package.html options. See its doc
+default "package kokkos"_package.html options. See its doc page for
-page for details and default settings. Experimenting with its options
+details and default settings. Experimenting with its options can
-can provide a speed-up for specific calculations. For example:
+provide a speed-up for specific calculations. For example:
 mpirun -np 64 lmp_kokkos_phi -k on t 4 -sf kk -pk kokkos comm no -in in.lj      #  Newton off, full neighbor list, non-threaded comm
 mpirun -np 64 lmp_kokkos_phi -k on t 4 -sf kk -pk kokkos newton on neigh half comm no -in in.reax      # Newton on, half neighbor list, non-threaded comm :pre
@ -265,15 +193,16 @@ supports.
 [Running on GPUs:]
-Use the "-k" "command-line switch"_Section_start.html#start_7 to
+Use the "-k" "command-line switch"_Run_options.html to
 specify the number of GPUs per node. Typically the -np setting of the
 mpirun command should set the number of MPI tasks/node to be equal to
-the # of physical GPUs on the node.  You can assign multiple MPI tasks
+the number of physical GPUs on the node.  You can assign multiple MPI
-to the same GPU with the KOKKOS package, but this is usually only
+tasks to the same GPU with the KOKKOS package, but this is usually
-faster if significant portions of the input script have not been
+only faster if significant portions of the input script have not
-ported to use Kokkos. Using CUDA MPS is recommended in this
+been ported to use Kokkos. Using CUDA MPS is recommended in this
 scenario. Using a CUDA-aware MPI library with support for GPU-direct
-is highly recommended. GPU-direct use can be avoided by using "-pk kokkos gpu/direct no".
+is highly recommended. GPU-direct use can be avoided by using
 "-pk kokkos gpu/direct no"_package.html.
 As above for multi-core CPUs (and no GPU), if N is the number of
 physical cores/node, then the number of MPI tasks/node should not
 exceed N.
@ -293,10 +222,10 @@ When running on Maxwell or Kepler GPUs, this will typically be
 best. For Pascal GPUs, using "half" neighbor lists and setting the
 Newton flag to "on" may be faster. For many pair styles, setting the
 neighbor binsize equal to the ghost atom cutoff will give speedup.
-Use the "-pk kokkos" "command-line switch"_Section_start.html#start_7
+Use the "-pk kokkos" "command-line switch"_Run_options.html to change
-to change the default "package kokkos"_package.html options. See its
+the default "package kokkos"_package.html options. See its doc page
-doc page for details and default settings. Experimenting with its
+for details and default settings. Experimenting with its options can
-options can provide a speed-up for specific calculations. For example:
+provide a speed-up for specific calculations. For example:
 mpirun -np 2 lmp_kokkos_cuda_openmpi -k on g 2 -sf kk -pk kokkos binsize 2.8 -in in.lj      # Set binsize = neighbor ghost cutoff
 mpirun -np 2 lmp_kokkos_cuda_openmpi -k on g 2 -sf kk -pk kokkos newton on neigh half binsize 2.8 -in in.lj      # Newton on, half neighborlist, set binsize = neighbor ghost cutoff :pre
@ -327,10 +256,9 @@ kk"_suffix.html commands to your input script.
 The discussion above for building LAMMPS with the KOKKOS package, the
 mpirun/mpiexec command, and setting appropriate thread are the same.
-You must still use the "-k on" "command-line
+You must still use the "-k on" "command-line switch"_Run_options.html
-switch"_Section_start.html#start_7 to enable the KOKKOS package, and
+to enable the KOKKOS package, and specify its additional arguments for
-specify its additional arguments for hardware options appropriate to
+hardware options appropriate to your system, as documented above.
 your system, as documented above.
 You can use the "suffix kk"_suffix.html command, or you can explicitly add a
 "kk" suffix to individual styles in your input script, e.g.
@ -339,7 +267,7 @@ pair_style lj/cut/kk 2.5 :pre
 You only need to use the "package kokkos"_package.html command if you
 wish to change any of its option defaults, as set by the "-k on"
-"command-line switch"_Section_start.html#start_7.
+"command-line switch"_Run_options.html.
 [Using OpenMP threading and CUDA together (experimental):]
@ -411,50 +339,18 @@ hardware.
 [Advanced Kokkos options:]
 There are other allowed options when building with the KOKKOS package.
-As above, they can be set either as variables on the make command line
+As explained on the "Build extras"_Build_extras.html#kokkos doc page,
-or in Makefile.machine. This is the full list of options, including
+they can be set either as variables on the make command line or in
-those discussed above. Each takes a value shown below. The default
+Makefile.machine, or they can be specified as CMake variables.  Each
-value is listed, which is set in the /lib/kokkos/Makefile.kokkos file.
+takes a value shown below.  The default value is listed, which is set
 in the lib/kokkos/Makefile.kokkos file.
 KOKKOS_DEVICES, values = {Serial}, {OpenMP}, {Pthreads}, {Cuda}, default = {OpenMP}
 KOKKOS_ARCH, values = {KNC}, {SNB}, {HSW}, {Kepler30}, {Kepler32}, {Kepler35}, {Kepler37}, {Maxwell50}, {Maxwell52}, {Maxwell53}, {Pascal60}, {Pascal61}, {ARMv80}, {ARMv81}, {ARMv81}, {ARMv8-ThunderX}, {BGQ}, {Power7}, {Power8}, {Power9}, {KNL}, {BDW}, {SKX}, default = {none}
 KOKKOS_DEBUG, values = {yes}, {no}, default = {no}
 KOKKOS_USE_TPLS, values = {hwloc}, {librt}, {experimental_memkind}, default = {none}
 KOKKOS_CXX_STANDARD, values = {c++11}, {c++1z}, default = {c++11}
 KOKKOS_OPTIONS, values = {aggressive_vectorization}, {disable_profiling}, default = {none}
 KOKKOS_CUDA_OPTIONS, values = {force_uvm}, {use_ldg}, {rdc}, {enable_lambda}, default = {enable_lambda} :ul
 KOKKOS_DEVICES sets the parallelization method used for Kokkos code
 (within LAMMPS). KOKKOS_DEVICES=Serial means that no threading will be used.
 KOKKOS_DEVICES=OpenMP means that OpenMP threading will be
 used. KOKKOS_DEVICES=Pthreads means that pthreads will be used.
 KOKKOS_DEVICES=Cuda means an NVIDIA GPU running CUDA will be used.
 KOKKOS_ARCH enables compiler switches needed when compiling for a
 specific hardware:
 ARMv80 = ARMv8.0 Compatible CPU
 ARMv81 = ARMv8.1 Compatible CPU
 ARMv8-ThunderX = ARMv8 Cavium ThunderX CPU
 SNB = Intel Sandy/Ivy Bridge CPUs
 HSW = Intel Haswell CPUs
 BDW = Intel Broadwell Xeon E-class CPUs
 SKX = Intel Sky Lake Xeon E-class HPC CPUs (AVX512)
 KNC = Intel Knights Corner Xeon Phi
 KNL = Intel Knights Landing Xeon Phi
 Kepler30 = NVIDIA Kepler generation CC 3.0
 Kepler32 = NVIDIA Kepler generation CC 3.2
 Kepler35 = NVIDIA Kepler generation CC 3.5
 Kepler37 = NVIDIA Kepler generation CC 3.7
 Maxwell50 = NVIDIA Maxwell generation CC 5.0
 Maxwell52 = NVIDIA Maxwell generation CC 5.2
 Maxwell53 = NVIDIA Maxwell generation CC 5.3
 Pascal60 = NVIDIA Pascal generation CC 6.0
 Pascal61 = NVIDIA Pascal generation CC 6.1
 BGQ = IBM Blue Gene/Q CPUs
 Power8 = IBM POWER8 CPUs
 Power9 = IBM POWER9 CPUs :ul
 KOKKOS_USE_TPLS=hwloc binds threads to hardware cores, so they do not
 migrate during a simulation. KOKKOS_USE_TPLS=hwloc should always be
 used if running with KOKKOS_DEVICES=Pthreads for pthreads. It is not
--- a/doc/src/Speed_measure.txt
+++ b/doc/src/Speed_measure.txt
@ -21,8 +21,8 @@ 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
+log file at the end of each LAMMPS run.  The
-section"_Section_start.html#start_7 of the manual has an overview.
+"Run_output"_Run_output.html doc page gives 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
--- a/doc/src/Speed_omp.txt
+++ b/doc/src/Speed_omp.txt
@ -10,42 +10,32 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 USER-OMP package :h3
 The USER-OMP package was developed by Axel Kohlmeyer at Temple
-University.  It provides multi-threaded versions of most pair styles,
+University.  It provides optimized and multi-threaded versions
-nearly all bonded styles (bond, angle, dihedral, improper), several
+of many pair styles, nearly all bonded styles (bond, angle, dihedral,
-Kspace styles, and a few fix styles.  The package currently uses the
+improper), several Kspace styles, and a few fix styles.  It uses
-OpenMP interface for multi-threading.
+the OpenMP interface for multi-threading, but can also be compiled
-
+without OpenMP support, providing optimized serial styles in that case.
 Here is a quick overview of how to use the USER-OMP package, assuming
 one or more 16-core nodes.  More details follow.
 use -fopenmp with CCFLAGS and LINKFLAGS in Makefile.machine
 make yes-user-omp
 make mpi                                   # build with USER-OMP package, if settings added to Makefile.mpi
 make omp                                   # or Makefile.omp already has settings :pre
 lmp_mpi -sf omp -pk omp 16 < in.script                         # 1 MPI task, 16 threads
 mpirun -np 4 lmp_mpi -sf omp -pk omp 4 -in in.script           # 4 MPI tasks, 4 threads/task
 mpirun -np 32 -ppn 4 lmp_mpi -sf omp -pk omp 4 -in in.script   # 8 nodes, 4 MPI tasks/node, 4 threads/task :pre
 [Required hardware/software:]
-Your compiler must support the OpenMP interface.  You should have one
+To enable multi-threading, your compiler must support the OpenMP interface.
-or more multi-core CPUs so that multiple threads can be launched by
+You should have one or more multi-core CPUs, as multiple threads can only be
-each MPI task running on a CPU.
+launched by each MPI task on the local node (using shared memory).
 [Building LAMMPS with the USER-OMP package:]
-The lines above illustrate how to include/build with the USER-OMP
+See the "Build extras"_Build_extras.html#user-omp doc page for
-package in two steps, using the "make" command.  Or how to do it with
+instructions.
 one command as described on the "Packages
 details"_Packages_details.html#USER-OMP doc page.
 Note that the CCFLAGS and LINKFLAGS settings in Makefile.machine must
 include "-fopenmp".  Likewise, if you use an Intel compiler, the
 CCFLAGS setting must include "-restrict".
 [Run with the USER-OMP package from the command line:]
 These example asume one or more 16-core nodes.
 env OMP_NUM_THREADS=16 lmp_omp -sf omp -in in.script           # 1 MPI task, 16 threads according to OMP_NUM_THREADS
 lmp_mpi -sf omp -in in.script                                  # 1 MPI task, no threads, optimized kernels
 mpirun -np 4 lmp_omp -sf omp -pk omp 4 -in in.script           # 4 MPI tasks, 4 threads/task
 mpirun -np 32 -ppn 4 lmp_omp -sf omp -pk omp 4 -in in.script   # 8 nodes, 4 MPI tasks/node, 4 threads/task :pre
 The mpirun or mpiexec command sets the total number of MPI tasks used
 by LAMMPS (one or multiple per compute node) and the number of MPI
 tasks used per node.  E.g. the mpirun command in MPICH does this via
@ -57,19 +47,18 @@ threads/task should not exceed the physical number of cores (on a
 node), otherwise performance will suffer.
 As in the lines above, use the "-sf omp" "command-line
-switch"_Section_start.html#start_6, which will automatically append
+switch"_Run_options.html, which will automatically append "omp" to
-"omp" to styles that support it.  The "-sf omp" switch also issues a
+styles that support it.  The "-sf omp" switch also issues a default
-default "package omp 0"_package.html command, which will set the
+"package omp 0"_package.html command, which will set the number of
-number of threads per MPI task via the OMP_NUM_THREADS environment
+threads per MPI task via the OMP_NUM_THREADS environment variable.
 variable.
 You can also use the "-pk omp Nt" "command-line
-switch"_Section_start.html#start_6, to explicitly set Nt = # of OpenMP
+switch"_Run_options.html, to explicitly set Nt = # of OpenMP threads
-threads per MPI task to use, as well as additional options.  Its
+per MPI task to use, as well as additional options.  Its syntax is the
-syntax is the same as the "package omp"_package.html command whose doc
+same as the "package omp"_package.html command whose doc page gives
-page gives details, including the default values used if it is not
+details, including the default values used if it is not specified.  It
-specified.  It also gives more details on how to set the number of
+also gives more details on how to set the number of threads via the
-threads via the OMP_NUM_THREADS environment variable.
+OMP_NUM_THREADS environment variable.
 [Or run with the USER-OMP package by editing an input script:]
--- a/doc/src/Speed_opt.txt
+++ b/doc/src/Speed_opt.txt
@ -15,34 +15,21 @@ Technologies).  It contains a handful of pair styles whose compute()
 methods were rewritten in C++ templated form to reduce the overhead
 due to if tests and other conditional code.
 Here is a quick overview of how to use the OPT package.  More details
 follow.
 make yes-opt
 make mpi                               # build with the OPT package :pre
 lmp_mpi -sf opt -in in.script                # run in serial
 mpirun -np 4 lmp_mpi -sf opt -in in.script   # run in parallel :pre
 [Required hardware/software:]
 None.
 [Building LAMMPS with the OPT package:]
-The lines above illustrate how to build LAMMPS with the OPT package in
+See the "Build extras"_Build_extras.html#opt doc page for instructions.
 two steps, using the "make" command.  Or how to do it with one command
 as described on the "Packages details"_Packages_details.html#OPT doc
 page.
 Note that if you use an Intel compiler to build with the OPT package,
 the CCFLAGS setting in your Makefile.machine must include "-restrict".
 [Run with the OPT package from the command line:]
-As in the lines above, use the "-sf opt" "command-line
+lmp_mpi -sf opt -in in.script                # run in serial
-switch"_Section_start.html#start_6, which will automatically append
+mpirun -np 4 lmp_mpi -sf opt -in in.script   # run in parallel :pre
-"opt" to styles that support it.
+
 Use the "-sf opt" "command-line switch"_Run_options.html, which will
 automatically append "opt" to styles that support it.
 [Or run with the OPT package by editing an input script:]
--- a/doc/src/Speed_packages.txt
+++ b/doc/src/Speed_packages.txt
@ -93,11 +93,11 @@ 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, |
+enable specific accelerator support via '-k on' "command-line switch"_Run_options.html, |
  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, |
+set any needed options for the package via "-pk" "command-line switch"_Run_options.html 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
+use accelerated styles in your input via "-sf" "command-line switch"_Run_options.html 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
--- a/doc/src/Speed_tips.txt
+++ b/doc/src/Speed_tips.txt
@ -9,7 +9,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 General tips :h3
-NOTE: this section 5.2 is still a work in progress
+NOTE: this page 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
@ -20,13 +20,8 @@ problem size, number of processors used, and your machine.  There is
 no substitute for identifying performance bottlenecks, and trying out
 various options.
 make individual pages for these, or one for PPPM
 one for timestepping, etc
 one for balancing 
 or proc layout
 rRESPA
-2-FFT PPPM
+Two-FFT PPPM
 Staggered PPPM
 single vs double PPPM
 partial charge PPPM
@ -34,12 +29,13 @@ 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
+Two-FFT PPPM, also called {analytic differentiation} or {ad} PPPM,
-2 FFTs instead of the 4 FFTs used by the default {ik differentiation}
+uses 2 FFTs instead of the 4 FFTs used by the default {ik
-PPPM. However, 2-FFT PPPM also requires a slightly larger mesh size to
+differentiation} PPPM. However, 2-FFT PPPM also requires a slightly
-achieve the same accuracy as 4-FFT PPPM. For problems where the FFT
+larger mesh size to achieve the same accuracy as 4-FFT PPPM. For
-cost is the performance bottleneck (typically large problems running
+problems where the FFT cost is the performance bottleneck (typically
-on many processors), 2-FFT PPPM may be faster than 4-FFT PPPM.
+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
--- a/doc/src/Tools.txt
+++ b/doc/src/Tools.txt
@ -74,10 +74,9 @@ own sub-directories with their own Makefiles and/or README files.
 "vim"_#vim
 "xmgrace"_#xmgrace :ul
 :line
 :line
-amber2lmp tool :h4,link(amber)
+amber2lmp tool :h3,link(amber)
 The amber2lmp sub-directory contains two Python scripts for converting
 files back-and-forth between the AMBER MD code and LAMMPS.  See the
@ -92,7 +91,7 @@ necessary modifications yourself.
 :line
-binary2txt tool :h4,link(binary)
+binary2txt tool :h3,link(binary)
 The file binary2txt.cpp converts one or more binary LAMMPS dump file
 into ASCII text files.  The syntax for running the tool is
@ -105,7 +104,7 @@ since binary files are not compatible across all platforms.
 :line
-ch2lmp tool :h4,link(charmm)
+ch2lmp tool :h3,link(charmm)
 The ch2lmp sub-directory contains tools for converting files
 back-and-forth between the CHARMM MD code and LAMMPS.
@ -130,7 +129,7 @@ Chris Lorenz (chris.lorenz at kcl.ac.uk), King's College London.
 :line
-chain tool :h4,link(chain)
+chain tool :h3,link(chain)
 The file chain.f creates a LAMMPS data file containing bead-spring
 polymer chains and/or monomer solvent atoms.  It uses a text file
@ -147,7 +146,7 @@ for the "chain benchmark"_Speed_bench.html.
 :line
-colvars tools :h4,link(colvars)
+colvars tools :h3,link(colvars)
 The colvars directory contains a collection of tools for postprocessing
 data produced by the colvars collective variable library.
@ -169,7 +168,7 @@ gmail.com) at ICTP, Italy.
 :line
-createatoms tool :h4,link(createatoms)
+createatoms tool :h3,link(createatoms)
 The tools/createatoms directory contains a Fortran program called
 createAtoms.f which can generate a variety of interesting crystal
@ -182,7 +181,7 @@ The tool is authored by Xiaowang Zhou (Sandia), xzhou at sandia.gov.
 :line
-doxygen tool :h4,link(doxygen)
+doxygen tool :h3,link(doxygen)
 The tools/doxygen directory contains a shell script called
 doxygen.sh which can generate a call graph and API lists using
@ -194,7 +193,7 @@ The tool is authored by Nandor Tamaskovics, numericalfreedom at googlemail.com.
 :line
-drude tool :h4,link(drude)
+drude tool :h3,link(drude)
 The tools/drude directory contains a Python script called
 polarizer.py which can add Drude oscillators to a LAMMPS
@ -207,7 +206,7 @@ at univ-bpclermont.fr, alain.dequidt at univ-bpclermont.fr
 :line
-eam database tool :h4,link(eamdb)
+eam database tool :h3,link(eamdb)
 The tools/eam_database directory contains a Fortran program that will
 generate EAM alloy setfl potential files for any combination of 16
@ -223,7 +222,7 @@ X. W. Zhou, R. A. Johnson, and H. N. G. Wadley, Phys. Rev. B, 69,
 :line
-eam generate tool :h4,link(eamgn)
+eam generate tool :h3,link(eamgn)
 The tools/eam_generate directory contains several one-file C programs
 that convert an analytic formula into a tabulated "embedded atom
@ -236,7 +235,7 @@ The source files and potentials were provided by Gerolf Ziegenhain
 :line
-eff tool :h4,link(eff)
+eff tool :h3,link(eff)
 The tools/eff directory contains various scripts for generating
 structures and post-processing output for simulations using the
@ -247,7 +246,7 @@ These tools were provided by Andres Jaramillo-Botero at CalTech
 :line
-emacs tool :h4,link(emacs)
+emacs tool :h3,link(emacs)
 The tools/emacs directory contains an Emacs Lisp add-on file for GNU Emacs 
 that enables a lammps-mode for editing input scripts when using GNU Emacs,
@ -258,7 +257,7 @@ These tools were provided by Aidan Thompson at Sandia
 :line
-fep tool :h4,link(fep)
+fep tool :h3,link(fep)
 The tools/fep directory contains Python scripts useful for
 post-processing results from performing free-energy perturbation
@ -271,7 +270,7 @@ See README file in the tools/fep directory.
 :line
-i-pi tool :h4,link(ipi)
+i-pi tool :h3,link(ipi)
 The tools/i-pi directory contains a version of the i-PI package, with
 all the LAMMPS-unrelated files removed.  It is provided so that it can
@ -288,7 +287,7 @@ calculations with LAMMPS.
 :line
-ipp tool :h4,link(ipp)
+ipp tool :h3,link(ipp)
 The tools/ipp directory contains a Perl script ipp which can be used
 to facilitate the creation of a complicated file (say, a lammps input
@ -302,7 +301,7 @@ tools/createatoms tool's input file.
 :line
-kate tool :h4,link(kate)
+kate tool :h3,link(kate)
 The file in the tools/kate directory is an add-on to the Kate editor
 in the KDE suite that allow syntax highlighting of LAMMPS input
@ -313,7 +312,7 @@ The file was provided by Alessandro Luigi Sellerio
 :line
-lmp2arc tool :h4,link(arc)
+lmp2arc tool :h3,link(arc)
 The lmp2arc sub-directory contains a tool for converting LAMMPS output
 files to the format for Accelrys' Insight MD code (formerly
@ -329,7 +328,7 @@ Greathouse at Sandia (jagreat at sandia.gov).
 :line
-lmp2cfg tool :h4,link(cfg)
+lmp2cfg tool :h3,link(cfg)
 The lmp2cfg sub-directory contains a tool for converting LAMMPS output
 files into a series of *.cfg files which can be read into the
@ -340,7 +339,7 @@ This tool was written by Ara Kooser at Sandia (askoose at sandia.gov).
 :line
-matlab tool :h4,link(matlab)
+matlab tool :h3,link(matlab)
 The matlab sub-directory contains several "MATLAB"_matlabhome scripts for
 post-processing LAMMPS output.  The scripts include readers for log
@ -358,7 +357,7 @@ These scripts were written by Arun Subramaniyan at Purdue Univ
 :line
-micelle2d tool :h4,link(micelle)
+micelle2d tool :h3,link(micelle)
 The file micelle2d.f creates a LAMMPS data file containing short lipid
 chains in a monomer solution.  It uses a text file containing lipid
@ -375,7 +374,7 @@ definition file.  This tool was used to create the system for the
 :line
-moltemplate tool :h4,link(moltemplate)
+moltemplate tool :h3,link(moltemplate)
 The moltemplate sub-directory contains a Python-based tool for
 building molecular systems based on a text-file description, and
@ -389,7 +388,7 @@ supports it.  It has its own WWW page at
 :line
-msi2lmp tool :h4,link(msi)
+msi2lmp tool :h3,link(msi)
 The msi2lmp sub-directory contains a tool for creating LAMMPS template
 input and data files from BIOVIA's Materias Studio files (formerly Accelrys'
@ -406,7 +405,7 @@ See the README file in the tools/msi2lmp folder for more information.
 :line
-phonon tool :h4,link(phonon)
+phonon tool :h3,link(phonon)
 The phonon sub-directory contains a post-processing tool useful for
 analyzing the output of the "fix phonon"_fix_phonon.html command in
@ -421,7 +420,7 @@ University.
 :line
-polybond tool :h4,link(polybond)
+polybond tool :h3,link(polybond)
 The polybond sub-directory contains a Python-based tool useful for
 performing "programmable polymer bonding".  The Python file
@ -435,7 +434,7 @@ This tool was written by Zachary Kraus at Georgia Tech.
 :line
-pymol_asphere tool :h4,link(pymol)
+pymol_asphere tool :h3,link(pymol)
 The pymol_asphere sub-directory contains a tool for converting a
 LAMMPS dump file that contains orientation info for ellipsoidal
@ -453,7 +452,7 @@ This tool was written by Mike Brown at Sandia.
 :line
-python tool :h4,link(pythontools)
+python tool :h3,link(pythontools)
 The python sub-directory contains several Python scripts
 that perform common LAMMPS post-processing tasks, such as:
@ -469,7 +468,7 @@ README for more info on Pizza.py and how to use these scripts.
 :line
-reax tool :h4,link(reax_tool)
+reax tool :h3,link(reax_tool)
 The reax sub-directory contains stand-alond codes that can
 post-process the output of the "fix reax/bonds"_fix_reax_bonds.html
@ -480,7 +479,7 @@ These tools were written by Aidan Thompson at Sandia.
 :line
-smd tool :h4,link(smd)
+smd tool :h3,link(smd)
 The smd sub-directory contains a C++ file dump2vtk_tris.cpp and
 Makefile which can be compiled and used to convert triangle output
@ -496,7 +495,7 @@ Ernst Mach Institute in Germany (georg.ganzenmueller at emi.fhg.de).
 :line
-vim tool :h4,link(vim)
+vim tool :h3,link(vim)
 The files in the tools/vim directory are add-ons to the VIM editor
 that allow easier editing of LAMMPS input scripts.  See the README.txt
@ -507,7 +506,7 @@ ziegenhain.com)
 :line
-xmgrace tool :h4,link(xmgrace)
+xmgrace tool :h3,link(xmgrace)
 The files in the tools/xmgrace directory can be used to plot the
 thermodynamic data in LAMMPS log files via the xmgrace plotting
--- a/doc/src/angle_charmm.txt
+++ b/doc/src/angle_charmm.txt
@ -57,13 +57,13 @@ produce the same results, except for round-off and precision issues.
 These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
 USER-OMP and OPT packages, respectively.  They are only enabled if
-LAMMPS was built with those packages.  See the "Making
+LAMMPS was built with those packages.  See the "Build
-LAMMPS"_Section_start.html#start_3 section for more info.
+package"_Build_package.html doc page for more info.
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
-use the "suffix"_suffix.html command in your input script.
+"suffix"_suffix.html command in your input script.
 See "Speed packages"_Speed_packages.html doc page for more
 instructions on how to use the accelerated styles effectively.
@ -73,8 +73,8 @@ instructions on how to use the accelerated styles effectively.
 [Restrictions:]
 This angle style can only be used if LAMMPS was built with the
-MOLECULE package.  See the "Making
+MOLECULE package.  See the "Build package"_Build_package.html doc page
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+for more info.
 [Related commands:]
--- a/doc/src/angle_class2.txt
+++ b/doc/src/angle_class2.txt
@ -89,13 +89,13 @@ produce the same results, except for round-off and precision issues.
 These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
 USER-OMP and OPT packages, respectively.  They are only enabled if
-LAMMPS was built with those packages.  See the "Making
+LAMMPS was built with those packages.  See the "Build
-LAMMPS"_Section_start.html#start_3 section for more info.
+package"_Build_package.html doc page for more info.
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
-use the "suffix"_suffix.html command in your input script.
+"suffix"_suffix.html command in your input script.
 See the "Speed packages"_Speed_packages.html doc page for more
 instructions on how to use the accelerated styles effectively.
@ -123,8 +123,8 @@ The bond-bond and bond-angle terms remain unchanged.
 This angle style can only be used if LAMMPS was built with the CLASS2
 package.  For the {class2/p6} style LAMMPS needs to be built with the
-USER-MOFFF package.  See the "Making LAMMPS"_Section_start.html#start_3 
+USER-MOFFF package.  See the "Build package"_Build_package.html doc
-section for more info on packages.
+page for more info.
 [Related commands:]
--- a/doc/src/angle_cosine.txt
+++ b/doc/src/angle_cosine.txt
@ -44,13 +44,13 @@ produce the same results, except for round-off and precision issues.
 These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
 USER-OMP and OPT packages, respectively.  They are only enabled if
-LAMMPS was built with those packages.  See the "Making
+LAMMPS was built with those packages.  See the "Build
-LAMMPS"_Section_start.html#start_3 section for more info.
+package"_Build_package.html doc page for more info.
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
-use the "suffix"_suffix.html command in your input script.
+"suffix"_suffix.html command in your input script.
 See the "Speed packages"_Speed_packages.html doc page for more
 instructions on how to use the accelerated styles effectively.
@ -60,8 +60,8 @@ instructions on how to use the accelerated styles effectively.
 [Restrictions:]
 This angle style can only be used if LAMMPS was built with the
-MOLECULE package.  See the "Making
+MOLECULE package.  See the "Build package"_Build_package.html doc page
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+for more info.
 [Related commands:]
--- a/doc/src/angle_cosine_buck6d.txt
+++ b/doc/src/angle_cosine_buck6d.txt
@ -55,8 +55,8 @@ the "special_bonds"_special_bonds.html 1-3 interactions to be weighted
 "special_bonds"_special_bonds.html 0.0 weighting of 1-3 interactions.  
 This angle style can only be used if LAMMPS was built with the
-USER-MOFFF package.  See the "Making
+USER-MOFFF package.  See the "Build package"_Build_package.html doc
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+page for more info.
 [Related commands:]
--- a/doc/src/angle_cosine_delta.txt
+++ b/doc/src/angle_cosine_delta.txt
@ -49,13 +49,13 @@ produce the same results, except for round-off and precision issues.
 These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
 USER-OMP and OPT packages, respectively.  They are only enabled if
-LAMMPS was built with those packages.  See the "Making
+LAMMPS was built with those packages.  See the "Build
-LAMMPS"_Section_start.html#start_3 section for more info.
+package"_Build_package.html doc page for more info.
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
-use the "suffix"_suffix.html command in your input script.
+"suffix"_suffix.html command in your input script.
 See the "Speed packages"_Speed_packages.html doc page for more
 instructions on how to use the accelerated styles effectively.
@ -65,8 +65,8 @@ instructions on how to use the accelerated styles effectively.
 [Restrictions:]
 This angle style can only be used if LAMMPS was built with the
-MOLECULE package.  See the "Making
+MOLECULE package.  See the "Build package"_Build_package.html doc page
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+for more info.
 [Related commands:]
--- a/doc/src/angle_cosine_periodic.txt
+++ b/doc/src/angle_cosine_periodic.txt
@ -57,13 +57,13 @@ produce the same results, except for round-off and precision issues.
 These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
 USER-OMP and OPT packages, respectively.  They are only enabled if
-LAMMPS was built with those packages.  See the "Making
+LAMMPS was built with those packages.  See the "Build
-LAMMPS"_Section_start.html#start_3 section for more info.
+package"_Build_package.html doc page for more info.
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
-use the "suffix"_suffix.html command in your input script.
+"suffix"_suffix.html command in your input script.
 See the "Speed packages"_Speed_packages.html doc page for more
 instructions on how to use the accelerated styles effectively.
@ -73,8 +73,8 @@ instructions on how to use the accelerated styles effectively.
 [Restrictions:]
 This angle style can only be used if LAMMPS was built with the
-MOLECULE package.  See the "Making
+MOLECULE package.  See the "Build package"_Build_package.html doc page
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+for more info.
 [Related commands:]
--- a/doc/src/angle_cosine_shift.txt
+++ b/doc/src/angle_cosine_shift.txt
@ -47,13 +47,13 @@ produce the same results, except for round-off and precision issues.
 These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
 USER-OMP and OPT packages, respectively.  They are only enabled if
-LAMMPS was built with those packages.  See the "Making
+LAMMPS was built with those packages.  See the "Build
-LAMMPS"_Section_start.html#start_3 section for more info.
+package"_Build_package.html doc page for more info.
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
-use the "suffix"_suffix.html command in your input script.
+"suffix"_suffix.html command in your input script.
 See the "Speed packages"_Speed_packages.html doc page for more
 instructions on how to use the accelerated styles effectively.
@ -63,8 +63,7 @@ instructions on how to use the accelerated styles effectively.
 [Restrictions:]
 This angle style can only be used if LAMMPS was built with the
-USER-MISC package.  See the "Making LAMMPS"_Section_start.html#start_3
+USER-MISC package.  
 section for more info on packages.
 [Related commands:]
--- a/doc/src/angle_cosine_shift_exp.txt
+++ b/doc/src/angle_cosine_shift_exp.txt
@ -59,13 +59,13 @@ produce the same results, except for round-off and precision issues.
 These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
 USER-OMP and OPT packages, respectively.  They are only enabled if
-LAMMPS was built with those packages.  See the "Making
+LAMMPS was built with those packages.  See the "Build
-LAMMPS"_Section_start.html#start_3 section for more info.
+package"_Build_package.html doc page for more info.
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
-use the "suffix"_suffix.html command in your input script.
+"suffix"_suffix.html command in your input script.
 See the "Speed packages"_Speed_packages.html doc page for more
 instructions on how to use the accelerated styles effectively.
@ -75,8 +75,8 @@ instructions on how to use the accelerated styles effectively.
 [Restrictions:]
 This angle style can only be used if LAMMPS was built with the
-USER-MISC package.  See the "Making LAMMPS"_Section_start.html#start_3
+USER-MISC package.  See the "Build package"_Build_package.html doc
-section for more info on packages.
+page for more info.
 [Related commands:]
--- a/doc/src/angle_cosine_squared.txt
+++ b/doc/src/angle_cosine_squared.txt
@ -49,13 +49,13 @@ produce the same results, except for round-off and precision issues.
 These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
 USER-OMP and OPT packages, respectively.  They are only enabled if
-LAMMPS was built with those packages.  See the "Making
+LAMMPS was built with those packages.  See the "Build
-LAMMPS"_Section_start.html#start_3 section for more info.
+package"_Build_package.html doc page for more info.
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
-use the "suffix"_suffix.html command in your input script.
+"suffix"_suffix.html command in your input script.
 See the "Speed packages"_Speed_packages.html doc page for more
 instructions on how to use the accelerated styles effectively.
@ -65,8 +65,8 @@ instructions on how to use the accelerated styles effectively.
 [Restrictions:]
 This angle style can only be used if LAMMPS was built with the
-MOLECULE package.  See the "Making
+MOLECULE package.  See the "Build package"_Build_package.html doc page
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+for more info.
 [Related commands:]
--- a/doc/src/angle_dipole.txt
+++ b/doc/src/angle_dipole.txt
@ -77,13 +77,13 @@ produce the same results, except for round-off and precision issues.
 These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
 USER-OMP and OPT packages, respectively.  They are only enabled if
-LAMMPS was built with those packages.  See the "Making
+LAMMPS was built with those packages.  See the "Build
-LAMMPS"_Section_start.html#start_3 section for more info.
+package"_Build_package.html doc page for more info.
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
-use the "suffix"_suffix.html command in your input script.
+"suffix"_suffix.html command in your input script.
 See the "Speed packages"_Speed_packages.html doc page for more
 instructions on how to use the accelerated styles effectively.
@ -91,8 +91,8 @@ instructions on how to use the accelerated styles effectively.
 [Restrictions:]
 This angle style can only be used if LAMMPS was built with the
-USER-MISC package.  See the "Making LAMMPS"_Section_start.html#start_2_3
+USER-MISC package.  See the "Build package"_Build_package.html doc
-section for more info on packages.
+page for more info.
 NOTE: In the "Angles" section of the data file, the atom ID 'j'
 defining the direction of the dipole vector to restrain must come
--- a/doc/src/angle_fourier.txt
+++ b/doc/src/angle_fourier.txt
@ -45,13 +45,13 @@ produce the same results, except for round-off and precision issues.
 These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
 USER-OMP and OPT packages, respectively.  They are only enabled if
-LAMMPS was built with those packages.  See the "Making
+LAMMPS was built with those packages.  See the "Build
-LAMMPS"_Section_start.html#start_3 section for more info.
+package"_Build_package.html doc page for more info.
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
-use the "suffix"_suffix.html command in your input script.
+"suffix"_suffix.html command in your input script.
 See the "Speed packages"_Speed_packages.html doc page for more
 instructions on how to use the accelerated styles effectively.
@ -61,8 +61,8 @@ instructions on how to use the accelerated styles effectively.
 [Restrictions:]
 This angle style can only be used if LAMMPS was built with the
-USER_MISC package.  See the "Making LAMMPS"_Section_start.html#start_3
+USER_MISC package.  See the "Build package"_Build_package.html doc
-section for more info on packages.
+page for more info.
 [Related commands:]
--- a/doc/src/angle_fourier_simple.txt
+++ b/doc/src/angle_fourier_simple.txt
@ -44,13 +44,13 @@ produce the same results, except for round-off and precision issues.
 These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
 USER-OMP and OPT packages, respectively.  They are only enabled if
-LAMMPS was built with those packages.  See the "Making
+LAMMPS was built with those packages.  See the "Build
-LAMMPS"_Section_start.html#start_3 section for more info.
+package"_Build_package.html doc page for more info.
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
-use the "suffix"_suffix.html command in your input script.
+"suffix"_suffix.html command in your input script.
 See the "Speed packages"_Speed_packages.html doc page for more
 instructions on how to use the accelerated styles effectively.
@ -60,8 +60,8 @@ instructions on how to use the accelerated styles effectively.
 [Restrictions:]
 This angle style can only be used if LAMMPS was built with the
-USER_MISC package.  See the "Making LAMMPS"_Section_start.html#start_3
+USER_MISC package.  See the "Build package"_Build_package.html doc
-section for more info on packages.
+page for more info.
 [Related commands:]
--- a/doc/src/angle_harmonic.txt
+++ b/doc/src/angle_harmonic.txt
@ -51,13 +51,13 @@ produce the same results, except for round-off and precision issues.
 These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
 USER-OMP and OPT packages, respectively.  They are only enabled if
-LAMMPS was built with those packages.  See the "Making
+LAMMPS was built with those packages.  See the "Build
-LAMMPS"_Section_start.html#start_3 section for more info.
+package"_Build_package.html doc page for more info.
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
-use the "suffix"_suffix.html command in your input script.
+"suffix"_suffix.html command in your input script.
 See the "Speed packages"_Speed_packages.html doc page for more
 instructions on how to use the accelerated styles effectively.
@ -67,8 +67,8 @@ instructions on how to use the accelerated styles effectively.
 [Restrictions:]
 This angle style can only be used if LAMMPS was built with the
-MOLECULE package.  See the "Making LAMMPS"_Section_start.html#start_3
+MOLECULE package.  See the "Build package"_Build_package.html doc
-section for more info on packages.
+page for more info.
 [Related commands:]
--- a/doc/src/angle_hybrid.txt
+++ b/doc/src/angle_hybrid.txt
@ -76,8 +76,8 @@ for specific angle types.
 [Restrictions:]
 This angle style can only be used if LAMMPS was built with the
-MOLECULE package.  See the "Making
+MOLECULE package.  See the "Build package"_Build_package.html doc page
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+for more info.
 Unlike other angle styles, the hybrid angle style does not store angle
 coefficient info for individual sub-styles in a "binary restart
--- a/doc/src/angle_quartic.txt
+++ b/doc/src/angle_quartic.txt
@ -51,13 +51,13 @@ produce the same results, except for round-off and precision issues.
 These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
 USER-OMP and OPT packages, respectively.  They are only enabled if
-LAMMPS was built with those packages.  See the "Making
+LAMMPS was built with those packages.  See the "Build
-LAMMPS"_Section_start.html#start_3 section for more info.
+package"_Build_package.html doc page for more info.
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
-use the "suffix"_suffix.html command in your input script.
+"suffix"_suffix.html command in your input script.
 See the "Speed packages"_Speed_packages.html doc page for more
 instructions on how to use the accelerated styles effectively.
@ -67,8 +67,8 @@ instructions on how to use the accelerated styles effectively.
 [Restrictions:]
 This angle style can only be used if LAMMPS was built with the
-USER_MISC package.  See the "Making LAMMPS"_Section_start.html#start_3
+USER_MISC package.  See the "Build package"_Build_package.html doc
-section for more info on packages.
+page for more info.
 [Related commands:]
--- a/doc/src/angle_sdk.txt
+++ b/doc/src/angle_sdk.txt
@ -46,8 +46,8 @@ from the pair_style.
 [Restrictions:]
 This angle style can only be used if LAMMPS was built with the
-USER-CGSDK package.  See the "Making
+USER-CGSDK package.  See the "Build package"_Build_package.html doc
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+page for more info.
 [Related commands:]
--- a/doc/src/angle_style.txt
+++ b/doc/src/angle_style.txt
@ -83,10 +83,9 @@ Angle styles can only be set for atom_styles that allow angles to be
 defined.
 Most angle styles are part of the MOLECULE package.  They are only
-enabled if LAMMPS was built with that package.  See the "Making
+enabled if LAMMPS was built with that package.  See the "Build
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+package"_Build_package.html doc page for more info.  The doc pages for
-The doc pages for individual bond potentials tell if it is part of a
+individual bond potentials tell if it is part of a package.
 package.
 [Related commands:]
--- a/doc/src/angle_table.txt
+++ b/doc/src/angle_table.txt
@ -130,13 +130,13 @@ produce the same results, except for round-off and precision issues.
 These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
 USER-OMP and OPT packages, respectively.  They are only enabled if
-LAMMPS was built with those packages.  See the "Making
+LAMMPS was built with those packages.  See the "Build
-LAMMPS"_Section_start.html#start_3 section for more info.
+package"_Build_package.html doc page for more info.
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
-use the "suffix"_suffix.html command in your input script.
+"suffix"_suffix.html command in your input script.
 See the "Speed packages"_Speed_packages.html doc page for more
 instructions on how to use the accelerated styles effectively.
@ -146,8 +146,8 @@ instructions on how to use the accelerated styles effectively.
 [Restrictions:]
 This angle style can only be used if LAMMPS was built with the
-MOLECULE package.  See the "Making
+MOLECULE package.  See the "Build package"_Build_package.html doc page
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+for more info.
 [Related commands:]
--- a/doc/src/atom_modify.txt
+++ b/doc/src/atom_modify.txt
@ -58,9 +58,9 @@ simulation so large that IDs cannot be uniquely assigned.  For a
 default LAMMPS build this limit is 2^31 or about 2 billion atoms.
 However, even in this case, you can use 64-bit atom IDs, allowing 2^63
 or about 9e18 atoms, if you build LAMMPS with the - DLAMMPS_BIGBIG
-switch.  This is described in "Section 2.2"_Section_start.html#start_2
+switch.  This is described on the "Build_settings"_Build_settings.html
-of the manual.  If atom IDs are not used, they must be specified as 0
+doc page.  If atom IDs are not used, they must be specified as 0 for
-for all atoms, e.g. in a data or restart file.
+all atoms, e.g. in a data or restart file.
 The {map} keyword determines how atoms with specific IDs are found
 when required.  An example are the bond (angle, etc) methods which
--- a/doc/src/atom_style.txt
+++ b/doc/src/atom_style.txt
@ -272,13 +272,13 @@ USER-INTEL, USER-OMP, and OPT packages do not use accelerated atom
 styles.
 The accelerated styles are part of the KOKKOS package.  They are only
-enabled if LAMMPS was built with those packages.  See the "Making
+enabled if LAMMPS was built with those packages.  See the "Build
-LAMMPS"_Section_start.html#start_3 section for more info.
+package"_Build_package.html doc page for more info.
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
-use the "suffix"_suffix.html command in your input script.
+"suffix"_suffix.html command in your input script.
 See the "Speed packages"_Speed_packages.html doc page for more
 instructions on how to use the accelerated styles effectively.
@ -289,8 +289,8 @@ This command cannot be used after the simulation box is defined by a
 "read_data"_read_data.html or "create_box"_create_box.html command.
 Many of the styles listed above are only enabled if LAMMPS was built
-with a specific package, as listed below.  See the "Making
+with a specific package, as listed below.  See the "Build
-LAMMPS"_Section_start.html#start_3 section for more info.
+package"_Build_package.html doc page for more info.
 The {angle}, {bond}, {full}, {molecular}, and {template} styles are
 part of the MOLECULE package.
--- a/doc/src/balance.txt
+++ b/doc/src/balance.txt
@ -394,11 +394,11 @@ weights.  It assigns the same weight to each particle owned by a
 processor based on the total computational time spent by that
 processor.  See details below on what time window is used.  It uses
 the same timing information as is used for the "MPI task timing
-breakdown"_Section_start.html#start_7, namely, for sections {Pair},
+breakdown"_Run_output.html, namely, for sections {Pair}, {Bond},
-{Bond}, {Kspace}, and {Neigh}.  The time spent in those portions of
+{Kspace}, and {Neigh}.  The time spent in those portions of the
-the timestep are measured for each MPI rank, summed, then divided by
+timestep are measured for each MPI rank, summed, then divided by the
-the number of particles owned by that processor.  I.e. the weight is
+number of particles owned by that processor.  I.e. the weight is an
-an effective CPU time/particle averaged over the particles on that
+effective CPU time/particle averaged over the particles on that
 processor.
 The {factor} setting is applied as an overall scale factor to the
--- a/doc/src/bond_class2.txt
+++ b/doc/src/bond_class2.txt
@ -50,13 +50,13 @@ produce the same results, except for round-off and precision issues.
 These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
 USER-OMP and OPT packages, respectively.  They are only enabled if
-LAMMPS was built with those packages.  See the "Making
+LAMMPS was built with those packages.  See the "Build
-LAMMPS"_Section_start.html#start_3 section for more info.
+package"_Build_package.html doc page for more info.
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
-use the "suffix"_suffix.html command in your input script.
+"suffix"_suffix.html command in your input script.
 See the "Speed packages"_Speed_packages.html doc page for more
 instructions on how to use the accelerated styles effectively.
@ -66,8 +66,8 @@ instructions on how to use the accelerated styles effectively.
 [Restrictions:]
 This bond style can only be used if LAMMPS was built with the CLASS2
-package.  See the "Making LAMMPS"_Section_start.html#start_3 section
+package.  See the "Build package"_Build_package.html doc page for more
-for more info on packages.
+info.
 [Related commands:]
--- a/doc/src/bond_fene.txt
+++ b/doc/src/bond_fene.txt
@ -53,13 +53,13 @@ produce the same results, except for round-off and precision issues.
 These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
 USER-OMP and OPT packages, respectively.  They are only enabled if
-LAMMPS was built with those packages.  See the "Making
+LAMMPS was built with those packages.  See the "Build
-LAMMPS"_Section_start.html#start_3 section for more info.
+package"_Build_package.html doc page for more info.
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
-use the "suffix"_suffix.html command in your input script.
+"suffix"_suffix.html command in your input script.
 See the "Speed packages"_Speed_packages.html doc page for more
 instructions on how to use the accelerated styles effectively.
@ -68,9 +68,9 @@ instructions on how to use the accelerated styles effectively.
 [Restrictions:]
-This bond style can only be used if LAMMPS was built with the
+This bond style can only be used if LAMMPS was built with the MOLECULE
-MOLECULE package.  See the "Making
+package.  See the "Build package"_Build_package.html doc page for more
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+info.
 You typically should specify "special_bonds fene"_special_bonds.html
 or "special_bonds lj/coul 0 1 1"_special_bonds.html to use this bond
--- a/doc/src/bond_fene_expand.txt
+++ b/doc/src/bond_fene_expand.txt
@ -56,13 +56,13 @@ produce the same results, except for round-off and precision issues.
 These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
 USER-OMP and OPT packages, respectively.  They are only enabled if
-LAMMPS was built with those packages.  See the "Making
+LAMMPS was built with those packages.  See the "Build
-LAMMPS"_Section_start.html#start_3 section for more info.
+package"_Build_package.html doc page for more info.
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
-use the "suffix"_suffix.html command in your input script.
+"suffix"_suffix.html command in your input script.
 See the "Speed packages"_Speed_packages.html doc page for more
 instructions on how to use the accelerated styles effectively.
@ -71,9 +71,9 @@ instructions on how to use the accelerated styles effectively.
 [Restrictions:]
-This bond style can only be used if LAMMPS was built with the
+This bond style can only be used if LAMMPS was built with the MOLECULE
-MOLECULE package.  See the "Making
+package.  See the "Build package"_Build_package.html doc page for more
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+info.
 You typically should specify "special_bonds fene"_special_bonds.html
 or "special_bonds lj/coul 0 1 1"_special_bonds.html to use this bond
--- a/Show More
+++ b/Show More