diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS
index 75b79443c396085d703b9afb970ea06fdaf7478c..b91e58a83f43476d985fc513a98a77c943ce8789 100644
--- a/.github/CODEOWNERS
+++ b/.github/CODEOWNERS
@@ -17,6 +17,7 @@ src/GPU/* @ndtrung81
src/KOKKOS/* @stanmoore1
src/KIM/* @ellio167
src/LATTE/* @cnegre
+src/SPIN/* @julient31
src/USER-CGDNA/* @ohenrich
src/USER-CGSDK/* @akohlmey
src/USER-COLVARS/* @giacomofiorin
@@ -44,6 +45,7 @@ src/USER-MISC/*_grem.* @dstelter92
# tools
tools/msi2lmp/* @akohlmey
+tools/emacs/* @HaoZeke
# cmake
cmake/* @junghans @rbberger
diff --git a/README b/README
index 784b1cb13ea9abfc852cf790b1ed40c579305619..680986bf6146b9ddc77a092e6dcc6d4c09dd6b8e 100644
--- a/README
+++ b/README
@@ -36,7 +36,14 @@ tools pre- and post-processing tools
Point your browser at any of these files to get started:
-doc/Manual.html the LAMMPS manual
-doc/Section_intro.html hi-level introduction to LAMMPS
-doc/Section_start.html how to build and use LAMMPS
-doc/Developer.pdf LAMMPS developer guide
+http://lammps.sandia.gov/doc/Manual.html the LAMMPS manual
+http://lammps.sandia.gov/doc/Intro.html hi-level introduction
+http://lammps.sandia.gov/doc/Build.html how to build LAMMPS
+http://lammps.sandia.gov/doc/Run_head.html how to run LAMMPS
+http://lammps.sandia.gov/doc/Developer.pdf LAMMPS developer guide
+
+You can also create these doc pages locally:
+
+% cd doc
+% make html # creates HTML pages in doc/html
+% make pdf # creates Manual.pdf and Developer.pdf
diff --git a/cmake/CMakeLists.txt b/cmake/CMakeLists.txt
index bf57398c71b851d45848e90a6b8e1b1dbe8a8dcd..460d177c9236998897e0e7518708c44fb87956a2 100644
--- a/cmake/CMakeLists.txt
+++ b/cmake/CMakeLists.txt
@@ -9,6 +9,7 @@ set(SOVERSION 0)
get_filename_component(LAMMPS_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../src ABSOLUTE)
get_filename_component(LAMMPS_LIB_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../lib ABSOLUTE)
get_filename_component(LAMMPS_LIB_BINARY_DIR ${CMAKE_BINARY_DIR}/lib ABSOLUTE)
+get_filename_component(LAMMPS_DOC_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../doc ABSOLUTE)
# To avoid conflicts with the conventional Makefile build system, we build everything here
@@ -16,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)
@@ -105,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)
@@ -132,13 +157,22 @@ 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)
-add_definitions(-D${LAMMPS_SIZE_LIMIT})
-set(LAMMPS_API_DEFINES "${LAMMPS_API_DEFINES} -D${LAMMPS_SIZE_LIMIT}")
-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")
-add_definitions(-DLAMMPS_MEMALIGN=${LAMMPS_MEMALIGN})
+set(LAMMPS_SIZES "smallbig" CACHE STRING "LAMMPS size limit")
+set(LAMMPS_SIZES_VALUES smallbig bigbig smallsmall)
+set_property(CACHE LAMMPS_SIZES PROPERTY STRINGS ${LAMMPS_SIZES_VALUES})
+validate_option(LAMMPS_SIZES LAMMPS_SIZES_VALUES)
+string(TOUPPER ${LAMMPS_SIZES} LAMMPS_SIZES)
+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 to 0 to disable")
+ 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)
if(LAMMPS_EXCEPTIONS)
@@ -153,14 +187,15 @@ if(ENABLE_TESTING)
enable_testing()
endif(ENABLE_TESTING)
-set(DEFAULT_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE GRANULAR
- KSPACE MANYBODY MC MEAM MISC MOLECULE PERI QEQ REAX REPLICA RIGID SHOCK SPIN SNAP
+set(DEFAULT_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS DIPOLE GRANULAR
+ KSPACE MANYBODY MC MEAM MISC MOLECULE PERI REAX REPLICA RIGID SHOCK SPIN SNAP
SRD KIM PYTHON MSCG MPIIO VORONOI POEMS LATTE USER-ATC USER-AWPMD USER-BOCS
USER-CGDNA USER-MESO USER-CGSDK USER-COLVARS USER-DIFFRACTION USER-DPD USER-DRUDE
USER-EFF USER-FEP USER-H5MD USER-LB USER-MANIFOLD USER-MEAMC USER-MGPT USER-MISC
USER-MOFFF USER-MOLFILE USER-NETCDF USER-PHONON USER-QTB USER-REAXC USER-SMD
USER-SMTBQ USER-SPH USER-TALLY USER-UEF USER-VTK USER-QUIP USER-QMMM)
set(ACCEL_PACKAGES USER-OMP KOKKOS OPT USER-INTEL GPU)
+set(OTHER_PACKAGES CORESHELL QEQ)
foreach(PKG ${DEFAULT_PACKAGES})
option(PKG_${PKG} "Build ${PKG} Package" OFF)
endforeach()
@@ -174,13 +209,12 @@ macro(pkg_depends PKG1 PKG2)
endif()
endmacro()
+# "hard" dependencies between packages resulting
+# in an error instead of skipping over files
pkg_depends(MPIIO MPI)
-pkg_depends(QEQ MANYBODY)
pkg_depends(USER-ATC MANYBODY)
pkg_depends(USER-LB MPI)
-pkg_depends(USER-MISC MANYBODY)
pkg_depends(USER-PHONON KSPACE)
-pkg_depends(CORESHELL KSPACE)
######################################################
# packages with special compiler needs or external libs
@@ -212,10 +246,13 @@ 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)
- if(NOT FFT STREQUAL "KISSFFT")
+ set(FFT_VALUES KISS ${FFTW} MKL)
+ set_property(CACHE FFT PROPERTY STRINGS ${FFT_VALUES})
+ validate_option(FFT FFT_VALUES)
+ string(TOUPPER ${FFT} FFT)
+ if(NOT FFT STREQUAL "KISS")
find_package(${FFT} REQUIRED)
if(NOT FFT STREQUAL "FFTW3F")
add_definitions(-DFFT_FFTW)
@@ -224,11 +261,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_property(CACHE PACK_OPTIMIZATION PROPERTY STRINGS PACK_ARRAY PACK_POINTER PACK_MEMCPY)
- if(NOT PACK_OPTIMIZATION STREQUAL "PACK_ARRAY")
- add_definitions(-D${PACK_OPTIMIZATION})
+ set(FFT_PACK "array" CACHE STRING "Optimization for FFT")
+ set(FFT_PACK_VALUES array pointer memcpy)
+ set_property(CACHE FFT_PACK PROPERTY STRINGS ${FFT_PACK_VALUES})
+ 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()
@@ -306,10 +348,17 @@ if(PKG_VORONOI)
option(DOWNLOAD_VORO "Download voro++ (instead of using the system's one)" OFF)
if(DOWNLOAD_VORO)
include(ExternalProject)
+
+ if(BUILD_SHARED_LIBS)
+ set(VORO_BUILD_OPTIONS "CFLAGS=-fPIC")
+ else()
+ set(VORO_BUILD_OPTIONS)
+ endif()
+
ExternalProject_Add(voro_build
URL http://math.lbl.gov/voro++/download/dir/voro++-0.4.6.tar.gz
URL_MD5 2338b824c3b7b25590e18e8df5d68af9
- CONFIGURE_COMMAND "" BUILD_IN_SOURCE 1 INSTALL_COMMAND ""
+ CONFIGURE_COMMAND "" BUILD_COMMAND make ${VORO_BUILD_OPTIONS} BUILD_IN_SOURCE 1 INSTALL_COMMAND ""
)
ExternalProject_get_property(voro_build SOURCE_DIR)
set(VORO_LIBRARIES ${SOURCE_DIR}/src/libvoro++.a)
@@ -328,11 +377,14 @@ endif()
if(PKG_LATTE)
option(DOWNLOAD_LATTE "Download latte (instead of using the system's one)" OFF)
if(DOWNLOAD_LATTE)
+ if (CMAKE_VERSION VERSION_LESS "3.7") # due to SOURCE_SUBDIR
+ message(FATAL_ERROR "For downlading LATTE you need at least cmake-3.7")
+ endif()
message(STATUS "LATTE not found - we will build our own")
include(ExternalProject)
ExternalProject_Add(latte_build
URL https://github.com/lanl/LATTE/archive/v1.2.1.tar.gz
- URL_MD5 bed76e7e76c545c36dd848a8f1fd35eb
+ URL_MD5 85ac414fdada2d04619c8f936344df14
SOURCE_SUBDIR cmake
CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=<INSTALL_DIR> -DCMAKE_POSITION_INDEPENDENT_CODE=${CMAKE_POSITION_INDEPENDENT_CODE}
)
@@ -363,8 +415,8 @@ if(PKG_USER-NETCDF)
endif()
if(PKG_USER-SMD)
- option(DOWNLOAD_Eigen3 "Download Eigen3 (instead of using the system's one)" OFF)
- if(DOWNLOAD_Eigen3)
+ option(DOWNLOAD_EIGEN3 "Download Eigen3 (instead of using the system's one)" OFF)
+ if(DOWNLOAD_EIGEN3)
include(ExternalProject)
ExternalProject_Add(Eigen3_build
URL http://bitbucket.org/eigen/eigen/get/3.3.4.tar.gz
@@ -377,7 +429,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})
@@ -430,6 +482,9 @@ if(PKG_MSCG)
find_package(GSL REQUIRED)
option(DOWNLOAD_MSCG "Download latte (instead of using the system's one)" OFF)
if(DOWNLOAD_MSCG)
+ if (CMAKE_VERSION VERSION_LESS "3.7") # due to SOURCE_SUBDIR
+ message(FATAL_ERROR "For downlading LATTE you need at least cmake-3.7")
+ endif()
include(ExternalProject)
if(NOT LAPACK_FOUND)
set(EXTRA_MSCG_OPTS "-DLAPACK_LIBRARIES=${CMAKE_CURRENT_BINARY_DIR}/liblinalg.a")
@@ -466,6 +521,11 @@ if(PKG_COMPRESS)
list(APPEND LAMMPS_LINK_LIBS ${ZLIB_LIBRARIES})
endif()
+# the windows version of LAMMPS requires a couple extra libraries
+if(${CMAKE_SYSTEM_NAME} STREQUAL "Windows")
+ list(APPEND LAMMPS_LINK_LIBS -lwsock32 -lpsapi)
+endif()
+
########################################################################
# Basic system tests (standard libraries, headers, functions, types) #
########################################################################
@@ -483,12 +543,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)
- check_library_exists(${MATH_LIBRARIES} ${FUNC} "" FOUND_${FUNC}_${MATH_LIBRARIES})
- if(NOT FOUND_${FUNC}_${MATH_LIBRARIES})
- message(FATAL_ERROR "Could not find needed math function - ${FUNC}")
- endif(NOT FOUND_${FUNC}_${MATH_LIBRARIES})
-endforeach(FUNC)
+# RB: disabled this check because it breaks with KOKKOS CUDA enabled
+#foreach(FUNC sin cos)
+# check_library_exists(${MATH_LIBRARIES} ${FUNC} "" FOUND_${FUNC}_${MATH_LIBRARIES})
+# if(NOT FOUND_${FUNC}_${MATH_LIBRARIES})
+# message(FATAL_ERROR "Could not find needed math function - ${FUNC}")
+# endif(NOT FOUND_${FUNC}_${MATH_LIBRARIES})
+#endforeach(FUNC)
list(APPEND LAMMPS_LINK_LIBS ${MATH_LIBRARIES})
######################################
@@ -574,6 +635,41 @@ endif()
# packages which selectively include variants based on enabled styles
# e.g. accelerator packages
######################################################################
+if(PKG_CORESHELL)
+ set(CORESHELL_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/CORESHELL)
+ set(CORESHELL_SOURCES)
+ set_property(GLOBAL PROPERTY "CORESHELL_SOURCES" "${CORESHELL_SOURCES}")
+
+ # detects styles which have a CORESHELL version
+ RegisterStylesExt(${CORESHELL_SOURCES_DIR} cs CORESHELL_SOURCES)
+
+ get_property(CORESHELL_SOURCES GLOBAL PROPERTY CORESHELL_SOURCES)
+
+ list(APPEND LIB_SOURCES ${CORESHELL_SOURCES})
+ include_directories(${CORESHELL_SOURCES_DIR})
+endif()
+
+# Fix qeq/fire requires MANYBODY (i.e. COMB and COMB3) to be installed
+if(PKG_QEQ)
+ set(QEQ_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/QEQ)
+ file(GLOB QEQ_HEADERS ${QEQ_SOURCES_DIR}/fix*.h)
+ file(GLOB QEQ_SOURCES ${QEQ_SOURCES_DIR}/fix*.cpp)
+
+ if(NOT PKG_MANYBODY)
+ list(REMOVE_ITEM QEQ_HEADERS ${QEQ_SOURCES_DIR}/fix_qeq_fire.h)
+ list(REMOVE_ITEM QEQ_SOURCES ${QEQ_SOURCES_DIR}/fix_qeq_fire.cpp)
+ endif()
+ set_property(GLOBAL PROPERTY "QEQ_SOURCES" "${QEQ_SOURCES}")
+
+ foreach(MY_HEADER ${QEQ_HEADERS})
+ AddStyleHeader(${MY_HEADER} FIX)
+ endforeach()
+
+ get_property(QEQ_SOURCES GLOBAL PROPERTY QEQ_SOURCES)
+ list(APPEND LIB_SOURCES ${QEQ_SOURCES})
+ include_directories(${QEQ_SOURCES_DIR})
+endif()
+
if(PKG_USER-OMP)
set(USER-OMP_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/USER-OMP)
set(USER-OMP_SOURCES ${USER-OMP_SOURCES_DIR}/thr_data.cpp
@@ -585,8 +681,31 @@ if(PKG_USER-OMP)
# detects styles which have USER-OMP version
RegisterStylesExt(${USER-OMP_SOURCES_DIR} omp OMP_SOURCES)
+
get_property(USER-OMP_SOURCES GLOBAL PROPERTY OMP_SOURCES)
+ # manually add package dependent source files from USER-OMP that do not provide styles
+
+ if(PKG_ASPHERE)
+ list(APPEND USER-OMP_SOURCES ${USER-OMP_SOURCES_DIR}/fix_nh_asphere_omp.cpp)
+ endif()
+
+ if(PKG_RIGID)
+ list(APPEND USER-OMP_SOURCES ${USER-OMP_SOURCES_DIR}/fix_rigid_nh_omp.cpp)
+ endif()
+
+ if(PKG_USER-REAXC)
+ list(APPEND USER-OMP_SOURCES ${USER-OMP_SOURCES_DIR}/reaxc_bond_orders_omp.cpp
+ ${USER-OMP_SOURCES_DIR}/reaxc_hydrogen_bonds_omp.cpp
+ ${USER-OMP_SOURCES_DIR}/reaxc_nonbonded_omp.cpp
+ ${USER-OMP_SOURCES_DIR}/reaxc_bonds_omp.cpp
+ ${USER-OMP_SOURCES_DIR}/reaxc_init_md_omp.cpp
+ ${USER-OMP_SOURCES_DIR}/reaxc_torsion_angles_omp.cpp
+ ${USER-OMP_SOURCES_DIR}/reaxc_forces_omp.cpp
+ ${USER-OMP_SOURCES_DIR}/reaxc_multi_body_omp.cpp
+ ${USER-OMP_SOURCES_DIR}/reaxc_valence_angles_omp.cpp)
+ endif()
+
list(APPEND LIB_SOURCES ${USER-OMP_SOURCES})
include_directories(${USER-OMP_SOURCES_DIR})
endif()
@@ -618,6 +737,11 @@ if(PKG_KOKKOS)
${KOKKOS_PKG_SOURCES_DIR}/npair_kokkos.cpp
${KOKKOS_PKG_SOURCES_DIR}/domain_kokkos.cpp
${KOKKOS_PKG_SOURCES_DIR}/modify_kokkos.cpp)
+
+ if(PKG_KSPACE)
+ list(APPEND KOKKOS_PKG_SOURCES ${KOKKOS_PKG_SOURCES_DIR}/gridcomm_kokkos.cpp)
+ endif()
+
set_property(GLOBAL PROPERTY "KOKKOS_PKG_SOURCES" "${KOKKOS_PKG_SOURCES}")
# detects styles which have KOKKOS version
@@ -655,33 +779,55 @@ if(PKG_OPT)
endif()
if(PKG_USER-INTEL)
- if(NOT DEVELOPER_MODE)
- if(NOT CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
- message(FATAL_ERROR "USER-INTEL is only useful together with intel compiler")
- endif()
- if(CMAKE_CXX_COMPILER_VERSION VERSION_LESS 16)
+ find_package(TBB REQUIRED)
+ find_package(MKL REQUIRED)
+
+ if(NOT CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
+ 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)
- set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -xMIC-AVX512")
+
+ if(NOT BUILD_OMP)
+ 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)
+ string(TOUPPER ${INTEL_ARCH} INTEL_ARCH)
+
+ 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
@@ -714,11 +860,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_property(CACHE GPU_API PROPERTY STRINGS OpenCL CUDA)
-
- set(GPU_PREC "SINGLE_DOUBLE" CACHE STRING "LAMMPS GPU precision size")
- set_property(CACHE GPU_PREC PROPERTY STRINGS SINGLE_DOUBLE SINGLE_SINGLE DOUBLE_DOUBLE)
+ set(GPU_API "opencl" CACHE STRING "API used by GPU package")
+ 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 "mixed" CACHE STRING "LAMMPS GPU precision")
+ 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)
@@ -731,7 +891,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)
@@ -745,10 +905,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)
@@ -765,7 +925,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)
@@ -779,10 +939,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_property(CACHE OCL_TUNE PROPERTY STRINGS INTEL FERMI KEPLER CYPRESS GENERIC)
+ set(OCL_TUNE "generic" CACHE STRING "OpenCL Device Tuning")
+ 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)
@@ -804,7 +967,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)
@@ -900,6 +1063,80 @@ if(BUILD_EXE)
endif()
endif()
+###############################################################################
+# Build documentation
+###############################################################################
+option(BUILD_DOC "Build LAMMPS documentation" OFF)
+if(BUILD_DOC)
+ include(ProcessorCount)
+ ProcessorCount(NPROCS)
+ find_package(PythonInterp 3 REQUIRED)
+
+ set(VIRTUALENV ${PYTHON_EXECUTABLE} -m virtualenv)
+
+ file(GLOB DOC_SOURCES ${LAMMPS_DOC_DIR}/src/*.txt)
+ file(GLOB PDF_EXTRA_SOURCES ${LAMMPS_DOC_DIR}/src/lammps_commands*.txt ${LAMMPS_DOC_DIR}/src/lammps_support.txt ${LAMMPS_DOC_DIR}/src/lammps_tutorials.txt)
+ list(REMOVE_ITEM DOC_SOURCES ${PDF_EXTRA_SOURCES})
+
+ add_custom_command(
+ OUTPUT docenv
+ COMMAND ${VIRTUALENV} docenv
+ )
+
+ set(DOCENV_BINARY_DIR ${CMAKE_BINARY_DIR}/docenv/bin)
+
+ add_custom_command(
+ OUTPUT requirements.txt
+ DEPENDS docenv
+ COMMAND ${CMAKE_COMMAND} -E copy ${LAMMPS_DOC_DIR}/utils/requirements.txt requirements.txt
+ COMMAND ${DOCENV_BINARY_DIR}/pip install -r requirements.txt --upgrade
+ COMMAND ${DOCENV_BINARY_DIR}/pip install --upgrade ${LAMMPS_DOC_DIR}/utils/converters
+ )
+
+ set(RST_FILES "")
+ set(RST_DIR ${CMAKE_BINARY_DIR}/rst)
+ file(MAKE_DIRECTORY ${RST_DIR})
+ foreach(TXT_FILE ${DOC_SOURCES})
+ get_filename_component(FILENAME ${TXT_FILE} NAME_WE)
+ set(RST_FILE ${RST_DIR}/${FILENAME}.rst)
+ list(APPEND RST_FILES ${RST_FILE})
+ add_custom_command(
+ OUTPUT ${RST_FILE}
+ DEPENDS requirements.txt docenv ${TXT_FILE}
+ COMMAND ${DOCENV_BINARY_DIR}/txt2rst -o ${RST_DIR} ${TXT_FILE}
+ )
+ endforeach()
+
+ add_custom_command(
+ OUTPUT html
+ DEPENDS ${RST_FILES}
+ COMMAND ${CMAKE_COMMAND} -E copy_directory ${LAMMPS_DOC_DIR}/src ${RST_DIR}
+ COMMAND ${DOCENV_BINARY_DIR}/sphinx-build -j ${NPROCS} -b html -c ${LAMMPS_DOC_DIR}/utils/sphinx-config -d ${CMAKE_BINARY_DIR}/doctrees ${RST_DIR} html
+ )
+
+ add_custom_target(
+ doc ALL
+ DEPENDS html
+ SOURCES ${LAMMPS_DOC_DIR}/utils/requirements.txt ${DOC_SOURCES}
+ )
+
+ install(DIRECTORY ${CMAKE_BINARY_DIR}/html DESTINATION ${CMAKE_INSTALL_DOCDIR})
+endif()
+
+###############################################################################
+# Install potential files in data directory
+###############################################################################
+set(LAMMPS_POTENTIALS_DIR ${CMAKE_INSTALL_FULL_DATADIR}/lammps/potentials)
+install(DIRECTORY ${LAMMPS_SOURCE_DIR}/../potentials DESTINATION ${CMAKE_INSTALL_DATADIR}/lammps/potentials)
+
+configure_file(etc/profile.d/lammps.sh.in ${CMAKE_BINARY_DIR}/etc/profile.d/lammps.sh @ONLY)
+configure_file(etc/profile.d/lammps.csh.in ${CMAKE_BINARY_DIR}/etc/profile.d/lammps.csh @ONLY)
+install(
+ FILES ${CMAKE_BINARY_DIR}/etc/profile.d/lammps.sh
+ ${CMAKE_BINARY_DIR}/etc/profile.d/lammps.csh
+ DESTINATION ${CMAKE_INSTALL_SYSCONFDIR}/profile.d
+)
+
###############################################################################
# Testing
#
@@ -983,7 +1220,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}")
diff --git a/cmake/Modules/FindQUIP.cmake b/cmake/Modules/FindQUIP.cmake
index 4ee1baf4f878e4a1c684d1a71d6a6a2074a92ca9..b6d87d11fa1cc82fd65452074a48e7469f5d39b4 100644
--- 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_FOUND - True if fftw3 found.
+# QUIP_LIBRARIES - List of libraries of the QUIP package
+# QUIP_FOUND - True if QUIP library was found.
#
find_library(QUIP_LIBRARY NAMES quip)
diff --git a/cmake/Modules/FindTBB.cmake b/cmake/Modules/FindTBB.cmake
new file mode 100644
index 0000000000000000000000000000000000000000..8cc050817e6b919d3d77935afcd26f1fd4d1cce0
--- /dev/null
+++ 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 )
diff --git a/cmake/README.md b/cmake/README.md
index 5419063f6dc0c25382caa54ee1dc0dcd0030cf82..85375cd2aa49ca9ddb0bc97b0fa50d048a344f4a 100644
--- 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>
@@ -275,6 +285,16 @@ cmake -C ../cmake/presets/std_nolib.cmake ../cmake -DPKG_GPU=on
</dl>
</td>
</tr>
+<tr>
+ <td><code>BUILD_DOC</code></td>
+ <td>control whether to build LAMMPS documentation</td>
+ <td>
+ <dl>
+ <dt><code>off</code> (default)</dt>
+ <dt><code>on</code></dt>
+ </dl>
+ </td>
+</tr>
<tr>
<td><code>LAMMPS_LONGLONG_TO_LONG</code></td>
<td>Workaround if your system or MPI version does not recognize <code>long long</code> data types</td>
@@ -305,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></dt>
+ <dt><code>on</code> (default, if found)</dt>
+ <dt><code>off</code></dt>
</dl>
</td>
</tr>
@@ -315,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></dt>
+ <dt><code>on</code> (default, if found)</dt>
+ <dt><code>off</code></dt>
</dl>
</td>
</tr>
@@ -1261,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>
@@ -1269,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>PACK_POINTER</code></dt>
- <dt><code>PACK_MEMCPY</code></dt>
+ <dt><code>array (default)</code></dt>
+ <dt><code>pointer</code></dt>
+ <dt><code>memcpy</code></dt>
</dl>
</td>
</tr>
@@ -1367,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
@@ -1386,8 +1429,8 @@ target API.
<td>API used by GPU package</td>
<td>
<dl>
- <dt><code>OpenCL</code> (default)</dt>
- <dt><code>CUDA</code></dt>
+ <dt><code>opencl</code> (default)</dt>
+ <dt><code>cuda</code></dt>
</dl>
</td>
</tr>
@@ -1396,9 +1439,9 @@ target API.
<td>Precision size used by GPU package kernels</td>
<td>
<dl>
- <dt><code>SINGLE_DOUBLE</code></dt>
- <dt><code>SINGLE_SINGLE</code></dt>
- <dt><code>DOUBLE_DOUBLE</code></dt>
+ <dt><code>mixed</code> (default)</dt>
+ <dt><code>single</code></dt>
+ <dt><code>double</code></dt>
</dl>
</td>
</tr>
@@ -1407,12 +1450,12 @@ target API.
<td>Tuning target for OpenCL driver code</td>
<td>
<dl>
- <dt><code>GENERIC</code> (default)</dt>
- <dt><code>INTEL</code> (Intel CPU)</dt>
- <dt><code>PHI</code> (Intel Xeon Phi)</dt>
- <dt><code>FERMI</code> (NVIDIA)</dt>
- <dt><code>KEPLER</code> (NVIDIA)</dt>
- <dt><code>CYPRESS</code> (AMD)</dt>
+ <dt><code>generic</code> (default)</dt>
+ <dt><code>intel</code> (Intel CPU)</dt>
+ <dt><code>phi</code> (Intel Xeon Phi)</dt>
+ <dt><code>fermi</code> (NVIDIA)</dt>
+ <dt><code>kepler</code> (NVIDIA)</dt>
+ <dt><code>cypress</code> (AMD)</dt>
</dl>
</td>
</tr>
@@ -1421,11 +1464,11 @@ target API.
<td>CUDA SM architecture targeted by GPU package</td>
<td>
<dl>
- <dt><code>sm20</code> (Fermi)</dt>
- <dt><code>sm30</code> (Kepler)</dt>
- <dt><code>sm50</code> (Maxwell)</dt>
- <dt><code>sm60</code> (Pascal)</dt>
- <dt><code>sm70</code> (Volta)</dt>
+ <dt><code>sm_20</code> (Fermi)</dt>
+ <dt><code>sm_30</code> (Kepler)</dt>
+ <dt><code>sm_50</code> (Maxwell)</dt>
+ <dt><code>sm_60</code> (Pascal)</dt>
+ <dt><code>sm_70</code> (Volta)</dt>
</dl>
</td>
</tr>
@@ -1507,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>
@@ -1534,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>
@@ -1562,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>
@@ -1584,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>
@@ -1596,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
-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.
+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 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>
@@ -1633,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
```
diff --git a/cmake/etc/profile.d/lammps.csh.in b/cmake/etc/profile.d/lammps.csh.in
new file mode 100644
index 0000000000000000000000000000000000000000..def49bf75c0112503f7286dbb68843a258e993f3
--- /dev/null
+++ b/cmake/etc/profile.d/lammps.csh.in
@@ -0,0 +1,2 @@
+# set environment for LAMMPS executables to find potential files
+if ( "$?LAMMPS_POTENTIALS" == 0 ) setenv LAMMPS_POTENTIALS @LAMMPS_POTENTIALS_DIR@
diff --git a/cmake/etc/profile.d/lammps.sh.in b/cmake/etc/profile.d/lammps.sh.in
new file mode 100644
index 0000000000000000000000000000000000000000..acd75fa0cff7bae7013d8c32d8453e2083dc217d
--- /dev/null
+++ b/cmake/etc/profile.d/lammps.sh.in
@@ -0,0 +1,2 @@
+# set environment for LAMMPS executables to find potential files
+export LAMMPS_POTENTIALS=${LAMMPS_POTENTIALS-@LAMMPS_POTENTIALS_DIR@}
diff --git a/doc/Makefile b/doc/Makefile
index c8cc8bc1bd027947165d30d79df3a0a8f3c0d73b..81f362349950be2123d2da4bd14255e7f9f27739 100644
--- a/doc/Makefile
+++ b/doc/Makefile
@@ -49,11 +49,11 @@ help:
# ------------------------------------------
-clean-all:
+clean-all: clean
rm -rf $(BUILDDIR)/* utils/txt2html/txt2html.exe
clean:
- rm -rf $(RSTDIR) html
+ rm -rf $(RSTDIR) html old epub
rm -rf spelling
clean-spelling:
@@ -157,7 +157,7 @@ $(RSTDIR)/%.rst : src/%.txt $(TXT2RST)
@(\
mkdir -p $(RSTDIR) ; \
. $(VENV)/bin/activate ;\
- txt2rst $< > $@ ;\
+ txt2rst -v $< > $@ ;\
deactivate ;\
)
diff --git a/doc/src/Build.txt b/doc/src/Build.txt
new file mode 100644
index 0000000000000000000000000000000000000000..1046171de1c58ecd8c1fc358bc4b598d661ecc38
--- /dev/null
+++ b/doc/src/Build.txt
@@ -0,0 +1,47 @@
+"Previous Section"_Install.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Run_head.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
+ Build_basics
+ Build_settings
+ Build_package
+ 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
+"Basic build options"_Build_basics.html
+"Optional build settings"_Build_settings.html
+"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.
diff --git a/doc/src/Build_basics.txt b/doc/src/Build_basics.txt
new file mode 100644
index 0000000000000000000000000000000000000000..cee78aced3faafce24586e4543d344185500fc7d
--- /dev/null
+++ 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 :h4,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 :h4,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 :h4,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 :h4,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 :h4,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.
diff --git a/doc/src/Build_cmake.txt b/doc/src/Build_cmake.txt
new file mode 100644
index 0000000000000000000000000000000000000000..08c1c72180a417b259078753dd1245d4f93cc6ce
--- /dev/null
+++ b/doc/src/Build_cmake.txt
@@ -0,0 +1,196 @@
+"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"_https://github.com/lammps/lammps/blob/master/cmake/README.md
+for how to use CMake to build LAMMPS. If you are new to CMake it is a
+good place to start.
+
+: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. A handful of LAMMPS packages (KOKKOS, LATTE, MSCG) require a
+later version. CMake will print a message telling you if a later
+version is required. Installation instructions for CMake are below.
+
+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/.
diff --git a/doc/src/Build_extras.txt b/doc/src/Build_extras.txt
new file mode 100644
index 0000000000000000000000000000000000000000..5c33a0a4d44f97545e8d94819161e2bce9fad78e
--- /dev/null
+++ b/doc/src/Build_extras.txt
@@ -0,0 +1,952 @@
+"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.
+
+"COMPRESS"_#compress,
+"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,a=l)
+
+: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 # KIM library file (only needed if a custom location)
+-D KIM_INCLUDE_DIR=path # KIM include directory (only needed if a custom location) :pre
+
+If DOWNLOAD_KIM is set, the KIM library will be downloaded and built
+inside the CMake build directory. If the KIM library is already on
+your system (in a location CMake cannot find it), KIM_LIBRARY is the
+filename (plus path) of the KIM library file, not the directory the
+library file is in. KIM_INCLUDE_DIR is the directory the KIM include
+file is in.
+
+[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
+-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 # LATTE library file (only needed if a custom location) :pre
+
+If DOWNLOAD_LATTE is set, the LATTE library will be downloaded and
+built inside the CMake build directory. If the LATTE library is
+already on your system (in a location CMake cannot find it),
+LATTE_LIBRARY is the filename (plus path) of the LATTE library file,
+not the directory the library file is in.
+
+[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 # MSCG library file (only needed if a custom location)
+-D MSCG_INCLUDE_DIR=path # MSCG include directory (only needed if a custom location) :pre
+
+If DOWNLOAD_MSCG is set, the MSCG library will be downloaded and built
+inside the CMake build directory. If the MSCG library is already on
+your system (in a location CMake cannot find it), MSCG_LIBRARY is the
+filename (plus path) of the MSCG library file, not the directory the
+library file is in. MSCG_INCLUDE_DIR is the directory the MSCG
+include file is in.
+
+[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 # Voro++ library file (only needed if at custom location)
+-D VORO_INCLUDE_DIR=path # Voro++ include directory (only needed if at custom location) :pre
+
+If DOWNLOAD_VORO is set, the Voro++ library will be downloaded and
+built inside the CMake build directory. If the Voro++ library is
+already on your system (in a location CMake cannot find it),
+VORO_LIBRARY is the filename (plus path) of the Voro++ library file,
+not the directory the library file is in. VORO_INCLUDE_DIR is the
+directory the Voro++ include file is in.
+
+[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) :pre
+
+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
+
+If DOWNLOAD_EIGEN3 is set, the Eigen3 library will be downloaded and
+inside the CMake build directory. If the Eig3n3 library is already on
+your system (in a location CMake cannot find it), EIGEN3_INCLUDE_DIR
+is the directory the Eigen3++ include file is in.
+
+[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.
diff --git a/doc/src/Build_link.txt b/doc/src/Build_link.txt
new file mode 100644
index 0000000000000000000000000000000000000000..1a1b387f3fd07dc2ad20433e840e4e3775b17bba
--- /dev/null
+++ 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.
+
+
diff --git a/doc/src/Build_make.txt b/doc/src/Build_make.txt
new file mode 100644
index 0000000000000000000000000000000000000000..c00ce1f4208ba04a8517b98a9128cb63e886ef8b
--- /dev/null
+++ 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
diff --git a/doc/src/Build_package.txt b/doc/src/Build_package.txt
new file mode 100644
index 0000000000000000000000000000000000000000..4f71e9eb18067d4ef3210aada08a8722e38e8687
--- /dev/null
+++ b/doc/src/Build_package.txt
@@ -0,0 +1,223 @@
+"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:
+
+"COMPRESS"_Build_extras.html#compress,
+"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,a=l)
+
+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.
diff --git a/doc/src/Build_settings.txt b/doc/src/Build_settings.txt
new file mode 100644
index 0000000000000000000000000000000000000000..773217e3a0e205f4d818c349f7a96b09d7526eba
--- /dev/null
+++ 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 :h4,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 :h4,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 :h4,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 :h4,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 :h4,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 :h4,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 :h4,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
diff --git a/doc/src/Commands.txt b/doc/src/Commands.txt
new file mode 100644
index 0000000000000000000000000000000000000000..a1a94c6d29ce6e81189b40868cf429dbde26ceb4
--- /dev/null
+++ b/doc/src/Commands.txt
@@ -0,0 +1,53 @@
+"Previous Section"_Run_head.html - "LAMMPS WWW Site"_lws -
+"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
+Section"_Packages.html :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html#comm)
+
+:line
+
+Commands :h2
+
+These pages describe how a LAMMPS input script is formatted and the
+commands in it are used to define a LAMMPS simulation.
+
+<!-- RST
+
+.. toctree::
+ :maxdepth: 1
+
+ Commands_input
+ Commands_parse
+ Commands_structure
+ Commands_category
+
+.. toctree::
+ :maxdepth: 1
+
+ Commands_all
+ Commands_fix
+ Commands_compute
+ Commands_pair
+ Commands_bond
+ Commands_kspace
+
+END_RST -->
+
+<!-- HTML_ONLY -->
+
+"LAMMPS input scripts"_Commands_input.html
+"Parsing rules for input scripts"_Commands_parse.html
+"Input script structure"_Commands_structure.html
+"Commands by category"_Commands_category.html :all(b)
+
+"All commands"_Commands_all.html
+"Fix commands"_Commands_fix.html
+"Compute commands"_Commands_compute.html
+"Pair commands"_Commands_pair.html
+"Bond, angle, dihedral, improper commands"_Commands_bond.html
+"KSpace solvers"_Commands_kspace.html :all(b)
+
+<!-- END_HTML_ONLY -->
+
diff --git a/doc/src/Commands_all.txt b/doc/src/Commands_all.txt
new file mode 100644
index 0000000000000000000000000000000000000000..13db1272b928e558ceda0853df22162945e6c6e5
--- /dev/null
+++ b/doc/src/Commands_all.txt
@@ -0,0 +1,128 @@
+"Higher level section"_Commands.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
+
+"All commands"_Commands_all.html,
+"Fix styles"_Commands_fix.html,
+"Compute styles"_Commands_compute.html,
+"Pair styles"_Commands_pair.html,
+"Bond styles"_Commands_bond.html,
+"Angle styles"_Commands_bond.html#angle,
+"Dihedral styles"_Commands_bond.html#dihedral,
+"Improper styles"_Commands_bond.html#improper,
+"KSpace styles"_Commands_kspace.html :tb(c=3,ea=c)
+
+All commands :h3
+
+An alphabetic list of all LAMMPS commmands.
+
+"angle_coeff"_angle_coeff.html,
+"angle_style"_angle_style.html,
+"atom_modify"_atom_modify.html,
+"atom_style"_atom_style.html,
+"balance"_balance.html,
+"bond_coeff"_bond_coeff.html,
+"bond_style"_bond_style.html,
+"bond_write"_bond_write.html,
+"boundary"_boundary.html,
+"box"_box.html,
+"change_box"_change_box.html,
+"clear"_clear.html,
+"comm_modify"_comm_modify.html,
+"comm_style"_comm_style.html,
+"compute"_compute.html,
+"compute_modify"_compute_modify.html,
+"create_atoms"_create_atoms.html,
+"create_bonds"_create_bonds.html,
+"create_box"_create_box.html,
+"delete_atoms"_delete_atoms.html,
+"delete_bonds"_delete_bonds.html,
+"dielectric"_dielectric.html,
+"dihedral_coeff"_dihedral_coeff.html,
+"dihedral_style"_dihedral_style.html,
+"dimension"_dimension.html,
+"displace_atoms"_displace_atoms.html,
+"dump"_dump.html,
+"dump image"_dump_image.html,
+"dump_modify"_dump_modify.html,
+"dump movie"_dump_image.html,
+"dump netcdf"_dump_netcdf.html,
+"dump netcdf/mpiio"_dump_netcdf.html,
+"dump vtk"_dump_vtk.html,
+"echo"_echo.html,
+"fix"_fix.html,
+"fix_modify"_fix_modify.html,
+"group"_group.html,
+"group2ndx"_group2ndx.html,
+"if"_if.html,
+"info"_info.html,
+"improper_coeff"_improper_coeff.html,
+"improper_style"_improper_style.html,
+"include"_include.html,
+"jump"_jump.html,
+"kspace_modify"_kspace_modify.html,
+"kspace_style"_kspace_style.html,
+"label"_label.html,
+"lattice"_lattice.html,
+"log"_log.html,
+"mass"_mass.html,
+"minimize"_minimize.html,
+"min_modify"_min_modify.html,
+"min_style"_min_style.html,
+"molecule"_molecule.html,
+"ndx2group"_group2ndx.html,
+"neb"_neb.html,
+"neigh_modify"_neigh_modify.html,
+"neighbor"_neighbor.html,
+"newton"_newton.html,
+"next"_next.html,
+"package"_package.html,
+"pair_coeff"_pair_coeff.html,
+"pair_modify"_pair_modify.html,
+"pair_style"_pair_style.html,
+"pair_write"_pair_write.html,
+"partition"_partition.html,
+"prd"_prd.html,
+"print"_print.html,
+"processors"_processors.html,
+"python"_python.html,
+"quit"_quit.html,
+"read_data"_read_data.html,
+"read_dump"_read_dump.html,
+"read_restart"_read_restart.html,
+"region"_region.html,
+"replicate"_replicate.html,
+"rerun"_rerun.html,
+"reset_ids"_reset_ids.html,
+"reset_timestep"_reset_timestep.html,
+"restart"_restart.html,
+"run"_run.html,
+"run_style"_run_style.html,
+"set"_set.html,
+"shell"_shell.html,
+"special_bonds"_special_bonds.html,
+"suffix"_suffix.html,
+"tad"_tad.html,
+"temper"_temper.html,
+"temper/grem"_temper_grem.html,
+"temper/npt"_temper_npt.html,
+"thermo"_thermo.html,
+"thermo_modify"_thermo_modify.html,
+"thermo_style"_thermo_style.html,
+"timer"_timer.html,
+"timestep"_timestep.html,
+"uncompute"_uncompute.html,
+"undump"_undump.html,
+"unfix"_unfix.html,
+"units"_units.html,
+"variable"_variable.html,
+"velocity"_velocity.html,
+"write_coeff"_write_coeff.html,
+"write_data"_write_data.html,
+"write_dump"_write_dump.html,
+"write_restart"_write_restart.html :tb(c=6,ea=c)
diff --git a/doc/src/Commands_bond.txt b/doc/src/Commands_bond.txt
new file mode 100644
index 0000000000000000000000000000000000000000..48069d3120048e9d59ead6a3f2959be296d078de
--- /dev/null
+++ b/doc/src/Commands_bond.txt
@@ -0,0 +1,124 @@
+"Higher level section"_Commands.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)
+
+"All commands"_Commands_all.html,
+"Fix styles"_Commands_fix.html,
+"Compute styles"_Commands_compute.html,
+"Pair styles"_Commands_pair.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,
+"KSpace styles"_Commands_kspace.html :tb(c=3,ea=c)
+
+Bond, angle, dihedral, and improper commands :h3
+
+:line
+
+Bond_style potentials :h3,link(bond)
+
+All LAMMPS "bond_style"_bond_style.html commands. Some styles have
+accelerated versions. This is indicated by additional letters in
+parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
+OPT.
+
+"none"_bond_none.html,
+"zero"_bond_zero.html,
+"hybrid"_bond_hybrid.html :tb(c=3,ea=c)
+
+"class2 (ko)"_bond_class2.html,
+"fene (iko)"_bond_fene.html,
+"fene/expand (o)"_bond_fene_expand.html,
+"gromos (o)"_bond_gromos.html,
+"harmonic (ko)"_bond_harmonic.html,
+"harmonic/shift (o)"_bond_harmonic_shift.html,
+"harmonic/shift/cut (o)"_bond_harmonic_shift_cut.html,
+"morse (o)"_bond_morse.html,
+"nonlinear (o)"_bond_nonlinear.html,
+"oxdna/fene"_bond_oxdna.html,
+"oxdna2/fene"_bond_oxdna.html,
+"quartic (o)"_bond_quartic.html,
+"table (o)"_bond_table.html :tb(c=4,ea=c)
+
+:line
+
+Angle_style potentials :h3,link(angle)
+
+All LAMMPS "angle_style"_angle_style.html commands. Some styles have
+accelerated versions. This is indicated by additional letters in
+parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
+OPT.
+
+"none"_angle_none.html,
+"zero"_angle_zero.html,
+"hybrid"_angle_hybrid.html :tb(c=3,ea=c)
+
+"charmm (ko)"_angle_charmm.html,
+"class2 (ko)"_angle_class2.html,
+"cosine (o)"_angle_cosine.html,
+"cosine/delta (o)"_angle_cosine_delta.html,
+"cosine/periodic (o)"_angle_cosine_periodic.html,
+"cosine/shift (o)"_angle_cosine_shift.html,
+"cosine/shift/exp (o)"_angle_cosine_shift_exp.html,
+"cosine/squared (o)"_angle_cosine_squared.html,
+"dipole (o)"_angle_dipole.html,
+"fourier (o)"_angle_fourier.html,
+"fourier/simple (o)"_angle_fourier_simple.html,
+"harmonic (iko)"_angle_harmonic.html,
+"quartic (o)"_angle_quartic.html,
+"sdk"_angle_sdk.html,
+"table (o)"_angle_table.html :tb(c=4,ea=c)
+
+:line
+
+Dihedral_style potentials :h3,link(dihedral)
+
+All LAMMPS "dihedral_style"_dihedral_style.html commands. Some styles
+have accelerated versions. This is indicated by additional letters in
+parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
+OPT.
+
+"none"_dihedral_none.html,
+"zero"_dihedral_zero.html,
+"hybrid"_dihedral_hybrid.html :tb(c=3,ea=c)
+
+"charmm (iko)"_dihedral_charmm.html,
+"charmmfsw"_dihedral_charmm.html,
+"class2 (ko)"_dihedral_class2.html,
+"cosine/shift/exp (o)"_dihedral_cosine_shift_exp.html,
+"fourier (io)"_dihedral_fourier.html,
+"harmonic (io)"_dihedral_harmonic.html,
+"helix (o)"_dihedral_helix.html,
+"multi/harmonic (o)"_dihedral_multi_harmonic.html,
+"nharmonic (o)"_dihedral_nharmonic.html,
+"opls (iko)"_dihedral_opls.htm;,
+"quadratic (o)"_dihedral_quadratic.html,
+"spherical (o)"_dihedral_spherical.html,
+"table (o)"_dihedral_table.html,
+"table/cut"_dihedral_table_cut.html :tb(c=4,ea=c)
+
+:line
+
+Improper_style potentials :h3,link(improper)
+
+All LAMMPS "improper_style"_improper_style.html commands. Some styles
+have accelerated versions. This is indicated by additional letters in
+parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
+OPT.
+
+"none"_improper_none.html,
+"zero"_improper_zero.html,
+"hybrid"_improper_hybrid.html :tb(c=3,ea=c)
+
+"class2 (ko)"_improper_class2.html,
+"cossq (o)"_improper_cossq.html,
+"cvff (io)"_improper_cvff.html,
+"distance"_improper_distance.html,
+"fourier (o)"_improper_fourier.html,
+"harmonic (iko)"_improper_harmonic.html,
+"ring (o)"_improper_ring.html,
+"umbrella (o)"_improper_umbrella.html :tb(c=4,ea=c)
diff --git a/doc/src/Commands_category.txt b/doc/src/Commands_category.txt
new file mode 100644
index 0000000000000000000000000000000000000000..5d047c67272ef0e8bedb1d2d9e52260ee4be0b2e
--- /dev/null
+++ b/doc/src/Commands_category.txt
@@ -0,0 +1,141 @@
+"Higher level section"_Commands.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
+
+Commands by category :h3
+
+This page lists most of the LAMMPS commands, grouped by category. The
+"Commands all"_Commands_all.html doc page lists all commands
+alphabetically. It also includes long lists of style options for
+entries that appear in the following categories as a single command
+(fix, compute, pair, etc).
+
+Initialization:
+
+"newton"_newton.html,
+"package"_package.html,
+"processors"_processors.html,
+"suffix"_suffix.html,
+"units"_units.html :ul
+
+Setup simulation box:
+
+"boundary"_boundary.html,
+"box"_box.html,
+"change_box"_change_box.html,
+"create_box"_create_box.html,
+"dimension"_dimension.html,
+"lattice"_lattice.html,
+"region"_region.html :ul
+
+Setup atoms:
+
+"atom_modify"_atom_modify.html,
+"atom_style"_atom_style.html,
+"balance"_balance.html,
+"create_atoms"_create_atoms.html,
+"create_bonds"_create_bonds.html,
+"delete_atoms"_delete_atoms.html,
+"delete_bonds"_delete_bonds.html,
+"displace_atoms"_displace_atoms.html,
+"group"_group.html,
+"mass"_mass.html,
+"molecule"_molecule.html,
+"read_data"_read_data.html,
+"read_dump"_read_dump.html,
+"read_restart"_read_restart.html,
+"replicate"_replicate.html,
+"set"_set.html,
+"velocity"_velocity.html :ul
+
+Force fields:
+
+"angle_coeff"_angle_coeff.html,
+"angle_style"_angle_style.html,
+"bond_coeff"_bond_coeff.html,
+"bond_style"_bond_style.html,
+"bond_write"_bond_write.html,
+"dielectric"_dielectric.html,
+"dihedral_coeff"_dihedral_coeff.html,
+"dihedral_style"_dihedral_style.html,
+"improper_coeff"_improper_coeff.html,
+"improper_style"_improper_style.html,
+"kspace_modify"_kspace_modify.html,
+"kspace_style"_kspace_style.html,
+"pair_coeff"_pair_coeff.html,
+"pair_modify"_pair_modify.html,
+"pair_style"_pair_style.html,
+"pair_write"_pair_write.html,
+"special_bonds"_special_bonds.html :ul
+
+Settings:
+
+"comm_modify"_comm_modify.html,
+"comm_style"_comm_style.html,
+"info"_info.html,
+"min_modify"_min_modify.html,
+"min_style"_min_style.html,
+"neigh_modify"_neigh_modify.html,
+"neighbor"_neighbor.html,
+"partition"_partition.html,
+"reset_timestep"_reset_timestep.html,
+"run_style"_run_style.html,
+"timer"_timer.html,
+"timestep"_timestep.html :ul
+
+Operations within timestepping (fixes) and diagnostics (computes):
+
+"compute"_compute.html,
+"compute_modify"_compute_modify.html,
+"fix"_fix.html,
+"fix_modify"_fix_modify.html,
+"uncompute"_uncompute.html,
+"unfix"_unfix.html :ul
+
+Output:
+
+"dump image"_dump_image.html,
+"dump movie"_dump_image.html,
+"dump"_dump.html,
+"dump_modify"_dump_modify.html,
+"restart"_restart.html,
+"thermo"_thermo.html,
+"thermo_modify"_thermo_modify.html,
+"thermo_style"_thermo_style.html,
+"undump"_undump.html,
+"write_coeff"_write_coeff.html,
+"write_data"_write_data.html,
+"write_dump"_write_dump.html,
+"write_restart"_write_restart.html :ul
+
+Actions:
+
+"minimize"_minimize.html,
+"neb"_neb.html,
+"prd"_prd.html,
+"rerun"_rerun.html,
+"run"_run.html,
+"tad"_tad.html,
+"temper"_temper.html :ul
+
+Input script control:
+
+"clear"_clear.html,
+"echo"_echo.html,
+"if"_if.html,
+"include"_include.html,
+"jump"_jump.html,
+"label"_label.html,
+"log"_log.html,
+"next"_next.html,
+"print"_print.html,
+"python"_python.html,
+"quit"_quit.html,
+"shell"_shell.html,
+"variable"_variable.html :ul
+
diff --git a/doc/src/Commands_compute.txt b/doc/src/Commands_compute.txt
new file mode 100644
index 0000000000000000000000000000000000000000..028e274c9be4a80555dfcab5a417d738b763bfda
--- /dev/null
+++ b/doc/src/Commands_compute.txt
@@ -0,0 +1,153 @@
+"Higher level section"_Commands.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
+
+"All commands"_Commands_all.html,
+"Fix styles"_Commands_fix.html,
+"Compute styles"_Commands_compute.html,
+"Pair styles"_Commands_pair.html,
+"Bond styles"_Commands_bond.html,
+"Angle styles"_Commands_bond.html#angle,
+"Dihedral styles"_Commands_bond.html#dihedral,
+"Improper styles"_Commands_bond.html#improper,
+"KSpace styles"_Commands_kspace.html :tb(c=3,ea=c)
+
+Compute commands :h3
+
+An alphabetic list of all LAMMPS "compute"_compute.html commands.
+Some styles have accelerated versions. This is indicated by
+additional letters in parenthesis: g = GPU, i = USER-INTEL, k =
+KOKKOS, o = USER-OMP, t = OPT.
+
+"ackland/atom"_compute_ackland_atom.html,
+"aggregate/atom"_compute_cluster_atom.html,
+"angle"_compute_angle.html,
+"angle/local"_compute_angle_local.html,
+"angmom/chunk"_compute_angmom_chunk.html,
+"basal/atom"_compute_basal_atom.html,
+"body/local"_compute_body_local.html,
+"bond"_compute_bond.html,
+"bond/local"_compute_bond_local.html,
+"centro/atom"_compute_centro_atom.html,
+"chunk/atom"_compute_chunk_atom.html,
+"cluster/atom"_compute_cluster_atom.html,
+"cna/atom"_compute_cna_atom.html,
+"cnp/atom"_compute_cnp_atom.html,
+"com"_compute_com.html,
+"com/chunk"_compute_com_chunk.html,
+"contact/atom"_compute_contact_atom.html,
+"coord/atom"_compute_coord_atom.html,
+"damage/atom"_compute_damage_atom.html,
+"dihedral"_compute_dihedral.html,
+"dihedral/local"_compute_dihedral_local.html,
+"dilatation/atom"_compute_dilatation_atom.html,
+"dipole/chunk"_compute_dipole_chunk.html,
+"displace/atom"_compute_displace_atom.html,
+"dpd"_compute_dpd.html,
+"dpd/atom"_compute_dpd_atom.html,
+"edpd/temp/atom"_compute_edpd_temp_atom.html,
+"entropy/atom"_compute_entropy_atom.html,
+"erotate/asphere"_compute_erotate_asphere.html,
+"erotate/rigid"_compute_erotate_rigid.html,
+"erotate/sphere"_compute_erotate_sphere.html,
+"erotate/sphere/atom"_compute_erotate_sphere_atom.html,
+"event/displace"_compute_event_displace.html,
+"fep"_compute_fep.html,
+"force/tally"_compute_tally.html,
+"fragment/atom"_compute_cluster_atom.html,
+"global/atom"_compute_global_atom.html,
+"group/group"_compute_group_group.html,
+"gyration"_compute_gyration.html,
+"gyration/chunk"_compute_gyration_chunk.html,
+"heat/flux"_compute_heat_flux.html,
+"heat/flux/tally"_compute_tally.html,
+"hexorder/atom"_compute_hexorder_atom.html,
+"improper"_compute_improper.html,
+"improper/local"_compute_improper_local.html,
+"inertia/chunk"_compute_inertia_chunk.html,
+"ke"_compute_ke.html,
+"ke/atom"_compute_ke_atom.html,
+"ke/atom/eff"_compute_ke_atom_eff.html,
+"ke/eff"_compute_ke_eff.html,
+"ke/rigid"_compute_ke_rigid.html,
+"meso/e/atom"_compute_meso_e_atom.html,
+"meso/rho/atom"_compute_meso_rho_atom.html,
+"meso/t/atom"_compute_meso_t_atom.html,
+"msd"_compute_msd.html,
+"msd/chunk"_compute_msd_chunk.html,
+"msd/nongauss"_compute_msd_nongauss.html,
+"omega/chunk"_compute_omega_chunk.html,
+"orientorder/atom"_compute_orientorder_atom.html,
+"pair"_compute_pair.html,
+"pair/local"_compute_pair_local.html,
+"pe"_compute_pe.html,
+"pe/atom"_compute_pe_atom.html,
+"pe/mol/tally"_compute_tally.html,
+"pe/tally"_compute_tally.html,
+"plasticity/atom"_compute_plasticity_atom.html,
+"pressure"_compute_pressure.html,
+"pressure/uef"_compute_pressure_uef.html,
+"property/atom"_compute_property_atom.html,
+"property/chunk"_compute_property_chunk.html,
+"property/local"_compute_property_local.html,
+"rdf"_compute_rdf.html,
+"reduce"_compute_reduce.html,
+"reduce/region"_compute_reduce.html,
+"rigid/local"_compute_rigid_local.html,
+"saed"_compute_saed.html,
+"slice"_compute_slice.html,
+"smd/contact/radius"_compute_smd_contact_radius.html,
+"smd/damage"_compute_smd_damage.html,
+"smd/hourglass/error"_compute_smd_hourglass_error.html,
+"smd/internal/energy"_compute_smd_internal_energy.html,
+"smd/plastic/strain"_compute_smd_plastic_strain.html,
+"smd/plastic/strain/rate"_compute_smd_plastic_strain_rate.html,
+"smd/rho"_compute_smd_rho.html,
+"smd/tlsph/defgrad"_compute_smd_tlsph_defgrad.html,
+"smd/tlsph/dt"_compute_smd_tlsph_dt.html,
+"smd/tlsph/num/neighs"_compute_smd_tlsph_num_neighs.html,
+"smd/tlsph/shape"_compute_smd_tlsph_shape.html,
+"smd/tlsph/strain"_compute_smd_tlsph_strain.html,
+"smd/tlsph/strain/rate"_compute_smd_tlsph_strain_rate.html,
+"smd/tlsph/stress"_compute_smd_tlsph_stress.html,
+"smd/triangle/mesh/vertices"_compute_smd_triangle_mesh_vertices.html,
+"smd/ulsph/num/neighs"_compute_smd_ulsph_num_neighs.html,
+"smd/ulsph/strain"_compute_smd_ulsph_strain.html,
+"smd/ulsph/strain/rate"_compute_smd_ulsph_strain_rate.html,
+"smd/ulsph/stress"_compute_smd_ulsph_stress.html,
+"smd/vol"_compute_smd_vol.html,
+"sna/atom"_compute_sna_atom.html,
+"snad/atom"_compute_sna_atom.html,
+"snav/atom"_compute_sna_atom.html,
+"spin"_compute_spin.html,
+"stress/atom"_compute_stress_atom.html,
+"stress/tally"_compute_tally.html,
+"tdpd/cc/atom"_compute_tdpd_cc_atom.html,
+"temp (k)"_compute_temp.html,
+"temp/asphere"_compute_temp_asphere.html,
+"temp/body"_compute_temp_body.html,
+"temp/chunk"_compute_temp_chunk.html,
+"temp/com"_compute_temp_com.html,
+"temp/deform"_compute_temp_deform.html,
+"temp/deform/eff"_compute_temp_deform_eff.html,
+"temp/drude"_compute_temp_drude.html,
+"temp/eff"_compute_temp_eff.html,
+"temp/partial"_compute_temp_partial.html,
+"temp/profile"_compute_temp_profile.html,
+"temp/ramp"_compute_temp_ramp.html,
+"temp/region"_compute_temp_region.html,
+"temp/region/eff"_compute_temp_region_eff.html,
+"temp/rotate"_compute_temp_rotate.html,
+"temp/sphere"_compute_temp_sphere.html,
+"temp/uef"_compute_temp_uef.html,
+"ti"_compute_ti.html,
+"torque/chunk"_compute_torque_chunk.html,
+"vacf"_compute_vacf.html,
+"vcm/chunk"_compute_vcm_chunk.html,
+"voronoi/atom"_compute_voronoi_atom.html,
+"xrd"_compute_xrd.html :tb(c=6,ea=c)
diff --git a/doc/src/Commands_fix.txt b/doc/src/Commands_fix.txt
new file mode 100644
index 0000000000000000000000000000000000000000..d90e8d64038cc53ebfa48c9376c5241e3d97ddf1
--- /dev/null
+++ b/doc/src/Commands_fix.txt
@@ -0,0 +1,229 @@
+"Higher level section"_Commands.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
+
+"All commands"_Commands_all.html,
+"Fix styles"_Commands_fix.html,
+"Compute styles"_Commands_compute.html,
+"Pair styles"_Commands_pair.html,
+"Bond styles"_Commands_bond.html,
+"Angle styles"_Commands_bond.html#angle,
+"Dihedral styles"_Commands_bond.html#dihedral,
+"Improper styles"_Commands_bond.html#improper,
+"KSpace styles"_Commands_kspace.html :tb(c=3,ea=c)
+
+Fix commands :h3
+
+An alphabetic list of all LAMMPS "fix"_fix.html commands. Some styles
+have accelerated versions. This is indicated by additional letters in
+parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
+OPT.
+
+"adapt"_fix_adapt.html,
+"adapt/fep"_fix_adapt_fep.html,
+"addforce"_fix_addforce.html,
+"addtorque"_fix_addtorque.html,
+"append/atoms"_fix_append_atoms.html,
+"atc"_fix_atc.html,
+"atom/swap"_fix_atom_swap.html,
+"ave/atom"_fix_ave_atom.html,
+"ave/chunk"_fix_ave_chunk.html,
+"ave/correlate"_fix_ave_correlate.html,
+"ave/correlate/long"_fix_ave_correlate_long.html,
+"ave/histo"_fix_ave_histo.html,
+"ave/histo/weight"_fix_ave_histo.html,
+"ave/time"_fix_ave_time.html,
+"aveforce"_fix_aveforce.html,
+"balance"_fix_balance.html,
+"bond/break"_fix_bond_break.html,
+"bond/create"_fix_bond_create.html,
+"bond/react"_fix_bond_react.html,
+"bond/swap"_fix_bond_swap.html,
+"box/relax"_fix_box_relax.html,
+"cmap"_fix_cmap.html,
+"colvars"_fix_colvars.html,
+"controller"_fix_controller.html,
+"deform (k)"_fix_deform.html,
+"deposit"_fix_deposit.html,
+"dpd/energy (k)"_fix_dpd_energy.html,
+"drag"_fix_drag.html,
+"drude"_fix_drude.html,
+"drude/transform/direct"_fix_drude_transform.html,
+"drude/transform/reverse"_fix_drude_transform.html,
+"dt/reset"_fix_dt_reset.html,
+"edpd/source"_fix_dpd_source.html,
+"efield"_fix_efield.html,
+"ehex"_fix_ehex.html,
+"enforce2d (k)"_fix_enforce2d.html,
+"eos/cv"_fix_eos_cv.html,
+"eos/table"_fix_eos_table.html,
+"eos/table/rx (k)"_fix_eos_table_rx.html,
+"evaporate"_fix_evaporate.html,
+"external"_fix_external.html,
+"filter/corotate"_fix_filter_corotate.html,
+"flow/gauss"_fix_flow_gauss.html,
+"freeze (k)"_fix_freeze.html,
+"gcmc"_fix_gcmc.html,
+"gld"_fix_gld.html,
+"gle"_fix_gle.html,
+"gravity (ko)"_fix_gravity.html,
+"grem"_fix_grem.html,
+"halt"_fix_halt.html,
+"heat"_fix_heat.html,
+"imd"_fix_imd.html,
+"indent"_fix_indent.html,
+"ipi"_fix_ipi.html,
+"langevin (k)"_fix_langevin.html,
+"langevin/drude"_fix_langevin_drude.html,
+"langevin/eff"_fix_langevin_eff.html,
+"langevin/spin"_fix_langevin_spin.html,
+"latte"_fix_latte.html,
+"lb/fluid"_fix_lb_fluid.html,
+"lb/momentum"_fix_lb_momentum.html,
+"lb/pc"_fix_lb_pc.html,
+"lb/rigid/pc/sphere"_fix_lb_rigid_pc_sphere.html,
+"lb/viscous"_fix_lb_viscous.html,
+"lineforce"_fix_lineforce.html,
+"manifoldforce"_fix_manifoldforce.html,
+"meso"_fix_meso.html,
+"meso/stationary"_fix_meso_stationary.html,
+"momentum (k)"_fix_momentum.html,
+"move"_fix_move.html,
+"mscg"_fix_mscg.html,
+"msst"_fix_msst.html,
+"mvv/dpd"_fix_mvv_dpd.html,
+"mvv/edpd"_fix_mvv_dpd.html,
+"mvv/tdpd"_fix_mvv_dpd.html,
+"neb"_fix_neb.html,
+"nph (ko)"_fix_nh.html,
+"nph/asphere (o)"_fix_nph_asphere.html,
+"nph/body"_fix_nph_body.html,
+"nph/eff"_fix_nh_eff.html,
+"nph/sphere (ko)"_fix_nph_sphere.html,
+"nphug (o)"_fix_nphug.html,
+"npt (kio)"_fix_nh.html,
+"npt/asphere (o)"_fix_npt_asphere.html,
+"npt/body"_fix_npt_body.html,
+"npt/eff"_fix_nh_eff.html,
+"npt/sphere (o)"_fix_npt_sphere.html,
+"npt/uef"_fix_nh_uef.html,
+"nve (kio)"_fix_nve.html,
+"nve/asphere (i)"_fix_nve_asphere.html,
+"nve/asphere/noforce"_fix_nve_asphere_noforce.html,
+"nve/body"_fix_nve_body.html,
+"nve/dot"_fix_nve_dot.html,
+"nve/dotc/langevin"_fix_nve_dotc_langevin.html,
+"nve/eff"_fix_nve_eff.html,
+"nve/limit"_fix_nve_limit.html,
+"nve/line"_fix_nve_line.html,
+"nve/manifold/rattle"_fix_nve_manifold_rattle.html,
+"nve/noforce"_fix_nve_noforce.html,
+"nve/sphere (o)"_fix_nve_sphere.html,
+"nve/spin"_fix_nve_spin.html,
+"nve/tri"_fix_nve_tri.html,
+"nvk"_fix_nvk.html,
+"nvt (iko)"_fix_nh.html,
+"nvt/asphere (o)"_fix_nvt_asphere.html,
+"nvt/body"_fix_nvt_body.html,
+"nvt/eff"_fix_nh_eff.html,
+"nvt/manifold/rattle"_fix_nvt_manifold_rattle.html,
+"nvt/sllod (io)"_fix_nvt_sllod.html,
+"nvt/sllod/eff"_fix_nvt_sllod_eff.html,
+"nvt/sphere (o)"_fix_nvt_sphere.html,
+"nvt/uef"_fix_nh_uef.html,
+"oneway"_fix_oneway.html,
+"orient/bcc"_fix_orient.html,
+"orient/fcc"_fix_orient.html,
+"phonon"_fix_phonon.html,
+"pimd"_fix_pimd.html,
+"planeforce"_fix_planeforce.html,
+"poems"_fix_poems.html,
+"pour"_fix_pour.html,
+"precession/spin"_fix_precession_spin.html,
+"press/berendsen"_fix_press_berendsen.html,
+"print"_fix_print.html,
+"property/atom (k)"_fix_property_atom.html,
+"python/invoke"_fix_python_invoke.html,
+"python/move"_fix_python_move.html,
+"qbmsst"_fix_qbmsst.html,
+"qeq/comb (o)"_fix_qeq_comb.html,
+"qeq/dynamic"_fix_qeq.html,
+"qeq/fire"_fix_qeq.html,
+"qeq/point"_fix_qeq.html,
+"qeq/reax (ko)"_fix_qeq_reax.html,
+"qeq/shielded"_fix_qeq.html,
+"qeq/slater"_fix_qeq.html,
+"qmmm"_fix_qmmm.html,
+"qtb"_fix_qtb.html,
+"rattle"_fix_shake.html,
+"reax/bonds"_fix_reax_bonds.html,
+"reax/c/bonds (k)"_fix_reax_bonds.html,
+"reax/c/species (k)"_fix_reaxc_species.html,
+"recenter"_fix_recenter.html,
+"restrain"_fix_restrain.html,
+"rhok"_fix_rhok.html,
+"rigid (o)"_fix_rigid.html,
+"rigid/nph (o)"_fix_rigid.html,
+"rigid/npt (o)"_fix_rigid.html,
+"rigid/nve (o)"_fix_rigid.html,
+"rigid/nvt (o)"_fix_rigid.html,
+"rigid/small (o)"_fix_rigid.html,
+"rigid/small/nph"_fix_rigid.html,
+"rigid/small/npt"_fix_rigid.html,
+"rigid/small/nve"_fix_rigid.html,
+"rigid/small/nvt"_fix_rigid.html,
+"rx (k)"_fix_rx.html,
+"saed/vtk"_fix_saed_vtk.html,
+"setforce (k)"_fix_setforce.html,
+"shake"_fix_shake.html,
+"shardlow (k)"_fix_shardlow.html,
+"smd"_fix_smd.html,
+"smd/adjust/dt"_fix_smd_adjust_dt.html,
+"smd/integrate/tlsph"_fix_smd_integrate_tlsph.html,
+"smd/integrate/ulsph"_fix_smd_integrate_ulsph.html,
+"smd/move/triangulated/surface"_fix_smd_move_triangulated_surface.html,
+"smd/setvel"_fix_smd_setvel.html,
+"smd/wall/surface"_fix_smd_wall_surface.html,
+"spring"_fix_spring.html,
+"spring/chunk"_fix_spring_chunk.html,
+"spring/rg"_fix_spring_rg.html,
+"spring/self"_fix_spring_self.html,
+"srd"_fix_srd.html,
+"store/force"_fix_store_force.html,
+"store/state"_fix_store_state.html,
+"tdpd/source"_fix_dpd_source.html,
+"temp/berendsen"_fix_temp_berendsen.html,
+"temp/csld"_fix_temp_csvr.html,
+"temp/csvr"_fix_temp_csvr.html,
+"temp/rescale"_fix_temp_rescale.html,
+"temp/rescale/eff"_fix_temp_rescale_eff.html,
+"tfmc"_fix_tfmc.html,
+"thermal/conductivity"_fix_thermal_conductivity.html,
+"ti/spring"_fix_ti_spring.html,
+"tmd"_fix_tmd.html,
+"ttm"_fix_ttm.html,
+"ttm/mod"_fix_ttm.html,
+"tune/kspace"_fix_tune_kspace.html,
+"vector"_fix_vector.html,
+"viscosity"_fix_viscosity.html,
+"viscous"_fix_viscous.html,
+"wall/body/polygon"_fix_wall_body_polygon.html,
+"wall/body/polyhedron"_fix_wall_body_polyhedron.html,
+"wall/colloid"_fix_wall.html,
+"wall/ees"_fix_wall_ees.html,
+"wall/gran"_fix_wall_gran.html,
+"wall/gran/region"_fix_wall_gran_region.html,
+"wall/harmonic"_fix_wall.html,
+"wall/lj1043"_fix_wall.html,
+"wall/lj126"_fix_wall.html,
+"wall/lj93 (k)"_fix_wall.html,
+"wall/piston"_fix_wall_piston.html,
+"wall/reflect (k)"_fix_wall_reflect.html,
+"wall/region"_fix_wall_region.html,
+"wall/region/ees"_fix_wall_ees.html,
+"wall/srd"_fix_wall_srd.html :tb(c=8,ea=c)
diff --git a/doc/src/Commands_input.txt b/doc/src/Commands_input.txt
new file mode 100644
index 0000000000000000000000000000000000000000..8b3dda741b42dd03bcca359e654ef0ab1ae6a043
--- /dev/null
+++ b/doc/src/Commands_input.txt
@@ -0,0 +1,60 @@
+"Higher level section"_Commands.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
+
+LAMMPS input scripts :h3
+
+LAMMPS executes by reading commands from a input script (text file),
+one line at a time. When the input script ends, LAMMPS exits. Each
+command causes LAMMPS to take some action. It may set an internal
+variable, read in a file, or run a simulation. Most commands have
+default settings, which means you only need to use the command if you
+wish to change the default.
+
+In many cases, the ordering of commands in an input script is not
+important. However the following rules apply:
+
+(1) LAMMPS does not read your entire input script and then perform a
+simulation with all the settings. Rather, the input script is read
+one line at a time and each command takes effect when it is read.
+Thus this sequence of commands:
+
+timestep 0.5
+run 100
+run 100 :pre
+
+does something different than this sequence:
+
+run 100
+timestep 0.5
+run 100 :pre
+
+In the first case, the specified timestep (0.5 fs) is used for two
+simulations of 100 timesteps each. In the 2nd case, the default
+timestep (1.0 fs) is used for the 1st 100 step simulation and a 0.5 fs
+timestep is used for the 2nd one.
+
+(2) Some commands are only valid when they follow other commands. For
+example you cannot set the temperature of a group of atoms until atoms
+have been defined and a group command is used to define which atoms
+belong to the group.
+
+(3) Sometimes command B will use values that can be set by command A.
+This means command A must precede command B in the input script if it
+is to have the desired effect. For example, the
+"read_data"_read_data.html command initializes the system by setting
+up the simulation box and assigning atoms to processors. If default
+values are not desired, the "processors"_processors.html and
+"boundary"_boundary.html commands need to be used before read_data to
+tell LAMMPS how to map processors to the simulation box.
+
+Many input script errors are detected by LAMMPS and an ERROR or
+WARNING message is printed. The "Errors"_Errors.html doc page gives
+more information on what errors mean. The documentation for each
+command lists restrictions on how the command can be used.
+
diff --git a/doc/src/Commands_kspace.txt b/doc/src/Commands_kspace.txt
new file mode 100644
index 0000000000000000000000000000000000000000..a1263445050bda692218aa311831d3565d22155c
--- /dev/null
+++ b/doc/src/Commands_kspace.txt
@@ -0,0 +1,36 @@
+"Higher level section"_Commands.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.html)
+
+:line
+
+"All commands"_Commands_all.html,
+"Fix styles"_Commands_fix.html,
+"Compute styles"_Commands_compute.html,
+"Pair styles"_Commands_pair.html,
+"Bond styles"_Commands_bond.html,
+"Angle styles"_Commands_bond.html#angle,
+"Dihedral styles"_Commands_bond.html#dihedral,
+"Improper styles"_Commands_bond.html#improper,
+"KSpace styles"_Commands_kspace.html :tb(c=3,ea=c)
+
+KSpace solvers :h3
+
+All LAMMPS "kspace_style"_kspace_style.html solvers. Some styles have
+accelerated versions. This is indicated by additional letters in
+parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
+OPT.
+
+"ewald (o)"_kspace_style.html,
+"ewald/disp"_kspace_style.html,
+"msm (o)"_kspace_style.html,
+"msm/cg (o)"_kspace_style.html,
+"pppm (gok)"_kspace_style.html,
+"pppm/cg (o)"_kspace_style.html,
+"pppm/disp (i)"_kspace_style.html,
+"pppm/disp/tip4p"_kspace_style.html,
+"pppm/stagger"_kspace_style.html,
+"pppm/tip4p (o)"_kspace_style.html :tb(c=4,ea=c)
diff --git a/doc/src/Commands_pair.txt b/doc/src/Commands_pair.txt
new file mode 100644
index 0000000000000000000000000000000000000000..1de029150194afcca4272d5173d1bbc457831ec9
--- /dev/null
+++ b/doc/src/Commands_pair.txt
@@ -0,0 +1,231 @@
+"Higher level section"_Commands.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
+
+"All commands"_Commands_all.html,
+"Fix styles"_Commands_fix.html,
+"Compute styles"_Commands_compute.html,
+"Pair styles"_Commands_pair.html,
+"Bond styles"_Commands_bond.html,
+"Angle styles"_Commands_bond.html#angle,
+"Dihedral styles"_Commands_bond.html#dihedral,
+"Improper styles"_Commands_bond.html#improper,
+"KSpace styles"_Commands_kspace.html :tb(c=3,ea=c)
+
+Pair_style potentials :h3
+
+All LAMMPS "pair_style"_pair_style.html commands. Some styles have
+accelerated versions. This is indicated by additional letters in
+parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
+OPT.
+
+"none"_pair_none.html,
+"zero"_pair_zero.html,
+"hybrid"_pair_hybrid.html,
+"hybrid/overlay (k)"_pair_hybrid.html :tb(c=4,ea=c)
+
+"adp (o)"_pair_adp.html,
+"agni (o)"_pair_agni.html,
+"airebo (oi)"_pair_airebo.html,
+"airebo/morse (oi)"_pair_airebo.html,
+"awpmd/cut"_pair_awpmd.html,
+"beck (go)"_pair_beck.html,
+"body/nparticle"_pair_body_nparticle.html,
+"body/rounded/polygon"_pair_body_rounded_polygon.html,
+"body/rounded/polyhedron"_pair_body_rounded_polyhedron.html,
+"bop"_pair_bop.html,
+"born (go)"_pair_born.html,
+"born/coul/dsf"_pair_born.html,
+"born/coul/dsf/cs"_pair_born.html,
+"born/coul/long (go)"_pair_born.html,
+"born/coul/long/cs"_pair_born.html,
+"born/coul/msm (o)"_pair_born.html,
+"born/coul/wolf (go)"_pair_born.html,
+"born/coul/wolf/cs"_pair_born.html,
+"brownian (o)"_pair_brownian.html,
+"brownian/poly (o)"_pair_brownian.html,
+"buck (giko)"_pair_buck.html,
+"buck/coul/cut (giko)"_pair_buck.html,
+"buck/coul/long (giko)"_pair_buck.html,
+"buck/coul/long/cs"_pair_buck.html,
+"buck/coul/msm (o)"_pair_buck.html,
+"buck/long/coul/long (o)"_pair_buck_long.html,
+"buck/mdf"_pair_mdf.html,
+"colloid (go)"_pair_colloid.html,
+"comb (o)"_pair_comb.html,
+"comb3"_pair_comb.html,
+"coul/cut (gko)"_pair_coul.html,
+"coul/cut/soft (o)"_pair_lj_soft.html,
+"coul/debye (gko)"_pair_coul.html,
+"coul/diel (o)"_pair_coul_diel.html,
+"coul/dsf (gko)"_pair_coul.html,
+"coul/long (gko)"_pair_coul.html,
+"coul/long/cs"_pair_coul.html,
+"coul/long/soft (o)"_pair_lj_soft.html,
+"coul/msm"_pair_coul.html,
+"coul/shield"_pair_coul_shield.html,
+"coul/streitz"_pair_coul.html,
+"coul/wolf (ko)"_pair_coul.html,
+"coul/wolf/cs"_pair_coul.html,
+"dpd (gio)"_pair_dpd.html,
+"dpd/fdt"_pair_dpd_fdt.html,
+"dpd/fdt/energy (k)"_pair_dpd_fdt.html,
+"dpd/tstat (go)"_pair_dpd.html,
+"dsmc"_pair_dsmc.html,
+"eam (gikot)"_pair_eam.html,
+"eam/alloy (gikot)"_pair_eam.html,
+"eam/cd (o)"_pair_eam.html,
+"eam/fs (gikot)"_pair_eam.html,
+"edip (o)"_pair_edip.html,
+"edip/multi"_pair_edip.html,
+"edpd"_pair_meso.html,
+"eff/cut"_pair_eff.html,
+"eim (o)"_pair_eim.html,
+"exp6/rx (k)"_pair_exp6_rx.html,
+"extep"_pair_extep.html,
+"gauss (go)"_pair_gauss.html,
+"gauss/cut"_pair_gauss.html,
+"gayberne (gio)"_pair_gayberne.html,
+"gran/hertz/history (o)"_pair_gran.html,
+"gran/hooke (o)"_pair_gran.html,
+"gran/hooke/history (ko)"_pair_gran.html,
+"gw"_pair_gw.html,
+"gw/zbl"_pair_gw.html,
+"hbond/dreiding/lj (o)"_pair_hbond_dreiding.html,
+"hbond/dreiding/morse (o)"_pair_hbond_dreiding.html,
+"ilp/graphene/hbn"_pair_ilp_graphene_hbn.html,
+"kim"_pair_kim.html,
+"kolmogorov/crespi/full"_pair_kolmogorov_crespi_full.html,
+"kolmogorov/crespi/z"_pair_kolmogorov_crespi_z.html,
+"lcbop"_pair_lcbop.html,
+"lennard/mdf"_pair_mdf.html,
+"line/lj"_pair_line_lj.html,
+"list"_pair_list.html,
+"lj/charmm/coul/charmm (iko)"_pair_charmm.html,
+"lj/charmm/coul/charmm/implicit (ko)"_pair_charmm.html,
+"lj/charmm/coul/long (giko)"_pair_charmm.html,
+"lj/charmm/coul/long/soft (o)"_pair_charmm.html,
+"lj/charmm/coul/msm"_pair_charmm.html,
+"lj/charmmfsw/coul/charmmfsh"_pair_charmm.html,
+"lj/charmmfsw/coul/long"_pair_charmm.html,
+"lj/class2 (gko)"_pair_class2.html,
+"lj/class2/coul/cut (ko)"_pair_class2.html,
+"lj/class2/coul/long (gko)"_pair_class2.html,
+"lj/cubic (go)"_pair_lj_cubic.html,
+"lj/cut (gikot)"_pair_lj.html,
+"lj/cut/coul/cut (gko)"_pair_lj.html,
+"lj/cut/coul/cut/soft (o)"_pair_lj_soft.html,
+"lj/cut/coul/debye (gko)"_pair_lj.html,
+"lj/cut/coul/dsf (gko)"_pair_lj.html,
+"lj/cut/coul/long (gikot)"_pair_lj.html,
+"lj/cut/coul/long/cs"_pair_lj.html,
+"lj/cut/coul/long/soft (o)"_pair_lj_soft.html,
+"lj/cut/coul/msm (go)"_pair_lj.html,
+"lj/cut/coul/wolf (o)"_pair_lj.html,
+"lj/cut/dipole/cut (go)"_pair_dipole.html,
+"lj/cut/dipole/long"_pair_dipole.html,
+"lj/cut/dipole/sf (go)"_pair_dipole.html,
+"lj/cut/soft (o)"_pair_lj_soft.html,
+"lj/cut/thole/long (o)"_pair_thole.html,
+"lj/cut/tip4p/cut (o)"_pair_lj.html,
+"lj/cut/tip4p/long (ot)"_pair_lj.html,
+"lj/cut/tip4p/long/soft (o)"_pair_lj_soft.html,
+"lj/expand (gko)"_pair_lj_expand.html,
+"lj/gromacs (gko)"_pair_gromacs.html,
+"lj/gromacs/coul/gromacs (ko)"_pair_gromacs.html,
+"lj/long/coul/long (io)"_pair_lj_long.html,
+"lj/long/dipole/long"_pair_dipole.html,
+"lj/long/tip4p/long"_pair_lj_long.html,
+"lj/mdf"_pair_mdf.html,
+"lj/sdk (gko)"_pair_sdk.html,
+"lj/sdk/coul/long (go)"_pair_sdk.html,
+"lj/sdk/coul/msm (o)"_pair_sdk.html,
+"lj/smooth (o)"_pair_lj_smooth.html,
+"lj/smooth/linear (o)"_pair_lj_smooth_linear.html,
+"lj96/cut (go)"_pair_lj96.html,
+"lubricate (o)"_pair_lubricate.html,
+"lubricate/poly (o)"_pair_lubricate.html,
+"lubricateU"_pair_lubricateU.html,
+"lubricateU/poly"_pair_lubricateU.html,
+"mdpd"_pair_meso.html,
+"mdpd/rhosum"_pair_meso.html,
+"meam"_pair_meam.html,
+"meam/c"_pair_meam.html,
+"meam/spline (o)"_pair_meam_spline.html,
+"meam/sw/spline"_pair_meam_sw_spline.html,
+"mgpt"_pair_mgpt.html,
+"mie/cut (o)"_pair_mie.html,
+"momb"_pair_momb.html,
+"morse (gkot)"_pair_morse.html,
+"morse/smooth/linear"_pair_morse.html,
+"morse/soft"_pair_morse.html,
+"multi/lucy"_pair_multi_lucy.html,
+"multi/lucy/rx (k)"_pair_multi_lucy_rx.html,
+"nb3b/harmonic (o)"_pair_nb3b_harmonic.html,
+"nm/cut (o)"_pair_nm.html,
+"nm/cut/coul/cut (o)"_pair_nm.html,
+"nm/cut/coul/long (o)"_pair_nm.html,
+"oxdna/coaxstk"_pair_oxdna.html,
+"oxdna/excv"_pair_oxdna.html,
+"oxdna/hbond"_pair_oxdna.html,
+"oxdna/stk"_pair_oxdna.html,
+"oxdna/xstk"_pair_oxdna.html,
+"oxdna2/coaxstk"_pair_oxdna2.html,
+"oxdna2/dh"_pair_oxdna2.html,
+"oxdna2/excv"_pair_oxdna2.html,
+"oxdna2/stk"_pair_oxdna2.html,
+"peri/eps"_pair_peri.html,
+"peri/lps (o)"_pair_peri.html,
+"peri/pmb (o)"_pair_peri.html,
+"peri/ves"_pair_peri.html,
+"polymorphic"_pair_polymorphic.html,
+"python"_pair_python.html,
+"quip"_pair_quip.html,
+"reax"_pair_reax.html,
+"reax/c (ko)"_pair_reaxc.html,
+"rebo (oi)"_pair_airebo.html,
+"resquared (go)"_pair_resquared.html,
+"smd/hertz"_pair_smd_hertz.html,
+"smd/tlsph"_pair_smd_tlsph.html,
+"smd/triangulated/surface"_pair_smd_triangulated_surface.html,
+"smd/ulsph"_pair_smd_ulsph.html,
+"smtbq"_pair_smtbq.html,
+"snap (k)"_pair_snap.html,
+"snap (k)"_pair_snap.html,
+"soft (go)"_pair_soft.html,
+"sph/heatconduction"_pair_sph_heatconduction.html,
+"sph/idealgas"_pair_sph_idealgas.html,
+"sph/lj"_pair_sph_lj.html,
+"sph/rhosum"_pair_sph_rhosum.html,
+"sph/taitwater"_pair_sph_taitwater.html,
+"sph/taitwater/morris"_pair_sph_taitwater_morris.html,
+"spin/dmi"_pair_spin_dmi.html,
+"spin/exchange"_pair_spin_exchange.html,
+"spin/magelec"_pair_spin_magelec.html,
+"spin/neel"_pair_spin_neel.html,
+"srp"_pair_srp.html,
+"sw (giko)"_pair_sw.html,
+"table (gko)"_pair_table.html,
+"table/rx (k)"_pair_table_rx.html,
+"tdpd"_pair_meso.html,
+"tersoff (giko)"_pair_tersoff.html,
+"tersoff/mod (gko)"_pair_tersoff_mod.html,
+"tersoff/mod/c (o)"_pair_tersoff_mod.html,
+"tersoff/table (o)"_pair_tersoff.html,
+"tersoff/zbl (gko)"_pair_tersoff_zbl.html,
+"thole"_pair_thole.html,
+"tip4p/cut (o)"_pair_coul.html,
+"tip4p/long (o)"_pair_coul.html,
+"tip4p/long/soft (o)"_pair_lj_soft.html,
+"tri/lj"_pair_tri_lj.html,
+"ufm (got)"_pair_ufm.html,
+"vashishta (ko)"_pair_vashishta.html,
+"vashishta/table (o)"_pair_vashishta.html,
+"yukawa (gok)"_pair_yukawa.html,
+"yukawa/colloid (go)"_pair_yukawa_colloid.html,
+"zbl (gok)"_pair_zbl.html :tb(c=4,ea=c)
diff --git a/doc/src/Commands_parse.txt b/doc/src/Commands_parse.txt
new file mode 100644
index 0000000000000000000000000000000000000000..cbe2261986bb8f8f96089dac3dff3a03dc39dd42
--- /dev/null
+++ b/doc/src/Commands_parse.txt
@@ -0,0 +1,136 @@
+"Higher level section"_Commands.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
+
+Parsing rules for input scripts :h3
+
+Each non-blank line in the input script is treated as a command.
+LAMMPS commands are case sensitive. Command names are lower-case, as
+are specified command arguments. Upper case letters may be used in
+file names or user-chosen ID strings.
+
+Here are 6 rulse for how each line in the input script is parsed by
+LAMMPS:
+
+(1) If the last printable character on the line is a "&" character,
+the command is assumed to continue on the next line. The next line is
+concatenated to the previous line by removing the "&" character and
+line break. This allows long commands to be continued across two or
+more lines. See the discussion of triple quotes in (6) for how to
+continue a command across multiple line without using "&" characters.
+
+(2) All characters from the first "#" character onward are treated as
+comment and discarded. See an exception in (6). Note that a
+comment after a trailing "&" character will prevent the command from
+continuing on the next line. Also note that for multi-line commands a
+single leading "#" will comment out the entire command.
+
+(3) The line is searched repeatedly for $ characters, which indicate
+variables that are replaced with a text string. See an exception in
+(6).
+
+If the $ is followed by curly brackets, then the variable name is the
+text inside the curly brackets. If no curly brackets follow the $,
+then the variable name is the single character immediately following
+the $. Thus $\{myTemp\} and $x refer to variable names "myTemp" and
+"x".
+
+How the variable is converted to a text string depends on what style
+of variable it is; see the "variable"_variable.html doc page for details.
+It can be a variable that stores multiple text strings, and return one
+of them. The returned text string can be multiple "words" (space
+separated) which will then be interpreted as multiple arguments in the
+input command. The variable can also store a numeric formula which
+will be evaluated and its numeric result returned as a string.
+
+As a special case, if the $ is followed by parenthesis, then the text
+inside the parenthesis is treated as an "immediate" variable and
+evaluated as an "equal-style variable"_variable.html. This is a way
+to use numeric formulas in an input script without having to assign
+them to variable names. For example, these 3 input script lines:
+
+variable X equal (xlo+xhi)/2+sqrt(v_area)
+region 1 block $X 2 INF INF EDGE EDGE
+variable X delete :pre
+
+can be replaced by
+
+region 1 block $((xlo+xhi)/2+sqrt(v_area)) 2 INF INF EDGE EDGE :pre
+
+so that you do not have to define (or discard) a temporary variable X.
+
+Additionally, the "immediate" variable expression may be followed by a
+colon, followed by a C-style format string, e.g. ":%f" or ":%.10g".
+The format string must be appropriate for a double-precision
+floating-point value. The format string is used to output the result
+of the variable expression evaluation. If a format string is not
+specified a high-precision "%.20g" is used as the default.
+
+This can be useful for formatting print output to a desired precion:
+
+print "Final energy per atom: $(pe/atoms:%10.3f) eV/atom" :pre
+
+Note that neither the curly-bracket or immediate form of variables can
+contain nested $ characters for other variables to substitute for.
+Thus you cannot do this:
+
+variable a equal 2
+variable b2 equal 4
+print "B2 = $\{b$a\}" :pre
+
+Nor can you specify this $($x-1.0) for an immediate variable, but
+you could use $(v_x-1.0), since the latter is valid syntax for an
+"equal-style variable"_variable.html.
+
+See the "variable"_variable.html command for more details of how
+strings are assigned to variables and evaluated, and how they can be
+used in input script commands.
+
+(4) The line is broken into "words" separated by whitespace (tabs,
+spaces). Note that words can thus contain letters, digits,
+underscores, or punctuation characters.
+
+(5) The first word is the command name. All successive words in the
+line are arguments.
+
+(6) If you want text with spaces to be treated as a single argument,
+it can be enclosed in either single or double or triple quotes. A
+long single argument enclosed in single or double quotes can span
+multiple lines if the "&" character is used, as described above. When
+the lines are concatenated together (and the "&" characters and line
+breaks removed), the text will become a single line. If you want
+multiple lines of an argument to retain their line breaks, the text
+can be enclosed in triple quotes, in which case "&" characters are not
+needed. For example:
+
+print "Volume = $v"
+print 'Volume = $v'
+if "$\{steps\} > 1000" then quit
+variable a string "red green blue &
+ purple orange cyan"
+print """
+System volume = $v
+System temperature = $t
+""" :pre
+
+In each case, the single, double, or triple quotes are removed when
+the single argument they enclose is stored internally.
+
+See the "dump modify format"_dump_modify.html, "print"_print.html,
+"if"_if.html, and "python"_python.html commands for examples.
+
+A "#" or "$" character that is between quotes will not be treated as a
+comment indicator in (2) or substituted for as a variable in (3).
+
+NOTE: If the argument is itself a command that requires a quoted
+argument (e.g. using a "print"_print.html command as part of an
+"if"_if.html or "run every"_run.html command), then single, double, or
+triple quotes can be nested in the usual manner. See the doc pages
+for those commands for examples. Only one of level of nesting is
+allowed, but that should be sufficient for most use cases.
+
diff --git a/doc/src/Commands_structure.txt b/doc/src/Commands_structure.txt
new file mode 100644
index 0000000000000000000000000000000000000000..b5d2c7b07b1f8b4afdb2d255f4953cfbba0e330b
--- /dev/null
+++ b/doc/src/Commands_structure.txt
@@ -0,0 +1,95 @@
+"Higher level section"_Commands.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
+
+Input script structure :h3
+
+This page describes the structure of a typical LAMMPS input script.
+The examples directory in the LAMMPS distribution contains many sample
+input scripts; it is discussed on the "Examples"_Examples.html doc
+page.
+
+A LAMMPS input script typically has 4 parts:
+
+Initialization
+Atom definition
+Settings
+Run a simulation :ol
+
+The last 2 parts can be repeated as many times as desired. I.e. run a
+simulation, change some settings, run some more, etc. Each of the 4
+parts is now described in more detail. Remember that almost all
+commands need only be used if a non-default value is desired.
+
+(1) Initialization
+
+Set parameters that need to be defined before atoms are created or
+read-in from a file.
+
+The relevant commands are "units"_units.html,
+"dimension"_dimension.html, "newton"_newton.html,
+"processors"_processors.html, "boundary"_boundary.html,
+"atom_style"_atom_style.html, "atom_modify"_atom_modify.html.
+
+If force-field parameters appear in the files that will be read, these
+commands tell LAMMPS what kinds of force fields are being used:
+"pair_style"_pair_style.html, "bond_style"_bond_style.html,
+"angle_style"_angle_style.html, "dihedral_style"_dihedral_style.html,
+"improper_style"_improper_style.html.
+
+(2) Atom definition
+
+There are 3 ways to define atoms in LAMMPS. Read them in from a data
+or restart file via the "read_data"_read_data.html or
+"read_restart"_read_restart.html commands. These files can contain
+molecular topology information. Or create atoms on a lattice (with no
+molecular topology), using these commands: "lattice"_lattice.html,
+"region"_region.html, "create_box"_create_box.html,
+"create_atoms"_create_atoms.html. The entire set of atoms can be
+duplicated to make a larger simulation using the
+"replicate"_replicate.html command.
+
+(3) Settings
+
+Once atoms and molecular topology are defined, a variety of settings
+can be specified: force field coefficients, simulation parameters,
+output options, etc.
+
+Force field coefficients are set by these commands (they can also be
+set in the read-in files): "pair_coeff"_pair_coeff.html,
+"bond_coeff"_bond_coeff.html, "angle_coeff"_angle_coeff.html,
+"dihedral_coeff"_dihedral_coeff.html,
+"improper_coeff"_improper_coeff.html,
+"kspace_style"_kspace_style.html, "dielectric"_dielectric.html,
+"special_bonds"_special_bonds.html.
+
+Various simulation parameters are set by these commands:
+"neighbor"_neighbor.html, "neigh_modify"_neigh_modify.html,
+"group"_group.html, "timestep"_timestep.html,
+"reset_timestep"_reset_timestep.html, "run_style"_run_style.html,
+"min_style"_min_style.html, "min_modify"_min_modify.html.
+
+Fixes impose a variety of boundary conditions, time integration, and
+diagnostic options. The "fix"_fix.html command comes in many flavors.
+
+Various computations can be specified for execution during a
+simulation using the "compute"_compute.html,
+"compute_modify"_compute_modify.html, and "variable"_variable.html
+commands.
+
+Output options are set by the "thermo"_thermo.html, "dump"_dump.html,
+and "restart"_restart.html commands.
+
+(4) Run a simulation
+
+A molecular dynamics simulation is run using the "run"_run.html
+command. Energy minimization (molecular statics) is performed using
+the "minimize"_minimize.html command. A parallel tempering
+(replica-exchange) simulation can be run using the
+"temper"_temper.html command.
+
diff --git a/doc/src/Developer/developer.tex b/doc/src/Developer/developer.tex
index 9d9a93a53d7cd83aa6518e6d7fcce6da0c7880f5..8852f441680eb4921a010fe5399f21b865e29585 100644
--- a/doc/src/Developer/developer.tex
+++ b/doc/src/Developer/developer.tex
@@ -476,7 +476,7 @@ is the name of the class. This code allows LAMMPS to find your fix
when it parses input script. In addition, your fix header must be
included in the file "style\_fix.h". In case if you use LAMMPS make,
this file is generated automatically - all files starting with prefix
-fix\_ are included, so call your header the same way. Otherwise, donÕt
+fix\_ are included, so call your header the same way. Otherwise, don't
forget to add your include into "style\_fix.h".
Let's write a simple fix which will print average velocity at the end
diff --git a/doc/src/Eqs/pair_body_rounded.jpg b/doc/src/Eqs/pair_body_rounded.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..e7136ddd20c2acea0e89fa8412497333f15cb541
Binary files /dev/null and b/doc/src/Eqs/pair_body_rounded.jpg differ
diff --git a/doc/src/Eqs/pair_body_rounded.tex b/doc/src/Eqs/pair_body_rounded.tex
new file mode 100644
index 0000000000000000000000000000000000000000..54e095340f1ab3ae13d672d35797a56faeee927a
--- /dev/null
+++ b/doc/src/Eqs/pair_body_rounded.tex
@@ -0,0 +1,13 @@
+\documentstyle[12pt]{article}
+
+\begin{document}
+
+\begin{eqnarray*}
+ F_n &=& k_n \delta_n - c_n v_n, \qquad \delta_n \le 0 \\
+ &=& -k_{na} \delta_n - c_n v_n, \qquad 0 < \delta_n \le r_c \\
+ &=& 0 \qquad \qquad \qquad \qquad \delta_n > r_c \\
+ F_t &=& \mu k_n \delta_n - c_t v_t, \qquad \delta_n \le 0 \\
+ &=& 0 \qquad \qquad \qquad \qquad \delta_n > 0
+\end{eqnarray*}
+
+\end{document}
diff --git a/doc/src/Eqs/pair_spin_dmi_forces.jpg b/doc/src/Eqs/pair_spin_dmi_forces.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..fba6a91cbf6fdb6ee6736073a114d08c907d6d3c
Binary files /dev/null and b/doc/src/Eqs/pair_spin_dmi_forces.jpg differ
diff --git a/doc/src/Eqs/pair_spin_dmi_forces.tex b/doc/src/Eqs/pair_spin_dmi_forces.tex
new file mode 100644
index 0000000000000000000000000000000000000000..1c0c246db4c70852212f86c9a7ab7e6b518c323c
--- /dev/null
+++ b/doc/src/Eqs/pair_spin_dmi_forces.tex
@@ -0,0 +1,14 @@
+\documentclass[preview]{standalone}
+\usepackage{varwidth}
+\usepackage[utf8x]{inputenc}
+\usepackage{amsmath,amssymb,amsthm,bm}
+\begin{document}
+\begin{varwidth}{50in}
+ \begin{equation}
+ \vec{\omega}_i = -\frac{1}{\hbar} \sum_{j}^{Neighb} \vec{s}_{j}\times \left(\vec{e}_{ij}\times \vec{D} \right)
+ ~~{\rm and}~~
+ \vec{F}_i = -\sum_{j}^{Neighb} \frac{1}{r_{ij}} \vec{D} \times \left( \vec{s}_{i}\times \vec{s}_{j} \right)
+ , \nonumber
+ \end{equation}
+\end{varwidth}
+\end{document}
diff --git a/doc/src/Eqs/pair_spin_dmi_interaction.jpg b/doc/src/Eqs/pair_spin_dmi_interaction.jpg
index 1d15b2199add75eefecb424f75ea2dbd363a1afe..3eb24c67e3b26f97c362fd05982ead5fb0f5c150 100644
Binary files a/doc/src/Eqs/pair_spin_dmi_interaction.jpg and b/doc/src/Eqs/pair_spin_dmi_interaction.jpg differ
diff --git a/doc/src/Eqs/pair_spin_dmi_interaction.tex b/doc/src/Eqs/pair_spin_dmi_interaction.tex
index 5a5a776f030088efe17fcbe5e131e4686e8de2a3..79f63a333a6c823258f5d9012fa40561e00fb9cb 100644
--- a/doc/src/Eqs/pair_spin_dmi_interaction.tex
+++ b/doc/src/Eqs/pair_spin_dmi_interaction.tex
@@ -5,7 +5,7 @@
\begin{document}
\begin{varwidth}{50in}
\begin{equation}
- \bm{H}_{dm} = -\sum_{{ i,j}=1,i\neq j}^{N}
+ \bm{H}_{dm} = \sum_{{ i,j}=1,i\neq j}^{N}
\left( \vec{e}_{ij} \times \vec{D} \right)
\cdot\left(\vec{s}_{i}\times \vec{s}_{j}\right),
\nonumber
diff --git a/doc/src/Eqs/pair_spin_exchange_forces.jpg b/doc/src/Eqs/pair_spin_exchange_forces.jpg
index 2b0469bf4db84885fd8b81679cdd9571ba9e3574..b312a9ccdaaf44b7647f2c444c7d79a740cea88c 100644
Binary files a/doc/src/Eqs/pair_spin_exchange_forces.jpg and b/doc/src/Eqs/pair_spin_exchange_forces.jpg differ
diff --git a/doc/src/Eqs/pair_spin_exchange_forces.tex b/doc/src/Eqs/pair_spin_exchange_forces.tex
index 088696d5efbc8f44b7b9c5f87ca8984984927f2f..ac5ef682f3ca9d9532ff6d258cb1012529058636 100644
--- a/doc/src/Eqs/pair_spin_exchange_forces.tex
+++ b/doc/src/Eqs/pair_spin_exchange_forces.tex
@@ -5,10 +5,12 @@
\begin{document}
\begin{varwidth}{50in}
\begin{equation}
- \vec{F}^{i} = \sum_{j}^{Neighbor} \frac{\partial {J} \left(r_{ij} \right)}{
- \partial r_{ij}} \left( \vec{s}_{i}\cdot \vec{s}_{j} \right) \vec{r}_{ij}
- ~~{\rm and}~~ \vec{\omega}^{i} = \frac{1}{\hbar} \sum_{j}^{Neighbor} {J}
- \left(r_{ij} \right)\,\vec{s}_{j} \nonumber
+ \vec{\omega}_{i} = \frac{1}{\hbar} \sum_{j}^{Neighb} {J}
+ \left(r_{ij} \right)\,\vec{s}_{j}
+ ~~{\rm and}~~
+ \vec{F}_{i} = \sum_{j}^{Neighb} \frac{\partial {J} \left(r_{ij} \right)}{
+ \partial r_{ij}} \left( \vec{s}_{i}\cdot \vec{s}_{j} \right) \vec{e}_{ij}
+ \nonumber
\end{equation}
\end{varwidth}
\end{document}
diff --git a/doc/src/Eqs/pair_spin_exchange_interaction.jpg b/doc/src/Eqs/pair_spin_exchange_interaction.jpg
index d51524d27ca413ec4ded189107c2219b061f7d7e..c70d8a6554003e37472d648c1944a13ee9d3f859 100644
Binary files a/doc/src/Eqs/pair_spin_exchange_interaction.jpg and b/doc/src/Eqs/pair_spin_exchange_interaction.jpg differ
diff --git a/doc/src/Eqs/pair_spin_exchange_interaction.tex b/doc/src/Eqs/pair_spin_exchange_interaction.tex
index 6e598f75ac04b4318c8d5679c032a75c5e82aeec..f20b3e5740ce2db9cb86a70910ca2b80f263fe4f 100644
--- a/doc/src/Eqs/pair_spin_exchange_interaction.tex
+++ b/doc/src/Eqs/pair_spin_exchange_interaction.tex
@@ -5,7 +5,7 @@
\begin{document}
\begin{varwidth}{50in}
\begin{equation}
- \bm{H}_{exchange} ~=~ -\sum_{i,j,i\neq j}^{N} {J} \left(r_{ij} \right)\, \vec{s}_{i}\cdot \vec{s}_{j} \nonumber
+ \bm{H}_{ex} ~=~ -\sum_{i,j,i\neq j}^{N} {J} \left(r_{ij} \right)\, \vec{s}_{i}\cdot \vec{s}_{j} \nonumber
\end{equation}
\end{varwidth}
\end{document}
diff --git a/doc/src/Errors.txt b/doc/src/Errors.txt
new file mode 100644
index 0000000000000000000000000000000000000000..10f84874a32a6b187aa11e306f698695f0e607bd
--- /dev/null
+++ b/doc/src/Errors.txt
@@ -0,0 +1,38 @@
+"Previous Section"_Python_head.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
+
+Errors :h2
+
+These doc pages describe the errors you can encounter when using
+LAMMPS. The common problems include conceptual issues. The messages
+and warnings doc pages give complete lists of all the messages the
+code may generate (except those generated by USER packages), with
+additional details for many of them.
+
+<!-- RST
+
+.. toctree::
+ :maxdepth: 1
+
+ Errors_common
+ Errors_bugs
+ Errors_messages
+ Errors_warnings
+
+END_RST -->
+
+<!-- HTML_ONLY -->
+
+"Common problems"_Errors_common.html
+"Reporting bugs"_Errors_bugs.html
+"Error messages"_Errors_messages.html
+"Warning messages"_Errors_warnings.html :all(b)
+
+<!-- END_HTML_ONLY -->
diff --git a/doc/src/Errors_bugs.txt b/doc/src/Errors_bugs.txt
new file mode 100644
index 0000000000000000000000000000000000000000..4a8e62e77546206de35b1132a3484d731db61af3
--- /dev/null
+++ b/doc/src/Errors_bugs.txt
@@ -0,0 +1,35 @@
+"Higher level section"_Errors.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Reporting bugs :h3
+
+If you are confident that you have found a bug in LAMMPS, follow these
+steps.
+
+Check the "New features and bug
+fixes"_http://lammps.sandia.gov/bug.html section of the "LAMMPS WWW
+site"_lws to see if the bug has already been reported or fixed or the
+"Unfixed bug"_http://lammps.sandia.gov/unbug.html to see if a fix is
+pending.
+
+Check the "mailing list"_http://lammps.sandia.gov/mail.html to see if
+it has been discussed before.
+
+If not, send an email to the mailing list describing the problem with
+any ideas you have as to what is causing it or where in the code the
+problem might be. The developers will ask for more info if needed,
+such as an input script or data files.
+
+The most useful thing you can do to help us fix the bug is to isolate
+the problem. Run it on the smallest number of atoms and fewest number
+of processors and with the simplest input script that reproduces the
+bug and try to identify what command or combination of commands is
+causing the problem.
+
+NOTE: this page needs to have GitHub issues info added
diff --git a/doc/src/Errors_common.txt b/doc/src/Errors_common.txt
new file mode 100644
index 0000000000000000000000000000000000000000..651040ebc9e7b2bae23fc4cfc8df0d975295d6aa
--- /dev/null
+++ b/doc/src/Errors_common.txt
@@ -0,0 +1,123 @@
+"Higher level section"_Errors.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Common problems :h3
+
+If two LAMMPS runs do not produce the exact same answer on different
+machines or different numbers of processors, this is typically not a
+bug. In theory you should get identical answers on any number of
+processors and on any machine. In practice, numerical round-off can
+cause slight differences and eventual divergence of molecular dynamics
+phase space trajectories within a few 100s or few 1000s of timesteps.
+However, the statistical properties of the two runs (e.g. average
+energy or temperature) should still be the same.
+
+If the "velocity"_velocity.html command is used to set initial atom
+velocities, a particular atom can be assigned a different velocity
+when the problem is run on a different number of processors or on
+different machines. If this happens, the phase space trajectories of
+the two simulations will rapidly diverge. See the discussion of the
+{loop} option in the "velocity"_velocity.html command for details and
+options that avoid this issue.
+
+Similarly, the "create_atoms"_create_atoms.html command generates a
+lattice of atoms. For the same physical system, the ordering and
+numbering of atoms by atom ID may be different depending on the number
+of processors.
+
+Some commands use random number generators which may be setup to
+produce different random number streams on each processor and hence
+will produce different effects when run on different numbers of
+processors. A commonly-used example is the "fix
+langevin"_fix_langevin.html command for thermostatting.
+
+A LAMMPS simulation typically has two stages, setup and run. Most
+LAMMPS errors are detected at setup time; others like a bond
+stretching too far may not occur until the middle of a run.
+
+LAMMPS tries to flag errors and print informative error messages so
+you can fix the problem. For most errors it will also print the last
+input script command that it was processing. Of course, LAMMPS cannot
+figure out your physics or numerical mistakes, like choosing too big a
+timestep, specifying erroneous force field coefficients, or putting 2
+atoms on top of each other! If you run into errors that LAMMPS
+doesn't catch that you think it should flag, please send an email to
+the "developers"_http://lammps.sandia.gov/authors.html.
+
+If you get an error message about an invalid command in your input
+script, you can determine what command is causing the problem by
+looking in the log.lammps file or using the "echo command"_echo.html
+to see it on the screen. If you get an error like "Invalid ...
+style", with ... being fix, compute, pair, etc, it means that you
+mistyped the style name or that the command is part of an optional
+package which was not compiled into your executable. The list of
+available styles in your executable can be listed by using "the -h
+command-line swith"_Run_options.html. The installation and
+compilation of optional packages is explained on the "Build
+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
+may also simply read a bogus argument and assign a value that is
+valid, but not what you wanted. E.g. trying to read the string "abc"
+as an integer value of 0. Careful reading of the associated doc page
+for the command should allow you to fix these problems. In most cases,
+where LAMMPS expects to read a number, either integer or floating point,
+it performs a stringent test on whether the provided input actually
+is an integer or floating-point number, respectively, and reject the
+input with an error message (for instance, when an integer is required,
+but a floating-point number 1.0 is provided):
+
+ERROR: Expected integer parameter in input script or data file :pre
+
+Some commands allow for using variable references in place of numeric
+constants so that the value can be evaluated and may change over the
+course of a run. This is typically done with the syntax {v_name} for a
+parameter, where name is the name of the variable. On the other hand,
+immediate variable expansion with the syntax ${name} is performed while
+reading the input and before parsing commands,
+
+NOTE: Using a variable reference (i.e. {v_name}) is only allowed if
+the documentation of the corresponding command explicitly says it is.
+
+Generally, LAMMPS will print a message to the screen and logfile and
+exit gracefully when it encounters a fatal error. Sometimes it will
+print a WARNING to the screen and logfile and continue on; you can
+decide if the WARNING is important or not. A WARNING message that is
+generated in the middle of a run is only printed to the screen, not to
+the logfile, to avoid cluttering up thermodynamic output. If LAMMPS
+crashes or hangs without spitting out an error message first then it
+could be a bug (see "this section"_Errors_bugs.html) or one of the following
+cases:
+
+LAMMPS runs in the available memory a processor allows to be
+allocated. Most reasonable MD runs are compute limited, not memory
+limited, so this shouldn't be a bottleneck on most platforms. Almost
+all large memory allocations in the code are done via C-style malloc's
+which will generate an error message if you run out of memory.
+Smaller chunks of memory are allocated via C++ "new" statements. If
+you are unlucky you could run out of memory just when one of these
+small requests is made, in which case the code will crash or hang (in
+parallel), since LAMMPS doesn't trap on those errors.
+
+Illegal arithmetic can cause LAMMPS to run slow or crash. This is
+typically due to invalid physics and numerics that your simulation is
+computing. If you see wild thermodynamic values or NaN values in your
+LAMMPS output, something is wrong with your simulation. If you
+suspect this is happening, it is a good idea to print out
+thermodynamic info frequently (e.g. every timestep) via the
+"thermo"_thermo.html so you can monitor what is happening.
+Visualizing the atom movement is also a good idea to insure your model
+is behaving as you expect.
+
+In parallel, one way LAMMPS can hang is due to how different MPI
+implementations handle buffering of messages. If the code hangs
+without an error message, it may be that you need to specify an MPI
+setting or two (usually via an environment variable) to enable
+buffering or boost the sizes of messages that can be buffered.
diff --git a/doc/src/Section_errors.txt b/doc/src/Errors_messages.txt
similarity index 87%
rename from doc/src/Section_errors.txt
rename to doc/src/Errors_messages.txt
index 95482b06dc5bc1d768a0e4c355d8aad5e5e08821..d279b5e9758c0366169abb962e3d27b9fddaa56e 100644
--- a/doc/src/Section_errors.txt
+++ b/doc/src/Errors_messages.txt
@@ -1,192 +1,33 @@
-"Previous Section"_Section_python.html - "LAMMPS WWW Site"_lws -
-"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
-Section"_Section_history.html :c
+"Higher level section"_Errors.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
-12. Errors :h2
+Error messages :h3
-This section describes the errors you can encounter when using LAMMPS,
-either conceptually, or as printed out by the program.
+This is an alphabetic list of the ERROR messages LAMMPS prints out and
+the reason why. If the explanation here is not sufficient, the
+documentation for the offending command may help. Error messages also
+list the source file and line number where the error was generated.
+For example, a message like this:
-12.1 "Common problems"_#err_1
-12.2 "Reporting bugs"_#err_2
-12.3 "Error & warning messages"_#err_3 :all(b)
-
-:line
-:line
-
-12.1 Common problems :link(err_1),h4
-
-If two LAMMPS runs do not produce the exact same answer on different
-machines or different numbers of processors, this is typically not a
-bug. In theory you should get identical answers on any number of
-processors and on any machine. In practice, numerical round-off can
-cause slight differences and eventual divergence of molecular dynamics
-phase space trajectories within a few 100s or few 1000s of timesteps.
-However, the statistical properties of the two runs (e.g. average
-energy or temperature) should still be the same.
-
-If the "velocity"_velocity.html command is used to set initial atom
-velocities, a particular atom can be assigned a different velocity
-when the problem is run on a different number of processors or on
-different machines. If this happens, the phase space trajectories of
-the two simulations will rapidly diverge. See the discussion of the
-{loop} option in the "velocity"_velocity.html command for details and
-options that avoid this issue.
-
-Similarly, the "create_atoms"_create_atoms.html command generates a
-lattice of atoms. For the same physical system, the ordering and
-numbering of atoms by atom ID may be different depending on the number
-of processors.
-
-Some commands use random number generators which may be setup to
-produce different random number streams on each processor and hence
-will produce different effects when run on different numbers of
-processors. A commonly-used example is the "fix
-langevin"_fix_langevin.html command for thermostatting.
-
-A LAMMPS simulation typically has two stages, setup and run. Most
-LAMMPS errors are detected at setup time; others like a bond
-stretching too far may not occur until the middle of a run.
-
-LAMMPS tries to flag errors and print informative error messages so
-you can fix the problem. For most errors it will also print the last
-input script command that it was processing. Of course, LAMMPS cannot
-figure out your physics or numerical mistakes, like choosing too big a
-timestep, specifying erroneous force field coefficients, or putting 2
-atoms on top of each other! If you run into errors that LAMMPS
-doesn't catch that you think it should flag, please send an email to
-the "developers"_http://lammps.sandia.gov/authors.html.
-
-If you get an error message about an invalid command in your input
-script, you can determine what command is causing the problem by
-looking in the log.lammps file or using the "echo command"_echo.html
-to see it on the screen. If you get an error like "Invalid ...
-style", with ... being fix, compute, pair, etc, it means that you
-mistyped the style name or that the command is part of an optional
-package which was not compiled into your executable. The list of
-available styles in your executable can be listed by using "the -h
-command-line argument"_Section_start.html#start_6. The installation
-and compilation of optional packages is explained in the "installation
-instructions"_Section_start.html#start_3.
-
-For a given command, LAMMPS expects certain arguments in a specified
-order. If you mess this up, LAMMPS will often flag the error, but it
-may also simply read a bogus argument and assign a value that is
-valid, but not what you wanted. E.g. trying to read the string "abc"
-as an integer value of 0. Careful reading of the associated doc page
-for the command should allow you to fix these problems. In most cases,
-where LAMMPS expects to read a number, either integer or floating point,
-it performs a stringent test on whether the provided input actually
-is an integer or floating-point number, respectively, and reject the
-input with an error message (for instance, when an integer is required,
-but a floating-point number 1.0 is provided):
-
-ERROR: Expected integer parameter in input script or data file :pre
-
-Some commands allow for using variable references in place of numeric
-constants so that the value can be evaluated and may change over the
-course of a run. This is typically done with the syntax {v_name} for a
-parameter, where name is the name of the variable. On the other hand,
-immediate variable expansion with the syntax ${name} is performed while
-reading the input and before parsing commands,
-
-NOTE: Using a variable reference (i.e. {v_name}) is only allowed if
-the documentation of the corresponding command explicitly says it is.
-
-Generally, LAMMPS will print a message to the screen and logfile and
-exit gracefully when it encounters a fatal error. Sometimes it will
-print a WARNING to the screen and logfile and continue on; you can
-decide if the WARNING is important or not. A WARNING message that is
-generated in the middle of a run is only printed to the screen, not to
-the logfile, to avoid cluttering up thermodynamic output. If LAMMPS
-crashes or hangs without spitting out an error message first then it
-could be a bug (see "this section"_#err_2) or one of the following
-cases:
-
-LAMMPS runs in the available memory a processor allows to be
-allocated. Most reasonable MD runs are compute limited, not memory
-limited, so this shouldn't be a bottleneck on most platforms. Almost
-all large memory allocations in the code are done via C-style malloc's
-which will generate an error message if you run out of memory.
-Smaller chunks of memory are allocated via C++ "new" statements. If
-you are unlucky you could run out of memory just when one of these
-small requests is made, in which case the code will crash or hang (in
-parallel), since LAMMPS doesn't trap on those errors.
-
-Illegal arithmetic can cause LAMMPS to run slow or crash. This is
-typically due to invalid physics and numerics that your simulation is
-computing. If you see wild thermodynamic values or NaN values in your
-LAMMPS output, something is wrong with your simulation. If you
-suspect this is happening, it is a good idea to print out
-thermodynamic info frequently (e.g. every timestep) via the
-"thermo"_thermo.html so you can monitor what is happening.
-Visualizing the atom movement is also a good idea to insure your model
-is behaving as you expect.
-
-In parallel, one way LAMMPS can hang is due to how different MPI
-implementations handle buffering of messages. If the code hangs
-without an error message, it may be that you need to specify an MPI
-setting or two (usually via an environment variable) to enable
-buffering or boost the sizes of messages that can be buffered.
-
-:line
-
-12.2 Reporting bugs :link(err_2),h4
-
-If you are confident that you have found a bug in LAMMPS, follow these
-steps.
-
-Check the "New features and bug
-fixes"_http://lammps.sandia.gov/bug.html section of the "LAMMPS WWW
-site"_lws to see if the bug has already been reported or fixed or the
-"Unfixed bug"_http://lammps.sandia.gov/unbug.html to see if a fix is
-pending.
-
-Check the "mailing list"_http://lammps.sandia.gov/mail.html
-to see if it has been discussed before.
-
-If not, send an email to the mailing list describing the problem with
-any ideas you have as to what is causing it or where in the code the
-problem might be. The developers will ask for more info if needed,
-such as an input script or data files.
-
-The most useful thing you can do to help us fix the bug is to isolate
-the problem. Run it on the smallest number of atoms and fewest number
-of processors and with the simplest input script that reproduces the
-bug and try to identify what command or combination of commands is
-causing the problem.
-
-As a last resort, you can send an email directly to the
-"developers"_http://lammps.sandia.gov/authors.html.
-
-:line
-
-12.3 Error & warning messages :h3,link(err_3)
-
-These are two alphabetic lists of the "ERROR"_#error and
-"WARNING"_#warn messages LAMMPS prints out and the reason why. If the
-explanation here is not sufficient, the documentation for the
-offending command may help.
-Error and warning messages also list the source file and line number
-where the error was generated. For example, this message
-
-ERROR: Illegal velocity command (velocity.cpp:78)
+ERROR: Illegal velocity command (velocity.cpp:78) :pre
means that line #78 in the file src/velocity.cpp generated the error.
Looking in the source code may help you figure out what went wrong.
Note that error messages from "user-contributed
-packages"_Section_start.html#start_3 are not listed here. If such an
-error occurs and is not self-explanatory, you'll need to look in the
-source code or contact the author of the package.
+packages"_Packages_user.html are not listed here. If such an error
+occurs and is not self-explanatory, you'll need to look in the source
+code or contact the author of the package.
+
+Doc page with "WARNING messages"_Errors_warnings.html
-Errors: :h3,link(error)
+:line
:dlb
@@ -803,13 +644,6 @@ lo value must be less than the hi value for all 3 dimensions. :dd
The box command cannot be used after a read_data, read_restart, or
create_box command. :dd
-{BUG: restartinfo=1 but no restart support in pair style} :dt
-
-The pair style has a bug, where it does not support reading
-and writing information to a restart file, but does not set
-the member variable restartinfo to 0 as required in that case. :dd
-
-
{CPU neighbor lists must be used for ellipsoid/sphere mix.} :dt
When using Gay-Berne or RE-squared pair styles with both ellipsoidal and
@@ -8077,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
-more details. :dd
+setting in your LAMMPS build. See the "Build
+settings"_Build_settings.html doc page for more info. :dd
{One or more atom IDs is zero} :dt
@@ -11003,904 +10837,3 @@ Self-explanatory. :dd
Self-explanatory. :dd
:dle
-
-Warnings: :h3,link(warn)
-
-:dlb
-
-{Adjusting Coulombic cutoff for MSM, new cutoff = %g} :dt
-
-The adjust/cutoff command is turned on and the Coulombic cutoff has been
-adjusted to match the user-specified accuracy. :dd
-
-{Angle atoms missing at step %ld} :dt
-
-One or more of 3 atoms needed to compute a particular angle are
-missing on this processor. Typically this is because the pairwise
-cutoff is set too short or the angle has blown apart and an atom is
-too far away. :dd
-
-{Angle style in data file differs from currently defined angle style} :dt
-
-Self-explanatory. :dd
-
-{Atom style in data file differs from currently defined atom style} :dt
-
-Self-explanatory. :dd
-
-{Bond atom missing in box size check} :dt
-
-The 2nd atoms needed to compute a particular bond is missing on this
-processor. Typically this is because the pairwise cutoff is set too
-short or the bond has blown apart and an atom is too far away. :dd
-
-{Bond atom missing in image check} :dt
-
-The 2nd atom in a particular bond is missing on this processor.
-Typically this is because the pairwise cutoff is set too short or the
-bond has blown apart and an atom is too far away. :dd
-
-{Bond atoms missing at step %ld} :dt
-
-The 2nd atom needed to compute a particular bond is missing on this
-processor. Typically this is because the pairwise cutoff is set too
-short or the bond has blown apart and an atom is too far away. :dd
-
-{Bond style in data file differs from currently defined bond style} :dt
-
-Self-explanatory. :dd
-
-{Bond/angle/dihedral extent > half of periodic box length} :dt
-
-This is a restriction because LAMMPS can be confused about which image
-of an atom in the bonded interaction is the correct one to use.
-"Extent" in this context means the maximum end-to-end length of the
-bond/angle/dihedral. LAMMPS computes this by taking the maximum bond
-length, multiplying by the number of bonds in the interaction (e.g. 3
-for a dihedral) and adding a small amount of stretch. :dd
-
-{Both groups in compute group/group have a net charge; the Kspace boundary correction to energy will be non-zero} :dt
-
-Self-explanatory. :dd
-
-{Calling write_dump before a full system init.} :dt
-
-The write_dump command is used before the system has been fully
-initialized as part of a 'run' or 'minimize' command. Not all dump
-styles and features are fully supported at this point and thus the
-command may fail or produce incomplete or incorrect output. Insert
-a "run 0" command, if a full system init is required. :dd
-
-{Cannot count rigid body degrees-of-freedom before bodies are fully initialized} :dt
-
-This means the temperature associated with the rigid bodies may be
-incorrect on this timestep. :dd
-
-{Cannot count rigid body degrees-of-freedom before bodies are initialized} :dt
-
-This means the temperature associated with the rigid bodies may be
-incorrect on this timestep. :dd
-
-{Cannot include log terms without 1/r terms; setting flagHI to 1} :dt
-
-Self-explanatory. :dd
-
-{Cannot include log terms without 1/r terms; setting flagHI to 1.} :dt
-
-Self-explanatory. :dd
-
-{Charges are set, but coulombic solver is not used} :dt
-
-Self-explanatory. :dd
-
-{Charges did not converge at step %ld: %lg} :dt
-
-Self-explanatory. :dd
-
-{Communication cutoff is too small for SNAP micro load balancing, increased to %lf} :dt
-
-Self-explanatory. :dd
-
-{Compute cna/atom cutoff may be too large to find ghost atom neighbors} :dt
-
-The neighbor cutoff used may not encompass enough ghost atoms
-to perform this operation correctly. :dd
-
-{Computing temperature of portions of rigid bodies} :dt
-
-The group defined by the temperature compute does not encompass all
-the atoms in one or more rigid bodies, so the change in
-degrees-of-freedom for the atoms in those partial rigid bodies will
-not be accounted for. :dd
-
-{Create_bonds max distance > minimum neighbor cutoff} :dt
-
-This means atom pairs for some atom types may not be in the neighbor
-list and thus no bond can be created between them. :dd
-
-{Delete_atoms cutoff > minimum neighbor cutoff} :dt
-
-This means atom pairs for some atom types may not be in the neighbor
-list and thus an atom in that pair cannot be deleted. :dd
-
-{Dihedral atoms missing at step %ld} :dt
-
-One or more of 4 atoms needed to compute a particular dihedral are
-missing on this processor. Typically this is because the pairwise
-cutoff is set too short or the dihedral has blown apart and an atom is
-too far away. :dd
-
-{Dihedral problem} :dt
-
-Conformation of the 4 listed dihedral atoms is extreme; you may want
-to check your simulation geometry. :dd
-
-{Dihedral problem: %d %ld %d %d %d %d} :dt
-
-Conformation of the 4 listed dihedral atoms is extreme; you may want
-to check your simulation geometry. :dd
-
-{Dihedral style in data file differs from currently defined dihedral style} :dt
-
-Self-explanatory. :dd
-
-{Dump dcd/xtc timestamp may be wrong with fix dt/reset} :dt
-
-If the fix changes the timestep, the dump dcd file will not
-reflect the change. :dd
-
-{Energy due to X extra global DOFs will be included in minimizer energies} :dt
-
-When using fixes like box/relax, the potential energy used by the minimizer
-is augmented by an additional energy provided by the fix. Thus the printed
-converged energy may be different from the total potential energy. :dd
-
-{Energy tally does not account for 'zero yes'} :dt
-
-The energy removed by using the 'zero yes' flag is not accounted
-for in the energy tally and thus energy conservation cannot be
-monitored in this case. :dd
-
-{Estimated error in splitting of dispersion coeffs is %g} :dt
-
-Error is greater than 0.0001 percent. :dd
-
-{Ewald/disp Newton solver failed, using old method to estimate g_ewald} :dt
-
-Self-explanatory. Choosing a different cutoff value may help. :dd
-
-{FENE bond too long} :dt
-
-A FENE bond has stretched dangerously far. It's interaction strength
-will be truncated to attempt to prevent the bond from blowing up. :dd
-
-{FENE bond too long: %ld %d %d %g} :dt
-
-A FENE bond has stretched dangerously far. It's interaction strength
-will be truncated to attempt to prevent the bond from blowing up. :dd
-
-{FENE bond too long: %ld %g} :dt
-
-A FENE bond has stretched dangerously far. It's interaction strength
-will be truncated to attempt to prevent the bond from blowing up. :dd
-
-{Fix SRD walls overlap but fix srd overlap not set} :dt
-
-You likely want to set this in your input script. :dd
-
-{Fix bond/swap will ignore defined angles} :dt
-
-See the doc page for fix bond/swap for more info on this
-restriction. :dd
-
-{Fix deposit near setting < possible overlap separation %g} :dt
-
-This test is performed for finite size particles with a diameter, not
-for point particles. The near setting is smaller than the particle
-diameter which can lead to overlaps. :dd
-
-{Fix evaporate may delete atom with non-zero molecule ID} :dt
-
-This is probably an error, since you should not delete only one atom
-of a molecule. :dd
-
-{Fix gcmc using full_energy option} :dt
-
-Fix gcmc has automatically turned on the full_energy option since it
-is required for systems like the one specified by the user. User input
-included one or more of the following: kspace, triclinic, a hybrid
-pair style, an eam pair style, or no "single" function for the pair
-style. :dd
-
-{Fix property/atom mol or charge w/out ghost communication} :dt
-
-A model typically needs these properties defined for ghost atoms. :dd
-
-{Fix qeq CG convergence failed (%g) after %d iterations at %ld step} :dt
-
-Self-explanatory. :dd
-
-{Fix qeq has non-zero lower Taper radius cutoff} :dt
-
-Absolute value must be <= 0.01. :dd
-
-{Fix qeq has very low Taper radius cutoff} :dt
-
-Value should typically be >= 5.0. :dd
-
-{Fix qeq/dynamic tolerance may be too small for damped dynamics} :dt
-
-Self-explanatory. :dd
-
-{Fix qeq/fire tolerance may be too small for damped fires} :dt
-
-Self-explanatory. :dd
-
-{Fix rattle should come after all other integration fixes} :dt
-
-This fix is designed to work after all other integration fixes change
-atom positions. Thus it should be the last integration fix specified.
-If not, it will not satisfy the desired constraints as well as it
-otherwise would. :dd
-
-{Fix recenter should come after all other integration fixes} :dt
-
-Other fixes may change the position of the center-of-mass, so
-fix recenter should come last. :dd
-
-{Fix srd SRD moves may trigger frequent reneighboring} :dt
-
-This is because the SRD particles may move long distances. :dd
-
-{Fix srd grid size > 1/4 of big particle diameter} :dt
-
-This may cause accuracy problems. :dd
-
-{Fix srd particle moved outside valid domain} :dt
-
-This may indicate a problem with your simulation parameters. :dd
-
-{Fix srd particles may move > big particle diameter} :dt
-
-This may cause accuracy problems. :dd
-
-{Fix srd viscosity < 0.0 due to low SRD density} :dt
-
-This may cause accuracy problems. :dd
-
-{Fix thermal/conductivity comes before fix ave/spatial} :dt
-
-The order of these 2 fixes in your input script is such that fix
-thermal/conductivity comes first. If you are using fix ave/spatial to
-measure the temperature profile induced by fix viscosity, then this
-may cause a glitch in the profile since you are averaging immediately
-after swaps have occurred. Flipping the order of the 2 fixes
-typically helps. :dd
-
-{Fix viscosity comes before fix ave/spatial} :dt
-
-The order of these 2 fixes in your input script is such that
-fix viscosity comes first. If you are using fix ave/spatial
-to measure the velocity profile induced by fix viscosity, then
-this may cause a glitch in the profile since you are averaging
-immediately after swaps have occurred. Flipping the order
-of the 2 fixes typically helps. :dd
-
-{Fixes cannot send data in Kokkos communication, switching to classic communication} :dt
-
-This is current restriction with Kokkos. :dd
-
-{For better accuracy use 'pair_modify table 0'} :dt
-
-The user-specified force accuracy cannot be achieved unless the table
-feature is disabled by using 'pair_modify table 0'. :dd
-
-{Geometric mixing assumed for 1/r^6 coefficients} :dt
-
-Self-explanatory. :dd
-
-{Group for fix_modify temp != fix group} :dt
-
-The fix_modify command is specifying a temperature computation that
-computes a temperature on a different group of atoms than the fix
-itself operates on. This is probably not what you want to do. :dd
-
-{H matrix size has been exceeded: m_fill=%d H.m=%d\n} :dt
-
-This is the size of the matrix. :dd
-
-{Ignoring unknown or incorrect info command flag} :dt
-
-Self-explanatory. An unknown argument was given to the info command.
-Compare your input with the documentation. :dd
-
-{Improper atoms missing at step %ld} :dt
-
-One or more of 4 atoms needed to compute a particular improper are
-missing on this processor. Typically this is because the pairwise
-cutoff is set too short or the improper has blown apart and an atom is
-too far away. :dd
-
-{Improper problem: %d %ld %d %d %d %d} :dt
-
-Conformation of the 4 listed improper atoms is extreme; you may want
-to check your simulation geometry. :dd
-
-{Improper style in data file differs from currently defined improper style} :dt
-
-Self-explanatory. :dd
-
-{Inconsistent image flags} :dt
-
-The image flags for a pair on bonded atoms appear to be inconsistent.
-Inconsistent means that when the coordinates of the two atoms are
-unwrapped using the image flags, the two atoms are far apart.
-Specifically they are further apart than half a periodic box length.
-Or they are more than a box length apart in a non-periodic dimension.
-This is usually due to the initial data file not having correct image
-flags for the 2 atoms in a bond that straddles a periodic boundary.
-They should be different by 1 in that case. This is a warning because
-inconsistent image flags will not cause problems for dynamics or most
-LAMMPS simulations. However they can cause problems when such atoms
-are used with the fix rigid or replicate commands. Note that if you
-have an infinite periodic crystal with bonds then it is impossible to
-have fully consistent image flags, since some bonds will cross
-periodic boundaries and connect two atoms with the same image
-flag. :dd
-
-{KIM Model does not provide 'energy'; Potential energy will be zero} :dt
-
-Self-explanatory. :dd
-
-{KIM Model does not provide 'forces'; Forces will be zero} :dt
-
-Self-explanatory. :dd
-
-{KIM Model does not provide 'particleEnergy'; energy per atom will be zero} :dt
-
-Self-explanatory. :dd
-
-{KIM Model does not provide 'particleVirial'; virial per atom will be zero} :dt
-
-Self-explanatory. :dd
-
-{Kspace_modify slab param < 2.0 may cause unphysical behavior} :dt
-
-The kspace_modify slab parameter should be larger to insure periodic
-grids padded with empty space do not overlap. :dd
-
-{Less insertions than requested} :dt
-
-The fix pour command was unsuccessful at finding open space
-for as many particles as it tried to insert. :dd
-
-{Library error in lammps_gather_atoms} :dt
-
-This library function cannot be used if atom IDs are not defined
-or are not consecutively numbered. :dd
-
-{Library error in lammps_scatter_atoms} :dt
-
-This library function cannot be used if atom IDs are not defined or
-are not consecutively numbered, or if no atom map is defined. See the
-atom_modify command for details about atom maps. :dd
-
-{Lost atoms via change_box: original %ld current %ld} :dt
-
-The command options you have used caused atoms to be lost. :dd
-
-{Lost atoms via displace_atoms: original %ld current %ld} :dt
-
-The command options you have used caused atoms to be lost. :dd
-
-{Lost atoms: original %ld current %ld} :dt
-
-Lost atoms are checked for each time thermo output is done. See the
-thermo_modify lost command for options. Lost atoms usually indicate
-bad dynamics, e.g. atoms have been blown far out of the simulation
-box, or moved further than one processor's sub-domain away before
-reneighboring. :dd
-
-{MSM mesh too small, increasing to 2 points in each direction} :dt
-
-Self-explanatory. :dd
-
-{Mismatch between velocity and compute groups} :dt
-
-The temperature computation used by the velocity command will not be
-on the same group of atoms that velocities are being set for. :dd
-
-{Mixing forced for lj coefficients} :dt
-
-Self-explanatory. :dd
-
-{Molecule attributes do not match system attributes} :dt
-
-An attribute is specified (e.g. diameter, charge) that is
-not defined for the specified atom style. :dd
-
-{Molecule has bond topology but no special bond settings} :dt
-
-This means the bonded atoms will not be excluded in pair-wise
-interactions. :dd
-
-{Molecule template for create_atoms has multiple molecules} :dt
-
-The create_atoms command will only create molecules of a single type,
-i.e. the first molecule in the template. :dd
-
-{Molecule template for fix gcmc has multiple molecules} :dt
-
-The fix gcmc command will only create molecules of a single type,
-i.e. the first molecule in the template. :dd
-
-{Molecule template for fix shake has multiple molecules} :dt
-
-The fix shake command will only recognize molecules of a single
-type, i.e. the first molecule in the template. :dd
-
-{More than one compute centro/atom} :dt
-
-It is not efficient to use compute centro/atom more than once. :dd
-
-{More than one compute cluster/atom} :dt
-
-It is not efficient to use compute cluster/atom more than once. :dd
-
-{More than one compute cna/atom defined} :dt
-
-It is not efficient to use compute cna/atom more than once. :dd
-
-{More than one compute contact/atom} :dt
-
-It is not efficient to use compute contact/atom more than once. :dd
-
-{More than one compute coord/atom} :dt
-
-It is not efficient to use compute coord/atom more than once. :dd
-
-{More than one compute damage/atom} :dt
-
-It is not efficient to use compute ke/atom more than once. :dd
-
-{More than one compute dilatation/atom} :dt
-
-Self-explanatory. :dd
-
-{More than one compute erotate/sphere/atom} :dt
-
-It is not efficient to use compute erorate/sphere/atom more than once. :dd
-
-{More than one compute hexorder/atom} :dt
-
-It is not efficient to use compute hexorder/atom more than once. :dd
-
-{More than one compute ke/atom} :dt
-
-It is not efficient to use compute ke/atom more than once. :dd
-
-{More than one compute orientorder/atom} :dt
-
-It is not efficient to use compute orientorder/atom more than once. :dd
-
-{More than one compute plasticity/atom} :dt
-
-Self-explanatory. :dd
-
-{More than one compute sna/atom} :dt
-
-Self-explanatory. :dd
-
-{More than one compute snad/atom} :dt
-
-Self-explanatory. :dd
-
-{More than one compute snav/atom} :dt
-
-Self-explanatory. :dd
-
-{More than one fix poems} :dt
-
-It is not efficient to use fix poems more than once. :dd
-
-{More than one fix rigid} :dt
-
-It is not efficient to use fix rigid more than once. :dd
-
-{Neighbor exclusions used with KSpace solver may give inconsistent Coulombic energies} :dt
-
-This is because excluding specific pair interactions also excludes
-them from long-range interactions which may not be the desired effect.
-The special_bonds command handles this consistently by insuring
-excluded (or weighted) 1-2, 1-3, 1-4 interactions are treated
-consistently by both the short-range pair style and the long-range
-solver. This is not done for exclusions of charged atom pairs via the
-neigh_modify exclude command. :dd
-
-{New thermo_style command, previous thermo_modify settings will be lost} :dt
-
-If a thermo_style command is used after a thermo_modify command, the
-settings changed by the thermo_modify command will be reset to their
-default values. This is because the thermo_modify command acts on
-the currently defined thermo style, and a thermo_style command creates
-a new style. :dd
-
-{No Kspace calculation with verlet/split} :dt
-
-The 2nd partition performs a kspace calculation so the kspace_style
-command must be used. :dd
-
-{No automatic unit conversion to XTC file format conventions possible for units lj} :dt
-
-This means no scaling will be performed. :dd
-
-{No fixes defined, atoms won't move} :dt
-
-If you are not using a fix like nve, nvt, npt then atom velocities and
-coordinates will not be updated during timestepping. :dd
-
-{No joints between rigid bodies, use fix rigid instead} :dt
-
-The bodies defined by fix poems are not connected by joints. POEMS
-will integrate the body motion, but it would be more efficient to use
-fix rigid. :dd
-
-{Not using real units with pair reax} :dt
-
-This is most likely an error, unless you have created your own ReaxFF
-parameter file in a different set of units. :dd
-
-{Number of MSM mesh points changed to be a multiple of 2} :dt
-
-MSM requires that the number of grid points in each direction be a multiple
-of two and the number of grid points in one or more directions have been
-adjusted to meet this requirement. :dd
-
-{OMP_NUM_THREADS environment is not set.} :dt
-
-This environment variable must be set appropriately to use the
-USER-OMP package. :dd
-
-{One or more atoms are time integrated more than once} :dt
-
-This is probably an error since you typically do not want to
-advance the positions or velocities of an atom more than once
-per timestep. :dd
-
-{One or more chunks do not contain all atoms in molecule} :dt
-
-This may not be what you intended. :dd
-
-{One or more dynamic groups may not be updated at correct point in timestep} :dt
-
-If there are other fixes that act immediately after the initial stage
-of time integration within a timestep (i.e. after atoms move), then
-the command that sets up the dynamic group should appear after those
-fixes. This will insure that dynamic group assignments are made
-after all atoms have moved. :dd
-
-{One or more respa levels compute no forces} :dt
-
-This is computationally inefficient. :dd
-
-{Pair COMB charge %.10f with force %.10f hit max barrier} :dt
-
-Something is possibly wrong with your model. :dd
-
-{Pair COMB charge %.10f with force %.10f hit min barrier} :dt
-
-Something is possibly wrong with your model. :dd
-
-{Pair brownian needs newton pair on for momentum conservation} :dt
-
-Self-explanatory. :dd
-
-{Pair dpd needs newton pair on for momentum conservation} :dt
-
-Self-explanatory. :dd
-
-{Pair dsmc: num_of_collisions > number_of_A} :dt
-
-Collision model in DSMC is breaking down. :dd
-
-{Pair dsmc: num_of_collisions > number_of_B} :dt
-
-Collision model in DSMC is breaking down. :dd
-
-{Pair style in data file differs from currently defined pair style} :dt
-
-Self-explanatory. :dd
-
-{Particle deposition was unsuccessful} :dt
-
-The fix deposit command was not able to insert as many atoms as
-needed. The requested volume fraction may be too high, or other atoms
-may be in the insertion region. :dd
-
-{Proc sub-domain size < neighbor skin, could lead to lost atoms} :dt
-
-The decomposition of the physical domain (likely due to load
-balancing) has led to a processor's sub-domain being smaller than the
-neighbor skin in one or more dimensions. Since reneighboring is
-triggered by atoms moving the skin distance, this may lead to lost
-atoms, if an atom moves all the way across a neighboring processor's
-sub-domain before reneighboring is triggered. :dd
-
-{Reducing PPPM order b/c stencil extends beyond nearest neighbor processor} :dt
-
-This may lead to a larger grid than desired. See the kspace_modify overlap
-command to prevent changing of the PPPM order. :dd
-
-{Reducing PPPMDisp Coulomb order b/c stencil extends beyond neighbor processor} :dt
-
-This may lead to a larger grid than desired. See the kspace_modify overlap
-command to prevent changing of the PPPM order. :dd
-
-{Reducing PPPMDisp dispersion order b/c stencil extends beyond neighbor processor} :dt
-
-This may lead to a larger grid than desired. See the kspace_modify overlap
-command to prevent changing of the PPPM order. :dd
-
-{Replacing a fix, but new group != old group} :dt
-
-The ID and style of a fix match for a fix you are changing with a fix
-command, but the new group you are specifying does not match the old
-group. :dd
-
-{Replicating in a non-periodic dimension} :dt
-
-The parameters for a replicate command will cause a non-periodic
-dimension to be replicated; this may cause unwanted behavior. :dd
-
-{Resetting reneighboring criteria during PRD} :dt
-
-A PRD simulation requires that neigh_modify settings be delay = 0,
-every = 1, check = yes. Since these settings were not in place,
-LAMMPS changed them and will restore them to their original values
-after the PRD simulation. :dd
-
-{Resetting reneighboring criteria during TAD} :dt
-
-A TAD simulation requires that neigh_modify settings be delay = 0,
-every = 1, check = yes. Since these settings were not in place,
-LAMMPS changed them and will restore them to their original values
-after the PRD simulation. :dd
-
-{Resetting reneighboring criteria during minimization} :dt
-
-Minimization requires that neigh_modify settings be delay = 0, every =
-1, check = yes. Since these settings were not in place, LAMMPS
-changed them and will restore them to their original values after the
-minimization. :dd
-
-{Restart file used different # of processors} :dt
-
-The restart file was written out by a LAMMPS simulation running on a
-different number of processors. Due to round-off, the trajectories of
-your restarted simulation may diverge a little more quickly than if
-you ran on the same # of processors. :dd
-
-{Restart file used different 3d processor grid} :dt
-
-The restart file was written out by a LAMMPS simulation running on a
-different 3d grid of processors. Due to round-off, the trajectories
-of your restarted simulation may diverge a little more quickly than if
-you ran on the same # of processors. :dd
-
-{Restart file used different boundary settings, using restart file values} :dt
-
-Your input script cannot change these restart file settings. :dd
-
-{Restart file used different newton bond setting, using restart file value} :dt
-
-The restart file value will override the setting in the input script. :dd
-
-{Restart file used different newton pair setting, using input script value} :dt
-
-The input script value will override the setting in the restart file. :dd
-
-{Restrain problem: %d %ld %d %d %d %d} :dt
-
-Conformation of the 4 listed dihedral atoms is extreme; you may want
-to check your simulation geometry. :dd
-
-{Running PRD with only one replica} :dt
-
-This is allowed, but you will get no parallel speed-up. :dd
-
-{SRD bin shifting turned on due to small lamda} :dt
-
-This is done to try to preserve accuracy. :dd
-
-{SRD bin size for fix srd differs from user request} :dt
-
-Fix SRD had to adjust the bin size to fit the simulation box. See the
-cubic keyword if you want this message to be an error vs warning. :dd
-
-{SRD bins for fix srd are not cubic enough} :dt
-
-The bin shape is not within tolerance of cubic. See the cubic
-keyword if you want this message to be an error vs warning. :dd
-
-{SRD particle %d started inside big particle %d on step %ld bounce %d} :dt
-
-See the inside keyword if you want this message to be an error vs
-warning. :dd
-
-{SRD particle %d started inside wall %d on step %ld bounce %d} :dt
-
-See the inside keyword if you want this message to be an error vs
-warning. :dd
-
-{Shake determinant < 0.0} :dt
-
-The determinant of the quadratic equation being solved for a single
-cluster specified by the fix shake command is numerically suspect. LAMMPS
-will set it to 0.0 and continue. :dd
-
-{Shell command '%s' failed with error '%s'} :dt
-
-Self-explanatory. :dd
-
-{Shell command returned with non-zero status} :dt
-
-This may indicate the shell command did not operate as expected. :dd
-
-{Should not allow rigid bodies to bounce off relecting walls} :dt
-
-LAMMPS allows this, but their dynamics are not computed correctly. :dd
-
-{Should not use fix nve/limit with fix shake or fix rattle} :dt
-
-This will lead to invalid constraint forces in the SHAKE/RATTLE
-computation. :dd
-
-{Simulations might be very slow because of large number of structure factors} :dt
-
-Self-explanatory. :dd
-
-{Slab correction not needed for MSM} :dt
-
-Slab correction is intended to be used with Ewald or PPPM and is not needed by MSM. :dd
-
-{System is not charge neutral, net charge = %g} :dt
-
-The total charge on all atoms on the system is not 0.0.
-For some KSpace solvers this is only a warning. :dd
-
-{Table inner cutoff >= outer cutoff} :dt
-
-You specified an inner cutoff for a Coulombic table that is longer
-than the global cutoff. Probably not what you wanted. :dd
-
-{Temperature for MSST is not for group all} :dt
-
-User-assigned temperature to MSST fix does not compute temperature for
-all atoms. Since MSST computes a global pressure, the kinetic energy
-contribution from the temperature is assumed to also be for all atoms.
-Thus the pressure used by MSST could be inaccurate. :dd
-
-{Temperature for NPT is not for group all} :dt
-
-User-assigned temperature to NPT fix does not compute temperature for
-all atoms. Since NPT computes a global pressure, the kinetic energy
-contribution from the temperature is assumed to also be for all atoms.
-Thus the pressure used by NPT could be inaccurate. :dd
-
-{Temperature for fix modify is not for group all} :dt
-
-The temperature compute is being used with a pressure calculation
-which does operate on group all, so this may be inconsistent. :dd
-
-{Temperature for thermo pressure is not for group all} :dt
-
-User-assigned temperature to thermo via the thermo_modify command does
-not compute temperature for all atoms. Since thermo computes a global
-pressure, the kinetic energy contribution from the temperature is
-assumed to also be for all atoms. Thus the pressure printed by thermo
-could be inaccurate. :dd
-
-{The fix ave/spatial command has been replaced by the more flexible fix ave/chunk and compute chunk/atom commands -- fix ave/spatial will be removed in the summer of 2015} :dt
-
-Self-explanatory. :dd
-
-{The minimizer does not re-orient dipoles when using fix efield} :dt
-
-This means that only the atom coordinates will be minimized,
-not the orientation of the dipoles. :dd
-
-{Too many common neighbors in CNA %d times} :dt
-
-More than the maximum # of neighbors was found multiple times. This
-was unexpected. :dd
-
-{Too many inner timesteps in fix ttm} :dt
-
-Self-explanatory. :dd
-
-{Too many neighbors in CNA for %d atoms} :dt
-
-More than the maximum # of neighbors was found multiple times. This
-was unexpected. :dd
-
-{Triclinic box skew is large} :dt
-
-The displacement in a skewed direction is normally required to be less
-than half the box length in that dimension. E.g. the xy tilt must be
-between -half and +half of the x box length. You have relaxed the
-constraint using the box tilt command, but the warning means that a
-LAMMPS simulation may be inefficient as a result. :dd
-
-{Use special bonds = 0,1,1 with bond style fene} :dt
-
-Most FENE models need this setting for the special_bonds command. :dd
-
-{Use special bonds = 0,1,1 with bond style fene/expand} :dt
-
-Most FENE models need this setting for the special_bonds command. :dd
-
-{Using a manybody potential with bonds/angles/dihedrals and special_bond exclusions} :dt
-
-This is likely not what you want to do. The exclusion settings will
-eliminate neighbors in the neighbor list, which the manybody potential
-needs to calculated its terms correctly. :dd
-
-{Using compute temp/deform with inconsistent fix deform remap option} :dt
-
-Fix nvt/sllod assumes deforming atoms have a velocity profile provided
-by "remap v" or "remap none" as a fix deform option. :dd
-
-{Using compute temp/deform with no fix deform defined} :dt
-
-This is probably an error, since it makes little sense to use
-compute temp/deform in this case. :dd
-
-{Using fix srd with box deformation but no SRD thermostat} :dt
-
-The deformation will heat the SRD particles so this can
-be dangerous. :dd
-
-{Using kspace solver on system with no charge} :dt
-
-Self-explanatory. :dd
-
-{Using largest cut-off for lj/long/dipole/long long long} :dt
-
-Self-explanatory. :dd
-
-{Using largest cutoff for buck/long/coul/long} :dt
-
-Self-explanatory. :dd
-
-{Using largest cutoff for lj/long/coul/long} :dt
-
-Self-explanatory. :dd
-
-{Using largest cutoff for pair_style lj/long/tip4p/long} :dt
-
-Self-explanatory. :dd
-
-{Using package gpu without any pair style defined} :dt
-
-Self-explanatory. :dd
-
-{Using pair potential shift with pair_modify compute no} :dt
-
-The shift effects will thus not be computed. :dd
-
-{Using pair tail corrections with nonperiodic system} :dt
-
-This is probably a bogus thing to do, since tail corrections are
-computed by integrating the density of a periodic system out to
-infinity. :dd
-
-{Using pair tail corrections with pair_modify compute no} :dt
-
-The tail corrections will thus not be computed. :dd
-
-{pair style reax is now deprecated and will soon be retired. Users should switch to pair_style reax/c} :dt
-
-Self-explanatory. :dd
-
-:dle
-
diff --git a/doc/src/Errors_warnings.txt b/doc/src/Errors_warnings.txt
new file mode 100644
index 0000000000000000000000000000000000000000..dd3402ba8641c487f1a6a4210fa27f1b6ae062ff
--- /dev/null
+++ b/doc/src/Errors_warnings.txt
@@ -0,0 +1,934 @@
+"Higher level section"_Errors.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Warning messages :h3
+
+This is an alphabetic list of the WARNING messages LAMMPS prints out
+and the reason why. If the explanation here is not sufficient, the
+documentation for the offending command may help. Warning messages
+also list the source file and line number where the warning was
+generated. For example, a message lile this:
+
+WARNING: Bond atom missing in box size check (domain.cpp:187) :pre
+
+means that line #187 in the file src/domain.cpp generated the error.
+Looking in the source code may help you figure out what went wrong.
+
+Note that warning messages from "user-contributed
+packages"_Packages_user.html are not listed here. If such a warning
+occurs and is not self-explanatory, you'll need to look in the source
+code or contact the author of the package.
+
+Doc page with "ERROR messages"_Errors_messages.html
+
+:line
+
+:dlb
+
+{Adjusting Coulombic cutoff for MSM, new cutoff = %g} :dt
+
+The adjust/cutoff command is turned on and the Coulombic cutoff has been
+adjusted to match the user-specified accuracy. :dd
+
+{Angle atoms missing at step %ld} :dt
+
+One or more of 3 atoms needed to compute a particular angle are
+missing on this processor. Typically this is because the pairwise
+cutoff is set too short or the angle has blown apart and an atom is
+too far away. :dd
+
+{Angle style in data file differs from currently defined angle style} :dt
+
+Self-explanatory. :dd
+
+{Atom style in data file differs from currently defined atom style} :dt
+
+Self-explanatory. :dd
+
+{Bond atom missing in box size check} :dt
+
+The 2nd atoms needed to compute a particular bond is missing on this
+processor. Typically this is because the pairwise cutoff is set too
+short or the bond has blown apart and an atom is too far away. :dd
+
+{Bond atom missing in image check} :dt
+
+The 2nd atom in a particular bond is missing on this processor.
+Typically this is because the pairwise cutoff is set too short or the
+bond has blown apart and an atom is too far away. :dd
+
+{Bond atoms missing at step %ld} :dt
+
+The 2nd atom needed to compute a particular bond is missing on this
+processor. Typically this is because the pairwise cutoff is set too
+short or the bond has blown apart and an atom is too far away. :dd
+
+{Bond style in data file differs from currently defined bond style} :dt
+
+Self-explanatory. :dd
+
+{Bond/angle/dihedral extent > half of periodic box length} :dt
+
+This is a restriction because LAMMPS can be confused about which image
+of an atom in the bonded interaction is the correct one to use.
+"Extent" in this context means the maximum end-to-end length of the
+bond/angle/dihedral. LAMMPS computes this by taking the maximum bond
+length, multiplying by the number of bonds in the interaction (e.g. 3
+for a dihedral) and adding a small amount of stretch. :dd
+
+{Both groups in compute group/group have a net charge; the Kspace boundary correction to energy will be non-zero} :dt
+
+Self-explanatory. :dd
+
+{Calling write_dump before a full system init.} :dt
+
+The write_dump command is used before the system has been fully
+initialized as part of a 'run' or 'minimize' command. Not all dump
+styles and features are fully supported at this point and thus the
+command may fail or produce incomplete or incorrect output. Insert
+a "run 0" command, if a full system init is required. :dd
+
+{Cannot count rigid body degrees-of-freedom before bodies are fully initialized} :dt
+
+This means the temperature associated with the rigid bodies may be
+incorrect on this timestep. :dd
+
+{Cannot count rigid body degrees-of-freedom before bodies are initialized} :dt
+
+This means the temperature associated with the rigid bodies may be
+incorrect on this timestep. :dd
+
+{Cannot include log terms without 1/r terms; setting flagHI to 1} :dt
+
+Self-explanatory. :dd
+
+{Cannot include log terms without 1/r terms; setting flagHI to 1.} :dt
+
+Self-explanatory. :dd
+
+{Charges are set, but coulombic solver is not used} :dt
+
+Self-explanatory. :dd
+
+{Charges did not converge at step %ld: %lg} :dt
+
+Self-explanatory. :dd
+
+{Communication cutoff is too small for SNAP micro load balancing, increased to %lf} :dt
+
+Self-explanatory. :dd
+
+{Compute cna/atom cutoff may be too large to find ghost atom neighbors} :dt
+
+The neighbor cutoff used may not encompass enough ghost atoms
+to perform this operation correctly. :dd
+
+{Computing temperature of portions of rigid bodies} :dt
+
+The group defined by the temperature compute does not encompass all
+the atoms in one or more rigid bodies, so the change in
+degrees-of-freedom for the atoms in those partial rigid bodies will
+not be accounted for. :dd
+
+{Create_bonds max distance > minimum neighbor cutoff} :dt
+
+This means atom pairs for some atom types may not be in the neighbor
+list and thus no bond can be created between them. :dd
+
+{Delete_atoms cutoff > minimum neighbor cutoff} :dt
+
+This means atom pairs for some atom types may not be in the neighbor
+list and thus an atom in that pair cannot be deleted. :dd
+
+{Dihedral atoms missing at step %ld} :dt
+
+One or more of 4 atoms needed to compute a particular dihedral are
+missing on this processor. Typically this is because the pairwise
+cutoff is set too short or the dihedral has blown apart and an atom is
+too far away. :dd
+
+{Dihedral problem} :dt
+
+Conformation of the 4 listed dihedral atoms is extreme; you may want
+to check your simulation geometry. :dd
+
+{Dihedral problem: %d %ld %d %d %d %d} :dt
+
+Conformation of the 4 listed dihedral atoms is extreme; you may want
+to check your simulation geometry. :dd
+
+{Dihedral style in data file differs from currently defined dihedral style} :dt
+
+Self-explanatory. :dd
+
+{Dump dcd/xtc timestamp may be wrong with fix dt/reset} :dt
+
+If the fix changes the timestep, the dump dcd file will not
+reflect the change. :dd
+
+{Energy due to X extra global DOFs will be included in minimizer energies} :dt
+
+When using fixes like box/relax, the potential energy used by the minimizer
+is augmented by an additional energy provided by the fix. Thus the printed
+converged energy may be different from the total potential energy. :dd
+
+{Energy tally does not account for 'zero yes'} :dt
+
+The energy removed by using the 'zero yes' flag is not accounted
+for in the energy tally and thus energy conservation cannot be
+monitored in this case. :dd
+
+{Estimated error in splitting of dispersion coeffs is %g} :dt
+
+Error is greater than 0.0001 percent. :dd
+
+{Ewald/disp Newton solver failed, using old method to estimate g_ewald} :dt
+
+Self-explanatory. Choosing a different cutoff value may help. :dd
+
+{FENE bond too long} :dt
+
+A FENE bond has stretched dangerously far. It's interaction strength
+will be truncated to attempt to prevent the bond from blowing up. :dd
+
+{FENE bond too long: %ld %d %d %g} :dt
+
+A FENE bond has stretched dangerously far. It's interaction strength
+will be truncated to attempt to prevent the bond from blowing up. :dd
+
+{FENE bond too long: %ld %g} :dt
+
+A FENE bond has stretched dangerously far. It's interaction strength
+will be truncated to attempt to prevent the bond from blowing up. :dd
+
+{Fix SRD walls overlap but fix srd overlap not set} :dt
+
+You likely want to set this in your input script. :dd
+
+{Fix bond/swap will ignore defined angles} :dt
+
+See the doc page for fix bond/swap for more info on this
+restriction. :dd
+
+{Fix deposit near setting < possible overlap separation %g} :dt
+
+This test is performed for finite size particles with a diameter, not
+for point particles. The near setting is smaller than the particle
+diameter which can lead to overlaps. :dd
+
+{Fix evaporate may delete atom with non-zero molecule ID} :dt
+
+This is probably an error, since you should not delete only one atom
+of a molecule. :dd
+
+{Fix gcmc using full_energy option} :dt
+
+Fix gcmc has automatically turned on the full_energy option since it
+is required for systems like the one specified by the user. User input
+included one or more of the following: kspace, triclinic, a hybrid
+pair style, an eam pair style, or no "single" function for the pair
+style. :dd
+
+{Fix property/atom mol or charge w/out ghost communication} :dt
+
+A model typically needs these properties defined for ghost atoms. :dd
+
+{Fix qeq CG convergence failed (%g) after %d iterations at %ld step} :dt
+
+Self-explanatory. :dd
+
+{Fix qeq has non-zero lower Taper radius cutoff} :dt
+
+Absolute value must be <= 0.01. :dd
+
+{Fix qeq has very low Taper radius cutoff} :dt
+
+Value should typically be >= 5.0. :dd
+
+{Fix qeq/dynamic tolerance may be too small for damped dynamics} :dt
+
+Self-explanatory. :dd
+
+{Fix qeq/fire tolerance may be too small for damped fires} :dt
+
+Self-explanatory. :dd
+
+{Fix rattle should come after all other integration fixes} :dt
+
+This fix is designed to work after all other integration fixes change
+atom positions. Thus it should be the last integration fix specified.
+If not, it will not satisfy the desired constraints as well as it
+otherwise would. :dd
+
+{Fix recenter should come after all other integration fixes} :dt
+
+Other fixes may change the position of the center-of-mass, so
+fix recenter should come last. :dd
+
+{Fix srd SRD moves may trigger frequent reneighboring} :dt
+
+This is because the SRD particles may move long distances. :dd
+
+{Fix srd grid size > 1/4 of big particle diameter} :dt
+
+This may cause accuracy problems. :dd
+
+{Fix srd particle moved outside valid domain} :dt
+
+This may indicate a problem with your simulation parameters. :dd
+
+{Fix srd particles may move > big particle diameter} :dt
+
+This may cause accuracy problems. :dd
+
+{Fix srd viscosity < 0.0 due to low SRD density} :dt
+
+This may cause accuracy problems. :dd
+
+{Fix thermal/conductivity comes before fix ave/spatial} :dt
+
+The order of these 2 fixes in your input script is such that fix
+thermal/conductivity comes first. If you are using fix ave/spatial to
+measure the temperature profile induced by fix viscosity, then this
+may cause a glitch in the profile since you are averaging immediately
+after swaps have occurred. Flipping the order of the 2 fixes
+typically helps. :dd
+
+{Fix viscosity comes before fix ave/spatial} :dt
+
+The order of these 2 fixes in your input script is such that
+fix viscosity comes first. If you are using fix ave/spatial
+to measure the velocity profile induced by fix viscosity, then
+this may cause a glitch in the profile since you are averaging
+immediately after swaps have occurred. Flipping the order
+of the 2 fixes typically helps. :dd
+
+{Fixes cannot send data in Kokkos communication, switching to classic communication} :dt
+
+This is current restriction with Kokkos. :dd
+
+{For better accuracy use 'pair_modify table 0'} :dt
+
+The user-specified force accuracy cannot be achieved unless the table
+feature is disabled by using 'pair_modify table 0'. :dd
+
+{Geometric mixing assumed for 1/r^6 coefficients} :dt
+
+Self-explanatory. :dd
+
+{Group for fix_modify temp != fix group} :dt
+
+The fix_modify command is specifying a temperature computation that
+computes a temperature on a different group of atoms than the fix
+itself operates on. This is probably not what you want to do. :dd
+
+{H matrix size has been exceeded: m_fill=%d H.m=%d\n} :dt
+
+This is the size of the matrix. :dd
+
+{Ignoring unknown or incorrect info command flag} :dt
+
+Self-explanatory. An unknown argument was given to the info command.
+Compare your input with the documentation. :dd
+
+{Improper atoms missing at step %ld} :dt
+
+One or more of 4 atoms needed to compute a particular improper are
+missing on this processor. Typically this is because the pairwise
+cutoff is set too short or the improper has blown apart and an atom is
+too far away. :dd
+
+{Improper problem: %d %ld %d %d %d %d} :dt
+
+Conformation of the 4 listed improper atoms is extreme; you may want
+to check your simulation geometry. :dd
+
+{Improper style in data file differs from currently defined improper style} :dt
+
+Self-explanatory. :dd
+
+{Inconsistent image flags} :dt
+
+The image flags for a pair on bonded atoms appear to be inconsistent.
+Inconsistent means that when the coordinates of the two atoms are
+unwrapped using the image flags, the two atoms are far apart.
+Specifically they are further apart than half a periodic box length.
+Or they are more than a box length apart in a non-periodic dimension.
+This is usually due to the initial data file not having correct image
+flags for the 2 atoms in a bond that straddles a periodic boundary.
+They should be different by 1 in that case. This is a warning because
+inconsistent image flags will not cause problems for dynamics or most
+LAMMPS simulations. However they can cause problems when such atoms
+are used with the fix rigid or replicate commands. Note that if you
+have an infinite periodic crystal with bonds then it is impossible to
+have fully consistent image flags, since some bonds will cross
+periodic boundaries and connect two atoms with the same image
+flag. :dd
+
+{KIM Model does not provide 'energy'; Potential energy will be zero} :dt
+
+Self-explanatory. :dd
+
+{KIM Model does not provide 'forces'; Forces will be zero} :dt
+
+Self-explanatory. :dd
+
+{KIM Model does not provide 'particleEnergy'; energy per atom will be zero} :dt
+
+Self-explanatory. :dd
+
+{KIM Model does not provide 'particleVirial'; virial per atom will be zero} :dt
+
+Self-explanatory. :dd
+
+{Kspace_modify slab param < 2.0 may cause unphysical behavior} :dt
+
+The kspace_modify slab parameter should be larger to insure periodic
+grids padded with empty space do not overlap. :dd
+
+{Less insertions than requested} :dt
+
+The fix pour command was unsuccessful at finding open space
+for as many particles as it tried to insert. :dd
+
+{Library error in lammps_gather_atoms} :dt
+
+This library function cannot be used if atom IDs are not defined
+or are not consecutively numbered. :dd
+
+{Library error in lammps_scatter_atoms} :dt
+
+This library function cannot be used if atom IDs are not defined or
+are not consecutively numbered, or if no atom map is defined. See the
+atom_modify command for details about atom maps. :dd
+
+{Lost atoms via change_box: original %ld current %ld} :dt
+
+The command options you have used caused atoms to be lost. :dd
+
+{Lost atoms via displace_atoms: original %ld current %ld} :dt
+
+The command options you have used caused atoms to be lost. :dd
+
+{Lost atoms: original %ld current %ld} :dt
+
+Lost atoms are checked for each time thermo output is done. See the
+thermo_modify lost command for options. Lost atoms usually indicate
+bad dynamics, e.g. atoms have been blown far out of the simulation
+box, or moved further than one processor's sub-domain away before
+reneighboring. :dd
+
+{MSM mesh too small, increasing to 2 points in each direction} :dt
+
+Self-explanatory. :dd
+
+{Mismatch between velocity and compute groups} :dt
+
+The temperature computation used by the velocity command will not be
+on the same group of atoms that velocities are being set for. :dd
+
+{Mixing forced for lj coefficients} :dt
+
+Self-explanatory. :dd
+
+{Molecule attributes do not match system attributes} :dt
+
+An attribute is specified (e.g. diameter, charge) that is
+not defined for the specified atom style. :dd
+
+{Molecule has bond topology but no special bond settings} :dt
+
+This means the bonded atoms will not be excluded in pair-wise
+interactions. :dd
+
+{Molecule template for create_atoms has multiple molecules} :dt
+
+The create_atoms command will only create molecules of a single type,
+i.e. the first molecule in the template. :dd
+
+{Molecule template for fix gcmc has multiple molecules} :dt
+
+The fix gcmc command will only create molecules of a single type,
+i.e. the first molecule in the template. :dd
+
+{Molecule template for fix shake has multiple molecules} :dt
+
+The fix shake command will only recognize molecules of a single
+type, i.e. the first molecule in the template. :dd
+
+{More than one compute centro/atom} :dt
+
+It is not efficient to use compute centro/atom more than once. :dd
+
+{More than one compute cluster/atom} :dt
+
+It is not efficient to use compute cluster/atom more than once. :dd
+
+{More than one compute cna/atom defined} :dt
+
+It is not efficient to use compute cna/atom more than once. :dd
+
+{More than one compute contact/atom} :dt
+
+It is not efficient to use compute contact/atom more than once. :dd
+
+{More than one compute coord/atom} :dt
+
+It is not efficient to use compute coord/atom more than once. :dd
+
+{More than one compute damage/atom} :dt
+
+It is not efficient to use compute ke/atom more than once. :dd
+
+{More than one compute dilatation/atom} :dt
+
+Self-explanatory. :dd
+
+{More than one compute erotate/sphere/atom} :dt
+
+It is not efficient to use compute erorate/sphere/atom more than once. :dd
+
+{More than one compute hexorder/atom} :dt
+
+It is not efficient to use compute hexorder/atom more than once. :dd
+
+{More than one compute ke/atom} :dt
+
+It is not efficient to use compute ke/atom more than once. :dd
+
+{More than one compute orientorder/atom} :dt
+
+It is not efficient to use compute orientorder/atom more than once. :dd
+
+{More than one compute plasticity/atom} :dt
+
+Self-explanatory. :dd
+
+{More than one compute sna/atom} :dt
+
+Self-explanatory. :dd
+
+{More than one compute snad/atom} :dt
+
+Self-explanatory. :dd
+
+{More than one compute snav/atom} :dt
+
+Self-explanatory. :dd
+
+{More than one fix poems} :dt
+
+It is not efficient to use fix poems more than once. :dd
+
+{More than one fix rigid} :dt
+
+It is not efficient to use fix rigid more than once. :dd
+
+{Neighbor exclusions used with KSpace solver may give inconsistent Coulombic energies} :dt
+
+This is because excluding specific pair interactions also excludes
+them from long-range interactions which may not be the desired effect.
+The special_bonds command handles this consistently by insuring
+excluded (or weighted) 1-2, 1-3, 1-4 interactions are treated
+consistently by both the short-range pair style and the long-range
+solver. This is not done for exclusions of charged atom pairs via the
+neigh_modify exclude command. :dd
+
+{New thermo_style command, previous thermo_modify settings will be lost} :dt
+
+If a thermo_style command is used after a thermo_modify command, the
+settings changed by the thermo_modify command will be reset to their
+default values. This is because the thermo_modify command acts on
+the currently defined thermo style, and a thermo_style command creates
+a new style. :dd
+
+{No Kspace calculation with verlet/split} :dt
+
+The 2nd partition performs a kspace calculation so the kspace_style
+command must be used. :dd
+
+{No automatic unit conversion to XTC file format conventions possible for units lj} :dt
+
+This means no scaling will be performed. :dd
+
+{No fixes defined, atoms won't move} :dt
+
+If you are not using a fix like nve, nvt, npt then atom velocities and
+coordinates will not be updated during timestepping. :dd
+
+{No joints between rigid bodies, use fix rigid instead} :dt
+
+The bodies defined by fix poems are not connected by joints. POEMS
+will integrate the body motion, but it would be more efficient to use
+fix rigid. :dd
+
+{Not using real units with pair reax} :dt
+
+This is most likely an error, unless you have created your own ReaxFF
+parameter file in a different set of units. :dd
+
+{Number of MSM mesh points changed to be a multiple of 2} :dt
+
+MSM requires that the number of grid points in each direction be a multiple
+of two and the number of grid points in one or more directions have been
+adjusted to meet this requirement. :dd
+
+{OMP_NUM_THREADS environment is not set.} :dt
+
+This environment variable must be set appropriately to use the
+USER-OMP package. :dd
+
+{One or more atoms are time integrated more than once} :dt
+
+This is probably an error since you typically do not want to
+advance the positions or velocities of an atom more than once
+per timestep. :dd
+
+{One or more chunks do not contain all atoms in molecule} :dt
+
+This may not be what you intended. :dd
+
+{One or more dynamic groups may not be updated at correct point in timestep} :dt
+
+If there are other fixes that act immediately after the initial stage
+of time integration within a timestep (i.e. after atoms move), then
+the command that sets up the dynamic group should appear after those
+fixes. This will insure that dynamic group assignments are made
+after all atoms have moved. :dd
+
+{One or more respa levels compute no forces} :dt
+
+This is computationally inefficient. :dd
+
+{Pair COMB charge %.10f with force %.10f hit max barrier} :dt
+
+Something is possibly wrong with your model. :dd
+
+{Pair COMB charge %.10f with force %.10f hit min barrier} :dt
+
+Something is possibly wrong with your model. :dd
+
+{Pair brownian needs newton pair on for momentum conservation} :dt
+
+Self-explanatory. :dd
+
+{Pair dpd needs newton pair on for momentum conservation} :dt
+
+Self-explanatory. :dd
+
+{Pair dsmc: num_of_collisions > number_of_A} :dt
+
+Collision model in DSMC is breaking down. :dd
+
+{Pair dsmc: num_of_collisions > number_of_B} :dt
+
+Collision model in DSMC is breaking down. :dd
+
+{Pair style in data file differs from currently defined pair style} :dt
+
+Self-explanatory. :dd
+
+{Pair style restartinfo set but has no restart support} :dt
+
+This pair style has a bug, where it does not support reading and
+writing information to a restart file, but does not set the member
+variable "restartinfo" to 0 as required in that case. :dd
+
+{Particle deposition was unsuccessful} :dt
+
+The fix deposit command was not able to insert as many atoms as
+needed. The requested volume fraction may be too high, or other atoms
+may be in the insertion region. :dd
+
+{Proc sub-domain size < neighbor skin, could lead to lost atoms} :dt
+
+The decomposition of the physical domain (likely due to load
+balancing) has led to a processor's sub-domain being smaller than the
+neighbor skin in one or more dimensions. Since reneighboring is
+triggered by atoms moving the skin distance, this may lead to lost
+atoms, if an atom moves all the way across a neighboring processor's
+sub-domain before reneighboring is triggered. :dd
+
+{Reducing PPPM order b/c stencil extends beyond nearest neighbor processor} :dt
+
+This may lead to a larger grid than desired. See the kspace_modify overlap
+command to prevent changing of the PPPM order. :dd
+
+{Reducing PPPMDisp Coulomb order b/c stencil extends beyond neighbor processor} :dt
+
+This may lead to a larger grid than desired. See the kspace_modify overlap
+command to prevent changing of the PPPM order. :dd
+
+{Reducing PPPMDisp dispersion order b/c stencil extends beyond neighbor processor} :dt
+
+This may lead to a larger grid than desired. See the kspace_modify overlap
+command to prevent changing of the PPPM order. :dd
+
+{Replacing a fix, but new group != old group} :dt
+
+The ID and style of a fix match for a fix you are changing with a fix
+command, but the new group you are specifying does not match the old
+group. :dd
+
+{Replicating in a non-periodic dimension} :dt
+
+The parameters for a replicate command will cause a non-periodic
+dimension to be replicated; this may cause unwanted behavior. :dd
+
+{Resetting reneighboring criteria during PRD} :dt
+
+A PRD simulation requires that neigh_modify settings be delay = 0,
+every = 1, check = yes. Since these settings were not in place,
+LAMMPS changed them and will restore them to their original values
+after the PRD simulation. :dd
+
+{Resetting reneighboring criteria during TAD} :dt
+
+A TAD simulation requires that neigh_modify settings be delay = 0,
+every = 1, check = yes. Since these settings were not in place,
+LAMMPS changed them and will restore them to their original values
+after the PRD simulation. :dd
+
+{Resetting reneighboring criteria during minimization} :dt
+
+Minimization requires that neigh_modify settings be delay = 0, every =
+1, check = yes. Since these settings were not in place, LAMMPS
+changed them and will restore them to their original values after the
+minimization. :dd
+
+{Restart file used different # of processors} :dt
+
+The restart file was written out by a LAMMPS simulation running on a
+different number of processors. Due to round-off, the trajectories of
+your restarted simulation may diverge a little more quickly than if
+you ran on the same # of processors. :dd
+
+{Restart file used different 3d processor grid} :dt
+
+The restart file was written out by a LAMMPS simulation running on a
+different 3d grid of processors. Due to round-off, the trajectories
+of your restarted simulation may diverge a little more quickly than if
+you ran on the same # of processors. :dd
+
+{Restart file used different boundary settings, using restart file values} :dt
+
+Your input script cannot change these restart file settings. :dd
+
+{Restart file used different newton bond setting, using restart file value} :dt
+
+The restart file value will override the setting in the input script. :dd
+
+{Restart file used different newton pair setting, using input script value} :dt
+
+The input script value will override the setting in the restart file. :dd
+
+{Restrain problem: %d %ld %d %d %d %d} :dt
+
+Conformation of the 4 listed dihedral atoms is extreme; you may want
+to check your simulation geometry. :dd
+
+{Running PRD with only one replica} :dt
+
+This is allowed, but you will get no parallel speed-up. :dd
+
+{SRD bin shifting turned on due to small lamda} :dt
+
+This is done to try to preserve accuracy. :dd
+
+{SRD bin size for fix srd differs from user request} :dt
+
+Fix SRD had to adjust the bin size to fit the simulation box. See the
+cubic keyword if you want this message to be an error vs warning. :dd
+
+{SRD bins for fix srd are not cubic enough} :dt
+
+The bin shape is not within tolerance of cubic. See the cubic
+keyword if you want this message to be an error vs warning. :dd
+
+{SRD particle %d started inside big particle %d on step %ld bounce %d} :dt
+
+See the inside keyword if you want this message to be an error vs
+warning. :dd
+
+{SRD particle %d started inside wall %d on step %ld bounce %d} :dt
+
+See the inside keyword if you want this message to be an error vs
+warning. :dd
+
+{Shake determinant < 0.0} :dt
+
+The determinant of the quadratic equation being solved for a single
+cluster specified by the fix shake command is numerically suspect. LAMMPS
+will set it to 0.0 and continue. :dd
+
+{Shell command '%s' failed with error '%s'} :dt
+
+Self-explanatory. :dd
+
+{Shell command returned with non-zero status} :dt
+
+This may indicate the shell command did not operate as expected. :dd
+
+{Should not allow rigid bodies to bounce off relecting walls} :dt
+
+LAMMPS allows this, but their dynamics are not computed correctly. :dd
+
+{Should not use fix nve/limit with fix shake or fix rattle} :dt
+
+This will lead to invalid constraint forces in the SHAKE/RATTLE
+computation. :dd
+
+{Simulations might be very slow because of large number of structure factors} :dt
+
+Self-explanatory. :dd
+
+{Slab correction not needed for MSM} :dt
+
+Slab correction is intended to be used with Ewald or PPPM and is not needed by MSM. :dd
+
+{System is not charge neutral, net charge = %g} :dt
+
+The total charge on all atoms on the system is not 0.0.
+For some KSpace solvers this is only a warning. :dd
+
+{Table inner cutoff >= outer cutoff} :dt
+
+You specified an inner cutoff for a Coulombic table that is longer
+than the global cutoff. Probably not what you wanted. :dd
+
+{Temperature for MSST is not for group all} :dt
+
+User-assigned temperature to MSST fix does not compute temperature for
+all atoms. Since MSST computes a global pressure, the kinetic energy
+contribution from the temperature is assumed to also be for all atoms.
+Thus the pressure used by MSST could be inaccurate. :dd
+
+{Temperature for NPT is not for group all} :dt
+
+User-assigned temperature to NPT fix does not compute temperature for
+all atoms. Since NPT computes a global pressure, the kinetic energy
+contribution from the temperature is assumed to also be for all atoms.
+Thus the pressure used by NPT could be inaccurate. :dd
+
+{Temperature for fix modify is not for group all} :dt
+
+The temperature compute is being used with a pressure calculation
+which does operate on group all, so this may be inconsistent. :dd
+
+{Temperature for thermo pressure is not for group all} :dt
+
+User-assigned temperature to thermo via the thermo_modify command does
+not compute temperature for all atoms. Since thermo computes a global
+pressure, the kinetic energy contribution from the temperature is
+assumed to also be for all atoms. Thus the pressure printed by thermo
+could be inaccurate. :dd
+
+{The fix ave/spatial command has been replaced by the more flexible fix ave/chunk and compute chunk/atom commands -- fix ave/spatial will be removed in the summer of 2015} :dt
+
+Self-explanatory. :dd
+
+{The minimizer does not re-orient dipoles when using fix efield} :dt
+
+This means that only the atom coordinates will be minimized,
+not the orientation of the dipoles. :dd
+
+{Too many common neighbors in CNA %d times} :dt
+
+More than the maximum # of neighbors was found multiple times. This
+was unexpected. :dd
+
+{Too many inner timesteps in fix ttm} :dt
+
+Self-explanatory. :dd
+
+{Too many neighbors in CNA for %d atoms} :dt
+
+More than the maximum # of neighbors was found multiple times. This
+was unexpected. :dd
+
+{Triclinic box skew is large} :dt
+
+The displacement in a skewed direction is normally required to be less
+than half the box length in that dimension. E.g. the xy tilt must be
+between -half and +half of the x box length. You have relaxed the
+constraint using the box tilt command, but the warning means that a
+LAMMPS simulation may be inefficient as a result. :dd
+
+{Use special bonds = 0,1,1 with bond style fene} :dt
+
+Most FENE models need this setting for the special_bonds command. :dd
+
+{Use special bonds = 0,1,1 with bond style fene/expand} :dt
+
+Most FENE models need this setting for the special_bonds command. :dd
+
+{Using a manybody potential with bonds/angles/dihedrals and special_bond exclusions} :dt
+
+This is likely not what you want to do. The exclusion settings will
+eliminate neighbors in the neighbor list, which the manybody potential
+needs to calculated its terms correctly. :dd
+
+{Using compute temp/deform with inconsistent fix deform remap option} :dt
+
+Fix nvt/sllod assumes deforming atoms have a velocity profile provided
+by "remap v" or "remap none" as a fix deform option. :dd
+
+{Using compute temp/deform with no fix deform defined} :dt
+
+This is probably an error, since it makes little sense to use
+compute temp/deform in this case. :dd
+
+{Using fix srd with box deformation but no SRD thermostat} :dt
+
+The deformation will heat the SRD particles so this can
+be dangerous. :dd
+
+{Using kspace solver on system with no charge} :dt
+
+Self-explanatory. :dd
+
+{Using largest cut-off for lj/long/dipole/long long long} :dt
+
+Self-explanatory. :dd
+
+{Using largest cutoff for buck/long/coul/long} :dt
+
+Self-explanatory. :dd
+
+{Using largest cutoff for lj/long/coul/long} :dt
+
+Self-explanatory. :dd
+
+{Using largest cutoff for pair_style lj/long/tip4p/long} :dt
+
+Self-explanatory. :dd
+
+{Using package gpu without any pair style defined} :dt
+
+Self-explanatory. :dd
+
+{Using pair potential shift with pair_modify compute no} :dt
+
+The shift effects will thus not be computed. :dd
+
+{Using pair tail corrections with nonperiodic system} :dt
+
+This is probably a bogus thing to do, since tail corrections are
+computed by integrating the density of a periodic system out to
+infinity. :dd
+
+{Using pair tail corrections with pair_modify compute no} :dt
+
+The tail corrections will thus not be computed. :dd
+
+{pair style reax is now deprecated and will soon be retired. Users should switch to pair_style reax/c} :dt
+
+Self-explanatory. :dd
+
+:dle
diff --git a/doc/src/Section_example.txt b/doc/src/Examples.txt
similarity index 91%
rename from doc/src/Section_example.txt
rename to doc/src/Examples.txt
index a2a9940f4845f10c2df5fe3333c8de30cba1ea7d..4b6db8a047f64b5ab204750c8bf0a88da9d45140 100644
--- a/doc/src/Section_example.txt
+++ b/doc/src/Examples.txt
@@ -1,12 +1,14 @@
-"Previous Section"_Section_howto.html - "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Section_perf.html :c
+"Previous Section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc - "Next
+Section"_Tools.html :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
-7. Example problems :h2
+Example scripts :h3
The LAMMPS distribution includes an examples sub-directory with many
sample problems. Many are 2d models that run quickly are are
@@ -46,7 +48,7 @@ Lists of both kinds of directories are given below.
:line
-Lowercase directories :h3
+Lowercase directories :h4
accelerate: run with various acceleration options (OpenMP, GPU, Phi)
airebo: polyethylene with AIREBO potential
@@ -110,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
-2.2"_Section_start.html#start_2 for details). These can be viewed
-individually or turned into a movie or animated by tools like
-ImageMagick or QuickTime or various Windows-based tools. See the
+you built LAMMPS with JPG support; see the
+"Build_settings"_Build_settings.html doc page for details). These can
+be viewed individually or turned into a movie or animated by tools
+like ImageMagick or QuickTime or various Windows-based tools. See the
"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.
@@ -122,7 +124,7 @@ browser.
:line
-Uppercase directories :h3
+Uppercase directories :h4
ASPHERE: various aspherical particle models, using ellipsoids, rigid bodies, line/triangle particles, etc
COUPLE: examples of how to use LAMMPS as a library
@@ -141,5 +143,5 @@ The USER directory has a large number of sub-directories which
correspond by name to a USER package. They contain scripts that
illustrate how to use the command(s) provided in that package. Many
of the sub-directories have their own README files which give further
-instructions. See the "Section 4"_Section_packages.html doc
+instructions. See the "Packages_details"_Packages_details.html doc
page for more info on specific USER packages.
diff --git a/doc/src/Howto.txt b/doc/src/Howto.txt
new file mode 100644
index 0000000000000000000000000000000000000000..438ea561a10f9fa87f0e119aedd26bdbd13e89dd
--- /dev/null
+++ b/doc/src/Howto.txt
@@ -0,0 +1,189 @@
+"Previous Section"_Performance.html - "LAMMPS WWW Site"_lws -
+"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
+Section"_Examples.html :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands.html#comm)
+
+:line
+
+Howto discussions :h2
+
+These doc pages describe how to perform various tasks with LAMMPS,
+both for users and developers. The
+"glossary"_http://lammps.sandia.gov website page also lists MD
+terminology with links to corresponding LAMMPS manual pages. The
+example input scripts included in the examples dir of the LAMMPS
+distribution and highlighted on the "Examples"_Examples.html doc page
+also show how to setup and run various kinds of simulations.
+
+Tutorials howto :h3
+
+<!-- RST
+
+.. toctree::
+ :name: tutorials
+ :maxdepth: 1
+
+ Howto_github
+ Howto_pylammps
+ Howto_bash
+
+END_RST -->
+
+<!-- HTML_ONLY -->
+
+"Using GitHub with LAMMPS"_Howto_github.html
+"PyLAMMPS interface to LAMMPS"_Howto_pylammps.html
+"Using LAMMPS with bash on Windows"_Howto_bash.html :all(b)
+
+<!-- END_HTML_ONLY -->
+
+General howto :h3
+
+<!-- RST
+
+.. toctree::
+ :name: general
+ :maxdepth: 1
+
+ Howto_restart
+ Howto_viz
+ Howto_multiple
+ Howto_replica
+ Howto_library
+ Howto_couple
+
+END_RST -->
+
+<!-- HTML_ONLY -->
+
+"Restart a simulation"_Howto_restart.html
+"Visualize LAMMPS snapshots"_Howto_viz.html
+"Run multiple simulations from one input script"_Howto_multiple.html
+"Multi-replica simulations"_Howto_replica.html
+"Library interface to LAMMPS"_Howto_library.html
+"Couple LAMMPS to other codes"_Howto_couple.html :all(b)
+
+<!-- END_HTML_ONLY -->
+
+Settings howto :h3
+
+<!-- RST
+
+.. toctree::
+ :name: settings
+ :maxdepth: 1
+
+ Howto_2d
+ Howto_triclinic
+ Howto_thermostat
+ Howto_barostat
+ Howto_walls
+ Howto_nemd
+ Howto_dispersion
+
+END_RST -->
+
+<!-- HTML_ONLY -->
+
+"2d simulations"_Howto_2d.html
+"Triclinic (non-orthogonal) simulation boxes"_Howto_triclinic.html
+"Thermostats"_Howto_thermostat.html
+"Barostats"_Howto_barostat.html
+"Walls"_Howto_walls.html
+"NEMD simulations"_Howto_nemd.html
+"Long-range dispersion settings"_Howto_dispersion.html :all(b)
+
+<!-- END_HTML_ONLY -->
+
+
+Analysis howto :h3
+
+<!-- RST
+
+.. toctree::
+ :name: analysis
+ :maxdepth: 1
+
+ Howto_output
+ Howto_chunk
+ Howto_temperature
+ Howto_elastic
+ Howto_kappa
+ Howto_viscosity
+ Howto_diffusion
+
+END_RST -->
+
+<!-- HTML_ONLY -->
+
+"Output from LAMMPS (thermo, dumps, computes, fixes, variables)"_Howto_output.html
+"Use chunks to calculate system properties"_Howto_chunk.html :all(b)
+"Calculate temperature"_Howto_temperature.html
+"Calculate elastic constants"_Howto_elastic.html
+"Calculate thermal conductivity"_Howto_kappa.html
+"Calculate viscosity"_Howto_viscosity.html
+"Calculate a diffusion coefficient"_Howto_diffusion.html :all(b)
+
+<!-- END_HTML_ONLY -->
+
+Force fields howto :h3
+
+<!-- RST
+
+.. toctree::
+ :name: force
+ :maxdepth: 1
+
+ Howto_bioFF
+ Howto_tip3p
+ Howto_tip4p
+ Howto_spc
+
+END_RST -->
+
+<!-- HTML_ONLY -->
+
+"CHARMM, AMBER, and DREIDING force fields"_Howto_bioFF.html
+"TIP3P water model"_Howto_tip3p.html
+"TIP4P water model"_Howto_tip4p.html
+"SPC water model"_Howto_spc.html :all(b)
+
+<!-- END_HTML_ONLY -->
+
+Packages howto :h3
+
+<!-- RST
+
+.. toctree::
+ :name: packages
+ :maxdepth: 1
+
+ Howto_spherical
+ Howto_granular
+ Howto_body
+ Howto_polarizable
+ Howto_coreshell
+ Howto_drude
+ Howto_drude2
+ Howto_manifold
+ Howto_spins
+
+END_RST -->
+
+
+<!-- HTML_ONLY -->
+
+"Finite-size spherical and aspherical particles"_Howto_spherical.html
+"Granular models"_Howto_granular.html
+"Body style particles"_Howto_body.html
+"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
+"Manifolds (surfaces)"_Howto_manifold.html
+"Magnetic spins"_Howto_spins.html :all(b)
+
+<!-- END_HTML_ONLY -->
diff --git a/doc/src/Howto_2d.txt b/doc/src/Howto_2d.txt
new file mode 100644
index 0000000000000000000000000000000000000000..e1758c05d5ff9fc771e239ba6007f98d3abbbf63
--- /dev/null
+++ b/doc/src/Howto_2d.txt
@@ -0,0 +1,48 @@
+"Higher level section"_Howto.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
+
+2d simulations :h3
+
+Use the "dimension"_dimension.html command to specify a 2d simulation.
+
+Make the simulation box periodic in z via the "boundary"_boundary.html
+command. This is the default.
+
+If using the "create box"_create_box.html command to define a
+simulation box, set the z dimensions narrow, but finite, so that the
+create_atoms command will tile the 3d simulation box with a single z
+plane of atoms - e.g.
+
+"create box"_create_box.html 1 -10 10 -10 10 -0.25 0.25 :pre
+
+If using the "read data"_read_data.html command to read in a file of
+atom coordinates, set the "zlo zhi" values to be finite but narrow,
+similar to the create_box command settings just described. For each
+atom in the file, assign a z coordinate so it falls inside the
+z-boundaries of the box - e.g. 0.0.
+
+Use the "fix enforce2d"_fix_enforce2d.html command as the last
+defined fix to insure that the z-components of velocities and forces
+are zeroed out every timestep. The reason to make it the last fix is
+so that any forces induced by other fixes will be zeroed out.
+
+Many of the example input scripts included in the LAMMPS distribution
+are for 2d models.
+
+NOTE: Some models in LAMMPS treat particles as finite-size spheres, as
+opposed to point particles. See the "atom_style
+sphere"_atom_style.html and "fix nve/sphere"_fix_nve_sphere.html
+commands for details. By default, for 2d simulations, such particles
+will still be modeled as 3d spheres, not 2d discs (circles), meaning
+their moment of inertia will be that of a sphere. If you wish to
+model them as 2d discs, see the "set density/disc"_set.html command
+and the {disc} option for the "fix nve/sphere"_fix_nve_sphere.html,
+"fix nvt/sphere"_fix_nvt_sphere.html, "fix
+nph/sphere"_fix_nph_sphere.html, "fix npt/sphere"_fix_npt_sphere.html
+commands.
diff --git a/doc/src/Howto_barostat.txt b/doc/src/Howto_barostat.txt
new file mode 100644
index 0000000000000000000000000000000000000000..7c3db891524379f49fe38134186764e07eeff959
--- /dev/null
+++ b/doc/src/Howto_barostat.txt
@@ -0,0 +1,75 @@
+"Higher level section"_Howto.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
+
+Barostats :h3
+
+Barostatting means controlling the pressure in an MD simulation.
+"Thermostatting"_Howto_thermostat.html means controlling the
+temperature of the particles. Since the pressure includes a kinetic
+component due to particle velocities, both these operations require
+calculation of the temperature. Typically a target temperature (T)
+and/or pressure (P) is specified by the user, and the thermostat or
+barostat attempts to equilibrate the system to the requested T and/or
+P.
+
+Barostatting in LAMMPS is performed by "fixes"_fix.html. Two
+barosttating methods are currently available: Nose-Hoover (npt and
+nph) and Berendsen:
+
+"fix npt"_fix_nh.html
+"fix npt/sphere"_fix_npt_sphere.html
+"fix npt/asphere"_fix_npt_asphere.html
+"fix nph"_fix_nh.html
+"fix press/berendsen"_fix_press_berendsen.html :ul
+
+The "fix npt"_fix_nh.html commands include a Nose-Hoover thermostat
+and barostat. "Fix nph"_fix_nh.html is just a Nose/Hoover barostat;
+it does no thermostatting. Both "fix nph"_fix_nh.html and "fix
+press/berendsen"_fix_press_berendsen.html can be used in conjunction
+with any of the thermostatting fixes.
+
+As with the "thermostats"_Howto_thermostat.html, "fix npt"_fix_nh.html
+and "fix nph"_fix_nh.html only use translational motion of the
+particles in computing T and P and performing thermo/barostatting.
+"Fix npt/sphere"_fix_npt_sphere.html and "fix
+npt/asphere"_fix_npt_asphere.html thermo/barostat using not only
+translation velocities but also rotational velocities for spherical
+and aspherical particles.
+
+All of the barostatting fixes use the "compute
+pressure"_compute_pressure.html compute to calculate a current
+pressure. By default, this compute is created with a simple "compute
+temp"_compute_temp.html (see the last argument of the "compute
+pressure"_compute_pressure.html command), which is used to calculated
+the kinetic component of the pressure. The barostatting fixes can
+also use temperature computes that remove bias for the purpose of
+computing the kinetic component which contributes to the current
+pressure. See the doc pages for the individual fixes and for the
+"fix_modify"_fix_modify.html command for instructions on how to assign
+a temperature or pressure compute to a barostatting fix.
+
+NOTE: As with the thermostats, the Nose/Hoover methods ("fix
+npt"_fix_nh.html and "fix nph"_fix_nh.html) perform time integration.
+"Fix press/berendsen"_fix_press_berendsen.html does NOT, so it should
+be used with one of the constant NVE fixes or with one of the NVT
+fixes.
+
+Thermodynamic output, which can be setup via the
+"thermo_style"_thermo_style.html command, often includes pressure
+values. As explained on the doc page for the
+"thermo_style"_thermo_style.html command, the default pressure is
+setup by the thermo command itself. It is NOT the presure associated
+with any barostatting fix you have defined or with any compute you
+have defined that calculates a presure. The doc pages for the
+barostatting fixes explain the ID of the pressure compute they create.
+Thus if you want to view these pressurse, you need to specify them
+explicitly via the "thermo_style custom"_thermo_style.html command.
+Or you can use the "thermo_modify"_thermo_modify.html command to
+re-define what pressure compute is used for default thermodynamic
+output.
diff --git a/doc/src/tutorial_bash_on_windows.txt b/doc/src/Howto_bash.txt
old mode 100644
new mode 100755
similarity index 99%
rename from doc/src/tutorial_bash_on_windows.txt
rename to doc/src/Howto_bash.txt
index 66712bdffafc8173bef83e5883bae8d3e0843ec0..f1438418e78b2bf97118992dea972e73513e0e29
--- a/doc/src/tutorial_bash_on_windows.txt
+++ b/doc/src/Howto_bash.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -10,6 +10,7 @@ Using LAMMPS with Bash on Windows :h3
[written by Richard Berger]
:line
+
Starting with Windows 10 you can install Linux tools directly in Windows. This
allows you to compile LAMMPS following the same procedure as on a real Ubuntu
Linux installation. Software can be easily installed using the package manager
diff --git a/doc/src/Howto_bioFF.txt b/doc/src/Howto_bioFF.txt
new file mode 100644
index 0000000000000000000000000000000000000000..deb5b31441918e8646b29c74740fc16ed0ed4b52
--- /dev/null
+++ b/doc/src/Howto_bioFF.txt
@@ -0,0 +1,105 @@
+"Higher level section"_Howto.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
+
+CHARMM, AMBER, and DREIDING force fields :h3
+
+A force field has 2 parts: the formulas that define it and the
+coefficients used for a particular system. Here we only discuss
+formulas implemented in LAMMPS that correspond to formulas commonly
+used in the CHARMM, AMBER, and DREIDING force fields. Setting
+coefficients is done in the input data file via the
+"read_data"_read_data.html command or in the input script with
+commands like "pair_coeff"_pair_coeff.html or
+"bond_coeff"_bond_coeff.html. See the "Tools"_Tools.html doc page for
+additional tools that can use CHARMM or AMBER to assign force field
+coefficients and convert their output into LAMMPS input.
+
+See "(MacKerell)"_#howto-MacKerell for a description of the CHARMM force
+field. See "(Cornell)"_#howto-Cornell for a description of the AMBER force
+field.
+
+:link(charmm,http://www.scripps.edu/brooks)
+:link(amber,http://amber.scripps.edu)
+
+These style choices compute force field formulas that are consistent
+with common options in CHARMM or AMBER. See each command's
+documentation for the formula it computes.
+
+"bond_style"_bond_harmonic.html harmonic
+"angle_style"_angle_charmm.html charmm
+"dihedral_style"_dihedral_charmm.html charmmfsh
+"dihedral_style"_dihedral_charmm.html charmm
+"pair_style"_pair_charmm.html lj/charmmfsw/coul/charmmfsh
+"pair_style"_pair_charmm.html lj/charmmfsw/coul/long
+"pair_style"_pair_charmm.html lj/charmm/coul/charmm
+"pair_style"_pair_charmm.html lj/charmm/coul/charmm/implicit
+"pair_style"_pair_charmm.html lj/charmm/coul/long :ul
+
+"special_bonds"_special_bonds.html charmm
+"special_bonds"_special_bonds.html amber :ul
+
+NOTE: For CHARMM, newer {charmmfsw} or {charmmfsh} styles were
+released in March 2017. We recommend they be used instead of the
+older {charmm} styles. See discussion of the differences on the "pair
+charmm"_pair_charmm.html and "dihedral charmm"_dihedral_charmm.html
+doc pages.
+
+DREIDING is a generic force field developed by the "Goddard
+group"_http://www.wag.caltech.edu at Caltech and is useful for
+predicting structures and dynamics of organic, biological and
+main-group inorganic molecules. The philosophy in DREIDING is to use
+general force constants and geometry parameters based on simple
+hybridization considerations, rather than individual force constants
+and geometric parameters that depend on the particular combinations of
+atoms involved in the bond, angle, or torsion terms. DREIDING has an
+"explicit hydrogen bond term"_pair_hbond_dreiding.html to describe
+interactions involving a hydrogen atom on very electronegative atoms
+(N, O, F).
+
+See "(Mayo)"_#howto-Mayo for a description of the DREIDING force field
+
+These style choices compute force field formulas that are consistent
+with the DREIDING force field. See each command's
+documentation for the formula it computes.
+
+"bond_style"_bond_harmonic.html harmonic
+"bond_style"_bond_morse.html morse :ul
+
+"angle_style"_angle_harmonic.html harmonic
+"angle_style"_angle_cosine.html cosine
+"angle_style"_angle_cosine_periodic.html cosine/periodic :ul
+
+"dihedral_style"_dihedral_charmm.html charmm
+"improper_style"_improper_umbrella.html umbrella :ul
+
+"pair_style"_pair_buck.html buck
+"pair_style"_pair_buck.html buck/coul/cut
+"pair_style"_pair_buck.html buck/coul/long
+"pair_style"_pair_lj.html lj/cut
+"pair_style"_pair_lj.html lj/cut/coul/cut
+"pair_style"_pair_lj.html lj/cut/coul/long :ul
+
+"pair_style"_pair_hbond_dreiding.html hbond/dreiding/lj
+"pair_style"_pair_hbond_dreiding.html hbond/dreiding/morse :ul
+
+"special_bonds"_special_bonds.html dreiding :ul
+
+:line
+
+:link(howto-MacKerell)
+[(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).
diff --git a/doc/src/body.txt b/doc/src/Howto_body.txt
similarity index 52%
rename from doc/src/body.txt
rename to doc/src/Howto_body.txt
index 8d49efdae40eed30f9c7ec82e704adc3aef44771..3535349b461589aa6ddafdf4e9a3d684a546c2e1 100644
--- a/doc/src/body.txt
+++ b/doc/src/Howto_body.txt
@@ -1,24 +1,24 @@
-"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
-Body particles :h2
+Body particles :h3
[Overview:]
-This doc page is not about a LAMMPS input script command, but about
-body particles, which are generalized finite-size particles.
+In LAMMPS, body particles are generalized finite-size particles.
Individual body particles can represent complex entities, such as
surface meshes of discrete points, collections of sub-particles,
deformable objects, etc. Note that other kinds of finite-size
spherical and aspherical particles are also supported by LAMMPS, such
as spheres, ellipsoids, line segments, and triangles, but they are
-simpler entities that body particles. See "Section
-6.14"_Section_howto.html#howto_14 for a general overview of all
+simpler entities that body particles. See the "Howto
+spherical"_Howto_spherical.html doc page for a general overview of all
these particle types.
Body particles are used via the "atom_style body"_atom_style.html
@@ -27,19 +27,17 @@ styles supported by LAMMPS are as follows. The name in the first
column is used as the {bstyle} argument for the "atom_style
body"_atom_style.html command.
-{nparticle} | rigid body with N sub-particles |
-{rounded/polygon} | 2d convex polygon with N vertices :tb(c=2,s=|)
+{nparticle} : rigid body with N sub-particles
+{rounded/polygon} : 2d polygons with N vertices
+{rounded/polyhedron} : 3d polyhedra with N vertices, E edges and F faces :tb(s=:)
The body style determines what attributes are stored for each body and
thus how they can be used to compute pairwise body/body or
bond/non-body (point particle) interactions. More details of each
style are described below.
-NOTE: The rounded/polygon style listed in the table above and
-described below has not yet been relesed in LAMMPS. It will be soon.
-
-We hope to add more styles in the future. See "Section
-10.12"_Section_modify.html#mod_12 for details on how to add a new body
+More styles may be added in the future. See the "Modify
+body"_Modify_body.html doc page for details on how to add a new body
style to the code.
:line
@@ -61,7 +59,7 @@ the simple particles.
By contrast, when body particles are used, LAMMPS treats an entire
body as a single particle for purposes of computing pairwise
interactions, building neighbor lists, migrating particles between
-processors, outputting particles to a dump file, etc. This means that
+processors, output of particles to a dump file, etc. This means that
interactions between pairs of bodies or between a body and non-body
(point) particle need to be encoded in an appropriate pair style. If
such a pair style were to mimic the "fix rigid"_fix_rigid.html model,
@@ -72,17 +70,20 @@ single body/body interaction was computed.
Thus it only makes sense to use body particles and develop such a pair
style, when particle/particle interactions are more complex than what
the "fix rigid"_fix_rigid.html command can already calculate. For
-example, if particles have one or more of the following attributes:
+example, consider particles with one or more of the following
+attributes:
represented by a surface mesh
represented by a collection of geometric entities (e.g. planes + spheres)
deformable
internal stress that induces fragmentation :ul
-then the interaction between pairs of particles is likely to be more
-complex than the summation of simple sub-particle interactions. An
-example is contact or frictional forces between particles with planar
-surfaces that inter-penetrate.
+For these models, the interaction between pairs of particles is likely
+to be more complex than the summation of simple pairwise interactions.
+An example is contact or frictional forces between particles with
+planar surfaces that inter-penetrate. Likewise, the body particle may
+store internal state, such as a stress tensor used to compute a
+fracture criterion.
These are additional LAMMPS commands that can be used with body
particles of different styles
@@ -130,7 +131,9 @@ x1 y1 z1
...
xN yN zN :pre
-N is the number of sub-particles in the body particle. M = 6 + 3*N.
+where M = 6 + 3*N, and N is the number of sub-particles in the body
+particle.
+
The integer line has a single value N. The floating point line(s)
list 6 moments of inertia followed by the coordinates of the N
sub-particles (x1 to zN) as 3N values. These values can be listed on
@@ -148,8 +151,8 @@ center-of-mass position of the particle is specified by the x,y,z
values in the {Atoms} section of the data file, as is the total mass
of the body particle.
-The "pair_style body"_pair_body.html command can be used with this
-body style to compute body/body and body/non-body interactions.
+The "pair_style body/nparticle"_pair_body_nparticle.html command can be used
+with this body style to compute body/body and body/non-body interactions.
For output purposes via the "compute
body/local"_compute_body_local.html and "dump local"_dump.html
@@ -175,15 +178,18 @@ The {bflag2} argument is ignored.
[Specifics of body style rounded/polygon:]
-NOTE: Aug 2016 - This body style has not yet been added to LAMMPS.
-The info below is a placeholder.
+The {rounded/polygon} body style represents body particles as a 2d
+polygon with a variable number of N vertices. This style can only be
+used for 2d models; see the "boundary"_boundary.html command. See the
+"pair_style body/rounded/polygon" doc page for a diagram of two
+squares with rounded circles at the vertices. Special cases for N = 1
+(circle) and N = 2 (rod with rounded ends) can also be specified.
+
+One use of this body style is for 2d discrete element models, as
+described in "Fraige"_#body-Fraige.
-The {rounded/polygon} body style represents body particles as a convex
-polygon with a variable number N > 2 of vertices, which can only be
-used for 2d models. One example use of this body style is for 2d
-discrete element models, as described in "Fraige"_#Fraige. Similar to
-body style {nparticle}, the atom_style body command for this body
-style takes two additional arguments:
+Similar to body style {nparticle}, the atom_style body command for
+this body style takes two additional arguments:
atom_style body rounded/polygon Nmin Nmax
Nmin = minimum # of vertices in any body in the system
@@ -203,17 +209,20 @@ x1 y1 z1
...
xN yN zN
i j j k k ...
-radius :pre
+diameter :pre
-N is the number of vertices in the body particle. M = 6 + 3*N + 2*N +
-1. The integer line has a single value N. The floating point line(s)
+where M = 6 + 3*N + 2*N + 1, and N is the number of vertices in the
+body particle.
+
+The integer line has a single value N. The floating point line(s)
list 6 moments of inertia followed by the coordinates of the N
-vertices (x1 to zN) as 3N values, followed by 2N vertex indices
-corresponding to the end points of the N edges, followed by a single
-radius value = the smallest circle encompassing the polygon. That
-last value is used to facilitate the body/body contact detection.
-These floating-point values can be listed on as many lines as you
-wish; see the "read_data"_read_data.html command for more details.
+vertices (x1 to zN) as 3N values (with z = 0.0 for each), followed by
+2N vertex indices corresponding to the end points of the N edges,
+followed by a single diameter value = the rounded diameter of the
+circle that surrounds each vertex. The diameter value can be different
+for each body particle. These floating-point values can be listed on
+as many lines as you wish; see the "read_data"_read_data.html command
+for more details.
The 6 moments of inertia (ixx,iyy,izz,ixy,ixz,iyz) should be the
values consistent with the current orientation of the rigid body
@@ -225,8 +234,11 @@ from the center-of-mass of the body particle. The center-of-mass
position of the particle is specified by the x,y,z values in the
{Atoms} section of the data file.
-For example, the following information would specify a square
-particles whose edge length is sqrt(2):
+For example, the following information would specify a square particle
+whose edge length is sqrt(2) and rounded diameter is 1.0. The
+orientation of the square is aligned with the xy coordinate axes which
+is consistent with the 6 moments of inertia: ixx iyy izz ixy ixz iyz =
+1 1 4 0 0 0. Note that only Izz matters in 2D simulations.
3 1 27
4
@@ -235,12 +247,178 @@ particles whose edge length is sqrt(2):
-0.7071 0.7071 0
0.7071 0.7071 0
0.7071 -0.7071 0
-0 1 1 2 2 3 3 0
+0 1
+1 2
+2 3
+3 0
1.0 :pre
+A rod in 2D, whose length is 4.0, mass 1.0, rounded at two ends
+by circles of diameter 0.5, is specified as follows:
+
+1 1 13
+2
+1 1 1.33333 0 0 0
+-2 0 0
+2 0 0
+0.5 :pre
+
+A disk, whose diameter is 3.0, mass 1.0, is specified as follows:
+
+1 1 10
+1
+1 1 4.5 0 0 0
+0 0 0
+3.0 :pre
+
The "pair_style body/rounded/polygon"_pair_body_rounded_polygon.html
command can be used with this body style to compute body/body
-interactions.
+interactions. The "fix wall/body/polygon"_fix_wall_body_polygon.html
+command can be used with this body style to compute the interaction of
+body particles with a wall.
+
+:line
+
+[Specifics of body style rounded/polyhedron:]
+
+The {rounded/polyhedron} body style represents body particles as a 3d
+polyhedron with a variable number of N vertices, E edges and F faces.
+This style can only be used for 3d models; see the
+"boundary"_boundary.html command. See the "pair_style
+body/rounded/polygon" doc page for a diagram of a two 2d squares with
+rounded circles at the vertices. A 3d cube with rounded spheres at
+the 8 vertices and 12 rounded edges would be similar. Special cases
+for N = 1 (sphere) and N = 2 (rod with rounded ends) can also be
+specified.
+
+This body style is for 3d discrete element models, as described in
+"Wang"_#body-Wang.
+
+Similar to body style {rounded/polygon}, the atom_style body command
+for this body style takes two additional arguments:
+
+atom_style body rounded/polyhedron Nmin Nmax
+Nmin = minimum # of vertices in any body in the system
+Nmax = maximum # of vertices in any body in the system :pre
+
+The Nmin and Nmax arguments are used to bound the size of data
+structures used internally by each particle.
+
+When the "read_data"_read_data.html command reads a data file for this
+body style, the following information must be provided for each entry
+in the {Bodies} section of the data file:
+
+atom-ID 3 M
+N E F
+ixx iyy izz ixy ixz iyz
+x1 y1 z1
+...
+xN yN zN
+0 1
+1 2
+2 3
+...
+0 1 2 -1
+0 2 3 -1
+...
+1 2 3 4
+diameter :pre
+
+where M = 6 + 3*N + 2*E + 4*F + 1, and N is the number of vertices in
+the body particle, E = number of edges, F = number of faces.
+
+The integer line has three values: number of vertices (N), number of
+edges (E) and number of faces (F). The floating point line(s) list 6
+moments of inertia followed by the coordinates of the N vertices (x1
+to zN) as 3N values, followed by 2N vertex indices corresponding to
+the end points of the E edges, then 4*F vertex indices defining F
+faces. The last value is the diameter value = the rounded diameter of
+the sphere that surrounds each vertex. The diameter value can be
+different for each body particle. These floating-point values can be
+listed on as many lines as you wish; see the
+"read_data"_read_data.html command for more details. Because the
+maxmimum vertices per face is hard-coded to be 4
+(i.e. quadrilaterals), faces with more than 4 vertices need to be
+split into triangles or quadrilaterals. For triangular faces, the
+last vertex index should be set to -1.
+
+The ordering of the 4 vertices within a face should follow
+the right-hand rule so that the normal vector of the face points
+outwards from the center of mass.
+
+The 6 moments of inertia (ixx,iyy,izz,ixy,ixz,iyz) should be the
+values consistent with the current orientation of the rigid body
+around its center of mass. The values are with respect to the
+simulation box XYZ axes, not with respect to the principal axes of the
+rigid body itself. LAMMPS performs the latter calculation internally.
+The coordinates of each vertex are specified as its x,y,z displacement
+from the center-of-mass of the body particle. The center-of-mass
+position of the particle is specified by the x,y,z values in the
+{Atoms} section of the data file.
+
+For example, the following information would specify a cubic particle
+whose edge length is 2.0 and rounded diameter is 0.5.
+The orientation of the cube is aligned with the xyz coordinate axes
+which is consistent with the 6 moments of inertia: ixx iyy izz ixy ixz
+iyz = 0.667 0.667 0.667 0 0 0.
+
+1 3 79
+8 12 6
+0.667 0.667 0.667 0 0 0
+1 1 1
+1 -1 1
+-1 -1 1
+-1 1 1
+1 1 -1
+1 -1 -1
+-1 -1 -1
+-1 1 -1
+0 1
+1 2
+2 3
+3 0
+4 5
+5 6
+6 7
+7 4
+0 4
+1 5
+2 6
+3 7
+0 1 2 3
+4 5 6 7
+0 1 5 4
+1 2 6 5
+2 3 7 6
+3 0 4 7
+0.5 :pre
+
+A rod in 3D, whose length is 4.0, mass 1.0 and rounded at two ends
+by circles of diameter 0.5, is specified as follows:
+
+1 1 13
+2
+0 1.33333 1.33333 0 0 0
+-2 0 0
+2 0 0
+0.5 :pre
+
+A sphere whose diameter is 3.0 and mass 1.0, is specified as follows:
+
+1 1 10
+1
+0.9 0.9 0.9 0 0 0
+0 0 0
+3.0 :pre
+
+The "pair_style
+body/rounded/polhedron"_pair_body_rounded_polyhedron.html command can
+be used with this body style to compute body/body interactions. The
+"fix wall/body/polyhedron"_fix_wall_body_polygon.html command can be
+used with this body style to compute the interaction of body particles
+with a wall.
+
+:line
For output purposes via the "compute
body/local"_compute_body_local.html and "dump local"_dump.html
@@ -257,10 +435,10 @@ the body particle itself. These values are calculated using the
current COM and orientation of the body particle.
For images created by the "dump image"_dump_image.html command, if the
-{body} keyword is set, then each body particle is drawn as a convex
-polygon consisting of N line segments. Note that the line segments
-are drawn between the N vertices, which does not correspond exactly to
-the physical extent of the body (because the "pair_style
+{body} keyword is set, then each body particle is drawn as a polygon
+consisting of N line segments. Note that the line segments are drawn
+between the N vertices, which does not correspond exactly to the
+physical extent of the body (because the "pair_style
rounded/polygon"_pair_body_rounded_polygon.html defines finite-size
spheres at those point and the line segments between the spheres are
tangent to the spheres). The drawn diameter of each line segment is
@@ -269,6 +447,10 @@ determined by the {bflag1} parameter for the {body} keyword. The
:line
-:link(Fraige)
+:link(body-Fraige)
[(Fraige)] F. Y. Fraige, P. A. Langston, A. J. Matchett, J. Dodds,
Particuology, 6, 455 (2008).
+
+:link(body-Wang)
+[(Wang)] J. Wang, H. S. Yu, P. A. Langston, F. Y. Fraige, Granular
+Matter, 13, 1 (2011).
diff --git a/doc/src/Howto_chunk.txt b/doc/src/Howto_chunk.txt
new file mode 100644
index 0000000000000000000000000000000000000000..8e52acf4b8693569bac54304bb5f2c0ffd56d0fb
--- /dev/null
+++ b/doc/src/Howto_chunk.txt
@@ -0,0 +1,166 @@
+"Higher level section"_Howto.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
+
+Use chunks to calculate system properties :h3
+
+In LAMMS, "chunks" are collections of atoms, as defined by the
+"compute chunk/atom"_compute_chunk_atom.html command, which assigns
+each atom to a chunk ID (or to no chunk at all). The number of chunks
+and the assignment of chunk IDs to atoms can be static or change over
+time. Examples of "chunks" are molecules or spatial bins or atoms
+with similar values (e.g. coordination number or potential energy).
+
+The per-atom chunk IDs can be used as input to two other kinds of
+commands, to calculate various properties of a system:
+
+"fix ave/chunk"_fix_ave_chunk.html
+any of the "compute */chunk"_compute.html commands :ul
+
+Here, each of the 3 kinds of chunk-related commands is briefly
+overviewed. Then some examples are given of how to compute different
+properties with chunk commands.
+
+Compute chunk/atom command: :h4
+
+This compute can assign atoms to chunks of various styles. Only atoms
+in the specified group and optional specified region are assigned to a
+chunk. Here are some possible chunk definitions:
+
+atoms in same molecule | chunk ID = molecule ID |
+atoms of same atom type | chunk ID = atom type |
+all atoms with same atom property (charge, radius, etc) | chunk ID = output of compute property/atom |
+atoms in same cluster | chunk ID = output of "compute cluster/atom"_compute_cluster_atom.html command |
+atoms in same spatial bin | chunk ID = bin ID |
+atoms in same rigid body | chunk ID = molecule ID used to define rigid bodies |
+atoms with similar potential energy | chunk ID = output of "compute pe/atom"_compute_pe_atom.html |
+atoms with same local defect structure | chunk ID = output of "compute centro/atom"_compute_centro_atom.html or "compute coord/atom"_compute_coord_atom.html command :tb(s=|,c=2)
+
+Note that chunk IDs are integer values, so for atom properties or
+computes that produce a floating point value, they will be truncated
+to an integer. You could also use the compute in a variable that
+scales the floating point value to spread it across multiple integers.
+
+Spatial bins can be of various kinds, e.g. 1d bins = slabs, 2d bins =
+pencils, 3d bins = boxes, spherical bins, cylindrical bins.
+
+This compute also calculates the number of chunks {Nchunk}, which is
+used by other commands to tally per-chunk data. {Nchunk} can be a
+static value or change over time (e.g. the number of clusters). The
+chunk ID for an individual atom can also be static (e.g. a molecule
+ID), or dynamic (e.g. what spatial bin an atom is in as it moves).
+
+Note that this compute allows the per-atom output of other
+"computes"_compute.html, "fixes"_fix.html, and
+"variables"_variable.html to be used to define chunk IDs for each
+atom. This means you can write your own compute or fix to output a
+per-atom quantity to use as chunk ID. See the "Modify"_Modify.html
+doc pages for info on how to do this. You can also define a "per-atom
+variable"_variable.html in the input script that uses a formula to
+generate a chunk ID for each atom.
+
+Fix ave/chunk command: :h4
+
+This fix takes the ID of a "compute
+chunk/atom"_compute_chunk_atom.html command as input. For each chunk,
+it then sums one or more specified per-atom values over the atoms in
+each chunk. The per-atom values can be any atom property, such as
+velocity, force, charge, potential energy, kinetic energy, stress,
+etc. Additional keywords are defined for per-chunk properties like
+density and temperature. More generally any per-atom value generated
+by other "computes"_compute.html, "fixes"_fix.html, and "per-atom
+variables"_variable.html, can be summed over atoms in each chunk.
+
+Similar to other averaging fixes, this fix allows the summed per-chunk
+values to be time-averaged in various ways, and output to a file. The
+fix produces a global array as output with one row of values per
+chunk.
+
+Compute */chunk commands: :h4
+
+Currently the following computes operate on chunks of atoms to produce
+per-chunk values.
+
+"compute com/chunk"_compute_com_chunk.html
+"compute gyration/chunk"_compute_gyration_chunk.html
+"compute inertia/chunk"_compute_inertia_chunk.html
+"compute msd/chunk"_compute_msd_chunk.html
+"compute property/chunk"_compute_property_chunk.html
+"compute temp/chunk"_compute_temp_chunk.html
+"compute torque/chunk"_compute_vcm_chunk.html
+"compute vcm/chunk"_compute_vcm_chunk.html :ul
+
+They each take the ID of a "compute
+chunk/atom"_compute_chunk_atom.html command as input. As their names
+indicate, they calculate the center-of-mass, radius of gyration,
+moments of inertia, mean-squared displacement, temperature, torque,
+and velocity of center-of-mass for each chunk of atoms. The "compute
+property/chunk"_compute_property_chunk.html command can tally the
+count of atoms in each chunk and extract other per-chunk properties.
+
+The reason these various calculations are not part of the "fix
+ave/chunk command"_fix_ave_chunk.html, is that each requires a more
+complicated operation than simply summing and averaging over per-atom
+values in each chunk. For example, many of them require calculation
+of a center of mass, which requires summing mass*position over the
+atoms and then dividing by summed mass.
+
+All of these computes produce a global vector or global array as
+output, wih one or more values per chunk. They can be used
+in various ways:
+
+As input to the "fix ave/time"_fix_ave_time.html command, which can
+write the values to a file and optionally time average them. :ulb,l
+
+As input to the "fix ave/histo"_fix_ave_histo.html command to
+histogram values across chunks. E.g. a histogram of cluster sizes or
+molecule diffusion rates. :l
+
+As input to special functions of "equal-style
+variables"_variable.html, like sum() and max(). E.g. to find the
+largest cluster or fastest diffusing molecule. :l
+:ule
+
+Example calculations with chunks :h4
+
+Here are examples using chunk commands to calculate various
+properties:
+
+(1) Average velocity in each of 1000 2d spatial bins:
+
+compute cc1 all chunk/atom bin/2d x 0.0 0.1 y lower 0.01 units reduced
+fix 1 all ave/chunk 100 10 1000 cc1 vx vy file tmp.out :pre
+
+(2) Temperature in each spatial bin, after subtracting a flow
+velocity:
+
+compute cc1 all chunk/atom bin/2d x 0.0 0.1 y lower 0.1 units reduced
+compute vbias all temp/profile 1 0 0 y 10
+fix 1 all ave/chunk 100 10 1000 cc1 temp bias vbias file tmp.out :pre
+
+(3) Center of mass of each molecule:
+
+compute cc1 all chunk/atom molecule
+compute myChunk all com/chunk cc1
+fix 1 all ave/time 100 1 100 c_myChunk\[*\] file tmp.out mode vector :pre
+
+(4) Total force on each molecule and ave/max across all molecules:
+
+compute cc1 all chunk/atom molecule
+fix 1 all ave/chunk 1000 1 1000 cc1 fx fy fz file tmp.out
+variable xave equal ave(f_1\[2\])
+variable xmax equal max(f_1\[2\])
+thermo 1000
+thermo_style custom step temp v_xave v_xmax :pre
+
+(5) Histogram of cluster sizes:
+
+compute cluster all cluster/atom 1.0
+compute cc1 all chunk/atom c_cluster compress yes
+compute size all property/chunk cc1 count
+fix 1 all ave/histo 100 1 100 0 20 20 c_size mode vector ave running beyond ignore file tmp.histo :pre
diff --git a/doc/src/Howto_coreshell.txt b/doc/src/Howto_coreshell.txt
new file mode 100644
index 0000000000000000000000000000000000000000..7503fa1ebe4a2f2dcbf8eace63fce07ee0b155a7
--- /dev/null
+++ b/doc/src/Howto_coreshell.txt
@@ -0,0 +1,253 @@
+"Higher level section"_Howto.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
+
+Adiabatic core/shell model :h3
+
+The adiabatic core-shell model by "Mitchell and
+Fincham"_#MitchellFincham is a simple method for adding polarizability
+to a system. In order to mimic the electron shell of an ion, a
+satellite particle is attached to it. This way the ions are split into
+a core and a shell where the latter is meant to react to the
+electrostatic environment inducing polarizability. See the "Howto
+polarizable"_Howto_polarizable.html doc page for a discussion of all
+the polarizable models available in LAMMPS.
+
+Technically, shells are attached to the cores by a spring force f =
+k*r where k is a parametrized spring constant and r is the distance
+between the core and the shell. The charges of the core and the shell
+add up to the ion charge, thus q(ion) = q(core) + q(shell). This
+setup introduces the ion polarizability (alpha) given by
+alpha = q(shell)^2 / k. In a
+similar fashion the mass of the ion is distributed on the core and the
+shell with the core having the larger mass.
+
+To run this model in LAMMPS, "atom_style"_atom_style.html {full} can
+be used since atom charge and bonds are needed. Each kind of
+core/shell pair requires two atom types and a bond type. The core and
+shell of a core/shell pair should be bonded to each other with a
+harmonic bond that provides the spring force. For example, a data file
+for NaCl, as found in examples/coreshell, has this format:
+
+432 atoms # core and shell atoms
+216 bonds # number of core/shell springs :pre
+
+4 atom types # 2 cores and 2 shells for Na and Cl
+2 bond types :pre
+
+0.0 24.09597 xlo xhi
+0.0 24.09597 ylo yhi
+0.0 24.09597 zlo zhi :pre
+
+Masses # core/shell mass ratio = 0.1 :pre
+
+1 20.690784 # Na core
+2 31.90500 # Cl core
+3 2.298976 # Na shell
+4 3.54500 # Cl shell :pre
+
+Atoms :pre
+
+1 1 2 1.5005 0.00000000 0.00000000 0.00000000 # core of core/shell pair 1
+2 1 4 -2.5005 0.00000000 0.00000000 0.00000000 # shell of core/shell pair 1
+3 2 1 1.5056 4.01599500 4.01599500 4.01599500 # core of core/shell pair 2
+4 2 3 -0.5056 4.01599500 4.01599500 4.01599500 # shell of core/shell pair 2
+(...) :pre
+
+Bonds # Bond topology for spring forces :pre
+
+1 2 1 2 # spring for core/shell pair 1
+2 2 3 4 # spring for core/shell pair 2
+(...) :pre
+
+Non-Coulombic (e.g. Lennard-Jones) pairwise interactions are only
+defined between the shells. Coulombic interactions are defined
+between all cores and shells. If desired, additional bonds can be
+specified between cores.
+
+The "special_bonds"_special_bonds.html command should be used to
+turn-off the Coulombic interaction within core/shell pairs, since that
+interaction is set by the bond spring. This is done using the
+"special_bonds"_special_bonds.html command with a 1-2 weight = 0.0,
+which is the default value. It needs to be considered whether one has
+to adjust the "special_bonds"_special_bonds.html weighting according
+to the molecular topology since the interactions of the shells are
+bypassed over an extra bond.
+
+Note that this core/shell implementation does not require all ions to
+be polarized. One can mix core/shell pairs and ions without a
+satellite particle if desired.
+
+Since the core/shell model permits distances of r = 0.0 between the
+core and shell, a pair style with a "cs" suffix needs to be used to
+implement a valid long-range Coulombic correction. Several such pair
+styles are provided in the CORESHELL package. See "this doc
+page"_pair_cs.html for details. All of the core/shell enabled pair
+styles require the use of a long-range Coulombic solver, as specified
+by the "kspace_style"_kspace_style.html command. Either the PPPM or
+Ewald solvers can be used.
+
+For the NaCL example problem, these pair style and bond style settings
+are used:
+
+pair_style born/coul/long/cs 20.0 20.0
+pair_coeff * * 0.0 1.000 0.00 0.00 0.00
+pair_coeff 3 3 487.0 0.23768 0.00 1.05 0.50 #Na-Na
+pair_coeff 3 4 145134.0 0.23768 0.00 6.99 8.70 #Na-Cl
+pair_coeff 4 4 405774.0 0.23768 0.00 72.40 145.40 #Cl-Cl :pre
+
+bond_style harmonic
+bond_coeff 1 63.014 0.0
+bond_coeff 2 25.724 0.0 :pre
+
+When running dynamics with the adiabatic core/shell model, the
+following issues should be considered. The relative motion of
+the core and shell particles corresponds to the polarization,
+hereby an instantaneous relaxation of the shells is approximated
+and a fast core/shell spring frequency ensures a nearly constant
+internal kinetic energy during the simulation.
+Thermostats can alter this polarization behaviour, by scaling the
+internal kinetic energy, meaning the shell will not react freely to
+its electrostatic environment.
+Therefore it is typically desirable to decouple the relative motion of
+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.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
+non-polarized ions (ions without an attached satellite particle). The
+"compute temp/cs"_compute_temp_cs.html command requires input of two
+groups, one for the core atoms, another for the shell atoms.
+Non-polarized ions which might also be included in the treated system
+should not be included into either of these groups, they are taken
+into account by the {group-ID} (2nd argument) of the compute. The
+groups can be defined using the "group {type}"_group.html command.
+Note that to perform thermostatting using this definition of
+temperature, the "fix modify temp"_fix_modify.html command should be
+used to assign the compute to the thermostat fix. Likewise the
+"thermo_modify temp"_thermo_modify.html command can be used to make
+this temperature be output for the overall system.
+
+For the NaCl example, this can be done as follows:
+
+group cores type 1 2
+group shells type 3 4
+compute CSequ all temp/cs cores shells
+fix thermoberendsen all temp/berendsen 1427 1427 0.4 # thermostat for the true physical system
+fix thermostatequ all nve # integrator as needed for the berendsen thermostat
+fix_modify thermoberendsen temp CSequ
+thermo_modify temp CSequ # output of center-of-mass derived temperature :pre
+
+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.html compute based on
+the default "temperature"_compute_temp.html and specifying it as a
+second argument in "fix modify"_fix_modify.html and
+"thermo_modify"_thermo_modify.html resulting in:
+
+(...)
+compute CSequ all temp/cs cores shells
+compute thermo_press_lmp all pressure thermo_temp # pressure for individual particles
+thermo_modify temp CSequ press thermo_press_lmp # modify thermo to regular pressure
+fix press_bar all npt temp 300 300 0.04 iso 0 0 0.4
+fix_modify press_bar temp CSequ press thermo_press_lmp # pressure modification for correct kinetic scalar :pre
+
+If "compute temp/cs"_compute_temp_cs.html is used, the decoupled
+relative motion of the core and the shell should in theory be
+stable. However numerical fluctuation can introduce a small
+momentum to the system, which is noticable over long trajectories.
+Therefore it is recommendable to use the "fix
+momentum"_fix_momentum.html command in combination with "compute
+temp/cs"_compute_temp_cs.html when equilibrating the system to
+prevent any drift.
+
+When initializing the velocities of a system with core/shell pairs, it
+is also desirable to not introduce energy into the relative motion of
+the core/shell particles, but only assign a center-of-mass velocity to
+the pairs. This can be done by using the {bias} keyword of the
+"velocity create"_velocity.html command and assigning the "compute
+temp/cs"_compute_temp_cs.html command to the {temp} keyword of the
+"velocity"_velocity.html command, e.g.
+
+velocity all create 1427 134 bias yes temp CSequ
+velocity all scale 1427 temp CSequ :pre
+
+To maintain the correct polarizability of the core/shell pairs, the
+kinetic energy of the internal motion shall remain nearly constant.
+Therefore the choice of spring force and mass ratio need to ensure
+much faster relative motion of the 2 atoms within the core/shell pair
+than their center-of-mass velocity. This allows the shells to
+effectively react instantaneously to the electrostatic environment and
+limits energy transfer to or from the core/shell oscillators.
+This fast movement also dictates the timestep that can be used.
+
+The primary literature of the adiabatic core/shell model suggests that
+the fast relative motion of the core/shell pairs only allows negligible
+energy transfer to the environment.
+The mentioned energy transfer will typically lead to a small drift
+in total energy over time. This internal energy can be monitored
+using the "compute chunk/atom"_compute_chunk_atom.html and "compute
+temp/chunk"_compute_temp_chunk.html commands. The internal kinetic
+energies of each core/shell pair can then be summed using the sum()
+special function of the "variable"_variable.html command. Or they can
+be time/averaged and output using the "fix ave/time"_fix_ave_time.html
+command. To use these commands, each core/shell pair must be defined
+as a "chunk". If each core/shell pair is defined as its own molecule,
+the molecule ID can be used to define the chunks. If cores are bonded
+to each other to form larger molecules, the chunks can be identified
+by the "fix property/atom"_fix_property_atom.html via assigning a
+core/shell ID to each atom using a special field in the data file read
+by the "read_data"_read_data.html command. This field can then be
+accessed by the "compute property/atom"_compute_property_atom.html
+command, to use as input to the "compute
+chunk/atom"_compute_chunk_atom.html command to define the core/shell
+pairs as chunks.
+
+For example if core/shell pairs are the only molecules:
+
+read_data NaCl_CS_x0.1_prop.data
+compute prop all property/atom molecule
+compute cs_chunk all chunk/atom c_prop
+compute cstherm all temp/chunk cs_chunk temp internal com yes cdof 3.0 # note the chosen degrees of freedom for the core/shell pairs
+fix ave_chunk all ave/time 10 1 10 c_cstherm file chunk.dump mode vector :pre
+
+For example if core/shell pairs and other molecules are present:
+
+fix csinfo all property/atom i_CSID # property/atom command
+read_data NaCl_CS_x0.1_prop.data fix csinfo NULL CS-Info # atom property added in the data-file
+compute prop all property/atom i_CSID
+(...) :pre
+
+The additional section in the date file would be formatted like this:
+
+CS-Info # header of additional section :pre
+
+1 1 # column 1 = atom ID, column 2 = core/shell ID
+2 1
+3 2
+4 2
+5 3
+6 3
+7 4
+8 4
+(...) :pre
+
+:line
+
+:link(MitchellFincham)
+[(Mitchell and Fincham)] Mitchell, Fincham, J Phys Condensed Matter,
+5, 1031-1038 (1993).
+
+:link(MitchellFincham2)
+[(Fincham)] Fincham, Mackrodt and Mitchell, J Phys Condensed Matter,
+6, 393-404 (1994).
diff --git a/doc/src/Howto_couple.txt b/doc/src/Howto_couple.txt
new file mode 100644
index 0000000000000000000000000000000000000000..d7b4924d8cda690ef5204f6adabab34f2fff0a7d
--- /dev/null
+++ b/doc/src/Howto_couple.txt
@@ -0,0 +1,104 @@
+"Higher level section"_Howto.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
+
+Coupling LAMMPS to other codes :h3
+
+LAMMPS is designed to allow it to be coupled to other codes. For
+example, a quantum mechanics code might compute forces on a subset of
+atoms and pass those forces to LAMMPS. Or a continuum finite element
+(FE) simulation might use atom positions as boundary conditions on FE
+nodal points, compute a FE solution, and return interpolated forces on
+MD atoms.
+
+LAMMPS can be coupled to other codes in at least 3 ways. Each has
+advantages and disadvantages, which you'll have to think about in the
+context of your application.
+
+(1) Define a new "fix"_fix.html command that calls the other code. In
+this scenario, LAMMPS is the driver code. During its timestepping,
+the fix is invoked, and can make library calls to the other code,
+which has been linked to LAMMPS as a library. This is the way the
+"POEMS"_poems package that performs constrained rigid-body motion on
+groups of atoms is hooked to LAMMPS. See the "fix
+poems"_fix_poems.html command for more details. See the
+"Modify"_Modify.html doc pages for info on how to add a new fix to
+LAMMPS.
+
+:link(poems,http://www.rpi.edu/~anderk5/lab)
+
+(2) Define a new LAMMPS command that calls the other code. This is
+conceptually similar to method (1), but in this case LAMMPS and the
+other code are on a more equal footing. Note that now the other code
+is not called during the timestepping of a LAMMPS run, but between
+runs. The LAMMPS input script can be used to alternate LAMMPS runs
+with calls to the other code, invoked via the new command. The
+"run"_run.html command facilitates this with its {every} option, which
+makes it easy to run a few steps, invoke the command, run a few steps,
+invoke the command, etc.
+
+In this scenario, the other code can be called as a library, as in
+(1), or it could be a stand-alone code, invoked by a system() call
+made by the command (assuming your parallel machine allows one or more
+processors to start up another program). In the latter case the
+stand-alone code could communicate with LAMMPS thru files that the
+command writes and reads.
+
+See the "Modify command"_Modify_command.html doc page for info on how
+to add a new command to LAMMPS.
+
+(3) Use LAMMPS as a library called by another code. In this case the
+other code is the driver and calls LAMMPS as needed. Or a wrapper
+code could link and call both LAMMPS and another code as libraries.
+Again, the "run"_run.html command has options that allow it to be
+invoked with minimal overhead (no setup or clean-up) if you wish to do
+multiple short runs, driven by another program.
+
+Examples of driver codes that call LAMMPS as a library are included in
+the examples/COUPLE directory of the LAMMPS distribution; see
+examples/COUPLE/README for more details:
+
+simple: simple driver programs in C++ and C which invoke LAMMPS as a
+library :ulb,l
+
+lammps_quest: coupling of LAMMPS and "Quest"_quest, to run classical
+MD with quantum forces calculated by a density functional code :l
+
+lammps_spparks: coupling of LAMMPS and "SPPARKS"_spparks, to couple
+a kinetic Monte Carlo model for grain growth using MD to calculate
+strain induced across grain boundaries :l
+:ule
+
+:link(quest,http://dft.sandia.gov/Quest)
+:link(spparks,http://www.sandia.gov/~sjplimp/spparks.html)
+
+The "Build basics"_Build_basics.html doc page describes how to build
+LAMMPS as a library. Once this is done, you can interface with LAMMPS
+either via C++, C, Fortran, or Python (or any other language that
+supports a vanilla C-like interface). For example, from C++ you could
+create one (or more) "instances" of LAMMPS, pass it an input script to
+process, or execute individual commands, all by invoking the correct
+class methods in LAMMPS. From C or Fortran you can make function
+calls to do the same things. See the "Python"_Python_head.html doc
+pages for a description of the Python wrapper provided with LAMMPS
+that operates through the LAMMPS library 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
+description of the interface and how to extend it for your needs.
+
+Note that the lammps_open() function that creates an instance of
+LAMMPS takes an MPI communicator as an argument. This means that
+instance of LAMMPS will run on the set of processors in the
+communicator. Thus the calling code can run LAMMPS on all or a subset
+of processors. For example, a wrapper script might decide to
+alternate between LAMMPS and another code, allowing them both to run
+on all the processors. Or it might allocate half the processors to
+LAMMPS and half to the other code and run both codes simultaneously
+before syncing them up periodically. Or it might instantiate multiple
+instances of LAMMPS to perform different calculations.
diff --git a/doc/src/Howto_diffusion.txt b/doc/src/Howto_diffusion.txt
new file mode 100644
index 0000000000000000000000000000000000000000..6c920c9bc3da9463589362805d5e46592996ffe4
--- /dev/null
+++ b/doc/src/Howto_diffusion.txt
@@ -0,0 +1,31 @@
+"Higher level section"_Howto.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
+
+Calculate diffusion coefficients :h3
+
+The diffusion coefficient D of a material can be measured in at least
+2 ways using various options in LAMMPS. See the examples/DIFFUSE
+directory for scripts that implement the 2 methods discussed here for
+a simple Lennard-Jones fluid model.
+
+The first method is to measure the mean-squared displacement (MSD) of
+the system, via the "compute msd"_compute_msd.html command. The slope
+of the MSD versus time is proportional to the diffusion coefficient.
+The instantaneous MSD values can be accumulated in a vector via the
+"fix vector"_fix_vector.html command, and a line fit to the vector to
+compute its slope via the "variable slope"_variable.html function, and
+thus extract D.
+
+The second method is to measure the velocity auto-correlation function
+(VACF) of the system, via the "compute vacf"_compute_vacf.html
+command. The time-integral of the VACF is proportional to the
+diffusion coefficient. The instantaneous VACF values can be
+accumulated in a vector via the "fix vector"_fix_vector.html command,
+and time integrated via the "variable trap"_variable.html function,
+and thus extract D.
diff --git a/doc/src/Howto_dispersion.txt b/doc/src/Howto_dispersion.txt
new file mode 100644
index 0000000000000000000000000000000000000000..8a5953d84dbf692bddb7be8b58a86a2680aea526
--- /dev/null
+++ b/doc/src/Howto_dispersion.txt
@@ -0,0 +1,108 @@
+"Higher level section"_Howto.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
+
+Long-range dispersion settings :h3
+
+The PPPM method computes interactions by splitting the pair potential
+into two parts, one of which is computed in a normal pairwise fashion,
+the so-called real-space part, and one of which is computed using the
+Fourier transform, the so called reciprocal-space or kspace part. For
+both parts, the potential is not computed exactly but is approximated.
+Thus, there is an error in both parts of the computation, the
+real-space and the kspace error. The just mentioned facts are true
+both for the PPPM for Coulomb as well as dispersion interactions. The
+deciding difference - and also the reason why the parameters for
+pppm/disp have to be selected with more care - is the impact of the
+errors on the results: The kspace error of the PPPM for Coulomb and
+dispersion interaction and the real-space error of the PPPM for
+Coulomb interaction have the character of noise. In contrast, the
+real-space error of the PPPM for dispersion has a clear physical
+interpretation: the underprediction of cohesion. As a consequence, the
+real-space error has a much stronger effect than the kspace error on
+simulation results for pppm/disp. Parameters must thus be chosen in a
+way that this error is much smaller than the kspace error.
+
+When using pppm/disp and not making any specifications on the PPPM
+parameters via the kspace modify command, parameters will be tuned
+such that the real-space error and the kspace error are equal. This
+will result in simulations that are either inaccurate or slow, both of
+which is not desirable. For selecting parameters for the pppm/disp
+that provide fast and accurate simulations, there are two approaches,
+which both have their up- and downsides.
+
+The first approach is to set desired real-space an kspace accuracies
+via the {kspace_modify force/disp/real} and {kspace_modify
+force/disp/kspace} commands. Note that the accuracies have to be
+specified in force units and are thus dependent on the chosen unit
+settings. For real units, 0.0001 and 0.002 seem to provide reasonable
+accurate and efficient computations for the real-space and kspace
+accuracies. 0.002 and 0.05 work well for most systems using lj
+units. PPPM parameters will be generated based on the desired
+accuracies. The upside of this approach is that it usually provides a
+good set of parameters and will work for both the {kspace_modify diff
+ad} and {kspace_modify diff ik} options. The downside of the method
+is that setting the PPPM parameters will take some time during the
+initialization of the simulation.
+
+The second approach is to set the parameters for the pppm/disp
+explicitly using the {kspace_modify mesh/disp}, {kspace_modify
+order/disp}, and {kspace_modify gewald/disp} commands. This approach
+requires a more experienced user who understands well the impact of
+the choice of parameters on the simulation accuracy and
+performance. This approach provides a fast initialization of the
+simulation. However, it is sensitive to errors: A combination of
+parameters that will perform well for one system might result in
+far-from-optimal conditions for other simulations. For example,
+parameters that provide accurate and fast computations for
+all-atomistic force fields can provide insufficient accuracy or
+united-atomistic force fields (which is related to that the latter
+typically have larger dispersion coefficients).
+
+To avoid inaccurate or inefficient simulations, the pppm/disp stops
+simulations with an error message if no action is taken to control the
+PPPM parameters. If the automatic parameter generation is desired and
+real-space and kspace accuracies are desired to be equal, this error
+message can be suppressed using the {kspace_modify disp/auto yes}
+command.
+
+A reasonable approach that combines the upsides of both methods is to
+make the first run using the {kspace_modify force/disp/real} and
+{kspace_modify force/disp/kspace} commands, write down the PPPM
+parameters from the outut, and specify these parameters using the
+second approach in subsequent runs (which have the same composition,
+force field, and approximately the same volume).
+
+Concerning the performance of the pppm/disp there are two more things
+to consider. The first is that when using the pppm/disp, the cutoff
+parameter does no longer affect the accuracy of the simulation
+(subject to that gewald/disp is adjusted when changing the cutoff).
+The performance can thus be increased by examining different values
+for the cutoff parameter. A lower bound for the cutoff is only set by
+the truncation error of the repulsive term of pair potentials.
+
+The second is that the mixing rule of the pair style has an impact on
+the computation time when using the pppm/disp. Fastest computations
+are achieved when using the geometric mixing rule. Using the
+arithmetic mixing rule substantially increases the computational cost.
+The computational overhead can be reduced using the {kspace_modify
+mix/disp geom} and {kspace_modify splittol} commands. The first
+command simply enforces geometric mixing of the dispersion
+coefficients in kspace computations. This introduces some error in
+the computations but will also significantly speed-up the
+simulations. The second keyword sets the accuracy with which the
+dispersion coefficients are approximated using a matrix factorization
+approach. This may result in better accuracy then using the first
+command, but will usually also not provide an equally good increase of
+efficiency.
+
+Finally, pppm/disp can also be used when no mixing rules apply.
+This can be achieved using the {kspace_modify mix/disp none} command.
+Note that the code does not check automatically whether any mixing
+rule is fulfilled. If mixing rules do not apply, the user will have
+to specify this command explicitly.
diff --git a/doc/src/Howto_drude.txt b/doc/src/Howto_drude.txt
new file mode 100644
index 0000000000000000000000000000000000000000..ebdf5f865824a365220f1a58214fd06f111dcae2
--- /dev/null
+++ b/doc/src/Howto_drude.txt
@@ -0,0 +1,77 @@
+"Higher level section"_Howto.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
+
+Drude induced dipoles :h3
+
+The thermalized Drude model represents induced dipoles by a pair of
+charges (the core atom and the Drude particle) connected by a harmonic
+spring. See the "Howto polarizable"_Howto_polarizable.html doc page
+for a discussion of all the polarizable models available in LAMMPS.
+
+The Drude model has a number of features aimed at its use in
+molecular systems ("Lamoureux and Roux"_#howto-Lamoureux):
+
+Thermostating of the additional degrees of freedom associated with the
+induced dipoles at very low temperature, in terms of the reduced
+coordinates of the Drude particles with respect to their cores. This
+makes the trajectory close to that of relaxed induced dipoles. :ulb,l
+
+Consistent definition of 1-2 to 1-4 neighbors. A core-Drude particle
+pair represents a single (polarizable) atom, so the special screening
+factors in a covalent structure should be the same for the core and
+the Drude particle. Drude particles have to inherit the 1-2, 1-3, 1-4
+special neighbor relations from their respective cores. :l
+
+Stabilization of the interactions between induced dipoles. Drude
+dipoles on covalently bonded atoms interact too strongly due to the
+short distances, so an atom may capture the Drude particle of a
+neighbor, or the induced dipoles within the same molecule may align
+too much. To avoid this, damping at short range can be done by Thole
+functions (for which there are physical grounds). This Thole damping
+is applied to the point charges composing the induced dipole (the
+charge of the Drude particle and the opposite charge on the core, not
+to the total charge of the core atom). :l,ule
+
+A detailed tutorial covering the usage of Drude induced dipoles in
+LAMMPS is on the "Howto drude2e"_Howto_drude2.html doc page.
+
+As with the core-shell model, the cores and Drude particles should
+appear in the data file as standard atoms. The same holds for the
+springs between them, which are described by standard harmonic bonds.
+The nature of the atoms (core, Drude particle or non-polarizable) is
+specified via the "fix drude"_fix_drude.html command. The special
+list of neighbors is automatically refactored to account for the
+equivalence of core and Drude particles as regards special 1-2 to 1-4
+screening. It may be necessary to use the {extra/special/per/atom}
+keyword of the "read_data"_read_data.html command. If using "fix
+shake"_fix_shake.html, make sure no Drude particle is in this fix
+group.
+
+There are two ways to thermostat the Drude particles at a low
+temperature: use either "fix langevin/drude"_fix_langevin_drude.html
+for a Langevin thermostat, or "fix
+drude/transform/*"_fix_drude_transform.html for a Nose-Hoover
+thermostat. The former requires use of the command "comm_modify vel
+yes"_comm_modify.html. The latter requires two separate integration
+fixes like {nvt} or {npt}. The correct temperatures of the reduced
+degrees of freedom can be calculated using the "compute
+temp/drude"_compute_temp_drude.html. This requires also to use the
+command {comm_modify vel yes}.
+
+Short-range damping of the induced dipole interactions can be achieved
+using Thole functions through the "pair style
+thole"_pair_thole.html in "pair_style hybrid/overlay"_pair_hybrid.html
+with a Coulomb pair style. It may be useful to use {coul/long/cs} or
+similar from the CORESHELL package if the core and Drude particle come
+too close, which can cause numerical issues.
+
+:line
+
+:link(howto-Lamoureux)
+[(Lamoureux and Roux)] G. Lamoureux, B. Roux, J. Chem. Phys 119, 3025 (2003)
diff --git a/doc/src/tutorial_drude.txt b/doc/src/Howto_drude2.txt
similarity index 99%
rename from doc/src/tutorial_drude.txt
rename to doc/src/Howto_drude2.txt
index f6e7eed40bd84cde46e30213c0a14c22244eae86..a342d4a87d1deec93cbb9820a39099aaf5fb75a6 100644
--- a/doc/src/tutorial_drude.txt
+++ b/doc/src/Howto_drude2.txt
@@ -9,7 +9,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/Howto_elastic.txt b/doc/src/Howto_elastic.txt
new file mode 100644
index 0000000000000000000000000000000000000000..68b30970ca33a84308b32bb1516081f49470367e
--- /dev/null
+++ b/doc/src/Howto_elastic.txt
@@ -0,0 +1,47 @@
+"Higher level section"_Howto.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
+
+Calculate elastic constants :h3
+
+Elastic constants characterize the stiffness of a material. The formal
+definition is provided by the linear relation that holds between the
+stress and strain tensors in the limit of infinitesimal deformation.
+In tensor notation, this is expressed as s_ij = C_ijkl * e_kl, where
+the repeated indices imply summation. s_ij are the elements of the
+symmetric stress tensor. e_kl are the elements of the symmetric strain
+tensor. C_ijkl are the elements of the fourth rank tensor of elastic
+constants. In three dimensions, this tensor has 3^4=81 elements. Using
+Voigt notation, the tensor can be written as a 6x6 matrix, where C_ij
+is now the derivative of s_i w.r.t. e_j. Because s_i is itself a
+derivative w.r.t. e_i, it follows that C_ij is also symmetric, with at
+most 7*6/2 = 21 distinct elements.
+
+At zero temperature, it is easy to estimate these derivatives by
+deforming the simulation box in one of the six directions using the
+"change_box"_change_box.html command and measuring the change in the
+stress tensor. A general-purpose script that does this is given in the
+examples/elastic directory described on the "Examples"_Examples.html
+doc page.
+
+Calculating elastic constants at finite temperature is more
+challenging, because it is necessary to run a simulation that perfoms
+time averages of differential properties. One way to do this is to
+measure the change in average stress tensor in an NVT simulations when
+the cell volume undergoes a finite deformation. In order to balance
+the systematic and statistical errors in this method, the magnitude of
+the deformation must be chosen judiciously, and care must be taken to
+fully equilibrate the deformed cell before sampling the stress
+tensor. Another approach is to sample the triclinic cell fluctuations
+that occur in an NPT simulation. This method can also be slow to
+converge and requires careful post-processing "(Shinoda)"_#Shinoda1
+
+:line
+
+:link(Shinoda1)
+[(Shinoda)] Shinoda, Shiga, and Mikami, Phys Rev B, 69, 134103 (2004).
diff --git a/doc/src/tutorial_github.txt b/doc/src/Howto_github.txt
similarity index 98%
rename from doc/src/tutorial_github.txt
rename to doc/src/Howto_github.txt
index 3e10b821aecf3b8bce1f1f9e54198720bd521ce5..720b3317f012eb3eaf3f32f65fc1542185359721 100644
--- a/doc/src/tutorial_github.txt
+++ b/doc/src/Howto_github.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -26,7 +26,7 @@ work required by the LAMMPS developers. Consequently, creating a pull
request will increase your chances to have your contribution included
and will reduce the time until the integration is complete. For more
information on the requirements to have your code included into LAMMPS
-please see "Section 10.15"_Section_modify.html#mod_15
+please see the "Modify contribute"_Modify_contribute.html doc page.
:line
@@ -124,7 +124,7 @@ unrelated feature, you should switch branches!
After everything is done, add the files to the branch and commit them:
- $ git add doc/src/tutorial_github.txt
+ $ git add doc/src/Howto_github.txt
$ git add doc/src/JPG/tutorial*.png :pre
IMPORTANT NOTE: Do not use {git commit -a} (or {git add -A}). The -a
@@ -318,7 +318,7 @@ Because the changes are OK with us, we are going to merge by clicking on
Now, since in the meantime our local text for the tutorial also changed,
we need to pull Axel's change back into our branch, and merge them:
- $ git add tutorial_github.txt
+ $ git add Howto_github.txt
$ git add JPG/tutorial_reverse_pull_request*.png
$ git commit -m "Updated text and images on reverse pull requests"
$ git pull :pre
@@ -331,7 +331,7 @@ With Axel's changes merged in and some final text updates, our feature
branch is now perfect as far as we are concerned, so we are going to
commit and push again:
- $ git add tutorial_github.txt
+ $ git add Howto_github.txt
$ git add JPG/tutorial_reverse_pull_request6.png
$ git commit -m "Merged Axel's suggestions and updated text"
$ git push git@github.com:Pakketeretet2/lammps :pre
diff --git a/doc/src/Howto_granular.txt b/doc/src/Howto_granular.txt
new file mode 100644
index 0000000000000000000000000000000000000000..758b1cebee76645f7e5c6d023cbab045269875de
--- /dev/null
+++ b/doc/src/Howto_granular.txt
@@ -0,0 +1,57 @@
+"Higher level section"_Howto.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
+
+Granular models :h3
+
+Granular system are composed of spherical particles with a diameter,
+as opposed to point particles. This means they have an angular
+velocity and torque can be imparted to them to cause them to rotate.
+
+To run a simulation of a granular model, you will want to use
+the following commands:
+
+"atom_style sphere"_atom_style.html
+"fix nve/sphere"_fix_nve_sphere.html
+"fix gravity"_fix_gravity.html :ul
+
+This compute
+
+"compute erotate/sphere"_compute_erotate_sphere.html :ul
+
+calculates rotational kinetic energy which can be "output with
+thermodynamic info"_Howto_output.html.
+
+Use one of these 3 pair potentials, which compute forces and torques
+between interacting pairs of particles:
+
+"pair_style"_pair_style.html gran/history
+"pair_style"_pair_style.html gran/no_history
+"pair_style"_pair_style.html gran/hertzian :ul
+
+These commands implement fix options specific to granular systems:
+
+"fix freeze"_fix_freeze.html
+"fix pour"_fix_pour.html
+"fix viscous"_fix_viscous.html
+"fix wall/gran"_fix_wall_gran.html :ul
+
+The fix style {freeze} zeroes both the force and torque of frozen
+atoms, and should be used for granular system instead of the fix style
+{setforce}.
+
+For computational efficiency, you can eliminate needless pairwise
+computations between frozen atoms by using this command:
+
+"neigh_modify"_neigh_modify.html exclude :ul
+
+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.html
+doc page, where 2d simulations are discussed.
diff --git a/doc/src/Howto_kappa.txt b/doc/src/Howto_kappa.txt
new file mode 100644
index 0000000000000000000000000000000000000000..b2a57ef49b82461b89a72cda29c9785297a877f0
--- /dev/null
+++ b/doc/src/Howto_kappa.txt
@@ -0,0 +1,90 @@
+"Higher level section"_Howto.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
+
+Calculate thermal conductivity :h3
+
+The thermal conductivity kappa of a material can be measured in at
+least 4 ways using various options in LAMMPS. See the examples/KAPPA
+directory for scripts that implement the 4 methods discussed here for
+a simple Lennard-Jones fluid model. Also, see the "Howto
+viscosity"_Howto_viscosity.html doc page for an analogous discussion
+for viscosity.
+
+The thermal conductivity tensor kappa is a measure of the propensity
+of a material to transmit heat energy in a diffusive manner as given
+by Fourier's law
+
+J = -kappa grad(T)
+
+where J is the heat flux in units of energy per area per time and
+grad(T) is the spatial gradient of temperature. The thermal
+conductivity thus has units of energy per distance per time per degree
+K and is often approximated as an isotropic quantity, i.e. as a
+scalar.
+
+The first method is to setup two thermostatted regions at opposite
+ends of a simulation box, or one in the middle and one at the end of a
+periodic box. By holding the two regions at different temperatures
+with a "thermostatting fix"_Howto_thermostat.html, the energy added to
+the hot region should equal the energy subtracted from the cold region
+and be proportional to the heat flux moving between the regions. See
+the papers by "Ikeshoji and Hafskjold"_#howto-Ikeshoji and
+"Wirnsberger et al"_#howto-Wirnsberger for details of this idea. Note
+that thermostatting fixes such as "fix nvt"_fix_nh.html, "fix
+langevin"_fix_langevin.html, and "fix
+temp/rescale"_fix_temp_rescale.html store the cumulative energy they
+add/subtract.
+
+Alternatively, as a second method, the "fix heat"_fix_heat.html or
+"fix ehex"_fix_ehex.html commands can be used in place of thermostats
+on each of two regions to add/subtract specified amounts of energy to
+both regions. In both cases, the resulting temperatures of the two
+regions can be monitored with the "compute temp/region" command and
+the temperature profile of the intermediate region can be monitored
+with the "fix ave/chunk"_fix_ave_chunk.html and "compute
+ke/atom"_compute_ke_atom.html commands.
+
+The third method is to perform a reverse non-equilibrium MD simulation
+using the "fix thermal/conductivity"_fix_thermal_conductivity.html
+command which implements the rNEMD algorithm of Muller-Plathe.
+Kinetic energy is swapped between atoms in two different layers of the
+simulation box. This induces a temperature gradient between the two
+layers which can be monitored with the "fix
+ave/chunk"_fix_ave_chunk.html and "compute
+ke/atom"_compute_ke_atom.html commands. The fix tallies the
+cumulative energy transfer that it performs. See the "fix
+thermal/conductivity"_fix_thermal_conductivity.html command for
+details.
+
+The fourth method is based on the Green-Kubo (GK) formula which
+relates the ensemble average of the auto-correlation of the heat flux
+to kappa. The heat flux can be calculated from the fluctuations of
+per-atom potential and kinetic energies and per-atom stress tensor in
+a steady-state equilibrated simulation. This is in contrast to the
+two preceding non-equilibrium methods, where energy flows continuously
+between hot and cold regions of the simulation box.
+
+The "compute heat/flux"_compute_heat_flux.html command can calculate
+the needed heat flux and describes how to implement the Green_Kubo
+formalism using additional LAMMPS commands, such as the "fix
+ave/correlate"_fix_ave_correlate.html command to calculate the needed
+auto-correlation. See the doc page for the "compute
+heat/flux"_compute_heat_flux.html command for an example input script
+that calculates the thermal conductivity of solid Ar via the GK
+formalism.
+
+:line
+
+:link(howto-Ikeshoji)
+[(Ikeshoji)] Ikeshoji and Hafskjold, Molecular Physics, 81, 251-261
+(1994).
+
+:link(howto-Wirnsberger)
+[(Wirnsberger)] Wirnsberger, Frenkel, and Dellago, J Chem Phys, 143, 124104
+(2015).
diff --git a/doc/src/Howto_library.txt b/doc/src/Howto_library.txt
new file mode 100644
index 0000000000000000000000000000000000000000..741078e7eb7cb74a574c0e0bada4cca4414cce89
--- /dev/null
+++ b/doc/src/Howto_library.txt
@@ -0,0 +1,207 @@
+"Higher level section"_Howto.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
+
+Library interface to LAMMPS :h3
+
+As described on the "Build basics"_Build_basics.html doc page, LAMMPS
+can be built as a library, so that it can be called by another code,
+used in a "coupled manner"_Howto_couple.html with other codes, or
+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
+functions therein have a C-style argument list, but contain C++ code
+you could write yourself in a C++ application that was invoking LAMMPS
+directly. The C++ code in the functions illustrates how to invoke
+internal LAMMPS operations. Note that LAMMPS classes are defined
+within a LAMMPS namespace (LAMMPS_NS) if you use them from another C++
+application.
+
+The examples/COUPLE and python/examples directories have example C++
+and C and Python codes which show how a driver code can link to LAMMPS
+as a library, run LAMMPS on a subset of processors, grab data from
+LAMMPS, change it, and put it back into LAMMPS.
+
+The file src/library.cpp contains the following functions for creating
+and destroying an instance of LAMMPS and sending it commands to
+execute. See the documentation in the src/library.cpp file for
+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_head.html.
+The added functions can access or change any internal LAMMPS data you
+wish.
+
+void lammps_open(int, char **, MPI_Comm, void **)
+void lammps_open_no_mpi(int, char **, void **)
+void lammps_close(void *)
+int lammps_version(void *)
+void lammps_file(void *, char *)
+char *lammps_command(void *, char *)
+void lammps_commands_list(void *, int, char **)
+void lammps_commands_string(void *, char *)
+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"_Run_options.html when LAMMPS is run in stand-alone mode
+from the command line, and a MPI communicator for LAMMPS to run under.
+It returns a ptr to the LAMMPS object that is created, and which is
+used in subsequent library calls. The lammps_open() function can be
+called multiple times, to create 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
+processors. For example, a wrapper script might decide to alternate
+between LAMMPS and another code, allowing them both to run on all the
+processors. Or it might allocate half the processors to LAMMPS and
+half to the other code and run both codes simultaneously before
+syncing them up periodically. Or it might instantiate multiple
+instances of LAMMPS to perform different calculations.
+
+The lammps_open_no_mpi() function is similar except that no MPI
+communicator is passed from the caller. Instead, MPI_COMM_WORLD is
+used to instantiate LAMMPS, and MPI is initialized if necessary.
+
+The lammps_close() function is used to shut down an instance of LAMMPS
+and free all its memory.
+
+The lammps_version() function can be used to determined the specific
+version of the underlying LAMMPS code. This is particularly useful
+when loading LAMMPS as a shared library via dlopen(). The code using
+the library interface can than use this information to adapt to
+changes to the LAMMPS command syntax between versions. The returned
+LAMMPS version code is an integer (e.g. 2 Sep 2015 results in
+20150902) that grows with every new LAMMPS version.
+
+The lammps_file(), lammps_command(), lammps_commands_list(), and
+lammps_commands_string() functions are used to pass one or more
+commands to LAMMPS to execute, the same as if they were coming from an
+input script.
+
+Via these functions, the calling code can read or generate a series of
+LAMMPS commands one or multiple at a time and pass it thru the library
+interface to setup a problem and then run it in stages. The caller
+can interleave the command function calls with operations it performs,
+calls to extract information from or set information within LAMMPS, or
+calls to another code's library.
+
+The lammps_file() function passes the filename of an input script.
+The lammps_command() function passes a single command as a string.
+The lammps_commands_list() function passes multiple commands in a
+char** list. In both lammps_command() and lammps_commands_list(),
+individual commands may or may not have a trailing newline. The
+lammps_commands_string() function passes multiple commands
+concatenated into one long string, separated by newline characters.
+In both lammps_commands_list() and lammps_commands_string(), a single
+command can be spread across multiple lines, if the last printable
+character of all but the last line is "&", the same as if the lines
+appeared in an input script.
+
+The lammps_free() function is a clean-up function to free memory that
+the library allocated previously via other function calls. See
+comments in src/library.cpp file for which other functions need this
+clean-up.
+
+The file src/library.cpp also contains these functions for extracting
+information from LAMMPS and setting value within LAMMPS. Again, see
+the documentation in the src/library.cpp file for details, including
+which quantities can be queried by name:
+
+int lammps_extract_setting(void *, char *)
+void *lammps_extract_global(void *, char *)
+void lammps_extract_box(void *, double *, double *,
+ double *, double *, double *, int *, int *)
+void *lammps_extract_atom(void *, char *)
+void *lammps_extract_compute(void *, char *, int, int)
+void *lammps_extract_fix(void *, char *, int, int, int, int)
+void *lammps_extract_variable(void *, char *, char *) :pre
+
+The extract_setting() function returns info on the size
+of data types (e.g. 32-bit or 64-bit atom IDs) used
+by the LAMMPS executable (a compile-time choice).
+
+The other extract functions return a pointer to various global or
+per-atom quantities stored in LAMMPS or to values calculated by a
+compute, fix, or variable. The pointer returned by the
+extract_global() function can be used as a permanent reference to a
+value which may change. For the extract_atom() method, see the
+extract() method in the src/atom.cpp file for a list of valid per-atom
+properties. New names could easily be added if the property you want
+is not listed. For the other extract functions, the underlying
+storage may be reallocated as LAMMPS runs, so you need to re-call the
+function to assure a current pointer or returned value(s).
+
+double lammps_get_thermo(void *, char *)
+int lammps_get_natoms(void *) :pre
+
+int lammps_set_variable(void *, char *, char *)
+void lammps_reset_box(void *, double *, double *, double, double, double) :pre
+
+The lammps_get_thermo() function returns the current value of a thermo
+keyword as a double precision value.
+
+The lammps_get_natoms() function returns the total number of atoms in
+the system and can be used by the caller to allocate memory for the
+lammps_gather_atoms() and lammps_scatter_atoms() functions.
+
+The lammps_set_variable() function can set an existing string-style
+variable to a new string value, so that subsequent LAMMPS commands can
+access the variable.
+
+The lammps_reset_box() function resets the size and shape of the
+simulation box, e.g. as part of restoring a previously extracted and
+saved state of a simulation.
+
+void lammps_gather_atoms(void *, char *, int, int, void *)
+void lammps_gather_atoms_concat(void *, char *, int, int, void *)
+void lammps_gather_atoms_subset(void *, char *, int, int, int, int *, void *)
+void lammps_scatter_atoms(void *, char *, int, int, void *)
+void lammps_scatter_atoms_subset(void *, char *, int, int, int, int *, void *) :pre
+
+void lammps_create_atoms(void *, int, tagint *, int *, double *, double *,
+ imageint *, int) :pre
+
+The gather functions collect peratom info of the requested type (atom
+coords, atom types, forces, etc) from all processors, and returns the
+same vector of values to each callling processor. The scatter
+functions do the inverse. They distribute a vector of peratom values,
+passed by all calling processors, to invididual atoms, which may be
+owned by different processos.
+
+The lammps_gather_atoms() function does this for all N atoms in the
+system, ordered by atom ID, from 1 to N. The
+lammps_gather_atoms_concat() function does it for all N atoms, but
+simply concatenates the subset of atoms owned by each processor. The
+resulting vector is not ordered by atom ID. Atom IDs can be requetsed
+by the same function if the caller needs to know the ordering. The
+lammps_gather_subset() function allows the caller to request values
+for only a subset of atoms (identified by ID).
+For all 3 gather function, per-atom image flags can be retrieved in 2 ways.
+If the count is specified as 1, they are returned
+in a packed format with all three image flags stored in a single integer.
+If the count is specified as 3, the values are unpacked into xyz flags
+by the library before returning them.
+
+The lammps_scatter_atoms() function takes a list of values for all N
+atoms in the system, ordered by atom ID, from 1 to N, and assigns
+those values to each atom in the system. The
+lammps_scatter_atoms_subset() function takes a subset of IDs as an
+argument and only scatters those values to the owning atoms.
+
+The lammps_create_atoms() function takes a list of N atoms as input
+with atom types and coords (required), an optionally atom IDs and
+velocities and image flags. It uses the coords of each atom to assign
+it as a new atom to the processor that owns it. This function is
+useful to add atoms to a simulation or (in tandem with
+lammps_reset_box()) to restore a previously extracted and saved state
+of a simulation. Additional properties for the new atoms can then be
+assigned via the lammps_scatter_atoms() or lammps_extract_atom()
+functions.
diff --git a/doc/src/manifolds.txt b/doc/src/Howto_manifold.txt
similarity index 97%
rename from doc/src/manifolds.txt
rename to doc/src/Howto_manifold.txt
index 1013d8fab68f91cb2d5113b0cde132d7fc1f4385..09a936f7d3adec5cec22b820be9e9c54a2e4dfd0 100644
--- a/doc/src/manifolds.txt
+++ b/doc/src/Howto_manifold.txt
@@ -2,11 +2,11 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
-Manifolds (surfaces) :h2
+Manifolds (surfaces) :h3
[Overview:]
diff --git a/doc/src/Howto_multiple.txt b/doc/src/Howto_multiple.txt
new file mode 100644
index 0000000000000000000000000000000000000000..9ad872fedc1890c9fc166b884a3585f56dd3a329
--- /dev/null
+++ b/doc/src/Howto_multiple.txt
@@ -0,0 +1,94 @@
+"Higher level section"_Howto.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
+
+Run multiple simulations from one input script :h3
+
+This can be done in several ways. See the documentation for
+individual commands for more details on how these examples work.
+
+If "multiple simulations" means continue a previous simulation for
+more timesteps, then you simply use the "run"_run.html command
+multiple times. For example, this script
+
+units lj
+atom_style atomic
+read_data data.lj
+run 10000
+run 10000
+run 10000
+run 10000
+run 10000 :pre
+
+would run 5 successive simulations of the same system for a total of
+50,000 timesteps.
+
+If you wish to run totally different simulations, one after the other,
+the "clear"_clear.html command can be used in between them to
+re-initialize LAMMPS. For example, this script
+
+units lj
+atom_style atomic
+read_data data.lj
+run 10000
+clear
+units lj
+atom_style atomic
+read_data data.lj.new
+run 10000 :pre
+
+would run 2 independent simulations, one after the other.
+
+For large numbers of independent simulations, you can use
+"variables"_variable.html and the "next"_next.html and
+"jump"_jump.html commands to loop over the same input script
+multiple times with different settings. For example, this
+script, named in.polymer
+
+variable d index run1 run2 run3 run4 run5 run6 run7 run8
+shell cd $d
+read_data data.polymer
+run 10000
+shell cd ..
+clear
+next d
+jump in.polymer :pre
+
+would run 8 simulations in different directories, using a data.polymer
+file in each directory. The same concept could be used to run the
+same system at 8 different temperatures, using a temperature variable
+and storing the output in different log and dump files, for example
+
+variable a loop 8
+variable t index 0.8 0.85 0.9 0.95 1.0 1.05 1.1 1.15
+log log.$a
+read data.polymer
+velocity all create $t 352839
+fix 1 all nvt $t $t 100.0
+dump 1 all atom 1000 dump.$a
+run 100000
+clear
+next t
+next a
+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"_Run_options.html.
+
+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
+replaced with {universe}-style variables, as described in the
+"variable"_variable.html command. Also, the "next t" and "next a"
+commands would need to be replaced with a single "next a t" command.
+With these modifications, the 8 simulations of each script would run
+on the 3 partitions one after the other until all were finished.
+Initially, 3 simulations would be started simultaneously, one on each
+partition. When one finished, that partition would then start
+the 4th simulation, and so forth, until all 8 were completed.
diff --git a/doc/src/Howto_nemd.txt b/doc/src/Howto_nemd.txt
new file mode 100644
index 0000000000000000000000000000000000000000..f787801c36745d934abbfb1c26462734014d1c0c
--- /dev/null
+++ b/doc/src/Howto_nemd.txt
@@ -0,0 +1,48 @@
+"Higher level section"_Howto.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
+
+NEMD simulations :h3
+
+Non-equilibrium molecular dynamics or NEMD simulations are typically
+used to measure a fluid's rheological properties such as viscosity.
+In LAMMPS, such simulations can be performed by first setting up a
+non-orthogonal simulation box (see the preceding Howto section).
+
+A shear strain can be applied to the simulation box at a desired
+strain rate by using the "fix deform"_fix_deform.html command. The
+"fix nvt/sllod"_fix_nvt_sllod.html command can be used to thermostat
+the sheared fluid and integrate the SLLOD equations of motion for the
+system. Fix nvt/sllod uses "compute
+temp/deform"_compute_temp_deform.html to compute a thermal temperature
+by subtracting out the streaming velocity of the shearing atoms. The
+velocity profile or other properties of the fluid can be monitored via
+the "fix ave/chunk"_fix_ave_chunk.html command.
+
+As discussed in the previous section on non-orthogonal simulation
+boxes, the amount of tilt or skew that can be applied is limited by
+LAMMPS for computational efficiency to be 1/2 of the parallel box
+length. However, "fix deform"_fix_deform.html can continuously strain
+a box by an arbitrary amount. As discussed in the "fix
+deform"_fix_deform.html command, when the tilt value reaches a limit,
+the box is flipped to the opposite limit which is an equivalent tiling
+of periodic space. The strain rate can then continue to change as
+before. In a long NEMD simulation these box re-shaping events may
+occur many times.
+
+In a NEMD simulation, the "remap" option of "fix
+deform"_fix_deform.html should be set to "remap v", since that is what
+"fix nvt/sllod"_fix_nvt_sllod.html assumes to generate a velocity
+profile consistent with the applied shear strain rate.
+
+An alternative method for calculating viscosities is provided via the
+"fix viscosity"_fix_viscosity.html command.
+
+NEMD simulations can also be used to measure transport properties of a fluid
+through a pore or channel. Simulations of steady-state flow can be performed
+using the "fix flow/gauss"_fix_flow_gauss.html command.
diff --git a/doc/src/Howto_output.txt b/doc/src/Howto_output.txt
new file mode 100644
index 0000000000000000000000000000000000000000..a204a3cc96c3a0f2cebdc97fbc4ac7d2b78e8420
--- /dev/null
+++ b/doc/src/Howto_output.txt
@@ -0,0 +1,307 @@
+"Higher level section"_Howto.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
+
+Output from LAMMPS (thermo, dumps, computes, fixes, variables) :h3
+
+There are four basic kinds of LAMMPS output:
+
+"Thermodynamic output"_thermo_style.html, which is a list
+of quantities printed every few timesteps to the screen and logfile. :ulb,l
+
+"Dump files"_dump.html, which contain snapshots of atoms and various
+per-atom values and are written at a specified frequency. :l
+
+Certain fixes can output user-specified quantities to files: "fix
+ave/time"_fix_ave_time.html for time averaging, "fix
+ave/chunk"_fix_ave_chunk.html for spatial or other averaging, and "fix
+print"_fix_print.html for single-line output of
+"variables"_variable.html. Fix print can also output to the
+screen. :l
+
+"Restart files"_restart.html. :l
+:ule
+
+A simulation prints one set of thermodynamic output and (optionally)
+restart files. It can generate any number of dump files and fix
+output files, depending on what "dump"_dump.html and "fix"_fix.html
+commands you specify.
+
+As discussed below, LAMMPS gives you a variety of ways to determine
+what quantities are computed and printed when the thermodynamics,
+dump, or fix commands listed above perform output. Throughout this
+discussion, note that users can also "add their own computes and fixes
+to LAMMPS"_Modify.html which can then generate values that can then be
+output with these commands.
+
+The following sub-sections discuss different LAMMPS command related
+to output and the kind of data they operate on and produce:
+
+"Global/per-atom/local data"_#global
+"Scalar/vector/array data"_#scalar
+"Thermodynamic output"_#thermo
+"Dump file output"_#dump
+"Fixes that write output files"_#fixoutput
+"Computes that process output quantities"_#computeoutput
+"Fixes that process output quantities"_#fixprocoutput
+"Computes that generate values to output"_#compute
+"Fixes that generate values to output"_#fix
+"Variables that generate values to output"_#variable
+"Summary table of output options and data flow between commands"_#table :ul
+
+Global/per-atom/local data :h4,link(global)
+
+Various output-related commands work with three different styles of
+data: global, per-atom, or local. A global datum is one or more
+system-wide values, e.g. the temperature of the system. A per-atom
+datum is one or more values per atom, e.g. the kinetic energy of each
+atom. Local datums are calculated by each processor based on the
+atoms it owns, but there may be zero or more per atom, e.g. a list of
+bond distances.
+
+Scalar/vector/array data :h4,link(scalar)
+
+Global, per-atom, and local datums can each come in three kinds: a
+single scalar value, a vector of values, or a 2d array of values. The
+doc page for a "compute" or "fix" or "variable" that generates data
+will specify both the style and kind of data it produces, e.g. a
+per-atom vector.
+
+When a quantity is accessed, as in many of the output commands
+discussed below, it can be referenced via the following bracket
+notation, where ID in this case is the ID of a compute. The leading
+"c_" would be replaced by "f_" for a fix, or "v_" for a variable:
+
+c_ID | entire scalar, vector, or array
+c_ID\[I\] | one element of vector, one column of array
+c_ID\[I\]\[J\] | one element of array :tb(s=|)
+
+In other words, using one bracket reduces the dimension of the data
+once (vector -> scalar, array -> vector). Using two brackets reduces
+the dimension twice (array -> scalar). Thus a command that uses
+scalar values as input can typically also process elements of a vector
+or array.
+
+Thermodynamic output :h4,link(thermo)
+
+The frequency and format of thermodynamic output is set by the
+"thermo"_thermo.html, "thermo_style"_thermo_style.html, and
+"thermo_modify"_thermo_modify.html commands. The
+"thermo_style"_thermo_style.html command also specifies what values
+are calculated and written out. Pre-defined keywords can be specified
+(e.g. press, etotal, etc). Three additional kinds of keywords can
+also be specified (c_ID, f_ID, v_name), where a "compute"_compute.html
+or "fix"_fix.html or "variable"_variable.html provides the value to be
+output. In each case, the compute, fix, or variable must generate
+global values for input to the "thermo_style custom"_dump.html
+command.
+
+Note that thermodynamic output values can be "extensive" or
+"intensive". The former scale with the number of atoms in the system
+(e.g. total energy), the latter do not (e.g. temperature). The
+setting for "thermo_modify norm"_thermo_modify.html determines whether
+extensive quantities are normalized or not. Computes and fixes
+produce either extensive or intensive values; see their individual doc
+pages for details. "Equal-style variables"_variable.html produce only
+intensive values; you can include a division by "natoms" in the
+formula if desired, to make an extensive calculation produce an
+intensive result.
+
+Dump file output :h4,link(dump)
+
+Dump file output is specified by the "dump"_dump.html and
+"dump_modify"_dump_modify.html commands. There are several
+pre-defined formats (dump atom, dump xtc, etc).
+
+There is also a "dump custom"_dump.html format where the user
+specifies what values are output with each atom. Pre-defined atom
+attributes can be specified (id, x, fx, etc). Three additional kinds
+of keywords can also be specified (c_ID, f_ID, v_name), where a
+"compute"_compute.html or "fix"_fix.html or "variable"_variable.html
+provides the values to be output. In each case, the compute, fix, or
+variable must generate per-atom values for input to the "dump
+custom"_dump.html command.
+
+There is also a "dump local"_dump.html format where the user specifies
+what local values to output. A pre-defined index keyword can be
+specified to enumerate the local values. Two additional kinds of
+keywords can also be specified (c_ID, f_ID), where a
+"compute"_compute.html or "fix"_fix.html or "variable"_variable.html
+provides the values to be output. In each case, the compute or fix
+must generate local values for input to the "dump local"_dump.html
+command.
+
+Fixes that write output files :h4,link(fixoutput)
+
+Several fixes take various quantities as input and can write output
+files: "fix ave/time"_fix_ave_time.html, "fix
+ave/chunk"_fix_ave_chunk.html, "fix ave/histo"_fix_ave_histo.html,
+"fix ave/correlate"_fix_ave_correlate.html, and "fix
+print"_fix_print.html.
+
+The "fix ave/time"_fix_ave_time.html command enables direct output to
+a file and/or time-averaging of global scalars or vectors. The user
+specifies one or more quantities as input. These can be global
+"compute"_compute.html values, global "fix"_fix.html values, or
+"variables"_variable.html of any style except the atom style which
+produces per-atom values. Since a variable can refer to keywords used
+by the "thermo_style custom"_thermo_style.html command (like temp or
+press) and individual per-atom values, a wide variety of quantities
+can be time averaged and/or output in this way. If the inputs are one
+or more scalar values, then the fix generate a global scalar or vector
+of output. If the inputs are one or more vector values, then the fix
+generates a global vector or array of output. The time-averaged
+output of this fix can also be used as input to other output commands.
+
+The "fix ave/chunk"_fix_ave_chunk.html command enables direct output
+to a file of chunk-averaged per-atom quantities like those output in
+dump files. Chunks can represent spatial bins or other collections of
+atoms, e.g. individual molecules. The per-atom quantities can be atom
+density (mass or number) or atom attributes such as position,
+velocity, force. They can also be per-atom quantities calculated by a
+"compute"_compute.html, by a "fix"_fix.html, or by an atom-style
+"variable"_variable.html. The chunk-averaged output of this fix can
+also be used as input to other output commands.
+
+The "fix ave/histo"_fix_ave_histo.html command enables direct output
+to a file of histogrammed quantities, which can be global or per-atom
+or local quantities. The histogram output of this fix can also be
+used as input to other output commands.
+
+The "fix ave/correlate"_fix_ave_correlate.html command enables direct
+output to a file of time-correlated quantities, which can be global
+values. The correlation matrix output of this fix can also be used as
+input to other output commands.
+
+The "fix print"_fix_print.html command can generate a line of output
+written to the screen and log file or to a separate file, periodically
+during a running simulation. The line can contain one or more
+"variable"_variable.html values for any style variable except the
+vector or atom styles). As explained above, variables themselves can
+contain references to global values generated by "thermodynamic
+keywords"_thermo_style.html, "computes"_compute.html,
+"fixes"_fix.html, or other "variables"_variable.html, or to per-atom
+values for a specific atom. Thus the "fix print"_fix_print.html
+command is a means to output a wide variety of quantities separate
+from normal thermodynamic or dump file output.
+
+Computes that process output quantities :h4,link(computeoutput)
+
+The "compute reduce"_compute_reduce.html and "compute
+reduce/region"_compute_reduce.html commands take one or more per-atom
+or local vector quantities as inputs and "reduce" them (sum, min, max,
+ave) to scalar quantities. These are produced as output values which
+can be used as input to other output commands.
+
+The "compute slice"_compute_slice.html command take one or more global
+vector or array quantities as inputs and extracts a subset of their
+values to create a new vector or array. These are produced as output
+values which can be used as input to other output commands.
+
+The "compute property/atom"_compute_property_atom.html command takes a
+list of one or more pre-defined atom attributes (id, x, fx, etc) and
+stores the values in a per-atom vector or array. These are produced
+as output values which can be used as input to other output commands.
+The list of atom attributes is the same as for the "dump
+custom"_dump.html command.
+
+The "compute property/local"_compute_property_local.html command takes
+a list of one or more pre-defined local attributes (bond info, angle
+info, etc) and stores the values in a local vector or array. These
+are produced as output values which can be used as input to other
+output commands.
+
+Fixes that process output quantities :h4,link(fixprocoutput)
+
+The "fix vector"_fix_vector.html command can create global vectors as
+output from global scalars as input, accumulating them one element at
+a time.
+
+The "fix ave/atom"_fix_ave_atom.html command performs time-averaging
+of per-atom vectors. The per-atom quantities can be atom attributes
+such as position, velocity, force. They can also be per-atom
+quantities calculated by a "compute"_compute.html, by a
+"fix"_fix.html, or by an atom-style "variable"_variable.html. The
+time-averaged per-atom output of this fix can be used as input to
+other output commands.
+
+The "fix store/state"_fix_store_state.html command can archive one or
+more per-atom attributes at a particular time, so that the old values
+can be used in a future calculation or output. The list of atom
+attributes is the same as for the "dump custom"_dump.html command,
+including per-atom quantities calculated by a "compute"_compute.html,
+by a "fix"_fix.html, or by an atom-style "variable"_variable.html.
+The output of this fix can be used as input to other output commands.
+
+Computes that generate values to output :h4,link(compute)
+
+Every "compute"_compute.html in LAMMPS produces either global or
+per-atom or local values. The values can be scalars or vectors or
+arrays of data. These values can be output using the other commands
+described in this section. The doc page for each compute command
+describes what it produces. Computes that produce per-atom or local
+values have the word "atom" or "local" in their style name. Computes
+without the word "atom" or "local" produce global values.
+
+Fixes that generate values to output :h4,link(fix)
+
+Some "fixes"_fix.html in LAMMPS produces either global or per-atom or
+local values which can be accessed by other commands. The values can
+be scalars or vectors or arrays of data. These values can be output
+using the other commands described in this section. The doc page for
+each fix command tells whether it produces any output quantities and
+describes them.
+
+Variables that generate values to output :h4,link(variable)
+
+"Variables"_variable.html defined in an input script can store one or
+more strings. But equal-style, vector-style, and atom-style or
+atomfile-style variables generate a global scalar value, global vector
+or values, or a per-atom vector, respectively, when accessed. The
+formulas used to define these variables can contain references to the
+thermodynamic keywords and to global and per-atom data generated by
+computes, fixes, and other variables. The values generated by
+variables can be used as input to and thus output by the other
+commands described in this section.
+
+Summary table of output options and data flow between commands :h4,link(table)
+
+This table summarizes the various commands that can be used for
+generating output from LAMMPS. Each command produces output data of
+some kind and/or writes data to a file. Most of the commands can take
+data from other commands as input. Thus you can link many of these
+commands together in pipeline form, where data produced by one command
+is used as input to another command and eventually written to the
+screen or to a file. Note that to hook two commands together the
+output and input data types must match, e.g. global/per-atom/local
+data and scalar/vector/array data.
+
+Also note that, as described above, when a command takes a scalar as
+input, that could be an element of a vector or array. Likewise a
+vector input could be a column of an array.
+
+Command: Input: Output:
+"thermo_style custom"_thermo_style.html: global scalars: screen, log file:
+"dump custom"_dump.html: per-atom vectors: dump file:
+"dump local"_dump.html: local vectors: dump file:
+"fix print"_fix_print.html: global scalar from variable: screen, file:
+"print"_print.html: global scalar from variable: screen:
+"computes"_compute.html: N/A: global/per-atom/local scalar/vector/array:
+"fixes"_fix.html: N/A: global/per-atom/local scalar/vector/array:
+"variables"_variable.html: global scalars and vectors, per-atom vectors: global scalar and vector, per-atom vector:
+"compute reduce"_compute_reduce.html: per-atom/local vectors: global scalar/vector:
+"compute slice"_compute_slice.html: global vectors/arrays: global vector/array:
+"compute property/atom"_compute_property_atom.html: per-atom vectors: per-atom vector/array:
+"compute property/local"_compute_property_local.html: local vectors: local vector/array:
+"fix vector"_fix_vector.html: global scalars: global vector:
+"fix ave/atom"_fix_ave_atom.html: per-atom vectors: per-atom vector/array:
+"fix ave/time"_fix_ave_time.html: global scalars/vectors: global scalar/vector/array, file:
+"fix ave/chunk"_fix_ave_chunk.html: per-atom vectors: global array, file:
+"fix ave/histo"_fix_ave_histo.html: global/per-atom/local scalars and vectors: global array, file:
+"fix ave/correlate"_fix_ave_correlate.html: global scalars: global array, file:
+"fix store/state"_fix_store_state.html: per-atom vectors: per-atom vector/array :tb(c=3,s=:)
diff --git a/doc/src/Howto_polarizable.txt b/doc/src/Howto_polarizable.txt
new file mode 100644
index 0000000000000000000000000000000000000000..b2653b117e9caed203f1a9127575278f1747fcb4
--- /dev/null
+++ b/doc/src/Howto_polarizable.txt
@@ -0,0 +1,81 @@
+"Higher level section"_Howto.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
+
+Polarizable models :h3
+
+In polarizable force fields the charge distributions in molecules and
+materials respond to their electrostatic environments. Polarizable
+systems can be simulated in LAMMPS using three methods:
+
+the fluctuating charge method, implemented in the "QEQ"_fix_qeq.html
+package, :ulb,l
+the adiabatic core-shell method, implemented in the
+"CORESHELL"_Howto_coreshell.html package, :l
+the thermalized Drude dipole method, implemented in the
+"USER-DRUDE"_Howto_drude.html package. :l,ule
+
+The fluctuating charge method calculates instantaneous charges on
+interacting atoms based on the electronegativity equalization
+principle. It is implemented in the "fix qeq"_fix_qeq.html which is
+available in several variants. It is a relatively efficient technique
+since no additional particles are introduced. This method allows for
+charge transfer between molecules or atom groups. However, because the
+charges are located at the interaction sites, off-plane components of
+polarization cannot be represented in planar molecules or atom groups.
+
+The two other methods share the same basic idea: polarizable atoms are
+split into one core atom and one satellite particle (called shell or
+Drude particle) attached to it by a harmonic spring. Both atoms bear
+a charge and they represent collectively an induced electric dipole.
+These techniques are computationally more expensive than the QEq
+method because of additional particles and bonds. These two
+charge-on-spring methods differ in certain features, with the
+core-shell model being normally used for ionic/crystalline materials,
+whereas the so-called Drude model is normally used for molecular
+systems and fluid states.
+
+The core-shell model is applicable to crystalline materials where the
+high symmetry around each site leads to stable trajectories of the
+core-shell pairs. However, bonded atoms in molecules can be so close
+that a core would interact too strongly or even capture the Drude
+particle of a neighbor. The Drude dipole model is relatively more
+complex in order to remediate this and other issues. Specifically, the
+Drude model includes specific thermostating of the core-Drude pairs
+and short-range damping of the induced dipoles.
+
+The three polarization methods can be implemented through a
+self-consistent calculation of charges or induced dipoles at each
+timestep. In the fluctuating charge scheme this is done by the matrix
+inversion method in "fix qeq/point"_fix_qeq.html, but for core-shell
+or Drude-dipoles the relaxed-dipoles technique would require an slow
+iterative procedure. These self-consistent solutions yield accurate
+trajectories since the additional degrees of freedom representing
+polarization are massless. An alternative is to attribute a mass to
+the additional degrees of freedom and perform time integration using
+an extended Lagrangian technique. For the fluctuating charge scheme
+this is done by "fix qeq/dynamic"_fix_qeq.html, and for the
+charge-on-spring models by the methods outlined in the next two
+sections. The assignment of masses to the additional degrees of
+freedom can lead to unphysical trajectories if care is not exerted in
+choosing the parameters of the polarizable models and the simulation
+conditions.
+
+In the core-shell model the vibration of the shells is kept faster
+than the ionic vibrations to mimic the fast response of the
+polarizable electrons. But in molecular systems thermalizing the
+core-Drude pairs at temperatures comparable to the rest of the
+simulation leads to several problems (kinetic energy transfer, too
+short a timestep, etc.) In order to avoid these problems the relative
+motion of the Drude particles with respect to their cores is kept
+"cold" so the vibration of the core-Drude pairs is very slow,
+approaching the self-consistent regime. In both models the
+temperature is regulated using the velocities of the center of mass of
+core+shell (or Drude) pairs, but in the Drude model the actual
+relative core-Drude particle motion is thermostated separately as
+well.
diff --git a/doc/src/tutorial_pylammps.txt b/doc/src/Howto_pylammps.txt
similarity index 95%
rename from doc/src/tutorial_pylammps.txt
rename to doc/src/Howto_pylammps.txt
index 11cddb3cbf3fa7abc4350c9fe0cfb685f19b7b47..8be4b66e78a511b404987929d247ce3836a40086 100644
--- a/doc/src/tutorial_pylammps.txt
+++ b/doc/src/Howto_pylammps.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -15,13 +15,19 @@ END_RST -->
Overview :h4
-PyLammps is a Python wrapper class which can be created on its own or use an
-existing lammps Python object. It creates a simpler, Python-like interface to
-common LAMMPS functionality. Unlike the original flat C-types interface, it
-exposes a discoverable API. It no longer requires knowledge of the underlying
-C++ code implementation. Finally, the IPyLammps wrapper builds on top of
-PyLammps and adds some additional features for IPython integration into IPython
-notebooks, e.g. for embedded visualization output from dump/image.
+PyLammps is a Python wrapper class which can be created on its own or
+use an existing lammps Python object. It creates a simpler,
+Python-like interface to common LAMMPS functionality, in contrast to
+the lammps.py wrapper on the C-style LAMMPS library interface which is
+written using Python ctypes. The lammps.py wrapper is discussed on
+the "Python library"_Python_library.html doc page.
+
+Unlike the flat ctypes interface, PyLammps exposes a discoverable API.
+It no longer requires knowledge of the underlying C++ code
+implementation. Finally, the IPyLammps wrapper builds on top of
+PyLammps and adds some additional features for IPython integration
+into IPython notebooks, e.g. for embedded visualization output from
+dump/image.
Comparison of lammps and PyLammps interfaces :h5
@@ -40,7 +46,6 @@ communication with LAMMPS is hidden from API user
shorter, more concise Python
better IPython integration, designed for quick prototyping :ul
-
Quick Start :h4
System-wide Installation :h5
diff --git a/doc/src/Howto_replica.txt b/doc/src/Howto_replica.txt
new file mode 100644
index 0000000000000000000000000000000000000000..2135e52e0e360c7b62f052b58763262d6d0d651e
--- /dev/null
+++ b/doc/src/Howto_replica.txt
@@ -0,0 +1,60 @@
+"Higher level section"_Howto.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
+
+Multi-replica simulations :h3
+
+Several commands in LAMMPS run mutli-replica simulations, meaning
+that multiple instances (replicas) of your simulation are run
+simultaneously, with small amounts of data exchanged between replicas
+periodically.
+
+These are the relevant commands:
+
+"neb"_neb.html for nudged elastic band calculations
+"prd"_prd.html for parallel replica dynamics
+"tad"_tad.html for temperature accelerated dynamics
+"temper"_temper.html for parallel tempering
+"fix pimd"_fix_pimd.html for path-integral molecular dynamics (PIMD) :ul
+
+NEB is a method for finding transition states and barrier energies.
+PRD and TAD are methods for performing accelerated dynamics to find
+and perform infrequent events. Parallel tempering or replica exchange
+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 "Build package"_Build_package.html doc page for more
+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 "Build package"_Build_package.html doc page for more
+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"_Run_options.html to launch LAMMPS on multiple partitions,
+which in this context are the same as replicas. E.g. 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"_Run_options.html to specify the input
+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
+processors. Thus the above commands could be run on a
+single-processor (or few-processor) desktop so that you can run
+a multi-replica simulation on more replicas than you have
+physical processors.
diff --git a/doc/src/Howto_restart.txt b/doc/src/Howto_restart.txt
new file mode 100644
index 0000000000000000000000000000000000000000..bc67daa78e3b9a3c2e866b8d9a748753300e6ffe
--- /dev/null
+++ b/doc/src/Howto_restart.txt
@@ -0,0 +1,97 @@
+"Higher level section"_Howto.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
+
+Restart a simulation :h3
+
+There are 3 ways to continue a long LAMMPS simulation. Multiple
+"run"_run.html commands can be used in the same input script. Each
+run will continue from where the previous run left off. Or binary
+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"_Run_options.html and read by a "read_data"_read_data.html
+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
+continue where the previous run left off. They illustrate what
+settings must be made in the new script. Details are discussed in the
+documentation for the "read_restart"_read_restart.html and
+"read_data"_read_data.html commands.
+
+Look at the {in.chain} input script provided in the {bench} directory
+of the LAMMPS distribution to see the original script that these 2
+scripts are based on. If that script had the line
+
+restart 50 tmp.restart :pre
+
+added to it, it would produce 2 binary restart files (tmp.restart.50
+and tmp.restart.100) as it ran.
+
+This script could be used to read the 1st restart file and re-run the
+last 50 timesteps:
+
+read_restart tmp.restart.50 :pre
+
+neighbor 0.4 bin
+neigh_modify every 1 delay 1 :pre
+
+fix 1 all nve
+fix 2 all langevin 1.0 1.0 10.0 904297 :pre
+
+timestep 0.012 :pre
+
+run 50 :pre
+
+Note that the following commands do not need to be repeated because
+their settings are included in the restart file: {units, atom_style,
+special_bonds, pair_style, bond_style}. However these commands do
+need to be used, since their settings are not in the restart file:
+{neighbor, fix, timestep}.
+
+If you actually use this script to perform a restarted run, you will
+notice that the thermodynamic data match at step 50 (if you also put a
+"thermo 50" command in the original script), but do not match at step
+100. This is because the "fix langevin"_fix_langevin.html command
+uses random numbers in a way that does not allow for perfect restarts.
+
+As an alternate approach, the restart file could be converted to a data
+file as follows:
+
+lmp_g++ -r tmp.restart.50 tmp.restart.data :pre
+
+Then, this script could be used to re-run the last 50 steps:
+
+units lj
+atom_style bond
+pair_style lj/cut 1.12
+pair_modify shift yes
+bond_style fene
+special_bonds 0.0 1.0 1.0 :pre
+
+read_data tmp.restart.data :pre
+
+neighbor 0.4 bin
+neigh_modify every 1 delay 1 :pre
+
+fix 1 all nve
+fix 2 all langevin 1.0 1.0 10.0 904297 :pre
+
+timestep 0.012 :pre
+
+reset_timestep 50
+run 50 :pre
+
+Note that nearly all the settings specified in the original {in.chain}
+script must be repeated, except the {pair_coeff} and {bond_coeff}
+commands since the new data file lists the force field coefficients.
+Also, the "reset_timestep"_reset_timestep.html command is used to tell
+LAMMPS the current timestep. This value is stored in restart files,
+but not in data files.
diff --git a/doc/src/Howto_spc.txt b/doc/src/Howto_spc.txt
new file mode 100644
index 0000000000000000000000000000000000000000..2cbf16547be6f318794d837d832d3651edd072be
--- /dev/null
+++ b/doc/src/Howto_spc.txt
@@ -0,0 +1,54 @@
+"Higher level section"_Howto.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
+
+SPC water model :h3
+
+The SPC water model specifies a 3-site rigid water molecule with
+charges and Lennard-Jones parameters assigned to each of the 3 atoms.
+In LAMMPS the "fix shake"_fix_shake.html command can be used to hold
+the two O-H bonds and the H-O-H angle rigid. A bond style of
+{harmonic} and an angle style of {harmonic} or {charmm} should also be
+used.
+
+These are the additional parameters (in real units) to set for O and H
+atoms and the water molecule to run a rigid SPC model.
+
+O mass = 15.9994
+H mass = 1.008
+O charge = -0.820
+H charge = 0.410
+LJ epsilon of OO = 0.1553
+LJ sigma of OO = 3.166
+LJ epsilon, sigma of OH, HH = 0.0
+r0 of OH bond = 1.0
+theta of HOH angle = 109.47 :all(b),p
+
+Note that as originally proposed, the SPC model was run with a 9
+Angstrom cutoff for both LJ and Coulommbic terms. It can also be used
+with long-range Coulombics (Ewald or PPPM in LAMMPS), without changing
+any of the parameters above, though it becomes a different model in
+that mode of usage.
+
+The SPC/E (extended) water model is the same, except
+the partial charge assignments change:
+
+O charge = -0.8476
+H charge = 0.4238 :all(b),p
+
+See the "(Berendsen)"_#howto-Berendsen reference for more details on both
+the SPC and SPC/E models.
+
+Wikipedia also has a nice article on "water
+models"_http://en.wikipedia.org/wiki/Water_model.
+
+:line
+
+:link(howto-Berendsen)
+[(Berendsen)] Berendsen, Grigera, Straatsma, J Phys Chem, 91,
+6269-6271 (1987).
diff --git a/doc/src/Howto_spherical.txt b/doc/src/Howto_spherical.txt
new file mode 100644
index 0000000000000000000000000000000000000000..1e737df655462c2fc0e1059ac7bc56ecdb120287
--- /dev/null
+++ b/doc/src/Howto_spherical.txt
@@ -0,0 +1,243 @@
+"Higher level section"_Howto.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
+
+Finite-size spherical and aspherical particles :h3
+
+Typical MD models treat atoms or particles as point masses. Sometimes
+it is desirable to have a model with finite-size particles such as
+spheroids or ellipsoids or generalized aspherical bodies. The
+difference is that such particles have a moment of inertia, rotational
+energy, and angular momentum. Rotation is induced by torque coming
+from interactions with other particles.
+
+LAMMPS has several options for running simulations with these kinds of
+particles. The following aspects are discussed in turn:
+
+atom styles
+pair potentials
+time integration
+computes, thermodynamics, and dump output
+rigid bodies composed of finite-size particles :ul
+
+Example input scripts for these kinds of models are in the body,
+colloid, dipole, ellipse, line, peri, pour, and tri directories of the
+"examples directory"_Examples.html in the LAMMPS distribution.
+
+Atom styles :h4
+
+There are several "atom styles"_atom_style.html that allow for
+definition of finite-size particles: sphere, dipole, ellipsoid, line,
+tri, peri, and body.
+
+The sphere style defines particles that are spheriods and each
+particle can have a unique diameter and mass (or density). These
+particles store an angular velocity (omega) and can be acted upon by
+torque. The "set" command can be used to modify the diameter and mass
+of individual particles, after then are created.
+
+The dipole style does not actually define finite-size particles, but
+is often used in conjunction with spherical particles, via a command
+like
+
+atom_style hybrid sphere dipole :pre
+
+This is because when dipoles interact with each other, they induce
+torques, and a particle must be finite-size (i.e. have a moment of
+inertia) in order to respond and rotate. See the "atom_style
+dipole"_atom_style.html command for details. The "set" command can be
+used to modify the orientation and length of the dipole moment of
+individual particles, after then are created.
+
+The ellipsoid style defines particles that are ellipsoids and thus can
+be aspherical. Each particle has a shape, specified by 3 diameters,
+and mass (or density). These particles store an angular momentum and
+their orientation (quaternion), and can be acted upon by torque. They
+do not store an angular velocity (omega), which can be in a different
+direction than angular momentum, rather they compute it as needed.
+The "set" command can be used to modify the diameter, orientation, and
+mass of individual particles, after then are created. It also has a
+brief explanation of what quaternions are.
+
+The line style defines line segment particles with two end points and
+a mass (or density). They can be used in 2d simulations, and they can
+be joined together to form rigid bodies which represent arbitrary
+polygons.
+
+The tri style defines triangular particles with three corner points
+and a mass (or density). They can be used in 3d simulations, and they
+can be joined together to form rigid bodies which represent arbitrary
+particles with a triangulated surface.
+
+The peri style is used with "Peridynamic models"_pair_peri.html and
+defines particles as having a volume, that is used internally in the
+"pair_style peri"_pair_peri.html potentials.
+
+The body style allows for definition of particles which can represent
+complex entities, such as surface meshes of discrete points,
+collections of sub-particles, deformable objects, etc. The body style
+is discussed in more detail on the "Howto body"_Howto_body.html doc
+page.
+
+Note that if one of these atom styles is used (or multiple styles via
+the "atom_style hybrid"_atom_style.html command), not all particles in
+the system are required to be finite-size or aspherical.
+
+For example, in the ellipsoid style, if the 3 shape parameters are set
+to the same value, the particle will be a sphere rather than an
+ellipsoid. If the 3 shape parameters are all set to 0.0 or if the
+diameter is set to 0.0, it will be a point particle. In the line or
+tri style, if the lineflag or triflag is specified as 0, then it
+will be a point particle.
+
+Some of the pair styles used to compute pairwise interactions between
+finite-size particles also compute the correct interaction with point
+particles as well, e.g. the interaction between a point particle and a
+finite-size particle or between two point particles. If necessary,
+"pair_style hybrid"_pair_hybrid.html can be used to insure the correct
+interactions are computed for the appropriate style of interactions.
+Likewise, using groups to partition particles (ellipsoids versus
+spheres versus point particles) will allow you to use the appropriate
+time integrators and temperature computations for each class of
+particles. See the doc pages for various commands for details.
+
+Also note that for "2d simulations"_dimension.html, atom styles sphere
+and ellipsoid still use 3d particles, rather than as circular disks or
+ellipses. This means they have the same moment of inertia as the 3d
+object. When temperature is computed, the correct degrees of freedom
+are used for rotation in a 2d versus 3d system.
+
+Pair potentials :h4
+
+When a system with finite-size particles is defined, the particles
+will only rotate and experience torque if the force field computes
+such interactions. These are the various "pair
+styles"_pair_style.html that generate torque:
+
+"pair_style gran/history"_pair_gran.html
+"pair_style gran/hertzian"_pair_gran.html
+"pair_style gran/no_history"_pair_gran.html
+"pair_style dipole/cut"_pair_dipole.html
+"pair_style gayberne"_pair_gayberne.html
+"pair_style resquared"_pair_resquared.html
+"pair_style brownian"_pair_brownian.html
+"pair_style lubricate"_pair_lubricate.html
+"pair_style line/lj"_pair_line_lj.html
+"pair_style tri/lj"_pair_tri_lj.html
+"pair_style body/nparticle"_pair_body_nparticle.html :ul
+
+The granular pair styles are used with spherical particles. The
+dipole pair style is used with the dipole atom style, which could be
+applied to spherical or ellipsoidal particles. The GayBerne and
+REsquared potentials require ellipsoidal particles, though they will
+also work if the 3 shape parameters are the same (a sphere). The
+Brownian and lubrication potentials are used with spherical particles.
+The line, tri, and body potentials are used with line segment,
+triangular, and body particles respectively.
+
+Time integration :h4
+
+There are several fixes that perform time integration on finite-size
+spherical particles, meaning the integrators update the rotational
+orientation and angular velocity or angular momentum of the particles:
+
+"fix nve/sphere"_fix_nve_sphere.html
+"fix nvt/sphere"_fix_nvt_sphere.html
+"fix npt/sphere"_fix_npt_sphere.html :ul
+
+Likewise, there are 3 fixes that perform time integration on
+ellipsoidal particles:
+
+"fix nve/asphere"_fix_nve_asphere.html
+"fix nvt/asphere"_fix_nvt_asphere.html
+"fix npt/asphere"_fix_npt_asphere.html :ul
+
+The advantage of these fixes is that those which thermostat the
+particles include the rotational degrees of freedom in the temperature
+calculation and thermostatting. The "fix langevin"_fix_langevin
+command can also be used with its {omgea} or {angmom} options to
+thermostat the rotational degrees of freedom for spherical or
+ellipsoidal particles. Other thermostatting fixes only operate on the
+translational kinetic energy of finite-size particles.
+
+These fixes perform constant NVE time integration on line segment,
+triangular, and body particles:
+
+"fix nve/line"_fix_nve_line.html
+"fix nve/tri"_fix_nve_tri.html
+"fix nve/body"_fix_nve_body.html :ul
+
+Note that for mixtures of point and finite-size particles, these
+integration fixes can only be used with "groups"_group.html which
+contain finite-size particles.
+
+Computes, thermodynamics, and dump output :h4
+
+There are several computes that calculate the temperature or
+rotational energy of spherical or ellipsoidal particles:
+
+"compute temp/sphere"_compute_temp_sphere.html
+"compute temp/asphere"_compute_temp_asphere.html
+"compute erotate/sphere"_compute_erotate_sphere.html
+"compute erotate/asphere"_compute_erotate_asphere.html :ul
+
+These include rotational degrees of freedom in their computation. If
+you wish the thermodynamic output of temperature or pressure to use
+one of these computes (e.g. for a system entirely composed of
+finite-size particles), then the compute can be defined and the
+"thermo_modify"_thermo_modify.html command used. Note that by default
+thermodynamic quantities will be calculated with a temperature that
+only includes translational degrees of freedom. See the
+"thermo_style"_thermo_style.html command for details.
+
+These commands can be used to output various attributes of finite-size
+particles:
+
+"dump custom"_dump.html
+"compute property/atom"_compute_property_atom.html
+"dump local"_dump.html
+"compute body/local"_compute_body_local.html :ul
+
+Attributes include the dipole moment, the angular velocity, the
+angular momentum, the quaternion, the torque, the end-point and
+corner-point coordinates (for line and tri particles), and
+sub-particle attributes of body particles.
+
+Rigid bodies composed of finite-size particles :h4
+
+The "fix rigid"_fix_rigid.html command treats a collection of
+particles as a rigid body, computes its inertia tensor, sums the total
+force and torque on the rigid body each timestep due to forces on its
+constituent particles, and integrates the motion of the rigid body.
+
+If any of the constituent particles of a rigid body are finite-size
+particles (spheres or ellipsoids or line segments or triangles), then
+their contribution to the inertia tensor of the body is different than
+if they were point particles. This means the rotational dynamics of
+the rigid body will be different. Thus a model of a dimer is
+different if the dimer consists of two point masses versus two
+spheroids, even if the two particles have the same mass. Finite-size
+particles that experience torque due to their interaction with other
+particles will also impart that torque to a rigid body they are part
+of.
+
+See the "fix rigid" command for example of complex rigid-body models
+it is possible to define in LAMMPS.
+
+Note that the "fix shake"_fix_shake.html command can also be used to
+treat 2, 3, or 4 particles as a rigid body, but it always assumes the
+particles are point masses.
+
+Also note that body particles cannot be modeled with the "fix
+rigid"_fix_rigid.html command. Body particles are treated by LAMMPS
+as single particles, though they can store internal state, such as a
+list of sub-particles. Individual body partices are typically treated
+as rigid bodies, and their motion integrated with a command like "fix
+nve/body"_fix_nve_body.html. Interactions between pairs of body
+particles are computed via a command like "pair_style
+body/nparticle"_pair_body_nparticle.html.
diff --git a/doc/src/Howto_spins.txt b/doc/src/Howto_spins.txt
new file mode 100644
index 0000000000000000000000000000000000000000..1b9adb49a5701789dafc9f86cebc23a87623411c
--- /dev/null
+++ b/doc/src/Howto_spins.txt
@@ -0,0 +1,59 @@
+"Higher level section"_Howto.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
+
+Magnetic spins :h3
+
+The magnetic spin simualtions are enabled by the SPIN package, whose
+implementation is detailed in "Tranchida"_#Tranchida7.
+
+The model representents the simulation of atomic magnetic spins coupled
+to lattice vibrations. The dynamics of those magnetic spins can be used
+to simulate a broad range a phenomena related to magneto-elasticity, or
+or to study the influence of defects on the magnetic properties of
+materials.
+
+The magnetic spins are interacting with each others and with the
+lattice via pair interactions. Typically, the magnetic exchange
+interaction can be defined using the
+"pair/spin/exchange"_pair_spin_exchange.html command. This exchange
+applies a magnetic torque to a given spin, considering the orientation
+of its neighboring spins and their relative distances.
+It also applies a force on the atoms as a function of the spin
+orientations and their associated inter-atomic distances.
+
+The command "fix precession/spin"_fix_precession_spin.html allows to
+apply a constant magnetic torque on all the spins in the system. This
+torque can be an external magnetic field (Zeeman interaction), or an
+uniaxial magnetic anisotropy.
+
+A Langevin thermostat can be applied to those magnetic spins using
+"fix langevin/spin"_fix_langevin_spin.html. Typically, this thermostat
+can be coupled to another Langevin thermostat applied to the atoms
+using "fix langevin"_fix_langevin.html in order to simulate
+thermostated spin-lattice system.
+
+The magnetic Gilbert damping can also be applied using "fix
+langevin/spin"_fix_langevin_spin.html. It allows to either dissipate
+the thermal energy of the Langevin thermostat, or to perform a
+relaxation of the magnetic configuration toward an equilibrium state.
+
+All the computed magnetic properties can be outputed by two main
+commands. The first one is "compute spin"_compute_spin.html, that
+enables to evaluate magnetic averaged quantities, such as the total
+magnetization of the system along x, y, or z, the spin temperature, or
+the magnetic energy. The second command is "compute
+property/atom"_compute_property_atom.html. It enables to output all the
+per atom magnetic quantities. Typically, the orientation of a given
+magnetic spin, or the magnetic force acting on this spin.
+
+:line
+
+:link(Tranchida7)
+[(Tranchida)] Tranchida, Plimpton, Thibaudeau and Thompson,
+arXiv preprint arXiv:1801.10233, (2018).
diff --git a/doc/src/Howto_temperature.txt b/doc/src/Howto_temperature.txt
new file mode 100644
index 0000000000000000000000000000000000000000..896cc96a403a2555b9aceb1cb7da90793d9a909a
--- /dev/null
+++ b/doc/src/Howto_temperature.txt
@@ -0,0 +1,43 @@
+"Higher level section"_Howto.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
+
+Calculate temperature :h3
+
+Temperature is computed as kinetic energy divided by some number of
+degrees of freedom (and the Boltzmann constant). Since kinetic energy
+is a function of particle velocity, there is often a need to
+distinguish between a particle's advection velocity (due to some
+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:
+
+"compute temp"_compute_temp.html
+"compute temp/sphere"_compute_temp_sphere.html
+"compute temp/asphere"_compute_temp_asphere.html
+"compute temp/com"_compute_temp_com.html
+"compute temp/deform"_compute_temp_deform.html
+"compute temp/partial"_compute_temp_partial.html
+"compute temp/profile"_compute_temp_profile.html
+"compute temp/ramp"_compute_temp_ramp.html
+"compute temp/region"_compute_temp_region.html :ul
+
+All but the first 3 calculate velocity biases directly (e.g. advection
+velocities) that are removed when computing the thermal temperature.
+"Compute temp/sphere"_compute_temp_sphere.html and "compute
+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. This allows the translational velocity of spherical or
+aspherical particles to be adjusted in prescribed ways.
diff --git a/doc/src/Howto_thermostat.txt b/doc/src/Howto_thermostat.txt
new file mode 100644
index 0000000000000000000000000000000000000000..0e2feb18699cd993abf78df4542b599431d8512a
--- /dev/null
+++ b/doc/src/Howto_thermostat.txt
@@ -0,0 +1,89 @@
+"Higher level section"_Howto.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
+
+Thermostats :h3
+
+Thermostatting means controlling the temperature of particles in an MD
+simulation. "Barostatting"_Howto_barostat.html means controlling the
+pressure. Since the pressure includes a kinetic component due to
+particle velocities, both these operations require calculation of the
+temperature. Typically a target temperature (T) and/or pressure (P)
+is specified by the user, and the thermostat or barostat attempts to
+equilibrate the system to the requested T and/or P.
+
+Thermostatting in LAMMPS is performed by "fixes"_fix.html, or in one
+case by a pair style. Several thermostatting fixes are available:
+Nose-Hoover (nvt), Berendsen, CSVR, Langevin, and direct rescaling
+(temp/rescale). Dissipative particle dynamics (DPD) thermostatting
+can be invoked via the {dpd/tstat} pair style:
+
+"fix nvt"_fix_nh.html
+"fix nvt/sphere"_fix_nvt_sphere.html
+"fix nvt/asphere"_fix_nvt_asphere.html
+"fix nvt/sllod"_fix_nvt_sllod.html
+"fix temp/berendsen"_fix_temp_berendsen.html
+"fix temp/csvr"_fix_temp_csvr.html
+"fix langevin"_fix_langevin.html
+"fix temp/rescale"_fix_temp_rescale.html
+"pair_style dpd/tstat"_pair_dpd.html :ul
+
+"Fix nvt"_fix_nh.html only thermostats the translational velocity of
+particles. "Fix nvt/sllod"_fix_nvt_sllod.html also does this, except
+that it subtracts out a velocity bias due to a deforming box and
+integrates the SLLOD equations of motion. See the "Howto
+nemd"_Howto_nemd.html doc page for further details. "Fix
+nvt/sphere"_fix_nvt_sphere.html and "fix
+nvt/asphere"_fix_nvt_asphere.html thermostat not only translation
+velocities but also rotational velocities for spherical and aspherical
+particles.
+
+DPD thermostatting alters pairwise interactions in a manner analogous
+to the per-particle thermostatting of "fix
+langevin"_fix_langevin.html.
+
+Any of the thermostatting fixes can use "temperature
+computes"_Howto_thermostat.html that remove bias which has two
+effects. First, the current calculated temperature, which is compared
+to the requested target temperature, is calculated with the velocity
+bias removed. Second, the thermostat adjusts only the thermal
+temperature component of the particle's velocities, which are the
+velocities with the bias removed. The removed bias is then added back
+to the adjusted velocities. See the doc pages for the individual
+fixes and for the "fix_modify"_fix_modify.html command for
+instructions on how to assign a temperature compute to a
+thermostatting fix. For example, you can apply a thermostat to only
+the x and z components of velocity by using it in conjunction with
+"compute temp/partial"_compute_temp_partial.html. Of you could
+thermostat only the thermal temperature of a streaming flow of
+particles without affecting the streaming velocity, by using "compute
+temp/profile"_compute_temp_profile.html.
+
+NOTE: Only the nvt fixes perform time integration, meaning they update
+the velocities and positions of particles due to forces and velocities
+respectively. The other thermostat fixes only adjust velocities; they
+do NOT perform time integration updates. Thus they should be used in
+conjunction with a constant NVE integration fix such as these:
+
+"fix nve"_fix_nve.html
+"fix nve/sphere"_fix_nve_sphere.html
+"fix nve/asphere"_fix_nve_asphere.html :ul
+
+Thermodynamic output, which can be setup via the
+"thermo_style"_thermo_style.html command, often includes temperature
+values. As explained on the doc page for the
+"thermo_style"_thermo_style.html command, the default temperature is
+setup by the thermo command itself. It is NOT the temperature
+associated with any thermostatting fix you have defined or with any
+compute you have defined that calculates a temperature. The doc pages
+for the thermostatting fixes explain the ID of the temperature compute
+they create. Thus if you want to view these temperatures, you need to
+specify them explicitly via the "thermo_style
+custom"_thermo_style.html command. Or you can use the
+"thermo_modify"_thermo_modify.html command to re-define what
+temperature compute is used for default thermodynamic output.
diff --git a/doc/src/Howto_tip3p.txt b/doc/src/Howto_tip3p.txt
new file mode 100644
index 0000000000000000000000000000000000000000..942b42aea16ea63d2541ca839646f4b77dc9c079
--- /dev/null
+++ b/doc/src/Howto_tip3p.txt
@@ -0,0 +1,69 @@
+"Higher level section"_Howto.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
+
+TIP3P water model :h3
+
+The TIP3P water model as implemented in CHARMM
+"(MacKerell)"_#howto-MacKerell specifies a 3-site rigid water molecule with
+charges and Lennard-Jones parameters assigned to each of the 3 atoms.
+In LAMMPS the "fix shake"_fix_shake.html command can be used to hold
+the two O-H bonds and the H-O-H angle rigid. A bond style of
+{harmonic} and an angle style of {harmonic} or {charmm} should also be
+used.
+
+These are the additional parameters (in real units) to set for O and H
+atoms and the water molecule to run a rigid TIP3P-CHARMM model with a
+cutoff. The K values can be used if a flexible TIP3P model (without
+fix shake) is desired. If the LJ epsilon and sigma for HH and OH are
+set to 0.0, it corresponds to the original 1983 TIP3P model
+"(Jorgensen)"_#Jorgensen1.
+
+O mass = 15.9994
+H mass = 1.008
+O charge = -0.834
+H charge = 0.417
+LJ epsilon of OO = 0.1521
+LJ sigma of OO = 3.1507
+LJ epsilon of HH = 0.0460
+LJ sigma of HH = 0.4000
+LJ epsilon of OH = 0.0836
+LJ sigma of OH = 1.7753
+K of OH bond = 450
+r0 of OH bond = 0.9572
+K of HOH angle = 55
+theta of HOH angle = 104.52 :all(b),p
+
+These are the parameters to use for TIP3P with a long-range Coulombic
+solver (e.g. Ewald or PPPM in LAMMPS), see "(Price)"_#Price1 for
+details:
+
+O mass = 15.9994
+H mass = 1.008
+O charge = -0.830
+H charge = 0.415
+LJ epsilon of OO = 0.102
+LJ sigma of OO = 3.188
+LJ epsilon, sigma of OH, HH = 0.0
+K of OH bond = 450
+r0 of OH bond = 0.9572
+K of HOH angle = 55
+theta of HOH angle = 104.52 :all(b),p
+
+Wikipedia also has a nice article on "water
+models"_http://en.wikipedia.org/wiki/Water_model.
+
+:line
+
+:link(Jorgensen1)
+[(Jorgensen)] Jorgensen, Chandrasekhar, Madura, Impey, Klein, J Chem
+Phys, 79, 926 (1983).
+
+:link(Price1)
+[(Price)] Price and Brooks, J Chem Phys, 121, 10096 (2004).
+
diff --git a/doc/src/Howto_tip4p.txt b/doc/src/Howto_tip4p.txt
new file mode 100644
index 0000000000000000000000000000000000000000..9f7f1413147e9f13e9ce21b44457502d1d95fa87
--- /dev/null
+++ b/doc/src/Howto_tip4p.txt
@@ -0,0 +1,112 @@
+"Higher level section"_Howto.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
+
+TIP4P water model :h3
+
+The four-point TIP4P rigid water model extends the traditional
+three-point TIP3P model by adding an additional site, usually
+massless, where the charge associated with the oxygen atom is placed.
+This site M is located at a fixed distance away from the oxygen along
+the bisector of the HOH bond angle. A bond style of {harmonic} and an
+angle style of {harmonic} or {charmm} should also be used.
+
+A TIP4P model is run with LAMMPS using either this command
+for a cutoff model:
+
+"pair_style lj/cut/tip4p/cut"_pair_lj.html
+
+or these two commands for a long-range model:
+
+"pair_style lj/cut/tip4p/long"_pair_lj.html
+"kspace_style pppm/tip4p"_kspace_style.html :ul
+
+For both models, the bond lengths and bond angles should be held fixed
+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)"_#Jorgensen5. Note that the OM distance is specified in
+the "pair_style"_pair_style.html command, not as part of the pair
+coefficients.
+
+O mass = 15.9994
+H mass = 1.008
+O charge = -1.040
+H charge = 0.520
+r0 of OH bond = 0.9572
+theta of HOH angle = 104.52
+OM distance = 0.15
+LJ epsilon of O-O = 0.1550
+LJ sigma of O-O = 3.1536
+LJ epsilon, sigma of OH, HH = 0.0
+Coulombic cutoff = 8.5 :all(b),p
+
+For the TIP4/Ice model (J Chem Phys, 122, 234511 (2005);
+http://dx.doi.org/10.1063/1.1931662) these values can be used:
+
+O mass = 15.9994
+H mass = 1.008
+O charge = -1.1794
+H charge = 0.5897
+r0 of OH bond = 0.9572
+theta of HOH angle = 104.52
+OM distance = 0.1577
+LJ epsilon of O-O = 0.21084
+LJ sigma of O-O = 3.1668
+LJ epsilon, sigma of OH, HH = 0.0
+Coulombic cutoff = 8.5 :all(b),p
+
+For the TIP4P/2005 model (J Chem Phys, 123, 234505 (2005);
+http://dx.doi.org/10.1063/1.2121687), these values can be used:
+
+O mass = 15.9994
+H mass = 1.008
+O charge = -1.1128
+H charge = 0.5564
+r0 of OH bond = 0.9572
+theta of HOH angle = 104.52
+OM distance = 0.1546
+LJ epsilon of O-O = 0.1852
+LJ sigma of O-O = 3.1589
+LJ epsilon, sigma of OH, HH = 0.0
+Coulombic cutoff = 8.5 :all(b),p
+
+These are the parameters to use for TIP4P with a long-range Coulombic
+solver (e.g. Ewald or PPPM in LAMMPS):
+
+O mass = 15.9994
+H mass = 1.008
+O charge = -1.0484
+H charge = 0.5242
+r0 of OH bond = 0.9572
+theta of HOH angle = 104.52
+OM distance = 0.1250
+LJ epsilon of O-O = 0.16275
+LJ sigma of O-O = 3.16435
+LJ epsilon, sigma of OH, HH = 0.0 :all(b),p
+
+Note that the when using the TIP4P pair style, the neighbor list
+cutoff for Coulomb interactions is effectively extended by a distance
+2 * (OM distance), to account for the offset distance of the
+fictitious charges on O atoms in water molecules. Thus it is
+typically best in an efficiency sense to use a LJ cutoff >= Coulomb
+cutoff + 2*(OM distance), to shrink the size of the neighbor list.
+This leads to slightly larger cost for the long-range calculation, so
+you can test the trade-off for your model. The OM distance and the LJ
+and Coulombic cutoffs are set in the "pair_style
+lj/cut/tip4p/long"_pair_lj.html command.
+
+Wikipedia also has a nice article on "water
+models"_http://en.wikipedia.org/wiki/Water_model.
+
+:line
+
+:link(Jorgensen5)
+[(Jorgensen)] Jorgensen, Chandrasekhar, Madura, Impey, Klein, J Chem
+Phys, 79, 926 (1983).
diff --git a/doc/src/Howto_triclinic.txt b/doc/src/Howto_triclinic.txt
new file mode 100644
index 0000000000000000000000000000000000000000..4b299e5ae1ecc024c3be42bbc019bc8d9550c54d
--- /dev/null
+++ b/doc/src/Howto_triclinic.txt
@@ -0,0 +1,213 @@
+"Higher level section"_Howto.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)
+
+Triclinic (non-orthogonal) simulation boxes :h3
+
+By default, LAMMPS uses an orthogonal simulation box to encompass the
+particles. The "boundary"_boundary.html command sets the boundary
+conditions of the box (periodic, non-periodic, etc). The orthogonal
+box has its "origin" at (xlo,ylo,zlo) and is defined by 3 edge vectors
+starting from the origin given by [a] = (xhi-xlo,0,0); [b] =
+(0,yhi-ylo,0); [c] = (0,0,zhi-zlo). The 6 parameters
+(xlo,xhi,ylo,yhi,zlo,zhi) are defined at the time the simulation box
+is created, e.g. by the "create_box"_create_box.html or
+"read_data"_read_data.html or "read_restart"_read_restart.html
+commands. Additionally, LAMMPS defines box size parameters lx,ly,lz
+where lx = xhi-xlo, and similarly in the y and z dimensions. The 6
+parameters, as well as lx,ly,lz, can be output via the "thermo_style
+custom"_thermo_style.html command.
+
+LAMMPS also allows simulations to be performed in triclinic
+(non-orthogonal) simulation boxes shaped as a parallelepiped with
+triclinic symmetry. The parallelepiped has its "origin" at
+(xlo,ylo,zlo) and is defined by 3 edge vectors starting from the
+origin given by [a] = (xhi-xlo,0,0); [b] = (xy,yhi-ylo,0); [c] =
+(xz,yz,zhi-zlo). {xy,xz,yz} can be 0.0 or positive or negative values
+and are called "tilt factors" because they are the amount of
+displacement applied to faces of an originally orthogonal box to
+transform it into the parallelepiped. In LAMMPS the triclinic
+simulation box edge vectors [a], [b], and [c] cannot be arbitrary
+vectors. As indicated, [a] must lie on the positive x axis. [b] must
+lie in the xy plane, with strictly positive y component. [c] may have
+any orientation with strictly positive z component. The requirement
+that [a], [b], and [c] have strictly positive x, y, and z components,
+respectively, ensures that [a], [b], and [c] form a complete
+right-handed basis. These restrictions impose no loss of generality,
+since it is possible to rotate/invert any set of 3 crystal basis
+vectors so that they conform to the restrictions.
+
+For example, assume that the 3 vectors [A],[B],[C] are the edge
+vectors of a general parallelepiped, where there is no restriction on
+[A],[B],[C] other than they form a complete right-handed basis i.e.
+[A] x [B] . [C] > 0. The equivalent LAMMPS [a],[b],[c] are a linear
+rotation of [A], [B], and [C] and can be computed as follows:
+
+:c,image(Eqs/transform.jpg)
+
+where A = | [A] | indicates the scalar length of [A]. The hat symbol (^)
+indicates the corresponding unit vector. {beta} and {gamma} are angles
+between the vectors described below. Note that by construction,
+[a], [b], and [c] have strictly positive x, y, and z components, respectively.
+If it should happen that
+[A], [B], and [C] form a left-handed basis, then the above equations
+are not valid for [c]. In this case, it is necessary
+to first apply an inversion. This can be achieved
+by interchanging two basis vectors or by changing the sign of one of them.
+
+For consistency, the same rotation/inversion applied to the basis vectors
+must also be applied to atom positions, velocities,
+and any other vector quantities.
+This can be conveniently achieved by first converting to
+fractional coordinates in the
+old basis and then converting to distance coordinates in the new basis.
+The transformation is given by the following equation:
+
+:c,image(Eqs/rotate.jpg)
+
+where {V} is the volume of the box, [X] is the original vector quantity and
+[x] is the vector in the LAMMPS basis.
+
+There is no requirement that a triclinic box be periodic in any
+dimension, though it typically should be in at least the 2nd dimension
+of the tilt (y in xy) if you want to enforce a shift in periodic
+boundary conditions across that boundary. Some commands that work
+with triclinic boxes, e.g. the "fix deform"_fix_deform.html and "fix
+npt"_fix_nh.html commands, require periodicity or non-shrink-wrap
+boundary conditions in specific dimensions. See the command doc pages
+for details.
+
+The 9 parameters (xlo,xhi,ylo,yhi,zlo,zhi,xy,xz,yz) are defined at the
+time the simulation box is created. This happens in one of 3 ways.
+If the "create_box"_create_box.html command is used with a region of
+style {prism}, then a triclinic box is setup. See the
+"region"_region.html command for details. If the
+"read_data"_read_data.html command is used to define the simulation
+box, and the header of the data file contains a line with the "xy xz
+yz" keyword, then a triclinic box is setup. See the
+"read_data"_read_data.html command for details. Finally, if the
+"read_restart"_read_restart.html command reads a restart file which
+was written from a simulation using a triclinic box, then a triclinic
+box will be setup for the restarted simulation.
+
+Note that you can define a triclinic box with all 3 tilt factors =
+0.0, so that it is initially orthogonal. This is necessary if the box
+will become non-orthogonal, e.g. due to the "fix npt"_fix_nh.html or
+"fix deform"_fix_deform.html commands. Alternatively, you can use the
+"change_box"_change_box.html command to convert a simulation box from
+orthogonal to triclinic and vice versa.
+
+As with orthogonal boxes, LAMMPS defines triclinic box size parameters
+lx,ly,lz where lx = xhi-xlo, and similarly in the y and z dimensions.
+The 9 parameters, as well as lx,ly,lz, can be output via the
+"thermo_style custom"_thermo_style.html command.
+
+To avoid extremely tilted boxes (which would be computationally
+inefficient), LAMMPS normally requires that no tilt factor can skew
+the box more than half the distance of the parallel box length, which
+is the 1st dimension in the tilt factor (x for xz). This is required
+both when the simulation box is created, e.g. via the
+"create_box"_create_box.html or "read_data"_read_data.html commands,
+as well as when the box shape changes dynamically during a simulation,
+e.g. via the "fix deform"_fix_deform.html or "fix npt"_fix_nh.html
+commands.
+
+For example, if xlo = 2 and xhi = 12, then the x box length is 10 and
+the xy tilt factor must be between -5 and 5. Similarly, both xz and
+yz must be between -(xhi-xlo)/2 and +(yhi-ylo)/2. Note that this is
+not a limitation, since if the maximum tilt factor is 5 (as in this
+example), then configurations with tilt = ..., -15, -5, 5, 15, 25,
+... are geometrically all equivalent. If the box tilt exceeds this
+limit during a dynamics run (e.g. via the "fix deform"_fix_deform.html
+command), then the box is "flipped" to an equivalent shape with a tilt
+factor within the bounds, so the run can continue. See the "fix
+deform"_fix_deform.html doc page for further details.
+
+One exception to this rule is if the 1st dimension in the tilt
+factor (x for xy) is non-periodic. In that case, the limits on the
+tilt factor are not enforced, since flipping the box in that dimension
+does not change the atom positions due to non-periodicity. In this
+mode, if you tilt the system to extreme angles, the simulation will
+simply become inefficient, due to the highly skewed simulation box.
+
+The limitation on not creating a simulation box with a tilt factor
+skewing the box more than half the distance of the parallel box length
+can be overridden via the "box"_box.html command. Setting the {tilt}
+keyword to {large} allows any tilt factors to be specified.
+
+Box flips that may occur using the "fix deform"_fix_deform.html or
+"fix npt"_fix_nh.html commands can be turned off using the {flip no}
+option with either of the commands.
+
+Note that if a simulation box has a large tilt factor, LAMMPS will run
+less efficiently, due to the large volume of communication needed to
+acquire ghost atoms around a processor's irregular-shaped sub-domain.
+For extreme values of tilt, LAMMPS may also lose atoms and generate an
+error.
+
+Triclinic crystal structures are often defined using three lattice
+constants {a}, {b}, and {c}, and three angles {alpha}, {beta} and
+{gamma}. Note that in this nomenclature, the a, b, and c lattice
+constants are the scalar lengths of the edge vectors [a], [b], and [c]
+defined above. The relationship between these 6 quantities
+(a,b,c,alpha,beta,gamma) and the LAMMPS box sizes (lx,ly,lz) =
+(xhi-xlo,yhi-ylo,zhi-zlo) and tilt factors (xy,xz,yz) is as follows:
+
+:c,image(Eqs/box.jpg)
+
+The inverse relationship can be written as follows:
+
+:c,image(Eqs/box_inverse.jpg)
+
+The values of {a}, {b}, {c} , {alpha}, {beta} , and {gamma} can be printed
+out or accessed by computes using the
+"thermo_style custom"_thermo_style.html keywords
+{cella}, {cellb}, {cellc}, {cellalpha}, {cellbeta}, {cellgamma},
+respectively.
+
+As discussed on the "dump"_dump.html command doc page, when the BOX
+BOUNDS for a snapshot is written to a dump file for a triclinic box,
+an orthogonal bounding box which encloses the triclinic simulation box
+is output, along with the 3 tilt factors (xy, xz, yz) of the triclinic
+box, formatted as follows:
+
+ITEM: BOX BOUNDS xy xz yz
+xlo_bound xhi_bound xy
+ylo_bound yhi_bound xz
+zlo_bound zhi_bound yz :pre
+
+This bounding box is convenient for many visualization programs and is
+calculated from the 9 triclinic box parameters
+(xlo,xhi,ylo,yhi,zlo,zhi,xy,xz,yz) as follows:
+
+xlo_bound = xlo + MIN(0.0,xy,xz,xy+xz)
+xhi_bound = xhi + MAX(0.0,xy,xz,xy+xz)
+ylo_bound = ylo + MIN(0.0,yz)
+yhi_bound = yhi + MAX(0.0,yz)
+zlo_bound = zlo
+zhi_bound = zhi :pre
+
+These formulas can be inverted if you need to convert the bounding box
+back into the triclinic box parameters, e.g. xlo = xlo_bound -
+MIN(0.0,xy,xz,xy+xz).
+
+One use of triclinic simulation boxes is to model solid-state crystals
+with triclinic symmetry. The "lattice"_lattice.html command can be
+used with non-orthogonal basis vectors to define a lattice that will
+tile a triclinic simulation box via the
+"create_atoms"_create_atoms.html command.
+
+A second use is to run Parinello-Rahman dynamics via the "fix
+npt"_fix_nh.html command, which will adjust the xy, xz, yz tilt
+factors to compensate for off-diagonal components of the pressure
+tensor. The analog for an "energy minimization"_minimize.html is
+the "fix box/relax"_fix_box_relax.html command.
+
+A third use is to shear a bulk solid to study the response of the
+material. The "fix deform"_fix_deform.html command can be used for
+this purpose. It allows dynamic control of the xy, xz, yz tilt
+factors as a simulation runs. This is discussed in the next section
+on non-equilibrium MD (NEMD) simulations.
diff --git a/doc/src/Howto_viscosity.txt b/doc/src/Howto_viscosity.txt
new file mode 100644
index 0000000000000000000000000000000000000000..8bcab6dd247f02de5dbb3135e67fe76cc32efb01
--- /dev/null
+++ b/doc/src/Howto_viscosity.txt
@@ -0,0 +1,133 @@
+"Higher level section"_Howto.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
+
+Calculate viscosity :h3
+
+The shear viscosity eta of a fluid can be measured in at least 5 ways
+using various options in LAMMPS. See the examples/VISCOSITY directory
+for scripts that implement the 5 methods discussed here for a simple
+Lennard-Jones fluid model. Also, see the "Howto
+kappa"_Howto_kappa.html doc page for an analogous discussion for
+thermal conductivity.
+
+Eta is a measure of the propensity of a fluid to transmit momentum in
+a direction perpendicular to the direction of velocity or momentum
+flow. Alternatively it is the resistance the fluid has to being
+sheared. It is given by
+
+J = -eta grad(Vstream)
+
+where J is the momentum flux in units of momentum per area per time.
+and grad(Vstream) is the spatial gradient of the velocity of the fluid
+moving in another direction, normal to the area through which the
+momentum flows. Viscosity thus has units of pressure-time.
+
+The first method is to perform a non-equilibrium MD (NEMD) simulation
+by shearing the simulation box via the "fix deform"_fix_deform.html
+command, and using the "fix nvt/sllod"_fix_nvt_sllod.html command to
+thermostat the fluid via the SLLOD equations of motion.
+Alternatively, as a second method, one or more moving walls can be
+used to shear the fluid in between them, again with some kind of
+thermostat that modifies only the thermal (non-shearing) components of
+velocity to prevent the fluid from heating up.
+
+In both cases, the velocity profile setup in the fluid by this
+procedure can be monitored by the "fix ave/chunk"_fix_ave_chunk.html
+command, which determines grad(Vstream) in the equation above.
+E.g. the derivative in the y-direction of the Vx component of fluid
+motion or grad(Vstream) = dVx/dy. The Pxy off-diagonal component of
+the pressure or stress tensor, as calculated by the "compute
+pressure"_compute_pressure.html command, can also be monitored, which
+is the J term in the equation above. See the "Howto
+nemd"_Howto_nemd.html doc page for details on NEMD simulations.
+
+The third method is to perform a reverse non-equilibrium MD simulation
+using the "fix viscosity"_fix_viscosity.html command which implements
+the rNEMD algorithm of Muller-Plathe. Momentum in one dimension is
+swapped between atoms in two different layers of the simulation box in
+a different dimension. This induces a velocity gradient which can be
+monitored with the "fix ave/chunk"_fix_ave_chunk.html command.
+The fix tallies the cumulative momentum transfer that it performs.
+See the "fix viscosity"_fix_viscosity.html command for details.
+
+The fourth method is based on the Green-Kubo (GK) formula which
+relates the ensemble average of the auto-correlation of the
+stress/pressure tensor to eta. This can be done in a fully
+equilibrated simulation which is in contrast to the two preceding
+non-equilibrium methods, where momentum flows continuously through the
+simulation box.
+
+Here is an example input script that calculates the viscosity of
+liquid Ar via the GK formalism:
+
+# Sample LAMMPS input script for viscosity of liquid Ar :pre
+
+units real
+variable T equal 86.4956
+variable V equal vol
+variable dt equal 4.0
+variable p equal 400 # correlation length
+variable s equal 5 # sample interval
+variable d equal $p*$s # dump interval :pre
+
+# convert from LAMMPS real units to SI :pre
+
+variable kB equal 1.3806504e-23 # \[J/K/] Boltzmann
+variable atm2Pa equal 101325.0
+variable A2m equal 1.0e-10
+variable fs2s equal 1.0e-15
+variable convert equal $\{atm2Pa\}*$\{atm2Pa\}*$\{fs2s\}*$\{A2m\}*$\{A2m\}*$\{A2m\} :pre
+
+# setup problem :pre
+
+dimension 3
+boundary p p p
+lattice fcc 5.376 orient x 1 0 0 orient y 0 1 0 orient z 0 0 1
+region box block 0 4 0 4 0 4
+create_box 1 box
+create_atoms 1 box
+mass 1 39.948
+pair_style lj/cut 13.0
+pair_coeff * * 0.2381 3.405
+timestep $\{dt\}
+thermo $d :pre
+
+# equilibration and thermalization :pre
+
+velocity all create $T 102486 mom yes rot yes dist gaussian
+fix NVT all nvt temp $T $T 10 drag 0.2
+run 8000 :pre
+
+# viscosity calculation, switch to NVE if desired :pre
+
+#unfix NVT
+#fix NVE all nve :pre
+
+reset_timestep 0
+variable pxy equal pxy
+variable pxz equal pxz
+variable pyz equal pyz
+fix SS all ave/correlate $s $p $d &
+ v_pxy v_pxz v_pyz type auto file S0St.dat ave running
+variable scale equal $\{convert\}/($\{kB\}*$T)*$V*$s*$\{dt\}
+variable v11 equal trap(f_SS\[3\])*$\{scale\}
+variable v22 equal trap(f_SS\[4\])*$\{scale\}
+variable v33 equal trap(f_SS\[5\])*$\{scale\}
+thermo_style custom step temp press v_pxy v_pxz v_pyz v_v11 v_v22 v_v33
+run 100000
+variable v equal (v_v11+v_v22+v_v33)/3.0
+variable ndens equal count(all)/vol
+print "average viscosity: $v \[Pa.s\] @ $T K, $\{ndens\} /A^3" :pre
+
+The fifth method is related to the above Green-Kubo method,
+but uses the Einstein formulation, analogous to the Einstein
+mean-square-displacement formulation for self-diffusivity. The
+time-integrated momentum fluxes play the role of Cartesian
+coordinates, whose mean-square displacement increases linearly
+with time at sufficiently long times.
diff --git a/doc/src/Howto_viz.txt b/doc/src/Howto_viz.txt
new file mode 100644
index 0000000000000000000000000000000000000000..00c329c50b1a7f5685d31b4f9a59b3affa2dcb4f
--- /dev/null
+++ b/doc/src/Howto_viz.txt
@@ -0,0 +1,40 @@
+"Higher level section"_Howto.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
+
+Visualize LAMMPS snapshots :h3
+
+LAMMPS itself does not do visualization, but snapshots from LAMMPS
+simulations can be visualized (and analyzed) in a variety of ways.
+
+Mention dump image and dump movie.
+
+LAMMPS snapshots are created by the "dump"_dump.html command which can
+create files in several formats. The native LAMMPS dump format is a
+text file (see "dump atom" or "dump custom") which can be visualized
+by several popular visualization tools. The "dump
+image"_dump_image.html and "dump movie"_dump_image.html styles can
+output internally rendered images and convert a sequence of them to a
+movie during the MD run. Several programs included with LAMMPS as
+auxiliary tools can convert between LAMMPS format files and other
+formats. See the "Tools"_Tools.html doc page for details.
+
+A Python-based toolkit distributed by our group can read native LAMMPS
+dump files, including custom dump files with additional columns of
+user-specified atom information, and convert them to various formats
+or pipe them into visualization software directly. See the "Pizza.py
+WWW site"_pizza for details. Specifically, Pizza.py can convert
+LAMMPS dump files into PDB, XYZ, "Ensight"_ensight, and VTK formats.
+Pizza.py can pipe LAMMPS dump files directly into the Raster3d and
+RasMol visualization programs. Pizza.py has tools that do interactive
+3d OpenGL visualization and one that creates SVG images of dump file
+snapshots.
+
+:link(pizza,http://www.sandia.gov/~sjplimp/pizza.html)
+:link(ensight,http://www.ensight.com)
+:link(atomeye,http://mt.seas.upenn.edu/Archive/Graphics/A)
diff --git a/doc/src/Howto_walls.txt b/doc/src/Howto_walls.txt
new file mode 100644
index 0000000000000000000000000000000000000000..75221185829cfbb3c6b4f9489ee1a3cd47764b43
--- /dev/null
+++ b/doc/src/Howto_walls.txt
@@ -0,0 +1,80 @@
+"Higher level section"_Howto.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
+
+Walls :h3
+
+Walls in an MD simulation are typically used to bound particle motion,
+i.e. to serve as a boundary condition.
+
+Walls in LAMMPS can be of rough (made of particles) or idealized
+surfaces. Ideal walls can be smooth, generating forces only in the
+normal direction, or frictional, generating forces also in the
+tangential direction.
+
+Rough walls, built of particles, can be created in various ways. The
+particles themselves can be generated like any other particle, via the
+"lattice"_lattice.html and "create_atoms"_create_atoms.html commands,
+or read in via the "read_data"_read_data.html command.
+
+Their motion can be constrained by many different commands, so that
+they do not move at all, move together as a group at constant velocity
+or in response to a net force acting on them, move in a prescribed
+fashion (e.g. rotate around a point), etc. Note that if a time
+integration fix like "fix nve"_fix_nve.html or "fix nvt"_fix_nh.html
+is not used with the group that contains wall particles, their
+positions and velocities will not be updated.
+
+"fix aveforce"_fix_aveforce.html - set force on particles to average value, so they move together
+"fix setforce"_fix_setforce.html - set force on particles to a value, e.g. 0.0
+"fix freeze"_fix_freeze.html - freeze particles for use as granular walls
+"fix nve/noforce"_fix_nve_noforce.html - advect particles by their velocity, but without force
+"fix move"_fix_move.html - prescribe motion of particles by a linear velocity, oscillation, rotation, variable :ul
+
+The "fix move"_fix_move.html command offers the most generality, since
+the motion of individual particles can be specified with
+"variable"_variable.html formula which depends on time and/or the
+particle position.
+
+For rough walls, it may be useful to turn off pairwise interactions
+between wall particles via the "neigh_modify
+exclude"_neigh_modify.html command.
+
+Rough walls can also be created by specifying frozen particles that do
+not move and do not interact with mobile particles, and then tethering
+other particles to the fixed particles, via a "bond"_bond_style.html.
+The bonded particles do interact with other mobile particles.
+
+Idealized walls can be specified via several fix commands. "Fix
+wall/gran"_fix_wall_gran.html creates frictional walls for use with
+granular particles; all the other commands create smooth walls.
+
+"fix wall/reflect"_fix_wall_reflect.html - reflective flat walls
+"fix wall/lj93"_fix_wall.html - flat walls, with Lennard-Jones 9/3 potential
+"fix wall/lj126"_fix_wall.html - flat walls, with Lennard-Jones 12/6 potential
+"fix wall/colloid"_fix_wall.html - flat walls, with "pair_style colloid"_pair_colloid.html potential
+"fix wall/harmonic"_fix_wall.html - flat walls, with repulsive harmonic spring potential
+"fix wall/region"_fix_wall_region.html - use region surface as wall
+"fix wall/gran"_fix_wall_gran.html - flat or curved walls with "pair_style granular"_pair_gran.html potential :ul
+
+The {lj93}, {lj126}, {colloid}, and {harmonic} styles all allow the
+flat walls to move with a constant velocity, or oscillate in time.
+The "fix wall/region"_fix_wall_region.html command offers the most
+generality, since the region surface is treated as a wall, and the
+geometry of the region can be a simple primitive volume (e.g. a
+sphere, or cube, or plane), or a complex volume made from the union
+and intersection of primitive volumes. "Regions"_region.html can also
+specify a volume "interior" or "exterior" to the specified primitive
+shape or {union} or {intersection}. "Regions"_region.html can also be
+"dynamic" meaning they move with constant velocity, oscillate, or
+rotate.
+
+The only frictional idealized walls currently in LAMMPS are flat or
+curved surfaces specified by the "fix wall/gran"_fix_wall_gran.html
+command. At some point we plan to allow regoin surfaces to be used as
+frictional walls, as well as triangulated surfaces.
diff --git a/doc/src/Install.txt b/doc/src/Install.txt
new file mode 100644
index 0000000000000000000000000000000000000000..0a2e870a5d7ec5762337bc4c6b30dc5f419f9481
--- /dev/null
+++ 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.
diff --git a/doc/src/Install_git.txt b/doc/src/Install_git.txt
new file mode 100644
index 0000000000000000000000000000000000000000..538fa8aff80c43c890e9dca75bcfe2adce443390
--- /dev/null
+++ 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).
diff --git a/doc/src/Install_linux.txt b/doc/src/Install_linux.txt
new file mode 100644
index 0000000000000000000000000000000000000000..cc15ac0ae0f6f4ef43f9b9fbfd0372eeae28e8e4
--- /dev/null
+++ 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.
diff --git a/doc/src/Install_mac.txt b/doc/src/Install_mac.txt
new file mode 100644
index 0000000000000000000000000000000000000000..3fcc55b8abb8ac08bda46f06e0bad0f1445e9cc9
--- /dev/null
+++ 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.
diff --git a/doc/src/Install_patch.txt b/doc/src/Install_patch.txt
new file mode 100644
index 0000000000000000000000000000000000000000..3d0b27370e1285e293f247e02c7a4fac0c24c630
--- /dev/null
+++ 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".
diff --git a/doc/src/Install_svn.txt b/doc/src/Install_svn.txt
new file mode 100644
index 0000000000000000000000000000000000000000..7a0211ab65fa39a41985e74198f7a7cdd145b0b2
--- /dev/null
+++ 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).
diff --git a/doc/src/Install_tarball.txt b/doc/src/Install_tarball.txt
new file mode 100644
index 0000000000000000000000000000000000000000..b672c5ff252143a0484cd60025549c64878b127f
--- /dev/null
+++ 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.
diff --git a/doc/src/Install_windows.txt b/doc/src/Install_windows.txt
new file mode 100644
index 0000000000000000000000000000000000000000..df87754c5fcfc84bf9f55bc99679ffe8e4b793dd
--- /dev/null
+++ 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.
diff --git a/doc/src/Intro.txt b/doc/src/Intro.txt
new file mode 100644
index 0000000000000000000000000000000000000000..c8725e0085edde75afcc8afd1ab2bd50da8b17a1
--- /dev/null
+++ b/doc/src/Intro.txt
@@ -0,0 +1,39 @@
+"Previous Section"_Manual.html - "LAMMPS WWW Site"_lws -
+"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
+Section"_Install.html :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands.html#comm)
+
+:line
+
+Introduction :h2
+
+These pages provide a brief introduction to LAMMPS.
+
+<!-- RST
+
+.. toctree::
+ :maxdepth: 1
+
+ Intro_overview
+ Manual_version
+ Intro_features
+ Intro_nonfeatures
+ Intro_opensource
+ Intro_authors
+ Intro_website
+
+END_RST -->
+
+<!-- HTML_ONLY -->
+
+"Overview of LAMMPS"_Intro_overview.html
+"LAMMPS features"_Intro_features.html
+"LAMMPS non-features"_Intro_nonfeatures.html
+"LAMMPS open-source license"_Intro_license.html
+"LAMMPS authors"_Intro_authors.html
+"Additional website links"_Intro_website.html :all(b)
+
+<!-- END_HTML_ONLY -->
diff --git a/doc/src/Intro_authors.txt b/doc/src/Intro_authors.txt
new file mode 100644
index 0000000000000000000000000000000000000000..b909265a3eebc70abdcbbb8a439fa319589a8346
--- /dev/null
+++ b/doc/src/Intro_authors.txt
@@ -0,0 +1,66 @@
+"Higher level section"_Intro.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
+
+Authors of LAMMPS :h3
+
+The primary LAMMPS developers are at Sandia National Labs and Temple
+University:
+
+"Steve Plimpton"_sjp, sjplimp at sandia.gov
+Aidan Thompson, athomps at sandia.gov
+Stan Moore, stamoor at sandia.gov
+Axel Kohlmeyer, akohlmey at gmail.com
+Richard Berger, richard.berger at temple.edu :ul
+
+:link(sjp,http://www.cs.sandia.gov/~sjplimp)
+
+Past developers include Paul Crozier and Mark Stevens, both at Sandia,
+and Ray Shan, now at Materials Design.
+
+:line
+
+The "Authors page"_http://lammps.sandia.gov/authors.html of the
+"LAMMPS website"_lws has a comprehensive list of all the individuals
+who have contributed code for a new feature or command or tool to
+LAMMPS.
+
+:line
+
+The following folks deserve special recognition. Many of the packages
+they have written are unique for an MD code and LAMMPS would not be as
+general-purpose as it is without their expertise and efforts.
+
+Metin Aktulga (MSU), USER-REAXC package for C version of ReaxFF
+Mike Brown (Intel), GPU and USER-INTEL packages
+Colin Denniston (U Western Ontario), USER-LB package
+Georg Ganzenmuller (EMI), USER-SMD and USER-SPH packages
+Andres Jaramillo-Botero (Caltech), USER-EFF package for electron force field
+Reese Jones (Sandia) and colleagues, USER-ATC package for atom/continuum coupling
+Christoph Kloss (DCS Computing), LIGGGHTS code for granular materials, built on top of LAMMPS
+Rudra Mukherjee (JPL), POEMS package for articulated rigid body motion
+Trung Ngyuen (Northwestern U), GPU and RIGID and BODY packages
+Mike Parks (Sandia), PERI package for Peridynamics
+Roy Pollock (LLNL), Ewald and PPPM solvers
+Christian Trott (Sandia), USER-CUDA and KOKKOS packages
+Ilya Valuev (JIHT), USER-AWPMD package for wave-packet MD
+Greg Wagner (Northwestern U), MEAM package for MEAM potential :ul
+
+:line
+
+As discussed on the "History
+page"_http://lammps.sandia.gov/history.html of the website, LAMMPS
+originated as a cooperative project between DOE labs and industrial
+partners. Folks involved in the design and testing of the original
+version of LAMMPS were the following:
+
+John Carpenter (Mayo Clinic, formerly at Cray Research)
+Terry Stouch (Lexicon Pharmaceuticals, formerly at Bristol Myers Squibb)
+Steve Lustig (Dupont)
+Jim Belak and Roy Pollock (LLNL) :ul
+
diff --git a/doc/src/Intro_features.txt b/doc/src/Intro_features.txt
new file mode 100644
index 0000000000000000000000000000000000000000..07c549c1566a73c09d66b92b590c87d5654773d5
--- /dev/null
+++ b/doc/src/Intro_features.txt
@@ -0,0 +1,202 @@
+"Higher level section"_Intro.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
+
+LAMMPS features :h3
+
+LAMMPS is a classical molecular dynamics (MD) code with these general
+classes of functionality:
+
+"General features"_#general
+"Particle and model types"_#particle
+"Interatomic potentials (force fields)"_#ff
+"Atom creation"_#create
+"Ensembles, constraints, and boundary conditions"_#ensemble
+"Integrators"_#integrate
+"Diagnostics"_#diag
+"Output"_#output
+"Multi-replica models"_#replica1
+"Pre- and post-processing"_#prepost
+"Specialized features (beyond MD itself)"_#special :ul
+
+:line
+
+General features :h4,link(general)
+
+ runs on a single processor or in parallel
+ distributed-memory message-passing parallelism (MPI)
+ spatial-decomposition of simulation domain for parallelism
+ open-source distribution
+ highly portable C++
+ optional libraries used: MPI and single-processor FFT
+ GPU (CUDA and OpenCL), Intel Xeon Phi, and OpenMP support for many code features
+ easy to extend with new features and functionality
+ runs from an input script
+ syntax for defining and using variables and formulas
+ syntax for looping over runs and breaking out of loops
+ run one or multiple simulations simultaneously (in parallel) from one script
+ build as library, invoke LAMMPS thru library interface or provided Python wrapper
+ couple with other codes: LAMMPS calls other code, other code calls LAMMPS, umbrella code calls both :ul
+
+Particle and model types :h4,link(particle)
+("atom style"_atom_style.html command)
+
+ atoms
+ coarse-grained particles (e.g. bead-spring polymers)
+ united-atom polymers or organic molecules
+ all-atom polymers, organic molecules, proteins, DNA
+ metals
+ granular materials
+ coarse-grained mesoscale models
+ finite-size spherical and ellipsoidal particles
+ finite-size line segment (2d) and triangle (3d) particles
+ point dipole particles
+ rigid collections of particles
+ hybrid combinations of these :ul
+
+Interatomic potentials (force fields) :h4,link(ff)
+("pair style"_pair_style.html, "bond style"_bond_style.html,
+"angle style"_angle_style.html, "dihedral style"_dihedral_style.html,
+"improper style"_improper_style.html, "kspace style"_kspace_style.html
+commands)
+
+ pairwise potentials: Lennard-Jones, Buckingham, Morse, Born-Mayer-Huggins, \
+ Yukawa, soft, class 2 (COMPASS), hydrogen bond, tabulated
+ charged pairwise potentials: Coulombic, point-dipole
+ manybody potentials: EAM, Finnis/Sinclair EAM, modified EAM (MEAM), \
+ embedded ion method (EIM), EDIP, ADP, Stillinger-Weber, Tersoff, \
+ REBO, AIREBO, ReaxFF, COMB, SNAP, Streitz-Mintmire, 3-body polymorphic
+ long-range interactions for charge, point-dipoles, and LJ dispersion: \
+ Ewald, Wolf, PPPM (similar to particle-mesh Ewald)
+ polarization models: "QEq"_fix_qeq.html, \
+ "core/shell model"_Howto_coreshell.html, \
+ "Drude dipole model"_Howto_drude.html
+ charge equilibration (QEq via dynamic, point, shielded, Slater methods)
+ coarse-grained potentials: DPD, GayBerne, REsquared, colloidal, DLVO
+ mesoscopic potentials: granular, Peridynamics, SPH
+ electron force field (eFF, AWPMD)
+ bond potentials: harmonic, FENE, Morse, nonlinear, class 2, \
+ quartic (breakable)
+ angle potentials: harmonic, CHARMM, cosine, cosine/squared, cosine/periodic, \
+ class 2 (COMPASS)
+ dihedral potentials: harmonic, CHARMM, multi-harmonic, helix, \
+ class 2 (COMPASS), OPLS
+ improper potentials: harmonic, cvff, umbrella, class 2 (COMPASS)
+ polymer potentials: all-atom, united-atom, bead-spring, breakable
+ water potentials: TIP3P, TIP4P, SPC
+ implicit solvent potentials: hydrodynamic lubrication, Debye
+ force-field compatibility with common CHARMM, AMBER, DREIDING, \
+ OPLS, GROMACS, COMPASS options
+ access to "KIM archive"_http://openkim.org of potentials via \
+ "pair kim"_pair_kim.html
+ hybrid potentials: multiple pair, bond, angle, dihedral, improper \
+ potentials can be used in one simulation
+ overlaid potentials: superposition of multiple pair potentials :ul
+
+Atom creation :h4,link(create)
+("read_data"_read_data.html, "lattice"_lattice.html,
+"create_atoms"_create_atoms.html, "delete_atoms"_delete_atoms.html,
+"displace_atoms"_displace_atoms.html, "replicate"_replicate.html commands)
+
+ read in atom coords from files
+ create atoms on one or more lattices (e.g. grain boundaries)
+ delete geometric or logical groups of atoms (e.g. voids)
+ replicate existing atoms multiple times
+ displace atoms :ul
+
+Ensembles, constraints, and boundary conditions :h4,link(ensemble)
+("fix"_fix.html command)
+
+ 2d or 3d systems
+ orthogonal or non-orthogonal (triclinic symmetry) simulation domains
+ constant NVE, NVT, NPT, NPH, Parinello/Rahman integrators
+ thermostatting options for groups and geometric regions of atoms
+ pressure control via Nose/Hoover or Berendsen barostatting in 1 to 3 dimensions
+ simulation box deformation (tensile and shear)
+ harmonic (umbrella) constraint forces
+ rigid body constraints
+ SHAKE bond and angle constraints
+ Monte Carlo bond breaking, formation, swapping
+ atom/molecule insertion and deletion
+ walls of various kinds
+ non-equilibrium molecular dynamics (NEMD)
+ variety of additional boundary conditions and constraints :ul
+
+Integrators :h4,link(integrate)
+("run"_run.html, "run_style"_run_style.html, "minimize"_minimize.html commands)
+
+ velocity-Verlet integrator
+ Brownian dynamics
+ rigid body integration
+ energy minimization via conjugate gradient or steepest descent relaxation
+ rRESPA hierarchical timestepping
+ rerun command for post-processing of dump files :ul
+
+Diagnostics :h4,link(diag)
+
+ see various flavors of the "fix"_fix.html and "compute"_compute.html commands :ul
+
+Output :h4,link(output)
+("dump"_dump.html, "restart"_restart.html commands)
+
+ log file of thermodynamic info
+ text dump files of atom coords, velocities, other per-atom quantities
+ binary restart files
+ parallel I/O of dump and restart files
+ per-atom quantities (energy, stress, centro-symmetry parameter, CNA, etc)
+ user-defined system-wide (log file) or per-atom (dump file) calculations
+ spatial and time averaging of per-atom quantities
+ time averaging of system-wide quantities
+ atom snapshots in native, XYZ, XTC, DCD, CFG formats :ul
+
+Multi-replica models :h4,link(replica1)
+
+"nudged elastic band"_neb.html
+"parallel replica dynamics"_prd.html
+"temperature accelerated dynamics"_tad.html
+"parallel tempering"_temper.html :ul
+
+Pre- and post-processing :h4,link(prepost)
+
+A handful of pre- and post-processing tools are packaged with LAMMPS,
+some of which can convert input and output files to/from formats used
+by other codes; see the "Toos"_Tools.html doc page. :ulb,l
+
+Our group has also written and released a separate toolkit called
+"Pizza.py"_pizza which provides tools for doing setup, analysis,
+plotting, and visualization for LAMMPS simulations. Pizza.py is
+written in "Python"_python and is available for download from "the
+Pizza.py WWW site"_pizza. :l,ule
+
+:link(pizza,http://www.sandia.gov/~sjplimp/pizza.html)
+:link(python,http://www.python.org)
+
+Specialized features :h4,link(special)
+
+LAMMPS can be built with optional packages which implement a variety
+of additional capabilities. See the "Packages"_Packages.html doc
+page for details.
+
+These are LAMMPS capabilities which you may not think of as typical
+classical MD options:
+
+"static"_balance.html and "dynamic load-balancing"_fix_balance.html
+"generalized aspherical particles"_Howto_body.html
+"stochastic rotation dynamics (SRD)"_fix_srd.html
+"real-time visualization and interactive MD"_fix_imd.html
+calculate "virtual diffraction patterns"_compute_xrd.html
+"atom-to-continuum coupling"_fix_atc.html with finite elements
+coupled rigid body integration via the "POEMS"_fix_poems.html library
+"QM/MM coupling"_fix_qmmm.html
+Monte Carlo via "GCMC"_fix_gcmc.html and "tfMC"_fix_tfmc.html and "atom swapping"_fix_atom_swap.html
+"path-integral molecular dynamics (PIMD)"_fix_ipi.html and "this as well"_fix_pimd.html
+"Direct Simulation Monte Carlo"_pair_dsmc.html for low-density fluids
+"Peridynamics mesoscale modeling"_pair_peri.html
+"Lattice Boltzmann fluid"_fix_lb_fluid.html
+"targeted"_fix_tmd.html and "steered"_fix_smd.html molecular dynamics
+"two-temperature electron model"_fix_ttm.html :ul
diff --git a/doc/src/Intro_nonfeatures.txt b/doc/src/Intro_nonfeatures.txt
new file mode 100644
index 0000000000000000000000000000000000000000..2acf6db71f5ccfeea1db3609ba47b2673d00c86d
--- /dev/null
+++ b/doc/src/Intro_nonfeatures.txt
@@ -0,0 +1,83 @@
+"Higher level section"_Intro.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
+
+LAMMPS non-features :h3
+
+LAMMPS is designed to be a fast, parallel engine for molecular
+dynamics (MD) simulations. It provides only a modest amount of
+functionality for setting up simulations and analyzing their output.
+
+Specifically, LAMMPS does not:
+
+run thru a GUI
+build molecular systems
+assign force-field coefficients automagically
+perform sophisticated analyses of your MD simulation
+visualize your MD simulation interactively
+plot your output data :ul
+
+Here are suggestions on how to perform these tasks:
+
+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_head.html doc
+page. :ulb,l
+
+Builder: Several pre-processing tools are packaged with LAMMPS. Some
+of them convert input files in formats produced by other MD codes such
+as CHARMM, AMBER, or Insight into LAMMPS input formats. Some of them
+are simple programs that will build simple molecular systems, such as
+linear bead-spring polymer chains. The moltemplate program is a true
+molecular builder that will generate complex molecular models. See
+the "Tools"_Tools.html doc page for details on tools packaged with
+LAMMPS. The "Pre/post processing
+page"_http:/lammps.sandia.gov/prepost.html of the LAMMPS website
+describes a variety of 3rd party tools for this task. :l
+
+Force-field assignment: The conversion tools described in the previous
+bullet for CHARMM, AMBER, and Insight will also assign force field
+coefficients in the LAMMPS format, assuming you provide CHARMM, AMBER,
+or Accelerys force field files. :l
+
+Simulation analyses: If you want to perform analyses on-the-fly as
+your simulation runs, see the "compute"_compute.html and
+"fix"_fix.html doc pages, which list commands that can be used in a
+LAMMPS input script. Also see the "Modify"_Modify.html doc page for
+info on how to add your own analysis code or algorithms to LAMMPS.
+For post-processing, LAMMPS output such as "dump file
+snapshots"_dump.html can be converted into formats used by other MD or
+post-processing codes. Some post-processing tools packaged with
+LAMMPS will do these conversions. Scripts provided in the
+tools/python directory can extract and massage data in dump files to
+make it easier to import into other programs. See the
+"Tools"_Tools.html doc page for details on these various options. :l
+
+Visualization: LAMMPS can produce JPG or PNG snapshot images
+on-the-fly via its "dump image"_dump_image.html command. For
+high-quality, interactive visualization there are many excellent and
+free tools available. See the "Other Codes
+page"_http://lammps.sandia.gov/viz.html page of the LAMMPS website for
+visualization packages that can use LAMMPS output data. :l
+
+Plotting: See the next bullet about Pizza.py as well as the
+"Python"_Python_head.html doc page for examples of plotting LAMMPS
+output. Scripts provided with the {python} tool in the tools
+directory will extract and massage data in log and dump files to make
+it easier to analyze and plot. See the "Tools"_Tools.html doc page
+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
+setup, analysis, plotting, and visualization (via OpenGL) for LAMMPS
+simulations. It thus provides some functionality for several of the
+above bullets. Pizza.py is written in "Python"_http://www.python.org
+and is available for download from "this
+page"_http://www.cs.sandia.gov/~sjplimp/download.html. :l,ule
diff --git a/doc/src/Intro_opensource.txt b/doc/src/Intro_opensource.txt
new file mode 100644
index 0000000000000000000000000000000000000000..e0d57f7ce199b35ffa8abab06e9e0217b3a54304
--- /dev/null
+++ b/doc/src/Intro_opensource.txt
@@ -0,0 +1,44 @@
+"Higher level section"_Intro.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
+
+LAMMPS open-source license :h3
+
+LAMMPS is a freely-available open-source code, distributed under the
+terms of the "GNU Public License"_gnu, which means you can use or
+modify the code however you wish.
+
+LAMMPS comes with no warranty of any kind. As each source file states
+in its header, it is a copyrighted code that is distributed free-of-
+charge, under the terms of the "GNU Public License"_gnu (GPL). This
+is often referred to as open-source distribution - see
+"www.gnu.org"_gnuorg or "www.opensource.org"_opensource. The legal
+text of the GPL is in the LICENSE file included in the LAMMPS
+distribution.
+
+:link(gnu,http://www.gnu.org/copyleft/gpl.html)
+:link(gnuorg,http://www.gnu.org)
+:link(opensource,http://www.opensource.org)
+
+Here is a summary of what the GPL means for LAMMPS users:
+
+(1) Anyone is free to use, modify, or extend LAMMPS in any way they
+choose, including for commercial purposes.
+
+(2) If you distribute a modified version of LAMMPS, it must remain
+open-source, meaning you distribute it under the terms of the GPL.
+You should clearly annotate such a code as a derivative version of
+LAMMPS.
+
+(3) If you release any code that includes LAMMPS source code, then it
+must also be open-sourced, meaning you distribute it under the terms
+of the GPL.
+
+(4) If you give LAMMPS files to someone else, the GPL LICENSE file and
+source file headers (including the copyright and GPL notices) should
+remain part of the code.
diff --git a/doc/src/Intro_overview.txt b/doc/src/Intro_overview.txt
new file mode 100644
index 0000000000000000000000000000000000000000..49c14bc5f06d463037d294d28873b43fdf6c7f14
--- /dev/null
+++ b/doc/src/Intro_overview.txt
@@ -0,0 +1,58 @@
+"Higher level section"_Intro.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
+
+Overview of LAMMPS :h3
+
+LAMMPS is a classical molecular dynamics (MD) code that models
+ensembles of particles in a liquid, solid, or gaseous state. It can
+model atomic, polymeric, biological, solid-state (metals, ceramics,
+oxides), granular, coarse-grained, or macroscopic systems using a
+variety of interatomic potentials (force fields) and boundary
+conditions. It can model 2d or 3d systems with only a few particles
+up to millions or billions.
+
+LAMMPS can be built and run on a laptop or destop machine, but is
+designed for parallel computers. It will run on any parallel machine
+that supports the "MPI"_mpi message-passing library. This includes
+shared-memory boxes and distributed-memory clusters and
+supercomputers.
+
+:link(mpi,http://www-unix.mcs.anl.gov/mpi)
+
+LAMMPS is written in C++. Earlier versions were written in F77 and
+F90. See the "History page"_http://lammps.sandia.gov/history.html of
+the website for details. All versions can be downloaded from the
+"LAMMPS website"_lws.
+
+LAMMPS is designed to be easy to modify or extend with new
+capabilities, such as new force fields, atom types, boundary
+conditions, or diagnostics. See the "Modify"_Modify.html doc page for
+more details.
+
+In the most general sense, LAMMPS integrates Newton's equations of
+motion for a collection of interacting particles. A single particle
+can be an atom or molecule or electron, a coarse-grained cluster of
+atoms, or a mesoscopic or macroscopic clump of material. The
+interaction models that LAMMPS includes are mostly short-range in
+nature; some long-range models are included as well.
+
+LAMMPS uses neighbor lists to keep track of nearby particles. The
+lists are optimized for systems with particles that are repulsive at
+short distances, so that the local density of particles never becomes
+too large. This is in contrast to methods used for modeling plasmas
+or gravitational bodies (e.g. galaxy formation).
+
+On parallel machines, LAMMPS uses spatial-decomposition techniques to
+partition the simulation domain into small sub-domains of equal
+computational cost, one of which is assigned to each processor.
+Processors communicate and store "ghost" atom information for atoms
+that border their sub-domain.
+
+
+
diff --git a/doc/src/Intro_website.txt b/doc/src/Intro_website.txt
new file mode 100644
index 0000000000000000000000000000000000000000..a8af94157ceb9545be2c6ddd22bcb928115b63d8
--- /dev/null
+++ b/doc/src/Intro_website.txt
@@ -0,0 +1,42 @@
+"Higher level section"_Intro.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
+
+Additional website links :h3
+
+The "LAMMPS website"_lws has a variety of additional info about
+LAMMPS, beyond what is in this manual. Some of the other pages in
+this Intr are included in this list.
+
+"Brief intro and recently added significant features"_lws
+"List of features"_http://lammps.sandia.gov/features.html
+"List of non-features"_http://lammps.sandia.gov/non_features.html
+"Recent bug fixes and new features"_http://lammps.sandia.gov/bug.html :ul
+
+"Download info"_http://lammps.sandia.gov/download.html
+"GitHub site"_https://github.com/lammps/lammps
+"SourceForge site"_https://sourceforge.net/projects/lammps
+"LAMMPS open-source license"_http://lammps.sandia.gov/open_source.html :ul
+
+"Glossary of MD terms relevant to LAMMPS"_http://lammps.sandia.gov/glossary.html
+"LAMMPS highlights with images"_http://lammps.sandia.gov/pictures.html
+"LAMMPS highlights with movies"_http://lammps.sandia.gov/movies.html
+"Mail list"_http://lammps.sandia.gov/mail.html
+"Workshops"_http://lammps.sandia.gov/workshops.html
+"Tutorials"_http://lammps.sandia.gov/tutorials.html
+"Developer guide"_http://lammps.sandia.gov/Developer.pdf :ul
+
+"Pre- and post-processing tools for LAMMPS"_http://lammps.sandia.gov/prepost.html
+"Other software usable with LAMMPS"_http://lammps.sandia.gov/offsite.html
+"Viz tools usable with LAMMPS"_http://lammps.sandia.gov/viz.html :ul
+
+"Benchmark performance"_http://lammps.sandia.gov/bench.html
+"Publications that have cited LAMMPS"_http://lammps.sandia.gov/papers.html
+"Authors of LAMMPS"_http://lammps.sandia.gov/authors.html
+"History of LAMMPS development"_http://lammps.sandia.gov/history.html
+"Funding for LAMMPS"_http://lammps.sandia.gov/funding.html :ul
diff --git a/doc/src/JPG/pair_body_rounded.jpg b/doc/src/JPG/pair_body_rounded.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..cd745c44e27e96585be021b3dcca342f686e15e9
Binary files /dev/null and b/doc/src/JPG/pair_body_rounded.jpg differ
diff --git a/doc/src/Manual.txt b/doc/src/Manual.txt
index e34ec8d5ba75ad6fab8bf5ba417d79a0ec3cd022..c5e5aff61b1ce5149ee2a2acef906bf31eb6bdd5 100644
--- a/doc/src/Manual.txt
+++ b/doc/src/Manual.txt
@@ -1,134 +1,97 @@
<!-- HTML_ONLY -->
<HEAD>
<TITLE>LAMMPS Users Manual</TITLE>
-<META NAME="docnumber" CONTENT="29 Jun 2018 version">
+<META NAME="docnumber" CONTENT="16 Aug 2018 version">
<META NAME="author" CONTENT="http://lammps.sandia.gov - Sandia National Laboratories">
<META NAME="copyright" CONTENT="Copyright (2003) Sandia Corporation. This software and manual is distributed under the GNU General Public License.">
</HEAD>
<BODY>
+<H1></H1>
+
<!-- END_HTML_ONLY -->
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html#comm)
:line
LAMMPS Documentation :c,h1
-29 Jun 2018 version :c,h2
-
-Version info: :h3
-
-The LAMMPS "version" is the date when it was released, such as 1 May
-2010. LAMMPS is updated continuously. Whenever we fix a bug or add a
-feature, we release it immediately, and post a notice on "this page of
-the WWW site"_bug. Every 2-4 months one of the incremental releases
-is subjected to more thorough testing and labeled as a {stable} version.
-
-Each dated copy of LAMMPS contains all the
-features and bug-fixes up to and including that version date. The
-version date is printed to the screen and logfile every time you run
-LAMMPS. It is also in the file src/version.h and in the LAMMPS
-directory name created when you unpack a tarball, and at the top of
-the first page of the manual (this page).
-
-If you browse the HTML doc pages on the LAMMPS WWW site, they always
-describe the most current [development] version of LAMMPS. :ulb,l
-
-If you browse the HTML doc pages included in your tarball, they
-describe the version you have. :l
+16 Aug 2018 version :c,h2
-The "PDF file"_Manual.pdf on the WWW site or in the tarball is updated
-about once per month. This is because it is large, and we don't want
-it to be part of every patch. :l
-
-There is also a "Developer.pdf"_Developer.pdf file in the doc
-directory, which describes the internal structure and algorithms of
-LAMMPS. :l
-:ule
+"What is a LAMMPS version?"_Manual_version.html
LAMMPS stands for Large-scale Atomic/Molecular Massively Parallel
Simulator.
-LAMMPS is a classical molecular dynamics simulation code designed to
-run efficiently on parallel computers. It was developed at Sandia
-National Laboratories, a US Department of Energy facility, with
-funding from the DOE. It is an open-source code, distributed freely
-under the terms of the GNU Public License (GPL).
+LAMMPS is a classical molecular dynamics simulation code with a focus
+on materials modeling. It was designed to run efficiently on parallel
+computers. It was developed originally at Sandia National
+Laboratories, a US Department of Energy facility. The majority of
+funding for LAMMPS has come from the US Department of Energy (DOE).
+LAMMPS is an open-source code, distributed freely under the terms of
+the GNU Public License (GPL).
+
+The "LAMMPS website"_lws has a variety of information about the code.
+It includes links to an on-line version of this manual, a "mail
+list"_http://lammps.sandia.gov/mail.html where users can post
+questions, and a "GitHub site"https://github.com/lammps/lammps where
+all LAMMPS development is coordinated.
-The current core group of LAMMPS developers is at Sandia National
-Labs and Temple University:
+:line
-"Steve Plimpton"_sjp, sjplimp at sandia.gov :ulb,l
-Aidan Thompson, athomps at sandia.gov :l
-Stan Moore, stamoor at sandia.gov :l
-"Axel Kohlmeyer"_ako, akohlmey at gmail.com :l
-:ule
+"PDF file"_Manual.pdf of the entire manual, generated by
+"htmldoc"_http://freecode.com/projects/htmldoc
-Past core developers include Paul Crozier, Ray Shan and Mark Stevens,
-all at Sandia. The [LAMMPS home page] at
-"http://lammps.sandia.gov"_http://lammps.sandia.gov has more information
-about the code and its uses. Interaction with external LAMMPS developers,
-bug reports and feature requests are mainly coordinated through the
-"LAMMPS project on GitHub."_https://github.com/lammps/lammps
-The lammps.org domain, currently hosting "public continuous integration
-testing"_https://ci.lammps.org/job/lammps/ and "precompiled Linux
-RPM and Windows installer packages"_http://packages.lammps.org is located
-at Temple University and managed by Richard Berger,
-richard.berger at temple.edu.
+The content for this manual is part of the LAMMPS distribution. You
+can build a local copy of the Manual as HTML pages or a PDF file, by
+following the steps on the "Manual build"_Manual_build.html doc page.
-:link(bug,http://lammps.sandia.gov/bug.html)
-:link(sjp,http://www.sandia.gov/~sjplimp)
-:link(ako,http://goo.gl/1wk0)
+There is also a "Developer.pdf"_Developer.pdf document which gives
+a brief description of the basic code structure of LAMMPS.
:line
-The LAMMPS documentation is organized into the following sections. If
-you find errors or omissions in this manual or have suggestions for
-useful information to add, please send an email to the developers so
-we can improve the LAMMPS documentation.
+This manual is organized into the following sections.
Once you are familiar with LAMMPS, you may want to bookmark "this
-page"_Section_commands.html#comm at Section_commands.html#comm since
-it gives quick access to documentation for all LAMMPS commands.
-
-"PDF file"_Manual.pdf of the entire manual, generated by
-"htmldoc"_http://freecode.com/projects/htmldoc
+page"_Commands.html since it gives quick access to a doc page for
+every LAMMPS command.
<!-- RST
.. toctree::
:maxdepth: 2
- :numbered:
+ :numbered: 3
:caption: User Documentation
:name: userdoc
:includehidden:
- Section_intro
- Section_start
- Section_commands
- Section_packages
- Section_accelerate
- Section_howto
- Section_example
- Section_perf
- Section_tools
- Section_modify
- Section_python
- Section_errors
- Section_history
+ Intro
+ Install
+ Build
+ Run_head
+ Commands
+ Packages
+ Speed
+ Howto
+ Examples
+ Tools
+ Modify
+ Python_head
+ Errors
+ Manual_build
.. toctree::
:caption: Index
:name: index
:hidden:
- tutorials
- commands
+ commands_list
fixes
computes
pairs
@@ -146,191 +109,22 @@ Indices and tables
END_RST -->
<!-- HTML_ONLY -->
-"Introduction"_Section_intro.html :olb,l
- 1.1 "What is LAMMPS"_intro_1 :ulb,b
- 1.2 "LAMMPS features"_intro_2 :b
- 1.3 "LAMMPS non-features"_intro_3 :b
- 1.4 "Open source distribution"_intro_4 :b
- 1.5 "Acknowledgments and citations"_intro_5 :ule,b
-"Getting started"_Section_start.html :l
- 2.1 "What's in the LAMMPS distribution"_start_1 :ulb,b
- 2.2 "Making LAMMPS"_start_2 :b
- 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"_Section_commands.html :l
- 3.1 "LAMMPS input script"_cmd_1 :ulb,b
- 3.2 "Parsing rules"_cmd_2 :b
- 3.3 "Input script structure"_cmd_3 :b
- 3.4 "Commands listed by category"_cmd_4 :b
- 3.5 "Commands listed alphabetically"_cmd_5 :ule,b
-"Packages"_Section_packages.html :l
- 4.1 "Standard packages"_pkg_1 :ulb,b
- 4.2 "User packages"_pkg_2 :ule,b
-"Accelerating LAMMPS performance"_Section_accelerate.html :l
- 5.1 "Measuring performance"_acc_1 :ulb,b
- 5.2 "Algorithms and code options to boost performace"_acc_2 :b
- 5.3 "Accelerator packages with optimized styles"_acc_3 :b
- 5.3.1 "GPU package"_accelerate_gpu.html :b
- 5.3.2 "USER-INTEL package"_accelerate_intel.html :b
- 5.3.3 "KOKKOS package"_accelerate_kokkos.html :b
- 5.3.4 "USER-OMP package"_accelerate_omp.html :b
- 5.3.5 "OPT package"_accelerate_opt.html :b
- 5.4 "Comparison of various accelerator packages"_acc_4 :ule,b
-"How-to discussions"_Section_howto.html :l
- 6.1 "Restarting a simulation"_howto_1 :ulb,b
- 6.2 "2d simulations"_howto_2 :b
- 6.3 "CHARMM and AMBER force fields"_howto_3 :b
- 6.4 "Running multiple simulations from one input script"_howto_4 :b
- 6.5 "Multi-replica simulations"_howto_5 :b
- 6.6 "Granular models"_howto_6 :b
- 6.7 "TIP3P water model"_howto_7 :b
- 6.8 "TIP4P water model"_howto_8 :b
- 6.9 "SPC water model"_howto_9 :b
- 6.10 "Coupling LAMMPS to other codes"_howto_10 :b
- 6.11 "Visualizing LAMMPS snapshots"_howto_11 :b
- 6.12 "Triclinic (non-orthogonal) simulation boxes"_howto_12 :b
- 6.13 "NEMD simulations"_howto_13 :b
- 6.14 "Finite-size spherical and aspherical particles"_howto_14 :b
- 6.15 "Output from LAMMPS (thermo, dumps, computes, fixes, variables)"_howto_15 :b
- 6.16 "Thermostatting, barostatting, and compute temperature"_howto_16 :b
- 6.17 "Walls"_howto_17 :b
- 6.18 "Elastic constants"_howto_18 :b
- 6.19 "Library interface to LAMMPS"_howto_19 :b
- 6.20 "Calculating thermal conductivity"_howto_20 :b
- 6.21 "Calculating viscosity"_howto_21 :b
- 6.22 "Calculating a diffusion coefficient"_howto_22 :b
- 6.23 "Using chunks to calculate system properties"_howto_23 :b
- 6.24 "Setting parameters for pppm/disp"_howto_24 :b
- 6.25 "Polarizable models"_howto_25 :b
- 6.26 "Adiabatic core/shell model"_howto_26 :b
- 6.27 "Drude induced dipoles"_howto_27 :ule,b
-"Example problems"_Section_example.html :l
-"Performance & scalability"_Section_perf.html :l
-"Additional tools"_Section_tools.html :l
-"Modifying & extending LAMMPS"_Section_modify.html :l
- 10.1 "Atom styles"_mod_1 :ulb,b
- 10.2 "Bond, angle, dihedral, improper potentials"_mod_2 :b
- 10.3 "Compute styles"_mod_3 :b
- 10.4 "Dump styles"_mod_4 :b
- 10.5 "Dump custom output options"_mod_5 :b
- 10.6 "Fix styles"_mod_6 :b
- 10.7 "Input script commands"_mod_7 :b
- 10.8 "Kspace computations"_mod_8 :b
- 10.9 "Minimization styles"_mod_9 :b
- 10.10 "Pairwise potentials"_mod_10 :b
- 10.11 "Region styles"_mod_11 :b
- 10.12 "Body styles"_mod_12 :b
- 10.13 "Thermodynamic output options"_mod_13 :b
- 10.14 "Variable options"_mod_14 :b
- 10.15 "Submitting new features for inclusion in LAMMPS"_mod_15 :ule,b
-"Python interface"_Section_python.html :l
- 11.1 "Overview of running LAMMPS from Python"_py_1 :ulb,b
- 11.2 "Overview of using Python from a LAMMPS script"_py_2 :b
- 11.3 "Building LAMMPS as a shared library"_py_3 :b
- 11.4 "Installing the Python wrapper into Python"_py_4 :b
- 11.5 "Extending Python with MPI to run in parallel"_py_5 :b
- 11.6 "Testing the Python-LAMMPS interface"_py_6 :b
- 11.7 "Using LAMMPS from Python"_py_7 :b
- 11.8 "Example Python scripts that use LAMMPS"_py_8 :ule,b
-"Errors"_Section_errors.html :l
- 12.1 "Common problems"_err_1 :ulb,b
- 12.2 "Reporting bugs"_err_2 :b
- 12.3 "Error & warning messages"_err_3 :ule,b
-"Future and history"_Section_history.html :l
- 13.1 "Coming attractions"_hist_1 :ulb,b
- 13.2 "Past versions"_hist_2 :ule,b
+"Introduction"_Intro.html :olb,l
+"Install LAMMPS"_Install.html :l
+"Build LAMMPS"_Build.html :l
+"Run LAMMPS"_Run_head.html :l
+"Commands"_Commands.html :l
+"Optional packages"_Packages.html :l
+"Accelerate performance"_Speed.html :l
+"How-to discussions"_Howto.html :l
+"Example scripts"_Examples.html :l
+"Auxiliary tools"_Tools.html :l
+"Modify & extend LAMMPS"_Modify.html :l
+"Use Python with LAMMPS"_Python_head.html :l
+"Errors"_Errors.html :l
+"Building the LAMMPS manual"_Manual_build.html :l
:ole
-:link(intro_1,Section_intro.html#intro_1)
-:link(intro_2,Section_intro.html#intro_2)
-:link(intro_3,Section_intro.html#intro_3)
-:link(intro_4,Section_intro.html#intro_4)
-:link(intro_5,Section_intro.html#intro_5)
-
-: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)
-
-:link(cmd_1,Section_commands.html#cmd_1)
-:link(cmd_2,Section_commands.html#cmd_2)
-:link(cmd_3,Section_commands.html#cmd_3)
-:link(cmd_4,Section_commands.html#cmd_4)
-:link(cmd_5,Section_commands.html#cmd_5)
-
-:link(pkg_1,Section_packages.html#pkg_1)
-:link(pkg_2,Section_packages.html#pkg_2)
-
-:link(acc_1,Section_accelerate.html#acc_1)
-:link(acc_2,Section_accelerate.html#acc_2)
-:link(acc_3,Section_accelerate.html#acc_3)
-:link(acc_4,Section_accelerate.html#acc_4)
-
-:link(howto_1,Section_howto.html#howto_1)
-:link(howto_2,Section_howto.html#howto_2)
-:link(howto_3,Section_howto.html#howto_3)
-:link(howto_4,Section_howto.html#howto_4)
-:link(howto_5,Section_howto.html#howto_5)
-:link(howto_6,Section_howto.html#howto_6)
-:link(howto_7,Section_howto.html#howto_7)
-:link(howto_8,Section_howto.html#howto_8)
-:link(howto_9,Section_howto.html#howto_9)
-:link(howto_10,Section_howto.html#howto_10)
-:link(howto_11,Section_howto.html#howto_11)
-:link(howto_12,Section_howto.html#howto_12)
-:link(howto_13,Section_howto.html#howto_13)
-:link(howto_14,Section_howto.html#howto_14)
-:link(howto_15,Section_howto.html#howto_15)
-:link(howto_16,Section_howto.html#howto_16)
-:link(howto_17,Section_howto.html#howto_17)
-:link(howto_18,Section_howto.html#howto_18)
-:link(howto_19,Section_howto.html#howto_19)
-:link(howto_20,Section_howto.html#howto_20)
-:link(howto_21,Section_howto.html#howto_21)
-:link(howto_22,Section_howto.html#howto_22)
-:link(howto_23,Section_howto.html#howto_23)
-:link(howto_24,Section_howto.html#howto_24)
-:link(howto_25,Section_howto.html#howto_25)
-:link(howto_26,Section_howto.html#howto_26)
-:link(howto_27,Section_howto.html#howto_27)
-
-:link(mod_1,Section_modify.html#mod_1)
-:link(mod_2,Section_modify.html#mod_2)
-:link(mod_3,Section_modify.html#mod_3)
-:link(mod_4,Section_modify.html#mod_4)
-:link(mod_5,Section_modify.html#mod_5)
-:link(mod_6,Section_modify.html#mod_6)
-:link(mod_7,Section_modify.html#mod_7)
-:link(mod_8,Section_modify.html#mod_8)
-:link(mod_9,Section_modify.html#mod_9)
-:link(mod_10,Section_modify.html#mod_10)
-:link(mod_11,Section_modify.html#mod_11)
-:link(mod_12,Section_modify.html#mod_12)
-:link(mod_13,Section_modify.html#mod_13)
-:link(mod_14,Section_modify.html#mod_14)
-:link(mod_15,Section_modify.html#mod_15)
-
-:link(py_1,Section_python.html#py_1)
-:link(py_2,Section_python.html#py_2)
-:link(py_3,Section_python.html#py_3)
-:link(py_4,Section_python.html#py_4)
-:link(py_5,Section_python.html#py_5)
-:link(py_6,Section_python.html#py_6)
-
-:link(err_1,Section_errors.html#err_1)
-:link(err_2,Section_errors.html#err_2)
-:link(err_3,Section_errors.html#err_3)
-
-:link(hist_1,Section_history.html#hist_1)
-:link(hist_2,Section_history.html#hist_2)
<!-- END_HTML_ONLY -->
</BODY>
diff --git a/doc/src/Manual_build.txt b/doc/src/Manual_build.txt
new file mode 100644
index 0000000000000000000000000000000000000000..a6b881cb79708c37760dc482cac2a7017342d7df
--- /dev/null
+++ 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
diff --git a/doc/src/Manual_version.txt b/doc/src/Manual_version.txt
new file mode 100644
index 0000000000000000000000000000000000000000..436e531246053144e26cff63e37920c7069fd7d6
--- /dev/null
+++ b/doc/src/Manual_version.txt
@@ -0,0 +1,33 @@
+"Higher level section"_Manual.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
+
+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
+feature, we release it in the next {patch} release, which are
+typically made every couple of weeks. Info on patch releases are on
+"this website page"_http://lammps.sandia.gov/bug.html. Every few
+months, the latest patch release is subjected to more thorough testing
+and labeled as a {stable} version.
+
+Each version of LAMMPS contains all the features and bug-fixes up to
+and including its version date.
+
+The version date is printed to the screen and logfile every time you
+run LAMMPS. It is also in the file src/version.h and in the LAMMPS
+directory name created when you unpack a tarball. And it is on the
+first page of the "manual"_Manual.html.
+
+If you browse the HTML doc pages on the LAMMPS WWW site, they always
+describe the most current patch release of LAMMPS. :ulb,l
+
+If you browse the HTML doc pages included in your tarball, they
+describe the version you have, which may be older. :l,ule
+
diff --git a/doc/src/Modify.txt b/doc/src/Modify.txt
new file mode 100644
index 0000000000000000000000000000000000000000..38fbf17dd918304e3e8eb9a59df790eaba3c12ae
--- /dev/null
+++ b/doc/src/Modify.txt
@@ -0,0 +1,70 @@
+"Previous Section"_Tools.html - "LAMMPS WWW Site"_lws -
+"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
+Section"_Python_head.html :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Modify & extend LAMMPS :h2
+
+LAMMPS is designed in a modular fashion so as to be easy to modify and
+extend with new functionality. In fact, about 95% of its source code
+is add-on files. These doc pages give basic instructions on how to do
+this.
+
+If you add a new feature to LAMMPS and think it will be of interest to
+general users, we encourage you to submit it for inclusion in LAMMPS
+as a pull request on our "GitHub
+site"_https://github.com/lammps/lammps, after reading the "Modify
+contribute"_Modify_contribute.html doc page.
+
+<!-- RST
+
+.. toctree::
+ :maxdepth: 1
+
+ Modify_overview
+ Modify_contribute
+
+.. toctree::
+ :maxdepth: 1
+
+ Modify_atom
+ Modify_pair
+ Modify_bond
+ Modify_compute
+ Modify_fix
+ Modify_command
+ Modify_dump
+ Modify_kspace
+ Modify_min
+ Modify_region
+ Modify_body
+ Modify_thermo
+ Modify_variable
+
+END_RST -->
+
+<!-- HTML_ONLY -->
+
+"Overview"_Modify_overview.html
+"Submitting new features for inclusion in LAMMPS"_Modify_contribute.html :all(b)
+
+"Atom styles"_Modify_atom.html
+"Pair styles"_Modify_pair.html
+"Bond, angle, dihedral, improper styles"_Modify_bond.html
+"Compute styles"_Modify_compute.html
+"Fix styles"_Modify_fix.html
+"Input script command styles"_Modify_command.html
+"Dump styles"_Modify_dump.html
+"Kspace styles"_Modify_kspace.html
+"Minimization styles"_Modify_min.html
+"Region styles"_Modify_region.html
+"Body styles"_Modify_body.html
+"Thermodynamic output options"_Modify_thermo.html
+"Variable options"_Modify_variable.html :all(b)
+
+<!-- END_HTML_ONLY -->
diff --git a/doc/src/Modify_atom.txt b/doc/src/Modify_atom.txt
new file mode 100644
index 0000000000000000000000000000000000000000..60c7dccb29a38e4c628752f87c58a84532eb7c24
--- /dev/null
+++ b/doc/src/Modify_atom.txt
@@ -0,0 +1,90 @@
+"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Atom styles :h3
+
+Classes that define an "atom style"_atom_style.html are derived from
+the AtomVec class and managed by the Atom class. The atom style
+determines what attributes are associated with an atom. A new atom
+style can be created if one of the existing atom styles does not
+define all the attributes you need to store and communicate with
+atoms.
+
+Atom_vec_atomic.cpp is a simple example of an atom style.
+
+Here is a brief description of methods you define in your new derived
+class. See atom_vec.h for details.
+
+init: one time setup (optional)
+grow: re-allocate atom arrays to longer lengths (required)
+grow_reset: make array pointers in Atom and AtomVec classes consistent (required)
+copy: copy info for one atom to another atom's array locations (required)
+pack_comm: store an atom's info in a buffer communicated every timestep (required)
+pack_comm_vel: add velocity info to communication buffer (required)
+pack_comm_hybrid: store extra info unique to this atom style (optional)
+unpack_comm: retrieve an atom's info from the buffer (required)
+unpack_comm_vel: also retrieve velocity info (required)
+unpack_comm_hybrid: retrieve extra info unique to this atom style (optional)
+pack_reverse: store an atom's info in a buffer communicating partial forces (required)
+pack_reverse_hybrid: store extra info unique to this atom style (optional)
+unpack_reverse: retrieve an atom's info from the buffer (required)
+unpack_reverse_hybrid: retrieve extra info unique to this atom style (optional)
+pack_border: store an atom's info in a buffer communicated on neighbor re-builds (required)
+pack_border_vel: add velocity info to buffer (required)
+pack_border_hybrid: store extra info unique to this atom style (optional)
+unpack_border: retrieve an atom's info from the buffer (required)
+unpack_border_vel: also retrieve velocity info (required)
+unpack_border_hybrid: retrieve extra info unique to this atom style (optional)
+pack_exchange: store all an atom's info to migrate to another processor (required)
+unpack_exchange: retrieve an atom's info from the buffer (required)
+size_restart: number of restart quantities associated with proc's atoms (required)
+pack_restart: pack atom quantities into a buffer (required)
+unpack_restart: unpack atom quantities from a buffer (required)
+create_atom: create an individual atom of this style (required)
+data_atom: parse an atom line from the data file (required)
+data_atom_hybrid: parse additional atom info unique to this atom style (optional)
+data_vel: parse one line of velocity information from data file (optional)
+data_vel_hybrid: parse additional velocity data unique to this atom style (optional)
+memory_usage: tally memory allocated by atom arrays (required) :tb(s=:)
+
+The constructor of the derived class sets values for several variables
+that you must set when defining a new atom style, which are documented
+in atom_vec.h. New atom arrays are defined in atom.cpp. Search for
+the word "customize" and you will find locations you will need to
+modify.
+
+NOTE: It is possible to add some attributes, such as a molecule ID, to
+atom styles that do not have them via the "fix
+property/atom"_fix_property_atom.html command. This command also
+allows new custom attributes consisting of extra integer or
+floating-point values to be added to atoms. See the "fix
+property/atom"_fix_property_atom.html doc page for examples of cases
+where this is useful and details on how to initialize, access, and
+output the custom values.
+
+New "pair styles"_pair_style.html, "fixes"_fix.html, or
+"computes"_compute.html can be added to LAMMPS, as discussed below.
+The code for these classes can use the per-atom properties defined by
+fix property/atom. The Atom class has a find_custom() method that is
+useful in this context:
+
+int index = atom->find_custom(char *name, int &flag); :pre
+
+The "name" of a custom attribute, as specified in the "fix
+property/atom"_fix_property_atom.html command, is checked to verify
+that it exists and its index is returned. The method also sets flag =
+0/1 depending on whether it is an integer or floating-point attribute.
+The vector of values associated with the attribute can then be
+accessed using the returned index as
+
+int *ivector = atom->ivector\[index\];
+double *dvector = atom->dvector\[index\]; :pre
+
+Ivector or dvector are vectors of length Nlocal = # of owned atoms,
+which store the attributes of individual atoms.
diff --git a/doc/src/Modify_body.txt b/doc/src/Modify_body.txt
new file mode 100644
index 0000000000000000000000000000000000000000..0114ae10c885c2cbd78cd1d2067ad2751ac997fd
--- /dev/null
+++ b/doc/src/Modify_body.txt
@@ -0,0 +1,34 @@
+"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Body styles :h3
+
+Classes that define body particles are derived from the Body class.
+Body particles can represent complex entities, such as surface meshes
+of discrete points, collections of sub-particles, deformable objects,
+etc.
+
+See the "Howto body"_Howto_body.html doc page for an overview of using
+body particles and the various body styles LAMMPS supports. New
+styles can be created to add new kinds of body particles to LAMMPS.
+
+Body_nparticle.cpp is an example of a body particle that is treated as
+a rigid body containing N sub-particles.
+
+Here is a brief description of methods you define in your new derived
+class. See body.h for details.
+
+data_body: process a line from the Bodies section of a data file
+noutrow: number of sub-particles output is generated for
+noutcol: number of values per-sub-particle output is generated for
+output: output values for the Mth sub-particle
+pack_comm_body: body attributes to communicate every timestep
+unpack_comm_body: unpacking of those attributes
+pack_border_body: body attributes to communicate when reneighboring is done
+unpack_border_body: unpacking of those attributes :tb(s=:)
diff --git a/doc/src/Modify_bond.txt b/doc/src/Modify_bond.txt
new file mode 100644
index 0000000000000000000000000000000000000000..7ceea3f910121c4191b27cd0aaa8256e421281e3
--- /dev/null
+++ b/doc/src/Modify_bond.txt
@@ -0,0 +1,33 @@
+"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Bond, angle, dihedral, improper styles :h3
+
+Classes that compute molecular interactions are derived from the Bond,
+Angle, Dihedral, and Improper classes. New styles can be created to
+add new potentials to LAMMPS.
+
+Bond_harmonic.cpp is the simplest example of a bond style. Ditto for
+the harmonic forms of the angle, dihedral, and improper style
+commands.
+
+Here is a brief description of common methods you define in your
+new derived class. See bond.h, angle.h, dihedral.h, and improper.h
+for details and specific additional methods.
+
+init: check if all coefficients are set, calls {init_style} (optional)
+init_style: check if style specific conditions are met (optional)
+compute: compute the molecular interactions (required)
+settings: apply global settings for all types (optional)
+coeff: set coefficients for one type (required)
+equilibrium_distance: length of bond, used by SHAKE (required, bond only)
+equilibrium_angle: opening of angle, used by SHAKE (required, angle only)
+write & read_restart: writes/reads coeffs to restart files (required)
+single: force and energy of a single bond or angle (required, bond or angle only)
+memory_usage: tally memory allocated by the style (optional) :tb(s=:)
diff --git a/doc/src/Modify_command.txt b/doc/src/Modify_command.txt
new file mode 100644
index 0000000000000000000000000000000000000000..4576f6c8067684ca95b94b7ae022ec0df6166f76
--- /dev/null
+++ b/doc/src/Modify_command.txt
@@ -0,0 +1,27 @@
+"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Input script command style :h3
+
+New commands can be added to LAMMPS input scripts by adding new
+classes that have a "command" method. For example, the create_atoms,
+read_data, velocity, and run commands are all implemented in this
+fashion. When such a command is encountered in the LAMMPS input
+script, LAMMPS simply creates a class with the corresponding name,
+invokes the "command" method of the class, and passes it the arguments
+from the input script. The command method can perform whatever
+operations it wishes on LAMMPS data structures.
+
+The single method your new class must define is as follows:
+
+command: operations performed by the new command :tb(s=:)
+
+Of course, the new class can define other methods and variables as
+needed.
+
diff --git a/doc/src/Modify_compute.txt b/doc/src/Modify_compute.txt
new file mode 100644
index 0000000000000000000000000000000000000000..2f6481dbd5be934fd8dcfa7f1abed50bd57cc3c3
--- /dev/null
+++ b/doc/src/Modify_compute.txt
@@ -0,0 +1,49 @@
+"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Compute styles :h3
+
+Classes that compute scalar and vector quantities like temperature
+and the pressure tensor, as well as classes that compute per-atom
+quantities like kinetic energy and the centro-symmetry parameter
+are derived from the Compute class. New styles can be created
+to add new calculations to LAMMPS.
+
+Compute_temp.cpp is a simple example of computing a scalar
+temperature. Compute_ke_atom.cpp is a simple example of computing
+per-atom kinetic energy.
+
+Here is a brief description of methods you define in your new derived
+class. See compute.h for details.
+
+init: perform one time setup (required)
+init_list: neighbor list setup, if needed (optional)
+compute_scalar: compute a scalar quantity (optional)
+compute_vector: compute a vector of quantities (optional)
+compute_peratom: compute one or more quantities per atom (optional)
+compute_local: compute one or more quantities per processor (optional)
+pack_comm: pack a buffer with items to communicate (optional)
+unpack_comm: unpack the buffer (optional)
+pack_reverse: pack a buffer with items to reverse communicate (optional)
+unpack_reverse: unpack the buffer (optional)
+remove_bias: remove velocity bias from one atom (optional)
+remove_bias_all: remove velocity bias from all atoms in group (optional)
+restore_bias: restore velocity bias for one atom after remove_bias (optional)
+restore_bias_all: same as before, but for all atoms in group (optional)
+pair_tally_callback: callback function for {tally}-style computes (optional).
+memory_usage: tally memory usage (optional) :tb(s=:)
+
+Tally-style computes are a special case, as their computation is done
+in two stages: the callback function is registered with the pair style
+and then called from the Pair::ev_tally() function, which is called for
+each pair after force and energy has been computed for this pair. Then
+the tallied values are retrieved with the standard compute_scalar or
+compute_vector or compute_peratom methods. The USER-TALLY package
+provides {examples}_compute_tally.html for utilizing this mechanism.
+
diff --git a/doc/src/Modify_contribute.txt b/doc/src/Modify_contribute.txt
new file mode 100644
index 0000000000000000000000000000000000000000..8cbea8bb317f912a500857886b50a6f8a42e3c4d
--- /dev/null
+++ b/doc/src/Modify_contribute.txt
@@ -0,0 +1,212 @@
+"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Submitting new features for inclusion in LAMMPS :h3
+
+We encourage users to submit new features or modifications for LAMMPS
+to "the core developers"_http://lammps.sandia.gov/authors.html so they
+can be added to the LAMMPS distribution. The preferred way to manage
+and coordinate this is as of Fall 2016 via the LAMMPS project on
+"GitHub"_https://github.com/lammps/lammps. An alternative is to
+contact the LAMMPS developers or the indicated developer of a package
+or feature directly and send in your contribution via e-mail.
+
+For any larger modifications or programming project, you are
+encouraged to contact the LAMMPS developers ahead of time, in order to
+discuss implementation strategies and coding guidelines, that will
+make it easier to integrate your contribution and result in less work
+for everybody involved. You are also encouraged to search through the
+list of "open issues on
+GitHub"_https://github.com/lammps/lammps/issues and submit a new issue
+for a planned feature, so you would not duplicate the work of others
+(and possibly get scooped by them) or have your work duplicated by
+others.
+
+How quickly your contribution will be integrated depends largely on
+how much effort it will cause to integrate and test it, how much it
+requires changes to the core codebase, and of how much interest it is
+to the larger LAMMPS community. Please see below for a checklist of
+typical requirements. Once you have prepared everything, see the
+"Howto github"_Howto_github.html doc page for instructions on how to
+submit your changes or new files through a GitHub pull request. If you
+prefer to submit patches or full files, you should first make certain,
+that your code works correctly with the latest patch-level version of
+LAMMPS and contains all bugfixes from it. Then create a gzipped tar
+file of all changed or added files or a corresponding patch file using
+'diff -u' or 'diff -c' and compress it with gzip. Please only use gzip
+compression, as this works well on all platforms.
+
+If the new features/files are broadly useful we may add them as core
+files to LAMMPS or as part of a "standard
+package"_Packages_standard.html. Else we will add them as a
+user-contributed file or "user package"_Packages_user.html. Examples
+of user packages are in src sub-directories that start with USER. The
+USER-MISC package is simply a collection of (mostly) unrelated single
+files, which is the simplest way to have your contribution quickly
+added to the LAMMPS distribution. All the standard and user packages
+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,
+used as a license for the rest of LAMMPS. See the "Open
+source"_http://lammps.sandia.gov/open_source.html page on the LAMMPS
+website for details.
+
+With user packages and files, all we are really providing (aside from
+the fame and fortune that accompanies having your name in the source
+code and on the "Authors page"_http://lammps.sandia.gov/authors.html
+of the "LAMMPS WWW site"_lws), is a means for you to distribute your
+work to the LAMMPS user community, and a mechanism for others to
+easily try out your new feature. This may help you find bugs or make
+contact with new collaborators. Note that you're also implicitly
+agreeing to support your code which means answer questions, fix bugs,
+and maintain it if LAMMPS changes in some way that breaks it (an
+unusual event).
+
+NOTE: If you prefer to actively develop and support your add-on
+feature yourself, then you may wish to make it available for download
+from your own website, as a user package that LAMMPS users can add to
+their copy of LAMMPS. See the "Offsite LAMMPS packages and
+tools"_http://lammps.sandia.gov/offsite.html page of the LAMMPS web
+site for examples of groups that do this. We are happy to advertise
+your package and web site from that page. Simply email the
+"developers"_http://lammps.sandia.gov/authors.html with info about
+your package and we will post it there.
+
+The previous sections of this doc page describe how to add new "style"
+files of various kinds to LAMMPS. Packages are simply collections of
+one or more new class files which are invoked as a new style within a
+LAMMPS input script. If designed correctly, these additions typically
+do not require changes to the main core of LAMMPS; they are simply
+add-on files. If you think your new feature requires non-trivial
+changes in core LAMMPS files, you'll need to "communicate with the
+developers"_http://lammps.sandia.gov/authors.html, since we may or may
+not want to make those changes. An example of a trivial change is
+making a parent-class method "virtual" when you derive a new child
+class from it.
+
+Here is a checklist of steps you need to follow to submit a single file
+or user package for our consideration. Following these steps will save
+both you and us time. See existing files in packages in the src dir for
+examples. If you are uncertain, please ask.
+
+All source files you provide must compile with the most current
+version of LAMMPS with multiple configurations. In particular you
+need to test compiling LAMMPS from scratch with -DLAMMPS_BIGBIG
+set in addition to the default -DLAMMPS_SMALLBIG setting. Your code
+will need to work correctly in serial and in parallel using MPI. :ulb,l
+
+For consistency with the rest of LAMMPS and especially, if you want
+your contribution(s) to be added to main LAMMPS code or one of its
+standard packages, it needs to be written in a style compatible with
+other LAMMPS source files. This means: 2-character indentation per
+level, [no tabs], no lines over 80 characters. I/O is done via
+the C-style stdio library, class header files should not import any
+system headers outside <stdio.h>, STL containers should be avoided
+in headers, and forward declarations used where possible or needed.
+All added code should be placed into the LAMMPS_NS namespace or a
+sub-namespace; global or static variables should be avoided, as they
+conflict with the modular nature of LAMMPS and the C++ class structure.
+Header files must [not] import namespaces with {using}.
+This all is so the developers can more easily understand, integrate,
+and maintain your contribution and reduce conflicts with other parts
+of LAMMPS. This basically means that the code accesses data
+structures, performs its operations, and is formatted similar to other
+LAMMPS source files, including the use of the error class for error
+and warning messages. :l
+
+If you want your contribution to be added as a user-contributed
+feature, and it's a single file (actually a *.cpp and *.h file) it can
+rapidly be added to the USER-MISC directory. Send us the one-line
+entry to add to the USER-MISC/README file in that dir, along with the
+2 source files. You can do this multiple times if you wish to
+contribute several individual features. :l
+
+If you want your contribution to be added as a user-contribution and
+it is several related features, it is probably best to make it a user
+package directory with a name like USER-FOO. In addition to your new
+files, the directory should contain a README text file. The README
+should contain your name and contact information and a brief
+description of what your new package does. If your files depend on
+other LAMMPS style files also being installed (e.g. because your file
+is a derived class from the other LAMMPS class), then an Install.sh
+file is also needed to check for those dependencies. See other README
+and Install.sh files in other USER directories as examples. Send us a
+tarball of this USER-FOO directory. :l
+
+Your new source files need to have the LAMMPS copyright, GPL notice,
+and your name and email address at the top, like other
+user-contributed LAMMPS source files. They need to create a class
+that is inside the LAMMPS namespace. If the file is for one of the
+
+USER packages, including USER-MISC, then we are not as picky about the
+coding style (see above). I.e. the files do not need to be in the
+same stylistic format and syntax as other LAMMPS files, though that
+would be nice for developers as well as users who try to read your
+code. :l
+
+You [must] also create a [documentation] file for each new command or
+style you are adding to LAMMPS. For simplicity and convenience, the
+documentation of groups of closely related commands or styles may be
+combined into a single file. This will be one file for a single-file
+feature. For a package, it might be several files. These are simple
+text files with a specific markup language, that are then auto-converted
+to HTML and PDF. The tools for this conversion are included in the
+source distribution, and the translation can be as simple as doing
+"make html pdf" in the doc folder.
+Thus the documentation source files must be in the same format and
+style as other *.txt files in the lammps/doc/src directory for similar
+commands and styles; use one or more of them as a starting point.
+A description of the markup can also be found in
+lammps/doc/utils/txt2html/README.html
+As appropriate, the text files can include links to equations
+(see doc/Eqs/*.tex for examples, we auto-create the associated JPG
+files), or figures (see doc/JPG for examples), or even additional PDF
+files with further details (see doc/PDF for examples). The doc page
+should also include literature citations as appropriate; see the
+bottom of doc/fix_nh.txt for examples and the earlier part of the same
+file for how to format the cite itself. The "Restrictions" section of
+the doc page should indicate that your command is only available if
+LAMMPS is built with the appropriate USER-MISC or USER-FOO package.
+See other user package doc files for examples of how to do this. The
+prerequisite for building the HTML format files are Python 3.x and
+virtualenv, the requirement for generating the PDF format manual
+is the "htmldoc"_http://www.htmldoc.org/ software. Please run at least
+"make html" and carefully inspect and proofread the resulting HTML format
+doc page before submitting your code. :l
+
+For a new package (or even a single command) you should include one or
+more example scripts demonstrating its use. These should run in no
+more than a couple minutes, even on a single processor, and not require
+large data files as input. See directories under examples/USER for
+examples of input scripts other users provided for their packages.
+These example inputs are also required for validating memory accesses
+and testing for memory leaks with valgrind :l
+
+If there is a paper of yours describing your feature (either the
+algorithm/science behind the feature itself, or its initial usage, or
+its implementation in LAMMPS), you can add the citation to the *.cpp
+source file. See src/USER-EFF/atom_vec_electron.cpp for an example.
+A LaTeX citation is stored in a variable at the top of the file and a
+single line of code that references the variable is added to the
+constructor of the class. Whenever a user invokes your feature from
+their input script, this will cause LAMMPS to output the citation to a
+log.cite file and prompt the user to examine the file. Note that you
+should only use this for a paper you or your group authored.
+E.g. adding a cite in the code for a paper by Nose and Hoover if you
+write a fix that implements their integrator is not the intended
+usage. That kind of citation should just be in the doc page you
+provide. :l
+:ule
+
+Finally, as a general rule-of-thumb, the more clear and
+self-explanatory you make your documentation and README files, and the
+easier you make it for people to get started, e.g. by providing example
+scripts, the more likely it is that users will try out your new feature.
diff --git a/doc/src/Modify_dump.txt b/doc/src/Modify_dump.txt
new file mode 100644
index 0000000000000000000000000000000000000000..cfe96f5d3d0bc25402b73beef55261f8e7679eb1
--- /dev/null
+++ b/doc/src/Modify_dump.txt
@@ -0,0 +1,35 @@
+"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Dump styles :h3
+
+Classes that dump per-atom info to files are derived from the Dump
+class. To dump new quantities or in a new format, a new derived dump
+class can be added, but it is typically simpler to modify the
+DumpCustom class contained in the dump_custom.cpp file.
+
+Dump_atom.cpp is a simple example of a derived dump class.
+
+Here is a brief description of methods you define in your new derived
+class. See dump.h for details.
+
+write_header: write the header section of a snapshot of atoms
+count: count the number of lines a processor will output
+pack: pack a proc's output data into a buffer
+write_data: write a proc's data to a file :tb(s=:)
+
+See the "dump"_dump.html command and its {custom} style for a list of
+keywords for atom information that can already be dumped by
+DumpCustom. It includes options to dump per-atom info from Compute
+classes, so adding a new derived Compute class is one way to calculate
+new quantities to dump.
+
+Note that new keywords for atom properties are not typically
+added to the "dump custom"_dump.html command. Instead they are added
+to the "compute property/atom"_compute_property_atom.html command.
diff --git a/doc/src/Modify_fix.txt b/doc/src/Modify_fix.txt
new file mode 100644
index 0000000000000000000000000000000000000000..b095ebc4b5fa8b549fbfb411c2558e5c6bb14c4d
--- /dev/null
+++ b/doc/src/Modify_fix.txt
@@ -0,0 +1,107 @@
+"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Fix styles :h3
+
+In LAMMPS, a "fix" is any operation that is computed during
+timestepping that alters some property of the system. Essentially
+everything that happens during a simulation besides force computation,
+neighbor list construction, and output, is a "fix". This includes
+time integration (update of coordinates and velocities), force
+constraints or boundary conditions (SHAKE or walls), and diagnostics
+(compute a diffusion coefficient). New styles can be created to add
+new options to LAMMPS.
+
+Fix_setforce.cpp is a simple example of setting forces on atoms to
+prescribed values. There are dozens of fix options already in LAMMPS;
+choose one as a template that is similar to what you want to
+implement.
+
+Here is a brief description of methods you can define in your new
+derived class. See fix.h for details.
+
+setmask: determines when the fix is called during the timestep (required)
+init: initialization before a run (optional)
+setup_pre_exchange: called before atom exchange in setup (optional)
+setup_pre_force: called before force computation in setup (optional)
+setup: called immediately before the 1st timestep and after forces are computed (optional)
+min_setup_pre_force: like setup_pre_force, but for minimizations instead of MD runs (optional)
+min_setup: like setup, but for minimizations instead of MD runs (optional)
+initial_integrate: called at very beginning of each timestep (optional)
+pre_exchange: called before atom exchange on re-neighboring steps (optional)
+pre_neighbor: called before neighbor list build (optional)
+pre_force: called before pair & molecular forces are computed (optional)
+post_force: called after pair & molecular forces are computed and communicated (optional)
+final_integrate: called at end of each timestep (optional)
+end_of_step: called at very end of timestep (optional)
+write_restart: dumps fix info to restart file (optional)
+restart: uses info from restart file to re-initialize the fix (optional)
+grow_arrays: allocate memory for atom-based arrays used by fix (optional)
+copy_arrays: copy atom info when an atom migrates to a new processor (optional)
+pack_exchange: store atom's data in a buffer (optional)
+unpack_exchange: retrieve atom's data from a buffer (optional)
+pack_restart: store atom's data for writing to restart file (optional)
+unpack_restart: retrieve atom's data from a restart file buffer (optional)
+size_restart: size of atom's data (optional)
+maxsize_restart: max size of atom's data (optional)
+setup_pre_force_respa: same as setup_pre_force, but for rRESPA (optional)
+initial_integrate_respa: same as initial_integrate, but for rRESPA (optional)
+post_integrate_respa: called after the first half integration step is done in rRESPA (optional)
+pre_force_respa: same as pre_force, but for rRESPA (optional)
+post_force_respa: same as post_force, but for rRESPA (optional)
+final_integrate_respa: same as final_integrate, but for rRESPA (optional)
+min_pre_force: called after pair & molecular forces are computed in minimizer (optional)
+min_post_force: called after pair & molecular forces are computed and communicated in minimizer (optional)
+min_store: store extra data for linesearch based minimization on a LIFO stack (optional)
+min_pushstore: push the minimization LIFO stack one element down (optional)
+min_popstore: pop the minimization LIFO stack one element up (optional)
+min_clearstore: clear minimization LIFO stack (optional)
+min_step: reset or move forward on line search minimization (optional)
+min_dof: report number of degrees of freedom {added} by this fix in minimization (optional)
+max_alpha: report maximum allowed step size during linesearch minimization (optional)
+pack_comm: pack a buffer to communicate a per-atom quantity (optional)
+unpack_comm: unpack a buffer to communicate a per-atom quantity (optional)
+pack_reverse_comm: pack a buffer to reverse communicate a per-atom quantity (optional)
+unpack_reverse_comm: unpack a buffer to reverse communicate a per-atom quantity (optional)
+dof: report number of degrees of freedom {removed} by this fix during MD (optional)
+compute_scalar: return a global scalar property that the fix computes (optional)
+compute_vector: return a component of a vector property that the fix computes (optional)
+compute_array: return a component of an array property that the fix computes (optional)
+deform: called when the box size is changed (optional)
+reset_target: called when a change of the target temperature is requested during a run (optional)
+reset_dt: is called when a change of the time step is requested during a run (optional)
+modify_param: called when a fix_modify request is executed (optional)
+memory_usage: report memory used by fix (optional)
+thermo: compute quantities for thermodynamic output (optional) :tb(s=:)
+
+Typically, only a small fraction of these methods are defined for a
+particular fix. Setmask is mandatory, as it determines when the fix
+will be invoked during the timestep. Fixes that perform time
+integration ({nve}, {nvt}, {npt}) implement initial_integrate() and
+final_integrate() to perform velocity Verlet updates. Fixes that
+constrain forces implement post_force().
+
+Fixes that perform diagnostics typically implement end_of_step(). For
+an end_of_step fix, one of your fix arguments must be the variable
+"nevery" which is used to determine when to call the fix and you must
+set this variable in the constructor of your fix. By convention, this
+is the first argument the fix defines (after the ID, group-ID, style).
+
+If the fix needs to store information for each atom that persists from
+timestep to timestep, it can manage that memory and migrate the info
+with the atoms as they move from processors to processor by
+implementing the grow_arrays, copy_arrays, pack_exchange, and
+unpack_exchange methods. Similarly, the pack_restart and
+unpack_restart methods can be implemented to store information about
+the fix in restart files. If you wish an integrator or force
+constraint fix to work with rRESPA (see the "run_style"_run_style.html
+command), the initial_integrate, post_force_integrate, and
+final_integrate_respa methods can be implemented. The thermo method
+enables a fix to contribute values to thermodynamic output, as printed
+quantities and/or to be summed to the potential energy of the system.
diff --git a/doc/src/Modify_kspace.txt b/doc/src/Modify_kspace.txt
new file mode 100644
index 0000000000000000000000000000000000000000..d5f018411d8d280d679b7a7940403b1658a20726
--- /dev/null
+++ b/doc/src/Modify_kspace.txt
@@ -0,0 +1,25 @@
+"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Kspace styles :h3
+
+Classes that compute long-range Coulombic interactions via K-space
+representations (Ewald, PPPM) are derived from the KSpace class. New
+styles can be created to add new K-space options to LAMMPS.
+
+Ewald.cpp is an example of computing K-space interactions.
+
+Here is a brief description of methods you define in your new derived
+class. See kspace.h for details.
+
+init: initialize the calculation before a run
+setup: computation before the 1st timestep of a run
+compute: every-timestep computation
+memory_usage: tally of memory usage :tb(s=:)
+
diff --git a/doc/src/Modify_min.txt b/doc/src/Modify_min.txt
new file mode 100644
index 0000000000000000000000000000000000000000..8252a576f3b01b7d58461a5bf200c0ddc1405c19
--- /dev/null
+++ b/doc/src/Modify_min.txt
@@ -0,0 +1,23 @@
+"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Minimization styles :h3
+
+Classes that perform energy minimization derived from the Min class.
+New styles can be created to add new minimization algorithms to
+LAMMPS.
+
+Min_cg.cpp is an example of conjugate gradient minimization.
+
+Here is a brief description of methods you define in your new derived
+class. See min.h for details.
+
+init: initialize the minimization before a run
+run: perform the minimization
+memory_usage: tally of memory usage :tb(s=:)
diff --git a/doc/src/Modify_overview.txt b/doc/src/Modify_overview.txt
new file mode 100644
index 0000000000000000000000000000000000000000..cf94b40281417805515700d697dc84cbd476fc38
--- /dev/null
+++ b/doc/src/Modify_overview.txt
@@ -0,0 +1,101 @@
+"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Overview :h3
+
+The best way to add a new feature to LAMMPS is to find a similar
+featureand look at the corresponding source and header files to figure
+out what it does. You will need some knowledge of C++ to be able to
+understand the hi-level structure of LAMMPS and its class
+organization, but functions (class methods) that do actual
+computations are written in vanilla C-style code and operate on simple
+C-style data structures (vectors and arrays).
+
+Most of the new features described on the "Modify"_Modify.html doc
+page require you to write a new C++ derived class (except for
+exceptions described below, where you can make small edits to existing
+files). Creating a new class requires 2 files, a source code file
+(*.cpp) and a header file (*.h). The derived class must provide
+certain methods to work as a new option. Depending on how different
+your new feature is compared to existing features, you can either
+derive from the base class itself, or from a derived class that
+already exists. Enabling LAMMPS to invoke the new class is as simple
+as putting the two source files in the src dir and re-building LAMMPS.
+
+The advantage of C++ and its object-orientation is that all the code
+and variables needed to define the new feature are in the 2 files you
+write, and thus shouldn't make the rest of LAMMPS more complex or
+cause side-effect bugs.
+
+Here is a concrete example. Suppose you write 2 files pair_foo.cpp
+and pair_foo.h that define a new class PairFoo that computes pairwise
+potentials described in the classic 1997 "paper"_#Foo by Foo, et al.
+If you wish to invoke those potentials in a LAMMPS input script with a
+command like
+
+pair_style foo 0.1 3.5 :pre
+
+then your pair_foo.h file should be structured as follows:
+
+#ifdef PAIR_CLASS
+PairStyle(foo,PairFoo)
+#else
+...
+(class definition for PairFoo)
+...
+#endif :pre
+
+where "foo" is the style keyword in the pair_style command, and
+PairFoo is the class name defined in your pair_foo.cpp and pair_foo.h
+files.
+
+When you re-build LAMMPS, your new pairwise potential becomes part of
+the executable and can be invoked with a pair_style command like the
+example above. Arguments like 0.1 and 3.5 can be defined and
+processed by your new class.
+
+As illustrated by this pairwise example, many kinds of options are
+referred to in the LAMMPS documentation as the "style" of a particular
+command.
+
+The "Modify page"_Modify.html lists all the common styles in LAMMPS,
+and discusses the header file for the base class that these styles are
+derived from. Public variables in that file are ones used and set by
+the derived classes which are also used by the base class. Sometimes
+they are also used by the rest of LAMMPS. Virtual functions in the
+base class header file which are set = 0 are ones you must define in
+your new derived class to give it the functionality LAMMPS expects.
+Virtual functions that are not set to 0 are functions you can
+optionally define.
+
+Additionally, new output options can be added directly to the
+thermo.cpp, dump_custom.cpp, and variable.cpp files. These are also
+listed on the "Modify page"_Modify.html.
+
+Here are additional guidelines for modifying LAMMPS and adding new
+functionality:
+
+Think about whether what you want to do would be better as a pre- or
+post-processing step. Many computations are more easily and more
+quickly done that way. :ulb,l
+
+Don't do anything within the timestepping of a run that isn't
+parallel. E.g. don't accumulate a bunch of data on a single processor
+and analyze it. You run the risk of seriously degrading the parallel
+efficiency. :l
+
+If your new feature reads arguments or writes output, make sure you
+follow the unit conventions discussed by the "units"_units.html
+command. :l
+:ule
+
+:line
+
+:link(Foo)
+[(Foo)] Foo, Morefoo, and Maxfoo, J of Classic Potentials, 75, 345 (1997).
diff --git a/doc/src/Modify_pair.txt b/doc/src/Modify_pair.txt
new file mode 100644
index 0000000000000000000000000000000000000000..0ebf2daa30baab30e377cb5df9cae40d5e0f5a36
--- /dev/null
+++ b/doc/src/Modify_pair.txt
@@ -0,0 +1,33 @@
+"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Pair styles :h3
+
+Classes that compute pairwise interactions are derived from the Pair
+class. In LAMMPS, pairwise calculation include manybody potentials
+such as EAM or Tersoff where particles interact without a static bond
+topology. New styles can be created to add new pair potentials to
+LAMMPS.
+
+Pair_lj_cut.cpp is a simple example of a Pair class, though it
+includes some optional methods to enable its use with rRESPA.
+
+Here is a brief description of the class methods in pair.h:
+
+compute: workhorse routine that computes pairwise interactions
+settings: reads the input script line with arguments you define
+coeff: set coefficients for one i,j type pair
+init_one: perform initialization for one i,j type pair
+init_style: initialization specific to this pair style
+write & read_restart: write/read i,j pair coeffs to restart files
+write & read_restart_settings: write/read global settings to restart files
+single: force and energy of a single pairwise interaction between 2 atoms
+compute_inner/middle/outer: versions of compute used by rRESPA :tb(s=:)
+
+The inner/middle/outer routines are optional.
diff --git a/doc/src/Modify_region.txt b/doc/src/Modify_region.txt
new file mode 100644
index 0000000000000000000000000000000000000000..cdf192323ac50a8f5d771a4ea80822ec2bc6d3bf
--- /dev/null
+++ b/doc/src/Modify_region.txt
@@ -0,0 +1,25 @@
+"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Region styles :h3
+
+Classes that define geometric regions are derived from the Region
+class. Regions are used elsewhere in LAMMPS to group atoms, delete
+atoms to create a void, insert atoms in a specified region, etc. New
+styles can be created to add new region shapes to LAMMPS.
+
+Region_sphere.cpp is an example of a spherical region.
+
+Here is a brief description of methods you define in your new derived
+class. See region.h for details.
+
+inside: determine whether a point is in the region
+surface_interior: determine if a point is within a cutoff distance inside of surc
+surface_exterior: determine if a point is within a cutoff distance outside of surf
+shape_update : change region shape if set by time-dependent variable :tb(s=:)
diff --git a/doc/src/Modify_thermo.txt b/doc/src/Modify_thermo.txt
new file mode 100644
index 0000000000000000000000000000000000000000..1772bae87a185846f941e0b540d8df2a904a1208
--- /dev/null
+++ b/doc/src/Modify_thermo.txt
@@ -0,0 +1,35 @@
+"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Thermodynamic output options :h3
+
+There is one class that computes and prints thermodynamic information
+to the screen and log file; see the file thermo.cpp.
+
+There are two styles defined in thermo.cpp: "one" and "multi". There
+is also a flexible "custom" style which allows the user to explicitly
+list keywords for quantities to print when thermodynamic info is
+output. See the "thermo_style"_thermo_style.html command for a list
+of defined quantities.
+
+The thermo styles (one, multi, etc) are simply lists of keywords.
+Adding a new style thus only requires defining a new list of keywords.
+Search for the word "customize" with references to "thermo style" in
+thermo.cpp to see the two locations where code will need to be added.
+
+New keywords can also be added to thermo.cpp to compute new quantities
+for output. Search for the word "customize" with references to
+"keyword" in thermo.cpp to see the several locations where code will
+need to be added.
+
+Note that the "thermo_style custom"_thermo.html command already allows
+for thermo output of quantities calculated by "fixes"_fix.html,
+"computes"_compute.html, and "variables"_variable.html. Thus, it may
+be simpler to compute what you wish via one of those constructs, than
+by adding a new keyword to the thermo command.
diff --git a/doc/src/Modify_variable.txt b/doc/src/Modify_variable.txt
new file mode 100644
index 0000000000000000000000000000000000000000..b163272f3ebc225522467d08fe144b725dc22a27
--- /dev/null
+++ b/doc/src/Modify_variable.txt
@@ -0,0 +1,46 @@
+"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Variable options :h3
+
+There is one class that computes and stores "variable"_variable.html
+information in LAMMPS; see the file variable.cpp. The value
+associated with a variable can be periodically printed to the screen
+via the "print"_print.html, "fix print"_fix_print.html, or
+"thermo_style custom"_thermo_style.html commands. Variables of style
+"equal" can compute complex equations that involve the following types
+of arguments:
+
+thermo keywords = ke, vol, atoms, ...
+other variables = v_a, v_myvar, ...
+math functions = div(x,y), mult(x,y), add(x,y), ...
+group functions = mass(group), xcm(group,x), ...
+atom values = x\[123\], y\[3\], vx\[34\], ...
+compute values = c_mytemp\[0\], c_thermo_press\[3\], ... :pre
+
+Adding keywords for the "thermo_style custom"_thermo_style.html
+command (which can then be accessed by variables) is discussed on the
+"Modify thermo"_Modify_thermo.html doc page.
+
+Adding a new math function of one or two arguments can be done by
+editing one section of the Variable::evaluate() method. Search for
+the word "customize" to find the appropriate location.
+
+Adding a new group function can be done by editing one section of the
+Variable::evaluate() method. Search for the word "customize" to find
+the appropriate location. You may need to add a new method to the
+Group class as well (see the group.cpp file).
+
+Accessing a new atom-based vector can be done by editing one section
+of the Variable::evaluate() method. Search for the word "customize"
+to find the appropriate location.
+
+Adding new "compute styles"_compute.html (whose calculated values can
+then be accessed by variables) is discussed on the "Modify
+compute"_Modify_compute.html doc page.
diff --git a/doc/src/Packages.txt b/doc/src/Packages.txt
new file mode 100644
index 0000000000000000000000000000000000000000..231c8528e90d57b7291297b40a7f8f0a19d0da75
--- /dev/null
+++ b/doc/src/Packages.txt
@@ -0,0 +1,40 @@
+"Previous Section"_Commands.html - "LAMMPS WWW Site"_lws -
+"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
+Section"_Speed.html :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Optional packages :h2
+
+This section gives an overview of the optional packages that extend
+LAMMPS functionality. Packages are groups of files that enable a
+specific set of features. For example, force fields for molecular
+systems or rigid-body 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. The "Build package"_Build_package.html doc page gives
+general info on how to install and un-install packages as part of the
+LAMMPS build process.
+
+<!-- RST
+
+.. toctree::
+ :maxdepth: 1
+
+ Packages_standard
+ Packages_user
+ Packages_details
+
+END_RST -->
+
+<!-- HTML_ONLY -->
+
+"Standard packages"_Packages_standard.html
+"User packages"_Packages_user.html
+"Details on each package"_Packages_details.html :ul
+
+<!-- END_HTML_ONLY -->
diff --git a/doc/src/Packages_details.txt b/doc/src/Packages_details.txt
new file mode 100644
index 0000000000000000000000000000000000000000..892774be383f379ade01ca6265e69ea6b6f4bcfc
--- /dev/null
+++ b/doc/src/Packages_details.txt
@@ -0,0 +1,2000 @@
+"Higher level section"_Packages.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Package details :h3
+
+Here is a brief description of all the standard and user packages in
+LAMMPS. It lists authors (if applicable) and summarizes the package
+contents. It has specific instructions on how to install the package,
+including, if necessary, info on how to download or build any extra
+library it requires. It also gives links to documentation, example
+scripts, and pictures/movies (if available) that illustrate use of the
+package.
+
+The majority of packages can be included in a LAMMPS build with a
+single setting (-D PGK_NAME for CMake) or command ("make yes-name" for
+make). See the "Build package"_Build_package.html doc page for more
+info. A few packages may require additional steps; this is indicated
+in the descriptions below. The "Build extras"_Build_extras.html doc
+page gives those details.
+
+NOTE: To see the complete list of commands a package adds to LAMMPS,
+you can examine the files in its src directory, e.g. "ls
+src/GRANULAR". Files with names that start with fix, compute, atom,
+pair, bond, angle, etc correspond to commands with the same style name
+as contained in the file name.
+
+"ASPHERE"_#PKG-ASPHERE,
+"BODY"_#PKG-BODY,
+"CLASS2"_#PKG-CLASS2,
+"COLLOID"_#PKG-COLLOID,
+"COMPRESS"_#PKG-COMPRESS,
+"CORESHELL"_#PKG-CORESHELL,
+"DIPOLE"_#PKG-DIPOLE,
+"GPU"_#PKG-GPU,
+"GRANULAR"_#PKG-GRANULAR,
+"KIM"_#PKG-KIM,
+"KOKKOS"_#PKG-KOKKOS,
+"KSPACE"_#PKG-KSPACE,
+"LATTE"_#PKG-LATTE,
+"MANYBODY"_#PKG-MANYBODY,
+"MC"_#PKG-MC,
+"MEAM"_#PKG-MEAM,
+"MISC"_#PKG-MISC,
+"MOLECULE"_#PKG-MOLECULE,
+"MPIIO"_#PKG-MPIIO,
+"MSCG"_#PKG-MSCG,
+"OPT"_#PKG-OPT,
+"PERI"_#PKG-PERI,
+"POEMS"_#PKG-POEMS,
+"PYTHON"_#PKG-PYTHON,
+"QEQ"_#PKG-QEQ,
+"REAX"_#PKG-REAX,
+"REPLICA"_#PKG-REPLICA2,
+"RIGID"_#PKG-RIGID,
+"SHOCK"_#PKG-SHOCK,
+"SNAP"_#PKG-SNAP,
+"SPIN"_#PKG-SPIN,
+"SRD"_#PKG-SRD,
+"VORONOI"_#PKG-VORONOI :tb(c=6,ea=c)
+
+"USER-ATC"_#PKG-USER-ATC,
+"USER-AWPMD"_#PKG-USER-AWPMD,
+"USER-BOCS"_#PKG-USER-BOCS,
+"USER-CGDNA"_#PKG-USER-CGDNA,
+"USER-CGSDK"_#PKG-USER-CGSDK,
+"USER-COLVARS"_#PKG-USER-COLVARS,
+"USER-DIFFRACTION"_#PKG-USER-DIFFRACTION,
+"USER-DPD"_#PKG-USER-DPD,
+"USER-DRUDE"_#PKG-USER-DRUDE,
+"USER-EFF"_#PKG-USER-EFF,
+"USER-FEP"_#PKG-USER-FEP,
+"USER-H5MD"_#PKG-USER-H5MD,
+"USER-INTEL"_#PKG-USER-INTEL,
+"USER-LB"_#PKG-USER-LB,
+"USER-MANIFOLD"_#PKG-USER-MANIFOLD,
+"USER-MEAMC"_#PKG-USER-MEAMC,
+"USER-MESO"_#PKG-USER-MESO,
+"USER-MGPT"_#PKG-USER-MGPT,
+"USER-MISC"_#PKG-USER-MISC,
+"USER-MOFFF"_#PKG-USER-MOFFF,
+"USER-MOLFILE"_#PKG-USER-MOLFILE,
+"USER-NETCDF"_#PKG-USER-NETCDF,
+"USER-OMP"_#PKG-USER-OMP,
+"USER-PHONON"_#PKG-USER-PHONON,
+"USER-QMMM"_#PKG-USER-QMMM,
+"USER-QTB"_#PKG-USER-QTB,
+"USER-QUIP"_#PKG-USER-QUIP,
+"USER-REAXC"_#PKG-USER-REAXC,
+"USER-SMD"_#PKG-USER-SMD,
+"USER-SMTBQ"_#PKG-USER-SMTBQ,
+"USER-SPH"_#PKG-USER-SPH,
+"USER-TALLY"_#PKG-USER-TALLY,
+"USER-UEF"_#PKG-USER-UEF,
+"USER-VTK"_#PKG-USER-VTK :tb(c=6,ea=c)
+
+:line
+
+ASPHERE package :link(PKG-ASPHERE),h4
+
+[Contents:]
+
+Computes, time-integration fixes, and pair styles for aspherical
+particle models including ellipsoids, 2d lines, and 3d triangles.
+
+[Supporting info:]
+
+src/ASPHERE: filenames -> commands
+"Howto spherical"_Howto_spherical.html
+"pair_style gayberne"_pair_gayberne.html
+"pair_style resquared"_pair_resquared.html
+"doc/PDF/pair_gayberne_extra.pdf"_PDF/pair_gayberne_extra.pdf
+"doc/PDF/pair_resquared_extra.pdf"_PDF/pair_resquared_extra.pdf
+examples/ASPHERE
+examples/ellipse
+http://lammps.sandia.gov/movies.html#line
+http://lammps.sandia.gov/movies.html#tri :ul
+
+:line
+
+BODY package :link(PKG-BODY),h4
+
+[Contents:]
+
+Body-style particles with internal structure. Computes,
+time-integration fixes, pair styles, as well as the body styles
+themselves. See the "Howto body"_Howto_body.html doc page for an
+overview.
+
+[Supporting info:]
+
+src/BODY filenames -> commands
+"Howto_body"_Howto_body.html
+"atom_style body"_atom_style.html
+"fix nve/body"_fix_nve_body.html
+"pair_style body/nparticle"_pair_body_nparticle.html
+examples/body :ul
+
+:line
+
+CLASS2 package :link(PKG-CLASS2),h4
+
+[Contents:]
+
+Bond, angle, dihedral, improper, and pair styles for the COMPASS
+CLASS2 molecular force field.
+
+[Supporting info:]
+
+src/CLASS2: filenames -> commands
+"bond_style class2"_bond_class2.html
+"angle_style class2"_angle_class2.html
+"dihedral_style class2"_dihedral_class2.html
+"improper_style class2"_improper_class2.html
+"pair_style lj/class2"_pair_class2.html :ul
+
+:line
+
+COLLOID package :link(PKG-COLLOID),h4
+
+[Contents:]
+
+Coarse-grained finite-size colloidal particles. Pair styles and fix
+wall styles for colloidal interactions. Includes the Fast Lubrication
+Dynamics (FLD) method for hydrodynamic interactions, which is a
+simplified approximation to Stokesian dynamics.
+
+[Authors:] This package includes Fast Lubrication Dynamics pair styles
+which were created by Amit Kumar and Michael Bybee from Jonathan
+Higdon's group at UIUC.
+
+[Supporting info:]
+
+src/COLLOID: filenames -> commands
+"fix wall/colloid"_fix_wall.html
+"pair_style colloid"_pair_colloid.html
+"pair_style yukawa/colloid"_pair_yukawa_colloid.html
+"pair_style brownian"_pair_brownian.html
+"pair_style lubricate"_pair_lubricate.html
+"pair_style lubricateU"_pair_lubricateU.html
+examples/colloid
+examples/srd :ul
+
+:line
+
+COMPRESS package :link(PKG-COMPRESS),h4
+
+[Contents:]
+
+Compressed output of dump files via the zlib compression library,
+using dump styles with a "gz" in their style name.
+
+To use this package you must have the zlib compression library
+available on your system.
+
+[Author:] Axel Kohlmeyer (Temple U).
+
+[Install:]
+
+This package has "specific installation
+instructions"_Build_extras.html#gpu on the "Build
+extras"_Build_extras.html doc page.
+
+[Supporting info:]
+
+src/COMPRESS: filenames -> commands
+src/COMPRESS/README
+lib/compress/README
+"dump atom/gz"_dump.html
+"dump cfg/gz"_dump.html
+"dump custom/gz"_dump.html
+"dump xyz/gz"_dump.html :ul
+
+:line
+
+CORESHELL package :link(PKG-CORESHELL),h4
+
+[Contents:]
+
+Compute and pair styles that implement the adiabatic core/shell model
+for polarizability. The pair styles augment Born, Buckingham, and
+Lennard-Jones styles with core/shell capabilities. The "compute
+temp/cs"_compute_temp_cs.html command calculates the temperature of a
+system with core/shell particles. See the "Howto
+coreshell"_Howto_coreshell.html doc page for an overview of how to use
+this package.
+
+[Author:] Hendrik Heenen (Technical U of Munich).
+
+[Supporting info:]
+
+src/CORESHELL: filenames -> commands
+"Howto coreshell"_Howto_coreshell.html
+"Howto polarizable"_Howto_polarizable.html
+"compute temp/cs"_compute_temp_cs.html
+"pair_style born/coul/long/cs"_pair_cs.html
+"pair_style buck/coul/long/cs"_pair_cs.html
+"pair_style lj/cut/coul/long/cs"_pair_lj.html
+examples/coreshell :ul
+
+:line
+
+DIPOLE package :link(PKG-DIPOLE),h4
+
+[Contents:]
+
+An atom style and several pair styles for point dipole models with
+short-range or long-range interactions.
+
+[Supporting info:]
+
+src/DIPOLE: filenames -> commands
+"atom_style dipole"_atom_style.html
+"pair_style lj/cut/dipole/cut"_pair_dipole.html
+"pair_style lj/cut/dipole/long"_pair_dipole.html
+"pair_style lj/long/dipole/long"_pair_dipole.html
+examples/dipole :ul
+
+:line
+
+GPU package :link(PKG-GPU),h4
+
+[Contents:]
+
+Dozens of pair styles and a version of the PPPM long-range Coulombic
+solver optimized for GPUs. All such styles have a "gpu" as a suffix
+in their style name. The GPU code can be compiled with either CUDA or
+OpenCL, however the OpenCL variants are no longer actively maintained
+and only the CUDA versions are regularly tested. The "Speed
+gpu"_Speed_gpu.html doc page gives details of what hardware and GPU
+software is required on your system, and details on how to build and
+use this package. Its styles can be invoked at run time via the "-sf
+gpu" or "-suffix gpu" "command-line switches"_Run_options.html. See
+also the "KOKKOS"_#PKG-KOKKOS package, which has GPU-enabled styles.
+
+[Authors:] Mike Brown (Intel) while at Sandia and ORNL and Trung Nguyen
+(Northwestern U) while at ORNL.
+
+[Install:]
+
+This package has "specific installation
+instructions"_Build_extras.html#gpu on the "Build
+extras"_Build_extras.html doc page.
+
+[Supporting info:]
+
+src/GPU: filenames -> commands
+src/GPU/README
+lib/gpu/README
+"Speed packages"_Speed_packages.html
+"Speed gpu"_Speed_gpu.html
+"Section 2.6 -sf gpu"_Run_options.html
+"Section 2.6 -pk gpu"_Run_options.html
+"package gpu"_package.html
+"Commands all"_Commands_all.html pages (pair,kspace) for styles followed by (g)
+"Benchmarks page"_http://lammps.sandia.gov/bench.html of web site :ul
+
+:line
+
+GRANULAR package :link(PKG-GRANULAR),h4
+
+[Contents:]
+
+Pair styles and fixes for finite-size granular particles, which
+interact with each other and boundaries via frictional and dissipative
+potentials.
+
+[Supporting info:]
+
+src/GRANULAR: filenames -> commands
+"Howto granular"_Howto_granular.html
+"fix pour"_fix_pour.html
+"fix wall/gran"_fix_wall_gran.html
+"pair_style gran/hooke"_pair_gran.html
+"pair_style gran/hertz/history"_pair_gran.html
+examples/granregion
+examples/pour
+bench/in.chute
+http://lammps.sandia.gov/pictures.html#jamming
+http://lammps.sandia.gov/movies.html#hopper
+http://lammps.sandia.gov/movies.html#dem
+http://lammps.sandia.gov/movies.html#brazil
+http://lammps.sandia.gov/movies.html#granregion :ul
+
+:line
+
+KIM package :link(PKG-KIM),h4
+
+[Contents:]
+
+A "pair_style kim"_pair_kim.html command which is a wrapper on the
+Knowledge Base for Interatomic Models (KIM) repository of interatomic
+potentials, enabling any of them to be used in LAMMPS simulations.
+
+To use this package you must have the KIM library available on your
+system.
+
+Information about the KIM project can be found at its website:
+https://openkim.org. The KIM project is led by Ellad Tadmor and Ryan
+Elliott (U Minnesota) and James Sethna (Cornell U).
+
+[Authors:] Ryan Elliott (U Minnesota) is the main developer for the KIM
+API which the "pair_style kim"_pair_kim.html command uses. He
+developed the pair style in collaboration with Valeriu Smirichinski (U
+Minnesota).
+
+[Install:]
+
+This package has "specific installation
+instructions"_Build_extras.html#gpu on the "Build
+extras"_Build_extras.html doc page.
+
+[Supporting info:]
+
+src/KIM: filenames -> commands
+src/KIM/README
+lib/kim/README
+"pair_style kim"_pair_kim.html
+examples/kim :ul
+
+:line
+
+KOKKOS package :link(PKG-KOKKOS),h4
+
+[Contents:]
+
+Dozens of atom, pair, bond, angle, dihedral, improper, fix, compute
+styles adapted to compile using the Kokkos library which can convert
+them to OpenMP or CUDA code so that they run efficiently on multicore
+CPUs, KNLs, or GPUs. All the styles have a "kk" as a suffix in their
+style name. The "Speed kokkos"_Speed_kokkos.html doc page gives
+details of what hardware and software is required on your system, and
+how to build and use this package. Its styles can be invoked at run
+time via the "-sf kk" or "-suffix kk" "command-line
+switches"_Run_options.html. Also see the "GPU"_#PKG-GPU, "OPT"_#PKG-OPT,
+"USER-INTEL"_#PKG-USER-INTEL, and "USER-OMP"_#PKG-USER-OMP packages, which
+have styles optimized for CPUs, KNLs, and GPUs.
+
+You must have a C++11 compatible compiler to use this package.
+KOKKOS makes extensive use of advanced C++ features, which can
+expose compiler bugs, especially when compiling for maximum
+performance at high optimization levels. Please see the file
+lib/kokkos/README for a list of compilers and their respective
+platforms, that are known to work.
+
+[Authors:] The KOKKOS package was created primarily by Christian Trott
+and Stan Moore (Sandia), with contributions from other folks as well.
+It uses the open-source "Kokkos library"_https://github.com/kokkos
+which was developed by Carter Edwards, Christian Trott, and others at
+Sandia, and which is included in the LAMMPS distribution in
+lib/kokkos.
+
+[Install:]
+
+This package has "specific installation
+instructions"_Build_extras.html#gpu on the "Build
+extras"_Build_extras.html doc page.
+
+[Supporting info:]
+
+src/KOKKOS: filenames -> commands
+src/KOKKOS/README
+lib/kokkos/README
+"Speed packages"_Speed_packages.html
+"Speed kokkos"_Speed_kokkos.html
+"Section 2.6 -k on ..."_Run_options.html
+"Section 2.6 -sf kk"_Run_options.html
+"Section 2.6 -pk kokkos"_Run_options.html
+"package kokkos"_package.html
+"Commands all"_Commands_all.html pages (fix,compute,pair,etc) for styles followed by (k)
+"Benchmarks page"_http://lammps.sandia.gov/bench.html of web site :ul
+
+:line
+
+KSPACE package :link(PKG-KSPACE),h4
+
+[Contents:]
+
+A variety of long-range Coulombic solvers, as well as pair styles
+which compute the corresponding short-range pairwise Coulombic
+interactions. These include Ewald, particle-particle particle-mesh
+(PPPM), and multilevel summation method (MSM) solvers.
+
+[Install:]
+
+Building with this package requires a 1d FFT library be present on
+your system for use by the PPPM solvers. This can be the KISS FFT
+library provided with LAMMPS, 3rd party libraries like FFTW, or a
+vendor-supplied FFT library. See the "Build
+settings"_Build_settings.html doc page for details on how to select
+different FFT options for your LAMPMS build.
+
+[Supporting info:]
+
+src/KSPACE: filenames -> commands
+"kspace_style"_kspace_style.html
+"doc/PDF/kspace.pdf"_PDF/kspace.pdf
+"Howto tip3p"_Howto_tip3p.html
+"Howto tip4p"_Howto_tip4p.html
+"Howto spc"_Howto_spc.html
+"pair_style coul"_pair_coul.html
+"Commands pair"_Commands_pair.html page for styles with "long" or "msm" in name
+examples/peptide
+bench/in.rhodo :ul
+
+:line
+
+LATTE package :link(PKG-LATTE),h4
+
+[Contents:]
+
+A fix command which wraps the LATTE DFTB code, so that molecular
+dynamics can be run with LAMMPS using density-functional tight-binding
+quantum forces calculated by LATTE.
+
+More information on LATTE can be found at this web site:
+"https://github.com/lanl/LATTE"_latte_home. A brief technical
+description is given with the "fix latte"_fix_latte.html command.
+
+:link(latte_home,https://github.com/lanl/LATTE)
+
+[Authors:] Christian Negre (LANL) and Steve Plimpton (Sandia). LATTE
+itself is developed at Los Alamos National Laboratory by Marc
+Cawkwell, Anders Niklasson, and Christian Negre.
+
+[Install:]
+
+This package has "specific installation
+instructions"_Build_extras.html#gpu on the "Build
+extras"_Build_extras.html doc page.
+
+[Supporting info:]
+
+src/LATTE: filenames -> commands
+src/LATTE/README
+lib/latte/README
+"fix latte"_fix_latte.html
+examples/latte
+"LAMMPS-LATTE tutorial"_https://github.com/lanl/LATTE/wiki/Using-LATTE-through-LAMMPS :ul
+
+:line
+
+MANYBODY package :link(PKG-MANYBODY),h4
+
+[Contents:]
+
+A variety of manybody and bond-order potentials. These include
+(AI)REBO, BOP, EAM, EIM, Stillinger-Weber, and Tersoff potentials.
+
+[Supporting info:]
+
+src/MANYBODY: filenames -> commands
+"Commands pair"_Commands_pair.html page
+examples/comb
+examples/eim
+examples/nb3d
+examples/shear
+examples/streitz
+examples/vashishta
+bench/in.eam :ul
+
+:line
+
+MC package :link(PKG-MC),h4
+
+[Contents:]
+
+Several fixes and a pair style that have Monte Carlo (MC) or MC-like
+attributes. These include fixes for creating, breaking, and swapping
+bonds, for performing atomic swaps, and performing grand-canonical MC
+(GCMC) in conjuction with dynamics.
+
+[Supporting info:]
+
+src/MC: filenames -> commands
+"fix atom/swap"_fix_atom_swap.html
+"fix bond/break"_fix_bond_break.html
+"fix bond/create"_fix_bond_create.html
+"fix bond/swap"_fix_bond_swap.html
+"fix gcmc"_fix_gcmc.html
+"pair_style dsmc"_pair_dsmc.html
+http://lammps.sandia.gov/movies.html#gcmc :ul
+
+:line
+
+MEAM package :link(PKG-MEAM),h4
+
+[Contents:]
+
+A pair style for the modified embedded atom (MEAM) potential.
+
+Please note that the use of the MEAM package is discouraged as
+it has been superseded by the "USER-MEAMC"_#PKG-USER-MEAMC package,
+which is a direct translation of the MEAM package to C++.
+USER-MEAMC contains additional optimizations making it run faster
+than MEAM on most machines, while providing the identical features
+and user interface.
+
+[Author:] Greg Wagner (Northwestern U) while at Sandia.
+
+[Install:]
+
+This package has "specific installation
+instructions"_Build_extras.html#gpu on the "Build
+extras"_Build_extras.html doc page.
+
+NOTE: You should test building the MEAM library with both the Intel
+and GNU compilers to see if a simulation runs faster with one versus
+the other on your system.
+
+[Supporting info:]
+
+src/MEAM: filenames -> commands
+src/meam/README
+lib/meam/README
+"pair_style meam"_pair_meam.html
+examples/meam :ul
+
+:line
+
+MISC package :link(PKG-MISC),h4
+
+[Contents:]
+
+A variety of compute, fix, pair, dump styles with specialized
+capabilities that don't align with other packages. Do a directory
+listing, "ls src/MISC", to see the list of commands.
+
+NOTE: the MISC package contains styles that require using the
+-restrict flag, when compiling with Intel compilers.
+
+[Supporting info:]
+
+src/MISC: filenames -> commands
+"compute ti"_compute_ti.html
+"fix evaporate"_fix_evaporate.html
+"fix orient/fcc"_fix_orient.html
+"fix ttm"_fix_ttm.html
+"fix thermal/conductivity"_fix_thermal_conductivity.html
+"fix viscosity"_fix_viscosity.html
+examples/KAPPA
+examples/VISCOSITY
+http://lammps.sandia.gov/pictures.html#ttm
+http://lammps.sandia.gov/movies.html#evaporation :ul
+
+:line
+
+MOLECULE package :link(PKG-MOLECULE),h4
+
+[Contents:]
+
+A large number of atom, pair, bond, angle, dihedral, improper styles
+that are used to model molecular systems with fixed covalent bonds.
+The pair styles include the Dreiding (hydrogen-bonding) and CHARMM
+force fields, and a TIP4P water model.
+
+[Supporting info:]
+
+src/MOLECULE: filenames -> commands
+"atom_style"_atom_style.html
+"bond_style"_bond_style.html
+"angle_style"_angle_style.html
+"dihedral_style"_dihedral_style.html
+"improper_style"_improper_style.html
+"pair_style hbond/dreiding/lj"_pair_hbond_dreiding.html
+"pair_style lj/charmm/coul/charmm"_pair_charmm.html
+"Howto bioFF"_Howto_bioFF.html
+examples/cmap
+examples/dreiding
+examples/micelle,
+examples/peptide
+bench/in.chain
+bench/in.rhodo :ul
+
+:line
+
+MPIIO package :link(PKG-MPIIO),h4
+
+[Contents:]
+
+Support for parallel output/input of dump and restart files via the
+MPIIO library. It adds "dump styles"_dump.html with a "mpiio" in
+their style name. Restart files with an ".mpiio" suffix are also
+written and read in parallel.
+
+[Supporting info:]
+
+src/MPIIO: filenames -> commands
+"dump"_dump.html
+"restart"_restart.html
+"write_restart"_write_restart.html
+"read_restart"_read_restart.html :ul
+
+:line
+
+MSCG package :link(PKG-mscg),h4
+
+[Contents:]
+
+A "fix mscg"_fix_mscg.html command which can parameterize a
+Multi-Scale Coarse-Graining (MSCG) model using the open-source "MS-CG
+library"_mscg_home.
+
+:link(mscg_home,https://github.com/uchicago-voth/MSCG-release)
+
+To use this package you must have the MS-CG library available on your
+system.
+
+[Authors:] The fix was written by Lauren Abbott (Sandia). The MS-CG
+library was developed by Jacob Wagner in Greg Voth's group at the
+University of Chicago.
+
+[Install:]
+
+This package has "specific installation
+instructions"_Build_extras.html#gpu on the "Build
+extras"_Build_extras.html doc page.
+
+[Supporting info:]
+
+src/MSCG: filenames -> commands
+src/MSCG/README
+lib/mscg/README
+examples/mscg :ul
+
+:line
+
+OPT package :link(PKG-OPT),h4
+
+[Contents:]
+
+A handful of pair styles which are optimized for improved CPU
+performance on single or multiple cores. These include EAM, LJ,
+CHARMM, and Morse potentials. The styles have an "opt" suffix in
+their style name. The "Speed opt"_Speed_opt.html doc page gives
+details of how to build and use this package. Its styles can be
+invoked at run time via the "-sf opt" or "-suffix opt" "command-line
+switches"_Run_options.html. See also the "KOKKOS"_#PKG-KOKKOS,
+"USER-INTEL"_#PKG-USER-INTEL, and "USER-OMP"_#PKG-USER-OMP packages, which
+have styles optimized for CPU performance.
+
+[Authors:] James Fischer (High Performance Technologies), David Richie,
+and Vincent Natoli (Stone Ridge Technolgy).
+
+[Install:]
+
+This package has "specific installation
+instructions"_Build_extras.html#gpu on the "Build
+extras"_Build_extras.html doc page.
+
+[Supporting info:]
+
+src/OPT: filenames -> commands
+"Speed packages"_Speed_packages.html
+"Speed opt"_Speed_opt.html
+"Section 2.6 -sf opt"_Run_options.html
+"Commands pair"_Commands_pair.html for styles followed by (t)
+"Benchmarks page"_http://lammps.sandia.gov/bench.html of web site :ul
+
+:line
+
+PERI package :link(PKG-PERI),h4
+
+[Contents:]
+
+An atom style, several pair styles which implement different
+Peridynamics materials models, and several computes which calculate
+diagnostics. Peridynamics is a a particle-based meshless continuum
+model.
+
+[Authors:] The original package was created by Mike Parks (Sandia).
+Additional Peridynamics models were added by Rezwanur Rahman and John
+Foster (UTSA).
+
+[Supporting info:]
+
+src/PERI: filenames -> commands
+"doc/PDF/PDLammps_overview.pdf"_PDF/PDLammps_overview.pdf
+"doc/PDF/PDLammps_EPS.pdf"_PDF/PDLammps_EPS.pdf
+"doc/PDF/PDLammps_VES.pdf"_PDF/PDLammps_VES.pdf
+"atom_style peri"_atom_style.html
+"pair_style peri/*"_pair_peri.html
+"compute damage/atom"_compute_damage_atom.html
+"compute plasticity/atom"_compute_plasticity_atom.html
+examples/peri
+http://lammps.sandia.gov/movies.html#peri :ul
+
+:line
+
+POEMS package :link(PKG-POEMS),h4
+
+[Contents:]
+
+A fix that wraps the Parallelizable Open source Efficient Multibody
+Software (POEMS) library, which is able to simulate the dynamics of
+articulated body systems. These are systems with multiple rigid
+bodies (collections of particles) whose motion is coupled by
+connections at hinge points.
+
+[Author:] Rudra Mukherjee (JPL) while at RPI.
+
+[Install:]
+
+This package has "specific installation
+instructions"_Build_extras.html#gpu on the "Build
+extras"_Build_extras.html doc page.
+
+[Supporting info:]
+
+src/POEMS: filenames -> commands
+src/POEMS/README
+lib/poems/README
+"fix poems"_fix_poems.html
+examples/rigid :ul
+
+:line
+
+PYTHON package :link(PKG-PYTHON),h4
+
+[Contents:]
+
+A "python"_python.html command which allow you to execute Python code
+from a LAMMPS input script. The code can be in a separate file or
+embedded in the input script itself. See the "Python
+call"_Python_call.html doc page for an overview of using Python from
+LAMMPS in this manner and all the "Python"_Python_head.html doc pages
+for other ways to use LAMMPS and Python together.
+
+NOTE: Building with the PYTHON package assumes 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 the
+lib/python/README for more details.
+
+[Install:]
+
+This package has "specific installation
+instructions"_Build_extras.html#gpu on the "Build
+extras"_Build_extras.html doc page.
+
+[Supporting info:]
+
+src/PYTHON: filenames -> commands
+"Python call"_Python_head.html
+lib/python/README
+examples/python :ul
+
+:line
+
+QEQ package :link(PKG-QEQ),h4
+
+[Contents:]
+
+Several fixes for performing charge equilibration (QEq) via different
+algorithms. These can be used with pair styles that perform QEq as
+part of their formulation.
+
+[Supporting info:]
+
+src/QEQ: filenames -> commands
+"fix qeq/*"_fix_qeq.html
+examples/qeq
+examples/streitz :ul
+
+:line
+
+REAX package :link(PKG-REAX),h4
+
+[Contents:]
+
+NOTE: the use of the REAX package is discouraged, as it is no longer
+maintained. Please use the "USER-REAXC"_#PKG-USER-REAXC package instead,
+and possibly the KOKKOS enabled variant of that, which has a more robust
+memory management.
+
+A pair style which wraps a Fortran library which implements the ReaxFF
+potential, which is a universal reactive force field. Also included is
+a "fix reax/bonds"_fix_reax_bonds.html command for monitoring molecules
+as bonds are created and destroyed.
+
+[Author:] Aidan Thompson (Sandia).
+
+[Install:]
+
+This package has "specific installation
+instructions"_Build_extras.html#gpu on the "Build
+extras"_Build_extras.html doc page.
+
+[Supporting info:]
+
+src/REAX: filenames -> commands
+lib/reax/README
+"pair_style reax"_pair_reax.html
+"fix reax/bonds"_fix_reax_bonds.html
+examples/reax :ul
+
+:line
+
+REPLICA package :link(PKG-REPLICA2),h4
+
+[Contents:]
+
+A collection of multi-replica methods which can be used when running
+multiple LAMMPS simulations (replicas). See the "Howto
+replica"_Howto_replica.html doc page for an overview of how to run
+multi-replica simulations in LAMMPS. Methods in the package include
+nudged elastic band (NEB), parallel replica dynamics (PRD),
+temperature accelerated dynamics (TAD), parallel tempering, and a
+verlet/split algorithm for performing long-range Coulombics on one set
+of processors, and the remainder of the force field calcalation on
+another set.
+
+[Supporting info:]
+
+src/REPLICA: filenames -> commands
+"Howto replica"_Howto_replica.html
+"neb"_neb.html
+"prd"_prd.html
+"tad"_tad.html
+"temper"_temper.html,
+"run_style verlet/split"_run_style.html
+examples/neb
+examples/prd
+examples/tad :ul
+
+:line
+
+RIGID package :link(PKG-RIGID),h4
+
+[Contents:]
+
+Fixes which enforce rigid constraints on collections of atoms or
+particles. This includes SHAKE and RATTLE, as well as varous
+rigid-body integrators for a few large bodies or many small bodies.
+Also several computes which calculate properties of rigid bodies.
+
+[Supporting info:]
+
+src/RIGID: filenames -> commands
+"compute erotate/rigid"_compute_erotate_rigid.html
+fix shake"_fix_shake.html
+"fix rattle"_fix_shake.html
+"fix rigid/*"_fix_rigid.html
+examples/ASPHERE
+examples/rigid
+bench/in.rhodo
+http://lammps.sandia.gov/movies.html#box
+http://lammps.sandia.gov/movies.html#star :ul
+
+:line
+
+SHOCK package :link(PKG-SHOCK),h4
+
+[Contents:]
+
+Fixes for running impact simulations where a shock-wave passes through
+a material.
+
+[Supporting info:]
+
+src/SHOCK: filenames -> commands
+"fix append/atoms"_fix_append_atoms.html
+"fix msst"_fix_msst.html
+"fix nphug"_fix_nphug.html
+"fix wall/piston"_fix_wall_piston.html
+examples/hugoniostat
+examples/msst :ul
+
+:line
+
+SNAP package :link(PKG-SNAP),h4
+
+[Contents:]
+
+A pair style for the spectral neighbor analysis potential (SNAP).
+SNAP is methodology for deriving a highly accurate classical potential
+fit to a large archive of quantum mechanical (DFT) data. Also several
+computes which analyze attributes of the potential.
+
+[Author:] Aidan Thompson (Sandia).
+
+[Supporting info:]
+
+src/SNAP: filenames -> commands
+"pair_style snap"_pair_snap.html
+"compute sna/atom"_compute_sna_atom.html
+"compute snad/atom"_compute_sna_atom.html
+"compute snav/atom"_compute_sna_atom.html
+examples/snap :ul
+
+:line
+
+SPIN package :link(PKG-SPIN),h4
+
+[Contents:]
+
+Model atomic magnetic spins classically, coupled to atoms moving in
+the usual manner via MD. Various pair, fix, and compute styles.
+
+[Author:] Julian Tranchida (Sandia).
+
+[Supporting info:]
+
+src/SPIN: filenames -> commands
+"Howto spins"_Howto_spins.html
+"pair_style spin/dmi"_pair_spin_dmi.html
+"pair_style spin/exchange"_pair_spin_exchange.html
+"pair_style spin/magelec"_pair_spin_magelec.html
+"pair_style spin/neel"_pair_spin_neel.html
+"fix nve/spin"_fix_nve_spin.html
+"fix precession/spin"_fix_precession_spin.html
+"compute spin"_compute_spin.html
+examples/SPIN :ul
+
+:line
+
+SRD package :link(PKG-SRD),h4
+
+[Contents:]
+
+A pair of fixes which implement the Stochastic Rotation Dynamics (SRD)
+method for coarse-graining of a solvent, typically around large
+colloidal particles.
+
+[Supporting info:]
+
+src/SRD: filenames -> commands
+"fix srd"_fix_srd.html
+"fix wall/srd"_fix_wall_srd.html
+examples/srd
+examples/ASPHERE
+http://lammps.sandia.gov/movies.html#tri
+http://lammps.sandia.gov/movies.html#line
+http://lammps.sandia.gov/movies.html#poly :ul
+
+:line
+
+VORONOI package :link(PKG-VORONOI),h4
+
+[Contents:]
+
+A compute command which calculates the Voronoi tesselation of a
+collection of atoms by wrapping the "Voro++ library"_voro_home. This
+can be used to calculate the local volume or each atoms or its near
+neighbors.
+
+:link(voro_home,http://math.lbl.gov/voro++)
+
+To use this package you must have the Voro++ library available on your
+system.
+
+[Author:] Daniel Schwen (INL) while at LANL. The open-source Voro++
+library was written by Chris Rycroft (Harvard U) while at UC Berkeley
+and LBNL.
+
+[Install:]
+
+This package has "specific installation
+instructions"_Build_extras.html#gpu on the "Build
+extras"_Build_extras.html doc page.
+
+[Supporting info:]
+
+src/VORONOI: filenames -> commands
+src/VORONOI/README
+lib/voronoi/README
+"compute voronoi/atom"_compute_voronoi_atom.html
+examples/voronoi :ul
+
+:line
+
+USER-ATC package :link(PKG-USER-ATC),h4
+
+[Contents:]
+
+ATC stands for atoms-to-continuum. This package implements a "fix
+atc"_fix_atc.html command to either couple molecular dynamics with
+continuum finite element equations or perform on-the-fly conversion of
+atomic information to continuum fields.
+
+[Authors:] Reese Jones, Jeremy Templeton, Jon Zimmerman (Sandia).
+
+[Install:]
+
+This package has "specific installation
+instructions"_Build_extras.html#gpu on the "Build
+extras"_Build_extras.html doc page.
+
+[Supporting info:]
+
+src/USER-ATC: filenames -> commands
+src/USER-ATC/README
+"fix atc"_fix_atc.html
+examples/USER/atc
+http://lammps.sandia.gov/pictures.html#atc :ul
+
+:line
+
+USER-AWPMD package :link(PKG-USER-AWPMD),h4
+
+[Contents:]
+
+AWPMD stands for Antisymmetrized Wave Packet Molecular Dynamics. This
+package implements an atom, pair, and fix style which allows electrons
+to be treated as explicit particles in a classical molecular dynamics
+model.
+
+[Author:] Ilya Valuev (JIHT, Russia).
+
+[Install:]
+
+This package has "specific installation
+instructions"_Build_extras.html#gpu on the "Build
+extras"_Build_extras.html doc page.
+
+[Supporting info:]
+
+src/USER-AWPMD: filenames -> commands
+src/USER-AWPMD/README
+"pair_style awpmd/cut"_pair_awpmd.html
+examples/USER/awpmd :ul
+
+:line
+
+USER-BOCS package :link(PKG-USER-BOCS),h4
+
+[Contents:]
+
+This package provides "fix bocs"_fix_bocs.html, a modified version
+of "fix npt"_fix_nh.html which includes the pressure correction to
+the barostat as outlined in:
+
+N. J. H. Dunn and W. G. Noid, "Bottom-up coarse-grained models that
+accurately describe the structure, pressure, and compressibility of
+molecular liquids," J. Chem. Phys. 143, 243148 (2015).
+
+[Authors:] Nicholas J. H. Dunn and Michael R. DeLyser (The
+Pennsylvania State University)
+
+[Supporting info:]
+
+The USER-BOCS user package for LAMMPS is part of the BOCS software package:
+"https://github.com/noid-group/BOCS"_https://github.com/noid-group/BOCS
+
+See the following reference for information about the entire package:
+
+Dunn, NJH; Lebold, KM; DeLyser, MR; Rudzinski, JF; Noid, WG.
+"BOCS: Bottom-Up Open-Source Coarse-Graining Software."
+J. Phys. Chem. B. 122, 13, 3363-3377 (2018).
+
+Example inputs are in the examples/USER/bocs folder.
+
+:line
+
+USER-CGDNA package :link(PKG-USER-CGDNA),h4
+
+[Contents:]
+
+Several pair styles, a bond style, and integration fixes for
+coarse-grained models of single- and double-stranded DNA based on the
+oxDNA model of Doye, Louis and Ouldridge at the University of Oxford.
+This includes Langevin-type rigid-body integrators with improved
+stability.
+
+[Author:] Oliver Henrich (University of Strathclyde, Glasgow).
+
+[Supporting info:]
+
+src/USER-CGDNA: filenames -> commands
+/src/USER-CGDNA/README
+"pair_style oxdna/*"_pair_oxdna.html
+"pair_style oxdna2/*"_pair_oxdna2.html
+"bond_style oxdna/*"_bond_oxdna.html
+"bond_style oxdna2/*"_bond_oxdna.html
+"fix nve/dotc/langevin"_fix_nve_dotc_langevin.html :ul
+
+:line
+
+USER-CGSDK package :link(PKG-USER-CGSDK),h4
+
+[Contents:]
+
+Several pair styles and an angle style which implement the
+coarse-grained SDK model of Shinoda, DeVane, and Klein which enables
+simulation of ionic liquids, electrolytes, lipids and charged amino
+acids.
+
+[Author:] Axel Kohlmeyer (Temple U).
+
+[Supporting info:]
+
+src/USER-CGSDK: filenames -> commands
+src/USER-CGSDK/README
+"pair_style lj/sdk/*"_pair_sdk.html
+"angle_style sdk"_angle_sdk.html
+examples/USER/cgsdk
+http://lammps.sandia.gov/pictures.html#cg :ul
+
+:line
+
+USER-COLVARS package :link(PKG-USER-COLVARS),h4
+
+[Contents:]
+
+COLVARS stands for collective variables, which can be used to
+implement various enhanced sampling methods, including Adaptive
+Biasing Force, Metadynamics, Steered MD, Umbrella Sampling and
+Restraints. A "fix colvars"_fix_colvars.html command is implemented
+which wraps a COLVARS library, which implements these methods.
+simulations.
+
+[Authors:] The COLVARS library is written and maintained by
+Giacomo Fiorin (ICMS, Temple University, Philadelphia, PA, USA)
+and Jerome Henin (LISM, CNRS, Marseille, France), originally for
+the NAMD MD code, but with portability in mind. Axel Kohlmeyer
+(Temple U) provided the interface to LAMMPS.
+
+[Install:]
+
+This package has "specific installation
+instructions"_Build_extras.html#gpu on the "Build
+extras"_Build_extras.html doc page.
+
+[Supporting info:]
+
+src/USER-COLVARS: filenames -> commands
+"doc/PDF/colvars-refman-lammps.pdf"_PDF/colvars-refman-lammps.pdf
+src/USER-COLVARS/README
+lib/colvars/README
+"fix colvars"_fix_colvars.html
+examples/USER/colvars :ul
+
+:line
+
+USER-DIFFRACTION package :link(PKG-USER-DIFFRACTION),h4
+
+[Contents:]
+
+Two computes and a fix for calculating x-ray and electron diffraction
+intensities based on kinematic diffraction theory.
+
+[Author:] Shawn Coleman while at the U Arkansas.
+
+[Supporting info:]
+
+src/USER-DIFFRACTION: filenames -> commands
+"compute saed"_compute_saed.html
+"compute xrd"_compute_xrd.html
+"fix saed/vtk"_fix_saed_vtk.html
+examples/USER/diffraction :ul
+
+:line
+
+USER-DPD package :link(PKG-USER-DPD),h4
+
+[Contents:]
+
+DPD stands for dissipative particle dynamics. This package implements
+coarse-grained DPD-based models for energetic, reactive molecular
+crystalline materials. It includes many pair styles specific to these
+systems, including for reactive DPD, where each particle has internal
+state for multiple species and a coupled set of chemical reaction ODEs
+are integrated each timestep. Highly accurate time integrators for
+isothermal, isoenergetic, isobaric and isenthalpic conditions are
+included. These enable long timesteps via the Shardlow splitting
+algorithm.
+
+[Authors:] Jim Larentzos (ARL), Tim Mattox (Engility Corp), and and John
+Brennan (ARL).
+
+[Supporting info:]
+
+src/USER-DPD: filenames -> commands
+/src/USER-DPD/README
+"compute dpd"_compute_dpd.html
+"compute dpd/atom"_compute_dpd_atom.html
+"fix eos/cv"_fix_eos_table.html
+"fix eos/table"_fix_eos_table.html
+"fix eos/table/rx"_fix_eos_table_rx.html
+"fix shardlow"_fix_shardlow.html
+"fix rx"_fix_rx.html
+"pair_style table/rx"_pair_table_rx.html
+"pair_style dpd/fdt"_pair_dpd_fdt.html
+"pair_style dpd/fdt/energy"_pair_dpd_fdt.html
+"pair_style exp6/rx"_pair_exp6_rx.html
+"pair_style multi/lucy"_pair_multi_lucy.html
+"pair_style multi/lucy/rx"_pair_multi_lucy_rx.html
+examples/USER/dpd :ul
+
+:line
+
+USER-DRUDE package :link(PKG-USER-DRUDE),h4
+
+[Contents:]
+
+Fixes, pair styles, and a compute to simulate thermalized Drude
+oscillators as a model of polarization. See the "Howto
+drude"_Howto_drude.html and "Howto drude2"_Howto_drude2.html doc pages
+for an overview of how to use the package. There are auxiliary tools
+for using this package in tools/drude.
+
+[Authors:] Alain Dequidt (U Blaise Pascal Clermont-Ferrand), Julien
+Devemy (CNRS), and Agilio Padua (U Blaise Pascal).
+
+[Supporting info:]
+
+src/USER-DRUDE: filenames -> commands
+"Howto drude"_Howto_drude.html
+"Howto drude2"_Howto_drude2.html
+"Howto polarizable"_Howto_polarizable.html
+src/USER-DRUDE/README
+"fix drude"_fix_drude.html
+"fix drude/transform/*"_fix_drude_transform.html
+"compute temp/drude"_compute_temp_drude.html
+"pair_style thole"_pair_thole.html
+"pair_style lj/cut/thole/long"_pair_thole.html
+examples/USER/drude
+tools/drude :ul
+
+:line
+
+USER-EFF package :link(PKG-USER-EFF),h4
+
+[Contents:]
+
+EFF stands for electron force field which allows a classical MD code
+to model electrons as particles of variable radius. This package
+contains atom, pair, fix and compute styles which implement the eFF as
+described in A. Jaramillo-Botero, J. Su, Q. An, and W.A. Goddard III,
+JCC, 2010. The eFF potential was first introduced by Su and Goddard,
+in 2007. There are auxiliary tools for using this package in
+tools/eff; see its README file.
+
+[Author:] Andres Jaramillo-Botero (CalTech).
+
+[Supporting info:]
+
+src/USER-EFF: filenames -> commands
+src/USER-EFF/README
+"atom_style electron"_atom_style.html
+"fix nve/eff"_fix_nve_eff.html
+"fix nvt/eff"_fix_nh_eff.html
+"fix npt/eff"_fix_nh_eff.html
+"fix langevin/eff"_fix_langevin_eff.html
+"compute temp/eff"_compute_temp_eff.html
+"pair_style eff/cut"_pair_eff.html
+"pair_style eff/inline"_pair_eff.html
+examples/USER/eff
+tools/eff/README
+tools/eff
+http://lammps.sandia.gov/movies.html#eff :ul
+
+:line
+
+USER-FEP package :link(PKG-USER-FEP),h4
+
+[Contents:]
+
+FEP stands for free energy perturbation. This package provides
+methods for performing FEP simulations by using a "fix
+adapt/fep"_fix_adapt_fep.html command with soft-core pair potentials,
+which have a "soft" in their style name. There are auxiliary tools
+for using this package in tools/fep; see its README file.
+
+[Author:] Agilio Padua (Universite Blaise Pascal Clermont-Ferrand)
+
+[Supporting info:]
+
+src/USER-FEP: filenames -> commands
+src/USER-FEP/README
+"fix adapt/fep"_fix_adapt_fep.html
+"compute fep"_compute_fep.html
+"pair_style */soft"_pair_lj_soft.html
+examples/USER/fep
+tools/fep/README
+tools/fep :ul
+
+:line
+
+USER-H5MD package :link(PKG-USER-H5MD),h4
+
+[Contents:]
+
+H5MD stands for HDF5 for MD. "HDF5"_HDF5 is a portable, binary,
+self-describing file format, used by many scientific simulations.
+H5MD is a format for molecular simulations, built on top of HDF5.
+This package implements a "dump h5md"_dump_h5md.html command to output
+LAMMPS snapshots in this format.
+
+:link(HDF5,http://www.hdfgroup.org/HDF5)
+
+To use this package you must have the HDF5 library available on your
+system.
+
+[Author:] Pierre de Buyl (KU Leuven) created both the package and the
+H5MD format.
+
+[Install:]
+
+This package has "specific installation
+instructions"_Build_extras.html#gpu on the "Build
+extras"_Build_extras.html doc page.
+
+[Supporting info:]
+
+src/USER-H5MD: filenames -> commands
+src/USER-H5MD/README
+lib/h5md/README
+"dump h5md"_dump_h5md.html :ul
+
+:line
+
+USER-INTEL package :link(PKG-USER-INTEL),h4
+
+[Contents:]
+
+Dozens of pair, fix, bond, angle, dihedral, improper, and kspace
+styles which are optimized for Intel CPUs and KNLs (Knights Landing).
+All of them have an "intel" in their style name. The "Speed
+intel"_Speed_intel.html doc page gives details of what hardware and
+compilers are required on your system, and how to build and use this
+package. Its styles can be invoked at run time via the "-sf intel" or
+"-suffix intel" "command-line switches"_Run_options.html. Also see
+the "KOKKOS"_#PKG-KOKKOS, "OPT"_#PKG-OPT, and "USER-OMP"_#PKG-USER-OMP packages,
+which have styles optimized for CPUs and KNLs.
+
+You need to have an Intel compiler, version 14 or higher to take full
+advantage of this package. While compilation with GNU compilers is
+supported, performance will be suboptimal.
+
+NOTE: the USER-INTEL package contains styles that require using the
+-restrict flag, when compiling with Intel compilers.
+
+[Author:] Mike Brown (Intel).
+
+[Install:]
+
+This package has "specific installation
+instructions"_Build_extras.html#gpu on the "Build
+extras"_Build_extras.html doc page.
+
+[Supporting info:]
+
+src/USER-INTEL: filenames -> commands
+src/USER-INTEL/README
+"Speed packages"_Speed_packages.html
+"Speed intel"_Speed_intel.html
+"Section 2.6 -sf intel"_Run_options.html
+"Section 2.6 -pk intel"_Run_options.html
+"package intel"_package.html
+"Commands all"_Commands_all.html pages (fix,compute,pair,etc) for styles followed by (i)
+src/USER-INTEL/TEST
+"Benchmarks page"_http://lammps.sandia.gov/bench.html of web site :ul
+
+:line
+
+USER-LB package :link(PKG-USER-LB),h4
+
+[Contents:]
+
+Fixes which implement a background Lattice-Boltzmann (LB) fluid, which
+can be used to model MD particles influenced by hydrodynamic forces.
+
+[Authors:] Frances Mackay and Colin Denniston (University of Western
+Ontario).
+
+[Supporting info:]
+
+src/USER-LB: filenames -> commands
+src/USER-LB/README
+"fix lb/fluid"_fix_lb_fluid.html
+"fix lb/momentum"_fix_lb_momentum.html
+"fix lb/viscous"_fix_lb_viscous.html
+examples/USER/lb :ul
+
+:line
+
+USER-MGPT package :link(PKG-USER-MGPT),h4
+
+[Contents:]
+
+A pair style which provides a fast implementation of the quantum-based
+MGPT multi-ion potentials. The MGPT or model GPT method derives from
+first-principles DFT-based generalized pseudopotential theory (GPT)
+through a series of systematic approximations valid for mid-period
+transition metals with nearly half-filled d bands. The MGPT method
+was originally developed by John Moriarty at LLNL. The pair style in
+this package calculates forces and energies using an optimized
+matrix-MGPT algorithm due to Tomas Oppelstrup at LLNL.
+
+[Authors:] Tomas Oppelstrup and John Moriarty (LLNL).
+
+[Supporting info:]
+
+src/USER-MGPT: filenames -> commands
+src/USER-MGPT/README
+"pair_style mgpt"_pair_mgpt.html
+examples/USER/mgpt :ul
+
+:line
+
+USER-MISC package :link(PKG-USER-MISC),h4
+
+[Contents:]
+
+A potpourri of (mostly) unrelated features contributed to LAMMPS by
+users. Each feature is a single fix, compute, pair, bond, angle,
+dihedral, improper, or command style.
+
+[Authors:] The author for each style in the package is listed in the
+src/USER-MISC/README file.
+
+[Supporting info:]
+
+src/USER-MISC: filenames -> commands
+src/USER-MISC/README
+one doc page per individual command listed in src/USER-MISC/README
+examples/USER/misc :ul
+
+:line
+
+USER-MANIFOLD package :link(PKG-USER-MANIFOLD),h4
+
+[Contents:]
+
+Several fixes and a "manifold" class which enable simulations of
+particles constrained to a manifold (a 2D surface within the 3D
+simulation box). This is done by applying the RATTLE constraint
+algorithm to formulate single-particle constraint functions
+g(xi,yi,zi) = 0 and their derivative (i.e. the normal of the manifold)
+n = grad(g).
+
+[Author:] Stefan Paquay (until 2017: Eindhoven University of
+Technology (TU/e), The Netherlands; since 2017: Brandeis University,
+Waltham, MA, USA)
+
+[Supporting info:]
+
+src/USER-MANIFOLD: filenames -> commands
+src/USER-MANIFOLD/README
+"Howto manifold"_Howto_manifold.html
+"fix manifoldforce"_fix_manifoldforce.html
+"fix nve/manifold/rattle"_fix_nve_manifold_rattle.html
+"fix nvt/manifold/rattle"_fix_nvt_manifold_rattle.html
+examples/USER/manifold
+http://lammps.sandia.gov/movies.html#manifold :ul
+
+:line
+
+USER-MEAMC package :link(PKG-USER-MEAMC),h4
+
+[Contents:]
+
+A pair style for the modified embedded atom (MEAM) potential
+translated from the Fortran version in the "MEAM"_MEAM package
+to plain C++. In contrast to the MEAM package, no library
+needs to be compiled and the pair style can be instantiated
+multiple times.
+
+[Author:] Sebastian Huetter, (Otto-von-Guericke University Magdeburg)
+based on the Fortran version of Greg Wagner (Northwestern U) while at
+Sandia.
+
+[Supporting info:]
+
+src/USER-MEAMC: filenames -> commands
+src/USER-MEAMC/README
+"pair_style meam/c"_pair_meam.html
+examples/meam :ul
+
+:line
+
+USER-MESO package :link(PKG-USER-MESO),h4
+
+[Contents:]
+
+Several extensions of the the dissipative particle dynamics (DPD)
+method. Specifically, energy-conserving DPD (eDPD) that can model
+non-isothermal processes, many-body DPD (mDPD) for simulating
+vapor-liquid coexistence, and transport DPD (tDPD) for modeling
+advection-diffusion-reaction systems. The equations of motion of these
+DPD extensions are integrated through a modified velocity-Verlet (MVV)
+algorithm.
+
+[Author:] Zhen Li (Division of Applied Mathematics, Brown University)
+
+[Supporting info:]
+
+src/USER-MESO: filenames -> commands
+src/USER-MESO/README
+"atom_style edpd"_atom_style.html
+"pair_style edpd"_pair_meso.html
+"pair_style mdpd"_pair_meso.html
+"pair_style tdpd"_pair_meso.html
+"fix mvv/dpd"_fix_mvv_dpd.html
+examples/USER/meso
+http://lammps.sandia.gov/movies.html#mesodpd :ul
+
+:line
+
+USER-MOFFF package :link(PKG-USER-MOFFF),h4
+
+[Contents:]
+
+Pair, angle and improper styles needed to employ the MOF-FF
+force field by Schmid and coworkers with LAMMPS.
+MOF-FF is a first principles derived force field with the primary aim
+to simulate MOFs and related porous framework materials, using spherical
+Gaussian charges. It is described in S. Bureekaew et al., Phys. Stat. Sol. B
+2013, 250, 1128-1141.
+For the usage of MOF-FF see the example in the example directory as
+well as the "MOF+"_MOFplus website.
+
+:link(MOFplus,https://www.mofplus.org/content/show/MOF-FF)
+
+[Author:] Hendrik Heenen (Technical U of Munich),
+Rochus Schmid (Ruhr-University Bochum).
+
+[Supporting info:]
+
+src/USER-MOFFF: filenames -> commands
+src/USER-MOFFF/README
+"pair_style buck6d/coul/gauss"_pair_buck6d_coul_gauss.html
+"angle_style class2"_angle_class2.html
+"angle_style cosine/buck6d"_angle_cosine_buck6d.html
+"improper_style inversion/harmonic"_improper_inversion_harmonic.html
+examples/USER/mofff :ul
+
+:line
+
+USER-MOLFILE package :link(PKG-USER-MOLFILE),h4
+
+[Contents:]
+
+A "dump molfile"_dump_molfile.html command which uses molfile plugins
+that are bundled with the "VMD"_vmd_home
+molecular visualization and analysis program, to enable LAMMPS to dump
+snapshots in formats compatible with various molecular simulation
+tools.
+
+:link(vmd_home,http://www.ks.uiuc.edu/Research/vmd)
+
+To use this package you must have the desired VMD plugins available on
+your system.
+
+Note that this package only provides the interface code, not the
+plugins themselves, which will be accessed when requesting a specific
+plugin via the "dump molfile"_dump_molfile.html command. Plugins can
+be obtained from a VMD installation which has to match the platform
+that you are using to compile LAMMPS for. By adding plugins to VMD,
+support for new file formats can be added to LAMMPS (or VMD or other
+programs that use them) without having to recompile the application
+itself. More information about the VMD molfile plugins can be found
+at
+"http://www.ks.uiuc.edu/Research/vmd/plugins/molfile"_http://www.ks.uiuc.edu/Research/vmd/plugins/molfile.
+
+[Author:] Axel Kohlmeyer (Temple U).
+
+[Install:]
+
+This package has "specific installation
+instructions"_Build_extras.html#gpu on the "Build
+extras"_Build_extras.html doc page.
+
+[Supporting info:]
+
+src/USER-MOLFILE: filenames -> commands
+src/USER-MOLFILE/README
+lib/molfile/README
+"dump molfile"_dump_molfile.html :ul
+
+:line
+
+USER-NETCDF package :link(PKG-USER-NETCDF),h4
+
+[Contents:]
+
+Dump styles for writing NetCDF formatted dump files. NetCDF is a
+portable, binary, self-describing file format developed on top of
+HDF5. The file contents follow the AMBER NetCDF trajectory conventions
+(http://ambermd.org/netcdf/nctraj.xhtml), but include extensions.
+
+To use this package you must have the NetCDF library available on your
+system.
+
+Note that NetCDF files can be directly visualized with the following
+tools:
+
+"Ovito"_ovito (Ovito supports the AMBER convention and the extensions mentioned above)
+"VMD"_vmd_home
+"AtomEye"_atomeye (the libAtoms version of AtomEye contains a NetCDF reader not present in the standard distribution) :ul
+
+:link(ovito,http://www.ovito.org)
+:link(atomeye,http://www.libatoms.org)
+
+[Author:] Lars Pastewka (Karlsruhe Institute of Technology).
+
+[Install:]
+
+This package has "specific installation
+instructions"_Build_extras.html#gpu on the "Build
+extras"_Build_extras.html doc page.
+
+[Supporting info:]
+
+src/USER-NETCDF: filenames -> commands
+src/USER-NETCDF/README
+lib/netcdf/README
+"dump netcdf"_dump_netcdf.html :ul
+
+:line
+
+USER-OMP package :link(PKG-USER-OMP),h4
+
+[Contents:]
+
+Hundreds of pair, fix, compute, bond, angle, dihedral, improper, and
+kspace styles which are altered to enable threading on many-core CPUs
+via OpenMP directives. All of them have an "omp" in their style name.
+The "Speed omp"_Speed_omp.html doc page gives details of what hardware
+and compilers are required on your system, and how to build and use
+this package. Its styles can be invoked at run time via the "-sf omp"
+or "-suffix omp" "command-line switches"_Run_options.html. Also see
+the "KOKKOS"_#PKG-KOKKOS, "OPT"_#PKG-OPT, and "USER-INTEL"_#PKG-USER-INTEL
+packages, which have styles optimized for CPUs.
+
+[Author:] Axel Kohlmeyer (Temple U).
+
+NOTE: To enable multi-threading support the compile flag "-fopenmp"
+and the link flag "-fopenmp" (for GNU compilers, you have to look up
+the equivalent flags for other compilers) must be used to build LAMMPS.
+When using Intel compilers, also the "-restrict" flag is required.
+The USER-OMP package can be compiled without enabling OpenMP; then
+all code will be compiled as serial and the only improvement over the
+regular styles are some data access optimization. These flags should
+be added to the CCFLAGS and LINKFLAGS lines of your Makefile.machine.
+See src/MAKE/OPTIONS/Makefile.omp for an example.
+
+Once you have an appropriate Makefile.machine, you can
+install/un-install the package and build LAMMPS in the usual manner:
+
+[Install:]
+
+This package has "specific installation
+instructions"_Build_extras.html#gpu on the "Build
+extras"_Build_extras.html doc page.
+
+[Supporting info:]
+
+src/USER-OMP: filenames -> commands
+src/USER-OMP/README
+"Speed packages"_Speed_packages.html
+"Speed omp"_Speed_omp.html
+"Section 2.6 -sf omp"_Run_options.html
+"Section 2.6 -pk omp"_Run_options.html
+"package omp"_package.html
+"Commands all"_Commands_all.html pages (fix,compute,pair,etc) for styles followed by (o)
+"Benchmarks page"_http://lammps.sandia.gov/bench.html of web site :ul
+
+:line
+
+USER-PHONON package :link(PKG-USER-PHONON),h4
+
+[Contents:]
+
+A "fix phonon"_fix_phonon.html command that calculates dynamical
+matrices, which can then be used to compute phonon dispersion
+relations, directly from molecular dynamics simulations.
+
+[Author:] Ling-Ti Kong (Shanghai Jiao Tong University).
+
+[Supporting info:]
+
+src/USER-PHONON: filenames -> commands
+src/USER-PHONON/README
+"fix phonon"_fix_phonon.html
+examples/USER/phonon :ul
+
+:line
+
+USER-QMMM package :link(PKG-USER-QMMM),h4
+
+[Contents:]
+
+A "fix qmmm"_fix_qmmm.html command which allows LAMMPS to be used in a
+QM/MM simulation, currently only in combination with the "Quantum
+ESPRESSO"_espresso package.
+
+:link(espresso,http://www.quantum-espresso.org)
+
+To use this package you must have Quantum ESPRESSO available on your
+system.
+
+The current implementation only supports an ONIOM style mechanical
+coupling to the Quantum ESPRESSO plane wave DFT package.
+Electrostatic coupling is in preparation and the interface has been
+written in a manner that coupling to other QM codes should be possible
+without changes to LAMMPS itself.
+
+[Author:] Axel Kohlmeyer (Temple U).
+
+[Install:]
+
+This package has "specific installation
+instructions"_Build_extras.html#gpu on the "Build
+extras"_Build_extras.html doc page.
+
+[Supporting info:]
+
+src/USER-QMMM: filenames -> commands
+src/USER-QMMM/README
+lib/qmmm/README
+"fix phonon"_fix_phonon.html
+lib/qmmm/example-ec/README
+lib/qmmm/example-mc/README :ul
+
+:line
+
+USER-QTB package :link(PKG-USER-QTB),h4
+
+[Contents:]
+
+Two fixes which provide a self-consistent quantum treatment of
+vibrational modes in a classical molecular dynamics simulation. By
+coupling the MD simulation to a colored thermostat, it introduces zero
+point energy into the system, altering the energy power spectrum and
+the heat capacity to account for their quantum nature. This is useful
+when modeling systems at temperatures lower than their classical
+limits or when temperatures ramp across the classical limits in a
+simulation.
+
+[Author:] Yuan Shen (Stanford U).
+
+[Supporting info:]
+
+src/USER-QTB: filenames -> commands
+src/USER-QTB/README
+"fix qtb"_fix_qtb.html
+"fix qbmsst"_fix_qbmsst.html
+examples/USER/qtb :ul
+
+:line
+
+USER-QUIP package :link(PKG-USER-QUIP),h4
+
+[Contents:]
+
+A "pair_style quip"_pair_quip.html command which wraps the "QUIP
+libAtoms library"_quip, which includes a variety of interatomic
+potentials, including Gaussian Approximation Potential (GAP) models
+developed by the Cambridge University group.
+
+:link(quip,https://github.com/libAtoms/QUIP)
+
+To use this package you must have the QUIP libAtoms library available
+on your system.
+
+[Author:] Albert Bartok (Cambridge University)
+
+[Install:]
+
+This package has "specific installation
+instructions"_Build_extras.html#gpu on the "Build
+extras"_Build_extras.html doc page.
+
+[Supporting info:]
+
+src/USER-QUIP: filenames -> commands
+src/USER-QUIP/README
+"pair_style quip"_pair_quip.html
+examples/USER/quip :ul
+
+:line
+
+USER-REAXC package :link(PKG-USER-REAXC),h4
+
+[Contents:]
+
+A pair style which implements the ReaxFF potential in C/C++ (in
+contrast to the "REAX package"_#PKG-REAX and its Fortran library). ReaxFF
+is universal reactive force field. See the src/USER-REAXC/README file
+for more info on differences between the two packages. Also two fixes
+for monitoring molecules as bonds are created and destroyed.
+
+[Author:] Hasan Metin Aktulga (MSU) while at Purdue University.
+
+[Supporting info:]
+
+src/USER-REAXC: filenames -> commands
+src/USER-REAXC/README
+"pair_style reax/c"_pair_reaxc.html
+"fix reax/c/bonds"_fix_reax_bonds.html
+"fix reax/c/species"_fix_reaxc_species.html
+examples/reax :ul
+
+:line
+
+USER-SMD package :link(PKG-USER-SMD),h4
+
+[Contents:]
+
+An atom style, fixes, computes, and several pair styles which
+implements smoothed Mach dynamics (SMD) for solids, which is a model
+related to smoothed particle hydrodynamics (SPH) for liquids (see the
+"USER-SPH package"_#PKG-USER-SPH).
+
+This package solves solids mechanics problems via a state of the art
+stabilized meshless method with hourglass control. It can specify
+hydrostatic interactions independently from material strength models,
+i.e. pressure and deviatoric stresses are separated. It provides many
+material models (Johnson-Cook, plasticity with hardening,
+Mie-Grueneisen, Polynomial EOS) and allows new material models to be
+added. It implements rigid boundary conditions (walls) which can be
+specified as surface geometries from *.STL files.
+
+[Author:] Georg Ganzenmuller (Fraunhofer-Institute for High-Speed
+Dynamics, Ernst Mach Institute, Germany).
+
+[Install:]
+
+This package has "specific installation
+instructions"_Build_extras.html#gpu on the "Build
+extras"_Build_extras.html doc page.
+
+[Supporting info:]
+
+src/USER-SMD: filenames -> commands
+src/USER-SMD/README
+doc/PDF/SMD_LAMMPS_userguide.pdf
+examples/USER/smd
+http://lammps.sandia.gov/movies.html#smd :ul
+
+:line
+
+USER-SMTBQ package :link(PKG-USER-SMTBQ),h4
+
+[Contents:]
+
+A pair style which implements a Second Moment Tight Binding model with
+QEq charge equilibration (SMTBQ) potential for the description of
+ionocovalent bonds in oxides.
+
+[Authors:] Nicolas Salles, Emile Maras, Olivier Politano, and Robert
+Tetot (LAAS-CNRS, France).
+
+[Supporting info:]
+
+src/USER-SMTBQ: filenames -> commands
+src/USER-SMTBQ/README
+"pair_style smtbq"_pair_smtbq.html
+examples/USER/smtbq :ul
+
+:line
+
+USER-SPH package :link(PKG-USER-SPH),h4
+
+[Contents:]
+
+An atom style, fixes, computes, and several pair styles which
+implements smoothed particle hydrodynamics (SPH) for liquids. See the
+related "USER-SMD package"_#PKG-USER-SMD package for smooth Mach dynamics
+(SMD) for solids.
+
+This package contains ideal gas, Lennard-Jones equation of states,
+Tait, and full support for complete (i.e. internal-energy dependent)
+equations of state. It allows for plain or Monaghans XSPH integration
+of the equations of motion. It has options for density continuity or
+density summation to propagate the density field. It has
+"set"_set.html command options to set the internal energy and density
+of particles from the input script and allows the same quantities to
+be output with thermodynamic output or to dump files via the "compute
+property/atom"_compute_property_atom.html command.
+
+[Author:] Georg Ganzenmuller (Fraunhofer-Institute for High-Speed
+Dynamics, Ernst Mach Institute, Germany).
+
+[Supporting info:]
+
+src/USER-SPH: filenames -> commands
+src/USER-SPH/README
+doc/PDF/SPH_LAMMPS_userguide.pdf
+examples/USER/sph
+http://lammps.sandia.gov/movies.html#sph :ul
+
+:line
+
+USER-TALLY package :link(PKG-USER-TALLY),h4
+
+[Contents:]
+
+Several compute styles that can be called when pairwise interactions
+are calculated to tally information (forces, heat flux, energy,
+stress, etc) about individual interactions.
+
+[Author:] Axel Kohlmeyer (Temple U).
+
+[Supporting info:]
+
+src/USER-TALLY: filenames -> commands
+src/USER-TALLY/README
+"compute */tally"_compute_tally.html
+examples/USER/tally :ul
+
+:line
+
+USER-UEF package :link(PKG-USER-UEF),h4
+
+[Contents:]
+
+A fix style for the integration of the equations of motion under
+extensional flow with proper boundary conditions, as well as several
+supporting compute styles and an output option.
+
+[Author:] David Nicholson (MIT).
+
+[Supporting info:]
+
+src/USER-UEF: filenames -> commands
+src/USER-UEF/README
+"fix nvt/uef"_fix_nh_uef.html
+"fix npt/uef"_fix_nh_uef.html
+"compute pressure/uef"_compute_pressure_uef.html
+"compute temp/uef"_compute_temp_uef.html
+"dump cfg/uef"_dump_cfg_uef.html
+examples/uef :ul
+
+:line
+
+USER-VTK package :link(PKG-USER-VTK),h4
+
+[Contents:]
+
+A "dump vtk"_dump_vtk.html command which outputs snapshot info in the
+"VTK format"_vtk, enabling visualization by "Paraview"_paraview or
+other visualization packages.
+
+:link(vtk,http://www.vtk.org)
+:link(paraview,http://www.paraview.org)
+
+To use this package you must have VTK library available on your
+system.
+
+[Authors:] Richard Berger (JKU) and Daniel Queteschiner (DCS Computing).
+
+[Install:]
+
+This package has "specific installation
+instructions"_Build_extras.html#gpu on the "Build
+extras"_Build_extras.html doc page.
+
+[Supporting info:]
+
+src/USER-VTK: filenames -> commands
+src/USER-VTK/README
+lib/vtk/README
+"dump vtk"_dump_vtk.html :ul
diff --git a/doc/src/Packages_standard.txt b/doc/src/Packages_standard.txt
new file mode 100644
index 0000000000000000000000000000000000000000..55d0d616f417a5511898b98f61d9b7b0b348edd9
--- /dev/null
+++ b/doc/src/Packages_standard.txt
@@ -0,0 +1,66 @@
+"Higher level section"_Packages.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Standard packages :h3
+
+This is the list of standard packages in LAMMPS. The link for each
+package name gives more details.
+
+Standard packages are supported by the LAMMPS developers and are
+written in a syntax and style consistent with the rest of LAMMPS.
+This means the developers will answer questions about them, debug and
+fix them if necessary, and keep them compatible with future changes to
+LAMMPS.
+
+The "Example" column is a sub-directory in the examples directory of
+the distribution which has an input script that uses the package.
+E.g. "peptide" refers to the examples/peptide directory; USER/atc
+refers to the examples/USER/atc directory. The "Library" column
+indicates whether an extra library is needed to build and use the
+package:
+
+no = no library
+sys = system library: you likely have it on your machine
+int = internal library: provided with LAMMPS, but you may need to build it
+ext = external library: you will need to download and install it on your machine :ul
+
+Package, Description, Doc page, Example, Library
+"ASPHERE"_Packages_details.html#PKG-ASPHERE, aspherical particle models, "Howto spherical"_Howto_spherical.html, ellipse, no
+"BODY"_Packages_details.html#PKG-BODY, body-style particles, "Howto body"_Howto_body.html, body, no
+"CLASS2"_Packages_details.html#PKG-CLASS2, class 2 force fields, "pair_style lj/class2"_pair_class2.html, n/a, no
+"COLLOID"_Packages_details.html#PKG-COLLOID, colloidal particles, "atom_style colloid"_atom_style.html, colloid, no
+"COMPRESS"_Packages_details.html#PKG-COMPRESS, I/O compression, "dump */gz"_dump.html, n/a, sys
+"CORESHELL"_Packages_details.html#PKG-CORESHELL, adiabatic core/shell model, "Howto coreshell"_Howto_coreshell.html, coreshell, no
+"DIPOLE"_Packages_details.html#PKG-DIPOLE, point dipole particles, "pair_style dipole/cut"_pair_dipole.html, dipole, no
+"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#PKG-GRANULAR, granular systems, "Howto granular"_Howto_granular.html, pour, no
+"KIM"_Packages_details.html#PKG-KIM, OpenKIM wrapper, "pair_style kim"_pair_kim.html, kim, ext
+"KOKKOS"_Packages_details.html#PKG-KOKKOS, Kokkos-enabled styles, "Speed kokkos"_Speed_kokkos.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, no
+"KSPACE"_Packages_details.html#PKG-KSPACE, long-range Coulombic solvers, "kspace_style"_kspace_style.html, peptide, no
+"LATTE"_Packages_details.html#PKG-LATTE, quantum DFTB forces via LATTE, "fix latte"_fix_latte.html, latte, ext
+"MANYBODY"_Packages_details.html#PKG-MANYBODY, many-body potentials, "pair_style tersoff"_pair_tersoff.html, shear, no
+"MC"_Packages_details.html#PKG-MC, Monte Carlo options, "fix gcmc"_fix_gcmc.html, n/a, no
+"MEAM"_Packages_details.html#PKG-MEAM, modified EAM potential, "pair_style meam"_pair_meam.html, meam, int
+"MISC"_Packages_details.html#PKG-MISC, miscellanous single-file commands, n/a, no, no
+"MOLECULE"_Packages_details.html#PKG-MOLECULE, molecular system force fields, "Howto bioFF"_Howto_bioFF.html, peptide, no
+"MPIIO"_Packages_details.html#PKG-MPIIO, MPI parallel I/O dump and restart, "dump"_dump.html, n/a, no
+"MSCG"_Packages_details.html#PKG-MSCG, multi-scale coarse-graining wrapper, "fix mscg"_fix_mscg.html, mscg, ext
+"OPT"_Packages_details.html#PKG-OPT, optimized pair styles, "Speed opt"_Speed_opt.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, no
+"PERI"_Packages_details.html#PKG-PERI, Peridynamics models, "pair_style peri"_pair_peri.html, peri, no
+"POEMS"_Packages_details.html#PKG-POEMS, coupled rigid body motion, "fix poems"_fix_poems.html, rigid, int
+"PYTHON"_Packages_details.html#PKG-PYTHON, embed Python code in an input script, "python"_python.html, python, sys
+"QEQ"_Packages_details.html#PKG-QEQ, QEq charge equilibration, "fix qeq"_fix_qeq.html, qeq, no
+"REAX"_Packages_details.html#PKG-REAX, ReaxFF potential (Fortran), "pair_style reax"_pair_reax.html, reax, int
+"REPLICA"_Packages_details.html#PKG-REPLICA2, multi-replica methods, "Howto replica"_Howto_replica.html, tad, no
+"RIGID"_Packages_details.html#PKG-RIGID, rigid bodies and constraints, "fix rigid"_fix_rigid.html, rigid, no
+"SHOCK"_Packages_details.html#PKG-SHOCK, shock loading methods, "fix msst"_fix_msst.html, n/a, no
+"SNAP"_Packages_details.html#PKG-SNAP, quantum-fitted potential, "pair_style snap"_pair_snap.html, snap, no
+"SPIN"_Packages_details.html#PKG-SPIN, magnetic atomic spin dynamics, "Howto spins"_Howto_spins.html, SPIN, no
+"SRD"_Packages_details.html#PKG-SRD, stochastic rotation dynamics, "fix srd"_fix_srd.html, srd, no
+"VORONOI"_Packages_details.html#PKG-VORONOI, Voronoi tesselation, "compute voronoi/atom"_compute_voronoi_atom.html, n/a, ext :tb(ea=c,ca1=l)
diff --git a/doc/src/Packages_user.txt b/doc/src/Packages_user.txt
new file mode 100644
index 0000000000000000000000000000000000000000..c1a52fd0d0d864493d49f849aa5c531fcb1cd40f
--- /dev/null
+++ b/doc/src/Packages_user.txt
@@ -0,0 +1,74 @@
+"Higher level section"_Packages.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+User packages :h3
+
+This is a list of user packages in LAMMPS. The link for each package
+name gives more details.
+
+User packages have been contributed by users, and begin with the
+"user" prefix. If a contribution is a single command (single file),
+it is typically in the user-misc package. User packages don't
+necessarily meet the requirements of the "standard
+packages"_Packages_standard.html. This means the developers will try
+to keep things working and usually can answer technical questions
+about compiling the package. If you have problems using a specific
+feature provided in a user package, you may need to contact the
+contributor directly to get help. Information on how to submit
+additions you make to LAMMPS as single files or as a standard or user
+package is explained on the "Modify contribute"_Modify_contribute.html
+doc page.
+
+The "Example" column is a sub-directory in the examples directory of
+the distribution which has an input script that uses the package.
+E.g. "peptide" refers to the examples/peptide directory; USER/atc
+refers to the examples/USER/atc directory. The "Library" column
+indicates whether an extra library is needed to build and use the
+package:
+
+no = no library
+sys = system library: you likely have it on your machine
+int = internal library: provided with LAMMPS, but you may need to build it
+ext = external library: you will need to download and install it on your machine :ul
+
+Package, Description, Doc page, Example, Library
+"USER-ATC"_Packages_details.html#PKG-USER-ATC, atom-to-continuum coupling, "fix atc"_fix_atc.html, USER/atc, int
+"USER-AWPMD"_Packages_details.html#PKG-USER-AWPMD, wave-packet MD, "pair_style awpmd/cut"_pair_awpmd.html, USER/awpmd, int
+"USER-BOCS"_Packages_details.html#PKG-USER-BOCS, BOCS bottom up coarse graining, "fix bocs"_fix_bocs.html, USER/bocs, no
+"USER-CGDNA"_Packages_details.html#PKG-USER-CGDNA, coarse-grained DNA force fields, src/USER-CGDNA/README, USER/cgdna, no
+"USER-CGSDK"_Packages_details.html#PKG-USER-CGSDK, SDK coarse-graining model, "pair_style lj/sdk"_pair_sdk.html, USER/cgsdk, no
+"USER-COLVARS"_Packages_details.html#PKG-USER-COLVARS, collective variables library, "fix colvars"_fix_colvars.html, USER/colvars, int
+"USER-DIFFRACTION"_Packages_details.html#PKG-USER-DIFFRACTION, virtual x-ray and electron diffraction,"compute xrd"_compute_xrd.html, USER/diffraction, no
+"USER-DPD"_Packages_details.html#PKG-USER-DPD, reactive dissipative particle dynamics, src/USER-DPD/README, USER/dpd, no
+"USER-DRUDE"_Packages_details.html#PKG-USER-DRUDE, Drude oscillators, "Howto drude"_Howto_drude.html, USER/drude, no
+"USER-EFF"_Packages_details.html#PKG-USER-EFF, electron force field,"pair_style eff/cut"_pair_eff.html, USER/eff, no
+"USER-FEP"_Packages_details.html#PKG-USER-FEP, free energy perturbation,"compute fep"_compute_fep.html, USER/fep, no
+"USER-H5MD"_Packages_details.html#PKG-USER-H5MD, dump output via HDF5,"dump h5md"_dump_h5md.html, n/a, ext
+"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, no
+"USER-LB"_Packages_details.html#PKG-USER-LB, Lattice Boltzmann fluid,"fix lb/fluid"_fix_lb_fluid.html, USER/lb, no
+"USER-MANIFOLD"_Packages_details.html#PKG-USER-MANIFOLD, motion on 2d surfaces,"fix manifoldforce"_fix_manifoldforce.html, USER/manifold, no
+"USER-MEAMC"_Packages_details.html#PKG-USER-MEAMC, modified EAM potential (C++), "pair_style meam/c"_pair_meam.html, meam, no
+"USER-MESO"_Packages_details.html#PKG-USER-MESO, mesoscale DPD models, "pair_style edpd"_pair_meso.html, USER/meso, no
+"USER-MGPT"_Packages_details.html#PKG-USER-MGPT, fast MGPT multi-ion potentials, "pair_style mgpt"_pair_mgpt.html, USER/mgpt, no
+"USER-MISC"_Packages_details.html#PKG-USER-MISC, single-file contributions, USER-MISC/README, USER/misc, no
+"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, no
+"USER-MOLFILE"_Packages_details.html#PKG-USER-MOLFILE, "VMD"_vmd_home molfile plug-ins,"dump molfile"_dump_molfile.html, n/a, ext
+"USER-NETCDF"_Packages_details.html#PKG-USER-NETCDF, dump output via NetCDF,"dump netcdf"_dump_netcdf.html, n/a, ext
+"USER-OMP"_Packages_details.html#PKG-USER-OMP, OpenMP-enabled styles,"Speed omp"_Speed_omp.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, no
+"USER-PHONON"_Packages_details.html#PKG-USER-PHONON, phonon dynamical matrix,"fix phonon"_fix_phonon.html, USER/phonon, no
+"USER-QMMM"_Packages_details.html#PKG-USER-QMMM, QM/MM coupling,"fix qmmm"_fix_qmmm.html, USER/qmmm, ext
+"USER-QTB"_Packages_details.html#PKG-USER-QTB, quantum nuclear effects,"fix qtb"_fix_qtb.html "fix qbmsst"_fix_qbmsst.html, qtb, no
+"USER-QUIP"_Packages_details.html#PKG-USER-QUIP, QUIP/libatoms interface,"pair_style quip"_pair_quip.html, USER/quip, ext
+"USER-REAXC"_Packages_details.html#PKG-USER-REAXC, ReaxFF potential (C/C++) ,"pair_style reaxc"_pair_reaxc.html, reax, no
+"USER-SMD"_Packages_details.html#PKG-USER-SMD, smoothed Mach dynamics,"SMD User Guide"_PDF/SMD_LAMMPS_userguide.pdf, USER/smd, ext
+"USER-SMTBQ"_Packages_details.html#PKG-USER-SMTBQ, second moment tight binding QEq potential,"pair_style smtbq"_pair_smtbq.html, USER/smtbq, no
+"USER-SPH"_Packages_details.html#PKG-USER-SPH, smoothed particle hydrodynamics,"SPH User Guide"_PDF/SPH_LAMMPS_userguide.pdf, USER/sph, no
+"USER-TALLY"_Packages_details.html#PKG-USER-TALLY, pairwise tally computes,"compute XXX/tally"_compute_tally.html, USER/tally, no
+"USER-UEF"_Packages_details.html#PKG-USER-UEF, extensional flow,"fix nvt/uef"_fix_nh_uef.html, USER/uef, no
+"USER-VTK"_Packages_details.html#PKG-USER-VTK, dump output via VTK, "compute vtk"_dump_vtk.html, n/a, ext :tb(ea=c,ca1=l)
diff --git a/doc/src/Python_call.txt b/doc/src/Python_call.txt
new file mode 100644
index 0000000000000000000000000000000000000000..029c8f831cc537da73f898ac5ba3172036a54faf
--- /dev/null
+++ b/doc/src/Python_call.txt
@@ -0,0 +1,85 @@
+"Higher level section"_Python_head.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
+
+Call Python from a LAMMPS input script :h3
+
+LAMMPS has several commands which can be used to invoke Python
+code directly from an input script:
+
+"python"_python.html
+"variable python"_variable.html
+"fix python/invoke"_fix_python_invoke.html
+"pair_style python"_pair_python.html :ul
+
+The "python"_python.html command which can be used to define and
+execute a Python function that you write the code for. The Python
+function can also be assigned to a LAMMPS python-style variable via
+the "variable"_variable.html command. Each time the variable is
+evaluated, either in the LAMMPS input script itself, or by another
+LAMMPS command that uses the variable, this will trigger the Python
+function to be invoked.
+
+The Python code for the function can be included directly in the input
+script or in an auxiliary file. The function can have arguments which
+are mapped to LAMMPS variables (also defined in the input script) and
+it can return a value to a LAMMPS variable. This is thus a mechanism
+for your input script to pass information to a piece of Python code,
+ask Python to execute the code, and return information to your input
+script.
+
+Note that a Python function can be arbitrarily complex. It can import
+other Python modules, instantiate Python classes, call other Python
+functions, etc. The Python code that you provide can contain more
+code than the single function. It can contain other functions or
+Python classes, as well as global variables or other mechanisms for
+storing state between calls from LAMMPS to the function.
+
+The Python function you provide can consist of "pure" Python code that
+only performs operations provided by standard Python. However, the
+Python function can also "call back" to LAMMPS through its
+Python-wrapped library interface, in the manner described in the
+"Python run"_Python_run.html doc page. This means it can issue LAMMPS
+input script commands or query and set internal LAMMPS state. As an
+example, this can be useful in an input script to create a more
+complex loop with branching logic, than can be created using the
+simple looping and branching logic enabled by the "next"_next.html and
+"if"_if.html commands.
+
+See the "python"_python.html doc page and the "variable"_variable.html
+doc page for its python-style variables for more info, including
+examples of Python code you can write for both pure Python operations
+and callbacks to LAMMPS.
+
+The "fix python/invoke"_fix_python_invoke.html command can execute
+Python code at selected timesteps during a simulation run.
+
+The "pair_style python"_pair_python command allows you to define
+pairwise potentials as python code which encodes a single pairwise
+interaction. This is useful for rapid-developement and debugging of a
+new potential.
+
+To use any of these commands, you only need to build LAMMPS with the
+PYTHON package installed:
+
+make yes-python
+make machine :pre
+
+Note that this will link LAMMPS with the Python library on your
+system, which typically requires several auxiliary system libraries to
+also be linked. The list of these libraries and the paths to find
+them are specified in the lib/python/Makefile.lammps file. You need
+to insure that file contains the correct information for your version
+of Python and your machine to successfully build LAMMPS. See the
+lib/python/README file for more info.
+
+If you want to write Python code with callbacks to LAMMPS, then you
+must also follow the steps overviewed in the "Python
+run"_Python_run.html doc page. I.e. you must build LAMMPS as a shared
+library and insure that Python can find the python/lammps.py file and
+the shared library.
diff --git a/doc/src/Python_examples.txt b/doc/src/Python_examples.txt
new file mode 100644
index 0000000000000000000000000000000000000000..f4b2197464312286a4a5cacd7600ba4c5bc56007
--- /dev/null
+++ b/doc/src/Python_examples.txt
@@ -0,0 +1,81 @@
+"Higher level section"_Python_head.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
+
+Example Python scripts that use LAMMPS :h3
+
+These are the Python scripts included as demos in the python/examples
+directory of the LAMMPS distribution, to illustrate the kinds of
+things that are possible when Python wraps LAMMPS. If you create your
+own scripts, send them to us and we can include them in the LAMMPS
+distribution.
+
+trivial.py, read/run a LAMMPS input script thru Python,
+demo.py, invoke various LAMMPS library interface routines,
+simple.py, run in parallel, similar to examples/COUPLE/simple/simple.cpp,
+split.py, same as simple.py but running in parallel on a subset of procs,
+gui.py, GUI go/stop/temperature-slider to control LAMMPS,
+plot.py, real-time temperature plot with GnuPlot via Pizza.py,
+viz_tool.py, real-time viz via some viz package,
+vizplotgui_tool.py, combination of viz_tool.py and plot.py and gui.py :tb(c=2)
+
+:line
+
+For the viz_tool.py and vizplotgui_tool.py commands, replace "tool"
+with "gl" or "atomeye" or "pymol" or "vmd", depending on what
+visualization package you have installed.
+
+Note that for GL, you need to be able to run the Pizza.py GL tool,
+which is included in the pizza sub-directory. See the "Pizza.py doc
+pages"_pizza for more info:
+
+:link(pizza,http://www.sandia.gov/~sjplimp/pizza.html)
+
+Note that for AtomEye, you need version 3, and there is a line in the
+scripts that specifies the path and name of the executable. See the
+AtomEye WWW pages "here"_atomeye or "here"_atomeye3 for more details:
+
+http://mt.seas.upenn.edu/Archive/Graphics/A
+http://mt.seas.upenn.edu/Archive/Graphics/A3/A3.html :pre
+
+:link(atomeye,http://mt.seas.upenn.edu/Archive/Graphics/A)
+:link(atomeye3,http://mt.seas.upenn.edu/Archive/Graphics/A3/A3.html)
+
+The latter link is to AtomEye 3 which has the scriping
+capability needed by these Python scripts.
+
+Note that for PyMol, you need to have built and installed the
+open-source version of PyMol in your Python, so that you can import it
+from a Python script. See the PyMol WWW pages "here"_pymolhome or
+"here"_pymolopen for more details:
+
+http://www.pymol.org
+http://sourceforge.net/scm/?type=svn&group_id=4546 :pre
+
+:link(pymolhome,http://www.pymol.org)
+:link(pymolopen,http://sourceforge.net/scm/?type=svn&group_id=4546)
+
+The latter link is to the open-source version.
+
+Note that for VMD, you need a fairly current version (1.8.7 works for
+me) and there are some lines in the pizza/vmd.py script for 4 PIZZA
+variables that have to match the VMD installation on your system.
+
+:line
+
+See the python/README file for instructions on how to run them and the
+source code for individual scripts for comments about what they do.
+
+Here are screenshots of the vizplotgui_tool.py script in action for
+different visualization package options. Click to see larger images:
+
+:image(JPG/screenshot_gl_small.jpg,JPG/screenshot_gl.jpg)
+:image(JPG/screenshot_atomeye_small.jpg,JPG/screenshot_atomeye.jpg)
+:image(JPG/screenshot_pymol_small.jpg,JPG/screenshot_pymol.jpg)
+:image(JPG/screenshot_vmd_small.jpg,JPG/screenshot_vmd.jpg)
+
diff --git a/doc/src/Python_head.txt b/doc/src/Python_head.txt
new file mode 100644
index 0000000000000000000000000000000000000000..1f0236842993a5a7492f3e805b32939a3c2fdff0
--- /dev/null
+++ b/doc/src/Python_head.txt
@@ -0,0 +1,72 @@
+"Previous Section"_Modify.html - "LAMMPS WWW Site"_lws -
+"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
+Section"_Errors.html :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Use Python with LAMMPS :h2
+
+These doc pages describe various ways that LAMMPS and Python can be
+used together.
+
+<!-- RST
+
+.. toctree::
+ :maxdepth: 1
+
+ Python_overview
+ Python_run
+ Python_shlib
+ Python_install
+ Python_mpi
+ Python_test
+ Python_library
+ Python_pylammps
+ Python_examples
+ Python_call
+
+END_RST -->
+
+<!-- HTML_ONLY -->
+
+"Overview of Python and LAMMPS"_Python_overview.html
+"Run LAMMPS from Python"_Python_run.html
+"Build LAMMPS as a shared library"_Python_shlib.html
+"Install LAMMPS in Python"_Python_install.html
+"Extend Python to run in parallel"_Python_mpi.html
+"Test the Python/LAMMPS interface"_Python_test.html
+"Python library interface"_Python_library.html
+"PyLammps interface"_Python_pylammps.html
+"Example Python scripts that use LAMMPS"_Python_examples.html
+"Call Python from a LAMMPS input script"_Python_call.html :all(b)
+
+<!-- END_HTML_ONLY -->
+
+If you're not familiar with "Python"_http://www.python.org, it's a
+powerful scripting and programming language which can do most
+everything that lower-level languages like C or C++ can do in fewer
+lines of code. The only drawback is slower execution speed. Python
+is also easy to use as a "glue" language to drive a program through
+its library interface, or to hook multiple pieces of software
+together, such as a simulation code plus a visualization tool, or to
+run a coupled multiscale or multiphysics model.
+
+See the "Howto_couple"_Howto_couple.html doc page for more ideas about
+coupling LAMMPS to other codes. See the "Howto
+library"_Howto_library.html doc page for a description of the LAMMPS
+library interface provided in src/library.h and src/library.h. That
+interface is exposed to Python either when calling LAMMPS from Python
+or when calling Python from a LAMMPS input script and then calling
+back to LAMMPS from Python code. The library interface is designed to
+be easy to add funcionality to. Thus the Python interface to LAMMPS
+is also easy to extend as well.
+
+If you create interesting Python scripts that run LAMMPS or
+interesting Python functions that can be called from a LAMMPS input
+script, that you think would be genearlly useful, please post them as
+a pull request to our "GitHub site"_https://github.com/lammps/lammps,
+and they can be added to the LAMMPS distribution or webpage.
diff --git a/doc/src/Python_install.txt b/doc/src/Python_install.txt
new file mode 100644
index 0000000000000000000000000000000000000000..97f6bf3c3a6ba5c21bb9f043d9d7313b769c7742
--- /dev/null
+++ b/doc/src/Python_install.txt
@@ -0,0 +1,74 @@
+"Higher level section"_Python_head.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
+
+Installing LAMMPS in Python :h3
+
+For Python to invoke LAMMPS, there are 2 files it needs to know about:
+
+python/lammps.py
+src/liblammps.so :ul
+
+Lammps.py is the Python wrapper on the LAMMPS library interface.
+Liblammps.so is the shared LAMMPS library that Python loads, as
+described above.
+
+You can insure Python can find these files in one of two ways:
+
+set two environment variables
+run the python/install.py script :ul
+
+If you set the paths to these files as environment variables, you only
+have to do it once. For the csh or tcsh shells, add something like
+this to your ~/.cshrc file, one line for each of the two files:
+
+setenv PYTHONPATH $\{PYTHONPATH\}:/home/sjplimp/lammps/python
+setenv LD_LIBRARY_PATH $\{LD_LIBRARY_PATH\}:/home/sjplimp/lammps/src :pre
+
+If you use the python/install.py script, you need to invoke it every
+time you rebuild LAMMPS (as a shared library) or make changes to the
+python/lammps.py file.
+
+You can invoke install.py from the python directory as
+
+% python install.py \[libdir\] \[pydir\] :pre
+
+The optional libdir is where to copy the LAMMPS shared library to; the
+default is /usr/local/lib. The optional pydir is where to copy the
+lammps.py file to; the default is the site-packages directory of the
+version of Python that is running the install script.
+
+Note that libdir must be a location that is in your default
+LD_LIBRARY_PATH, like /usr/local/lib or /usr/lib. And pydir must be a
+location that Python looks in by default for imported modules, like
+its site-packages dir. If you want to copy these files to
+non-standard locations, such as within your own user space, you will
+need to set your PYTHONPATH and LD_LIBRARY_PATH environment variables
+accordingly, as above.
+
+If the install.py script does not allow you to copy files into system
+directories, prefix the python command with "sudo". If you do this,
+make sure that the Python that root runs is the same as the Python you
+run. E.g. you may need to do something like
+
+% sudo /usr/local/bin/python install.py \[libdir\] \[pydir\] :pre
+
+You can also invoke install.py from the make command in the src
+directory as
+
+% make install-python :pre
+
+In this mode you cannot append optional arguments. Again, you may
+need to prefix this with "sudo". In this mode you cannot control
+which Python is invoked by root.
+
+Note that if you want Python to be able to load different versions of
+the LAMMPS shared library (see "this section"_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.
diff --git a/doc/src/Python_library.txt b/doc/src/Python_library.txt
new file mode 100644
index 0000000000000000000000000000000000000000..9a3ea93fc30ee932cbc1a85e374f37fb41bddee9
--- /dev/null
+++ b/doc/src/Python_library.txt
@@ -0,0 +1,256 @@
+"Higher level section"_Python_head.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
+
+Python library interface :h3
+
+As described previously, the Python interface to LAMMPS consists of a
+Python "lammps" module, the source code for which is in
+python/lammps.py, which creates a "lammps" object, with a set of
+methods that can be invoked on that object. The sample Python code
+below assumes you have first imported the "lammps" module in your
+Python script, as follows:
+
+from lammps import lammps :pre
+
+These are the methods defined by the lammps module. If you look at
+the files src/library.cpp and src/library.h you will see they
+correspond one-to-one with calls you can make to the LAMMPS library
+from a C++ or C or Fortran program, and which are described on the
+"Howto library"_Howto_library.html doc page.
+
+The python/examples directory has Python scripts which show how Python
+can run LAMMPS, grab data, change it, and put it back into LAMMPS.
+
+lmp = lammps() # create a LAMMPS object using the default liblammps.so library
+ # 4 optional args are allowed: name, cmdargs, ptr, comm
+lmp = lammps(ptr=lmpptr) # use lmpptr as previously created LAMMPS object
+lmp = lammps(comm=split) # create a LAMMPS object with a custom communicator, requires mpi4py 2.0.0 or later
+lmp = lammps(name="g++") # create a LAMMPS object using the liblammps_g++.so library
+lmp = lammps(name="g++",cmdargs=list) # add LAMMPS command-line args, e.g. list = \["-echo","screen"\] :pre
+
+lmp.close() # destroy a LAMMPS object :pre
+
+version = lmp.version() # return the numerical version id, e.g. LAMMPS 2 Sep 2015 -> 20150902 :pre
+
+lmp.file(file) # run an entire input script, file = "in.lj"
+lmp.command(cmd) # invoke a single LAMMPS command, cmd = "run 100"
+lmp.commands_list(cmdlist) # invoke commands in cmdlist = ["run 10", "run 20"]
+lmp.commands_string(multicmd) # invoke commands in multicmd = "run 10\nrun 20" :pre
+
+size = lmp.extract_setting(name) # return data type info :pre
+
+xlo = lmp.extract_global(name,type) # extract a global quantity
+ # name = "boxxlo", "nlocal", etc
+ # type = 0 = int
+ # 1 = double :pre
+
+boxlo,boxhi,xy,yz,xz,periodicity,box_change = lmp.extract_box() # extract box info :pre
+
+coords = lmp.extract_atom(name,type) # extract a per-atom quantity
+ # name = "x", "type", etc
+ # type = 0 = vector of ints
+ # 1 = array of ints
+ # 2 = vector of doubles
+ # 3 = array of doubles :pre
+
+eng = lmp.extract_compute(id,style,type) # extract value(s) from a compute
+v3 = lmp.extract_fix(id,style,type,i,j) # extract value(s) from a fix
+ # id = ID of compute or fix
+ # style = 0 = global data
+ # 1 = per-atom data
+ # 2 = local data
+ # type = 0 = scalar
+ # 1 = vector
+ # 2 = array
+ # i,j = indices of value in global vector or array :pre
+
+var = lmp.extract_variable(name,group,flag) # extract value(s) from a variable
+ # name = name of variable
+ # group = group ID (ignored for equal-style variables)
+ # flag = 0 = equal-style variable
+ # 1 = atom-style variable :pre
+
+value = lmp.get_thermo(name) # return current value of a thermo keyword
+natoms = lmp.get_natoms() # total # of atoms as int :pre
+
+flag = lmp.set_variable(name,value) # set existing named string-style variable to value, flag = 0 if successful
+lmp.reset_box(boxlo,boxhi,xy,yz,xz) # reset the simulation box size :pre
+
+data = lmp.gather_atoms(name,type,count) # return per-atom property of all atoms gathered into data, ordered by atom ID
+ # name = "x", "charge", "type", etc
+data = lmp.gather_atoms_concat(name,type,count) # ditto, but concatenated atom values from each proc (unordered)
+data = lmp.gather_atoms_subset(name,type,count,ndata,ids) # ditto, but for subset of Ndata atoms with IDs :pre
+
+lmp.scatter_atoms(name,type,count,data) # scatter per-atom property to all atoms from data, ordered by atom ID
+ # name = "x", "charge", "type", etc
+ # count = # of per-atom values, 1 or 3, etc :pre
+lmp.scatter_atoms_subset(name,type,count,ndata,ids,data) # ditto, but for subset of Ndata atoms with IDs :pre
+
+lmp.create_atoms(n,ids,types,x,v,image,shrinkexceed) # create N atoms with IDs, types, x, v, and image flags :pre
+
+:line
+
+The lines
+
+from lammps import lammps
+lmp = lammps() :pre
+
+create an instance of LAMMPS, wrapped in a Python class by the lammps
+Python module, and return an instance of the Python class as lmp. It
+is used to make all subsequent calls to the LAMMPS library.
+
+Additional arguments to lammps() can be used to tell Python the name
+of the shared library to load or to pass arguments to the LAMMPS
+instance, the same as if LAMMPS were launched from a command-line
+prompt.
+
+If the ptr argument is set like this:
+
+lmp = lammps(ptr=lmpptr) :pre
+
+then lmpptr must be an argument passed to Python via the LAMMPS
+"python"_python.html command, when it is used to define a Python
+function that is invoked by the LAMMPS input script. This mode of
+calling Python from LAMMPS is described in the "Python
+call"_Python_call.html doc page. The variable lmpptr refers to the
+instance of LAMMPS that called the embedded Python interpreter. Using
+it as an argument to lammps() allows the returned Python class
+instance "lmp" to make calls to that instance of LAMMPS. See the
+"python"_python.html command doc page for examples using this syntax.
+
+Note that you can create multiple LAMMPS objects in your Python
+script, and coordinate and run multiple simulations, e.g.
+
+from lammps import lammps
+lmp1 = lammps()
+lmp2 = lammps()
+lmp1.file("in.file1")
+lmp2.file("in.file2") :pre
+
+The file(), command(), commands_list(), commands_string() methods
+allow an input script, a single command, or multiple commands to be
+invoked.
+
+The extract_setting(), extract_global(), extract_box(),
+extract_atom(), extract_compute(), extract_fix(), and
+extract_variable() methods return values or pointers to data
+structures internal to LAMMPS.
+
+For extract_global() see the src/library.cpp file for the list of
+valid names. New names could easily be added. A double or integer is
+returned. You need to specify the appropriate data type via the type
+argument.
+
+For extract_atom(), a pointer to internal LAMMPS atom-based data is
+returned, which you can use via normal Python subscripting. See the
+extract() method in the src/atom.cpp file for a list of valid names.
+Again, new names could easily be added if the property you want is not
+listed. A pointer to a vector of doubles or integers, or a pointer to
+an array of doubles (double **) or integers (int **) is returned. You
+need to specify the appropriate data type via the type argument.
+
+For extract_compute() and extract_fix(), the global, per-atom, or
+local data calculated by the compute or fix can be accessed. What is
+returned depends on whether the compute or fix calculates a scalar or
+vector or array. For a scalar, a single double value is returned. If
+the compute or fix calculates a vector or array, a pointer to the
+internal LAMMPS data is returned, which you can use via normal Python
+subscripting. The one exception is that for a fix that calculates a
+global vector or array, a single double value from the vector or array
+is returned, indexed by I (vector) or I and J (array). I,J are
+zero-based indices. The I,J arguments can be left out if not needed.
+See the "Howto output"_Howto_output.html doc page for a discussion of
+global, per-atom, and local data, and of scalar, vector, and array
+data types. See the doc pages for individual "computes"_compute.html
+and "fixes"_fix.html for a description of what they calculate and
+store.
+
+For extract_variable(), an "equal-style or atom-style
+variable"_variable.html is evaluated and its result returned.
+
+For equal-style variables a single double value is returned and the
+group argument is ignored. For atom-style variables, a vector of
+doubles is returned, one value per atom, which you can use via normal
+Python subscripting. The values will be zero for atoms not in the
+specified group.
+
+The get_thermo() method returns returns the current value of a thermo
+keyword as a float.
+
+The get_natoms() method returns the total number of atoms in the
+simulation, as an int.
+
+The set_variable() methosd sets an existing string-style variable to a
+new string value, so that subsequent LAMMPS commands can access the
+variable.
+
+The reset_box() emthods resets the size and shape of the simulation
+box, e.g. as part of restoring a previously extracted and saved state
+of a simulation.
+
+The gather methods collect peratom info of the requested type (atom
+coords, atom types, forces, etc) from all processors, and returns the
+same vector of values to each callling processor. The scatter
+functions do the inverse. They distribute a vector of peratom values,
+passed by all calling processors, to invididual atoms, which may be
+owned by different processos.
+
+Note that the data returned by the gather methods,
+e.g. gather_atoms("x"), is different from the data structure returned
+by extract_atom("x") in four ways. (1) Gather_atoms() returns a
+vector which you index as x\[i\]; extract_atom() returns an array
+which you index as x\[i\]\[j\]. (2) Gather_atoms() orders the atoms
+by atom ID while extract_atom() does not. (3) Gather_atoms() returns
+a list of all atoms in the simulation; extract_atoms() returns just
+the atoms local to each processor. (4) Finally, the gather_atoms()
+data structure is a copy of the atom coords stored internally in
+LAMMPS, whereas extract_atom() returns an array that effectively
+points directly to the internal data. This means you can change
+values inside LAMMPS from Python by assigning a new values to the
+extract_atom() array. To do this with the gather_atoms() vector, you
+need to change values in the vector, then invoke the scatter_atoms()
+method.
+
+For the scatter methods, the array of coordinates passed to must be a
+ctypes vector of ints or doubles, allocated and initialized something
+like this:
+
+from ctypes import *
+natoms = lmp.get_natoms()
+n3 = 3*natoms
+x = (n3*c_double)()
+x\[0\] = x coord of atom with ID 1
+x\[1\] = y coord of atom with ID 1
+x\[2\] = z coord of atom with ID 1
+x\[3\] = x coord of atom with ID 2
+...
+x\[n3-1\] = z coord of atom with ID natoms
+lmp.scatter_atoms("x",1,3,x) :pre
+
+Alternatively, you can just change values in the vector returned by
+the gather methods, since they are also ctypes vectors.
+
+:line
+
+As noted above, these Python class methods correspond one-to-one with
+the functions in the LAMMPS library interface in src/library.cpp and
+library.h. This means you can extend the Python wrapper via the
+following steps:
+
+Add a new interface function to src/library.cpp and
+src/library.h. :ulb,l
+
+Rebuild LAMMPS as a shared library. :l
+
+Add a wrapper method to python/lammps.py for this interface
+function. :l
+
+You should now be able to invoke the new interface function from a
+Python script. :l
+:ule
diff --git a/doc/src/Python_mpi.txt b/doc/src/Python_mpi.txt
new file mode 100644
index 0000000000000000000000000000000000000000..96c42e0d0ff2a06ff889f3c5072047df6677632f
--- /dev/null
+++ b/doc/src/Python_mpi.txt
@@ -0,0 +1,67 @@
+"Higher level section"_Python_head.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
+
+Extending Python to run in parallel :h3
+
+If you wish to run LAMMPS in parallel from Python, you need to extend
+your Python with an interface to MPI. This also allows you to
+make MPI calls directly from Python in your script, if you desire.
+
+We recommend use of mpi4py:
+
+"PyPar"_https://github.com/daleroberts/pypar :ul
+
+As of version 2.0.0 it allows passing a custom MPI communicator to
+the LAMMPS constructor, which means one can easily run one or more
+LAMMPS instances on subsets of the total MPI ranks.
+
+To install mpi4py (version mpi4py-2.0.0 as of Oct 2015), unpack it
+and from its main directory, type
+
+python setup.py build
+sudo python setup.py install :pre
+
+Again, the "sudo" is only needed if required to copy mpi4py files into
+your Python distribution's site-packages directory. To install with
+user privilege into the user local directory type
+
+python setup.py install --user :pre
+
+If you have successfully installed mpi4py, you should be able to run
+Python and type
+
+from mpi4py import MPI :pre
+
+without error. You should also be able to run python in parallel
+on a simple test script
+
+% mpirun -np 4 python test.py :pre
+
+where test.py contains the lines
+
+from mpi4py import MPI
+comm = MPI.COMM_WORLD
+print "Proc %d out of %d procs" % (comm.Get_rank(),comm.Get_size()) :pre
+
+and see one line of output for each processor you run on.
+
+NOTE: To use mpi4py and LAMMPS in parallel from Python, you must
+insure both are using the same version of MPI. If you only have one
+MPI installed on your system, this is not an issue, but it can be if
+you have multiple MPIs. Your LAMMPS build is explicit about which MPI
+it is using, since you specify the details in your lo-level
+src/MAKE/Makefile.foo file. Mpi4py uses the "mpicc" command to find
+information about the MPI it uses to build against. And it tries to
+load "libmpi.so" from the LD_LIBRARY_PATH. This may or may not find
+the MPI library that LAMMPS is using. If you have problems running
+both mpi4py and LAMMPS together, this is an issue you may need to
+address, e.g. by moving other MPI installations so that mpi4py finds
+the right one.
+
+
diff --git a/doc/src/Python_overview.txt b/doc/src/Python_overview.txt
new file mode 100644
index 0000000000000000000000000000000000000000..a5d6a469ffdaffddfe5347e1c5ecaec0be5257cb
--- /dev/null
+++ b/doc/src/Python_overview.txt
@@ -0,0 +1,35 @@
+"Previous Section"_Examples.html - "LAMMPS WWW Site"_lws -
+"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
+Section"_Tools.html :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands.html#comm)
+
+:line
+
+Overview of Python and LAMMPS :h3
+
+LAMMPS can work together with Python in three ways. First, Python can
+wrap LAMMPS through the its "library interface"_Howto_library.html, so
+that a Python script can create one or more instances of LAMMPS and
+launch one or more simulations. In Python lingo, this is "extending"
+Python with LAMMPS.
+
+Second, a lower-level Python interface can be used indirectly through
+provided PyLammps and IPyLammps wrapper classes, written in Python.
+These wrappers try to simplify the usage of LAMMPS in Python by
+providing an object-based interface to common LAMMPS functionality.
+They also reduces the amount of code necessary to parameterize LAMMPS
+scripts through Python and make variables and computes directly
+accessible.
+
+Third, LAMMPS can use the Python interpreter, so that a LAMMPS
+input script can invoke Python code directly, and pass information
+back-and-forth between the input script and Python functions you
+write. This Python code can also callback to LAMMPS to query or change
+its attributes. In Python lingo, this is "embedding" Python in
+LAMMPS. When used in this mode, Python can perform operations that
+the simple LAMMPS input script syntax cannot.
+
+
diff --git a/doc/src/Python_pylammps.txt b/doc/src/Python_pylammps.txt
new file mode 100644
index 0000000000000000000000000000000000000000..303ac21a276fcab9444a33686b2373ee79cfae53
--- /dev/null
+++ b/doc/src/Python_pylammps.txt
@@ -0,0 +1,14 @@
+"Higher level section"_Python_head.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
+
+PyLammps interface :h3
+
+PyLammps is a Python wrapper class which can be created on its own or
+use an existing lammps Python object. It has its own "Howto
+pylammps"_Howto_pylammps.html doc page.
diff --git a/doc/src/Python_run.txt b/doc/src/Python_run.txt
new file mode 100644
index 0000000000000000000000000000000000000000..963248efced3a9ce8a084cf3411f562e33f00138
--- /dev/null
+++ b/doc/src/Python_run.txt
@@ -0,0 +1,40 @@
+"Higher level section"_Python_head.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
+
+Run LAMMPS from Python :h3
+
+The LAMMPS distribution includes a python directory with all you need
+to run LAMMPS from Python. The python/lammps.py file wraps the LAMMPS
+library interface, with one wrapper function per LAMMPS library
+function. This file makes it is possible to do the following either
+from a Python script, or interactively from a Python prompt: create
+one or more instances of LAMMPS, invoke LAMMPS commands or give it an
+input script, run LAMMPS incrementally, extract LAMMPS results, an
+modify internal LAMMPS variables. From a Python script you can do
+this in serial or parallel. Running Python interactively in parallel
+does not generally work, unless you have a version of Python that
+extends Python to enable multiple instances of Python to read what you
+type.
+
+To do all of this, you must first build LAMMPS as a shared library,
+then insure that your Python can find the python/lammps.py file and
+the shared library.
+
+Two advantages of using Python to run LAMMPS are how concise the
+language is, and that it can be run interactively, enabling rapid
+development and debugging. If you use it to mostly invoke costly
+operations within LAMMPS, such as running a simulation for a
+reasonable number of timesteps, then the overhead cost of invoking
+LAMMPS thru Python will be negligible.
+
+The Python wrapper for LAMMPS uses the "ctypes" package in Python,
+which auto-generates the interface code needed between Python and a
+set of C-style library functions. Ctypes is part of standard Python
+for versions 2.5 and later. You can check which version of Python you
+have by simply typing "python" at a shell prompt.
diff --git a/doc/src/Python_shlib.txt b/doc/src/Python_shlib.txt
new file mode 100644
index 0000000000000000000000000000000000000000..91c90d9a8f46628102a7ce200fb535e873a9061c
--- /dev/null
+++ b/doc/src/Python_shlib.txt
@@ -0,0 +1,73 @@
+"Higher level section"_Python_head.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 as a shared library :h3
+
+Build LAMMPS as a shared library using make :h4
+
+Instructions on how to build LAMMPS as a shared library are given on
+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
+
+make foo mode=shlib :pre
+
+where foo is the machine target name, such as mpi or serial.
+This should create the file liblammps_foo.so in the src directory, as
+well as a soft link liblammps.so, which is what the Python wrapper will
+load by default. Note that if you are building multiple machine
+versions of the shared library, the soft link is always set to the
+most recently built version.
+
+NOTE: If you are building LAMMPS with an MPI or FFT library or other
+auxiliary libraries (used by various packages), then all of these
+extra libraries must also be shared libraries. If the LAMMPS
+shared-library build fails with an error complaining about this, see
+the "Build_basics"_Build_basics.html doc page.
+
+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.
diff --git a/doc/src/Python_test.txt b/doc/src/Python_test.txt
new file mode 100644
index 0000000000000000000000000000000000000000..2bfec91bd60827dcfaab23ca389ea065cb92b846
--- /dev/null
+++ b/doc/src/Python_test.txt
@@ -0,0 +1,131 @@
+"Higher level section"_Python_head.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
+
+Test the Python/LAMMPS interface :h3
+
+To test if LAMMPS is callable from Python, launch Python interactively
+and type:
+
+>>> from lammps import lammps
+>>> lmp = lammps() :pre
+
+If you get no errors, you're ready to use LAMMPS from Python. If the
+2nd command fails, the most common error to see is
+
+OSError: Could not load LAMMPS dynamic library :pre
+
+which means Python was unable to load the LAMMPS shared library. This
+typically occurs if the system can't find the LAMMPS shared library or
+one of the auxiliary shared libraries it depends on, or if something
+about the library is incompatible with your Python. The error message
+should give you an indication of what went wrong.
+
+You can also test the load directly in Python as follows, without
+first importing from the lammps.py file:
+
+>>> from ctypes import CDLL
+>>> CDLL("liblammps.so") :pre
+
+If an error occurs, carefully go thru the steps on the
+"Build_basics"_Build_basics.html doc page about building a shared
+library and the "Python_install"_Python_install.html doc page about
+insuring Python can find the necessary two files it needs.
+
+[Test LAMMPS and Python in serial:] :h4
+
+To run a LAMMPS test in serial, type these lines into Python
+interactively from the bench directory:
+
+>>> from lammps import lammps
+>>> lmp = lammps()
+>>> lmp.file("in.lj") :pre
+
+Or put the same lines in the file test.py and run it as
+
+% python test.py :pre
+
+Either way, you should see the results of running the in.lj benchmark
+on a single processor appear on the screen, the same as if you had
+typed something like:
+
+lmp_g++ -in in.lj :pre
+
+[Test LAMMPS and Python in parallel:] :h4
+
+To run LAMMPS in parallel, assuming you have installed the
+"PyPar"_https://github.com/daleroberts/pypar package as discussed
+above, create a test.py file containing these lines:
+
+import pypar
+from lammps import lammps
+lmp = lammps()
+lmp.file("in.lj")
+print "Proc %d out of %d procs has" % (pypar.rank(),pypar.size()),lmp
+pypar.finalize() :pre
+
+To run LAMMPS in parallel, assuming you have installed the
+"mpi4py"_https://bitbucket.org/mpi4py/mpi4py package as discussed
+above, create a test.py file containing these lines:
+
+from mpi4py import MPI
+from lammps import lammps
+lmp = lammps()
+lmp.file("in.lj")
+me = MPI.COMM_WORLD.Get_rank()
+nprocs = MPI.COMM_WORLD.Get_size()
+print "Proc %d out of %d procs has" % (me,nprocs),lmp
+MPI.Finalize() :pre
+
+You can either script in parallel as:
+
+% mpirun -np 4 python test.py :pre
+
+and you should see the same output as if you had typed
+
+% mpirun -np 4 lmp_g++ -in in.lj :pre
+
+Note that if you leave out the 3 lines from test.py that specify PyPar
+commands you will instantiate and run LAMMPS independently on each of
+the P processors specified in the mpirun command. In this case you
+should get 4 sets of output, each showing that a LAMMPS run was made
+on a single processor, instead of one set of output showing that
+LAMMPS ran on 4 processors. If the 1-processor outputs occur, it
+means that PyPar is not working correctly.
+
+Also note that once you import the PyPar module, PyPar initializes MPI
+for you, and you can use MPI calls directly in your Python script, as
+described in the PyPar documentation. The last line of your Python
+script should be pypar.finalize(), to insure MPI is shut down
+correctly.
+
+[Running Python scripts:] :h4
+
+Note that any Python script (not just for LAMMPS) can be invoked in
+one of several ways:
+
+% python foo.script
+% python -i foo.script
+% foo.script :pre
+
+The last command requires that the first line of the script be
+something like this:
+
+#!/usr/local/bin/python
+#!/usr/local/bin/python -i :pre
+
+where the path points to where you have Python installed, and that you
+have made the script file executable:
+
+% chmod +x foo.script :pre
+
+Without the "-i" flag, Python will exit when the script finishes.
+With the "-i" flag, you will be left in the Python interpreter when
+the script finishes, so you can type subsequent commands. As
+mentioned above, you can only run Python interactively when running
+Python on a single processor, not in parallel.
diff --git a/doc/src/Run_basics.txt b/doc/src/Run_basics.txt
new file mode 100644
index 0000000000000000000000000000000000000000..02139a8c69ad9f7ddb37b7fa8e24e7b080de5d37
--- /dev/null
+++ b/doc/src/Run_basics.txt
@@ -0,0 +1,89 @@
+"Higher level section"_Run_head.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.
diff --git a/doc/src/Run_head.txt b/doc/src/Run_head.txt
new file mode 100644
index 0000000000000000000000000000000000000000..5e2c0fe23539eb3d513dd9b12699a7c78b09efc2
--- /dev/null
+++ b/doc/src/Run_head.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 -->
diff --git a/doc/src/Run_options.txt b/doc/src/Run_options.txt
new file mode 100644
index 0000000000000000000000000000000000000000..9c862d7b8ec136b75fe95e5126a500a3801bc359
--- /dev/null
+++ b/doc/src/Run_options.txt
@@ -0,0 +1,469 @@
+"Higher level section"_Run_head.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.
diff --git a/doc/src/Run_output.txt b/doc/src/Run_output.txt
new file mode 100644
index 0000000000000000000000000000000000000000..7d5a9e6ae6af55629a6bd25d5e06d0cd3f8e1f93
--- /dev/null
+++ b/doc/src/Run_output.txt
@@ -0,0 +1,176 @@
+"Higher level section"_Run_head.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.
diff --git a/doc/src/Run_windows.txt b/doc/src/Run_windows.txt
new file mode 100644
index 0000000000000000000000000000000000000000..2b93cc7d4944f4a3e61a826d9967986fb5d32516
--- /dev/null
+++ b/doc/src/Run_windows.txt
@@ -0,0 +1,73 @@
+"Higher level section"_Run_head.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
diff --git a/doc/src/Section_accelerate.txt b/doc/src/Section_accelerate.txt
deleted file mode 100644
index d5cbf77a84e2881a7cfd2f23d6cd94d98031cfec..0000000000000000000000000000000000000000
--- a/doc/src/Section_accelerate.txt
+++ /dev/null
@@ -1,391 +0,0 @@
-"Previous Section"_Section_packages.html - "LAMMPS WWW Site"_lws -
-"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
-Section"_Section_howto.html :c
-
-:link(lws,http://lammps.sandia.gov)
-:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
-
-:line
-
-5. Accelerating LAMMPS performance :h2
-
-This section describes various methods for improving LAMMPS
-performance for different classes of problems running on different
-kinds of machines.
-
-There are two thrusts to the discussion that follows. The
-first is using code options that implement alternate algorithms
-that can speed-up a simulation. The second is to use one
-of the several accelerator packages provided with LAMMPS that
-contain code optimized for certain kinds of hardware, including
-multi-core CPUs, GPUs, and Intel Xeon Phi coprocessors.
-
-5.1 "Measuring performance"_#acc_1 :ulb,l
-5.2 "Algorithms and code options to boost performace"_#acc_2 :l
-5.3 "Accelerator packages with optimized styles"_#acc_3 :l
- 5.3.1 "GPU package"_accelerate_gpu.html :l
- 5.3.2 "USER-INTEL package"_accelerate_intel.html :l
- 5.3.3 "KOKKOS package"_accelerate_kokkos.html :l
- 5.3.4 "USER-OMP package"_accelerate_omp.html :l
- 5.3.5 "OPT package"_accelerate_opt.html :l
-5.4 "Comparison of various accelerator packages"_#acc_4 :l
-:ule
-
-The "Benchmark page"_http://lammps.sandia.gov/bench.html of the LAMMPS
-web site gives performance results for the various accelerator
-packages discussed in Section 5.2, for several of the standard LAMMPS
-benchmark problems, as a function of problem size and number of
-compute nodes, on different hardware platforms.
-
-:line
-:line
-
-5.1 Measuring performance :h3,link(acc_1)
-
-Before trying to make your simulation run faster, you should
-understand how it currently performs and where the bottlenecks are.
-
-The best way to do this is run the your system (actual number of
-atoms) for a modest number of timesteps (say 100 steps) on several
-different processor counts, including a single processor if possible.
-Do this for an equilibrium version of your system, so that the
-100-step timings are representative of a much longer run. There is
-typically no need to run for 1000s of timesteps to get accurate
-timings; you can simply extrapolate from short runs.
-
-For the set of runs, look at the timing data printed to the screen and
-log file at the end of each LAMMPS run. "This
-section"_Section_start.html#start_7 of the manual has an overview.
-
-Running on one (or a few processors) should give a good estimate of
-the serial performance and what portions of the timestep are taking
-the most time. Running the same problem on a few different processor
-counts should give an estimate of parallel scalability. I.e. if the
-simulation runs 16x faster on 16 processors, its 100% parallel
-efficient; if it runs 8x faster on 16 processors, it's 50% efficient.
-
-The most important data to look at in the timing info is the timing
-breakdown and relative percentages. For example, trying different
-options for speeding up the long-range solvers will have little impact
-if they only consume 10% of the run time. If the pairwise time is
-dominating, you may want to look at GPU or OMP versions of the pair
-style, as discussed below. Comparing how the percentages change as
-you increase the processor count gives you a sense of how different
-operations within the timestep are scaling. Note that if you are
-running with a Kspace solver, there is additional output on the
-breakdown of the Kspace time. For PPPM, this includes the fraction
-spent on FFTs, which can be communication intensive.
-
-Another important detail in the timing info are the histograms of
-atoms counts and neighbor counts. If these vary widely across
-processors, you have a load-imbalance issue. This often results in
-inaccurate relative timing data, because processors have to wait when
-communication occurs for other processors to catch up. Thus the
-reported times for "Communication" or "Other" may be higher than they
-really are, due to load-imbalance. If this is an issue, you can
-uncomment the MPI_Barrier() lines in src/timer.cpp, and recompile
-LAMMPS, to obtain synchronized timings.
-
-:line
-
-5.2 General strategies :h3,link(acc_2)
-
-NOTE: this section 5.2 is still a work in progress
-
-Here is a list of general ideas for improving simulation performance.
-Most of them are only applicable to certain models and certain
-bottlenecks in the current performance, so let the timing data you
-generate be your guide. It is hard, if not impossible, to predict how
-much difference these options will make, since it is a function of
-problem size, number of processors used, and your machine. There is
-no substitute for identifying performance bottlenecks, and trying out
-various options.
-
-rRESPA
-2-FFT PPPM
-Staggered PPPM
-single vs double PPPM
-partial charge PPPM
-verlet/split run style
-processor command for proc layout and numa layout
-load-balancing: balance and fix balance :ul
-
-2-FFT PPPM, also called {analytic differentiation} or {ad} PPPM, uses
-2 FFTs instead of the 4 FFTs used by the default {ik differentiation}
-PPPM. However, 2-FFT PPPM also requires a slightly larger mesh size to
-achieve the same accuracy as 4-FFT PPPM. For problems where the FFT
-cost is the performance bottleneck (typically large problems running
-on many processors), 2-FFT PPPM may be faster than 4-FFT PPPM.
-
-Staggered PPPM performs calculations using two different meshes, one
-shifted slightly with respect to the other. This can reduce force
-aliasing errors and increase the accuracy of the method, but also
-doubles the amount of work required. For high relative accuracy, using
-staggered PPPM allows one to half the mesh size in each dimension as
-compared to regular PPPM, which can give around a 4x speedup in the
-kspace time. However, for low relative accuracy, using staggered PPPM
-gives little benefit and can be up to 2x slower in the kspace
-time. For example, the rhodopsin benchmark was run on a single
-processor, and results for kspace time vs. relative accuracy for the
-different methods are shown in the figure below. For this system,
-staggered PPPM (using ik differentiation) becomes useful when using a
-relative accuracy of slightly greater than 1e-5 and above.
-
-:c,image(JPG/rhodo_staggered.jpg)
-
-NOTE: Using staggered PPPM may not give the same increase in accuracy
-of energy and pressure as it does in forces, so some caution must be
-used if energy and/or pressure are quantities of interest, such as
-when using a barostat.
-
-:line
-
-5.3 Packages with optimized styles :h3,link(acc_3)
-
-Accelerated versions of various "pair_style"_pair_style.html,
-"fixes"_fix.html, "computes"_compute.html, and other commands have
-been added to LAMMPS, which will typically run faster than the
-standard non-accelerated versions. Some require appropriate hardware
-to be present on your system, e.g. GPUs or Intel Xeon Phi
-coprocessors.
-
-All of these commands are in packages provided with LAMMPS. An
-overview of packages is give in "Section
-packages"_Section_packages.html.
-
-These are the accelerator packages
-currently in LAMMPS, either as standard or user packages:
-
-"GPU Package"_accelerate_gpu.html : for NVIDIA GPUs as well as OpenCL support
-"USER-INTEL Package"_accelerate_intel.html : for Intel CPUs and Intel Xeon Phi
-"KOKKOS Package"_accelerate_kokkos.html : for Nvidia GPUs, Intel Xeon Phi, and OpenMP threading
-"USER-OMP Package"_accelerate_omp.html : for OpenMP threading and generic CPU optimizations
-"OPT Package"_accelerate_opt.html : generic CPU optimizations :tb(s=:)
-
-<!-- RST
-
-.. toctree::
- :maxdepth: 1
- :hidden:
-
- accelerate_gpu
- accelerate_intel
- accelerate_kokkos
- accelerate_omp
- accelerate_opt
-
-END_RST -->
-
-Inverting this list, LAMMPS currently has acceleration support for
-three kinds of hardware, via the listed packages:
-
-Many-core CPUs : "USER-INTEL"_accelerate_intel.html, "KOKKOS"_accelerate_kokkos.html, "USER-OMP"_accelerate_omp.html, "OPT"_accelerate_opt.html packages
-NVIDIA GPUs : "GPU"_accelerate_gpu.html, "KOKKOS"_accelerate_kokkos.html packages
-Intel Phi : "USER-INTEL"_accelerate_intel.html, "KOKKOS"_accelerate_kokkos.html packages :tb(s=:)
-
-Which package is fastest for your hardware may depend on the size
-problem you are running and what commands (accelerated and
-non-accelerated) are invoked by your input script. While these doc
-pages include performance guidelines, there is no substitute for
-trying out the different packages appropriate to your hardware.
-
-Any accelerated style has the same name as the corresponding standard
-style, except that a suffix is appended. Otherwise, the syntax for
-the command that uses the style is identical, their functionality is
-the same, and the numerical results it produces should also be the
-same, except for precision and round-off effects.
-
-For example, all of these styles are accelerated variants of the
-Lennard-Jones "pair_style lj/cut"_pair_lj.html:
-
-"pair_style lj/cut/gpu"_pair_lj.html
-"pair_style lj/cut/intel"_pair_lj.html
-"pair_style lj/cut/kk"_pair_lj.html
-"pair_style lj/cut/omp"_pair_lj.html
-"pair_style lj/cut/opt"_pair_lj.html :ul
-
-To see what accelerate styles are currently available, see
-"Section 3.5"_Section_commands.html#cmd_5 of the manual. The
-doc pages for individual commands (e.g. "pair lj/cut"_pair_lj.html or
-"fix nve"_fix_nve.html) also list any accelerated variants available
-for that style.
-
-To use an accelerator package in LAMMPS, and one or more of the styles
-it provides, follow these general steps. Details vary from package to
-package and are explained in the individual accelerator doc pages,
-listed above:
-
-build the accelerator library |
- only for GPU package |
-install the accelerator package |
- make yes-opt, make yes-user-intel, etc |
-add compile/link flags to Makefile.machine in src/MAKE |
- only for USER-INTEL, KOKKOS, USER-OMP, OPT packages |
-re-build LAMMPS |
- make machine |
-prepare and test a regular LAMMPS simulation |
- lmp_machine -in in.script; mpirun -np 32 lmp_machine -in in.script |
-enable specific accelerator support via '-k on' "command-line switch"_Section_start.html#start_6, |
- only needed for KOKKOS package |
-set any needed options for the package via "-pk" "command-line switch"_Section_start.html#start_6 or "package"_package.html command, |
- only if defaults need to be changed |
-use accelerated styles in your input via "-sf" "command-line switch"_Section_start.html#start_6 or "suffix"_suffix.html command | lmp_machine -in in.script -sf gpu
-:tb(c=2,s=|)
-
-Note that the first 4 steps can be done as a single command with
-suitable make command invocations. This is discussed in "Section
-4"_Section_packages.html of the manual, and its use is
-illustrated in the individual accelerator sections. Typically these
-steps only need to be done once, to create an executable that uses one
-or more accelerator packages.
-
-The last 4 steps can all be done from the command-line when LAMMPS is
-launched, without changing your input script, as illustrated in the
-individual accelerator sections. Or you can add
-"package"_package.html and "suffix"_suffix.html commands to your input
-script.
-
-NOTE: With a few exceptions, you can build a single LAMMPS executable
-with all its accelerator packages installed. Note however that the
-USER-INTEL and KOKKOS packages require you to choose one of their
-hardware options when building for a specific platform. I.e. CPU or
-Phi option for the USER-INTEL package. Or the OpenMP, Cuda, or Phi
-option for the KOKKOS package.
-
-These are the exceptions. You cannot build a single executable with:
-
-both the USER-INTEL Phi and KOKKOS Phi options
-the USER-INTEL Phi or Kokkos Phi option, and the GPU package :ul
-
-See the examples/accelerate/README and make.list files for sample
-Make.py commands that build LAMMPS with any or all of the accelerator
-packages. As an example, here is a command that builds with all the
-GPU related packages installed (GPU, KOKKOS with Cuda), including
-settings to build the needed auxiliary GPU libraries for Kepler GPUs:
-
-Make.py -j 16 -p omp gpu kokkos -cc nvcc wrap=mpi \
- -gpu mode=double arch=35 -kokkos cuda arch=35 lib-all file mpi :pre
-
-The examples/accelerate directory also has input scripts that can be
-used with all of the accelerator packages. See its README file for
-details.
-
-Likewise, the bench directory has FERMI and KEPLER and PHI
-sub-directories with Make.py commands and input scripts for using all
-the accelerator packages on various machines. See the README files in
-those dirs.
-
-As mentioned above, the "Benchmark
-page"_http://lammps.sandia.gov/bench.html of the LAMMPS web site gives
-performance results for the various accelerator packages for several
-of the standard LAMMPS benchmark problems, as a function of problem
-size and number of compute nodes, on different hardware platforms.
-
-Here is a brief summary of what the various packages provide. Details
-are in the individual accelerator sections.
-
-Styles with a "gpu" suffix are part of the GPU package, and can be run
-on NVIDIA GPUs. The speed-up on a GPU depends on a variety of
-factors, discussed in the accelerator sections. :ulb,l
-
-Styles with an "intel" suffix are part of the USER-INTEL
-package. These styles support vectorized single and mixed precision
-calculations, in addition to full double precision. In extreme cases,
-this can provide speedups over 3.5x on CPUs. The package also
-supports acceleration in "offload" mode to Intel(R) Xeon Phi(TM)
-coprocessors. This can result in additional speedup over 2x depending
-on the hardware configuration. :l
-
-Styles with a "kk" suffix are part of the KOKKOS package, and can be
-run using OpenMP on multicore CPUs, on an NVIDIA GPU, or on an Intel
-Xeon Phi in "native" mode. The speed-up depends on a variety of
-factors, as discussed on the KOKKOS accelerator page. :l
-
-Styles with an "omp" suffix are part of the USER-OMP package and allow
-a pair-style to be run in multi-threaded mode using OpenMP. This can
-be useful on nodes with high-core counts when using less MPI processes
-than cores is advantageous, e.g. when running with PPPM so that FFTs
-are run on fewer MPI processors or when the many MPI tasks would
-overload the available bandwidth for communication. :l
-
-Styles with an "opt" suffix are part of the OPT package and typically
-speed-up the pairwise calculations of your simulation by 5-25% on a
-CPU. :l
-:ule
-
-The individual accelerator package doc pages explain:
-
-what hardware and software the accelerated package requires
-how to build LAMMPS with the accelerated package
-how to run with the accelerated package either via command-line switches or modifying the input script
-speed-ups to expect
-guidelines for best performance
-restrictions :ul
-
-:line
-
-5.4 Comparison of various accelerator packages :h3,link(acc_4)
-
-NOTE: this section still needs to be re-worked with additional KOKKOS
-and USER-INTEL information.
-
-The next section compares and contrasts the various accelerator
-options, since there are multiple ways to perform OpenMP threading,
-run on GPUs, and run on Intel Xeon Phi coprocessors.
-
-All 3 of these packages accelerate a LAMMPS calculation using NVIDIA
-hardware, but they do it in different ways.
-
-As a consequence, for a particular simulation on specific hardware,
-one package may be faster than the other. We give guidelines below,
-but the best way to determine which package is faster for your input
-script is to try both of them on your machine. See the benchmarking
-section below for examples where this has been done.
-
-[Guidelines for using each package optimally:]
-
-The GPU package allows you to assign multiple CPUs (cores) to a single
-GPU (a common configuration for "hybrid" nodes that contain multicore
-CPU(s) and GPU(s)) and works effectively in this mode. :ulb,l
-
-The GPU package moves per-atom data (coordinates, forces)
-back-and-forth between the CPU and GPU every timestep. The
-KOKKOS/CUDA package only does this on timesteps when a CPU calculation
-is required (e.g. to invoke a fix or compute that is non-GPU-ized).
-Hence, if you can formulate your input script to only use GPU-ized
-fixes and computes, and avoid doing I/O too often (thermo output, dump
-file snapshots, restart files), then the data transfer cost of the
-KOKKOS/CUDA package can be very low, causing it to run faster than the
-GPU package. :l
-
-The GPU package is often faster than the KOKKOS/CUDA package, if the
-number of atoms per GPU is smaller. The crossover point, in terms of
-atoms/GPU at which the KOKKOS/CUDA package becomes faster depends
-strongly on the pair style. For example, for a simple Lennard Jones
-system the crossover (in single precision) is often about 50K-100K
-atoms per GPU. When performing double precision calculations the
-crossover point can be significantly smaller. :l
-
-Both packages compute bonded interactions (bonds, angles, etc) on the
-CPU. If the GPU package is running with several MPI processes
-assigned to one GPU, the cost of computing the bonded interactions is
-spread across more CPUs and hence the GPU package can run faster. :l
-
-When using the GPU package with multiple CPUs assigned to one GPU, its
-performance depends to some extent on high bandwidth between the CPUs
-and the GPU. Hence its performance is affected if full 16 PCIe lanes
-are not available for each GPU. In HPC environments this can be the
-case if S2050/70 servers are used, where two devices generally share
-one PCIe 2.0 16x slot. Also many multi-GPU mainboards do not provide
-full 16 lanes to each of the PCIe 2.0 16x slots. :l
-:ule
-
-[Differences between the two packages:]
-
-The GPU package accelerates only pair force, neighbor list, and PPPM
-calculations. :ulb,l
-
-The GPU package requires neighbor lists to be built on the CPU when using
-exclusion lists, hybrid pair styles, or a triclinic simulation box. :l
-:ule
diff --git a/doc/src/Section_commands.txt b/doc/src/Section_commands.txt
deleted file mode 100644
index e44595455fd9ac57d4257d1f3a0d7e2d2d6fe9d1..0000000000000000000000000000000000000000
--- a/doc/src/Section_commands.txt
+++ /dev/null
@@ -1,1288 +0,0 @@
-"Previous Section"_Section_start.html - "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Section_packages.html :c
-
-:link(lws,http://lammps.sandia.gov)
-:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
-
-:line
-
-3. Commands :h2
-
-This section describes how a LAMMPS input script is formatted and the
-input script commands used to define a LAMMPS simulation.
-
-3.1 "LAMMPS input script"_#cmd_1
-3.2 "Parsing rules"_#cmd_2
-3.3 "Input script structure"_#cmd_3
-3.4 "Commands listed by category"_#cmd_4
-3.5 "Commands listed alphabetically"_#cmd_5 :all(b)
-
-:line
-:line
-
-3.1 LAMMPS input script :link(cmd_1),h4
-
-LAMMPS executes by reading commands from a input script (text file),
-one line at a time. When the input script ends, LAMMPS exits. Each
-command causes LAMMPS to take some action. It may set an internal
-variable, read in a file, or run a simulation. Most commands have
-default settings, which means you only need to use the command if you
-wish to change the default.
-
-In many cases, the ordering of commands in an input script is not
-important. However the following rules apply:
-
-(1) LAMMPS does not read your entire input script and then perform a
-simulation with all the settings. Rather, the input script is read
-one line at a time and each command takes effect when it is read.
-Thus this sequence of commands:
-
-timestep 0.5
-run 100
-run 100 :pre
-
-does something different than this sequence:
-
-run 100
-timestep 0.5
-run 100 :pre
-
-In the first case, the specified timestep (0.5 fmsec) is used for two
-simulations of 100 timesteps each. In the 2nd case, the default
-timestep (1.0 fmsec) is used for the 1st 100 step simulation and a 0.5
-fmsec timestep is used for the 2nd one.
-
-(2) Some commands are only valid when they follow other commands. For
-example you cannot set the temperature of a group of atoms until atoms
-have been defined and a group command is used to define which atoms
-belong to the group.
-
-(3) Sometimes command B will use values that can be set by command A.
-This means command A must precede command B in the input script if it
-is to have the desired effect. For example, the
-"read_data"_read_data.html command initializes the system by setting
-up the simulation box and assigning atoms to processors. If default
-values are not desired, the "processors"_processors.html and
-"boundary"_boundary.html commands need to be used before read_data to
-tell LAMMPS how to map processors to the simulation box.
-
-Many input script errors are detected by LAMMPS and an ERROR or
-WARNING message is printed. "This section"_Section_errors.html gives
-more information on what errors mean. The documentation for each
-command lists restrictions on how the command can be used.
-
-:line
-
-3.2 Parsing rules :link(cmd_2),h4
-
-Each non-blank line in the input script is treated as a command.
-LAMMPS commands are case sensitive. Command names are lower-case, as
-are specified command arguments. Upper case letters may be used in
-file names or user-chosen ID strings.
-
-Here is how each line in the input script is parsed by LAMMPS:
-
-(1) If the last printable character on the line is a "&" character,
-the command is assumed to continue on the next line. The next line is
-concatenated to the previous line by removing the "&" character and
-line break. This allows long commands to be continued across two or
-more lines. See the discussion of triple quotes in (6) for how to
-continue a command across multiple line without using "&" characters.
-
-(2) All characters from the first "#" character onward are treated as
-comment and discarded. See an exception in (6). Note that a
-comment after a trailing "&" character will prevent the command from
-continuing on the next line. Also note that for multi-line commands a
-single leading "#" will comment out the entire command.
-
-(3) The line is searched repeatedly for $ characters, which indicate
-variables that are replaced with a text string. See an exception in
-(6).
-
-If the $ is followed by curly brackets, then the variable name is the
-text inside the curly brackets. If no curly brackets follow the $,
-then the variable name is the single character immediately following
-the $. Thus $\{myTemp\} and $x refer to variable names "myTemp" and
-"x".
-
-How the variable is converted to a text string depends on what style
-of variable it is; see the "variable"_variable.html doc page for details.
-It can be a variable that stores multiple text strings, and return one
-of them. The returned text string can be multiple "words" (space
-separated) which will then be interpreted as multiple arguments in the
-input command. The variable can also store a numeric formula which
-will be evaluated and its numeric result returned as a string.
-
-As a special case, if the $ is followed by parenthesis, then the text
-inside the parenthesis is treated as an "immediate" variable and
-evaluated as an "equal-style variable"_variable.html. This is a way
-to use numeric formulas in an input script without having to assign
-them to variable names. For example, these 3 input script lines:
-
-variable X equal (xlo+xhi)/2+sqrt(v_area)
-region 1 block $X 2 INF INF EDGE EDGE
-variable X delete :pre
-
-can be replaced by
-
-region 1 block $((xlo+xhi)/2+sqrt(v_area)) 2 INF INF EDGE EDGE :pre
-
-so that you do not have to define (or discard) a temporary variable X.
-
-Additionally, the "immediate" variable expression may be followed by a
-colon, followed by a C-style format string, e.g. ":%f" or ":%.10g".
-The format string must be appropriate for a double-precision
-floating-point value. The format string is used to output the result
-of the variable expression evaluation. If a format string is not
-specified a high-precision "%.20g" is used as the default.
-
-This can be useful for formatting print output to a desired precion:
-
-print "Final energy per atom: $(pe/atoms:%10.3f) eV/atom" :pre
-
-Note that neither the curly-bracket or immediate form of variables can
-contain nested $ characters for other variables to substitute for.
-Thus you cannot do this:
-
-variable a equal 2
-variable b2 equal 4
-print "B2 = $\{b$a\}" :pre
-
-Nor can you specify this $($x-1.0) for an immediate variable, but
-you could use $(v_x-1.0), since the latter is valid syntax for an
-"equal-style variable"_variable.html.
-
-See the "variable"_variable.html command for more details of how
-strings are assigned to variables and evaluated, and how they can be
-used in input script commands.
-
-(4) The line is broken into "words" separated by whitespace (tabs,
-spaces). Note that words can thus contain letters, digits,
-underscores, or punctuation characters.
-
-(5) The first word is the command name. All successive words in the
-line are arguments.
-
-(6) If you want text with spaces to be treated as a single argument,
-it can be enclosed in either single or double or triple quotes. A
-long single argument enclosed in single or double quotes can span
-multiple lines if the "&" character is used, as described above. When
-the lines are concatenated together (and the "&" characters and line
-breaks removed), the text will become a single line. If you want
-multiple lines of an argument to retain their line breaks, the text
-can be enclosed in triple quotes, in which case "&" characters are not
-needed. For example:
-
-print "Volume = $v"
-print 'Volume = $v'
-if "$\{steps\} > 1000" then quit
-variable a string "red green blue &
- purple orange cyan"
-print """
-System volume = $v
-System temperature = $t
-""" :pre
-
-In each case, the single, double, or triple quotes are removed when
-the single argument they enclose is stored internally.
-
-See the "dump modify format"_dump_modify.html, "print"_print.html,
-"if"_if.html, and "python"_python.html commands for examples.
-
-A "#" or "$" character that is between quotes will not be treated as a
-comment indicator in (2) or substituted for as a variable in (3).
-
-NOTE: If the argument is itself a command that requires a quoted
-argument (e.g. using a "print"_print.html command as part of an
-"if"_if.html or "run every"_run.html command), then single, double, or
-triple quotes can be nested in the usual manner. See the doc pages
-for those commands for examples. Only one of level of nesting is
-allowed, but that should be sufficient for most use cases.
-
-:line
-
-3.3 Input script structure :h3,link(cmd_3)
-
-This section describes the structure of a typical LAMMPS input script.
-The "examples" directory in the LAMMPS distribution contains many
-sample input scripts; the corresponding problems are discussed in
-"Section 7"_Section_example.html, and animated on the "LAMMPS
-WWW Site"_lws.
-
-A LAMMPS input script typically has 4 parts:
-
-Initialization
-Atom definition
-Settings
-Run a simulation :ol
-
-The last 2 parts can be repeated as many times as desired. I.e. run a
-simulation, change some settings, run some more, etc. Each of the 4
-parts is now described in more detail. Remember that almost all the
-commands need only be used if a non-default value is desired.
-
-(1) Initialization
-
-Set parameters that need to be defined before atoms are created or
-read-in from a file.
-
-The relevant commands are "units"_units.html,
-"dimension"_dimension.html, "newton"_newton.html,
-"processors"_processors.html, "boundary"_boundary.html,
-"atom_style"_atom_style.html, "atom_modify"_atom_modify.html.
-
-If force-field parameters appear in the files that will be read, these
-commands tell LAMMPS what kinds of force fields are being used:
-"pair_style"_pair_style.html, "bond_style"_bond_style.html,
-"angle_style"_angle_style.html, "dihedral_style"_dihedral_style.html,
-"improper_style"_improper_style.html.
-
-(2) Atom definition
-
-There are 3 ways to define atoms in LAMMPS. Read them in from a data
-or restart file via the "read_data"_read_data.html or
-"read_restart"_read_restart.html commands. These files can contain
-molecular topology information. Or create atoms on a lattice (with no
-molecular topology), using these commands: "lattice"_lattice.html,
-"region"_region.html, "create_box"_create_box.html,
-"create_atoms"_create_atoms.html. The entire set of atoms can be
-duplicated to make a larger simulation using the
-"replicate"_replicate.html command.
-
-(3) Settings
-
-Once atoms and molecular topology are defined, a variety of settings
-can be specified: force field coefficients, simulation parameters,
-output options, etc.
-
-Force field coefficients are set by these commands (they can also be
-set in the read-in files): "pair_coeff"_pair_coeff.html,
-"bond_coeff"_bond_coeff.html, "angle_coeff"_angle_coeff.html,
-"dihedral_coeff"_dihedral_coeff.html,
-"improper_coeff"_improper_coeff.html,
-"kspace_style"_kspace_style.html, "dielectric"_dielectric.html,
-"special_bonds"_special_bonds.html.
-
-Various simulation parameters are set by these commands:
-"neighbor"_neighbor.html, "neigh_modify"_neigh_modify.html,
-"group"_group.html, "timestep"_timestep.html,
-"reset_timestep"_reset_timestep.html, "run_style"_run_style.html,
-"min_style"_min_style.html, "min_modify"_min_modify.html.
-
-Fixes impose a variety of boundary conditions, time integration, and
-diagnostic options. The "fix"_fix.html command comes in many flavors.
-
-Various computations can be specified for execution during a
-simulation using the "compute"_compute.html,
-"compute_modify"_compute_modify.html, and "variable"_variable.html
-commands.
-
-Output options are set by the "thermo"_thermo.html, "dump"_dump.html,
-and "restart"_restart.html commands.
-
-(4) Run a simulation
-
-A molecular dynamics simulation is run using the "run"_run.html
-command. Energy minimization (molecular statics) is performed using
-the "minimize"_minimize.html command. A parallel tempering
-(replica-exchange) simulation can be run using the
-"temper"_temper.html command.
-
-:line
-
-3.4 Commands listed by category :link(cmd_4),h4
-
-This section lists core LAMMPS commands, grouped by category.
-The "next section"_#cmd_5 lists all commands alphabetically. The
-next section also includes (long) lists of style options for entries
-that appear in the following categories as a single command (fix,
-compute, pair, etc). Commands that are added by user packages are not
-included in the categories here, but they are in the next section.
-
-Initialization:
-
-"newton"_newton.html,
-"package"_package.html,
-"processors"_processors.html,
-"suffix"_suffix.html,
-"units"_units.html
-
-Setup simulation box:
-
-"boundary"_boundary.html,
-"box"_box.html,
-"change_box"_change_box.html,
-"create_box"_create_box.html,
-"dimension"_dimension.html,
-"lattice"_lattice.html,
-"region"_region.html
-
-Setup atoms:
-
-"atom_modify"_atom_modify.html,
-"atom_style"_atom_style.html,
-"balance"_balance.html,
-"create_atoms"_create_atoms.html,
-"create_bonds"_create_bonds.html,
-"delete_atoms"_delete_atoms.html,
-"delete_bonds"_delete_bonds.html,
-"displace_atoms"_displace_atoms.html,
-"group"_group.html,
-"mass"_mass.html,
-"molecule"_molecule.html,
-"read_data"_read_data.html,
-"read_dump"_read_dump.html,
-"read_restart"_read_restart.html,
-"replicate"_replicate.html,
-"set"_set.html,
-"velocity"_velocity.html
-
-Force fields:
-
-"angle_coeff"_angle_coeff.html,
-"angle_style"_angle_style.html,
-"bond_coeff"_bond_coeff.html,
-"bond_style"_bond_style.html,
-"bond_write"_bond_write.html,
-"dielectric"_dielectric.html,
-"dihedral_coeff"_dihedral_coeff.html,
-"dihedral_style"_dihedral_style.html,
-"improper_coeff"_improper_coeff.html,
-"improper_style"_improper_style.html,
-"kspace_modify"_kspace_modify.html,
-"kspace_style"_kspace_style.html,
-"pair_coeff"_pair_coeff.html,
-"pair_modify"_pair_modify.html,
-"pair_style"_pair_style.html,
-"pair_write"_pair_write.html,
-"special_bonds"_special_bonds.html
-
-Settings:
-
-"comm_modify"_comm_modify.html,
-"comm_style"_comm_style.html,
-"info"_info.html,
-"min_modify"_min_modify.html,
-"min_style"_min_style.html,
-"neigh_modify"_neigh_modify.html,
-"neighbor"_neighbor.html,
-"partition"_partition.html,
-"reset_timestep"_reset_timestep.html,
-"run_style"_run_style.html,
-"timer"_timer.html,
-"timestep"_timestep.html
-
-Operations within timestepping (fixes) and diagnostics (computes):
-
-"compute"_compute.html,
-"compute_modify"_compute_modify.html,
-"fix"_fix.html,
-"fix_modify"_fix_modify.html,
-"uncompute"_uncompute.html,
-"unfix"_unfix.html
-
-Output:
-
-"dump image"_dump_image.html,
-"dump movie"_dump_image.html,
-"dump"_dump.html,
-"dump_modify"_dump_modify.html,
-"restart"_restart.html,
-"thermo"_thermo.html,
-"thermo_modify"_thermo_modify.html,
-"thermo_style"_thermo_style.html,
-"undump"_undump.html,
-"write_coeff"_write_coeff.html,
-"write_data"_write_data.html,
-"write_dump"_write_dump.html,
-"write_restart"_write_restart.html
-
-Actions:
-
-"minimize"_minimize.html,
-"neb"_neb.html,
-"prd"_prd.html,
-"rerun"_rerun.html,
-"run"_run.html,
-"tad"_tad.html,
-"temper"_temper.html
-
-Input script control:
-
-"clear"_clear.html,
-"echo"_echo.html,
-"if"_if.html,
-"include"_include.html,
-"jump"_jump.html,
-"label"_label.html,
-"log"_log.html,
-"next"_next.html,
-"print"_print.html,
-"python"_python.html,
-"quit"_quit.html,
-"shell"_shell.html,
-"variable"_variable.html
-
-:line
-
-3.5 Individual commands :h3,link(cmd_5),link(comm)
-
-This section lists all LAMMPS commands alphabetically, with a separate
-listing below of styles within certain commands. The "previous
-section"_#cmd_4 lists the same commands, grouped by category. Note
-that some style options for some commands are part of specific LAMMPS
-packages, which means they cannot be used unless the package was
-included when LAMMPS was built. Not all packages are included in a
-default LAMMPS build. These dependencies are listed as Restrictions
-in the command's documentation.
-
-"angle_coeff"_angle_coeff.html,
-"angle_style"_angle_style.html,
-"atom_modify"_atom_modify.html,
-"atom_style"_atom_style.html,
-"balance"_balance.html,
-"bond_coeff"_bond_coeff.html,
-"bond_style"_bond_style.html,
-"bond_write"_bond_write.html,
-"boundary"_boundary.html,
-"box"_box.html,
-"change_box"_change_box.html,
-"clear"_clear.html,
-"comm_modify"_comm_modify.html,
-"comm_style"_comm_style.html,
-"compute"_compute.html,
-"compute_modify"_compute_modify.html,
-"create_atoms"_create_atoms.html,
-"create_bonds"_create_bonds.html,
-"create_box"_create_box.html,
-"delete_atoms"_delete_atoms.html,
-"delete_bonds"_delete_bonds.html,
-"dielectric"_dielectric.html,
-"dihedral_coeff"_dihedral_coeff.html,
-"dihedral_style"_dihedral_style.html,
-"dimension"_dimension.html,
-"displace_atoms"_displace_atoms.html,
-"dump"_dump.html,
-"dump image"_dump_image.html,
-"dump_modify"_dump_modify.html,
-"dump movie"_dump_image.html,
-"echo"_echo.html,
-"fix"_fix.html,
-"fix_modify"_fix_modify.html,
-"group"_group.html,
-"if"_if.html,
-"info"_info.html,
-"improper_coeff"_improper_coeff.html,
-"improper_style"_improper_style.html,
-"include"_include.html,
-"jump"_jump.html,
-"kspace_modify"_kspace_modify.html,
-"kspace_style"_kspace_style.html,
-"label"_label.html,
-"lattice"_lattice.html,
-"log"_log.html,
-"mass"_mass.html,
-"minimize"_minimize.html,
-"min_modify"_min_modify.html,
-"min_style"_min_style.html,
-"molecule"_molecule.html,
-"neb"_neb.html,
-"neigh_modify"_neigh_modify.html,
-"neighbor"_neighbor.html,
-"newton"_newton.html,
-"next"_next.html,
-"package"_package.html,
-"pair_coeff"_pair_coeff.html,
-"pair_modify"_pair_modify.html,
-"pair_style"_pair_style.html,
-"pair_write"_pair_write.html,
-"partition"_partition.html,
-"prd"_prd.html,
-"print"_print.html,
-"processors"_processors.html,
-"python"_python.html,
-"quit"_quit.html,
-"read_data"_read_data.html,
-"read_dump"_read_dump.html,
-"read_restart"_read_restart.html,
-"region"_region.html,
-"replicate"_replicate.html,
-"rerun"_rerun.html,
-"reset_ids"_reset_ids.html,
-"reset_timestep"_reset_timestep.html,
-"restart"_restart.html,
-"run"_run.html,
-"run_style"_run_style.html,
-"set"_set.html,
-"shell"_shell.html,
-"special_bonds"_special_bonds.html,
-"suffix"_suffix.html,
-"tad"_tad.html,
-"temper"_temper.html,
-"thermo"_thermo.html,
-"thermo_modify"_thermo_modify.html,
-"thermo_style"_thermo_style.html,
-"timer"_timer.html,
-"timestep"_timestep.html,
-"uncompute"_uncompute.html,
-"undump"_undump.html,
-"unfix"_unfix.html,
-"units"_units.html,
-"variable"_variable.html,
-"velocity"_velocity.html,
-"write_coeff"_write_coeff.html,
-"write_data"_write_data.html,
-"write_dump"_write_dump.html,
-"write_restart"_write_restart.html :tb(c=6,ea=c)
-
-These are additional commands in USER packages, which can be used if
-"LAMMPS is built with the appropriate
-package"_Section_start.html#start_3.
-
-"dump netcdf"_dump_netcdf.html,
-"dump netcdf/mpiio"_dump_netcdf.html,
-"dump vtk"_dump_vtk.html,
-"group2ndx"_group2ndx.html,
-"ndx2group"_group2ndx.html,
-"temper/grem"_temper_grem.html,
-"temper/npt"_temper_npt.html :tb(c=3,ea=c)
-
-:line
-
-Fix styles :h3
-
-See the "fix"_fix.html command for one-line descriptions of each style
-or click on the style itself for a full description. Some of the
-styles have accelerated versions, which can be used if LAMMPS is built
-with the "appropriate accelerated package"_Section_accelerate.html.
-This is indicated by additional letters in parenthesis: g = GPU, i =
-USER-INTEL, k = KOKKOS, o = USER-OMP, t = OPT.
-
-"adapt"_fix_adapt.html,
-"addforce"_fix_addforce.html,
-"append/atoms"_fix_append_atoms.html,
-"atom/swap"_fix_atom_swap.html,
-"aveforce"_fix_aveforce.html,
-"ave/atom"_fix_ave_atom.html,
-"ave/chunk"_fix_ave_chunk.html,
-"ave/correlate"_fix_ave_correlate.html,
-"ave/histo"_fix_ave_histo.html,
-"ave/histo/weight"_fix_ave_histo.html,
-"ave/time"_fix_ave_time.html,
-"balance"_fix_balance.html,
-"bond/break"_fix_bond_break.html,
-"bond/create"_fix_bond_create.html,
-"bond/swap"_fix_bond_swap.html,
-"box/relax"_fix_box_relax.html,
-"cmap"_fix_cmap.html,
-"controller"_fix_controller.html,
-"deform (k)"_fix_deform.html,
-"deposit"_fix_deposit.html,
-"drag"_fix_drag.html,
-"dt/reset"_fix_dt_reset.html,
-"efield"_fix_efield.html,
-"ehex"_fix_ehex.html,
-"enforce2d"_fix_enforce2d.html,
-"evaporate"_fix_evaporate.html,
-"external"_fix_external.html,
-"freeze"_fix_freeze.html,
-"gcmc"_fix_gcmc.html,
-"gld"_fix_gld.html,
-"gravity (o)"_fix_gravity.html,
-"halt"_fix_halt.html,
-"heat"_fix_heat.html,
-"indent"_fix_indent.html,
-"latte"_fix_latte.html,
-"langevin (k)"_fix_langevin.html,
-"langevin/spin"_fix_langevin_spin.hmtl,
-"lineforce"_fix_lineforce.html,
-"momentum (k)"_fix_momentum.html,
-"move"_fix_move.html,
-"mscg"_fix_mscg.html,
-"msst"_fix_msst.html,
-"neb"_fix_neb.html,
-"nph (ko)"_fix_nh.html,
-"nphug (o)"_fix_nphug.html,
-"nph/asphere (o)"_fix_nph_asphere.html,
-"nph/body"_fix_nph_body.html,
-"nph/sphere (o)"_fix_nph_sphere.html,
-"npt (kio)"_fix_nh.html,
-"npt/asphere (o)"_fix_npt_asphere.html,
-"npt/body"_fix_npt_body.html,
-"npt/sphere (o)"_fix_npt_sphere.html,
-"nve (kio)"_fix_nve.html,
-"nve/asphere (i)"_fix_nve_asphere.html,
-"nve/asphere/noforce"_fix_nve_asphere_noforce.html,
-"nve/body"_fix_nve_body.html,
-"nve/limit"_fix_nve_limit.html,
-"nve/line"_fix_nve_line.html,
-"nve/noforce"_fix_nve_noforce.html,
-"nve/sphere (o)"_fix_nve_sphere.html,
-"nve/spin"_fix_nve_spin.html,
-"nve/tri"_fix_nve_tri.html,
-"nvt (iko)"_fix_nh.html,
-"nvt/asphere (o)"_fix_nvt_asphere.html,
-"nvt/body"_fix_nvt_body.html,
-"nvt/sllod (io)"_fix_nvt_sllod.html,
-"nvt/sphere (o)"_fix_nvt_sphere.html,
-"oneway"_fix_oneway.html,
-"orient/bcc"_fix_orient.html,
-"orient/fcc"_fix_orient.html,
-"planeforce"_fix_planeforce.html,
-"poems"_fix_poems.html,
-"pour"_fix_pour.html,
-"precession/spin"_fix_precession_spin.html,
-"press/berendsen"_fix_press_berendsen.html,
-"print"_fix_print.html,
-"property/atom (k)"_fix_property_atom.html,
-"python/invoke"_fix_python_invoke.html,
-"python/move"_fix_python_move.html,
-"qeq/comb (o)"_fix_qeq_comb.html,
-"qeq/dynamic"_fix_qeq.html,
-"qeq/fire"_fix_qeq.html,
-"qeq/point"_fix_qeq.html,
-"qeq/shielded"_fix_qeq.html,
-"qeq/slater"_fix_qeq.html,
-"rattle"_fix_shake.html,
-"reax/bonds"_fix_reax_bonds.html,
-"recenter"_fix_recenter.html,
-"restrain"_fix_restrain.html,
-"rigid (o)"_fix_rigid.html,
-"rigid/nph (o)"_fix_rigid.html,
-"rigid/npt (o)"_fix_rigid.html,
-"rigid/nve (o)"_fix_rigid.html,
-"rigid/nvt (o)"_fix_rigid.html,
-"rigid/small (o)"_fix_rigid.html,
-"rigid/small/nph"_fix_rigid.html,
-"rigid/small/npt"_fix_rigid.html,
-"rigid/small/nve"_fix_rigid.html,
-"rigid/small/nvt"_fix_rigid.html,
-"setforce (k)"_fix_setforce.html,
-"shake"_fix_shake.html,
-"spring"_fix_spring.html,
-"spring/chunk"_fix_spring_chunk.html,
-"spring/rg"_fix_spring_rg.html,
-"spring/self"_fix_spring_self.html,
-"srd"_fix_srd.html,
-"store/force"_fix_store_force.html,
-"store/state"_fix_store_state.html,
-"temp/berendsen"_fix_temp_berendsen.html,
-"temp/csld"_fix_temp_csvr.html,
-"temp/csvr"_fix_temp_csvr.html,
-"temp/rescale"_fix_temp_rescale.html,
-"tfmc"_fix_tfmc.html,
-"thermal/conductivity"_fix_thermal_conductivity.html,
-"tmd"_fix_tmd.html,
-"ttm"_fix_ttm.html,
-"tune/kspace"_fix_tune_kspace.html,
-"vector"_fix_vector.html,
-"viscosity"_fix_viscosity.html,
-"viscous"_fix_viscous.html,
-"wall/colloid"_fix_wall.html,
-"wall/gran"_fix_wall_gran.html,
-"wall/gran/region"_fix_wall_gran_region.html,
-"wall/harmonic"_fix_wall.html,
-"wall/lj1043"_fix_wall.html,
-"wall/lj126"_fix_wall.html,
-"wall/lj93 (k)"_fix_wall.html,
-"wall/piston"_fix_wall_piston.html,
-"wall/reflect (k)"_fix_wall_reflect.html,
-"wall/region"_fix_wall_region.html,
-"wall/srd"_fix_wall_srd.html :tb(c=8,ea=c)
-
-These are additional fix styles in USER packages, which can be used if
-"LAMMPS is built with the appropriate
-package"_Section_start.html#start_3.
-
-"adapt/fep"_fix_adapt_fep.html,
-"addtorque"_fix_addtorque.html,
-"atc"_fix_atc.html,
-"ave/correlate/long"_fix_ave_correlate_long.html,
-"bond/react"_fix_bond_react.html,
-"colvars"_fix_colvars.html,
-"dpd/energy (k)"_fix_dpd_energy.html,
-"drude"_fix_drude.html,
-"drude/transform/direct"_fix_drude_transform.html,
-"drude/transform/reverse"_fix_drude_transform.html,
-"edpd/source"_fix_dpd_source.html,
-"eos/cv"_fix_eos_cv.html,
-"eos/table"_fix_eos_table.html,
-"eos/table/rx (k)"_fix_eos_table_rx.html,
-"filter/corotate"_fix_filter_corotate.html,
-"flow/gauss"_fix_flow_gauss.html,
-"gle"_fix_gle.html,
-"grem"_fix_grem.html,
-"imd"_fix_imd.html,
-"ipi"_fix_ipi.html,
-"langevin/drude"_fix_langevin_drude.html,
-"langevin/eff"_fix_langevin_eff.html,
-"lb/fluid"_fix_lb_fluid.html,
-"lb/momentum"_fix_lb_momentum.html,
-"lb/pc"_fix_lb_pc.html,
-"lb/rigid/pc/sphere"_fix_lb_rigid_pc_sphere.html,
-"lb/viscous"_fix_lb_viscous.html,
-"meso"_fix_meso.html,
-"manifoldforce"_fix_manifoldforce.html,
-"meso/stationary"_fix_meso_stationary.html,
-"mvv/dpd"_fix_mvv_dpd.html,
-"mvv/edpd"_fix_mvv_dpd.html,
-"mvv/tdpd"_fix_mvv_dpd.html,
-"nph/eff"_fix_nh_eff.html,
-"npt/eff"_fix_nh_eff.html,
-"npt/uef"_fix_nh_uef.html,
-"nve/dot"_fix_nve_dot.html,
-"nve/dotc/langevin"_fix_nve_dotc_langevin.html,
-"nve/eff"_fix_nve_eff.html,
-"nve/manifold/rattle"_fix_nve_manifold_rattle.html,
-"nvk"_fix_nvk.html,
-"nvt/eff"_fix_nh_eff.html,
-"nvt/manifold/rattle"_fix_nvt_manifold_rattle.html,
-"nvt/sllod/eff"_fix_nvt_sllod_eff.html,
-"nvt/uef"_fix_nh_uef.html,
-"phonon"_fix_phonon.html,
-"pimd"_fix_pimd.html,
-"qbmsst"_fix_qbmsst.html,
-"qeq/reax (ko)"_fix_qeq_reax.html,
-"qmmm"_fix_qmmm.html,
-"qtb"_fix_qtb.html,
-"reax/c/bonds (k)"_fix_reax_bonds.html,
-"reax/c/species (k)"_fix_reaxc_species.html,
-"rhok"_fix_rhok.html,
-"rx (k)"_fix_rx.html,
-"saed/vtk"_fix_saed_vtk.html,
-"shardlow (k)"_fix_shardlow.html,
-"smd"_fix_smd.html,
-"smd/adjust/dt"_fix_smd_adjust_dt.html,
-"smd/integrate/tlsph"_fix_smd_integrate_tlsph.html,
-"smd/integrate/ulsph"_fix_smd_integrate_ulsph.html,
-"smd/move/triangulated/surface"_fix_smd_move_triangulated_surface.html,
-"smd/setvel"_fix_smd_setvel.html,
-"smd/wall/surface"_fix_smd_wall_surface.html,
-"tdpd/source"_fix_dpd_source.html,
-"temp/rescale/eff"_fix_temp_rescale_eff.html,
-"ti/spring"_fix_ti_spring.html,
-"ttm/mod"_fix_ttm.html,
-"wall/ees"_fix_wall_ees.html,
-"wall/region/ees"_fix_wall_ees.html :tb(c=6,ea=c)
-
-:line
-
-Compute styles :h3
-
-See the "compute"_compute.html command for one-line descriptions of
-each style or click on the style itself for a full description. Some
-of the styles have accelerated versions, which can be used if LAMMPS
-is built with the "appropriate accelerated
-package"_Section_accelerate.html. This is indicated by additional
-letters in parenthesis: g = GPU, i = USER-INTEL, k =
-KOKKOS, o = USER-OMP, t = OPT.
-
-"aggregate/atom"_compute_cluster_atom.html,
-"angle"_compute_angle.html,
-"angle/local"_compute_angle_local.html,
-"angmom/chunk"_compute_angmom_chunk.html,
-"body/local"_compute_body_local.html,
-"bond"_compute_bond.html,
-"bond/local"_compute_bond_local.html,
-"centro/atom"_compute_centro_atom.html,
-"chunk/atom"_compute_chunk_atom.html,
-"cluster/atom"_compute_cluster_atom.html,
-"cna/atom"_compute_cna_atom.html,
-"com"_compute_com.html,
-"com/chunk"_compute_com_chunk.html,
-"contact/atom"_compute_contact_atom.html,
-"coord/atom"_compute_coord_atom.html,
-"damage/atom"_compute_damage_atom.html,
-"dihedral"_compute_dihedral.html,
-"dihedral/local"_compute_dihedral_local.html,
-"dilatation/atom"_compute_dilatation_atom.html,
-"dipole/chunk"_compute_dipole_chunk.html,
-"displace/atom"_compute_displace_atom.html,
-"erotate/asphere"_compute_erotate_asphere.html,
-"erotate/rigid"_compute_erotate_rigid.html,
-"erotate/sphere"_compute_erotate_sphere.html,
-"erotate/sphere/atom"_compute_erotate_sphere_atom.html,
-"event/displace"_compute_event_displace.html,
-"fragment/atom"_compute_cluster_atom.html,
-"global/atom"_compute_global_atom.html,
-"group/group"_compute_group_group.html,
-"gyration"_compute_gyration.html,
-"gyration/chunk"_compute_gyration_chunk.html,
-"heat/flux"_compute_heat_flux.html,
-"hexorder/atom"_compute_hexorder_atom.html,
-"improper"_compute_improper.html,
-"improper/local"_compute_improper_local.html,
-"inertia/chunk"_compute_inertia_chunk.html,
-"ke"_compute_ke.html,
-"ke/atom"_compute_ke_atom.html,
-"ke/rigid"_compute_ke_rigid.html,
-"msd"_compute_msd.html,
-"msd/chunk"_compute_msd_chunk.html,
-"msd/nongauss"_compute_msd_nongauss.html,
-"omega/chunk"_compute_omega_chunk.html,
-"orientorder/atom"_compute_orientorder_atom.html,
-"pair"_compute_pair.html,
-"pair/local"_compute_pair_local.html,
-"pe"_compute_pe.html,
-"pe/atom"_compute_pe_atom.html,
-"plasticity/atom"_compute_plasticity_atom.html,
-"pressure"_compute_pressure.html,
-"property/atom"_compute_property_atom.html,
-"property/local"_compute_property_local.html,
-"property/chunk"_compute_property_chunk.html,
-"rdf"_compute_rdf.html,
-"reduce"_compute_reduce.html,
-"reduce/region"_compute_reduce.html,
-"rigid/local"_compute_rigid_local.html,
-"slice"_compute_slice.html,
-"sna/atom"_compute_sna_atom.html,
-"snad/atom"_compute_sna_atom.html,
-"snav/atom"_compute_sna_atom.html,
-"spin"_compute_spin.html,
-"stress/atom"_compute_stress_atom.html,
-"temp (k)"_compute_temp.html,
-"temp/asphere"_compute_temp_asphere.html,
-"temp/body"_compute_temp_body.html,
-"temp/chunk"_compute_temp_chunk.html,
-"temp/com"_compute_temp_com.html,
-"temp/deform"_compute_temp_deform.html,
-"temp/partial"_compute_temp_partial.html,
-"temp/profile"_compute_temp_profile.html,
-"temp/ramp"_compute_temp_ramp.html,
-"temp/region"_compute_temp_region.html,
-"temp/sphere"_compute_temp_sphere.html,
-"ti"_compute_ti.html,
-"torque/chunk"_compute_torque_chunk.html,
-"vacf"_compute_vacf.html,
-"vcm/chunk"_compute_vcm_chunk.html,
-"voronoi/atom"_compute_voronoi_atom.html :tb(c=6,ea=c)
-
-These are additional compute styles in USER packages, which can be
-used if "LAMMPS is built with the appropriate
-package"_Section_start.html#start_3.
-
-"ackland/atom"_compute_ackland_atom.html,
-"basal/atom"_compute_basal_atom.html,
-"cnp/atom"_compute_cnp_atom.html,
-"dpd"_compute_dpd.html,
-"dpd/atom"_compute_dpd_atom.html,
-"edpd/temp/atom"_compute_edpd_temp_atom.html,
-"entropy/atom"_compute_entropy_atom.html,
-"fep"_compute_fep.html,
-"force/tally"_compute_tally.html,
-"heat/flux/tally"_compute_tally.html,
-"ke/eff"_compute_ke_eff.html,
-"ke/atom/eff"_compute_ke_atom_eff.html,
-"meso/e/atom"_compute_meso_e_atom.html,
-"meso/rho/atom"_compute_meso_rho_atom.html,
-"meso/t/atom"_compute_meso_t_atom.html,
-"pe/tally"_compute_tally.html,
-"pe/mol/tally"_compute_tally.html,
-"pressure/uef"_compute_pressure_uef.html,
-"saed"_compute_saed.html,
-"smd/contact/radius"_compute_smd_contact_radius.html,
-"smd/damage"_compute_smd_damage.html,
-"smd/hourglass/error"_compute_smd_hourglass_error.html,
-"smd/internal/energy"_compute_smd_internal_energy.html,
-"smd/plastic/strain"_compute_smd_plastic_strain.html,
-"smd/plastic/strain/rate"_compute_smd_plastic_strain_rate.html,
-"smd/rho"_compute_smd_rho.html,
-"smd/tlsph/defgrad"_compute_smd_tlsph_defgrad.html,
-"smd/tlsph/dt"_compute_smd_tlsph_dt.html,
-"smd/tlsph/num/neighs"_compute_smd_tlsph_num_neighs.html,
-"smd/tlsph/shape"_compute_smd_tlsph_shape.html,
-"smd/tlsph/strain"_compute_smd_tlsph_strain.html,
-"smd/tlsph/strain/rate"_compute_smd_tlsph_strain_rate.html,
-"smd/tlsph/stress"_compute_smd_tlsph_stress.html,
-"smd/triangle/mesh/vertices"_compute_smd_triangle_mesh_vertices.html,
-"smd/ulsph/num/neighs"_compute_smd_ulsph_num_neighs.html,
-"smd/ulsph/strain"_compute_smd_ulsph_strain.html,
-"smd/ulsph/strain/rate"_compute_smd_ulsph_strain_rate.html,
-"smd/ulsph/stress"_compute_smd_ulsph_stress.html,
-"smd/vol"_compute_smd_vol.html,
-"stress/tally"_compute_tally.html,
-"tdpd/cc/atom"_compute_tdpd_cc_atom.html,
-"temp/drude"_compute_temp_drude.html,
-"temp/eff"_compute_temp_eff.html,
-"temp/deform/eff"_compute_temp_deform_eff.html,
-"temp/region/eff"_compute_temp_region_eff.html,
-"temp/rotate"_compute_temp_rotate.html,
-"temp/uef"_compute_temp_uef.html,
-"xrd"_compute_xrd.html :tb(c=6,ea=c)
-
-:line
-
-Pair_style potentials :h3
-
-See the "pair_style"_pair_style.html command for an overview of pair
-potentials. Click on the style itself for a full description. Many
-of the styles have accelerated versions, which can be used if LAMMPS
-is built with the "appropriate accelerated
-package"_Section_accelerate.html. This is indicated by additional
-letters in parenthesis: g = GPU, i = USER-INTEL, k =
-KOKKOS, o = USER-OMP, t = OPT.
-
-"none"_pair_none.html,
-"zero"_pair_zero.html,
-"hybrid"_pair_hybrid.html,
-"hybrid/overlay (k)"_pair_hybrid.html,
-"adp (o)"_pair_adp.html,
-"airebo (oi)"_pair_airebo.html,
-"airebo/morse (oi)"_pair_airebo.html,
-"beck (go)"_pair_beck.html,
-"body"_pair_body.html,
-"bop"_pair_bop.html,
-"born (go)"_pair_born.html,
-"born/coul/dsf"_pair_born.html,
-"born/coul/dsf/cs"_pair_born.html,
-"born/coul/long (go)"_pair_born.html,
-"born/coul/long/cs"_pair_born.html,
-"born/coul/msm (o)"_pair_born.html,
-"born/coul/wolf (go)"_pair_born.html,
-"born/coul/wolf/cs"_pair_born.html,
-"brownian (o)"_pair_brownian.html,
-"brownian/poly (o)"_pair_brownian.html,
-"buck (giko)"_pair_buck.html,
-"buck/coul/cut (giko)"_pair_buck.html,
-"buck/coul/long (giko)"_pair_buck.html,
-"buck/coul/long/cs"_pair_buck.html,
-"buck/coul/msm (o)"_pair_buck.html,
-"buck/long/coul/long (o)"_pair_buck_long.html,
-"colloid (go)"_pair_colloid.html,
-"comb (o)"_pair_comb.html,
-"comb3"_pair_comb.html,
-"coul/cut (gko)"_pair_coul.html,
-"coul/debye (gko)"_pair_coul.html,
-"coul/dsf (gko)"_pair_coul.html,
-"coul/long (gko)"_pair_coul.html,
-"coul/long/cs"_pair_coul.html,
-"coul/msm"_pair_coul.html,
-"coul/streitz"_pair_coul.html,
-"coul/wolf (ko)"_pair_coul.html,
-"coul/wolf/cs"_pair_coul.html,
-"dpd (gio)"_pair_dpd.html,
-"dpd/tstat (go)"_pair_dpd.html,
-"dsmc"_pair_dsmc.html,
-"eam (gikot)"_pair_eam.html,
-"eam/alloy (gikot)"_pair_eam.html,
-"eam/fs (gikot)"_pair_eam.html,
-"eim (o)"_pair_eim.html,
-"gauss (go)"_pair_gauss.html,
-"gayberne (gio)"_pair_gayberne.html,
-"gran/hertz/history (o)"_pair_gran.html,
-"gran/hooke (o)"_pair_gran.html,
-"gran/hooke/history (o)"_pair_gran.html,
-"gw"_pair_gw.html,
-"gw/zbl"_pair_gw.html,
-"hbond/dreiding/lj (o)"_pair_hbond_dreiding.html,
-"hbond/dreiding/morse (o)"_pair_hbond_dreiding.html,
-"kim"_pair_kim.html,
-"lcbop"_pair_lcbop.html,
-"line/lj"_pair_line_lj.html,
-"lj/charmm/coul/charmm (iko)"_pair_charmm.html,
-"lj/charmm/coul/charmm/implicit (ko)"_pair_charmm.html,
-"lj/charmm/coul/long (giko)"_pair_charmm.html,
-"lj/charmm/coul/msm"_pair_charmm.html,
-"lj/charmmfsw/coul/charmmfsh"_pair_charmm.html,
-"lj/charmmfsw/coul/long"_pair_charmm.html,
-"lj/class2 (gko)"_pair_class2.html,
-"lj/class2/coul/cut (ko)"_pair_class2.html,
-"lj/class2/coul/long (gko)"_pair_class2.html,
-"lj/cubic (go)"_pair_lj_cubic.html,
-"lj/cut (gikot)"_pair_lj.html,
-"lj/cut/coul/cut (gko)"_pair_lj.html,
-"lj/cut/coul/debye (gko)"_pair_lj.html,
-"lj/cut/coul/dsf (gko)"_pair_lj.html,
-"lj/cut/coul/long (gikot)"_pair_lj.html,
-"lj/cut/coul/long/cs"_pair_lj.html,
-"lj/cut/coul/msm (go)"_pair_lj.html,
-"lj/cut/coul/wolf (o)"_pair_lj.html,
-"lj/cut/dipole/cut (go)"_pair_dipole.html,
-"lj/cut/dipole/long"_pair_dipole.html,
-"lj/cut/tip4p/cut (o)"_pair_lj.html,
-"lj/cut/tip4p/long (ot)"_pair_lj.html,
-"lj/expand (gko)"_pair_lj_expand.html,
-"lj/gromacs (gko)"_pair_gromacs.html,
-"lj/gromacs/coul/gromacs (ko)"_pair_gromacs.html,
-"lj/long/coul/long (io)"_pair_lj_long.html,
-"lj/long/dipole/long"_pair_dipole.html,
-"lj/long/tip4p/long"_pair_lj_long.html,
-"lj/smooth (o)"_pair_lj_smooth.html,
-"lj/smooth/linear (o)"_pair_lj_smooth_linear.html,
-"lj96/cut (go)"_pair_lj96.html,
-"lubricate (o)"_pair_lubricate.html,
-"lubricate/poly (o)"_pair_lubricate.html,
-"lubricateU"_pair_lubricateU.html,
-"lubricateU/poly"_pair_lubricateU.html,
-"meam"_pair_meam.html,
-"mie/cut (o)"_pair_mie.html,
-"morse (gkot)"_pair_morse.html,
-"nb3b/harmonic (o)"_pair_nb3b_harmonic.html,
-"nm/cut (o)"_pair_nm.html,
-"nm/cut/coul/cut (o)"_pair_nm.html,
-"nm/cut/coul/long (o)"_pair_nm.html,
-"peri/eps"_pair_peri.html,
-"peri/lps (o)"_pair_peri.html,
-"peri/pmb (o)"_pair_peri.html,
-"peri/ves"_pair_peri.html,
-"polymorphic"_pair_polymorphic.html,
-"python"_pair_python.html,
-"reax"_pair_reax.html,
-"rebo (oi)"_pair_airebo.html,
-"resquared (go)"_pair_resquared.html,
-"snap (k)"_pair_snap.html,
-"soft (go)"_pair_soft.html,
-"sw (giko)"_pair_sw.html,
-"spin/dmi"_pair_spin_dmi.html,
-"spin/exchange"_pair_spin_exchange.html,
-"spin/magelec"_pair_spin_magelec.html,
-"spin/neel"_pair_spin_neel.html,
-"table (gko)"_pair_table.html,
-"tersoff (giko)"_pair_tersoff.html,
-"tersoff/mod (gko)"_pair_tersoff_mod.html,
-"tersoff/mod/c (o)"_pair_tersoff_mod.html,
-"tersoff/zbl (gko)"_pair_tersoff_zbl.html,
-"tip4p/cut (o)"_pair_coul.html,
-"tip4p/long (o)"_pair_coul.html,
-"tri/lj"_pair_tri_lj.html,
-"ufm (got)"_pair_ufm.html,
-"vashishta (ko)"_pair_vashishta.html,
-"vashishta/table (o)"_pair_vashishta.html,
-"yukawa (gok)"_pair_yukawa.html,
-"yukawa/colloid (go)"_pair_yukawa_colloid.html,
-"zbl (gok)"_pair_zbl.html :tb(c=4,ea=c)
-
-These are additional pair styles in USER packages, which can be used
-if "LAMMPS is built with the appropriate
-package"_Section_start.html#start_3.
-
-"agni (o)"_pair_agni.html,
-"awpmd/cut"_pair_awpmd.html,
-"buck/mdf"_pair_mdf.html,
-"coul/cut/soft (o)"_pair_lj_soft.html,
-"coul/diel (o)"_pair_coul_diel.html,
-"coul/long/soft (o)"_pair_lj_soft.html,
-"coul/shield"_pair_coul_shield.html,
-"dpd/fdt"_pair_dpd_fdt.html,
-"dpd/fdt/energy (k)"_pair_dpd_fdt.html,
-"eam/cd (o)"_pair_eam.html,
-"edip (o)"_pair_edip.html,
-"edip/multi"_pair_edip.html,
-"edpd"_pair_meso.html,
-"eff/cut"_pair_eff.html,
-"exp6/rx (k)"_pair_exp6_rx.html,
-"extep"_pair_extep.html,
-"gauss/cut"_pair_gauss.html,
-"ilp/graphene/hbn"_pair_ilp_graphene_hbn.html,
-"kolmogorov/crespi/full"_pair_kolmogorov_crespi_full.html,
-"kolmogorov/crespi/z"_pair_kolmogorov_crespi_z.html,
-"lennard/mdf"_pair_mdf.html,
-"list"_pair_list.html,
-"lj/charmm/coul/long/soft (o)"_pair_charmm.html,
-"lj/cut/coul/cut/soft (o)"_pair_lj_soft.html,
-"lj/cut/coul/long/soft (o)"_pair_lj_soft.html,
-"lj/cut/dipole/sf (go)"_pair_dipole.html,
-"lj/cut/soft (o)"_pair_lj_soft.html,
-"lj/cut/thole/long (o)"_pair_thole.html,
-"lj/cut/tip4p/long/soft (o)"_pair_lj_soft.html,
-"lj/mdf"_pair_mdf.html,
-"lj/sdk (gko)"_pair_sdk.html,
-"lj/sdk/coul/long (go)"_pair_sdk.html,
-"lj/sdk/coul/msm (o)"_pair_sdk.html,
-"mdpd"_pair_meso.html,
-"mdpd/rhosum"_pair_meso.html,
-"meam/c"_pair_meam.html,
-"meam/spline (o)"_pair_meam_spline.html,
-"meam/sw/spline"_pair_meam_sw_spline.html,
-"mgpt"_pair_mgpt.html,
-"momb"_pair_momb.html,
-"morse/smooth/linear"_pair_morse.html,
-"morse/soft"_pair_morse.html,
-"multi/lucy"_pair_multi_lucy.html,
-"multi/lucy/rx (k)"_pair_multi_lucy_rx.html,
-"oxdna/coaxstk"_pair_oxdna.html,
-"oxdna/excv"_pair_oxdna.html,
-"oxdna/hbond"_pair_oxdna.html,
-"oxdna/stk"_pair_oxdna.html,
-"oxdna/xstk"_pair_oxdna.html,
-"oxdna2/coaxstk"_pair_oxdna2.html,
-"oxdna2/dh"_pair_oxdna2.html,
-"oxdna2/excv"_pair_oxdna2.html,
-"oxdna2/stk"_pair_oxdna2.html,
-"quip"_pair_quip.html,
-"reax/c (ko)"_pair_reaxc.html,
-"smd/hertz"_pair_smd_hertz.html,
-"smd/tlsph"_pair_smd_tlsph.html,
-"smd/triangulated/surface"_pair_smd_triangulated_surface.html,
-"smd/ulsph"_pair_smd_ulsph.html,
-"smtbq"_pair_smtbq.html,
-"snap (k)"_pair_snap.html,
-"sph/heatconduction"_pair_sph_heatconduction.html,
-"sph/idealgas"_pair_sph_idealgas.html,
-"sph/lj"_pair_sph_lj.html,
-"sph/rhosum"_pair_sph_rhosum.html,
-"sph/taitwater"_pair_sph_taitwater.html,
-"sph/taitwater/morris"_pair_sph_taitwater_morris.html,
-"srp"_pair_srp.html,
-"table/rx (k)"_pair_table_rx.html,
-"tdpd"_pair_meso.html,
-"tersoff/table (o)"_pair_tersoff.html,
-"thole"_pair_thole.html,
-"tip4p/long/soft (o)"_pair_lj_soft.html :tb(c=4,ea=c)
-
-:line
-
-Bond_style potentials :h3
-
-See the "bond_style"_bond_style.html command for an overview of bond
-potentials. Click on the style itself for a full description. Some
-of the styles have accelerated versions, which can be used if LAMMPS
-is built with the "appropriate accelerated
-package"_Section_accelerate.html. This is indicated by additional
-letters in parenthesis: g = GPU, i = USER-INTEL, k =
-KOKKOS, o = USER-OMP, t = OPT.
-
-"none"_bond_none.html,
-"zero"_bond_zero.html,
-"hybrid"_bond_hybrid.html,
-"class2 (ko)"_bond_class2.html,
-"fene (iko)"_bond_fene.html,
-"fene/expand (o)"_bond_fene_expand.html,
-"gromos (o)"_bond_gromos.html,
-"harmonic (ko)"_bond_harmonic.html,
-"morse (o)"_bond_morse.html,
-"nonlinear (o)"_bond_nonlinear.html,
-"quartic (o)"_bond_quartic.html,
-"table (o)"_bond_table.html :tb(c=4,ea=c)
-
-These are additional bond styles in USER packages, which can be used
-if "LAMMPS is built with the appropriate
-package"_Section_start.html#start_3.
-
-"harmonic/shift (o)"_bond_harmonic_shift.html,
-"harmonic/shift/cut (o)"_bond_harmonic_shift_cut.html,
-"oxdna/fene"_bond_oxdna.html,
-"oxdna2/fene"_bond_oxdna.html :tb(c=4,ea=c)
-
-:line
-
-Angle_style potentials :h3
-
-See the "angle_style"_angle_style.html command for an overview of
-angle potentials. Click on the style itself for a full description.
-Some of the styles have accelerated versions, which can be used if
-LAMMPS is built with the "appropriate accelerated
-package"_Section_accelerate.html. This is indicated by additional
-letters in parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o =
-USER-OMP, t = OPT.
-
-"none"_angle_none.html,
-"zero"_angle_zero.html,
-"hybrid"_angle_hybrid.html,
-"charmm (ko)"_angle_charmm.html,
-"class2 (ko)"_angle_class2.html,
-"cosine (o)"_angle_cosine.html,
-"cosine/delta (o)"_angle_cosine_delta.html,
-"cosine/periodic (o)"_angle_cosine_periodic.html,
-"cosine/squared (o)"_angle_cosine_squared.html,
-"harmonic (iko)"_angle_harmonic.html,
-"table (o)"_angle_table.html :tb(c=4,ea=c)
-
-These are additional angle styles in USER packages, which can be used
-if "LAMMPS is built with the appropriate
-package"_Section_start.html#start_3.
-
-"cosine/shift (o)"_angle_cosine_shift.html,
-"cosine/shift/exp (o)"_angle_cosine_shift_exp.html,
-"dipole (o)"_angle_dipole.html,
-"fourier (o)"_angle_fourier.html,
-"fourier/simple (o)"_angle_fourier_simple.html,
-"quartic (o)"_angle_quartic.html,
-"sdk"_angle_sdk.html :tb(c=4,ea=c)
-
-:line
-
-Dihedral_style potentials :h3
-
-See the "dihedral_style"_dihedral_style.html command for an overview
-of dihedral potentials. Click on the style itself for a full
-description. Some of the styles have accelerated versions, which can
-be used if LAMMPS is built with the "appropriate accelerated
-package"_Section_accelerate.html. This is indicated by additional
-letters in parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o =
-USER-OMP, t = OPT.
-
-"none"_dihedral_none.html,
-"zero"_dihedral_zero.html,
-"hybrid"_dihedral_hybrid.html,
-"charmm (iko)"_dihedral_charmm.html,
-"charmmfsw"_dihedral_charmm.html,
-"class2 (ko)"_dihedral_class2.html,
-"harmonic (io)"_dihedral_harmonic.html,
-"helix (o)"_dihedral_helix.html,
-"multi/harmonic (o)"_dihedral_multi_harmonic.html,
-"opls (iko)"_dihedral_opls.html :tb(c=4,ea=c)
-
-These are additional dihedral styles in USER packages, which can be
-used if "LAMMPS is built with the appropriate
-package"_Section_start.html#start_3.
-
-"cosine/shift/exp (o)"_dihedral_cosine_shift_exp.html,
-"fourier (io)"_dihedral_fourier.html,
-"nharmonic (o)"_dihedral_nharmonic.html,
-"quadratic (o)"_dihedral_quadratic.html,
-"spherical (o)"_dihedral_spherical.html,
-"table (o)"_dihedral_table.html,
-"table/cut"_dihedral_table_cut.html :tb(c=4,ea=c)
-
-:line
-
-Improper_style potentials :h3
-
-See the "improper_style"_improper_style.html command for an overview
-of improper potentials. Click on the style itself for a full
-description. Some of the styles have accelerated versions, which can
-be used if LAMMPS is built with the "appropriate accelerated
-package"_Section_accelerate.html. This is indicated by additional
-letters in parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o =
-USER-OMP, t = OPT.
-
-"none"_improper_none.html,
-"zero"_improper_zero.html,
-"hybrid"_improper_hybrid.html,
-"class2 (ko)"_improper_class2.html,
-"cvff (io)"_improper_cvff.html,
-"harmonic (iko)"_improper_harmonic.html,
-"umbrella (o)"_improper_umbrella.html :tb(c=4,ea=c)
-
-These are additional improper styles in USER packages, which can be
-used if "LAMMPS is built with the appropriate
-package"_Section_start.html#start_3.
-
-"cossq (o)"_improper_cossq.html,
-"distance"_improper_distance.html,
-"fourier (o)"_improper_fourier.html,
-"ring (o)"_improper_ring.html :tb(c=4,ea=c)
-
-:line
-
-Kspace solvers :h3
-
-See the "kspace_style"_kspace_style.html command for an overview of
-Kspace solvers. Click on the style itself for a full description.
-Some of the styles have accelerated versions, which can be used if
-LAMMPS is built with the "appropriate accelerated
-package"_Section_accelerate.html. This is indicated by additional
-letters in parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o =
-USER-OMP, t = OPT.
-
-"ewald (o)"_kspace_style.html,
-"ewald/disp"_kspace_style.html,
-"msm (o)"_kspace_style.html,
-"msm/cg (o)"_kspace_style.html,
-"pppm (gok)"_kspace_style.html,
-"pppm/cg (o)"_kspace_style.html,
-"pppm/disp (i)"_kspace_style.html,
-"pppm/disp/tip4p"_kspace_style.html,
-"pppm/stagger"_kspace_style.html,
-"pppm/tip4p (o)"_kspace_style.html :tb(c=4,ea=c)
diff --git a/doc/src/Section_history.txt b/doc/src/Section_history.txt
deleted file mode 100644
index 7b9041062855136866e909b7c37a451c41460256..0000000000000000000000000000000000000000
--- a/doc/src/Section_history.txt
+++ /dev/null
@@ -1,135 +0,0 @@
-"Previous Section"_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,Section_commands.html#comm)
-
-:line
-
-13. Future and history :h2
-
-This section lists features we plan to add to LAMMPS, features of
-previous versions of LAMMPS, and features of other parallel molecular
-dynamics codes our group has distributed.
-
-13.1 "Coming attractions"_#hist_1
-13.2 "Past versions"_#hist_2 :all(b)
-
-:line
-:line
-
-13.1 Coming attractions :h3,link(hist_1)
-
-As of summer 2016 we are using the "LAMMPS project issue tracker
-on GitHub"_https://github.com/lammps/lammps/issues for keeping
-track of suggested, planned or pending new features. This includes
-discussions of how to best implement them, or why they would be
-useful. Especially if a planned or proposed feature is non-trivial
-to add, e.g. because it requires changes to some of the core
-classes of LAMMPS, people planning to contribute a new feature to
-LAMMS are encouraged to submit an issue about their planned
-implementation this way in order to receive feedback from the
-LAMMPS core developers. They will provide suggestions about
-the validity of the proposed approach and possible improvements,
-pitfalls or alternatives.
-
-Please see some of the closed issues for examples of how to
-suggest code enhancements, submit proposed changes, or report
-possible bugs and how they are resolved.
-
-As an alternative to using GitHub, you may e-mail the
-"core developers"_http://lammps.sandia.gov/authors.html or send
-an e-mail to the "LAMMPS Mail list"_http://lammps.sandia.gov/mail.html
-if you want to have your suggestion added to the list.
-
-:line
-
-13.2 Past versions :h3,link(hist_2)
-
-LAMMPS development began in the mid 1990s under a cooperative research
-& development agreement (CRADA) between two DOE labs (Sandia and LLNL)
-and 3 companies (Cray, Bristol Myers Squibb, and Dupont). The goal was
-to develop a large-scale parallel classical MD code; the coding effort
-was led by Steve Plimpton at Sandia.
-
-After the CRADA ended, a final F77 version, LAMMPS 99, was
-released. As development of LAMMPS continued at Sandia, its memory
-management was converted to F90; a final F90 version was released as
-LAMMPS 2001.
-
-The current LAMMPS is a rewrite in C++ and was first publicly released
-as an open source code in 2004. It includes many new features beyond
-those in LAMMPS 99 or 2001. It also includes features from older
-parallel MD codes written at Sandia, namely ParaDyn, Warp, and
-GranFlow (see below).
-
-In late 2006 we began merging new capabilities into LAMMPS that were
-developed by Aidan Thompson at Sandia for his MD code GRASP, which has
-a parallel framework similar to LAMMPS. Most notably, these have
-included many-body potentials - Stillinger-Weber, Tersoff, ReaxFF -
-and the associated charge-equilibration routines needed for ReaxFF.
-
-The "History link"_http://lammps.sandia.gov/history.html on the
-LAMMPS WWW page gives a timeline of features added to the
-C++ open-source version of LAMMPS over the last several years.
-
-These older codes are available for download from the "LAMMPS WWW
-site"_lws, except for Warp & GranFlow which were primarily used
-internally. A brief listing of their features is given here.
-
-LAMMPS 2001
-
- F90 + MPI
- dynamic memory
- spatial-decomposition parallelism
- NVE, NVT, NPT, NPH, rRESPA integrators
- LJ and Coulombic pairwise force fields
- all-atom, united-atom, bead-spring polymer force fields
- CHARMM-compatible force fields
- class 2 force fields
- 3d/2d Ewald & PPPM
- various force and temperature constraints
- SHAKE
- Hessian-free truncated-Newton minimizer
- user-defined diagnostics :ul
-
-LAMMPS 99
-
- F77 + MPI
- static memory allocation
- spatial-decomposition parallelism
- most of the LAMMPS 2001 features with a few exceptions
- no 2d Ewald & PPPM
- molecular force fields are missing a few CHARMM terms
- no SHAKE :ul
-
-Warp
-
- F90 + MPI
- spatial-decomposition parallelism
- embedded atom method (EAM) metal potentials + LJ
- lattice and grain-boundary atom creation
- NVE, NVT integrators
- boundary conditions for applying shear stresses
- temperature controls for actively sheared systems
- per-atom energy and centro-symmetry computation and output :ul
-
-ParaDyn
-
- F77 + MPI
- atom- and force-decomposition parallelism
- embedded atom method (EAM) metal potentials
- lattice atom creation
- NVE, NVT, NPT integrators
- all serial DYNAMO features for controls and constraints :ul
-
-GranFlow
-
- F90 + MPI
- spatial-decomposition parallelism
- frictional granular potentials
- NVE integrator
- boundary conditions for granular flow and packing and walls
- particle insertion :ul
diff --git a/doc/src/Section_howto.txt b/doc/src/Section_howto.txt
deleted file mode 100644
index 2784858f020dc3db8fccea6c4f04d4dc020b6080..0000000000000000000000000000000000000000
--- a/doc/src/Section_howto.txt
+++ /dev/null
@@ -1,3012 +0,0 @@
-"Previous Section"_Section_accelerate.html - "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Section_example.html :c
-
-:link(lws,http://lammps.sandia.gov)
-:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
-
-:line
-
-6. How-to discussions :h2
-
-This section describes how to perform common tasks using LAMMPS.
-
-6.1 "Restarting a simulation"_#howto_1
-6.2 "2d simulations"_#howto_2
-6.3 "CHARMM, AMBER, and DREIDING force fields"_#howto_3
-6.4 "Running multiple simulations from one input script"_#howto_4
-6.5 "Multi-replica simulations"_#howto_5
-6.6 "Granular models"_#howto_6
-6.7 "TIP3P water model"_#howto_7
-6.8 "TIP4P water model"_#howto_8
-6.9 "SPC water model"_#howto_9
-6.10 "Coupling LAMMPS to other codes"_#howto_10
-6.11 "Visualizing LAMMPS snapshots"_#howto_11
-6.12 "Triclinic (non-orthogonal) simulation boxes"_#howto_12
-6.13 "NEMD simulations"_#howto_13
-6.14 "Finite-size spherical and aspherical particles"_#howto_14
-6.15 "Output from LAMMPS (thermo, dumps, computes, fixes, variables)"_#howto_15
-6.16 "Thermostatting, barostatting and computing temperature"_#howto_16
-6.17 "Walls"_#howto_17
-6.18 "Elastic constants"_#howto_18
-6.19 "Library interface to LAMMPS"_#howto_19
-6.20 "Calculating thermal conductivity"_#howto_20
-6.21 "Calculating viscosity"_#howto_21
-6.22 "Calculating a diffusion coefficient"_#howto_22
-6.23 "Using chunks to calculate system properties"_#howto_23
-6.24 "Setting parameters for the kspace_style pppm/disp command"_#howto_24
-6.25 "Polarizable models"_#howto_25
-6.26 "Adiabatic core/shell model"_#howto_26
-6.27 "Drude induced dipoles"_#howto_27
-6.28 "Magnetic spins"_#howto_28 :all(b)
-
-The example input scripts included in the LAMMPS distribution and
-highlighted in "Section 7"_Section_example.html also show how to
-setup and run various kinds of simulations.
-
-:line
-:line
-
-6.1 Restarting a simulation :link(howto_1),h4
-
-There are 3 ways to continue a long LAMMPS simulation. Multiple
-"run"_run.html commands can be used in the same input script. Each
-run will continue from where the previous run left off. Or binary
-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
-"read_data"_read_data.html 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
-continue where the previous run left off. They illustrate what
-settings must be made in the new script. Details are discussed in the
-documentation for the "read_restart"_read_restart.html and
-"read_data"_read_data.html commands.
-
-Look at the {in.chain} input script provided in the {bench} directory
-of the LAMMPS distribution to see the original script that these 2
-scripts are based on. If that script had the line
-
-restart 50 tmp.restart :pre
-
-added to it, it would produce 2 binary restart files (tmp.restart.50
-and tmp.restart.100) as it ran.
-
-This script could be used to read the 1st restart file and re-run the
-last 50 timesteps:
-
-read_restart tmp.restart.50 :pre
-
-neighbor 0.4 bin
-neigh_modify every 1 delay 1 :pre
-
-fix 1 all nve
-fix 2 all langevin 1.0 1.0 10.0 904297 :pre
-
-timestep 0.012 :pre
-
-run 50 :pre
-
-Note that the following commands do not need to be repeated because
-their settings are included in the restart file: {units, atom_style,
-special_bonds, pair_style, bond_style}. However these commands do
-need to be used, since their settings are not in the restart file:
-{neighbor, fix, timestep}.
-
-If you actually use this script to perform a restarted run, you will
-notice that the thermodynamic data match at step 50 (if you also put a
-"thermo 50" command in the original script), but do not match at step
-100. This is because the "fix langevin"_fix_langevin.html command
-uses random numbers in a way that does not allow for perfect restarts.
-
-As an alternate approach, the restart file could be converted to a data
-file as follows:
-
-lmp_g++ -r tmp.restart.50 tmp.restart.data :pre
-
-Then, this script could be used to re-run the last 50 steps:
-
-units lj
-atom_style bond
-pair_style lj/cut 1.12
-pair_modify shift yes
-bond_style fene
-special_bonds 0.0 1.0 1.0 :pre
-
-read_data tmp.restart.data :pre
-
-neighbor 0.4 bin
-neigh_modify every 1 delay 1 :pre
-
-fix 1 all nve
-fix 2 all langevin 1.0 1.0 10.0 904297 :pre
-
-timestep 0.012 :pre
-
-reset_timestep 50
-run 50 :pre
-
-Note that nearly all the settings specified in the original {in.chain}
-script must be repeated, except the {pair_coeff} and {bond_coeff}
-commands since the new data file lists the force field coefficients.
-Also, the "reset_timestep"_reset_timestep.html command is used to tell
-LAMMPS the current timestep. This value is stored in restart files,
-but not in data files.
-
-:line
-
-6.2 2d simulations :link(howto_2),h4
-
-Use the "dimension"_dimension.html command to specify a 2d simulation.
-
-Make the simulation box periodic in z via the "boundary"_boundary.html
-command. This is the default.
-
-If using the "create box"_create_box.html command to define a
-simulation box, set the z dimensions narrow, but finite, so that the
-create_atoms command will tile the 3d simulation box with a single z
-plane of atoms - e.g.
-
-"create box"_create_box.html 1 -10 10 -10 10 -0.25 0.25 :pre
-
-If using the "read data"_read_data.html command to read in a file of
-atom coordinates, set the "zlo zhi" values to be finite but narrow,
-similar to the create_box command settings just described. For each
-atom in the file, assign a z coordinate so it falls inside the
-z-boundaries of the box - e.g. 0.0.
-
-Use the "fix enforce2d"_fix_enforce2d.html command as the last
-defined fix to insure that the z-components of velocities and forces
-are zeroed out every timestep. The reason to make it the last fix is
-so that any forces induced by other fixes will be zeroed out.
-
-Many of the example input scripts included in the LAMMPS distribution
-are for 2d models.
-
-NOTE: Some models in LAMMPS treat particles as finite-size spheres, as
-opposed to point particles. See the "atom_style
-sphere"_atom_style.html and "fix nve/sphere"_fix_nve_sphere.html
-commands for details. By default, for 2d simulations, such particles
-will still be modeled as 3d spheres, not 2d discs (circles), meaning
-their moment of inertia will be that of a sphere. If you wish to
-model them as 2d discs, see the "set density/disc"_set.html command
-and the {disc} option for the "fix nve/sphere"_fix_nve_sphere.html,
-"fix nvt/sphere"_fix_nvt_sphere.html, "fix
-nph/sphere"_fix_nph_sphere.html, "fix npt/sphere"_fix_npt_sphere.html
-commands.
-
-:line
-
-6.3 CHARMM, AMBER, and DREIDING force fields :link(howto_3),h4
-
-A force field has 2 parts: the formulas that define it and the
-coefficients used for a particular system. Here we only discuss
-formulas implemented in LAMMPS that correspond to formulas commonly
-used in the CHARMM, AMBER, and DREIDING force fields. Setting
-coefficients is done in the input data file via the
-"read_data"_read_data.html command or in the input script with
-commands like "pair_coeff"_pair_coeff.html or
-"bond_coeff"_bond_coeff.html. See "Section 9"_Section_tools.html
-for additional tools that can use CHARMM or AMBER to assign force
-field coefficients and convert their output into LAMMPS input.
-
-See "(MacKerell)"_#howto-MacKerell for a description of the CHARMM force
-field. See "(Cornell)"_#howto-Cornell for a description of the AMBER force
-field.
-
-:link(charmm,http://www.scripps.edu/brooks)
-:link(amber,http://amber.scripps.edu)
-
-These style choices compute force field formulas that are consistent
-with common options in CHARMM or AMBER. See each command's
-documentation for the formula it computes.
-
-"bond_style"_bond_harmonic.html harmonic
-"angle_style"_angle_charmm.html charmm
-"dihedral_style"_dihedral_charmm.html charmmfsh
-"dihedral_style"_dihedral_charmm.html charmm
-"pair_style"_pair_charmm.html lj/charmmfsw/coul/charmmfsh
-"pair_style"_pair_charmm.html lj/charmmfsw/coul/long
-"pair_style"_pair_charmm.html lj/charmm/coul/charmm
-"pair_style"_pair_charmm.html lj/charmm/coul/charmm/implicit
-"pair_style"_pair_charmm.html lj/charmm/coul/long :ul
-
-"special_bonds"_special_bonds.html charmm
-"special_bonds"_special_bonds.html amber :ul
-
-NOTE: For CHARMM, newer {charmmfsw} or {charmmfsh} styles were
-released in March 2017. We recommend they be used instead of the
-older {charmm} styles. See discussion of the differences on the "pair
-charmm"_pair_charmm.html and "dihedral charmm"_dihedral_charmm.html
-doc pages.
-
-DREIDING is a generic force field developed by the "Goddard
-group"_http://www.wag.caltech.edu at Caltech and is useful for
-predicting structures and dynamics of organic, biological and
-main-group inorganic molecules. The philosophy in DREIDING is to use
-general force constants and geometry parameters based on simple
-hybridization considerations, rather than individual force constants
-and geometric parameters that depend on the particular combinations of
-atoms involved in the bond, angle, or torsion terms. DREIDING has an
-"explicit hydrogen bond term"_pair_hbond_dreiding.html to describe
-interactions involving a hydrogen atom on very electronegative atoms
-(N, O, F).
-
-See "(Mayo)"_#howto-Mayo for a description of the DREIDING force field
-
-These style choices compute force field formulas that are consistent
-with the DREIDING force field. See each command's
-documentation for the formula it computes.
-
-"bond_style"_bond_harmonic.html harmonic
-"bond_style"_bond_morse.html morse :ul
-
-"angle_style"_angle_harmonic.html harmonic
-"angle_style"_angle_cosine.html cosine
-"angle_style"_angle_cosine_periodic.html cosine/periodic :ul
-
-"dihedral_style"_dihedral_charmm.html charmm
-"improper_style"_improper_umbrella.html umbrella :ul
-
-"pair_style"_pair_buck.html buck
-"pair_style"_pair_buck.html buck/coul/cut
-"pair_style"_pair_buck.html buck/coul/long
-"pair_style"_pair_lj.html lj/cut
-"pair_style"_pair_lj.html lj/cut/coul/cut
-"pair_style"_pair_lj.html lj/cut/coul/long :ul
-
-"pair_style"_pair_hbond_dreiding.html hbond/dreiding/lj
-"pair_style"_pair_hbond_dreiding.html hbond/dreiding/morse :ul
-
-"special_bonds"_special_bonds.html dreiding :ul
-
-:line
-
-6.4 Running multiple simulations from one input script :link(howto_4),h4
-
-This can be done in several ways. See the documentation for
-individual commands for more details on how these examples work.
-
-If "multiple simulations" means continue a previous simulation for
-more timesteps, then you simply use the "run"_run.html command
-multiple times. For example, this script
-
-units lj
-atom_style atomic
-read_data data.lj
-run 10000
-run 10000
-run 10000
-run 10000
-run 10000 :pre
-
-would run 5 successive simulations of the same system for a total of
-50,000 timesteps.
-
-If you wish to run totally different simulations, one after the other,
-the "clear"_clear.html command can be used in between them to
-re-initialize LAMMPS. For example, this script
-
-units lj
-atom_style atomic
-read_data data.lj
-run 10000
-clear
-units lj
-atom_style atomic
-read_data data.lj.new
-run 10000 :pre
-
-would run 2 independent simulations, one after the other.
-
-For large numbers of independent simulations, you can use
-"variables"_variable.html and the "next"_next.html and
-"jump"_jump.html commands to loop over the same input script
-multiple times with different settings. For example, this
-script, named in.polymer
-
-variable d index run1 run2 run3 run4 run5 run6 run7 run8
-shell cd $d
-read_data data.polymer
-run 10000
-shell cd ..
-clear
-next d
-jump in.polymer :pre
-
-would run 8 simulations in different directories, using a data.polymer
-file in each directory. The same concept could be used to run the
-same system at 8 different temperatures, using a temperature variable
-and storing the output in different log and dump files, for example
-
-variable a loop 8
-variable t index 0.8 0.85 0.9 0.95 1.0 1.05 1.1 1.15
-log log.$a
-read data.polymer
-velocity all create $t 352839
-fix 1 all nvt $t $t 100.0
-dump 1 all atom 1000 dump.$a
-run 100000
-clear
-next t
-next a
-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
-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
-replaced with {universe}-style variables, as described in the
-"variable"_variable.html command. Also, the "next t" and "next a"
-commands would need to be replaced with a single "next a t" command.
-With these modifications, the 8 simulations of each script would run
-on the 3 partitions one after the other until all were finished.
-Initially, 3 simulations would be started simultaneously, one on each
-partition. When one finished, that partition would then start
-the 4th simulation, and so forth, until all 8 were completed.
-
-:line
-
-6.5 Multi-replica simulations :link(howto_5),h4
-
-Several commands in LAMMPS run mutli-replica simulations, meaning
-that multiple instances (replicas) of your simulation are run
-simultaneously, with small amounts of data exchanged between replicas
-periodically.
-
-These are the relevant commands:
-
-"neb"_neb.html for nudged elastic band calculations
-"prd"_prd.html for parallel replica dynamics
-"tad"_tad.html for temperature accelerated dynamics
-"temper"_temper.html for parallel tempering
-"fix pimd"_fix_pimd.html for path-integral molecular dynamics (PIMD) :ul
-
-NEB is a method for finding transition states and barrier energies.
-PRD and TAD are methods for performing accelerated dynamics to find
-and perform infrequent events. Parallel tempering or replica exchange
-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
-for more info on packages.
-
-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
-for more info on packages.
-
-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
-partitions, which in this context are the same as replicas. E.g.
-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
-the input 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
-processors. Thus the above commands could be run on a
-single-processor (or few-processor) desktop so that you can run
-a multi-replica simulation on more replicas than you have
-physical processors.
-
-:line
-
-6.6 Granular models :link(howto_6),h4
-
-Granular system are composed of spherical particles with a diameter,
-as opposed to point particles. This means they have an angular
-velocity and torque can be imparted to them to cause them to rotate.
-
-To run a simulation of a granular model, you will want to use
-the following commands:
-
-"atom_style sphere"_atom_style.html
-"fix nve/sphere"_fix_nve_sphere.html
-"fix gravity"_fix_gravity.html :ul
-
-This compute
-
-"compute erotate/sphere"_compute_erotate_sphere.html :ul
-
-calculates rotational kinetic energy which can be "output with
-thermodynamic info"_Section_howto.html#howto_15.
-
-Use one of these 3 pair potentials, which compute forces and torques
-between interacting pairs of particles:
-
-"pair_style"_pair_style.html gran/history
-"pair_style"_pair_style.html gran/no_history
-"pair_style"_pair_style.html gran/hertzian :ul
-
-These commands implement fix options specific to granular systems:
-
-"fix freeze"_fix_freeze.html
-"fix pour"_fix_pour.html
-"fix viscous"_fix_viscous.html
-"fix wall/gran"_fix_wall_gran.html :ul
-
-The fix style {freeze} zeroes both the force and torque of frozen
-atoms, and should be used for granular system instead of the fix style
-{setforce}.
-
-For computational efficiency, you can eliminate needless pairwise
-computations between frozen atoms by using this command:
-
-"neigh_modify"_neigh_modify.html exclude :ul
-
-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 in "Section
-6.2"_Section_howto.html#howto_2, where 2d simulations are discussed.
-
-:line
-
-6.7 TIP3P water model :link(howto_7),h4
-
-The TIP3P water model as implemented in CHARMM
-"(MacKerell)"_#howto-MacKerell specifies a 3-site rigid water molecule with
-charges and Lennard-Jones parameters assigned to each of the 3 atoms.
-In LAMMPS the "fix shake"_fix_shake.html command can be used to hold
-the two O-H bonds and the H-O-H angle rigid. A bond style of
-{harmonic} and an angle style of {harmonic} or {charmm} should also be
-used.
-
-These are the additional parameters (in real units) to set for O and H
-atoms and the water molecule to run a rigid TIP3P-CHARMM model with a
-cutoff. The K values can be used if a flexible TIP3P model (without
-fix shake) is desired. If the LJ epsilon and sigma for HH and OH are
-set to 0.0, it corresponds to the original 1983 TIP3P model
-"(Jorgensen)"_#Jorgensen1.
-
-O mass = 15.9994
-H mass = 1.008
-O charge = -0.834
-H charge = 0.417
-LJ epsilon of OO = 0.1521
-LJ sigma of OO = 3.1507
-LJ epsilon of HH = 0.0460
-LJ sigma of HH = 0.4000
-LJ epsilon of OH = 0.0836
-LJ sigma of OH = 1.7753
-K of OH bond = 450
-r0 of OH bond = 0.9572
-K of HOH angle = 55
-theta of HOH angle = 104.52 :all(b),p
-
-These are the parameters to use for TIP3P with a long-range Coulombic
-solver (e.g. Ewald or PPPM in LAMMPS), see "(Price)"_#Price1 for
-details:
-
-O mass = 15.9994
-H mass = 1.008
-O charge = -0.830
-H charge = 0.415
-LJ epsilon of OO = 0.102
-LJ sigma of OO = 3.188
-LJ epsilon, sigma of OH, HH = 0.0
-K of OH bond = 450
-r0 of OH bond = 0.9572
-K of HOH angle = 55
-theta of HOH angle = 104.52 :all(b),p
-
-Wikipedia also has a nice article on "water
-models"_http://en.wikipedia.org/wiki/Water_model.
-
-:line
-
-6.8 TIP4P water model :link(howto_8),h4
-
-The four-point TIP4P rigid water model extends the traditional
-three-point TIP3P model by adding an additional site, usually
-massless, where the charge associated with the oxygen atom is placed.
-This site M is located at a fixed distance away from the oxygen along
-the bisector of the HOH bond angle. A bond style of {harmonic} and an
-angle style of {harmonic} or {charmm} should also be used.
-
-A TIP4P model is run with LAMMPS using either this command
-for a cutoff model:
-
-"pair_style lj/cut/tip4p/cut"_pair_lj.html
-
-or these two commands for a long-range model:
-
-"pair_style lj/cut/tip4p/long"_pair_lj.html
-"kspace_style pppm/tip4p"_kspace_style.html :ul
-
-For both models, the bond lengths and bond angles should be held fixed
-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
-the "pair_style"_pair_style.html command, not as part of the pair
-coefficients.
-
-O mass = 15.9994
-H mass = 1.008
-O charge = -1.040
-H charge = 0.520
-r0 of OH bond = 0.9572
-theta of HOH angle = 104.52
-OM distance = 0.15
-LJ epsilon of O-O = 0.1550
-LJ sigma of O-O = 3.1536
-LJ epsilon, sigma of OH, HH = 0.0
-Coulombic cutoff = 8.5 :all(b),p
-
-For the TIP4/Ice model (J Chem Phys, 122, 234511 (2005);
-http://dx.doi.org/10.1063/1.1931662) these values can be used:
-
-O mass = 15.9994
-H mass = 1.008
-O charge = -1.1794
-H charge = 0.5897
-r0 of OH bond = 0.9572
-theta of HOH angle = 104.52
-OM distance = 0.1577
-LJ epsilon of O-O = 0.21084
-LJ sigma of O-O = 3.1668
-LJ epsilon, sigma of OH, HH = 0.0
-Coulombic cutoff = 8.5 :all(b),p
-
-For the TIP4P/2005 model (J Chem Phys, 123, 234505 (2005);
-http://dx.doi.org/10.1063/1.2121687), these values can be used:
-
-O mass = 15.9994
-H mass = 1.008
-O charge = -1.1128
-H charge = 0.5564
-r0 of OH bond = 0.9572
-theta of HOH angle = 104.52
-OM distance = 0.1546
-LJ epsilon of O-O = 0.1852
-LJ sigma of O-O = 3.1589
-LJ epsilon, sigma of OH, HH = 0.0
-Coulombic cutoff = 8.5 :all(b),p
-
-These are the parameters to use for TIP4P with a long-range Coulombic
-solver (e.g. Ewald or PPPM in LAMMPS):
-
-O mass = 15.9994
-H mass = 1.008
-O charge = -1.0484
-H charge = 0.5242
-r0 of OH bond = 0.9572
-theta of HOH angle = 104.52
-OM distance = 0.1250
-LJ epsilon of O-O = 0.16275
-LJ sigma of O-O = 3.16435
-LJ epsilon, sigma of OH, HH = 0.0 :all(b),p
-
-Note that the when using the TIP4P pair style, the neighbor list
-cutoff for Coulomb interactions is effectively extended by a distance
-2 * (OM distance), to account for the offset distance of the
-fictitious charges on O atoms in water molecules. Thus it is
-typically best in an efficiency sense to use a LJ cutoff >= Coulomb
-cutoff + 2*(OM distance), to shrink the size of the neighbor list.
-This leads to slightly larger cost for the long-range calculation, so
-you can test the trade-off for your model. The OM distance and the LJ
-and Coulombic cutoffs are set in the "pair_style
-lj/cut/tip4p/long"_pair_lj.html command.
-
-Wikipedia also has a nice article on "water
-models"_http://en.wikipedia.org/wiki/Water_model.
-
-:line
-
-6.9 SPC water model :link(howto_9),h4
-
-The SPC water model specifies a 3-site rigid water molecule with
-charges and Lennard-Jones parameters assigned to each of the 3 atoms.
-In LAMMPS the "fix shake"_fix_shake.html command can be used to hold
-the two O-H bonds and the H-O-H angle rigid. A bond style of
-{harmonic} and an angle style of {harmonic} or {charmm} should also be
-used.
-
-These are the additional parameters (in real units) to set for O and H
-atoms and the water molecule to run a rigid SPC model.
-
-O mass = 15.9994
-H mass = 1.008
-O charge = -0.820
-H charge = 0.410
-LJ epsilon of OO = 0.1553
-LJ sigma of OO = 3.166
-LJ epsilon, sigma of OH, HH = 0.0
-r0 of OH bond = 1.0
-theta of HOH angle = 109.47 :all(b),p
-
-Note that as originally proposed, the SPC model was run with a 9
-Angstrom cutoff for both LJ and Coulommbic terms. It can also be used
-with long-range Coulombics (Ewald or PPPM in LAMMPS), without changing
-any of the parameters above, though it becomes a different model in
-that mode of usage.
-
-The SPC/E (extended) water model is the same, except
-the partial charge assignments change:
-
-O charge = -0.8476
-H charge = 0.4238 :all(b),p
-
-See the "(Berendsen)"_#howto-Berendsen reference for more details on both
-the SPC and SPC/E models.
-
-Wikipedia also has a nice article on "water
-models"_http://en.wikipedia.org/wiki/Water_model.
-
-:line
-
-6.10 Coupling LAMMPS to other codes :link(howto_10),h4
-
-LAMMPS is designed to allow it to be coupled to other codes. For
-example, a quantum mechanics code might compute forces on a subset of
-atoms and pass those forces to LAMMPS. Or a continuum finite element
-(FE) simulation might use atom positions as boundary conditions on FE
-nodal points, compute a FE solution, and return interpolated forces on
-MD atoms.
-
-LAMMPS can be coupled to other codes in at least 3 ways. Each has
-advantages and disadvantages, which you'll have to think about in the
-context of your application.
-
-(1) Define a new "fix"_fix.html command that calls the other code. In
-this scenario, LAMMPS is the driver code. During its timestepping,
-the fix is invoked, and can make library calls to the other code,
-which has been linked to LAMMPS as a library. This is the way the
-"POEMS"_poems package that performs constrained rigid-body motion on
-groups of atoms is hooked to LAMMPS. See the
-"fix poems"_fix_poems.html command for more details. See "this
-section"_Section_modify.html of the documentation for info on how to add
-a new fix to LAMMPS.
-
-:link(poems,http://www.rpi.edu/~anderk5/lab)
-
-(2) Define a new LAMMPS command that calls the other code. This is
-conceptually similar to method (1), but in this case LAMMPS and the
-other code are on a more equal footing. Note that now the other code
-is not called during the timestepping of a LAMMPS run, but between
-runs. The LAMMPS input script can be used to alternate LAMMPS runs
-with calls to the other code, invoked via the new command. The
-"run"_run.html command facilitates this with its {every} option, which
-makes it easy to run a few steps, invoke the command, run a few steps,
-invoke the command, etc.
-
-In this scenario, the other code can be called as a library, as in
-(1), or it could be a stand-alone code, invoked by a system() call
-made by the command (assuming your parallel machine allows one or more
-processors to start up another program). In the latter case the
-stand-alone code could communicate with LAMMPS thru files that the
-command writes and reads.
-
-See "Section 10"_Section_modify.html of the documentation for how
-to add a new command to LAMMPS.
-
-(3) Use LAMMPS as a library called by another code. In this case the
-other code is the driver and calls LAMMPS as needed. Or a wrapper
-code could link and call both LAMMPS and another code as libraries.
-Again, the "run"_run.html command has options that allow it to be
-invoked with minimal overhead (no setup or clean-up) if you wish to do
-multiple short runs, driven by another program.
-
-Examples of driver codes that call LAMMPS as a library are included in
-the examples/COUPLE directory of the LAMMPS distribution; see
-examples/COUPLE/README for more details:
-
-simple: simple driver programs in C++ and C which invoke LAMMPS as a
-library :ulb,l
-
-lammps_quest: coupling of LAMMPS and "Quest"_quest, to run classical
-MD with quantum forces calculated by a density functional code :l
-
-lammps_spparks: coupling of LAMMPS and "SPPARKS"_spparks, to couple
-a kinetic Monte Carlo model for grain growth using MD to calculate
-strain induced across grain boundaries :l
-:ule
-
-: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
-describes how to build LAMMPS as a library. Once this is done, you
-can interface with LAMMPS either via C++, C, Fortran, or Python (or
-any other language that supports a vanilla C-like interface). For
-example, from C++ you could create one (or more) "instances" of
-LAMMPS, pass it an input script to process, or execute individual
-commands, all by invoking the correct class methods in LAMMPS. From C
-or Fortran you can make function calls to do the same things. See
-"Section 11"_Section_python.html of the manual for a description
-of the Python wrapper provided with LAMMPS that operates through the
-LAMMPS library interface.
-
-The files src/library.cpp and library.h contain the C-style interface
-to LAMMPS. See "Section 6.19"_Section_howto.html#howto_19 of the
-manual for a description of the interface and how to extend it for
-your needs.
-
-Note that the lammps_open() function that creates an instance of
-LAMMPS takes an MPI communicator as an argument. This means that
-instance of LAMMPS will run on the set of processors in the
-communicator. Thus the calling code can run LAMMPS on all or a subset
-of processors. For example, a wrapper script might decide to
-alternate between LAMMPS and another code, allowing them both to run
-on all the processors. Or it might allocate half the processors to
-LAMMPS and half to the other code and run both codes simultaneously
-before syncing them up periodically. Or it might instantiate multiple
-instances of LAMMPS to perform different calculations.
-
-:line
-
-6.11 Visualizing LAMMPS snapshots :link(howto_11),h4
-
-LAMMPS itself does not do visualization, but snapshots from LAMMPS
-simulations can be visualized (and analyzed) in a variety of ways.
-
-LAMMPS snapshots are created by the "dump"_dump.html command which can
-create files in several formats. The native LAMMPS dump format is a
-text file (see "dump atom" or "dump custom") which can be visualized
-by several popular visualization tools. The "dump image"_dump_image.html
-and "dump movie"_dump_image.html styles can output internally rendered
-images and convert a sequence of them to a movie during the MD run.
-Several programs included with LAMMPS as auxiliary tools can convert
-between LAMMPS format files and other formats.
-See the "Section 9"_Section_tools.html doc page for details.
-
-A Python-based toolkit distributed by our group can read native LAMMPS
-dump files, including custom dump files with additional columns of
-user-specified atom information, and convert them to various formats
-or pipe them into visualization software directly. See the "Pizza.py
-WWW site"_pizza for details. Specifically, Pizza.py can convert
-LAMMPS dump files into PDB, XYZ, "Ensight"_ensight, and VTK formats.
-Pizza.py can pipe LAMMPS dump files directly into the Raster3d and
-RasMol visualization programs. Pizza.py has tools that do interactive
-3d OpenGL visualization and one that creates SVG images of dump file
-snapshots.
-
-:link(pizza,http://www.sandia.gov/~sjplimp/pizza.html)
-:link(ensight,http://www.ensight.com)
-:link(atomeye,http://mt.seas.upenn.edu/Archive/Graphics/A)
-
-:line
-
-6.12 Triclinic (non-orthogonal) simulation boxes :link(howto_12),h4
-
-By default, LAMMPS uses an orthogonal simulation box to encompass the
-particles. The "boundary"_boundary.html command sets the boundary
-conditions of the box (periodic, non-periodic, etc). The orthogonal
-box has its "origin" at (xlo,ylo,zlo) and is defined by 3 edge vectors
-starting from the origin given by [a] = (xhi-xlo,0,0); [b] =
-(0,yhi-ylo,0); [c] = (0,0,zhi-zlo). The 6 parameters
-(xlo,xhi,ylo,yhi,zlo,zhi) are defined at the time the simulation box
-is created, e.g. by the "create_box"_create_box.html or
-"read_data"_read_data.html or "read_restart"_read_restart.html
-commands. Additionally, LAMMPS defines box size parameters lx,ly,lz
-where lx = xhi-xlo, and similarly in the y and z dimensions. The 6
-parameters, as well as lx,ly,lz, can be output via the "thermo_style
-custom"_thermo_style.html command.
-
-LAMMPS also allows simulations to be performed in triclinic
-(non-orthogonal) simulation boxes shaped as a parallelepiped with
-triclinic symmetry. The parallelepiped has its "origin" at
-(xlo,ylo,zlo) and is defined by 3 edge vectors starting from the
-origin given by [a] = (xhi-xlo,0,0); [b] = (xy,yhi-ylo,0); [c] =
-(xz,yz,zhi-zlo). {xy,xz,yz} can be 0.0 or positive or negative values
-and are called "tilt factors" because they are the amount of
-displacement applied to faces of an originally orthogonal box to
-transform it into the parallelepiped. In LAMMPS the triclinic
-simulation box edge vectors [a], [b], and [c] cannot be arbitrary
-vectors. As indicated, [a] must lie on the positive x axis. [b] must
-lie in the xy plane, with strictly positive y component. [c] may have
-any orientation with strictly positive z component. The requirement
-that [a], [b], and [c] have strictly positive x, y, and z components,
-respectively, ensures that [a], [b], and [c] form a complete
-right-handed basis. These restrictions impose no loss of generality,
-since it is possible to rotate/invert any set of 3 crystal basis
-vectors so that they conform to the restrictions.
-
-For example, assume that the 3 vectors [A],[B],[C] are the edge
-vectors of a general parallelepiped, where there is no restriction on
-[A],[B],[C] other than they form a complete right-handed basis i.e.
-[A] x [B] . [C] > 0. The equivalent LAMMPS [a],[b],[c] are a linear
-rotation of [A], [B], and [C] and can be computed as follows:
-
-:c,image(Eqs/transform.jpg)
-
-where A = | [A] | indicates the scalar length of [A]. The hat symbol (^)
-indicates the corresponding unit vector. {beta} and {gamma} are angles
-between the vectors described below. Note that by construction,
-[a], [b], and [c] have strictly positive x, y, and z components, respectively.
-If it should happen that
-[A], [B], and [C] form a left-handed basis, then the above equations
-are not valid for [c]. In this case, it is necessary
-to first apply an inversion. This can be achieved
-by interchanging two basis vectors or by changing the sign of one of them.
-
-For consistency, the same rotation/inversion applied to the basis vectors
-must also be applied to atom positions, velocities,
-and any other vector quantities.
-This can be conveniently achieved by first converting to
-fractional coordinates in the
-old basis and then converting to distance coordinates in the new basis.
-The transformation is given by the following equation:
-
-:c,image(Eqs/rotate.jpg)
-
-where {V} is the volume of the box, [X] is the original vector quantity and
-[x] is the vector in the LAMMPS basis.
-
-There is no requirement that a triclinic box be periodic in any
-dimension, though it typically should be in at least the 2nd dimension
-of the tilt (y in xy) if you want to enforce a shift in periodic
-boundary conditions across that boundary. Some commands that work
-with triclinic boxes, e.g. the "fix deform"_fix_deform.html and "fix
-npt"_fix_nh.html commands, require periodicity or non-shrink-wrap
-boundary conditions in specific dimensions. See the command doc pages
-for details.
-
-The 9 parameters (xlo,xhi,ylo,yhi,zlo,zhi,xy,xz,yz) are defined at the
-time the simulation box is created. This happens in one of 3 ways.
-If the "create_box"_create_box.html command is used with a region of
-style {prism}, then a triclinic box is setup. See the
-"region"_region.html command for details. If the
-"read_data"_read_data.html command is used to define the simulation
-box, and the header of the data file contains a line with the "xy xz
-yz" keyword, then a triclinic box is setup. See the
-"read_data"_read_data.html command for details. Finally, if the
-"read_restart"_read_restart.html command reads a restart file which
-was written from a simulation using a triclinic box, then a triclinic
-box will be setup for the restarted simulation.
-
-Note that you can define a triclinic box with all 3 tilt factors =
-0.0, so that it is initially orthogonal. This is necessary if the box
-will become non-orthogonal, e.g. due to the "fix npt"_fix_nh.html or
-"fix deform"_fix_deform.html commands. Alternatively, you can use the
-"change_box"_change_box.html command to convert a simulation box from
-orthogonal to triclinic and vice versa.
-
-As with orthogonal boxes, LAMMPS defines triclinic box size parameters
-lx,ly,lz where lx = xhi-xlo, and similarly in the y and z dimensions.
-The 9 parameters, as well as lx,ly,lz, can be output via the
-"thermo_style custom"_thermo_style.html command.
-
-To avoid extremely tilted boxes (which would be computationally
-inefficient), LAMMPS normally requires that no tilt factor can skew
-the box more than half the distance of the parallel box length, which
-is the 1st dimension in the tilt factor (x for xz). This is required
-both when the simulation box is created, e.g. via the
-"create_box"_create_box.html or "read_data"_read_data.html commands,
-as well as when the box shape changes dynamically during a simulation,
-e.g. via the "fix deform"_fix_deform.html or "fix npt"_fix_nh.html
-commands.
-
-For example, if xlo = 2 and xhi = 12, then the x box length is 10 and
-the xy tilt factor must be between -5 and 5. Similarly, both xz and
-yz must be between -(xhi-xlo)/2 and +(yhi-ylo)/2. Note that this is
-not a limitation, since if the maximum tilt factor is 5 (as in this
-example), then configurations with tilt = ..., -15, -5, 5, 15, 25,
-... are geometrically all equivalent. If the box tilt exceeds this
-limit during a dynamics run (e.g. via the "fix deform"_fix_deform.html
-command), then the box is "flipped" to an equivalent shape with a tilt
-factor within the bounds, so the run can continue. See the "fix
-deform"_fix_deform.html doc page for further details.
-
-One exception to this rule is if the 1st dimension in the tilt
-factor (x for xy) is non-periodic. In that case, the limits on the
-tilt factor are not enforced, since flipping the box in that dimension
-does not change the atom positions due to non-periodicity. In this
-mode, if you tilt the system to extreme angles, the simulation will
-simply become inefficient, due to the highly skewed simulation box.
-
-The limitation on not creating a simulation box with a tilt factor
-skewing the box more than half the distance of the parallel box length
-can be overridden via the "box"_box.html command. Setting the {tilt}
-keyword to {large} allows any tilt factors to be specified.
-
-Box flips that may occur using the "fix deform"_fix_deform.html or
-"fix npt"_fix_nh.html commands can be turned off using the {flip no}
-option with either of the commands.
-
-Note that if a simulation box has a large tilt factor, LAMMPS will run
-less efficiently, due to the large volume of communication needed to
-acquire ghost atoms around a processor's irregular-shaped sub-domain.
-For extreme values of tilt, LAMMPS may also lose atoms and generate an
-error.
-
-Triclinic crystal structures are often defined using three lattice
-constants {a}, {b}, and {c}, and three angles {alpha}, {beta} and
-{gamma}. Note that in this nomenclature, the a, b, and c lattice
-constants are the scalar lengths of the edge vectors [a], [b], and [c]
-defined above. The relationship between these 6 quantities
-(a,b,c,alpha,beta,gamma) and the LAMMPS box sizes (lx,ly,lz) =
-(xhi-xlo,yhi-ylo,zhi-zlo) and tilt factors (xy,xz,yz) is as follows:
-
-:c,image(Eqs/box.jpg)
-
-The inverse relationship can be written as follows:
-
-:c,image(Eqs/box_inverse.jpg)
-
-The values of {a}, {b}, {c} , {alpha}, {beta} , and {gamma} can be printed
-out or accessed by computes using the
-"thermo_style custom"_thermo_style.html keywords
-{cella}, {cellb}, {cellc}, {cellalpha}, {cellbeta}, {cellgamma},
-respectively.
-
-As discussed on the "dump"_dump.html command doc page, when the BOX
-BOUNDS for a snapshot is written to a dump file for a triclinic box,
-an orthogonal bounding box which encloses the triclinic simulation box
-is output, along with the 3 tilt factors (xy, xz, yz) of the triclinic
-box, formatted as follows:
-
-ITEM: BOX BOUNDS xy xz yz
-xlo_bound xhi_bound xy
-ylo_bound yhi_bound xz
-zlo_bound zhi_bound yz :pre
-
-This bounding box is convenient for many visualization programs and is
-calculated from the 9 triclinic box parameters
-(xlo,xhi,ylo,yhi,zlo,zhi,xy,xz,yz) as follows:
-
-xlo_bound = xlo + MIN(0.0,xy,xz,xy+xz)
-xhi_bound = xhi + MAX(0.0,xy,xz,xy+xz)
-ylo_bound = ylo + MIN(0.0,yz)
-yhi_bound = yhi + MAX(0.0,yz)
-zlo_bound = zlo
-zhi_bound = zhi :pre
-
-These formulas can be inverted if you need to convert the bounding box
-back into the triclinic box parameters, e.g. xlo = xlo_bound -
-MIN(0.0,xy,xz,xy+xz).
-
-One use of triclinic simulation boxes is to model solid-state crystals
-with triclinic symmetry. The "lattice"_lattice.html command can be
-used with non-orthogonal basis vectors to define a lattice that will
-tile a triclinic simulation box via the
-"create_atoms"_create_atoms.html command.
-
-A second use is to run Parinello-Rahman dynamics via the "fix
-npt"_fix_nh.html command, which will adjust the xy, xz, yz tilt
-factors to compensate for off-diagonal components of the pressure
-tensor. The analog for an "energy minimization"_minimize.html is
-the "fix box/relax"_fix_box_relax.html command.
-
-A third use is to shear a bulk solid to study the response of the
-material. The "fix deform"_fix_deform.html command can be used for
-this purpose. It allows dynamic control of the xy, xz, yz tilt
-factors as a simulation runs. This is discussed in the next section
-on non-equilibrium MD (NEMD) simulations.
-
-:line
-
-6.13 NEMD simulations :link(howto_13),h4
-
-Non-equilibrium molecular dynamics or NEMD simulations are typically
-used to measure a fluid's rheological properties such as viscosity.
-In LAMMPS, such simulations can be performed by first setting up a
-non-orthogonal simulation box (see the preceding Howto section).
-
-A shear strain can be applied to the simulation box at a desired
-strain rate by using the "fix deform"_fix_deform.html command. The
-"fix nvt/sllod"_fix_nvt_sllod.html command can be used to thermostat
-the sheared fluid and integrate the SLLOD equations of motion for the
-system. Fix nvt/sllod uses "compute
-temp/deform"_compute_temp_deform.html to compute a thermal temperature
-by subtracting out the streaming velocity of the shearing atoms. The
-velocity profile or other properties of the fluid can be monitored via
-the "fix ave/chunk"_fix_ave_chunk.html command.
-
-As discussed in the previous section on non-orthogonal simulation
-boxes, the amount of tilt or skew that can be applied is limited by
-LAMMPS for computational efficiency to be 1/2 of the parallel box
-length. However, "fix deform"_fix_deform.html can continuously strain
-a box by an arbitrary amount. As discussed in the "fix
-deform"_fix_deform.html command, when the tilt value reaches a limit,
-the box is flipped to the opposite limit which is an equivalent tiling
-of periodic space. The strain rate can then continue to change as
-before. In a long NEMD simulation these box re-shaping events may
-occur many times.
-
-In a NEMD simulation, the "remap" option of "fix
-deform"_fix_deform.html should be set to "remap v", since that is what
-"fix nvt/sllod"_fix_nvt_sllod.html assumes to generate a velocity
-profile consistent with the applied shear strain rate.
-
-An alternative method for calculating viscosities is provided via the
-"fix viscosity"_fix_viscosity.html command.
-
-NEMD simulations can also be used to measure transport properties of a fluid
-through a pore or channel. Simulations of steady-state flow can be performed
-using the "fix flow/gauss"_fix_flow_gauss.html command.
-
-:line
-
-6.14 Finite-size spherical and aspherical particles :link(howto_14),h4
-
-Typical MD models treat atoms or particles as point masses. Sometimes
-it is desirable to have a model with finite-size particles such as
-spheroids or ellipsoids or generalized aspherical bodies. The
-difference is that such particles have a moment of inertia, rotational
-energy, and angular momentum. Rotation is induced by torque coming
-from interactions with other particles.
-
-LAMMPS has several options for running simulations with these kinds of
-particles. The following aspects are discussed in turn:
-
-atom styles
-pair potentials
-time integration
-computes, thermodynamics, and dump output
-rigid bodies composed of finite-size particles :ul
-
-Example input scripts for these kinds of models are in the body,
-colloid, dipole, ellipse, line, peri, pour, and tri directories of the
-"examples directory"_Section_example.html in the LAMMPS distribution.
-
-Atom styles :h4
-
-There are several "atom styles"_atom_style.html that allow for
-definition of finite-size particles: sphere, dipole, ellipsoid, line,
-tri, peri, and body.
-
-The sphere style defines particles that are spheriods and each
-particle can have a unique diameter and mass (or density). These
-particles store an angular velocity (omega) and can be acted upon by
-torque. The "set" command can be used to modify the diameter and mass
-of individual particles, after then are created.
-
-The dipole style does not actually define finite-size particles, but
-is often used in conjunction with spherical particles, via a command
-like
-
-atom_style hybrid sphere dipole :pre
-
-This is because when dipoles interact with each other, they induce
-torques, and a particle must be finite-size (i.e. have a moment of
-inertia) in order to respond and rotate. See the "atom_style
-dipole"_atom_style.html command for details. The "set" command can be
-used to modify the orientation and length of the dipole moment of
-individual particles, after then are created.
-
-The ellipsoid style defines particles that are ellipsoids and thus can
-be aspherical. Each particle has a shape, specified by 3 diameters,
-and mass (or density). These particles store an angular momentum and
-their orientation (quaternion), and can be acted upon by torque. They
-do not store an angular velocity (omega), which can be in a different
-direction than angular momentum, rather they compute it as needed.
-The "set" command can be used to modify the diameter, orientation, and
-mass of individual particles, after then are created. It also has a
-brief explanation of what quaternions are.
-
-The line style defines line segment particles with two end points and
-a mass (or density). They can be used in 2d simulations, and they can
-be joined together to form rigid bodies which represent arbitrary
-polygons.
-
-The tri style defines triangular particles with three corner points
-and a mass (or density). They can be used in 3d simulations, and they
-can be joined together to form rigid bodies which represent arbitrary
-particles with a triangulated surface.
-
-The peri style is used with "Peridynamic models"_pair_peri.html and
-defines particles as having a volume, that is used internally in the
-"pair_style peri"_pair_peri.html potentials.
-
-The body style allows for definition of particles which can represent
-complex entities, such as surface meshes of discrete points,
-collections of sub-particles, deformable objects, etc. The body style
-is discussed in more detail on the "body"_body.html doc page.
-
-Note that if one of these atom styles is used (or multiple styles via
-the "atom_style hybrid"_atom_style.html command), not all particles in
-the system are required to be finite-size or aspherical.
-
-For example, in the ellipsoid style, if the 3 shape parameters are set
-to the same value, the particle will be a sphere rather than an
-ellipsoid. If the 3 shape parameters are all set to 0.0 or if the
-diameter is set to 0.0, it will be a point particle. In the line or
-tri style, if the lineflag or triflag is specified as 0, then it
-will be a point particle.
-
-Some of the pair styles used to compute pairwise interactions between
-finite-size particles also compute the correct interaction with point
-particles as well, e.g. the interaction between a point particle and a
-finite-size particle or between two point particles. If necessary,
-"pair_style hybrid"_pair_hybrid.html can be used to insure the correct
-interactions are computed for the appropriate style of interactions.
-Likewise, using groups to partition particles (ellipsoids versus
-spheres versus point particles) will allow you to use the appropriate
-time integrators and temperature computations for each class of
-particles. See the doc pages for various commands for details.
-
-Also note that for "2d simulations"_dimension.html, atom styles sphere
-and ellipsoid still use 3d particles, rather than as circular disks or
-ellipses. This means they have the same moment of inertia as the 3d
-object. When temperature is computed, the correct degrees of freedom
-are used for rotation in a 2d versus 3d system.
-
-Pair potentials :h4
-
-When a system with finite-size particles is defined, the particles
-will only rotate and experience torque if the force field computes
-such interactions. These are the various "pair
-styles"_pair_style.html that generate torque:
-
-"pair_style gran/history"_pair_gran.html
-"pair_style gran/hertzian"_pair_gran.html
-"pair_style gran/no_history"_pair_gran.html
-"pair_style dipole/cut"_pair_dipole.html
-"pair_style gayberne"_pair_gayberne.html
-"pair_style resquared"_pair_resquared.html
-"pair_style brownian"_pair_brownian.html
-"pair_style lubricate"_pair_lubricate.html
-"pair_style line/lj"_pair_line_lj.html
-"pair_style tri/lj"_pair_tri_lj.html
-"pair_style body"_pair_body.html :ul
-
-The granular pair styles are used with spherical particles. The
-dipole pair style is used with the dipole atom style, which could be
-applied to spherical or ellipsoidal particles. The GayBerne and
-REsquared potentials require ellipsoidal particles, though they will
-also work if the 3 shape parameters are the same (a sphere). The
-Brownian and lubrication potentials are used with spherical particles.
-The line, tri, and body potentials are used with line segment,
-triangular, and body particles respectively.
-
-Time integration :h4
-
-There are several fixes that perform time integration on finite-size
-spherical particles, meaning the integrators update the rotational
-orientation and angular velocity or angular momentum of the particles:
-
-"fix nve/sphere"_fix_nve_sphere.html
-"fix nvt/sphere"_fix_nvt_sphere.html
-"fix npt/sphere"_fix_npt_sphere.html :ul
-
-Likewise, there are 3 fixes that perform time integration on
-ellipsoidal particles:
-
-"fix nve/asphere"_fix_nve_asphere.html
-"fix nvt/asphere"_fix_nvt_asphere.html
-"fix npt/asphere"_fix_npt_asphere.html :ul
-
-The advantage of these fixes is that those which thermostat the
-particles include the rotational degrees of freedom in the temperature
-calculation and thermostatting. The "fix langevin"_fix_langevin
-command can also be used with its {omgea} or {angmom} options to
-thermostat the rotational degrees of freedom for spherical or
-ellipsoidal particles. Other thermostatting fixes only operate on the
-translational kinetic energy of finite-size particles.
-
-These fixes perform constant NVE time integration on line segment,
-triangular, and body particles:
-
-"fix nve/line"_fix_nve_line.html
-"fix nve/tri"_fix_nve_tri.html
-"fix nve/body"_fix_nve_body.html :ul
-
-Note that for mixtures of point and finite-size particles, these
-integration fixes can only be used with "groups"_group.html which
-contain finite-size particles.
-
-Computes, thermodynamics, and dump output :h4
-
-There are several computes that calculate the temperature or
-rotational energy of spherical or ellipsoidal particles:
-
-"compute temp/sphere"_compute_temp_sphere.html
-"compute temp/asphere"_compute_temp_asphere.html
-"compute erotate/sphere"_compute_erotate_sphere.html
-"compute erotate/asphere"_compute_erotate_asphere.html :ul
-
-These include rotational degrees of freedom in their computation. If
-you wish the thermodynamic output of temperature or pressure to use
-one of these computes (e.g. for a system entirely composed of
-finite-size particles), then the compute can be defined and the
-"thermo_modify"_thermo_modify.html command used. Note that by default
-thermodynamic quantities will be calculated with a temperature that
-only includes translational degrees of freedom. See the
-"thermo_style"_thermo_style.html command for details.
-
-These commands can be used to output various attributes of finite-size
-particles:
-
-"dump custom"_dump.html
-"compute property/atom"_compute_property_atom.html
-"dump local"_dump.html
-"compute body/local"_compute_body_local.html :ul
-
-Attributes include the dipole moment, the angular velocity, the
-angular momentum, the quaternion, the torque, the end-point and
-corner-point coordinates (for line and tri particles), and
-sub-particle attributes of body particles.
-
-Rigid bodies composed of finite-size particles :h4
-
-The "fix rigid"_fix_rigid.html command treats a collection of
-particles as a rigid body, computes its inertia tensor, sums the total
-force and torque on the rigid body each timestep due to forces on its
-constituent particles, and integrates the motion of the rigid body.
-
-If any of the constituent particles of a rigid body are finite-size
-particles (spheres or ellipsoids or line segments or triangles), then
-their contribution to the inertia tensor of the body is different than
-if they were point particles. This means the rotational dynamics of
-the rigid body will be different. Thus a model of a dimer is
-different if the dimer consists of two point masses versus two
-spheroids, even if the two particles have the same mass. Finite-size
-particles that experience torque due to their interaction with other
-particles will also impart that torque to a rigid body they are part
-of.
-
-See the "fix rigid" command for example of complex rigid-body models
-it is possible to define in LAMMPS.
-
-Note that the "fix shake"_fix_shake.html command can also be used to
-treat 2, 3, or 4 particles as a rigid body, but it always assumes the
-particles are point masses.
-
-Also note that body particles cannot be modeled with the "fix
-rigid"_fix_rigid.html command. Body particles are treated by LAMMPS
-as single particles, though they can store internal state, such as a
-list of sub-particles. Individual body partices are typically treated
-as rigid bodies, and their motion integrated with a command like "fix
-nve/body"_fix_nve_body.html. Interactions between pairs of body
-particles are computed via a command like "pair_style
-body"_pair_body.html.
-
-:line
-
-6.15 Output from LAMMPS (thermo, dumps, computes, fixes, variables) :link(howto_15),h4
-
-There are four basic kinds of LAMMPS output:
-
-"Thermodynamic output"_thermo_style.html, which is a list
-of quantities printed every few timesteps to the screen and logfile. :ulb,l
-
-"Dump files"_dump.html, which contain snapshots of atoms and various
-per-atom values and are written at a specified frequency. :l
-
-Certain fixes can output user-specified quantities to files: "fix
-ave/time"_fix_ave_time.html for time averaging, "fix
-ave/chunk"_fix_ave_chunk.html for spatial or other averaging, and "fix
-print"_fix_print.html for single-line output of
-"variables"_variable.html. Fix print can also output to the
-screen. :l
-
-"Restart files"_restart.html. :l
-:ule
-
-A simulation prints one set of thermodynamic output and (optionally)
-restart files. It can generate any number of dump files and fix
-output files, depending on what "dump"_dump.html and "fix"_fix.html
-commands you specify.
-
-As discussed below, LAMMPS gives you a variety of ways to determine
-what quantities are computed and printed when the thermodynamics,
-dump, or fix commands listed above perform output. Throughout this
-discussion, note that users can also "add their own computes and fixes
-to LAMMPS"_Section_modify.html which can then generate values that can
-then be output with these commands.
-
-The following sub-sections discuss different LAMMPS command related
-to output and the kind of data they operate on and produce:
-
-"Global/per-atom/local data"_#global
-"Scalar/vector/array data"_#scalar
-"Thermodynamic output"_#thermo
-"Dump file output"_#dump
-"Fixes that write output files"_#fixoutput
-"Computes that process output quantities"_#computeoutput
-"Fixes that process output quantities"_#fixprocoutput
-"Computes that generate values to output"_#compute
-"Fixes that generate values to output"_#fix
-"Variables that generate values to output"_#variable
-"Summary table of output options and data flow between commands"_#table :ul
-
-Global/per-atom/local data :h4,link(global)
-
-Various output-related commands work with three different styles of
-data: global, per-atom, or local. A global datum is one or more
-system-wide values, e.g. the temperature of the system. A per-atom
-datum is one or more values per atom, e.g. the kinetic energy of each
-atom. Local datums are calculated by each processor based on the
-atoms it owns, but there may be zero or more per atom, e.g. a list of
-bond distances.
-
-Scalar/vector/array data :h4,link(scalar)
-
-Global, per-atom, and local datums can each come in three kinds: a
-single scalar value, a vector of values, or a 2d array of values. The
-doc page for a "compute" or "fix" or "variable" that generates data
-will specify both the style and kind of data it produces, e.g. a
-per-atom vector.
-
-When a quantity is accessed, as in many of the output commands
-discussed below, it can be referenced via the following bracket
-notation, where ID in this case is the ID of a compute. The leading
-"c_" would be replaced by "f_" for a fix, or "v_" for a variable:
-
-c_ID | entire scalar, vector, or array
-c_ID\[I\] | one element of vector, one column of array
-c_ID\[I\]\[J\] | one element of array :tb(s=|)
-
-In other words, using one bracket reduces the dimension of the data
-once (vector -> scalar, array -> vector). Using two brackets reduces
-the dimension twice (array -> scalar). Thus a command that uses
-scalar values as input can typically also process elements of a vector
-or array.
-
-Thermodynamic output :h4,link(thermo)
-
-The frequency and format of thermodynamic output is set by the
-"thermo"_thermo.html, "thermo_style"_thermo_style.html, and
-"thermo_modify"_thermo_modify.html commands. The
-"thermo_style"_thermo_style.html command also specifies what values
-are calculated and written out. Pre-defined keywords can be specified
-(e.g. press, etotal, etc). Three additional kinds of keywords can
-also be specified (c_ID, f_ID, v_name), where a "compute"_compute.html
-or "fix"_fix.html or "variable"_variable.html provides the value to be
-output. In each case, the compute, fix, or variable must generate
-global values for input to the "thermo_style custom"_dump.html
-command.
-
-Note that thermodynamic output values can be "extensive" or
-"intensive". The former scale with the number of atoms in the system
-(e.g. total energy), the latter do not (e.g. temperature). The
-setting for "thermo_modify norm"_thermo_modify.html determines whether
-extensive quantities are normalized or not. Computes and fixes
-produce either extensive or intensive values; see their individual doc
-pages for details. "Equal-style variables"_variable.html produce only
-intensive values; you can include a division by "natoms" in the
-formula if desired, to make an extensive calculation produce an
-intensive result.
-
-Dump file output :h4,link(dump)
-
-Dump file output is specified by the "dump"_dump.html and
-"dump_modify"_dump_modify.html commands. There are several
-pre-defined formats (dump atom, dump xtc, etc).
-
-There is also a "dump custom"_dump.html format where the user
-specifies what values are output with each atom. Pre-defined atom
-attributes can be specified (id, x, fx, etc). Three additional kinds
-of keywords can also be specified (c_ID, f_ID, v_name), where a
-"compute"_compute.html or "fix"_fix.html or "variable"_variable.html
-provides the values to be output. In each case, the compute, fix, or
-variable must generate per-atom values for input to the "dump
-custom"_dump.html command.
-
-There is also a "dump local"_dump.html format where the user specifies
-what local values to output. A pre-defined index keyword can be
-specified to enumerate the local values. Two additional kinds of
-keywords can also be specified (c_ID, f_ID), where a
-"compute"_compute.html or "fix"_fix.html or "variable"_variable.html
-provides the values to be output. In each case, the compute or fix
-must generate local values for input to the "dump local"_dump.html
-command.
-
-Fixes that write output files :h4,link(fixoutput)
-
-Several fixes take various quantities as input and can write output
-files: "fix ave/time"_fix_ave_time.html, "fix
-ave/chunk"_fix_ave_chunk.html, "fix ave/histo"_fix_ave_histo.html,
-"fix ave/correlate"_fix_ave_correlate.html, and "fix
-print"_fix_print.html.
-
-The "fix ave/time"_fix_ave_time.html command enables direct output to
-a file and/or time-averaging of global scalars or vectors. The user
-specifies one or more quantities as input. These can be global
-"compute"_compute.html values, global "fix"_fix.html values, or
-"variables"_variable.html of any style except the atom style which
-produces per-atom values. Since a variable can refer to keywords used
-by the "thermo_style custom"_thermo_style.html command (like temp or
-press) and individual per-atom values, a wide variety of quantities
-can be time averaged and/or output in this way. If the inputs are one
-or more scalar values, then the fix generate a global scalar or vector
-of output. If the inputs are one or more vector values, then the fix
-generates a global vector or array of output. The time-averaged
-output of this fix can also be used as input to other output commands.
-
-The "fix ave/chunk"_fix_ave_chunk.html command enables direct output
-to a file of chunk-averaged per-atom quantities like those output in
-dump files. Chunks can represent spatial bins or other collections of
-atoms, e.g. individual molecules. The per-atom quantities can be atom
-density (mass or number) or atom attributes such as position,
-velocity, force. They can also be per-atom quantities calculated by a
-"compute"_compute.html, by a "fix"_fix.html, or by an atom-style
-"variable"_variable.html. The chunk-averaged output of this fix can
-also be used as input to other output commands.
-
-The "fix ave/histo"_fix_ave_histo.html command enables direct output
-to a file of histogrammed quantities, which can be global or per-atom
-or local quantities. The histogram output of this fix can also be
-used as input to other output commands.
-
-The "fix ave/correlate"_fix_ave_correlate.html command enables direct
-output to a file of time-correlated quantities, which can be global
-values. The correlation matrix output of this fix can also be used as
-input to other output commands.
-
-The "fix print"_fix_print.html command can generate a line of output
-written to the screen and log file or to a separate file, periodically
-during a running simulation. The line can contain one or more
-"variable"_variable.html values for any style variable except the
-vector or atom styles). As explained above, variables themselves can
-contain references to global values generated by "thermodynamic
-keywords"_thermo_style.html, "computes"_compute.html,
-"fixes"_fix.html, or other "variables"_variable.html, or to per-atom
-values for a specific atom. Thus the "fix print"_fix_print.html
-command is a means to output a wide variety of quantities separate
-from normal thermodynamic or dump file output.
-
-Computes that process output quantities :h4,link(computeoutput)
-
-The "compute reduce"_compute_reduce.html and "compute
-reduce/region"_compute_reduce.html commands take one or more per-atom
-or local vector quantities as inputs and "reduce" them (sum, min, max,
-ave) to scalar quantities. These are produced as output values which
-can be used as input to other output commands.
-
-The "compute slice"_compute_slice.html command take one or more global
-vector or array quantities as inputs and extracts a subset of their
-values to create a new vector or array. These are produced as output
-values which can be used as input to other output commands.
-
-The "compute property/atom"_compute_property_atom.html command takes a
-list of one or more pre-defined atom attributes (id, x, fx, etc) and
-stores the values in a per-atom vector or array. These are produced
-as output values which can be used as input to other output commands.
-The list of atom attributes is the same as for the "dump
-custom"_dump.html command.
-
-The "compute property/local"_compute_property_local.html command takes
-a list of one or more pre-defined local attributes (bond info, angle
-info, etc) and stores the values in a local vector or array. These
-are produced as output values which can be used as input to other
-output commands.
-
-Fixes that process output quantities :h4,link(fixprocoutput)
-
-The "fix vector"_fix_vector.html command can create global vectors as
-output from global scalars as input, accumulating them one element at
-a time.
-
-The "fix ave/atom"_fix_ave_atom.html command performs time-averaging
-of per-atom vectors. The per-atom quantities can be atom attributes
-such as position, velocity, force. They can also be per-atom
-quantities calculated by a "compute"_compute.html, by a
-"fix"_fix.html, or by an atom-style "variable"_variable.html. The
-time-averaged per-atom output of this fix can be used as input to
-other output commands.
-
-The "fix store/state"_fix_store_state.html command can archive one or
-more per-atom attributes at a particular time, so that the old values
-can be used in a future calculation or output. The list of atom
-attributes is the same as for the "dump custom"_dump.html command,
-including per-atom quantities calculated by a "compute"_compute.html,
-by a "fix"_fix.html, or by an atom-style "variable"_variable.html.
-The output of this fix can be used as input to other output commands.
-
-Computes that generate values to output :h4,link(compute)
-
-Every "compute"_compute.html in LAMMPS produces either global or
-per-atom or local values. The values can be scalars or vectors or
-arrays of data. These values can be output using the other commands
-described in this section. The doc page for each compute command
-describes what it produces. Computes that produce per-atom or local
-values have the word "atom" or "local" in their style name. Computes
-without the word "atom" or "local" produce global values.
-
-Fixes that generate values to output :h4,link(fix)
-
-Some "fixes"_fix.html in LAMMPS produces either global or per-atom or
-local values which can be accessed by other commands. The values can
-be scalars or vectors or arrays of data. These values can be output
-using the other commands described in this section. The doc page for
-each fix command tells whether it produces any output quantities and
-describes them.
-
-Variables that generate values to output :h4,link(variable)
-
-"Variables"_variable.html defined in an input script can store one or
-more strings. But equal-style, vector-style, and atom-style or
-atomfile-style variables generate a global scalar value, global vector
-or values, or a per-atom vector, respectively, when accessed. The
-formulas used to define these variables can contain references to the
-thermodynamic keywords and to global and per-atom data generated by
-computes, fixes, and other variables. The values generated by
-variables can be used as input to and thus output by the other
-commands described in this section.
-
-Summary table of output options and data flow between commands :h4,link(table)
-
-This table summarizes the various commands that can be used for
-generating output from LAMMPS. Each command produces output data of
-some kind and/or writes data to a file. Most of the commands can take
-data from other commands as input. Thus you can link many of these
-commands together in pipeline form, where data produced by one command
-is used as input to another command and eventually written to the
-screen or to a file. Note that to hook two commands together the
-output and input data types must match, e.g. global/per-atom/local
-data and scalar/vector/array data.
-
-Also note that, as described above, when a command takes a scalar as
-input, that could be an element of a vector or array. Likewise a
-vector input could be a column of an array.
-
-Command: Input: Output:
-"thermo_style custom"_thermo_style.html: global scalars: screen, log file:
-"dump custom"_dump.html: per-atom vectors: dump file:
-"dump local"_dump.html: local vectors: dump file:
-"fix print"_fix_print.html: global scalar from variable: screen, file:
-"print"_print.html: global scalar from variable: screen:
-"computes"_compute.html: N/A: global/per-atom/local scalar/vector/array:
-"fixes"_fix.html: N/A: global/per-atom/local scalar/vector/array:
-"variables"_variable.html: global scalars and vectors, per-atom vectors: global scalar and vector, per-atom vector:
-"compute reduce"_compute_reduce.html: per-atom/local vectors: global scalar/vector:
-"compute slice"_compute_slice.html: global vectors/arrays: global vector/array:
-"compute property/atom"_compute_property_atom.html: per-atom vectors: per-atom vector/array:
-"compute property/local"_compute_property_local.html: local vectors: local vector/array:
-"fix vector"_fix_vector.html: global scalars: global vector:
-"fix ave/atom"_fix_ave_atom.html: per-atom vectors: per-atom vector/array:
-"fix ave/time"_fix_ave_time.html: global scalars/vectors: global scalar/vector/array, file:
-"fix ave/chunk"_fix_ave_chunk.html: per-atom vectors: global array, file:
-"fix ave/histo"_fix_ave_histo.html: global/per-atom/local scalars and vectors: global array, file:
-"fix ave/correlate"_fix_ave_correlate.html: global scalars: global array, file:
-"fix store/state"_fix_store_state.html: per-atom vectors: per-atom vector/array :tb(c=3,s=:)
-
-:line
-
-6.16 Thermostatting, barostatting, and computing temperature :link(howto_16),h4
-
-Thermostatting means controlling the temperature of particles in an MD
-simulation. Barostatting means controlling the pressure. Since the
-pressure includes a kinetic component due to particle velocities, both
-these operations require calculation of the temperature. Typically a
-target temperature (T) and/or pressure (P) is specified by the user,
-and the thermostat or barostat attempts to equilibrate the system to
-the requested T and/or P.
-
-Temperature is computed as kinetic energy divided by some number of
-degrees of freedom (and the Boltzmann constant). Since kinetic energy
-is a function of particle velocity, there is often a need to
-distinguish between a particle's advection velocity (due to some
-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 and barostatting. These "compute
-commands"_compute.html calculate temperature, and the "compute
-pressure"_compute_pressure.html command calculates pressure.
-
-"compute temp"_compute_temp.html
-"compute temp/sphere"_compute_temp_sphere.html
-"compute temp/asphere"_compute_temp_asphere.html
-"compute temp/com"_compute_temp_com.html
-"compute temp/deform"_compute_temp_deform.html
-"compute temp/partial"_compute_temp_partial.html
-"compute temp/profile"_compute_temp_profile.html
-"compute temp/ramp"_compute_temp_ramp.html
-"compute temp/region"_compute_temp_region.html :ul
-
-All but the first 3 calculate velocity biases directly (e.g. advection
-velocities) that are removed when computing the thermal temperature.
-"Compute temp/sphere"_compute_temp_sphere.html and "compute
-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, another temperature compute that subtracts a velocity bias.
-This allows the translational velocity of spherical or aspherical
-particles to be adjusted in prescribed ways.
-
-Thermostatting in LAMMPS is performed by "fixes"_fix.html, or in one
-case by a pair style. Several thermostatting fixes are available:
-Nose-Hoover (nvt), Berendsen, CSVR, Langevin, and direct rescaling
-(temp/rescale). Dissipative particle dynamics (DPD) thermostatting
-can be invoked via the {dpd/tstat} pair style:
-
-"fix nvt"_fix_nh.html
-"fix nvt/sphere"_fix_nvt_sphere.html
-"fix nvt/asphere"_fix_nvt_asphere.html
-"fix nvt/sllod"_fix_nvt_sllod.html
-"fix temp/berendsen"_fix_temp_berendsen.html
-"fix temp/csvr"_fix_temp_csvr.html
-"fix langevin"_fix_langevin.html
-"fix temp/rescale"_fix_temp_rescale.html
-"pair_style dpd/tstat"_pair_dpd.html :ul
-
-"Fix nvt"_fix_nh.html only thermostats the translational velocity of
-particles. "Fix nvt/sllod"_fix_nvt_sllod.html also does this, except
-that it subtracts out a velocity bias due to a deforming box and
-integrates the SLLOD equations of motion. See the "NEMD
-simulations"_#howto_13 section of this page for further details. "Fix
-nvt/sphere"_fix_nvt_sphere.html and "fix
-nvt/asphere"_fix_nvt_asphere.html thermostat not only translation
-velocities but also rotational velocities for spherical and aspherical
-particles.
-
-DPD thermostatting alters pairwise interactions in a manner analogous
-to the per-particle thermostatting of "fix
-langevin"_fix_langevin.html.
-
-Any of the thermostatting fixes can use temperature computes that
-remove bias which has two effects. First, the current calculated
-temperature, which is compared to the requested target temperature, is
-calculated with the velocity bias removed. Second, the thermostat
-adjusts only the thermal temperature component of the particle's
-velocities, which are the velocities with the bias removed. The
-removed bias is then added back to the adjusted velocities. See the
-doc pages for the individual fixes and for the
-"fix_modify"_fix_modify.html command for instructions on how to assign
-a temperature compute to a thermostatting fix. For example, you can
-apply a thermostat to only the x and z components of velocity by using
-it in conjunction with "compute
-temp/partial"_compute_temp_partial.html. Of you could thermostat only
-the thermal temperature of a streaming flow of particles without
-affecting the streaming velocity, by using "compute
-temp/profile"_compute_temp_profile.html.
-
-NOTE: Only the nvt fixes perform time integration, meaning they update
-the velocities and positions of particles due to forces and velocities
-respectively. The other thermostat fixes only adjust velocities; they
-do NOT perform time integration updates. Thus they should be used in
-conjunction with a constant NVE integration fix such as these:
-
-"fix nve"_fix_nve.html
-"fix nve/sphere"_fix_nve_sphere.html
-"fix nve/asphere"_fix_nve_asphere.html :ul
-
-Barostatting in LAMMPS is also performed by "fixes"_fix.html. Two
-barosttating methods are currently available: Nose-Hoover (npt and
-nph) and Berendsen:
-
-"fix npt"_fix_nh.html
-"fix npt/sphere"_fix_npt_sphere.html
-"fix npt/asphere"_fix_npt_asphere.html
-"fix nph"_fix_nh.html
-"fix press/berendsen"_fix_press_berendsen.html :ul
-
-The "fix npt"_fix_nh.html commands include a Nose-Hoover thermostat
-and barostat. "Fix nph"_fix_nh.html is just a Nose/Hoover barostat;
-it does no thermostatting. Both "fix nph"_fix_nh.html and "fix
-press/berendsen"_fix_press_berendsen.html can be used in conjunction
-with any of the thermostatting fixes.
-
-As with the thermostats, "fix npt"_fix_nh.html and "fix
-nph"_fix_nh.html only use translational motion of the particles in
-computing T and P and performing thermo/barostatting. "Fix
-npt/sphere"_fix_npt_sphere.html and "fix
-npt/asphere"_fix_npt_asphere.html thermo/barostat using not only
-translation velocities but also rotational velocities for spherical
-and aspherical particles.
-
-All of the barostatting fixes use the "compute
-pressure"_compute_pressure.html compute to calculate a current
-pressure. By default, this compute is created with a simple "compute
-temp"_compute_temp.html (see the last argument of the "compute
-pressure"_compute_pressure.html command), which is used to calculated
-the kinetic component of the pressure. The barostatting fixes can
-also use temperature computes that remove bias for the purpose of
-computing the kinetic component which contributes to the current
-pressure. See the doc pages for the individual fixes and for the
-"fix_modify"_fix_modify.html command for instructions on how to assign
-a temperature or pressure compute to a barostatting fix.
-
-NOTE: As with the thermostats, the Nose/Hoover methods ("fix
-npt"_fix_nh.html and "fix nph"_fix_nh.html) perform time integration.
-"Fix press/berendsen"_fix_press_berendsen.html does NOT, so it should
-be used with one of the constant NVE fixes or with one of the NVT
-fixes.
-
-Finally, thermodynamic output, which can be setup via the
-"thermo_style"_thermo_style.html command, often includes temperature
-and pressure values. As explained on the doc page for the
-"thermo_style"_thermo_style.html command, the default T and P are
-setup by the thermo command itself. They are NOT the ones associated
-with any thermostatting or barostatting fix you have defined or with
-any compute that calculates a temperature or pressure. Thus if you
-want to view these values of T and P, you need to specify them
-explicitly via a "thermo_style custom"_thermo_style.html command. Or
-you can use the "thermo_modify"_thermo_modify.html command to
-re-define what temperature or pressure compute is used for default
-thermodynamic output.
-
-:line
-
-6.17 Walls :link(howto_17),h4
-
-Walls in an MD simulation are typically used to bound particle motion,
-i.e. to serve as a boundary condition.
-
-Walls in LAMMPS can be of rough (made of particles) or idealized
-surfaces. Ideal walls can be smooth, generating forces only in the
-normal direction, or frictional, generating forces also in the
-tangential direction.
-
-Rough walls, built of particles, can be created in various ways. The
-particles themselves can be generated like any other particle, via the
-"lattice"_lattice.html and "create_atoms"_create_atoms.html commands,
-or read in via the "read_data"_read_data.html command.
-
-Their motion can be constrained by many different commands, so that
-they do not move at all, move together as a group at constant velocity
-or in response to a net force acting on them, move in a prescribed
-fashion (e.g. rotate around a point), etc. Note that if a time
-integration fix like "fix nve"_fix_nve.html or "fix nvt"_fix_nh.html
-is not used with the group that contains wall particles, their
-positions and velocities will not be updated.
-
-"fix aveforce"_fix_aveforce.html - set force on particles to average value, so they move together
-"fix setforce"_fix_setforce.html - set force on particles to a value, e.g. 0.0
-"fix freeze"_fix_freeze.html - freeze particles for use as granular walls
-"fix nve/noforce"_fix_nve_noforce.html - advect particles by their velocity, but without force
-"fix move"_fix_move.html - prescribe motion of particles by a linear velocity, oscillation, rotation, variable :ul
-
-The "fix move"_fix_move.html command offers the most generality, since
-the motion of individual particles can be specified with
-"variable"_variable.html formula which depends on time and/or the
-particle position.
-
-For rough walls, it may be useful to turn off pairwise interactions
-between wall particles via the "neigh_modify
-exclude"_neigh_modify.html command.
-
-Rough walls can also be created by specifying frozen particles that do
-not move and do not interact with mobile particles, and then tethering
-other particles to the fixed particles, via a "bond"_bond_style.html.
-The bonded particles do interact with other mobile particles.
-
-Idealized walls can be specified via several fix commands. "Fix
-wall/gran"_fix_wall_gran.html creates frictional walls for use with
-granular particles; all the other commands create smooth walls.
-
-"fix wall/reflect"_fix_wall_reflect.html - reflective flat walls
-"fix wall/lj93"_fix_wall.html - flat walls, with Lennard-Jones 9/3 potential
-"fix wall/lj126"_fix_wall.html - flat walls, with Lennard-Jones 12/6 potential
-"fix wall/colloid"_fix_wall.html - flat walls, with "pair_style colloid"_pair_colloid.html potential
-"fix wall/harmonic"_fix_wall.html - flat walls, with repulsive harmonic spring potential
-"fix wall/region"_fix_wall_region.html - use region surface as wall
-"fix wall/gran"_fix_wall_gran.html - flat or curved walls with "pair_style granular"_pair_gran.html potential :ul
-
-The {lj93}, {lj126}, {colloid}, and {harmonic} styles all allow the
-flat walls to move with a constant velocity, or oscillate in time.
-The "fix wall/region"_fix_wall_region.html command offers the most
-generality, since the region surface is treated as a wall, and the
-geometry of the region can be a simple primitive volume (e.g. a
-sphere, or cube, or plane), or a complex volume made from the union
-and intersection of primitive volumes. "Regions"_region.html can also
-specify a volume "interior" or "exterior" to the specified primitive
-shape or {union} or {intersection}. "Regions"_region.html can also be
-"dynamic" meaning they move with constant velocity, oscillate, or
-rotate.
-
-The only frictional idealized walls currently in LAMMPS are flat or
-curved surfaces specified by the "fix wall/gran"_fix_wall_gran.html
-command. At some point we plan to allow regoin surfaces to be used as
-frictional walls, as well as triangulated surfaces.
-
-:line
-
-6.18 Elastic constants :link(howto_18),h4
-
-Elastic constants characterize the stiffness of a material. The formal
-definition is provided by the linear relation that holds between the
-stress and strain tensors in the limit of infinitesimal deformation.
-In tensor notation, this is expressed as s_ij = C_ijkl * e_kl, where
-the repeated indices imply summation. s_ij are the elements of the
-symmetric stress tensor. e_kl are the elements of the symmetric strain
-tensor. C_ijkl are the elements of the fourth rank tensor of elastic
-constants. In three dimensions, this tensor has 3^4=81 elements. Using
-Voigt notation, the tensor can be written as a 6x6 matrix, where C_ij
-is now the derivative of s_i w.r.t. e_j. Because s_i is itself a
-derivative w.r.t. e_i, it follows that C_ij is also symmetric, with at
-most 7*6/2 = 21 distinct elements.
-
-At zero temperature, it is easy to estimate these derivatives by
-deforming the simulation box in one of the six directions using the
-"change_box"_change_box.html command and measuring the change in the
-stress tensor. A general-purpose script that does this is given in the
-examples/elastic directory described in "this
-section"_Section_example.html.
-
-Calculating elastic constants at finite temperature is more
-challenging, because it is necessary to run a simulation that perfoms
-time averages of differential properties. One way to do this is to
-measure the change in average stress tensor in an NVT simulations when
-the cell volume undergoes a finite deformation. In order to balance
-the systematic and statistical errors in this method, the magnitude of
-the deformation must be chosen judiciously, and care must be taken to
-fully equilibrate the deformed cell before sampling the stress
-tensor. Another approach is to sample the triclinic cell fluctuations
-that occur in an NPT simulation. This method can also be slow to
-converge and requires careful post-processing "(Shinoda)"_#Shinoda1
-
-:line
-
-6.19 Library interface to LAMMPS :link(howto_19),h4
-
-As described in "Section 2.5"_Section_start.html#start_5, LAMMPS
-can be built as a library, so that it can be called by another code,
-used in a "coupled manner"_Section_howto.html#howto_10 with other
-codes, or driven through a "Python interface"_Section_python.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
-functions therein have a C-style argument list, but contain C++ code
-you could write yourself in a C++ application that was invoking LAMMPS
-directly. The C++ code in the functions illustrates how to invoke
-internal LAMMPS operations. Note that LAMMPS classes are defined
-within a LAMMPS namespace (LAMMPS_NS) if you use them from another C++
-application.
-
-The examples/COUPLE and python/examples directories have example C++
-and C and Python codes which show how a driver code can link to LAMMPS
-as a library, run LAMMPS on a subset of processors, grab data from
-LAMMPS, change it, and put it back into LAMMPS.
-
-The file src/library.cpp contains the following functions for creating
-and destroying an instance of LAMMPS and sending it commands to
-execute. See the documentation in the src/library.cpp file for
-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"_Section_python.html. The added functions can access or
-change any internal LAMMPS data you wish.
-
-void lammps_open(int, char **, MPI_Comm, void **)
-void lammps_open_no_mpi(int, char **, void **)
-void lammps_close(void *)
-int lammps_version(void *)
-void lammps_file(void *, char *)
-char *lammps_command(void *, char *)
-void lammps_commands_list(void *, int, char **)
-void lammps_commands_string(void *, char *)
-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
-stand-alone mode from the command line, and a MPI communicator for
-LAMMPS to run under. It returns a ptr to the LAMMPS object that is
-created, and which is used in subsequent library calls. The
-lammps_open() function can be called multiple times, to create
-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
-processors. For example, a wrapper script might decide to alternate
-between LAMMPS and another code, allowing them both to run on all the
-processors. Or it might allocate half the processors to LAMMPS and
-half to the other code and run both codes simultaneously before
-syncing them up periodically. Or it might instantiate multiple
-instances of LAMMPS to perform different calculations.
-
-The lammps_open_no_mpi() function is similar except that no MPI
-communicator is passed from the caller. Instead, MPI_COMM_WORLD is
-used to instantiate LAMMPS, and MPI is initialized if necessary.
-
-The lammps_close() function is used to shut down an instance of LAMMPS
-and free all its memory.
-
-The lammps_version() function can be used to determined the specific
-version of the underlying LAMMPS code. This is particularly useful
-when loading LAMMPS as a shared library via dlopen(). The code using
-the library interface can than use this information to adapt to
-changes to the LAMMPS command syntax between versions. The returned
-LAMMPS version code is an integer (e.g. 2 Sep 2015 results in
-20150902) that grows with every new LAMMPS version.
-
-The lammps_file(), lammps_command(), lammps_commands_list(), and
-lammps_commands_string() functions are used to pass one or more
-commands to LAMMPS to execute, the same as if they were coming from an
-input script.
-
-Via these functions, the calling code can read or generate a series of
-LAMMPS commands one or multiple at a time and pass it thru the library
-interface to setup a problem and then run it in stages. The caller
-can interleave the command function calls with operations it performs,
-calls to extract information from or set information within LAMMPS, or
-calls to another code's library.
-
-The lammps_file() function passes the filename of an input script.
-The lammps_command() function passes a single command as a string.
-The lammps_commands_list() function passes multiple commands in a
-char** list. In both lammps_command() and lammps_commands_list(),
-individual commands may or may not have a trailing newline. The
-lammps_commands_string() function passes multiple commands
-concatenated into one long string, separated by newline characters.
-In both lammps_commands_list() and lammps_commands_string(), a single
-command can be spread across multiple lines, if the last printable
-character of all but the last line is "&", the same as if the lines
-appeared in an input script.
-
-The lammps_free() function is a clean-up function to free memory that
-the library allocated previously via other function calls. See
-comments in src/library.cpp file for which other functions need this
-clean-up.
-
-The file src/library.cpp also contains these functions for extracting
-information from LAMMPS and setting value within LAMMPS. Again, see
-the documentation in the src/library.cpp file for details, including
-which quantities can be queried by name:
-
-int lammps_extract_setting(void *, char *)
-void *lammps_extract_global(void *, char *)
-void lammps_extract_box(void *, double *, double *,
- double *, double *, double *, int *, int *)
-void *lammps_extract_atom(void *, char *)
-void *lammps_extract_compute(void *, char *, int, int)
-void *lammps_extract_fix(void *, char *, int, int, int, int)
-void *lammps_extract_variable(void *, char *, char *) :pre
-
-The extract_setting() function returns info on the size
-of data types (e.g. 32-bit or 64-bit atom IDs) used
-by the LAMMPS executable (a compile-time choice).
-
-The other extract functions return a pointer to various global or
-per-atom quantities stored in LAMMPS or to values calculated by a
-compute, fix, or variable. The pointer returned by the
-extract_global() function can be used as a permanent reference to a
-value which may change. For the extract_atom() method, see the
-extract() method in the src/atom.cpp file for a list of valid per-atom
-properties. New names could easily be added if the property you want
-is not listed. For the other extract functions, the underlying
-storage may be reallocated as LAMMPS runs, so you need to re-call the
-function to assure a current pointer or returned value(s).
-
-double lammps_get_thermo(void *, char *)
-int lammps_get_natoms(void *) :pre
-
-int lammps_set_variable(void *, char *, char *)
-void lammps_reset_box(void *, double *, double *, double, double, double) :pre
-
-The lammps_get_thermo() function returns the current value of a thermo
-keyword as a double precision value.
-
-The lammps_get_natoms() function returns the total number of atoms in
-the system and can be used by the caller to allocate memory for the
-lammps_gather_atoms() and lammps_scatter_atoms() functions.
-
-The lammps_set_variable() function can set an existing string-style
-variable to a new string value, so that subsequent LAMMPS commands can
-access the variable.
-
-The lammps_reset_box() function resets the size and shape of the
-simulation box, e.g. as part of restoring a previously extracted and
-saved state of a simulation.
-
-void lammps_gather_atoms(void *, char *, int, int, void *)
-void lammps_gather_atoms_concat(void *, char *, int, int, void *)
-void lammps_gather_atoms_subset(void *, char *, int, int, int, int *, void *)
-void lammps_scatter_atoms(void *, char *, int, int, void *)
-void lammps_scatter_atoms_subset(void *, char *, int, int, int, int *, void *) :pre
-
-void lammps_create_atoms(void *, int, tagint *, int *, double *, double *,
- imageint *, int) :pre
-
-The gather functions collect peratom info of the requested type (atom
-coords, atom types, forces, etc) from all processors, and returns the
-same vector of values to each callling processor. The scatter
-functions do the inverse. They distribute a vector of peratom values,
-passed by all calling processors, to invididual atoms, which may be
-owned by different processos.
-
-The lammps_gather_atoms() function does this for all N atoms in the
-system, ordered by atom ID, from 1 to N. The
-lammps_gather_atoms_concat() function does it for all N atoms, but
-simply concatenates the subset of atoms owned by each processor. The
-resulting vector is not ordered by atom ID. Atom IDs can be requetsed
-by the same function if the caller needs to know the ordering. The
-lammps_gather_subset() function allows the caller to request values
-for only a subset of atoms (identified by ID).
-For all 3 gather function, per-atom image flags can be retrieved in 2 ways.
-If the count is specified as 1, they are returned
-in a packed format with all three image flags stored in a single integer.
-If the count is specified as 3, the values are unpacked into xyz flags
-by the library before returning them.
-
-The lammps_scatter_atoms() function takes a list of values for all N
-atoms in the system, ordered by atom ID, from 1 to N, and assigns
-those values to each atom in the system. The
-lammps_scatter_atoms_subset() function takes a subset of IDs as an
-argument and only scatters those values to the owning atoms.
-
-The lammps_create_atoms() function takes a list of N atoms as input
-with atom types and coords (required), an optionally atom IDs and
-velocities and image flags. It uses the coords of each atom to assign
-it as a new atom to the processor that owns it. This function is
-useful to add atoms to a simulation or (in tandem with
-lammps_reset_box()) to restore a previously extracted and saved state
-of a simulation. Additional properties for the new atoms can then be
-assigned via the lammps_scatter_atoms() or lammps_extract_atom()
-functions.
-
-:line
-
-6.20 Calculating thermal conductivity :link(howto_20),h4
-
-The thermal conductivity kappa of a material can be measured in at
-least 4 ways using various options in LAMMPS. See the examples/KAPPA
-directory for scripts that implement the 4 methods discussed here for
-a simple Lennard-Jones fluid model. Also, see "this
-section"_Section_howto.html#howto_21 of the manual for an analogous
-discussion for viscosity.
-
-The thermal conductivity tensor kappa is a measure of the propensity
-of a material to transmit heat energy in a diffusive manner as given
-by Fourier's law
-
-J = -kappa grad(T)
-
-where J is the heat flux in units of energy per area per time and
-grad(T) is the spatial gradient of temperature. The thermal
-conductivity thus has units of energy per distance per time per degree
-K and is often approximated as an isotropic quantity, i.e. as a
-scalar.
-
-The first method is to setup two thermostatted regions at opposite
-ends of a simulation box, or one in the middle and one at the end of a
-periodic box. By holding the two regions at different temperatures
-with a "thermostatting fix"_Section_howto.html#howto_13, the energy
-added to the hot region should equal the energy subtracted from the
-cold region and be proportional to the heat flux moving between the
-regions. See the papers by "Ikeshoji and Hafskjold"_#howto-Ikeshoji
-and "Wirnsberger et al"_#howto-Wirnsberger for details of this idea.
-Note that thermostatting fixes such as "fix nvt"_fix_nh.html, "fix
-langevin"_fix_langevin.html, and "fix
-temp/rescale"_fix_temp_rescale.html store the cumulative energy they
-add/subtract.
-
-Alternatively, as a second method, the "fix heat"_fix_heat.html or
-"fix ehex"_fix_ehex.html commands can be used in place of thermostats
-on each of two regions to add/subtract specified amounts of energy to
-both regions. In both cases, the resulting temperatures of the two
-regions can be monitored with the "compute temp/region" command and
-the temperature profile of the intermediate region can be monitored
-with the "fix ave/chunk"_fix_ave_chunk.html and "compute
-ke/atom"_compute_ke_atom.html commands.
-
-The third method is to perform a reverse non-equilibrium MD simulation
-using the "fix thermal/conductivity"_fix_thermal_conductivity.html
-command which implements the rNEMD algorithm of Muller-Plathe.
-Kinetic energy is swapped between atoms in two different layers of the
-simulation box. This induces a temperature gradient between the two
-layers which can be monitored with the "fix
-ave/chunk"_fix_ave_chunk.html and "compute
-ke/atom"_compute_ke_atom.html commands. The fix tallies the
-cumulative energy transfer that it performs. See the "fix
-thermal/conductivity"_fix_thermal_conductivity.html command for
-details.
-
-The fourth method is based on the Green-Kubo (GK) formula which
-relates the ensemble average of the auto-correlation of the heat flux
-to kappa. The heat flux can be calculated from the fluctuations of
-per-atom potential and kinetic energies and per-atom stress tensor in
-a steady-state equilibrated simulation. This is in contrast to the
-two preceding non-equilibrium methods, where energy flows continuously
-between hot and cold regions of the simulation box.
-
-The "compute heat/flux"_compute_heat_flux.html command can calculate
-the needed heat flux and describes how to implement the Green_Kubo
-formalism using additional LAMMPS commands, such as the "fix
-ave/correlate"_fix_ave_correlate.html command to calculate the needed
-auto-correlation. See the doc page for the "compute
-heat/flux"_compute_heat_flux.html command for an example input script
-that calculates the thermal conductivity of solid Ar via the GK
-formalism.
-
-:line
-
-6.21 Calculating viscosity :link(howto_21),h4
-
-The shear viscosity eta of a fluid can be measured in at least 5 ways
-using various options in LAMMPS. See the examples/VISCOSITY directory
-for scripts that implement the 5 methods discussed here for a simple
-Lennard-Jones fluid model. Also, see "this
-section"_Section_howto.html#howto_20 of the manual for an analogous
-discussion for thermal conductivity.
-
-Eta is a measure of the propensity of a fluid to transmit momentum in
-a direction perpendicular to the direction of velocity or momentum
-flow. Alternatively it is the resistance the fluid has to being
-sheared. It is given by
-
-J = -eta grad(Vstream)
-
-where J is the momentum flux in units of momentum per area per time.
-and grad(Vstream) is the spatial gradient of the velocity of the fluid
-moving in another direction, normal to the area through which the
-momentum flows. Viscosity thus has units of pressure-time.
-
-The first method is to perform a non-equilibrium MD (NEMD) simulation
-by shearing the simulation box via the "fix deform"_fix_deform.html
-command, and using the "fix nvt/sllod"_fix_nvt_sllod.html command to
-thermostat the fluid via the SLLOD equations of motion.
-Alternatively, as a second method, one or more moving walls can be
-used to shear the fluid in between them, again with some kind of
-thermostat that modifies only the thermal (non-shearing) components of
-velocity to prevent the fluid from heating up.
-
-In both cases, the velocity profile setup in the fluid by this
-procedure can be monitored by the "fix
-ave/chunk"_fix_ave_chunk.html command, which determines
-grad(Vstream) in the equation above. E.g. the derivative in the
-y-direction of the Vx component of fluid motion or grad(Vstream) =
-dVx/dy. The Pxy off-diagonal component of the pressure or stress
-tensor, as calculated by the "compute pressure"_compute_pressure.html
-command, can also be monitored, which is the J term in the equation
-above. See "this section"_Section_howto.html#howto_13 of the manual
-for details on NEMD simulations.
-
-The third method is to perform a reverse non-equilibrium MD simulation
-using the "fix viscosity"_fix_viscosity.html command which implements
-the rNEMD algorithm of Muller-Plathe. Momentum in one dimension is
-swapped between atoms in two different layers of the simulation box in
-a different dimension. This induces a velocity gradient which can be
-monitored with the "fix ave/chunk"_fix_ave_chunk.html command.
-The fix tallies the cumulative momentum transfer that it performs.
-See the "fix viscosity"_fix_viscosity.html command for details.
-
-The fourth method is based on the Green-Kubo (GK) formula which
-relates the ensemble average of the auto-correlation of the
-stress/pressure tensor to eta. This can be done in a fully
-equilibrated simulation which is in contrast to the two preceding
-non-equilibrium methods, where momentum flows continuously through the
-simulation box.
-
-Here is an example input script that calculates the viscosity of
-liquid Ar via the GK formalism:
-
-# Sample LAMMPS input script for viscosity of liquid Ar :pre
-
-units real
-variable T equal 86.4956
-variable V equal vol
-variable dt equal 4.0
-variable p equal 400 # correlation length
-variable s equal 5 # sample interval
-variable d equal $p*$s # dump interval :pre
-
-# convert from LAMMPS real units to SI :pre
-
-variable kB equal 1.3806504e-23 # \[J/K/] Boltzmann
-variable atm2Pa equal 101325.0
-variable A2m equal 1.0e-10
-variable fs2s equal 1.0e-15
-variable convert equal $\{atm2Pa\}*$\{atm2Pa\}*$\{fs2s\}*$\{A2m\}*$\{A2m\}*$\{A2m\} :pre
-
-# setup problem :pre
-
-dimension 3
-boundary p p p
-lattice fcc 5.376 orient x 1 0 0 orient y 0 1 0 orient z 0 0 1
-region box block 0 4 0 4 0 4
-create_box 1 box
-create_atoms 1 box
-mass 1 39.948
-pair_style lj/cut 13.0
-pair_coeff * * 0.2381 3.405
-timestep $\{dt\}
-thermo $d :pre
-
-# equilibration and thermalization :pre
-
-velocity all create $T 102486 mom yes rot yes dist gaussian
-fix NVT all nvt temp $T $T 10 drag 0.2
-run 8000 :pre
-
-# viscosity calculation, switch to NVE if desired :pre
-
-#unfix NVT
-#fix NVE all nve :pre
-
-reset_timestep 0
-variable pxy equal pxy
-variable pxz equal pxz
-variable pyz equal pyz
-fix SS all ave/correlate $s $p $d &
- v_pxy v_pxz v_pyz type auto file S0St.dat ave running
-variable scale equal $\{convert\}/($\{kB\}*$T)*$V*$s*$\{dt\}
-variable v11 equal trap(f_SS\[3\])*$\{scale\}
-variable v22 equal trap(f_SS\[4\])*$\{scale\}
-variable v33 equal trap(f_SS\[5\])*$\{scale\}
-thermo_style custom step temp press v_pxy v_pxz v_pyz v_v11 v_v22 v_v33
-run 100000
-variable v equal (v_v11+v_v22+v_v33)/3.0
-variable ndens equal count(all)/vol
-print "average viscosity: $v \[Pa.s\] @ $T K, $\{ndens\} /A^3" :pre
-
-The fifth method is related to the above Green-Kubo method,
-but uses the Einstein formulation, analogous to the Einstein
-mean-square-displacement formulation for self-diffusivity. The
-time-integrated momentum fluxes play the role of Cartesian
-coordinates, whose mean-square displacement increases linearly
-with time at sufficiently long times.
-
-:line
-
-6.22 Calculating a diffusion coefficient :link(howto_22),h4
-
-The diffusion coefficient D of a material can be measured in at least
-2 ways using various options in LAMMPS. See the examples/DIFFUSE
-directory for scripts that implement the 2 methods discussed here for
-a simple Lennard-Jones fluid model.
-
-The first method is to measure the mean-squared displacement (MSD) of
-the system, via the "compute msd"_compute_msd.html command. The slope
-of the MSD versus time is proportional to the diffusion coefficient.
-The instantaneous MSD values can be accumulated in a vector via the
-"fix vector"_fix_vector.html command, and a line fit to the vector to
-compute its slope via the "variable slope"_variable.html function, and
-thus extract D.
-
-The second method is to measure the velocity auto-correlation function
-(VACF) of the system, via the "compute vacf"_compute_vacf.html
-command. The time-integral of the VACF is proportional to the
-diffusion coefficient. The instantaneous VACF values can be
-accumulated in a vector via the "fix vector"_fix_vector.html command,
-and time integrated via the "variable trap"_variable.html function,
-and thus extract D.
-
-:line
-
-6.23 Using chunks to calculate system properties :link(howto_23),h4
-
-In LAMMS, "chunks" are collections of atoms, as defined by the
-"compute chunk/atom"_compute_chunk_atom.html command, which assigns
-each atom to a chunk ID (or to no chunk at all). The number of chunks
-and the assignment of chunk IDs to atoms can be static or change over
-time. Examples of "chunks" are molecules or spatial bins or atoms
-with similar values (e.g. coordination number or potential energy).
-
-The per-atom chunk IDs can be used as input to two other kinds of
-commands, to calculate various properties of a system:
-
-"fix ave/chunk"_fix_ave_chunk.html
-any of the "compute */chunk"_compute.html commands :ul
-
-Here, each of the 3 kinds of chunk-related commands is briefly
-overviewed. Then some examples are given of how to compute different
-properties with chunk commands.
-
-Compute chunk/atom command: :h4
-
-This compute can assign atoms to chunks of various styles. Only atoms
-in the specified group and optional specified region are assigned to a
-chunk. Here are some possible chunk definitions:
-
-atoms in same molecule | chunk ID = molecule ID |
-atoms of same atom type | chunk ID = atom type |
-all atoms with same atom property (charge, radius, etc) | chunk ID = output of compute property/atom |
-atoms in same cluster | chunk ID = output of "compute cluster/atom"_compute_cluster_atom.html command |
-atoms in same spatial bin | chunk ID = bin ID |
-atoms in same rigid body | chunk ID = molecule ID used to define rigid bodies |
-atoms with similar potential energy | chunk ID = output of "compute pe/atom"_compute_pe_atom.html |
-atoms with same local defect structure | chunk ID = output of "compute centro/atom"_compute_centro_atom.html or "compute coord/atom"_compute_coord_atom.html command :tb(s=|,c=2)
-
-Note that chunk IDs are integer values, so for atom properties or
-computes that produce a floating point value, they will be truncated
-to an integer. You could also use the compute in a variable that
-scales the floating point value to spread it across multiple integers.
-
-Spatial bins can be of various kinds, e.g. 1d bins = slabs, 2d bins =
-pencils, 3d bins = boxes, spherical bins, cylindrical bins.
-
-This compute also calculates the number of chunks {Nchunk}, which is
-used by other commands to tally per-chunk data. {Nchunk} can be a
-static value or change over time (e.g. the number of clusters). The
-chunk ID for an individual atom can also be static (e.g. a molecule
-ID), or dynamic (e.g. what spatial bin an atom is in as it moves).
-
-Note that this compute allows the per-atom output of other
-"computes"_compute.html, "fixes"_fix.html, and
-"variables"_variable.html to be used to define chunk IDs for each
-atom. This means you can write your own compute or fix to output a
-per-atom quantity to use as chunk ID. See
-"Section 10"_Section_modify.html of the documentation for how to
-do this. You can also define a "per-atom variable"_variable.html in
-the input script that uses a formula to generate a chunk ID for each
-atom.
-
-Fix ave/chunk command: :h4
-
-This fix takes the ID of a "compute
-chunk/atom"_compute_chunk_atom.html command as input. For each chunk,
-it then sums one or more specified per-atom values over the atoms in
-each chunk. The per-atom values can be any atom property, such as
-velocity, force, charge, potential energy, kinetic energy, stress,
-etc. Additional keywords are defined for per-chunk properties like
-density and temperature. More generally any per-atom value generated
-by other "computes"_compute.html, "fixes"_fix.html, and "per-atom
-variables"_variable.html, can be summed over atoms in each chunk.
-
-Similar to other averaging fixes, this fix allows the summed per-chunk
-values to be time-averaged in various ways, and output to a file. The
-fix produces a global array as output with one row of values per
-chunk.
-
-Compute */chunk commands: :h4
-
-Currently the following computes operate on chunks of atoms to produce
-per-chunk values.
-
-"compute com/chunk"_compute_com_chunk.html
-"compute gyration/chunk"_compute_gyration_chunk.html
-"compute inertia/chunk"_compute_inertia_chunk.html
-"compute msd/chunk"_compute_msd_chunk.html
-"compute property/chunk"_compute_property_chunk.html
-"compute temp/chunk"_compute_temp_chunk.html
-"compute torque/chunk"_compute_vcm_chunk.html
-"compute vcm/chunk"_compute_vcm_chunk.html :ul
-
-They each take the ID of a "compute
-chunk/atom"_compute_chunk_atom.html command as input. As their names
-indicate, they calculate the center-of-mass, radius of gyration,
-moments of inertia, mean-squared displacement, temperature, torque,
-and velocity of center-of-mass for each chunk of atoms. The "compute
-property/chunk"_compute_property_chunk.html command can tally the
-count of atoms in each chunk and extract other per-chunk properties.
-
-The reason these various calculations are not part of the "fix
-ave/chunk command"_fix_ave_chunk.html, is that each requires a more
-complicated operation than simply summing and averaging over per-atom
-values in each chunk. For example, many of them require calculation
-of a center of mass, which requires summing mass*position over the
-atoms and then dividing by summed mass.
-
-All of these computes produce a global vector or global array as
-output, wih one or more values per chunk. They can be used
-in various ways:
-
-As input to the "fix ave/time"_fix_ave_time.html command, which can
-write the values to a file and optionally time average them. :ulb,l
-
-As input to the "fix ave/histo"_fix_ave_histo.html command to
-histogram values across chunks. E.g. a histogram of cluster sizes or
-molecule diffusion rates. :l
-
-As input to special functions of "equal-style
-variables"_variable.html, like sum() and max(). E.g. to find the
-largest cluster or fastest diffusing molecule. :l
-:ule
-
-Example calculations with chunks :h4
-
-Here are examples using chunk commands to calculate various
-properties:
-
-(1) Average velocity in each of 1000 2d spatial bins:
-
-compute cc1 all chunk/atom bin/2d x 0.0 0.1 y lower 0.01 units reduced
-fix 1 all ave/chunk 100 10 1000 cc1 vx vy file tmp.out :pre
-
-(2) Temperature in each spatial bin, after subtracting a flow
-velocity:
-
-compute cc1 all chunk/atom bin/2d x 0.0 0.1 y lower 0.1 units reduced
-compute vbias all temp/profile 1 0 0 y 10
-fix 1 all ave/chunk 100 10 1000 cc1 temp bias vbias file tmp.out :pre
-
-(3) Center of mass of each molecule:
-
-compute cc1 all chunk/atom molecule
-compute myChunk all com/chunk cc1
-fix 1 all ave/time 100 1 100 c_myChunk\[*\] file tmp.out mode vector :pre
-
-(4) Total force on each molecule and ave/max across all molecules:
-
-compute cc1 all chunk/atom molecule
-fix 1 all ave/chunk 1000 1 1000 cc1 fx fy fz file tmp.out
-variable xave equal ave(f_1\[2\])
-variable xmax equal max(f_1\[2\])
-thermo 1000
-thermo_style custom step temp v_xave v_xmax :pre
-
-(5) Histogram of cluster sizes:
-
-compute cluster all cluster/atom 1.0
-compute cc1 all chunk/atom c_cluster compress yes
-compute size all property/chunk cc1 count
-fix 1 all ave/histo 100 1 100 0 20 20 c_size mode vector ave running beyond ignore file tmp.histo :pre
-
-:line
-
-6.24 Setting parameters for the "kspace_style pppm/disp"_kspace_style.html command :link(howto_24),h4
-
-The PPPM method computes interactions by splitting the pair potential
-into two parts, one of which is computed in a normal pairwise fashion,
-the so-called real-space part, and one of which is computed using the
-Fourier transform, the so called reciprocal-space or kspace part. For
-both parts, the potential is not computed exactly but is approximated.
-Thus, there is an error in both parts of the computation, the
-real-space and the kspace error. The just mentioned facts are true
-both for the PPPM for Coulomb as well as dispersion interactions. The
-deciding difference - and also the reason why the parameters for
-pppm/disp have to be selected with more care - is the impact of the
-errors on the results: The kspace error of the PPPM for Coulomb and
-dispersion interaction and the real-space error of the PPPM for
-Coulomb interaction have the character of noise. In contrast, the
-real-space error of the PPPM for dispersion has a clear physical
-interpretation: the underprediction of cohesion. As a consequence, the
-real-space error has a much stronger effect than the kspace error on
-simulation results for pppm/disp. Parameters must thus be chosen in a
-way that this error is much smaller than the kspace error.
-
-When using pppm/disp and not making any specifications on the PPPM
-parameters via the kspace modify command, parameters will be tuned
-such that the real-space error and the kspace error are equal. This
-will result in simulations that are either inaccurate or slow, both of
-which is not desirable. For selecting parameters for the pppm/disp
-that provide fast and accurate simulations, there are two approaches,
-which both have their up- and downsides.
-
-The first approach is to set desired real-space an kspace accuracies
-via the {kspace_modify force/disp/real} and {kspace_modify
-force/disp/kspace} commands. Note that the accuracies have to be
-specified in force units and are thus dependent on the chosen unit
-settings. For real units, 0.0001 and 0.002 seem to provide reasonable
-accurate and efficient computations for the real-space and kspace
-accuracies. 0.002 and 0.05 work well for most systems using lj
-units. PPPM parameters will be generated based on the desired
-accuracies. The upside of this approach is that it usually provides a
-good set of parameters and will work for both the {kspace_modify diff
-ad} and {kspace_modify diff ik} options. The downside of the method
-is that setting the PPPM parameters will take some time during the
-initialization of the simulation.
-
-The second approach is to set the parameters for the pppm/disp
-explicitly using the {kspace_modify mesh/disp}, {kspace_modify
-order/disp}, and {kspace_modify gewald/disp} commands. This approach
-requires a more experienced user who understands well the impact of
-the choice of parameters on the simulation accuracy and
-performance. This approach provides a fast initialization of the
-simulation. However, it is sensitive to errors: A combination of
-parameters that will perform well for one system might result in
-far-from-optimal conditions for other simulations. For example,
-parameters that provide accurate and fast computations for
-all-atomistic force fields can provide insufficient accuracy or
-united-atomistic force fields (which is related to that the latter
-typically have larger dispersion coefficients).
-
-To avoid inaccurate or inefficient simulations, the pppm/disp stops
-simulations with an error message if no action is taken to control the
-PPPM parameters. If the automatic parameter generation is desired and
-real-space and kspace accuracies are desired to be equal, this error
-message can be suppressed using the {kspace_modify disp/auto yes}
-command.
-
-A reasonable approach that combines the upsides of both methods is to
-make the first run using the {kspace_modify force/disp/real} and
-{kspace_modify force/disp/kspace} commands, write down the PPPM
-parameters from the outut, and specify these parameters using the
-second approach in subsequent runs (which have the same composition,
-force field, and approximately the same volume).
-
-Concerning the performance of the pppm/disp there are two more things
-to consider. The first is that when using the pppm/disp, the cutoff
-parameter does no longer affect the accuracy of the simulation
-(subject to that gewald/disp is adjusted when changing the cutoff).
-The performance can thus be increased by examining different values
-for the cutoff parameter. A lower bound for the cutoff is only set by
-the truncation error of the repulsive term of pair potentials.
-
-The second is that the mixing rule of the pair style has an impact on
-the computation time when using the pppm/disp. Fastest computations
-are achieved when using the geometric mixing rule. Using the
-arithmetic mixing rule substantially increases the computational cost.
-The computational overhead can be reduced using the {kspace_modify
-mix/disp geom} and {kspace_modify splittol} commands. The first
-command simply enforces geometric mixing of the dispersion
-coefficients in kspace computations. This introduces some error in
-the computations but will also significantly speed-up the
-simulations. The second keyword sets the accuracy with which the
-dispersion coefficients are approximated using a matrix factorization
-approach. This may result in better accuracy then using the first
-command, but will usually also not provide an equally good increase of
-efficiency.
-
-Finally, pppm/disp can also be used when no mixing rules apply.
-This can be achieved using the {kspace_modify mix/disp none} command.
-Note that the code does not check automatically whether any mixing
-rule is fulfilled. If mixing rules do not apply, the user will have
-to specify this command explicitly.
-
-:line
-
-6.25 Polarizable models :link(howto_25),h4
-
-In polarizable force fields the charge distributions in molecules and
-materials respond to their electrostatic environments. Polarizable
-systems can be simulated in LAMMPS using three methods:
-
-the fluctuating charge method, implemented in the "QEQ"_fix_qeq.html
-package, :ulb,l
-the adiabatic core-shell method, implemented in the
-"CORESHELL"_#howto_26 package, :l
-the thermalized Drude dipole method, implemented in the
-"USER-DRUDE"_#howto_27 package. :l
-:ule
-
-The fluctuating charge method calculates instantaneous charges on
-interacting atoms based on the electronegativity equalization
-principle. It is implemented in the "fix qeq"_fix_qeq.html which is
-available in several variants. It is a relatively efficient technique
-since no additional particles are introduced. This method allows for
-charge transfer between molecules or atom groups. However, because the
-charges are located at the interaction sites, off-plane components of
-polarization cannot be represented in planar molecules or atom groups.
-
-The two other methods share the same basic idea: polarizable atoms are
-split into one core atom and one satellite particle (called shell or
-Drude particle) attached to it by a harmonic spring. Both atoms bear
-a charge and they represent collectively an induced electric dipole.
-These techniques are computationally more expensive than the QEq
-method because of additional particles and bonds. These two
-charge-on-spring methods differ in certain features, with the
-core-shell model being normally used for ionic/crystalline materials,
-whereas the so-called Drude model is normally used for molecular
-systems and fluid states.
-
-The core-shell model is applicable to crystalline materials where the
-high symmetry around each site leads to stable trajectories of the
-core-shell pairs. However, bonded atoms in molecules can be so close
-that a core would interact too strongly or even capture the Drude
-particle of a neighbor. The Drude dipole model is relatively more
-complex in order to remediate this and other issues. Specifically, the
-Drude model includes specific thermostating of the core-Drude pairs
-and short-range damping of the induced dipoles.
-
-The three polarization methods can be implemented through a
-self-consistent calculation of charges or induced dipoles at each
-timestep. In the fluctuating charge scheme this is done by the matrix
-inversion method in "fix qeq/point"_fix_qeq.html, but for core-shell
-or Drude-dipoles the relaxed-dipoles technique would require an slow
-iterative procedure. These self-consistent solutions yield accurate
-trajectories since the additional degrees of freedom representing
-polarization are massless. An alternative is to attribute a mass to
-the additional degrees of freedom and perform time integration using
-an extended Lagrangian technique. For the fluctuating charge scheme
-this is done by "fix qeq/dynamic"_fix_qeq.html, and for the
-charge-on-spring models by the methods outlined in the next two
-sections. The assignment of masses to the additional degrees of
-freedom can lead to unphysical trajectories if care is not exerted in
-choosing the parameters of the polarizable models and the simulation
-conditions.
-
-In the core-shell model the vibration of the shells is kept faster
-than the ionic vibrations to mimic the fast response of the
-polarizable electrons. But in molecular systems thermalizing the
-core-Drude pairs at temperatures comparable to the rest of the
-simulation leads to several problems (kinetic energy transfer, too
-short a timestep, etc.) In order to avoid these problems the relative
-motion of the Drude particles with respect to their cores is kept
-"cold" so the vibration of the core-Drude pairs is very slow,
-approaching the self-consistent regime. In both models the
-temperature is regulated using the velocities of the center of mass of
-core+shell (or Drude) pairs, but in the Drude model the actual
-relative core-Drude particle motion is thermostated separately as
-well.
-
-:line
-
-6.26 Adiabatic core/shell model :link(howto_26),h4
-
-The adiabatic core-shell model by "Mitchell and
-Fincham"_#MitchellFincham is a simple method for adding
-polarizability to a system. In order to mimic the electron shell of
-an ion, a satellite particle is attached to it. This way the ions are
-split into a core and a shell where the latter is meant to react to
-the electrostatic environment inducing polarizability.
-
-Technically, shells are attached to the cores by a spring force f =
-k*r where k is a parametrized spring constant and r is the distance
-between the core and the shell. The charges of the core and the shell
-add up to the ion charge, thus q(ion) = q(core) + q(shell). This
-setup introduces the ion polarizability (alpha) given by
-alpha = q(shell)^2 / k. In a
-similar fashion the mass of the ion is distributed on the core and the
-shell with the core having the larger mass.
-
-To run this model in LAMMPS, "atom_style"_atom_style.html {full} can
-be used since atom charge and bonds are needed. Each kind of
-core/shell pair requires two atom types and a bond type. The core and
-shell of a core/shell pair should be bonded to each other with a
-harmonic bond that provides the spring force. For example, a data file
-for NaCl, as found in examples/coreshell, has this format:
-
-432 atoms # core and shell atoms
-216 bonds # number of core/shell springs :pre
-
-4 atom types # 2 cores and 2 shells for Na and Cl
-2 bond types :pre
-
-0.0 24.09597 xlo xhi
-0.0 24.09597 ylo yhi
-0.0 24.09597 zlo zhi :pre
-
-Masses # core/shell mass ratio = 0.1 :pre
-
-1 20.690784 # Na core
-2 31.90500 # Cl core
-3 2.298976 # Na shell
-4 3.54500 # Cl shell :pre
-
-Atoms :pre
-
-1 1 2 1.5005 0.00000000 0.00000000 0.00000000 # core of core/shell pair 1
-2 1 4 -2.5005 0.00000000 0.00000000 0.00000000 # shell of core/shell pair 1
-3 2 1 1.5056 4.01599500 4.01599500 4.01599500 # core of core/shell pair 2
-4 2 3 -0.5056 4.01599500 4.01599500 4.01599500 # shell of core/shell pair 2
-(...) :pre
-
-Bonds # Bond topology for spring forces :pre
-
-1 2 1 2 # spring for core/shell pair 1
-2 2 3 4 # spring for core/shell pair 2
-(...) :pre
-
-Non-Coulombic (e.g. Lennard-Jones) pairwise interactions are only
-defined between the shells. Coulombic interactions are defined
-between all cores and shells. If desired, additional bonds can be
-specified between cores.
-
-The "special_bonds"_special_bonds.html command should be used to
-turn-off the Coulombic interaction within core/shell pairs, since that
-interaction is set by the bond spring. This is done using the
-"special_bonds"_special_bonds.html command with a 1-2 weight = 0.0,
-which is the default value. It needs to be considered whether one has
-to adjust the "special_bonds"_special_bonds.html weighting according
-to the molecular topology since the interactions of the shells are
-bypassed over an extra bond.
-
-Note that this core/shell implementation does not require all ions to
-be polarized. One can mix core/shell pairs and ions without a
-satellite particle if desired.
-
-Since the core/shell model permits distances of r = 0.0 between the
-core and shell, a pair style with a "cs" suffix needs to be used to
-implement a valid long-range Coulombic correction. Several such pair
-styles are provided in the CORESHELL package. See "this doc
-page"_pair_cs.html for details. All of the core/shell enabled pair
-styles require the use of a long-range Coulombic solver, as specified
-by the "kspace_style"_kspace_style.html command. Either the PPPM or
-Ewald solvers can be used.
-
-For the NaCL example problem, these pair style and bond style settings
-are used:
-
-pair_style born/coul/long/cs 20.0 20.0
-pair_coeff * * 0.0 1.000 0.00 0.00 0.00
-pair_coeff 3 3 487.0 0.23768 0.00 1.05 0.50 #Na-Na
-pair_coeff 3 4 145134.0 0.23768 0.00 6.99 8.70 #Na-Cl
-pair_coeff 4 4 405774.0 0.23768 0.00 72.40 145.40 #Cl-Cl :pre
-
-bond_style harmonic
-bond_coeff 1 63.014 0.0
-bond_coeff 2 25.724 0.0 :pre
-
-When running dynamics with the adiabatic core/shell model, the
-following issues should be considered. The relative motion of
-the core and shell particles corresponds to the polarization,
-hereby an instantaneous relaxation of the shells is approximated
-and a fast core/shell spring frequency ensures a nearly constant
-internal kinetic energy during the simulation.
-Thermostats can alter this polarization behaviour, by scaling the
-internal kinetic energy, meaning the shell will not react freely to
-its electrostatic environment.
-Therefore it is typically desirable to decouple the relative motion of
-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
-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
-non-polarized ions (ions without an attached satellite particle). The
-"compute temp/cs"_compute_temp_cs.html command requires input of two
-groups, one for the core atoms, another for the shell atoms.
-Non-polarized ions which might also be included in the treated system
-should not be included into either of these groups, they are taken
-into account by the {group-ID} (2nd argument) of the compute. The
-groups can be defined using the "group {type}"_group.html command.
-Note that to perform thermostatting using this definition of
-temperature, the "fix modify temp"_fix_modify.html command should be
-used to assign the compute to the thermostat fix. Likewise the
-"thermo_modify temp"_thermo_modify.html command can be used to make
-this temperature be output for the overall system.
-
-For the NaCl example, this can be done as follows:
-
-group cores type 1 2
-group shells type 3 4
-compute CSequ all temp/cs cores shells
-fix thermoberendsen all temp/berendsen 1427 1427 0.4 # thermostat for the true physical system
-fix thermostatequ all nve # integrator as needed for the berendsen thermostat
-fix_modify thermoberendsen temp CSequ
-thermo_modify temp CSequ # output of center-of-mass derived temperature :pre
-
-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
-default "temperature"_compute_temp and specifying it as a second
-argument in "fix modify"_fix_modify.html and
-"thermo_modify"_thermo_modify.html resulting in:
-
-(...)
-compute CSequ all temp/cs cores shells
-compute thermo_press_lmp all pressure thermo_temp # pressure for individual particles
-thermo_modify temp CSequ press thermo_press_lmp # modify thermo to regular pressure
-fix press_bar all npt temp 300 300 0.04 iso 0 0 0.4
-fix_modify press_bar temp CSequ press thermo_press_lmp # pressure modification for correct kinetic scalar :pre
-
-If "compute temp/cs"_compute_temp_cs.html is used, the decoupled
-relative motion of the core and the shell should in theory be
-stable. However numerical fluctuation can introduce a small
-momentum to the system, which is noticable over long trajectories.
-Therefore it is recommendable to use the "fix
-momentum"_fix_momentum.html command in combination with "compute
-temp/cs"_compute_temp_cs.html when equilibrating the system to
-prevent any drift.
-
-When initializing the velocities of a system with core/shell pairs, it
-is also desirable to not introduce energy into the relative motion of
-the core/shell particles, but only assign a center-of-mass velocity to
-the pairs. This can be done by using the {bias} keyword of the
-"velocity create"_velocity.html command and assigning the "compute
-temp/cs"_compute_temp_cs.html command to the {temp} keyword of the
-"velocity"_velocity.html command, e.g.
-
-velocity all create 1427 134 bias yes temp CSequ
-velocity all scale 1427 temp CSequ :pre
-
-To maintain the correct polarizability of the core/shell pairs, the
-kinetic energy of the internal motion shall remain nearly constant.
-Therefore the choice of spring force and mass ratio need to ensure
-much faster relative motion of the 2 atoms within the core/shell pair
-than their center-of-mass velocity. This allows the shells to
-effectively react instantaneously to the electrostatic environment and
-limits energy transfer to or from the core/shell oscillators.
-This fast movement also dictates the timestep that can be used.
-
-The primary literature of the adiabatic core/shell model suggests that
-the fast relative motion of the core/shell pairs only allows negligible
-energy transfer to the environment.
-The mentioned energy transfer will typically lead to a small drift
-in total energy over time. This internal energy can be monitored
-using the "compute chunk/atom"_compute_chunk_atom.html and "compute
-temp/chunk"_compute_temp_chunk.html commands. The internal kinetic
-energies of each core/shell pair can then be summed using the sum()
-special function of the "variable"_variable.html command. Or they can
-be time/averaged and output using the "fix ave/time"_fix_ave_time.html
-command. To use these commands, each core/shell pair must be defined
-as a "chunk". If each core/shell pair is defined as its own molecule,
-the molecule ID can be used to define the chunks. If cores are bonded
-to each other to form larger molecules, the chunks can be identified
-by the "fix property/atom"_fix_property_atom.html via assigning a
-core/shell ID to each atom using a special field in the data file read
-by the "read_data"_read_data.html command. This field can then be
-accessed by the "compute property/atom"_compute_property_atom.html
-command, to use as input to the "compute
-chunk/atom"_compute_chunk_atom.html command to define the core/shell
-pairs as chunks.
-
-For example if core/shell pairs are the only molecules:
-
-read_data NaCl_CS_x0.1_prop.data
-compute prop all property/atom molecule
-compute cs_chunk all chunk/atom c_prop
-compute cstherm all temp/chunk cs_chunk temp internal com yes cdof 3.0 # note the chosen degrees of freedom for the core/shell pairs
-fix ave_chunk all ave/time 10 1 10 c_cstherm file chunk.dump mode vector :pre
-
-For example if core/shell pairs and other molecules are present:
-
-fix csinfo all property/atom i_CSID # property/atom command
-read_data NaCl_CS_x0.1_prop.data fix csinfo NULL CS-Info # atom property added in the data-file
-compute prop all property/atom i_CSID
-(...) :pre
-
-The additional section in the date file would be formatted like this:
-
-CS-Info # header of additional section :pre
-
-1 1 # column 1 = atom ID, column 2 = core/shell ID
-2 1
-3 2
-4 2
-5 3
-6 3
-7 4
-8 4
-(...) :pre
-
-:line
-
-6.27 Drude induced dipoles :link(howto_27),h4
-
-The thermalized Drude model, similarly to the "core-shell"_#howto_26
-model, represents induced dipoles by a pair of charges (the core atom
-and the Drude particle) connected by a harmonic spring. The Drude
-model has a number of features aimed at its use in molecular systems
-("Lamoureux and Roux"_#howto-Lamoureux):
-
-Thermostating of the additional degrees of freedom associated with the
-induced dipoles at very low temperature, in terms of the reduced
-coordinates of the Drude particles with respect to their cores. This
-makes the trajectory close to that of relaxed induced dipoles. :ulb,l
-
-Consistent definition of 1-2 to 1-4 neighbors. A core-Drude particle
-pair represents a single (polarizable) atom, so the special screening
-factors in a covalent structure should be the same for the core and
-the Drude particle. Drude particles have to inherit the 1-2, 1-3, 1-4
-special neighbor relations from their respective cores. :l
-
-Stabilization of the interactions between induced dipoles. Drude
-dipoles on covalently bonded atoms interact too strongly due to the
-short distances, so an atom may capture the Drude particle of a
-neighbor, or the induced dipoles within the same molecule may align
-too much. To avoid this, damping at short range can be done by Thole
-functions (for which there are physical grounds). This Thole damping
-is applied to the point charges composing the induced dipole (the
-charge of the Drude particle and the opposite charge on the core, not
-to the total charge of the core atom). :l
-:ule
-
-A detailed tutorial covering the usage of Drude induced dipoles in
-LAMMPS is "available here"_tutorial_drude.html.
-
-As with the core-shell model, the cores and Drude particles should
-appear in the data file as standard atoms. The same holds for the
-springs between them, which are described by standard harmonic bonds.
-The nature of the atoms (core, Drude particle or non-polarizable) is
-specified via the "fix drude"_fix_drude.html command. The special
-list of neighbors is automatically refactored to account for the
-equivalence of core and Drude particles as regards special 1-2 to 1-4
-screening. It may be necessary to use the {extra/special/per/atom}
-keyword of the "read_data"_read_data.html command. If using "fix
-shake"_fix_shake.html, make sure no Drude particle is in this fix
-group.
-
-There are two ways to thermostat the Drude particles at a low
-temperature: use either "fix langevin/drude"_fix_langevin_drude.html
-for a Langevin thermostat, or "fix
-drude/transform/*"_fix_drude_transform.html for a Nose-Hoover
-thermostat. The former requires use of the command "comm_modify vel
-yes"_comm_modify.html. The latter requires two separate integration
-fixes like {nvt} or {npt}. The correct temperatures of the reduced
-degrees of freedom can be calculated using the "compute
-temp/drude"_compute_temp_drude.html. This requires also to use the
-command {comm_modify vel yes}.
-
-Short-range damping of the induced dipole interactions can be achieved
-using Thole functions through the "pair style
-thole"_pair_thole.html in "pair_style hybrid/overlay"_pair_hybrid.html
-with a Coulomb pair style. It may be useful to use {coul/long/cs} or
-similar from the CORESHELL package if the core and Drude particle come
-too close, which can cause numerical issues.
-
-:line
-
-6.28 Magnetic spins :link(howto_28),h4
-
-Classical magnetic spin simualtions can be performed via the SPIN
-package. The algrorithmic and implementation details are described in
-"Tranchida"_#Tranchida7.
-
-The model representents the simulation of atomic magnetic spins
-coupled to lattice vibrations. The dynamics of those magnetic spins
-can be used to simulate a broad range a phenomena related to
-magneto-elasticity, or or to study the influence of defects on the
-magnetic properties of materials.
-
-The magnetic spins are interacting with each others and with the
-lattice via pair interactions. Typically, the magnetic exchange
-interaction can be defined using the
-"pair/spin/exchange"_pair_spin_exchange.html command. This exchange
-applies a magnetic torque to a given spin, considering the orientation
-of its neighboring spins and their relative distances.
-It also applies a force on the atoms as a function of the spin
-orientations and their associated inter-atomic distances.
-
-The command "fix precession/spin"_fix_precession_spin.html allows to
-apply a constant magnetic torque on all the spins in the system. This
-torque can be an external magnetic field (Zeeman interaction), or an
-uniaxial magnetic anisotropy.
-
-A Langevin thermostat can be applied to those magnetic spins using
-"fix langevin/spin"_fix_langevin_spin.html. Typically, this thermostat
-can be coupled to another Langevin thermostat applied to the atoms
-using "fix langevin"_fix_langevin.html in order to simulate
-thermostated spin-lattice system.
-
-The magnetic Gilbert damping can also be applied using "fix
-langevin/spin"_fix_langevin_spin.html. It allows to either dissipate
-the thermal energy of the Langevin thermostat, or to perform a
-relaxation of the magnetic configuration toward an equilibrium state.
-
-All the computed magnetic properties can be outputed by two main
-commands. The first one is "compute spin"_compute_spin.html, that
-enables to evaluate magnetic averaged quantities, such as the total
-magnetization of the system along x, y, or z, the spin temperature, or
-the magnetic energy. The second command is "compute
-property/atom"_compute_property_atom.html. It enables to output all the
-per atom magnetic quantities. Typically, the orientation of a given
-magnetic spin, or the magnetic force acting on this spin.
-
-:line
-:line
-
-:link(howto-Berendsen)
-[(Berendsen)] Berendsen, Grigera, Straatsma, J Phys Chem, 91,
-6269-6271 (1987).
-
-:link(howto-Cornell)
-[(Cornell)] Cornell, Cieplak, Bayly, Gould, Merz, Ferguson,
-Spellmeyer, Fox, Caldwell, Kollman, JACS 117, 5179-5197 (1995).
-
-:link(Horn)
-[(Horn)] Horn, Swope, Pitera, Madura, Dick, Hura, and Head-Gordon,
-J Chem Phys, 120, 9665 (2004).
-
-:link(howto-Ikeshoji)
-[(Ikeshoji)] Ikeshoji and Hafskjold, Molecular Physics, 81, 251-261
-(1994).
-
-:link(howto-Wirnsberger)
-[(Wirnsberger)] Wirnsberger, Frenkel, and Dellago, J Chem Phys, 143, 124104
-(2015).
-
-:link(howto-MacKerell)
-[(MacKerell)] MacKerell, Bashford, Bellott, Dunbrack, Evanseck, Field,
-Fischer, Gao, Guo, Ha, et al, J Phys Chem, 102, 3586 (1998).
-
-:link(howto-Mayo)
-[(Mayo)] Mayo, Olfason, Goddard III, J Phys Chem, 94, 8897-8909
-(1990).
-
-:link(Jorgensen1)
-[(Jorgensen)] Jorgensen, Chandrasekhar, Madura, Impey, Klein, J Chem
-Phys, 79, 926 (1983).
-
-:link(Price1)
-[(Price)] Price and Brooks, J Chem Phys, 121, 10096 (2004).
-
-:link(Shinoda1)
-[(Shinoda)] Shinoda, Shiga, and Mikami, Phys Rev B, 69, 134103 (2004).
-
-:link(MitchellFincham)
-[(Mitchell and Fincham)] Mitchell, Fincham, J Phys Condensed Matter,
-5, 1031-1038 (1993).
-
-:link(MitchellFincham2)
-[(Fincham)] Fincham, Mackrodt and Mitchell, J Phys Condensed Matter,
-6, 393-404 (1994).
-
-:link(howto-Lamoureux)
-[(Lamoureux and Roux)] G. Lamoureux, B. Roux, J. Chem. Phys 119, 3025 (2003)
-
-:link(Tranchida7)
-[(Tranchida)] Tranchida, Plimpton, Thibaudeau and Thompson,
-arXiv preprint arXiv:1801.10233, (2018).
diff --git a/doc/src/Section_intro.txt b/doc/src/Section_intro.txt
deleted file mode 100644
index 67293b2ee3363b422cdb3f2f58bd0da9a037d9ab..0000000000000000000000000000000000000000
--- a/doc/src/Section_intro.txt
+++ /dev/null
@@ -1,549 +0,0 @@
-"Previous Section"_Manual.html - "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Section_start.html :c
-
-:link(lws,http://lammps.sandia.gov)
-:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
-
-:line
-
-1. Introduction :h2
-
-This section provides an overview of what LAMMPS can and can't do,
-describes what it means for LAMMPS to be an open-source code, and
-acknowledges the funding and people who have contributed to LAMMPS
-over the years.
-
-1.1 "What is LAMMPS"_#intro_1
-1.2 "LAMMPS features"_#intro_2
-1.3 "LAMMPS non-features"_#intro_3
-1.4 "Open source distribution"_#intro_4
-1.5 "Acknowledgments and citations"_#intro_5 :all(b)
-
-:line
-:line
-
-1.1 What is LAMMPS :link(intro_1),h4
-
-LAMMPS is a classical molecular dynamics code that models an ensemble
-of particles in a liquid, solid, or gaseous state. It can model
-atomic, polymeric, biological, metallic, granular, and coarse-grained
-systems using a variety of force fields and boundary conditions.
-
-For examples of LAMMPS simulations, see the Publications page of the
-"LAMMPS WWW Site"_lws.
-
-LAMMPS runs efficiently on single-processor desktop or laptop
-machines, but is designed for parallel computers. It will run on any
-parallel machine that compiles C++ and supports the "MPI"_mpi
-message-passing library. This includes distributed- or shared-memory
-parallel machines and Beowulf-style clusters.
-
-:link(mpi,http://www-unix.mcs.anl.gov/mpi)
-
-LAMMPS can model systems with only a few particles up to millions or
-billions. See "Section 8"_Section_perf.html for information on
-LAMMPS performance and scalability, or the Benchmarks section of the
-"LAMMPS WWW Site"_lws.
-
-LAMMPS is a freely-available open-source code, distributed under the
-terms of the "GNU Public License"_gnu, which means you can use or
-modify the code however you wish. See "this section"_#intro_4 for a
-brief discussion of the open-source philosophy.
-
-:link(gnu,http://www.gnu.org/copyleft/gpl.html)
-
-LAMMPS is designed to be easy to modify or extend with new
-capabilities, such as new force fields, atom types, boundary
-conditions, or diagnostics. See "Section 10"_Section_modify.html
-for more details.
-
-The current version of LAMMPS is written in C++. Earlier versions
-were written in F77 and F90. See
-"Section 13"_Section_history.html for more information on
-different versions. All versions can be downloaded from the "LAMMPS
-WWW Site"_lws.
-
-LAMMPS was originally developed under a US Department of Energy CRADA
-(Cooperative Research and Development Agreement) between two DOE labs
-and 3 companies. It is distributed by "Sandia National Labs"_snl.
-See "this section"_#intro_5 for more information on LAMMPS funding and
-individuals who have contributed to LAMMPS.
-
-:link(snl,http://www.sandia.gov)
-
-In the most general sense, LAMMPS integrates Newton's equations of
-motion for collections of atoms, molecules, or macroscopic particles
-that interact via short- or long-range forces with a variety of
-initial and/or boundary conditions. For computational efficiency
-LAMMPS uses neighbor lists to keep track of nearby particles. The
-lists are optimized for systems with particles that are repulsive at
-short distances, so that the local density of particles never becomes
-too large. On parallel machines, LAMMPS uses spatial-decomposition
-techniques to partition the simulation domain into small 3d
-sub-domains, one of which is assigned to each processor. Processors
-communicate and store "ghost" atom information for atoms that border
-their sub-domain. LAMMPS is most efficient (in a parallel sense) for
-systems whose particles fill a 3d rectangular box with roughly uniform
-density. Papers with technical details of the algorithms used in
-LAMMPS are listed in "this section"_#intro_5.
-
-:line
-
-1.2 LAMMPS features :link(intro_2),h4
-
-This section highlights LAMMPS features, with pointers to specific
-commands which give more details. If LAMMPS doesn't have your
-favorite interatomic potential, boundary condition, or atom type, see
-"Section 10"_Section_modify.html, which describes how you can add
-it to LAMMPS.
-
-General features :h4
-
- runs on a single processor or in parallel
- distributed-memory message-passing parallelism (MPI)
- spatial-decomposition of simulation domain for parallelism
- open-source distribution
- highly portable C++
- optional libraries used: MPI and single-processor FFT
- GPU (CUDA and OpenCL), Intel(R) Xeon Phi(TM) coprocessors, and OpenMP support for many code features
- easy to extend with new features and functionality
- runs from an input script
- syntax for defining and using variables and formulas
- syntax for looping over runs and breaking out of loops
- run one or multiple simulations simultaneously (in parallel) from one script
- build as library, invoke LAMMPS thru library interface or provided Python wrapper
- couple with other codes: LAMMPS calls other code, other code calls LAMMPS, umbrella code calls both :ul
-
-Particle and model types :h4
-("atom style"_atom_style.html command)
-
- atoms
- coarse-grained particles (e.g. bead-spring polymers)
- united-atom polymers or organic molecules
- all-atom polymers, organic molecules, proteins, DNA
- metals
- granular materials
- coarse-grained mesoscale models
- finite-size spherical and ellipsoidal particles
- finite-size line segment (2d) and triangle (3d) particles
- point dipole particles
- rigid collections of particles
- hybrid combinations of these :ul
-
-Force fields :h4
-("pair style"_pair_style.html, "bond style"_bond_style.html,
-"angle style"_angle_style.html, "dihedral style"_dihedral_style.html,
-"improper style"_improper_style.html, "kspace style"_kspace_style.html
-commands)
-
- pairwise potentials: Lennard-Jones, Buckingham, Morse, Born-Mayer-Huggins, \
- Yukawa, soft, class 2 (COMPASS), hydrogen bond, tabulated
- charged pairwise potentials: Coulombic, point-dipole
- manybody potentials: EAM, Finnis/Sinclair EAM, modified EAM (MEAM), \
- embedded ion method (EIM), EDIP, ADP, Stillinger-Weber, Tersoff, \
- REBO, AIREBO, ReaxFF, COMB, SNAP, Streitz-Mintmire, 3-body polymorphic
- long-range interactions for charge, point-dipoles, and LJ dispersion: \
- Ewald, Wolf, PPPM (similar to particle-mesh Ewald)
- polarization models: "QEq"_fix_qeq.html, \
- "core/shell model"_Section_howto.html#howto_26, \
- "Drude dipole model"_Section_howto.html#howto_27
- charge equilibration (QEq via dynamic, point, shielded, Slater methods)
- coarse-grained potentials: DPD, GayBerne, REsquared, colloidal, DLVO
- mesoscopic potentials: granular, Peridynamics, SPH
- electron force field (eFF, AWPMD)
- bond potentials: harmonic, FENE, Morse, nonlinear, class 2, \
- quartic (breakable)
- angle potentials: harmonic, CHARMM, cosine, cosine/squared, cosine/periodic, \
- class 2 (COMPASS)
- dihedral potentials: harmonic, CHARMM, multi-harmonic, helix, \
- class 2 (COMPASS), OPLS
- improper potentials: harmonic, cvff, umbrella, class 2 (COMPASS)
- polymer potentials: all-atom, united-atom, bead-spring, breakable
- water potentials: TIP3P, TIP4P, SPC
- implicit solvent potentials: hydrodynamic lubrication, Debye
- force-field compatibility with common CHARMM, AMBER, DREIDING, \
- OPLS, GROMACS, COMPASS options
- access to "KIM archive"_http://openkim.org of potentials via \
- "pair kim"_pair_kim.html
- hybrid potentials: multiple pair, bond, angle, dihedral, improper \
- potentials can be used in one simulation
- overlaid potentials: superposition of multiple pair potentials :ul
-
-Atom creation :h4
-("read_data"_read_data.html, "lattice"_lattice.html,
-"create_atoms"_create_atoms.html, "delete_atoms"_delete_atoms.html,
-"displace_atoms"_displace_atoms.html, "replicate"_replicate.html commands)
-
- read in atom coords from files
- create atoms on one or more lattices (e.g. grain boundaries)
- delete geometric or logical groups of atoms (e.g. voids)
- replicate existing atoms multiple times
- displace atoms :ul
-
-Ensembles, constraints, and boundary conditions :h4
-("fix"_fix.html command)
-
- 2d or 3d systems
- orthogonal or non-orthogonal (triclinic symmetry) simulation domains
- constant NVE, NVT, NPT, NPH, Parinello/Rahman integrators
- thermostatting options for groups and geometric regions of atoms
- pressure control via Nose/Hoover or Berendsen barostatting in 1 to 3 dimensions
- simulation box deformation (tensile and shear)
- harmonic (umbrella) constraint forces
- rigid body constraints
- SHAKE bond and angle constraints
- Monte Carlo bond breaking, formation, swapping
- atom/molecule insertion and deletion
- walls of various kinds
- non-equilibrium molecular dynamics (NEMD)
- variety of additional boundary conditions and constraints :ul
-
-Integrators :h4
-("run"_run.html, "run_style"_run_style.html, "minimize"_minimize.html commands)
-
- velocity-Verlet integrator
- Brownian dynamics
- rigid body integration
- energy minimization via conjugate gradient or steepest descent relaxation
- rRESPA hierarchical timestepping
- rerun command for post-processing of dump files :ul
-
-Diagnostics :h4
-
- see the various flavors of the "fix"_fix.html and "compute"_compute.html commands :ul
-
-Output :h4
-("dump"_dump.html, "restart"_restart.html commands)
-
- log file of thermodynamic info
- text dump files of atom coords, velocities, other per-atom quantities
- binary restart files
- parallel I/O of dump and restart files
- per-atom quantities (energy, stress, centro-symmetry parameter, CNA, etc)
- user-defined system-wide (log file) or per-atom (dump file) calculations
- spatial and time averaging of per-atom quantities
- time averaging of system-wide quantities
- atom snapshots in native, XYZ, XTC, DCD, CFG formats :ul
-
-Multi-replica models :h4
-
-"nudged elastic band"_neb.html
-"parallel replica dynamics"_prd.html
-"temperature accelerated dynamics"_tad.html
-"parallel tempering"_temper.html
-
-Pre- and post-processing :h4
-
-Various pre- and post-processing serial tools are packaged
-with LAMMPS; see these "doc pages"_Section_tools.html. :ulb,l
-
-Our group has also written and released a separate toolkit called
-"Pizza.py"_pizza which provides tools for doing setup, analysis,
-plotting, and visualization for LAMMPS simulations. Pizza.py is
-written in "Python"_python and is available for download from "the
-Pizza.py WWW site"_pizza. :l
-:ule
-
-:link(pizza,http://www.sandia.gov/~sjplimp/pizza.html)
-:link(python,http://www.python.org)
-
-Specialized features :h4
-
-LAMMPS can be built with optional packages which implement a variety
-of additional capabilities. An overview of all the packages is "given
-here"_Section_packages.html.
-
-These are some LAMMPS capabilities which you may not think of as
-typical classical molecular dynamics options:
-
-"static"_balance.html and "dynamic load-balancing"_fix_balance.html
-"generalized aspherical particles"_body.html
-"stochastic rotation dynamics (SRD)"_fix_srd.html
-"real-time visualization and interactive MD"_fix_imd.html
-calculate "virtual diffraction patterns"_compute_xrd.html
-"atom-to-continuum coupling"_fix_atc.html with finite elements
-coupled rigid body integration via the "POEMS"_fix_poems.html library
-"QM/MM coupling"_fix_qmmm.html
-"path-integral molecular dynamics (PIMD)"_fix_ipi.html and "this as well"_fix_pimd.html
-Monte Carlo via "GCMC"_fix_gcmc.html and "tfMC"_fix_tfmc.html "atom swapping"_fix_atom_swap.html and "bond swapping"_fix_bond_swap.html
-"Direct Simulation Monte Carlo"_pair_dsmc.html for low-density fluids
-"Peridynamics mesoscale modeling"_pair_peri.html
-"Lattice Boltzmann fluid"_fix_lb_fluid.html
-"targeted"_fix_tmd.html and "steered"_fix_smd.html molecular dynamics
-"two-temperature electron model"_fix_ttm.html :ul
-
-:line
-
-1.3 LAMMPS non-features :link(intro_3),h4
-
-LAMMPS is designed to efficiently compute Newton's equations of motion
-for a system of interacting particles. Many of the tools needed to
-pre- and post-process the data for such simulations are not included
-in the LAMMPS kernel for several reasons:
-
-the desire to keep LAMMPS simple
-they are not parallel operations
-other codes already do them
-limited development resources :ul
-
-Specifically, LAMMPS itself does not:
-
-run thru a GUI
-build molecular systems
-assign force-field coefficients automagically
-perform sophisticated analyses of your MD simulation
-visualize your MD simulation
-plot your output data :ul
-
-A few tools for pre- and post-processing tasks are provided as part of
-the LAMMPS package; they are described in "this
-section"_Section_tools.html. However, many people use other codes or
-write their own tools for these tasks.
-
-As noted above, our group has also written and released a separate
-toolkit called "Pizza.py"_pizza which addresses some of the listed
-bullets. It provides tools for doing setup, analysis, plotting, and
-visualization for LAMMPS simulations. Pizza.py is written in
-"Python"_python and is available for download from "the Pizza.py WWW
-site"_pizza.
-
-LAMMPS requires as input a list of initial atom coordinates and types,
-molecular topology information, and force-field coefficients assigned
-to all atoms and bonds. LAMMPS will not build molecular systems and
-assign force-field parameters for you.
-
-For atomic systems LAMMPS provides a "create_atoms"_create_atoms.html
-command which places atoms on solid-state lattices (fcc, bcc,
-user-defined, etc). Assigning small numbers of force field
-coefficients can be done via the "pair coeff"_pair_coeff.html, "bond
-coeff"_bond_coeff.html, "angle coeff"_angle_coeff.html, etc commands.
-For molecular systems or more complicated simulation geometries, users
-typically use another code as a builder and convert its output to
-LAMMPS input format, or write their own code to generate atom
-coordinate and molecular topology for LAMMPS to read in.
-
-For complicated molecular systems (e.g. a protein), a multitude of
-topology information and hundreds of force-field coefficients must
-typically be specified. We suggest you use a program like
-"CHARMM"_charmm or "AMBER"_amber or other molecular builders to setup
-such problems and dump its information to a file. You can then
-reformat the file as LAMMPS input. Some of the tools in "this
-section"_Section_tools.html can assist in this process.
-
-Similarly, LAMMPS creates output files in a simple format. Most users
-post-process these files with their own analysis tools or re-format
-them for input into other programs, including visualization packages.
-If you are convinced you need to compute something on-the-fly as
-LAMMPS runs, see "Section 10"_Section_modify.html for a discussion
-of how you can use the "dump"_dump.html and "compute"_compute.html and
-"fix"_fix.html commands to print out data of your choosing. Keep in
-mind that complicated computations can slow down the molecular
-dynamics timestepping, particularly if the computations are not
-parallel, so it is often better to leave such analysis to
-post-processing codes.
-
-For high-quality visualization we recommend the
-following packages:
-
-"VMD"_http://www.ks.uiuc.edu/Research/vmd
-"AtomEye"_http://mt.seas.upenn.edu/Archive/Graphics/A
-"OVITO"_http://www.ovito.org/
-"ParaView"_http://www.paraview.org/
-"PyMol"_http://www.pymol.org
-"Raster3d"_http://www.bmsc.washington.edu/raster3d/raster3d.html
-"RasMol"_http://www.openrasmol.org :ul
-
-Other features that LAMMPS does not yet (and may never) support are
-discussed in "Section 13"_Section_history.html.
-
-Finally, these are freely-available molecular dynamics codes, most of
-them parallel, which may be well-suited to the problems you want to
-model. They can also be used in conjunction with LAMMPS to perform
-complementary modeling tasks.
-
-"CHARMM"_charmm
-"AMBER"_amber
-"NAMD"_namd
-"NWCHEM"_nwchem
-"DL_POLY"_dlpoly
-"Tinker"_tinker :ul
-
-:link(charmm,http://www.charmm.org)
-:link(amber,http://ambermd.org)
-:link(namd,http://www.ks.uiuc.edu/Research/namd/)
-:link(nwchem,http://www.emsl.pnl.gov/docs/nwchem/nwchem.html)
-:link(dlpoly,http://www.ccp5.ac.uk/DL_POLY_CLASSIC)
-:link(tinker,http://dasher.wustl.edu/tinker)
-
-CHARMM, AMBER, NAMD, NWCHEM, and Tinker are designed primarily for
-modeling biological molecules. CHARMM and AMBER use
-atom-decomposition (replicated-data) strategies for parallelism; NAMD
-and NWCHEM use spatial-decomposition approaches, similar to LAMMPS.
-Tinker is a serial code. DL_POLY includes potentials for a variety of
-biological and non-biological materials; both a replicated-data and
-spatial-decomposition version exist.
-
-:line
-
-1.4 Open source distribution :link(intro_4),h4
-
-LAMMPS comes with no warranty of any kind. As each source file states
-in its header, it is a copyrighted code that is distributed free-of-
-charge, under the terms of the "GNU Public License"_gnu (GPL). This
-is often referred to as open-source distribution - see
-"www.gnu.org"_gnuorg or "www.opensource.org"_opensource for more
-details. The legal text of the GPL is in the LICENSE file that is
-included in the LAMMPS distribution.
-
-:link(gnuorg,http://www.gnu.org)
-:link(opensource,http://www.opensource.org)
-
-Here is a summary of what the GPL means for LAMMPS users:
-
-(1) Anyone is free to use, modify, or extend LAMMPS in any way they
-choose, including for commercial purposes.
-
-(2) If you distribute a modified version of LAMMPS, it must remain
-open-source, meaning you distribute it under the terms of the GPL.
-You should clearly annotate such a code as a derivative version of
-LAMMPS.
-
-(3) If you release any code that includes LAMMPS source code, then it
-must also be open-sourced, meaning you distribute it under the terms
-of the GPL.
-
-(4) If you give LAMMPS files to someone else, the GPL LICENSE file and
-source file headers (including the copyright and GPL notices) should
-remain part of the code.
-
-In the spirit of an open-source code, these are various ways you can
-contribute to making LAMMPS better. You can send email to the
-"developers"_http://lammps.sandia.gov/authors.html on any of these
-items.
-
-Point prospective users to the "LAMMPS WWW Site"_lws. Mention it in
-talks or link to it from your WWW site. :ulb,l
-
-If you find an error or omission in this manual or on the "LAMMPS WWW
-Site"_lws, or have a suggestion for something to clarify or include,
-send an email to the
-"developers"_http://lammps.sandia.gov/authors.html. :l
-
-If you find a bug, "Section 12.2"_Section_errors.html#err_2
-describes how to report it. :l
-
-If you publish a paper using LAMMPS results, send the citation (and
-any cool pictures or movies if you like) to add to the Publications,
-Pictures, and Movies pages of the "LAMMPS WWW Site"_lws, with links
-and attributions back to you. :l
-
-Create a new Makefile.machine that can be added to the src/MAKE
-directory. :l
-
-The tools sub-directory of the LAMMPS distribution has various
-stand-alone codes for pre- and post-processing of LAMMPS data. More
-details are given in "Section 9"_Section_tools.html. If you write
-a new tool that users will find useful, it can be added to the LAMMPS
-distribution. :l
-
-LAMMPS is designed to be easy to extend with new code for features
-like potentials, boundary conditions, diagnostic computations, etc.
-"This section"_Section_modify.html gives details. If you add a
-feature of general interest, it can be added to the LAMMPS
-distribution. :l
-
-The Benchmark page of the "LAMMPS WWW Site"_lws lists LAMMPS
-performance on various platforms. The files needed to run the
-benchmarks are part of the LAMMPS distribution. If your machine is
-sufficiently different from those listed, your timing data can be
-added to the page. :l
-
-You can send feedback for the User Comments page of the "LAMMPS WWW
-Site"_lws. It might be added to the page. No promises. :l
-
-Cash. Small denominations, unmarked bills preferred. Paper sack OK.
-Leave on desk. VISA also accepted. Chocolate chip cookies
-encouraged. :l
-:ule
-
-:line
-
-1.5 Acknowledgments and citations :h3,link(intro_5)
-
-LAMMPS development has been funded by the "US Department of
-Energy"_doe (DOE), through its CRADA, LDRD, ASCI, and Genomes-to-Life
-programs and its "OASCR"_oascr and "OBER"_ober offices.
-
-Specifically, work on the latest version was funded in part by the US
-Department of Energy's Genomics:GTL program
-("www.doegenomestolife.org"_gtl) under the "project"_ourgtl, "Carbon
-Sequestration in Synechococcus Sp.: From Molecular Machines to
-Hierarchical Modeling".
-
-:link(doe,http://www.doe.gov)
-:link(gtl,http://www.doegenomestolife.org)
-:link(ourgtl,http://www.genomes2life.org)
-:link(oascr,http://www.sc.doe.gov/ascr/home.html)
-:link(ober,http://www.er.doe.gov/production/ober/ober_top.html)
-
-The following paper describe the basic parallel algorithms used in
-LAMMPS. If you use LAMMPS results in your published work, please cite
-this paper and include a pointer to the "LAMMPS WWW Site"_lws
-(http://lammps.sandia.gov):
-
-S. Plimpton, [Fast Parallel Algorithms for Short-Range Molecular
-Dynamics], J Comp Phys, 117, 1-19 (1995).
-
-Other papers describing specific algorithms used in LAMMPS are listed
-under the "Citing LAMMPS link"_http://lammps.sandia.gov/cite.html of
-the LAMMPS WWW page.
-
-The "Publications link"_http://lammps.sandia.gov/papers.html on the
-LAMMPS WWW page lists papers that have cited LAMMPS. If your paper is
-not listed there for some reason, feel free to send us the info. If
-the simulations in your paper produced cool pictures or animations,
-we'll be pleased to add them to the
-"Pictures"_http://lammps.sandia.gov/pictures.html or
-"Movies"_http://lammps.sandia.gov/movies.html pages of the LAMMPS WWW
-site.
-
-The primary LAMMPS developers are at Sandia National Labs and Temple University:
-
-Steve Plimpton, sjplimp at sandia.gov
-Aidan Thompson, athomps at sandia.gov
-Stan Moore, stamoor at sandia.gov
-Axel Kohlmeyer, akohlmey at gmail.com :ul
-
-Past primary developers include Paul Crozier and Mark Stevens,
-both at Sandia, and Ray Shan, now at Materials Design.
-
-The following folks are responsible for significant contributions to
-the code, or other aspects of the LAMMPS development effort. Many of
-the packages they have written are somewhat unique to LAMMPS and the
-code would not be as general-purpose as it is without their expertise
-and efforts.
-
-Axel Kohlmeyer (Temple U), akohlmey at gmail.com, SVN and Git repositories, indefatigable mail list responder, USER-CGSDK, USER-OMP, USER-COLVARS, USER-MOLFILE, USER-QMMM, USER-TALLY, and COMPRESS packages
-Roy Pollock (LLNL), Ewald and PPPM solvers
-Mike Brown (ORNL), brownw at ornl.gov, GPU and USER-INTEL package
-Greg Wagner (Sandia), gjwagne at sandia.gov, MEAM package for MEAM potential (superseded by USER-MEAMC)
-Mike Parks (Sandia), mlparks at sandia.gov, PERI package for Peridynamics
-Rudra Mukherjee (JPL), Rudranarayan.M.Mukherjee at jpl.nasa.gov, POEMS package for articulated rigid body motion
-Reese Jones (Sandia) and collaborators, rjones at sandia.gov, USER-ATC package for atom/continuum coupling
-Ilya Valuev (JIHT), valuev at physik.hu-berlin.de, USER-AWPMD package for wave-packet MD
-Christian Trott (U Tech Ilmenau), christian.trott at tu-ilmenau.de, USER-CUDA (obsoleted by KOKKOS) and KOKKOS packages
-Andres Jaramillo-Botero (Caltech), ajaramil at wag.caltech.edu, USER-EFF package for electron force field
-Christoph Kloss (JKU), Christoph.Kloss at jku.at, LIGGGHTS fork for granular models and granular/fluid coupling
-Metin Aktulga (LBL), hmaktulga at lbl.gov, USER-REAXC package for C version of ReaxFF
-Georg Gunzenmuller (EMI), georg.ganzenmueller at emi.fhg.de, USER-SMD and USER-SPH packages
-Colin Denniston (U Western Ontario), cdennist at uwo.ca, USER-LB package :ul
-
-As discussed in "Section 13"_Section_history.html, LAMMPS
-originated as a cooperative project between DOE labs and industrial
-partners. Folks involved in the design and testing of the original
-version of LAMMPS were the following:
-
-John Carpenter (Mayo Clinic, formerly at Cray Research)
-Terry Stouch (Lexicon Pharmaceuticals, formerly at Bristol Myers Squibb)
-Steve Lustig (Dupont)
-Jim Belak (LLNL) :ul
diff --git a/doc/src/Section_modify.txt b/doc/src/Section_modify.txt
deleted file mode 100644
index f1d55758c8b0b498710d2f9c2e83eb9834817481..0000000000000000000000000000000000000000
--- a/doc/src/Section_modify.txt
+++ /dev/null
@@ -1,827 +0,0 @@
- "Previous Section"_Section_tools.html - "LAMMPS WWW Site"_lws -
-"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
-Section"_Section_python.html :c
-
-:link(lws,http://lammps.sandia.gov)
-:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
-
-:line
-
-10. Modifying & extending LAMMPS :h2
-
-This section describes how to customize LAMMPS by modifying
-and extending its source code.
-
-10.1 "Atom styles"_#mod_1
-10.2 "Bond, angle, dihedral, improper potentials"_#mod_2
-10.3 "Compute styles"_#mod_3
-10.4 "Dump styles"_#mod_4
-10.5 "Dump custom output options"_#mod_5
-10.6 "Fix styles"_#mod_6 which include integrators, \
- temperature and pressure control, force constraints, \
- boundary conditions, diagnostic output, etc
-10.7 "Input script commands"_#mod_7
-10.8 "Kspace computations"_#mod_8
-10.9 "Minimization styles"_#mod_9
-10.10 "Pairwise potentials"_#mod_10
-10.11 "Region styles"_#mod_11
-10.12 "Body styles"_#mod_12
-10.13 "Thermodynamic output options"_#mod_13
-10.14 "Variable options"_#mod_14
-10.15 "Submitting new features for inclusion in LAMMPS"_#mod_15 :all(b)
-
-LAMMPS is designed in a modular fashion so as to be easy to modify and
-extend with new functionality. In fact, about 75% of its source code
-is files added in this fashion.
-
-In this section, changes and additions users can make are listed along
-with minimal instructions. If you add a new feature to LAMMPS and
-think it will be of interest to general users, we encourage you to
-submit it to the developers for inclusion in the released version of
-LAMMPS. Information about how to do this is provided
-"below"_#mod_14.
-
-The best way to add a new feature is to find a similar feature in
-LAMMPS and look at the corresponding source and header files to figure
-out what it does. You will need some knowledge of C++ to be able to
-understand the hi-level structure of LAMMPS and its class
-organization, but functions (class methods) that do actual
-computations are written in vanilla C-style code and operate on simple
-C-style data structures (vectors and arrays).
-
-Most of the new features described in this section require you to
-write a new C++ derived class (except for exceptions described below,
-where you can make small edits to existing files). Creating a new
-class requires 2 files, a source code file (*.cpp) and a header file
-(*.h). The derived class must provide certain methods to work as a
-new option. Depending on how different your new feature is compared
-to existing features, you can either derive from the base class
-itself, or from a derived class that already exists. Enabling LAMMPS
-to invoke the new class is as simple as putting the two source
-files in the src dir and re-building LAMMPS.
-
-The advantage of C++ and its object-orientation is that all the code
-and variables needed to define the new feature are in the 2 files you
-write, and thus shouldn't make the rest of LAMMPS more complex or
-cause side-effect bugs.
-
-Here is a concrete example. Suppose you write 2 files pair_foo.cpp
-and pair_foo.h that define a new class PairFoo that computes pairwise
-potentials described in the classic 1997 "paper"_#Foo by Foo, et al.
-If you wish to invoke those potentials in a LAMMPS input script with a
-command like
-
-pair_style foo 0.1 3.5 :pre
-
-then your pair_foo.h file should be structured as follows:
-
-#ifdef PAIR_CLASS
-PairStyle(foo,PairFoo)
-#else
-...
-(class definition for PairFoo)
-...
-#endif :pre
-
-where "foo" is the style keyword in the pair_style command, and
-PairFoo is the class name defined in your pair_foo.cpp and pair_foo.h
-files.
-
-When you re-build LAMMPS, your new pairwise potential becomes part of
-the executable and can be invoked with a pair_style command like the
-example above. Arguments like 0.1 and 3.5 can be defined and
-processed by your new class.
-
-As illustrated by this pairwise example, many kinds of options are
-referred to in the LAMMPS documentation as the "style" of a particular
-command.
-
-The instructions below give the header file for the base class that
-these styles are derived from. Public variables in that file are ones
-used and set by the derived classes which are also used by the base
-class. Sometimes they are also used by the rest of LAMMPS. Virtual
-functions in the base class header file which are set = 0 are ones you
-must define in your new derived class to give it the functionality
-LAMMPS expects. Virtual functions that are not set to 0 are functions
-you can optionally define.
-
-Additionally, new output options can be added directly to the
-thermo.cpp, dump_custom.cpp, and variable.cpp files as explained
-below.
-
-Here are additional guidelines for modifying LAMMPS and adding new
-functionality:
-
-Think about whether what you want to do would be better as a pre- or
-post-processing step. Many computations are more easily and more
-quickly done that way. :ulb,l
-
-Don't do anything within the timestepping of a run that isn't
-parallel. E.g. don't accumulate a bunch of data on a single processor
-and analyze it. You run the risk of seriously degrading the parallel
-efficiency. :l
-
-If your new feature reads arguments or writes output, make sure you
-follow the unit conventions discussed by the "units"_units.html
-command. :l
-
-If you add something you think is truly useful and doesn't impact
-LAMMPS performance when it isn't used, send an email to the
-"developers"_http://lammps.sandia.gov/authors.html. We might be
-interested in adding it to the LAMMPS distribution. See further
-details on this at the bottom of this page. :l
-:ule
-
-:line
-:line
-
-10.1 Atom styles :link(mod_1),h4
-
-Classes that define an "atom style"_atom_style.html are derived from
-the AtomVec class and managed by the Atom class. The atom style
-determines what attributes are associated with an atom. A new atom
-style can be created if one of the existing atom styles does not
-define all the attributes you need to store and communicate with
-atoms.
-
-Atom_vec_atomic.cpp is a simple example of an atom style.
-
-Here is a brief description of methods you define in your new derived
-class. See atom_vec.h for details.
-
-init: one time setup (optional)
-grow: re-allocate atom arrays to longer lengths (required)
-grow_reset: make array pointers in Atom and AtomVec classes consistent (required)
-copy: copy info for one atom to another atom's array locations (required)
-pack_comm: store an atom's info in a buffer communicated every timestep (required)
-pack_comm_vel: add velocity info to communication buffer (required)
-pack_comm_hybrid: store extra info unique to this atom style (optional)
-unpack_comm: retrieve an atom's info from the buffer (required)
-unpack_comm_vel: also retrieve velocity info (required)
-unpack_comm_hybrid: retrieve extra info unique to this atom style (optional)
-pack_reverse: store an atom's info in a buffer communicating partial forces (required)
-pack_reverse_hybrid: store extra info unique to this atom style (optional)
-unpack_reverse: retrieve an atom's info from the buffer (required)
-unpack_reverse_hybrid: retrieve extra info unique to this atom style (optional)
-pack_border: store an atom's info in a buffer communicated on neighbor re-builds (required)
-pack_border_vel: add velocity info to buffer (required)
-pack_border_hybrid: store extra info unique to this atom style (optional)
-unpack_border: retrieve an atom's info from the buffer (required)
-unpack_border_vel: also retrieve velocity info (required)
-unpack_border_hybrid: retrieve extra info unique to this atom style (optional)
-pack_exchange: store all an atom's info to migrate to another processor (required)
-unpack_exchange: retrieve an atom's info from the buffer (required)
-size_restart: number of restart quantities associated with proc's atoms (required)
-pack_restart: pack atom quantities into a buffer (required)
-unpack_restart: unpack atom quantities from a buffer (required)
-create_atom: create an individual atom of this style (required)
-data_atom: parse an atom line from the data file (required)
-data_atom_hybrid: parse additional atom info unique to this atom style (optional)
-data_vel: parse one line of velocity information from data file (optional)
-data_vel_hybrid: parse additional velocity data unique to this atom style (optional)
-memory_usage: tally memory allocated by atom arrays (required) :tb(s=:)
-
-The constructor of the derived class sets values for several variables
-that you must set when defining a new atom style, which are documented
-in atom_vec.h. New atom arrays are defined in atom.cpp. Search for
-the word "customize" and you will find locations you will need to
-modify.
-
-NOTE: It is possible to add some attributes, such as a molecule ID, to
-atom styles that do not have them via the "fix
-property/atom"_fix_property_atom.html command. This command also
-allows new custom attributes consisting of extra integer or
-floating-point values to be added to atoms. See the "fix
-property/atom"_fix_property_atom.html doc page for examples of cases
-where this is useful and details on how to initialize, access, and
-output the custom values.
-
-New "pair styles"_pair_style.html, "fixes"_fix.html, or
-"computes"_compute.html can be added to LAMMPS, as discussed below.
-The code for these classes can use the per-atom properties defined by
-fix property/atom. The Atom class has a find_custom() method that is
-useful in this context:
-
-int index = atom->find_custom(char *name, int &flag); :pre
-
-The "name" of a custom attribute, as specified in the "fix
-property/atom"_fix_property_atom.html command, is checked to verify
-that it exists and its index is returned. The method also sets flag =
-0/1 depending on whether it is an integer or floating-point attribute.
-The vector of values associated with the attribute can then be
-accessed using the returned index as
-
-int *ivector = atom->ivector\[index\];
-double *dvector = atom->dvector\[index\]; :pre
-
-Ivector or dvector are vectors of length Nlocal = # of owned atoms,
-which store the attributes of individual atoms.
-
-:line
-
-10.2 Bond, angle, dihedral, improper potentials :link(mod_2),h4
-
-Classes that compute molecular interactions are derived from the Bond,
-Angle, Dihedral, and Improper classes. New styles can be created to
-add new potentials to LAMMPS.
-
-Bond_harmonic.cpp is the simplest example of a bond style. Ditto for
-the harmonic forms of the angle, dihedral, and improper style
-commands.
-
-Here is a brief description of common methods you define in your
-new derived class. See bond.h, angle.h, dihedral.h, and improper.h
-for details and specific additional methods.
-
-init: check if all coefficients are set, calls {init_style} (optional)
-init_style: check if style specific conditions are met (optional)
-compute: compute the molecular interactions (required)
-settings: apply global settings for all types (optional)
-coeff: set coefficients for one type (required)
-equilibrium_distance: length of bond, used by SHAKE (required, bond only)
-equilibrium_angle: opening of angle, used by SHAKE (required, angle only)
-write & read_restart: writes/reads coeffs to restart files (required)
-single: force and energy of a single bond or angle (required, bond or angle only)
-memory_usage: tally memory allocated by the style (optional) :tb(s=:)
-
-:line
-
-10.3 Compute styles :link(mod_3),h4
-
-Classes that compute scalar and vector quantities like temperature
-and the pressure tensor, as well as classes that compute per-atom
-quantities like kinetic energy and the centro-symmetry parameter
-are derived from the Compute class. New styles can be created
-to add new calculations to LAMMPS.
-
-Compute_temp.cpp is a simple example of computing a scalar
-temperature. Compute_ke_atom.cpp is a simple example of computing
-per-atom kinetic energy.
-
-Here is a brief description of methods you define in your new derived
-class. See compute.h for details.
-
-init: perform one time setup (required)
-init_list: neighbor list setup, if needed (optional)
-compute_scalar: compute a scalar quantity (optional)
-compute_vector: compute a vector of quantities (optional)
-compute_peratom: compute one or more quantities per atom (optional)
-compute_local: compute one or more quantities per processor (optional)
-pack_comm: pack a buffer with items to communicate (optional)
-unpack_comm: unpack the buffer (optional)
-pack_reverse: pack a buffer with items to reverse communicate (optional)
-unpack_reverse: unpack the buffer (optional)
-remove_bias: remove velocity bias from one atom (optional)
-remove_bias_all: remove velocity bias from all atoms in group (optional)
-restore_bias: restore velocity bias for one atom after remove_bias (optional)
-restore_bias_all: same as before, but for all atoms in group (optional)
-pair_tally_callback: callback function for {tally}-style computes (optional).
-memory_usage: tally memory usage (optional) :tb(s=:)
-
-Tally-style computes are a special case, as their computation is done
-in two stages: the callback function is registered with the pair style
-and then called from the Pair::ev_tally() function, which is called for
-each pair after force and energy has been computed for this pair. Then
-the tallied values are retrieved with the standard compute_scalar or
-compute_vector or compute_peratom methods. The USER-TALLY package
-provides {examples}_compute_tally.html for utilizing this mechanism.
-
-:line
-
-10.4 Dump styles :link(mod_4),h4
-10.5 Dump custom output options :link(mod_5),h4
-
-Classes that dump per-atom info to files are derived from the Dump
-class. To dump new quantities or in a new format, a new derived dump
-class can be added, but it is typically simpler to modify the
-DumpCustom class contained in the dump_custom.cpp file.
-
-Dump_atom.cpp is a simple example of a derived dump class.
-
-Here is a brief description of methods you define in your new derived
-class. See dump.h for details.
-
-write_header: write the header section of a snapshot of atoms
-count: count the number of lines a processor will output
-pack: pack a proc's output data into a buffer
-write_data: write a proc's data to a file :tb(s=:)
-
-See the "dump"_dump.html command and its {custom} style for a list of
-keywords for atom information that can already be dumped by
-DumpCustom. It includes options to dump per-atom info from Compute
-classes, so adding a new derived Compute class is one way to calculate
-new quantities to dump.
-
-Alternatively, you can add new keywords to the dump custom command.
-Search for the word "customize" in dump_custom.cpp to see the
-half-dozen or so locations where code will need to be added.
-
-:line
-
-10.6 Fix styles :link(mod_6),h4
-
-In LAMMPS, a "fix" is any operation that is computed during
-timestepping that alters some property of the system. Essentially
-everything that happens during a simulation besides force computation,
-neighbor list construction, and output, is a "fix". This includes
-time integration (update of coordinates and velocities), force
-constraints or boundary conditions (SHAKE or walls), and diagnostics
-(compute a diffusion coefficient). New styles can be created to add
-new options to LAMMPS.
-
-Fix_setforce.cpp is a simple example of setting forces on atoms to
-prescribed values. There are dozens of fix options already in LAMMPS;
-choose one as a template that is similar to what you want to
-implement.
-
-Here is a brief description of methods you can define in your new
-derived class. See fix.h for details.
-
-setmask: determines when the fix is called during the timestep (required)
-init: initialization before a run (optional)
-setup_pre_exchange: called before atom exchange in setup (optional)
-setup_pre_force: called before force computation in setup (optional)
-setup: called immediately before the 1st timestep and after forces are computed (optional)
-min_setup_pre_force: like setup_pre_force, but for minimizations instead of MD runs (optional)
-min_setup: like setup, but for minimizations instead of MD runs (optional)
-initial_integrate: called at very beginning of each timestep (optional)
-pre_exchange: called before atom exchange on re-neighboring steps (optional)
-pre_neighbor: called before neighbor list build (optional)
-pre_force: called before pair & molecular forces are computed (optional)
-post_force: called after pair & molecular forces are computed and communicated (optional)
-final_integrate: called at end of each timestep (optional)
-end_of_step: called at very end of timestep (optional)
-write_restart: dumps fix info to restart file (optional)
-restart: uses info from restart file to re-initialize the fix (optional)
-grow_arrays: allocate memory for atom-based arrays used by fix (optional)
-copy_arrays: copy atom info when an atom migrates to a new processor (optional)
-pack_exchange: store atom's data in a buffer (optional)
-unpack_exchange: retrieve atom's data from a buffer (optional)
-pack_restart: store atom's data for writing to restart file (optional)
-unpack_restart: retrieve atom's data from a restart file buffer (optional)
-size_restart: size of atom's data (optional)
-maxsize_restart: max size of atom's data (optional)
-setup_pre_force_respa: same as setup_pre_force, but for rRESPA (optional)
-initial_integrate_respa: same as initial_integrate, but for rRESPA (optional)
-post_integrate_respa: called after the first half integration step is done in rRESPA (optional)
-pre_force_respa: same as pre_force, but for rRESPA (optional)
-post_force_respa: same as post_force, but for rRESPA (optional)
-final_integrate_respa: same as final_integrate, but for rRESPA (optional)
-min_pre_force: called after pair & molecular forces are computed in minimizer (optional)
-min_post_force: called after pair & molecular forces are computed and communicated in minimizer (optional)
-min_store: store extra data for linesearch based minimization on a LIFO stack (optional)
-min_pushstore: push the minimization LIFO stack one element down (optional)
-min_popstore: pop the minimization LIFO stack one element up (optional)
-min_clearstore: clear minimization LIFO stack (optional)
-min_step: reset or move forward on line search minimization (optional)
-min_dof: report number of degrees of freedom {added} by this fix in minimization (optional)
-max_alpha: report maximum allowed step size during linesearch minimization (optional)
-pack_comm: pack a buffer to communicate a per-atom quantity (optional)
-unpack_comm: unpack a buffer to communicate a per-atom quantity (optional)
-pack_reverse_comm: pack a buffer to reverse communicate a per-atom quantity (optional)
-unpack_reverse_comm: unpack a buffer to reverse communicate a per-atom quantity (optional)
-dof: report number of degrees of freedom {removed} by this fix during MD (optional)
-compute_scalar: return a global scalar property that the fix computes (optional)
-compute_vector: return a component of a vector property that the fix computes (optional)
-compute_array: return a component of an array property that the fix computes (optional)
-deform: called when the box size is changed (optional)
-reset_target: called when a change of the target temperature is requested during a run (optional)
-reset_dt: is called when a change of the time step is requested during a run (optional)
-modify_param: called when a fix_modify request is executed (optional)
-memory_usage: report memory used by fix (optional)
-thermo: compute quantities for thermodynamic output (optional) :tb(s=:)
-
-Typically, only a small fraction of these methods are defined for a
-particular fix. Setmask is mandatory, as it determines when the fix
-will be invoked during the timestep. Fixes that perform time
-integration ({nve}, {nvt}, {npt}) implement initial_integrate() and
-final_integrate() to perform velocity Verlet updates. Fixes that
-constrain forces implement post_force().
-
-Fixes that perform diagnostics typically implement end_of_step(). For
-an end_of_step fix, one of your fix arguments must be the variable
-"nevery" which is used to determine when to call the fix and you must
-set this variable in the constructor of your fix. By convention, this
-is the first argument the fix defines (after the ID, group-ID, style).
-
-If the fix needs to store information for each atom that persists from
-timestep to timestep, it can manage that memory and migrate the info
-with the atoms as they move from processors to processor by
-implementing the grow_arrays, copy_arrays, pack_exchange, and
-unpack_exchange methods. Similarly, the pack_restart and
-unpack_restart methods can be implemented to store information about
-the fix in restart files. If you wish an integrator or force
-constraint fix to work with rRESPA (see the "run_style"_run_style.html
-command), the initial_integrate, post_force_integrate, and
-final_integrate_respa methods can be implemented. The thermo method
-enables a fix to contribute values to thermodynamic output, as printed
-quantities and/or to be summed to the potential energy of the system.
-
-:line
-
-10.7 Input script commands :link(mod_7),h4
-
-New commands can be added to LAMMPS input scripts by adding new
-classes that have a "command" method. For example, the create_atoms,
-read_data, velocity, and run commands are all implemented in this
-fashion. When such a command is encountered in the LAMMPS input
-script, LAMMPS simply creates a class with the corresponding name,
-invokes the "command" method of the class, and passes it the arguments
-from the input script. The command method can perform whatever
-operations it wishes on LAMMPS data structures.
-
-The single method your new class must define is as follows:
-
-command: operations performed by the new command :tb(s=:)
-
-Of course, the new class can define other methods and variables as
-needed.
-
-:line
-
-10.8 Kspace computations :link(mod_8),h4
-
-Classes that compute long-range Coulombic interactions via K-space
-representations (Ewald, PPPM) are derived from the KSpace class. New
-styles can be created to add new K-space options to LAMMPS.
-
-Ewald.cpp is an example of computing K-space interactions.
-
-Here is a brief description of methods you define in your new derived
-class. See kspace.h for details.
-
-init: initialize the calculation before a run
-setup: computation before the 1st timestep of a run
-compute: every-timestep computation
-memory_usage: tally of memory usage :tb(s=:)
-
-:line
-
-10.9 Minimization styles :link(mod_9),h4
-
-Classes that perform energy minimization derived from the Min class.
-New styles can be created to add new minimization algorithms to
-LAMMPS.
-
-Min_cg.cpp is an example of conjugate gradient minimization.
-
-Here is a brief description of methods you define in your new derived
-class. See min.h for details.
-
-init: initialize the minimization before a run
-run: perform the minimization
-memory_usage: tally of memory usage :tb(s=:)
-
-:line
-
-10.10 Pairwise potentials :link(mod_10),h4
-
-Classes that compute pairwise interactions are derived from the Pair
-class. In LAMMPS, pairwise calculation include manybody potentials
-such as EAM or Tersoff where particles interact without a static bond
-topology. New styles can be created to add new pair potentials to
-LAMMPS.
-
-Pair_lj_cut.cpp is a simple example of a Pair class, though it
-includes some optional methods to enable its use with rRESPA.
-
-Here is a brief description of the class methods in pair.h:
-
-compute: workhorse routine that computes pairwise interactions
-settings: reads the input script line with arguments you define
-coeff: set coefficients for one i,j type pair
-init_one: perform initialization for one i,j type pair
-init_style: initialization specific to this pair style
-write & read_restart: write/read i,j pair coeffs to restart files
-write & read_restart_settings: write/read global settings to restart files
-single: force and energy of a single pairwise interaction between 2 atoms
-compute_inner/middle/outer: versions of compute used by rRESPA :tb(s=:)
-
-The inner/middle/outer routines are optional.
-
-:line
-
-10.11 Region styles :link(mod_11),h4
-
-Classes that define geometric regions are derived from the Region
-class. Regions are used elsewhere in LAMMPS to group atoms, delete
-atoms to create a void, insert atoms in a specified region, etc. New
-styles can be created to add new region shapes to LAMMPS.
-
-Region_sphere.cpp is an example of a spherical region.
-
-Here is a brief description of methods you define in your new derived
-class. See region.h for details.
-
-inside: determine whether a point is in the region
-surface_interior: determine if a point is within a cutoff distance inside of surc
-surface_exterior: determine if a point is within a cutoff distance outside of surf
-shape_update : change region shape if set by time-dependent variable :tb(s=:)
-
-:line
-
-10.12 Body styles :link(mod_12),h4
-
-Classes that define body particles are derived from the Body class.
-Body particles can represent complex entities, such as surface meshes
-of discrete points, collections of sub-particles, deformable objects,
-etc.
-
-See "Section 6.14"_Section_howto.html#howto_14 of the manual for
-an overview of using body particles and the "body"_body.html doc page
-for details on the various body styles LAMMPS supports. New styles
-can be created to add new kinds of body particles to LAMMPS.
-
-Body_nparticle.cpp is an example of a body particle that is treated as
-a rigid body containing N sub-particles.
-
-Here is a brief description of methods you define in your new derived
-class. See body.h for details.
-
-data_body: process a line from the Bodies section of a data file
-noutrow: number of sub-particles output is generated for
-noutcol: number of values per-sub-particle output is generated for
-output: output values for the Mth sub-particle
-pack_comm_body: body attributes to communicate every timestep
-unpack_comm_body: unpacking of those attributes
-pack_border_body: body attributes to communicate when reneighboring is done
-unpack_border_body: unpacking of those attributes :tb(s=:)
-
-:line
-
-10.13 Thermodynamic output options :link(mod_13),h4
-
-There is one class that computes and prints thermodynamic information
-to the screen and log file; see the file thermo.cpp.
-
-There are two styles defined in thermo.cpp: "one" and "multi". There
-is also a flexible "custom" style which allows the user to explicitly
-list keywords for quantities to print when thermodynamic info is
-output. See the "thermo_style"_thermo_style.html command for a list
-of defined quantities.
-
-The thermo styles (one, multi, etc) are simply lists of keywords.
-Adding a new style thus only requires defining a new list of keywords.
-Search for the word "customize" with references to "thermo style" in
-thermo.cpp to see the two locations where code will need to be added.
-
-New keywords can also be added to thermo.cpp to compute new quantities
-for output. Search for the word "customize" with references to
-"keyword" in thermo.cpp to see the several locations where code will
-need to be added.
-
-Note that the "thermo_style custom"_thermo.html command already allows
-for thermo output of quantities calculated by "fixes"_fix.html,
-"computes"_compute.html, and "variables"_variable.html. Thus, it may
-be simpler to compute what you wish via one of those constructs, than
-by adding a new keyword to the thermo command.
-
-:line
-
-10.14 Variable options :link(mod_14),h4
-
-There is one class that computes and stores "variable"_variable.html
-information in LAMMPS; see the file variable.cpp. The value
-associated with a variable can be periodically printed to the screen
-via the "print"_print.html, "fix print"_fix_print.html, or
-"thermo_style custom"_thermo_style.html commands. Variables of style
-"equal" can compute complex equations that involve the following types
-of arguments:
-
-thermo keywords = ke, vol, atoms, ...
-other variables = v_a, v_myvar, ...
-math functions = div(x,y), mult(x,y), add(x,y), ...
-group functions = mass(group), xcm(group,x), ...
-atom values = x\[123\], y\[3\], vx\[34\], ...
-compute values = c_mytemp\[0\], c_thermo_press\[3\], ... :pre
-
-Adding keywords for the "thermo_style custom"_thermo_style.html command
-(which can then be accessed by variables) was discussed
-"here"_Section_modify.html#mod_13 on this page.
-
-Adding a new math function of one or two arguments can be done by
-editing one section of the Variable::evaluate() method. Search for
-the word "customize" to find the appropriate location.
-
-Adding a new group function can be done by editing one section of the
-Variable::evaluate() method. Search for the word "customize" to find
-the appropriate location. You may need to add a new method to the
-Group class as well (see the group.cpp file).
-
-Accessing a new atom-based vector can be done by editing one section
-of the Variable::evaluate() method. Search for the word "customize"
-to find the appropriate location.
-
-Adding new "compute styles"_compute.html (whose calculated values can
-then be accessed by variables) was discussed
-"here"_Section_modify.html#mod_3 on this page.
-
-:line
-:line
-
-10.15 Submitting new features for inclusion in LAMMPS :link(mod_15),h4
-
-We encourage users to submit new features or modifications for
-LAMMPS to "the core developers"_http://lammps.sandia.gov/authors.html
-so they can be added to the LAMMPS distribution. The preferred way to
-manage and coordinate this is as of Fall 2016 via the LAMMPS project on
-"GitHub"_https://github.com/lammps/lammps. An alternative is to contact
-the LAMMPS developers or the indicated developer of a package or feature
-directly and send in your contribution via e-mail.
-
-For any larger modifications or programming project, you are encouraged
-to contact the LAMMPS developers ahead of time, in order to discuss
-implementation strategies and coding guidelines, that will make it
-easier to integrate your contribution and result in less work for
-everybody involved. You are also encouraged to search through the list
-of "open issues on GitHub"_https://github.com/lammps/lammps/issues and
-submit a new issue for a planned feature, so you would not duplicate
-the work of others (and possibly get scooped by them) or have your work
-duplicated by others.
-
-How quickly your contribution will be integrated
-depends largely on how much effort it will cause to integrate and test
-it, how much it requires changes to the core codebase, and of how much
-interest it is to the larger LAMMPS community. Please see below for a
-checklist of typical requirements. Once you have prepared everything,
-see "this tutorial"_tutorial_github.html for instructions on how to
-submit your changes or new files through a GitHub pull request. If you
-prefer to submit patches or full files, you should first make certain,
-that your code works correctly with the latest patch-level version of
-LAMMPS and contains all bugfixes from it. Then create a gzipped tar
-file of all changed or added files or a corresponding patch file using
-'diff -u' or 'diff -c' and compress it with gzip. Please only use
-gzip compression, as this works well on all platforms.
-
-If the new features/files are broadly useful we may add them as core
-files to LAMMPS or as part of a "standard
-package"_Section_start.html#start_3. Else we will add them as a
-user-contributed file or package. Examples of user packages are in
-src sub-directories that start with USER. The USER-MISC package is
-simply a collection of (mostly) unrelated single files, which is the
-simplest way to have your contribution quickly added to the LAMMPS
-distribution. You can see a list of the both standard and user
-packages by typing "make package" in the LAMMPS src directory.
-
-Note that by providing us files to release, you are agreeing to make
-them open-source, i.e. we can release them under the terms of the GPL,
-used as a license for the rest of LAMMPS. See "Section
-1.4"_Section_intro.html#intro_4 for details.
-
-With user packages and files, all we are really providing (aside from
-the fame and fortune that accompanies having your name in the source
-code and on the "Authors page"_http://lammps.sandia.gov/authors.html
-of the "LAMMPS WWW site"_lws), is a means for you to distribute your
-work to the LAMMPS user community, and a mechanism for others to
-easily try out your new feature. This may help you find bugs or make
-contact with new collaborators. Note that you're also implicitly
-agreeing to support your code which means answer questions, fix bugs,
-and maintain it if LAMMPS changes in some way that breaks it (an
-unusual event).
-
-NOTE: If you prefer to actively develop and support your add-on
-feature yourself, then you may wish to make it available for download
-from your own website, as a user package that LAMMPS users can add to
-their copy of LAMMPS. See the "Offsite LAMMPS packages and
-tools"_http://lammps.sandia.gov/offsite.html page of the LAMMPS web
-site for examples of groups that do this. We are happy to advertise
-your package and web site from that page. Simply email the
-"developers"_http://lammps.sandia.gov/authors.html with info about
-your package and we will post it there.
-
-The previous sections of this doc page describe how to add new "style"
-files of various kinds to LAMMPS. Packages are simply collections of
-one or more new class files which are invoked as a new style within a
-LAMMPS input script. If designed correctly, these additions typically
-do not require changes to the main core of LAMMPS; they are simply
-add-on files. If you think your new feature requires non-trivial
-changes in core LAMMPS files, you'll need to "communicate with the
-developers"_http://lammps.sandia.gov/authors.html, since we may or may
-not want to make those changes. An example of a trivial change is
-making a parent-class method "virtual" when you derive a new child
-class from it.
-
-Here is a checklist of steps you need to follow to submit a single file
-or user package for our consideration. Following these steps will save
-both you and us time. See existing files in packages in the src dir for
-examples. If you are uncertain, please ask.
-
-All source files you provide must compile with the most current
-version of LAMMPS with multiple configurations. In particular you
-need to test compiling LAMMPS from scratch with -DLAMMPS_BIGBIG
-set in addition to the default -DLAMMPS_SMALLBIG setting. Your code
-will need to work correctly in serial and in parallel using MPI. :ulb,l
-
-For consistency with the rest of LAMMPS and especially, if you want
-your contribution(s) to be added to main LAMMPS code or one of its
-standard packages, it needs to be written in a style compatible with
-other LAMMPS source files. This means: 2-character indentation per
-level, [no tabs], no lines over 80 characters. I/O is done via
-the C-style stdio library, class header files should not import any
-system headers outside <stdio.h>, STL containers should be avoided
-in headers, and forward declarations used where possible or needed.
-All added code should be placed into the LAMMPS_NS namespace or a
-sub-namespace; global or static variables should be avoided, as they
-conflict with the modular nature of LAMMPS and the C++ class structure.
-Header files must [not] import namespaces with {using}.
-This all is so the developers can more easily understand, integrate,
-and maintain your contribution and reduce conflicts with other parts
-of LAMMPS. This basically means that the code accesses data
-structures, performs its operations, and is formatted similar to other
-LAMMPS source files, including the use of the error class for error
-and warning messages. :l
-
-If you want your contribution to be added as a user-contributed
-feature, and it's a single file (actually a *.cpp and *.h file) it can
-rapidly be added to the USER-MISC directory. Send us the one-line
-entry to add to the USER-MISC/README file in that dir, along with the
-2 source files. You can do this multiple times if you wish to
-contribute several individual features. :l
-
-If you want your contribution to be added as a user-contribution and
-it is several related features, it is probably best to make it a user
-package directory with a name like USER-FOO. In addition to your new
-files, the directory should contain a README text file. The README
-should contain your name and contact information and a brief
-description of what your new package does. If your files depend on
-other LAMMPS style files also being installed (e.g. because your file
-is a derived class from the other LAMMPS class), then an Install.sh
-file is also needed to check for those dependencies. See other README
-and Install.sh files in other USER directories as examples. Send us a
-tarball of this USER-FOO directory. :l
-
-Your new source files need to have the LAMMPS copyright, GPL notice,
-and your name and email address at the top, like other
-user-contributed LAMMPS source files. They need to create a class
-that is inside the LAMMPS namespace. If the file is for one of the
-USER packages, including USER-MISC, then we are not as picky about the
-coding style (see above). I.e. the files do not need to be in the
-same stylistic format and syntax as other LAMMPS files, though that
-would be nice for developers as well as users who try to read your
-code. :l
-
-You [must] also create a [documentation] file for each new command or
-style you are adding to LAMMPS. For simplicity and convenience, the
-documentation of groups of closely related commands or styles may be
-combined into a single file. This will be one file for a single-file
-feature. For a package, it might be several files. These are simple
-text files with a specific markup language, that are then auto-converted
-to HTML and PDF. The tools for this conversion are included in the
-source distribution, and the translation can be as simple as doing
-"make html pdf" in the doc folder.
-Thus the documentation source files must be in the same format and
-style as other *.txt files in the lammps/doc/src directory for similar
-commands and styles; use one or more of them as a starting point.
-A description of the markup can also be found in
-lammps/doc/utils/txt2html/README.html
-As appropriate, the text files can include links to equations
-(see doc/Eqs/*.tex for examples, we auto-create the associated JPG
-files), or figures (see doc/JPG for examples), or even additional PDF
-files with further details (see doc/PDF for examples). The doc page
-should also include literature citations as appropriate; see the
-bottom of doc/fix_nh.txt for examples and the earlier part of the same
-file for how to format the cite itself. The "Restrictions" section of
-the doc page should indicate that your command is only available if
-LAMMPS is built with the appropriate USER-MISC or USER-FOO package.
-See other user package doc files for examples of how to do this. The
-prerequisite for building the HTML format files are Python 3.x and
-virtualenv, the requirement for generating the PDF format manual
-is the "htmldoc"_http://www.htmldoc.org/ software. Please run at least
-"make html" and carefully inspect and proofread the resulting HTML format
-doc page before submitting your code. :l
-
-For a new package (or even a single command) you should include one or
-more example scripts demonstrating its use. These should run in no
-more than a couple minutes, even on a single processor, and not require
-large data files as input. See directories under examples/USER for
-examples of input scripts other users provided for their packages.
-These example inputs are also required for validating memory accesses
-and testing for memory leaks with valgrind :l
-
-If there is a paper of yours describing your feature (either the
-algorithm/science behind the feature itself, or its initial usage, or
-its implementation in LAMMPS), you can add the citation to the *.cpp
-source file. See src/USER-EFF/atom_vec_electron.cpp for an example.
-A LaTeX citation is stored in a variable at the top of the file and a
-single line of code that references the variable is added to the
-constructor of the class. Whenever a user invokes your feature from
-their input script, this will cause LAMMPS to output the citation to a
-log.cite file and prompt the user to examine the file. Note that you
-should only use this for a paper you or your group authored.
-E.g. adding a cite in the code for a paper by Nose and Hoover if you
-write a fix that implements their integrator is not the intended
-usage. That kind of citation should just be in the doc page you
-provide. :l
-:ule
-
-Finally, as a general rule-of-thumb, the more clear and
-self-explanatory you make your documentation and README files, and the
-easier you make it for people to get started, e.g. by providing example
-scripts, the more likely it is that users will try out your new feature.
-
-:line
-:line
-
-:link(Foo)
-[(Foo)] Foo, Morefoo, and Maxfoo, J of Classic Potentials, 75, 345 (1997).
diff --git a/doc/src/Section_packages.txt b/doc/src/Section_packages.txt
deleted file mode 100644
index 218866e2715b88794c6c0bb46b1fea7658230538..0000000000000000000000000000000000000000
--- a/doc/src/Section_packages.txt
+++ /dev/null
@@ -1,2955 +0,0 @@
-"Previous Section"_Section_commands.html - "LAMMPS WWW Site"_lws -
-"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
-Section"_Section_accelerate.html :c
-
-:link(lws,http://lammps.sandia.gov)
-:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
-
-:line
-
-4. Packages :h2
-
-This section gives an overview of the optional packages that extend
-LAMMPS functionality with instructions on how to build LAMMPS with
-each of them. Packages are groups of files that enable a specific set
-of features. For example, force fields for molecular systems or
-granular systems are in packages. You can see the list of all
-packages and "make" commands to manage them by typing "make package"
-from within the src directory of the LAMMPS distribution. "Section
-2.3"_Section_start.html#start_3 gives general info on how to install
-and un-install packages as part of the LAMMPS build process.
-
-There are two kinds of packages in LAMMPS, standard and user packages:
-
-"Table of standard packages"_#table_standard
-"Table of user packages"_#table_user :ul
-
-Either of these kinds of packages may work as is, may require some
-additional code compiled located in the lib folder, or may require
-an external library to be downloaded, compiled, installed, and LAMMPS
-configured to know about its location and additional compiler flags.
-You can often do the build of the internal or external libraries
-in one step by typing "make lib-name args='...'" from the src dir,
-with appropriate arguments included in args='...'. If you just type
-"make lib-name" you should see a help message about supported flags
-and some examples. For more details about this, please study the
-tables below and the sections about the individual packages.
-
-Standard packages are supported by the LAMMPS developers and are
-written in a syntax and style consistent with the rest of LAMMPS.
-This means the developers will answer questions about them, debug and
-fix them if necessary, and keep them compatible with future changes to
-LAMMPS.
-
-User packages have been contributed by users, and begin with the
-"user" prefix. If they are a single command (single file), they are
-typically in the user-misc package. User packages don't necessarily
-meet the requirements of the standard packages. This means the
-developers will try to keep things working and usually can answer
-technical questions about compiling the package. If you have problems
-using a feature provided in a user package, you may need to contact
-the contributor directly to get help. Information on how to submit
-additions you make to LAMMPS as single files or as a standard or user
-package are given in "this section"_Section_modify.html#mod_15 of the
-manual.
-
-Following the next two tables is a sub-section for each package. It
-lists authors (if applicable) and summarizes the package contents. It
-has specific instructions on how to install the package, including (if
-necessary) downloading or building any extra library it requires. It
-also gives links to documentation, example scripts, and
-pictures/movies (if available) that illustrate use of the package.
-
-NOTE: To see the complete list of commands a package adds to LAMMPS,
-just look at the files in its src directory, e.g. "ls src/GRANULAR".
-Files with names that start with fix, compute, atom, pair, bond,
-angle, etc correspond to commands with the same style names.
-
-In these two tables, the "Example" column is a sub-directory in the
-examples directory of the distribution which has an input script that
-uses the package. E.g. "peptide" refers to the examples/peptide
-directory; USER/atc refers to the examples/USER/atc directory. The
-"Library" column indicates whether an extra library is needed to build
-and use the package:
-
-dash = no library
-sys = system library: you likely have it on your machine
-int = internal library: provided with LAMMPS, but you may need to build it
-ext = external library: you will need to download and install it on your machine :ul
-
-:line
-:line
-
-[Standard packages] :link(table_standard),p
-
-Package, Description, Doc page, Example, Library
-"ASPHERE"_#ASPHERE, aspherical particle models, "Section 6.6.14"_Section_howto.html#howto_14, ellipse, -
-"BODY"_#BODY, body-style particles, "body"_body.html, body, -
-"CLASS2"_#CLASS2, class 2 force fields, "pair_style lj/class2"_pair_class2.html, -, -
-"COLLOID"_#COLLOID, colloidal particles, "atom_style colloid"_atom_style.html, colloid, -
-"COMPRESS"_#COMPRESS, I/O compression, "dump */gz"_dump.html, -, sys
-"CORESHELL"_#CORESHELL, adiabatic core/shell model, "Section 6.6.25"_Section_howto.html#howto_25, coreshell, -
-"DIPOLE"_#DIPOLE, point dipole particles, "pair_style dipole/cut"_pair_dipole.html, dipole, -
-"GPU"_#GPU, GPU-enabled styles, "Section 5.3.1"_accelerate_gpu.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, int
-"GRANULAR"_#GRANULAR, granular systems, "Section 6.6.6"_Section_howto.html#howto_6, pour, -
-"KIM"_#KIM, OpenKIM wrapper, "pair_style kim"_pair_kim.html, kim, ext
-"KOKKOS"_#KOKKOS, Kokkos-enabled styles, "Section 5.3.3"_accelerate_kokkos.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, -
-"KSPACE"_#KSPACE, long-range Coulombic solvers, "kspace_style"_kspace_style.html, peptide, -
-"LATTE"_#LATTE, quantum DFTB forces via LATTE, "fix latte"_fix_latte.html, latte, ext
-"MANYBODY"_#MANYBODY, many-body potentials, "pair_style tersoff"_pair_tersoff.html, shear, -
-"MC"_#MC, Monte Carlo options, "fix gcmc"_fix_gcmc.html, -, -
-"MEAM"_#MEAM, modified EAM potential, "pair_style meam"_pair_meam.html, meam, int
-"MISC"_#MISC, miscellanous single-file commands, -, -, -
-"MOLECULE"_#MOLECULE, molecular system force fields, "Section 6.6.3"_Section_howto.html#howto_3, peptide, -
-"MPIIO"_#MPIIO, MPI parallel I/O dump and restart, "dump"_dump.html, -, -
-"MSCG"_#MSCG, multi-scale coarse-graining wrapper, "fix mscg"_fix_mscg.html, mscg, ext
-"OPT"_#OPT, optimized pair styles, "Section 5.3.5"_accelerate_opt.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, -
-"PERI"_#PERI, Peridynamics models, "pair_style peri"_pair_peri.html, peri, -
-"POEMS"_#POEMS, coupled rigid body motion, "fix poems"_fix_poems.html, rigid, int
-"PYTHON"_#PYTHON, embed Python code in an input script, "python"_python.html, python, sys
-"QEQ"_#QEQ, QEq charge equilibration, "fix qeq"_fix_qeq.html, qeq, -
-"REAX"_#REAX, ReaxFF potential (Fortran), "pair_style reax"_pair_reax.html, reax, int
-"REPLICA"_#REPLICA, multi-replica methods, "Section 6.6.5"_Section_howto.html#howto_5, tad, -
-"RIGID"_#RIGID, rigid bodies and constraints, "fix rigid"_fix_rigid.html, rigid, -
-"SHOCK"_#SHOCK, shock loading methods, "fix msst"_fix_msst.html, -, -
-"SNAP"_#SNAP, quantum-fitted potential, "pair_style snap"_pair_snap.html, snap, -
-"SPIN"_#SPIN, magnetic atomic spin dynamics, "Section 6.6.28"_Section_howto.html#howto_28, SPIN, -
-"SRD"_#SRD, stochastic rotation dynamics, "fix srd"_fix_srd.html, srd, -
-"VORONOI"_#VORONOI, Voronoi tesselation, "compute voronoi/atom"_compute_voronoi_atom.html, -, ext :tb(ea=c,ca1=l)
-
-[USER packages] :link(table_user),p
-
-Package, Description, Doc page, Example, Library
-"USER-ATC"_#USER-ATC, atom-to-continuum coupling, "fix atc"_fix_atc.html, USER/atc, int
-"USER-AWPMD"_#USER-AWPMD, wave-packet MD, "pair_style awpmd/cut"_pair_awpmd.html, USER/awpmd, int
-"USER-BOCS"_#USER-BOCS, BOCS bottom up coarse graining, "fix bocs"_fix_bocs.html, USER/bocs, -
-"USER-CGDNA"_#USER-CGDNA, coarse-grained DNA force fields, src/USER-CGDNA/README, USER/cgdna, -
-"USER-CGSDK"_#USER-CGSDK, SDK coarse-graining model, "pair_style lj/sdk"_pair_sdk.html, USER/cgsdk, -
-"USER-COLVARS"_#USER-COLVARS, collective variables library, "fix colvars"_fix_colvars.html, USER/colvars, int
-"USER-DIFFRACTION"_#USER-DIFFRACTION, virtual x-ray and electron diffraction,"compute xrd"_compute_xrd.html, USER/diffraction, -
-"USER-DPD"_#USER-DPD, reactive dissipative particle dynamics, src/USER-DPD/README, USER/dpd, -
-"USER-DRUDE"_#USER-DRUDE, Drude oscillators, "tutorial"_tutorial_drude.html, USER/drude, -
-"USER-EFF"_#USER-EFF, electron force field,"pair_style eff/cut"_pair_eff.html, USER/eff, -
-"USER-FEP"_#USER-FEP, free energy perturbation,"compute fep"_compute_fep.html, USER/fep, -
-"USER-H5MD"_#USER-H5MD, dump output via HDF5,"dump h5md"_dump_h5md.html, -, ext
-"USER-INTEL"_#USER-INTEL, optimized Intel CPU and KNL styles,"Section 5.3.2"_accelerate_intel.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, -
-"USER-LB"_#USER-LB, Lattice Boltzmann fluid,"fix lb/fluid"_fix_lb_fluid.html, USER/lb, -
-"USER-MANIFOLD"_#USER-MANIFOLD, motion on 2d surfaces,"fix manifoldforce"_fix_manifoldforce.html, USER/manifold, -
-"USER-MEAMC"_#USER-MEAMC, modified EAM potential (C++), "pair_style meam/c"_pair_meam.html, meam, -
-"USER-MESO"_#USER-MESO, mesoscale DPD models, "pair_style edpd"_pair_meso.html, USER/meso, -
-"USER-MGPT"_#USER-MGPT, fast MGPT multi-ion potentials, "pair_style mgpt"_pair_mgpt.html, USER/mgpt, -
-"USER-MISC"_#USER-MISC, single-file contributions, USER-MISC/README, USER/misc, -
-"USER-MOFFF"_#USER-MOFFF, styles for "MOF-FF"_MOFplus force field, "pair_style buck6d/coul/gauss"_pair_buck6d_coul_gauss.html, USER/mofff, -
-"USER-MOLFILE"_#USER-MOLFILE, "VMD"_vmd_home molfile plug-ins,"dump molfile"_dump_molfile.html, -, ext
-"USER-NETCDF"_#USER-NETCDF, dump output via NetCDF,"dump netcdf"_dump_netcdf.html, -, ext
-"USER-OMP"_#USER-OMP, OpenMP-enabled styles,"Section 5.3.4"_accelerate_omp.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, -
-"USER-PHONON"_#USER-PHONON, phonon dynamical matrix,"fix phonon"_fix_phonon.html, USER/phonon, -
-"USER-QMMM"_#USER-QMMM, QM/MM coupling,"fix qmmm"_fix_qmmm.html, USER/qmmm, ext
-"USER-QTB"_#USER-QTB, quantum nuclear effects,"fix qtb"_fix_qtb.html "fix qbmsst"_fix_qbmsst.html, qtb, -
-"USER-QUIP"_#USER-QUIP, QUIP/libatoms interface,"pair_style quip"_pair_quip.html, USER/quip, ext
-"USER-REAXC"_#USER-REAXC, ReaxFF potential (C/C++) ,"pair_style reaxc"_pair_reaxc.html, reax, -
-"USER-SMD"_#USER-SMD, smoothed Mach dynamics,"SMD User Guide"_PDF/SMD_LAMMPS_userguide.pdf, USER/smd, ext
-"USER-SMTBQ"_#USER-SMTBQ, second moment tight binding QEq potential,"pair_style smtbq"_pair_smtbq.html, USER/smtbq, -
-"USER-SPH"_#USER-SPH, smoothed particle hydrodynamics,"SPH User Guide"_PDF/SPH_LAMMPS_userguide.pdf, USER/sph, -
-"USER-TALLY"_#USER-TALLY, pairwise tally computes,"compute XXX/tally"_compute_tally.html, USER/tally, -
-"USER-UEF"_#USER-UEF, extensional flow,"fix nvt/uef"_fix_nh_uef.html, USER/uef, -
-"USER-VTK"_#USER-VTK, dump output via VTK, "compute vtk"_dump_vtk.html, -, ext :tb(ea=c,ca1=l)
-
-:line
-:line
-
-ASPHERE package :link(ASPHERE),h4
-
-[Contents:]
-
-Computes, time-integration fixes, and pair styles for aspherical
-particle models including ellipsoids, 2d lines, and 3d triangles.
-
-[Install or un-install:]
-
-make yes-asphere
-make machine :pre
-
-make no-asphere
-make machine :pre
-
-[Supporting info:]
-
-src/ASPHERE: filenames -> commands
-"Section 6.14"_Section_howto.html#howto_14
-"pair_style gayberne"_pair_gayberne.html
-"pair_style resquared"_pair_resquared.html
-"doc/PDF/pair_gayberne_extra.pdf"_PDF/pair_gayberne_extra.pdf
-"doc/PDF/pair_resquared_extra.pdf"_PDF/pair_resquared_extra.pdf
-examples/ASPHERE
-examples/ellipse
-http://lammps.sandia.gov/movies.html#line
-http://lammps.sandia.gov/movies.html#tri :ul
-
-:line
-
-BODY package :link(BODY),h4
-
-[Contents:]
-
-Body-style particles with internal structure. Computes,
-time-integration fixes, pair styles, as well as the body styles
-themselves. See the "body"_body.html doc page for an overview.
-
-[Install or un-install:]
-
-make yes-body
-make machine :pre
-
-make no-body
-make machine :pre
-
-[Supporting info:]
-
-src/BODY filenames -> commands
-"body"_body.html
-"atom_style body"_atom_style.html
-"fix nve/body"_fix_nve_body.html
-"pair_style body"_pair_body.html
-examples/body :ul
-
-:line
-
-CLASS2 package :link(CLASS2),h4
-
-[Contents:]
-
-Bond, angle, dihedral, improper, and pair styles for the COMPASS
-CLASS2 molecular force field.
-
-[Install or un-install:]
-
-make yes-class2
-make machine :pre
-
-make no-class2
-make machine :pre
-
-[Supporting info:]
-
-src/CLASS2: filenames -> commands
-"bond_style class2"_bond_class2.html
-"angle_style class2"_angle_class2.html
-"dihedral_style class2"_dihedral_class2.html
-"improper_style class2"_improper_class2.html
-"pair_style lj/class2"_pair_class2.html :ul
-
-:line
-
-COLLOID package :link(COLLOID),h4
-
-[Contents:]
-
-Coarse-grained finite-size colloidal particles. Pair styles and fix
-wall styles for colloidal interactions. Includes the Fast Lubrication
-Dynamics (FLD) method for hydrodynamic interactions, which is a
-simplified approximation to Stokesian dynamics.
-
-[Authors:] This package includes Fast Lubrication Dynamics pair styles
-which were created by Amit Kumar and Michael Bybee from Jonathan
-Higdon's group at UIUC.
-
-[Install or un-install:]
-
-make yes-colloid
-make machine :pre
-
-make no-colloid
-make machine :pre
-
-[Supporting info:]
-
-src/COLLOID: filenames -> commands
-"fix wall/colloid"_fix_wall.html
-"pair_style colloid"_pair_colloid.html
-"pair_style yukawa/colloid"_pair_yukawa_colloid.html
-"pair_style brownian"_pair_brownian.html
-"pair_style lubricate"_pair_lubricate.html
-"pair_style lubricateU"_pair_lubricateU.html
-examples/colloid
-examples/srd :ul
-
-:line
-
-COMPRESS package :link(COMPRESS),h4
-
-[Contents:]
-
-Compressed output of dump files via the zlib compression library,
-using dump styles with a "gz" in their style name.
-
-To use this package you must have the zlib compression library
-available on your system.
-
-[Author:] Axel Kohlmeyer (Temple U).
-
-[Install or un-install:]
-
-Note that building with this package assumes you have the zlib
-compression library available on your system. The LAMMPS build uses
-the settings in the lib/compress/Makefile.lammps file in the
-compile/link process. You should only need to edit this file if the
-LAMMPS build fails on your system.
-
-make yes-compress
-make machine :pre
-
-make no-compress
-make machine :pre
-
-[Supporting info:]
-
-src/COMPRESS: filenames -> commands
-src/COMPRESS/README
-lib/compress/README
-"dump atom/gz"_dump.html
-"dump cfg/gz"_dump.html
-"dump custom/gz"_dump.html
-"dump xyz/gz"_dump.html :ul
-
-:line
-
-CORESHELL package :link(CORESHELL),h4
-
-[Contents:]
-
-Compute and pair styles that implement the adiabatic core/shell model
-for polarizability. The pair styles augment Born, Buckingham, and
-Lennard-Jones styles with core/shell capabilities. The "compute
-temp/cs"_compute_temp_cs.html command calculates the temperature of a
-system with core/shell particles. See "Section
-6.26"_Section_howto.html#howto_26 for an overview of how to use this
-package.
-
-[Author:] Hendrik Heenen (Technical U of Munich).
-
-[Install or un-install:]
-
-make yes-coreshell
-make machine :pre
-
-make no-coreshell
-make machine :pre
-
-[Supporting info:]
-
-src/CORESHELL: filenames -> commands
-"Section 6.26"_Section_howto.html#howto_26
-"Section 6.25"_Section_howto.html#howto_25
-"compute temp/cs"_compute_temp_cs.html
-"pair_style born/coul/long/cs"_pair_cs.html
-"pair_style buck/coul/long/cs"_pair_cs.html
-"pair_style lj/cut/coul/long/cs"_pair_lj.html
-examples/coreshell :ul
-
-:line
-
-DIPOLE package :link(DIPOLE),h4
-
-[Contents:]
-
-An atom style and several pair styles for point dipole models with
-short-range or long-range interactions.
-
-[Install or un-install:]
-
-make yes-dipole
-make machine :pre
-
-make no-dipole
-make machine :pre
-
-[Supporting info:]
-
-src/DIPOLE: filenames -> commands
-"atom_style dipole"_atom_style.html
-"pair_style lj/cut/dipole/cut"_pair_dipole.html
-"pair_style lj/cut/dipole/long"_pair_dipole.html
-"pair_style lj/long/dipole/long"_pair_dipole.html
-examples/dipole :ul
-
-:line
-
-GPU package :link(GPU),h4
-
-[Contents:]
-
-Dozens of pair styles and a version of the PPPM long-range Coulombic
-solver optimized for GPUs. All such styles have a "gpu" as a
-suffix in their style name. The GPU code can be compiled with either
-CUDA or OpenCL, however the OpenCL variants are no longer actively
-maintained and only the CUDA versions are regularly tested.
-"Section 5.3.1"_accelerate_gpu.html gives details of what
-hardware and GPU software is required on your system,
-and details on how to build and use this package. Its styles can be
-invoked at run time via the "-sf gpu" or "-suffix gpu" "command-line
-switches"_Section_start.html#start_6. See also the "KOKKOS"_#KOKKOS
-package, which has GPU-enabled styles.
-
-[Authors:] Mike Brown (Intel) while at Sandia and ORNL and Trung Nguyen
-(Northwestern U) while at ORNL.
-
-[Install or un-install:]
-
-Before building LAMMPS with this package, you must first build the GPU
-library in lib/gpu from a set of provided C and CUDA files. You can
-do this manually if you prefer; follow the instructions in
-lib/gpu/README. Please note, that the GPU library uses MPI calls, so
-you have to make certain to use the same MPI library (or the STUBS
-library) settings as the main LAMMPS code. That same applies to the
--DLAMMPS_BIGBIG, -DLAMMPS_SMALLBIG, or -DLAMMPS_SMALLSMALL define.
-
-You can also do it 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 -p mixed -b" # build GPU library with mixed precision using settings in Makefile.mpi :pre
-
-Note that this procedure through the '-m machine' flag starts with one of
-the existing Makefile.machine files in lib/gpu. 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 that
-Makefile, via the -h, -a, -p, -e switches, and also save a copy of the
-new Makefile, if desired:
-
-CUDA_HOME = where NVIDIA CUDA software is installed on your system
-CUDA_ARCH = what GPU hardware you have (see help message for details)
-CUDA_PRECISION = precision (double, mixed, single)
-EXTRAMAKE = which Makefile.lammps.* file to copy to Makefile.lammps :ul
-
-If the library build is successful, at least 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.
-
-You can then install/un-install the package and build LAMMPS in the
-usual manner:
-
-make yes-gpu
-make machine :pre
-
-make no-gpu
-make machine :pre
-
-NOTE: If you re-build the GPU library in lib/gpu, you should always
-un-install the GPU package, then re-install it and re-build LAMMPS.
-This is because the compilation of files in the GPU package use the
-library settings from the lib/gpu/Makefile.machine used to build the
-GPU library.
-
-[Supporting info:]
-
-src/GPU: filenames -> commands
-src/GPU/README
-lib/gpu/README
-"Section 5.3"_Section_accelerate.html#acc_3
-"Section 5.3.1"_accelerate_gpu.html
-"Section 2.6 -sf gpu"_Section_start.html#start_6
-"Section 2.6 -pk gpu"_Section_start.html#start_6
-"package gpu"_package.html
-Pair Styles section of "Section 3.5"_Section_commands.html#cmd_5 for pair styles followed by (g)
-"Benchmarks page"_http://lammps.sandia.gov/bench.html of web site :ul
-
-:line
-
-GRANULAR package :link(GRANULAR),h4
-
-[Contents:]
-
-Pair styles and fixes for finite-size granular particles, which
-interact with each other and boundaries via frictional and dissipative
-potentials.
-
-[Install or un-install:]
-
-make yes-granular
-make machine :pre
-
-make no-granular
-make machine :pre
-
-[Supporting info:]
-
-src/GRANULAR: filenames -> commands
-"Section 6.6"_Section_howto.html#howto_6,
-"fix pour"_fix_pour.html
-"fix wall/gran"_fix_wall_gran.html
-"pair_style gran/hooke"_pair_gran.html
-"pair_style gran/hertz/history"_pair_gran.html
-examples/granregion
-examples/pour
-bench/in.chute
-http://lammps.sandia.gov/pictures.html#jamming
-http://lammps.sandia.gov/movies.html#hopper
-http://lammps.sandia.gov/movies.html#dem
-http://lammps.sandia.gov/movies.html#brazil
-http://lammps.sandia.gov/movies.html#granregion :ul
-
-:line
-
-KIM package :link(KIM),h4
-
-[Contents:]
-
-A "pair_style kim"_pair_kim.html command which is a wrapper on the
-Knowledge Base for Interatomic Models (KIM) repository of interatomic
-potentials, enabling any of them to be used in LAMMPS simulations.
-
-To use this package you must have the KIM library available on your
-system.
-
-Information about the KIM project can be found at its website:
-https://openkim.org. The KIM project is led by Ellad Tadmor and Ryan
-Elliott (U Minnesota) and James Sethna (Cornell U).
-
-[Authors:] Ryan Elliott (U Minnesota) is the main developer for the KIM
-API which the "pair_style kim"_pair_kim.html command uses. He
-developed the pair style in collaboration with Valeriu Smirichinski (U
-Minnesota).
-
-[Install or un-install:]
-
-Before building LAMMPS with this package, you must first download and
-build the KIM library and include the KIM models that you want to
-use. You can do this 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
-
-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 in the "What is in the KIM API source
-package?" section
-
-You can then install/un-install the package and build LAMMPS in the
-usual manner:
-
-make yes-kim
-make machine :pre
-
-make no-kim
-make machine :pre
-
-[Supporting info:]
-
-src/KIM: filenames -> commands
-src/KIM/README
-lib/kim/README
-"pair_style kim"_pair_kim.html
-examples/kim :ul
-
-:line
-
-KOKKOS package :link(KOKKOS),h4
-
-[Contents:]
-
-Dozens of atom, pair, bond, angle, dihedral, improper, fix, compute
-styles adapted to compile using the Kokkos library which can convert
-them to OpenMP or CUDA code so that they run efficiently on multicore
-CPUs, KNLs, or GPUs. All the styles have a "kk" as a suffix in their
-style name. "Section 5.3.3"_accelerate_kokkos.html gives details of
-what hardware and software is required on your system, and how to
-build and use this package. Its styles can be invoked at run time via
-the "-sf kk" or "-suffix kk" "command-line
-switches"_Section_start.html#start_6. Also see the "GPU"_#GPU,
-"OPT"_#OPT, "USER-INTEL"_#USER-INTEL, and "USER-OMP"_#USER-OMP
-packages, which have styles optimized for CPUs, KNLs, and GPUs.
-
-You must have a C++11 compatible compiler to use this package.
-
-[Authors:] The KOKKOS package was created primarily by Christian Trott
-and Stan Moore (Sandia), with contributions from other folks as well.
-It uses the open-source "Kokkos library"_https://github.com/kokkos
-which was developed by Carter Edwards, Christian Trott, and others at
-Sandia, and which is included in the LAMMPS distribution in
-lib/kokkos.
-
-[Install or un-install:]
-
-For the KOKKOS package, you have 3 choices when building. You can
-build with either CPU or KNL or GPU support. Each choice requires
-additional settings in your Makefile.machine for the 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 = HSW # HSW = Haswell, SNB = SandyBridge, BDW = Broadwell, etc :pre
-
-For Intel KNLs using OpenMP:
-
-KOKKOS_DEVICES = OpenMP
-KOKKOS_ARCH = KNL :pre
-
-For NVIDIA GPUs using CUDA:
-
-KOKKOS_DEVICES = Cuda
-KOKKOS_ARCH = Pascal60,Power8 # P100 hosted by an IBM Power8, etc
-KOKKOS_ARCH = Kepler37,Power8 # K80 hosted by an IBM Power8, etc :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 or 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
-
-Once you have an appropriate Makefile.machine, you can
-install/un-install the package and build LAMMPS in the usual manner.
-Note that you cannot build one executable to run on multiple hardware
-targets (CPU or KNL or GPU). You need to build LAMMPS once for each
-hardware target, to produce a separate executable. Also note that we
-do not recommend building with other acceleration packages installed
-(GPU, OPT, USER-INTEL, USER-OMP) when also building with KOKKOS.
-
-make yes-kokkos
-make machine :pre
-
-make no-kokkos
-make machine :pre
-
-[Supporting info:]
-
-src/KOKKOS: filenames -> commands
-src/KOKKOS/README
-lib/kokkos/README
-"Section 5.3"_Section_accelerate.html#acc_3
-"Section 5.3.3"_accelerate_kokkos.html
-"Section 2.6 -k on ..."_Section_start.html#start_6
-"Section 2.6 -sf kk"_Section_start.html#start_6
-"Section 2.6 -pk kokkos"_Section_start.html#start_6
-"package kokkos"_package.html
-Styles sections of "Section 3.5"_Section_commands.html#cmd_5 for styles followed by (k)
-"Benchmarks page"_http://lammps.sandia.gov/bench.html of web site :ul
-
-:line
-
-KSPACE package :link(KSPACE),h4
-
-[Contents:]
-
-A variety of long-range Coulombic solvers, as well as pair styles
-which compute the corresponding short-range pairwise Coulombic
-interactions. These include Ewald, particle-particle particle-mesh
-(PPPM), and multilevel summation method (MSM) solvers.
-
-[Install or un-install:]
-
-Building with this package requires a 1d FFT library be present on
-your system for use by the PPPM solvers. This can be the KISS FFT
-library provided with LAMMPS, 3rd party libraries like FFTW, or a
-vendor-supplied FFT library. See step 6 of "Section
-2.2.2"_Section_start.html#start_2_2 of the manual for details on how
-to select different FFT options in your machine Makefile.
-
-make yes-kspace
-make machine :pre
-
-make no-kspace
-make machine :pre
-
-[Supporting info:]
-
-src/KSPACE: filenames -> commands
-"kspace_style"_kspace_style.html
-"doc/PDF/kspace.pdf"_PDF/kspace.pdf
-"Section 6.7"_Section_howto.html#howto_7
-"Section 6.8"_Section_howto.html#howto_8
-"Section 6.9"_Section_howto.html#howto_9
-"pair_style coul"_pair_coul.html
-Pair Styles section of "Section 3.5"_Section_commands.html#cmd_5 with "long" or "msm" in pair style name
-examples/peptide
-bench/in.rhodo :ul
-
-:line
-
-LATTE package :link(LATTE),h4
-
-[Contents:]
-
-A fix command which wraps the LATTE DFTB code, so that molecular
-dynamics can be run with LAMMPS using density-functional tight-binding
-quantum forces calculated by LATTE.
-
-More information on LATTE can be found at this web site:
-"https://github.com/lanl/LATTE"_latte_home. A brief technical
-description is given with the "fix latte"_fix_latte.html command.
-
-:link(latte_home,https://github.com/lanl/LATTE)
-
-[Authors:] Christian Negre (LANL) and Steve Plimpton (Sandia). LATTE
-itself is developed at Los Alamos National Laboratory by Marc
-Cawkwell, Anders Niklasson, and Christian Negre.
-
-[Install or un-install:]
-
-Before building LAMMPS with this package, you must first download and
-build the LATTE library. You can do this 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 builds in src 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.
-
-You can then install/un-install the package and build LAMMPS in the
-usual manner:
-
-make yes-latte
-make machine :pre
-
-make no-latte
-make machine :pre
-
-[Supporting info:]
-
-src/LATTE: filenames -> commands
-src/LATTE/README
-lib/latte/README
-"fix latte"_fix_latte.html
-examples/latte
-"LAMMPS-LATTE tutorial"_https://github.com/lanl/LATTE/wiki/Using-LATTE-through-LAMMPS :ul
-
-:line
-
-MANYBODY package :link(MANYBODY),h4
-
-[Contents:]
-
-A variety of manybody and bond-order potentials. These include
-(AI)REBO, BOP, EAM, EIM, Stillinger-Weber, and Tersoff potentials.
-
-[Install or un-install:]
-
-make yes-manybody
-make machine :pre
-
-make no-manybody
-make machine :pre
-
-[Supporting info:]
-
-src/MANYBODY: filenames -> commands
-Pair Styles section of "Section 3.5"_Section_commands.html#cmd_5
-examples/comb
-examples/eim
-examples/nb3d
-examples/shear
-examples/streitz
-examples/vashishta
-bench/in.eam :ul
-
-:line
-
-MC package :link(MC),h4
-
-[Contents:]
-
-Several fixes and a pair style that have Monte Carlo (MC) or MC-like
-attributes. These include fixes for creating, breaking, and swapping
-bonds, for performing atomic swaps, and performing grand-canonical MC
-(GCMC) in conjuction with dynamics.
-
-[Install or un-install:]
-
-make yes-mc
-make machine :pre
-
-make no-mc
-make machine :pre
-
-[Supporting info:]
-
-src/MC: filenames -> commands
-"fix atom/swap"_fix_atom_swap.html
-"fix bond/break"_fix_bond_break.html
-"fix bond/create"_fix_bond_create.html
-"fix bond/swap"_fix_bond_swap.html
-"fix gcmc"_fix_gcmc.html
-"pair_style dsmc"_pair_dsmc.html
-http://lammps.sandia.gov/movies.html#gcmc :ul
-
-:line
-
-MEAM package :link(MEAM),h4
-
-[Contents:]
-
-A pair style for the modified embedded atom (MEAM) potential.
-
-Please note that the MEAM package has been superseded by the
-"USER-MEAMC"_#USER-MEAMC package, which is a direct translation
-of the MEAM package to C++. USER-MEAMC contains additional
-optimizations making it run faster than MEAM on most machines,
-while providing the identical features and USER interface.
-
-[Author:] Greg Wagner (Northwestern U) while at Sandia.
-
-[Install or un-install:]
-
-Before building LAMMPS with this package, you must first build the
-MEAM library in lib/meam. You can do this 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.
-
-You can then install/un-install the package and build LAMMPS in the
-usual manner:
-
-make yes-meam
-make machine :pre
-
-make no-meam
-make machine :pre
-
-NOTE: You should test building the MEAM library with both the Intel
-and GNU compilers to see if a simulation runs faster with one versus
-the other on your system.
-
-[Supporting info:]
-
-src/MEAM: filenames -> commands
-src/meam/README
-lib/meam/README
-"pair_style meam"_pair_meam.html
-examples/meam :ul
-
-:line
-
-MISC package :link(MISC),h4
-
-[Contents:]
-
-A variety of compute, fix, pair, dump styles with specialized
-capabilities that don't align with other packages. Do a directory
-listing, "ls src/MISC", to see the list of commands.
-
-NOTE: the MISC package contains styles that require using the
--restrict flag, when compiling with Intel compilers.
-
-[Install or un-install:]
-
-make yes-misc
-make machine :pre
-
-make no-misc
-make machine :pre
-
-[Supporting info:]
-
-src/MISC: filenames -> commands
-"compute ti"_compute_ti.html
-"fix evaporate"_fix_evaporate.html
-"fix orient/fcc"_fix_orient.html
-"fix ttm"_fix_ttm.html
-"fix thermal/conductivity"_fix_thermal_conductivity.html
-"fix viscosity"_fix_viscosity.html
-examples/KAPPA
-examples/VISCOSITY
-http://lammps.sandia.gov/pictures.html#ttm
-http://lammps.sandia.gov/movies.html#evaporation :ul
-
-:line
-
-MOLECULE package :link(MOLECULE),h4
-
-[Contents:]
-
-A large number of atom, pair, bond, angle, dihedral, improper styles
-that are used to model molecular systems with fixed covalent bonds.
-The pair styles include the Dreiding (hydrogen-bonding) and CHARMM
-force fields, and a TIP4P water model.
-
-[Install or un-install:]
-
-make yes-molecule
-make machine :pre
-
-make no-molecule
-make machine :pre
-
-[Supporting info:]
-
-src/MOLECULE: filenames -> commands
-"atom_style"_atom_style.html
-"bond_style"_bond_style.html
-"angle_style"_angle_style.html
-"dihedral_style"_dihedral_style.html
-"improper_style"_improper_style.html
-"pair_style hbond/dreiding/lj"_pair_hbond_dreiding.html
-"pair_style lj/charmm/coul/charmm"_pair_charmm.html
-"Section 6.3"_Section_howto.html#howto_3
-examples/cmap
-examples/dreiding
-examples/micelle,
-examples/peptide
-bench/in.chain
-bench/in.rhodo :ul
-
-:line
-
-MPIIO package :link(MPIIO),h4
-
-[Contents:]
-
-Support for parallel output/input of dump and restart files via the
-MPIIO library. It adds "dump styles"_dump.html with a "mpiio" in
-their style name. Restart files with an ".mpiio" suffix are also
-written and read in parallel.
-
-[Install or un-install:]
-
-Note that MPIIO is part of the standard message-passing interface
-(MPI) library, so you should not need any additional compiler or link
-settings, beyond what LAMMPS normally uses for MPI on your system.
-
-make yes-mpiio
-make machine :pre
-
-make no-mpiio
-make machine :pre
-
-[Supporting info:]
-
-src/MPIIO: filenames -> commands
-"dump"_dump.html
-"restart"_restart.html
-"write_restart"_write_restart.html
-"read_restart"_read_restart.html :ul
-
-:line
-
-MSCG package :link(mscg),h4
-
-[Contents:]
-
-A "fix mscg"_fix_mscg.html command which can parameterize a
-Multi-Scale Coarse-Graining (MSCG) model using the open-source "MS-CG
-library"_mscg_home.
-
-:link(mscg_home,https://github.com/uchicago-voth/MSCG-release)
-
-To use this package you must have the MS-CG library available on your
-system.
-
-[Authors:] The fix was written by Lauren Abbott (Sandia). The MS-CG
-library was developed by Jacob Wagner in Greg Voth's group at the
-University of Chicago.
-
-[Install or un-install:]
-
-Before building LAMMPS with this package, you must first 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.
-
-Assuming these libraries are in place, you can do the download and
-build of MS-CG 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.
-
-You can then install/un-install the package and build LAMMPS in the
-usual manner:
-
-make yes-mscg
-make machine :pre
-
-make no-mscg
-make machine :pre
-
-[Supporting info:]
-
-src/MSCG: filenames -> commands
-src/MSCG/README
-lib/mscg/README
-examples/mscg :ul
-
-:line
-
-OPT package :link(OPT),h4
-
-[Contents:]
-
-A handful of pair styles which are optimized for improved CPU
-performance on single or multiple cores. These include EAM, LJ,
-CHARMM, and Morse potentials. The styles have an "opt" suffix in
-their style name. "Section 5.3.5"_accelerate_opt.html gives details
-of how to build and use this package. Its styles can be invoked at
-run time via the "-sf opt" or "-suffix opt" "command-line
-switches"_Section_start.html#start_6. See also the "KOKKOS"_#KOKKOS,
-"USER-INTEL"_#USER-INTEL, and "USER-OMP"_#USER-OMP packages, which
-have styles optimized for CPU performance.
-
-[Authors:] James Fischer (High Performance Technologies), David Richie,
-and Vincent Natoli (Stone Ridge Technolgy).
-
-[Install or un-install:]
-
-make yes-opt
-make machine :pre
-
-make no-opt
-make machine :pre
-
-NOTE: 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 Makefile.opt in
-src/MAKE/OPTIONS for an example.
-
-CCFLAGS: add -restrict for Intel compilers :ul
-
-[Supporting info:]
-
-src/OPT: filenames -> commands
-"Section 5.3"_Section_accelerate.html#acc_3
-"Section 5.3.5"_accelerate_opt.html
-"Section 2.6 -sf opt"_Section_start.html#start_6
-Pair Styles section of "Section 3.5"_Section_commands.html#cmd_5 for pair styles followed by (t)
-"Benchmarks page"_http://lammps.sandia.gov/bench.html of web site :ul
-
-:line
-
-PERI package :link(PERI),h4
-
-[Contents:]
-
-An atom style, several pair styles which implement different
-Peridynamics materials models, and several computes which calculate
-diagnostics. Peridynamics is a a particle-based meshless continuum
-model.
-
-[Authors:] The original package was created by Mike Parks (Sandia).
-Additional Peridynamics models were added by Rezwanur Rahman and John
-Foster (UTSA).
-
-[Install or un-install:]
-
-make yes-peri
-make machine :pre
-
-make no-peri
-make machine :pre
-
-[Supporting info:]
-
-src/PERI: filenames -> commands
-"doc/PDF/PDLammps_overview.pdf"_PDF/PDLammps_overview.pdf
-"doc/PDF/PDLammps_EPS.pdf"_PDF/PDLammps_EPS.pdf
-"doc/PDF/PDLammps_VES.pdf"_PDF/PDLammps_VES.pdf
-"atom_style peri"_atom_style.html
-"pair_style peri/*"_pair_peri.html
-"compute damage/atom"_compute_damage_atom.html
-"compute plasticity/atom"_compute_plasticity_atom.html
-examples/peri
-http://lammps.sandia.gov/movies.html#peri :ul
-
-:line
-
-POEMS package :link(POEMS),h4
-
-[Contents:]
-
-A fix that wraps the Parallelizable Open source Efficient Multibody
-Software (POEMS) library, which is able to simulate the dynamics of
-articulated body systems. These are systems with multiple rigid
-bodies (collections of particles) whose motion is coupled by
-connections at hinge points.
-
-[Author:] Rudra Mukherjee (JPL) while at RPI.
-
-[Install or un-install:]
-
-Before building LAMMPS with this package, you must first 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.
-
-You can then install/un-install the package and build LAMMPS in the
-usual manner:
-
-make yes-poems
-make machine :pre
-
-make no-meam
-make machine :pre
-
-[Supporting info:]
-
-src/POEMS: filenames -> commands
-src/POEMS/README
-lib/poems/README
-"fix poems"_fix_poems.html
-examples/rigid :ul
-
-:line
-
-PYTHON package :link(PYTHON),h4
-
-[Contents:]
-
-A "python"_python.html command which allow you to execute Python code
-from a LAMMPS input script. The code can be in a separate file or
-embedded in the input script itself. See "Section
-11.2"_Section_python.html#py_2 for an overview of using Python from
-LAMMPS in this manner and the entire section for other ways to use
-LAMMPS and Python together.
-
-[Install or un-install:]
-
-make yes-python
-make machine :pre
-
-make no-python
-make machine :pre
-
-NOTE: Building with the PYTHON package assumes 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 the
-lib/python/README for more details. Note that the build uses the
-lib/python/Makefile.lammps file in the compile/link process. You
-should only need to create a new Makefile.lammps.* file (and copy it
-to Makefile.lammps) if the LAMMPS build fails.
-
-[Supporting info:]
-
-src/PYTHON: filenames -> commands
-"Section 11"_Section_python.html
-lib/python/README
-examples/python :ul
-
-:line
-
-QEQ package :link(QEQ),h4
-
-[Contents:]
-
-Several fixes for performing charge equilibration (QEq) via different
-algorithms. These can be used with pair styles that perform QEq as
-part of their formulation.
-
-[Install or un-install:]
-
-make yes-qeq
-make machine :pre
-
-make no-qeq
-make machine :pre
-
-[Supporting info:]
-
-src/QEQ: filenames -> commands
-"fix qeq/*"_fix_qeq.html
-examples/qeq
-examples/streitz :ul
-
-:line
-
-REAX package :link(REAX),h4
-
-[Contents:]
-
-A pair style which wraps a Fortran library which implements the ReaxFF
-potential, which is a universal reactive force field. See the
-"USER-REAXC package"_#USER-REAXC for an alternate implementation in
-C/C++. Also a "fix reax/bonds"_fix_reax_bonds.html command for
-monitoring molecules as bonds are created and destroyed.
-
-[Author:] Aidan Thompson (Sandia).
-
-[Install or un-install:]
-
-Before building LAMMPS with this package, you must first 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.
-
-You can then install/un-install the package and build LAMMPS in the
-usual manner:
-
-make yes-reax
-make machine :pre
-
-make no-reax
-make machine :pre
-
-[Supporting info:]
-
-src/REAX: filenames -> commands
-lib/reax/README
-"pair_style reax"_pair_reax.html
-"fix reax/bonds"_fix_reax_bonds.html
-examples/reax :ul
-
-:line
-
-REPLICA package :link(REPLICA),h4
-
-[Contents:]
-
-A collection of multi-replica methods which can be used when running
-multiple LAMMPS simulations (replicas). See "Section
-6.5"_Section_howto.html#howto_5 for an overview of how to run
-multi-replica simulations in LAMMPS. Methods in the package include
-nudged elastic band (NEB), parallel replica dynamics (PRD),
-temperature accelerated dynamics (TAD), parallel tempering, and a
-verlet/split algorithm for performing long-range Coulombics on one set
-of processors, and the remainder of the force field calcalation on
-another set.
-
-[Install or un-install:]
-
-make yes-replica
-make machine :pre
-
-make no-replica
-make machine :pre
-
-[Supporting info:]
-
-src/REPLICA: filenames -> commands
-"Section 6.5"_Section_howto.html#howto_5
-"neb"_neb.html
-"prd"_prd.html
-"tad"_tad.html
-"temper"_temper.html,
-"run_style verlet/split"_run_style.html
-examples/neb
-examples/prd
-examples/tad :ul
-
-:line
-
-RIGID package :link(RIGID),h4
-
-[Contents:]
-
-Fixes which enforce rigid constraints on collections of atoms or
-particles. This includes SHAKE and RATTLE, as well as varous
-rigid-body integrators for a few large bodies or many small bodies.
-Also several computes which calculate properties of rigid bodies.
-
-To install/build:
-
-make yes-rigid
-make machine :pre
-
-To un-install/re-build:
-
-make no-rigid
-make machine :pre
-
-[Supporting info:]
-
-src/RIGID: filenames -> commands
-"compute erotate/rigid"_compute_erotate_rigid.html
-fix shake"_fix_shake.html
-"fix rattle"_fix_shake.html
-"fix rigid/*"_fix_rigid.html
-examples/ASPHERE
-examples/rigid
-bench/in.rhodo
-http://lammps.sandia.gov/movies.html#box
-http://lammps.sandia.gov/movies.html#star :ul
-
-:line
-
-SHOCK package :link(SHOCK),h4
-
-[Contents:]
-
-Fixes for running impact simulations where a shock-wave passes through
-a material.
-
-[Install or un-install:]
-
-make yes-shock
-make machine :pre
-
-make no-shock
-make machine :pre
-
-[Supporting info:]
-
-src/SHOCK: filenames -> commands
-"fix append/atoms"_fix_append_atoms.html
-"fix msst"_fix_msst.html
-"fix nphug"_fix_nphug.html
-"fix wall/piston"_fix_wall_piston.html
-examples/hugoniostat
-examples/msst :ul
-
-:line
-
-SNAP package :link(SNAP),h4
-
-[Contents:]
-
-A pair style for the spectral neighbor analysis potential (SNAP).
-SNAP is methodology for deriving a highly accurate classical potential
-fit to a large archive of quantum mechanical (DFT) data. Also several
-computes which analyze attributes of the potential.
-
-[Author:] Aidan Thompson (Sandia).
-
-[Install or un-install:]
-
-make yes-snap
-make machine :pre
-
-make no-snap
-make machine :pre
-
-[Supporting info:]
-
-src/SNAP: filenames -> commands
-"pair_style snap"_pair_snap.html
-"compute sna/atom"_compute_sna_atom.html
-"compute snad/atom"_compute_sna_atom.html
-"compute snav/atom"_compute_sna_atom.html
-examples/snap :ul
-
-:line
-
-SPIN package :link(SPIN),h4
-
-[Contents:]
-
-Model atomic magnetic spins classically, coupled to atoms moving in
-the usual manner via MD. Various pair, fix, and compute styles.
-
-[Author:] Julian Tranchida (Sandia).
-
-[Install or un-install:]
-
-make yes-spin
-make machine :pre
-
-make no-spin
-make machine :pre
-
-[Supporting info:]
-
-src/SPIN: filenames -> commands
-"Section 6.28"_Section_howto.html#howto_28
-"pair_style spin/dmi"_pair_spin_dmi.html
-"pair_style spin/exchange"_pair_spin_exchange.html
-"pair_style spin/magelec"_pair_spin_magelec.html
-"pair_style spin/neel"_pair_spin_neel.html
-"fix nve/spin"_fix_nve_spin.html
-"fix precession/spin"_fix_precession_spin.html
-"compute spin"_compute_spin.html
-examples/SPIN :ul
-
-:line
-
-SRD package :link(SRD),h4
-
-[Contents:]
-
-A pair of fixes which implement the Stochastic Rotation Dynamics (SRD)
-method for coarse-graining of a solvent, typically around large
-colloidal particles.
-
-To install/build:
-
-make yes-srd
-make machine :pre
-
-To un-install/re-build:
-
-make no-srd
-make machine :pre
-
-[Supporting info:]
-
-src/SRD: filenames -> commands
-"fix srd"_fix_srd.html
-"fix wall/srd"_fix_wall_srd.html
-examples/srd
-examples/ASPHERE
-http://lammps.sandia.gov/movies.html#tri
-http://lammps.sandia.gov/movies.html#line
-http://lammps.sandia.gov/movies.html#poly :ul
-
-:line
-
-VORONOI package :link(VORONOI),h4
-
-[Contents:]
-
-A compute command which calculates the Voronoi tesselation of a
-collection of atoms by wrapping the "Voro++ library"_voro_home. This
-can be used to calculate the local volume or each atoms or its near
-neighbors.
-
-:link(voro_home,http://math.lbl.gov/voro++)
-
-To use this package you must have the Voro++ library available on your
-system.
-
-[Author:] Daniel Schwen (INL) while at LANL. The open-source Voro++
-library was written by Chris Rycroft (Harvard U) while at UC Berkeley
-and LBNL.
-
-[Install or un-install:]
-
-Before building LAMMPS with this package, you must first download and
-build the Voro++ library. You can do this 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.
-
-You can then install/un-install the package and build LAMMPS in the
-usual manner:
-
-make yes-voronoi
-make machine :pre
-
-make no-voronoi
-make machine :pre
-
-[Supporting info:]
-
-src/VORONOI: filenames -> commands
-src/VORONOI/README
-lib/voronoi/README
-"compute voronoi/atom"_compute_voronoi_atom.html
-examples/voronoi :ul
-
-:line
-:line
-
-USER-ATC package :link(USER-ATC),h4
-
-[Contents:]
-
-ATC stands for atoms-to-continuum. This package implements a "fix
-atc"_fix_atc.html command to either couple molecular dynamics with
-continuum finite element equations or perform on-the-fly conversion of
-atomic information to continuum fields.
-
-[Authors:] Reese Jones, Jeremy Templeton, Jon Zimmerman (Sandia).
-
-[Install or un-install:]
-
-Before building LAMMPS with this package, you must first 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
-
-You can then install/un-install the package and build LAMMPS in the
-usual manner:
-
-make yes-user-atc
-make machine :pre
-
-make no-user-atc
-make machine :pre
-
-[Supporting info:]
-
-src/USER-ATC: filenames -> commands
-src/USER-ATC/README
-"fix atc"_fix_atc.html
-examples/USER/atc
-http://lammps.sandia.gov/pictures.html#atc :ul
-
-:line
-
-USER-AWPMD package :link(USER-AWPMD),h4
-
-[Contents:]
-
-AWPMD stands for Antisymmetrized Wave Packet Molecular Dynamics. This
-package implements an atom, pair, and fix style which allows electrons
-to be treated as explicit particles in a classical molecular dynamics
-model.
-
-[Author:] Ilya Valuev (JIHT, Russia).
-
-[Install or un-install:]
-
-Before building LAMMPS with this package, you must first 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
-
-You can then install/un-install the package and build LAMMPS in the
-usual manner:
-
-make yes-user-awpmd
-make machine :pre
-
-make no-user-awpmd
-make machine :pre
-
-[Supporting info:]
-
-src/USER-AWPMD: filenames -> commands
-src/USER-AWPMD/README
-"pair_style awpmd/cut"_pair_awpmd.html
-examples/USER/awpmd :ul
-
-:line
-
-USER-BOCS package :link(USER-BOCS),h4
-
-[Contents:]
-
-This package provides "fix bocs"_fix_bocs.html, a modified version
-of "fix npt"_fix_nh.html which includes the pressure correction to
-the barostat as outlined in:
-
-N. J. H. Dunn and W. G. Noid, "Bottom-up coarse-grained models that
-accurately describe the structure, pressure, and compressibility of
-molecular liquids," J. Chem. Phys. 143, 243148 (2015).
-
-[Authors:] Nicholas J. H. Dunn and Michael R. DeLyser (The Pennsylvania State University)
-
-[Install or un-install:]
-
-make yes-user-bocs
-make machine :pre
-
-make no-user-bocs
-make machine :pre
-
-[Supporting info:]
-
-The USER-BOCS user package for LAMMPS is part of the BOCS software package:
-"https://github.com/noid-group/BOCS"_https://github.com/noid-group/BOCS
-
-See the following reference for information about the entire package:
-
-Dunn, NJH; Lebold, KM; DeLyser, MR; Rudzinski, JF; Noid, WG.
-"BOCS: Bottom-Up Open-Source Coarse-Graining Software."
-J. Phys. Chem. B. 122, 13, 3363-3377 (2018).
-
-Example inputs are in the examples/USER/bocs folder.
-
-:line
-
-USER-CGDNA package :link(USER-CGDNA),h4
-
-[Contents:]
-
-Several pair styles, a bond style, and integration fixes for
-coarse-grained models of single- and double-stranded DNA based on the
-oxDNA model of Doye, Louis and Ouldridge at the University of Oxford.
-This includes Langevin-type rigid-body integrators with improved
-stability.
-
-[Author:] Oliver Henrich (University of Strathclyde, Glasgow).
-
-[Install or un-install:]
-
-make yes-user-cgdna
-make machine :pre
-
-make no-user-cgdna
-make machine :pre
-
-[Supporting info:]
-
-src/USER-CGDNA: filenames -> commands
-/src/USER-CGDNA/README
-"pair_style oxdna/*"_pair_oxdna.html
-"pair_style oxdna2/*"_pair_oxdna2.html
-"bond_style oxdna/*"_bond_oxdna.html
-"bond_style oxdna2/*"_bond_oxdna.html
-"fix nve/dotc/langevin"_fix_nve_dotc_langevin.html :ul
-
-:line
-
-USER-CGSDK package :link(USER-CGSDK),h4
-
-[Contents:]
-
-Several pair styles and an angle style which implement the
-coarse-grained SDK model of Shinoda, DeVane, and Klein which enables
-simulation of ionic liquids, electrolytes, lipids and charged amino
-acids.
-
-[Author:] Axel Kohlmeyer (Temple U).
-
-[Install or un-install:]
-
-make yes-user-cgsdk
-make machine :pre
-
-make no-user-cgsdk
-make machine :pre
-
-[Supporting info:]
-
-src/USER-CGSDK: filenames -> commands
-src/USER-CGSDK/README
-"pair_style lj/sdk/*"_pair_sdk.html
-"angle_style sdk"_angle_sdk.html
-examples/USER/cgsdk
-http://lammps.sandia.gov/pictures.html#cg :ul
-
-:line
-
-USER-COLVARS package :link(USER-COLVARS),h4
-
-[Contents:]
-
-COLVARS stands for collective variables, which can be used to
-implement various enhanced sampling methods, including Adaptive
-Biasing Force, Metadynamics, Steered MD, Umbrella Sampling and
-Restraints. A "fix colvars"_fix_colvars.html command is implemented
-which wraps a COLVARS library, which implements these methods.
-simulations.
-
-[Authors:] The COLVARS library is written and maintained by
-Giacomo Fiorin (ICMS, Temple University, Philadelphia, PA, USA)
-and Jerome Henin (LISM, CNRS, Marseille, France), originally for
-the NAMD MD code, but with portability in mind. Axel Kohlmeyer
-(Temple U) provided the interface to LAMMPS.
-
-[Install or un-install:]
-
-Before building LAMMPS with this package, you must first 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.
-
-You can then install/un-install the package and build LAMMPS in the
-usual manner:
-
-make yes-user-colvars
-make machine :pre
-
-make no-user-colvars
-make machine :pre
-
-[Supporting info:]
-
-src/USER-COLVARS: filenames -> commands
-"doc/PDF/colvars-refman-lammps.pdf"_PDF/colvars-refman-lammps.pdf
-src/USER-COLVARS/README
-lib/colvars/README
-"fix colvars"_fix_colvars.html
-examples/USER/colvars :ul
-
-:line
-
-USER-DIFFRACTION package :link(USER-DIFFRACTION),h4
-
-[Contents:]
-
-Two computes and a fix for calculating x-ray and electron diffraction
-intensities based on kinematic diffraction theory.
-
-[Author:] Shawn Coleman while at the U Arkansas.
-
-[Install or un-install:]
-
-make yes-user-diffraction
-make machine :pre
-
-make no-user-diffraction
-make machine :pre
-
-[Supporting info:]
-
-src/USER-DIFFRACTION: filenames -> commands
-"compute saed"_compute_saed.html
-"compute xrd"_compute_xrd.html
-"fix saed/vtk"_fix_saed_vtk.html
-examples/USER/diffraction :ul
-
-:line
-
-USER-DPD package :link(USER-DPD),h4
-
-[Contents:]
-
-DPD stands for dissipative particle dynamics. This package implements
-coarse-grained DPD-based models for energetic, reactive molecular
-crystalline materials. It includes many pair styles specific to these
-systems, including for reactive DPD, where each particle has internal
-state for multiple species and a coupled set of chemical reaction ODEs
-are integrated each timestep. Highly accurate time integrators for
-isothermal, isoenergetic, isobaric and isenthalpic conditions are
-included. These enable long timesteps via the Shardlow splitting
-algorithm.
-
-[Authors:] Jim Larentzos (ARL), Tim Mattox (Engility Corp), and and John
-Brennan (ARL).
-
-[Install or un-install:]
-
-make yes-user-dpd
-make machine :pre
-
-make no-user-dpd
-make machine :pre
-
-[Supporting info:]
-
-src/USER-DPD: filenames -> commands
-/src/USER-DPD/README
-"compute dpd"_compute_dpd.html
-"compute dpd/atom"_compute_dpd_atom.html
-"fix eos/cv"_fix_eos_table.html
-"fix eos/table"_fix_eos_table.html
-"fix eos/table/rx"_fix_eos_table_rx.html
-"fix shardlow"_fix_shardlow.html
-"fix rx"_fix_rx.html
-"pair_style table/rx"_pair_table_rx.html
-"pair_style dpd/fdt"_pair_dpd_fdt.html
-"pair_style dpd/fdt/energy"_pair_dpd_fdt.html
-"pair_style exp6/rx"_pair_exp6_rx.html
-"pair_style multi/lucy"_pair_multi_lucy.html
-"pair_style multi/lucy/rx"_pair_multi_lucy_rx.html
-examples/USER/dpd :ul
-
-:line
-
-USER-DRUDE package :link(USER-DRUDE),h4
-
-[Contents:]
-
-Fixes, pair styles, and a compute to simulate thermalized Drude
-oscillators as a model of polarization. See "Section
-6.27"_Section_howto.html#howto_27 for an overview of how to use the
-package. There are auxiliary tools for using this package in
-tools/drude.
-
-[Authors:] Alain Dequidt (U Blaise Pascal Clermont-Ferrand), Julien
-Devemy (CNRS), and Agilio Padua (U Blaise Pascal).
-
-[Install or un-install:]
-
-make yes-user-drude
-make machine :pre
-
-make no-user-drude
-make machine :pre
-
-[Supporting info:]
-
-src/USER-DRUDE: filenames -> commands
-"Section 6.27"_Section_howto.html#howto_27
-"Section 6.25"_Section_howto.html#howto_25
-src/USER-DRUDE/README
-"fix drude"_fix_drude.html
-"fix drude/transform/*"_fix_drude_transform.html
-"compute temp/drude"_compute_temp_drude.html
-"pair_style thole"_pair_thole.html
-"pair_style lj/cut/thole/long"_pair_thole.html
-examples/USER/drude
-tools/drude :ul
-
-:line
-
-USER-EFF package :link(USER-EFF),h4
-
-[Contents:]
-
-EFF stands for electron force field which allows a classical MD code
-to model electrons as particles of variable radius. This package
-contains atom, pair, fix and compute styles which implement the eFF as
-described in A. Jaramillo-Botero, J. Su, Q. An, and W.A. Goddard III,
-JCC, 2010. The eFF potential was first introduced by Su and Goddard,
-in 2007. There are auxiliary tools for using this package in
-tools/eff; see its README file.
-
-[Author:] Andres Jaramillo-Botero (CalTech).
-
-[Install or un-install:]
-
-make yes-user-eff
-make machine :pre
-
-make no-user-eff
-make machine :pre
-
-[Supporting info:]
-
-src/USER-EFF: filenames -> commands
-src/USER-EFF/README
-"atom_style electron"_atom_style.html
-"fix nve/eff"_fix_nve_eff.html
-"fix nvt/eff"_fix_nh_eff.html
-"fix npt/eff"_fix_nh_eff.html
-"fix langevin/eff"_fix_langevin_eff.html
-"compute temp/eff"_compute_temp_eff.html
-"pair_style eff/cut"_pair_eff.html
-"pair_style eff/inline"_pair_eff.html
-examples/USER/eff
-tools/eff/README
-tools/eff
-http://lammps.sandia.gov/movies.html#eff :ul
-
-:line
-
-USER-FEP package :link(USER-FEP),h4
-
-[Contents:]
-
-FEP stands for free energy perturbation. This package provides
-methods for performing FEP simulations by using a "fix
-adapt/fep"_fix_adapt_fep.html command with soft-core pair potentials,
-which have a "soft" in their style name. There are auxiliary tools
-for using this package in tools/fep; see its README file.
-
-[Author:] Agilio Padua (Universite Blaise Pascal Clermont-Ferrand)
-
-[Install or un-install:]
-
-make yes-user-fep
-make machine :pre
-
-make no-user-fep
-make machine :pre
-
-[Supporting info:]
-
-src/USER-FEP: filenames -> commands
-src/USER-FEP/README
-"fix adapt/fep"_fix_adapt_fep.html
-"compute fep"_compute_fep.html
-"pair_style */soft"_pair_lj_soft.html
-examples/USER/fep
-tools/fep/README
-tools/fep :ul
-
-:line
-
-USER-H5MD package :link(USER-H5MD),h4
-
-[Contents:]
-
-H5MD stands for HDF5 for MD. "HDF5"_HDF5 is a portable, binary,
-self-describing file format, used by many scientific simulations.
-H5MD is a format for molecular simulations, built on top of HDF5.
-This package implements a "dump h5md"_dump_h5md.html command to output
-LAMMPS snapshots in this format.
-
-:link(HDF5,http://www.hdfgroup.org/HDF5)
-
-To use this package you must have the HDF5 library available on your
-system.
-
-[Author:] Pierre de Buyl (KU Leuven) created both the package and the
-H5MD format.
-
-[Install or un-install:]
-
-Note that to follow these steps to compile and link to the CH5MD
-library, you need the standard HDF5 software package installed on your
-system, which should include the h5cc compiler and the HDF5 library.
-
-Before building LAMMPS with this package, you must first 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.
-
-You can then install/un-install the package and build LAMMPS in the
-usual manner:
-
-make yes-user-h5md
-make machine :pre
-
-make no-user-h5md
-make machine :pre
-
-[Supporting info:]
-
-src/USER-H5MD: filenames -> commands
-src/USER-H5MD/README
-lib/h5md/README
-"dump h5md"_dump_h5md.html :ul
-
-:line
-
-USER-INTEL package :link(USER-INTEL),h4
-
-[Contents:]
-
-Dozens of pair, fix, bond, angle, dihedral, improper, and kspace
-styles which are optimized for Intel CPUs and KNLs (Knights Landing).
-All of them have an "intel" in their style name. "Section
-5.3.2"_accelerate_intel.html gives details of what hardware and
-compilers are required on your system, and how to build and use this
-package. Its styles can be invoked at run time via the "-sf intel" or
-"-suffix intel" "command-line switches"_Section_start.html#start_6.
-Also see the "KOKKOS"_#KOKKOS, "OPT"_#OPT, and "USER-OMP"_#USER-OMP
-packages, which have styles optimized for CPUs and KNLs.
-
-You need to have an Intel compiler, version 14 or higher to take full
-advantage of this package. While compilation with GNU compilers is
-supported, performance will be suboptimal.
-
-NOTE: the USER-INTEL package contains styles that require using the
--restrict flag, when compiling with Intel compilers.
-
-
-[Author:] Mike Brown (Intel).
-
-[Install or un-install:]
-
-For the USER-INTEL package, you have 2 choices when building. You can
-build with either CPU or KNL support. Each choice requires additional
-settings in your Makefile.machine for CCFLAGS and LINKFLAGS and
-optimized malloc libraries. See the
-src/MAKE/OPTIONS/Makefile.intel_cpu and src/MAKE/OPTIONS/Makefile.knl
-files for examples.
-
-For CPUs:
-
-OPTFLAGS = -xHost -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 -ltbbmalloc_proxy :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
-
-Once you have an appropriate Makefile.machine, you can
-install/un-install the package and build LAMMPS in the usual manner.
-Note that you cannot build one executable to run on multiple hardware
-targets (Intel CPUs or KNL). You need to build LAMMPS once for each
-hardware target, to produce a separate executable.
-
-You should also typically install the USER-OMP package, as it can be
-used in tandem with the USER-INTEL package to good effect, as
-explained in "Section 5.3.2"_accelerate_intel.html.
-
-make yes-user-intel yes-user-omp
-make machine :pre
-
-make no-user-intel no-user-omp
-make machine :pre
-
-[Supporting info:]
-
-src/USER-INTEL: filenames -> commands
-src/USER-INTEL/README
-"Section 5.3"_Section_accelerate.html#acc_3
-"Section 5.3.2"_accelerate_gpu.html
-"Section 2.6 -sf intel"_Section_start.html#start_6
-"Section 2.6 -pk intel"_Section_start.html#start_6
-"package intel"_package.html
-Styles sections of "Section 3.5"_Section_commands.html#cmd_5 for styles followed by (i)
-src/USER-INTEL/TEST
-"Benchmarks page"_http://lammps.sandia.gov/bench.html of web site :ul
-
-:line
-
-USER-LB package :link(USER-LB),h4
-
-[Contents:]
-
-Fixes which implement a background Lattice-Boltzmann (LB) fluid, which
-can be used to model MD particles influenced by hydrodynamic forces.
-
-[Authors:] Frances Mackay and Colin Denniston (University of Western
-Ontario).
-
-[Install or un-install:]
-
-make yes-user-lb
-make machine :pre
-
-make no-user-lb
-make machine :pre
-
-[Supporting info:]
-
-src/USER-LB: filenames -> commands
-src/USER-LB/README
-"fix lb/fluid"_fix_lb_fluid.html
-"fix lb/momentum"_fix_lb_momentum.html
-"fix lb/viscous"_fix_lb_viscous.html
-examples/USER/lb :ul
-
-:line
-
-USER-MGPT package :link(USER-MGPT),h4
-
-[Contents:]
-
-A pair style which provides a fast implementation of the quantum-based
-MGPT multi-ion potentials. The MGPT or model GPT method derives from
-first-principles DFT-based generalized pseudopotential theory (GPT)
-through a series of systematic approximations valid for mid-period
-transition metals with nearly half-filled d bands. The MGPT method
-was originally developed by John Moriarty at LLNL. The pair style in
-this package calculates forces and energies using an optimized
-matrix-MGPT algorithm due to Tomas Oppelstrup at LLNL.
-
-[Authors:] Tomas Oppelstrup and John Moriarty (LLNL).
-
-[Install or un-install:]
-
-make yes-user-mgpt
-make machine :pre
-
-make no-user-mgpt
-make machine :pre
-
-[Supporting info:]
-
-src/USER-MGPT: filenames -> commands
-src/USER-MGPT/README
-"pair_style mgpt"_pair_mgpt.html
-examples/USER/mgpt :ul
-
-:line
-
-USER-MISC package :link(USER-MISC),h4
-
-[Contents:]
-
-A potpourri of (mostly) unrelated features contributed to LAMMPS by
-users. Each feature is a single fix, compute, pair, bond, angle,
-dihedral, improper, or command style.
-
-[Authors:] The author for each style in the package is listed in the
-src/USER-MISC/README file.
-
-[Install or un-install:]
-
-make yes-user-misc
-make machine :pre
-
-make no-user-misc
-make machine :pre
-
-[Supporting info:]
-
-src/USER-MISC: filenames -> commands
-src/USER-MISC/README
-one doc page per individual command listed in src/USER-MISC/README
-examples/USER/misc :ul
-
-:line
-
-USER-MANIFOLD package :link(USER-MANIFOLD),h4
-
-[Contents:]
-
-Several fixes and a "manifold" class which enable simulations of
-particles constrained to a manifold (a 2D surface within the 3D
-simulation box). This is done by applying the RATTLE constraint
-algorithm to formulate single-particle constraint functions
-g(xi,yi,zi) = 0 and their derivative (i.e. the normal of the manifold)
-n = grad(g).
-
-[Author:] Stefan Paquay (until 2017: Eindhoven University of Technology (TU/e), The
-Netherlands; since 2017: Brandeis University, Waltham, MA, USA)
-
-[Install or un-install:]
-
-make yes-user-manifold
-make machine :pre
-
-make no-user-manifold
-make machine :pre
-
-[Supporting info:]
-
-src/USER-MANIFOLD: filenames -> commands
-src/USER-MANIFOLD/README
-"doc/manifolds"_manifolds.html
-"fix manifoldforce"_fix_manifoldforce.html
-"fix nve/manifold/rattle"_fix_nve_manifold_rattle.html
-"fix nvt/manifold/rattle"_fix_nvt_manifold_rattle.html
-examples/USER/manifold
-http://lammps.sandia.gov/movies.html#manifold :ul
-
-:line
-
-USER-MEAMC package :link(USER-MEAMC),h4
-
-[Contents:]
-
-A pair style for the modified embedded atom (MEAM) potential
-translated from the Fortran version in the "MEAM"_MEAM package
-to plain C++. In contrast to the MEAM package, no library
-needs to be compiled and the pair style can be instantiated
-multiple times.
-
-[Author:] Sebastian Huetter, (Otto-von-Guericke University Magdeburg)
-based on the Fortran version of Greg Wagner (Northwestern U) while at
-Sandia.
-
-[Install or un-install:]
-
-make yes-user-meamc
-make machine :pre
-
-make no-user-meamc
-make machine :pre
-
-[Supporting info:]
-
-src/USER-MEAMC: filenames -> commands
-src/USER-MEAMC/README
-"pair_style meam/c"_pair_meam.html
-examples/meam :ul
-
-:line
-
-USER-MESO package :link(USER-MESO),h4
-
-[Contents:]
-
-Several extensions of the the dissipative particle dynamics (DPD)
-method. Specifically, energy-conserving DPD (eDPD) that can model
-non-isothermal processes, many-body DPD (mDPD) for simulating
-vapor-liquid coexistence, and transport DPD (tDPD) for modeling
-advection-diffusion-reaction systems. The equations of motion of these
-DPD extensions are integrated through a modified velocity-Verlet (MVV)
-algorithm.
-
-[Author:] Zhen Li (Division of Applied Mathematics, Brown University)
-
-[Install or un-install:]
-
-make yes-user-meso
-make machine :pre
-
-make no-user-meso
-make machine :pre
-
-[Supporting info:]
-
-src/USER-MESO: filenames -> commands
-src/USER-MESO/README
-"atom_style edpd"_atom_style.html
-"pair_style edpd"_pair_meso.html
-"pair_style mdpd"_pair_meso.html
-"pair_style tdpd"_pair_meso.html
-"fix mvv/dpd"_fix_mvv_dpd.html
-examples/USER/meso
-http://lammps.sandia.gov/movies.html#mesodpd :ul
-
-:line
-
-USER-MOFFF package :link(USER-MOFFF),h4
-
-[Contents:]
-
-Pair, angle and improper styles needed to employ the MOF-FF
-force field by Schmid and coworkers with LAMMPS.
-MOF-FF is a first principles derived force field with the primary aim
-to simulate MOFs and related porous framework materials, using spherical
-Gaussian charges. It is described in S. Bureekaew et al., Phys. Stat. Sol. B
-2013, 250, 1128-1141.
-For the usage of MOF-FF see the example in the example directory as
-well as the "MOF+"_MOFplus website.
-
-:link(MOFplus,https://www.mofplus.org/content/show/MOF-FF)
-
-[Author:] Hendrik Heenen (Technical U of Munich),
-Rochus Schmid (Ruhr-University Bochum).
-
-[Install or un-install:]
-
-make yes-user-mofff
-make machine :pre
-
-make no-user-mofff
-make machine :pre
-
-[Supporting info:]
-
-src/USER-MOFFF: filenames -> commands
-src/USER-MOFFF/README
-"pair_style buck6d/coul/gauss"_pair_buck6d_coul_gauss.html
-"angle_style class2"_angle_class2.html
-"angle_style cosine/buck6d"_angle_cosine_buck6d.html
-"improper_style inversion/harmonic"_improper_inversion_harmonic.html
-examples/USER/mofff :ul
-
-:line
-
-USER-MOLFILE package :link(USER-MOLFILE),h4
-
-[Contents:]
-
-A "dump molfile"_dump_molfile.html command which uses molfile plugins
-that are bundled with the "VMD"_vmd_home
-molecular visualization and analysis program, to enable LAMMPS to dump
-snapshots in formats compatible with various molecular simulation
-tools.
-
-:link(vmd_home,http://www.ks.uiuc.edu/Research/vmd)
-
-To use this package you must have the desired VMD plugins available on
-your system.
-
-Note that this package only provides the interface code, not the
-plugins themselves, which will be accessed when requesting a specific
-plugin via the "dump molfile"_dump_molfile.html command. Plugins can
-be obtained from a VMD installation which has to match the platform
-that you are using to compile LAMMPS for. By adding plugins to VMD,
-support for new file formats can be added to LAMMPS (or VMD or other
-programs that use them) without having to recompile the application
-itself. More information about the VMD molfile plugins can be found
-at
-"http://www.ks.uiuc.edu/Research/vmd/plugins/molfile"_http://www.ks.uiuc.edu/Research/vmd/plugins/molfile.
-
-[Author:] Axel Kohlmeyer (Temple U).
-
-[Install or un-install:]
-
-Note that the lib/molfile/Makefile.lammps file has a setting for a
-dynamic loading library libdl.a that should is typically present on
-all systems, which 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.
-
-make yes-user-molfile
-make machine :pre
-
-make no-user-molfile
-make machine :pre
-
-[Supporting info:]
-
-src/USER-MOLFILE: filenames -> commands
-src/USER-MOLFILE/README
-lib/molfile/README
-"dump molfile"_dump_molfile.html :ul
-
-:line
-
-USER-NETCDF package :link(USER-NETCDF),h4
-
-[Contents:]
-
-Dump styles for writing NetCDF formatted dump files. NetCDF is a
-portable, binary, self-describing file format developed on top of
-HDF5. The file contents follow the AMBER NetCDF trajectory conventions
-(http://ambermd.org/netcdf/nctraj.xhtml), but include extensions.
-
-To use this package you must have the NetCDF library available on your
-system.
-
-Note that NetCDF files can be directly visualized with the following
-tools:
-
-"Ovito"_ovito (Ovito supports the AMBER convention and the extensions mentioned above)
-"VMD"_vmd_home
-"AtomEye"_atomeye (the libAtoms version of AtomEye contains a NetCDF reader not present in the standard distribution) :ul
-
-:link(ovito,http://www.ovito.org)
-:link(atomeye,http://www.libatoms.org)
-
-[Author:] Lars Pastewka (Karlsruhe Institute of Technology).
-
-[Install or un-install:]
-
-Note that to follow these steps, you need the standard NetCDF software
-package installed on your system. The lib/netcdf/Makefile.lammps file
-has settings for NetCDF include and library files that LAMMPS needs to
-compile and linkk 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.
-
-make yes-user-netcdf
-make machine :pre
-
-make no-user-netcdf
-make machine :pre
-
-[Supporting info:]
-
-src/USER-NETCDF: filenames -> commands
-src/USER-NETCDF/README
-lib/netcdf/README
-"dump netcdf"_dump_netcdf.html :ul
-
-:line
-
-USER-OMP package :link(USER-OMP),h4
-
-[Contents:]
-
-Hundreds of pair, fix, compute, bond, angle, dihedral, improper, and
-kspace styles which are altered to enable threading on many-core CPUs
-via OpenMP directives. All of them have an "omp" in their style name.
-"Section 5.3.4"_accelerate_omp.html gives details of what hardware and
-compilers are required on your system, and how to build and use this
-package. Its styles can be invoked at run time via the "-sf omp" or
-"-suffix omp" "command-line switches"_Section_start.html#start_6.
-Also see the "KOKKOS"_#KOKKOS, "OPT"_#OPT, and
-"USER-INTEL"_#USER-INTEL packages, which have styles optimized for
-CPUs.
-
-[Author:] Axel Kohlmeyer (Temple U).
-
-NOTE: To enable multi-threading support the compile flag "-fopenmp"
-and the link flag "-fopenmp" (for GNU compilers, you have to look up
-the equivalent flags for other compilers) must be used to build LAMMPS.
-When using Intel compilers, also the "-restrict" flag is required.
-The USER-OMP package can be compiled without enabling OpenMP; then
-all code will be compiled as serial and the only improvement over the
-regular styles are some data access optimization. These flags should
-be added to the CCFLAGS and LINKFLAGS lines of your Makefile.machine.
-See src/MAKE/OPTIONS/Makefile.omp for an example.
-
-Once you have an appropriate Makefile.machine, you can
-install/un-install the package and build LAMMPS in the usual manner:
-
-[Install or un-install:]
-
-make yes-user-omp
-make machine :pre
-
-make no-user-omp
-make machine :pre
-
-CCFLAGS: add -fopenmp (and -restrict when using Intel compilers)
-LINKFLAGS: add -fopenmp :ul
-
-[Supporting info:]
-
-src/USER-OMP: filenames -> commands
-src/USER-OMP/README
-"Section 5.3"_Section_accelerate.html#acc_3
-"Section 5.3.4"_accelerate_omp.html
-"Section 2.6 -sf omp"_Section_start.html#start_6
-"Section 2.6 -pk omp"_Section_start.html#start_6
-"package omp"_package.html
-Styles sections of "Section 3.5"_Section_commands.html#cmd_5 for styles followed by (o)
-"Benchmarks page"_http://lammps.sandia.gov/bench.html of web site :ul
-
-:line
-
-USER-PHONON package :link(USER-PHONON),h4
-
-[Contents:]
-
-A "fix phonon"_fix_phonon.html command that calculates dynamical
-matrices, which can then be used to compute phonon dispersion
-relations, directly from molecular dynamics simulations.
-
-[Author:] Ling-Ti Kong (Shanghai Jiao Tong University).
-
-[Install or un-install:]
-
-make yes-user-phonon
-make machine :pre
-
-make no-user-phonon
-make machine :pre
-
-[Supporting info:]
-
-src/USER-PHONON: filenames -> commands
-src/USER-PHONON/README
-"fix phonon"_fix_phonon.html
-examples/USER/phonon :ul
-
-:line
-
-USER-QMMM package :link(USER-QMMM),h4
-
-[Contents:]
-
-A "fix qmmm"_fix_qmmm.html command which allows LAMMPS to be used in a
-QM/MM simulation, currently only in combination with the "Quantum
-ESPRESSO"_espresso package.
-
-:link(espresso,http://www.quantum-espresso.org)
-
-To use this package you must have Quantum ESPRESSO available on your
-system.
-
-The current implementation only supports an ONIOM style mechanical
-coupling to the Quantum ESPRESSO plane wave DFT package.
-Electrostatic coupling is in preparation and the interface has been
-written in a manner that coupling to other QM codes should be possible
-without changes to LAMMPS itself.
-
-[Author:] Axel Kohlmeyer (Temple U).
-
-[Install or un-install:]
-
-Before building LAMMPS with this package, you must first 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/un-install the package and build LAMMPS in the
-usual manner:
-
-make yes-user-qmmm
-make machine :pre
-
-make no-user-qmmm
-make machine :pre
-
-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 which links LAMMPS and Quantum ESPRESSO
-together. These are steps 3 and 4 described in the lib/qmmm/README
-file.
-
-[Supporting info:]
-
-src/USER-QMMM: filenames -> commands
-src/USER-QMMM/README
-lib/qmmm/README
-"fix phonon"_fix_phonon.html
-lib/qmmm/example-ec/README
-lib/qmmm/example-mc/README :ul
-
-:line
-
-USER-QTB package :link(USER-QTB),h4
-
-[Contents:]
-
-Two fixes which provide a self-consistent quantum treatment of
-vibrational modes in a classical molecular dynamics simulation. By
-coupling the MD simulation to a colored thermostat, it introduces zero
-point energy into the system, altering the energy power spectrum and
-the heat capacity to account for their quantum nature. This is useful
-when modeling systems at temperatures lower than their classical
-limits or when temperatures ramp across the classical limits in a
-simulation.
-
-[Author:] Yuan Shen (Stanford U).
-
-[Install or un-install:]
-
-make yes-user-qtb
-make machine :pre
-
-make no-user-qtb
-make machine :pre
-
-[Supporting info:]
-
-src/USER-QTB: filenames -> commands
-src/USER-QTB/README
-"fix qtb"_fix_qtb.html
-"fix qbmsst"_fix_qbmsst.html
-examples/USER/qtb :ul
-
-:line
-
-USER-QUIP package :link(USER-QUIP),h4
-
-[Contents:]
-
-A "pair_style quip"_pair_quip.html command which wraps the "QUIP
-libAtoms library"_quip, which includes a variety of interatomic
-potentials, including Gaussian Approximation Potential (GAP) models
-developed by the Cambridge University group.
-
-:link(quip,https://github.com/libAtoms/QUIP)
-
-To use this package you must have the QUIP libAtoms library available
-on your system.
-
-[Author:] Albert Bartok (Cambridge University)
-
-[Install or un-install:]
-
-Note that to follow these steps to compile and link to the QUIP
-library, you must first download and build QUIP on your systems. It
-can be obtained from GitHub. See step 1 and step 1.1 in the
-lib/quip/README file for details on how to do this. Note that it
-requires setting two environment variables, QUIP_ROOT and QUIP_ARCH,
-which will be 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 this file if the LAMMPS build can not use its
-settings to successfully build on your system.
-
-You can then install/un-install the package and build LAMMPS in the
-usual manner:
-
-make yes-user-quip
-make machine :pre
-
-make no-user-quip
-make machine :pre
-
-[Supporting info:]
-
-src/USER-QUIP: filenames -> commands
-src/USER-QUIP/README
-"pair_style quip"_pair_quip.html
-examples/USER/quip :ul
-
-:line
-
-USER-REAXC package :link(USER-REAXC),h4
-
-[Contents:]
-
-A pair style which implements the ReaxFF potential in C/C++ (in
-contrast to the "REAX package"_#REAX and its Fortran library). ReaxFF
-is universal reactive force field. See the src/USER-REAXC/README file
-for more info on differences between the two packages. Also two fixes
-for monitoring molecules as bonds are created and destroyed.
-
-[Author:] Hasan Metin Aktulga (MSU) while at Purdue University.
-
-[Install or un-install:]
-
-make yes-user-reaxc
-make machine :pre
-
-make no-user-reaxc
-make machine :pre
-
-[Supporting info:]
-
-src/USER-REAXC: filenames -> commands
-src/USER-REAXC/README
-"pair_style reax/c"_pair_reaxc.html
-"fix reax/c/bonds"_fix_reax_bonds.html
-"fix reax/c/species"_fix_reaxc_species.html
-examples/reax :ul
-
-:line
-
-USER-SMD package :link(USER-SMD),h4
-
-[Contents:]
-
-An atom style, fixes, computes, and several pair styles which
-implements smoothed Mach dynamics (SMD) for solids, which is a model
-related to smoothed particle hydrodynamics (SPH) for liquids (see the
-"USER-SPH package"_#USER-SPH).
-
-This package solves solids mechanics problems via a state of the art
-stabilized meshless method with hourglass control. It can specify
-hydrostatic interactions independently from material strength models,
-i.e. pressure and deviatoric stresses are separated. It provides many
-material models (Johnson-Cook, plasticity with hardening,
-Mie-Grueneisen, Polynomial EOS) and allows new material models to be
-added. It implements rigid boundary conditions (walls) which can be
-specified as surface geometries from *.STL files.
-
-[Author:] Georg Ganzenmuller (Fraunhofer-Institute for High-Speed
-Dynamics, Ernst Mach Institute, Germany).
-
-[Install or un-install:]
-
-Before building LAMMPS with this package, you must first download the
-Eigen library. Eigen is a template library, so you do not need to
-build it, just download it. You can do this 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 and build in default lib/smd/eigen-eigen-...
-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.
-
-You can then install/un-install the package and build LAMMPS in the
-usual manner:
-
-make yes-user-smd
-make machine :pre
-
-make no-user-smd
-make machine :pre
-
-[Supporting info:]
-
-src/USER-SMD: filenames -> commands
-src/USER-SMD/README
-doc/PDF/SMD_LAMMPS_userguide.pdf
-examples/USER/smd
-http://lammps.sandia.gov/movies.html#smd :ul
-
-:line
-
-USER-SMTBQ package :link(USER-SMTBQ),h4
-
-[Contents:]
-
-A pair style which implements a Second Moment Tight Binding model with
-QEq charge equilibration (SMTBQ) potential for the description of
-ionocovalent bonds in oxides.
-
-[Authors:] Nicolas Salles, Emile Maras, Olivier Politano, and Robert
-Tetot (LAAS-CNRS, France).
-
-[Install or un-install:]
-
-make yes-user-smtbq
-make machine :pre
-
-make no-user-smtbq
-make machine :pre
-
-[Supporting info:]
-
-src/USER-SMTBQ: filenames -> commands
-src/USER-SMTBQ/README
-"pair_style smtbq"_pair_smtbq.html
-examples/USER/smtbq :ul
-
-:line
-
-USER-SPH package :link(USER-SPH),h4
-
-[Contents:]
-
-An atom style, fixes, computes, and several pair styles which
-implements smoothed particle hydrodynamics (SPH) for liquids. See the
-related "USER-SMD package"_#USER-SMD package for smooth Mach dynamics
-(SMD) for solids.
-
-This package contains ideal gas, Lennard-Jones equation of states,
-Tait, and full support for complete (i.e. internal-energy dependent)
-equations of state. It allows for plain or Monaghans XSPH integration
-of the equations of motion. It has options for density continuity or
-density summation to propagate the density field. It has
-"set"_set.html command options to set the internal energy and density
-of particles from the input script and allows the same quantities to
-be output with thermodynamic output or to dump files via the "compute
-property/atom"_compute_property_atom.html command.
-
-[Author:] Georg Ganzenmuller (Fraunhofer-Institute for High-Speed
-Dynamics, Ernst Mach Institute, Germany).
-
-[Install or un-install:]
-
-make yes-user-sph
-make machine :pre
-
-make no-user-sph
-make machine :pre
-
-[Supporting info:]
-
-src/USER-SPH: filenames -> commands
-src/USER-SPH/README
-doc/PDF/SPH_LAMMPS_userguide.pdf
-examples/USER/sph
-http://lammps.sandia.gov/movies.html#sph :ul
-
-:line
-
-USER-TALLY package :link(USER-TALLY),h4
-
-[Contents:]
-
-Several compute styles that can be called when pairwise interactions
-are calculated to tally information (forces, heat flux, energy,
-stress, etc) about individual interactions.
-
-[Author:] Axel Kohlmeyer (Temple U).
-
-[Install or un-install:]
-
-make yes-user-tally
-make machine :pre
-
-make no-user-tally
-make machine :pre
-
-[Supporting info:]
-
-src/USER-TALLY: filenames -> commands
-src/USER-TALLY/README
-"compute */tally"_compute_tally.html
-examples/USER/tally :ul
-
-:line
-
-USER-UEF package :link(USER-UEF),h4
-
-[Contents:]
-
-A fix style for the integration of the equations of motion under
-extensional flow with proper boundary conditions, as well as several
-supporting compute styles and an output option.
-
-[Author:] David Nicholson (MIT).
-
-[Install or un-install:]
-
-make yes-user-uef
-make machine :pre
-
-make no-user-uef
-make machine :pre
-
-[Supporting info:]
-
-src/USER-UEF: filenames -> commands
-src/USER-UEF/README
-"fix nvt/uef"_fix_nh_uef.html
-"fix npt/uef"_fix_nh_uef.html
-"compute pressure/uef"_compute_pressure_uef.html
-"compute temp/uef"_compute_temp_uef.html
-"dump cfg/uef"_dump_cfg_uef.html
-examples/uef :ul
-
-:line
-
-USER-VTK package :link(USER-VTK),h4
-
-[Contents:]
-
-A "dump vtk"_dump_vtk.html command which outputs snapshot info in the
-"VTK format"_vtk, enabling visualization by "Paraview"_paraview or
-other visualization packages.
-
-:link(vtk,http://www.vtk.org)
-:link(paraview,http://www.paraview.org)
-
-To use this package you must have VTK library available on your
-system.
-
-[Authors:] Richard Berger (JKU) and Daniel Queteschiner (DCS Computing).
-
-[Install or un-install:]
-
-The lib/vtk/Makefile.lammps file has settings for accessing VTK files
-and its library, which are required for LAMMPS to build and link 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.
-
-You can then install/un-install the package and build LAMMPS in the
-usual manner:
-
-make yes-user-vtk
-make machine :pre
-
-make no-user-vtk
-make machine :pre
-
-[Supporting info:]
-
-src/USER-VTK: filenames -> commands
-src/USER-VTK/README
-lib/vtk/README
-"dump vtk"_dump_vtk.html :ul
diff --git a/doc/src/Section_python.txt b/doc/src/Section_python.txt
deleted file mode 100644
index 5427cd67f28d36bb0344012e6f7cfe593f7aca88..0000000000000000000000000000000000000000
--- a/doc/src/Section_python.txt
+++ /dev/null
@@ -1,867 +0,0 @@
-"Previous Section"_Section_modify.html - "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Section_errors.html :c
-
-:link(lws,http://lammps.sandia.gov)
-:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
-
-:line
-
-11. Python interface to LAMMPS :h2
-
-LAMMPS can work together with Python in three ways. First, Python can
-wrap LAMMPS through the "LAMMPS library
-interface"_Section_howto.html#howto_19, so that a Python script can
-create one or more instances of LAMMPS and launch one or more
-simulations. In Python lingo, this is "extending" Python with LAMMPS.
-
-Second, the low-level Python interface can be used indirectly through the
-PyLammps and IPyLammps wrapper classes in Python. These wrappers try to
-simplify the usage of LAMMPS in Python by providing an object-based interface
-to common LAMMPS functionality. It also reduces the amount of code necessary to
-parameterize LAMMPS scripts through Python and makes variables and computes
-directly accessible. See "PyLammps interface"_#py_9 for more details.
-
-Third, LAMMPS can use the Python interpreter, so that a LAMMPS input
-script can invoke Python code, and pass information back-and-forth
-between the input script and Python functions you write. The Python
-code can also callback to LAMMPS to query or change its attributes.
-In Python lingo, this is "embedding" Python in LAMMPS.
-
-This section describes how to use these three approaches.
-
-11.1 "Overview of running LAMMPS from Python"_#py_1
-11.2 "Overview of using Python from a LAMMPS script"_#py_2
-11.3 "Building LAMMPS as a shared library"_#py_3
-11.4 "Installing the Python wrapper into Python"_#py_4
-11.5 "Extending Python with MPI to run in parallel"_#py_5
-11.6 "Testing the Python-LAMMPS interface"_#py_6
-11.7 "Using LAMMPS from Python"_#py_7
-11.8 "Example Python scripts that use LAMMPS"_#py_8
-11.9 "PyLammps interface"_#py_9 :ul
-
-If you are not familiar with it, "Python"_http://www.python.org is a
-powerful scripting and programming language which can essentially do
-anything that faster, lower-level languages like C or C++ can do, but
-typically with much fewer lines of code. When used in embedded mode,
-Python can perform operations that the simplistic LAMMPS input script
-syntax cannot. Python can be also be used as a "glue" language to
-drive a program through its library interface, or to hook multiple
-pieces of software together, such as a simulation package plus a
-visualization package, or to run a coupled multiscale or multiphysics
-model.
-
-See "Section 6.10"_Section_howto.html#howto_10 of the manual and
-the couple directory of the distribution for more ideas about coupling
-LAMMPS to other codes. See "Section
-6.19"_Section_howto.html#howto_19 for a description of the LAMMPS
-library interface provided in src/library.cpp and src/library.h, and
-how to extend it for your needs. As described below, that interface
-is what is exposed to Python either when calling LAMMPS from Python or
-when calling Python from a LAMMPS input script and then calling back
-to LAMMPS from Python code. The library interface is designed to be
-easy to add functions to. Thus the Python interface to LAMMPS is also
-easy to extend as well.
-
-If you create interesting Python scripts that run LAMMPS or
-interesting Python functions that can be called from a LAMMPS input
-script, that you think would be useful to other users, please "email
-them to the developers"_http://lammps.sandia.gov/authors.html. We can
-include them in the LAMMPS distribution.
-
-:line
-:line
-
-11.1 Overview of running LAMMPS from Python :link(py_1),h4
-
-The LAMMPS distribution includes a python directory with all you need
-to run LAMMPS from Python. The python/lammps.py file wraps the LAMMPS
-library interface, with one wrapper function per LAMMPS library
-function. This file makes it is possible to do the following either
-from a Python script, or interactively from a Python prompt: create
-one or more instances of LAMMPS, invoke LAMMPS commands or give it an
-input script, run LAMMPS incrementally, extract LAMMPS results, an
-modify internal LAMMPS variables. From a Python script you can do
-this in serial or parallel. Running Python interactively in parallel
-does not generally work, unless you have a version of Python that
-extends standard Python to enable multiple instances of Python to read
-what you type.
-
-To do all of this, you must first build LAMMPS as a shared library,
-then insure that your Python can find the python/lammps.py file and
-the shared library. These steps are explained in subsequent sections
-11.3 and 11.4. Sections 11.5 and 11.6 discuss using MPI from a
-parallel Python program and how to test that you are ready to use
-LAMMPS from Python. Section 11.7 lists all the functions in the
-current LAMMPS library interface and how to call them from Python.
-
-Section 11.8 gives some examples of coupling LAMMPS to other tools via
-Python. For example, LAMMPS can easily be coupled to a GUI or other
-visualization tools that display graphs or animations in real time as
-LAMMPS runs. Examples of such scripts are included in the python
-directory.
-
-Two advantages of using Python to run LAMMPS are how concise the
-language is, and that it can be run interactively, enabling rapid
-development and debugging of programs. If you use it to mostly invoke
-costly operations within LAMMPS, such as running a simulation for a
-reasonable number of timesteps, then the overhead cost of invoking
-LAMMPS thru Python will be negligible.
-
-The Python wrapper for LAMMPS uses the amazing and magical (to me)
-"ctypes" package in Python, which auto-generates the interface code
-needed between Python and a set of C interface routines for a library.
-Ctypes is part of standard Python for versions 2.5 and later. You can
-check which version of Python you have installed, by simply typing
-"python" at a shell prompt.
-
-:line
-
-11.2 Overview of using Python from a LAMMPS script :link(py_2),h4
-
-LAMMPS has several commands which can be used to invoke Python
-code directly from an input script:
-
-"python"_python.html
-"variable python"_variable.html
-"fix python/invoke"_fix_python_invoke.html
-"pair_style python"_pair_python.html :ul
-
-The "python"_python.html command which can be used to define and
-execute a Python function that you write the code for. The Python
-function can also be assigned to a LAMMPS python-style variable via
-the "variable"_variable.html command. Each time the variable is
-evaluated, either in the LAMMPS input script itself, or by another
-LAMMPS command that uses the variable, this will trigger the Python
-function to be invoked.
-
-The Python code for the function can be included directly in the input
-script or in an auxiliary file. The function can have arguments which
-are mapped to LAMMPS variables (also defined in the input script) and
-it can return a value to a LAMMPS variable. This is thus a mechanism
-for your input script to pass information to a piece of Python code,
-ask Python to execute the code, and return information to your input
-script.
-
-Note that a Python function can be arbitrarily complex. It can import
-other Python modules, instantiate Python classes, call other Python
-functions, etc. The Python code that you provide can contain more
-code than the single function. It can contain other functions or
-Python classes, as well as global variables or other mechanisms for
-storing state between calls from LAMMPS to the function.
-
-The Python function you provide can consist of "pure" Python code that
-only performs operations provided by standard Python. However, the
-Python function can also "call back" to LAMMPS through its
-Python-wrapped library interface, in the manner described in the
-previous section 11.1. This means it can issue LAMMPS input script
-commands or query and set internal LAMMPS state. As an example, this
-can be useful in an input script to create a more complex loop with
-branching logic, than can be created using the simple looping and
-branching logic enabled by the "next"_next.html and "if"_if.html
-commands.
-
-See the "python"_python.html doc page and the "variable"_variable.html
-doc page for its python-style variables for more info, including
-examples of Python code you can write for both pure Python operations
-and callbacks to LAMMPS.
-
-The "fix python/invoke"_fix_python_invoke.html command can execute
-Python code at selected timesteps during a simulation run.
-
-The "pair_style python"_pair_python command allows you to define
-pairwise potentials as python code which encodes a single pairwise
-interaction. This is useful for rapid-developement and debugging of a
-new potential.
-
-To use any of these commands, you only need to build LAMMPS with the
-PYTHON package installed:
-
-make yes-python
-make machine :pre
-
-Note that this will link LAMMPS with the Python library on your
-system, which typically requires several auxiliary system libraries to
-also be linked. The list of these libraries and the paths to find
-them are specified in the lib/python/Makefile.lammps file. You need
-to insure that file contains the correct information for your version
-of Python and your machine to successfully build LAMMPS. See the
-lib/python/README file for more info.
-
-If you want to write Python code with callbacks to LAMMPS, then you
-must also follow the steps overviewed in the preceding section (11.1)
-for running LAMMPS from Python. I.e. you must build LAMMPS as a
-shared library and insure that Python can find the python/lammps.py
-file and the shared library.
-
-:line
-
-11.3 Building LAMMPS as a shared library :link(py_3),h4
-
-Instructions on how to build LAMMPS as a shared library are given in
-"Section 2.4"_Section_start.html#start_4. A shared library is one
-that is dynamically loadable, which is what Python requires to wrap
-LAMMPS. On Linux this is a library file that ends in ".so", not ".a".
-
-From the src directory, type
-
-make foo mode=shlib :pre
-
-where foo is the machine target name, such as linux or g++ or serial.
-This should create the file liblammps_foo.so in the src directory, as
-well as a soft link liblammps.so, which is what the Python wrapper will
-load by default. Note that if you are building multiple machine
-versions of the shared library, the soft link is always set to the
-most recently built version.
-
-NOTE: If you are building LAMMPS with an MPI or FFT library or other
-auxiliary libraries (used by various packages), then all of these
-extra libraries must also be shared libraries. If the LAMMPS
-shared-library build fails with an error complaining about this, see
-"Section 2.4"_Section_start.html#start_4 for more details.
-
-:line
-
-11.4 Installing the Python wrapper into Python :link(py_4),h4
-
-For Python to invoke LAMMPS, there are 2 files it needs to know about:
-
-python/lammps.py
-src/liblammps.so :ul
-
-Lammps.py is the Python wrapper on the LAMMPS library interface.
-Liblammps.so is the shared LAMMPS library that Python loads, as
-described above.
-
-You can insure Python can find these files in one of two ways:
-
-set two environment variables
-run the python/install.py script :ul
-
-If you set the paths to these files as environment variables, you only
-have to do it once. For the csh or tcsh shells, add something like
-this to your ~/.cshrc file, one line for each of the two files:
-
-setenv PYTHONPATH $\{PYTHONPATH\}:/home/sjplimp/lammps/python
-setenv LD_LIBRARY_PATH $\{LD_LIBRARY_PATH\}:/home/sjplimp/lammps/src :pre
-
-If you use the python/install.py script, you need to invoke it every
-time you rebuild LAMMPS (as a shared library) or make changes to the
-python/lammps.py file.
-
-You can invoke install.py from the python directory as
-
-% python install.py \[libdir\] \[pydir\] :pre
-
-The optional libdir is where to copy the LAMMPS shared library to; the
-default is /usr/local/lib. The optional pydir is where to copy the
-lammps.py file to; the default is the site-packages directory of the
-version of Python that is running the install script.
-
-Note that libdir must be a location that is in your default
-LD_LIBRARY_PATH, like /usr/local/lib or /usr/lib. And pydir must be a
-location that Python looks in by default for imported modules, like
-its site-packages dir. If you want to copy these files to
-non-standard locations, such as within your own user space, you will
-need to set your PYTHONPATH and LD_LIBRARY_PATH environment variables
-accordingly, as above.
-
-If the install.py script does not allow you to copy files into system
-directories, prefix the python command with "sudo". If you do this,
-make sure that the Python that root runs is the same as the Python you
-run. E.g. you may need to do something like
-
-% sudo /usr/local/bin/python install.py \[libdir\] \[pydir\] :pre
-
-You can also invoke install.py from the make command in the src
-directory as
-
-% make install-python :pre
-
-In this mode you cannot append optional arguments. Again, you may
-need to prefix this with "sudo". In this mode you cannot control
-which Python is invoked by root.
-
-Note that if you want Python to be able to load different versions of
-the LAMMPS shared library (see "this section"_#py_5 below), you will
-need to manually copy files like liblammps_g++.so into the appropriate
-system directory. This is not needed if you set the LD_LIBRARY_PATH
-environment variable as described above.
-
-:line
-
-11.5 Extending Python with MPI to run in parallel :link(py_5),h4
-
-If you wish to run LAMMPS in parallel from Python, you need to extend
-your Python with an interface to MPI. This also allows you to
-make MPI calls directly from Python in your script, if you desire.
-
-There are several Python packages available that purport to wrap MPI
-as a library and allow MPI functions to be called from Python. However,
-development on most of them seems to be halted except on:
-
-"mpi4py"_https://bitbucket.org/mpi4py/mpi4py
-"PyPar"_https://github.com/daleroberts/pypar :ul
-
-Both packages, PyPar and mpi4py have been successfully tested with
-LAMMPS. PyPar is simpler and easy to set up and use, but supports
-only a subset of MPI. Mpi4py is more MPI-feature complete, but also a
-bit more complex to use. As of version 2.0.0, mpi4py is the only
-python MPI wrapper that allows passing a custom MPI communicator to
-the LAMMPS constructor, which means one can easily run one or more
-LAMMPS instances on subsets of the total MPI ranks.
-
-:line
-
-PyPar requires the ubiquitous "Numpy package"_http://numpy.scipy.org
-be installed in your Python. After launching Python, type
-
-import numpy :pre
-
-to see if it is installed. If not, here is how to install it (version
-1.3.0b1 as of April 2009). Unpack the numpy tarball and from its
-top-level directory, type
-
-python setup.py build
-sudo python setup.py install :pre
-
-The "sudo" is only needed if required to copy Numpy files into your
-Python distribution's site-packages directory.
-
-To install PyPar (version pypar-2.1.4_94 as of Aug 2012), unpack it
-and from its "source" directory, type
-
-python setup.py build
-sudo python setup.py install :pre
-
-Again, the "sudo" is only needed if required to copy PyPar files into
-your Python distribution's site-packages directory.
-
-If you have successfully installed PyPar, you should be able to run
-Python and type
-
-import pypar :pre
-
-without error. You should also be able to run python in parallel
-on a simple test script
-
-% mpirun -np 4 python test.py :pre
-
-where test.py contains the lines
-
-import pypar
-print "Proc %d out of %d procs" % (pypar.rank(),pypar.size()) :pre
-
-and see one line of output for each processor you run on.
-
-NOTE: To use PyPar and LAMMPS in parallel from Python, you must insure
-both are using the same version of MPI. If you only have one MPI
-installed on your system, this is not an issue, but it can be if you
-have multiple MPIs. Your LAMMPS build is explicit about which MPI it
-is using, since you specify the details in your lo-level
-src/MAKE/Makefile.foo file. PyPar uses the "mpicc" command to find
-information about the MPI it uses to build against. And it tries to
-load "libmpi.so" from the LD_LIBRARY_PATH. This may or may not find
-the MPI library that LAMMPS is using. If you have problems running
-both PyPar and LAMMPS together, this is an issue you may need to
-address, e.g. by moving other MPI installations so that PyPar finds
-the right one.
-
-:line
-
-To install mpi4py (version mpi4py-2.0.0 as of Oct 2015), unpack it
-and from its main directory, type
-
-python setup.py build
-sudo python setup.py install :pre
-
-Again, the "sudo" is only needed if required to copy mpi4py files into
-your Python distribution's site-packages directory. To install with
-user privilege into the user local directory type
-
-python setup.py install --user :pre
-
-If you have successfully installed mpi4py, you should be able to run
-Python and type
-
-from mpi4py import MPI :pre
-
-without error. You should also be able to run python in parallel
-on a simple test script
-
-% mpirun -np 4 python test.py :pre
-
-where test.py contains the lines
-
-from mpi4py import MPI
-comm = MPI.COMM_WORLD
-print "Proc %d out of %d procs" % (comm.Get_rank(),comm.Get_size()) :pre
-
-and see one line of output for each processor you run on.
-
-NOTE: To use mpi4py and LAMMPS in parallel from Python, you must
-insure both are using the same version of MPI. If you only have one
-MPI installed on your system, this is not an issue, but it can be if
-you have multiple MPIs. Your LAMMPS build is explicit about which MPI
-it is using, since you specify the details in your lo-level
-src/MAKE/Makefile.foo file. Mpi4py uses the "mpicc" command to find
-information about the MPI it uses to build against. And it tries to
-load "libmpi.so" from the LD_LIBRARY_PATH. This may or may not find
-the MPI library that LAMMPS is using. If you have problems running
-both mpi4py and LAMMPS together, this is an issue you may need to
-address, e.g. by moving other MPI installations so that mpi4py finds
-the right one.
-
-:line
-
-11.6 Testing the Python-LAMMPS interface :link(py_6),h4
-
-To test if LAMMPS is callable from Python, launch Python interactively
-and type:
-
->>> from lammps import lammps
->>> lmp = lammps() :pre
-
-If you get no errors, you're ready to use LAMMPS from Python. If the
-2nd command fails, the most common error to see is
-
-OSError: Could not load LAMMPS dynamic library :pre
-
-which means Python was unable to load the LAMMPS shared library. This
-typically occurs if the system can't find the LAMMPS shared library or
-one of the auxiliary shared libraries it depends on, or if something
-about the library is incompatible with your Python. The error message
-should give you an indication of what went wrong.
-
-You can also test the load directly in Python as follows, without
-first importing from the lammps.py file:
-
->>> from ctypes import CDLL
->>> CDLL("liblammps.so") :pre
-
-If an error occurs, carefully go thru the steps in "Section
-2.4"_Section_start.html#start_4 and above about building a shared
-library and about insuring Python can find the necessary two files
-it needs.
-
-[Test LAMMPS and Python in serial:] :h4
-
-To run a LAMMPS test in serial, type these lines into Python
-interactively from the bench directory:
-
->>> from lammps import lammps
->>> lmp = lammps()
->>> lmp.file("in.lj") :pre
-
-Or put the same lines in the file test.py and run it as
-
-% python test.py :pre
-
-Either way, you should see the results of running the in.lj benchmark
-on a single processor appear on the screen, the same as if you had
-typed something like:
-
-lmp_g++ -in in.lj :pre
-
-[Test LAMMPS and Python in parallel:] :h4
-
-To run LAMMPS in parallel, assuming you have installed the
-"PyPar"_https://github.com/daleroberts/pypar package as discussed
-above, create a test.py file containing these lines:
-
-import pypar
-from lammps import lammps
-lmp = lammps()
-lmp.file("in.lj")
-print "Proc %d out of %d procs has" % (pypar.rank(),pypar.size()),lmp
-pypar.finalize() :pre
-
-To run LAMMPS in parallel, assuming you have installed the
-"mpi4py"_https://bitbucket.org/mpi4py/mpi4py package as discussed
-above, create a test.py file containing these lines:
-
-from mpi4py import MPI
-from lammps import lammps
-lmp = lammps()
-lmp.file("in.lj")
-me = MPI.COMM_WORLD.Get_rank()
-nprocs = MPI.COMM_WORLD.Get_size()
-print "Proc %d out of %d procs has" % (me,nprocs),lmp
-MPI.Finalize() :pre
-
-You can either script in parallel as:
-
-% mpirun -np 4 python test.py :pre
-
-and you should see the same output as if you had typed
-
-% mpirun -np 4 lmp_g++ -in in.lj :pre
-
-Note that if you leave out the 3 lines from test.py that specify PyPar
-commands you will instantiate and run LAMMPS independently on each of
-the P processors specified in the mpirun command. In this case you
-should get 4 sets of output, each showing that a LAMMPS run was made
-on a single processor, instead of one set of output showing that
-LAMMPS ran on 4 processors. If the 1-processor outputs occur, it
-means that PyPar is not working correctly.
-
-Also note that once you import the PyPar module, PyPar initializes MPI
-for you, and you can use MPI calls directly in your Python script, as
-described in the PyPar documentation. The last line of your Python
-script should be pypar.finalize(), to insure MPI is shut down
-correctly.
-
-[Running Python scripts:] :h4
-
-Note that any Python script (not just for LAMMPS) can be invoked in
-one of several ways:
-
-% python foo.script
-% python -i foo.script
-% foo.script :pre
-
-The last command requires that the first line of the script be
-something like this:
-
-#!/usr/local/bin/python
-#!/usr/local/bin/python -i :pre
-
-where the path points to where you have Python installed, and that you
-have made the script file executable:
-
-% chmod +x foo.script :pre
-
-Without the "-i" flag, Python will exit when the script finishes.
-With the "-i" flag, you will be left in the Python interpreter when
-the script finishes, so you can type subsequent commands. As
-mentioned above, you can only run Python interactively when running
-Python on a single processor, not in parallel.
-
-:line
-:line
-
-11.7 Using LAMMPS from Python :link(py_7),h4
-
-As described above, the Python interface to LAMMPS consists of a
-Python "lammps" module, the source code for which is in
-python/lammps.py, which creates a "lammps" object, with a set of
-methods that can be invoked on that object. The sample Python code
-below assumes you have first imported the "lammps" module in your
-Python script, as follows:
-
-from lammps import lammps :pre
-
-These are the methods defined by the lammps module. If you look at
-the files src/library.cpp and src/library.h you will see they
-correspond one-to-one with calls you can make to the LAMMPS library
-from a C++ or C or Fortran program, and which are described in
-"Section 6.19"_Section_howto.html#howto_19 of the manual.
-
-The python/examples directory has Python scripts which show how Python
-can run LAMMPS, grab data, change it, and put it back into LAMMPS.
-
-lmp = lammps() # create a LAMMPS object using the default liblammps.so library
- # 4 optional args are allowed: name, cmdargs, ptr, comm
-lmp = lammps(ptr=lmpptr) # use lmpptr as previously created LAMMPS object
-lmp = lammps(comm=split) # create a LAMMPS object with a custom communicator, requires mpi4py 2.0.0 or later
-lmp = lammps(name="g++") # create a LAMMPS object using the liblammps_g++.so library
-lmp = lammps(name="g++",cmdargs=list) # add LAMMPS command-line args, e.g. list = \["-echo","screen"\] :pre
-
-lmp.close() # destroy a LAMMPS object :pre
-
-version = lmp.version() # return the numerical version id, e.g. LAMMPS 2 Sep 2015 -> 20150902 :pre
-
-lmp.file(file) # run an entire input script, file = "in.lj"
-lmp.command(cmd) # invoke a single LAMMPS command, cmd = "run 100"
-lmp.commands_list(cmdlist) # invoke commands in cmdlist = ["run 10", "run 20"]
-lmp.commands_string(multicmd) # invoke commands in multicmd = "run 10\nrun 20" :pre
-
-size = lmp.extract_setting(name) # return data type info :pre
-
-xlo = lmp.extract_global(name,type) # extract a global quantity
- # name = "boxxlo", "nlocal", etc
- # type = 0 = int
- # 1 = double :pre
-
-boxlo,boxhi,xy,yz,xz,periodicity,box_change = lmp.extract_box() # extract box info :pre
-
-coords = lmp.extract_atom(name,type) # extract a per-atom quantity
- # name = "x", "type", etc
- # type = 0 = vector of ints
- # 1 = array of ints
- # 2 = vector of doubles
- # 3 = array of doubles :pre
-
-eng = lmp.extract_compute(id,style,type) # extract value(s) from a compute
-v3 = lmp.extract_fix(id,style,type,i,j) # extract value(s) from a fix
- # id = ID of compute or fix
- # style = 0 = global data
- # 1 = per-atom data
- # 2 = local data
- # type = 0 = scalar
- # 1 = vector
- # 2 = array
- # i,j = indices of value in global vector or array :pre
-
-var = lmp.extract_variable(name,group,flag) # extract value(s) from a variable
- # name = name of variable
- # group = group ID (ignored for equal-style variables)
- # flag = 0 = equal-style variable
- # 1 = atom-style variable :pre
-
-value = lmp.get_thermo(name) # return current value of a thermo keyword
-natoms = lmp.get_natoms() # total # of atoms as int :pre
-
-flag = lmp.set_variable(name,value) # set existing named string-style variable to value, flag = 0 if successful
-lmp.reset_box(boxlo,boxhi,xy,yz,xz) # reset the simulation box size :pre
-
-data = lmp.gather_atoms(name,type,count) # return per-atom property of all atoms gathered into data, ordered by atom ID
- # name = "x", "charge", "type", etc
-data = lmp.gather_atoms_concat(name,type,count) # ditto, but concatenated atom values from each proc (unordered)
-data = lmp.gather_atoms_subset(name,type,count,ndata,ids) # ditto, but for subset of Ndata atoms with IDs :pre
-
-lmp.scatter_atoms(name,type,count,data) # scatter per-atom property to all atoms from data, ordered by atom ID
- # name = "x", "charge", "type", etc
- # count = # of per-atom values, 1 or 3, etc :pre
-lmp.scatter_atoms_subset(name,type,count,ndata,ids,data) # ditto, but for subset of Ndata atoms with IDs :pre
-
-lmp.create_atoms(n,ids,types,x,v,image,shrinkexceed) # create N atoms with IDs, types, x, v, and image flags :pre
-
-:line
-
-The lines
-
-from lammps import lammps
-lmp = lammps() :pre
-
-create an instance of LAMMPS, wrapped in a Python class by the lammps
-Python module, and return an instance of the Python class as lmp. It
-is used to make all subsequent calls to the LAMMPS library.
-
-Additional arguments to lammps() can be used to tell Python the name
-of the shared library to load or to pass arguments to the LAMMPS
-instance, the same as if LAMMPS were launched from a command-line
-prompt.
-
-If the ptr argument is set like this:
-
-lmp = lammps(ptr=lmpptr) :pre
-
-then lmpptr must be an argument passed to Python via the LAMMPS
-"python"_python.html command, when it is used to define a Python
-function that is invoked by the LAMMPS input script. This mode of
-using Python with LAMMPS is described above in 11.2. The variable
-lmpptr refers to the instance of LAMMPS that called the embedded
-Python interpreter. Using it as an argument to lammps() allows the
-returned Python class instance "lmp" to make calls to that instance of
-LAMMPS. See the "python"_python.html command doc page for examples
-using this syntax.
-
-Note that you can create multiple LAMMPS objects in your Python
-script, and coordinate and run multiple simulations, e.g.
-
-from lammps import lammps
-lmp1 = lammps()
-lmp2 = lammps()
-lmp1.file("in.file1")
-lmp2.file("in.file2") :pre
-
-The file(), command(), commands_list(), commands_string() methods
-allow an input script, a single command, or multiple commands to be
-invoked.
-
-The extract_setting(), extract_global(), extract_box(),
-extract_atom(), extract_compute(), extract_fix(), and
-extract_variable() methods return values or pointers to data
-structures internal to LAMMPS.
-
-For extract_global() see the src/library.cpp file for the list of
-valid names. New names could easily be added. A double or integer is
-returned. You need to specify the appropriate data type via the type
-argument.
-
-For extract_atom(), a pointer to internal LAMMPS atom-based data is
-returned, which you can use via normal Python subscripting. See the
-extract() method in the src/atom.cpp file for a list of valid names.
-Again, new names could easily be added if the property you want is not
-listed. A pointer to a vector of doubles or integers, or a pointer to
-an array of doubles (double **) or integers (int **) is returned. You
-need to specify the appropriate data type via the type argument.
-
-For extract_compute() and extract_fix(), the global, per-atom, or
-local data calculated by the compute or fix can be accessed. What is
-returned depends on whether the compute or fix calculates a scalar or
-vector or array. For a scalar, a single double value is returned. If
-the compute or fix calculates a vector or array, a pointer to the
-internal LAMMPS data is returned, which you can use via normal Python
-subscripting. The one exception is that for a fix that calculates a
-global vector or array, a single double value from the vector or array
-is returned, indexed by I (vector) or I and J (array). I,J are
-zero-based indices. The I,J arguments can be left out if not needed.
-See "Section 6.15"_Section_howto.html#howto_15 of the manual for a
-discussion of global, per-atom, and local data, and of scalar, vector,
-and array data types. See the doc pages for individual
-"computes"_compute.html and "fixes"_fix.html for a description of what
-they calculate and store.
-
-For extract_variable(), an "equal-style or atom-style
-variable"_variable.html is evaluated and its result returned.
-
-For equal-style variables a single double value is returned and the
-group argument is ignored. For atom-style variables, a vector of
-doubles is returned, one value per atom, which you can use via normal
-Python subscripting. The values will be zero for atoms not in the
-specified group.
-
-The get_thermo() method returns returns the current value of a thermo
-keyword as a float.
-
-The get_natoms() method returns the total number of atoms in the
-simulation, as an int.
-
-The set_variable() methosd sets an existing string-style variable to a
-new string value, so that subsequent LAMMPS commands can access the
-variable.
-
-The reset_box() emthods resets the size and shape of the simulation
-box, e.g. as part of restoring a previously extracted and saved state
-of a simulation.
-
-The gather methods collect peratom info of the requested type (atom
-coords, atom types, forces, etc) from all processors, and returns the
-same vector of values to each callling processor. The scatter
-functions do the inverse. They distribute a vector of peratom values,
-passed by all calling processors, to invididual atoms, which may be
-owned by different processos.
-
-Note that the data returned by the gather methods,
-e.g. gather_atoms("x"), is different from the data structure returned
-by extract_atom("x") in four ways. (1) Gather_atoms() returns a
-vector which you index as x\[i\]; extract_atom() returns an array
-which you index as x\[i\]\[j\]. (2) Gather_atoms() orders the atoms
-by atom ID while extract_atom() does not. (3) Gather_atoms() returns
-a list of all atoms in the simulation; extract_atoms() returns just
-the atoms local to each processor. (4) Finally, the gather_atoms()
-data structure is a copy of the atom coords stored internally in
-LAMMPS, whereas extract_atom() returns an array that effectively
-points directly to the internal data. This means you can change
-values inside LAMMPS from Python by assigning a new values to the
-extract_atom() array. To do this with the gather_atoms() vector, you
-need to change values in the vector, then invoke the scatter_atoms()
-method.
-
-For the scatter methods, the array of coordinates passed to must be a
-ctypes vector of ints or doubles, allocated and initialized something
-like this:
-
-from ctypes import *
-natoms = lmp.get_natoms()
-n3 = 3*natoms
-x = (n3*c_double)()
-x\[0\] = x coord of atom with ID 1
-x\[1\] = y coord of atom with ID 1
-x\[2\] = z coord of atom with ID 1
-x\[3\] = x coord of atom with ID 2
-...
-x\[n3-1\] = z coord of atom with ID natoms
-lmp.scatter_atoms("x",1,3,x) :pre
-
-Alternatively, you can just change values in the vector returned by
-the gather methods, since they are also ctypes vectors.
-
-:line
-
-As noted above, these Python class methods correspond one-to-one with
-the functions in the LAMMPS library interface in src/library.cpp and
-library.h. This means you can extend the Python wrapper via the
-following steps:
-
-Add a new interface function to src/library.cpp and
-src/library.h. :ulb,l
-
-Rebuild LAMMPS as a shared library. :l
-
-Add a wrapper method to python/lammps.py for this interface
-function. :l
-
-You should now be able to invoke the new interface function from a
-Python script. Isn't ctypes amazing? :l
-:ule
-
-:line
-:line
-
-11.8 Example Python scripts that use LAMMPS :link(py_8),h4
-
-These are the Python scripts included as demos in the python/examples
-directory of the LAMMPS distribution, to illustrate the kinds of
-things that are possible when Python wraps LAMMPS. If you create your
-own scripts, send them to us and we can include them in the LAMMPS
-distribution.
-
-trivial.py, read/run a LAMMPS input script thru Python,
-demo.py, invoke various LAMMPS library interface routines,
-simple.py, run in parallel, similar to examples/COUPLE/simple/simple.cpp,
-split.py, same as simple.py but running in parallel on a subset of procs,
-gui.py, GUI go/stop/temperature-slider to control LAMMPS,
-plot.py, real-time temperature plot with GnuPlot via Pizza.py,
-viz_tool.py, real-time viz via some viz package,
-vizplotgui_tool.py, combination of viz_tool.py and plot.py and gui.py :tb(c=2)
-
-:line
-
-For the viz_tool.py and vizplotgui_tool.py commands, replace "tool"
-with "gl" or "atomeye" or "pymol" or "vmd", depending on what
-visualization package you have installed.
-
-Note that for GL, you need to be able to run the Pizza.py GL tool,
-which is included in the pizza sub-directory. See the "Pizza.py doc
-pages"_pizza for more info:
-
-:link(pizza,http://www.sandia.gov/~sjplimp/pizza.html)
-
-Note that for AtomEye, you need version 3, and there is a line in the
-scripts that specifies the path and name of the executable. See the
-AtomEye WWW pages "here"_atomeye or "here"_atomeye3 for more details:
-
-http://mt.seas.upenn.edu/Archive/Graphics/A
-http://mt.seas.upenn.edu/Archive/Graphics/A3/A3.html :pre
-
-:link(atomeye,http://mt.seas.upenn.edu/Archive/Graphics/A)
-:link(atomeye3,http://mt.seas.upenn.edu/Archive/Graphics/A3/A3.html)
-
-The latter link is to AtomEye 3 which has the scriping
-capability needed by these Python scripts.
-
-Note that for PyMol, you need to have built and installed the
-open-source version of PyMol in your Python, so that you can import it
-from a Python script. See the PyMol WWW pages "here"_pymolhome or
-"here"_pymolopen for more details:
-
-http://www.pymol.org
-http://sourceforge.net/scm/?type=svn&group_id=4546 :pre
-
-:link(pymolhome,http://www.pymol.org)
-:link(pymolopen,http://sourceforge.net/scm/?type=svn&group_id=4546)
-
-The latter link is to the open-source version.
-
-Note that for VMD, you need a fairly current version (1.8.7 works for
-me) and there are some lines in the pizza/vmd.py script for 4 PIZZA
-variables that have to match the VMD installation on your system.
-
-:line
-
-See the python/README file for instructions on how to run them and the
-source code for individual scripts for comments about what they do.
-
-Here are screenshots of the vizplotgui_tool.py script in action for
-different visualization package options. Click to see larger images:
-
-:image(JPG/screenshot_gl_small.jpg,JPG/screenshot_gl.jpg)
-:image(JPG/screenshot_atomeye_small.jpg,JPG/screenshot_atomeye.jpg)
-:image(JPG/screenshot_pymol_small.jpg,JPG/screenshot_pymol.jpg)
-:image(JPG/screenshot_vmd_small.jpg,JPG/screenshot_vmd.jpg)
-
-11.9 PyLammps interface :link(py_9),h4
-
-Please see the "PyLammps Tutorial"_tutorial_pylammps.html.
diff --git a/doc/src/Section_start.txt b/doc/src/Section_start.txt
deleted file mode 100644
index 7d456171dc5f26a3362b2bbdbb6fe8634a245802..0000000000000000000000000000000000000000
--- a/doc/src/Section_start.txt
+++ /dev/null
@@ -1,1817 +0,0 @@
-"Previous Section"_Section_intro.html - "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Section_commands.html :c
-
-:link(lws,http://lammps.sandia.gov)
-:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
-
-:line
-
-2. Getting Started :h2
-
-This section describes how to build and run LAMMPS, for both new and
-experienced users.
-
-2.1 "What's in the LAMMPS distribution"_#start_1
-2.2 "Making LAMMPS"_#start_2
-2.3 "Making LAMMPS with optional packages"_#start_3
-2.4 "Building LAMMPS as a library"_#start_4
-2.5 "Running LAMMPS"_#start_5
-2.6 "Command-line options"_#start_6
-2.7 "Screen output"_#start_7
-2.8 "Tips for users of previous versions"_#start_8 :all(b)
-
-:line
-
-2.1 What's in the LAMMPS distribution :h3,link(start_1)
-
-When you download a LAMMPS tarball you will need to unzip and untar
-the downloaded file with the following commands, after placing the
-tarball in an appropriate directory.
-
-tar -xzvf lammps*.tar.gz :pre
-
-This will create a LAMMPS directory containing two files and several
-sub-directories:
-
-README: text file
-LICENSE: the GNU General Public License (GPL)
-bench: benchmark problems
-doc: documentation
-examples: simple test problems
-potentials: embedded atom method (EAM) potential files
-src: source files
-tools: pre- and post-processing tools :tb(s=:)
-
-Note that the "download page"_download also has links to download
-pre-build Windows installers, as well as pre-built packages for
-several widely used Linux distributions. It also has instructions
-for how to download/install LAMMPS for Macs (via Homebrew), and to
-download and update LAMMPS from SVN and Git repositories, which gives
-you access to the up-to-date sources that are used by the LAMMPS
-core developers.
-
-:link(download,http://lammps.sandia.gov/download.html)
-
-The Windows and Linux packages for serial or parallel include
-only selected packages and bug-fixes/upgrades listed on "this
-page"_http://lammps.sandia.gov/bug.html up to a certain date, as
-stated on the download page. If you want an executable with
-non-included packages or that is more current, then you'll need to
-build LAMMPS yourself, as discussed in the next section.
-
-Skip to the "Running LAMMPS"_#start_6 sections for info on how to
-launch a LAMMPS Windows executable on a Windows box.
-
-:line
-
-2.2 Making LAMMPS :h3,link(start_2)
-
-This section has the following sub-sections:
-
-2.2.1 "Read this first"_#start_2_1
-2.2.1 "Steps to build a LAMMPS executable"_#start_2_2
-2.2.3 "Common errors that can occur when making LAMMPS"_#start_2_3
-2.2.4 "Additional build tips"_#start_2_4
-2.2.5 "Building for a Mac"_#start_2_5
-2.2.6 "Building for Windows"_#start_2_6 :all(b)
-
-:line
-
-Read this first :h4,link(start_2_1)
-
-If you want to avoid building LAMMPS yourself, read the preceding
-section about options available for downloading and installing
-executables. Details are discussed on the "download"_download page.
-
-Building LAMMPS can be simple or not-so-simple. If all you need are
-the default packages installed in LAMMPS, and MPI is already installed
-on your machine, or you just want to run LAMMPS in serial, then you
-can typically use the Makefile.mpi or Makefile.serial files in
-src/MAKE by typing one of these lines (from the src dir):
-
-make mpi
-make serial :pre
-
-Note that on a facility supercomputer, there are often "modules"
-loaded in your environment that provide the compilers and MPI you
-should use. In this case, the "mpicxx" compile/link command in
-Makefile.mpi should simply work by accessing those modules.
-
-It may be the case that one of the other Makefile.machine files in the
-src/MAKE sub-directories is a better match to your system (type "make"
-to see a list), you can use it as-is by typing (for example):
-
-make stampede :pre
-
-If any of these builds (with an existing Makefile.machine) works on
-your system, then you're done!
-
-If you need to install an optional package with a LAMMPS command you
-want to use, and the package does not depend on an extra library, you
-can simply type
-
-make name :pre
-
-before invoking (or re-invoking) the above steps. "Name" is the
-lower-case name of the package, e.g. replica or user-misc.
-
-If you want to do one of the following:
-
-use a LAMMPS command that requires an extra library (e.g. "dump image"_dump_image.html)
-build with a package that requires an extra library
-build with an accelerator package that requires special compiler/linker settings
-run on a machine that has its own compilers, settings, or libraries :ul
-
-then building LAMMPS is more complicated. You may need to find where
-extra libraries exist on your machine or install them if they don't.
-You may need to build extra libraries that are included in the LAMMPS
-distribution, before building LAMMPS itself. You may need to edit a
-Makefile.machine file to make it compatible with your system.
-
-Please read the following sections carefully. If you are not
-comfortable with makefiles, or building codes on a Unix platform, or
-running an MPI job on your machine, please find a local expert to help
-you. Many compilation, linking, and run problems users experience are
-often not LAMMPS issues - they are peculiar to the user's system,
-compilers, libraries, etc. Such questions are better answered by a
-local expert.
-
-If you have a build problem that you are convinced is a LAMMPS issue
-(e.g. the compiler complains about a line of LAMMPS source code), then
-please post the issue to the "LAMMPS mail
-list"_http://lammps.sandia.gov/mail.html.
-
-If you succeed in building LAMMPS on a new kind of machine, for which
-there isn't a similar machine Makefile included in the
-src/MAKE/MACHINES directory, then send it to the developers and we can
-include it in the LAMMPS distribution.
-
-:line
-
-Steps to build a LAMMPS executable :h4,link(start_2_2)
-
-Step 0 :h5
-
-The src directory contains the C++ source and header files for LAMMPS.
-It also contains a top-level Makefile and a MAKE sub-directory with
-low-level Makefile.* files for many systems and machines. See the
-src/MAKE/README file for a quick overview of what files are available
-and what sub-directories they are in.
-
-The src/MAKE dir has a few files that should work as-is on many
-platforms. The src/MAKE/OPTIONS dir has more that invoke additional
-compiler, MPI, and other setting options commonly used by LAMMPS, to
-illustrate their syntax. The src/MAKE/MACHINES dir has many more that
-have been tweaked or optimized for specific machines. These files are
-all good starting points if you find you need to change them for your
-machine. Put any file you edit into the src/MAKE/MINE directory and
-it will be never be touched by any LAMMPS updates.
-
->From within the src directory, type "make" or "gmake". You should see
-a list of available choices from src/MAKE and all of its
-sub-directories. If one of those has the options you want or is the
-machine you want, you can type a command like:
-
-make mpi :pre
-or
-
-make serial :pre
-or
-
-gmake mac :pre
-
-Note that the corresponding Makefile.machine can exist in src/MAKE or
-any of its sub-directories. If a file with the same name appears in
-multiple places (not a good idea), the order they are used is as
-follows: src/MAKE/MINE, src/MAKE, src/MAKE/OPTIONS, src/MAKE/MACHINES.
-This gives preference to a file you have created/edited and put in
-src/MAKE/MINE.
-
-Note that on a multi-processor or multi-core platform you can launch a
-parallel make, by using the "-j" switch with the make command, which
-will build LAMMPS more quickly.
-
-If you get no errors and an executable like [lmp_mpi] or [lmp_serial]
-or [lmp_mac] is produced, then you're done; it's your lucky day.
-
-Note that by default only a few of LAMMPS optional packages are
-installed. To build LAMMPS with optional packages, see "this
-section"_#start_3 below.
-
-Step 1 :h5
-
-If Step 0 did not work, you will need to create a low-level Makefile
-for your machine, like Makefile.foo. You should make a copy of an
-existing Makefile.* in src/MAKE or one of its sub-directories as a
-starting point. The only portions of the file you need to edit are
-the first line, the "compiler/linker settings" section, and the
-"LAMMPS-specific settings" section. When it works, put the edited
-file in src/MAKE/MINE and it will not be altered by any future LAMMPS
-updates.
-
-Step 2 :h5
-
-Change the first line of Makefile.foo to list the word "foo" after the
-"#", and whatever other options it will set. This is the line you
-will see if you just type "make".
-
-Step 3 :h5
-
-The "compiler/linker settings" section lists compiler and linker
-settings for your C++ compiler, including optimization flags. You can
-use g++, the open-source GNU compiler, which is available on all Unix
-systems. You can also use mpicxx which will typically be available if
-MPI is installed on your system, though you should check which actual
-compiler it wraps. Vendor compilers often produce faster code. On
-boxes with Intel CPUs, we suggest using the Intel icc compiler, which
-can be downloaded from "Intel's compiler site"_intel.
-
-:link(intel,http://www.intel.com/software/products/noncom)
-
-If building a C++ code on your machine requires additional libraries,
-then you should list them as part of the LIB variable. You should
-not need to do this if you use mpicxx.
-
-The DEPFLAGS setting is what triggers the C++ compiler to create a
-dependency list for a source file. This speeds re-compilation when
-source (*.cpp) or header (*.h) files are edited. Some compilers do
-not support dependency file creation, or may use a different switch
-than -D. GNU g++ and Intel icc works with -D. If your compiler can't
-create dependency files, then you'll need to create a Makefile.foo
-patterned after Makefile.storm, which uses different rules that do not
-involve dependency files. Note that when you build LAMMPS for the
-first time on a new platform, 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.
-
-Step 4 :h5
-
-The "system-specific settings" section has several parts. Note that
-if you change any -D setting in this section, you should do a full
-re-compile, after typing "make clean" (which will describe different
-clean options).
-
-The LMP_INC variable is used to include options that turn on ifdefs
-within the LAMMPS code. The options that are currently recognized are:
-
--DLAMMPS_GZIP
--DLAMMPS_JPEG
--DLAMMPS_PNG
--DLAMMPS_FFMPEG
--DLAMMPS_MEMALIGN
--DLAMMPS_SMALLBIG
--DLAMMPS_BIGBIG
--DLAMMPS_SMALLSMALL
--DLAMMPS_LONGLONG_TO_LONG
--DLAMMPS_EXCEPTIONS
--DPACK_ARRAY
--DPACK_POINTER
--DPACK_MEMCPY :ul
-
-The read_data and dump commands will read/write gzipped files if you
-compile with -DLAMMPS_GZIP. It 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 are
-provided in the COMPRESS package. From more details about compiling
-LAMMPS with packages, please see below.
-
-If you use -DLAMMPS_JPEG, the "dump image"_dump_image.html command
-will be able to write out JPEG image files. For JPEG files, you must
-also link LAMMPS with a JPEG library, as described below. If you use
--DLAMMPS_PNG, the "dump image"_dump.html command will be able to write
-out PNG image files. For PNG files, you must also link LAMMPS with a
-PNG library, as described below. If neither of those two defines are
-used, LAMMPS will only be able to write out uncompressed PPM image
-files.
-
-If you use -DLAMMPS_FFMPEG, the "dump movie"_dump_image.html command
-will be available to support on-the-fly generation of rendered movies
-the need to store intermediate image files. It requires that your
-machines supports the "popen" function in the standard runtime library
-and that an FFmpeg executable can be found by LAMMPS during the run.
-
-NOTE: Similar to the note above, this option can conflict with
-high-speed networks, because it uses popen().
-
-Using -DLAMMPS_MEMALIGN=<bytes> enables the use of the
-posix_memalign() call instead of malloc() when large chunks or memory
-are allocated by LAMMPS. This can help to make more efficient use of
-vector instructions of modern CPUS, since dynamically allocated memory
-has to be aligned on larger than default byte boundaries (e.g. 16
-bytes instead of 8 bytes on x86 type platforms) for optimal
-performance.
-
-Use at most one of the -DLAMMPS_SMALLBIG, -DLAMMPS_BIGBIG,
--DLAMMPS_SMALLSMALL settings. The default is -DLAMMPS_SMALLBIG. These
-settings refer to use of 4-byte (small) vs 8-byte (big) integers
-within LAMMPS, as specified in src/lmptype.h. The only reason to use
-the BIGBIG setting is to enable simulation of huge molecular systems
-(which store bond topology info) with more than 2 billion atoms, or to
-track the image flags of moving atoms that wrap around a periodic box
-more than 512 times. Normally, the only reason to use SMALLSMALL is
-if your machine does not support 64-bit integers, though you can use
-SMALLSMALL setting if you are running in serial or on a desktop
-machine or small cluster where you will never run large systems or for
-long time (more than 2 billion atoms, more than 2 billion timesteps).
-See the "Additional build tips"_#start_2_4 section below for more
-details on these settings.
-
-Note that the USER-ATC package is not currently compatible with
--DLAMMPS_BIGBIG. Also the GPU package requires the lib/gpu library to
-be compiled with the same setting, or the link will fail.
-
-The -DLAMMPS_LONGLONG_TO_LONG setting may be needed if your system or
-MPI version does not recognize "long long" data types. In this case a
-"long" data type is likely already 64-bits, in which case this setting
-will convert to that data type.
-
-The -DLAMMPS_EXCEPTIONS setting can be used to activate alternative
-versions of error handling inside of LAMMPS. This is useful when
-external codes drive LAMMPS as a library. Using this option, LAMMPS
-errors do not kill the caller. Instead, the call stack is unwound and
-control returns to the caller. The library interface provides the
-lammps_has_error() and lammps_get_last_error_message() functions to
-detect and find out more about a LAMMPS error.
-
-Using one of the -DPACK_ARRAY, -DPACK_POINTER, and -DPACK_MEMCPY
-options can make for faster parallel FFTs (in the PPPM solver) on some
-platforms. The -DPACK_ARRAY setting is the default. See the
-"kspace_style"_kspace_style.html command for info about PPPM. See
-Step 6 below for info about building LAMMPS with an FFT library.
-
-Step 5 :h5
-
-The 3 MPI variables are used to specify an MPI library to build LAMMPS
-with. Note that you do not need to set these if you use the MPI
-compiler mpicxx for your CC and LINK setting in the section above.
-The MPI wrapper knows where to find the needed files.
-
-If you want LAMMPS to run in parallel, you must have an MPI library
-installed on your platform. If MPI is installed on your system in the
-usual place (under /usr/local), you also may not need to specify these
-3 variables, assuming /usr/local is in your path. On some large
-parallel machines which use "modules" for their compile/link
-environments, you may simply need to include the correct module in
-your build environment, before building LAMMPS. Or the parallel
-machine may have a vendor-provided MPI which the compiler has no
-trouble finding.
-
-Failing this, these 3 variables can be used to specify where the mpi.h
-file (MPI_INC) and the MPI library file (MPI_PATH) are found and the
-name of the library file (MPI_LIB).
-
-If you are installing MPI yourself, we recommend Argonne's MPICH2
-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 big
-parallel platform, your system people 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. If you use MPICH or OpenMPI, you will have to
-configure and build it for your platform. The MPI configure script
-should have compiler options to enable you to use the same compiler
-you are using for the LAMMPS build, which can avoid problems that can
-arise when linking LAMMPS to the MPI library.
-
-If you just want to run LAMMPS on a single processor, you can use the
-dummy MPI library provided in src/STUBS, since you don't need a true
-MPI library installed on your system. See src/MAKE/Makefile.serial
-for how to specify the 3 MPI variables in this case. You will also
-need to build the STUBS library for your platform before making LAMMPS
-itself. Note that if you are building with src/MAKE/Makefile.serial,
-e.g. by typing "make serial", then the STUBS library is built for you.
-
-To build the STUBS library from the src directory, type "make
-mpi-stubs", or from the src/STUBS dir, type "make". This should
-create a libmpi_stubs.a file suitable for linking to LAMMPS. 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.
-
-Step 6 :h5
-
-The 3 FFT variables allow you to specify an FFT library which LAMMPS
-uses (for performing 1d FFTs) when running the particle-particle
-particle-mesh (PPPM) option for long-range Coulombics via the
-"kspace_style"_kspace_style.html command.
-
-LAMMPS supports common open-source or vendor-supplied FFT libraries
-for this purpose. If you leave these 3 variables blank, LAMMPS will
-use the open-source "KISS FFT library"_http://kissfft.sf.net, which is
-included in the LAMMPS distribution. This library is portable to all
-platforms and for typical LAMMPS simulations is almost as fast as FFTW
-or vendor optimized libraries. If you are not including the KSPACE
-package in your build, you can also leave the 3 variables blank.
-
-Otherwise, select which kinds of FFTs to use as part of the FFT_INC
-setting by a switch of the form -DFFT_XXX. Recommended values for XXX
-are: MKL or FFTW3. FFTW2 and NONE are supported as legacy options.
-Selecting -DFFT_FFTW will use the FFTW3 library and -DFFT_NONE will
-use the KISS library described above.
-
-You may also need to set the FFT_INC, FFT_PATH, and FFT_LIB variables,
-so the compiler and linker can find the needed FFT header and library
-files. Note that on some large parallel machines which use "modules"
-for their compile/link environments, you may simply need to include
-the correct module in your build environment. Or the parallel machine
-may have a vendor-provided FFT library which the compiler has no
-trouble finding. See the src/MAKE/OPTIONS/Makefile.fftw file for an
-example of how to specify these variables to use the FFTW3 library.
-
-FFTW is fast, portable library that should also work on any platform
-and typically be faster than KISS FFT. You can download it from
-"www.fftw.org"_http://www.fftw.org. Both the legacy version 2.1.X and
-the newer 3.X versions are supported as -DFFT_FFTW2 or -DFFT_FFTW3.
-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.
-
-If you wish to have FFTW support for single-precision FFTs (see below
-about -DFFT_SINGLE) in addition to the default double-precision FFTs,
-you will need to build FFTW a second time for single-precision. For
-FFTW3, do this via:
-
-make clean
-./configure --enable-single; make; make install :pre
-
-which should produce the additional library libfftw3f.a.
-
-For FFTW2, do this:
-
-make clean
-./configure --enable-float --enable-type-prefix; make; make install :pre
-
-which should produce the additional library libsfftw.a and additional
-include file sfttw.a. Note that on some platforms FFTW2 has been
-pre-installed for both single- and double-precision, and may already
-have these files as well as libdfftw.a and dfftw.h for double
-precision.
-
-The FFT_INC variable also allows for a -DFFT_SINGLE setting that will
-use single-precision FFTs with PPPM, which can speed-up long-range
-calculations, particularly in parallel or on GPUs. Fourier transform
-and related PPPM operations are somewhat insensitive to floating point
-truncation errors and thus do not always need to be performed in
-double precision. Using the -DFFT_SINGLE setting trades off a little
-accuracy for reduced memory use and parallel communication costs for
-transposing 3d FFT data. Note that single precision FFTs have only
-been tested with the FFTW3, FFTW2, MKL, and KISS FFT options.
-
-When using -DFFT_SINGLE with FFTW3 or FFTW2, you need to build FFTW
-with support for single-precision, as explained above. For FFTW3 you
-also need to include -lfftw3f with the FFT_LIB setting, in addition to
--lfftw3. For FFTW2, you also need to specify -DFFT_SIZE with the
-FFT_INC setting and -lsfftw with the FFT_LIB setting (in place of
--lfftw). Similarly, if FFTW2 has been pre-installed with an explicit
-double-precision library (libdfftw.a and not the default libfftw.a),
-then you can specify -DFFT_SIZE (and not -DFFT_SINGLE), and specify
--ldfftw to use double-precision FFTs.
-
-Step 7 :h5
-
-The 3 JPG variables allow you to specify a JPEG and/or PNG library
-which LAMMPS uses when writing out JPEG or PNG files via the "dump
-image"_dump_image.html command. These can be left blank if you do not
-use the -DLAMMPS_JPEG or -DLAMMPS_PNG switches discussed above in Step
-4, since in that case JPEG/PNG output will be disabled.
-
-A standard JPEG library usually goes by the name libjpeg.a or
-libjpeg.so and has an associated header file jpeglib.h. Whichever
-JPEG library you have on your platform, you'll need to set the
-appropriate JPG_INC, JPG_PATH, and JPG_LIB variables, so that the
-compiler and linker can find it.
-
-A standard PNG library usually goes by the name libpng.a or libpng.so
-and has an associated header file png.h. Whichever PNG library you
-have on your platform, you'll need to set the appropriate JPG_INC,
-JPG_PATH, and JPG_LIB variables, so that the compiler and linker can
-find it.
-
-As before, if these header and library files are in the usual place on
-your machine, you may not need to set these variables.
-
-Step 8 :h5
-
-Note that by default only a few of LAMMPS optional packages are
-installed. To build LAMMPS with optional packages, see "this
-section"_#start_3 below, before proceeding to Step 9.
-
-Step 9 :h5
-
-That's it. Once you have a correct Makefile.foo, and you have
-pre-built any other needed libraries (e.g. MPI, FFT, etc) all you need
-to do from the src directory is type something like this:
-
-make foo
-make -j N foo
-gmake foo
-gmake -j N foo :pre
-
-The -j or -j N switches perform a parallel build which can be much
-faster, depending on how many cores your compilation machine has. N
-is the number of cores the build runs on.
-
-You should get the executable lmp_foo when the build is complete.
-
-:line
-
-Errors that can occur when making LAMMPS :h4 :link(start_2_3)
-
-If an error occurs when building LAMMPS, the compiler or linker will
-state very explicitly what the problem is. The error message should
-give you a hint as to which of the steps above has failed, and what
-you need to do in order to fix it. Building a code with a Makefile is
-a very logical process. The compiler and linker need to find the
-appropriate files and those files need to be compatible with LAMMPS
-settings and source files. When a make fails, there is usually a very
-simple reason, which you or a local expert will need to fix.
-
-Here are two non-obvious errors that can occur:
-
-(1) If the make command breaks immediately with errors that indicate
-it can't find files with a "*" in their names, this can be because
-your machine's native make doesn't support wildcard expansion in a
-makefile. Try gmake instead of make. If that doesn't work, try using
-a -f switch with your make command to use a pre-generated
-Makefile.list which explicitly lists all the needed files, e.g.
-
-make makelist
-make -f Makefile.list linux
-gmake -f Makefile.list mac :pre
-
-The first "make" command will create a current Makefile.list with all
-the file names in your src dir. The 2nd "make" command (make or
-gmake) will use it to build LAMMPS. Note that you should
-include/exclude any desired optional packages before using the "make
-makelist" command.
-
-(2) If you get an error that says something like 'identifier "atoll"
-is undefined', then your machine does not support "long long"
-integers. Try using the -DLAMMPS_LONGLONG_TO_LONG setting described
-above in Step 4.
-
-:line
-
-Additional build tips :h4,link(start_2_4)
-
-Building LAMMPS for multiple platforms. :h5
-
-You can make LAMMPS for multiple platforms from the same src
-directory. Each target creates its own object sub-directory called
-Obj_target where it stores the system-specific *.o files.
-
-Cleaning up. :h5
-
-Typing "make clean-all" or "make clean-machine" will delete *.o object
-files created when LAMMPS is built, for either all builds or for a
-particular machine.
-
-Changing the LAMMPS size limits via -DLAMMPS_SMALLBIG or -DLAMMPS_BIGBIG or -DLAMMPS_SMALLSMALL :h5
-
-As explained above, any of these 3 settings can be specified on the
-LMP_INC line in your low-level src/MAKE/Makefile.foo.
-
-The default is -DLAMMPS_SMALLBIG which allows for systems with up to
-2^63 atoms and 2^63 timesteps (about 9e18). The atom limit is for
-atomic systems which do not store bond topology info and thus do not
-require atom IDs. If you use atom IDs for atomic systems (which is
-the default) or if you use a molecular model, which stores bond
-topology info and thus requires atom IDs, the limit is 2^31 atoms
-(about 2 billion). This is because the IDs are stored in 32-bit
-integers.
-
-Likewise, with this setting, the 3 image flags for each atom (see the
-"dump"_dump.html doc page for a discussion) are stored in a 32-bit
-integer, which means the atoms can only wrap around a periodic box (in
-each dimension) at most 512 times. If atoms move through the periodic
-box more than this many times, the image flags 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.
-
-To allow for larger atomic systems with atom IDs or larger molecular
-systems or larger image flags, compile with -DLAMMPS_BIGBIG. This
-stores atom IDs and image flags in 64-bit integers. This enables
-atomic or molecular systems with atom IDS of up to 2^63 atoms (about
-9e18). And image flags will not "roll over" until they reach 2^20 =
-1048576.
-
-If your system does not support 8-byte integers, you will need to
-compile with the -DLAMMPS_SMALLSMALL setting. This will restrict the
-total number of atoms (for atomic or molecular systems) and timesteps
-to 2^31 (about 2 billion). Image flags will roll over at 2^9 = 512.
-
-Note that in src/lmptype.h there are definitions of all these data
-types as well as the MPI data types associated with them. The MPI
-types need to be consistent with the associated C data types, or else
-LAMMPS will generate a run-time error. As far as we know, the
-settings defined in src/lmptype.h are portable and work on every
-current system.
-
-In all cases, the size of problem that can be run on a per-processor
-basis is limited by 4-byte integer storage to 2^31 atoms per processor
-(about 2 billion). This should not normally be a limitation since such
-a problem would have a huge per-processor memory footprint due to
-neighbor lists and would run very slowly in terms of CPU secs/timestep.
-
-:line
-
-Building for a Mac :h4,link(start_2_5)
-
-OS X is a derivative of BSD Unix, so it should just work. See the
-src/MAKE/MACHINES/Makefile.mac and Makefile.mac_mpi files.
-
-:line
-
-Building for Windows :h4,link(start_2_6)
-
-If you want to build a Windows version of LAMMPS, you can build it
-yourself, but it may require some effort. LAMMPS expects a Unix-like
-build environment for the default build procedure. This can be done
-using either Cygwin or MinGW; the latter also exists as a ready-to-use
-Linux-to-Windows cross-compiler in several Linux distributions. In
-these cases, you can do the installation after installing several
-unix-style commands like make, grep, sed and bash with some shell
-utilities.
-
-For Cygwin and the MinGW cross-compilers, suitable makefiles are
-provided in src/MAKE/MACHINES. When using other compilers, like
-Visual C++ or Intel compilers for Windows, you may have to implement
-your own build system. Due to differences between the Windows OS
-and Windows system libraries to Unix-like environments like Linux
-or MacOS, when compiling for Windows a few adjustments may be needed:
-
-Do [not] set the -DLAMMPS_MEMALIGN define (see LMP_INC makefile variable)
-Add -lwsock32 -lpsapi to the linker flags (see LIB makefile variable)
-Try adding -static-libgcc or -static or both to the linker flags when your LAMMPS executable complains about missing .dll files :ul
-
-Since none of the current LAMMPS core developers has significant
-experience building executables on Windows, we are happy to distribute
-contributed instructions and modifications to improve the situation,
-but we cannot provide support for those.
-
-With the so-called "Anniversary Update" to Windows 10, there is a
-Ubuntu Linux subsystem available for Windows, that can be installed
-and then used to compile/install LAMMPS as if you are running on a
-Ubuntu Linux system instead of Windows.
-
-As an alternative, you can download pre-compiled installer packages from
-"packages.lammps.org/windows.html"_http://packages.lammps.org/windows.html.
-These executables are built with most optional packages included and the
-download includes documentation, potential files, some tools and many
-examples, but no source code.
-
-:line
-
-2.3 Making LAMMPS with optional packages :h3,link(start_3)
-
-This section has the following sub-sections:
-
-2.3.1 "Package basics"_#start_3_1
-2.3.2 "Including/excluding packages"_#start_3_2
-2.3.3 "Packages that require extra libraries"_#start_3_3 :all(b)
-
-:line
-
-Package basics: :h4,link(start_3_1)
-
-The source code for LAMMPS is structured as a set of core files which
-are always included, plus optional packages. Packages are groups of
-files that enable a specific set of features. For example, force
-fields for molecular systems or granular systems are in packages.
-
-"Section 4"_Section_packages.html in the manual has details about all
-the packages, which come in two flavors: [standard] and [user]
-packages. It also has specific instructions for building LAMMPS with
-any package which requires an extra library. General instructions are
-below.
-
-You can see the list of all packages by typing "make package" from
-within the src directory of the LAMMPS distribution. It will also
-list various make commands that can be used to manage packages.
-
-If you use a command in a LAMMPS input script that is part of a
-package, you must have built LAMMPS with that package, else you will
-get an error that the style is invalid or the command is unknown.
-Every command's doc page specifies if it is part of a package. You can
-type
-
-lmp_machine -h :pre
-
-to run your executable with the optional "-h command-line
-switch"_#start_6 for "help", which will list the styles and commands
-known to your executable, and immediately exit.
-
-:line
-
-Including/excluding packages :h4,link(start_3_2)
-
-To use (or not use) a package you must install it (or un-install it)
-before building LAMMPS. From the src directory, this is as simple as:
-
-make yes-colloid
-make mpi :pre
-
-or
-
-make no-user-omp
-make mpi :pre
-
-NOTE: You should NOT install/un-install packages and build LAMMPS in a
-single make command using 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.
-
-Any package can be installed or not 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. I.e. 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.
-
-NOTE: The one exception is that we do not recommend building with both
-the KOKKOS package installed and any of the other acceleration
-packages (GPU, OPT, USER-INTEL, USER-OMP) also installed. This is
-because of how Kokkos sometimes builds using a wrapper compiler which
-can make it difficult to invoke all the compile/link flags correctly
-for both Kokkos and non-Kokkos files.
-
-If you will never run simulations that use the features in a
-particular packages, there is no reason to include it in your build.
-For some packages, this will keep you from having to build extra
-libraries, and will also produce a smaller executable which may run a
-bit faster.
-
-When you download a LAMMPS tarball, three packages are pre-installed
-in the src directory -- KSPACE, MANYBODY, MOLECULE -- because they are
-so commonly used. When you download LAMMPS source files from the SVN
-or Git repositories, no packages are pre-installed.
-
-Packages are installed or un-installed by typing
-
-make yes-name
-make no-name :pre
-
-where "name" is the name of the package in lower-case, e.g. name =
-kspace for the KSPACE package or name = user-atc for the USER-ATC
-package. You can also type any of these commands:
-
-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=|)
-
-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 moving
-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.
-After you have installed or un-installed a package, you must re-build
-LAMMPS for the action to take effect.
-
-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 have
-downloaded a patch from the LAMMPS web site.
-
-Typing "make package-status" or "make ps" will 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.
-
-Typing "make package-installed" or "make pi" will list which packages are
-currently installed, without listing the status of packages that are not
-installed.
-
-Typing "make package-update" or "make pu" will 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, since
-patches only update the files in the package sub-directory, but not
-the src files.
-
-Typing "make package-overwrite" will overwrite files in the package
-sub-directories with src files.
-
-Typing "make package-diff" lists all differences between these files.
-
-Again, just type "make package" to see all of the package-related make
-options.
-
-:line
-
-Packages that require extra libraries :h4,link(start_3_3)
-
-A few of the standard and user packages require extra libraries. See
-"Section 4"_Section_packages.html for two tables of packages which
-indicate which ones require libraries. For each such package, the
-Section 4 doc page gives details on how to build the extra library,
-including how to download it if necessary. The basic ideas are
-summarized here.
-
-[System libraries:]
-
-Packages in the tables "Section 4"_Section_packages.html with a "sys"
-in the last column link to system libraries that typically already
-exist on your machine. E.g. the python package links to a system
-Python library. If your machine does not have the required library,
-you will have to download and install it on your machine, in either
-the system or user space.
-
-[Internal libraries:]
-
-Packages in the tables "Section 4"_Section_packages.html with an "int"
-in the last column link to internal libraries whose source code is
-included with LAMMPS, in the lib/name directory where name is the
-package name. You must first build the library in that directory
-before building LAMMPS with that package installed. E.g. the gpu
-package links to a library you build in the lib/gpu dir. You can
-often do the build in one step by typing "make lib-name args=..."
-from the src dir, with appropriate arguments. You can leave off the
-args to see a help message. See "Section 4"_Section_packages.html for
-details for each package.
-
-[External libraries:]
-
-Packages in the tables "Section 4"_Section_packages.html with an "ext"
-in the last column link to external libraries whose source code is not
-included with LAMMPS. You must first download and install the library
-before building LAMMPS with that package installed. E.g. the voronoi
-package links to the freely available "Voro++ library"_voro_home2. You
-can often do the download/build in one step by typing "make lib-name
-args=..." from the src dir, with appropriate arguments. You can leave
-off the args to see a help message. See "Section
-4"_Section_packages.html for details for each package.
-
-:link(voro_home2,http://math.lbl.gov/voro++)
-
-[Possible errors:]
-
-There are various common errors which can occur when building extra
-libraries or when building LAMMPS with packages that require the extra
-libraries.
-
-If you cannot build the extra library itself successfully, you may
-need to edit or create an appropriate Makefile for your machine, e.g.
-with appropriate compiler or system settings. Provided makefiles are
-typically in the lib/name directory. E.g. see the Makefile.* files in
-lib/gpu.
-
-The LAMMPS build often uses settings in a lib/name/Makefile.lammps
-file which either exists in the LAMMPS distribution or is created or
-copied from a lib/name/Makefile.lammps.* file when the library is
-built. If those settings are not correct for your machine you will
-need to edit or create an appropriate Makefile.lammps file.
-
-Package-specific details for these steps are given in "Section
-4"_Section_packages.html an in README files in the lib/name
-directories.
-
-[Compiler options needed for accelerator packages:]
-
-Several packages contain code that is optimized for specific hardware,
-e.g. CPU, KNL, or GPU. These are the OPT, GPU, KOKKOS, USER-INTEL,
-and USER-OMP packages. Compiling and linking the source files in
-these accelerator packages for optimal performance requires specific
-settings in the Makefile.machine file you use.
-
-A summary of the Makefile.machine settings needed for each of these
-packages is given in "Section 4"_Section_packages.html. More info is
-given on the doc pages that describe each package in detail:
-
-5.3.1 "USER-INTEL package"_accelerate_intel.html
-5.3.2 "GPU package"_accelerate_intel.html
-5.3.3 "KOKKOS package"_accelerate_kokkos.html
-5.3.4 "USER-OMP package"_accelerate_omp.html
-5.3.5 "OPT package"_accelerate_opt.html :all(b)
-
-You can also use or examine the following machine Makefiles in
-src/MAKE/OPTIONS, which include the settings. Note that the
-USER-INTEL and KOKKOS packages can use settings that build LAMMPS for
-different hardware. The USER-INTEL package can be compiled for Intel
-CPUs and KNLs; the KOKKOS package builds for CPUs (OpenMP), GPUs
-(CUDA), and Intel KNLs.
-
-Makefile.intel_cpu
-Makefile.intel_phi
-Makefile.kokkos_omp
-Makefile.kokkos_cuda_mpi
-Makefile.kokkos_phi
-Makefile.omp
-Makefile.opt :ul
-
-:line
-
-2.4 Building LAMMPS as a library :h3,link(start_4)
-
-LAMMPS can be built as either a static or shared library, which can
-then be called from another application or a scripting language. See
-"this section"_Section_howto.html#howto_10 for more info on coupling
-LAMMPS to other codes. See "this section"_Section_python.html for
-more info on wrapping and running LAMMPS from Python.
-
-Static library :h4
-
-To build LAMMPS as a static library (*.a file on Linux), type
-
-make foo mode=lib :pre
-
-where foo is the machine name. This kind of library is typically used
-to statically link a driver application to LAMMPS, so that you can
-insure all dependencies are satisfied at compile time. This will use
-the ARCHIVE and ARFLAGS settings in src/MAKE/Makefile.foo. The build
-will create the file liblammps_foo.a which another application can
-link to. It will also create a soft link liblammps.a, which will
-point to the most recently built static library.
-
-Shared library :h4
-
-To build LAMMPS as a shared library (*.so file on Linux), which can be
-dynamically loaded, e.g. from Python, type
-
-make foo mode=shlib :pre
-
-where foo is the machine name. This kind of library is required when
-wrapping LAMMPS with Python; see "Section 11"_Section_python.html
-for details. This will use the SHFLAGS and SHLIBFLAGS settings in
-src/MAKE/Makefile.foo and perform the build in the directory
-Obj_shared_foo. This is so that each file can be compiled with the
--fPIC flag which is required for inclusion in a shared library. The
-build will create the file liblammps_foo.so which another application
-can link to dynamically. It will also create a soft link liblammps.so,
-which will point to the most recently built shared library. This is
-the file the Python wrapper loads by default.
-
-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
-lib/packages, 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.
-
-Here is an example of such errors when the system FFTW or provided
-lib/colvars library have not been built as shared libraries:
-
-/usr/bin/ld: /usr/local/lib/libfftw3.a(mapflags.o): relocation
-R_X86_64_32 against '.rodata' can not be used when making a shared
-object; recompile with -fPIC
-/usr/local/lib/libfftw3.a: could not read symbols: Bad value :pre
-
-/usr/bin/ld: ../../lib/colvars/libcolvars.a(colvarmodule.o):
-relocation R_X86_64_32 against '__pthread_key_create' can not be used
-when making a shared object; recompile with -fPIC
-../../lib/colvars/libcolvars.a: error adding symbols: Bad value :pre
-
-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 Labs, 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.
-
-[Additional requirement for using a shared library:] :h4
-
-The operating system finds shared libraries to load at run-time using
-the environment variable LD_LIBRARY_PATH. So you may wish to copy the
-file src/liblammps.so or src/liblammps_g++.so (for example) to a place
-the system can find it by default, such as /usr/local/lib, or you may
-wish to add the LAMMPS src directory to 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
-
-Calling the LAMMPS library :h4
-
-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 or a scripting language like
-Python, the library has a simple function-style interface, provided in
-src/library.cpp and src/library.h.
-
-See the sample codes in examples/COUPLE/simple for examples of C++ and
-C and Fortran codes that invoke LAMMPS thru its library interface.
-There are other examples as well in the COUPLE directory which are
-discussed in "Section 6.10"_Section_howto.html#howto_10 of the
-manual. See "Section 11"_Section_python.html of the manual for a
-description of the Python wrapper provided with LAMMPS that operates
-through the LAMMPS library interface.
-
-The files src/library.cpp and library.h define the C-style API for
-using LAMMPS as a library. See "Section
-6.19"_Section_howto.html#howto_19 of the manual for a description of the
-interface and how to extend it for your needs.
-
-:line
-
-2.5 Running LAMMPS :h3,link(start_5)
-
-By default, LAMMPS runs by reading commands from standard input. Thus
-if you run the LAMMPS executable by itself, e.g.
-
-lmp_linux :pre
-
-it will simply wait, expecting commands from the keyboard. Typically
-you should put commands in an input script and use I/O redirection,
-e.g.
-
-lmp_linux < in.file :pre
-
-For parallel environments this should also work. If it does not, use
-the '-in' command-line switch, e.g.
-
-lmp_linux -in in.file :pre
-
-"This section"_Section_commands.html describes how input scripts are
-structured and what commands they contain.
-
-You can test LAMMPS on any of the sample inputs provided in the
-examples or bench directory. Input scripts are named in.* and sample
-outputs are named log.*.name.P where name is a machine and P is the
-number of processors it was run on.
-
-Here is how you might run a standard Lennard-Jones benchmark on a
-Linux box, using mpirun to launch a parallel job:
-
-cd src
-make linux
-cp lmp_linux ../bench
-cd ../bench
-mpirun -np 4 lmp_linux -in in.lj :pre
-
-See "this page"_bench for timings for this and the other benchmarks on
-various platforms. Note that some of the example scripts require
-LAMMPS to be built with one or more of its optional packages.
-
-:link(bench,http://lammps.sandia.gov/bench.html)
-
-:line
-
-On a Windows box, you can skip making LAMMPS and simply download an
-installer package from "here"_http://packages.lammps.org/windows.html
-
-For running the 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, e.g. a copy of
-the [in.lj] input from the bench folder. (e.g. by typing: cd "Documents"). :l
-
-At the command prompt, type "lmp_serial -in in.lj", replacing [in.lj]
-with the name of your LAMMPS input script. :l
-
-The serial executable includes support for multi-threading
-parallelization from the styles in the USER-OMP packages.
-
-To run with, e.g. 4 threads, type "lmp_serial -in in.lj -pk omp 4 -sf omp"
-:ule
-
-For the MPI version, which allows you to run LAMMPS under Windows with
-the more general message passing parallel library (LAMMPS has been
-designed from ground up to use MPI efficiently), 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
-and for 64-bit Windows
-"mpich2-1.4.1p1-win-x86-64.msi"_download.lammps.org/thirdparty/mpich2-1.4.1p1-win-x86-64.msi
-:ulb,l
-
-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". :l
-
-Move to the directory where you have your input file
-(e.g. by typing: cd "Documents"). :l
-
-Then type something like this:
-
-mpiexec -localonly 4 lmp_mpi -in in.lj :pre
-or
-
-mpiexec -np 4 lmp_mpi -in in.lj :pre
-
-replacing [in.lj] with the name of your LAMMPS input script. For the latter
-case, you may be prompted to enter your password. :l
-
-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. :l
-
-The parallel executable can also run on a single processor by typing
-something like:
-
-lmp_mpi -in in.lj :pre
-
-And 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
-
-:ule
-
-:line
-
-The screen output from LAMMPS is described in a section below. As it
-runs, LAMMPS also writes a log.lammps file with the same information.
-
-Note that this sequence of commands copies the LAMMPS executable
-(lmp_linux) to the directory with the input files. This may not be
-necessary, but some versions of MPI reset the working directory to
-where the executable is, rather than leave it as the directory where
-you launch mpirun from (if you launch lmp_linux on its own and not
-under mpirun). If that happens, LAMMPS will look for additional input
-files and write its output files to the executable directory, rather
-than your working directory, which is probably not what you want.
-
-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 "Section 12"_Section_errors.html 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.
-
-LAMMPS can run a 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.
-
-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 setup a smaller problem.
-
-:line
-
-2.6 Command-line options :h3,link(start_6)
-
-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
--h or -help
--i or -in
--k or -kokkos
--l or -log
--nc or -nocite
--pk or -package
--p or -partition
--pl or -plog
--ps or -pscreen
--r or -restart
--ro or -reorder
--sc or -screen
--sf or -suffix
--v or -var :ul
-
-For example, lmp_ibm might be launched as follows:
-
-mpirun -np 16 lmp_ibm -v f tmp.out -l my.log -sc none -in in.alloy
-mpirun -np 16 lmp_ibm -var f tmp.out -log my.log -screen none -in in.alloy :pre
-
-Here are the details on the options:
-
--echo style :pre
-
-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.
-
--help :pre
-
-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.
-
--in file :pre
-
-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.
-
--kokkos on/off keyword/value ... :pre
-
-Explicitly enable or disable KOKKOS support, as provided by the KOKKOS
-package. Even if LAMMPS is built with this package, as described
-above in "Section 2.3"_#start_3, 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. Example of when to use these options and what
-settings to use on different platforms is given in "Section
-5.3"_Section_accelerate.html#acc_3.
-
-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.
-
--log file :pre
-
-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.
-
--nocite :pre
-
-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.
-
--package style args .... :pre
-
-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.
-
--partition 8x2 4 5 ... :pre
-
-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 e useful for running
-"multi-replica simulations"_Section_howto.html#howto_5, 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 "Section 6.4"_Section_howto.html#howto_4
-of the manual. World- and universe-style "variables"_variable.html
-are useful in this context.
-
--plog file :pre
-
-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.
-
--pscreen file :pre
-
-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.
-
--restart restartfile {remap} datafile keyword value ... :pre
-
-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.
-
--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 "Section 5"_Section_accelerate.html doc pages 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.
-
--screen file :pre
-
-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.
-
--suffix style args :pre
-
-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
-above in "Section 2.3"_#start_3. 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.
-
--var name value1 value2 ... :pre
-
-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 "this
-section"_Section_commands.html#cmd_2 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 they start with a "-", e.g. a
-negative numeric value. It is OK if the first value1 starts with a
-"-", since it is automatically skipped.
-
-:line
-
-2.7 LAMMPS screen output :h3,link(start_7)
-
-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 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 then
-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
-
-The first section provides a global loop timing summary. The {loop time}
-is the total wall time for the section. The {Performance} line is
-provided for convenience to help predicting the number of loop
-continuations required and for comparing performance with other,
-similar MD codes. 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 no OpenMP). Lower numbers correspond to delays due
-to file I/O or insufficient thread utilization.
-
-The MPI task section gives the breakdown of the CPU run time (in
-seconds) into major categories:
-
-{Pair} stands for all non-bonded force computation
-{Bond} stands for bonded interactions: bonds, angles, dihedrals, impropers
-{Kspace} stands for reciprocal space interactions: Ewald, PPPM, MSM
-{Neigh} stands for neighbor list construction
-{Comm} stands for communicating atoms and their properties
-{Output} stands for writing dumps and thermo output
-{Modify} stands for fixes and computes called by them
-{Other} is the remaining time :ul
-
-For each category, there is a breakdown of the least, average and most
-amount of wall time a processor spent on this section. Also you have the
-variation from the average time. Together these numbers allow to gauge
-the amount of load imbalance in this segment of the calculation. Ideally
-the difference between minimum, maximum and average is small and thus
-the variation from the average close to zero. The final column shows
-the percentage of the total loop time is spent in this section.
-
-When using the "timer full"_timer.html setting, an additional column
-is present 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 entry is the {Reduce} section, which lists the time spent in
-reducing the per-thread data elements to the storage for non-threaded
-computation. These thread timings are taking from the first MPI rank
-only and and thus, as 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
-
-The third section 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.
-
-The last section gives aggregate statistics 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 during the run is given as well as 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.
-
-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 the minimization
-to be completed. The third 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 force vector; the inf-norm is the
-largest component. Then some information 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.
-
-If a "kspace_style"_kspace_style.html long-range Coulombics solve was
-performed 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 gives the time spent doing 3d FFTs (4 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.
-
-:line
-
-2.8 Tips for users of previous LAMMPS versions :h3,link(start_8)
-
-The current C++ began with a complete rewrite of LAMMPS 2001, which
-was written in F90. Features of earlier versions of LAMMPS are listed
-in "Section 13"_Section_history.html. The F90 and F77 versions
-(2001 and 99) are also freely distributed as open-source codes; check
-the "LAMMPS WWW Site"_lws for distribution information if you prefer
-those versions. The 99 and 2001 versions are no longer under active
-development; they do not have all the features of C++ LAMMPS.
-
-If you are a previous user of LAMMPS 2001, these are the most
-significant changes you will notice in C++ LAMMPS:
-
-(1) The names and arguments of many input script commands have
-changed. All commands are now a single word (e.g. read_data instead
-of read data).
-
-(2) All the functionality of LAMMPS 2001 is included in C++ LAMMPS,
-but you may need to specify the relevant commands in different ways.
-
-(3) The format of the data file can be streamlined for some problems.
-See the "read_data"_read_data.html command for details. The data file
-section "Nonbond Coeff" has been renamed to "Pair Coeff" in C++ LAMMPS.
-
-(4) Binary restart files written by LAMMPS 2001 cannot be read by C++
-LAMMPS with a "read_restart"_read_restart.html command. This is
-because they were output by F90 which writes in a different binary
-format than C or C++ writes or reads. Use the {restart2data} tool
-provided with LAMMPS 2001 to convert the 2001 restart file to a text
-data file. Then edit the data file as necessary before using the C++
-LAMMPS "read_data"_read_data.html command to read it in.
-
-(5) There are numerous small numerical changes in C++ LAMMPS that mean
-you will not get identical answers when comparing to a 2001 run.
-However, your initial thermodynamic energy and MD trajectory should be
-close if you have setup the problem for both codes the same.
diff --git a/doc/src/Speed.txt b/doc/src/Speed.txt
new file mode 100644
index 0000000000000000000000000000000000000000..dd2052bac184863ccbf15290b13fbd7589f0653e
--- /dev/null
+++ b/doc/src/Speed.txt
@@ -0,0 +1,57 @@
+"Previous Section"_Package.html - "LAMMPS WWW Site"_lws -
+"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
+Section"_Howto.html :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Accelerate performance :h2
+
+This section describes various methods for improving LAMMPS
+performance for different classes of problems running on different
+kinds of machines.
+
+There are two thrusts to the discussion that follows. The first is
+using code options that implement alternate algorithms that can
+speed-up a simulation. The second is to use one of the several
+accelerator packages provided with LAMMPS that contain code optimized
+for certain kinds of hardware, including multi-core CPUs, GPUs, and
+Intel Xeon Phi coprocessors.
+
+The "Benchmark page"_http://lammps.sandia.gov/bench.html of the LAMMPS
+web site gives performance results for the various accelerator
+packages discussed on the "Speed packages"_Speed_packages.html doc
+page, for several of the standard LAMMPS benchmark problems, as a
+function of problem size and number of compute nodes, on different
+hardware platforms.
+
+<!-- RST
+
+.. toctree::
+ :maxdepth: 1
+
+ Speed_bench
+ Speed_measure
+ Speed_tips
+ Speed_packages
+ Speed_compare
+
+END_RST -->
+
+<!-- HTML_ONLY -->
+
+"Benchmarks"_Speed_bench.html
+"Measuring performance"_Speed_measure.html
+"General tips"_Speed_tips.html
+"Accelerator packages"_Speed_packages.html
+"GPU package"_Speed_gpu.html
+"USER-INTEL package"_Speed_intel.html
+"KOKKOS package"_Speed_kokkos.html
+"USER-OMP package"_Speed_omp.html
+"OPT package"_Speed_opt.html
+"Comparison of accelerator packages"_Speed_compare.html :all(b)
+
+<!-- END_HTML_ONLY -->
diff --git a/doc/src/Section_perf.txt b/doc/src/Speed_bench.txt
similarity index 85%
rename from doc/src/Section_perf.txt
rename to doc/src/Speed_bench.txt
index 9998cb0d9a1371fdcca7c6e927c49925bb6f81d2..8e407d14ea6bdb7428bff3818a670a9a84244f63 100644
--- a/doc/src/Section_perf.txt
+++ b/doc/src/Speed_bench.txt
@@ -1,17 +1,18 @@
-"Previous Section"_Section_example.html - "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Section_tools.html :c
+"Higher level section"_Speed.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
-8. Performance & scalability :h2
+Benchmarks :h3
-Current LAMMPS performance is discussed on the Benchmarks page of the
-"LAMMPS WWW Site"_lws where CPU timings and parallel efficiencies are
-listed. The page has several sections, which are briefly described
-below:
+Current LAMMPS performance is discussed on the "Benchmarks
+page"_http://lammps.sandia.gov/bench.html of the "LAMMPS website"_lws
+where timings and parallel efficiencies are listed. The page has
+several sections, which are briefly described below:
CPU performance on 5 standard problems, strong and weak scaling
GPU and Xeon Phi performance on same and related problems
@@ -51,8 +52,8 @@ of these 5 problems on 1 or 4 cores of Linux desktop. The bench/FERMI
and bench/KEPLER dirs have input files and scripts and instructions
for running the same (or similar) problems using OpenMP or GPU or Xeon
Phi acceleration options. See the README files in those dirs and the
-"Section 5.3"_Section_accelerate.html#acc_3 doc pages for
-instructions on how to build LAMMPS and run on that kind of hardware.
+"Speed packages"_Speed_packages.html doc pages for instructions on how
+to build LAMMPS and run on that kind of hardware.
The bench/POTENTIALS directory has input files which correspond to the
table of results on the
diff --git a/doc/src/Speed_compare.txt b/doc/src/Speed_compare.txt
new file mode 100644
index 0000000000000000000000000000000000000000..c93407515e5cebe6b8e278c62ea36b731c2b121b
--- /dev/null
+++ b/doc/src/Speed_compare.txt
@@ -0,0 +1,116 @@
+"Higher level section"_Speed.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
+
+Comparison of various accelerator packages :h3
+
+The next section compares and contrasts the various accelerator
+options, since there are multiple ways to perform OpenMP threading,
+run on GPUs, optimize for vector units on CPUs and run on Intel
+Xeon Phi (co-)processors.
+
+All of these packages can accelerate a LAMMPS calculation taking
+advantage of hardware features, but they do it in different ways
+and acceleration is not always guaranteed.
+
+As a consequence, for a particular simulation on specific hardware,
+one package may be faster than the other. We give some guidelines
+below, but the best way to determine which package is faster for your
+input script is to try multiple of them on your machine and experiment
+with available performance tuning settings. See the benchmarking
+section below for examples where this has been done.
+
+[Guidelines for using each package optimally:]
+
+Both, the GPU and the KOKKOS package allows you to assign multiple
+MPI ranks (= CPU cores) to the same GPU. For the GPU package, this
+can lead to a speedup through better utilization of the GPU (by
+overlapping computation and data transfer) and more efficient
+computation of the non-GPU accelerated parts of LAMMPS through MPI
+parallelization, as all system data is maintained and updated on
+the host. For KOKKOS, there is less to no benefit from this, due
+to its different memory management model, which tries to retain
+data on the GPU.
+ :ulb,l
+
+The GPU package moves per-atom data (coordinates, forces, and
+(optionally) neighbor list data, if not computed on the GPU) between
+the CPU and GPU at every timestep. The KOKKOS/CUDA package only does
+this on timesteps when a CPU calculation is required (e.g. to invoke
+a fix or compute that is non-GPU-ized). Hence, if you can formulate
+your input script to only use GPU-ized fixes and computes, and avoid
+doing I/O too often (thermo output, dump file snapshots, restart files),
+then the data transfer cost of the KOKKOS/CUDA package can be very low,
+causing it to run faster than the GPU package. :l
+
+The GPU package is often faster than the KOKKOS/CUDA package, when the
+number of atoms per GPU is on the smaller side. The crossover point,
+in terms of atoms/GPU at which the KOKKOS/CUDA package becomes faster
+depends strongly on the pair style. For example, for a simple Lennard Jones
+system the crossover (in single precision) is often about 50K-100K
+atoms per GPU. When performing double precision calculations the
+crossover point can be significantly smaller. :l
+
+Both KOKKOS and GPU package compute bonded interactions (bonds, angles,
+etc) on the CPU. If the GPU package is running with several MPI processes
+assigned to one GPU, the cost of computing the bonded interactions is
+spread across more CPUs and hence the GPU package can run faster in these
+cases. :l
+
+When using LAMMPS with multiple MPI ranks assigned to the same GPU, its
+performance depends to some extent on the available bandwidth between
+the CPUs and the GPU. This can differ significantly based on the
+available bus technology, capability of the host CPU and mainboard,
+the wiring of the buses and whether switches are used to increase the
+number of available bus slots, or if GPUs are housed in an external
+enclosure. This can become quite complex. :l
+
+To achieve significant acceleration through GPUs, both KOKKOS and GPU
+package require capable GPUs with fast on-device memory and efficient
+data transfer rates. This requests capable upper mid-level to high-end
+(desktop) GPUs. Using lower performance GPUs (e.g. on laptops) may
+result in a slowdown instead. :l
+
+For the GPU package, specifically when running in parallel with MPI,
+if it often more efficient to exclude the PPPM kspace style from GPU
+acceleration and instead run it - concurrently with a GPU accelerated
+pair style - on the CPU. This can often be easily achieved with placing
+a {suffix off} command before and a {suffix on} command after the
+{kspace_style pppm} command. :l
+
+The KOKKOS/OpenMP and USER-OMP package have different thread management
+strategies, which should result in USER-OMP being more efficient for a
+small number of threads with increasing overhead as the number of threads
+per MPI rank grows. The KOKKOS/OpenMP kernels have less overhead in that
+case, but have lower performance with few threads. :l
+
+The USER-INTEL package contains many options and settings for achieving
+additional performance on Intel hardware (CPU and accelerator cards), but
+to unlock this potential, an Intel compiler is required. The package code
+will compile with GNU gcc, but it will not be as efficient. :l
+:ule
+
+[Differences between the GPU and KOKKOS packages:]
+
+The GPU package accelerates only pair force, neighbor list, and (parts
+of) PPPM calculations. The KOKKOS package attempts to run most of the
+calculation on the GPU, but can transparently support non-accelerated
+code (with a performance penalty due to having data transfers between
+host and GPU). :ulb,l
+
+The GPU package requires neighbor lists to be built on the CPU when using
+exclusion lists, hybrid pair styles, or a triclinic simulation box. :l
+
+The GPU package can be compiled for CUDA or OpenCL and thus supports
+both, Nvidia and AMD GPUs well. On Nvidia hardware, using CUDA is typically
+resulting in equal or better performance over OpenCL. :l
+
+OpenCL in the GPU package does theoretically also support Intel CPUs or
+Intel Xeon Phi, but the native support for those in KOKKOS (or USER-INTEL)
+is superior. :l
+:ule
diff --git a/doc/src/accelerate_gpu.txt b/doc/src/Speed_gpu.txt
similarity index 64%
rename from doc/src/accelerate_gpu.txt
rename to doc/src/Speed_gpu.txt
index 816a31c788e99592a3f70af5e42c786c2ce75410..3ae4639dc2391b492410a450c8f9b3ad56402684 100644
--- a/doc/src/accelerate_gpu.txt
+++ b/doc/src/Speed_gpu.txt
@@ -1,15 +1,13 @@
-"Previous Section"_Section_packages.html - "LAMMPS WWW Site"_lws -
-"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+"Higher level section"_Speed.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
-"Return to Section accelerate overview"_Section_accelerate.html
-
-5.3.1 GPU package :h5
+GPU package :h3
The GPU package was developed by Mike Brown at ORNL and his
collaborators, particularly Trung Nguyen (ORNL). It provides GPU
@@ -45,90 +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
-Go to http://www.nvidia.com/object/cuda_get.html
-Install a driver and 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
+Check if you have an NVIDIA GPU: cat
+/proc/driver/nvidia/gpus/0/information Go to
+http://www.nvidia.com/object/cuda_get.html Install a driver and
+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
-LAMMPS with the GPU package.
-
-You can do both these steps in one line as described in
-"Section 4"_Section_packages.html of the manual.
-
-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.
+See the "Build extras"_Build_extras.html#gpu doc page for
+instructions.
[Run with the GPU package from the command line:]
@@ -146,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,
-which will automatically append "gpu" to styles that support it. Use
-the "-pk gpu Ng" "command-line switch"_Section_start.html#start_6 to
-set Ng = # of GPUs/node to use.
+Use the "-sf gpu" "command-line switch"_Run_options.html, which will
+automatically append "gpu" to styles that support it. Use the "-pk
+gpu Ng" "command-line switch"_Run_options.html to set Ng = # of
+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
@@ -183,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
-number of GPUs/node to use, as well as other options.
+switches"_Run_options.html were used. It specifies the number of
+GPUs/node to use, as well as other options.
[Speed-ups to expect:]
diff --git a/doc/src/accelerate_intel.txt b/doc/src/Speed_intel.txt
similarity index 87%
rename from doc/src/accelerate_intel.txt
rename to doc/src/Speed_intel.txt
index 71f5185b154f9f832d0ab5b92bd3d2e49f25df2f..ef876a7d42108a3ae8aad4f6c2f65670f65e0223 100644
--- a/doc/src/accelerate_intel.txt
+++ b/doc/src/Speed_intel.txt
@@ -1,15 +1,13 @@
-"Previous Section"_Section_packages.html - "LAMMPS WWW Site"_lws -
-"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+"Higher level section"_Speed.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
-"Return to Section accelerate overview"_Section_accelerate.html
-
-5.3.2 USER-INTEL package :h5
+USER-INTEL package :h3
The USER-INTEL package is maintained by Mike Brown at Intel
Corporation. It provides two methods for accelerating simulations,
@@ -188,8 +186,8 @@ can start running so that the CPU pipeline is still being used
efficiently. Although benefits can be seen by launching a MPI task
for every hardware thread, for multinode simulations, we recommend
that OpenMP threads are used for SMT instead, either with the
-USER-INTEL package, "USER-OMP package"_accelerate_omp.html, or
-"KOKKOS package"_accelerate_kokkos.html. In the example above, up
+USER-INTEL package, "USER-OMP package"_Speed_omp.html, or
+"KOKKOS package"_Speed_kokkos.html. In the example above, up
to 36X speedups can be observed by using all 36 physical cores with
LAMMPS. By using all 72 hardware threads, an additional 10-30%
performance gain can be achieved.
@@ -205,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
-might be needed for best performance on Intel server processors
-code-named "Skylake".
-
-The USER-INTEL package must be installed into the source directory:
-
-make yes-user-intel :pre
+See the "Build extras"_Build_extras.html#user-intel doc page for
+instructions. Some additional details are covered here.
-Several example Makefiles for building with the Intel compiler are
-included with LAMMPS in the src/MAKE/OPTIONS/ directory:
+For building with make, 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
@@ -223,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
-Xeon Phi x200 processors making it easier to cross-compile. For
-users with recent installations of Intel Parallel Studio, the
-process can be as simple as:
+it explicitly specifies that vectorization should be for Intel Xeon
+Phi x200 processors making it easier to cross-compile. For users with
+recent installations of Intel Parallel Studio, the process can be 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. This is discussed in "Section
-4"_Section_packages.html of the manual.
-
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
@@ -255,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
@@ -308,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"
-"command-line switch"_Section_start.html#start_6 can be used without
-any requirement for editing the input script. This switch will
-automatically append "intel" to styles that support it. It also
-invokes a default command: "package intel 1"_package.html. This
-package command is used to set options for the USER-INTEL package.
-The default package command will specify that USER-INTEL calculations
-are performed in mixed precision, that the number of OpenMP threads
-is specified by the OMP_NUM_THREADS environment variable, and that
-if coprocessors are present and the binary was built with offload
-support, that 1 coprocessor per node will be used with automatic
-balancing of work between the CPU and the coprocessor.
+the input script, the "-sf intel" "command-line
+switch"_Run_options.html can be used without any requirement for
+editing the input script. This switch will automatically append
+"intel" to styles that support it. It also invokes a default command:
+"package intel 1"_package.html. This package command is used to set
+options for the USER-INTEL package. The default package command will
+specify that USER-INTEL calculations are performed in mixed precision,
+that the number of OpenMP threads is specified by the OMP_NUM_THREADS
+environment variable, and that if coprocessors are present and the
+binary was built with offload support, that 1 coprocessor per node
+will be used with automatic balancing of work between the CPU and the
+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
-with keyword/value pairs as specified in the documentation. Here,
-Nphi = # of Xeon Phi coprocessors/node (ignored without offload
+the "-pk intel Nphi" "command-line switch"_Run_options.html with
+keyword/value pairs as specified in the documentation. Here, Nphi = #
+of Xeon Phi coprocessors/node (ignored without offload
support). Common options to the USER-INTEL package include {omp} to
override any OMP_NUM_THREADS setting and specify the number of OpenMP
-threads, {mode} to set the floating-point precision mode, and
-{lrt} to enable Long-Range Thread mode as described below. See the
-"package intel"_package.html command for details, including the
-default values used for all its options if not specified, and how to
-set the number of OpenMP threads via the OMP_NUM_THREADS environment
-variable if desired.
+threads, {mode} to set the floating-point precision mode, and {lrt} to
+enable Long-Range Thread mode as described below. See the "package
+intel"_package.html command for details, including the default values
+used for all its options if not specified, and how to set the number
+of OpenMP threads via the OMP_NUM_THREADS environment variable if
+desired.
Examples (see documentation for your MPI/Machine for differences in
launching MPI applications):
@@ -391,20 +385,19 @@ performance and/or scalability for simple 2-body potentials such as
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"_accelerate_opt.html
-package or the "USER-OMP package"_accelerate_omp.html. Of course,
-this requires that these packages were installed at build time. This
-can performed automatically by using "-sf hybrid intel opt" or
-"-sf hybrid intel omp" command-line options. Alternatively, the "opt"
-and "omp" suffixes can be appended manually in the input script. For
-the latter, the "package omp"_package.html command must be in the
-input script or the "-pk omp Nt" "command-line
-switch"_Section_start.html#start_6 must be used where Nt is the
-number of OpenMP threads. The number of OpenMP threads should not be
-set differently for the different packages. Note that the "suffix
-hybrid intel omp"_suffix.html command can also be used within the
-input script to automatically append the "omp" suffix to styles when
-USER-INTEL styles are not available.
+the USER-INTEL package with styles from the "OPT"_Speed_opt.html
+package or the "USER-OMP package"_Speed_omp.html. Of course, this
+requires that these packages were installed at build time. This can
+performed automatically by using "-sf hybrid intel opt" or "-sf hybrid
+intel omp" command-line options. Alternatively, the "opt" and "omp"
+suffixes can be appended manually in the input script. For the latter,
+the "package omp"_package.html command must be in the input script or
+the "-pk omp Nt" "command-line switch"_Run_options.html must be used
+where Nt is the number of OpenMP threads. The number of OpenMP threads
+should not be set differently for the different packages. Note that
+the "suffix hybrid intel omp"_suffix.html command can also be used
+within the input script to automatically append the "omp" suffix to
+styles when 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
@@ -498,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
-threads per MPI task.
+switch"_Run_options.html is used to limit the coprocessor threads per
+MPI task.
[Restrictions:]
diff --git a/doc/src/Speed_kokkos.txt b/doc/src/Speed_kokkos.txt
new file mode 100644
index 0000000000000000000000000000000000000000..eb787df5d6ac8a1e97136453a8eda62f754bdc0b
--- /dev/null
+++ b/doc/src/Speed_kokkos.txt
@@ -0,0 +1,381 @@
+"Higher level section"_Speed.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
+
+KOKKOS package :h3
+
+Kokkos is a templated C++ library that provides abstractions to allow
+a single implementation of an application kernel (e.g. a pair style)
+to run efficiently on different kinds of hardware, such as GPUs, Intel
+Xeon Phis, or many-core CPUs. Kokkos maps the C++ kernel onto
+different backend languages such as CUDA, OpenMP, or Pthreads. The
+Kokkos library also provides data abstractions to adjust (at compile
+time) the memory layout of data structures like 2d and 3d arrays to
+optimize performance on different hardware. For more information on
+Kokkos, see "Github"_https://github.com/kokkos/kokkos. Kokkos is part
+of "Trilinos"_http://trilinos.sandia.gov/packages/kokkos. The Kokkos
+library was written primarily by Carter Edwards, Christian Trott, and
+Dan Sunderland (all Sandia).
+
+The LAMMPS KOKKOS package contains versions of pair, fix, and atom
+styles that use data structures and macros provided by the Kokkos
+library, which is included with LAMMPS in /lib/kokkos. The KOKKOS
+package was developed primarily by Christian Trott (Sandia) and Stan
+Moore (Sandia) with contributions of various styles by others,
+including Sikandar Mashayak (UIUC), Ray Shan (Sandia), and Dan Ibanez
+(Sandia). For more information on developing using Kokkos abstractions
+see the Kokkos programmers' guide at /lib/kokkos/doc/Kokkos_PG.pdf.
+
+Kokkos currently provides support for 3 modes of execution (per MPI
+task). These are Serial (MPI-only for CPUs and Intel Phi), OpenMP
+(threading for many-core CPUs and Intel Phi), and CUDA (for NVIDIA
+GPUs). You choose the mode at build time to produce an executable
+compatible with specific hardware.
+
+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.
+
+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 the case, especially when using pre-compiled MPI libraries
+provided by a Linux distribution. This is not a problem when using
+only a single GPU and a single MPI rank on a desktop. When running
+with multiple MPI ranks, you may see segmentation faults without
+GPU-direct support. These can be avoided by adding the flags "-pk
+kokkos gpu/direct off"_Run_options.html to the LAMMPS command line or
+by using the command "package kokkos gpu/direct off"_package.html in
+the input file.
+
+[Building LAMMPS with the KOKKOS package:]
+
+See the "Build extras"_Build_extras.html#kokkos doc page for instructions.
+
+[Running LAMMPS with the KOKKOS package:]
+
+All Kokkos operations occur within the context of an individual MPI
+task running on a single node of the machine. The total number of MPI
+tasks used by LAMMPS (one or multiple per compute node) is set in the
+usual manner via the mpirun or mpiexec commands, and is independent of
+Kokkos. E.g. the mpirun command in OpenMPI does this via its -np and
+-npernode switches. Ditto for MPICH via -np and -ppn.
+
+[Running on a multi-core CPU:]
+
+Here is a quick overview of how to use the KOKKOS package
+for CPU acceleration, assuming one or more 16-core nodes.
+
+mpirun -np 16 lmp_kokkos_mpi_only -k on -sf kk -in in.lj # 1 node, 16 MPI tasks/node, no multi-threading
+mpirun -np 2 -ppn 1 lmp_kokkos_omp -k on t 16 -sf kk -in in.lj # 2 nodes, 1 MPI task/node, 16 threads/task
+mpirun -np 2 lmp_kokkos_omp -k on t 8 -sf kk -in in.lj # 1 node, 2 MPI tasks/node, 8 threads/task
+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"_Run_options.html in your mpirun
+command. You must use the "-k on" "command-line
+switch"_Run_options.html to enable the KOKKOS package. It takes
+additional arguments for hardware settings appropriate to your system.
+For OpenMP use:
+
+-k on t Nt :pre
+
+The "t Nt" option specifies how many OpenMP threads per MPI task to
+use with a node. The default is Nt = 1, which is MPI-only mode. Note
+that the product of MPI tasks * OpenMP threads/task should not exceed
+the physical number of cores (on a node), otherwise performance will
+suffer. If hyperthreading is enabled, then the product of MPI tasks *
+OpenMP threads/task should not exceed the physical number of cores *
+hardware threads. The "-k on" switch also issues a "package kokkos"
+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"_Run_options.html will automatically
+append the "/kk" suffix to styles that support it. In this manner no
+modification to the input script is needed. Alternatively, one can run
+with the KOKKOS package by editing the input script as described
+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
+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"_Run_options.html to change the
+default "package kokkos"_package.html options. See its doc page for
+details and default settings. Experimenting with its options can
+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
+
+If the "newton"_newton.html command is used in the input
+script, it can also override the Newton flag defaults.
+
+[Core and Thread Affinity:]
+
+When using multi-threading, it is important for performance to bind
+both MPI tasks to physical cores, and threads to physical cores, so
+they do not migrate during a simulation.
+
+If you are not certain MPI tasks are being bound (check the defaults
+for your MPI installation), binding can be forced with these flags:
+
+OpenMPI 1.8: mpirun -np 2 --bind-to socket --map-by socket ./lmp_openmpi ...
+Mvapich2 2.0: mpiexec -np 2 --bind-to socket --map-by socket ./lmp_mvapich ... :pre
+
+For binding threads with KOKKOS OpenMP, use thread affinity
+environment variables to force binding. With OpenMP 3.1 (gcc 4.7 or
+later, intel 12 or later) setting the environment variable
+OMP_PROC_BIND=true should be sufficient. In general, for best
+performance with OpenMP 4.0 or better set OMP_PROC_BIND=spread and
+OMP_PLACES=threads. For binding threads with the KOKKOS pthreads
+option, compile LAMMPS the KOKKOS HWLOC=yes option as described below.
+
+[Running on Knight's Landing (KNL) Intel Xeon Phi:]
+
+Here is a quick overview of how to use the KOKKOS package for the
+Intel Knight's Landing (KNL) Xeon Phi:
+
+KNL Intel Phi chips have 68 physical cores. Typically 1 to 4 cores are
+reserved for the OS, and only 64 or 66 cores are used. Each core has 4
+hyperthreads,so there are effectively N = 256 (4*64) or N = 264 (4*66)
+cores to run on. The product of MPI tasks * OpenMP threads/task should
+not exceed this limit, otherwise performance will suffer. Note that
+with the KOKKOS package you do not need to specify how many KNLs there
+are per node; each KNL is simply treated as running some number of MPI
+tasks.
+
+Examples of mpirun commands that follow these rules are shown below.
+
+Intel KNL node with 68 cores (272 threads/node via 4x hardware threading):
+mpirun -np 64 lmp_kokkos_phi -k on t 4 -sf kk -in in.lj # 1 node, 64 MPI tasks/node, 4 threads/task
+mpirun -np 66 lmp_kokkos_phi -k on t 4 -sf kk -in in.lj # 1 node, 66 MPI tasks/node, 4 threads/task
+mpirun -np 32 lmp_kokkos_phi -k on t 8 -sf kk -in in.lj # 1 node, 32 MPI tasks/node, 8 threads/task
+mpirun -np 512 -ppn 64 lmp_kokkos_phi -k on t 4 -sf kk -in in.lj # 8 nodes, 64 MPI tasks/node, 4 threads/task :pre
+
+The -np setting of the mpirun command sets the number of MPI
+tasks/node. The "-k on t Nt" command-line switch sets the number of
+threads/task as Nt. The product of these two values should be N, i.e.
+256 or 264.
+
+NOTE: The default for the "package kokkos"_package.html command is to
+use "full" neighbor lists and set the Newton flag to "off" for both
+pairwise and bonded interactions. When running on KNL, this will
+typically be best for pair-wise potentials. For manybody potentials,
+using "half" neighbor lists and setting the Newton flag to "on" may be
+faster. It can also be faster to use non-threaded communication. Use
+the "-pk kokkos" "command-line switch"_Run_options.html to change the
+default "package kokkos"_package.html options. See its doc page for
+details and default settings. Experimenting with its options can
+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
+
+NOTE: MPI tasks and threads should be bound to cores as described
+above for CPUs.
+
+NOTE: To build with Kokkos support for Intel Xeon Phi coprocessors
+such as Knight's Corner (KNC), your system must be configured to use
+them in "native" mode, not "offload" mode like the USER-INTEL package
+supports.
+
+[Running on GPUs:]
+
+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 number of physical GPUs on the node. You can assign multiple MPI
+tasks to the same GPU with the KOKKOS package, but this is usually
+only faster if significant portions of the input script have not
+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"_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.
+
+-k on g Ng :pre
+
+Here are examples of how to use the KOKKOS package for GPUs, assuming
+one or more nodes, each with two GPUs:
+
+mpirun -np 2 lmp_kokkos_cuda_openmpi -k on g 2 -sf kk -in in.lj # 1 node, 2 MPI tasks/node, 2 GPUs/node
+mpirun -np 32 -ppn 2 lmp_kokkos_cuda_openmpi -k on g 2 -sf kk -in in.lj # 16 nodes, 2 MPI tasks/node, 2 GPUs/node (32 GPUs total) :pre
+
+NOTE: The default for the "package kokkos"_package.html command is to
+use "full" neighbor lists and set the Newton flag to "off" for both
+pairwise and bonded interactions, along with threaded communication.
+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"_Run_options.html to change
+the default "package kokkos"_package.html options. See its doc page
+for details and default settings. Experimenting with its options can
+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
+
+NOTE: For good performance of the KOKKOS package on GPUs, you must
+have Kepler generation GPUs (or later). The Kokkos library exploits
+texture cache options not supported by Telsa generation GPUs (or
+older).
+
+NOTE: When using a GPU, you will achieve the best performance if your
+input script does not use fix or compute styles which are not yet
+Kokkos-enabled. This allows data to stay on the GPU for multiple
+timesteps, without being copied back to the host CPU. Invoking a
+non-Kokkos fix or compute, or performing I/O for
+"thermo"_thermo_style.html or "dump"_dump.html output will cause data
+to be copied back to the CPU incurring a performance penalty.
+
+NOTE: To get an accurate timing breakdown between time spend in pair,
+kspace, etc., you must set the environment variable CUDA_LAUNCH_BLOCKING=1.
+However, this will reduce performance and is not recommended for production runs.
+
+[Run with the KOKKOS package by editing an input script:]
+
+Alternatively the effect of the "-sf" or "-pk" switches can be
+duplicated by adding the "package kokkos"_package.html or "suffix
+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 switch"_Run_options.html
+to enable the KOKKOS package, and specify its additional arguments for
+hardware options appropriate to 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.
+
+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"_Run_options.html.
+
+[Using OpenMP threading and CUDA together (experimental):]
+
+With the KOKKOS package, both OpenMP multi-threading and GPUs can be
+used together in a few special cases. In the Makefile, the
+KOKKOS_DEVICES variable must include both "Cuda" and "OpenMP", as is
+the case for /src/MAKE/OPTIONS/Makefile.kokkos_cuda_mpi
+
+KOKKOS_DEVICES=Cuda,OpenMP :pre
+
+The suffix "/kk" is equivalent to "/kk/device", and for Kokkos CUDA,
+using the "-sf kk" in the command line gives the default CUDA version
+everywhere. However, if the "/kk/host" suffix is added to a specific
+style in the input script, the Kokkos OpenMP (CPU) version of that
+specific style will be used instead. Set the number of OpenMP threads
+as "t Nt" and the number of GPUs as "g Ng"
+
+-k on t Nt g Ng :pre
+
+For example, the command to run with 1 GPU and 8 OpenMP threads is then:
+
+mpiexec -np 1 lmp_kokkos_cuda_openmpi -in in.lj -k on g 1 t 8 -sf kk :pre
+
+Conversely, if the "-sf kk/host" is used in the command line and then
+the "/kk" or "/kk/device" suffix is added to a specific style in your
+input script, then only that specific style will run on the GPU while
+everything else will run on the CPU in OpenMP mode. Note that the
+execution of the CPU and GPU styles will NOT overlap, except for a
+special case:
+
+A kspace style and/or molecular topology (bonds, angles, etc.) running
+on the host CPU can overlap with a pair style running on the
+GPU. First compile with "--default-stream per-thread" added to CCFLAGS
+in the Kokkos CUDA Makefile. Then explicitly use the "/kk/host"
+suffix for kspace and bonds, angles, etc. in the input file and the
+"kk" suffix (equal to "kk/device") on the command line. Also make
+sure the environment variable CUDA_LAUNCH_BLOCKING is not set to "1"
+so CPU/GPU overlap can occur.
+
+[Speed-ups to expect:]
+
+The performance of KOKKOS running in different modes is a function of
+your hardware, which KOKKOS-enable styles are used, and the problem
+size.
+
+Generally speaking, the following rules of thumb apply:
+
+When running on CPUs only, with a single thread per MPI task,
+performance of a KOKKOS style is somewhere between the standard
+(un-accelerated) styles (MPI-only mode), and those provided by the
+USER-OMP package. However the difference between all 3 is small (less
+than 20%). :ulb,l
+
+When running on CPUs only, with multiple threads per MPI task,
+performance of a KOKKOS style is a bit slower than the USER-OMP
+package. :l
+
+When running large number of atoms per GPU, KOKKOS is typically faster
+than the GPU package. :l
+
+When running on Intel hardware, KOKKOS is not as fast as
+the USER-INTEL package, which is optimized for that hardware. :l
+:ule
+
+See the "Benchmark page"_http://lammps.sandia.gov/bench.html of the
+LAMMPS web site for performance of the KOKKOS package on different
+hardware.
+
+[Advanced Kokkos options:]
+
+There are other allowed options when building with the KOKKOS package.
+As explained on the "Build extras"_Build_extras.html#kokkos doc page,
+they can be set either as variables on the make command line or in
+Makefile.machine, or they can be specified as CMake variables. Each
+takes a value shown below. The default value is listed, which is set
+in the lib/kokkos/Makefile.kokkos file.
+
+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_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
+necessary for KOKKOS_DEVICES=OpenMP for OpenMP, because OpenMP
+provides alternative methods via environment variables for binding
+threads to hardware cores. More info on binding threads to cores is
+given on the "Speed omp"_Speed_omp.html doc page.
+
+KOKKOS_USE_TPLS=librt enables use of a more accurate timer mechanism
+on most Unix platforms. This library is not available on all
+platforms.
+
+KOKKOS_DEBUG is only useful when developing a Kokkos-enabled style
+within LAMMPS. KOKKOS_DEBUG=yes enables printing of run-time
+debugging information that can be useful. It also enables runtime
+bounds checking on Kokkos data structures.
+
+KOKKOS_CXX_STANDARD and KOKKOS_OPTIONS are typically not changed when
+building LAMMPS.
+
+KOKKOS_CUDA_OPTIONS are additional options for CUDA. The LAMMPS KOKKOS
+package must be compiled with the {enable_lambda} option when using
+GPUs.
+
+[Restrictions:]
+
+Currently, there are no precision options with the KOKKOS package. All
+compilation and computation is performed in double precision.
diff --git a/doc/src/Speed_measure.txt b/doc/src/Speed_measure.txt
new file mode 100644
index 0000000000000000000000000000000000000000..647ff71e36593f9a642c22360e74c36752e43e7d
--- /dev/null
+++ b/doc/src/Speed_measure.txt
@@ -0,0 +1,55 @@
+"Higher level section"_Speed.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
+
+Measuring performance :h3
+
+Before trying to make your simulation run faster, you should
+understand how it currently performs and where the bottlenecks are.
+
+The best way to do this is run the your system (actual number of
+atoms) for a modest number of timesteps (say 100 steps) on several
+different processor counts, including a single processor if possible.
+Do this for an equilibrium version of your system, so that the
+100-step timings are representative of a much longer run. There is
+typically no need to run for 1000s of timesteps to get accurate
+timings; you can simply extrapolate from short runs.
+
+For the set of runs, look at the timing data printed to the screen and
+log file at the end of each LAMMPS run. The
+"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
+the most time. Running the same problem on a few different processor
+counts should give an estimate of parallel scalability. I.e. if the
+simulation runs 16x faster on 16 processors, its 100% parallel
+efficient; if it runs 8x faster on 16 processors, it's 50% efficient.
+
+The most important data to look at in the timing info is the timing
+breakdown and relative percentages. For example, trying different
+options for speeding up the long-range solvers will have little impact
+if they only consume 10% of the run time. If the pairwise time is
+dominating, you may want to look at GPU or OMP versions of the pair
+style, as discussed below. Comparing how the percentages change as
+you increase the processor count gives you a sense of how different
+operations within the timestep are scaling. Note that if you are
+running with a Kspace solver, there is additional output on the
+breakdown of the Kspace time. For PPPM, this includes the fraction
+spent on FFTs, which can be communication intensive.
+
+Another important detail in the timing info are the histograms of
+atoms counts and neighbor counts. If these vary widely across
+processors, you have a load-imbalance issue. This often results in
+inaccurate relative timing data, because processors have to wait when
+communication occurs for other processors to catch up. Thus the
+reported times for "Communication" or "Other" may be higher than they
+really are, due to load-imbalance. If this is an issue, you can
+uncomment the MPI_Barrier() lines in src/timer.cpp, and recompile
+LAMMPS, to obtain synchronized timings.
+
diff --git a/doc/src/accelerate_omp.txt b/doc/src/Speed_omp.txt
similarity index 71%
rename from doc/src/accelerate_omp.txt
rename to doc/src/Speed_omp.txt
index fa7bef1a520bd867b4d3cf610d50b5ea8614c865..0abf54430ef042de4e04080cd741332cf5a7b85f 100644
--- a/doc/src/accelerate_omp.txt
+++ b/doc/src/Speed_omp.txt
@@ -1,52 +1,41 @@
-"Previous Section"_Section_packages.html - "LAMMPS WWW Site"_lws -
-"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+"Higher level section"_Speed.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
-"Return to Section 5 overview"_Section_accelerate.html
-
-5.3.4 USER-OMP package :h5
+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,
-nearly all bonded styles (bond, angle, dihedral, improper), several
-Kspace styles, and a few fix styles. The package currently uses the
-OpenMP interface for multi-threading.
-
-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
+University. It provides optimized and multi-threaded versions
+of many pair styles, nearly all bonded styles (bond, angle, dihedral,
+improper), several Kspace styles, and a few fix styles. It uses
+the OpenMP interface for multi-threading, but can also be compiled
+without OpenMP support, providing optimized serial styles in that case.
[Required hardware/software:]
-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.
+To enable multi-threading, your compiler must support the OpenMP interface.
+You should have one or more multi-core CPUs, as multiple threads can only be
+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
-package in two steps, using the "make" command. Or how to do it with
-one command as described in "Section 4"_Section_packages.html of the manual.
-
-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".
+See the "Build extras"_Build_extras.html#user-omp doc page for
+instructions.
[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
@@ -58,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
-"omp" to styles that support it. The "-sf omp" switch also issues a
-default "package omp 0"_package.html command, which will set the
-number of threads per MPI task via the OMP_NUM_THREADS environment
-variable.
+switch"_Run_options.html, which will automatically append "omp" to
+styles that support it. The "-sf omp" switch also issues a default
+"package omp 0"_package.html command, which will set the number of
+threads per MPI task via the OMP_NUM_THREADS environment variable.
You can also use the "-pk omp Nt" "command-line
-switch"_Section_start.html#start_6, to explicitly set Nt = # of OpenMP
-threads per MPI task to use, as well as additional options. Its
-syntax is the same as the "package omp"_package.html command whose doc
-page gives details, including the default values used if it is not
-specified. It also gives more details on how to set the number of
-threads via the OMP_NUM_THREADS environment variable.
+switch"_Run_options.html, to explicitly set Nt = # of OpenMP threads
+per MPI task to use, as well as additional options. Its syntax is the
+same as the "package omp"_package.html command whose doc page gives
+details, including the default values used if it is not specified. It
+also gives more details on how to set the number of threads via the
+OMP_NUM_THREADS environment variable.
[Or run with the USER-OMP package by editing an input script:]
@@ -100,7 +88,7 @@ task, versus running standard LAMMPS with its standard un-accelerated
styles (in serial or all-MPI parallelization with 1 task/core). This
is because many of the USER-OMP styles contain similar optimizations
to those used in the OPT package, described in "Section
-5.3.5"_accelerate_opt.html.
+5.3.5"_Speed_opt.html.
With multiple threads/task, the optimal choice of number of MPI
tasks/node and OpenMP threads/task can vary a lot and should always be
diff --git a/doc/src/accelerate_opt.txt b/doc/src/Speed_opt.txt
similarity index 55%
rename from doc/src/accelerate_opt.txt
rename to doc/src/Speed_opt.txt
index 845264b5227ca31493cb582eac91ab5c216427ae..7dd83a84bfb027d1a34cd4cda8285895fda53f76 100644
--- a/doc/src/accelerate_opt.txt
+++ b/doc/src/Speed_opt.txt
@@ -1,15 +1,13 @@
-"Previous Section"_Section_packages.html - "LAMMPS WWW Site"_lws -
-"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+"Higher level section"_Speed.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
-"Return to Section accelerate overview"_Section_accelerate.html
-
-5.3.5 OPT package :h5
+OPT package :h3
The OPT package was developed by James Fischer (High Performance
Technologies), David Richie, and Vincent Natoli (Stone Ridge
@@ -17,33 +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
-two steps, using the "make" command. Or how to do it with one command
-as described in "Section 4"_Section_packages.html of the manual.
-
-Note that if you use an Intel compiler to build with the OPT package,
-the CCFLAGS setting in your Makefile.machine must include "-restrict".
+See the "Build extras"_Build_extras.html#opt doc page for instructions.
[Run with the OPT package from the command line:]
-As in the lines above, use the "-sf opt" "command-line
-switch"_Section_start.html#start_6, which will automatically append
-"opt" to styles that support it.
+lmp_mpi -sf opt -in in.script # run in serial
+mpirun -np 4 lmp_mpi -sf opt -in in.script # run in parallel :pre
+
+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:]
diff --git a/doc/src/Speed_packages.txt b/doc/src/Speed_packages.txt
new file mode 100644
index 0000000000000000000000000000000000000000..6c837885cd4dd5272e9b7925d84aa01ee8f9ab79
--- /dev/null
+++ b/doc/src/Speed_packages.txt
@@ -0,0 +1,192 @@
+"Higher level section"_Speed.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
+
+Accelerator packages :h3
+
+Accelerated versions of various "pair_style"_pair_style.html,
+"fixes"_fix.html, "computes"_compute.html, and other commands have
+been added to LAMMPS, which will typically run faster than the
+standard non-accelerated versions. Some require appropriate hardware
+to be present on your system, e.g. GPUs or Intel Xeon Phi
+coprocessors.
+
+All of these commands are in packages provided with LAMMPS. An
+overview of packages is give on the "Packages"_Packages.html doc
+pages.
+
+These are the accelerator packages currently in LAMMPS, either as
+standard or user packages:
+
+"GPU Package"_Speed_gpu.html : for NVIDIA GPUs as well as OpenCL support
+"USER-INTEL Package"_Speed_intel.html : for Intel CPUs and Intel Xeon Phi
+"KOKKOS Package"_Speed_kokkos.html : for Nvidia GPUs, Intel Xeon Phi, and OpenMP threading
+"USER-OMP Package"_Speed_omp.html : for OpenMP threading and generic CPU optimizations
+"OPT Package"_Speed_opt.html : generic CPU optimizations :tb(s=:)
+
+<!-- RST
+
+.. toctree::
+ :maxdepth: 1
+ :hidden:
+
+ Speed_gpu
+ Speed_intel
+ Speed_kokkos
+ Speed_omp
+ Speed_opt
+
+END_RST -->
+
+Inverting this list, LAMMPS currently has acceleration support for
+three kinds of hardware, via the listed packages:
+
+Many-core CPUs : "USER-INTEL"_Speed_intel.html, "KOKKOS"_Speed_kokkos.html, "USER-OMP"_Speed_omp.html, "OPT"_Speed_opt.html packages
+NVIDIA GPUs : "GPU"_Speed_gpu.html, "KOKKOS"_Speed_kokkos.html packages
+Intel Phi : "USER-INTEL"_Speed_intel.html, "KOKKOS"_Speed_kokkos.html packages :tb(s=:)
+
+Which package is fastest for your hardware may depend on the size
+problem you are running and what commands (accelerated and
+non-accelerated) are invoked by your input script. While these doc
+pages include performance guidelines, there is no substitute for
+trying out the different packages appropriate to your hardware.
+
+Any accelerated style has the same name as the corresponding standard
+style, except that a suffix is appended. Otherwise, the syntax for
+the command that uses the style is identical, their functionality is
+the same, and the numerical results it produces should also be the
+same, except for precision and round-off effects.
+
+For example, all of these styles are accelerated variants of the
+Lennard-Jones "pair_style lj/cut"_pair_lj.html:
+
+"pair_style lj/cut/gpu"_pair_lj.html
+"pair_style lj/cut/intel"_pair_lj.html
+"pair_style lj/cut/kk"_pair_lj.html
+"pair_style lj/cut/omp"_pair_lj.html
+"pair_style lj/cut/opt"_pair_lj.html :ul
+
+To see what accelerate styles are currently available for a particular
+style, find the style name in the "Commands_all"_Commands_all.html
+style pages (fix,compute,pair,etc) and see what suffixes are listed
+(g,i,k,o,t) with it. The doc pages for individual commands
+(e.g. "pair lj/cut"_pair_lj.html or "fix nve"_fix_nve.html) also list
+any accelerated variants available for that style.
+
+To use an accelerator package in LAMMPS, and one or more of the styles
+it provides, follow these general steps. Details vary from package to
+package and are explained in the individual accelerator doc pages,
+listed above:
+
+build the accelerator library |
+ only for GPU package |
+install the accelerator package |
+ make yes-opt, make yes-user-intel, etc |
+add compile/link flags to Makefile.machine in src/MAKE |
+ only for USER-INTEL, KOKKOS, USER-OMP, OPT packages |
+re-build LAMMPS |
+ make machine |
+prepare and test a regular LAMMPS simulation |
+ lmp_machine -in in.script; mpirun -np 32 lmp_machine -in in.script |
+enable specific accelerator support via '-k on' "command-line switch"_Run_options.html, |
+ only needed for KOKKOS package |
+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"_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
+suitable make command invocations. This is discussed on the
+"Packages"_Packages.html doc pages, and its use is illustrated in the
+individual accelerator sections. Typically these steps only need to
+be done once, to create an executable that uses one or more
+accelerator packages.
+
+The last 4 steps can all be done from the command-line when LAMMPS is
+launched, without changing your input script, as illustrated in the
+individual accelerator sections. Or you can add
+"package"_package.html and "suffix"_suffix.html commands to your input
+script.
+
+NOTE: With a few exceptions, you can build a single LAMMPS executable
+with all its accelerator packages installed. Note however that the
+USER-INTEL and KOKKOS packages require you to choose one of their
+hardware options when building for a specific platform. I.e. CPU or
+Phi option for the USER-INTEL package. Or the OpenMP, Cuda, or Phi
+option for the KOKKOS package.
+
+These are the exceptions. You cannot build a single executable with:
+
+both the USER-INTEL Phi and KOKKOS Phi options
+the USER-INTEL Phi or Kokkos Phi option, and the GPU package :ul
+
+See the examples/accelerate/README and make.list files for sample
+Make.py commands that build LAMMPS with any or all of the accelerator
+packages. As an example, here is a command that builds with all the
+GPU related packages installed (GPU, KOKKOS with Cuda), including
+settings to build the needed auxiliary GPU libraries for Kepler GPUs:
+
+Make.py -j 16 -p omp gpu kokkos -cc nvcc wrap=mpi \
+ -gpu mode=double arch=35 -kokkos cuda arch=35 lib-all file mpi :pre
+
+The examples/accelerate directory also has input scripts that can be
+used with all of the accelerator packages. See its README file for
+details.
+
+Likewise, the bench directory has FERMI and KEPLER and PHI
+sub-directories with Make.py commands and input scripts for using all
+the accelerator packages on various machines. See the README files in
+those dirs.
+
+As mentioned above, the "Benchmark
+page"_http://lammps.sandia.gov/bench.html of the LAMMPS web site gives
+performance results for the various accelerator packages for several
+of the standard LAMMPS benchmark problems, as a function of problem
+size and number of compute nodes, on different hardware platforms.
+
+Here is a brief summary of what the various packages provide. Details
+are in the individual accelerator sections.
+
+Styles with a "gpu" suffix are part of the GPU package, and can be run
+on NVIDIA GPUs. The speed-up on a GPU depends on a variety of
+factors, discussed in the accelerator sections. :ulb,l
+
+Styles with an "intel" suffix are part of the USER-INTEL
+package. These styles support vectorized single and mixed precision
+calculations, in addition to full double precision. In extreme cases,
+this can provide speedups over 3.5x on CPUs. The package also
+supports acceleration in "offload" mode to Intel(R) Xeon Phi(TM)
+coprocessors. This can result in additional speedup over 2x depending
+on the hardware configuration. :l
+
+Styles with a "kk" suffix are part of the KOKKOS package, and can be
+run using OpenMP on multicore CPUs, on an NVIDIA GPU, or on an Intel
+Xeon Phi in "native" mode. The speed-up depends on a variety of
+factors, as discussed on the KOKKOS accelerator page. :l
+
+Styles with an "omp" suffix are part of the USER-OMP package and allow
+a pair-style to be run in multi-threaded mode using OpenMP. This can
+be useful on nodes with high-core counts when using less MPI processes
+than cores is advantageous, e.g. when running with PPPM so that FFTs
+are run on fewer MPI processors or when the many MPI tasks would
+overload the available bandwidth for communication. :l
+
+Styles with an "opt" suffix are part of the OPT package and typically
+speed-up the pairwise calculations of your simulation by 5-25% on a
+CPU. :l
+:ule
+
+The individual accelerator package doc pages explain:
+
+what hardware and software the accelerated package requires
+how to build LAMMPS with the accelerated package
+how to run with the accelerated package either via command-line switches or modifying the input script
+speed-ups to expect
+guidelines for best performance
+restrictions :ul
+
diff --git a/doc/src/Speed_tips.txt b/doc/src/Speed_tips.txt
new file mode 100644
index 0000000000000000000000000000000000000000..858b1d493fcbc9c54cc29ab6b23859a77df4677b
--- /dev/null
+++ b/doc/src/Speed_tips.txt
@@ -0,0 +1,59 @@
+"Higher level section"_Speed.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
+
+General tips :h3
+
+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
+bottlenecks in the current performance, so let the timing data you
+generate be your guide. It is hard, if not impossible, to predict how
+much difference these options will make, since it is a function of
+problem size, number of processors used, and your machine. There is
+no substitute for identifying performance bottlenecks, and trying out
+various options.
+
+rRESPA
+Two-FFT PPPM
+Staggered PPPM
+single vs double PPPM
+partial charge PPPM
+verlet/split run style
+processor command for proc layout and numa layout
+load-balancing: balance and fix balance :ul
+
+Two-FFT PPPM, also called {analytic differentiation} or {ad} PPPM,
+uses 2 FFTs instead of the 4 FFTs used by the default {ik
+differentiation} PPPM. However, 2-FFT PPPM also requires a slightly
+larger mesh size to achieve the same accuracy as 4-FFT PPPM. For
+problems where the FFT cost is the performance bottleneck (typically
+large problems running on many processors), 2-FFT PPPM may be faster
+than 4-FFT PPPM.
+
+Staggered PPPM performs calculations using two different meshes, one
+shifted slightly with respect to the other. This can reduce force
+aliasing errors and increase the accuracy of the method, but also
+doubles the amount of work required. For high relative accuracy, using
+staggered PPPM allows one to half the mesh size in each dimension as
+compared to regular PPPM, which can give around a 4x speedup in the
+kspace time. However, for low relative accuracy, using staggered PPPM
+gives little benefit and can be up to 2x slower in the kspace
+time. For example, the rhodopsin benchmark was run on a single
+processor, and results for kspace time vs. relative accuracy for the
+different methods are shown in the figure below. For this system,
+staggered PPPM (using ik differentiation) becomes useful when using a
+relative accuracy of slightly greater than 1e-5 and above.
+
+:c,image(JPG/rhodo_staggered.jpg)
+
+NOTE: Using staggered PPPM may not give the same increase in accuracy
+of energy and pressure as it does in forces, so some caution must be
+used if energy and/or pressure are quantities of interest, such as
+when using a barostat.
diff --git a/doc/src/Section_tools.txt b/doc/src/Tools.txt
similarity index 83%
rename from doc/src/Section_tools.txt
rename to doc/src/Tools.txt
index 7cc07cbec55a5e7c4f3545c623875be8cc6919cc..a9ad5032cec07de0048ba0288733267caaf18f8e 100644
--- a/doc/src/Section_tools.txt
+++ b/doc/src/Tools.txt
@@ -1,40 +1,41 @@
-"Previous Section"_Section_perf.html - "LAMMPS WWW Site"_lws - "LAMMPS
+"Previous Section"_Examples.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc - "Next
-Section"_Section_modify.html :c
+Section"_Modify.html :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
-9. Additional tools :h2
+Auxiliary tools :h2
LAMMPS is designed to be a computational kernel for performing
molecular dynamics computations. Additional pre- and post-processing
-steps are often necessary to setup and analyze a simulation. A
-list of such tools can be found on the LAMMPS home page
-at "http://lammps.sandia.gov/prepost.html"_http://lammps.sandia.gov/prepost.html
+steps are often necessary to setup and analyze a simulation. A list
+of such tools can be found on the "LAMMPS webpage"_lws at these links:
-A few additional tools are provided with the LAMMPS distribution
-and are described in this section.
+"Pre/Post processing"_http://lammps.sandia.gov/prepost.html
+"Offsite LAMMPS packages & tools"_http://lammps.sandia.gov/offsite.html
+"Pizza.py toolkit"_pizza :ul
-Our group has also written and released a separate toolkit called
-"Pizza.py"_pizza which provides tools for doing setup, analysis,
-plotting, and visualization for LAMMPS simulations. Pizza.py is
-written in "Python"_python and is available for download from "the
-Pizza.py WWW site"_pizza.
+The last link for "Pizza.py"_pizza is a Python-based tool developed at
+Sandia which provides tools for doing setup, analysis, plotting, and
+visualization for LAMMPS simulations.
-:link(pizza,http://www.sandia.gov/~sjplimp/pizza.html)
+:link(pizza,http://pizza.sandia.gov)
:link(python,http://www.python.org)
+Additional tools included in the LAMMPS distribution are described on
+this page.
+
Note that many users write their own setup or analysis tools or use
other existing codes and convert their output to a LAMMPS input format
or vice versa. The tools listed here are included in the LAMMPS
distribution as examples of auxiliary tools. Some of them are not
-actively supported by Sandia, as they were contributed by LAMMPS
-users. If you have problems using them, we can direct you to the
-authors.
+actively supported by the LAMMPS developers, as they were contributed
+by LAMMPS users. If you have problems using them, we can direct you
+to the authors.
The source code for each of these codes is in the tools sub-directory
of the LAMMPS distribution. There is a Makefile (which you may need
@@ -42,40 +43,55 @@ to edit for your platform) which will build several of the tools which
reside in that directory. Most of them are larger packages in their
own sub-directories with their own Makefiles and/or README files.
-"amber2lmp"_#amber
-"binary2txt"_#binary
-"ch2lmp"_#charmm
-"chain"_#chain
-"colvars"_#colvars
-"createatoms"_#createatoms
-"doxygen"_#doxygen
-"drude"_#drude
-"eam database"_#eamdb
-"eam generate"_#eamgn
-"eff"_#eff
-"emacs"_#emacs
-"fep"_#fep
-"i-pi"_#ipi
-"ipp"_#ipp
-"kate"_#kate
-"lmp2arc"_#arc
-"lmp2cfg"_#cfg
-"matlab"_#matlab
-"micelle2d"_#micelle
-"moltemplate"_#moltemplate
-"msi2lmp"_#msi
-"phonon"_#phonon
-"polybond"_#polybond
-"pymol_asphere"_#pymol
-"python"_#pythontools
-"reax"_#reax_tool
-"smd"_#smd
-"vim"_#vim
-"xmgrace"_#xmgrace
-
-:line
-
-amber2lmp tool :h3,link(amber)
+:line
+
+Pre-processing tools :h3
+
+"amber2lmp"_#amber,
+"ch2lmp"_#charmm,
+"chain"_#chain,
+"createatoms"_#createatoms,
+"drude"_#drude,
+"eam database"_#eamdb,
+"eam generate"_#eamgn,
+"eff"_#eff,
+"ipp"_#ipp,
+"micelle2d"_#micelle,
+"moltemplate"_#moltemplate,
+"msi2lmp"_#msi,
+"polybond"_#polybond :tb(c=6,ea=c,a=l)
+
+Post-processing tools :h3
+
+"amber2lmp"_#amber,
+"binary2txt"_#binary,
+"ch2lmp"_#charmm,
+"colvars"_#colvars,
+"eff"_#eff,
+"fep"_#fep,
+"lmp2arc"_#arc,
+"lmp2cfg"_#cfg,
+"matlab"_#matlab,
+"phonon"_#phonon,
+"pymol_asphere"_#pymol,
+"python"_#pythontools,
+"reax"_#reax_tool,
+"smd"_#smd,
+"xmgrace"_#xmgrace :tb(c=6,ea=c,a=l)
+
+Miscellaneous tools :h3
+
+"doxygen"_#doxygen,
+"emacs"_#emacs,
+"i-pi"_#ipi,
+"kate"_#kate,
+"vim"_#vim :tb(c=5,ea=c,a=l)
+
+:line
+
+Tool descriptions :h3
+
+amber2lmp tool :h4,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
@@ -90,7 +106,7 @@ necessary modifications yourself.
:line
-binary2txt tool :h3,link(binary)
+binary2txt tool :h4,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
@@ -103,7 +119,7 @@ since binary files are not compatible across all platforms.
:line
-ch2lmp tool :h3,link(charmm)
+ch2lmp tool :h4,link(charmm)
The ch2lmp sub-directory contains tools for converting files
back-and-forth between the CHARMM MD code and LAMMPS.
@@ -128,7 +144,7 @@ Chris Lorenz (chris.lorenz at kcl.ac.uk), King's College London.
:line
-chain tool :h3,link(chain)
+chain tool :h4,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
@@ -140,12 +156,12 @@ The syntax for running the tool is
chain < def.chain > data.file :pre
See the def.chain or def.chain.ab files in the tools directory for
-examples of definition files. This tool was used to create the
-system for the "chain benchmark"_Section_perf.html.
+examples of definition files. This tool was used to create the system
+for the "chain benchmark"_Speed_bench.html.
:line
-colvars tools :h3,link(colvars)
+colvars tools :h4,link(colvars)
The colvars directory contains a collection of tools for postprocessing
data produced by the colvars collective variable library.
@@ -167,7 +183,7 @@ gmail.com) at ICTP, Italy.
:line
-createatoms tool :h3,link(createatoms)
+createatoms tool :h4,link(createatoms)
The tools/createatoms directory contains a Fortran program called
createAtoms.f which can generate a variety of interesting crystal
@@ -180,7 +196,7 @@ The tool is authored by Xiaowang Zhou (Sandia), xzhou at sandia.gov.
:line
-doxygen tool :h3,link(doxygen)
+doxygen tool :h4,link(doxygen)
The tools/doxygen directory contains a shell script called
doxygen.sh which can generate a call graph and API lists using
@@ -192,7 +208,7 @@ The tool is authored by Nandor Tamaskovics, numericalfreedom at googlemail.com.
:line
-drude tool :h3,link(drude)
+drude tool :h4,link(drude)
The tools/drude directory contains a Python script called
polarizer.py which can add Drude oscillators to a LAMMPS
@@ -205,7 +221,7 @@ at univ-bpclermont.fr, alain.dequidt at univ-bpclermont.fr
:line
-eam database tool :h3,link(eamdb)
+eam database tool :h4,link(eamdb)
The tools/eam_database directory contains a Fortran program that will
generate EAM alloy setfl potential files for any combination of 16
@@ -221,7 +237,7 @@ X. W. Zhou, R. A. Johnson, and H. N. G. Wadley, Phys. Rev. B, 69,
:line
-eam generate tool :h3,link(eamgn)
+eam generate tool :h4,link(eamgn)
The tools/eam_generate directory contains several one-file C programs
that convert an analytic formula into a tabulated "embedded atom
@@ -234,7 +250,7 @@ The source files and potentials were provided by Gerolf Ziegenhain
:line
-eff tool :h3,link(eff)
+eff tool :h4,link(eff)
The tools/eff directory contains various scripts for generating
structures and post-processing output for simulations using the
@@ -245,18 +261,18 @@ These tools were provided by Andres Jaramillo-Botero at CalTech
:line
-emacs tool :h3,link(emacs)
+emacs tool :h4,link(emacs)
-The tools/emacs directory contains a Lips add-on file for Emacs that
-enables a lammps-mode for editing of input scripts when using Emacs,
-with various highlighting options setup.
+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,
+with various highlighting options set up.
These tools were provided by Aidan Thompson at Sandia
(athomps at sandia.gov).
:line
-fep tool :h3,link(fep)
+fep tool :h4,link(fep)
The tools/fep directory contains Python scripts useful for
post-processing results from performing free-energy perturbation
@@ -269,7 +285,7 @@ See README file in the tools/fep directory.
:line
-i-pi tool :h3,link(ipi)
+i-pi tool :h4,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
@@ -286,7 +302,7 @@ calculations with LAMMPS.
:line
-ipp tool :h3,link(ipp)
+ipp tool :h4,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
@@ -300,7 +316,7 @@ tools/createatoms tool's input file.
:line
-kate tool :h3,link(kate)
+kate tool :h4,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
@@ -311,7 +327,7 @@ The file was provided by Alessandro Luigi Sellerio
:line
-lmp2arc tool :h3,link(arc)
+lmp2arc tool :h4,link(arc)
The lmp2arc sub-directory contains a tool for converting LAMMPS output
files to the format for Accelrys' Insight MD code (formerly
@@ -327,7 +343,7 @@ Greathouse at Sandia (jagreat at sandia.gov).
:line
-lmp2cfg tool :h3,link(cfg)
+lmp2cfg tool :h4,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
@@ -338,7 +354,7 @@ This tool was written by Ara Kooser at Sandia (askoose at sandia.gov).
:line
-matlab tool :h3,link(matlab)
+matlab tool :h4,link(matlab)
The matlab sub-directory contains several "MATLAB"_matlabhome scripts for
post-processing LAMMPS output. The scripts include readers for log
@@ -356,7 +372,7 @@ These scripts were written by Arun Subramaniyan at Purdue Univ
:line
-micelle2d tool :h3,link(micelle)
+micelle2d tool :h4,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
@@ -369,11 +385,11 @@ micelle2d < def.micelle2d > data.file :pre
See the def.micelle2d file in the tools directory for an example of a
definition file. This tool was used to create the system for the
-"micelle example"_Section_example.html.
+"micelle example"_Examples.html.
:line
-moltemplate tool :h3,link(moltemplate)
+moltemplate tool :h4,link(moltemplate)
The moltemplate sub-directory contains a Python-based tool for
building molecular systems based on a text-file description, and
@@ -387,7 +403,7 @@ supports it. It has its own WWW page at
:line
-msi2lmp tool :h3,link(msi)
+msi2lmp tool :h4,link(msi)
The msi2lmp sub-directory contains a tool for creating LAMMPS template
input and data files from BIOVIA's Materias Studio files (formerly Accelrys'
@@ -404,7 +420,7 @@ See the README file in the tools/msi2lmp folder for more information.
:line
-phonon tool :h3,link(phonon)
+phonon tool :h4,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
@@ -419,7 +435,7 @@ University.
:line
-polybond tool :h3,link(polybond)
+polybond tool :h4,link(polybond)
The polybond sub-directory contains a Python-based tool useful for
performing "programmable polymer bonding". The Python file
@@ -433,7 +449,7 @@ This tool was written by Zachary Kraus at Georgia Tech.
:line
-pymol_asphere tool :h3,link(pymol)
+pymol_asphere tool :h4,link(pymol)
The pymol_asphere sub-directory contains a tool for converting a
LAMMPS dump file that contains orientation info for ellipsoidal
@@ -451,7 +467,7 @@ This tool was written by Mike Brown at Sandia.
:line
-python tool :h3,link(pythontools)
+python tool :h4,link(pythontools)
The python sub-directory contains several Python scripts
that perform common LAMMPS post-processing tasks, such as:
@@ -467,7 +483,7 @@ README for more info on Pizza.py and how to use these scripts.
:line
-reax tool :h3,link(reax_tool)
+reax tool :h4,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
@@ -478,7 +494,7 @@ These tools were written by Aidan Thompson at Sandia.
:line
-smd tool :h3,link(smd)
+smd tool :h4,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
@@ -494,7 +510,7 @@ Ernst Mach Institute in Germany (georg.ganzenmueller at emi.fhg.de).
:line
-vim tool :h3,link(vim)
+vim tool :h4,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
@@ -505,7 +521,7 @@ ziegenhain.com)
:line
-xmgrace tool :h3,link(xmgrace)
+xmgrace tool :h4,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
@@ -517,4 +533,3 @@ simulation.
See the README file for details.
These files were provided by Vikas Varshney (vv0210 at gmail.com)
-
diff --git a/doc/src/accelerate_kokkos.txt b/doc/src/accelerate_kokkos.txt
deleted file mode 100644
index 0c9178d6e4f42863003b0a2848f29cd42189620f..0000000000000000000000000000000000000000
--- a/doc/src/accelerate_kokkos.txt
+++ /dev/null
@@ -1,458 +0,0 @@
-"Previous Section"_Section_packages.html - "LAMMPS WWW Site"_lws -
-"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
-
-:link(lws,http://lammps.sandia.gov)
-:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
-
-:line
-
-"Return to Section accelerate overview"_Section_accelerate.html
-
-5.3.3 KOKKOS package :h5
-
-Kokkos is a templated C++ library that provides abstractions to allow
-a single implementation of an application kernel (e.g. a pair style) to run efficiently on
-different kinds of hardware, such as GPUs, Intel Xeon Phis, or many-core
-CPUs. Kokkos maps the C++ kernel onto different backend languages such as CUDA, OpenMP, or Pthreads.
-The Kokkos library also provides data abstractions to adjust (at
-compile time) the memory layout of data structures like 2d and
-3d arrays to optimize performance on different hardware. For more information on Kokkos, see
-"Github"_https://github.com/kokkos/kokkos. Kokkos is part of
-"Trilinos"_http://trilinos.sandia.gov/packages/kokkos. The Kokkos library was written primarily by Carter Edwards,
-Christian Trott, and Dan Sunderland (all Sandia).
-
-The LAMMPS KOKKOS package contains versions of pair, fix, and atom styles
-that use data structures and macros provided by the Kokkos library,
-which is included with LAMMPS in /lib/kokkos. The KOKKOS package was developed primarily by Christian Trott (Sandia)
-and Stan Moore (Sandia) with contributions of various styles by others, including Sikandar
-Mashayak (UIUC), Ray Shan (Sandia), and Dan Ibanez (Sandia). For more information on developing using Kokkos abstractions
-see the Kokkos programmers' guide at /lib/kokkos/doc/Kokkos_PG.pdf.
-
-Kokkos currently provides support for 3 modes of execution (per MPI
-task). These are Serial (MPI-only for CPUs and Intel Phi), OpenMP (threading
-for many-core CPUs and Intel Phi), and CUDA (for NVIDIA 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"_accelerate_gpu.html package for details of
-how to check and do this.
-
-use a C++11 compatible compiler and set KOKKOS_ARCH variable in
-/src/MAKE/OPTIONS/Makefile.kokkos_cuda_mpi for both GPU and CPU as described
-above. Then do the following:
-
-cd lammps/src
-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:]
-
-All Kokkos operations occur within the
-context of an individual MPI task running on a single node of the
-machine. The total number of MPI tasks used by LAMMPS (one or
-multiple per compute node) is set in the usual manner via the mpirun
-or mpiexec commands, and is independent of Kokkos. E.g. the mpirun
-command in OpenMPI does this via its
--np and -npernode switches. Ditto for MPICH via -np and -ppn.
-
-[Running on a multi-core CPU:]
-
-Here is a quick overview of how to use the KOKKOS package
-for CPU acceleration, assuming one or more 16-core nodes.
-
-mpirun -np 16 lmp_kokkos_mpi_only -k on -sf kk -in in.lj # 1 node, 16 MPI tasks/node, no multi-threading
-mpirun -np 2 -ppn 1 lmp_kokkos_omp -k on t 16 -sf kk -in in.lj # 2 nodes, 1 MPI task/node, 16 threads/task
-mpirun -np 2 lmp_kokkos_omp -k on t 8 -sf kk -in in.lj # 1 node, 2 MPI tasks/node, 8 threads/task
-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 mpirun command.
-You must use the "-k on" "command-line
-switch"_Section_start.html#start_7 to enable the KOKKOS package. It
-takes additional arguments for hardware settings appropriate to your
-system. Those arguments are "documented
-here"_Section_start.html#start_7. For OpenMP use:
-
--k on t Nt :pre
-
-The "t Nt" option specifies how many OpenMP threads per MPI
-task to use with a node. The default is Nt = 1, which is MPI-only mode.
-Note that the product of MPI tasks * OpenMP
-threads/task should not exceed the physical number of cores (on a
-node), otherwise performance will suffer. If hyperthreading is enabled, then
-the product of MPI tasks * OpenMP threads/task should not exceed the
-physical number of cores * hardware threads.
-The "-k on" switch also issues a "package kokkos" 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 automatically append the "/kk" suffix to styles that support it.
-In this manner no modification to the input script is needed. Alternatively,
-one can run with the KOKKOS package by editing the input script as described 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
-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
-change the default "package kokkos"_package.html
-options. See its doc page for details and default settings. Experimenting with
-its options can 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
-
-If the "newton"_newton.html command is used in the input
-script, it can also override the Newton flag defaults.
-
-[Core and Thread Affinity:]
-
-When using multi-threading, it is important for
-performance to bind both MPI tasks to physical cores, and threads to
-physical cores, so they do not migrate during a simulation.
-
-If you are not certain MPI tasks are being bound (check the defaults
-for your MPI installation), binding can be forced with these flags:
-
-OpenMPI 1.8: mpirun -np 2 --bind-to socket --map-by socket ./lmp_openmpi ...
-Mvapich2 2.0: mpiexec -np 2 --bind-to socket --map-by socket ./lmp_mvapich ... :pre
-
-For binding threads with KOKKOS OpenMP, use thread affinity
-environment variables to force binding. With OpenMP 3.1 (gcc 4.7 or
-later, intel 12 or later) setting the environment variable
-OMP_PROC_BIND=true should be sufficient. In general, for best performance
-with OpenMP 4.0 or better set OMP_PROC_BIND=spread and OMP_PLACES=threads.
-For binding threads with the
-KOKKOS pthreads option, compile LAMMPS the KOKKOS HWLOC=yes option
-as described below.
-
-[Running on Knight's Landing (KNL) Intel Xeon Phi:]
-
-Here is a quick overview of how to use the KOKKOS package
-for the Intel Knight's Landing (KNL) Xeon Phi:
-
-KNL Intel Phi chips have 68 physical cores. Typically 1 to 4 cores
-are reserved for the OS, and only 64 or 66 cores are used. Each core
-has 4 hyperthreads,so there are effectively N = 256 (4*64) or
-N = 264 (4*66) cores to run on. The product of MPI tasks * OpenMP threads/task should not exceed this limit,
-otherwise performance will suffer. Note that with the KOKKOS package you do not need to
-specify how many KNLs there are per node; each
-KNL is simply treated as running some number of MPI tasks.
-
-Examples of mpirun commands that follow these rules are shown below.
-
-Intel KNL node with 68 cores (272 threads/node via 4x hardware threading):
-mpirun -np 64 lmp_kokkos_phi -k on t 4 -sf kk -in in.lj # 1 node, 64 MPI tasks/node, 4 threads/task
-mpirun -np 66 lmp_kokkos_phi -k on t 4 -sf kk -in in.lj # 1 node, 66 MPI tasks/node, 4 threads/task
-mpirun -np 32 lmp_kokkos_phi -k on t 8 -sf kk -in in.lj # 1 node, 32 MPI tasks/node, 8 threads/task
-mpirun -np 512 -ppn 64 lmp_kokkos_phi -k on t 4 -sf kk -in in.lj # 8 nodes, 64 MPI tasks/node, 4 threads/task :pre
-
-The -np setting of the mpirun command sets the number of MPI
-tasks/node. The "-k on t Nt" command-line switch sets the number of
-threads/task as Nt. The product of these two values should be N, i.e.
-256 or 264.
-
-NOTE: The default for the "package kokkos"_package.html command is
-to use "full" neighbor lists and set the Newton flag to "off" for both
-pairwise and bonded interactions. When running on KNL, this
-will typically be best for pair-wise potentials. For manybody potentials,
-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
-change the default "package kokkos"_package.html
-options. See its doc page for details and default settings. Experimenting with
-its options can 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
-
-NOTE: MPI tasks and threads should be bound to cores as described above for CPUs.
-
-NOTE: To build with Kokkos support for Intel Xeon Phi coprocessors such as Knight's Corner (KNC), your
-system must be configured to use them in "native" mode, not "offload"
-mode like the USER-INTEL package supports.
-
-[Running on GPUs:]
-
-Use the "-k" "command-line switch"_Section_commands.html#start_7 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 to the same GPU with the
-KOKKOS package, but this is usually only faster if significant portions
-of the input script have not been ported to use Kokkos. Using CUDA MPS
-is recommended in this scenario. 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.
-
--k on g Ng :pre
-
-Here are examples of how to use the KOKKOS package for GPUs,
-assuming one or more nodes, each with two GPUs:
-
-mpirun -np 2 lmp_kokkos_cuda_openmpi -k on g 2 -sf kk -in in.lj # 1 node, 2 MPI tasks/node, 2 GPUs/node
-mpirun -np 32 -ppn 2 lmp_kokkos_cuda_openmpi -k on g 2 -sf kk -in in.lj # 16 nodes, 2 MPI tasks/node, 2 GPUs/node (32 GPUs total) :pre
-
-NOTE: The default for the "package kokkos"_package.html command is
-to use "full" neighbor lists and set the Newton flag to "off" for both
-pairwise and bonded interactions, along with threaded communication.
-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 to
-change the default "package kokkos"_package.html
-options. See its doc page for details and default settings. Experimenting with
-its options can 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
-
-NOTE: For good performance of the KOKKOS package on GPUs, you must
-have Kepler generation GPUs (or later). The Kokkos library exploits
-texture cache options not supported by Telsa generation GPUs (or
-older).
-
-NOTE: When using a GPU, you will achieve the best performance if your
-input script does not use fix or compute styles which are not yet
-Kokkos-enabled. This allows data to stay on the GPU for multiple
-timesteps, without being copied back to the host CPU. Invoking a
-non-Kokkos fix or compute, or performing I/O for
-"thermo"_thermo_style.html or "dump"_dump.html output will cause data
-to be copied back to the CPU incurring a performance penalty.
-
-NOTE: To get an accurate timing breakdown between time spend in pair,
-kspace, etc., you must set the environment variable CUDA_LAUNCH_BLOCKING=1.
-However, this will reduce performance and is not recommended for production runs.
-
-[Run with the KOKKOS package by editing an input script:]
-
-Alternatively the effect of the "-sf" or "-pk" switches can be
-duplicated by adding the "package kokkos"_package.html or "suffix
-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
-switch"_Section_start.html#start_7 to enable the KOKKOS package, and
-specify its additional arguments for hardware options appropriate to
-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.
-
-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.
-
-[Using OpenMP threading and CUDA together (experimental):]
-
-With the KOKKOS package, both OpenMP multi-threading and GPUs can be used
-together in a few special cases. In the Makefile, the KOKKOS_DEVICES variable must
-include both "Cuda" and "OpenMP", as is the case for /src/MAKE/OPTIONS/Makefile.kokkos_cuda_mpi
-
-KOKKOS_DEVICES=Cuda,OpenMP :pre
-
-The suffix "/kk" is equivalent to "/kk/device", and for Kokkos CUDA,
-using the "-sf kk" in the command line gives the default CUDA version everywhere.
-However, if the "/kk/host" suffix is added to a specific style in the input
-script, the Kokkos OpenMP (CPU) version of that specific style will be used instead.
-Set the number of OpenMP threads as "t Nt" and the number of GPUs as "g Ng"
-
--k on t Nt g Ng :pre
-
-For example, the command to run with 1 GPU and 8 OpenMP threads is then:
-
-mpiexec -np 1 lmp_kokkos_cuda_openmpi -in in.lj -k on g 1 t 8 -sf kk :pre
-
-Conversely, if the "-sf kk/host" is used in the command line and then the
-"/kk" or "/kk/device" suffix is added to a specific style in your input script,
-then only that specific style will run on the GPU while everything else will
-run on the CPU in OpenMP mode. Note that the execution of the CPU and GPU
-styles will NOT overlap, except for a special case:
-
-A kspace style and/or molecular topology (bonds, angles, etc.) running on
-the host CPU can overlap with a pair style running on the GPU. First compile
-with "--default-stream per-thread" added to CCFLAGS in the Kokkos CUDA Makefile.
-Then explicitly use the "/kk/host" suffix for kspace and bonds, angles, etc.
-in the input file and the "kk" suffix (equal to "kk/device") on the command line.
-Also make sure the environment variable CUDA_LAUNCH_BLOCKING is not set to "1"
-so CPU/GPU overlap can occur.
-
-[Speed-ups to expect:]
-
-The performance of KOKKOS running in different modes is a function of
-your hardware, which KOKKOS-enable styles are used, and the problem
-size.
-
-Generally speaking, the following rules of thumb apply:
-
-When running on CPUs only, with a single thread per MPI task,
-performance of a KOKKOS style is somewhere between the standard
-(un-accelerated) styles (MPI-only mode), and those provided by the
-USER-OMP package. However the difference between all 3 is small (less
-than 20%). :ulb,l
-
-When running on CPUs only, with multiple threads per MPI task,
-performance of a KOKKOS style is a bit slower than the USER-OMP
-package. :l
-
-When running large number of atoms per GPU, KOKKOS is typically faster
-than the GPU package. :l
-
-When running on Intel hardware, KOKKOS is not as fast as
-the USER-INTEL package, which is optimized for that hardware. :l
-:ule
-
-See the "Benchmark page"_http://lammps.sandia.gov/bench.html of the
-LAMMPS web site for performance of the KOKKOS package on different
-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
-or in Makefile.machine. This is the full list of options, including
-those discussed above. Each 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
-necessary for KOKKOS_DEVICES=OpenMP for OpenMP, because OpenMP
-provides alternative methods via environment variables for binding
-threads to hardware cores. More info on binding threads to cores is
-given in "Section 5.3"_Section_accelerate.html#acc_3.
-
-KOKKOS_USE_TPLS=librt enables use of a more accurate timer mechanism
-on most Unix platforms. This library is not available on all
-platforms.
-
-KOKKOS_DEBUG is only useful when developing a Kokkos-enabled style
-within LAMMPS. KOKKOS_DEBUG=yes enables printing of run-time
-debugging information that can be useful. It also enables runtime
-bounds checking on Kokkos data structures.
-
-KOKKOS_CXX_STANDARD and KOKKOS_OPTIONS are typically not changed when building LAMMPS.
-
-KOKKOS_CUDA_OPTIONS are additional options for CUDA. The LAMMPS KOKKOS package must be compiled
-with the {enable_lambda} option when using GPUs.
-
-[Restrictions:]
-
-Currently, there are no precision options with the KOKKOS
-package. All compilation and computation is performed in double
-precision.
diff --git a/doc/src/angle_charmm.txt b/doc/src/angle_charmm.txt
index 7ff7ef8fd417c1118951adcbc0f89b4c7d08540a..8b0e298a43cccc82433505de4646f0cd254ffcb0 100644
--- a/doc/src/angle_charmm.txt
+++ b/doc/src/angle_charmm.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -51,31 +51,30 @@ internally; hence the units of K are in energy/radian^2.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[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 section for more info on packages.
+MOLECULE package. See the "Build package"_Build_package.html doc page
+for more info.
[Related commands:]
diff --git a/doc/src/angle_class2.txt b/doc/src/angle_class2.txt
index d4330139c963c12c53dc50aa2312eca93ce068e6..fa5e29582cf4762e2851ba82c69624076a09e705 100644
--- a/doc/src/angle_class2.txt
+++ b/doc/src/angle_class2.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -83,23 +83,22 @@ same value from the Ea formula.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -124,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
-section for more info on packages.
+USER-MOFFF package. See the "Build package"_Build_package.html doc
+page for more info.
[Related commands:]
diff --git a/doc/src/angle_coeff.txt b/doc/src/angle_coeff.txt
index 37298ba14591ca28fe4a45952ec5ed80551a8178..4c217bae7d3905298202c2d48592e1bb045e49ef 100644
--- a/doc/src/angle_coeff.txt
+++ b/doc/src/angle_coeff.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -65,9 +65,9 @@ the style to display the formula it computes and coefficients
specified by the associated "angle_coeff"_angle_coeff.html command.
Note that there are also additional angle styles submitted by users
-which are included in the LAMMPS distribution. The list of these with
-links to the individual styles are given in the angle section of "this
-page"_Section_commands.html#cmd_5.
+which are included in the LAMMPS distribution. The full list of all
+angle styles is on the "Commands bond"_Commands_bond.html#angle doc
+page.
"angle_style none"_angle_none.html - turn off angle interactions
"angle_style hybrid"_angle_hybrid.html - define multiple styles of angle interactions :ul
diff --git a/doc/src/angle_cosine.txt b/doc/src/angle_cosine.txt
index c0ce3c9301f735fc69fb1b239d30ddce3150c3b0..80cf8ae8f13ecee4bde4faf93ab923a153e61118 100644
--- a/doc/src/angle_cosine.txt
+++ b/doc/src/angle_cosine.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -38,31 +38,30 @@ K (energy) :ul
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[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 section for more info on packages.
+MOLECULE package. See the "Build package"_Build_package.html doc page
+for more info.
[Related commands:]
diff --git a/doc/src/angle_cosine_buck6d.txt b/doc/src/angle_cosine_buck6d.txt
index 7182ffecc849e1c581793add231af6ed1fa03d57..54709c1370f65d740f134a4e8d9bc80b8e106ca3 100644
--- a/doc/src/angle_cosine_buck6d.txt
+++ b/doc/src/angle_cosine_buck6d.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -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
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+USER-MOFFF package. See the "Build package"_Build_package.html doc
+page for more info.
[Related commands:]
diff --git a/doc/src/angle_cosine_delta.txt b/doc/src/angle_cosine_delta.txt
index 830fd6db584a67bf7c93082b971e3abb383e69d2..1532e39b31007e149d964912a1fbde27fe4fe253 100644
--- a/doc/src/angle_cosine_delta.txt
+++ b/doc/src/angle_cosine_delta.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -43,31 +43,30 @@ internally.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[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 section for more info on packages.
+MOLECULE package. See the "Build package"_Build_package.html doc page
+for more info.
[Related commands:]
diff --git a/doc/src/angle_cosine_periodic.txt b/doc/src/angle_cosine_periodic.txt
index b5c53b1b0fb5a81d8ab33d2ebbc8e2087fd26fab..039144797ff75badb1771d220720db471aebf6e6 100644
--- a/doc/src/angle_cosine_periodic.txt
+++ b/doc/src/angle_cosine_periodic.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -21,10 +21,10 @@ angle_coeff * 75.0 1 6 :pre
[Description:]
The {cosine/periodic} angle style uses the following potential, which
-is commonly used in the "DREIDING"_Section_howto.html#howto_4 force
-field, particularly for organometallic systems where {n} = 4 might be
-used for an octahedral complex and {n} = 3 might be used for a
-trigonal center:
+is commonly used in the "DREIDING"_Howto_bioFF.html force field,
+particularly for organometallic systems where {n} = 4 might be used
+for an octahedral complex and {n} = 3 might be used for a trigonal
+center:
:c,image(Eqs/angle_cosine_periodic.jpg)
@@ -51,31 +51,30 @@ geometry.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[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 section for more info on packages.
+MOLECULE package. See the "Build package"_Build_package.html doc page
+for more info.
[Related commands:]
diff --git a/doc/src/angle_cosine_shift.txt b/doc/src/angle_cosine_shift.txt
index 6ed9fe2150b7d7bdcda19e55bc7ca852ceed4a88..3a4efad218bb204e5b23773725c3221a38ca47c8 100644
--- a/doc/src/angle_cosine_shift.txt
+++ b/doc/src/angle_cosine_shift.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -41,31 +41,29 @@ theta (angle) :ul
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[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
-section for more info on packages.
+USER-MISC package.
[Related commands:]
diff --git a/doc/src/angle_cosine_shift_exp.txt b/doc/src/angle_cosine_shift_exp.txt
index 44a68c1087582357c0d2b27a98ba21184a582531..3091e838850742d8f1efdae6b1b921aa4afd6afd 100644
--- a/doc/src/angle_cosine_shift_exp.txt
+++ b/doc/src/angle_cosine_shift_exp.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -53,31 +53,30 @@ A (real number) :ul
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[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
-section for more info on packages.
+USER-MISC package. See the "Build package"_Build_package.html doc
+page for more info.
[Related commands:]
diff --git a/doc/src/angle_cosine_squared.txt b/doc/src/angle_cosine_squared.txt
index 065cdad5421bf816fd6cb600a023d265e4bbfff8..07fcb1ceb4cb731c89f1dc7eae7452fafe266c86 100644
--- a/doc/src/angle_cosine_squared.txt
+++ b/doc/src/angle_cosine_squared.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -43,31 +43,30 @@ internally.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[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 section for more info on packages.
+MOLECULE package. See the "Build package"_Build_package.html doc page
+for more info.
[Related commands:]
diff --git a/doc/src/angle_dipole.txt b/doc/src/angle_dipole.txt
index d91f260d51b5d208c8a2d3a182c6fb17fbc0545c..cdb11972ecb01dc7d6c602c8444495fef8d46dba 100644
--- a/doc/src/angle_dipole.txt
+++ b/doc/src/angle_dipole.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -71,41 +71,41 @@ gamma0 (degrees) :ul
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+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
-section for more info on packages.
+USER-MISC package. See the "Build package"_Build_package.html doc
+page for more info.
NOTE: In the "Angles" section of the data file, the atom ID 'j'
-corresponding to the dipole to restrain must come before the atom ID
-of the reference atom 'i'. A third atom ID 'k' must also be provided,
-although 'k' is just a 'dummy' atom which can be any atom; it may be
-useful to choose a convention (e.g., 'k'='i') and adhere to it. For
-example, if ID=1 for the dipolar atom to restrain, and ID=2 for the
-reference atom, the corresponding line in the "Angles" section of the
-data file would read: X X 1 2 2
+defining the direction of the dipole vector to restrain must come
+before the atom ID of the reference atom 'i'. A third atom ID 'k' must
+also be provided to comply with the requirement of a valid angle
+definition. This atom ID k should be chosen to be that of an atom
+bonded to atom 'i' to avoid errors with "lost angle atoms" when running
+in parallel. Since the LAMMPS code checks for valid angle definitions,
+cannot use the same atom ID of either 'i' or 'j' (this was allowed
+and recommended with older LAMMPS versions).
The "newton" command for intramolecular interactions must be "on"
-(which is the default).
+(which is the default except when using some accelerator packages).
This angle style should not be used with SHAKE.
diff --git a/doc/src/angle_fourier.txt b/doc/src/angle_fourier.txt
index da39e7cf326b43afce171e0005c1ef93cde2d5c8..7dc9975793353787e56cd677c25459744c0f2d87 100644
--- a/doc/src/angle_fourier.txt
+++ b/doc/src/angle_fourier.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -39,31 +39,30 @@ C2 (real) :ul
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[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
-section for more info on packages.
+USER_MISC package. See the "Build package"_Build_package.html doc
+page for more info.
[Related commands:]
diff --git a/doc/src/angle_fourier_simple.txt b/doc/src/angle_fourier_simple.txt
index 5adda6cb32f85a00310f5dc62ada7838e84d5715..ae5d30835387a071bf801c7f30af3b0f2cad6ce6 100644
--- a/doc/src/angle_fourier_simple.txt
+++ b/doc/src/angle_fourier_simple.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -38,31 +38,30 @@ n (real) :ul
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[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
-section for more info on packages.
+USER_MISC package. See the "Build package"_Build_package.html doc
+page for more info.
[Related commands:]
diff --git a/doc/src/angle_harmonic.txt b/doc/src/angle_harmonic.txt
index 4c74763964832d98cfcae9443866e2db4293ca64..b632f684786bc8c465bf350b270cd91388b4ef66 100644
--- a/doc/src/angle_harmonic.txt
+++ b/doc/src/angle_harmonic.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -45,31 +45,30 @@ internally; hence the units of K are in energy/radian^2.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[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
-section for more info on packages.
+MOLECULE package. See the "Build package"_Build_package.html doc
+page for more info.
[Related commands:]
diff --git a/doc/src/angle_hybrid.txt b/doc/src/angle_hybrid.txt
index bdd3707ccb80130284817d86a3eec53a698c2a2a..0046c161be6a30ea500e8b1a26b61b3145166f6a 100644
--- a/doc/src/angle_hybrid.txt
+++ b/doc/src/angle_hybrid.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -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
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+MOLECULE package. See the "Build package"_Build_package.html doc page
+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
diff --git a/doc/src/angle_none.txt b/doc/src/angle_none.txt
index a4a9b07c78e0bf7616ffe4d0ae0dc4ee8c4c9061..1eca5cbbeca786991139f7af6a44547f86d9d821 100644
--- a/doc/src/angle_none.txt
+++ b/doc/src/angle_none.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/angle_quartic.txt b/doc/src/angle_quartic.txt
index f7640bdfbc0f75af1170cb551220d846df1529a0..b20a06eb8d681fd0f7987e9f686e4e247699ffa0 100644
--- a/doc/src/angle_quartic.txt
+++ b/doc/src/angle_quartic.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -45,31 +45,30 @@ internally; hence the units of K are in energy/radian^2.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[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
-section for more info on packages.
+USER_MISC package. See the "Build package"_Build_package.html doc
+page for more info.
[Related commands:]
diff --git a/doc/src/angle_sdk.txt b/doc/src/angle_sdk.txt
index 0cc535e543f878bba02b38b9a5fa18e65da0aea2..4de1a6755d9eebf47045996fdad8b711367d9f6d 100644
--- a/doc/src/angle_sdk.txt
+++ b/doc/src/angle_sdk.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -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
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+USER-CGSDK package. See the "Build package"_Build_package.html doc
+page for more info.
[Related commands:]
diff --git a/doc/src/angle_style.txt b/doc/src/angle_style.txt
index f687e9286c40ac37a84566a5ab904c65fb3d30bf..756cfc0c6038d3d3a0e9dd7a12b229e2f8f11c09 100644
--- a/doc/src/angle_style.txt
+++ b/doc/src/angle_style.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -58,9 +58,9 @@ the style to display the formula it computes and coefficients
specified by the associated "angle_coeff"_angle_coeff.html command.
Note that there are also additional angle styles submitted by users
-which are included in the LAMMPS distribution. The list of these with
-links to the individual styles are given in the angle section of "this
-page"_Section_commands.html#cmd_5.
+which are included in the LAMMPS distribution. The full list of all
+angle styles are is on the "Commands bond"_Commands_bond.html#angle
+doc page.
"angle_style none"_angle_none.html - turn off angle interactions
"angle_style zero"_angle_zero.html - topology but no interactions
@@ -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
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
-The doc pages for individual bond potentials tell if it is part of a
-package.
+enabled if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info. The doc pages for
+individual bond potentials tell if it is part of a package.
[Related commands:]
diff --git a/doc/src/angle_table.txt b/doc/src/angle_table.txt
index bd6e167bd8f4dfccc84412c6597e1d2568a1daec..6b9187e512a355649ef7fffdaa87c3747d9a3010 100644
--- a/doc/src/angle_table.txt
+++ b/doc/src/angle_table.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -124,31 +124,30 @@ one that matches the specified keyword.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[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 section for more info on packages.
+MOLECULE package. See the "Build package"_Build_package.html doc page
+for more info.
[Related commands:]
diff --git a/doc/src/angle_zero.txt b/doc/src/angle_zero.txt
index b8e8ebf953c6b6ba40a583bef0508ab9992f3a6d..c6c1958ec8f35f7d1335b5a9cafaf36b96049c9a 100644
--- a/doc/src/angle_zero.txt
+++ b/doc/src/angle_zero.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/atom_modify.txt b/doc/src/atom_modify.txt
index 1dc0fa6bfb6410df5eaef9abf35cebb3a66749fd..4b4ac3862d102b54ed08cb0b2d8b63f84ec32f89 100644
--- a/doc/src/atom_modify.txt
+++ b/doc/src/atom_modify.txt
@@ -3,7 +3,7 @@ Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -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
-of the manual. If atom IDs are not used, they must be specified as 0
-for all atoms, e.g. in a data or restart file.
+switch. This is described on the "Build_settings"_Build_settings.html
+doc page. If atom IDs are not used, they must be specified as 0 for
+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
diff --git a/doc/src/atom_style.txt b/doc/src/atom_style.txt
index 5421e467aaf968be0c9d172a06702f5020059fde..db2e285dc48fefb79709933d1230ed4a750f084d 100644
--- a/doc/src/atom_style.txt
+++ b/doc/src/atom_style.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -20,7 +20,7 @@ style = {angle} or {atomic} or {body} or {bond} or {charge} or {dipole} or \
{body} args = bstyle bstyle-args
bstyle = style of body particles
bstyle-args = additional arguments specific to the bstyle
- see the "body"_body.html doc page for details
+ see the "Howto body"_Howto_body.html doc page for details
{tdpd} arg = Nspecies
Nspecies = # of chemical species
{template} arg = template-ID
@@ -106,9 +106,9 @@ output the custom values.
All of the above styles define point particles, except the {sphere},
{ellipsoid}, {electron}, {peri}, {wavepacket}, {line}, {tri}, and
-{body} styles, which define finite-size particles. See "Section
-6.14"_Section_howto.html#howto_14 for an overview of using finite-size
-particle models with LAMMPS.
+{body} styles, which define finite-size particles. See the "Howto
+spherical"_Howto_spherical.html doc page for an overview of using
+finite-size particle models with LAMMPS.
All of the point-particle styles assign mass to particles on a
per-type basis, using the "mass"_mass.html command, The finite-size
@@ -224,15 +224,16 @@ the {bstyle} argument. Body particles can represent complex entities,
such as surface meshes of discrete points, collections of
sub-particles, deformable objects, etc.
-The "body"_body.html doc page describes the body styles LAMMPS
-currently supports, and provides more details as to the kind of body
-particles they represent. For all styles, each body particle stores
-moments of inertia and a quaternion 4-vector, so that its orientation
-and position can be time integrated due to forces and torques.
+The "Howto body"_Howto_body.html doc page describes the body styles
+LAMMPS currently supports, and provides more details as to the kind of
+body particles they represent. For all styles, each body particle
+stores moments of inertia and a quaternion 4-vector, so that its
+orientation and position can be time integrated due to forces and
+torques.
Note that there may be additional arguments required along with the
{bstyle} specification, in the atom_style body command. These
-arguments are described in the "body"_body.html doc page.
+arguments are described on the "Howto body"_Howto_body.html doc page.
:line
@@ -255,32 +256,32 @@ with another molecular style that stores bond,angle,etc info on a
per-atom basis.
LAMMPS can be extended with new atom styles as well as new body
-styles; see "this section"_Section_modify.html.
+styles; see the "Modify"_Modify.html doc page.
:line
Styles with a {kk} suffix are functionally the same as the
corresponding style without the suffix. They have been optimized to
-run faster, depending on your available hardware, as discussed in
-"Section 5"_Section_accelerate.html of the manual. The
-accelerated styles take the same arguments and should produce the same
-results, except for round-off and precision issues.
+run faster, depending on your available hardware, as discussed in on
+the "Speed packages"_Speed_packages.html doc page. The accelerated
+styles take the same arguments and should produce the same results,
+except for round-off and precision issues.
Note that other acceleration packages in LAMMPS, specifically the GPU,
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
-LAMMPS"_Section_start.html#start_3 section for more info.
+enabled if LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
[Restrictions:]
@@ -288,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
-LAMMPS"_Section_start.html#start_3 section for more info.
+with a specific package, as listed below. See the "Build
+package"_Build_package.html doc page for more info.
The {angle}, {bond}, {full}, {molecular}, and {template} styles are
part of the MOLECULE package.
diff --git a/doc/src/balance.txt b/doc/src/balance.txt
index da6f59900d69fb784ee8cdf91cc3bef60921aaa8..26e146d89b3222fabdfdabe9daf4e6720d5f6750 100644
--- a/doc/src/balance.txt
+++ b/doc/src/balance.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -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},
-{Bond}, {Kspace}, and {Neigh}. The time spent in those portions of
-the timestep are measured for each MPI rank, summed, then divided by
-the number of particles owned by that processor. I.e. the weight is
-an effective CPU time/particle averaged over the particles on that
+breakdown"_Run_output.html, namely, for sections {Pair}, {Bond},
+{Kspace}, and {Neigh}. The time spent in those portions of the
+timestep are measured for each MPI rank, summed, then divided by the
+number of particles owned by that processor. I.e. the weight is an
+effective CPU time/particle averaged over the particles on that
processor.
The {factor} setting is applied as an overall scale factor to the
diff --git a/doc/src/bond_class2.txt b/doc/src/bond_class2.txt
index 9687a6316805acb77298f74eeb84952e8f4243fe..4390e3613c001741ecc9a2203e6c3899402a8356 100644
--- a/doc/src/bond_class2.txt
+++ b/doc/src/bond_class2.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -44,31 +44,30 @@ K4 (energy/distance^4) :ul
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[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
-for more info on packages.
+package. See the "Build package"_Build_package.html doc page for more
+info.
[Related commands:]
diff --git a/doc/src/bond_coeff.txt b/doc/src/bond_coeff.txt
index d93c0b223b84a0da9d6f171d9e222847d905ee69..7485fa3d8d1da5da832cc832f69f7ffd6d593696 100644
--- a/doc/src/bond_coeff.txt
+++ b/doc/src/bond_coeff.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -61,9 +61,8 @@ the style to display the formula it computes and coefficients
specified by the associated "bond_coeff"_bond_coeff.html command.
Note that here are also additional bond styles submitted by users
-which are included in the LAMMPS distribution. The list of these with
-links to the individual styles are given in the bond section of "this
-page"_Section_commands.html#cmd_5.
+which are included in the LAMMPS distribution. The full list of all
+bond styles is on the "Commands bond"_Commands_bond.html doc page.
"bond_style none"_bond_none.html - turn off bonded interactions
"bond_style hybrid"_bond_hybrid.html - define multiple styles of bond interactions :ul
diff --git a/doc/src/bond_fene.txt b/doc/src/bond_fene.txt
index 9050c3bf5ccecdd8701f414ef0caea5e39a19c2c..9ec4017d000a865108d08a209226283918b57c17 100644
--- a/doc/src/bond_fene.txt
+++ b/doc/src/bond_fene.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -47,31 +47,30 @@ sigma (distance) :ul
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
-This bond style can only be used if LAMMPS was built with the
-MOLECULE package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+This bond style can only be used if LAMMPS was built with the MOLECULE
+package. See the "Build package"_Build_package.html doc page for more
+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
diff --git a/doc/src/bond_fene_expand.txt b/doc/src/bond_fene_expand.txt
index ff687444a97378373514442bda71a614b74bd821..4d7d2d54382e3afbfa74a4f25924052ed544b16a 100644
--- a/doc/src/bond_fene_expand.txt
+++ b/doc/src/bond_fene_expand.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -50,31 +50,30 @@ delta (distance) :ul
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
-This bond style can only be used if LAMMPS was built with the
-MOLECULE package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+This bond style can only be used if LAMMPS was built with the MOLECULE
+package. See the "Build package"_Build_package.html doc page for more
+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
diff --git a/doc/src/bond_gromos.txt b/doc/src/bond_gromos.txt
index cc3ff75878f36dd27f2d85b61ae3bfb522f52583..e039e6c4117ccbdabc132f24b723d4e5f2c8d1e2 100644
--- a/doc/src/bond_gromos.txt
+++ b/doc/src/bond_gromos.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -40,31 +40,30 @@ r0 (distance) :ul
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
-This bond style can only be used if LAMMPS was built with the
-MOLECULE package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+This bond style can only be used if LAMMPS was built with the MOLECULE
+package. See the "Build package"_Build_package.html doc page for more
+info.
[Related commands:]
diff --git a/doc/src/bond_harmonic.txt b/doc/src/bond_harmonic.txt
index c18a7e0fd4d35a337a832255b64b4daf8f07392f..3afdf4ceba020fdd4f5e31d3a075da2b79b8712e 100644
--- a/doc/src/bond_harmonic.txt
+++ b/doc/src/bond_harmonic.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -42,31 +42,30 @@ r0 (distance) :ul
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
-This bond style can only be used if LAMMPS was built with the
-MOLECULE package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+This bond style can only be used if LAMMPS was built with the MOLECULE
+package. See the "Build package"_Build_package.html doc page for more
+info.
[Related commands:]
diff --git a/doc/src/bond_harmonic_shift.txt b/doc/src/bond_harmonic_shift.txt
index bf3b3c115adeb59fcbd0a7a51e36a4612e6c020d..23d3dcb5d509337005b973fd7610e59ab0ae81a1 100644
--- a/doc/src/bond_harmonic_shift.txt
+++ b/doc/src/bond_harmonic_shift.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -43,31 +43,30 @@ rc (distance) :ul
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This bond style can only be used if LAMMPS was built with the
-USER-MISC package. See the "Making LAMMPS"_Section_start.html#start_3
-section for more info on packages.
+USER-MISC package. See the "Build package"_Build_package.html doc
+page for more info.
[Related commands:]
diff --git a/doc/src/bond_harmonic_shift_cut.txt b/doc/src/bond_harmonic_shift_cut.txt
index 1918ce00b6210468a119d332762ed85f8f2bad0e..13ccb5843b44b132789305b9779bccac6d08ed72 100644
--- a/doc/src/bond_harmonic_shift_cut.txt
+++ b/doc/src/bond_harmonic_shift_cut.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -43,31 +43,30 @@ rc (distance) :ul
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This bond style can only be used if LAMMPS was built with the
-USER-MISC package. See the "Making LAMMPS"_Section_start.html#start_3
-section for more info on packages.
+USER-MISC package. See the "Build package"_Build_package.html doc
+page for more info.
[Related commands:]
diff --git a/doc/src/bond_hybrid.txt b/doc/src/bond_hybrid.txt
index 400c3e0be4c9e1b7fb1fd98936208ad19f384896..0996f72ce3a4cbbf8f25869363f2b5072d790996 100644
--- a/doc/src/bond_hybrid.txt
+++ b/doc/src/bond_hybrid.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -58,9 +58,9 @@ bond types.
[Restrictions:]
-This bond style can only be used if LAMMPS was built with the
-MOLECULE package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+This bond style can only be used if LAMMPS was built with the MOLECULE
+package. See the "Build package"_Build_package.html doc page for more
+info.
Unlike other bond styles, the hybrid bond style does not store bond
coefficient info for individual sub-styles in a "binary restart
diff --git a/doc/src/bond_morse.txt b/doc/src/bond_morse.txt
index 4f6a32e341b57a7977e4aaabc83d8dd1a1282137..60fd16e17a0894ef131bc9794354d645c067ac33 100644
--- a/doc/src/bond_morse.txt
+++ b/doc/src/bond_morse.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -41,31 +41,30 @@ r0 (distance) :ul
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
-This bond style can only be used if LAMMPS was built with the
-MOLECULE package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+This bond style can only be used if LAMMPS was built with the MOLECULE
+package. See the "Build package"_Build_package.html doc page for more
+info.
[Related commands:]
diff --git a/doc/src/bond_none.txt b/doc/src/bond_none.txt
index 8cb262a50f939617011853d41fe416f1a6e3160a..cace1919e13ff668c51418063f6a2d4a30dbefbc 100644
--- a/doc/src/bond_none.txt
+++ b/doc/src/bond_none.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/bond_nonlinear.txt b/doc/src/bond_nonlinear.txt
index 434af625061a45679e9f01630c3999743d6d77ee..af51383213998faa6427bcb8b078b5c400127b6b 100644
--- a/doc/src/bond_nonlinear.txt
+++ b/doc/src/bond_nonlinear.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -41,31 +41,30 @@ lamda (distance) :ul
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
-This bond style can only be used if LAMMPS was built with the
-MOLECULE package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+This bond style can only be used if LAMMPS was built with the MOLECULE
+package. See the "Build package"_Build_package.html doc page for more
+info.
[Related commands:]
diff --git a/doc/src/bond_oxdna.txt b/doc/src/bond_oxdna.txt
index 927fea64031d5422615d1251b9332e4e66120d3a..1944f7027a6573de91d6b490482931af332e0ed5 100644
--- a/doc/src/bond_oxdna.txt
+++ b/doc/src/bond_oxdna.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -62,8 +62,8 @@ The preprint version of the article can be found "here"_PDF/USER-CGDNA.pdf.
[Restrictions:]
This bond style can only be used if LAMMPS was built with the
-USER-CGDNA package and the MOLECULE and ASPHERE package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+USER-CGDNA package and the MOLECULE and ASPHERE package. See the
+"Build package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/bond_quartic.txt b/doc/src/bond_quartic.txt
index 4dc7ad4a3693e8d0ed492514fbaaf5f15deaecd0..b7b1ee4ce61aac52c01b80a98acb9cd889e359bd 100644
--- a/doc/src/bond_quartic.txt
+++ b/doc/src/bond_quartic.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -76,31 +76,30 @@ delete_bonds all bond 0 remove :pre
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
-This bond style can only be used if LAMMPS was built with the
-MOLECULE package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+This bond style can only be used if LAMMPS was built with the MOLECULE
+package. See the "Build package"_Build_package.html doc page for more
+info.
The {quartic} style requires that "special_bonds"_special_bonds.html
parameters be set to 1,1,1. Three- and four-body interactions (angle,
diff --git a/doc/src/bond_style.txt b/doc/src/bond_style.txt
index 3bd8afda196a642c883f7321d7998ed70f98f09c..22fae3e34698a7da47dd8d171fd2d996a682a01f 100644
--- a/doc/src/bond_style.txt
+++ b/doc/src/bond_style.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -66,9 +66,8 @@ the style to display the formula it computes and coefficients
specified by the associated "bond_coeff"_bond_coeff.html command.
Note that there are also additional bond styles submitted by users
-which are included in the LAMMPS distribution. The list of these with
-links to the individual styles are given in the bond section of "this
-page"_Section_commands.html#cmd_5.
+which are included in the LAMMPS distribution. The full list of all
+bond styles is on the "Commands bond"_Commands_bond.html doc page.
"bond_style none"_bond_none.html - turn off bonded interactions
"bond_style zero"_bond_zero.html - topology but no interactions
@@ -91,10 +90,9 @@ Bond styles can only be set for atom styles that allow bonds to be
defined.
Most bond styles are part of the MOLECULE package. They are only
-enabled if LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
-The doc pages for individual bond potentials tell if it is part of a
-package.
+enabled if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info. The doc pages for
+individual bond potentials tell if it is part of a package.
[Related commands:]
diff --git a/doc/src/bond_table.txt b/doc/src/bond_table.txt
index 906d3e5d7639eb08e211554b2817195dd383bcf1..fbf6eb5815cc48661804af29a4e0e49543c75e70 100644
--- a/doc/src/bond_table.txt
+++ b/doc/src/bond_table.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -121,31 +121,30 @@ one that matches the specified keyword.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
-This bond style can only be used if LAMMPS was built with the
-MOLECULE package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+This bond style can only be used if LAMMPS was built with the MOLECULE
+package. See the "Build package"_Build_package.html doc page for more
+info.
[Related commands:]
diff --git a/doc/src/bond_write.txt b/doc/src/bond_write.txt
index 4797d06cb1b5a164a47805840ce38824ea78b6ce..711bd2c2968b7119d80539027feb9deefe991a16 100644
--- a/doc/src/bond_write.txt
+++ b/doc/src/bond_write.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/bond_zero.txt b/doc/src/bond_zero.txt
index b599f291b4cc5fef8b4a77beb893c3b99026d893..554f26e7f00d5eeee62343792b1b3b351ec9f92f 100644
--- a/doc/src/bond_zero.txt
+++ b/doc/src/bond_zero.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/boundary.txt b/doc/src/boundary.txt
index ce638f11b3ffbe871d398762df4397114f147d76..f9685433b2c4ca35d6f5ebbdaf29b4071514a67f 100644
--- a/doc/src/boundary.txt
+++ b/doc/src/boundary.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -82,9 +82,9 @@ and xhi faces of the box are planes tilting in the +y direction as y
increases. These tilted planes are shrink-wrapped around the atoms to
determine the x extent of the box.
-See "Section 6.12"_Section_howto.html#howto_12 of the doc pages
-for a geometric description of triclinic boxes, as defined by LAMMPS,
-and how to transform these parameters to and from other commonly used
+See the "Howto triclinic"_Howto_triclinic.html doc page for a
+geometric description of triclinic boxes, as defined by LAMMPS, and
+how to transform these parameters to and from other commonly used
triclinic representations.
[Restrictions:]
diff --git a/doc/src/box.txt b/doc/src/box.txt
index a6207ae9937e569277a9d5a9b001493297f991dc..38c874fb78bc68b93ddaf666c6f97c0c147794e4 100644
--- a/doc/src/box.txt
+++ b/doc/src/box.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -30,9 +30,9 @@ For triclinic (non-orthogonal) simulation boxes, the {tilt} keyword
allows simulation domains to be created with arbitrary tilt factors,
e.g. via the "create_box"_create_box.html or
"read_data"_read_data.html commands. Tilt factors determine how
-skewed the triclinic box is; see "this
-section"_Section_howto.html#howto_12 of the manual for a discussion of
-triclinic boxes in LAMMPS.
+skewed the triclinic box is; see the "Howto
+triclinic"_Howto_triclinic.html doc page for a discussion of triclinic
+boxes in LAMMPS.
LAMMPS normally requires that no tilt factor can skew the box more
than half the distance of the parallel box length, which is the 1st
diff --git a/doc/src/change_box.txt b/doc/src/change_box.txt
index 2c7a890d4cfb406abf018fb4787917f797fcc963..adc5d6bdcb42ee3c8b814ad21480e2ef9496e8d5 100644
--- a/doc/src/change_box.txt
+++ b/doc/src/change_box.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -75,9 +75,9 @@ The "create_box"_create_box.html, "read data"_read_data.html, and
simulation box is orthogonal or triclinic and their doc pages explain
the meaning of the xy,xz,yz tilt factors.
-See "Section 6.12"_Section_howto.html#howto_12 of the doc pages
-for a geometric description of triclinic boxes, as defined by LAMMPS,
-and how to transform these parameters to and from other commonly used
+See the "Howto triclinic"_Howto_triclinic.html doc page for a
+geometric description of triclinic boxes, as defined by LAMMPS, and
+how to transform these parameters to and from other commonly used
triclinic representations.
The keywords used in this command are applied sequentially to the
@@ -140,8 +140,8 @@ transformation in the sequence. If skew is exceeded before the final
transformation this can be avoided by changing the order of the
sequence, or breaking the transformation into two or more smaller
transformations. For more information on the allowed limits for box
-skew see the discussion on triclinic boxes on "this
-page"_Section_howto.html#howto_12.
+skew see the discussion on triclinic boxes on "Howto
+triclinic"_Howto_triclinic.html doc page.
:line
@@ -258,9 +258,7 @@ command.
:line
The {ortho} and {triclinic} keywords convert the simulation box to be
-orthogonal or triclinic (non-orthogonal). See "this
-section"_Section_howto#howto_13 for a discussion of how non-orthogonal
-boxes are represented in LAMMPS.
+orthogonal or triclinic (non-orthogonal).
The simulation box is defined as either orthogonal or triclinic when
it is created via the "create_box"_create_box.html,
@@ -271,8 +269,8 @@ These keywords allow you to toggle the existing simulation box from
orthogonal to triclinic and vice versa. For example, an initial
equilibration simulation can be run in an orthogonal box, the box can
be toggled to triclinic, and then a "non-equilibrium MD (NEMD)
-simulation"_Section_howto.html#howto_13 can be run with deformation
-via the "fix deform"_fix_deform.html command.
+simulation"_Howto_nemd.html can be run with deformation via the "fix
+deform"_fix_deform.html command.
If the simulation box is currently triclinic and has non-zero tilt in
xy, yz, or xz, then it cannot be converted to an orthogonal box.
diff --git a/doc/src/clear.txt b/doc/src/clear.txt
index 7ac4da5c8d93228e974c48d20b746a3abef2153c..c4ad4c4030ca601cc2c1fa9fde44ce71c21946d2 100644
--- a/doc/src/clear.txt
+++ b/doc/src/clear.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/comm_modify.txt b/doc/src/comm_modify.txt
index 3e8d0eca4ffe2d8c55e0998dd26384619fc712d6..489278523bde3a605053c565405732c55c905825 100644
--- a/doc/src/comm_modify.txt
+++ b/doc/src/comm_modify.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/comm_style.txt b/doc/src/comm_style.txt
index 8248d654d32265924b3e25734fb19d40d2c3b0f5..39eb1d4ef5aece3e2d77f2b6bbd8d16940700ccc 100644
--- a/doc/src/comm_style.txt
+++ b/doc/src/comm_style.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/commands.txt b/doc/src/commands_list.txt
similarity index 100%
rename from doc/src/commands.txt
rename to doc/src/commands_list.txt
diff --git a/doc/src/compute.txt b/doc/src/compute.txt
index c06735d28e3dbe0091b3426eebbf264f1e147ad0..7d9e443e7da7455de147ca1531daab58887e65f8 100644
--- a/doc/src/compute.txt
+++ b/doc/src/compute.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -33,7 +33,7 @@ information about a previous state of the system. Defining a compute
does not perform a computation. Instead computes are invoked by other
LAMMPS commands as needed, e.g. to calculate a temperature needed for
a thermostat fix or to generate thermodynamic or dump file output.
-See this "howto section"_Section_howto.html#howto_15 for a summary of
+See the "Howto output"_Howto_output.html doc page for a summary of
various LAMMPS output options, many of which involve computes.
The ID of a compute can only contain alphanumeric characters and
@@ -153,21 +153,27 @@ via the "compute_modify"_compute_modify.html command.
Computes can be deleted with the "uncompute"_uncompute.html command.
-Code for new computes can be added to LAMMPS (see "this
-section"_Section_modify.html of the manual) and the results of their
+Code for new computes can be added to LAMMPS; see the
+"Modify"_Modify.html doc page for details. The results of their
calculations accessed in the various ways described above.
:line
Each compute style has its own doc page which describes its arguments
and what it does. Here is an alphabetic list of compute styles
-available in LAMMPS. They are also given in more compact form in the
-Compute section of "this page"_Section_commands.html#cmd_5.
+available in LAMMPS. They are also listed in more compact form on the
+"Commands compute"_Commands_compute.html doc page.
There are also additional compute styles (not listed here) submitted
-by users which are included in the LAMMPS distribution. The list of
-these with links to the individual styles are given in the compute
-section of "this page"_Section_commands.html#cmd_5.
+by users which are included in the LAMMPS distribution. The full list
+of all compute styles is on the "Commands
+compute"_Commands_compute.html doc page.
+
+There are also additional accelerated compute styles included in the
+LAMMPS distribution for faster performance on CPUs, GPUs, and KNLs.
+The individual style names on the "Commands
+compute"_Commands_compute.html doc page are followed by one or more of
+(g,i,k,o,t) to indicate which accerlerated styles exist.
"aggregate/atom"_compute_cluster_atom.html - aggregate ID for each atom
"angle/local"_compute_bond_local.html - theta and energy of each angle
@@ -243,16 +249,6 @@ section of "this page"_Section_commands.html#cmd_5.
"vcm/chunk"_compute_vcm_chunk.html - velocity of center-of-mass for each chunk
"voronoi/atom"_compute_voronoi_atom.html - Voronoi volume and neighbors for each atom :ul
-There are also additional compute styles submitted by users which are
-included in the LAMMPS distribution. The list of these with links to
-the individual styles are given in the compute section of "this
-page"_Section_commands.html#cmd_5.
-
-There are also additional accelerated compute styles included in the
-LAMMPS distribution for faster performance on CPUs and GPUs. The list
-of these with links to the individual styles are given in the pair
-section of "this page"_Section_commands.html#cmd_5.
-
[Restrictions:] none
[Related commands:]
diff --git a/doc/src/compute_ackland_atom.txt b/doc/src/compute_ackland_atom.txt
index 3fd838d95775ae9e97f7ad8da792112b9890d80d..cda4a36b34d01c83a4977440adc94e747ea090df 100644
--- a/doc/src/compute_ackland_atom.txt
+++ b/doc/src/compute_ackland_atom.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -60,14 +60,14 @@ which computes this quantity.-
This compute calculates a per-atom vector, which can be accessed by
any command that uses per-atom values from a compute as input. See
-"Section 6.15"_Section_howto.html#howto_15 for an overview of
+the "Howto output"_Howto_output.html doc page for an overview of
LAMMPS output options.
[Restrictions:]
This compute is part of the USER-MISC package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
The per-atom vector values will be unitless since they are the
integers defined above.
diff --git a/doc/src/compute_angle.txt b/doc/src/compute_angle.txt
index 2c363ce8f63fcb4f181814399b47b1cf5f558435..64eb2f4bb1262828736bb342d3f9fe145f6c4f7b 100644
--- a/doc/src/compute_angle.txt
+++ b/doc/src/compute_angle.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -37,8 +37,8 @@ This compute calculates a global vector of length N where N is the
number of sub_styles defined by the "angle_style
hybrid"_angle_style.html command, which can be accessed by indices
1-N. These values can be used by any command that uses global scalar
-or vector values from a compute as input. See "this
-section"_Section_howto.html#howto_15 for an overview of LAMMPS output
+or vector values from a compute as input. See the "Howto
+output"_Howto_output.html doc page for an overview of LAMMPS output
options.
The vector values are "extensive" and will be in energy
diff --git a/doc/src/compute_angle_local.txt b/doc/src/compute_angle_local.txt
index 0ee1d32d7dcf8e3611fb98a5b8f70774d8cb3334..3a321965ef71135104bdf12f8dc13111dd515564 100644
--- a/doc/src/compute_angle_local.txt
+++ b/doc/src/compute_angle_local.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -70,8 +70,8 @@ array is the number of angles. If a single keyword is specified, a
local vector is produced. If two or more keywords are specified, a
local array is produced where the number of columns = the number of
keywords. The vector or array can be accessed by any command that
-uses local values from a compute as input. See "this
-section"_Section_howto.html#howto_15 for an overview of LAMMPS output
+uses local values from a compute as input. See the "Howto
+output"_Howto_output.html doc page for an overview of LAMMPS output
options.
The output for {theta} will be in degrees. The output for {eng} will
diff --git a/doc/src/compute_angmom_chunk.txt b/doc/src/compute_angmom_chunk.txt
index 813da15eeadeed76c43a5f933f52e272d9653cbc..7e49ff302480a753cc5aacefe28b609931d56b06 100644
--- a/doc/src/compute_angmom_chunk.txt
+++ b/doc/src/compute_angmom_chunk.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -30,10 +30,9 @@ chunk/atom"_compute_chunk_atom.html command, which assigns each atom
to a single chunk (or no chunk). The ID for this command is specified
as chunkID. For example, a single chunk could be the atoms in a
molecule or atoms in a spatial bin. See the "compute
-chunk/atom"_compute_chunk_atom.html doc page and "Section
-6.23"_Section_howto.html#howto_23 for details of how chunks can be
-defined and examples of how they can be used to measure properties of
-a system.
+chunk/atom"_compute_chunk_atom.html and "Howto chunk"_Howto_chunk.html
+doc pages for details of how chunks can be defined and examples of how
+they can be used to measure properties of a system.
This compute calculates the 3 components of the angular momentum
vector for each chunk, due to the velocity/momentum of the individual
@@ -73,8 +72,8 @@ number of chunks {Nchunk} as calculated by the specified "compute
chunk/atom"_compute_chunk_atom.html command. The number of columns =
3 for the 3 xyz components of the angular momentum for each chunk.
These values can be accessed by any command that uses global array
-values from a compute as input. See "Section
-6.15"_Section_howto.html#howto_15 for an overview of LAMMPS output
+values from a compute as input. See the "Howto
+output"_Howto_output.html doc page for an overview of LAMMPS output
options.
The array values are "intensive". The array values will be in
diff --git a/doc/src/compute_basal_atom.txt b/doc/src/compute_basal_atom.txt
index b59a3fd4c878789dfd13c3e60a40ef0fb682ec96..5c28b8e378d6c3a0f6b3cc4d99b3f8b66b0572c7 100644
--- a/doc/src/compute_basal_atom.txt
+++ b/doc/src/compute_basal_atom.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -46,9 +46,8 @@ in examples/USER/misc/basal.
This compute calculates a per-atom array with 3 columns, which can be
accessed by indices 1-3 by any command that uses per-atom values from
-a compute as input. See "Section
-6.15"_Section_howto.html#howto_15 for an overview of LAMMPS output
-options.
+a compute as input. See the "Howto output"_Howto_output.html doc page
+for an overview of LAMMPS output options.
The per-atom vector values are unitless since the 3 columns represent
components of a unit vector.
@@ -56,8 +55,8 @@ components of a unit vector.
[Restrictions:]
This compute is part of the USER-MISC package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
The output of this compute will be meaningless unless the atoms are on
(or near) hcp lattice sites, since the calculation assumes a
diff --git a/doc/src/compute_body_local.txt b/doc/src/compute_body_local.txt
index 12ce21885356da3541d1d3f2c9a0fcf23f35f198..8ac3f00c559345d1de1547542296a9f7b0469c00 100644
--- a/doc/src/compute_body_local.txt
+++ b/doc/src/compute_body_local.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -32,9 +32,8 @@ Define a computation that calculates properties of individual body
sub-particles. The number of datums generated, aggregated across all
processors, equals the number of body sub-particles plus the number of
non-body particles in the system, modified by the group parameter as
-explained below. See "Section 6.14"_Section_howto.html#howto_14
-of the manual and the "body"_body.html doc page for more details on
-using body particles.
+explained below. See the "Howto body"_Howto_body.html doc page for
+more details on using body particles.
The local data stored by this command is generated by looping over all
the atoms. An atom will only be included if it is in the group. If
@@ -58,8 +57,8 @@ group.
For a body particle, the {integer} keywords refer to fields calculated
by the body style for each sub-particle. The body style, as specified
by the "atom_style body"_atom_style.html, determines how many fields
-exist and what they are. See the "body"_body.html doc page for
-details of the different styles.
+exist and what they are. See the "Howto_body"_Howto_body.html doc
+page for details of the different styles.
Here is an example of how to output body information using the "dump
local"_dump.html command with this compute. If fields 1,2,3 for the
@@ -78,9 +77,9 @@ array is the number of datums as described above. If a single keyword
is specified, a local vector is produced. If two or more keywords are
specified, a local array is produced where the number of columns = the
number of keywords. The vector or array can be accessed by any
-command that uses local values from a compute as input. See "this
-section"_Section_howto.html#howto_15 for an overview of LAMMPS output
-options.
+command that uses local values from a compute as input. See the
+"Howto output"_Howto_output.html doc page for an overview of LAMMPS
+output options.
The "units"_units.html for output values depend on the body style.
diff --git a/doc/src/compute_bond.txt b/doc/src/compute_bond.txt
index 6c4384b0806c7436f9384fe9d043c3fd9cb33c51..a87c510538f6035bf90b75d61cbd886a78c19208 100644
--- a/doc/src/compute_bond.txt
+++ b/doc/src/compute_bond.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -37,8 +37,8 @@ This compute calculates a global vector of length N where N is the
number of sub_styles defined by the "bond_style
hybrid"_bond_style.html command, which can be accessed by indices 1-N.
These values can be used by any command that uses global scalar or
-vector values from a compute as input. See "this
-section"_Section_howto.html#howto_15 for an overview of LAMMPS output
+vector values from a compute as input. See the "Howto
+output"_Howto_output.html doc page for an overview of LAMMPS output
options.
The vector values are "extensive" and will be in energy
diff --git a/doc/src/compute_bond_local.txt b/doc/src/compute_bond_local.txt
index 58d96f9ee4951f4517809a2e49f2fd6171941a16..c3dc1cc4afe92ae09118e8f56c0e678a380cee71 100644
--- a/doc/src/compute_bond_local.txt
+++ b/doc/src/compute_bond_local.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -116,8 +116,8 @@ array is the number of bonds. If a single keyword is specified, a
local vector is produced. If two or more keywords are specified, a
local array is produced where the number of columns = the number of
keywords. The vector or array can be accessed by any command that
-uses local values from a compute as input. See "this
-section"_Section_howto.html#howto_15 for an overview of LAMMPS output
+uses local values from a compute as input. See the "Howto
+output"_Howto_output.html doc page for an overview of LAMMPS output
options.
The output for {dist} will be in distance "units"_units.html. The
diff --git a/doc/src/compute_centro_atom.txt b/doc/src/compute_centro_atom.txt
index 4e4b03d16762c97eb44fb010f131d63ab0d1fd4f..183537690f43f61a5c5099ac3c76c3dd37b8223c 100644
--- a/doc/src/compute_centro_atom.txt
+++ b/doc/src/compute_centro_atom.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -97,8 +97,8 @@ too frequently or to have multiple compute/dump commands, each with a
By default, this compute calculates the centrosymmetry value for each
atom as a per-atom vector, which can be accessed by any command that
-uses per-atom values from a compute as input. See "Section
-6.15"_Section_howto.html#howto_15 for an overview of LAMMPS output
+uses per-atom values from a compute as input. See the "Howto
+output"_Howto_output.html doc page for an overview of LAMMPS output
options.
If the {axes} keyword setting is {yes}, then a per-atom array is
diff --git a/doc/src/compute_chunk_atom.txt b/doc/src/compute_chunk_atom.txt
index 3a46f79d160013e96c177c3939454da9a6f4ecc7..e76b51e6ec9df377f4e1354f0090c588f6dd4b53 100644
--- a/doc/src/compute_chunk_atom.txt
+++ b/doc/src/compute_chunk_atom.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -101,14 +101,13 @@ msd/chunk"_compute_msd_chunk.html. Or they can be used by the "fix
ave/chunk"_fix_ave_chunk.html command to sum and time average a
variety of per-atom properties over the atoms in each chunk. Or they
can simply be accessed by any command that uses per-atom values from a
-compute as input, as discussed in "Section
-6.15"_Section_howto.html#howto_15.
+compute as input, as discussed on the "Howto output"_Howto_output.html
+doc page.
-See "Section 6.23"_Section_howto.html#howto_23 for an overview of
-how this compute can be used with a variety of other commands to
-tabulate properties of a simulation. The howto section gives several
-examples of input script commands that can be used to calculate
-interesting properties.
+See the "Howto chunk"_Howto_chunk.html doc page for an overview of how
+this compute can be used with a variety of other commands to tabulate
+properties of a simulation. The page gives several examples of input
+script commands that can be used to calculate interesting properties.
Conceptually it is important to realize that this compute does two
simple things. First, it sets the value of {Nchunk} = the number of
@@ -135,7 +134,6 @@ timesteps it specifies, while it accumulates per-chunk averages.
The details are described below.
-:line
:line
The different chunk styles operate as follows. For each style, how it
@@ -167,11 +165,11 @@ or the bounds specified by the optional {bounds} keyword.
For orthogonal simulation boxes, the bins are layers, pencils, or
boxes aligned with the xyz coordinate axes. For triclinic
(non-orthogonal) simulation boxes, the bin faces are parallel to the
-tilted faces of the simulation box. See "this
-section"_Section_howto.html#howto_12 of the manual for a discussion of
-the geometry of triclinic boxes in LAMMPS. As described there, a
-tilted simulation box has edge vectors a,b,c. In that nomenclature,
-bins in the x dimension have faces with normals in the "b" cross "c"
+tilted faces of the simulation box. See the "Howto
+triclinic"_Howto_triclinic.html doc page for a discussion of the
+geometry of triclinic boxes in LAMMPS. As described there, a tilted
+simulation box has edge vectors a,b,c. In that nomenclature, bins in
+the x dimension have faces with normals in the "b" cross "c"
direction. Bins in y have faces normal to the "a" cross "c"
direction. And bins in z have faces normal to the "a" cross "b"
direction. Note that in order to define the size and position of
@@ -275,7 +273,7 @@ previously defined in the input script. If no bracketed integer is
appended, the per-atom vector calculated by the compute is used. If a
bracketed integer is appended, the Ith column of the per-atom array
calculated by the compute is used. Users can also write code for
-their own compute styles and "add them to LAMMPS"_Section_modify.html.
+their own compute styles and "add them to LAMMPS"_Modify.html.
If the style begins with "f_", a fix ID must follow which has been
previously defined in the input script. If no bracketed integer is
@@ -285,7 +283,7 @@ calculated by the fix is used. Note that some fixes only produce
their values on certain timesteps, which must be compatible with the
timestep on which this compute accesses the fix, else an error
results. Users can also write code for their own fix styles and "add
-them to LAMMPS"_Section_modify.html.
+them to LAMMPS"_Modify.html.
If a value begins with "v_", a variable name for an {atom} or
{atomfile} style "variable"_variable.html must follow which has been
@@ -295,7 +293,6 @@ invoke other computes, fixes, or variables when they are evaluated, so
this is a very general means of generating per-atom quantities to
treat as a chunk ID.
-:line
:line
Normally, {Nchunk} = the number of chunks, is re-calculated every time
@@ -323,7 +320,6 @@ the same compute chunk/atom compute. However, the time windows they
induce for holding {Nchunk} constant must be identical, else an error
will be generated.
-:line
:line
The various optional keywords operate as follows. Note that some of
@@ -626,7 +622,7 @@ cylinder, x for a y-axis cylinder, and x for a z-axis cylinder.
This compute calculates a per-atom vector, which can be accessed by
any command that uses per-atom values from a compute as input. See
-"Section 6.15"_Section_howto.html#howto_15 for an overview of
+the "Howto output"_Howto_output.html doc page for an overview of
LAMMPS output options.
The per-atom vector values are unitless chunk IDs, ranging from 1 to
diff --git a/doc/src/compute_cluster_atom.txt b/doc/src/compute_cluster_atom.txt
index 94113de5f2422a2628acc9f5bcb22a4940eefe21..e6138fe1e8eb80256cdc317120bcedb8fb7326cb 100644
--- a/doc/src/compute_cluster_atom.txt
+++ b/doc/src/compute_cluster_atom.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -84,7 +84,7 @@ the neighbor list.
This compute calculates a per-atom vector, which can be accessed by
any command that uses per-atom values from a compute as input. See
-"Section 6.15"_Section_howto.html#howto_15 for an overview of
+the "Howto output"_Howto_output.html doc page for an overview of
LAMMPS output options.
The per-atom vector values will be an ID > 0, as explained above.
diff --git a/doc/src/compute_cna_atom.txt b/doc/src/compute_cna_atom.txt
index 23289b01325b4afac23c938788a8ef1e775ecc59..d69c5e9c467e626017381f6e96268c9ed8aa4b8f 100644
--- a/doc/src/compute_cna_atom.txt
+++ b/doc/src/compute_cna_atom.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -74,7 +74,7 @@ too frequently or to have multiple compute/dump commands, each with a
This compute calculates a per-atom vector, which can be accessed by
any command that uses per-atom values from a compute as input. See
-"Section 6.15"_Section_howto.html#howto_15 for an overview of
+the "Howto output"_Howto_output.html doc page for an overview of
LAMMPS output options.
The per-atom vector values will be a number from 0 to 5, as explained
diff --git a/doc/src/compute_cnp_atom.txt b/doc/src/compute_cnp_atom.txt
index 16a51f5241f16ee058553a6e4634ec578219712c..95dd59089f60fb4fcccc1d4e79f1f0cb1e840639 100644
--- a/doc/src/compute_cnp_atom.txt
+++ b/doc/src/compute_cnp_atom.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -78,7 +78,7 @@ too frequently or to have multiple compute/dump commands, each with a
This compute calculates a per-atom vector, which can be accessed by
any command that uses per-atom values from a compute as input. See
-"Section 6.15"_Section_howto.html#howto_15 for an overview of
+the "Howto output"_Howto_output.html doc page for an overview of
LAMMPS output options.
The per-atom vector values will be real positive numbers. Some typical CNP
@@ -95,8 +95,8 @@ FCC dislocation core ~ 11 :pre
[Restrictions:]
This compute is part of the USER-MISC package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/compute_com.txt b/doc/src/compute_com.txt
index b0e0c14e424ae0de3d043c2686bbc19be9e938f0..fdc631a263cb155e437a5f54aa368ffb40ee2d76 100644
--- a/doc/src/compute_com.txt
+++ b/doc/src/compute_com.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -41,9 +41,8 @@ image"_set.html command.
This compute calculates a global vector of length 3, which can be
accessed by indices 1-3 by any command that uses global vector values
-from a compute as input. See "this
-section"_Section_howto.html#howto_15 for an overview of LAMMPS output
-options.
+from a compute as input. See the "Howto output"_Howto_output.html doc
+page for an overview of LAMMPS output options.
The vector values are "intensive". The vector values will be in
distance "units"_units.html.
diff --git a/doc/src/compute_com_chunk.txt b/doc/src/compute_com_chunk.txt
index d497585cb036455b2cf199b6bc1098e34077b16e..b982f0d9017f4a501d56a9d1696cf6d4a5e51486 100644
--- a/doc/src/compute_com_chunk.txt
+++ b/doc/src/compute_com_chunk.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -30,10 +30,9 @@ chunk/atom"_compute_chunk_atom.html command, which assigns each atom
to a single chunk (or no chunk). The ID for this command is specified
as chunkID. For example, a single chunk could be the atoms in a
molecule or atoms in a spatial bin. See the "compute
-chunk/atom"_compute_chunk_atom.html doc page and "Section
-6.23"_Section_howto.html#howto_23 for details of how chunks can be
-defined and examples of how they can be used to measure properties of
-a system.
+chunk/atom"_compute_chunk_atom.html and "Howto chunk"_Howto_chunk.html
+doc pages for details of how chunks can be defined and examples of how
+they can be used to measure properties of a system.
This compute calculates the x,y,z coordinates of the center-of-mass
for each chunk, which includes all effects due to atoms passing thru
@@ -71,9 +70,8 @@ number of chunks {Nchunk} as calculated by the specified "compute
chunk/atom"_compute_chunk_atom.html command. The number of columns =
3 for the x,y,z center-of-mass coordinates of each chunk. These
values can be accessed by any command that uses global array values
-from a compute as input. See "Section
-6.15"_Section_howto.html#howto_15 for an overview of LAMMPS output
-options.
+from a compute as input. See the "Howto output"_Howto_output.html doc
+page for an overview of LAMMPS output options.
The array values are "intensive". The array values will be in
distance "units"_units.html.
diff --git a/doc/src/compute_contact_atom.txt b/doc/src/compute_contact_atom.txt
index f0bd62f4e87b9b5b1bfc85693ba0a028f95435ff..efe524263aa8c399e8771dd7348b52c9ae5cd42c 100644
--- a/doc/src/compute_contact_atom.txt
+++ b/doc/src/compute_contact_atom.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -36,7 +36,7 @@ specified compute group.
This compute calculates a per-atom vector, whose values can be
accessed by any command that uses per-atom values from a compute as
-input. See "Section 6.15"_Section_howto.html#howto_15 for an
+input. See the "Howto output"_Howto_output.html doc page for an
overview of LAMMPS output options.
The per-atom vector values will be a number >= 0.0, as explained
diff --git a/doc/src/compute_coord_atom.txt b/doc/src/compute_coord_atom.txt
index a88f7ec729298c45b534ff8799d6c58896fbb793..66eecd195da4fb19851d5d84349c72391e51add6 100644
--- a/doc/src/compute_coord_atom.txt
+++ b/doc/src/compute_coord_atom.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -109,9 +109,8 @@ array, with N columns.
For {cstyle} orientorder, this compute calculates a per-atom vector.
These values can be accessed by any command that uses per-atom values
-from a compute as input. See "Section
-6.15"_Section_howto.html#howto_15 for an overview of LAMMPS output
-options.
+from a compute as input. See the "Howto output"_Howto_output.html doc
+page for an overview of LAMMPS output options.
The per-atom vector or array values will be a number >= 0.0, as
explained above.
diff --git a/doc/src/compute_damage_atom.txt b/doc/src/compute_damage_atom.txt
index 918fbf65eff0c4172e92a8d551ce74e1a9f59cd1..2594dfe3561e02bdcbbdbbfa0651d1f0db668d88 100644
--- a/doc/src/compute_damage_atom.txt
+++ b/doc/src/compute_damage_atom.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -44,7 +44,7 @@ group.
This compute calculates a per-atom vector, which can be accessed by
any command that uses per-atom values from a compute as input. See
-"Section 6.15"_Section_howto.html#howto_15 for an overview of
+the "Howto output"_Howto_output.html doc page for an overview of
LAMMPS output options.
The per-atom vector values are unitless numbers (damage) >= 0.0.
@@ -52,8 +52,8 @@ The per-atom vector values are unitless numbers (damage) >= 0.0.
[Restrictions:]
This compute is part of the PERI package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/compute_dihedral.txt b/doc/src/compute_dihedral.txt
index a3c3dff8d68f0bb2c36d6461ceb42d6f85fd238d..aa25f9dd1029af8d7f23ffb938bd7fd6a70e08c8 100644
--- a/doc/src/compute_dihedral.txt
+++ b/doc/src/compute_dihedral.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -37,8 +37,8 @@ This compute calculates a global vector of length N where N is the
number of sub_styles defined by the "dihedral_style
hybrid"_dihedral_style.html command. which can be accessed by indices
1-N. These values can be used by any command that uses global scalar
-or vector values from a compute as input. See "this
-section"_Section_howto.html#howto_15 for an overview of LAMMPS output
+or vector values from a compute as input. See the "Howto
+output"_Howto_output.html doc page for an overview of LAMMPS output
options.
The vector values are "extensive" and will be in energy
diff --git a/doc/src/compute_dihedral_local.txt b/doc/src/compute_dihedral_local.txt
index 865e86fddb1483ccf7a3b1c3d79fec912b90ea04..77812699d35fc826c95a344ddc7bf0207caf2ec4 100644
--- a/doc/src/compute_dihedral_local.txt
+++ b/doc/src/compute_dihedral_local.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -62,8 +62,8 @@ array is the number of dihedrals. If a single keyword is specified, a
local vector is produced. If two or more keywords are specified, a
local array is produced where the number of columns = the number of
keywords. The vector or array can be accessed by any command that
-uses local values from a compute as input. See "this
-section"_Section_howto.html#howto_15 for an overview of LAMMPS output
+uses local values from a compute as input. See the "Howto
+output"_Howto_output.html doc page for an overview of LAMMPS output
options.
The output for {phi} will be in degrees.
diff --git a/doc/src/compute_dilatation_atom.txt b/doc/src/compute_dilatation_atom.txt
index ce00f7f12a5b9daae8a2b9ce9ae07a03188c41b4..292638bdf5e57f4fbe9cfc1079bb3ae64dec20fa 100644
--- a/doc/src/compute_dilatation_atom.txt
+++ b/doc/src/compute_dilatation_atom.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -47,16 +47,17 @@ compute group.
[Output info:]
This compute calculates a per-atom vector, which can be accessed by
-any command that uses per-atom values from a compute as input. See
-Section_howto 15 for an overview of LAMMPS output options.
+any command that uses per-atom values from a compute as input. See
+the "Howto output"_Howto_output.html doc page for an overview of
+LAMMPS output options.
The per-atom vector values are unitless numbers (theta) >= 0.0.
[Restrictions:]
This compute is part of the PERI package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/compute_dipole_chunk.txt b/doc/src/compute_dipole_chunk.txt
index 75131ffbb113ad75802e88afb59c36f07f160ab5..d45fde9af2dbdd86aedc30abaa55c4b62e82b648 100644
--- a/doc/src/compute_dipole_chunk.txt
+++ b/doc/src/compute_dipole_chunk.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -32,10 +32,9 @@ chunk/atom"_compute_chunk_atom.html command, which assigns each atom
to a single chunk (or no chunk). The ID for this command is specified
as chunkID. For example, a single chunk could be the atoms in a
molecule or atoms in a spatial bin. See the "compute
-chunk/atom"_compute_chunk_atom.html doc page and "Section
-6.23"_Section_howto.html#howto_23 for details of how chunks can be
-defined and examples of how they can be used to measure properties of
-a system.
+chunk/atom"_compute_chunk_atom.html and "Howto chunk"_Howto_chunk.html
+doc pages for details of how chunks can be defined and examples of how
+they can be used to measure properties of a system.
This compute calculates the x,y,z coordinates of the dipole vector
and the total dipole moment for each chunk, which includes all effects
@@ -76,8 +75,8 @@ number of chunks {Nchunk} as calculated by the specified "compute
chunk/atom"_compute_chunk_atom.html command. The number of columns =
4 for the x,y,z dipole vector components and the total dipole of each
chunk. These values can be accessed by any command that uses global
-array values from a compute as input. See "Section
-6.15"_Section_howto.html#howto_15 for an overview of LAMMPS output
+array values from a compute as input. See the "Howto
+output"_Howto_output.html doc page for an overview of LAMMPS output
options.
The array values are "intensive". The array values will be in
diff --git a/doc/src/compute_displace_atom.txt b/doc/src/compute_displace_atom.txt
index 00e5f696c118029431bf5a36395bcd906fe432ee..669ab9f7ca3ea74e4a3a8a0b5537c0b09cbd814d 100644
--- a/doc/src/compute_displace_atom.txt
+++ b/doc/src/compute_displace_atom.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -118,9 +118,8 @@ would be empty.
This compute calculates a per-atom array with 4 columns, which can be
accessed by indices 1-4 by any command that uses per-atom values from
-a compute as input. See "Section
-6.15"_Section_howto.html#howto_15 for an overview of LAMMPS output
-options.
+a compute as input. See the "Howto output"_Howto_output.html doc page
+for an overview of LAMMPS output options.
The per-atom array values will be in distance "units"_units.html.
diff --git a/doc/src/compute_dpd.txt b/doc/src/compute_dpd.txt
index 0e43feb9d23195bced66f17990bd42022b86c1ee..eccffee9b8fe85d02321ba85167a9b090c2b7972 100644
--- a/doc/src/compute_dpd.txt
+++ b/doc/src/compute_dpd.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -40,17 +40,17 @@ where N is the number of particles in the system
[Output info:]
This compute calculates a global vector of length 5 (U_cond, U_mech,
-U_chem, dpdTheta, N_particles), which can be accessed by indices 1-5. See
-"this section"_Section_howto.html#howto_15 for an overview of LAMMPS
-output options.
+U_chem, dpdTheta, N_particles), which can be accessed by indices 1-5.
+See the "Howto output"_Howto_output.html doc page for an overview of
+LAMMPS output options.
The vector values will be in energy and temperature "units"_units.html.
[Restrictions:]
This command is part of the USER-DPD package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This command also requires use of the "atom_style dpd"_atom_style.html
command.
diff --git a/doc/src/compute_dpd_atom.txt b/doc/src/compute_dpd_atom.txt
index 0532fc60c64193f977ce7d74e84768709d6502cf..2f9b4098cff988047b9a39f2926b3320b85e3aa3 100644
--- a/doc/src/compute_dpd_atom.txt
+++ b/doc/src/compute_dpd_atom.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -34,9 +34,9 @@ particles.
[Output info:]
This compute calculates a per-particle array with 4 columns (u_cond,
-u_mech, u_chem, dpdTheta), which can be accessed by indices 1-4 by any command
-that uses per-particle values from a compute as input. See
-"Section 6.15"_Section_howto.html#howto_15 for an overview of
+u_mech, u_chem, dpdTheta), which can be accessed by indices 1-4 by any
+command that uses per-particle values from a compute as input. See
+the "Howto output"_Howto_output.html doc page for an overview of
LAMMPS output options.
The per-particle array values will be in energy (u_cond, u_mech, u_chem)
@@ -45,8 +45,8 @@ and temperature (dpdTheta) "units"_units.html.
[Restrictions:]
This command is part of the USER-DPD package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This command also requires use of the "atom_style dpd"_atom_style.html
command.
diff --git a/doc/src/compute_edpd_temp_atom.txt b/doc/src/compute_edpd_temp_atom.txt
index 5b8c8ebd67c371c20deb465941d4007008c60b35..f3c1418d44c52c1d6678e32b568c3df389118fc0 100644
--- a/doc/src/compute_edpd_temp_atom.txt
+++ b/doc/src/compute_edpd_temp_atom.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -32,17 +32,17 @@ For more details please see "(Espanol1997)"_#Espanol1997 and
[Output info:]
This compute calculates a per-atom vector, which can be accessed by
-any command that uses per-atom values from a compute as input. See
-"Section 6.15"_Section_howto.html#howto_15 for an overview of
-LAMMPS output options.
+any command that uses per-atom values from a compute as input. See the
+"Howto output"_Howto_output.html doc page for an overview of LAMMPS
+output options.
The per-atom vector values will be in temperature "units"_units.html.
[Restrictions:]
This compute is part of the USER-MESO package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/compute_entropy_atom.txt b/doc/src/compute_entropy_atom.txt
index f7e7b8a66764427cd117c4305920d457efbd7e2b..b3891841b8ce04185b3f0705e877b8c34f87b34f 100644
--- a/doc/src/compute_entropy_atom.txt
+++ b/doc/src/compute_entropy_atom.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -98,8 +98,8 @@ compute 1 all entropy/atom 0.25 7.3 avg yes 5.1 :pre
By default, this compute calculates the pair entropy value for each
atom as a per-atom vector, which can be accessed by any command that
-uses per-atom values from a compute as input. See "Section
-6.15"_Section_howto.html#howto_15 for an overview of LAMMPS output
+uses per-atom values from a compute as input. See the "Howto
+output"_Howto_output.html doc page for an overview of LAMMPS output
options.
The pair entropy values have units of the Boltzmann constant. They are
@@ -109,8 +109,8 @@ ordered environments.
[Restrictions:]
This compute is part of the USER-MISC package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/compute_erotate_asphere.txt b/doc/src/compute_erotate_asphere.txt
index b9a486c32eab61c8399328e028d7eb6d59cdaa1c..5cdc0997826f3dfbfff0281e85efe3ebb4864bb0 100644
--- a/doc/src/compute_erotate_asphere.txt
+++ b/doc/src/compute_erotate_asphere.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -40,7 +40,7 @@ will be the same as in 3d.
This compute calculates a global scalar (the KE). This value can be
used by any command that uses a global scalar value from a compute as
-input. See "Section 6.15"_Section_howto.html#howto_15 for an
+input. See the "Howto output"_Howto_output.html doc page for an
overview of LAMMPS output options.
The scalar value calculated by this compute is "extensive". The
diff --git a/doc/src/compute_erotate_rigid.txt b/doc/src/compute_erotate_rigid.txt
index dec0939a43375ebb3f082634f0d11e64b508b46c..fa433c1c97699957320110651323240b2cced994 100644
--- a/doc/src/compute_erotate_rigid.txt
+++ b/doc/src/compute_erotate_rigid.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -41,9 +41,9 @@ calculation.
This compute calculates a global scalar (the summed rotational energy
of all the rigid bodies). This value can be used by any command that
-uses a global scalar value from a compute as input. See
-"Section 6.15"_Section_howto.html#howto_15 for an overview of
-LAMMPS output options.
+uses a global scalar value from a compute as input. See the "Howto
+output"_Howto_output.html doc page for an overview of LAMMPS output
+options.
The scalar value calculated by this compute is "extensive". The
scalar value will be in energy "units"_units.html.
@@ -51,8 +51,8 @@ scalar value will be in energy "units"_units.html.
[Restrictions:]
This compute is part of the RIGID package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/compute_erotate_sphere.txt b/doc/src/compute_erotate_sphere.txt
index 41e80b0154dad4d1a073b9fdb4674365e0fe1033..d0c176b50eb264ff3431b6bbcdd71ad578092b1a 100644
--- a/doc/src/compute_erotate_sphere.txt
+++ b/doc/src/compute_erotate_sphere.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -35,7 +35,7 @@ as in 3d.
This compute calculates a global scalar (the KE). This value can be
used by any command that uses a global scalar value from a compute as
-input. See "Section 6.15"_Section_howto.html#howto_15 for an
+input. See the "Howto output"_Howto_output.html doc page for an
overview of LAMMPS output options.
The scalar value calculated by this compute is "extensive". The
diff --git a/doc/src/compute_erotate_sphere_atom.txt b/doc/src/compute_erotate_sphere_atom.txt
index a0081ff6a8cb8bc26106809817a108091026741e..fdd609a0e65ffd71a599a16310b9c1bacdd809b1 100644
--- a/doc/src/compute_erotate_sphere_atom.txt
+++ b/doc/src/compute_erotate_sphere_atom.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -39,7 +39,7 @@ in the specified compute group or for point particles with a radius =
This compute calculates a per-atom vector, which can be accessed by
any command that uses per-atom values from a compute as input. See
-"Section 6.15"_Section_howto.html#howto_15 for an overview of
+the "Howto output"_Howto_output.html doc page for an overview of
LAMMPS output options.
The per-atom vector values will be in energy "units"_units.html.
diff --git a/doc/src/compute_event_displace.txt b/doc/src/compute_event_displace.txt
index 5e3a0c8599d533af3313cbe711c5d64ab77c680d..a36cf2c9c49440c6428908915caa2f16ca58dab5 100644
--- a/doc/src/compute_event_displace.txt
+++ b/doc/src/compute_event_displace.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -43,7 +43,7 @@ local atom displacements and may generate "false positives."
This compute calculates a global scalar (the flag). This value can be
used by any command that uses a global scalar value from a compute as
-input. See "Section 6.15"_Section_howto.html#howto_15 for an
+input. See the "Howto output"_Howto_output.html doc page for an
overview of LAMMPS output options.
The scalar value calculated by this compute is "intensive". The
@@ -52,8 +52,8 @@ scalar value will be a 0 or 1 as explained above.
[Restrictions:]
This command can only be used if LAMMPS was built with the REPLICA
-package. See the "Making LAMMPS"_Section_start.html#start_3 section
-for more info on packages.
+package. See the "Build package"_Build_package.html doc
+page for more info.
[Related commands:]
diff --git a/doc/src/compute_fep.txt b/doc/src/compute_fep.txt
index 9bbae7b20f1c835c67d7808867d4a398a79b4541..5b3a6915dd4a6c3c442be5034caa03b7fb709602 100644
--- a/doc/src/compute_fep.txt
+++ b/doc/src/compute_fep.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -219,8 +219,8 @@ unperturbed parameters. The energies include kspace terms if these
are used in the simulation.
These output results can be used by any command that uses a global
-scalar or vector from a compute as input. See "Section
-6.15"_Section_howto.html#howto_15 for an overview of LAMMPS output
+scalar or vector from a compute as input. See the "Howto
+output"_Howto_output.html doc page for an overview of LAMMPS output
options. For example, the computed values can be averaged using "fix
ave/time"_fix_ave_time.html.
@@ -230,8 +230,8 @@ The values calculated by this compute are "extensive".
[Restrictions:]
This compute is distributed as the USER-FEP package. It is only
-enabled if LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+enabled if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/compute_global_atom.txt b/doc/src/compute_global_atom.txt
index 3136b1fd18f849bcf6c69b328983b8aa135d5c50..a26dba72b008de7202aa880c2b6999be67dc56a8 100644
--- a/doc/src/compute_global_atom.txt
+++ b/doc/src/compute_global_atom.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -67,7 +67,7 @@ this command. This command will then assign the global chunk value to
each atom in the chunk, producing a per-atom vector or per-atom array
as output. The per-atom values can then be output to a dump file or
used by any command that uses per-atom values from a compute as input,
-as discussed in "Section 6.15"_Section_howto.html#howto_15.
+as discussed on the "Howto output"_Howto_output.html doc page.
As a concrete example, these commands will calculate the displacement
of each atom from the center-of-mass of the molecule it is in, and
@@ -130,7 +130,7 @@ page for details. If no bracketed integer is appended, the per-atom
vector calculated by the compute is used. If a bracketed integer is
appended, the Ith column of the per-atom array calculated by the
compute is used. Users can also write code for their own compute
-styles and "add them to LAMMPS"_Section_modify.html. See the
+styles and "add them to LAMMPS"_Modify.html. See the
discussion above for how I can be specified with a wildcard asterisk
to effectively specify multiple values.
@@ -143,7 +143,7 @@ references the values, else an error results. If no bracketed integer
is appended, the per-atom vector calculated by the fix is used. If a
bracketed integer is appended, the Ith column of the per-atom array
calculated by the fix is used. Users can also write code for their
-own fix style and "add them to LAMMPS"_Section_modify.html. See the
+own fix style and "add them to LAMMPS"_Modify.html. See the
discussion above for how I can be specified with a wildcard asterisk
to effectively specify multiple values.
@@ -168,7 +168,7 @@ page for details. If no bracketed integer is appended, the vector
calculated by the compute is used. If a bracketed integer is
appended, the Ith column of the array calculated by the compute is
used. Users can also write code for their own compute styles and "add
-them to LAMMPS"_Section_modify.html. See the discussion above for how
+them to LAMMPS"_Modify.html. See the discussion above for how
I can be specified with a wildcard asterisk to effectively specify
multiple values.
@@ -181,7 +181,7 @@ global/atom references the values, else an error results. If no
bracketed integer is appended, the vector calculated by the fix is
used. If a bracketed integer is appended, the Ith column of the array
calculated by the fix is used. Users can also write code for their
-own fix style and "add them to LAMMPS"_Section_modify.html. See the
+own fix style and "add them to LAMMPS"_Modify.html. See the
discussion above for how I can be specified with a wildcard asterisk
to effectively specify multiple values.
@@ -203,7 +203,7 @@ vector. If multiple inputs are specified, this compute produces a
per-atom array values, where the number of columns is equal to the
number of inputs specified. These values can be used by any command
that uses per-atom vector or array values from a compute as input.
-See "Section 6.15"_Section_howto.html#howto_15 for an overview of
+See the "Howto output"_Howto_output.html doc page for an overview of
LAMMPS output options.
The per-atom vector or array values will be in whatever units the
diff --git a/doc/src/compute_group_group.txt b/doc/src/compute_group_group.txt
index f10547339d476eb44866be4dd596fd67b4657520..cff3687354589ab402cbe03114425ec9baf04985 100644
--- a/doc/src/compute_group_group.txt
+++ b/doc/src/compute_group_group.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -123,8 +123,8 @@ group-group calculations are performed.
This compute calculates a global scalar (the energy) and a global
vector of length 3 (force), which can be accessed by indices 1-3.
These values can be used by any command that uses global scalar or
-vector values from a compute as input. See "this
-section"_Section_howto.html#howto_15 for an overview of LAMMPS output
+vector values from a compute as input. See the "Howto
+output"_Howto_output.html doc page for an overview of LAMMPS output
options.
Both the scalar and vector values calculated by this compute are
diff --git a/doc/src/compute_gyration.txt b/doc/src/compute_gyration.txt
index dd71431527f6f985b4d0e64acb85d46881134390..4dc883ad0bd2f2737b4e547b05621da6f39a01d2 100644
--- a/doc/src/compute_gyration.txt
+++ b/doc/src/compute_gyration.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -55,8 +55,8 @@ using the "set image"_set.html command.
This compute calculates a global scalar (Rg) and a global vector of
length 6 (Rg^2 tensor), which can be accessed by indices 1-6. These
values can be used by any command that uses a global scalar value or
-vector values from a compute as input. See "Section
-6.15"_Section_howto.html#howto_15 for an overview of LAMMPS output
+vector values from a compute as input. See the "Howto
+output"_Howto_output.html doc page for an overview of LAMMPS output
options.
The scalar and vector values calculated by this compute are
diff --git a/doc/src/compute_gyration_chunk.txt b/doc/src/compute_gyration_chunk.txt
index 3e338213cf579f317e773374183b115bd327d697..dcbfc653938f13b147d5cd58ec85fb3ca392f163 100644
--- a/doc/src/compute_gyration_chunk.txt
+++ b/doc/src/compute_gyration_chunk.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -35,10 +35,9 @@ chunk/atom"_compute_chunk_atom.html command, which assigns each atom
to a single chunk (or no chunk). The ID for this command is specified
as chunkID. For example, a single chunk could be the atoms in a
molecule or atoms in a spatial bin. See the "compute
-chunk/atom"_compute_chunk_atom.html doc page and "Section
-6.23"_Section_howto.html#howto_23 for details of how chunks can be
-defined and examples of how they can be used to measure properties of
-a system.
+chunk/atom"_compute_chunk_atom.html and "Howto chunk"_Howto_chunk.html
+doc pages for details of how chunks can be defined and examples of how
+they can be used to measure properties of a system.
This compute calculates the radius of gyration Rg for each chunk,
which includes all effects due to atoms passing thru periodic
@@ -93,8 +92,8 @@ calculated by the specified "compute
chunk/atom"_compute_chunk_atom.html command. If the {tensor} keyword
is specified, the global array has 6 columns. The vector or array can
be accessed by any command that uses global values from a compute as
-input. See "this section"_Section_howto.html#howto_15 for an overview
-of LAMMPS output options.
+input. See the "Howto output"_Howto_output.html doc page for an
+overview of LAMMPS output options.
All the vector or array values calculated by this compute are
"intensive". The vector or array values will be in distance
diff --git a/doc/src/compute_heat_flux.txt b/doc/src/compute_heat_flux.txt
index 39a1470201fc3f6705ee222e9719261aeae5dd4f..81a2a3f51711dc56e4b763de70421fecab1e4a4c 100644
--- a/doc/src/compute_heat_flux.txt
+++ b/doc/src/compute_heat_flux.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -32,9 +32,9 @@ or to calculate a thermal conductivity using the equilibrium
Green-Kubo formalism.
For other non-equilibrium ways to compute a thermal conductivity, see
-"this section"_Section_howto.html#howto_20. These include use of the
-"fix thermal/conductivity"_fix_thermal_conductivity.html command for
-the Muller-Plathe method. Or the "fix heat"_fix_heat.html command
+the "Howto kappa"_Howto_kappa.html doc page.. These include use of
+the "fix thermal/conductivity"_fix_thermal_conductivity.html command
+for the Muller-Plathe method. Or the "fix heat"_fix_heat.html command
which can add or subtract heat from groups of atoms.
The compute takes three arguments which are IDs of other
@@ -99,8 +99,8 @@ result should be: average conductivity ~0.29 in W/mK.
This compute calculates a global vector of length 6 (total heat flux
vector, followed by convective heat flux vector), which can be
accessed by indices 1-6. These values can be used by any command that
-uses global vector values from a compute as input. See "this
-section"_Section_howto.html#howto_15 for an overview of LAMMPS output
+uses global vector values from a compute as input. See the "Howto
+output"_Howto_output.html doc page for an overview of LAMMPS output
options.
The vector values calculated by this compute are "extensive", meaning
diff --git a/doc/src/compute_hexorder_atom.txt b/doc/src/compute_hexorder_atom.txt
index cdf47e0894aeffffb7d4a83da178ee328a8d1eb2..082a3cad7a0e62195fa333fd15f5071c2810000c 100644
--- a/doc/src/compute_hexorder_atom.txt
+++ b/doc/src/compute_hexorder_atom.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -95,10 +95,9 @@ This compute calculates a per-atom array with 2 columns, giving the
real and imaginary parts {qn}, a complex number restricted to the
unit disk of the complex plane i.e. Re({qn})^2 + Im({qn})^2 <= 1 .
-These values can be accessed by any command that uses
-per-atom values from a compute as input. See "Section
-6.15"_Section_howto.html#howto_15 for an overview of LAMMPS output
-options.
+These values can be accessed by any command that uses per-atom values
+from a compute as input. See the "Howto output"_Howto_output.html doc
+page for an overview of LAMMPS output options.
[Restrictions:] none
diff --git a/doc/src/compute_improper.txt b/doc/src/compute_improper.txt
index f0d2fa400e634ad40eccda5999f0bded55467eaf..867dd48cc16edc61f5b1cc8d64d4b80234120209 100644
--- a/doc/src/compute_improper.txt
+++ b/doc/src/compute_improper.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -37,8 +37,8 @@ This compute calculates a global vector of length N where N is the
number of sub_styles defined by the "improper_style
hybrid"_improper_style.html command. which can be accessed by indices
1-N. These values can be used by any command that uses global scalar
-or vector values from a compute as input. See "this
-section"_Section_howto.html#howto_15 for an overview of LAMMPS output
+or vector values from a compute as input. See the "Howto
+output"_Howto_output.html doc page for an overview of LAMMPS output
options.
The vector values are "extensive" and will be in energy
diff --git a/doc/src/compute_improper_local.txt b/doc/src/compute_improper_local.txt
index 0c289fbf0774fde0651d77d6a27b209621b5388e..f340d5a03fc472889b22f854480c0563eee0e6dc 100644
--- a/doc/src/compute_improper_local.txt
+++ b/doc/src/compute_improper_local.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -63,8 +63,8 @@ array is the number of impropers. If a single keyword is specified, a
local vector is produced. If two or more keywords are specified, a
local array is produced where the number of columns = the number of
keywords. The vector or array can be accessed by any command that
-uses local values from a compute as input. See "this
-section"_Section_howto.html#howto_15 for an overview of LAMMPS output
+uses local values from a compute as input. See the "Howto
+output"_Howto_output.html doc page for an overview of LAMMPS output
options.
The output for {chi} will be in degrees.
diff --git a/doc/src/compute_inertia_chunk.txt b/doc/src/compute_inertia_chunk.txt
index b0dbb12aea8d5e7e1e5d982f0d4d656b9d0c2ffb..d6cdb3fe79eb950ce3aa3675c9a7d13986d1e957 100644
--- a/doc/src/compute_inertia_chunk.txt
+++ b/doc/src/compute_inertia_chunk.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -30,10 +30,9 @@ chunk/atom"_compute_chunk_atom.html command, which assigns each atom
to a single chunk (or no chunk). The ID for this command is specified
as chunkID. For example, a single chunk could be the atoms in a
molecule or atoms in a spatial bin. See the "compute
-chunk/atom"_compute_chunk_atom.html doc page and "Section
-6.23"_Section_howto.html#howto_23 for details of how chunks can be
-defined and examples of how they can be used to measure properties of
-a system.
+chunk/atom"_compute_chunk_atom.html and "Howto chunk"_Howto_chunk.html
+doc pages for details of how chunks can be defined and examples of how
+they can be used to measure properties of a system.
This compute calculates the 6 components of the symmetric inertia
tensor for each chunk, ordered Ixx,Iyy,Izz,Ixy,Iyz,Ixz. The
@@ -72,8 +71,8 @@ number of chunks {Nchunk} as calculated by the specified "compute
chunk/atom"_compute_chunk_atom.html command. The number of columns =
6 for the 6 components of the inertia tensor for each chunk, ordered
as listed above. These values can be accessed by any command that
-uses global array values from a compute as input. See "Section
-6.15"_Section_howto.html#howto_15 for an overview of LAMMPS output
+uses global array values from a compute as input. See the "Howto
+output"_Howto_output.html doc page for an overview of LAMMPS output
options.
The array values are "intensive". The array values will be in
diff --git a/doc/src/compute_ke.txt b/doc/src/compute_ke.txt
index caee8971627231b080a680612017df790ef292df..64ab83db48b792aa0bc26dbd60ca0de7800166ae 100644
--- a/doc/src/compute_ke.txt
+++ b/doc/src/compute_ke.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -44,7 +44,7 @@ include different degrees of freedom (translational, rotational, etc).
This compute calculates a global scalar (the summed KE). This value
can be used by any command that uses a global scalar value from a
-compute as input. See "Section 6.15"_Section_howto.html#howto_15
+compute as input. See the "Howto output"_Howto_output.html doc page
for an overview of LAMMPS output options.
The scalar value calculated by this compute is "extensive". The
diff --git a/doc/src/compute_ke_atom.txt b/doc/src/compute_ke_atom.txt
index f5431f0569fe48e82ec9ebbb48f77d3f9e1d7f17..d288ab0236d44a40c32805a94e8d1b04a181edd1 100644
--- a/doc/src/compute_ke_atom.txt
+++ b/doc/src/compute_ke_atom.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -34,7 +34,7 @@ specified compute group.
This compute calculates a per-atom vector, which can be accessed by
any command that uses per-atom values from a compute as input. See
-"Section 6.15"_Section_howto.html#howto_15 for an overview of
+the "Howto output"_Howto_output.html doc page for an overview of
LAMMPS output options.
The per-atom vector values will be in energy "units"_units.html.
diff --git a/doc/src/compute_ke_atom_eff.txt b/doc/src/compute_ke_atom_eff.txt
index 8228e13f07c697e32cf678c3e381082d21a653ea..29905f81d6b624f119cfb05a8daebfb959971492 100644
--- a/doc/src/compute_ke_atom_eff.txt
+++ b/doc/src/compute_ke_atom_eff.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -57,17 +57,17 @@ electrons) not in the specified compute group.
[Output info:]
This compute calculates a scalar quantity for each atom, which can be
-accessed by any command that uses per-atom computes as input. See
-"Section 6.15"_Section_howto.html#howto_15 for an overview of
-LAMMPS output options.
+accessed by any command that uses per-atom computes as input. See the
+"Howto output"_Howto_output.html doc page for an overview of LAMMPS
+output options.
The per-atom vector values will be in energy "units"_units.html.
[Restrictions:]
This compute is part of the USER-EFF package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/compute_ke_eff.txt b/doc/src/compute_ke_eff.txt
index ac8d7e6c01d48b723484e9ff7ab7959e7b97b9e0..fa2c51a032607c696bbb61c23abe489b189a3975 100644
--- a/doc/src/compute_ke_eff.txt
+++ b/doc/src/compute_ke_eff.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -61,7 +61,7 @@ See "compute temp/eff"_compute_temp_eff.html.
This compute calculates a global scalar (the KE). This value can be
used by any command that uses a global scalar value from a compute as
-input. See "Section 6.15"_Section_howto.html#howto_15 for an
+input. See the "Howto output"_Howto_output.html doc page for an
overview of LAMMPS output options.
The scalar value calculated by this compute is "extensive". The
@@ -70,8 +70,8 @@ scalar value will be in energy "units"_units.html.
[Restrictions:]
This compute is part of the USER-EFF package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:] none
diff --git a/doc/src/compute_ke_rigid.txt b/doc/src/compute_ke_rigid.txt
index f79696a77a1fe3692fad26fadbca9f47f765612e..ad6baf567fa87e8e4be7e67d65f9fe5a7333ba40 100644
--- a/doc/src/compute_ke_rigid.txt
+++ b/doc/src/compute_ke_rigid.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -40,8 +40,8 @@ calculation.
This compute calculates a global scalar (the summed KE of all the
rigid bodies). This value can be used by any command that uses a
-global scalar value from a compute as input. See "Section
-6.15"_Section_howto.html#howto_15 for an overview of LAMMPS output
+global scalar value from a compute as input. See the "Howto
+output"_Howto_output.html doc page for an overview of LAMMPS output
options.
The scalar value calculated by this compute is "extensive". The
@@ -50,8 +50,8 @@ scalar value will be in energy "units"_units.html.
[Restrictions:]
This compute is part of the RIGID package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/compute_meso_e_atom.txt b/doc/src/compute_meso_e_atom.txt
index 4e621b43018137817134f567efc0c550574e5737..0f0cfda2d1c8a9c01d367608e5e36d27f01de416 100644
--- a/doc/src/compute_meso_e_atom.txt
+++ b/doc/src/compute_meso_e_atom.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -38,7 +38,7 @@ specified compute group.
This compute calculates a per-atom vector, which can be accessed by
any command that uses per-atom values from a compute as input. See
-"Section 6.15"_Section_howto.html#howto_15 for an overview of
+the "Howto output"_Howto_output.html doc page for an overview of
LAMMPS output options.
The per-atom vector values will be in energy "units"_units.html.
@@ -46,8 +46,8 @@ The per-atom vector values will be in energy "units"_units.html.
[Restrictions:]
This compute is part of the USER-SPH package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/compute_meso_rho_atom.txt b/doc/src/compute_meso_rho_atom.txt
index a017424dd01f0314e5155ac59e5b3dc50c652630..5127ad2c48f7a3f033957e800a7ba8303dfa0fe7 100644
--- a/doc/src/compute_meso_rho_atom.txt
+++ b/doc/src/compute_meso_rho_atom.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -38,7 +38,7 @@ specified compute group.
This compute calculates a per-atom vector, which can be accessed by
any command that uses per-atom values from a compute as input. See
-"Section 6.15"_Section_howto.html#howto_15 for an overview of
+the "Howto output"_Howto_output.html doc page for an overview of
LAMMPS output options.
The per-atom vector values will be in mass/volume "units"_units.html.
@@ -46,8 +46,8 @@ The per-atom vector values will be in mass/volume "units"_units.html.
[Restrictions:]
This compute is part of the USER-SPH package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/compute_meso_t_atom.txt b/doc/src/compute_meso_t_atom.txt
index 9e81b038f452c901aeb5dc3d0747e4df6cafd215..f4ab869ec27bd943dffcfe5b4df1dce358efa5cf 100644
--- a/doc/src/compute_meso_t_atom.txt
+++ b/doc/src/compute_meso_t_atom.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -40,7 +40,7 @@ specified compute group.
This compute calculates a per-atom vector, which can be accessed by
any command that uses per-atom values from a compute as input. See
-"Section 6.15"_Section_howto.html#howto_15 for an overview of
+the "Howto output"_Howto_output.html doc page for an overview of
LAMMPS output options.
The per-atom vector values will be in temperature "units"_units.html.
@@ -48,8 +48,8 @@ The per-atom vector values will be in temperature "units"_units.html.
[Restrictions:]
This compute is part of the USER-SPH package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/compute_modify.txt b/doc/src/compute_modify.txt
index 9a2480ec0ac7fd7b584216a74355ed9b707c877e..192ea0bc9ec96d6c7691214f78f7cf2c080f4ddd 100644
--- a/doc/src/compute_modify.txt
+++ b/doc/src/compute_modify.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/compute_msd.txt b/doc/src/compute_msd.txt
index f806c5e29266752bae1859a33bcf8eb1101eb99c..b54e05bc6498ffd450ce91ff9f5b4c959f9790fd 100644
--- a/doc/src/compute_msd.txt
+++ b/doc/src/compute_msd.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -93,9 +93,8 @@ instead of many, which will change the values of msd somewhat.
This compute calculates a global vector of length 4, which can be
accessed by indices 1-4 by any command that uses global vector values
-from a compute as input. See "this
-section"_Section_howto.html#howto_15 for an overview of LAMMPS output
-options.
+from a compute as input. See the "Howto output"_Howto_output.html doc
+page for an overview of LAMMPS output options.
The vector values are "intensive". The vector values will be in
distance^2 "units"_units.html.
diff --git a/doc/src/compute_msd_chunk.txt b/doc/src/compute_msd_chunk.txt
index 7f31b61ed0bda808a94a5a45e3c4d165f4e3c1cf..264f38d5fde4a6f587ff97f22ed797b07f3b50bc 100644
--- a/doc/src/compute_msd_chunk.txt
+++ b/doc/src/compute_msd_chunk.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -30,10 +30,9 @@ chunk/atom"_compute_chunk_atom.html command, which assigns each atom
to a single chunk (or no chunk). The ID for this command is specified
as chunkID. For example, a single chunk could be the atoms in a
molecule or atoms in a spatial bin. See the "compute
-chunk/atom"_compute_chunk_atom.html doc page and "Section
-6.23"_Section_howto.html#howto_23 for details of how chunks can be
-defined and examples of how they can be used to measure properties of
-a system.
+chunk/atom"_compute_chunk_atom.html and "Howto chunk"_Howto_chunk.html
+doc pages for details of how chunks can be defined and examples of how
+they can be used to measure properties of a system.
Four quantities are calculated by this compute for each chunk. The
first 3 quantities are the squared dx,dy,dz displacements of the
@@ -106,7 +105,7 @@ number of chunks {Nchunk} as calculated by the specified "compute
chunk/atom"_compute_chunk_atom.html command. The number of columns =
4 for dx,dy,dz and the total displacement. These values can be
accessed by any command that uses global array values from a compute
-as input. See "this section"_Section_howto.html#howto_15 for an
+as input. See the "Howto output"_Howto_output.html doc page for an
overview of LAMMPS output options.
The array values are "intensive". The array values will be in
diff --git a/doc/src/compute_msd_nongauss.txt b/doc/src/compute_msd_nongauss.txt
index 198da999e0a3c36af28e45f173dc9683aca3aa50..c6e89a10615a191d4df77fd3e4d207d07ecb69a4 100644
--- a/doc/src/compute_msd_nongauss.txt
+++ b/doc/src/compute_msd_nongauss.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -57,9 +57,8 @@ NOTEs, which also apply to this compute.
This compute calculates a global vector of length 3, which can be
accessed by indices 1-3 by any command that uses global vector values
-from a compute as input. See "this
-section"_Section_howto.html#howto_15 for an overview of LAMMPS output
-options.
+from a compute as input. See the "Howto output"_Howto_output.html doc
+page for an overview of LAMMPS output options.
The vector values are "intensive". The first vector value will be in
distance^2 "units"_units.html, the second is in distance^4 units, and
@@ -67,9 +66,9 @@ the 3rd is dimensionless.
[Restrictions:]
-This compute is part of the MISC package. It is only enabled if LAMMPS
-was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+This compute is part of the MISC package. It is only enabled if
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/compute_omega_chunk.txt b/doc/src/compute_omega_chunk.txt
index 46c72d3dcb3d15aed65805003bd419b30d098fb2..84b25ac6f26e014a2258715bf2e7d847642854df 100644
--- a/doc/src/compute_omega_chunk.txt
+++ b/doc/src/compute_omega_chunk.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -30,10 +30,9 @@ chunk/atom"_compute_chunk_atom.html command, which assigns each atom
to a single chunk (or no chunk). The ID for this command is specified
as chunkID. For example, a single chunk could be the atoms in a
molecule or atoms in a spatial bin. See the "compute
-chunk/atom"_compute_chunk_atom.html doc page and "Section
-6.23"_Section_howto.html#howto_23 for details of how chunks can be
-defined and examples of how they can be used to measure properties of
-a system.
+chunk/atom"_compute_chunk_atom.html and "Howto chunk"_Howto_chunk.html
+doc pages for details of how chunks can be defined and examples of how
+they can be used to measure properties of a system.
This compute calculates the 3 components of the angular velocity
vector for each chunk, via the formula L = Iw where L is the angular
@@ -73,8 +72,8 @@ number of chunks {Nchunk} as calculated by the specified "compute
chunk/atom"_compute_chunk_atom.html command. The number of columns =
3 for the 3 xyz components of the angular velocity for each chunk.
These values can be accessed by any command that uses global array
-values from a compute as input. See "Section
-6.15"_Section_howto.html#howto_15 for an overview of LAMMPS output
+values from a compute as input. See the "Howto
+output"_Howto_output.html doc page for an overview of LAMMPS output
options.
The array values are "intensive". The array values will be in
diff --git a/doc/src/compute_orientorder_atom.txt b/doc/src/compute_orientorder_atom.txt
index adf11dcfcfa9822f4c736f1cb7203ca0e02c446c..7327a7b1d333a5375d033d5d8f88b9e74efc6237 100644
--- a/doc/src/compute_orientorder_atom.txt
+++ b/doc/src/compute_orientorder_atom.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -115,10 +115,9 @@ Re({Ybar_-m+1}) Im({Ybar_-m+1}) ... Re({Ybar_m}) Im({Ybar_m}). This
way, the per-atom array will have a total of {nlvalues}+2*(2{l}+1)
columns.
-These values can be accessed by any command that uses
-per-atom values from a compute as input. See "Section
-6.15"_Section_howto.html#howto_15 for an overview of LAMMPS output
-options.
+These values can be accessed by any command that uses per-atom values
+from a compute as input. See the "Howto output"_Howto_output.html doc
+page for an overview of LAMMPS output options.
[Restrictions:] none
diff --git a/doc/src/compute_pair.txt b/doc/src/compute_pair.txt
index 0602dab81bd5902838a01d52432a881db684f710..a2c25fcc8dc0dbe737e3efb76fd1ef57197dd765 100644
--- a/doc/src/compute_pair.txt
+++ b/doc/src/compute_pair.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -62,9 +62,8 @@ This compute calculates a global scalar which is {epair} or {evdwl} or
{ecoul}. If the pair style supports it, it also calculates a global
vector of length >= 1, as determined by the pair style. These values
can be used by any command that uses global scalar or vector values
-from a compute as input. See "this
-section"_Section_howto.html#howto_15 for an overview of LAMMPS output
-options.
+from a compute as input. See the "Howto output"_Howto_output.html doc
+page for an overview of LAMMPS output options.
The scalar and vector values calculated by this compute are
"extensive".
diff --git a/doc/src/compute_pair_local.txt b/doc/src/compute_pair_local.txt
index 16aaba4667396dfc038c9f7625fdca532a8cd04b..1460ba18a5b1ffbadfce39cae346872c16866dd0 100644
--- a/doc/src/compute_pair_local.txt
+++ b/doc/src/compute_pair_local.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -62,7 +62,7 @@ pair styles do not define any additional quantities, so N = 0. An
example of ones that do are the "granular pair styles"_pair_gran.html
which calculate the tangential force between two particles and return
its components and magnitude acting on atom I for N = 1,2,3,4. See
-individual pair styles for detils.
+individual pair styles for details.
The value {dist} will be in distance "units"_units.html. The value
{eng} will be in energy "units"_units.html. The values {force}, {fx},
@@ -76,7 +76,7 @@ command for the types of the two atoms is used. For the {radius}
setting, the sum of the radii of the two particles is used as a
cutoff. For example, this is appropriate for granular particles which
only interact when they are overlapping, as computed by "granular pair
-styles"_pair_gran.txt. Note that if a granular model defines atom
+styles"_pair_gran.html. Note that if a granular model defines atom
types such that all particles of a specific type are monodisperse
(same diameter), then the two settings are effectively identical.
@@ -119,8 +119,8 @@ array is the number of pairs. If a single keyword is specified, a
local vector is produced. If two or more keywords are specified, a
local array is produced where the number of columns = the number of
keywords. The vector or array can be accessed by any command that
-uses local values from a compute as input. See "this
-section"_Section_howto.html#howto_15 for an overview of LAMMPS output
+uses local values from a compute as input. See the "Howto
+output"_Howto_output.html doc page for an overview of LAMMPS output
options.
The output for {dist} will be in distance "units"_units.html. The
diff --git a/doc/src/compute_pe.txt b/doc/src/compute_pe.txt
index 15f27a8eff5f92cb97b215e8313b98429db8fef9..37655dfd480c8bb48b2b722436f5b6b0d15f5e6d 100644
--- a/doc/src/compute_pe.txt
+++ b/doc/src/compute_pe.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -64,9 +64,8 @@ See the "thermo_style" command for more details.
This compute calculates a global scalar (the potential energy). This
value can be used by any command that uses a global scalar value from
-a compute as input. See "Section
-6.15"_Section_howto.html#howto_15 for an overview of LAMMPS output
-options.
+a compute as input. See the "Howto output"_Howto_output.html doc page
+for an overview of LAMMPS output options.
The scalar value calculated by this compute is "extensive". The
scalar value will be in energy "units"_units.html.
diff --git a/doc/src/compute_pe_atom.txt b/doc/src/compute_pe_atom.txt
index c312c886a692f5a0ffcbb277e432acb34bcc88aa..400621f8df1d50b921c2ad870df98b8cdf578784 100644
--- a/doc/src/compute_pe_atom.txt
+++ b/doc/src/compute_pe_atom.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -81,7 +81,7 @@ global system energy.
This compute calculates a per-atom vector, which can be accessed by
any command that uses per-atom values from a compute as input. See
-"Section 6.15"_Section_howto.html#howto_15 for an overview of
+the "Howto output"_Howto_output.html doc page for an overview of
LAMMPS output options.
The per-atom vector values will be in energy "units"_units.html.
diff --git a/doc/src/compute_plasticity_atom.txt b/doc/src/compute_plasticity_atom.txt
index 788213fc65985cb86bee7a08b3e78f50adf423cc..b82179712abcd146420f0ac7b538f2c49b01f855 100644
--- a/doc/src/compute_plasticity_atom.txt
+++ b/doc/src/compute_plasticity_atom.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -41,16 +41,17 @@ compute group.
[Output info:]
This compute calculates a per-atom vector, which can be accessed by
-any command that uses per-atom values from a compute as input. See
-Section_howto 15 for an overview of LAMMPS output options.
+any command that uses per-atom values from a compute as input. See
+the "Howto output"_Howto_output.html doc page for an overview of
+LAMMPS output options.
The per-atom vector values are unitless numbers (lambda) >= 0.0.
[Restrictions:]
This compute is part of the PERI package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/compute_pressure.txt b/doc/src/compute_pressure.txt
index f0691ad20762758234828f976e7519ef47568d57..6acbaf7d3d5619c4c08001bf712a606b911e280e 100644
--- a/doc/src/compute_pressure.txt
+++ b/doc/src/compute_pressure.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -105,23 +105,22 @@ where "thermo_temp" is the ID of a similarly defined compute of style
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -130,8 +129,8 @@ more instructions on how to use the accelerated styles effectively.
This compute calculates a global scalar (the pressure) and a global
vector of length 6 (pressure tensor), which can be accessed by indices
1-6. These values can be used by any command that uses global scalar
-or vector values from a compute as input. See "this
-section"_Section_howto.html#howto_15 for an overview of LAMMPS output
+or vector values from a compute as input. See the "Howto
+output"_Howto_output.html doc page for an overview of LAMMPS output
options.
The scalar and vector values calculated by this compute are
diff --git a/doc/src/compute_pressure_uef.txt b/doc/src/compute_pressure_uef.txt
index 5b252b369dd012691e62a3dcf267c6e00cca11c3..c4c0fc405ff563273c1d9b1ff72c51a638eedf02 100644
--- a/doc/src/compute_pressure_uef.txt
+++ b/doc/src/compute_pressure_uef.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -38,9 +38,9 @@ The keywords and output information are documented in
[Restrictions:]
-This fix is part of the USER-UEF package. It is only enabled if
-LAMMPS was built with that package. See the
-"Making LAMMPS"_Section_start.html#start_3 section for more info.
+This fix is part of the USER-UEF package. It is only enabled if LAMMPS
+was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This command can only be used when "fix nvt/uef"_fix_nh_uef.html
or "fix npt/uef"_fix_nh_uef.html is active.
diff --git a/doc/src/compute_property_atom.txt b/doc/src/compute_property_atom.txt
index c0970d5121cca49705fa5eb5eb02407f490a04e5..512009093c0e052e8e7b43f44455d1f61d7e6fb8 100644
--- a/doc/src/compute_property_atom.txt
+++ b/doc/src/compute_property_atom.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -93,11 +93,11 @@ compute 3 all property/atom sp spx spy spz :pre
Define a computation that simply stores atom attributes for each atom
in the group. This is useful so that the values can be used by other
-"output commands"_Section_howto.html#howto_15 that take computes as
-inputs. See for example, the "compute reduce"_compute_reduce.html,
-"fix ave/atom"_fix_ave_atom.html, "fix ave/histo"_fix_ave_histo.html,
-"fix ave/chunk"_fix_ave_chunk.html, and "atom-style
-variable"_variable.html commands.
+"output commands"_Howto_output.html that take computes as inputs. See
+for example, the "compute reduce"_compute_reduce.html, "fix
+ave/atom"_fix_ave_atom.html, "fix ave/histo"_fix_ave_histo.html, "fix
+ave/chunk"_fix_ave_chunk.html, and "atom-style variable"_variable.html
+commands.
The list of possible attributes is the same as that used by the "dump
custom"_dump.html command, which describes their meaning, with some
@@ -149,8 +149,8 @@ on the number of input values. If a single input is specified, a
per-atom vector is produced. If two or more inputs are specified, a
per-atom array is produced where the number of columns = the number of
inputs. The vector or array can be accessed by any command that uses
-per-atom values from a compute as input. See "this
-section"_Section_howto.html#howto_15 for an overview of LAMMPS output
+per-atom values from a compute as input. See the "Howto
+output"_Howto_output.html doc page for an overview of LAMMPS output
options.
The vector or array values will be in whatever "units"_units.html the
diff --git a/doc/src/compute_property_chunk.txt b/doc/src/compute_property_chunk.txt
index b9d4944b30740cfcb28313811a6885296c65acf4..a30b5a1f0a5526421610cc06946328874c762115 100644
--- a/doc/src/compute_property_chunk.txt
+++ b/doc/src/compute_property_chunk.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -36,15 +36,14 @@ chunk/atom"_compute_chunk_atom.html command, which assigns each atom
to a single chunk (or no chunk). The ID for this command is specified
as chunkID. For example, a single chunk could be the atoms in a
molecule or atoms in a spatial bin. See the "compute
-chunk/atom"_compute_chunk_atom.html doc page and "Section
-6.23"_Section_howto.html#howto_23 for details of how chunks can be
-defined and examples of how they can be used to measure properties of
-a system.
+chunk/atom"_compute_chunk_atom.html and "Howto chunk"_Howto_chunk.html
+doc pages for details of how chunks can be defined and examples of how
+they can be used to measure properties of a system.
This compute calculates and stores the specified attributes of chunks
as global data so they can be accessed by other "output
-commands"_Section_howto.html#howto_15 and used in conjunction with
-other commands that generate per-chunk data, such as "compute
+commands"_Howto_output.html and used in conjunction with other
+commands that generate per-chunk data, such as "compute
com/chunk"_compute_com_chunk.html or "compute
msd/chunk"_compute_msd_chunk.html.
@@ -103,8 +102,8 @@ single input is specified, a global vector is produced. If two or
more inputs are specified, a global array is produced where the number
of columns = the number of inputs. The vector or array can be
accessed by any command that uses global values from a compute as
-input. See "this section"_Section_howto.html#howto_15 for an overview
-of LAMMPS output options.
+input. See the "Howto output"_Howto_output.html doc page for an
+overview of LAMMPS output options.
The vector or array values are "intensive". The values will be
unitless or in the units discussed above.
diff --git a/doc/src/compute_property_local.txt b/doc/src/compute_property_local.txt
index 39106a39c890cae655d635216bbe93876f43fc74..c4ad0afc95cd3fcf7655d5861c66a3f488683519 100644
--- a/doc/src/compute_property_local.txt
+++ b/doc/src/compute_property_local.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -19,8 +19,8 @@ one or more attributes may be appended :l
patom1 patom2 ptype1 ptype2
batom1 batom2 btype
aatom1 aatom2 aatom3 atype
- datom1 datom2 datom3 dtype
- iatom1 iatom2 iatom3 itype :pre
+ datom1 datom2 datom3 datom4 dtype
+ iatom1 iatom2 iatom3 iatom4 itype :pre
natom1, natom2 = IDs of 2 atoms in each pair (within neighbor cutoff)
ntype1, ntype2 = type of 2 atoms in each pair (within neighbor cutoff)
@@ -48,10 +48,10 @@ compute 1 all property/local atype aatom2 :pre
Define a computation that stores the specified attributes as local
data so it can be accessed by other "output
-commands"_Section_howto.html#howto_15. If the input attributes refer
-to bond information, then the number of datums generated, aggregated
-across all processors, equals the number of bonds in the system.
-Ditto for pairs, angles, etc.
+commands"_Howto_output.html. If the input attributes refer to bond
+information, then the number of datums generated, aggregated across
+all processors, equals the number of bonds in the system. Ditto for
+pairs, angles, etc.
If multiple attributes are specified then they must all generate the
same amount of information, so that the resulting local array has the
@@ -140,8 +140,8 @@ the array is the number of bonds, angles, etc. If a single input is
specified, a local vector is produced. If two or more inputs are
specified, a local array is produced where the number of columns = the
number of inputs. The vector or array can be accessed by any command
-that uses local values from a compute as input. See "this
-section"_Section_howto.html#howto_15 for an overview of LAMMPS output
+that uses local values from a compute as input. See the "Howto
+output"_Howto_output.html doc page for an overview of LAMMPS output
options.
The vector or array values will be integers that correspond to the
diff --git a/doc/src/compute_rdf.txt b/doc/src/compute_rdf.txt
index e462e85fc038a10dfe9de0c701fecb103002a731..04b38682cc4957ac67459b18652249b1dfb75f14 100644
--- a/doc/src/compute_rdf.txt
+++ b/doc/src/compute_rdf.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -152,7 +152,7 @@ coordinate (center of the bin), Each successive set of 2 columns has
the g(r) and coord(r) values for a specific set of {itypeN} versus
{jtypeN} interactions, as described above. These values can be used
by any command that uses a global values from a compute as input. See
-"Section 6.15"_Section_howto.html#howto_15 for an overview of
+the "Howto output"_Howto_output.html doc page for an overview of
LAMMPS output options.
The array values calculated by this compute are all "intensive".
diff --git a/doc/src/compute_reduce.txt b/doc/src/compute_reduce.txt
index 07d3c3bda7b88e277f36cb2e839398763488ca40..ef3c7c6489e03ef3c1056edefd8d4dc419766cdf 100644
--- a/doc/src/compute_reduce.txt
+++ b/doc/src/compute_reduce.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -116,7 +116,7 @@ per-atom or local quantities. See the individual
is appended, the vector calculated by the compute is used. If a
bracketed integer is appended, the Ith column of the array calculated
by the compute is used. Users can also write code for their own
-compute styles and "add them to LAMMPS"_Section_modify.html. See the
+compute styles and "add them to LAMMPS"_Modify.html. See the
discussion above for how I can be specified with a wildcard asterisk
to effectively specify multiple values.
@@ -129,9 +129,9 @@ references the values, else an error results. If no bracketed integer
is appended, the vector calculated by the fix is used. If a bracketed
integer is appended, the Ith column of the array calculated by the fix
is used. Users can also write code for their own fix style and "add
-them to LAMMPS"_Section_modify.html. See the discussion above for how
-I can be specified with a wildcard asterisk to effectively specify
-multiple values.
+them to LAMMPS"_Modify.html. See the discussion above for how I can
+be specified with a wildcard asterisk to effectively specify multiple
+values.
If a value begins with "v_", a variable name must follow which has
been previously defined in the input script. It must be an
@@ -192,7 +192,7 @@ This compute calculates a global scalar if a single input value is
specified or a global vector of length N where N is the number of
inputs, and which can be accessed by indices 1 to N. These values can
be used by any command that uses global scalar or vector values from a
-compute as input. See "Section 6.15"_Section_howto.html#howto_15
+compute as input. See the "Howto output"_Howto_output.html doc page
for an overview of LAMMPS output options.
All the scalar or vector values calculated by this compute are
diff --git a/doc/src/compute_rigid_local.txt b/doc/src/compute_rigid_local.txt
index 077ad57d81b6bb1acd7d328e4e3f819867e71510..9b829a70fcb82a1de7defbafbce6b949ca833f20 100644
--- a/doc/src/compute_rigid_local.txt
+++ b/doc/src/compute_rigid_local.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -49,8 +49,8 @@ Define a computation that simply stores rigid body attributes for
rigid bodies defined by the "fix rigid/small"_fix_rigid.html command
or one of its NVE, NVT, NPT, NPH variants. The data is stored as
local data so it can be accessed by other "output
-commands"_Section_howto.html#howto_15 that process local data, such as
-the "compute reduce"_compute_reduce.html or "dump local"_dump.html
+commands"_Howto_output.html that process local data, such as the
+"compute reduce"_compute_reduce.html or "dump local"_dump.html
commands.
Note that this command only works with the "fix
@@ -154,9 +154,9 @@ array is the number of rigid bodies. If a single keyword is
specified, a local vector is produced. If two or more keywords are
specified, a local array is produced where the number of columns = the
number of keywords. The vector or array can be accessed by any
-command that uses local values from a compute as input. See "this
-section"_Section_howto.html#howto_15 for an overview of LAMMPS output
-options.
+command that uses local values from a compute as input. See the
+"Howto output"_Howto_output.html doc page for an overview of LAMMPS
+output options.
The vector or array values will be in whatever "units"_units.html the
corresponding attribute is in:
@@ -175,8 +175,8 @@ inertiax,inertiay,inertiaz = mass*distance^2 units :ul
[Restrictions:]
This compute is part of the RIGID package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/compute_saed.txt b/doc/src/compute_saed.txt
index 020f72f565c1009426ae22e891932aa648f6f1bd..b27c36e318757159978998b723d2e3bc5b5c3924 100644
--- a/doc/src/compute_saed.txt
+++ b/doc/src/compute_saed.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -143,18 +143,17 @@ the number of reciprocal lattice nodes that are explored by the mesh.
The entries of the global vector are the computed diffraction
intensities as described above.
-The vector can be accessed by any command that uses global values
-from a compute as input. See "this
-section"_Section_howto.html#howto_15 for an overview of LAMMPS output
-options.
+The vector can be accessed by any command that uses global values from
+a compute as input. See the "Howto output"_Howto_output.html doc page
+for an overview of LAMMPS output options.
All array values calculated by this compute are "intensive".
[Restrictions:]
This compute is part of the USER-DIFFRACTION package. It is only
-enabled if LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+enabled if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
The compute_saed command does not work for triclinic cells.
diff --git a/doc/src/compute_slice.txt b/doc/src/compute_slice.txt
index e89c05a0f95a0e2b39d2545a512fe158c4bd39e3..51031aeab3017a4bbfee683c0055165d74fd8c03 100644
--- a/doc/src/compute_slice.txt
+++ b/doc/src/compute_slice.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -58,7 +58,7 @@ page for details. If no bracketed integer is appended, the vector
calculated by the compute is used. If a bracketed integer is
appended, the Ith column of the array calculated by the compute is
used. Users can also write code for their own compute styles and "add
-them to LAMMPS"_Section_modify.html.
+them to LAMMPS"_Modify.html.
If a value begins with "f_", a fix ID must follow which has been
previously defined in the input script and which generates a global
@@ -69,7 +69,7 @@ the values, else an error results. If no bracketed integer is
appended, the vector calculated by the fix is used. If a bracketed
integer is appended, the Ith column of the array calculated by the fix
is used. Users can also write code for their own fix style and "add
-them to LAMMPS"_Section_modify.html.
+them to LAMMPS"_Modify.html.
If an input value begins with "v_", a variable name must follow which
has been previously defined in the input script. Only vector-style
@@ -94,8 +94,8 @@ specified or a global array with N columns where N is the number of
inputs. The length of the vector or the number of rows in the array
is equal to the number of values extracted from each input vector.
These values can be used by any command that uses global vector or
-array values from a compute as input. See "this
-section"_Section_howto.html#howto_15 for an overview of LAMMPS output
+array values from a compute as input. See the "Howto
+output"_Howto_output.html doc page for an overview of LAMMPS output
options.
The vector or array values calculated by this compute are simply
diff --git a/doc/src/compute_smd_contact_radius.txt b/doc/src/compute_smd_contact_radius.txt
index 69fe45334398fb60c77b4582074d0b2309c4f6ff..4ab03e3738c4fcc60378ab988a60c33b1260ad41 100644
--- a/doc/src/compute_smd_contact_radius.txt
+++ b/doc/src/compute_smd_contact_radius.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -35,9 +35,9 @@ specified compute group.
[Output info:]
-This compute calculates a per-particle vector, which can be accessed by
-any command that uses per-particle values from a compute as input. See
-"Section 6.15"_Section_howto.html#howto_15 for an overview of
+This compute calculates a per-particle vector, which can be accessed
+by any command that uses per-particle values from a compute as input.
+See the "Howto output"_Howto_output.html doc page for an overview of
LAMMPS output options.
The per-particle vector values will be in distance "units"_units.html.
@@ -45,8 +45,8 @@ The per-particle vector values will be in distance "units"_units.html.
[Restrictions:]
This compute is part of the USER-SMD package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/compute_smd_damage.txt b/doc/src/compute_smd_damage.txt
index b6c75a3b204532003231bad5f7a61089e9544199..139fb3ec7bfb48e56b56e23af5cce1176f45cdbe 100644
--- a/doc/src/compute_smd_damage.txt
+++ b/doc/src/compute_smd_damage.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -28,18 +28,18 @@ See "this PDF guide"_PDF/SMD_LAMMPS_userguide.pdf to use Smooth Mach Dynamics in
[Output Info:]
-This compute calculates a per-particle vector, which can be accessed by
-any command that uses per-particle values from a compute as input. See
-"How-to discussions, section 6.15"_Section_howto.html#howto_15
-for an overview of LAMMPS output options.
+This compute calculates a per-particle vector, which can be accessed
+by any command that uses per-particle values from a compute as input.
+See the "Howto output"_Howto_output.html doc page for an overview of
+LAMMPS output options.
The per-particle values are dimensionless an in the range of zero to one.
[Restrictions:]
This compute is part of the USER-SMD package. It is only enabled if
-LAMMPS was built with that package. See the "Making LAMMPS"_Section_start.html#start_3
-section for more info.
+LAMMPS was built with that package. See the "Build
+
[Related commands:]
diff --git a/doc/src/compute_smd_hourglass_error.txt b/doc/src/compute_smd_hourglass_error.txt
index a15b79e64e4490e51a9321d06206757589a5c06a..5bc3e3a2decbefdcd3e026e12e1aae6ccf535758 100644
--- a/doc/src/compute_smd_hourglass_error.txt
+++ b/doc/src/compute_smd_hourglass_error.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -37,10 +37,10 @@ Mach Dynamics in LAMMPS.
[Output Info:]
-This compute calculates a per-particle vector, which can be accessed by
-any command that uses per-particle values from a compute as input. See
-"How-to discussions, section 6.15"_Section_howto.html#howto_15
-for an overview of LAMMPS output options.
+This compute calculates a per-particle vector, which can be accessed
+by any command that uses per-particle values from a compute as input.
+See the "Howto output"_Howto_output.html doc page for an overview of
+LAMMPS output options.
The per-particle vector values will are dimensionless. See
"units"_units.html.
@@ -48,8 +48,8 @@ The per-particle vector values will are dimensionless. See
[Restrictions:]
This compute is part of the USER-SMD package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This quantity will be computed only for particles which interact with
tlsph pair style.
diff --git a/doc/src/compute_smd_internal_energy.txt b/doc/src/compute_smd_internal_energy.txt
index bc6f9e0f2068b440c731bbaa6a5710daa8d2c446..b9d18ce933966e161c26a1ecc783e8a2bbc76abe 100644
--- a/doc/src/compute_smd_internal_energy.txt
+++ b/doc/src/compute_smd_internal_energy.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -31,18 +31,18 @@ Mach Dynamics in LAMMPS.
This compute calculates a per-particle vector, which can be accessed
by any command that uses per-particle values from a compute as input.
-See "How-to discussions, section 6.15"_Section_howto.html#howto_15 for
-an overview of LAMMPS output options.
+See the "Howto output"_Howto_output.html doc page for an overview of
+LAMMPS output options.
The per-particle vector values will be given in "units"_units.html of energy.
[Restrictions:]
This compute is part of the USER-SMD package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info. This compute
-can only be used for particles which interact via the updated
-Lagrangian or total Lagrangian SPH pair styles.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info. This compute can
+only be used for particles which interact via the updated Lagrangian
+or total Lagrangian SPH pair styles.
[Related Commands:]
diff --git a/doc/src/compute_smd_plastic_strain.txt b/doc/src/compute_smd_plastic_strain.txt
index af5b1644534adcd3c624109aadf0f69205db78c6..d12be7222a23744d489b6a1153bae16fb91f6753 100644
--- a/doc/src/compute_smd_plastic_strain.txt
+++ b/doc/src/compute_smd_plastic_strain.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -32,18 +32,18 @@ Mach Dynamics in LAMMPS.
This compute calculates a per-particle vector, which can be accessed
by any command that uses per-particle values from a compute as input.
-See "How-to discussions, section 6.15"_Section_howto.html#howto_15 for
-an overview of LAMMPS output options.
+See the "Howto output"_Howto_output.html doc page for an overview of
+LAMMPS output options.
The per-particle values will be given dimensionless. See "units"_units.html.
[Restrictions:]
This compute is part of the USER-SMD package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info. This compute
-can only be used for particles which interact via the updated
-Lagrangian or total Lagrangian SPH pair styles.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info. This compute can
+only be used for particles which interact via the updated Lagrangian
+or total Lagrangian SPH pair styles.
[Related commands:]
diff --git a/doc/src/compute_smd_plastic_strain_rate.txt b/doc/src/compute_smd_plastic_strain_rate.txt
index ba7b3176dbf538f25802ec53eb0e4a12b2db3cff..ffc009b2a70978a272f9184b71ca6b1828dc768a 100644
--- a/doc/src/compute_smd_plastic_strain_rate.txt
+++ b/doc/src/compute_smd_plastic_strain_rate.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -32,18 +32,18 @@ Mach Dynamics in LAMMPS.
This compute calculates a per-particle vector, which can be accessed
by any command that uses per-particle values from a compute as input.
-See "How-to discussions, section 6.15"_Section_howto.html#howto_15 for
-an overview of LAMMPS output options.
+See the "Howto output"_Howto_output.html doc page for an overview of
+LAMMPS output options.
The per-particle values will be given in "units"_units.html of one over time.
[Restrictions:]
This compute is part of the USER-SMD package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info. This compute
-can only be used for particles which interact via the updated
-Lagrangian or total Lagrangian SPH pair styles.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info. This compute can
+only be used for particles which interact via the updated Lagrangian
+or total Lagrangian SPH pair styles.
[Related commands:]
diff --git a/doc/src/compute_smd_rho.txt b/doc/src/compute_smd_rho.txt
index ae50526725e091a21b80a1a1b0c8c39680fbf031..31d7351c92e2aaeb55f53c71bd7fe75be82df9bc 100644
--- a/doc/src/compute_smd_rho.txt
+++ b/doc/src/compute_smd_rho.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -33,16 +33,16 @@ Mach Dynamics in LAMMPS.
This compute calculates a per-particle vector, which can be accessed
by any command that uses per-particle values from a compute as input.
-See "How-to discussions, section 6.15"_Section_howto.html#howto_15 for
-an overview of LAMMPS output options.
+See the "Howto output"_Howto_output.html doc page for an overview of
+LAMMPS output options.
The per-particle values will be in "units"_units.html of mass over volume.
[Restrictions:]
This compute is part of the USER-SMD package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/compute_smd_tlsph_defgrad.txt b/doc/src/compute_smd_tlsph_defgrad.txt
index 68b5dffa1cf558df517156e61bc604604bbfa113..a733a3d6a75f1394889be1c13eb402b146a1edc5 100644
--- a/doc/src/compute_smd_tlsph_defgrad.txt
+++ b/doc/src/compute_smd_tlsph_defgrad.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -32,9 +32,8 @@ Mach Dynamics in LAMMPS.
This compute outputss a per-particle vector of vectors (tensors),
which can be accessed by any command that uses per-particle values
-from a compute as input. See "How-to discussions, section
-6.15"_Section_howto.html#howto_15 for an overview of LAMMPS output
-options.
+from a compute as input. See the "Howto output"_Howto_output.html doc
+page for an overview of LAMMPS output options.
The per-particle vector values will be given dimensionless. See
"units"_units.html. The per-particle vector has 10 entries. The first
@@ -45,10 +44,10 @@ entry is the determinant of the deformation gradient.
[Restrictions:]
This compute is part of the USER-SMD package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info. TThis
-compute can only be used for particles which interact via the total
-Lagrangian SPH pair style.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info. TThis compute can
+only be used for particles which interact via the total Lagrangian SPH
+pair style.
[Related commands:]
diff --git a/doc/src/compute_smd_tlsph_dt.txt b/doc/src/compute_smd_tlsph_dt.txt
index 560a9b6fd878386ff140cba30ecf879a62cdc047..92f5923de05f735931aae9908844b197ad127fe3 100644
--- a/doc/src/compute_smd_tlsph_dt.txt
+++ b/doc/src/compute_smd_tlsph_dt.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -37,16 +37,16 @@ Mach Dynamics in LAMMPS.
This compute calculates a per-particle vector, which can be accessed
by any command that uses per-particle values from a compute as input.
-See "How-to discussions, section 6.15"_Section_howto.html#howto_15 for
-an overview of LAMMPS output options.
+See the "Howto output"_Howto_output.html doc page for an overview of
+LAMMPS output options.
The per-particle values will be given in "units"_units.html of time.
[Restrictions:]
This compute is part of the USER-SMD package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This compute can only be used for particles interacting with the
Total-Lagrangian SPH pair style.
diff --git a/doc/src/compute_smd_tlsph_num_neighs.txt b/doc/src/compute_smd_tlsph_num_neighs.txt
index 0420d1903d82c6d4af44e519b309e0da27813293..db977fe676b5185f39088c96e2a5157dda30a30f 100644
--- a/doc/src/compute_smd_tlsph_num_neighs.txt
+++ b/doc/src/compute_smd_tlsph_num_neighs.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -32,16 +32,16 @@ Mach Dynamics in LAMMPS.
This compute calculates a per-particle vector, which can be accessed
by any command that uses per-particle values from a compute as input.
-See "How-to discussions, section 6.15"_Section_howto.html#howto_15 for
-an overview of LAMMPS output options.
+See the "Howto output"_Howto_output.html doc page for an overview of
+LAMMPS output options.
The per-particle values are dimensionless. See "units"_units.html.
[Restrictions:]
This compute is part of the USER-SMD package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This quantity will be computed only for particles which interact with
the Total-Lagrangian pair style.
diff --git a/doc/src/compute_smd_tlsph_shape.txt b/doc/src/compute_smd_tlsph_shape.txt
index 02bd0c50ddb504d7effd71d7155e5cc39c7a4378..9c17194ec18ed8c40fc775b4d68aa9ef54bf9e69 100644
--- a/doc/src/compute_smd_tlsph_shape.txt
+++ b/doc/src/compute_smd_tlsph_shape.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -33,9 +33,8 @@ Mach Dynamics in LAMMPS.
This compute calculates a per-particle vector of vectors, which can be
accessed by any command that uses per-particle values from a compute
-as input. See "How-to discussions, section
-6.15"_Section_howto.html#howto_15 for an overview of LAMMPS output
-options.
+as input. See the "Howto output"_Howto_output.html doc page for an
+overview of LAMMPS output options.
The per-particle vector has 7 entries. The first three entries
correspond to the lengths of the ellipsoid's axes and have units of
@@ -48,8 +47,8 @@ particle relative to its initial state.
[Restrictions:]
This compute is part of the USER-SMD package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This quantity will be computed only for particles which interact with
the Total-Lagrangian SPH pair style.
diff --git a/doc/src/compute_smd_tlsph_strain.txt b/doc/src/compute_smd_tlsph_strain.txt
index f25d1b77db2c32cc25a2d7a3dd64466db1370c20..70f996e2064f0dc530844b825e8116f10b04b94b 100644
--- a/doc/src/compute_smd_tlsph_strain.txt
+++ b/doc/src/compute_smd_tlsph_strain.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -31,9 +31,8 @@ Mach Dynamics in LAMMPS.
This compute calculates a per-particle vector of vectors (tensors),
which can be accessed by any command that uses per-particle values
-from a compute as input. See "How-to discussions, section
-6.15"_Section_howto.html#howto_15 for an overview of LAMMPS output
-options.
+from a compute as input. See the "Howto output"_Howto_output.html doc
+page for an overview of LAMMPS output options.
The per-particle tensor values will be given dimensionless. See
"units"_units.html.
@@ -44,8 +43,8 @@ zz, xy, xz, yz components of the symmetric strain tensor.
[Restrictions:]
This compute is part of the USER-SMD package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This quantity will be computed only for particles which interact with
the Total-Lagrangian SPH pair style.
diff --git a/doc/src/compute_smd_tlsph_strain_rate.txt b/doc/src/compute_smd_tlsph_strain_rate.txt
index 13ca57ac4df413e8348a37d34d49fa606239243e..e6d968c523d62ce483b05a5a4522959bf4f6e2cb 100644
--- a/doc/src/compute_smd_tlsph_strain_rate.txt
+++ b/doc/src/compute_smd_tlsph_strain_rate.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -31,9 +31,8 @@ Mach Dynamics in LAMMPS.
This compute calculates a per-particle vector of vectors (tensors),
which can be accessed by any command that uses per-particle values
-from a compute as input. See "How-to discussions, section
-6.15"_Section_howto.html#howto_15 for an overview of LAMMPS output
-options.
+from a compute as input. See the "Howto output"_Howto_output.html doc
+page for an overview of LAMMPS output options.
The values will be given in "units"_units.html of one over time.
@@ -43,8 +42,8 @@ zz, xy, xz, yz components of the symmetric strain rate tensor.
[Restrictions:]
This compute is part of the USER-SMD package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This quantity will be computed only for particles which interact with
Total-Lagrangian SPH pair style.
diff --git a/doc/src/compute_smd_tlsph_stress.txt b/doc/src/compute_smd_tlsph_stress.txt
index 5d707d4c2f6934cd0b630de1767a43f33b9de46c..8340e885363c43c931f6734ffdbd2a415d74f74b 100644
--- a/doc/src/compute_smd_tlsph_stress.txt
+++ b/doc/src/compute_smd_tlsph_stress.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -29,11 +29,10 @@ Mach Dynamics in LAMMPS.
[Output info:]
-This compute calculates a per-particle vector of vectors (tensors), which can be
-accessed by any command that uses per-particle values from a compute
-as input. See
-"How-to discussions, section 6.15"_Section_howto.html#howto_15
-for an overview of LAMMPS output options.
+This compute calculates a per-particle vector of vectors (tensors),
+which can be accessed by any command that uses per-particle values
+from a compute as input. See the "Howto output"_Howto_output.html doc
+page for an overview of LAMMPS output options.
The values will be given in "units"_units.html of pressure.
@@ -45,8 +44,8 @@ invariant of the stress tensor, i.e., the von Mises equivalent stress.
[Restrictions:]
This compute is part of the USER-SMD package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This quantity will be computed only for particles which interact with
the Total-Lagrangian SPH pair style.
diff --git a/doc/src/compute_smd_triangle_mesh_vertices.txt b/doc/src/compute_smd_triangle_mesh_vertices.txt
index 5b0f0afc4c84a93f0b1f31307da9d7a89197abbe..cd1f8fdd9b29b007ae0f3f0a28a491b7dee2fd7e 100644
--- a/doc/src/compute_smd_triangle_mesh_vertices.txt
+++ b/doc/src/compute_smd_triangle_mesh_vertices.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -31,9 +31,9 @@ Mach Dynamics in LAMMPS.
[Output info:]
This compute returns a per-particle vector of vectors, which can be
-accessed by any command that uses per-particle values from a compute as
-input. See "How-to discussions, section 6.15"_Section_howto.html#howto_15
-for an overview of LAMMPS output options.
+accessed by any command that uses per-particle values from a compute
+as input. See the "Howto output"_Howto_output.html doc page for an
+overview of LAMMPS output options.
The per-particle vector has nine entries, (x1/y1/z1), (x2/y2/z2), and
(x3/y3/z3) corresponding to the first, second, and third vertex of
@@ -51,8 +51,8 @@ The values will be given in "units"_units.html of distance.
[Restrictions:]
This compute is part of the USER-SMD package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/compute_smd_ulsph_num_neighs.txt b/doc/src/compute_smd_ulsph_num_neighs.txt
index adece9334361d154d3f7d7a62de19b0eaac01a93..5157f17e578e80ec2a8799b63ea894c5ffc60ac5 100644
--- a/doc/src/compute_smd_ulsph_num_neighs.txt
+++ b/doc/src/compute_smd_ulsph_num_neighs.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -32,7 +32,7 @@ Mach Dynamics in LAMMPS.
This compute returns a per-particle vector, which can be accessed by
any command that uses per-particle values from a compute as input.
-See "Section 6.15"_Section_howto.html#howto_15 for an overview of
+See the "Howto output"_Howto_output.html doc page for an overview of
LAMMPS output options.
The per-particle values will be given dimensionless, see "units"_units.html.
@@ -40,10 +40,10 @@ The per-particle values will be given dimensionless, see "units"_units.html.
[Restrictions:]
This compute is part of the USER-SMD package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_2 section for more info. This compute
-can only be used for particles which interact with the updated
-Lagrangian SPH pair style.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info. This compute can
+only be used for particles which interact with the updated Lagrangian
+SPH pair style.
[Related commands:]
diff --git a/doc/src/compute_smd_ulsph_strain.txt b/doc/src/compute_smd_ulsph_strain.txt
index b7d425b12b7e1b0146ba321986e56470719b115f..3dc6bd5249439a82cc76d12bd519f3f1803bbd27 100644
--- a/doc/src/compute_smd_ulsph_strain.txt
+++ b/doc/src/compute_smd_ulsph_strain.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -31,7 +31,7 @@ Mach Dynamics in LAMMPS.
This compute calculates a per-particle tensor, which can be accessed
by any command that uses per-particle values from a compute as input.
-See "Section 6.15"_Section_howto.html#howto_15 for an overview of
+See the "Howto output"_Howto_output.html doc page for an overview of
LAMMPS output options.
The per-particle vector has 6 entries, corresponding to the xx, yy,
@@ -43,10 +43,10 @@ The per-particle tensor values will be given dimensionless, see
[Restrictions:]
This compute is part of the USER-SMD package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info. This compute
-can only be used for particles which interact with the updated
-Lagrangian SPH pair style.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info. This compute can
+only be used for particles which interact with the updated Lagrangian
+SPH pair style.
[Related commands:]
diff --git a/doc/src/compute_smd_ulsph_strain_rate.txt b/doc/src/compute_smd_ulsph_strain_rate.txt
index e2c349c2656de89aaa53534f3980e235caa17901..1ade5ac2d5a8b77c950d4dfab582ad95aafa52e4 100644
--- a/doc/src/compute_smd_ulsph_strain_rate.txt
+++ b/doc/src/compute_smd_ulsph_strain_rate.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -32,9 +32,8 @@ Mach Dynamics in LAMMPS.
This compute calculates a per-particle vector of vectors (tensors),
which can be accessed by any command that uses per-particle values
-from a compute as input. See "Section
-6.15"_Section_howto.html#howto_15 for an overview of LAMMPS output
-options.
+from a compute as input. See the "Howto output"_Howto_output.html doc
+page for an overview of LAMMPS output options.
The values will be given in "units"_units.html of one over time.
@@ -44,10 +43,11 @@ zz, xy, xz, yz components of the symmetric strain rate tensor.
[Restrictions:]
This compute is part of the USER-SMD package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_2 section for more info. This compute
-can only be used for particles which interact with the updated
-Lagrangian SPH pair style.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
+
+This compute can only be used for particles which interact with the
+updated Lagrangian SPH pair style.
[Related commands:]
diff --git a/doc/src/compute_smd_ulsph_stress.txt b/doc/src/compute_smd_ulsph_stress.txt
index 47f903d3b88effc7055084674b0866fe5ad4b596..ff53e777c50615386d28db11a07a46ec682c0563 100644
--- a/doc/src/compute_smd_ulsph_stress.txt
+++ b/doc/src/compute_smd_ulsph_stress.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -30,9 +30,8 @@ Mach Dynamics in LAMMPS.
This compute calculates a per-particle vector of vectors (tensors),
which can be accessed by any command that uses per-particle values
-from a compute as input. See "Section
-6.15"_Section_howto.html#howto_15 for an overview of LAMMPS output
-options.
+from a compute as input. See the "Howto output"_Howto_output.html doc
+page for an overview of LAMMPS output options.
The values will be given in "units"_units.html of pressure.
@@ -44,10 +43,10 @@ stress tensor, i.e., the von Mises equivalent stress.
[Restrictions:]
This compute is part of the USER-SMD package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info. This compute
-can only be used for particles which interact with the updated
-Lagrangian SPH pair style.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info. This compute can
+only be used for particles which interact with the updated Lagrangian
+SPH pair style.
[Related commands:]
diff --git a/doc/src/compute_smd_vol.txt b/doc/src/compute_smd_vol.txt
index fc736a5bf5c2fd0e9c6d89b749acb11d6d79d1e1..0edd61f624228972e7090aa15549b2361b24d0c8 100644
--- a/doc/src/compute_smd_vol.txt
+++ b/doc/src/compute_smd_vol.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -31,8 +31,8 @@ Mach Dynamics in LAMMPS.
This compute calculates a per-particle vector, which can be accessed
by any command that uses per-particle values from a compute as input.
-See "How-to discussions, section 6.15"_Section_howto.html#howto_15 for
-an overview of LAMMPS output options.
+See the "Howto output"_Howto_output.html doc page for an overview of
+LAMMPS output options.
The per-particle vector values will be given in "units"_units.html of
volume.
@@ -43,8 +43,8 @@ per-particle volumes of the group for which the fix is defined.
[Restrictions:]
This compute is part of the USER-SMD package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/compute_sna_atom.txt b/doc/src/compute_sna_atom.txt
index 268e23ac2808d82f8750b95bd652cd4d50f6b9d2..95d183937f8db2d79e202af0796c814b000b0ca2 100644
--- a/doc/src/compute_sna_atom.txt
+++ b/doc/src/compute_sna_atom.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -244,15 +244,14 @@ So the nesting order from inside to outside is bispectrum component,
linear then quadratic, vector/tensor component, type.
These values can be accessed by any command that uses per-atom values
-from a compute as input. See "Section
-6.15"_Section_howto.html#howto_15 for an overview of LAMMPS output
-options.
+from a compute as input. See the "Howto output"_Howto_output.html doc
+page for an overview of LAMMPS output options.
[Restrictions:]
These computes are part of the SNAP package. They are only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/compute_spin.txt b/doc/src/compute_spin.txt
index fcc764c14cb0f7cc88869655bf8d2df1f745c777..787ff8cdcfa822ba37c896d464e6c9655d5e543a 100644
--- a/doc/src/compute_spin.txt
+++ b/doc/src/compute_spin.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -61,10 +61,10 @@ metal units ("units"_units.html).
[Restrictions:]
-The {spin} compute is part of the SPIN package.
-This compute is only enabled if LAMMPS was built with this package.
-See the "Making LAMMPS"_Section_start.html#start_3 section for more info.
-The atom_style has to be "spin" for this compute to be valid.
+The {spin} compute is part of the SPIN package. This compute is only
+enabled if LAMMPS was built with this package. See the "Build
+package"_Build_package.html doc page for more info. The atom_style
+has to be "spin" for this compute to be valid.
[Related commands:] none
diff --git a/doc/src/compute_stress_atom.txt b/doc/src/compute_stress_atom.txt
index 83b1df68e3555e4d74b4c0296845fc6a395148e7..222513da61d45e22238a38780c39977ec3900b68 100644
--- a/doc/src/compute_stress_atom.txt
+++ b/doc/src/compute_stress_atom.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -142,9 +142,8 @@ global system pressure.
This compute calculates a per-atom array with 6 columns, which can be
accessed by indices 1-6 by any command that uses per-atom values from
-a compute as input. See "Section
-6.15"_Section_howto.html#howto_15 for an overview of LAMMPS output
-options.
+a compute as input. See the "Howto output"_Howto_output.html doc page
+for an overview of LAMMPS output options.
The per-atom array values will be in pressure*volume
"units"_units.html as discussed above.
diff --git a/doc/src/compute_tally.txt b/doc/src/compute_tally.txt
index 95ef4a553b8df78af94dd0d51a7fc48c12d313fb..a4a8441f9ec4e7555f977b454a56f3f8ffb137b0 100644
--- a/doc/src/compute_tally.txt
+++ b/doc/src/compute_tally.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -76,9 +76,9 @@ Both the scalar and vector values calculated by this compute are
[Restrictions:]
-This compute is part of the USER-TALLY package. It is only enabled
-if LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+This compute is part of the USER-TALLY package. It is only enabled if
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
Not all pair styles can be evaluated in a pairwise mode as required by
this compute. For example, 3-body and other many-body potentials,
diff --git a/doc/src/compute_tdpd_cc_atom.txt b/doc/src/compute_tdpd_cc_atom.txt
index a6a12dc52ccb31febe7a8bc5559b50913e0f242a..a385bef10b612c9e5a4a485570c82e406f83ff16 100644
--- a/doc/src/compute_tdpd_cc_atom.txt
+++ b/doc/src/compute_tdpd_cc_atom.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -33,9 +33,9 @@ details see "(Li2015)"_#Li2015a.
[Output info:]
This compute calculates a per-atom vector, which can be accessed by
-any command that uses per-atom values from a compute as input. See
-"Section 6.15"_Section_howto.html#howto_15 for an overview of
-LAMMPS output options.
+any command that uses per-atom values from a compute as input. See the
+"Howto output"_Howto_output.html doc page for an overview of LAMMPS
+output options.
The per-atom vector values will be in the units of chemical species
per unit mass.
@@ -43,8 +43,8 @@ per unit mass.
[Restrictions:]
This compute is part of the USER-MESO package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/compute_temp.txt b/doc/src/compute_temp.txt
index b88be79e20704a41482ad444668ca8b81d0c4b32..757e00c4d2f3e57ba70ccd180acc69099ee0e325 100644
--- a/doc/src/compute_temp.txt
+++ b/doc/src/compute_temp.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -58,8 +58,8 @@ compute thermo_temp all temp :pre
See the "thermo_style" command for more details.
-See "this howto section"_Section_howto.html#howto_16 of the manual for
-a discussion of different ways to compute temperature and perform
+See the "Howto thermostat"_Howto_thermostat.html doc page for a
+discussion of different ways to compute temperature and perform
thermostatting.
:line
@@ -67,23 +67,22 @@ thermostatting.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -92,8 +91,8 @@ more instructions on how to use the accelerated styles effectively.
This compute calculates a global scalar (the temperature) and a global
vector of length 6 (KE tensor), which can be accessed by indices 1-6.
These values can be used by any command that uses global scalar or
-vector values from a compute as input. See "this
-section"_Section_howto.html#howto_15 for an overview of LAMMPS output
+vector values from a compute as input. See the "Howto
+output"_Howto_output.html doc page for an overview of LAMMPS output
options.
The scalar value calculated by this compute is "intensive". The
diff --git a/doc/src/compute_temp_asphere.txt b/doc/src/compute_temp_asphere.txt
index 495366b34501b65e785bff5ec6e442ff02e89b96..eb73891e82572001a3834f292a373772edf9b396 100644
--- a/doc/src/compute_temp_asphere.txt
+++ b/doc/src/compute_temp_asphere.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -93,8 +93,8 @@ computed correctly. If needed, the subtracted degrees-of-freedom can
be altered using the {extra} option of the
"compute_modify"_compute_modify.html command.
-See "this howto section"_Section_howto.html#howto_16 of the manual for
-a discussion of different ways to compute temperature and perform
+See the "Howto thermostat"_Howto_thermostat.html doc page for a
+discussion of different ways to compute temperature and perform
thermostatting.
:line
@@ -122,8 +122,8 @@ rotational degrees of freedom.
This compute calculates a global scalar (the temperature) and a global
vector of length 6 (KE tensor), which can be accessed by indices 1-6.
These values can be used by any command that uses global scalar or
-vector values from a compute as input. See "this
-section"_Section_howto.html#howto_15 for an overview of LAMMPS output
+vector values from a compute as input. See the "Howto
+output"_Howto_output.html doc page for an overview of LAMMPS output
options.
The scalar value calculated by this compute is "intensive". The
@@ -135,8 +135,8 @@ vector values will be in energy "units"_units.html.
[Restrictions:]
This compute is part of the ASPHERE package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This compute requires that atoms store angular momentum and a
quaternion as defined by the "atom_style ellipsoid"_atom_style.html
diff --git a/doc/src/compute_temp_body.txt b/doc/src/compute_temp_body.txt
index f72b886cc47afa0b0f7badd75b39ef943375002d..341d6d7f792c7815c540b03c25c480b212df9deb 100644
--- a/doc/src/compute_temp_body.txt
+++ b/doc/src/compute_temp_body.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -75,8 +75,8 @@ computed correctly. If needed, the subtracted degrees-of-freedom can
be altered using the {extra} option of the
"compute_modify"_compute_modify.html command.
-See "this howto section"_Section_howto.html#howto_16 of the manual for
-a discussion of different ways to compute temperature and perform
+See the "Howto thermostat"_Howto_thermostat.html doc page for a
+discussion of different ways to compute temperature and perform
thermostatting.
:line
@@ -104,8 +104,8 @@ rotational degrees of freedom.
This compute calculates a global scalar (the temperature) and a global
vector of length 6 (KE tensor), which can be accessed by indices 1-6.
These values can be used by any command that uses global scalar or
-vector values from a compute as input. See "this
-section"_Section_howto.html#howto_15 for an overview of LAMMPS output
+vector values from a compute as input. See the "Howto
+output"_Howto_output.html doc page for an overview of LAMMPS output
options.
The scalar value calculated by this compute is "intensive". The
@@ -117,8 +117,8 @@ vector values will be in energy "units"_units.html.
[Restrictions:]
This compute is part of the BODY package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This compute requires that atoms store angular momentum and a
quaternion as defined by the "atom_style body"_atom_style.html
diff --git a/doc/src/compute_temp_chunk.txt b/doc/src/compute_temp_chunk.txt
index f877f6ece84b9a2429d64949eea298e20d98ef74..de8c850a7087329465e84544a2084309602a80d1 100644
--- a/doc/src/compute_temp_chunk.txt
+++ b/doc/src/compute_temp_chunk.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -52,10 +52,9 @@ chunk/atom"_compute_chunk_atom.html command, which assigns each atom
to a single chunk (or no chunk). The ID for this command is specified
as chunkID. For example, a single chunk could be the atoms in a
molecule or atoms in a spatial bin. See the "compute
-chunk/atom"_compute_chunk_atom.html doc page and "Section
-6.23"_Section_howto.html#howto_23 for details of how chunks can be
-defined and examples of how they can be used to measure properties of
-a system.
+chunk/atom"_compute_chunk_atom.html and "Howto chunk"_Howto_chunk.html
+doc pages for details of how chunks can be defined and examples of how
+they can be used to measure properties of a system.
The temperature is calculated by the formula KE = DOF/2 k T, where KE =
total kinetic energy of all atoms assigned to chunks (sum of 1/2 m
@@ -200,8 +199,8 @@ molecule.
This compute calculates a global scalar (the temperature) and a global
vector of length 6 (KE tensor), which can be accessed by indices 1-6.
These values can be used by any command that uses global scalar or
-vector values from a compute as input. See "this
-section"_Section_howto.html#howto_15 for an overview of LAMMPS output
+vector values from a compute as input. See the "Howto
+output"_Howto_output.html doc page for an overview of LAMMPS output
options.
This compute also optionally calculates a global array, if one or more
@@ -210,9 +209,8 @@ of the optional values are specified. The number of rows in the array
"compute chunk/atom"_compute_chunk_atom.html command. The number of
columns is the number of specified values (1 or more). These values
can be accessed by any command that uses global array values from a
-compute as input. Again, see "Section
-6.15"_Section_howto.html#howto_15 for an overview of LAMMPS output
-options.
+compute as input. Again, see the "Howto output"_Howto_output.html doc
+page for an overview of LAMMPS output options.
The scalar value calculated by this compute is "intensive". The
vector values are "extensive". The array values are "intensive".
diff --git a/doc/src/compute_temp_com.txt b/doc/src/compute_temp_com.txt
index c7cc5ec4e280db434892260b9b2d7d045515d765..12df694e382657c9424e8b0649a4dd677a2630d6 100644
--- a/doc/src/compute_temp_com.txt
+++ b/doc/src/compute_temp_com.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -65,8 +65,8 @@ atoms that include these constraints will be computed correctly. If
needed, the subtracted degrees-of-freedom can be altered using the
{extra} option of the "compute_modify"_compute_modify.html command.
-See "this howto section"_Section_howto.html#howto_16 of the manual for
-a discussion of different ways to compute temperature and perform
+See the "Howto thermostat"_Howto_thermostat.html doc page for a
+discussion of different ways to compute temperature and perform
thermostatting.
[Output info:]
@@ -74,8 +74,8 @@ thermostatting.
This compute calculates a global scalar (the temperature) and a global
vector of length 6 (KE tensor), which can be accessed by indices 1-6.
These values can be used by any command that uses global scalar or
-vector values from a compute as input. See "this
-section"_Section_howto.html#howto_15 for an overview of LAMMPS output
+vector values from a compute as input. See the "Howto
+output"_Howto_output.html doc page for an overview of LAMMPS output
options.
The scalar value calculated by this compute is "intensive". The
diff --git a/doc/src/compute_temp_cs.txt b/doc/src/compute_temp_cs.txt
index 561b787df637b48a69173f2f863ccec871e4855b..0236319f547a2a71e5f533f797ffb191e6e8254d 100644
--- a/doc/src/compute_temp_cs.txt
+++ b/doc/src/compute_temp_cs.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -28,9 +28,9 @@ Define a computation that calculates the temperature of a system based
on the center-of-mass velocity of atom pairs that are bonded to each
other. This compute is designed to be used with the adiabatic
core/shell model of "(Mitchell and Finchham)"_#MitchellFinchham1. See
-"Section 6.25"_Section_howto.html#howto_25 of the manual for an
-overview of the model as implemented in LAMMPS. Specifically, this
-compute enables correct temperature calculation and thermostatting of
+the "Howto coreshell"_Howto_coreshell.html doc page for an overview of
+the model as implemented in LAMMPS. Specifically, this compute
+enables correct temperature calculation and thermostatting of
core/shell pairs where it is desirable for the internal degrees of
freedom of the core/shell pairs to not be influenced by a thermostat.
A compute of this style can be used by any command that computes a
@@ -83,8 +83,9 @@ langevin"_fix_langevin.html.
The internal energy of core/shell pairs can be calculated by the
"compute temp/chunk"_compute_temp_chunk.html command, if chunks are
-defined as core/shell pairs. See "Section
-6.25"_Section_howto.html#howto_25 for more discussion on how to do this.
+defined as core/shell pairs. See the "Howto
+coreshell"_Howto_coreshell.html doc page doc page for more discussion
+on how to do this.
[Output info:]
diff --git a/doc/src/compute_temp_deform.txt b/doc/src/compute_temp_deform.txt
index 168b0b3880b2ec25e2040b17d135d874709dc68a..26d322589ed70d49d23a0ac8948fc4524e04daef 100644
--- a/doc/src/compute_temp_deform.txt
+++ b/doc/src/compute_temp_deform.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -104,8 +104,8 @@ atoms that include these constraints will be computed correctly. If
needed, the subtracted degrees-of-freedom can be altered using the
{extra} option of the "compute_modify"_compute_modify.html command.
-See "this howto section"_Section_howto.html#howto_16 of the manual for
-a discussion of different ways to compute temperature and perform
+See the "Howto thermostat"_Howto_thermostat.html doc page for a
+discussion of different ways to compute temperature and perform
thermostatting.
[Output info:]
@@ -113,8 +113,8 @@ thermostatting.
This compute calculates a global scalar (the temperature) and a global
vector of length 6 (KE tensor), which can be accessed by indices 1-6.
These values can be used by any command that uses global scalar or
-vector values from a compute as input. See "this
-section"_Section_howto.html#howto_15 for an overview of LAMMPS output
+vector values from a compute as input. See the "Howto
+output"_Howto_output.html doc page for an overview of LAMMPS output
options.
The scalar value calculated by this compute is "intensive". The
diff --git a/doc/src/compute_temp_deform_eff.txt b/doc/src/compute_temp_deform_eff.txt
index d09a0ace2fbb449fd969dc63532402cfa2c3c06a..4af61dc91867890533ea9a4f20606275bf4e3d07 100644
--- a/doc/src/compute_temp_deform_eff.txt
+++ b/doc/src/compute_temp_deform_eff.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -48,8 +48,8 @@ component of the electrons is not affected.
This compute calculates a global scalar (the temperature) and a global
vector of length 6 (KE tensor), which can be accessed by indices 1-6.
These values can be used by any command that uses global scalar or
-vector values from a compute as input. See "this
-section"_Section_howto.html#howto_15 for an overview of LAMMPS output
+vector values from a compute as input. See the "Howto
+output"_Howto_output.html doc page for an overview of LAMMPS output
options.
The scalar value calculated by this compute is "intensive". The
@@ -61,8 +61,8 @@ vector values will be in energy "units"_units.html.
[Restrictions:]
This compute is part of the USER-EFF package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/compute_temp_drude.txt b/doc/src/compute_temp_drude.txt
index 169b8d588086cefdac9aa0db42fc05ab95b18587..20d9a5c05670a66938a70bb85660cd6b79bc100a 100644
--- a/doc/src/compute_temp_drude.txt
+++ b/doc/src/compute_temp_drude.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -22,10 +22,10 @@ compute TDRUDE all temp/drude :pre
[Description:]
Define a computation that calculates the temperatures of core-Drude
-pairs. This compute is designed to be used with the
-"thermalized Drude oscillator model"_tutorial_drude.html. Polarizable
-models in LAMMPS are described in "this
-Section"_Section_howto.html#howto_25.
+pairs. This compute is designed to be used with the "thermalized Drude
+oscillator model"_Howto_drude.html. Polarizable models in LAMMPS
+are described on the "Howto polarizable"_Howto_polarizable.html doc
+page.
Drude oscillators consist of a core particle and a Drude particle
connected by a harmonic bond, and the relative motion of these Drude
@@ -57,8 +57,8 @@ kinetic energy of the centers of mass (energy units)
kinetic energy of the dipoles (energy units) :ol
These values can be used by any command that uses global scalar or
-vector values from a compute as input. See "this
-section"_Section_howto.html#howto_15 for an overview of LAMMPS output
+vector values from a compute as input. See the "Howto
+output"_Howto_output.html doc page for an overview of LAMMPS output
options.
Both the scalar value and the first two values of the vector
diff --git a/doc/src/compute_temp_eff.txt b/doc/src/compute_temp_eff.txt
index 409319edcb9f3a89ffc38d43892a8539073c13ba..415cb775956ec3e759e0dfa6c2209c9e4b68520d 100644
--- a/doc/src/compute_temp_eff.txt
+++ b/doc/src/compute_temp_eff.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -69,8 +69,8 @@ atoms that include these constraints will be computed correctly. If
needed, the subtracted degrees-of-freedom can be altered using the
{extra} option of the "compute_modify"_compute_modify.html command.
-See "this howto section"_Section_howto.html#howto_16 of the manual for
-a discussion of different ways to compute temperature and perform
+See the "Howto thermostat"_Howto_thermostat.html doc page for a
+discussion of different ways to compute temperature and perform
thermostatting.
[Output info:]
@@ -83,8 +83,8 @@ the simulation.
[Restrictions:]
This compute is part of the USER-EFF package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/compute_temp_partial.txt b/doc/src/compute_temp_partial.txt
index fe2420b4e40d8d28e0b824d8022b8322596877f6..14294842a15b11c11461618224b663840b1dce0c 100644
--- a/doc/src/compute_temp_partial.txt
+++ b/doc/src/compute_temp_partial.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -65,8 +65,8 @@ atoms that include these constraints will be computed correctly. If
needed, the subtracted degrees-of-freedom can be altered using the
{extra} option of the "compute_modify"_compute_modify.html command.
-See "this howto section"_Section_howto.html#howto_16 of the manual for
-a discussion of different ways to compute temperature and perform
+See the "Howto thermostat"_Howto_thermostat.html doc page for a
+discussion of different ways to compute temperature and perform
thermostatting.
:line
@@ -74,23 +74,22 @@ thermostatting.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -99,8 +98,8 @@ more instructions on how to use the accelerated styles effectively.
This compute calculates a global scalar (the temperature) and a global
vector of length 6 (KE tensor), which can be accessed by indices 1-6.
These values can be used by any command that uses global scalar or
-vector values from a compute as input. See "this
-section"_Section_howto.html#howto_15 for an overview of LAMMPS output
+vector values from a compute as input. See the "Howto
+output"_Howto_output.html doc page for an overview of LAMMPS output
options.
The scalar value calculated by this compute is "intensive". The
diff --git a/doc/src/compute_temp_profile.txt b/doc/src/compute_temp_profile.txt
index 64a6abd283986747d01514a2e53d9fb3ca2cb1b3..4ed04ca67e0e0c07ebc3250829ad4f9486c791d2 100644
--- a/doc/src/compute_temp_profile.txt
+++ b/doc/src/compute_temp_profile.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -122,8 +122,8 @@ degrees-of-freedom adjustment described in the preceding paragraph,
for fixes that constrain molecular motion. It does include the
adjustment due to the {extra} option, which is applied to each bin.
-See "this howto section"_Section_howto.html#howto_16 of the manual for
-a discussion of different ways to compute temperature and perform
+See the "Howto thermostat"_Howto_thermostat.html doc page for a
+discussion of different ways to compute temperature and perform
thermostatting. Using this compute in conjunction with a
thermostatting fix, as explained there, will effectively implement a
profile-unbiased thermostat (PUT), as described in "(Evans)"_#Evans1.
@@ -145,8 +145,8 @@ indices ix,iy,iz = 2,3,4 would map to row M = (iz-1)*10*10 + (iy-1)*10
indices are numbered from 1 to 10 in each dimension.
These values can be used by any command that uses global scalar or
-vector or array values from a compute as input. See "this
-section"_Section_howto.html#howto_15 for an overview of LAMMPS output
+vector or array values from a compute as input. See the "Howto
+output"_Howto_output.html doc page for an overview of LAMMPS output
options.
The scalar value calculated by this compute is "intensive". The
diff --git a/doc/src/compute_temp_ramp.txt b/doc/src/compute_temp_ramp.txt
index bc9283469cf2bda9e55f2ee29f95e25d92f68c69..15cad9c0cb814ed464f5c9210499a333f6cf576d 100644
--- a/doc/src/compute_temp_ramp.txt
+++ b/doc/src/compute_temp_ramp.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -83,8 +83,8 @@ atoms that include these constraints will be computed correctly. If
needed, the subtracted degrees-of-freedom can be altered using the
{extra} option of the "compute_modify"_compute_modify.html command.
-See "this howto section"_Section_howto.html#howto_16 of the manual for
-a discussion of different ways to compute temperature and perform
+See the "Howto thermostat"_Howto_thermostat.html doc page for a
+discussion of different ways to compute temperature and perform
thermostatting.
[Output info:]
@@ -92,8 +92,8 @@ thermostatting.
This compute calculates a global scalar (the temperature) and a global
vector of length 6 (KE tensor), which can be accessed by indices 1-6.
These values can be used by any command that uses global scalar or
-vector values from a compute as input. See "this
-section"_Section_howto.html#howto_15 for an overview of LAMMPS output
+vector values from a compute as input. See the "Howto
+output"_Howto_output.html doc page for an overview of LAMMPS output
options.
The scalar value calculated by this compute is "intensive". The
diff --git a/doc/src/compute_temp_region.txt b/doc/src/compute_temp_region.txt
index 3e4a80db8dd1ff4cf2c0cee248754bf2f2721158..f23901af9861633b83b33d5c172b62f8fe3f681c 100644
--- a/doc/src/compute_temp_region.txt
+++ b/doc/src/compute_temp_region.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -81,8 +81,8 @@ If needed the number of subtracted degrees-of-freedom can be set
explicitly using the {extra} option of the
"compute_modify"_compute_modify.html command.
-See "this howto section"_Section_howto.html#howto_16 of the manual for
-a discussion of different ways to compute temperature and perform
+See the "Howto thermostat"_Howto_thermostat.html doc page for a
+discussion of different ways to compute temperature and perform
thermostatting.
[Output info:]
@@ -90,8 +90,8 @@ thermostatting.
This compute calculates a global scalar (the temperature) and a global
vector of length 6 (KE tensor), which can be accessed by indices 1-6.
These values can be used by any command that uses global scalar or
-vector values from a compute as input. See "this
-section"_Section_howto.html#howto_15 for an overview of LAMMPS output
+vector values from a compute as input. See the "Howto
+output"_Howto_output.html doc page for an overview of LAMMPS output
options.
The scalar value calculated by this compute is "intensive". The
diff --git a/doc/src/compute_temp_region_eff.txt b/doc/src/compute_temp_region_eff.txt
index 8baf2dd46cc01f57cbec0ede1d76265b3b8b113f..f15f3155b08c51880ae3ae8fc9f6b255ff9b78fe 100644
--- a/doc/src/compute_temp_region_eff.txt
+++ b/doc/src/compute_temp_region_eff.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -39,8 +39,8 @@ temp/eff"_compute_temp_eff.html command.
This compute calculates a global scalar (the temperature) and a global
vector of length 6 (KE tensor), which can be accessed by indices 1-6.
These values can be used by any command that uses global scalar or
-vector values from a compute as input. See "this
-section"_Section_howto.html#howto_15 for an overview of LAMMPS output
+vector values from a compute as input. See the "Howto
+output"_Howto_output.html doc page for an overview of LAMMPS output
options.
The scalar value calculated by this compute is "intensive". The
@@ -52,8 +52,8 @@ vector values will be in energy "units"_units.html.
[Restrictions:]
This compute is part of the USER-EFF package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/compute_temp_rotate.txt b/doc/src/compute_temp_rotate.txt
index 34feca7b6fd014ee4792126aed5c9277e1b4c203..8dac0405b402efa55594068b1e7c57775ee47359 100644
--- a/doc/src/compute_temp_rotate.txt
+++ b/doc/src/compute_temp_rotate.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -64,8 +64,8 @@ atoms that include these constraints will be computed correctly. If
needed, the subtracted degrees-of-freedom can be altered using the
{extra} option of the "compute_modify"_compute_modify.html command.
-See "this howto section"_Section_howto.html#howto_16 of the manual for
-a discussion of different ways to compute temperature and perform
+See the "Howto thermostat"_Howto_thermostat.html doc page for a
+discussion of different ways to compute temperature and perform
thermostatting.
[Output info:]
@@ -73,8 +73,8 @@ thermostatting.
This compute calculates a global scalar (the temperature) and a global
vector of length 6 (KE tensor), which can be accessed by indices 1-6.
These values can be used by any command that uses global scalar or
-vector values from a compute as input. See "this
-section"_Section_howto.html#howto_15 for an overview of LAMMPS output
+vector values from a compute as input. See the "Howto
+output"_Howto_output.html doc page for an overview of LAMMPS output
options.
The scalar value calculated by this compute is "intensive". The
@@ -86,8 +86,8 @@ vector values will be in energy "units"_units.html.
[Restrictions:]
This compute is part of the USER-MISC package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/compute_temp_sphere.txt b/doc/src/compute_temp_sphere.txt
index 9e9dff2cb6dc149e5834043a7f420f968666f15a..5a55126d121755a60f9705e52189f28dbcca70cf 100644
--- a/doc/src/compute_temp_sphere.txt
+++ b/doc/src/compute_temp_sphere.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -79,8 +79,8 @@ computed correctly. If needed, the subtracted degrees-of-freedom can
be altered using the {extra} option of the
"compute_modify"_compute_modify.html command.
-See "this howto section"_Section_howto.html#howto_16 of the manual for
-a discussion of different ways to compute temperature and perform
+See the "Howto thermostat"_Howto_thermostat.html doc page for a
+discussion of different ways to compute temperature and perform
thermostatting.
:line
@@ -108,8 +108,8 @@ rotational degrees of freedom.
This compute calculates a global scalar (the temperature) and a global
vector of length 6 (KE tensor), which can be accessed by indices 1-6.
These values can be used by any command that uses global scalar or
-vector values from a compute as input. See "this
-section"_Section_howto.html#howto_15 for an overview of LAMMPS output
+vector values from a compute as input. See the "Howto
+output"_Howto_output.html doc page for an overview of LAMMPS output
options.
The scalar value calculated by this compute is "intensive". The
diff --git a/doc/src/compute_temp_uef.txt b/doc/src/compute_temp_uef.txt
index acd3a6218d9e39d25a73be4d7562ee8127ae9cfa..9a509da4503db6cb3a9e03b0314de6300e28d36b 100644
--- a/doc/src/compute_temp_uef.txt
+++ b/doc/src/compute_temp_uef.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -35,9 +35,9 @@ documentation for "compute temp"_compute_temp.html.
[Restrictions:]
-This fix is part of the USER-UEF package. It is only enabled if
-LAMMPS was built with that package. See the
-"Making LAMMPS"_Section_start.html#start_3 section for more info.
+This fix is part of the USER-UEF package. It is only enabled if LAMMPS
+was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This command can only be used when "fix nvt/uef"_fix_nh_uef.html
or "fix npt/uef"_fix_nh_uef.html is active.
diff --git a/doc/src/compute_ti.txt b/doc/src/compute_ti.txt
index 733954d146bc9ec9b90c821f45432115638db7fc..9057cab4769c5e201d1a30a7b47b8d1f6645d324 100644
--- a/doc/src/compute_ti.txt
+++ b/doc/src/compute_ti.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -111,9 +111,8 @@ du/dl can be found in the paper by "Eike"_#Eike.
This compute calculates a global scalar, namely dUs/dlambda. This
value can be used by any command that uses a global scalar value from
-a compute as input. See "Section
-6.15"_Section_howto.html#howto_15 for an overview of LAMMPS output
-options.
+a compute as input. See the "Howto output"_Howto_output.html doc page
+for an overview of LAMMPS output options.
The scalar value calculated by this compute is "extensive".
@@ -122,8 +121,8 @@ The scalar value will be in energy "units"_units.html.
[Restrictions:]
This compute is part of the MISC package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/compute_torque_chunk.txt b/doc/src/compute_torque_chunk.txt
index b9f832dd03afe36960509535c348973a46e83e01..6484076b37619db625ea585480d1d00b73c455ed 100644
--- a/doc/src/compute_torque_chunk.txt
+++ b/doc/src/compute_torque_chunk.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -30,10 +30,9 @@ chunk/atom"_compute_chunk_atom.html command, which assigns each atom
to a single chunk (or no chunk). The ID for this command is specified
as chunkID. For example, a single chunk could be the atoms in a
molecule or atoms in a spatial bin. See the "compute
-chunk/atom"_compute_chunk_atom.html doc page and "Section
-6.23"_Section_howto.html#howto_23 for details of how chunks can be
-defined and examples of how they can be used to measure properties of
-a system.
+chunk/atom"_compute_chunk_atom.html and "Howto chunk"_Howto_chunk.html
+doc pages for details of how chunks can be defined and examples of how
+they can be used to measure properties of a system.
This compute calculates the 3 components of the torque vector for eqch
chunk, due to the forces on the individual atoms in the chunk around
@@ -72,7 +71,7 @@ number of chunks {Nchunk} as calculated by the specified "compute
chunk/atom"_compute_chunk_atom.html command. The number of columns =
3 for the 3 xyz components of the torque for each chunk. These values
can be accessed by any command that uses global array values from a
-compute as input. See "Section 6.15"_Section_howto.html#howto_15
+compute as input. See the "Howto output"_Howto_output.html doc page
for an overview of LAMMPS output options.
The array values are "intensive". The array values will be in
diff --git a/doc/src/compute_vacf.txt b/doc/src/compute_vacf.txt
index a0d9a3c5f702ea42c77d8a18f433743f73500f77..70f1e99490586badb949d7fe6bec0b791a0ebc1c 100644
--- a/doc/src/compute_vacf.txt
+++ b/doc/src/compute_vacf.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -55,9 +55,8 @@ correctly with time=0 atom velocities from the restart file.
This compute calculates a global vector of length 4, which can be
accessed by indices 1-4 by any command that uses global vector values
-from a compute as input. See "this
-section"_Section_howto.html#howto_15 for an overview of LAMMPS output
-options.
+from a compute as input. See the "Howto output"_Howto_output.html doc
+page for an overview of LAMMPS output options.
The vector values are "intensive". The vector values will be in
velocity^2 "units"_units.html.
diff --git a/doc/src/compute_vcm_chunk.txt b/doc/src/compute_vcm_chunk.txt
index de02c586bf9d0d052f7e9421e4f52372b5b8e3c4..7e8ad712086fe17931a8676179865117aaf41c1f 100644
--- a/doc/src/compute_vcm_chunk.txt
+++ b/doc/src/compute_vcm_chunk.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -30,10 +30,9 @@ chunk/atom"_compute_chunk_atom.html command, which assigns each atom
to a single chunk (or no chunk). The ID for this command is specified
as chunkID. For example, a single chunk could be the atoms in a
molecule or atoms in a spatial bin. See the "compute
-chunk/atom"_compute_chunk_atom.html doc page and "Section
-6.23"_Section_howto.html#howto_23 for details of how chunks can be
-defined and examples of how they can be used to measure properties of
-a system.
+chunk/atom"_compute_chunk_atom.html and "Howto chunk"_Howto_chunk.html
+doc pages for details of how chunks can be defined and examples of how
+they can be used to measure properties of a system.
This compute calculates the x,y,z components of the center-of-mass
velocity for each chunk. This is done by summing mass*velocity for
@@ -63,8 +62,8 @@ number of chunks {Nchunk} as calculated by the specified "compute
chunk/atom"_compute_chunk_atom.html command. The number of columns =
3 for the x,y,z center-of-mass velocity coordinates of each chunk.
These values can be accessed by any command that uses global array
-values from a compute as input. See "Section
-6.15"_Section_howto.html#howto_15 for an overview of LAMMPS output
+values from a compute as input. See the "Howto
+output"_Howto_output.html doc page for an overview of LAMMPS output
options.
The array values are "intensive". The array values will be in
diff --git a/doc/src/compute_voronoi_atom.txt b/doc/src/compute_voronoi_atom.txt
index a280b2b151d7e7656a421e8007f04c1eed464c90..d01f4df71217920649b688cb20562dab8396ac82 100644
--- a/doc/src/compute_voronoi_atom.txt
+++ b/doc/src/compute_voronoi_atom.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -122,18 +122,16 @@ to locate vacancies (the coordinates are given by the atom coordinates
at the time step when the compute was first invoked), while column two
data can be used to identify interstitial atoms.
-If the {neighbors} value is set to yes, then
-this compute creates a local array with 3 columns. There
-is one row for each face of each Voronoi cell. The
-3 columns are the atom ID of the atom that owns the cell,
-the atom ID of the atom in the neighboring cell
-(or zero if the face is external), and the area of the face.
-The array can be accessed by any command that
-uses local values from a compute as input. See "this
-section"_Section_howto.html#howto_15 for an overview of LAMMPS output
-options. More specifically, the array can be accessed by a
-"dump local"_dump.html command to write a file containing
-all the Voronoi neighbors in a system:
+If the {neighbors} value is set to yes, then this compute creates a
+local array with 3 columns. There is one row for each face of each
+Voronoi cell. The 3 columns are the atom ID of the atom that owns the
+cell, the atom ID of the atom in the neighboring cell (or zero if the
+face is external), and the area of the face. The array can be
+accessed by any command that uses local values from a compute as
+input. See the "Howto output"_Howto_output.html doc page for an
+overview of LAMMPS output options. More specifically, the array can be
+accessed by a "dump local"_dump.html command to write a file
+containing all the Voronoi neighbors in a system:
compute 6 all voronoi/atom neighbors yes
dump d2 all local 1 dump.neighbors index c_6\[1\] c_6\[2\] c_6\[3\] :pre
@@ -186,8 +184,8 @@ columns. In regular dynamic tessellation mode the first column is the
Voronoi volume, the second is the neighbor count, as described above
(read above for the output data in case the {occupation} keyword is
specified). These values can be accessed by any command that uses
-per-atom values from a compute as input. See "Section
-6.15"_Section_howto.html#howto_15 for an overview of LAMMPS output
+per-atom values from a compute as input. See the "Howto
+output"_Howto_output.html doc page for an overview of LAMMPS output
options. If the {peratom} keyword is set to "no", the per-atom array
is still created, but it is not accessible.
@@ -214,8 +212,8 @@ The Voronoi face area will be in distance "units"_units.html squared.
[Restrictions:]
This compute is part of the VORONOI package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
It also requires you have a copy of the Voro++ library built and
installed on your system. See instructions on obtaining and
diff --git a/doc/src/compute_xrd.txt b/doc/src/compute_xrd.txt
index 1a151d63f9157380349a55d2f4a49d2ac806a4a2..41523f25afa828f214491d7d3bdae2cf87172905 100644
--- a/doc/src/compute_xrd.txt
+++ b/doc/src/compute_xrd.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -162,7 +162,7 @@ or degrees) provided with the {2Theta} values. The second column contains
the computed diffraction intensities as described above.
The array can be accessed by any command that uses global values from
-a compute as input. See "this section"_Section_howto.html#howto_15
+a compute as input. See the "Howto output"_Howto_output.html doc page
for an overview of LAMMPS output options.
All array values calculated by this compute are "intensive".
@@ -170,8 +170,8 @@ All array values calculated by this compute are "intensive".
[Restrictions:]
This compute is part of the USER-DIFFRACTION package. It is only
-enabled if LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+enabled if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
The compute_xrd command does not work for triclinic cells.
diff --git a/doc/src/create_atoms.txt b/doc/src/create_atoms.txt
index 5d824ae1ef2e57815bba64e8596d069048a46f12..d80e2d45f1473d2a4a084b35af0140e6a3e0605a 100644
--- a/doc/src/create_atoms.txt
+++ b/doc/src/create_atoms.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/create_bonds.txt b/doc/src/create_bonds.txt
index 6700ed29d3f3f6d9b3c7d5094b182a1bf6235a82..fbf741d914b4d1978d5179fffecb929a487fc099 100644
--- a/doc/src/create_bonds.txt
+++ b/doc/src/create_bonds.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -132,7 +132,7 @@ between 1 and the number of bond types defined.
The {single/angle} style creates a single angle of type {atype}
between three atoms with IDs {aatom1}, {aatom2}, and {aatom3}. The
ordering of the atoms is the same as in the {Angles} section of a data
-file read by the "read_data"_read_data command. I.e. the 3 atoms are
+file read by the "read_data"_read_data.html command. I.e. the 3 atoms are
ordered linearly within the angle; the central atom is {aatom2}.
{Atype} must be a value between 1 and the number of angle types
defined.
@@ -140,7 +140,7 @@ defined.
The {single/dihedral} style creates a single dihedral of type {btype}
between two atoms with IDs {batom1} and {batom2}. The ordering of the
atoms is the same as in the {Dihedrals} section of a data file read by
-the "read_data"_read_data command. I.e. the 4 atoms are ordered
+the "read_data"_read_data.html command. I.e. the 4 atoms are ordered
linearly within the dihedral. {Dtype} must be a value between 1 and
the number of dihedral types defined.
diff --git a/doc/src/create_box.txt b/doc/src/create_box.txt
index f4ef13654c6eaf3f13a1795862879b6642e7734b..0993b4f927d49a02b8a93328f564c72e16e3fbdb 100644
--- a/doc/src/create_box.txt
+++ b/doc/src/create_box.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -73,9 +73,9 @@ factors that exceed these limits, you can use the "box tilt"_box.html
command, with a setting of {large}; a setting of {small} is the
default.
-See "Section 6.12"_Section_howto.html#howto_12 of the doc pages
-for a geometric description of triclinic boxes, as defined by LAMMPS,
-and how to transform these parameters to and from other commonly used
+See the "Howto triclinic"_Howto_triclinic.html doc page for a
+geometric description of triclinic boxes, as defined by LAMMPS, and
+how to transform these parameters to and from other commonly used
triclinic representations.
When a prism region is used, the simulation domain should normally be
diff --git a/doc/src/delete_atoms.txt b/doc/src/delete_atoms.txt
index 1aa71d341f83a34a25017b4d123996f22a6fcd16..57faf97ad1bf1d213135707989985a1f866a8f8d 100644
--- a/doc/src/delete_atoms.txt
+++ b/doc/src/delete_atoms.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/delete_bonds.txt b/doc/src/delete_bonds.txt
index b1137a22881213506c8921b9e422d0d9f2e33253..b29fa82f2d0d16c9b1a252073080aba43332605c 100644
--- a/doc/src/delete_bonds.txt
+++ b/doc/src/delete_bonds.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/dielectric.txt b/doc/src/dielectric.txt
index e98badf87b72c94b3a308c806044499966d76463..f93be8cc25823c691b108dce6d8e41b5d6367775 100644
--- a/doc/src/dielectric.txt
+++ b/doc/src/dielectric.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/dihedral_charmm.txt b/doc/src/dihedral_charmm.txt
index 06abe054e4819e7c7e9ea9e248e7f2285e423572..637a10102dc1f79c65995c9361731b00777bd1c9 100644
--- a/doc/src/dihedral_charmm.txt
+++ b/doc/src/dihedral_charmm.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -116,23 +116,22 @@ computed.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -147,8 +146,8 @@ Otherwise non-bonded contributions for these 1-4 pairs will be
computed multiple times.
These dihedral styles can only be used if LAMMPS was built with the
-MOLECULE package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+MOLECULE package. See the "Build package"_Build_package.html doc page
+for more info.
[Related commands:]
diff --git a/doc/src/dihedral_class2.txt b/doc/src/dihedral_class2.txt
index cb9fc72c223b2293990764db4b0dffb59dc249b5..9936f3768df703d8b2e63072499c3d0c96d2c3f8 100644
--- a/doc/src/dihedral_class2.txt
+++ b/doc/src/dihedral_class2.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -141,31 +141,30 @@ r3 (distance) :ul
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This dihedral style can only be used if LAMMPS was built with the
-CLASS2 package. See the "Making LAMMPS"_Section_start.html#start_3
-section for more info on packages.
+CLASS2 package. See the "Build package"_Build_package.html doc
+page for more info.
[Related commands:]
diff --git a/doc/src/dihedral_coeff.txt b/doc/src/dihedral_coeff.txt
index 5b43cbbe7f36d937fcb60334bde83a5911a2e61d..1db69e40d5739320b57139e56494749f6661e8d2 100644
--- a/doc/src/dihedral_coeff.txt
+++ b/doc/src/dihedral_coeff.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -74,9 +74,9 @@ the style to display the formula it computes and coefficients
specified by the associated "dihedral_coeff"_dihedral_coeff.html command.
Note that there are also additional dihedral styles submitted by users
-which are included in the LAMMPS distribution. The list of these with
-links to the individual styles are given in the dihedral section of
-"this page"_Section_commands.html#cmd_5.
+which are included in the LAMMPS distribution. The full list of all
+dihedral styles is on the "Commands bond"_Commands_bond.html#dihedral
+doc page.
"dihedral_style none"_dihedral_none.html - turn off dihedral interactions
"dihedral_style hybrid"_dihedral_hybrid.html - define multiple styles of dihedral interactions :ul
diff --git a/doc/src/dihedral_cosine_shift_exp.txt b/doc/src/dihedral_cosine_shift_exp.txt
index 715682affc010e657556ba9221ca68a093b5259a..e2a46d28d8ad9f686f6221e2594a7f3b7a4392d3 100644
--- a/doc/src/dihedral_cosine_shift_exp.txt
+++ b/doc/src/dihedral_cosine_shift_exp.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -52,31 +52,30 @@ A (real number) :ul
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This dihedral style can only be used if LAMMPS was built with the
-USER-MISC package. See the "Making LAMMPS"_Section_start.html#start_3
-section for more info on packages.
+USER-MISC package. See the "Build package"_Build_package.html doc
+page for more info.
[Related commands:]
diff --git a/doc/src/dihedral_fourier.txt b/doc/src/dihedral_fourier.txt
index 0accbb22bf80bfb89e1b77bd7fa8760e56ad3e55..3045f6824b1b27d393a720578193cca47627b160 100644
--- a/doc/src/dihedral_fourier.txt
+++ b/doc/src/dihedral_fourier.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -44,31 +44,30 @@ dm (degrees) :ul
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[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
-section for more info on packages.
+USER_MISC package. See the "Build package"_Build_package.html doc
+page for more info.
[Related commands:]
diff --git a/doc/src/dihedral_harmonic.txt b/doc/src/dihedral_harmonic.txt
index d9a48ff384d9df3dd9228a05be3c523302b80362..27bc04f9df6d05cf8774270a2900a5fb96cf1d4c 100644
--- a/doc/src/dihedral_harmonic.txt
+++ b/doc/src/dihedral_harmonic.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -53,31 +53,30 @@ Some force fields let {n} be positive or negative which corresponds to
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This dihedral style can only be used if LAMMPS was built with the
-MOLECULE package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+MOLECULE package. See the "Build package"_Build_package.html doc page
+for more info.
[Related commands:]
diff --git a/doc/src/dihedral_helix.txt b/doc/src/dihedral_helix.txt
index 1e907557b28564f74e3f080160997a107941d4b5..3b3607337b91bb056d3ea7f4227cc3cabb07c3d7 100644
--- a/doc/src/dihedral_helix.txt
+++ b/doc/src/dihedral_helix.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -46,31 +46,30 @@ C (energy) :ul
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This dihedral style can only be used if LAMMPS was built with the
-MOLECULE package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+MOLECULE package. See the "Build package"_Build_package.html doc page
+for more info.
[Related commands:]
diff --git a/doc/src/dihedral_hybrid.txt b/doc/src/dihedral_hybrid.txt
index 8cb40eff44a66189d2ff37aadbd0c25ccd5a00c3..a4a2a2808eb1ca170a315708fa92c23326840aae 100644
--- a/doc/src/dihedral_hybrid.txt
+++ b/doc/src/dihedral_hybrid.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -77,8 +77,8 @@ for specific dihedral types.
[Restrictions:]
This dihedral style can only be used if LAMMPS was built with the
-MOLECULE package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+MOLECULE package. See the "Build package"_Build_package.html doc page
+for more info.
Unlike other dihedral styles, the hybrid dihedral style does not store
dihedral coefficient info for individual sub-styles in a "binary
diff --git a/doc/src/dihedral_multi_harmonic.txt b/doc/src/dihedral_multi_harmonic.txt
index 7d3c2ea083d0ef78b7e275caa9ca51e1305e8e49..74f1f6abc69cc1e1dfbe009a5ef096de88a0110a 100644
--- a/doc/src/dihedral_multi_harmonic.txt
+++ b/doc/src/dihedral_multi_harmonic.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -40,31 +40,30 @@ A5 (energy) :ul
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This dihedral style can only be used if LAMMPS was built with the
-MOLECULE package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+MOLECULE package. See the "Build package"_Build_package.html doc page
+for more info.
[Related commands:]
diff --git a/doc/src/dihedral_nharmonic.txt b/doc/src/dihedral_nharmonic.txt
index 8392d83899de8c41cd855e6a038f3e7a585ec08a..7a8bf6cdb7c6ce73c0593896ace978cac62e044a 100644
--- a/doc/src/dihedral_nharmonic.txt
+++ b/doc/src/dihedral_nharmonic.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -40,31 +40,30 @@ An (energy) :ul
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[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
-section for more info on packages.
+USER_MISC package. See the "Build package"_Build_package.html doc
+page for more info.
[Related commands:]
diff --git a/doc/src/dihedral_none.txt b/doc/src/dihedral_none.txt
index 3ce2aa1729c6dfb31ad8924b20554f974cbc73b5..4c1ff2ea5d30fadd25949e613b6ec29e4cfa3fdb 100644
--- a/doc/src/dihedral_none.txt
+++ b/doc/src/dihedral_none.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/dihedral_opls.txt b/doc/src/dihedral_opls.txt
index d1a6ba3ff2865db905b97bf72b70d343f509e06e..7fa5d81a14a778baf76815ad2cc8cede3a5ae4ce 100644
--- a/doc/src/dihedral_opls.txt
+++ b/doc/src/dihedral_opls.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -48,31 +48,30 @@ K4 (energy) :ul
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This dihedral style can only be used if LAMMPS was built with the
-MOLECULE package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+MOLECULE package. See the "Build package"_Build_package.html doc page
+for more info.
[Related commands:]
diff --git a/doc/src/dihedral_quadratic.txt b/doc/src/dihedral_quadratic.txt
index ca2f5aed40f2f67512a255813689a50e35a4c7d7..dc951e4269fdbf3752dd7f36aa366b81a06389fd 100644
--- a/doc/src/dihedral_quadratic.txt
+++ b/doc/src/dihedral_quadratic.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -41,31 +41,30 @@ phi0 (degrees) :ul
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[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
-section for more info on packages.
+USER_MISC package. See the "Build package"_Build_package.html doc
+page for more info.
[Related commands:]
diff --git a/doc/src/dihedral_spherical.txt b/doc/src/dihedral_spherical.txt
index 7c17fbf5ef1c50aa939642c0eb224835c3721f0d..61949174df8d052740a1f0676a8c68e8b00606dd 100644
--- a/doc/src/dihedral_spherical.txt
+++ b/doc/src/dihedral_spherical.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -78,8 +78,8 @@ wn (typically 0.0 or 1.0) :ul
[Restrictions:]
This dihedral style can only be used if LAMMPS was built with the
-USER_MISC package. See the "Making LAMMPS"_Section_start.html#start_3
-section for more info on packages.
+USER_MISC package. See the "Build package"_Build_package.html doc
+page for more info.
[Related commands:]
diff --git a/doc/src/dihedral_style.txt b/doc/src/dihedral_style.txt
index ca592b29b55415fde7c4306fa231ea35e0c5f40a..749f74e399559570fc52f0c8fa65be30a9557a1d 100644
--- a/doc/src/dihedral_style.txt
+++ b/doc/src/dihedral_style.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -81,9 +81,9 @@ the style to display the formula it computes and coefficients
specified by the associated "dihedral_coeff"_dihedral_coeff.html command.
Note that there are also additional dihedral styles submitted by users
-which are included in the LAMMPS distribution. The list of these with
-links to the individual styles are given in the dihedral section of
-"this page"_Section_commands.html#cmd_5.
+which are included in the LAMMPS distribution. The full list of all
+dihedral styles is on the "Commands bond"_Commands_bond.html#dihedral
+doc page.
"dihedral_style none"_dihedral_none.html - turn off dihedral interactions
"dihedral_style zero"_dihedral_zero.html - topology but no interactions
@@ -104,10 +104,9 @@ Dihedral styles can only be set for atom styles that allow dihedrals
to be defined.
Most dihedral styles are part of the MOLECULE package. They are only
-enabled if LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
-The doc pages for individual dihedral potentials tell if it is part of
-a package.
+enabled if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info. The doc pages for
+individual dihedral potentials tell if it is part of a package.
[Related commands:]
diff --git a/doc/src/dihedral_table.txt b/doc/src/dihedral_table.txt
index 0b88f26a61076c6b10750ea419b947fb88a0dd8f..3f679f57093c95954927fddbe73a3aa9beeb94bd 100644
--- a/doc/src/dihedral_table.txt
+++ b/doc/src/dihedral_table.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -174,29 +174,28 @@ that matches the specified keyword.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
[Restrictions:]
This dihedral style can only be used if LAMMPS was built with the
-USER-MISC package. See the "Making LAMMPS"_Section_start.html#start_3
-section for more info on packages.
+USER-MISC package. See the "Build package"_Build_package.html doc
+page for more info.
[Related commands:]
diff --git a/doc/src/dihedral_table_cut.txt b/doc/src/dihedral_table_cut.txt
index 1c83d4ffa09f7221ac8c3859594abc754b9b28c4..b8e0ec64c8863ac4b87db5b7433c84c3c4dbff55 100644
--- a/doc/src/dihedral_table_cut.txt
+++ b/doc/src/dihedral_table_cut.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -192,8 +192,8 @@ that matches the specified keyword.
[Restrictions:]
This dihedral style can only be used if LAMMPS was built with the
-USER-MISC package. See the "Making LAMMPS"_Section_start.html#start_3
-section for more info on packages.
+USER-MISC package. See the "Build package"_Build_package.html doc
+page for more info.
[Related commands:]
diff --git a/doc/src/dihedral_zero.txt b/doc/src/dihedral_zero.txt
index 4d33126eeb76330e830fced4f9c55d7b47c86fdf..0c9995a5637c84571297f7b6a28a7162dc75b2fd 100644
--- a/doc/src/dihedral_zero.txt
+++ b/doc/src/dihedral_zero.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/dimension.txt b/doc/src/dimension.txt
index 0531e92acf60d439c22848fc3d2a94b653a1c52d..b7dde7652443a10a7199ddc46f9e7e70a21b3a09 100644
--- a/doc/src/dimension.txt
+++ b/doc/src/dimension.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -26,7 +26,7 @@ prior to setting up a simulation box via the
"create_box"_create_box.html or "read_data"_read_data.html commands.
Restart files also store this setting.
-See the discussion in "Section 6"_Section_howto.html for
+See the discussion on the "Howto 2d"_Howto_2d.html doc page for
additional instructions on how to run 2d simulations.
NOTE: Some models in LAMMPS treat particles as finite-size spheres or
diff --git a/doc/src/displace_atoms.txt b/doc/src/displace_atoms.txt
index 634add196b78fe249d4c42177482b69b05f5719e..b4afd5c3a9b9eb4af9666fc4b57f0b0df85810be 100644
--- a/doc/src/displace_atoms.txt
+++ b/doc/src/displace_atoms.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/dump.txt b/doc/src/dump.txt
index 438ff1d4e074779f22217e851799a81f1f7ff857..8b630cc7069ccc949579c5cda38cc1834a4c0d54 100644
--- a/doc/src/dump.txt
+++ b/doc/src/dump.txt
@@ -1,8 +1,8 @@
- "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -184,10 +184,10 @@ file and in what format. Settings made via the
individual values and the file itself.
The {atom}, {local}, and {custom} styles create files in a simple text
-format that is self-explanatory when viewing a dump file. Many of the
-LAMMPS "post-processing tools"_Section_tools.html, including
-"Pizza.py"_http://www.sandia.gov/~sjplimp/pizza.html, work with this
-format, as does the "rerun"_rerun.html command.
+format that is self-explanatory when viewing a dump file. Some of the
+LAMMPS post-processing tools described on the "Tools"_Tools.html doc
+page, including "Pizza.py"_http://www.sandia.gov/~sjplimp/pizza.html,
+work with this format, as does the "rerun"_rerun.html command.
For post-processing purposes the {atom}, {local}, and {custom} text
files are self-describing in the following sense.
@@ -224,12 +224,12 @@ This bounding box is convenient for many visualization programs. The
meaning of the 6 character flags for "xx yy zz" is the same as above.
Note that the first two numbers on each line are now xlo_bound instead
-of xlo, etc, since they represent a bounding box. See "this
-section"_Section_howto.html#howto_12 of the doc pages for a geometric
-description of triclinic boxes, as defined by LAMMPS, simple formulas
-for how the 6 bounding box extents (xlo_bound,xhi_bound,etc) are
-calculated from the triclinic parameters, and how to transform those
-parameters to and from other commonly used triclinic representations.
+of xlo, etc, since they represent a bounding box. See the "Howto
+triclinic"_Howto_triclinic.html doc page for a geometric description
+of triclinic boxes, as defined by LAMMPS, simple formulas for how the
+6 bounding box extents (xlo_bound,xhi_bound,etc) are calculated from
+the triclinic parameters, and how to transform those parameters to and
+from other commonly used triclinic representations.
The "ITEM: ATOMS" line in each snapshot lists column descriptors for
the per-atom lines that follow. For example, the descriptors would be
@@ -413,10 +413,10 @@ If the filename ends with ".bin", the dump file (or files, if "*" or
will be about the same size as a text version, but will typically
write out much faster. Of course, when post-processing, you will need
to convert it back to text format (see the "binary2txt
-tool"_Section_tools.html#binary) or write your own code to read the
-binary file. The format of the binary file can be understood by
-looking at the tools/binary2txt.cpp file. This option is only
-available for the {atom} and {custom} styles.
+tool"_Tools.html#binary) or write your own code to read the binary
+file. The format of the binary file can be understood by looking at
+the tools/binary2txt.cpp file. This option is only available for the
+{atom} and {custom} styles.
If the filename ends with ".gz", the dump file (or files, if "*" or "%"
is also used) is written in gzipped format. A gzipped dump file will
@@ -530,7 +530,7 @@ so that each value is 0.0 to 1.0. If the simulation box is triclinic
(tilted), then all atom coords will still be between 0.0 and 1.0.
I.e. actual unscaled (x,y,z) = xs*A + ys*B + zs*C, where (A,B,C) are
the non-orthogonal vectors of the simulation box edges, as discussed
-in "Section 6.12"_Section_howto.html#howto_12.
+on the "Howto triclinic"_Howto_triclinic.html doc page.
Use {xu}, {yu}, {zu} if you want the coordinates "unwrapped" by the
image flags for each atom. Unwrapped means that if the atom has
@@ -625,32 +625,31 @@ The {d_name} and {i_name} attributes allow to output custom per atom
floating point or integer properties that are managed by
"fix property/atom"_fix_property_atom.html.
-See "Section 10"_Section_modify.html of the manual for information
-on how to add new compute and fix styles to LAMMPS to calculate
-per-atom quantities which could then be output into dump files.
+See the "Modify"_Modify.html doc page for information on how to add
+new compute and fix styles to LAMMPS to calculate per-atom quantities
+which could then be output into dump files.
:line
[Restrictions:]
To write gzipped dump files, you must either compile LAMMPS with the
--DLAMMPS_GZIP option or use the styles from the COMPRESS package
-- see the "Making LAMMPS"_Section_start.html#start_2 section of
-the documentation.
+-DLAMMPS_GZIP option or use the styles from the COMPRESS package.
+See the "Build settings"_Build_settings.html doc page for details.
-The {atom/gz}, {cfg/gz}, {custom/gz}, and {xyz/gz} styles are part
-of the COMPRESS package. They are only enabled if LAMMPS was built
-with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+The {atom/gz}, {cfg/gz}, {custom/gz}, and {xyz/gz} styles are part of
+the COMPRESS package. They are only enabled if LAMMPS was built with
+that package. See the "Build package"_Build_package.html doc page for
+more info.
The {atom/mpiio}, {cfg/mpiio}, {custom/mpiio}, and {xyz/mpiio} styles
are part of the MPIIO package. They are only enabled if LAMMPS was
-built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+built with that package. See the "Build package"_Build_package.html
+doc page for more info.
The {xtc} style is part of the MISC package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/dump_cfg_uef.txt b/doc/src/dump_cfg_uef.txt
index e257f9c4f16d2f768ee4e688f3d71e0a0dd0c1cd..16e4aba4c04fd6db18adfb622e670ba8448ddc10 100644
--- a/doc/src/dump_cfg_uef.txt
+++ b/doc/src/dump_cfg_uef.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -38,9 +38,9 @@ reference frame as the atomic positions.
[Restrictions:]
-This fix is part of the USER-UEF package. It is only enabled if
-LAMMPS was built with that package. See the
-"Making LAMMPS"_Section_start.html#start_3 section for more info.
+This fix is part of the USER-UEF package. It is only enabled if LAMMPS
+was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This command can only be used when "fix nvt/uef"_fix_nh_uef.html
or "fix npt/uef"_fix_nh_uef.html is active.
diff --git a/doc/src/dump_h5md.txt b/doc/src/dump_h5md.txt
index 93c87d85b7a6064140b6cf320199d3cd99114e10..9065e8a648b4ae8f600e680bac713298d2043f37 100644
--- a/doc/src/dump_h5md.txt
+++ b/doc/src/dump_h5md.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -98,13 +98,13 @@ note above). Only orthogonal domains are currently supported. This is
a limitation of the present dump h5md command and not of H5MD itself.
The {h5md} dump style is part of the USER-H5MD package. It is only
-enabled if LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info. It also
-requires (i) building the ch5md library provided with LAMMPS (See the
-"Making LAMMPS"_Section_start.html#start_3 section for more info.) and
-(ii) having the "HDF5"_HDF5_ws library installed (C bindings are
-sufficient) on your system. The library ch5md is compiled with the
-h5cc wrapper provided by the HDF5 library.
+enabled if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info. It also requires
+(i) building the ch5md library provided with LAMMPS (See the "Build
+package"_Build_package.html doc page for more info.) and (ii) having
+the "HDF5"_HDF5_ws library installed (C bindings are sufficient) on
+your system. The library ch5md is compiled with the h5cc wrapper
+provided by the HDF5 library.
:link(HDF5_ws,http://www.hdfgroup.org/HDF5/)
diff --git a/doc/src/dump_image.txt b/doc/src/dump_image.txt
index 3fa267d2b099a252bce78e49d24c69609dffac2a..9b56dd95a6006878dc9e865be9c148093e3f52a5 100644
--- a/doc/src/dump_image.txt
+++ b/doc/src/dump_image.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -142,8 +142,8 @@ framerate can be set using the "dump_modify"_dump_modify.html command.
To write out JPEG and PNG format files, you must build LAMMPS with
support for the corresponding JPEG or PNG library. To convert images
into movies, LAMMPS has to be compiled with the -DLAMMPS_FFMPEG
-flag. See "this section"_Section_start.html#start_2_4 of the manual
-for instructions on how to do this.
+flag. See the "Build settings"_Build_settings.html doc page for
+details.
NOTE: Because periodic boundary conditions are enforced only on
timesteps when neighbor lists are rebuilt, the coordinates of an atom
@@ -356,16 +356,16 @@ is used to define body particles with internal state
body style. If this keyword is not used, such particles will be drawn
as spheres, the same as if they were regular atoms.
-The "body"_body.html doc page describes the body styles LAMMPS
-currently supports, and provides more details as to the kind of body
-particles they represent and how they are drawn by this dump image
-command. For all the body styles, individual atoms can be either a
-body particle or a usual point (non-body) particle. Non-body
+The "Howto body"_Howto_body.html doc page describes the body styles
+LAMMPS currently supports, and provides more details as to the kind of
+body particles they represent and how they are drawn by this dump
+image command. For all the body styles, individual atoms can be
+either a body particle or a usual point (non-body) particle. Non-body
particles will be drawn the same way they would be as a regular atom.
The {bflag1} and {bflag2} settings are numerical values which are
passed to the body style to affect how the drawing of a body particle
-is done. See the "body"_body.html doc page for a description of what
-these parameters mean for each body style.
+is done. See the "Howto body"_Howto_body.html doc page for a
+description of what these parameters mean for each body style.
The only setting currently allowed for the {color} value is {type},
which will color the body particles according to the atom type of the
@@ -606,9 +606,9 @@ supported. :l
:line
-See "Section 10"_Section_modify.html of the manual for information
-on how to add new compute and fix styles to LAMMPS to calculate
-per-atom quantities which could then be output into dump files.
+See the "Modify"_Modify.html doc page for information on how to add
+new compute and fix styles to LAMMPS to calculate per-atom quantities
+which could then be output into dump files.
:line
@@ -624,8 +624,7 @@ building LAMMPS and have the FFmpeg executable available on the
machine where LAMMPS is being run. Typically it's name is lowercase,
i.e. ffmpeg.
-See the "Making LAMMPS"_Section_start.html#start_2_4 section of the
-documentation for details on how to compile with optional switches.
+See the "Build settings"_Build_settings.html doc page for details.
Note that since FFmpeg is run as an external program via a pipe,
LAMMPS has limited control over its execution and no knowledge about
diff --git a/doc/src/dump_modify.txt b/doc/src/dump_modify.txt
index 5365610d640ab7598a11554d6c20bb47de8cf442..98bcbc5e551e85216732c74afebbc6c6b361a663 100644
--- a/doc/src/dump_modify.txt
+++ b/doc/src/dump_modify.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -133,7 +133,6 @@ dump_modify option below is valid for the {atom} style, it is also
valid for the {atom/mpiio} style, and similarly for the other styles
which allow for use of MPI-IO.
-:line
:line
These keywords apply to various dump styles, including the "dump
@@ -629,7 +628,6 @@ the coordinate would be if it had not been wrapped back into the
periodic box. Note that these coordinates may thus be far outside the
box size stored with the snapshot.
-:line
:line
These keywords apply only to the "dump image"_dump_image.html and
@@ -894,7 +892,6 @@ frame rate higher than 24 is not recommended, as it will result in
simply dropping the rendered images. It is more efficient to dump
images less frequently.
-:line
:line
[Restrictions:] none
diff --git a/doc/src/dump_molfile.txt b/doc/src/dump_molfile.txt
index 7e68490a68e013c42f13883d9b7d1f9044929ce8..dd2b212f0baafc6efd4200c42eb4439e1d6715e3 100644
--- a/doc/src/dump_molfile.txt
+++ b/doc/src/dump_molfile.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -90,8 +90,8 @@ determine the sequence of timesteps on which dump files are written.
[Restrictions:]
The {molfile} dump style is part of the USER-MOLFILE package. It is
-only enabled if LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+only enabled if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
Molfile plugins provide a consistent programming interface to read and
write file formats commonly used in molecular simulations. The
diff --git a/doc/src/dump_netcdf.txt b/doc/src/dump_netcdf.txt
index 70111a36a8b28d9654db6779426090b7e37b507d..52d757eac562083eff17a2dc5ffebfc741b5b2f5 100644
--- a/doc/src/dump_netcdf.txt
+++ b/doc/src/dump_netcdf.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -66,8 +66,8 @@ by "thermo_style"_thermo_style.html.
The {netcdf} and {netcdf/mpiio} dump styles are part of the
USER-NETCDF package. They are only enabled if LAMMPS was built with
-that package. See the "Making LAMMPS"_Section_start.html#start_3
-section for more info.
+that package. See the "Build package"_Build_package.html doc page for
+more info.
:line
diff --git a/doc/src/dump_vtk.txt b/doc/src/dump_vtk.txt
index d4d28c81fca69cea2fb65d72e940acf4de0fdcb0..7eaa59a79505a18318633a031cf4a64e8a3d4b43 100644
--- a/doc/src/dump_vtk.txt
+++ b/doc/src/dump_vtk.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -156,9 +156,9 @@ write out much faster.
The {vtk} style does not support writing of gzipped dump files.
-The {vtk} dump style is part of the USER-VTK package. It is
-only enabled if LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+The {vtk} dump style is part of the USER-VTK package. It is only
+enabled if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
To use this dump style, you also must link to the VTK library. See
the info in lib/vtk/README and insure the Makefile.lammps file in that
diff --git a/doc/src/echo.txt b/doc/src/echo.txt
index 3141c7a719bcb0de5d39366183a269f761bd0230..3436737faaa6f364c520b62c713647a96e63d7d7 100644
--- a/doc/src/echo.txt
+++ b/doc/src/echo.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -26,8 +26,8 @@ command to the screen and/or log file as it is read and processed. If
an input script has errors, it can be useful to look at echoed output
to see the last command processed.
-The "command-line switch"_Section_start.html#start_6 -echo can be used
-in place of this command.
+The "command-line switch"_Run_options.html -echo can be used in place
+of this command.
[Restrictions:] none
diff --git a/doc/src/fix.txt b/doc/src/fix.txt
index e54a918cd0e2d876088f9cc76a4a52136df71a7e..9c3a1d0349fd097eb9f5572b943872bce1254a4e 100644
--- a/doc/src/fix.txt
+++ b/doc/src/fix.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -30,9 +30,9 @@ Set a fix that will be applied to a group of atoms. In LAMMPS, a
timestepping or minimization. Examples include updating of atom
positions and velocities due to time integration, controlling
temperature, applying constraint forces to atoms, enforcing boundary
-conditions, computing diagnostics, etc. There are dozens of fixes
-defined in LAMMPS and new ones can be added; see "this
-section"_Section_modify.html for a discussion.
+conditions, computing diagnostics, etc. There are hundredes of fixes
+defined in LAMMPS and new ones can be added; see the
+"Modify"_Modify.html doc page for details.
Fixes perform their operations at different stages of the timestep.
If 2 or more fixes operate at the same stage of the timestep, they are
@@ -133,7 +133,7 @@ reduce"_compute_reduce.html command, or histogrammed by the "fix
ave/histo"_fix_ave_histo.html command. :l
:ule
-See this "howto section"_Section_howto.html#howto_15 for a summary of
+See the "Howto output"_Howto_output.html doc page for a summary of
various LAMMPS output options, many of which involve fixes.
The results of fixes that calculate global quantities can be either
@@ -151,16 +151,20 @@ for further info.
:line
-Each fix style has its own documentation page which describes its
-arguments and what it does, as listed below. Here is an alphabetic
-list of fix styles available in LAMMPS. They are also given in more
-compact form in the Fix section of "this
-page"_Section_commands.html#cmd_5.
+Each fix style has its own doc page which describes its arguments and
+what it does, as listed below. Here is an alphabetic list of fix
+styles available in LAMMPS. They are also listed in more compact form
+on the "Commands fix"_Commands_fix.html doc page.
There are also additional fix styles (not listed here) submitted by
-users which are included in the LAMMPS distribution. The list of
-these with links to the individual styles are given in the fix section
-of "this page"_Section_commands.html#cmd_5.
+users which are included in the LAMMPS distribution. The full list of
+all fix styles is on the "Commands fix"_Commands_fix.html doc page.
+
+There are also additional accelerated fix styles included in the
+LAMMPS distribution for faster performance on CPUs, GPUs, and KNLs.
+The individual style names on the "Commands fix"_Commands_fix.html doc
+page are followed by one or more of (g,i,k,o,t) to indicate which
+accerlerated styles exist.
"adapt"_fix_adapt.html - change a simulation parameter over time
"addforce"_fix_addforce.html - add a force to each atom
@@ -305,9 +309,9 @@ of "this page"_Section_commands.html#cmd_5.
[Restrictions:]
Some fix styles are part of specific packages. They are only enabled
-if LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
-The doc pages for individual fixes tell if it is part of a package.
+if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info. The doc pages for
+individual fixes tell if it is part of a package.
[Related commands:]
diff --git a/doc/src/fix_adapt.txt b/doc/src/fix_adapt.txt
index 7a34f2ff4480004c3ff249957b2b36204a087035..0ca28fb8694c6c5c4d4c2d39ab649dc79a9152a3 100644
--- a/doc/src/fix_adapt.txt
+++ b/doc/src/fix_adapt.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -270,10 +270,10 @@ fix 1 center adapt 10 atom diameter v_size :pre
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
-by this fix for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of this fix can
-be used with the {start/stop} keywords of the "run"_run.html command.
-This fix is not invoked during "energy minimization"_minimize.html.
+by this fix for access by various "output commands"_Howto_output.html.
+No parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command. This fix is not invoked during "energy
+minimization"_minimize.html.
For "rRESPA time integration"_run_style.html, this fix changes
parameters on the outermost rRESPA level.
diff --git a/doc/src/fix_adapt_fep.txt b/doc/src/fix_adapt_fep.txt
index 5dd58bc39adb83c1994bf847bcaf4e878ea34fb4..7e30a1d29d5b4354b7fae0761f50fc7d8d6e8dd3 100644
--- a/doc/src/fix_adapt_fep.txt
+++ b/doc/src/fix_adapt_fep.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -243,10 +243,10 @@ parameters on the outermost rRESPA level.
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
-by this fix for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of this fix can
-be used with the {start/stop} keywords of the "run"_run.html command.
-This fix is not invoked during "energy minimization"_minimize.html.
+by this fix for access by various "output commands"_Howto_output.html.
+No parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command. This fix is not invoked during "energy
+minimization"_minimize.html.
[Restrictions:] none
diff --git a/doc/src/fix_addforce.txt b/doc/src/fix_addforce.txt
index b2ac95eabb0f4e2e49e4af226ae6cc98ea0d0358..4fdf9a41ddefb31f80e5d391aee7b2adc60c5a35 100644
--- a/doc/src/fix_addforce.txt
+++ b/doc/src/fix_addforce.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -103,25 +103,25 @@ converge properly.
:line
-Styles with a suffix are functionally the same as the corresponding
-style without the suffix. They have been optimized to run faster,
-depending on your available hardware, as discussed in
-"Section 5"_Section_accelerate.html of the manual. The
-accelerated styles take the same arguments and should produce the same
-results, except for round-off and precision issues.
+Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
+functionally the same as the corresponding style without the suffix.
+They have been optimized to run faster, depending on your available
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -150,11 +150,11 @@ integrator the fix is adding its forces. Default is the outermost
level.
This fix computes a global scalar and a global 3-vector of forces,
-which can be accessed by various "output
-commands"_Section_howto.html#howto_15. The scalar is the potential
-energy discussed above. The vector is the total force on the group of
-atoms before the forces on individual atoms are changed by the fix.
-The scalar and vector values calculated by this fix are "extensive".
+which can be accessed by various "output commands"_Howto_output.html.
+The scalar is the potential energy discussed above. The vector is the
+total force on the group of atoms before the forces on individual
+atoms are changed by the fix. The scalar and vector values calculated
+by this fix are "extensive".
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command.
diff --git a/doc/src/fix_addtorque.txt b/doc/src/fix_addtorque.txt
index 793ec0e0157121a404a6991a2e67d9c01444ae21..0963915e7a38aabb9db22c12a7fcac6b918c35a9 100644
--- a/doc/src/fix_addtorque.txt
+++ b/doc/src/fix_addtorque.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -70,11 +70,11 @@ this fix. This allows to set at which level of the "r-RESPA"_run_style.html
integrator the fix is adding its torque. Default is the outermost level.
This fix computes a global scalar and a global 3-vector, which can be
-accessed by various "output commands"_Section_howto.html#howto_15.
-The scalar is the potential energy discussed above. The vector is the
-total torque on the group of atoms before the forces on individual
-atoms are changed by the fix. The scalar and vector values calculated
-by this fix are "extensive".
+accessed by various "output commands"_Howto_output.html. The scalar
+is the potential energy discussed above. The vector is the total
+torque on the group of atoms before the forces on individual atoms are
+changed by the fix. The scalar and vector values calculated by this
+fix are "extensive".
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command.
@@ -88,8 +88,8 @@ the iteration count during the minimization.
[Restrictions:]
This fix is part of the USER-MISC package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/fix_append_atoms.txt b/doc/src/fix_append_atoms.txt
index 27070c9be53f3d725e5f4492a1d35ce1deffead2..d83f265982cdaadc3303c751779e1d7cf9112b18 100644
--- a/doc/src/fix_append_atoms.txt
+++ b/doc/src/fix_append_atoms.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -87,16 +87,16 @@ define the lattice spacings.
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
-by this fix for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of this fix can
-be used with the {start/stop} keywords of the "run"_run.html command.
-This fix is not invoked during "energy minimization"_minimize.html.
+by this fix for access by various "output commands"_Howto_output.html.
+No parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command. This fix is not invoked during "energy
+minimization"_minimize.html.
[Restrictions:]
This fix style is part of the SHOCK package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
The boundary on which atoms are added with append/atoms must be
shrink/minimum. The opposite boundary may be any boundary type other
diff --git a/doc/src/fix_atc.txt b/doc/src/fix_atc.txt
index 49014f0591ff08e6f6e636067eed11ee9c8aab43..6de917e5714e6b68537b1180a7f7c5b9769cec81 100644
--- a/doc/src/fix_atc.txt
+++ b/doc/src/fix_atc.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -102,7 +102,13 @@ Note coupling and post-processing can be combined in the same simulations using
[Restart, fix_modify, output, run start/stop, minimize info:]
-No information about this fix is written to "binary restart files"_restart.html. The "fix_modify"_fix_modify.html options relevant to this fix are listed below. No global scalar or vector or per-atom quantities are stored by this fix for access by various "output commands"_Section_howto.html#howto_15. No parameter of this fix can be used with the {start/stop} keywords of the "run"_run.html command. This fix is not invoked during "energy minimization"_minimize.html.
+No information about this fix is written to "binary restart
+files"_restart.html. The "fix_modify"_fix_modify.html options
+relevant to this fix are listed below. No global scalar or vector or
+per-atom quantities are stored by this fix for access by various
+"output commands"_Howto_output.html. No parameter of this fix can be
+used with the {start/stop} keywords of the "run"_run.html command.
+This fix is not invoked during "energy minimization"_minimize.html.
[Restrictions:]
diff --git a/doc/src/fix_atom_swap.txt b/doc/src/fix_atom_swap.txt
index bf56277214bf78ac10270d40ea2fcd56c1391aa7..22091eca005540b5316aee0bccd2c3d4e77aa2ba 100644
--- a/doc/src/fix_atom_swap.txt
+++ b/doc/src/fix_atom_swap.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -150,8 +150,8 @@ None of the "fix_modify"_fix_modify.html options are relevant to this
fix.
This fix computes a global vector of length 2, which can be accessed
-by various "output commands"_Section_howto.html#howto_15. The vector
-values are the following global cumulative quantities:
+by various "output commands"_Howto_output.html. The vector values are
+the following global cumulative quantities:
1 = swap attempts
2 = swap successes :ul
@@ -165,8 +165,8 @@ minimization"_minimize.html.
[Restrictions:]
This fix is part of the MC package. It is only enabled if LAMMPS was
-built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+built with that package. See the "Build package"_Build_package.html
+doc page for more info.
[Related commands:]
diff --git a/doc/src/fix_ave_atom.txt b/doc/src/fix_ave_atom.txt
index 3251125a5d2f21e8f9cdeea958112a5a23b59506..10deaf64cd2900ee76be741c7a835ed2d0e04175 100644
--- a/doc/src/fix_ave_atom.txt
+++ b/doc/src/fix_ave_atom.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -38,7 +38,7 @@ fix 1 all ave/atom 10 20 1000 c_my_stress\[*\] :pre
Use one or more per-atom vectors as inputs every few timesteps, and
average them atom by atom over longer timescales. The resulting
per-atom averages can be used by other "output
-commands"_Section_howto.html#howto_15 such as the "fix
+commands"_Howto_output.html such as the "fix
ave/chunk"_fix_ave_chunk.html or "dump custom"_dump.html commands.
The group specified with the command means only atoms within the group
@@ -124,7 +124,7 @@ appended, the per-atom vector calculated by the compute is used. If a
bracketed term containing an index I is appended, the Ith column of
the per-atom array calculated by the compute is used. Users can also
write code for their own compute styles and "add them to
-LAMMPS"_Section_modify.html. See the discussion above for how I can
+LAMMPS"_Modify.html. See the discussion above for how I can
be specified with a wildcard asterisk to effectively specify multiple
values.
@@ -136,8 +136,8 @@ the per-atom array calculated by the fix is used. Note that some
fixes only produce their values on certain timesteps, which must be
compatible with {Nevery}, else an error will result. Users can also
write code for their own fix styles and "add them to
-LAMMPS"_Section_modify.html. See the discussion above for how I can
-be specified with a wildcard asterisk to effectively specify multiple
+LAMMPS"_Modify.html. See the discussion above for how I can be
+specified with a wildcard asterisk to effectively specify multiple
values.
If a value begins with "v_", a variable name must follow which has
@@ -155,14 +155,14 @@ No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global scalar or vector quantities are
stored by this fix for access by various "output
-commands"_Section_howto.html#howto_15.
+commands"_Howto_output.html.
This fix produces a per-atom vector or array which can be accessed by
-various "output commands"_Section_howto.html#howto_15. A vector is
-produced if only a single quantity is averaged by this fix. If two or
-more quantities are averaged, then an array of values is produced.
-The per-atom values can only be accessed on timesteps that are
-multiples of {Nfreq} since that is when averaging is performed.
+various "output commands"_Howto_output.html. A vector is produced if
+only a single quantity is averaged by this fix. If two or more
+quantities are averaged, then an array of values is produced. The
+per-atom values can only be accessed on timesteps that are multiples
+of {Nfreq} since that is when averaging is performed.
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command. This fix is not invoked during "energy
diff --git a/doc/src/fix_ave_chunk.txt b/doc/src/fix_ave_chunk.txt
index a8691d376772f458d5c0ed82376fcd0154b7a69a..d331e512953b8c32817f0aef973ca99d4289216a 100644
--- a/doc/src/fix_ave_chunk.txt
+++ b/doc/src/fix_ave_chunk.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -85,17 +85,17 @@ fix 1 flow ave/chunk 100 10 1000 cc1 vx vz norm sample file vel.profile :pre
Use one or more per-atom vectors as inputs every few timesteps, sum
the values over the atoms in each chunk at each timestep, then average
the per-chunk values over longer timescales. The resulting chunk
-averages can be used by other "output
-commands"_Section_howto.html#howto_15 such as "thermo_style
-custom"_thermo_style.html, and can also be written to a file.
+averages can be used by other "output commands"_Howto_output.html such
+as "thermo_style custom"_thermo_style.html, and can also be written to
+a file.
In LAMMPS, chunks are collections of atoms defined by a "compute
chunk/atom"_compute_chunk_atom.html command, which assigns each atom
to a single chunk (or no chunk). The ID for this command is specified
as chunkID. For example, a single chunk could be the atoms in a
molecule or atoms in a spatial bin. See the "compute
-chunk/atom"_compute_chunk_atom.html doc page and "Section
-6.23"_Section_howto.html#howto_23 for details of how chunks can be
+chunk/atom"_compute_chunk_atom.html doc page and the "Howto
+chunk"_Howto_chunk.html doc page for details of how chunks can be
defined and examples of how they can be used to measure properties of
a system.
@@ -263,7 +263,7 @@ previously defined in the input script. If no bracketed integer is
appended, the per-atom vector calculated by the compute is used. If a
bracketed integer is appended, the Ith column of the per-atom array
calculated by the compute is used. Users can also write code for
-their own compute styles and "add them to LAMMPS"_Section_modify.html.
+their own compute styles and "add them to LAMMPS"_Modify.html.
See the discussion above for how I can be specified with a wildcard
asterisk to effectively specify multiple values.
@@ -274,7 +274,7 @@ bracketed integer is appended, the Ith column of the per-atom array
calculated by the fix is used. Note that some fixes only produce
their values on certain timesteps, which must be compatible with
{Nevery}, else an error results. Users can also write code for their
-own fix styles and "add them to LAMMPS"_Section_modify.html. See the
+own fix styles and "add them to LAMMPS"_Modify.html. See the
discussion above for how I can be specified with a wildcard asterisk
to effectively specify multiple values.
@@ -456,20 +456,19 @@ files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix.
This fix computes a global array of values which can be accessed by
-various "output commands"_Section_howto.html#howto_15. The values can
-only be accessed on timesteps that are multiples of {Nfreq} since that
-is when averaging is performed. The global array has # of rows =
-the number of chunks {Nchunk} as calculated by the specified "compute
+various "output commands"_Howto_output.html. The values can only be
+accessed on timesteps that are multiples of {Nfreq} since that is when
+averaging is performed. The global array has # of rows = the number
+of chunks {Nchunk} as calculated by the specified "compute
chunk/atom"_compute_chunk_atom.html command. The # of columns =
M+1+Nvalues, where M = 1 to 4, depending on whether the optional
-columns for OrigID and CoordN are used, as explained above.
-Following the optional columns, the next column contains the count of
-atoms in the chunk, and the remaining columns are the Nvalue
-quantities. When the array is accessed with a row I that exceeds the
-current number of chunks, than a 0.0 is returned by the fix instead of
-an error, since the number of chunks can vary as a simulation runs
-depending on how that value is computed by the compute chunk/atom
-command.
+columns for OrigID and CoordN are used, as explained above. Following
+the optional columns, the next column contains the count of atoms in
+the chunk, and the remaining columns are the Nvalue quantities. When
+the array is accessed with a row I that exceeds the current number of
+chunks, than a 0.0 is returned by the fix instead of an error, since
+the number of chunks can vary as a simulation runs depending on how
+that value is computed by the compute chunk/atom command.
The array values calculated by this fix are treated as "intensive",
since they are typically already normalized by the count of atoms in
diff --git a/doc/src/fix_ave_correlate.txt b/doc/src/fix_ave_correlate.txt
index 371f2f66a88f5394bac76c74e18a811939eb6961..22e8768f1d04444df665513b4d5651c1e31cdbde 100644
--- a/doc/src/fix_ave_correlate.txt
+++ b/doc/src/fix_ave_correlate.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -68,7 +68,7 @@ calculate time correlations between them at varying time intervals,
and average the correlation data over longer timescales. The
resulting correlation values can be time integrated by
"variables"_variable.html or used by other "output
-commands"_Section_howto.html#howto_15 such as "thermo_style
+commands"_Howto_output.html such as "thermo_style
custom"_thermo_style.html, and can also be written to a file. See the
"fix ave/correlate/long"_fix_ave_correlate_long.html command for an
alternate method for computing correlation functions efficiently over
@@ -176,7 +176,7 @@ output"_thermo_style.html or other fixes such as "fix nvt"_fix_nh.html
or "fix temp/rescale"_fix_temp_rescale.html. See the doc pages for
these commands which give the IDs of these computes. Users can also
write code for their own compute styles and "add them to
-LAMMPS"_Section_modify.html.
+LAMMPS"_Modify.html.
If a value begins with "f_", a fix ID must follow which has been
previously defined in the input script. If no bracketed term is
@@ -189,7 +189,7 @@ values.
Note that some fixes only produce their values on certain timesteps,
which must be compatible with {Nevery}, else an error will result.
Users can also write code for their own fix styles and "add them to
-LAMMPS"_Section_modify.html.
+LAMMPS"_Modify.html.
If a value begins with "v_", a variable name must follow which has
been previously defined in the input script. Only equal-style or
@@ -313,16 +313,15 @@ files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix.
This fix computes a global array of values which can be accessed by
-various "output commands"_Section_howto.html#howto_15. The values can
-only be accessed on timesteps that are multiples of {Nfreq} since that
-is when averaging is performed. The global array has # of rows =
-{Nrepeat} and # of columns = Npair+2. The first column has the time
-delta (in timesteps) between the pairs of input values used to
-calculate the correlation, as described above. The 2nd column has the
-number of samples contributing to the correlation average, as
-described above. The remaining Npair columns are for I,J pairs of the
-N input values, as determined by the {type} keyword, as described
-above.
+various "output commands"_Howto_output.html. The values can only be
+accessed on timesteps that are multiples of {Nfreq} since that is when
+averaging is performed. The global array has # of rows = {Nrepeat}
+and # of columns = Npair+2. The first column has the time delta (in
+timesteps) between the pairs of input values used to calculate the
+correlation, as described above. The 2nd column has the number of
+samples contributing to the correlation average, as described above.
+The remaining Npair columns are for I,J pairs of the N input values,
+as determined by the {type} keyword, as described above.
For {type} = {auto}, the Npair = N columns are ordered: C11, C22, ...,
CNN. :ulb,l
diff --git a/doc/src/fix_ave_correlate_long.txt b/doc/src/fix_ave_correlate_long.txt
index 7b4bc53701cf9232ca87cd6cec1ceee38ac67690..d94bf8af7b08daf2767255ddeaaed993c2e1691a 100644
--- a/doc/src/fix_ave_correlate_long.txt
+++ b/doc/src/fix_ave_correlate_long.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -120,8 +120,8 @@ the run command. This fix is not invoked during energy minimization.
[Restrictions:]
This compute is part of the USER-MISC package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/fix_ave_histo.txt b/doc/src/fix_ave_histo.txt
index 043f0e22be3c7dda7b85209b9b6c53c3578c5b30..f1da130ff7e25c84528bda44cc2e582a8e910274 100644
--- a/doc/src/fix_ave_histo.txt
+++ b/doc/src/fix_ave_histo.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -69,10 +69,9 @@ fix 1 all ave/histo/weight 1 1 1 10 100 2000 c_XRD\[1\] c_XRD\[2\] :pre
Use one or more values as inputs every few timesteps to create a
single histogram. The histogram can then be averaged over longer
timescales. The resulting histogram can be used by other "output
-commands"_Section_howto.html#howto_15, and can also be written to a
-file. The fix ave/histo/weight command has identical syntax to fix
-ave/histo, except that exactly two values must be specified. See
-details below.
+commands"_Howto_output.html, and can also be written to a file. The
+fix ave/histo/weight command has identical syntax to fix ave/histo,
+except that exactly two values must be specified. See details below.
The group specified with this command is ignored for global and local
input values. For per-atom input values, only atoms in the group
@@ -183,11 +182,11 @@ Note that there is a "compute reduce"_compute_reduce.html command
which can sum per-atom quantities into a global scalar or vector which
can thus be accessed by fix ave/histo. Or it can be a compute defined
not in your input script, but by "thermodynamic
-output"_thermo_style.html or other fixes such as "fix
-nvt"_fix_nh.html or "fix temp/rescale"_fix_temp_rescale.html. See
-the doc pages for these commands which give the IDs of these computes.
-Users can also write code for their own compute styles and "add them
-to LAMMPS"_Section_modify.html.
+output"_thermo_style.html or other fixes such as "fix nvt"_fix_nh.html
+or "fix temp/rescale"_fix_temp_rescale.html. See the doc pages for
+these commands which give the IDs of these computes. Users can also
+write code for their own compute styles and "add them to
+LAMMPS"_Modify.html.
If a value begins with "f_", a fix ID must follow which has been
previously defined in the input script. If {mode} = scalar, then if
@@ -204,7 +203,7 @@ values.
Note that some fixes only produce their values on certain timesteps,
which must be compatible with {Nevery}, else an error will result.
Users can also write code for their own fix styles and "add them to
-LAMMPS"_Section_modify.html.
+LAMMPS"_Modify.html.
If a value begins with "v_", a variable name must follow which has
been previously defined in the input script. If {mode} = scalar, then
@@ -320,10 +319,10 @@ files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix.
This fix produces a global vector and global array which can be
-accessed by various "output commands"_Section_howto.html#howto_15.
-The values can only be accessed on timesteps that are multiples of
-{Nfreq} since that is when a histogram is generated. The global
-vector has 4 values:
+accessed by various "output commands"_Howto_output.html. The values
+can only be accessed on timesteps that are multiples of {Nfreq} since
+that is when a histogram is generated. The global vector has 4
+values:
1 = total counts in the histogram
2 = values that were not histogrammed (see {beyond} keyword)
diff --git a/doc/src/fix_ave_time.txt b/doc/src/fix_ave_time.txt
index 266e3f0e38488694dfce0b442a607a6851483377..a53e318d3fd83a3aab0382876b305681ed17ee0b 100644
--- a/doc/src/fix_ave_time.txt
+++ b/doc/src/fix_ave_time.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -64,7 +64,7 @@ fix 1 all ave/time 1 100 1000 f_indent f_indent\[1\] file temp.indent off 1 :pre
Use one or more global values as inputs every few timesteps, and
average them over longer timescales. The resulting averages can be
-used by other "output commands"_Section_howto.html#howto_15 such as
+used by other "output commands"_Howto_output.html such as
"thermo_style custom"_thermo_style.html, and can also be written to a
file. Note that if no time averaging is done, this command can be
used as a convenient way to simply output one or more global values to
@@ -168,7 +168,7 @@ output"_thermo_style.html or other fixes such as "fix
nvt"_fix_nh.html or "fix temp/rescale"_fix_temp_rescale.html. See
the doc pages for these commands which give the IDs of these computes.
Users can also write code for their own compute styles and "add them
-to LAMMPS"_Section_modify.html.
+to LAMMPS"_Modify.html.
If a value begins with "f_", a fix ID must follow which has been
previously defined in the input script. If {mode} = scalar, then if
@@ -184,7 +184,7 @@ specify multiple values.
Note that some fixes only produce their values on certain timesteps,
which must be compatible with {Nevery}, else an error will result.
Users can also write code for their own fix styles and "add them to
-LAMMPS"_Section_modify.html.
+LAMMPS"_Modify.html.
If a value begins with "v_", a variable name must follow which has
been previously defined in the input script. If {mode} = scalar, then
@@ -305,10 +305,9 @@ files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix.
This fix produces a global scalar or global vector or global array
-which can be accessed by various "output
-commands"_Section_howto.html#howto_15. The values can only be
-accessed on timesteps that are multiples of {Nfreq} since that is when
-averaging is performed.
+which can be accessed by various "output commands"_Howto_output.html.
+The values can only be accessed on timesteps that are multiples of
+{Nfreq} since that is when averaging is performed.
A scalar is produced if only a single input value is averaged and
{mode} = scalar. A vector is produced if multiple input values are
diff --git a/doc/src/fix_aveforce.txt b/doc/src/fix_aveforce.txt
index 5d7dec3e6aef7bb804f312546cb15bbe85b0e639..8c759864c67eb60bf8583d3654c4f4d51a55fca1 100644
--- a/doc/src/fix_aveforce.txt
+++ b/doc/src/fix_aveforce.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -63,25 +63,25 @@ to it.
:line
-Styles with a suffix are functionally the same as the corresponding
-style without the suffix. They have been optimized to run faster,
-depending on your available hardware, as discussed in
-"Section 5"_Section_accelerate.html of the manual. The
-accelerated styles take the same arguments and should produce the same
-results, except for round-off and precision issues.
+Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
+functionally the same as the corresponding style without the suffix.
+They have been optimized to run faster, depending on your available
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -95,10 +95,10 @@ fix. This allows to set at which level of the "r-RESPA"_run_style.html
integrator the fix is adding its forces. Default is the outermost level.
This fix computes a global 3-vector of forces, which can be accessed
-by various "output commands"_Section_howto.html#howto_15. This is the
-total force on the group of atoms before the forces on individual
-atoms are changed by the fix. The vector values calculated by this
-fix are "extensive".
+by various "output commands"_Howto_output.html. This is the total
+force on the group of atoms before the forces on individual atoms are
+changed by the fix. The vector values calculated by this fix are
+"extensive".
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command.
diff --git a/doc/src/fix_balance.txt b/doc/src/fix_balance.txt
index f148e6f99663fe6028e83a246f334b5160ddb470..2de17cdd2a992344886a3eec4d92bc8e3d15b893 100644
--- a/doc/src/fix_balance.txt
+++ b/doc/src/fix_balance.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -357,8 +357,8 @@ number of particles (or total weight) on any processor to the average
number of particles (or total weight) per processor.
These quantities can be accessed by various "output
-commands"_Section_howto.html#howto_15. The scalar and vector values
-calculated by this fix are "intensive".
+commands"_Howto_output.html. The scalar and vector values calculated
+by this fix are "intensive".
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command. This fix is not invoked during "energy
diff --git a/doc/src/fix_bocs.txt b/doc/src/fix_bocs.txt
index f53b7c785c251240a0d325b820545f342ce21c06..7acc22d702e4b7cfd496df2865fdbdc0844bd276 100644
--- a/doc/src/fix_bocs.txt
+++ b/doc/src/fix_bocs.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -85,8 +85,8 @@ XXXX_press, where XXXX is the ID given to the fix bocs command (in the
example, the ID of the fix bocs command is 1 ).
This fix is part of the USER-BOCS package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related:]
diff --git a/doc/src/fix_bond_break.txt b/doc/src/fix_bond_break.txt
index 83364b9efbbb0b6b9135707c15cae7353ca5b0da..59fea8f45b846b3ad94f4d9b29f8617025d1bb4d 100644
--- a/doc/src/fix_bond_break.txt
+++ b/doc/src/fix_bond_break.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -116,8 +116,8 @@ are relevant to this fix.
This fix computes two statistics which it stores in a global vector of
length 2, which can be accessed by various "output
-commands"_Section_howto.html#howto_15. The vector values calculated
-by this fix are "intensive".
+commands"_Howto_output.html. The vector values calculated by this fix
+are "intensive".
These are the 2 quantities:
@@ -131,8 +131,8 @@ minimization"_minimize.html.
[Restrictions:]
This fix is part of the MC package. It is only enabled if LAMMPS was
-built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+built with that package. See the "Build package"_Build_package.html
+doc page for more info.
[Related commands:]
diff --git a/doc/src/fix_bond_create.txt b/doc/src/fix_bond_create.txt
index c0045ac0f081e4df37c9fd6cf201d43238aea88f..02655577fdb2f9c6d712638ef4ed781ae0b1b6dc 100644
--- a/doc/src/fix_bond_create.txt
+++ b/doc/src/fix_bond_create.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -211,8 +211,8 @@ are relevant to this fix.
This fix computes two statistics which it stores in a global vector of
length 2, which can be accessed by various "output
-commands"_Section_howto.html#howto_15. The vector values calculated
-by this fix are "intensive".
+commands"_Howto_output.html. The vector values calculated by this fix
+are "intensive".
These are the 2 quantities:
@@ -226,8 +226,8 @@ minimization"_minimize.html.
[Restrictions:]
This fix is part of the MC package. It is only enabled if LAMMPS was
-built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+built with that package. See the "Build package"_Build_package.html
+doc page for more info.
[Related commands:]
diff --git a/doc/src/fix_bond_react.txt b/doc/src/fix_bond_react.txt
index f85ef9bc1aa6ea034364e5358ac1eafa2824f0d6..7317dd26bb3b9d4b563b0266364490fafc39d37c 100644
--- a/doc/src/fix_bond_react.txt
+++ b/doc/src/fix_bond_react.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -298,9 +298,8 @@ relevant to this fix.
This fix computes one statistic for each {react} argument that it
stores in a global vector, of length 'number of react arguments', that
-can be accessed by various "output
-commands"_Section_howto.html#howto_15. The vector values calculated by
-this fix are "intensive".
+can be accessed by various "output commands"_Howto_output.html. The
+vector values calculated by this fix are "intensive".
These is 1 quantity for each react argument:
@@ -313,8 +312,8 @@ minimization"_minimize.html.
[Restrictions:]
This fix is part of the USER-MISC package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/fix_bond_swap.txt b/doc/src/fix_bond_swap.txt
index ca7069e2478de279e063b5e43f1a82d29fe1f9b1..3c90bb53f6d57606bf1f82870477de9055ff15db 100644
--- a/doc/src/fix_bond_swap.txt
+++ b/doc/src/fix_bond_swap.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -150,13 +150,13 @@ the Boltzmann criterion.
This fix computes two statistical quantities as a global 2-vector of
output, which can be accessed by various "output
-commands"_Section_howto.html#howto_15. The first component of the
-vector is the cumulative number of swaps performed by all processors.
-The second component of the vector is the cumulative number of swaps
-attempted (whether accepted or rejected). Note that a swap "attempt"
-only occurs when swap partners meeting the criteria described above
-are found on a particular timestep. The vector values calculated by
-this fix are "intensive".
+commands"_Howto_output.html. The first component of the vector is the
+cumulative number of swaps performed by all processors. The second
+component of the vector is the cumulative number of swaps attempted
+(whether accepted or rejected). Note that a swap "attempt" only
+occurs when swap partners meeting the criteria described above are
+found on a particular timestep. The vector values calculated by this
+fix are "intensive".
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command. This fix is not invoked during "energy
@@ -165,8 +165,8 @@ minimization"_minimize.html.
[Restrictions:]
This fix is part of the MC package. It is only enabled if LAMMPS was
-built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+built with that package. See the "Build package"_Build_package.html
+doc page for more info.
The settings of the "special_bond" command must be 0,1,1 in order to
use this fix, which is typical of bead-spring chains with FENE or
diff --git a/doc/src/fix_box_relax.txt b/doc/src/fix_box_relax.txt
index e3d75ee858ea82013a59441cbc1fe016fcd19670..29ebeaeef391d370c5bb3f6659ccf73e68fe990b 100644
--- a/doc/src/fix_box_relax.txt
+++ b/doc/src/fix_box_relax.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -126,8 +126,6 @@ minimizer from the new adjusted box size/shape, since that creates a
new objective function valid for the new box size/shape. Repeat as
necessary until the box size/shape has reached its new equilibrium.
-:line
-:line
:line
The {couple} keyword allows two or three of the diagonal components of
@@ -315,17 +313,15 @@ specified by the {press} keyword will be unaffected by the {temp}
setting.
This fix computes a global scalar which can be accessed by various
-"output commands"_Section_howto.html#howto_15. The scalar is the
-pressure-volume energy, plus the strain energy, if it exists,
-as described above.
-The energy values reported at the
-end of a minimization run under "Minimization stats" include this
-energy, and so differ from what LAMMPS normally reports as potential
-energy. This fix does not support the "fix_modify"_fix_modify.html
-{energy} option, because that would result in double-counting of the
-fix energy in the minimization energy. Instead, the fix energy can be
-explicitly added to the potential energy using one of these two
-variants:
+"output commands"_Howto_output.html. The scalar is the pressure-volume
+energy, plus the strain energy, if it exists, as described above. The
+energy values reported at the end of a minimization run under
+"Minimization stats" include this energy, and so differ from what
+LAMMPS normally reports as potential energy. This fix does not support
+the "fix_modify"_fix_modify.html {energy} option, because that would
+result in double-counting of the fix energy in the minimization
+energy. Instead, the fix energy can be explicitly added to the
+potential energy using one of these two variants:
variable emin equal pe+f_1 :pre
diff --git a/doc/src/fix_cmap.txt b/doc/src/fix_cmap.txt
index f8de2b4efec469736a067faa51fd4ac5a7d863eb..ef48e8b51c6c445f3ff1d0e365ec054392ee956f 100644
--- a/doc/src/fix_cmap.txt
+++ b/doc/src/fix_cmap.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -103,9 +103,9 @@ the system's virial as part of "thermodynamic output"_thermo_style.html.
The default is {virial yes}
This fix computes a global scalar which can be accessed by various
-"output commands"_Section_howto.html#howto_15. The scalar is the
-potential energy discussed above. The scalar value calculated by this
-fix is "extensive".
+"output commands"_Howto_output.html. The scalar is the potential
+energy discussed above. The scalar value calculated by this fix is
+"extensive".
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command.
@@ -125,8 +125,8 @@ To function as expected this fix command must be issued {before} a
"read_restart"_read_restart.html command.
This fix can only be used if LAMMPS was built with the MOLECULE
-package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+package. See the "Build package"_Build_package.html doc page for more
+info.
[Related commands:]
diff --git a/doc/src/fix_colvars.txt b/doc/src/fix_colvars.txt
index e48dedacd9e17c54b7f4a28d588d173a821ad289..3a64840bdcc10620033873ce65a42900a7e1a866 100644
--- a/doc/src/fix_colvars.txt
+++ b/doc/src/fix_colvars.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -99,15 +99,15 @@ to the system's potential energy as part of "thermodynamic
output"_thermo_style.html.
This fix computes a global scalar which can be accessed by various
-"output commands"_Section_howto.html#howto_15. The scalar is the
-cumulative energy change due to this fix. The scalar value
-calculated by this fix is "extensive".
+"output commands"_Howto_output.html. The scalar is the cumulative
+energy change due to this fix. The scalar value calculated by this
+fix is "extensive".
[Restrictions:]
This fix is part of the USER-COLVARS package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
There can only be one colvars fix active at a time. Since the interface
communicates only the minimum amount of information and colvars module
diff --git a/doc/src/fix_controller.txt b/doc/src/fix_controller.txt
index cfb26138fdaa468c3074b1ef6fa1f1dfe6c6eb8c..7458f1bcfa015985158cbb3a1148fe625eb964e4 100644
--- a/doc/src/fix_controller.txt
+++ b/doc/src/fix_controller.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -139,7 +139,7 @@ for details. If no bracketed integer is appended, the scalar
calculated by the compute is used. If a bracketed integer is
appended, the Ith value of the vector calculated by the compute is
used. Users can also write code for their own compute styles and "add
-them to LAMMPS"_Section_modify.html.
+them to LAMMPS"_Modify.html.
If {pvar} begins with "f_", a fix ID must follow which has been
previously defined in the input script and which generates a global
@@ -150,7 +150,7 @@ references the values, or else an error results. If no bracketed integer
is appended, the scalar calculated by the fix is used. If a bracketed
integer is appended, the Ith value of the vector calculated by the fix
is used. Users can also write code for their own fix style and "add
-them to LAMMPS"_Section_modify.html.
+them to LAMMPS"_Modify.html.
If {pvar} begins with "v_", a variable name must follow which has been
previously defined in the input script. Only equal-style variables
@@ -180,9 +180,9 @@ files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix.
This fix produces a global vector with 3 values which can be accessed
-by various "output commands"_Section_howto.html#howto_15. The values
-can be accessed on any timestep, though they are only updated on
-timesteps that are a multiple of {Nevery}.
+by various "output commands"_Howto_output.html. The values can be
+accessed on any timestep, though they are only updated on timesteps
+that are a multiple of {Nevery}.
The three values are the most recent updates made to the control
variable by each of the 3 terms in the PID equation above. The first
diff --git a/doc/src/fix_deform.txt b/doc/src/fix_deform.txt
index c870c73bdccf918288589c5141ba4dbafcc60434..d35c3065a224ae25972e92bfb8b610fc47bdc2f2 100644
--- a/doc/src/fix_deform.txt
+++ b/doc/src/fix_deform.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -94,7 +94,7 @@ nvt/sllod"_fix_nvt_sllod.html and "compute
temp/deform"_compute_temp_deform.html commands for more details. Note
that simulation of a continuously extended system (extensional flow)
can be modeled using the "USER-UEF
-package"_Section_packages.html#USER-UEF and its "fix
+package"_Packages_details.html#PKG-USER-UEF and its "fix
commands"_fix_nh_uef.html.
For the {x}, {y}, {z} parameters, the associated dimension cannot be
@@ -550,33 +550,31 @@ command if you want to include lattice spacings in a variable formula.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
[Restart, fix_modify, output, run start/stop, minimize info:]
This fix will restore the initial box settings from "binary restart
files"_restart.html, which allows the fix to be properly continue
deformation, when using the start/stop options of the "run"_run.html
-command. None of the "fix_modify"_fix_modify.html options
-are relevant to this fix. No global or per-atom quantities are stored
-by this fix for access by various "output
-commands"_Section_howto.html#howto_15.
+command. None of the "fix_modify"_fix_modify.html options are
+relevant to this fix. No global or per-atom quantities are stored by
+this fix for access by various "output commands"_Howto_output.html.
This fix can perform deformation over multiple runs, using the {start}
and {stop} keywords of the "run"_run.html command. See the
diff --git a/doc/src/fix_deposit.txt b/doc/src/fix_deposit.txt
index 477c14ea8955ed45763bb1dd27d1242898e22ff5..265f43bd4be218146ce5384c59b7d57b74ca3bda 100644
--- a/doc/src/fix_deposit.txt
+++ b/doc/src/fix_deposit.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -116,8 +116,8 @@ side = {in}.
NOTE: LAMMPS checks that the specified region is wholly inside the
simulation box. It can do this correctly for orthonormal simulation
-boxes. However for "triclinic boxes"_Section_howto.html#howto_12, it
-only tests against the larger orthonormal box that bounds the tilted
+boxes. However for "triclinic boxes"_Howto_triclinic.html, it only
+tests against the larger orthonormal box that bounds the tilted
simulation box. If the specified region includes volume outside the
tilted box, then an insertion will likely fail, leading to a "lost
atoms" error. Thus for triclinic boxes you should insure the
@@ -263,16 +263,16 @@ operation of the fix continues in an uninterrupted fashion.
None of the "fix_modify"_fix_modify.html options are relevant to this
fix. No global or per-atom quantities are stored by this fix for
-access by various "output commands"_Section_howto.html#howto_15. No
-parameter of this fix can be used with the {start/stop} keywords of
-the "run"_run.html command. This fix is not invoked during "energy
+access by various "output commands"_Howto_output.html. No parameter
+of this fix can be used with the {start/stop} keywords of the
+"run"_run.html command. This fix is not invoked during "energy
minimization"_minimize.html.
[Restrictions:]
This fix is part of the MISC package. It is only enabled if LAMMPS
-was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
The specified insertion region cannot be a "dynamic" region, as
defined by the "region"_region.html command.
diff --git a/doc/src/fix_dpd_energy.txt b/doc/src/fix_dpd_energy.txt
index 1c10d954d6eb910f5863120a405ace281b12e6da..5e8e295de915c91c4df76d59815f2f919f0f0190 100644
--- a/doc/src/fix_dpd_energy.txt
+++ b/doc/src/fix_dpd_energy.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -50,31 +50,30 @@ examples/USER/dpd directory.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This command is part of the USER-DPD package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This fix must be used with an additional fix that specifies time
integration, e.g. "fix nve"_fix_nve.html.
diff --git a/doc/src/fix_dpd_source.txt b/doc/src/fix_dpd_source.txt
index b6decc657cea412ac80a96ff4bcf7d8d84bb6348..691cfe86f15c1840f9fd0b6c2ef1baefa7bf54bb 100644
--- a/doc/src/fix_dpd_source.txt
+++ b/doc/src/fix_dpd_source.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -63,16 +63,16 @@ cuboid domain to apply the source flux to.
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
-by this fix for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of this fix can
-be used with the {start/stop} keywords of the "run"_run.html command.
-This fix is not invoked during "energy minimization"_minimize.html.
+by this fix for access by various "output commands"_Howto_output.html.
+No parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command. This fix is not invoked during "energy
+minimization"_minimize.html.
[Restrictions:]
This fix is part of the USER-MESO package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
Fix {edpd/source} must be used with the "pair_style
edpd"_pair_meso.html command. Fix {tdpd/source} must be used with the
diff --git a/doc/src/fix_drag.txt b/doc/src/fix_drag.txt
index 235d3d38b5f97d91dae8a4fa3122e77486fbf7cd..92e68d13a447e07f9f83c4f5c2a1d1666cbdef53 100644
--- a/doc/src/fix_drag.txt
+++ b/doc/src/fix_drag.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -47,9 +47,9 @@ fix. This allows to set at which level of the "r-RESPA"_run_style.html
integrator the fix is adding its forces. Default is the outermost level.
This fix computes a global 3-vector of forces, which can be accessed
-by various "output commands"_Section_howto.html#howto_15. This is the
-total force on the group of atoms by the drag force. The vector
-values calculated by this fix are "extensive".
+by various "output commands"_Howto_output.html. This is the total
+force on the group of atoms by the drag force. The vector values
+calculated by this fix are "extensive".
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command. This fix is not invoked during "energy
diff --git a/doc/src/fix_drude.txt b/doc/src/fix_drude.txt
index faa354b31439dbecf3dc8e04a3b31e47d1011757..80eb79201b2a8e5e0222337209bbacb074c6c78e 100644
--- a/doc/src/fix_drude.txt
+++ b/doc/src/fix_drude.txt
@@ -3,7 +3,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -25,10 +25,10 @@ fix 1 all drude C C N C N D D D :pre
[Description:]
Assign each atom type in the system to be one of 3 kinds of atoms
-within the Drude polarization model. This fix is designed to be
-used with the "thermalized Drude oscillator
-model"_tutorial_drude.html. Polarizable models in LAMMPS
-are described in "this Section"_Section_howto.html#howto_25.
+within the Drude polarization model. This fix is designed to be used
+with the "thermalized Drude oscillator model"_Howto_drude.html.
+Polarizable models in LAMMPS are described on the "Howto
+polarizable"_Howto_polarizable.html doc page.
The three possible types can be designated with an integer (0,1,2)
or capital letter (N,C,D):
diff --git a/doc/src/fix_drude_transform.txt b/doc/src/fix_drude_transform.txt
index 2e094d528c368ca35e59eb09d67abe2e2eb6198e..8864cc4eb66242f220bbc50a3e87e2e9abb5385a 100644
--- a/doc/src/fix_drude_transform.txt
+++ b/doc/src/fix_drude_transform.txt
@@ -9,7 +9,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -34,8 +34,8 @@ Transform the coordinates of Drude oscillators from real to reduced
and back for thermalizing the Drude oscillators as described in
"(Lamoureux)"_#Lamoureux1 using a Nose-Hoover thermostat. This fix is
designed to be used with the "thermalized Drude oscillator
-model"_tutorial_drude.html. Polarizable models in LAMMPS are
-described in "this Section"_Section_howto.html#howto_25.
+model"_Howto_drude.html. Polarizable models in LAMMPS are described
+on the "Howto polarizable"_Howto_polarizable.html doc page.
Drude oscillators are a pair of atoms representing a single
polarizable atom. Ideally, the mass of Drude particles would vanish
diff --git a/doc/src/fix_dt_reset.txt b/doc/src/fix_dt_reset.txt
index 7605395ca05122bbde2a2600e2349b9026be4b56..be4fbd255b58983cd52ac8a9fbb1e4144b5a2f6c 100644
--- a/doc/src/fix_dt_reset.txt
+++ b/doc/src/fix_dt_reset.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -82,8 +82,8 @@ files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix.
This fix computes a global scalar which can be accessed by various
-"output commands"_Section_howto.html#howto_15. The scalar stores
-the last timestep on which the timestep was reset to a new value.
+"output commands"_Howto_output.html. The scalar stores the last
+timestep on which the timestep was reset to a new value.
The scalar value calculated by this fix is "intensive".
diff --git a/doc/src/fix_efield.txt b/doc/src/fix_efield.txt
index 5d2b86fe4b9c1dcc3cc3b8ae5fd25802d5d1c1bd..cecfb6e6a3ce804b958fd36b89b476e6d466cd2d 100644
--- a/doc/src/fix_efield.txt
+++ b/doc/src/fix_efield.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -134,11 +134,10 @@ fix. This allows to set at which level of the "r-RESPA"_run_style.html
integrator the fix adding its forces. Default is the outermost level.
This fix computes a global scalar and a global 3-vector of forces,
-which can be accessed by various "output
-commands"_Section_howto.html#howto_15. The scalar is the potential
-energy discussed above. The vector is the total force added to the
-group of atoms. The scalar and vector values calculated by this fix
-are "extensive".
+which can be accessed by various "output commands"_Howto_output.html.
+The scalar is the potential energy discussed above. The vector is the
+total force added to the group of atoms. The scalar and vector values
+calculated by this fix are "extensive".
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command.
@@ -157,8 +156,8 @@ system (the quantity being minimized), you MUST enable the
[Restrictions:]
This fix is part of the MISC package. It is only enabled if LAMMPS
-was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/fix_ehex.txt b/doc/src/fix_ehex.txt
index 40752a811fdabe06285d0f980ee9cdd253ac10e6..75651e21a4c5812593699735b9eaf1bc2a549bc7 100644
--- a/doc/src/fix_ehex.txt
+++ b/doc/src/fix_ehex.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -156,8 +156,8 @@ minimization"_minimize.html.
[Restrictions:]
This fix is part of the RIGID package. It is only enabled if LAMMPS
-was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/fix_enforce2d.txt b/doc/src/fix_enforce2d.txt
index 5d04e96677f2adc27c9622b84d97810b23748d7a..17ac8146fd3242d531df02ba409dba553d946b9f 100644
--- a/doc/src/fix_enforce2d.txt
+++ b/doc/src/fix_enforce2d.txt
@@ -2,11 +2,12 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
fix enforce2d command :h3
+fix enforce2d/kk command :h3
[Syntax:]
@@ -27,25 +28,25 @@ not move from their initial z coordinate.
:line
-Styles with a suffix are functionally the same as the corresponding
-style without the suffix. They have been optimized to run faster,
-depending on your available hardware, as discussed in
-"Section 5"_Section_accelerate.html of the manual. The
-accelerated styles take the same arguments and should produce the same
-results, except for round-off and precision issues.
+Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
+functionally the same as the corresponding style without the suffix.
+They have been optimized to run faster, depending on your available
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -54,9 +55,9 @@ more instructions on how to use the accelerated styles effectively.
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
-by this fix for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of this fix can
-be used with the {start/stop} keywords of the "run"_run.html command.
+by this fix for access by various "output commands"_Howto_output.html.
+No parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command.
The forces due to this fix are imposed during an energy minimization,
invoked by the "minimize"_minimize.html command.
diff --git a/doc/src/fix_eos_cv.txt b/doc/src/fix_eos_cv.txt
index 4c973043353c307790aa15447d70ffe77f375e7d..b2ac0eb6b932396ab229d8a14292d65cb1d99b39 100644
--- a/doc/src/fix_eos_cv.txt
+++ b/doc/src/fix_eos_cv.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -39,8 +39,8 @@ possible.
[Restrictions:]
This command is part of the USER-DPD package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This command also requires use of the "atom_style dpd"_atom_style.html
command.
diff --git a/doc/src/fix_eos_table.txt b/doc/src/fix_eos_table.txt
index 42778d79781c80ced6c90855f7fefe78f62d7207..53b32043728d9213e15b2ff86d5b301e0dabf2c5 100644
--- a/doc/src/fix_eos_table.txt
+++ b/doc/src/fix_eos_table.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -99,8 +99,8 @@ one that matches the specified keyword.
[Restrictions:]
This command is part of the USER-DPD package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This command also requires use of the "atom_style dpd"_atom_style.html
command.
diff --git a/doc/src/fix_eos_table_rx.txt b/doc/src/fix_eos_table_rx.txt
index 0c878743471ae03c5bd76fec05f16dbc7631f01e..1a2daa0bc646f19bec6032c43a2adfb28e4d5c36 100644
--- a/doc/src/fix_eos_table_rx.txt
+++ b/doc/src/fix_eos_table_rx.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -156,31 +156,30 @@ no 0.93 0.00 0.000 -1.76 :pre
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This command is part of the USER-DPD package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This command also requires use of the "atom_style dpd"_atom_style.html
command.
diff --git a/doc/src/fix_evaporate.txt b/doc/src/fix_evaporate.txt
index ed6c6d03775d5fe11195b3c3d6ccfc7eb365c909..59dab43d9a200465ba18e883cdb2e3a4dd80b23b 100644
--- a/doc/src/fix_evaporate.txt
+++ b/doc/src/fix_evaporate.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -73,9 +73,9 @@ files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix.
This fix computes a global scalar, which can be accessed by various
-"output commands"_Section_howto.html#howto_15. The scalar is the
-cumulative number of deleted atoms. The scalar value calculated by
-this fix is "intensive".
+"output commands"_Howto_output.html. The scalar is the cumulative
+number of deleted atoms. The scalar value calculated by this fix is
+"intensive".
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command. This fix is not invoked during "energy
@@ -84,8 +84,8 @@ minimization"_minimize.html.
[Restrictions:]
This fix is part of the MISC package. It is only enabled if LAMMPS
-was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/fix_external.txt b/doc/src/fix_external.txt
index b28d33446fe6df61d6efd46017dc37c4cf6f61ee..dd7f7914e96f365db3d523578e88efa8068aee5d 100644
--- a/doc/src/fix_external.txt
+++ b/doc/src/fix_external.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -31,11 +31,10 @@ fix 1 all external pf/array 10 :pre
[Description:]
This fix allows external programs that are running LAMMPS through its
-"library interface"_Section_howto.html#howto_19 to modify certain
-LAMMPS properties on specific timesteps, similar to the way other
-fixes do. The external driver can be a "C/C++ or Fortran
-program"_Section_howto.html#howto_19 or a "Python
-script"_Section_python.html.
+"library interface"_Howto_library.html to modify certain LAMMPS
+properties on specific timesteps, similar to the way other fixes do.
+The external driver can be a "C/C++ or Fortran
+program"_Howto_library.html or a "Python script"_Python_head.html.
:line
@@ -137,9 +136,8 @@ external program to the system's virial as part of "thermodynamic
output"_thermo_style.html. The default is {virial yes}
This fix computes a global scalar which can be accessed by various
-"output commands"_Section_howto.html#howto_15. The scalar is the
-potential energy discussed above. The scalar stored by this fix
-is "extensive".
+"output commands"_Howto_output.html. The scalar is the potential
+energy discussed above. The scalar stored by this fix is "extensive".
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command.
diff --git a/doc/src/fix_filter_corotate.txt b/doc/src/fix_filter_corotate.txt
index b782d285c768ec6f4b25eaf29037cef6695e7613..b30966c2f941de518e42f4c90463f543a21fdad5 100644
--- a/doc/src/fix_filter_corotate.txt
+++ b/doc/src/fix_filter_corotate.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -63,16 +63,15 @@ No information about these fixes is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to these fixes. No global or per-atom quantities are
stored by these fixes for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of these fixes
-can be used with the {start/stop} keywords of the "run"_run.html
-command. These fixes are not invoked during "energy
-minimization"_minimize.html.
+commands"_Howto_output.html. No parameter of these fixes can be used
+with the {start/stop} keywords of the "run"_run.html command. These
+fixes are not invoked during "energy minimization"_minimize.html.
[Restrictions:]
This fix is part of the USER-MISC package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
Currently, it does not support "molecule templates"_molecule.html.
diff --git a/doc/src/fix_flow_gauss.txt b/doc/src/fix_flow_gauss.txt
index efa58ea65fa8b71a940d707dbbabb5119ad90759..46a9477aa2184e4bb7699f8462db78aaf8316bbf 100644
--- a/doc/src/fix_flow_gauss.txt
+++ b/doc/src/fix_flow_gauss.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -111,8 +111,8 @@ flow/gauss fixes, one that specifies {fix_modify respa 3} and one with
[Restart, fix_modify, output, run start/stop, minimize info:]
This fix is part of the USER-MISC package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
No information about this fix is written to "binary restart
files"_restart.html.
@@ -128,11 +128,11 @@ integrator the fix computes and adds the external acceleration. Default is the
outermost level.
This fix computes a global scalar and a global 3-vector of forces,
-which can be accessed by various "output
-commands"_Section_howto.html#howto_15. The scalar is the negative of the
-work done on the system, see above discussion. The vector is the total force
-that this fix applied to the group of atoms on the current timestep.
-The scalar and vector values calculated by this fix are "extensive".
+which can be accessed by various "output commands"_Howto_output.html.
+The scalar is the negative of the work done on the system, see above
+discussion. The vector is the total force that this fix applied to
+the group of atoms on the current timestep. The scalar and vector
+values calculated by this fix are "extensive".
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command.
diff --git a/doc/src/fix_freeze.txt b/doc/src/fix_freeze.txt
index a63ee4cb32688c286797292acbaa140fbed18101..9e085d8b1dc68470b6d991b1ca430f055cb08d83 100644
--- a/doc/src/fix_freeze.txt
+++ b/doc/src/fix_freeze.txt
@@ -2,11 +2,12 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
fix freeze command :h3
+fix freeze/kk command :h3
[Syntax:]
@@ -31,25 +32,25 @@ using "fix setforce"_fix_setforce.html.
:line
-Styles with a suffix are functionally the same as the corresponding
-style without the suffix. They have been optimized to run faster,
-depending on your available hardware, as discussed in
-"Section 5"_Section_accelerate.html of the manual. The
-accelerated styles take the same arguments and should produce the same
-results, except for round-off and precision issues.
+Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
+functionally the same as the corresponding style without the suffix.
+They have been optimized to run faster, depending on your available
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -60,10 +61,10 @@ files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix.
This fix computes a global 3-vector of forces, which can be accessed
-by various "output commands"_Section_howto.html#howto_15. This is the
-total force on the group of atoms before the forces on individual
-atoms are changed by the fix. The vector values calculated by this
-fix are "extensive".
+by various "output commands"_Howto_output.html. This is the total
+force on the group of atoms before the forces on individual atoms are
+changed by the fix. The vector values calculated by this fix are
+"extensive".
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command. This fix is not invoked during "energy
@@ -72,8 +73,8 @@ minimization"_minimize.html.
[Restrictions:]
This fix is part of the GRANULAR package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
There can only be a single freeze fix defined. This is because other
the "granular pair styles"_pair_gran.html treat frozen particles
diff --git a/doc/src/fix_gcmc.txt b/doc/src/fix_gcmc.txt
index 38f0fb95ce0530d425689b0daa9052e6a6995074..6b9a02eecada3fa7f2e8f2886b8ff6b88a106d7c 100644
--- a/doc/src/fix_gcmc.txt
+++ b/doc/src/fix_gcmc.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -349,7 +349,7 @@ in the context of NVT dynamics.
NOTE: If the density of the cell is initially very small or zero, and
increases to a much larger density after a period of equilibration,
then certain quantities that are only calculated once at the start
-(kspace parameters, tail corrections) may no longer be accurate. The
+(kspace parameters) may no longer be accurate. The
solution is to start a new simulation after the equilibrium density
has been reached.
@@ -382,8 +382,8 @@ None of the "fix_modify"_fix_modify.html options are relevant to this
fix.
This fix computes a global vector of length 8, which can be accessed
-by various "output commands"_Section_howto.html#howto_15. The vector
-values are the following global cumulative quantities:
+by various "output commands"_Howto_output.html. The vector values are
+the following global cumulative quantities:
1 = translation attempts
2 = translation successes
@@ -403,8 +403,8 @@ minimization"_minimize.html.
[Restrictions:]
This fix is part of the MC package. It is only enabled if LAMMPS was
-built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+built with that package. See the "Build package"_Build_package.html
+doc page for more info.
Do not set "neigh_modify once yes" or else this fix will never be
called. Reneighboring is required.
diff --git a/doc/src/fix_gld.txt b/doc/src/fix_gld.txt
index 1425f62e13374d3c6f0feb14d624c63a1e2128cf..97c3d0e408e9ea2d4eb675a994cb7c96a579b0e6 100644
--- a/doc/src/fix_gld.txt
+++ b/doc/src/fix_gld.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -126,7 +126,7 @@ sense, a restarted simulation should produce the same behavior.
None of the "fix_modify"_fix_modify.html options are relevant to this
fix. No global or per-atom quantities are stored by this fix for
-access by various "output commands"_Section_howto.html#howto_15.
+access by various "output commands"_Howto_output.html.
This fix can ramp its target temperature over multiple runs, using the
{start} and {stop} keywords of the "run"_run.html command. See the
@@ -137,8 +137,8 @@ This fix is not invoked during "energy minimization"_minimize.html.
[Restrictions:]
This fix is part of the MISC package. It is only enabled if LAMMPS
-was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/fix_gle.txt b/doc/src/fix_gle.txt
index 6568060f0c2482c99607b1af93022a20ec0d6fe6..70a8e7f34246b446d4b40456945c784b11c54665 100644
--- a/doc/src/fix_gle.txt
+++ b/doc/src/fix_gle.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -116,9 +116,9 @@ system's potential energy as part of "thermodynamic
output"_thermo_style.html.
This fix computes a global scalar which can be accessed by various
-"output commands"_Section_howto.html#howto_15. The scalar is the
-cumulative energy change due to this fix. The scalar value
-calculated by this fix is "extensive".
+"output commands"_Howto_output.html. The scalar is the cumulative
+energy change due to this fix. The scalar value calculated by this
+fix is "extensive".
[Restrictions:]
@@ -132,9 +132,9 @@ In order to perform constant-pressure simulations please use
"fix npt"_fix_nh.html, to avoid duplicate integration of the
equations of motion.
-This fix is part of the USER-MISC package. It is only enabled if LAMMPS
-was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+This fix is part of the USER-MISC package. It is only enabled if
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/fix_gravity.txt b/doc/src/fix_gravity.txt
index dae8ac5ed0910fc2c91b776339de840707bf5500..c529a04d34068940256e38bda3948cd796fcbe17 100644
--- a/doc/src/fix_gravity.txt
+++ b/doc/src/fix_gravity.txt
@@ -2,12 +2,13 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
fix gravity command :h3
fix gravity/omp command :h3
+fix gravity/kk command :h3
[Syntax:]
@@ -90,23 +91,22 @@ field.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -125,11 +125,11 @@ fix. This allows to set at which level of the "r-RESPA"_run_style.html
integrator the fix is adding its forces. Default is the outermost level.
This fix computes a global scalar which can be accessed by various
-"output commands"_Section_howto.html#howto_15. This scalar is the
-gravitational potential energy of the particles in the defined field,
-namely mass * (g dot x) for each particles, where x and mass are the
-particles position and mass, and g is the gravitational field. The
-scalar value calculated by this fix is "extensive".
+"output commands"_Howto_output.html. This scalar is the gravitational
+potential energy of the particles in the defined field, namely mass *
+(g dot x) for each particles, where x and mass are the particles
+position and mass, and g is the gravitational field. The scalar value
+calculated by this fix is "extensive".
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command. This fix is not invoked during "energy
diff --git a/doc/src/fix_grem.txt b/doc/src/fix_grem.txt
index 661f68ed99cf21d5c5a08514d78dff411a28880e..e096d4bd3cbe8ee0d461444985ac932f38bab787 100644
--- a/doc/src/fix_grem.txt
+++ b/doc/src/fix_grem.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -91,8 +91,8 @@ by this fix to add the rescaled kinetic pressure as part of
[Restrictions:]
This fix is part of the USER-MISC package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/fix_halt.txt b/doc/src/fix_halt.txt
index 08043eb5fb76659bf851d59444eeec56548b11cd..ec117518d285d488b28a78e552280f1ac7b81c17 100644
--- a/doc/src/fix_halt.txt
+++ b/doc/src/fix_halt.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -133,10 +133,10 @@ files.
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
-by this fix for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of this fix can
-be used with the {start/stop} keywords of the "run"_run.html command.
-This fix is not invoked during "energy minimization"_minimize.html.
+by this fix for access by various "output commands"_Howto_output.html.
+No parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command. This fix is not invoked during "energy
+minimization"_minimize.html.
[Restrictions:] none
diff --git a/doc/src/fix_heat.txt b/doc/src/fix_heat.txt
index 23db87dac27d8fc51d958bb1df857a0b6539e426..6db75926091bf4aac4e7fafa5679dab9e58231f4 100644
--- a/doc/src/fix_heat.txt
+++ b/doc/src/fix_heat.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -108,12 +108,11 @@ files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix.
This fix computes a global scalar which can be accessed by various
-"output commands"_Section_howto.html#howto_15. This scalar is the
-most recent value by which velocites were scaled. The scalar value
-calculated by this fix is "intensive". If {eflux} is specified as
-an atom-style variable, this fix computes the average value by which
-the velocities were scaled for all of the atoms that had their
-velocities scaled.
+"output commands"_Howto_output.html. This scalar is the most recent
+value by which velocites were scaled. The scalar value calculated by
+this fix is "intensive". If {eflux} is specified as an atom-style
+variable, this fix computes the average value by which the velocities
+were scaled for all of the atoms that had their velocities scaled.
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command. This fix is not invoked during "energy
diff --git a/doc/src/fix_imd.txt b/doc/src/fix_imd.txt
index b2756128191740d86ec6a9be5a18a831e48a0627..a58cfdb3d396d7bec9ad67324bec3ba0bbe60fb1 100644
--- a/doc/src/fix_imd.txt
+++ b/doc/src/fix_imd.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -136,15 +136,15 @@ No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global scalar or vector or per-atom
quantities are stored by this fix for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of this fix can
-be used with the {start/stop} keywords of the "run"_run.html command.
-This fix is not invoked during "energy minimization"_minimize.html.
+commands"_Howto_output.html. No parameter of this fix can be used
+with the {start/stop} keywords of the "run"_run.html command. This
+fix is not invoked during "energy minimization"_minimize.html.
[Restrictions:]
This fix is part of the USER-MISC package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
When used in combination with VMD, a topology or coordinate file has
to be loaded, which matches (in number and ordering of atoms) the
diff --git a/doc/src/fix_indent.txt b/doc/src/fix_indent.txt
index c9a791ae4ece3069805ac86172ffae4805361076..9931793c0bffbc1398bee31bf7a5c87cda692d7d 100644
--- a/doc/src/fix_indent.txt
+++ b/doc/src/fix_indent.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -180,8 +180,8 @@ integrator the fix is adding its forces. Default is the outermost level.
This fix computes a global scalar energy and a global 3-vector of
forces (on the indenter), which can be accessed by various "output
-commands"_Section_howto.html#howto_15. The scalar and vector values
-calculated by this fix are "extensive".
+commands"_Howto_output.html. The scalar and vector values calculated
+by this fix are "extensive".
The forces due to this fix are imposed during an energy minimization,
invoked by the "minimize"_minimize.html command. Note that if you
diff --git a/doc/src/fix_ipi.txt b/doc/src/fix_ipi.txt
index 07e8025d77061db6e41fd3c3e765898664f2ffcd..b115aba7dfa38d5a85a0aee82000d2e8bf568fcd 100644
--- a/doc/src/fix_ipi.txt
+++ b/doc/src/fix_ipi.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -81,9 +81,9 @@ define an external potential acting on the atoms that are moved by
i-PI.
This fix is part of the USER-MISC package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info. Because of
-the use of UNIX domain sockets, this fix will only work in a UNIX
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info. Because of the
+use of UNIX domain sockets, this fix will only work in a UNIX
environment.
[Related commands:]
diff --git a/doc/src/fix_langevin.txt b/doc/src/fix_langevin.txt
index 93c73f5a5dd2390f93d80dfe7ce2d4efc7f53e69..e97c7c3c3785011551f6c7b476c709acc2ec1925 100644
--- a/doc/src/fix_langevin.txt
+++ b/doc/src/fix_langevin.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -101,7 +101,7 @@ should not normally be used on atoms that also have their temperature
controlled by another fix - e.g. by "fix nvt"_fix_nh.html or "fix
temp/rescale"_fix_temp_rescale.html commands.
-See "this howto section"_Section_howto.html#howto_16 of the manual for
+See the "Howto thermostat"_Howto_thermostat.html doc page for
a discussion of different ways to compute temperature and perform
thermostatting.
@@ -264,23 +264,22 @@ generates an average temperature of 220 K, instead of 300 K.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -306,10 +305,10 @@ output"_thermo_style.html. Note that use of this option requires
setting the {tally} keyword to {yes}.
This fix computes a global scalar which can be accessed by various
-"output commands"_Section_howto.html#howto_15. The scalar is the
-cumulative energy change due to this fix. The scalar value
-calculated by this fix is "extensive". Note that calculation of this
-quantity requires setting the {tally} keyword to {yes}.
+"output commands"_Howto_output.html. The scalar is the cumulative
+energy change due to this fix. The scalar value calculated by this
+fix is "extensive". Note that calculation of this quantity requires
+setting the {tally} keyword to {yes}.
This fix can ramp its target temperature over multiple runs, using the
{start} and {stop} keywords of the "run"_run.html command. See the
diff --git a/doc/src/fix_langevin_drude.txt b/doc/src/fix_langevin_drude.txt
index c85ff24c96d2982439d67c4ac52fd3bea5083044..19a3f87ffc0a20fb66038671e6a76529c5a1db6d 100644
--- a/doc/src/fix_langevin_drude.txt
+++ b/doc/src/fix_langevin_drude.txt
@@ -9,7 +9,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -44,8 +44,9 @@ fix 1 all langevin/drude 298.15 100.0 19377 5.0 10.0 83451 zero yes :pre
Apply two Langevin thermostats as described in "(Jiang)"_#Jiang1 for
thermalizing the reduced degrees of freedom of Drude oscillators.
This link describes how to use the "thermalized Drude oscillator
-model"_tutorial_drude.html in LAMMPS and polarizable models in LAMMPS
-are discussed in "this Section"_Section_howto.html#howto_25.
+model"_Howto_drude.html in LAMMPS and polarizable models in LAMMPS
+are discussed on the "Howto polarizable"_Howto_polarizable.html doc
+page.
Drude oscillators are a way to simulate polarizables atoms, by
splitting them into a core and a Drude particle bound by a harmonic
@@ -99,8 +100,8 @@ Likewise, this fix should not normally be used on atoms that also have
their temperature controlled by another fix - e.g. by "fix
nvt"_fix_nh.html or "fix temp/rescale"_fix_temp_rescale.html commands.
-See "this howto section"_Section_howto.html#howto_16 of the manual for
-a discussion of different ways to compute temperature and perform
+See the "Howto thermostat"_Howto_thermostat.html doc page for a
+discussion of different ways to compute temperature and perform
thermostating.
:line
diff --git a/doc/src/fix_langevin_eff.txt b/doc/src/fix_langevin_eff.txt
index 4a50bfae54d1a058b3b31bf86159e838163ff87f..e55e40c6c80ea7e822222ffc84eedbbf9841d9e3 100644
--- a/doc/src/fix_langevin_eff.txt
+++ b/doc/src/fix_langevin_eff.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -79,10 +79,10 @@ output"_thermo_style.html. Note that use of this option requires
setting the {tally} keyword to {yes}.
This fix computes a global scalar which can be accessed by various
-"output commands"_Section_howto.html#howto_15. The scalar is the
-cumulative energy change due to this fix. The scalar value
-calculated by this fix is "extensive". Note that calculation of this
-quantity requires setting the {tally} keyword to {yes}.
+"output commands"_Howto_output.html. The scalar is the cumulative
+energy change due to this fix. The scalar value calculated by this
+fix is "extensive". Note that calculation of this quantity requires
+setting the {tally} keyword to {yes}.
This fix can ramp its target temperature over multiple runs, using the
{start} and {stop} keywords of the "run"_run.html command. See the
@@ -93,8 +93,8 @@ This fix is not invoked during "energy minimization"_minimize.html.
[Restrictions:] none
This fix is part of the USER-EFF package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/fix_langevin_spin.txt b/doc/src/fix_langevin_spin.txt
index 51f085ebdcbd389dbceebe8e28f5d31fbe1ee4ac..7bb25e0a687af2c0af3f14a1ccd9d0c9a73e7257 100644
--- a/doc/src/fix_langevin_spin.txt
+++ b/doc/src/fix_langevin_spin.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -76,9 +76,9 @@ This fix is not invoked during "energy minimization"_minimize.html.
[Restrictions:]
-The {langevin/spin} fix is part of the SPIN package.
-This style is only enabled if LAMMPS was built with this package.
-See the "Making LAMMPS"_Section_start.html#start_3 section for more info.
+The {langevin/spin} fix is part of the SPIN package. This style is
+only enabled if LAMMPS was built with this package. See the "Build
+package"_Build_package.html doc page for more info.
The numerical integration has to be performed with {fix nve/spin}
when {fix langevin/spin} is enabled.
@@ -98,5 +98,5 @@ integration fix (e.g. {fix nve/spin}).
[(Mayergoyz)] I.D. Mayergoyz, G. Bertotti, C. Serpico (2009). Elsevier (2009)
:link(Tranchida2)
-[(Tranchida)] Tranchida, Plimpton, Thibaudeau and Thompson,
-arXiv preprint arXiv:1801.10233, (2018).
+[(Tranchida)] Tranchida, Plimpton, Thibaudeau and Thompson,
+Journal of Computational Physics, (2018).
diff --git a/doc/src/fix_latte.txt b/doc/src/fix_latte.txt
index 4edd610546350ac082789fb517af918c7167c1f3..bd61e29dcb66f9c19772345cbe3c19161143474e 100644
--- a/doc/src/fix_latte.txt
+++ b/doc/src/fix_latte.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -118,9 +118,9 @@ of "thermodynamic output"_thermo_style.html. The default is {virial
yes}
This fix computes a global scalar which can be accessed by various
-"output commands"_Section_howto.html#howto_15. The scalar is the
-potential energy discussed above. The scalar value calculated by this
-fix is "extensive".
+"output commands"_Howto_output.html. The scalar is the potential
+energy discussed above. The scalar value calculated by this fix is
+"extensive".
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command.
@@ -136,11 +136,11 @@ quantity being minimized), you MUST enable the
[Restrictions:]
This fix is part of the LATTE package. It is only enabled if LAMMPS
-was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
-You must use metal units, as set by the "units"_units command to use
-this fix.
+You must use metal units, as set by the "units"_units.html command to
+use this fix.
LATTE does not currently compute per-atom energy or per-atom virial
contributions. So they will not show up as part of the calculations
@@ -154,8 +154,8 @@ doing 99% or more of the work to compute quantum-accurate forces.
NOTE: NEB calculations can be done using this fix using multiple
replicas and running LAMMPS in parallel. However, each replica must
be run on a single MPI task. For details, see the "neb"_neb.html
-command and -partition command-line explained in "Section
-2.6"_Section_start.html#start_6 of the manual.
+command doc page and the "-partition command-line
+switch"_Run_options.html
[Related commands:] none
diff --git a/doc/src/fix_lb_fluid.txt b/doc/src/fix_lb_fluid.txt
index fc6203b0f2c1967613e81b694977c9dd26accfcf..1a5239782268f34870cd3ec3faac1b560f7c451a 100644
--- a/doc/src/fix_lb_fluid.txt
+++ b/doc/src/fix_lb_fluid.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -299,16 +299,16 @@ is written to the main LAMMPS "binary restart files"_restart.html.
None of the "fix_modify"_fix_modify.html options are relevant to this
fix. No global or per-atom quantities are stored by this fix for
-access by various "output commands"_Section_howto.html#howto_15. No
-parameter of this fix can be used with the {start/stop} keywords of
-the "run"_run.html command. This fix is not invoked during "energy
+access by various "output commands"_Howto_output.html. No parameter
+of this fix can be used with the {start/stop} keywords of the
+"run"_run.html command. This fix is not invoked during "energy
minimization"_minimize.html.
[Restrictions:]
This fix is part of the USER-LB package. It is only enabled if LAMMPS
-was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This fix can only be used with an orthogonal simulation domain.
diff --git a/doc/src/fix_lb_momentum.txt b/doc/src/fix_lb_momentum.txt
index 97965e870d95b70688428bd17304bdb83dce43e5..408978f64c40cb1eff59995ed62481c1200b4960 100644
--- a/doc/src/fix_lb_momentum.txt
+++ b/doc/src/fix_lb_momentum.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -49,10 +49,10 @@ dimension.
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
-by this fix for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of this fix can be
-used with the {start/stop} keywords of the "run"_run.html command.
-This fix is not invoked during "energy minimization"_minimize.html.
+by this fix for access by various "output commands"_Howto_output.html.
+No parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command. This fix is not invoked during "energy
+minimization"_minimize.html.
[Restrictions:]
@@ -61,8 +61,8 @@ Can only be used if a lattice-Boltzmann fluid has been created via the
command.
This fix is part of the USER-LB package. It is only enabled if LAMMPS
-was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/fix_lb_pc.txt b/doc/src/fix_lb_pc.txt
index d2b6aafaab84a38d890abba5d5125ca5327f9687..05b5eb20a21ce268024eda47782fae035496efb2 100644
--- a/doc/src/fix_lb_pc.txt
+++ b/doc/src/fix_lb_pc.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -34,16 +34,16 @@ algorithm if the force coupling constant has been set by default.
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
-by this fix for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of this fix can be
-used with the {start/stop} keywords of the "run"_run.html command.
-This fix is not invoked during "energy minimization"_minimize.html.
+by this fix for access by various "output commands"_Howto_output.html.
+No parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command. This fix is not invoked during "energy
+minimization"_minimize.html.
[Restrictions:]
This fix is part of the USER-LB package. It is only enabled if LAMMPS
-was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
Can only be used if a lattice-Boltzmann fluid has been created via the
"fix lb/fluid"_fix_lb_fluid.html command, and must come after this
diff --git a/doc/src/fix_lb_rigid_pc_sphere.txt b/doc/src/fix_lb_rigid_pc_sphere.txt
index 468ebe1ff5d31e8b224e6b864b3a8949eafd7c22..ddaa552ecc15165daa71f813b532e3737f5f6e80 100644
--- a/doc/src/fix_lb_rigid_pc_sphere.txt
+++ b/doc/src/fix_lb_rigid_pc_sphere.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -80,12 +80,12 @@ assumes the constituent atoms are point particles); see
No information about the {rigid} and {rigid/nve} fixes are written to
"binary restart files"_restart.html.
-Similar to the "fix rigid"_fix_rigid.html command: The rigid
-fix computes a global scalar which can be accessed by various "output
-commands"_Section_howto.html#howto_15. The scalar value calculated by
-these fixes is "intensive". The scalar is the current temperature of
-the collection of rigid bodies. This is averaged over all rigid
-bodies and their translational and rotational degrees of freedom. The
+Similar to the "fix rigid"_fix_rigid.html command: The rigid fix
+computes a global scalar which can be accessed by various "output
+commands"_Howto_output.html. The scalar value calculated by these
+fixes is "intensive". The scalar is the current temperature of the
+collection of rigid bodies. This is averaged over all rigid bodies
+and their translational and rotational degrees of freedom. The
translational energy of a rigid body is 1/2 m v^2, where m = total
mass of the body and v = the velocity of its center of mass. The
rotational energy of a rigid body is 1/2 I w^2, where I = the moment
@@ -94,17 +94,17 @@ of freedom constrained by the {force} and {torque} keywords are
removed from this calculation.
All of these fixes compute a global array of values which can be
-accessed by various "output commands"_Section_howto.html#howto_15.
-The number of rows in the array is equal to the number of rigid
-bodies. The number of columns is 15. Thus for each rigid body, 15
-values are stored: the xyz coords of the center of mass (COM), the xyz
-components of the COM velocity, the xyz components of the force acting
-on the COM, the xyz components of the torque acting on the COM, and
-the xyz image flags of the COM, which have the same meaning as image
-flags for atom positions (see the "dump" command). The force and
-torque values in the array are not affected by the {force} and
-{torque} keywords in the fix rigid command; they reflect values before
-any changes are made by those keywords.
+accessed by various "output commands"_Howto_output.html. The number
+of rows in the array is equal to the number of rigid bodies. The
+number of columns is 15. Thus for each rigid body, 15 values are
+stored: the xyz coords of the center of mass (COM), the xyz components
+of the COM velocity, the xyz components of the force acting on the
+COM, the xyz components of the torque acting on the COM, and the xyz
+image flags of the COM, which have the same meaning as image flags for
+atom positions (see the "dump" command). The force and torque values
+in the array are not affected by the {force} and {torque} keywords in
+the fix rigid command; they reflect values before any changes are made
+by those keywords.
The ordering of the rigid bodies (by row in the array) is as follows.
For the {single} keyword there is just one rigid body. For the
@@ -122,8 +122,8 @@ of the "run"_run.html command. These fixes are not invoked during
[Restrictions:]
This fix is part of the USER-LB package. It is only enabled if LAMMPS
-was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
Can only be used if a lattice-Boltzmann fluid has been created via the
"fix lb/fluid"_fix_lb_fluid.html command, and must come after this
diff --git a/doc/src/fix_lb_viscous.txt b/doc/src/fix_lb_viscous.txt
index fcc69d2b4315bd9a6695260efc0da5bafe27a0c2..ba91a2cd541984096f79925097f2c38d9db17eee 100644
--- a/doc/src/fix_lb_viscous.txt
+++ b/doc/src/fix_lb_viscous.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -57,9 +57,9 @@ As described in the "fix viscous"_fix_viscous.html documentation:
"No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
-by this fix for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of this fix can
-be used with the {start/stop} keywords of the "run"_run.html command.
+by this fix for access by various "output commands"_Howto_output.html.
+No parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command.
The forces due to this fix are imposed during an energy minimization,
invoked by the "minimize"_minimize.html command. This fix should only
@@ -70,8 +70,8 @@ for details."
[Restrictions:]
This fix is part of the USER-LB package. It is only enabled if LAMMPS
-was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
Can only be used if a lattice-Boltzmann fluid has been created via the
"fix lb/fluid"_fix_lb_fluid.html command, and must come after this
diff --git a/doc/src/fix_lineforce.txt b/doc/src/fix_lineforce.txt
index 65672fc5a5bdce5ca34fbff81f1c5fb0b94d6c07..3114ed62501e3c3c3581ae06a154c45de0d92996 100644
--- a/doc/src/fix_lineforce.txt
+++ b/doc/src/fix_lineforce.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -35,9 +35,9 @@ it should continue to move along the line thereafter.
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
-by this fix for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of this fix can
-be used with the {start/stop} keywords of the "run"_run.html command.
+by this fix for access by various "output commands"_Howto_output.html.
+No parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command.
The forces due to this fix are imposed during an energy minimization,
invoked by the "minimize"_minimize.html command.
diff --git a/doc/src/fix_manifoldforce.txt b/doc/src/fix_manifoldforce.txt
index 5fc25167a7c7218097606cbbd77031a1cff0b709..a25b9f0b2e1c47d951d81906580dc6d011e32ea6 100644
--- a/doc/src/fix_manifoldforce.txt
+++ b/doc/src/fix_manifoldforce.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -24,10 +24,14 @@ fix constrain all manifoldforce sphere 5.0
[Description:]
-This fix subtracts each time step from the force the component along the normal of the specified "manifold"_manifolds.html.
-This can be used in combination with "minimize"_minimize.html to remove overlap between particles while
-keeping them (roughly) constrained to the given manifold, e.g. to set up a run with "fix nve/manifold/rattle"_fix_nve_manifold_rattle.html.
-I have found that only {hftn} and {quickmin} with a very small time step perform adequately though.
+This fix subtracts each time step from the force the component along
+the normal of the specified "manifold"_Howto_manifold.html. This can be
+used in combination with "minimize"_minimize.html to remove overlap
+between particles while keeping them (roughly) constrained to the
+given manifold, e.g. to set up a run with "fix
+nve/manifold/rattle"_fix_nve_manifold_rattle.html. I have found that
+only {hftn} and {quickmin} with a very small time step perform
+adequately though.
:line
@@ -36,26 +40,27 @@ I have found that only {hftn} and {quickmin} with a very small time step perform
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
-by this fix for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of this fix can
-be used with the {start/stop} keywords of the "run"_run.html command.
-This fix is invoked during "energy minimization"_minimize.html.
+by this fix for access by various "output commands"_Howto_output.html.
+No parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command. This fix is invoked during "energy
+minimization"_minimize.html.
:line
[Restrictions:]
-This fix is part of the USER-MANIFOLD package. It is only enabled if LAMMPS
-was built with that package. See the "Making LAMMPS"_Section_start.html#start_3
-section for more info.
+This fix is part of the USER-MANIFOLD package. It is only enabled if
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
-Only use this with {min_style hftn} or {min_style quickmin}. If not, the constraints
-will not be satisfied very well at all. A warning is generated if the {min_style} is
-incompatible but no error.
+Only use this with {min_style hftn} or {min_style quickmin}. If not,
+the constraints will not be satisfied very well at all. A warning is
+generated if the {min_style} is incompatible but no error.
:line
[Related commands:]
-"fix nve/manifold/rattle"_fix_nve_manifold_rattle.html, "fix nvt/manifold/rattle"_fix_nvt_manifold_rattle.html
+"fix nve/manifold/rattle"_fix_nve_manifold_rattle.html, "fix
+nvt/manifold/rattle"_fix_nvt_manifold_rattle.html
diff --git a/doc/src/fix_meso.txt b/doc/src/fix_meso.txt
index 85f5838dd261fbd232a8fa570aaa20fc1391ef8a..8c0ce5a9b7b729b42ce2f13a3c612c1ea46cd096 100644
--- a/doc/src/fix_meso.txt
+++ b/doc/src/fix_meso.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -34,16 +34,16 @@ LAMMPS.
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
-by this fix for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of this fix can
-be used with the {start/stop} keywords of the "run"_run.html command.
-This fix is not invoked during "energy minimization"_minimize.html.
+by this fix for access by various "output commands"_Howto_output.html.
+No parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command. This fix is not invoked during "energy
+minimization"_minimize.html.
[Restrictions:]
This fix is part of the USER-SPH package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/fix_meso_stationary.txt b/doc/src/fix_meso_stationary.txt
index 5b83573bc8bcc58d2ad6aedc1d8b18c7d46f9368..1a546efec06e64e6f125b53e006f78db7e2f5d69 100644
--- a/doc/src/fix_meso_stationary.txt
+++ b/doc/src/fix_meso_stationary.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -35,16 +35,16 @@ LAMMPS.
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
-by this fix for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of this fix can
-be used with the {start/stop} keywords of the "run"_run.html command.
-This fix is not invoked during "energy minimization"_minimize.html.
+by this fix for access by various "output commands"_Howto_output.html.
+No parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command. This fix is not invoked during "energy
+minimization"_minimize.html.
[Restrictions:]
This fix is part of the USER-SPH package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/fix_modify.txt b/doc/src/fix_modify.txt
index 308bba1ac31fdf9a7cbd45ec1da50122cd46bcb9..ddb5f9a4cd4346e6f0d3195a101445c15eaedfde 100644
--- a/doc/src/fix_modify.txt
+++ b/doc/src/fix_modify.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/fix_momentum.txt b/doc/src/fix_momentum.txt
index bcf4465fb8f5c9bc30626cc3275f422fd2158e9e..aeedad07197163423a2a3db32025095294fbf676 100644
--- a/doc/src/fix_momentum.txt
+++ b/doc/src/fix_momentum.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -61,33 +61,32 @@ initial velocities with zero aggregate linear and/or angular momentum.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
[Restart, fix_modify, output, run start/stop, minimize info:]
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
-by this fix for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of this fix can
-be used with the {start/stop} keywords of the "run"_run.html command.
-This fix is not invoked during "energy minimization"_minimize.html.
+by this fix for access by various "output commands"_Howto_output.html.
+No parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command. This fix is not invoked during "energy
+minimization"_minimize.html.
[Restrictions:] none
diff --git a/doc/src/fix_move.txt b/doc/src/fix_move.txt
index 7cb40ad1320e365153d3d3165df06a8a1f064750..08f38d0ed65f2dec91bfec38fd572b8e82e75770 100644
--- a/doc/src/fix_move.txt
+++ b/doc/src/fix_move.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -203,10 +203,9 @@ None of the "fix_modify"_fix_modify.html options are relevant to this
fix.
This fix produces a per-atom array which can be accessed by various
-"output commands"_Section_howto.html#howto_15. The number of columns
-for each atom is 3, and the columns store the original unwrapped x,y,z
-coords of each atom. The per-atom values can be accessed on any
-timestep.
+"output commands"_Howto_output.html. The number of columns for each
+atom is 3, and the columns store the original unwrapped x,y,z coords
+of each atom. The per-atom values can be accessed on any timestep.
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command. This fix is not invoked during "energy
diff --git a/doc/src/fix_mscg.txt b/doc/src/fix_mscg.txt
index 7d16967955d1d9988636092d721fe40902386054..1ad780412756a117c28e8ac193295206e153c811 100644
--- a/doc/src/fix_mscg.txt
+++ b/doc/src/fix_mscg.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -103,8 +103,8 @@ dihedrals a bead can have in the coarse-grained model.
[Restrictions:]
This fix is part of the MSCG package. It is only enabled if LAMMPS was
-built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+built with that package. See the "Build package"_Build_package.html
+doc page for more info.
The MS-CG library uses C++11, which may not be supported by older
compilers. The MS-CG library also has some additional numeric library
diff --git a/doc/src/fix_msst.txt b/doc/src/fix_msst.txt
index 310692669abb39aaebb7e3596ee7f0b9e8cdf865..e31f61e5f7c815c8a0253b3db69b6f8c8fcb6a35 100644
--- a/doc/src/fix_msst.txt
+++ b/doc/src/fix_msst.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -156,14 +156,14 @@ thermo_style custom step temp ke pe lz pzz etotal v_dhug v_dray v_lgr_vel v_
These fixes compute a global scalar and a global vector of 4
quantities, which can be accessed by various "output
-commands"_Section_howto.html#howto_15. The scalar values calculated
-by this fix are "extensive"; the vector values are "intensive".
+commands"_Howto_output.html. The scalar values calculated by this fix
+are "extensive"; the vector values are "intensive".
[Restrictions:]
This fix style is part of the SHOCK package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
All cell dimensions must be periodic. This fix can not be used with a
triclinic cell. The MSST fix has been tested only for the group-ID
diff --git a/doc/src/fix_mvv_dpd.txt b/doc/src/fix_mvv_dpd.txt
index fb3c6fe8885ce8a23b58897cd05a94269a20e5d7..507f271469df32842ba0dbd29630c513d79c8c3c 100644
--- a/doc/src/fix_mvv_dpd.txt
+++ b/doc/src/fix_mvv_dpd.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -69,16 +69,16 @@ addition to position and velocity, and must be used with the
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
-by this fix for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of this fix can
-be used with the {start/stop} keywords of the "run"_run.html command.
-This fix is not invoked during "energy minimization"_minimize.html.
+by this fix for access by various "output commands"_Howto_output.html.
+No parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command. This fix is not invoked during "energy
+minimization"_minimize.html.
[Restrictions:]
This fix is part of the USER-MESO package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/fix_neb.txt b/doc/src/fix_neb.txt
index 5d18c39d994de3d58b752f7d595dfa4eb55e0019..d331d9ad75fbf7c2a203bfe68bb1035abcfd410a 100644
--- a/doc/src/fix_neb.txt
+++ b/doc/src/fix_neb.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -43,9 +43,9 @@ Add nudging forces to atoms in the group for a multi-replica
simulation run via the "neb"_neb.html command to perform a nudged
elastic band (NEB) calculation for finding the transition state.
Hi-level explanations of NEB are given with the "neb"_neb.html command
-and in "Section_howto 5"_Section_howto.html#howto_5 of the manual.
-The fix neb command must be used with the "neb" command and defines
-how inter-replica nudging forces are computed. A NEB calculation is
+and on the "Howto replica"_Howto_replica.html doc page. The fix neb
+command must be used with the "neb" command and defines how
+inter-replica nudging forces are computed. A NEB calculation is
divided in two stages. In the first stage n replicas are relaxed
toward a MEP until convergence. In the second stage, the climbing
image scheme (see "(Henkelman2)"_#Henkelman2) is enabled, so that the
@@ -192,9 +192,9 @@ target energy.
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
-by this fix for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of this fix can
-be used with the {start/stop} keywords of the "run"_run.html command.
+by this fix for access by various "output commands"_Howto_output.html.
+No parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command.
The forces due to this fix are imposed during an energy minimization,
as invoked by the "minimize"_minimize.html command via the
@@ -203,8 +203,8 @@ as invoked by the "minimize"_minimize.html command via the
[Restrictions:]
This command can only be used if LAMMPS was built with the REPLICA
-package. See the "Making LAMMPS"_Section_start.html#start_3 section
-for more info on packages.
+package. See the "Build package"_Build_package.html doc
+page for more info.
[Related commands:]
diff --git a/doc/src/fix_nh.txt b/doc/src/fix_nh.txt
index 41d0e6438fc9e05d08aa43d1548a98c0856ffd90..644ced4bdc6c0aaba54d27dc59004aebb0f16022 100644
--- a/doc/src/fix_nh.txt
+++ b/doc/src/fix_nh.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -386,9 +386,10 @@ have their temperature controlled by another fix - e.g. by "fix
langevin"_fix_nh.html or "fix temp/rescale"_fix_temp_rescale.html
commands.
-See "this howto section"_Section_howto.html#howto_16 of the manual for
-a discussion of different ways to compute temperature and perform
-thermostatting and barostatting.
+See the "Howto thermostat"_Howto_thermostat.html and "Howto
+barostat"_Howto_barostat.html doc pages for a discussion of different
+ways to compute temperature and perform thermostatting and
+barostatting.
:line
@@ -484,23 +485,22 @@ the various ways to do this.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -538,9 +538,9 @@ and barostatting to the system's potential energy as part of
"thermodynamic output"_thermo_style.html.
These fixes compute a global scalar and a global vector of quantities,
-which can be accessed by various "output
-commands"_Section_howto.html#howto_15. The scalar value calculated by
-these fixes is "extensive"; the vector values are "intensive".
+which can be accessed by various "output commands"_Howto_output.html.
+The scalar value calculated by these fixes is "extensive"; the vector
+values are "intensive".
The scalar is the cumulative energy change due to the fix.
diff --git a/doc/src/fix_nh_eff.txt b/doc/src/fix_nh_eff.txt
index 1731f1f3317a6f982a564c256e593439a8f73423..d7c045770860e1792dacb682170f6e64034282e6 100644
--- a/doc/src/fix_nh_eff.txt
+++ b/doc/src/fix_nh_eff.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -101,8 +101,8 @@ for details.
[Restrictions:]
This fix is part of the USER-EFF package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
Other restriction discussed on the doc page for the "fix nvt, npt, and
nph"_fix_nh.html commands also apply.
diff --git a/doc/src/fix_nh_uef.txt b/doc/src/fix_nh_uef.txt
index bde1818371f2c4bcab0bafe11e19c4b04df107b8..ae403cafd1d8ff7c5ee8f6e7fcc0589dd9437cb6 100644
--- a/doc/src/fix_nh_uef.txt
+++ b/doc/src/fix_nh_uef.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -182,8 +182,8 @@ The fix is not invoked during "energy minimization"_minimize.html.
[Restrictions:]
This fix is part of the USER-UEF package. It is only enabled if LAMMPS
-was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
Due to requirements of the boundary conditions, when the {strain}
keyword is set to zero (or unset), the initial simulation box must be
diff --git a/doc/src/fix_nph_asphere.txt b/doc/src/fix_nph_asphere.txt
index 8c35b6a1a7a4b8bbd2fc98573764f99f0995249c..5cabf930e73b00b9eb2e46701c026b1f37397985 100644
--- a/doc/src/fix_nph_asphere.txt
+++ b/doc/src/fix_nph_asphere.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -81,23 +81,22 @@ It also means that changing attributes of {thermo_temp} or
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
[Restart, fix_modify, output, run start/stop, minimize info:]
@@ -133,8 +132,8 @@ This fix is not invoked during "energy minimization"_minimize.html.
[Restrictions:]
This fix is part of the ASPHERE package. It is only enabled if LAMMPS
-was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This fix requires that atoms store torque and angular momentum and a
quaternion as defined by the "atom_style ellipsoid"_atom_style.html
diff --git a/doc/src/fix_nph_body.txt b/doc/src/fix_nph_body.txt
index 1e590f1cb3f3d5a46724d86e657d805a6a1906e3..e04c240de951965f94124617a1e88e658f5b8402 100644
--- a/doc/src/fix_nph_body.txt
+++ b/doc/src/fix_nph_body.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -80,23 +80,22 @@ It also means that changing attributes of {thermo_temp} or
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
[Restart, fix_modify, output, run start/stop, minimize info:]
@@ -132,8 +131,8 @@ This fix is not invoked during "energy minimization"_minimize.html.
[Restrictions:]
This fix is part of the BODY package. It is only enabled if LAMMPS
-was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This fix requires that atoms store torque and angular momentum and a
quaternion as defined by the "atom_style body"_atom_style.html
diff --git a/doc/src/fix_nph_sphere.txt b/doc/src/fix_nph_sphere.txt
index 62b45edfd7cd5ffbd8fe8ab48d5aefc29d3417ee..f94c057c93f300a911b5f524087187038f58fc48 100644
--- a/doc/src/fix_nph_sphere.txt
+++ b/doc/src/fix_nph_sphere.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -90,23 +90,22 @@ It also means that changing attributes of {thermo_temp} or
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
[Restart, fix_modify, output, run start/stop, minimize info:]
diff --git a/doc/src/fix_nphug.txt b/doc/src/fix_nphug.txt
index 292e46f94af6fcfe8e8c8b5b1e04908c2c55c9bc..855a4c9ae49fb49cf7929b59f796a8dc6dc89a30 100644
--- a/doc/src/fix_nphug.txt
+++ b/doc/src/fix_nphug.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -140,23 +140,22 @@ It also means that changing attributes of {thermo_temp} or
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -193,9 +192,9 @@ included in the definition of internal energy E when calculating the value
of Delta in the above equation.
These fixes compute a global scalar and a global vector of quantities,
-which can be accessed by various "output
-commands"_Section_howto.html#howto_15. The scalar value calculated by
-these fixes is "extensive"; the vector values are "intensive".
+which can be accessed by various "output commands"_Howto_output.html.
+The scalar value calculated by these fixes is "extensive"; the vector
+values are "intensive".
The scalar is the cumulative energy change due to the fix.
@@ -209,8 +208,8 @@ shock calculated from the RH conditions. They have units of distance/time.
[Restrictions:]
This fix style is part of the SHOCK package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
All the usual restrictions for "fix npt"_fix_nh.html apply,
plus the additional ones mentioned above.
diff --git a/doc/src/fix_npt_asphere.txt b/doc/src/fix_npt_asphere.txt
index 5f3979e36ed9e586f2eee15750364641348c040c..194f4ff499ea8763112456accddb26f308fb738e 100644
--- a/doc/src/fix_npt_asphere.txt
+++ b/doc/src/fix_npt_asphere.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -105,23 +105,22 @@ thermal degrees of freedom, and the bias is added back in.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
[Restart, fix_modify, output, run start/stop, minimize info:]
@@ -158,8 +157,8 @@ This fix is not invoked during "energy minimization"_minimize.html.
[Restrictions:]
This fix is part of the ASPHERE package. It is only enabled if LAMMPS
-was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This fix requires that atoms store torque and angular momentum and a
quaternion as defined by the "atom_style ellipsoid"_atom_style.html
diff --git a/doc/src/fix_npt_body.txt b/doc/src/fix_npt_body.txt
index d89bf19db24fa7a988923a8cb5822cccc9641ed9..1d608137b619e5b989c212a8aad83d92753c0570 100644
--- a/doc/src/fix_npt_body.txt
+++ b/doc/src/fix_npt_body.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -104,23 +104,22 @@ thermal degrees of freedom, and the bias is added back in.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
[Restart, fix_modify, output, run start/stop, minimize info:]
@@ -157,8 +156,8 @@ This fix is not invoked during "energy minimization"_minimize.html.
[Restrictions:]
This fix is part of the BODY package. It is only enabled if LAMMPS
-was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This fix requires that atoms store torque and angular momentum and a
quaternion as defined by the "atom_style body"_atom_style.html
diff --git a/doc/src/fix_npt_sphere.txt b/doc/src/fix_npt_sphere.txt
index c4cf2cb08de85d8fe892f240473a0a90daa56de0..6ebb68e176311fe1eda0c1d71a2c84a6861a8366 100644
--- a/doc/src/fix_npt_sphere.txt
+++ b/doc/src/fix_npt_sphere.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -115,23 +115,22 @@ thermal degrees of freedom, and the bias is added back in.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
[Restart, fix_modify, output, run start/stop, minimize info:]
diff --git a/doc/src/fix_nve.txt b/doc/src/fix_nve.txt
index c04c17858ebdf9b4166827a9cf5f52ed0f43e597..2347f957aef8636dc1e8ab2261cee737c93de8e5 100644
--- a/doc/src/fix_nve.txt
+++ b/doc/src/fix_nve.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -34,23 +34,22 @@ ensemble.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -59,10 +58,10 @@ more instructions on how to use the accelerated styles effectively.
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
-by this fix for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of this fix can
-be used with the {start/stop} keywords of the "run"_run.html command.
-This fix is not invoked during "energy minimization"_minimize.html.
+by this fix for access by various "output commands"_Howto_output.html.
+No parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command. This fix is not invoked during "energy
+minimization"_minimize.html.
[Restrictions:] none
diff --git a/doc/src/fix_nve_asphere.txt b/doc/src/fix_nve_asphere.txt
index 1f31fb96792239de806f99e78744106b0b08c1f7..bd9e4ae8731b35fdc140063e6f76c80dea58ef61 100644
--- a/doc/src/fix_nve_asphere.txt
+++ b/doc/src/fix_nve_asphere.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -35,41 +35,40 @@ assumes point particles and only updates their position and velocity.
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
-by this fix for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of this fix can
-be used with the {start/stop} keywords of the "run"_run.html command.
-This fix is not invoked during "energy minimization"_minimize.html.
+by this fix for access by various "output commands"_Howto_output.html.
+No parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command. This fix is not invoked during "energy
+minimization"_minimize.html.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This fix is part of the ASPHERE package. It is only enabled if LAMMPS
-was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This fix requires that atoms store torque and angular momentum and a
quaternion as defined by the "atom_style ellipsoid"_atom_style.html
diff --git a/doc/src/fix_nve_asphere_noforce.txt b/doc/src/fix_nve_asphere_noforce.txt
index 5f1b2715464c01468494f8fb0da33bd46c1c5ec4..c0598e8839090202cfb662cb75959a06debcc4e7 100644
--- a/doc/src/fix_nve_asphere_noforce.txt
+++ b/doc/src/fix_nve_asphere_noforce.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -29,7 +29,7 @@ angular momenta are used to update their positions and orientation.
This is useful as an implicit time integrator for Fast Lubrication
Dynamics, since the velocity and angular momentum are updated by the
-"pair_style lubricuteU"_pair_lubricateU.txt command.
+"pair_style lubricuteU"_pair_lubricateU.html command.
:line
@@ -38,16 +38,16 @@ Dynamics, since the velocity and angular momentum are updated by the
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
-by this fix for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of this fix can
-be used with the {start/stop} keywords of the "run"_run.html command.
-This fix is not invoked during "energy minimization"_minimize.html.
+by this fix for access by various "output commands"_Howto_output.html.
+No parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command. This fix is not invoked during "energy
+minimization"_minimize.html.
[Restrictions:]
This fix is part of the ASPHERE package. It is only enabled if LAMMPS
-was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This fix requires that atoms store torque and angular momentum and a
quaternion as defined by the "atom_style ellipsoid"_atom_style.html
diff --git a/doc/src/fix_nve_body.txt b/doc/src/fix_nve_body.txt
index 604b5391cd180e064207ca3cd5a02d2335470ac7..1a9efb5e139f99efd1ed8008b6e4fdcb10c6b84e 100644
--- a/doc/src/fix_nve_body.txt
+++ b/doc/src/fix_nve_body.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -24,9 +24,9 @@ fix 1 all nve/body :pre
Perform constant NVE integration to update position, velocity,
orientation, and angular velocity for body particles in the group each
timestep. V is volume; E is energy. This creates a system trajectory
-consistent with the microcanonical ensemble. See "Section
-6.14"_Section_howto.html#howto_14 of the manual and the "body"_body.html
-doc page for more details on using body particles.
+consistent with the microcanonical ensemble. See the "Howto
+body"_Howto_body.html doc page for more details on using body
+particles.
This fix differs from the "fix nve"_fix_nve.html command, which
assumes point particles and only updates their position and velocity.
@@ -36,16 +36,16 @@ assumes point particles and only updates their position and velocity.
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
-by this fix for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of this fix can
-be used with the {start/stop} keywords of the "run"_run.html command.
-This fix is not invoked during "energy minimization"_minimize.html.
+by this fix for access by various "output commands"_Howto_output.html.
+No parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command. This fix is not invoked during "energy
+minimization"_minimize.html.
[Restrictions:]
This fix is part of the BODY package. It is only enabled if LAMMPS
-was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This fix requires that atoms store torque and angular momentum and a
quaternion as defined by the "atom_style body"_atom_style.html
diff --git a/doc/src/fix_nve_dot.txt b/doc/src/fix_nve_dot.txt
index 0e0c8f8ecf5d9d02f3a6982ee1ae3e5cd8aa3746..06140c2d37361b3017ac685df08536ea34d1ca6a 100644
--- a/doc/src/fix_nve_dot.txt
+++ b/doc/src/fix_nve_dot.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -44,8 +44,8 @@ A technical report with more information on this integrator can be found
[Restrictions:]
These pair styles can only be used if LAMMPS was built with the
-"USER-CGDNA"_#USER-CGDNA package and the MOLECULE and ASPHERE package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+"USER-CGDNA"_Package_details.html#PKG-USER-CGDNA package and the MOLECULE and ASPHERE package.
+See the "Build package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/fix_nve_dotc_langevin.txt b/doc/src/fix_nve_dotc_langevin.txt
index 93d875bca5436127526cdb5f1dad6b170d6c46b3..7339f251ad1c3ebbd56d8e754e4ea336f2fd76f6 100644
--- a/doc/src/fix_nve_dotc_langevin.txt
+++ b/doc/src/fix_nve_dotc_langevin.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -122,8 +122,8 @@ A technical report with more information on this integrator can be found
[Restrictions:]
These pair styles can only be used if LAMMPS was built with the
-"USER-CGDNA"_#USER-CGDNA package and the MOLECULE and ASPHERE package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+"USER-CGDNA"_Package_details.html#PKG-USER-CGDNA package and the MOLECULE and ASPHERE package.
+See the "Build package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/fix_nve_eff.txt b/doc/src/fix_nve_eff.txt
index 156f184daceb6ee31c14168e65deecc43d7a9bc1..556b95deba6d5400466d088c8b34c9bdf1d24e56 100644
--- a/doc/src/fix_nve_eff.txt
+++ b/doc/src/fix_nve_eff.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -35,16 +35,16 @@ of electrons are also updated.
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
-by this fix for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of this fix can
-be used with the {start/stop} keywords of the "run"_run.html command.
-This fix is not invoked during "energy minimization"_minimize.html.
+by this fix for access by various "output commands"_Howto_output.html.
+No parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command. This fix is not invoked during "energy
+minimization"_minimize.html.
[Restrictions:]
This fix is part of the USER-EFF package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/fix_nve_limit.txt b/doc/src/fix_nve_limit.txt
index 2ecec83e9ce8bf5886a1d66dc4c50046a7f74882..8c8c66a0dac92424d08b577ee3957277e81e6ce2 100644
--- a/doc/src/fix_nve_limit.txt
+++ b/doc/src/fix_nve_limit.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -63,14 +63,14 @@ files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix.
This fix computes a global scalar which can be accessed by various
-"output commands"_Section_howto.html#howto_15. The scalar is the
-count of how many updates of atom's velocity/position were limited by
-the maximum distance criterion. This should be roughly the number of
-atoms so affected, except that updates occur at both the beginning and
-end of a timestep in a velocity Verlet timestepping algorithm. This
-is a cumulative quantity for the current run, but is re-initialized to
-zero each time a run is performed. The scalar value calculated by
-this fix is "extensive".
+"output commands"_Howto_output.html. The scalar is the count of how
+many updates of atom's velocity/position were limited by the maximum
+distance criterion. This should be roughly the number of atoms so
+affected, except that updates occur at both the beginning and end of a
+timestep in a velocity Verlet timestepping algorithm. This is a
+cumulative quantity for the current run, but is re-initialized to zero
+each time a run is performed. The scalar value calculated by this fix
+is "extensive".
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command. This fix is not invoked during "energy
diff --git a/doc/src/fix_nve_line.txt b/doc/src/fix_nve_line.txt
index ac5206aa5ce4ad1f9047bed437d96318498362d0..896e3b810d83049198c1e0f7f630d545836698c7 100644
--- a/doc/src/fix_nve_line.txt
+++ b/doc/src/fix_nve_line.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -24,9 +24,9 @@ fix 1 all nve/line :pre
Perform constant NVE integration to update position, velocity,
orientation, and angular velocity for line segment particles in the
group each timestep. V is volume; E is energy. This creates a system
-trajectory consistent with the microcanonical ensemble. See
-"Section 6.14"_Section_howto.html#howto_14 of the manual for an
-overview of using line segment particles.
+trajectory consistent with the microcanonical ensemble. See "Howto
+spherical"_Howto_spherical.html doc page for an overview of using line
+segment particles.
This fix differs from the "fix nve"_fix_nve.html command, which
assumes point particles and only updates their position and velocity.
@@ -36,16 +36,16 @@ assumes point particles and only updates their position and velocity.
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
-by this fix for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of this fix can
-be used with the {start/stop} keywords of the "run"_run.html command.
-This fix is not invoked during "energy minimization"_minimize.html.
+by this fix for access by various "output commands"_Howto_output.html.
+No parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command. This fix is not invoked during "energy
+minimization"_minimize.html.
[Restrictions:]
This fix is part of the ASPHERE package. It is only enabled if LAMMPS
-was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This fix requires that particles be line segments as defined by the
"atom_style line"_atom_style.html command.
diff --git a/doc/src/fix_nve_manifold_rattle.txt b/doc/src/fix_nve_manifold_rattle.txt
index e032a7e1cc76408f8db42a9108662997a47e440d..5301ea603ce65747344f68fe42bf93233ecccac7 100644
--- a/doc/src/fix_nve_manifold_rattle.txt
+++ b/doc/src/fix_nve_manifold_rattle.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -40,7 +40,7 @@ the dynamics of particles constrained to curved surfaces can be
studied. If combined with "fix langevin"_fix_langevin.html, this
generates Brownian motion of particles constrained to a curved
surface. For a list of currently supported manifolds and their
-parameters, see "manifolds"_manifolds.html.
+parameters, see the "Howto manifold"_Howto_manifold.html doc page.
Note that the particles must initially be close to the manifold in
question. If not, RATTLE will not be able to iterate until the
@@ -68,18 +68,18 @@ conserved.
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
-by this fix for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of this fix can
-be used with the {start/stop} keywords of the "run"_run.html command.
-This fix is not invoked during "energy minimization"_minimize.html.
+by this fix for access by various "output commands"_Howto_output.html.
+No parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command. This fix is not invoked during "energy
+minimization"_minimize.html.
:line
[Restrictions:]
This fix is part of the USER-MANIFOLD package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
:line
diff --git a/doc/src/fix_nve_noforce.txt b/doc/src/fix_nve_noforce.txt
index a0dbcc80f18f0fc7d15f7b4503031fa80aaaa50c..da8d16bbb7c1c49bdee6af72dc4c1bcc2f355a1e 100644
--- a/doc/src/fix_nve_noforce.txt
+++ b/doc/src/fix_nve_noforce.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -40,10 +40,10 @@ fcm() group function to compute the total force on the group of atoms.
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
-by this fix for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of this fix can
-be used with the {start/stop} keywords of the "run"_run.html command.
-This fix is not invoked during "energy minimization"_minimize.html.
+by this fix for access by various "output commands"_Howto_output.html.
+No parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command. This fix is not invoked during "energy
+minimization"_minimize.html.
[Restrictions:] none
diff --git a/doc/src/fix_nve_sphere.txt b/doc/src/fix_nve_sphere.txt
index 21dc6cba8a4aa7e067bcb9b0c066879e60b23479..225359dfa7f03b56e6e0636eca55f70384853e19 100644
--- a/doc/src/fix_nve_sphere.txt
+++ b/doc/src/fix_nve_sphere.txt
@@ -2,12 +2,13 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
fix nve/sphere command :h3
fix nve/sphere/omp command :h3
+fix nve/sphere/kk command :h3
[Syntax:]
@@ -65,23 +66,22 @@ moment of inertia, as used in the time integration.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -90,10 +90,10 @@ more instructions on how to use the accelerated styles effectively.
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
-by this fix for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of this fix can
-be used with the {start/stop} keywords of the "run"_run.html command.
-This fix is not invoked during "energy minimization"_minimize.html.
+by this fix for access by various "output commands"_Howto_output.html.
+No parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command. This fix is not invoked during "energy
+minimization"_minimize.html.
[Restrictions:]
diff --git a/doc/src/fix_nve_spin.txt b/doc/src/fix_nve_spin.txt
index 6ccebcebf66292459283bf6b4270868e99c9d16d..08f0eab61dcfd4f505d1c840f0a0fb434c336c18 100644
--- a/doc/src/fix_nve_spin.txt
+++ b/doc/src/fix_nve_spin.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -47,9 +47,9 @@ in "(Tranchida)"_#Tranchida1.
[Restrictions:]
-This fix style can only be used if LAMMPS was built with the
-SPIN package. See the "Making LAMMPS"_Section_start.html#start_3
-section for more info on packages.
+This fix style can only be used if LAMMPS was built with the SPIN
+package. See the "Build package"_Build_package.html doc page for more
+info.
To use the spin algorithm, it is necessary to define a map with
the atom_modify command. Typically, by adding the command:
@@ -73,4 +73,4 @@ instead of "array" is also valid.
:link(Tranchida1)
[(Tranchida)] Tranchida, Plimpton, Thibaudeau and Thompson,
-arXiv preprint arXiv:1801.10233, (2018).
+Journal of Computational Physics, (2018).
diff --git a/doc/src/fix_nve_tri.txt b/doc/src/fix_nve_tri.txt
index cee27e2fa43087a2b6847a6f119fcb3792252259..c14907ca02596e448a3ee9004574f93bd3fd2e35 100644
--- a/doc/src/fix_nve_tri.txt
+++ b/doc/src/fix_nve_tri.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -23,10 +23,10 @@ fix 1 all nve/tri :pre
Perform constant NVE integration to update position, velocity,
orientation, and angular momentum for triangular particles in the
-group each timestep. V is volume; E is energy. This creates a
-system trajectory consistent with the microcanonical ensemble. See
-"Section 6.14"_Section_howto.html#howto_14 of the manual for an
-overview of using triangular particles.
+group each timestep. V is volume; E is energy. This creates a system
+trajectory consistent with the microcanonical ensemble. See the
+"Howto spherical"_Howto_spherical.html doc page for an overview of
+using triangular particles.
This fix differs from the "fix nve"_fix_nve.html command, which
assumes point particles and only updates their position and velocity.
@@ -36,16 +36,16 @@ assumes point particles and only updates their position and velocity.
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
-by this fix for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of this fix can
-be used with the {start/stop} keywords of the "run"_run.html command.
-This fix is not invoked during "energy minimization"_minimize.html.
+by this fix for access by various "output commands"_Howto_output.html.
+No parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command. This fix is not invoked during "energy
+minimization"_minimize.html.
[Restrictions:]
This fix is part of the ASPHERE package. It is only enabled if LAMMPS
-was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This fix requires that particles be triangles as defined by the
"atom_style tri"_atom_style.html command.
diff --git a/doc/src/fix_nvk.txt b/doc/src/fix_nvk.txt
index 49fd8217ab7a88b90c23afc7ca56295e906ec245..98f63487b73144d9cc155ffd937147d0358d618b 100644
--- a/doc/src/fix_nvk.txt
+++ b/doc/src/fix_nvk.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -42,10 +42,10 @@ energy prior to this fix.
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
-by this fix for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of this fix can
-be used with the {start/stop} keywords of the "run"_run.html command.
-This fix is not invoked during "energy minimization"_minimize.html.
+by this fix for access by various "output commands"_Howto_output.html.
+No parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command. This fix is not invoked during "energy
+minimization"_minimize.html.
[Restrictions:]
@@ -54,9 +54,9 @@ the simulation box. Therefore, the group must be set to all.
This fix has not yet been implemented to work with the RESPA integrator.
-This fix is part of the USER-MISC package. It is only enabled if LAMMPS
-was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+This fix is part of the USER-MISC package. It is only enabled if
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:] none
diff --git a/doc/src/fix_nvt_asphere.txt b/doc/src/fix_nvt_asphere.txt
index 21b900f16ac69d3ef28b7b39fa90f232f43eb290..a2187f8495f63ddec697337b417a16f53348da5f 100644
--- a/doc/src/fix_nvt_asphere.txt
+++ b/doc/src/fix_nvt_asphere.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -86,23 +86,22 @@ thermal degrees of freedom, and the bias is added back in.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
[Restart, fix_modify, output, run start/stop, minimize info:]
@@ -134,8 +133,8 @@ This fix is not invoked during "energy minimization"_minimize.html.
[Restrictions:]
This fix is part of the ASPHERE package. It is only enabled if LAMMPS
-was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This fix requires that atoms store torque and angular momentum and a
quaternion as defined by the "atom_style ellipsoid"_atom_style.html
diff --git a/doc/src/fix_nvt_body.txt b/doc/src/fix_nvt_body.txt
index 6a5e09ba7fb57ef45a91b9bf764e1f2e821fc34f..62c7cfecf822973c40c343c17eb2c3e54e3a6d74 100644
--- a/doc/src/fix_nvt_body.txt
+++ b/doc/src/fix_nvt_body.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -85,23 +85,22 @@ thermal degrees of freedom, and the bias is added back in.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
[Restart, fix_modify, output, run start/stop, minimize info:]
@@ -133,8 +132,8 @@ This fix is not invoked during "energy minimization"_minimize.html.
[Restrictions:]
This fix is part of the BODY package. It is only enabled if LAMMPS
-was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This fix requires that atoms store torque and angular momentum and a
quaternion as defined by the "atom_style body"_atom_style.html
diff --git a/doc/src/fix_nvt_manifold_rattle.txt b/doc/src/fix_nvt_manifold_rattle.txt
index a620648a460682c26780b67f9a4eddb3f21738ce..0c4b81aa32d83fa348ec660116a0ce8b53b56a34 100644
--- a/doc/src/fix_nvt_manifold_rattle.txt
+++ b/doc/src/fix_nvt_manifold_rattle.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -27,8 +27,6 @@ keyword = {temp} or {tchain} or {every}
N = length of thermostat chain (1 = single thermostat)
{every} value = N
N = print info about iteration every N steps. N = 0 means no output :pre
-
-
:ule
[Examples:]
@@ -37,9 +35,13 @@ fix 1 all nvt/manifold/rattle 1e-4 10 cylinder 3.0 temp 1.0 1.0 10.0
[Description:]
-This fix combines the RATTLE-based "(Andersen)"_#Andersen2 time integrator of "fix nve/manifold/rattle"_fix_nve_manifold_rattle.html "(Paquay)"_#Paquay3 with a Nose-Hoover-chain thermostat to sample the
-canonical ensemble of particles constrained to a curved surface (manifold). This sampling does suffer from discretization bias of O(dt).
-For a list of currently supported manifolds and their parameters, see "manifolds"_manifolds.html
+This fix combines the RATTLE-based "(Andersen)"_#Andersen2 time
+integrator of "fix nve/manifold/rattle"_fix_nve_manifold_rattle.html
+"(Paquay)"_#Paquay3 with a Nose-Hoover-chain thermostat to sample the
+canonical ensemble of particles constrained to a curved surface
+(manifold). This sampling does suffer from discretization bias of
+O(dt). For a list of currently supported manifolds and their
+parameters, see the "Howto manifold"_Howto_manifold.html doc page.
:line
@@ -48,27 +50,25 @@ For a list of currently supported manifolds and their parameters, see "manifolds
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
-by this fix for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of this fix can
-be used with the {start/stop} keywords of the "run"_run.html command.
-This fix is not invoked during "energy minimization"_minimize.html.
+by this fix for access by various "output commands"_Howto_output.html.
+No parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command. This fix is not invoked during "energy
+minimization"_minimize.html.
:line
-
[Restrictions:]
-This fix is part of the USER-MANIFOLD package. It is only enabled if LAMMPS
-was built with that package. See the "Making LAMMPS"_Section_start.html#start_3
-section for more info.
+This fix is part of the USER-MANIFOLD package. It is only enabled if
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
:line
-
[Related commands:]
-"fix nve/manifold/rattle"_fix_nvt_manifold_rattle.html, "fix manifoldforce"_fix_manifoldforce.html
-[Default:] every = 0
+"fix nve/manifold/rattle"_fix_nvt_manifold_rattle.html, "fix
+manifoldforce"_fix_manifoldforce.html [Default:] every = 0
:line
diff --git a/doc/src/fix_nvt_sllod.txt b/doc/src/fix_nvt_sllod.txt
index 392dbc281c6f5eee0fc164f4ed8eb6670bfbcbef..97a864a231d32cbc503031840d17384fcfa8e44f 100644
--- a/doc/src/fix_nvt_sllod.txt
+++ b/doc/src/fix_nvt_sllod.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -109,23 +109,22 @@ thermal degrees of freedom, and the bias is added back in.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
[Restart, fix_modify, output, run start/stop, minimize info:]
diff --git a/doc/src/fix_nvt_sllod_eff.txt b/doc/src/fix_nvt_sllod_eff.txt
index 408eb1da01f99bc026a4581bedbb4ecff2a91b6a..5cba15c8cf3f3af230263ba9215efca001144726 100644
--- a/doc/src/fix_nvt_sllod_eff.txt
+++ b/doc/src/fix_nvt_sllod_eff.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -69,8 +69,8 @@ This fix is not invoked during "energy minimization"_minimize.html.
[Restrictions:]
This fix is part of the USER-EFF package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This fix works best without Nose-Hoover chain thermostats, i.e. using
tchain = 1. Setting tchain to larger values can result in poor
diff --git a/doc/src/fix_nvt_sphere.txt b/doc/src/fix_nvt_sphere.txt
index ecf0922b7901a154f0728579b41d6e9502b2f3d0..75222e0de81d09462d5b1465c3f232f2a4903c44 100644
--- a/doc/src/fix_nvt_sphere.txt
+++ b/doc/src/fix_nvt_sphere.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -96,23 +96,22 @@ thermal degrees of freedom, and the bias is added back in.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
[Restart, fix_modify, output, run start/stop, minimize info:]
diff --git a/doc/src/fix_oneway.txt b/doc/src/fix_oneway.txt
index 2d85c581ebd95ec5cfdf27129ee39ae1c73532d5..433ceb50f244e7570b83979dffed7c5b34d7a8ca 100644
--- a/doc/src/fix_oneway.txt
+++ b/doc/src/fix_oneway.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -43,10 +43,10 @@ membrane, or as an implementation of Maxwell's demon.
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
-by this fix for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of this fix can
-be used with the {start/stop} keywords of the "run"_run.html command.
-This fix is not invoked during "energy minimization"_minimize.html.
+by this fix for access by various "output commands"_Howto_output.html.
+No parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command. This fix is not invoked during "energy
+minimization"_minimize.html.
[Restrictions:] none
diff --git a/doc/src/fix_orient.txt b/doc/src/fix_orient.txt
index 20ff94866ea3ad0c92fde75042cad455494bcc92..9d8e4e86282727eaa85292803f1095e2224596f8 100644
--- a/doc/src/fix_orient.txt
+++ b/doc/src/fix_orient.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -135,14 +135,14 @@ fixes. This allows to set at which level of the "r-RESPA"_run_style.html
integrator a fix is adding its forces. Default is the outermost level.
This fix calculates a global scalar which can be accessed by various
-"output commands"_Section_howto.html#howto_15. The scalar is the
-potential energy change due to this fix. The scalar value calculated
-by this fix is "extensive".
+"output commands"_Howto_output.html. The scalar is the potential
+energy change due to this fix. The scalar value calculated by this
+fix is "extensive".
This fix also calculates a per-atom array which can be accessed by
-various "output commands"_Section_howto.html#howto_15. The array
-stores the order parameter Xi and normalized order parameter (0 to 1)
-for each atom. The per-atom values can be accessed on any timestep.
+various "output commands"_Howto_output.html. The array stores the
+order parameter Xi and normalized order parameter (0 to 1) for each
+atom. The per-atom values can be accessed on any timestep.
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command. This fix is not invoked during "energy
@@ -151,8 +151,8 @@ minimization"_minimize.html.
[Restrictions:]
This fix is part of the MISC package. It is only enabled if LAMMPS
-was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This fix should only be used with fcc or bcc lattices.
diff --git a/doc/src/fix_phonon.txt b/doc/src/fix_phonon.txt
index aad6c2bfaa401bcb0af6e76851f849cb67c1af0c..0c449899df2a15965649820af6202e7f06bd702f 100644
--- a/doc/src/fix_phonon.txt
+++ b/doc/src/fix_phonon.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -150,7 +150,7 @@ fix. You can use it to change the temperature compute from thermo_temp
to the one that reflects the true temperature of atoms in the group.
No global scalar or vector or per-atom quantities are stored by this
-fix for access by various "output commands"_Section_howto.html#howto_15.
+fix for access by various "output commands"_Howto_output.html.
Instead, this fix outputs its initialization information (including
mapping information) and the calculated dynamical matrices to the file
@@ -171,11 +171,11 @@ temperature of the system should not exceed the melting temperature to
keep the system in its solid state.
This fix is part of the USER-PHONON package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
-This fix requires LAMMPS be built with an FFT library. See the
-"Making LAMMPS"_Section_start.html#start_2 section for more info.
+This fix requires LAMMPS be built with an FFT library. See the "Build
+settings"_Build_settings.html doc page for details.
[Related commands:]
diff --git a/doc/src/fix_pimd.txt b/doc/src/fix_pimd.txt
index 38022e4c7dd3d6d2e2bb1b0a56177fae2918604c..a82624497308567c3528413e6c052a63c693605c 100644
--- a/doc/src/fix_pimd.txt
+++ b/doc/src/fix_pimd.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -103,14 +103,13 @@ is appropriate for most situations.
The PIMD algorithm in LAMMPS is implemented as a hyper-parallel scheme
as described in "(Calhoun)"_#Calhoun. In LAMMPS this is done by using
-"multi-replica feature"_Section_howto.html#howto_5 in LAMMPS, where
-each quasi-particle system is stored and simulated on a separate
-partition of processors. The following diagram illustrates this
-approach. The original system with 2 ring polymers is shown in red.
-Since each ring has 4 quasi-beads (imaginary time slices), there are 4
-replicas of the system, each running on one of the 4 partitions of
-processors. Each replica (shown in green) owns one quasi-bead in each
-ring.
+"multi-replica feature"_Howto_replica.html in LAMMPS, where each
+quasi-particle system is stored and simulated on a separate partition
+of processors. The following diagram illustrates this approach. The
+original system with 2 ring polymers is shown in red. Since each ring
+has 4 quasi-beads (imaginary time slices), there are 4 replicas of the
+system, each running on one of the 4 partitions of processors. Each
+replica (shown in green) owns one quasi-bead in each ring.
:c,image(JPG/pimd.jpg)
@@ -137,8 +136,8 @@ read_restart system_$\{ibead\}.restart2 :pre
[Restrictions:]
This fix is part of the USER-MISC package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
A PIMD simulation can be initialized with a single data file read via
the "read_data"_read_data.html command. However, this means all
diff --git a/doc/src/fix_planeforce.txt b/doc/src/fix_planeforce.txt
index 67956c8b6ddfdcf7c3cfe0520f0fa888b4c9c87c..ffe1952e31a2f412ce23edf7b36a891b42f70f38 100644
--- a/doc/src/fix_planeforce.txt
+++ b/doc/src/fix_planeforce.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -35,9 +35,9 @@ should continue to move in the plane thereafter.
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
-by this fix for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of this fix can
-be used with the {start/stop} keywords of the "run"_run.html command.
+by this fix for access by various "output commands"_Howto_output.html.
+No parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command.
The forces due to this fix are imposed during an energy minimization,
invoked by the "minimize"_minimize.html command.
diff --git a/doc/src/fix_poems.txt b/doc/src/fix_poems.txt
index 03abc058b8b0d6e982f6291e1fecbb887cf2ad9a..52ab0ca44d7a740113441c0dd9d9e9a55f9b84a3 100644
--- a/doc/src/fix_poems.txt
+++ b/doc/src/fix_poems.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -114,17 +114,17 @@ early or late in a timestep, i.e. at the post-force stage or at the
final-integrate stage, respectively.
No global or per-atom quantities are stored by this fix for access by
-various "output commands"_Section_howto.html#howto_15. No parameter
-of this fix can be used with the {start/stop} keywords of the
-"run"_run.html command. This fix is not invoked during "energy
+various "output commands"_Howto_output.html. No parameter of this fix
+can be used with the {start/stop} keywords of the "run"_run.html
+command. This fix is not invoked during "energy
minimization"_minimize.html.
[Restrictions:]
This fix is part of the POEMS package. It is only enabled if LAMMPS
was built with that package, which also requires the POEMS library be
-built and linked with LAMMPS. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+built and linked with LAMMPS. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/fix_pour.txt b/doc/src/fix_pour.txt
index 54f78287e01d98368f1938122b1c9317e8446659..65f01c00fb85d7335afa734263a4c7da0a71255a 100644
--- a/doc/src/fix_pour.txt
+++ b/doc/src/fix_pour.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -237,16 +237,16 @@ appropriately.
None of the "fix_modify"_fix_modify.html options are relevant to this
fix. No global or per-atom quantities are stored by this fix for
-access by various "output commands"_Section_howto.html#howto_15. No
-parameter of this fix can be used with the {start/stop} keywords of
-the "run"_run.html command. This fix is not invoked during "energy
+access by various "output commands"_Howto_output.html. No parameter
+of this fix can be used with the {start/stop} keywords of the
+"run"_run.html command. This fix is not invoked during "energy
minimization"_minimize.html.
[Restrictions:]
This fix is part of the GRANULAR package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
For 3d simulations, a gravity fix in the -z direction must be defined
for use in conjunction with this fix. For 2d simulations, gravity
diff --git a/doc/src/fix_precession_spin.txt b/doc/src/fix_precession_spin.txt
index 4133d7dd57f42993ad8454d4d3e90973eccad34b..d58cd622b0913de70a3674396bc856771c1c9212 100644
--- a/doc/src/fix_precession_spin.txt
+++ b/doc/src/fix_precession_spin.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -67,18 +67,18 @@ to add this magnetic potential energy to the potential energy of the system,
fix 1 all precession/spin zeeman 1.0 0.0 0.0 1.0
fix_modify 1 energy yes :pre
-This fix computes a global scalar which can be accessed by various
-"output commands"_Section_howto.html#howto_15.
+This fix computes a global scalar which can be accessed by various
+"output commands"_Howto_output.html.
No information about this fix is written to "binary restart
files"_restart.html.
[Restrictions:]
-The {precession/spin} style is part of the SPIN package.
-This style is only enabled if LAMMPS was built with this package, and
-if the atom_style "spin" was declared.
-See the "Making LAMMPS"_Section_start.html#start_3 section for more info.
+The {precession/spin} style is part of the SPIN package. This style
+is only enabled if LAMMPS was built with this package, and if the
+atom_style "spin" was declared. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/fix_press_berendsen.txt b/doc/src/fix_press_berendsen.txt
index 9c9da8ec7b052f9e91651fa6adca5ee3ae675166..7f47a29ba35fa0a1ca9cc0c3aebd51917131564d 100644
--- a/doc/src/fix_press_berendsen.txt
+++ b/doc/src/fix_press_berendsen.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -58,9 +58,8 @@ to control the temperature, such as "fix nvt"_fix_nh.html or "fix
langevin"_fix_langevin.html or "fix
temp/berendsen"_fix_temp_berendsen.html.
-See "this howto section"_Section_howto.html#howto_16 of the manual for
-a discussion of different ways to compute temperature and perform
-thermostatting and barostatting.
+See the "Howto baroostat"_Howto_barostat.html doc page for a
+discussion of different ways to perform barostatting.
:line
@@ -196,7 +195,7 @@ pressure. LAMMPS will warn you if you choose to compute temperature
on a subset of atoms.
No global or per-atom quantities are stored by this fix for access by
-various "output commands"_Section_howto.html#howto_15.
+various "output commands"_Howto_output.html.
This fix can ramp its target pressure over multiple runs, using the
{start} and {stop} keywords of the "run"_run.html command. See the
diff --git a/doc/src/fix_print.txt b/doc/src/fix_print.txt
index cf3b542833b6d951e2b160797998e28406867758..d23c1103d3000963e8efcf4600080f79bf3eac20 100644
--- a/doc/src/fix_print.txt
+++ b/doc/src/fix_print.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -73,10 +73,10 @@ where ID is replaced with the fix-ID.
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
-by this fix for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of this fix can
-be used with the {start/stop} keywords of the "run"_run.html command.
-This fix is not invoked during "energy minimization"_minimize.html.
+by this fix for access by various "output commands"_Howto_output.html.
+No parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command. This fix is not invoked during "energy
+minimization"_minimize.html.
[Restrictions:] none
diff --git a/doc/src/fix_property_atom.txt b/doc/src/fix_property_atom.txt
index 10bb89c94cad5b28414578f621cab34c31266165..8a70cd8213ccc223c279e6961bf31b059c2dbf1d 100644
--- a/doc/src/fix_property_atom.txt
+++ b/doc/src/fix_property_atom.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -194,24 +194,24 @@ dump 1 all custom 100 tmp.dump id x y z c_1\[1\] c_1\[2\] :pre
If you wish to add new "pair styles"_pair_style.html,
"fixes"_fix.html, or "computes"_compute.html that use the per-atom
-properties defined by this fix, see "Section
-modify"_Section_modify.html#mod_1 of the manual which has some details
-on how the properties can be accessed from added classes.
+properties defined by this fix, see the "Modify atom"_Modify_atom.html
+doc page which has details on how the properties can be accessed from
+added classes.
:line
:link(isotopes)
-Example for using per-atom masses with TIP4P water to study isotope
-effects. When setting up simulations with the "TIP4P pair
-styles"_Section_howto.html#howto_8 for water, you have to provide
-exactly one atom type each to identify the water oxygen and hydrogen
+Example for using per-atom masses with TIP4P water to
+study isotope effects. When setting up simulations with the "TIP4P
+pair styles"_Howto_tip4p.html for water, you have to provide exactly
+one atom type each to identify the water oxygen and hydrogen
atoms. Since the atom mass is normally tied to the atom type, this
makes it impossible to study multiple isotopes in the same simulation.
With {fix property/atom rmass} however, the per-type masses are
replaced by per-atom masses. Asumming you have a working input deck
-for regular TIP4P water, where water oxygen is atom type 1 and
-water hydrogen is atom type 2, the following lines of input script
-convert this to using per-atom masses:
+for regular TIP4P water, where water oxygen is atom type 1 and water
+hydrogen is atom type 2, the following lines of input script convert
+this to using per-atom masses:
fix Isotopes all property/atom rmass ghost yes
set type 1 mass 15.9994
@@ -247,12 +247,12 @@ command for info on how to re-specify a fix in an input script that
reads a restart file, so that the operation of the fix continues in an
uninterrupted fashion.
-None of the "fix_modify"_fix_modify.html options
-are relevant to this fix. No global or per-atom quantities are stored
-by this fix for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of this fix can
-be used with the {start/stop} keywords of the "run"_run.html command.
-This fix is not invoked during "energy minimization"_minimize.html.
+None of the "fix_modify"_fix_modify.html options are relevant to this
+fix. No global or per-atom quantities are stored by this fix for
+access by various "output commands"_Howto_output.html. No parameter
+of this fix can be used with the {start/stop} keywords of the
+"run"_run.html command. This fix is not invoked during "energy
+minimization"_minimize.html.
[Restrictions:] none
diff --git a/doc/src/fix_python_invoke.txt b/doc/src/fix_python_invoke.txt
index 787940d9ebc4de8cd334a21454fe58dd6fa7b341..2a0124e6bfc0dd01d65f3b47d76df3a7de1bebc4 100644
--- a/doc/src/fix_python_invoke.txt
+++ b/doc/src/fix_python_invoke.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -62,9 +62,9 @@ case not work or in the worst case result in undefined behavior.
[Restrictions:]
-This fix is part of the PYTHON package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+This fix is part of the PYTHON package. It is only enabled if LAMMPS
+was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
Building LAMMPS with the PYTHON package will link LAMMPS with the
Python library on your system. Settings to enable this are in the
diff --git a/doc/src/fix_python_move.txt b/doc/src/fix_python_move.txt
index f10f607a9bc29ca630445664b844d9c1fce36fe5..c64ee788af9354955eb9fd2b63d07f8dcf773945 100644
--- a/doc/src/fix_python_move.txt
+++ b/doc/src/fix_python_move.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -83,16 +83,16 @@ Examples for how to do this are in the {examples/python} folder.
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
-by this fix for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of this fix can
-be used with the {start/stop} keywords of the "run"_run.html command.
-This fix is not invoked during "energy minimization"_minimize.html.
+by this fix for access by various "output commands"_Howto_output.html.
+No parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command. This fix is not invoked during "energy
+minimization"_minimize.html.
[Restrictions:]
This pair style is part of the PYTHON package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/fix_qbmsst.txt b/doc/src/fix_qbmsst.txt
index 2c116fb0f8cf34f6e29143035d0c9cc7414e2750..546d8c0813235c18868dfc47ad07b60d799e4d1d 100644
--- a/doc/src/fix_qbmsst.txt
+++ b/doc/src/fix_qbmsst.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -179,18 +179,18 @@ thermo_style custom step temp ke pe lz pzz etotal v_dhug v_dray v_lgr_vel v_
The global scalar under the entry f_fix_id is the quantity of thermo
energy as an extra part of <i>etot</i>. This global scalar and the
vector of 5 quantities can be accessed by various "output
-commands"_Section_howto.html#howto_15. It is worth noting that the
-temp keyword under the "thermo_style"_thermo_style.html command print
-the instantaneous classical temperature <i>T</i><sup>cl</sup> as
-described in the command "fix qtb"_fix_qtb.html.
+commands"_Howto_output.html. It is worth noting that the temp keyword
+under the "thermo_style"_thermo_style.html command print the
+instantaneous classical temperature <i>T</i><sup>cl</sup> as described
+in the command "fix qtb"_fix_qtb.html.
:line
[Restrictions:]
This fix style is part of the USER-QTB package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
All cell dimensions must be periodic. This fix can not be used with a
triclinic cell. The QBMSST fix has been tested only for the group-ID
diff --git a/doc/src/fix_qeq.txt b/doc/src/fix_qeq.txt
index 194361e990afdedbfccecf47be254c71df4623b7..46d2dd918cfc9f260a5307bdbd7657c8a671fa56 100644
--- a/doc/src/fix_qeq.txt
+++ b/doc/src/fix_qeq.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -179,17 +179,16 @@ parameters. See the examples/qeq directory for some examples.
No information about these fixes is written to "binary restart
files"_restart.html. No global scalar or vector or per-atom
quantities are stored by these fixes for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of these fixes
-can be used with the {start/stop} keywords of the "run"_run.html
-command.
+commands"_Howto_output.html. No parameter of these fixes can be used
+with the {start/stop} keywords of the "run"_run.html command.
Thexe fixes are invoked during "energy minimization"_minimize.html.
[Restrictions:]
These fixes are part of the QEQ package. They are only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/fix_qeq_comb.txt b/doc/src/fix_qeq_comb.txt
index 7f82404127fc61f6c3225f1c0d9b960bad470e27..714d03f6020f398d04fb3ee67d8f395c3f9a9a21 100644
--- a/doc/src/fix_qeq_comb.txt
+++ b/doc/src/fix_qeq_comb.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -62,23 +62,22 @@ equilibration calculation is written to the specified file.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -93,9 +92,9 @@ integrator the fix is performing charge equilibration. Default is
the outermost level.
This fix produces a per-atom vector which can be accessed by various
-"output commands"_Section_howto.html#howto_15. The vector stores the
-gradient of the charge on each atom. The per-atom values be accessed
-on any timestep.
+"output commands"_Howto_output.html. The vector stores the gradient
+of the charge on each atom. The per-atom values be accessed on any
+timestep.
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command.
diff --git a/doc/src/fix_qeq_reax.txt b/doc/src/fix_qeq_reax.txt
index 18450c7cd5c0852c30e2324f3c683d84a2b63479..b62d46d9de3a21e76a4f9405cc8acabaaa7009a0 100644
--- a/doc/src/fix_qeq_reax.txt
+++ b/doc/src/fix_qeq_reax.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -70,8 +70,8 @@ the {qeq/reax/omp} style. Otherwise they are processed separately.
No information about this fix is written to "binary restart
files"_restart.html. No global scalar or vector or per-atom
quantities are stored by this fix for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of this fix can
-be used with the {start/stop} keywords of the "run"_run.html command.
+commands"_Howto_output.html. No parameter of this fix can be used
+with the {start/stop} keywords of the "run"_run.html command.
This fix is invoked during "energy minimization"_minimize.html.
@@ -80,31 +80,30 @@ This fix is invoked during "energy minimization"_minimize.html.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This fix is part of the USER-REAXC package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This fix does not correctly handle interactions
involving multiple periodic images of the same atom. Hence, it should not
diff --git a/doc/src/fix_qmmm.txt b/doc/src/fix_qmmm.txt
index 1b4a850a42f7740ba4649d0a5cd8e494537987b3..2dbf935f93d3e82d7db6cbf8488da63e9d57812d 100644
--- a/doc/src/fix_qmmm.txt
+++ b/doc/src/fix_qmmm.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -46,16 +46,16 @@ No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global scalar or vector or per-atom
quantities are stored by this fix for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of this fix can
-be used with the {start/stop} keywords of the "run"_run.html command.
-This fix is not invoked during "energy minimization"_minimize.html.
+commands"_Howto_output.html. No parameter of this fix can be used
+with the {start/stop} keywords of the "run"_run.html command. This
+fix is not invoked during "energy minimization"_minimize.html.
[Restrictions:]
This fix is part of the USER-QMMM package. It is only enabled if
LAMMPS was built with that package. It also requires building a
-library provided with LAMMPS. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+library provided with LAMMPS. See the "Build
+package"_Build_package.html doc page for more info.
The fix is only functional when LAMMPS is built as a library and
linked with a compatible QM program and a QM/MM frontend into a QM/MM
diff --git a/doc/src/fix_qtb.txt b/doc/src/fix_qtb.txt
index 07a6af39ba2f81db6ed16cce0eb93d39ac98b65b..c412146604d49dd4bded74ee6e97b4e885256405 100644
--- a/doc/src/fix_qtb.txt
+++ b/doc/src/fix_qtb.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -155,8 +155,8 @@ This fix is not invoked during "energy minimization"_minimize.html.
[Restrictions:]
This fix style is part of the USER-QTB package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
:line
diff --git a/doc/src/fix_reax_bonds.txt b/doc/src/fix_reax_bonds.txt
index 3f8f237de1c7d574bfc214b9dfec2892e11b3793..06d30d871adbc423057799f1469aba3d50c505ff 100644
--- a/doc/src/fix_reax_bonds.txt
+++ b/doc/src/fix_reax_bonds.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -62,32 +62,32 @@ version, but will also take longer to write.
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
-by this fix for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of this fix can
-be used with the {start/stop} keywords of the "run"_run.html command.
-This fix is not invoked during "energy minimization"_minimize.html.
+by this fix for access by various "output commands"_Howto_output.html.
+No parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command. This fix is not invoked during "energy
+minimization"_minimize.html.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section_accelerate"_Section_accelerate.html
+hardware, as discussed in "Speed"_Speed.html
of the manual. The accelerated styles take the same arguments and
should 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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section_accelerate"_Section_accelerate.html of the manual for
+See "Speed"_Speed.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
@@ -101,8 +101,8 @@ which also requires the REAX library be built and linked with LAMMPS.
The fix reax/c/bonds command requires that the "pair_style
reax/c"_pair_reaxc.html be invoked. This fix is part of the
USER-REAXC package. It is only enabled if LAMMPS was built with that
-package. See the "Making LAMMPS"_Section_start.html#start_3 section
-for more info.
+package. See the "Build package"_Build_package.html doc page for more
+info.
To write gzipped bond files, you must compile LAMMPS with the
-DLAMMPS_GZIP option.
diff --git a/doc/src/fix_reaxc_species.txt b/doc/src/fix_reaxc_species.txt
index 7c920791f7b10bd923da0402c35a8215a15bf650..980384ff34c778e6ee3246c91762faff19b9e37e 100644
--- a/doc/src/fix_reaxc_species.txt
+++ b/doc/src/fix_reaxc_species.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -116,8 +116,8 @@ are relevant to this fix.
This fix computes both a global vector of length 2 and a per-atom
vector, either of which can be accessed by various "output
-commands"_Section_howto.html#howto_15. The values in the global
-vector are "intensive".
+commands"_Howto_output.html. The values in the global vector are
+"intensive".
The 2 values in the global vector are as follows:
@@ -139,34 +139,34 @@ minimization"_minimize.html.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section_accelerate"_Section_accelerate.html
+hardware, as discussed in "Speed"_Speed.html
of the manual. The accelerated styles take the same arguments and
should 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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section_accelerate"_Section_accelerate.html of the manual for
+See "Speed"_Speed.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
-The fix species currently only works with
-"pair_style reax/c"_pair_reaxc.html and it requires that the "pair_style
+The fix species currently only works with "pair_style
+reax/c"_pair_reaxc.html and it requires that the "pair_style
reax/c"_pair_reaxc.html be invoked. This fix is part of the
USER-REAXC package. It is only enabled if LAMMPS was built with that
-package. See the "Making LAMMPS"_Section_start.html#start_3 section
-for more info.
+package. See the "Build package"_Build_package.html doc page for more
+info.
To write gzipped species files, you must compile LAMMPS with the
-DLAMMPS_GZIP option.
diff --git a/doc/src/fix_recenter.txt b/doc/src/fix_recenter.txt
index 342bed42515f8b827cc18a1cd228480480bd70f0..cfac756cd1659f9d8e7fcc6abc2922104a6b7bb0 100644
--- a/doc/src/fix_recenter.txt
+++ b/doc/src/fix_recenter.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -94,13 +94,13 @@ files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix.
This fix computes a global scalar which can be accessed by various
-"output commands"_Section_howto.html#howto_15. The scalar is the
-distance the group is moved by fix recenter.
+"output commands"_Howto_output.html. The scalar is the distance the
+group is moved by fix recenter.
This fix also computes global 3-vector which can be accessed by
-various "output commands"_Section_howto.html#howto_15. The 3
-quantities in the vector are xyz components of displacement applied to
-the group of atoms by the fix.
+various "output commands"_Howto_output.html. The 3 quantities in the
+vector are xyz components of displacement applied to the group of
+atoms by the fix.
The scalar and vector values calculated by this fix are "extensive".
diff --git a/doc/src/fix_restrain.txt b/doc/src/fix_restrain.txt
index 9de63defb700fb0f713187d87f4077fd35b86e0f..2edc7e32963bb94c3bd60158bd21f94ba123e0a4 100644
--- a/doc/src/fix_restrain.txt
+++ b/doc/src/fix_restrain.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -187,8 +187,8 @@ added forces to be included in the total potential energy of the
system (the quantity being minimized), you MUST enable the
"fix_modify"_fix_modify.html {energy} option for this fix.
-This fix computes a global scalar and a global vector of length 3, which
-can be accessed by various "output commands"_Section_howto.html#howto_15.
+This fix computes a global scalar and a global vector of length 3,
+which can be accessed by various "output commands"_Howto_output.html.
The scalar is the total potential energy for {all} the restraints as
discussed above. The vector values are the sum of contributions to the
following individual categories:
diff --git a/doc/src/fix_rhok.txt b/doc/src/fix_rhok.txt
index 2db920ac4bef02c60f95604beb5e6feeb9cb7de6..a3d1ab702ebd6b28c55215a80d40d548017cc863 100644
--- a/doc/src/fix_rhok.txt
+++ b/doc/src/fix_rhok.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -40,8 +40,8 @@ An example of using the interface pinning method is located in the
[Restrictions:]
This fix is part of the MISC package. It is only enabled if LAMMPS
-was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/fix_rigid.txt b/doc/src/fix_rigid.txt
index 8d803ac6dacfcb4483fb4d66a204e8f3cba6989e..d489762e8022bdfe7f4d82af51a7642fe8fbd286 100644
--- a/doc/src/fix_rigid.txt
+++ b/doc/src/fix_rigid.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -244,7 +244,7 @@ includes atoms you want to be part of rigid bodies.
Bodystyle {custom} is similar to bodystyle {molecule} except that it
is more flexible in using other per-atom properties to define the sets
of atoms that form rigid bodies. An integer vector defined by the
-"fix property/atom"_fix_property_atom.txt command can be used. Or an
+"fix property/atom"_fix_property_atom.html command can be used. Or an
"atom-style or atomfile-style variable"_variable.html can be used; the
floating-point value produced by the variable is rounded to an
integer. As with bondstyle {molecule}, each set of atoms in the fix
@@ -690,23 +690,22 @@ rigid/nvt.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -746,29 +745,29 @@ computed early or late in a timestep, i.e. at the post-force stage or
at the final-integrate stage or the timestep, respectively.
The 2 NVE rigid fixes compute a global scalar which can be accessed by
-various "output commands"_Section_howto.html#howto_15. The scalar
-value calculated by these fixes is "intensive". The scalar is the
-current temperature of the collection of rigid bodies. This is
-averaged over all rigid bodies and their translational and rotational
-degrees of freedom. The translational energy of a rigid body is 1/2 m
-v^2, where m = total mass of the body and v = the velocity of its
-center of mass. The rotational energy of a rigid body is 1/2 I w^2,
-where I = the moment of inertia tensor of the body and w = its angular
-velocity. Degrees of freedom constrained by the {force} and {torque}
-keywords are removed from this calculation, but only for the {rigid}
-and {rigid/nve} fixes.
+various "output commands"_Howto_output.html. The scalar value
+calculated by these fixes is "intensive". The scalar is the current
+temperature of the collection of rigid bodies. This is averaged over
+all rigid bodies and their translational and rotational degrees of
+freedom. The translational energy of a rigid body is 1/2 m v^2, where
+m = total mass of the body and v = the velocity of its center of mass.
+The rotational energy of a rigid body is 1/2 I w^2, where I = the
+moment of inertia tensor of the body and w = its angular velocity.
+Degrees of freedom constrained by the {force} and {torque} keywords
+are removed from this calculation, but only for the {rigid} and
+{rigid/nve} fixes.
The 6 NVT, NPT, NPH rigid fixes compute a global scalar which can be
-accessed by various "output commands"_Section_howto.html#howto_15.
-The scalar value calculated by these fixes is "extensive". The scalar
-is the cumulative energy change due to the thermostatting and
-barostatting the fix performs.
+accessed by various "output commands"_Howto_output.html. The scalar
+value calculated by these fixes is "extensive". The scalar is the
+cumulative energy change due to the thermostatting and barostatting
+the fix performs.
All of the {rigid} styles (not the {rigid/small} styles) compute a
global array of values which can be accessed by various "output
-commands"_Section_howto.html#howto_15. Similar information about the
-bodies defined by the {rigid/small} styles can be accessed via the
-"compute rigid/local"_compute_rigid_local.html command.
+commands"_Howto_output.html. Similar information about the bodies
+defined by the {rigid/small} styles can be accessed via the "compute
+rigid/local"_compute_rigid_local.html command.
The number of rows in the array is equal to the number of rigid
bodies. The number of columns is 15. Thus for each rigid body, 15
@@ -807,8 +806,8 @@ of the "run"_run.html command. These fixes are not invoked during
[Restrictions:]
These fixes are all part of the RIGID package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
Assigning a temperature via the "velocity create"_velocity.html
command to a system with "rigid bodies"_fix_rigid.html may not have
diff --git a/doc/src/fix_rx.txt b/doc/src/fix_rx.txt
index 0810a347408f33cf20586448cf2141fb4c037275..ad42c577aaf279c007a3aa6a55cceea0b382ed05 100644
--- a/doc/src/fix_rx.txt
+++ b/doc/src/fix_rx.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -186,31 +186,30 @@ read_data data.dpd fix foo_SPECIES NULL Species
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This command is part of the USER-DPD package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This command also requires use of the "atom_style dpd"_atom_style.html
command.
diff --git a/doc/src/fix_saed_vtk.txt b/doc/src/fix_saed_vtk.txt
index 814e17b8e952ad71d3ffe918c99596a0d10dc575..60708cd6962cfa57823d1a3c3d33ba1b50a5f661 100644
--- a/doc/src/fix_saed_vtk.txt
+++ b/doc/src/fix_saed_vtk.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/fix_setforce.txt b/doc/src/fix_setforce.txt
index f5be0f93a54c459ead80c691dd4905df678760c4..4b9abba52ffee7bba246501c3fc77a8d5f495616 100644
--- a/doc/src/fix_setforce.txt
+++ b/doc/src/fix_setforce.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -65,28 +65,28 @@ to it.
:line
-Styles with a r {kk} suffix are functionally the same as the
-corresponding style without the suffix. They have been optimized to
-run faster, depending on your available hardware, as discussed in
-"Section 5"_Section_accelerate.html of the manual. The
-accelerated styles take the same arguments and should produce the same
-results, except for round-off and precision issues.
+Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
+functionally the same as the corresponding style without the suffix.
+They have been optimized to run faster, depending on your available
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+produce the same results, except for round-off and precision issues.
The region keyword is also supported by Kokkos, but a Kokkos-enabled
region must be used. See the region "region"_region.html command for
more information.
These accelerated styles are part of the r Kokkos package. They are
-only enabled if LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+only enabled if LAMMPS was built with that package. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -103,10 +103,10 @@ so that setforce values are not counted multiple times. Default is to
to override forces at the outermost level.
This fix computes a global 3-vector of forces, which can be accessed
-by various "output commands"_Section_howto.html#howto_15. This is the
-total force on the group of atoms before the forces on individual
-atoms are changed by the fix. The vector values calculated by this
-fix are "extensive".
+by various "output commands"_Howto_output.html. This is the total
+force on the group of atoms before the forces on individual atoms are
+changed by the fix. The vector values calculated by this fix are
+"extensive".
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command.
diff --git a/doc/src/fix_shake.txt b/doc/src/fix_shake.txt
index 46452a1f7e932eaf2531525f7ee6d557fceffb37..77bb5794f6d8e91852c1eb1857357e25e13337a9 100644
--- a/doc/src/fix_shake.txt
+++ b/doc/src/fix_shake.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -145,25 +145,25 @@ info of atoms in the molecule.
:line
-Styles with a suffix are functionally the same as the corresponding
-style without the suffix. They have been optimized to run faster,
-depending on your available hardware, as discussed in
-"Section 5"_Section_accelerate.html of the manual. The
-accelerated styles take the same arguments and should produce the same
-results, except for round-off and precision issues.
+Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
+functionally the same as the corresponding style without the suffix.
+They have been optimized to run faster, depending on your available
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -195,16 +195,15 @@ No information about these fixes is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to these fixes. No global or per-atom quantities are
stored by these fixes for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of these fixes
-can be used with the {start/stop} keywords of the "run"_run.html
-command. These fixes are not invoked during "energy
-minimization"_minimize.html.
+commands"_Howto_output.html. No parameter of these fixes can be used
+with the {start/stop} keywords of the "run"_run.html command. These
+fixes are not invoked during "energy minimization"_minimize.html.
[Restrictions:]
These fixes are part of the RIGID package. They are only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
For computational efficiency, there can only be one shake or rattle
fix defined in a simulation.
diff --git a/doc/src/fix_shardlow.txt b/doc/src/fix_shardlow.txt
index 24726d8610abf0a79db6e14b163731d61ff46404..c1be146fa6f7ed71dd7114b46f5f77d954f5b5e0 100644
--- a/doc/src/fix_shardlow.txt
+++ b/doc/src/fix_shardlow.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -56,31 +56,30 @@ examples/USER/dpd directory.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This command is part of the USER-DPD package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This fix is currently limited to orthogonal simulation cell
geometries.
diff --git a/doc/src/fix_smd.txt b/doc/src/fix_smd.txt
index cb4a40f0fd0a3cbea0f95de29562e5e4faea110b..644c04eadb9efe7e64d6f51f68893e8d9e59a1e7 100644
--- a/doc/src/fix_smd.txt
+++ b/doc/src/fix_smd.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -111,12 +111,12 @@ this fix. This allows to set at which level of the "r-RESPA"_run_style.html
integrator the fix is adding its forces. Default is the outermost level.
This fix computes a vector list of 7 quantities, which can be accessed
-by various "output commands"_Section_howto.html#howto_15. The
-quantities in the vector are in this order: the x-, y-, and
-z-component of the pulling force, the total force in direction of the
-pull, the equilibrium distance of the spring, the distance between the
-two reference points, and finally the accumulated PMF (the sum of
-pulling forces times displacement).
+by various "output commands"_Howto_output.html. The quantities in the
+vector are in this order: the x-, y-, and z-component of the pulling
+force, the total force in direction of the pull, the equilibrium
+distance of the spring, the distance between the two reference points,
+and finally the accumulated PMF (the sum of pulling forces times
+displacement).
The force is the total force on the group of atoms by the spring. In
the case of the {couple} style, it is the force on the fix group
@@ -130,8 +130,8 @@ minimization"_minimize.html.
[Restrictions:]
This fix is part of the USER-MISC package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/fix_smd_adjust_dt.txt b/doc/src/fix_smd_adjust_dt.txt
index 86b7363300929bada7f049fae3f3c13cf3cec11f..3535ddfcc22edee05efdaf4d2c6ab932d683ef5d 100644
--- a/doc/src/fix_smd_adjust_dt.txt
+++ b/doc/src/fix_smd_adjust_dt.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -25,18 +25,23 @@ fix 1 all smd/adjust_dt 0.1 :pre
[Description:]
-The fix calculates a new stable time increment for use with the SMD time integrators.
+The fix calculates a new stable time increment for use with the SMD
+time integrators.
-The stable time increment is based on multiple conditions. For the SPH pair styles, a
-CFL criterion (Courant, Friedrichs & Lewy, 1928) is evaluated, which determines the speed of
-sound cannot propagate further than a typical spacing between particles within a single time step to ensure
-no information is lost. For the contact pair styles, a linear analysis of the pair potential determines a
-stable maximum time step.
+The stable time increment is based on multiple conditions. For the SPH
+pair styles, a CFL criterion (Courant, Friedrichs & Lewy, 1928) is
+evaluated, which determines the speed of sound cannot propagate
+further than a typical spacing between particles within a single time
+step to ensure no information is lost. For the contact pair styles, a
+linear analysis of the pair potential determines a stable maximum time
+step.
-This fix inquires the minimum stable time increment across all particles contained in the group for which this
-fix is defined. An additional safety factor {s_fact} is applied to the time increment.
+This fix inquires the minimum stable time increment across all
+particles contained in the group for which this fix is defined. An
+additional safety factor {s_fact} is applied to the time increment.
-See "this PDF guide"_PDF/SMD_LAMMPS_userguide.pdf to use Smooth Mach Dynamics in LAMMPS.
+See "this PDF guide"_PDF/SMD_LAMMPS_userguide.pdf to use Smooth Mach
+Dynamics in LAMMPS.
[Restart, fix_modify, output, run start/stop, minimize info:]
@@ -45,8 +50,8 @@ Currently, no part of USER-SMD supports restarting nor minimization.
[Restrictions:]
This fix is part of the USER-SMD package. It is only enabled if
-LAMMPS was built with that package. See the "Making LAMMPS"_Section_start.html#start_3
-section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/fix_smd_integrate_tlsph.txt b/doc/src/fix_smd_integrate_tlsph.txt
index 17c9c0f400f4cdf5dfc67966d5b1f51d4d0f4672..029605ff7f7b5143e1ad99d5f6161fd4718a0764 100644
--- a/doc/src/fix_smd_integrate_tlsph.txt
+++ b/doc/src/fix_smd_integrate_tlsph.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -27,22 +27,26 @@ fix 1 all smd/integrate_tlsph limit_velocity 1000 :pre
[Description:]
-The fix performs explicit time integration for particles which interact according with the Total-Lagrangian SPH pair style.
+The fix performs explicit time integration for particles which
+interact according with the Total-Lagrangian SPH pair style.
-See "this PDF guide"_PDF/SMD_LAMMPS_userguide.pdf to using Smooth Mach Dynamics in LAMMPS.
+See "this PDF guide"_PDF/SMD_LAMMPS_userguide.pdf to using Smooth Mach
+Dynamics in LAMMPS.
-The {limit_velocity} keyword will control the velocity, scaling the norm of
-the velocity vector to max_vel in case it exceeds this velocity limit.
+The {limit_velocity} keyword will control the velocity, scaling the
+norm of the velocity vector to max_vel in case it exceeds this
+velocity limit.
[Restart, fix_modify, output, run start/stop, minimize info:]
-Currently, no part of USER-SMD supports restarting nor minimization. This fix has no outputs.
+Currently, no part of USER-SMD supports restarting nor
+minimization. This fix has no outputs.
[Restrictions:]
This fix is part of the USER-SMD package. It is only enabled if
-LAMMPS was built with that package. See the "Making LAMMPS"_Section_start.html#start_3
-section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/fix_smd_integrate_ulsph.txt b/doc/src/fix_smd_integrate_ulsph.txt
index 28e38c7f970a9d99a07294bd77f4fb66a54ced00..a99574cc85d75427a5507cc90d3c69e8aece085e 100644
--- a/doc/src/fix_smd_integrate_ulsph.txt
+++ b/doc/src/fix_smd_integrate_ulsph.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -24,7 +24,6 @@ adjust_radius values = adjust_radius_factor min_nn max_nn
limit_velocity values = max_velocity
max_velocity = maximum allowed velocity.
-
[Examples:]
fix 1 all smd/integrate_ulsph adjust_radius 1.02 25 50
@@ -32,28 +31,33 @@ fix 1 all smd/integrate_ulsph limit_velocity 1000 :pre
[Description:]
-The fix performs explicit time integration for particles which interact with the updated Lagrangian SPH pair style.
-See "this PDF guide"_PDF/SMD_LAMMPS_userguide.pdf to using Smooth Mach Dynamics in LAMMPS.
+The fix performs explicit time integration for particles which
+interact with the updated Lagrangian SPH pair style.
+
+See "this PDF guide"_PDF/SMD_LAMMPS_userguide.pdf to using Smooth Mach
+Dynamics in LAMMPS.
-The {adjust_radius} keyword activates dynamic adjustment of the per-particle SPH smoothing kernel radius such that the number of neighbors per particles remains
-within the interval {min_nn} to {max_nn}. The parameter {adjust_radius_factor} determines the amount of adjustment per timestep. Typical values are
-{adjust_radius_factor} =1.02, {min_nn} =15, and {max_nn} =20.
+The {adjust_radius} keyword activates dynamic adjustment of the
+per-particle SPH smoothing kernel radius such that the number of
+neighbors per particles remains within the interval {min_nn} to
+{max_nn}. The parameter {adjust_radius_factor} determines the amount
+of adjustment per timestep. Typical values are {adjust_radius_factor}
+=1.02, {min_nn} =15, and {max_nn} =20.
The {limit_velocity} keyword will control the velocity, scaling the norm of
the velocity vector to max_vel in case it exceeds this velocity limit.
[Restart, fix_modify, output, run start/stop, minimize info:]
-Currently, no part of USER-SMD supports restarting nor minimization. This fix has no outputs.
+Currently, no part of USER-SMD supports restarting nor
+minimization. This fix has no outputs.
[Restrictions:]
This fix is part of the USER-SMD package. It is only enabled if
-LAMMPS was built with that package. See the "Making LAMMPS"_Section_start.html#start_3
-section for more info.
-
-[Related commands:]
-
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
+[Related commands:] none
[Default:] none
diff --git a/doc/src/fix_smd_move_triangulated_surface.txt b/doc/src/fix_smd_move_triangulated_surface.txt
index 2cba001267433e921d908bd9d344cb1152886fde..2a998ba8c6128b86ebd42c9e9f80ad03d07caf50 100644
--- a/doc/src/fix_smd_move_triangulated_surface.txt
+++ b/doc/src/fix_smd_move_triangulated_surface.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -25,7 +25,6 @@ keyword = {*LINEAR} or {*WIGGLE} or {*ROTATE} :l
Px,Py,Pz = origin point of axis of rotation (distance units)
Rx,Ry,Rz = axis of rotation vector
period = period of rotation (time units) :pre
-
:ule
[Examples:]
@@ -36,9 +35,11 @@ fix 2 tool smd/move_tri_surf *ROTATE 0 0 0 5 2 1 :pre
[Description:]
-This fix applies only to rigid surfaces read from .STL files via fix "smd/wall_surface"_fix_smd_wall_surface.html .
-It updates position and velocity for the particles in the group each timestep without regard to forces on the particles.
-The rigid surfaces can thus be moved along simple trajectories during the simulation.
+This fix applies only to rigid surfaces read from .STL files via fix
+"smd/wall_surface"_fix_smd_wall_surface.html . It updates position
+and velocity for the particles in the group each timestep without
+regard to forces on the particles. The rigid surfaces can thus be
+moved along simple trajectories during the simulation.
The {*LINEAR} style moves particles with the specified constant velocity
vector V = (Vx,Vy,Vz). This style also sets the velocity of each particle
@@ -49,27 +50,30 @@ Particles are moved along (vx, vy, vz) with constant velocity until a
displacement of max_travel is reached. Then, the velocity vector is
reversed. This process is repeated.
-The {*ROTATE} style rotates particles around a rotation axis R = (Rx,Ry,Rz) that
-goes through a point P = (Px,Py,Pz). The period of the rotation is also
-specified. This style also sets the velocity of each particle to (omega cross
-Rperp) where omega is its angular velocity around the rotation axis and
-Rperp is a perpendicular vector from the rotation axis to the particle.
+The {*ROTATE} style rotates particles around a rotation axis R =
+(Rx,Ry,Rz) that goes through a point P = (Px,Py,Pz). The period of the
+rotation is also specified. This style also sets the velocity of each
+particle to (omega cross Rperp) where omega is its angular velocity
+around the rotation axis and Rperp is a perpendicular vector from the
+rotation axis to the particle.
-See "this PDF guide"_PDF/SMD_LAMMPS_userguide.pdf to using Smooth Mach Dynamics in LAMMPS.
+See "this PDF guide"_PDF/SMD_LAMMPS_userguide.pdf to using Smooth Mach
+Dynamics in LAMMPS.
[Restart, fix_modify, output, run start/stop, minimize info:]
-Currently, no part of USER-SMD supports restarting nor minimization. This fix has no outputs.
+Currently, no part of USER-SMD supports restarting nor
+minimization. This fix has no outputs.
[Restrictions:]
This fix is part of the USER-SMD package. It is only enabled if
-LAMMPS was built with that package. See the "Making LAMMPS"_Section_start.html#start_3
-section for more info.
-
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
-"smd/triangle_mesh_vertices"_compute_smd_triangle_mesh_vertices.html, "smd/wall_surface"_fix_smd_wall_surface.html
+"smd/triangle_mesh_vertices"_compute_smd_triangle_mesh_vertices.html,
+"smd/wall_surface"_fix_smd_wall_surface.html
[Default:] none
diff --git a/doc/src/fix_smd_setvel.txt b/doc/src/fix_smd_setvel.txt
index f93a7d0965b3eecb29dd130db7bbfbe0ae64bd63..b170eff8608c4465c77d02a4ff5a0d726c8e110b 100644
--- a/doc/src/fix_smd_setvel.txt
+++ b/doc/src/fix_smd_setvel.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -66,9 +66,9 @@ None of the "fix_modify"_fix_modify.html options
are relevant to this fix.
This fix computes a global 3-vector of forces, which can be accessed
-by various "output commands"_Section_howto.html#howto_15. This is the
-total force on the group of atoms. The vector values calculated by this
-fix are "extensive".
+by various "output commands"_Howto_output.html. This is the total
+force on the group of atoms. The vector values calculated by this fix
+are "extensive".
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command.
@@ -76,8 +76,8 @@ the "run"_run.html command.
[Restrictions:]
This fix is part of the USER-SMD package. It is only enabled if
-LAMMPS was built with that package. See the "Making LAMMPS"_Section_start.html#start_3
-section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:] none
diff --git a/doc/src/fix_smd_wall_surface.txt b/doc/src/fix_smd_wall_surface.txt
index feb65b2312823ece1b261e5349750500018b6ed7..dc3625e95ed18df89d863785613a5241d80ece76 100644
--- a/doc/src/fix_smd_wall_surface.txt
+++ b/doc/src/fix_smd_wall_surface.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -17,9 +17,7 @@ smd/wall_surface = style name of this fix command :l
arg = {file} :l
{file} = file name of a triangular mesh in stl format :pre
type = particle type to be given to the new particles created by this fix :l
-mol-ID = molecule-ID to be given to the new particles created by this fix (must be >= 65535) :l
-
-:ule
+mol-ID = molecule-ID to be given to the new particles created by this fix (must be >= 65535) :l,ule
[Examples:]
@@ -27,32 +25,47 @@ fix stl_surf all smd/wall_surface tool.stl 2 65535 :pre
[Description:]
-This fix creates reads a triangulated surface from a file in .STL format.
-For each triangle, a new particle is created which stores the barycenter of the triangle and the vertex positions.
-The radius of the new particle is that of the minimum circle which encompasses the triangle vertices.
+This fix creates reads a triangulated surface from a file in .STL
+format. For each triangle, a new particle is created which stores the
+barycenter of the triangle and the vertex positions. The radius of
+the new particle is that of the minimum circle which encompasses the
+triangle vertices.
-The triangulated surface can be used as a complex rigid wall via the "smd/tri_surface"_pair_smd_triangulated_surface.html pair style.
-It is possible to move the triangulated surface via the "smd/move_tri_surf"_fix_smd_move_triangulated_surface.html fix style.
+The triangulated surface can be used as a complex rigid wall via the
+"smd/tri_surface"_pair_smd_triangulated_surface.html pair style. It
+is possible to move the triangulated surface via the
+"smd/move_tri_surf"_fix_smd_move_triangulated_surface.html fix style.
-Immediately after a .STL file has been read, the simulation needs to be run for 0 timesteps in order to properly register the new particles
-in the system. See the "funnel_flow" example in the USER-SMD examples directory.
+Immediately after a .STL file has been read, the simulation needs to
+be run for 0 timesteps in order to properly register the new particles
+in the system. See the "funnel_flow" example in the USER-SMD examples
+directory.
-See "this PDF guide"_PDF/SMD_LAMMPS_userguide.pdf to use Smooth Mach Dynamics in LAMMPS.
+See "this PDF guide"_PDF/SMD_LAMMPS_userguide.pdf to use Smooth Mach
+Dynamics in LAMMPS.
[Restart, fix_modify, output, run start/stop, minimize info:]
-Currently, no part of USER-SMD supports restarting nor minimization. This fix has no outputs.
+Currently, no part of USER-SMD supports restarting nor
+minimization. This fix has no outputs.
[Restrictions:]
This fix is part of the USER-SMD package. It is only enabled if
-LAMMPS was built with that package. See the "Making LAMMPS"_Section_start.html#start_3
-section for more info. The molecule ID given to the particles created by this fix have to be equal to or larger than 65535.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
+
+The molecule ID given to the particles created by this fix have to be
+equal to or larger than 65535.
-Within each .STL file, only a single triangulated object must be present, even though the STL format allows for the possibility of multiple objects in one file.
+Within each .STL file, only a single triangulated object must be
+present, even though the STL format allows for the possibility of
+multiple objects in one file.
[Related commands:]
-"smd/triangle_mesh_vertices"_compute_smd_triangle_mesh_vertices.html, "smd/move_tri_surf"_fix_smd_move_triangulated_surface.html, "smd/tri_surface"_pair_smd_triangulated_surface.html
+"smd/triangle_mesh_vertices"_compute_smd_triangle_mesh_vertices.html,
+"smd/move_tri_surf"_fix_smd_move_triangulated_surface.html,
+"smd/tri_surface"_pair_smd_triangulated_surface.html
[Default:] none
diff --git a/doc/src/fix_spring.txt b/doc/src/fix_spring.txt
index 014a43aacc706e03b37ceb37ca906a1fb248f275..690fc3e67c381a9cddd7469e22d9a925f75e4c14 100644
--- a/doc/src/fix_spring.txt
+++ b/doc/src/fix_spring.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -105,19 +105,19 @@ fix. This allows to set at which level of the "r-RESPA"_run_style.html
integrator the fix is adding its forces. Default is the outermost level.
This fix computes a global scalar which can be accessed by various
-"output commands"_Section_howto.html#howto_15. The scalar is the
-spring energy = 0.5 * K * r^2.
+"output commands"_Howto_output.html. The scalar is the spring energy
+= 0.5 * K * r^2.
This fix also computes global 4-vector which can be accessed by
-various "output commands"_Section_howto.html#howto_15. The first 3
-quantities in the vector are xyz components of the total force added
-to the group of atoms by the spring. In the case of the {couple}
-style, it is the force on the fix group (group-ID) or the negative of
-the force on the 2nd group (group-ID2). The 4th quantity in the
-vector is the magnitude of the force added by the spring, as a
-positive value if (r-R0) > 0 and a negative value if (r-R0) < 0. This
-sign convention can be useful when using the spring force to compute a
-potential of mean force (PMF).
+various "output commands"_Howto_output.html. The first 3 quantities
+in the vector are xyz components of the total force added to the group
+of atoms by the spring. In the case of the {couple} style, it is the
+force on the fix group (group-ID) or the negative of the force on the
+2nd group (group-ID2). The 4th quantity in the vector is the
+magnitude of the force added by the spring, as a positive value if
+(r-R0) > 0 and a negative value if (r-R0) < 0. This sign convention
+can be useful when using the spring force to compute a potential of
+mean force (PMF).
The scalar and vector values calculated by this fix are "extensive".
diff --git a/doc/src/fix_spring_chunk.txt b/doc/src/fix_spring_chunk.txt
index 7630a009dd3bbfd9d087f5b57060f8f56c216227..9d4e8afd090e3a0ea9bc12af04cf1db4b53b6945 100644
--- a/doc/src/fix_spring_chunk.txt
+++ b/doc/src/fix_spring_chunk.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -60,8 +60,8 @@ fix. This allows to set at which level of the "r-RESPA"_run_style.html
integrator the fix is adding its forces. Default is the outermost level.
This fix computes a global scalar which can be accessed by various
-"output commands"_Section_howto.html#howto_15. The scalar is the
-energy of all the springs, i.e. 0.5 * K * r^2 per-spring.
+"output commands"_Howto_output.html. The scalar is the energy of all
+the springs, i.e. 0.5 * K * r^2 per-spring.
The scalar value calculated by this fix is "extensive".
diff --git a/doc/src/fix_spring_rg.txt b/doc/src/fix_spring_rg.txt
index bff6b38e7e94c44477c07e94efb0b72f909dfc43..b252163958fe5b983faeb2fc25e976bcf602f211 100644
--- a/doc/src/fix_spring_rg.txt
+++ b/doc/src/fix_spring_rg.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -51,10 +51,10 @@ the time the fix is specified, and that value is used as the target.
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
-by this fix for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of this fix can
-be used with the {start/stop} keywords of the "run"_run.html command.
-This fix is not invoked during "energy minimization"_minimize.html.
+by this fix for access by various "output commands"_Howto_output.html.
+No parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command. This fix is not invoked during "energy
+minimization"_minimize.html.
The "fix_modify"_fix_modify.html {respa} option is supported by this
fix. This allows to set at which level of the "r-RESPA"_run_style.html
diff --git a/doc/src/fix_spring_self.txt b/doc/src/fix_spring_self.txt
index 68961a1512d1ba80ddd72da8024333cc51180103..0ac1d5eecb627a363b900d5af01ebef318e200b0 100644
--- a/doc/src/fix_spring_self.txt
+++ b/doc/src/fix_spring_self.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -57,10 +57,10 @@ this fix. This allows to set at which level of the "r-RESPA"_run_style.html
integrator the fix is adding its forces. Default is the outermost level.
This fix computes a global scalar which can be accessed by various
-"output commands"_Section_howto.html#howto_15. The scalar is an
-energy which is the sum of the spring energy for each atom, where the
-per-atom energy is 0.5 * K * r^2. The scalar value calculated by this
-fix is "extensive".
+"output commands"_Howto_output.html. The scalar is an energy which is
+the sum of the spring energy for each atom, where the per-atom energy
+is 0.5 * K * r^2. The scalar value calculated by this fix is
+"extensive".
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command.
diff --git a/doc/src/fix_srd.txt b/doc/src/fix_srd.txt
index 4e190234fd2b873cb5592c9c335304b53245d5c1..557eee1cfc65738f56609a576882bd06c8b7224f 100644
--- a/doc/src/fix_srd.txt
+++ b/doc/src/fix_srd.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -341,11 +341,11 @@ are relevant to this fix.
This fix tabulates several SRD statistics which are stored in a vector
of length 12, which can be accessed by various "output
-commands"_Section_howto.html#howto_15. The vector values calculated
-by this fix are "intensive", meaning they do not scale with the size
-of the simulation. Technically, the first 8 do scale with the size of
-the simulation, but treating them as intensive means they are not
-scaled when printed as part of thermodynamic output.
+commands"_Howto_output.html. The vector values calculated by this fix
+are "intensive", meaning they do not scale with the size of the
+simulation. Technically, the first 8 do scale with the size of the
+simulation, but treating them as intensive means they are not scaled
+when printed as part of thermodynamic output.
These are the 12 quantities. All are values for the current timestep,
except for quantity 5 and the last three, each of which are
@@ -371,8 +371,8 @@ minimization"_minimize.html.
[Restrictions:]
This command can only be used if LAMMPS was built with the SRD
-package. See the "Making LAMMPS"_Section_start.html#start_3 section
-for more info on packages.
+package. See the "Build package"_Build_package.html doc
+page for more info.
[Related commands:]
diff --git a/doc/src/fix_store_force.txt b/doc/src/fix_store_force.txt
index c988431f9de8dc47b85bfbce1d9cc82de1228270..33ebc962d5da9def4a817dbf6a1e9cdb78c5e4ad 100644
--- a/doc/src/fix_store_force.txt
+++ b/doc/src/fix_store_force.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -26,7 +26,7 @@ timestep when the fix is invoked, as described below. This is useful
for storing forces before constraints or other boundary conditions are
computed which modify the forces, so that unmodified forces can be
"written to a dump file"_dump.html or accessed by other "output
-commands"_Section_howto.html#howto_15 that use per-atom quantities.
+commands"_Howto_output.html that use per-atom quantities.
This fix is invoked at the point in the velocity-Verlet timestepping
immediately after "pair"_pair_style.html, "bond"_bond_style.html,
@@ -54,9 +54,9 @@ files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix.
This fix produces a per-atom array which can be accessed by various
-"output commands"_Section_howto.html#howto_15. The number of columns
-for each atom is 3, and the columns store the x,y,z forces on each
-atom. The per-atom values be accessed on any timestep.
+"output commands"_Howto_output.html. The number of columns for each
+atom is 3, and the columns store the x,y,z forces on each atom. The
+per-atom values be accessed on any timestep.
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command. This fix is not invoked during "energy
diff --git a/doc/src/fix_store_state.txt b/doc/src/fix_store_state.txt
index df694fb97b4e2dd037d41a21b1200b89d3c3594a..df05adc5b9ceb274061dab5bc7a0dbfc5cc395dd 100644
--- a/doc/src/fix_store_state.txt
+++ b/doc/src/fix_store_state.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -68,8 +68,7 @@ Define a fix that stores attributes for each atom in the group at the
time the fix is defined. If {N} is 0, then the values are never
updated, so this is a way of archiving an atom attribute at a given
time for future use in a calculation or output. See the discussion of
-"output commands"_Section_howto.html#howto_15 that take fixes as
-inputs.
+"output commands"_Howto_output.html that take fixes as inputs.
If {N} is not zero, then the attributes will be updated every {N}
steps.
@@ -108,9 +107,8 @@ fix.
If a single input is specified, this fix produces a per-atom vector.
If multiple inputs are specified, a per-atom array is produced where
the number of columns for each atom is the number of inputs. These
-can be accessed by various "output
-commands"_Section_howto.html#howto_15. The per-atom values be
-accessed on any timestep.
+can be accessed by various "output commands"_Howto_output.html. The
+per-atom values be accessed on any timestep.
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command. This fix is not invoked during "energy
diff --git a/doc/src/fix_surface_global.txt b/doc/src/fix_surface_global.txt
index b470babab72a14f2761805d4719d8bfc92165546..ade64d2056e0e23e58e3e762620077d6ada3f1f1 100644
--- a/doc/src/fix_surface_global.txt
+++ b/doc/src/fix_surface_global.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/fix_temp_berendsen.txt b/doc/src/fix_temp_berendsen.txt
index 6944860e140d8ef9c5772a340007905086b86434..c1f1626782abffb6d380b0faae983b6642d67db0 100644
--- a/doc/src/fix_temp_berendsen.txt
+++ b/doc/src/fix_temp_berendsen.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -68,8 +68,8 @@ be used on atoms that also have their temperature controlled by
another fix - e.g. by "fix nvt"_fix_nh.html or "fix
langevin"_fix_langevin.html commands.
-See "this howto section"_Section_howto.html#howto_16 of the manual for
-a discussion of different ways to compute temperature and perform
+See the "Howto thermostat"_Howto_thermostat.html doc page for a
+discussion of different ways to compute temperature and perform
thermostatting.
This fix computes a temperature each timestep. To do this, the fix
@@ -126,9 +126,9 @@ system's potential energy as part of "thermodynamic
output"_thermo_style.html.
This fix computes a global scalar which can be accessed by various
-"output commands"_Section_howto.html#howto_15. The scalar is the
-cumulative energy change due to this fix. The scalar value
-calculated by this fix is "extensive".
+"output commands"_Howto_output.html. The scalar is the cumulative
+energy change due to this fix. The scalar value calculated by this
+fix is "extensive".
This fix can ramp its target temperature over multiple runs, using the
{start} and {stop} keywords of the "run"_run.html command. See the
diff --git a/doc/src/fix_temp_csvr.txt b/doc/src/fix_temp_csvr.txt
index 4129ad73c8fdbe514592b1a33d38e509c74f6f93..e50f821bfe9d55339164064ea18a515d4ac58967 100644
--- a/doc/src/fix_temp_csvr.txt
+++ b/doc/src/fix_temp_csvr.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -76,8 +76,8 @@ normally be used on atoms that also have their temperature controlled
by another fix - e.g. by "fix nvt"_fix_nh.html or "fix
langevin"_fix_langevin.html commands.
-See "this howto section"_Section_howto.html#howto_16 of the manual for
-a discussion of different ways to compute temperature and perform
+See the "Howto thermostat"_Howto_thermostat.html doc page for a
+discussion of different ways to compute temperature and perform
thermostatting.
These fixes compute a temperature each timestep. To do this, the fix
@@ -135,9 +135,9 @@ the {start} and {stop} keywords of the "run"_run.html command. See the
These fixes are not invoked during "energy minimization"_minimize.html.
These fixes compute a global scalar which can be accessed by various
-"output commands"_Section_howto.html#howto_15. The scalar is the
-cumulative energy change due to the fix. The scalar value
-calculated by this fix is "extensive".
+"output commands"_Howto_output.html. The scalar is the cumulative
+energy change due to the fix. The scalar value calculated by this fix
+is "extensive".
[Restrictions:]
diff --git a/doc/src/fix_temp_rescale.txt b/doc/src/fix_temp_rescale.txt
index eff25297c1e295f6bcb775d65147dfac932ea956..5640317f1cf68ae357480d2b641441af9acf752a 100644
--- a/doc/src/fix_temp_rescale.txt
+++ b/doc/src/fix_temp_rescale.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -75,8 +75,8 @@ be used on atoms that also have their temperature controlled by
another fix - e.g. by "fix nvt"_fix_nh.html or "fix
langevin"_fix_langevin.html commands.
-See "this howto section"_Section_howto.html#howto_16 of the manual for
-a discussion of different ways to compute temperature and perform
+See the "Howto thermostat"_Howto_thermostat.html doc page for a
+discussion of different ways to compute temperature and perform
thermostatting.
This fix computes a temperature each timestep. To do this, the fix
@@ -133,9 +133,9 @@ system's potential energy as part of "thermodynamic
output"_thermo_style.html.
This fix computes a global scalar which can be accessed by various
-"output commands"_Section_howto.html#howto_15. The scalar is the
-cumulative energy change due to this fix. The scalar value
-calculated by this fix is "extensive".
+"output commands"_Howto_output.html. The scalar is the cumulative
+energy change due to this fix. The scalar value calculated by this
+fix is "extensive".
This fix can ramp its target temperature over multiple runs, using the
{start} and {stop} keywords of the "run"_run.html command. See the
diff --git a/doc/src/fix_temp_rescale_eff.txt b/doc/src/fix_temp_rescale_eff.txt
index f87c1a219249438c0864dba1f2880b0f1bfae9d8..83b360df858d61f1769e1f8f3e56fde72985b7ec 100644
--- a/doc/src/fix_temp_rescale_eff.txt
+++ b/doc/src/fix_temp_rescale_eff.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -51,9 +51,9 @@ system's potential energy as part of "thermodynamic
output"_thermo_style.html.
This fix computes a global scalar which can be accessed by various
-"output commands"_Section_howto.html#howto_15. The scalar is the
-cumulative energy change due to this fix. The scalar value
-calculated by this fix is "extensive".
+"output commands"_Howto_output.html. The scalar is the cumulative
+energy change due to this fix. The scalar value calculated by this
+fix is "extensive".
This fix can ramp its target temperature over multiple runs, using the
{start} and {stop} keywords of the "run"_run.html command. See the
@@ -64,8 +64,8 @@ This fix is not invoked during "energy minimization"_minimize.html.
[Restrictions:]
This fix is part of the USER-EFF package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/fix_tfmc.txt b/doc/src/fix_tfmc.txt
index 3c81d62ee0aa7c136765e59267b0a9d85f1a8333..2d4f00360761be172621dd3a2ca20566778dbf48 100644
--- a/doc/src/fix_tfmc.txt
+++ b/doc/src/fix_tfmc.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -125,8 +125,8 @@ This fix is not invoked during "energy minimization"_minimize.html.
[Restrictions:]
This fix is part of the MC package. It is only enabled if LAMMPS was
-built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+built with that package. See the "Build package"_Build_package.html
+doc page for more info.
This fix is not compatible with "fix shake"_fix_shake.html.
diff --git a/doc/src/fix_thermal_conductivity.txt b/doc/src/fix_thermal_conductivity.txt
index 0353c095b29d60e4be37a581968a70d06f778492..2ab32b25f071545cde44fc1afd97e3f2032a6486 100644
--- a/doc/src/fix_thermal_conductivity.txt
+++ b/doc/src/fix_thermal_conductivity.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -108,9 +108,9 @@ files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix.
This fix computes a global scalar which can be accessed by various
-"output commands"_Section_howto.html#howto_15. The scalar is the
-cumulative kinetic energy transferred between the bottom and middle
-of the simulation box (in the {edim} direction) is stored as a scalar
+"output commands"_Howto_output.html. The scalar is the cumulative
+kinetic energy transferred between the bottom and middle of the
+simulation box (in the {edim} direction) is stored as a scalar
quantity by this fix. This quantity is zeroed when the fix is defined
and accumulates thereafter, once every N steps. The units of the
quantity are energy; see the "units"_units.html command for details.
@@ -123,8 +123,8 @@ minimization"_minimize.html.
[Restrictions:]
This fix is part of the MISC package. It is only enabled if LAMMPS
-was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
Swaps conserve both momentum and kinetic energy, even if the masses of
the swapped atoms are not equal. Thus you should not need to
diff --git a/doc/src/fix_ti_spring.txt b/doc/src/fix_ti_spring.txt
index 191f9e7c6b8d8667b5baef112f20d16fb435a382..290ee95b9aef0f7fefb60ad34d13519450dcf659 100644
--- a/doc/src/fix_ti_spring.txt
+++ b/doc/src/fix_ti_spring.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -121,13 +121,12 @@ fix to add the energy stored in the per-atom springs to the system's
potential energy as part of "thermodynamic output"_thermo_style.html.
This fix computes a global scalar and a global vector quantities which
-can be accessed by various "output
-commands"_Section_howto.html#howto_15. The scalar is an energy which
-is the sum of the spring energy for each atom, where the per-atom
-energy is 0.5 * k * r^2. The vector has 2 positions, the first one is
-the coupling parameter lambda and the second one is the time
-derivative of lambda. The scalar and vector values calculated by this
-fix are "extensive".
+can be accessed by various "output commands"_Howto_output.html. The
+scalar is an energy which is the sum of the spring energy for each
+atom, where the per-atom energy is 0.5 * k * r^2. The vector has 2
+positions, the first one is the coupling parameter lambda and the
+second one is the time derivative of lambda. The scalar and vector
+values calculated by this fix are "extensive".
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command.
@@ -147,8 +146,8 @@ this fix.
[Restrictions:]
This fix is part of the USER-MISC package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Default:]
diff --git a/doc/src/fix_tmd.txt b/doc/src/fix_tmd.txt
index 71d8d2c7670a2956a091ed68d293064de4ffcb59..73e95ba9fe58783c8b25df7d8081ca2e8c3980f1 100644
--- a/doc/src/fix_tmd.txt
+++ b/doc/src/fix_tmd.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -90,8 +90,7 @@ For more information about TMD, see "(Schlitter1)"_#Schlitter1 and
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
-by this fix for access by various "output
-commands"_Section_howto.html#howto_15.
+by this fix for access by various "output commands"_Howto_output.html.
This fix can ramp its rho parameter over multiple runs, using the
{start} and {stop} keywords of the "run"_run.html command. See the
@@ -111,8 +110,8 @@ are not multiple competing holonomic constraints applied to the same
atoms.
To read gzipped target files, you must compile LAMMPS with the
--DLAMMPS_GZIP option - see the "Making
-LAMMPS"_Section_start.html#start_2 section of the documentation.
+-DLAMMPS_GZIP option. See the "Build settings"_Build_settings.html
+doc page for details.
[Related commands:] none
diff --git a/doc/src/fix_ttm.txt b/doc/src/fix_ttm.txt
index 48dfd254a00de377ddb027c8d8e1c77d54e209a3..85407f2466cb9aaaae417174361fbd237d7481bf 100644
--- a/doc/src/fix_ttm.txt
+++ b/doc/src/fix_ttm.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -272,18 +272,17 @@ None of the "fix_modify"_fix_modify.html options are relevant to these
fixes.
Both fixes compute 2 output quantities stored in a vector of length 2,
-which can be accessed by various "output
-commands"_Section_howto.html#howto_15. The first quantity is the
-total energy of the electronic subsystem. The second quantity is the
-energy transferred from the electronic to the atomic subsystem on that
-timestep. Note that the velocity verlet integrator applies the fix ttm
-forces to the atomic subsystem as two half-step velocity updates: one
-on the current timestep and one on the subsequent timestep.
-Consequently, the change in the atomic subsystem energy is lagged by
-half a timestep relative to the change in the electronic subsystem
-energy. As a result of this, users may notice slight fluctuations in
-the sum of the atomic and electronic subsystem energies reported at
-the end of the timestep.
+which can be accessed by various "output commands"_Howto_output.html.
+The first quantity is the total energy of the electronic
+subsystem. The second quantity is the energy transferred from the
+electronic to the atomic subsystem on that timestep. Note that the
+velocity verlet integrator applies the fix ttm forces to the atomic
+subsystem as two half-step velocity updates: one on the current
+timestep and one on the subsequent timestep. Consequently, the change
+in the atomic subsystem energy is lagged by half a timestep relative
+to the change in the electronic subsystem energy. As a result of this,
+users may notice slight fluctuations in the sum of the atomic and
+electronic subsystem energies reported at the end of the timestep.
The vector values calculated are "extensive".
@@ -296,8 +295,7 @@ of the "run"_run.html command. The fixes are not invoked during
Fix {ttm} is part of the MISC package. It is only enabled if LAMMPS
was built with that package. Fix {ttm/mod} is part of the USER-MISC
package. It is only enabled if LAMMPS was built with that package.
-See the "Making LAMMPS"_Section_start.html#start_3 section for more
-info.
+See the "Build package"_Build_package.html doc page for more info.
These fixes can only be used for 3d simulations and orthogonal
simulation boxes. You must also use periodic
diff --git a/doc/src/fix_tune_kspace.txt b/doc/src/fix_tune_kspace.txt
index 60a34a26c9c671c291ff9ee77946e43e8c0a7c62..147bb1eb3dc71792c23078312db4f00eb3c3e412 100644
--- a/doc/src/fix_tune_kspace.txt
+++ b/doc/src/fix_tune_kspace.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -79,9 +79,9 @@ minimization"_minimize.html.
[Restrictions:]
-This fix is part of the KSPACE package. It is only enabled if LAMMPS was
-built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+This fix is part of the KSPACE package. It is only enabled if LAMMPS
+was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
Do not set "neigh_modify once yes" or else this fix will never be
called. Reneighboring is required.
diff --git a/doc/src/fix_vector.txt b/doc/src/fix_vector.txt
index 47b3cfc67a2dbe667ce2af1799368b50dc741f50..e1bfbe5738073e466f78f2742ed154e13884dc81 100644
--- a/doc/src/fix_vector.txt
+++ b/doc/src/fix_vector.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -37,7 +37,7 @@ simply store them. For a single specified value, the values are
stored as a global vector of growing length. For multiple specified
values, they are stored as rows in a global array, whose number of
rows is growing. The resulting vector or array can be used by other
-"output commands"_Section_howto.html#howto_15.
+"output commands"_Howto_output.html.
One way to to use this command is to accumulate a vector that is
time-integrated using the "variable trap()"_variable.html function.
@@ -94,7 +94,7 @@ output"_thermo_style.html or other fixes such as "fix nvt"_fix_nh.html
or "fix temp/rescale"_fix_temp_rescale.html. See the doc pages for
these commands which give the IDs of these computes. Users can also
write code for their own compute styles and "add them to
-LAMMPS"_Section_modify.html.
+LAMMPS"_Modify.html.
If a value begins with "f_", a fix ID must follow which has been
previously defined in the input script. If no bracketed term is
@@ -105,7 +105,7 @@ calculated by the fix is used.
Note that some fixes only produce their values on certain timesteps,
which must be compatible with {Nevery}, else an error will result.
Users can also write code for their own fix styles and "add them to
-LAMMPS"_Section_modify.html.
+LAMMPS"_Modify.html.
If a value begins with "v_", a variable name must follow which has
been previously defined in the input script. An equal-style or
@@ -127,9 +127,8 @@ files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix.
This fix produces a global vector or global array which can be
-accessed by various "output commands"_Section_howto.html#howto_15.
-The values can only be accessed on timesteps that are multiples of
-{Nevery}.
+accessed by various "output commands"_Howto_output.html. The values
+can only be accessed on timesteps that are multiples of {Nevery}.
A vector is produced if only a single input value is specified.
An array is produced if multiple input values are specified.
diff --git a/doc/src/fix_viscosity.txt b/doc/src/fix_viscosity.txt
index f6603be624da84ba7efa8de3c62a3ff9d5074e65..d86b13d0557f52e79685a06e3196333ae7147802 100644
--- a/doc/src/fix_viscosity.txt
+++ b/doc/src/fix_viscosity.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -100,13 +100,12 @@ accurately infer a viscosity and should try increasing the Nevery
parameter.
An alternative method for calculating a viscosity is to run a NEMD
-simulation, as described in "Section
-6.13"_Section_howto.html#howto_13 of the manual. NEMD simulations
-deform the simulation box via the "fix deform"_fix_deform.html
-command. Thus they cannot be run on a charged system using a "PPPM
-solver"_kspace_style.html since PPPM does not currently support
-non-orthogonal boxes. Using fix viscosity keeps the box orthogonal;
-thus it does not suffer from this limitation.
+simulation, as described on the "Howto nemd"_Howto_nemd.html doc page.
+NEMD simulations deform the simulation box via the "fix
+deform"_fix_deform.html command. Thus they cannot be run on a charged
+system using a "PPPM solver"_kspace_style.html since PPPM does not
+currently support non-orthogonal boxes. Using fix viscosity keeps the
+box orthogonal; thus it does not suffer from this limitation.
[Restart, fix_modify, output, run start/stop, minimize info:]
@@ -115,13 +114,13 @@ files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix.
This fix computes a global scalar which can be accessed by various
-"output commands"_Section_howto.html#howto_15. The scalar is the
-cumulative momentum transferred between the bottom and middle of the
-simulation box (in the {pdim} direction) is stored as a scalar
-quantity by this fix. This quantity is zeroed when the fix is defined
-and accumulates thereafter, once every N steps. The units of the
-quantity are momentum = mass*velocity. The scalar value calculated by
-this fix is "intensive".
+"output commands"_Howto_output.html. The scalar is the cumulative
+momentum transferred between the bottom and middle of the simulation
+box (in the {pdim} direction) is stored as a scalar quantity by this
+fix. This quantity is zeroed when the fix is defined and accumulates
+thereafter, once every N steps. The units of the quantity are
+momentum = mass*velocity. The scalar value calculated by this fix is
+"intensive".
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command. This fix is not invoked during "energy
@@ -130,8 +129,8 @@ minimization"_minimize.html.
[Restrictions:]
This fix is part of the MISC package. It is only enabled if LAMMPS
-was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
Swaps conserve both momentum and kinetic energy, even if the masses of
the swapped atoms are not equal. Thus you should not need to
diff --git a/doc/src/fix_viscous.txt b/doc/src/fix_viscous.txt
index 9c30e40249a4b4febdef4e17c508766ea8a619d7..c5a3ede0b24a908ffb9ed5652af2d179400a0dd0 100644
--- a/doc/src/fix_viscous.txt
+++ b/doc/src/fix_viscous.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -82,9 +82,9 @@ easily be used as a thermostat.
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
-by this fix for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of this fix can
-be used with the {start/stop} keywords of the "run"_run.html command.
+by this fix for access by various "output commands"_Howto_output.html.
+No parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command.
The "fix_modify"_fix_modify.html {respa} option is supported by this
fix. This allows to set at which level of the "r-RESPA"_run_style.html
diff --git a/doc/src/fix_wall.txt b/doc/src/fix_wall.txt
index e814c89a0743af6b7d744ac71d62d71df5c3053d..162e32c68c8e84d0613f47312185fe58a13ec60c 100644
--- a/doc/src/fix_wall.txt
+++ b/doc/src/fix_wall.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -263,14 +263,14 @@ integrator the fix is adding its forces. Default is the outermost level.
This fix computes a global scalar energy and a global vector of
forces, which can be accessed by various "output
-commands"_Section_howto.html#howto_15. Note that the scalar energy is
-the sum of interactions with all defined walls. If you want the
-energy on a per-wall basis, you need to use multiple fix wall
-commands. The length of the vector is equal to the number of walls
-defined by the fix. Each vector value is the normal force on a
-specific wall. Note that an outward force on a wall will be a
-negative value for {lo} walls and a positive value for {hi} walls.
-The scalar and vector values calculated by this fix are "extensive".
+commands"_Howto_output.html. Note that the scalar energy is the sum
+of interactions with all defined walls. If you want the energy on a
+per-wall basis, you need to use multiple fix wall commands. The
+length of the vector is equal to the number of walls defined by the
+fix. Each vector value is the normal force on a specific wall. Note
+that an outward force on a wall will be a negative value for {lo}
+walls and a positive value for {hi} walls. The scalar and vector
+values calculated by this fix are "extensive".
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command.
@@ -288,23 +288,22 @@ option for this fix.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
diff --git a/doc/src/fix_wall_body_polygon.txt b/doc/src/fix_wall_body_polygon.txt
new file mode 100644
index 0000000000000000000000000000000000000000..45cbb2841db4e4bb8d74c24e1aa704b1a3f3da2a
--- /dev/null
+++ b/doc/src/fix_wall_body_polygon.txt
@@ -0,0 +1,104 @@
+"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
+
+fix wall/body/polygon command :h3
+
+[Syntax:]
+
+fix ID group-ID wall/body/polygon k_n c_n c_t wallstyle args keyword values ... :pre
+
+ID, group-ID are documented in "fix"_fix.html command :ulb,l
+wall/body/polygon = style name of this fix command :l
+k_n = normal repulsion strength (force/distance or pressure units) :l
+c_n = normal damping coefficient (force/distance or pressure units) :l
+c_t = tangential damping coefficient (force/distance or pressure units) :l
+wallstyle = {xplane} or {yplane} or {zplane} or {zcylinder} :l
+args = list of arguments for a particular style :l
+ {xplane} or {yplane} args = lo hi
+ lo,hi = position of lower and upper plane (distance units), either can be NULL)
+ {zcylinder} args = radius
+ radius = cylinder radius (distance units) :pre
+zero or more keyword/value pairs may be appended to args :l
+keyword = {wiggle} :l
+ {wiggle} values = dim amplitude period
+ dim = {x} or {y} or {z}
+ amplitude = size of oscillation (distance units)
+ period = time of oscillation (time units) :pre
+:ule
+
+[Examples:]
+
+fix 1 all wall/body/polygon 1000.0 20.0 5.0 xplane -10.0 10.0
+
+[Description:]
+
+This fix is for use with 2d models of body particles of style
+{rounded/polygon}. It bounds the simulation domain with wall(s). All
+particles in the group interact with the wall when they are close
+enough to touch it. The nature of the interaction between the wall
+and the polygon particles is the same as that between the polygon
+particles themselves, which is similar to a Hookean potential. See
+the "Howto body"_Howto_body.html doc page for more details on using
+body particles.
+
+The parameters {k_n}, {c_n}, {c_t} have the same meaning and units as
+those specified with the "pair_style
+body/rounded/polygon"_pair_body_rounded_polygon.html command.
+
+The {wallstyle} can be planar or cylindrical. The 2 planar options
+specify a pair of walls in a dimension. Wall positions are given by
+{lo} and {hi}. Either of the values can be specified as NULL if a
+single wall is desired. For a {zcylinder} wallstyle, the cylinder's
+axis is at x = y = 0.0, and the radius of the cylinder is specified.
+
+Optionally, the wall can be moving, if the {wiggle} keyword is
+appended.
+
+For the {wiggle} keyword, the wall oscillates sinusoidally, similar to
+the oscillations of particles which can be specified by the "fix
+move"_fix_move.html command. This is useful in packing simulations of
+particles. The arguments to the {wiggle} keyword specify a dimension
+for the motion, as well as it's {amplitude} and {period}. Note that
+if the dimension is in the plane of the wall, this is effectively a
+shearing motion. If the dimension is perpendicular to the wall, it is
+more of a shaking motion. A {zcylinder} wall can only be wiggled in
+the z dimension.
+
+Each timestep, the position of a wiggled wall in the appropriate {dim}
+is set according to this equation:
+
+position = coord + A - A cos (omega * delta) :pre
+
+where {coord} is the specified initial position of the wall, {A} is
+the {amplitude}, {omega} is 2 PI / {period}, and {delta} is the time
+elapsed since the fix was specified. The velocity of the wall is set
+to the derivative of this expression.
+
+[Restart, fix_modify, output, run start/stop, minimize info:]
+
+None of the "fix_modify"_fix_modify.html options are relevant to this
+fix. No global or per-atom quantities are stored by this fix for
+access by various "output commands"_Howto_output.html. No parameter
+of this fix can be used with the {start/stop} keywords of the
+"run"_run.html command. This fix is not invoked during "energy
+minimization"_minimize.html.
+
+[Restrictions:]
+
+This fix is part of the BODY package. It is only enabled if LAMMPS
+was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
+
+Any dimension (xy) that has a wall must be non-periodic.
+
+[Related commands:]
+
+"atom_style body"_atom_style.html, "pair_style
+body/rounded/polygon"_pair_body_rounded_polygon.html
+
+[Default:] none
diff --git a/doc/src/fix_wall_body_polyhedron.txt b/doc/src/fix_wall_body_polyhedron.txt
new file mode 100644
index 0000000000000000000000000000000000000000..231ab1f0fe7763ddbe0fa3339cc5c0e5de3813ab
--- /dev/null
+++ b/doc/src/fix_wall_body_polyhedron.txt
@@ -0,0 +1,103 @@
+"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
+
+fix wall/body/polyhedron command :h3
+
+[Syntax:]
+
+fix ID group-ID wall/body/polyhedron k_n c_n c_t wallstyle args keyword values ... :pre
+
+ID, group-ID are documented in "fix"_fix.html command :ulb,l
+wall/body/polyhedron = style name of this fix command :l
+k_n = normal repulsion strength (force/distance units or pressure units - see discussion below) :l
+c_n = normal damping coefficient (force/distance units or pressure units - see discussion below) :l
+c_t = tangential damping coefficient (force/distance units or pressure units - see discussion below) :l
+wallstyle = {xplane} or {yplane} or {zplane} or {zcylinder} :l
+args = list of arguments for a particular style :l
+ {xplane} or {yplane} args = lo hi
+ lo,hi = position of lower and upper plane (distance units), either can be NULL)
+ {zcylinder} args = radius
+ radius = cylinder radius (distance units) :pre
+zero or more keyword/value pairs may be appended to args :l
+keyword = {wiggle} :l
+ {wiggle} values = dim amplitude period
+ dim = {x} or {y} or {z}
+ amplitude = size of oscillation (distance units)
+ period = time of oscillation (time units) :pre
+:ule
+
+[Examples:]
+
+fix 1 all wall/body/polyhedron 1000.0 20.0 5.0 xplane -10.0 10.0
+
+[Description:]
+
+This fix is for use with 3d models of body particles of style
+{rounded/polyhedron}. It bounds the simulation domain with wall(s).
+All particles in the group interact with the wall when they are close
+enough to touch it. The nature of the interaction between the wall
+and the polygon particles is the same as that between the polygon
+particles themselves, which is similar to a Hookean potential. See
+the "Howto body"_Howto_body.html doc page for more details on using
+body particles.
+
+The parameters {k_n}, {c_n}, {c_t} have the same meaning and units as
+those specified with the "pair_style
+body/rounded/polyhedron"_pair_body_rounded_polyhedron.html command.
+
+The {wallstyle} can be planar or cylindrical. The 3 planar options
+specify a pair of walls in a dimension. Wall positions are given by
+{lo} and {hi}. Either of the values can be specified as NULL if a
+single wall is desired. For a {zcylinder} wallstyle, the cylinder's
+axis is at x = y = 0.0, and the radius of the cylinder is specified.
+
+Optionally, the wall can be moving, if the {wiggle} keyword is appended.
+
+For the {wiggle} keyword, the wall oscillates sinusoidally, similar to
+the oscillations of particles which can be specified by the "fix
+move"_fix_move.html command. This is useful in packing simulations of
+particles. The arguments to the {wiggle} keyword specify a dimension
+for the motion, as well as it's {amplitude} and {period}. Note that
+if the dimension is in the plane of the wall, this is effectively a
+shearing motion. If the dimension is perpendicular to the wall, it is
+more of a shaking motion. A {zcylinder} wall can only be wiggled in
+the z dimension.
+
+Each timestep, the position of a wiggled wall in the appropriate {dim}
+is set according to this equation:
+
+position = coord + A - A cos (omega * delta) :pre
+
+where {coord} is the specified initial position of the wall, {A} is
+the {amplitude}, {omega} is 2 PI / {period}, and {delta} is the time
+elapsed since the fix was specified. The velocity of the wall is set
+to the derivative of this expression.
+
+[Restart, fix_modify, output, run start/stop, minimize info:]
+
+None of the "fix_modify"_fix_modify.html options are relevant to this
+fix. No global or per-atom quantities are stored by this fix for
+access by various "output commands"_Howto_output.html. No parameter
+of this fix can be used with the {start/stop} keywords of the
+"run"_run.html command. This fix is not invoked during "energy
+minimization"_minimize.html.
+
+[Restrictions:]
+
+This fix is part of the BODY package. It is only enabled if LAMMPS
+was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
+
+Any dimension (xyz) that has a wall must be non-periodic.
+
+[Related commands:]
+
+"atom_style body"_atom_style.html, "pair_style
+body/rounded/polyhedron"_pair_body_rounded_polyhedron.html
+
+[Default:] none
diff --git a/doc/src/fix_wall_ees.txt b/doc/src/fix_wall_ees.txt
index f141a194057f30fbb940922bf04d18044c4937b4..4cc91f52227ba759280c9a7db34ef706d0c45fbd 100644
--- a/doc/src/fix_wall_ees.txt
+++ b/doc/src/fix_wall_ees.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -97,8 +97,8 @@ of using this fix in the examples/USER/misc/ees/ directory.
[Restrictions:]
This fix is part of the USER-MISC package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This fix requires that atoms be ellipsoids as defined by the
"atom_style ellipsoid"_atom_style.html command.
diff --git a/doc/src/fix_wall_gran.txt b/doc/src/fix_wall_gran.txt
index 5f1679604e365ae0c3c2b59db43331c4b4925b02..0ea5b194ebefe000653562444ba455793b0a5da4 100644
--- a/doc/src/fix_wall_gran.txt
+++ b/doc/src/fix_wall_gran.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -148,16 +148,16 @@ uninterrupted fashion.
None of the "fix_modify"_fix_modify.html options are relevant to this
fix. No global or per-atom quantities are stored by this fix for
-access by various "output commands"_Section_howto.html#howto_15. No
-parameter of this fix can be used with the {start/stop} keywords of
-the "run"_run.html command. This fix is not invoked during "energy
+access by various "output commands"_Howto_output.html. No parameter
+of this fix can be used with the {start/stop} keywords of the
+"run"_run.html command. This fix is not invoked during "energy
minimization"_minimize.html.
[Restrictions:]
This fix is part of the GRANULAR package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
Any dimension (xyz) that has a granular wall must be non-periodic.
diff --git a/doc/src/fix_wall_gran_region.txt b/doc/src/fix_wall_gran_region.txt
index 92fb042194db78bbf7d38794a4c49ee65dcbfa09..50d744b305040799044fc85f033e10078150b0f7 100644
--- a/doc/src/fix_wall_gran_region.txt
+++ b/doc/src/fix_wall_gran_region.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -180,16 +180,16 @@ region with a different region ID.
None of the "fix_modify"_fix_modify.html options are relevant to this
fix. No global or per-atom quantities are stored by this fix for
-access by various "output commands"_Section_howto.html#howto_15. No
-parameter of this fix can be used with the {start/stop} keywords of
-the "run"_run.html command. This fix is not invoked during "energy
+access by various "output commands"_Howto_output.html. No parameter
+of this fix can be used with the {start/stop} keywords of the
+"run"_run.html command. This fix is not invoked during "energy
minimization"_minimize.html.
[Restrictions:]
This fix is part of the GRANULAR package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/fix_wall_piston.txt b/doc/src/fix_wall_piston.txt
index 4d7756c237d708840fc085a27b0540bdbe35c45d..b1968e0d490c1840005bae18e77f2589799adf4b 100644
--- a/doc/src/fix_wall_piston.txt
+++ b/doc/src/fix_wall_piston.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -91,16 +91,16 @@ define the lattice spacings.
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
-by this fix for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of this fix can
-be used with the {start/stop} keywords of the "run"_run.html command.
-This fix is not invoked during "energy minimization"_minimize.html.
+by this fix for access by various "output commands"_Howto_output.html.
+No parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command. This fix is not invoked during "energy
+minimization"_minimize.html.
[Restrictions:]
This fix style is part of the SHOCK package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
The face that has the wall/piston must be boundary type 's'
(shrink-wrapped). The opposing face can be
diff --git a/doc/src/fix_wall_reflect.txt b/doc/src/fix_wall_reflect.txt
index 954ec65bf6a1c059226c1beac58bea86fab0fb84..d43cafbf0949f2706b05b3ea06f0e137ff211f15 100644
--- a/doc/src/fix_wall_reflect.txt
+++ b/doc/src/fix_wall_reflect.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -51,7 +51,7 @@ corresponding component of its velocity is flipped.
When used in conjunction with "fix nve"_fix_nve.html and "run_style
verlet"_run_style.html, the resultant time-integration algorithm is
equivalent to the primitive splitting algorithm (PSA) described by
-"Bond"_#Bond. Because each reflection event divides
+"Bond"_#Bond1. Because each reflection event divides
the corresponding timestep asymmetrically, energy conservation is only
satisfied to O(dt), rather than to O(dt^2) as it would be for
velocity-Verlet integration without reflective walls.
@@ -130,23 +130,22 @@ position = c0 + A (1 - cos(omega*delta)) :pre
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -155,10 +154,10 @@ more instructions on how to use the accelerated styles effectively.
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
-by this fix for access by various "output
-commands"_Section_howto.html#howto_15. No parameter of this fix can
-be used with the {start/stop} keywords of the "run"_run.html command.
-This fix is not invoked during "energy minimization"_minimize.html.
+by this fix for access by various "output commands"_Howto_output.html.
+No parameter of this fix can be used with the {start/stop} keywords of
+the "run"_run.html command. This fix is not invoked during "energy
+minimization"_minimize.html.
[Restrictions:]
@@ -180,5 +179,5 @@ error.
:line
-:link(Bond)
+:link(Bond1)
[(Bond)] Bond and Leimkuhler, SIAM J Sci Comput, 30, p 134 (2007).
diff --git a/doc/src/fix_wall_region.txt b/doc/src/fix_wall_region.txt
index 9700545dc909c92f4327db4a155f0da789703b8a..559a2f0d89c0cd8c00cc49be87daf53f793cf6f9 100644
--- a/doc/src/fix_wall_region.txt
+++ b/doc/src/fix_wall_region.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -156,12 +156,11 @@ integrator the fix is adding its forces. Default is the outermost level.
This fix computes a global scalar energy and a global 3-length vector
of forces, which can be accessed by various "output
-commands"_Section_howto.html#howto_15. The scalar energy is the sum
-of energy interactions for all particles interacting with the wall
-represented by the region surface. The 3 vector quantities are the
-x,y,z components of the total force acting on the wall due to the
-particles. The scalar and vector values calculated by this fix are
-"extensive".
+commands"_Howto_output.html. The scalar energy is the sum of energy
+interactions for all particles interacting with the wall represented
+by the region surface. The 3 vector quantities are the x,y,z
+components of the total force acting on the wall due to the particles.
+The scalar and vector values calculated by this fix are "extensive".
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command.
diff --git a/doc/src/fix_wall_srd.txt b/doc/src/fix_wall_srd.txt
index c465896d37578969cad9b33143d24260b097f525..3a50c45ab7592d0c7d3d16dc969423218eaee8b6 100644
--- a/doc/src/fix_wall_srd.txt
+++ b/doc/src/fix_wall_srd.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -166,9 +166,9 @@ files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix.
This fix computes a global array of values which can be accessed by
-various "output commands"_Section_howto.html#howto_15. The number of
-rows in the array is equal to the number of walls defined by the fix.
-The number of columns is 3, for the x,y,z components of force on each
+various "output commands"_Howto_output.html. The number of rows in
+the array is equal to the number of walls defined by the fix. The
+number of columns is 3, for the x,y,z components of force on each
wall.
Note that an outward normal force on a wall will be a negative value
diff --git a/doc/src/fixes.txt b/doc/src/fixes.txt
index 9510217d029b79849ad03fc8092090472936e4fe..7a45ed8086a14cdc201eea9cce5f28f80b4df00e 100644
--- a/doc/src/fixes.txt
+++ b/doc/src/fixes.txt
@@ -168,6 +168,8 @@ Fixes :h1
fix_viscosity
fix_viscous
fix_wall
+ fix_wall_body_polygon
+ fix_wall_body_polyhedron
fix_wall_ees
fix_wall_gran
fix_wall_gran_region
diff --git a/doc/src/group.txt b/doc/src/group.txt
index dddb0459e3711e526e6077318aa6ae51922b0196..847267737286c79b0d99315d20b995907082cf81 100644
--- a/doc/src/group.txt
+++ b/doc/src/group.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/group2ndx.txt b/doc/src/group2ndx.txt
index 94d188399ba6937874f1d579eb4bdf66c840ea2d..ed9bcb003a6ec590c14b70eed2bc51073b16855d 100644
--- a/doc/src/group2ndx.txt
+++ b/doc/src/group2ndx.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -54,8 +54,8 @@ This command requires that atoms have atom IDs, since this is the
information that is written to the index file.
These commands are part of the USER-COLVARS package. They are only
-enabled if LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+enabled if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/if.txt b/doc/src/if.txt
index 52fad5aea756031760c56e6e7ec4183266f9212c..513e451034da5f2752b96c4cdd81b3ec26ac58c4 100644
--- a/doc/src/if.txt
+++ b/doc/src/if.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -65,9 +65,9 @@ above.
NOTE: If a command itself requires a quoted argument (e.g. a
"print"_print.html command), then double and single quotes can be used
and nested in the usual manner, as in the examples above and below.
-See "Section 3.2"_Section_commands.html#cmd_2 of the manual for
-more details on using quotes in arguments. Only one of level of
-nesting is allowed, but that should be sufficient for most use cases.
+The "Commands parse"_Commands_parse.html doc page has more details on
+using quotes in arguments. Only one of level of nesting is allowed,
+but that should be sufficient for most use cases.
Note that by using the line continuation character "&", the if command
can be spread across many lines, though it is still a single command:
diff --git a/doc/src/improper_class2.txt b/doc/src/improper_class2.txt
index 14ec6258de654a466ec429328014f420e81cb999..704944920eceaf00f67138723c017991e2fdd10d 100644
--- a/doc/src/improper_class2.txt
+++ b/doc/src/improper_class2.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -87,31 +87,30 @@ radians internally; hence the units of M are in energy/radian^2.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This improper style can only be used if LAMMPS was built with the
-CLASS2 package. See the "Making LAMMPS"_Section_start.html#start_3
-section for more info on packages.
+CLASS2 package. See the "Build package"_Build_package.html doc
+page for more info.
[Related commands:]
diff --git a/doc/src/improper_coeff.txt b/doc/src/improper_coeff.txt
index 5c01a23ae9cda2b729894bb87a8b4108ff4a11b7..8ed65f95350a3a56eb776b5fe5ad67c3257d939d 100644
--- a/doc/src/improper_coeff.txt
+++ b/doc/src/improper_coeff.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -67,9 +67,9 @@ the style to display the formula it computes and coefficients
specified by the associated "improper_coeff"_improper_coeff.html command.
Note that there are also additional improper styles submitted by users
-which are included in the LAMMPS distribution. The list of these with
-links to the individual styles are given in the improper section of
-"this page"_Section_commands.html#cmd_5.
+which are included in the LAMMPS distribution. The full list of all
+improper styles is on the "Commands bond"_Commands_bond.html#improper
+doc page.
"improper_style none"_improper_none.html - turn off improper interactions
"improper_style hybrid"_improper_hybrid.html - define multiple styles of improper interactions :ul
diff --git a/doc/src/improper_cossq.txt b/doc/src/improper_cossq.txt
index 138a6a16503b125003b15ec1ceb394f18963e1eb..8bd02afb84b4e27dbb31f4e3f9318c83dd6cf9d4 100644
--- a/doc/src/improper_cossq.txt
+++ b/doc/src/improper_cossq.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -53,31 +53,30 @@ X0 (degrees) :ul
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This improper style can only be used if LAMMPS was built with the
-USER-MISC package. See the "Making LAMMPS"_Section_start.html#start_3
-section for more info on packages.
+USER-MISC package. See the "Build package"_Build_package.html doc
+page for more info.
[Related commands:]
diff --git a/doc/src/improper_cvff.txt b/doc/src/improper_cvff.txt
index 5f69eccc60a1d060b894c89f487d591fa1a8b0b8..d57fddc5122c737c2c0835919b3d9dc67b147c3e 100644
--- a/doc/src/improper_cvff.txt
+++ b/doc/src/improper_cvff.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -54,31 +54,30 @@ n (0,1,2,3,4,6) :ul
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This improper style can only be used if LAMMPS was built with the
-MOLECULE package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+MOLECULE package. See the "Build package"_Build_package.html doc page
+for more info.
[Related commands:]
diff --git a/doc/src/improper_distance.txt b/doc/src/improper_distance.txt
index 7d49d17c976f262d39ff642380f23aadb0701595..bfd92f57ec9261b94c5b23c045fb726139efdafa 100644
--- a/doc/src/improper_distance.txt
+++ b/doc/src/improper_distance.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -48,8 +48,8 @@ K_4 (energy/distance^4) :ul
[Restrictions:]
This improper style can only be used if LAMMPS was built with the
-USER-MISC package. See the "Making LAMMPS"_Section_start.html#start_3
-section for more info on packages.
+USER-MISC package. See the "Build package"_Build_package.html doc
+page for more info.
[Related commands:]
diff --git a/doc/src/improper_fourier.txt b/doc/src/improper_fourier.txt
index f9062da207b329cb7616ca38420e8878675252b4..8b2021dccd5ff156aaaaf671cf77b12af9f1d105 100644
--- a/doc/src/improper_fourier.txt
+++ b/doc/src/improper_fourier.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -48,31 +48,30 @@ all (integer >= 0) :ul
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[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
-section for more info on packages.
+USER_MISC package. See the "Build package"_Build_package.html doc
+page for more info.
[Related commands:]
diff --git a/doc/src/improper_harmonic.txt b/doc/src/improper_harmonic.txt
index bb17e5a641e8da1b4b92f3e1b5ecfe8245fddf1a..1e9e7172f9ca5be5bdc0f83758b364997a370835 100644
--- a/doc/src/improper_harmonic.txt
+++ b/doc/src/improper_harmonic.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -58,31 +58,30 @@ internally; hence the units of K are in energy/radian^2.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This improper style can only be used if LAMMPS was built with the
-MOLECULE package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+MOLECULE package. See the "Build package"_Build_package.html doc page
+for more info.
[Related commands:]
diff --git a/doc/src/improper_hybrid.txt b/doc/src/improper_hybrid.txt
index 0c2beaef18c07dc3cfcc8ad136a8940486bdeef8..929eec43e16e0f6fd1d4f3cb4f24097a4d672f6f 100644
--- a/doc/src/improper_hybrid.txt
+++ b/doc/src/improper_hybrid.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -55,8 +55,8 @@ types.
[Restrictions:]
This improper style can only be used if LAMMPS was built with the
-MOLECULE package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+MOLECULE package. See the "Build package"_Build_package.html doc page
+for more info.
Unlike other improper styles, the hybrid improper style does not store
improper coefficient info for individual sub-styles in a "binary
diff --git a/doc/src/improper_inversion_harmonic.txt b/doc/src/improper_inversion_harmonic.txt
index 34683ca2bb0000db8f32f9e93838f344e0287b4c..43ffdeb8e9fae741bfd2825e1a620b079c6fc39e 100644
--- a/doc/src/improper_inversion_harmonic.txt
+++ b/doc/src/improper_inversion_harmonic.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -52,8 +52,8 @@ in between.
[Restrictions:]
This improper style can only be used if LAMMPS was built with the
-USER-MOFFF package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+USER-MOFFF package. See the "Build package"_Build_package.html doc
+page for more info.
[Related commands:]
diff --git a/doc/src/improper_none.txt b/doc/src/improper_none.txt
index af9964c7437af081e5a50ba8daf4359c94882593..f97af101fcffaf64ce4dacc34bc7824e4312d185 100644
--- a/doc/src/improper_none.txt
+++ b/doc/src/improper_none.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/improper_ring.txt b/doc/src/improper_ring.txt
index c02d39247403622fe51e1ffbc4e47df43e11db77..8a2ee29e17a9c6a694d8a8f6497e93f2a5f161c0 100644
--- a/doc/src/improper_ring.txt
+++ b/doc/src/improper_ring.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -57,31 +57,30 @@ theta0 (degrees) :ul
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This improper style can only be used if LAMMPS was built with the
-USER-MISC package. See the "Making LAMMPS"_Section_start.html#start_3
-section for more info on packages.
+USER-MISC package. See the "Build package"_Build_package.html doc
+page for more info.
[Related commands:]
diff --git a/doc/src/improper_style.txt b/doc/src/improper_style.txt
index 861701590fedcfce745e2542fd7c69c943e4e5a3..ef0c524d14086488d8f360b505bf640d09e9f3ff 100644
--- a/doc/src/improper_style.txt
+++ b/doc/src/improper_style.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -60,9 +60,9 @@ specified by the associated "improper_coeff"_improper_coeff.html
command.
Note that there are also additional improper styles submitted by users
-which are included in the LAMMPS distribution. The list of these with
-links to the individual styles are given in the improper section of
-"this page"_Section_commands.html#cmd_5.
+which are included in the LAMMPS distribution. The full list of all
+improper styles is on the "Commands bond"_Commands_bond.html#improper
+doc page.
"improper_style none"_improper_none.html - turn off improper interactions
"improper_style zero"_improper_zero.html - topology but no interactions
@@ -81,10 +81,9 @@ Improper styles can only be set for atom_style choices that allow
impropers to be defined.
Most improper styles are part of the MOLECULE package. They are only
-enabled if LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
-The doc pages for individual improper potentials tell if it is part of
-a package.
+enabled if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info. The doc pages for
+individual improper potentials tell if it is part of a package.
[Related commands:]
diff --git a/doc/src/improper_umbrella.txt b/doc/src/improper_umbrella.txt
index d6df9ee6cccc8ec2f391a2583ac495caa0ad07e9..6c29ec7ac5d879befb81202bbb6883b49c0b6599 100644
--- a/doc/src/improper_umbrella.txt
+++ b/doc/src/improper_umbrella.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -22,7 +22,7 @@ improper_coeff 1 100.0 180.0 :pre
The {umbrella} improper style uses the following potential, which is
commonly referred to as a classic inversion and used in the
-"DREIDING"_Section_howto.html#howto_4 force field:
+"DREIDING"_Howto_bioFF.html force field:
:c,image(Eqs/improper_umbrella.jpg)
@@ -51,31 +51,30 @@ omega0 (degrees) :ul
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This improper style can only be used if LAMMPS was built with the
-MOLECULE package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+MOLECULE package. See the "Build package"_Build_package.html doc page
+for more info.
[Related commands:]
diff --git a/doc/src/improper_zero.txt b/doc/src/improper_zero.txt
index 2a298573d5e359ef1676519ef494526fa14a2bc7..f3f3485b57cf0c6daf81233f1432e9b43f2aeb42 100644
--- a/doc/src/improper_zero.txt
+++ b/doc/src/improper_zero.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/include.txt b/doc/src/include.txt
index 95d08db3522d8d291512e477801860f41f78004a..c11405631365e173f57589d3a11825884a4b0157 100644
--- a/doc/src/include.txt
+++ b/doc/src/include.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/info.txt b/doc/src/info.txt
index d5b5bd97b942842c03a26011d66ce7049b1c3a27..99211de4fb5745edccf401a78f2045c756dee695 100644
--- a/doc/src/info.txt
+++ b/doc/src/info.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/jump.txt b/doc/src/jump.txt
index 4e3799f7b1c48fafa179454b458c2eff588c4453..2e26d32c4047537c6ca208456636277612bed612 100644
--- a/doc/src/jump.txt
+++ b/doc/src/jump.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -40,15 +40,14 @@ lmp_g++ < in.script :pre
since the SELF option invokes the C-library rewind() call, which may
not be supported for stdin on some systems or by some MPI
implementations. This can be worked around by using the "-in
-command-line argument"_Section_start.html#start_6, e.g.
+command-line switch"_Run_options.html, e.g.
lmp_g++ -in in.script :pre
-or by using the "-var command-line
-argument"_Section_start.html#start_6 to pass the script name as a
-variable to the input script. In the latter case, a
-"variable"_variable.html called "fname" could be used in place of
-SELF, e.g.
+or by using the "-var command-line switch"_Run_options.html to pass
+the script name as a variable to the input script. In the latter
+case, a "variable"_variable.html called "fname" could be used in place
+of SELF, e.g.
lmp_g++ -var fname in.script < in.script :pre
diff --git a/doc/src/kspace_modify.txt b/doc/src/kspace_modify.txt
index 6d27bb7076344adfd81ba2a0b7242c985a3eff02..dd7b1e8deadfdd3e6defeddaa0cc85d3e4467370 100644
--- a/doc/src/kspace_modify.txt
+++ b/doc/src/kspace_modify.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -285,15 +285,15 @@ performance and accuracy in the results is obtained when these values
are different.
The {disp/auto} option controls whether the pppm/disp is allowed to
-generate PPPM parameters automatically. If set to {no}, parameters have
-to be specified using the {gewald/disp}, {mesh/disp},
-{force/disp/real} or {force/disp/kspace} keywords, or
-the code will stop with an error message. When this option is set to
-{yes}, the error message will not appear and the simulation will start.
-For a typical application, using the automatic parameter generation
-will provide simulations that are either inaccurate or slow. Using this
-option is thus not recommended. For guidelines on how to obtain good
-parameters, see the "How-To"_Section_howto.html#howto_24 discussion.
+generate PPPM parameters automatically. If set to {no}, parameters
+have to be specified using the {gewald/disp}, {mesh/disp},
+{force/disp/real} or {force/disp/kspace} keywords, or the code will
+stop with an error message. When this option is set to {yes}, the
+error message will not appear and the simulation will start. For a
+typical application, using the automatic parameter generation will
+provide simulations that are either inaccurate or slow. Using this
+option is thus not recommended. For guidelines on how to obtain good
+parameters, see the "Howto dispersion"_Howto_dispersion.html doc page.
[Restrictions:] none
diff --git a/doc/src/kspace_style.txt b/doc/src/kspace_style.txt
index 4f27c9aa78e95cb2819b65d44be17acfb53e4a6f..7e479c76a64e69a1e8116712457779c0f67b43b6 100644
--- a/doc/src/kspace_style.txt
+++ b/doc/src/kspace_style.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -145,8 +145,8 @@ speedup in the KSpace time (8x less mesh points, 2x more expensive).
However, for low relative accuracy, the staggered PPPM mesh size may
be essentially the same as for regular PPPM, which means the method
will be up to 2x slower in the KSpace time (simply 2x more expensive).
-For more details and timings, see
-"Section 5"_Section_accelerate.html.
+For more details and timings, see the "Speed tips"_Speed_tips.html doc
+page.
NOTE: Using {pppm/stagger} may not give the same increase in the
accuracy of energy and pressure as it does in forces, so some caution
@@ -161,15 +161,16 @@ similar to the {ewald/disp} style. The 1/r^6 capability means
that Lennard-Jones or Buckingham potentials can be used without a cutoff,
i.e. they become full long-range potentials.
-For these styles, you will possibly want to adjust the default choice of
-parameters by using the "kspace_modify"_kspace_modify.html command.
+For these styles, you will possibly want to adjust the default choice
+of parameters by using the "kspace_modify"_kspace_modify.html command.
This can be done by either choosing the Ewald and grid parameters, or
by specifying separate accuracies for the real and kspace
-calculations. When not making any settings, the simulation will stop with
-an error message. Further information on the influence of the parameters
-and how to choose them is described in "(Isele-Holder)"_#Isele-Holder2012,
-"(Isele-Holder2)"_#Isele-Holder2013 and the
-"How-To"_Section_howto.html#howto_24 discussion.
+calculations. When not making any settings, the simulation will stop
+with an error message. Further information on the influence of the
+parameters and how to choose them is described in
+"(Isele-Holder)"_#Isele-Holder2012,
+"(Isele-Holder2)"_#Isele-Holder2013 and the "Howto
+dispersion"_Howto_dispersion.html doc page.
:line
@@ -179,9 +180,9 @@ lo-level Makefile. This setting also changes some of the PPPM
operations (e.g. mapping charge to mesh and interpolating electric
fields to particles) to be performed in single precision. This option
can speed-up long-range calculations, particularly in parallel or on
-GPUs. The use of the -DFFT_SINGLE flag is discussed in "this
-section"_Section_start.html#start_2_4 of the manual. MSM does not
-currently support the -DFFT_SINGLE compiler switch.
+GPUs. The use of the -DFFT_SINGLE flag is discussed on the "Build
+settings"_Build_settings.html doc page. MSM does not currently support
+the -DFFT_SINGLE compiler switch.
:line
@@ -267,10 +268,9 @@ relative RMS error.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+produce the same results, except for round-off and precision issues.
More specifically, the {pppm/gpu} style performs charge assignment and
force interpolation calculations on the GPU. These processes are
@@ -286,13 +286,13 @@ The {pppm/kk} style also performs charge assignment and force
interpolation calculations on the GPU while the FFTs themselves are
calculated on the CPU in non-threaded mode.
-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"_Section_start.html#start_3 section for more info.
+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 "Build
+package"_Build_package.html doc page for more info.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -308,9 +308,9 @@ triclinic simulation cells may not yet be supported by suffix versions
of these styles.
All of the kspace styles are part of the KSPACE package. They are
-only enabled if LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info. Note that
-the KSPACE package is installed by default.
+only enabled if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info. Note that the
+KSPACE package is installed by default.
For MSM, a simulation must be 3d and one can use any combination of
periodic, non-periodic, or shrink-wrapped boundaries (specified using
diff --git a/doc/src/label.txt b/doc/src/label.txt
index c6a573141b205b7dea517f3d24881f84f06e3414..adab44188c8cc3a45cc49139e935c2e7c37a9606 100644
--- a/doc/src/label.txt
+++ b/doc/src/label.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/lammps.book b/doc/src/lammps.book
index 1f181a1bd35bb6e104127e15f66d0c82fa008e70..f1ff39d80b0c0806e1e3e4b6928f95b96abeef27 100644
--- a/doc/src/lammps.book
+++ b/doc/src/lammps.book
@@ -1,34 +1,133 @@
#HTMLDOC 1.8.28
-t pdf14 -f "../Manual.pdf" --book --toclevels 4 --no-numbered --toctitle "Table of Contents" --title --textcolor #000000 --linkcolor #0000ff --linkstyle plain --bodycolor #ffffff --size Universal --left 1.00in --right 0.50in --top 0.50in --bottom 0.50in --header .t. --header1 ... --footer ..1 --nup 1 --tocheader .t. --tocfooter ..i --portrait --color --no-pscommands --no-xrxcomments --compression=9 --jpeg=0 --fontsize 11.0 --fontspacing 1.2 --headingfont Sans --bodyfont Serif --headfootsize 11.0 --headfootfont Sans-Bold --charset iso-8859-15 --links --embedfonts --pagemode document --pagelayout single --firstpage c1 --pageeffect none --pageduration 10 --effectduration 1.0 --no-encryption --permissions all --owner-password "" --user-password "" --browserwidth 680 --no-strict --no-overflow
Manual.html
-Section_intro.html
-Section_start.html
-Section_commands.html
-Section_packages.html
-Section_accelerate.html
-accelerate_gpu.html
-accelerate_intel.html
-accelerate_kokkos.html
-accelerate_omp.html
-accelerate_opt.html
-Section_howto.html
-Section_example.html
-Section_perf.html
-Section_tools.html
-Section_modify.html
-Section_python.html
-Section_errors.html
-Section_history.html
-
-lammps_tutorials.html
-tutorial_bash_on_windows.html
-tutorial_drude.html
-tutorial_github.html
-tutorial_pylammps.html
-
-lammps_support.html
-body.html
-manifolds.html
+Intro.html
+Intro_overview.html
+Manual_version.html
+Intro_features.html
+Intro_nonfeatures.html
+Intro_opensource.html
+Intro_authors.html
+Intro_website.html
+Install.html
+Install_linux.html
+Install_mac.html
+Install_windows.html
+Install_tarball.html
+Install_git.html
+Install_svn.html
+Install_patch.html
+Build.html
+Build_cmake.html
+Build_make.html
+Build_link.html
+Build_basics.html
+Build_settings.html
+Build_package.html
+Build_extras.html
+Run_head.html
+Run_basics.html
+Run_options.html
+Run_output.html
+Run_windows.html
+Commands.html
+Commands_input.html
+Commands_parse.html
+Commands_structure.html
+Commands_category.html
+Commands_all.html
+Commands_fix.html
+Commands_compute.html
+Commands_pair.html
+Commands_bond.html
+Commands_kspace.html
+Packages.html
+Packages_standard.html
+Packages_user.html
+Packages_details.html
+Speed.html
+Speed_bench.html
+Speed_measure.html
+Speed_tips.html
+Speed_packages.html
+Speed_gpu.html
+Speed_intel.html
+Speed_kokkos.html
+Speed_omp.html
+Speed_opt.html
+Speed_compare.html
+Howto.html
+Howto_github.html
+Howto_pylammps.html
+Howto_bash.html
+Howto_restart.html
+Howto_viz.html
+Howto_multiple.html
+Howto_replica.html
+Howto_library.html
+Howto_couple.html
+Howto_output.html
+Howto_chunk.html
+Howto_2d.html
+Howto_triclinic.html
+Howto_walls.html
+Howto_nemd.html
+Howto_granular.html
+Howto_spherical.html
+Howto_dispersion.html
+Howto_temperature.html
+Howto_thermostat.html
+Howto_barostat.html
+Howto_elastic.html
+Howto_kappa.html
+Howto_viscosity.html
+Howto_diffusion.html
+Howto_bioFF.html
+Howto_tip3p.html
+Howto_tip4p.html
+Howto_spc.html
+Howto_body.html
+Howto_polarizable.html
+Howto_coreshell.html
+Howto_drude.html
+Howto_drude2.html
+Howto_manifold.html
+Howto_spins.html
+Examples.html
+Tools.html
+Modify.html
+Modify_overview.html
+Modify_contribute.html
+Modify_atom.html
+Modify_pair.html
+Modify_bond.html
+Modify_compute.html
+Modify_fix.html
+Modify_command.html
+Modify_dump.html
+Modify_kspace.html
+Modify_min.html
+Modify_region.html
+Modify_body.html
+Modify_thermo.html
+Modify_variable.html
+Python_head.html
+Python_overview.html
+Python_run.html
+Python_shlib.html
+Python_install.html
+Python_mpi.html
+Python_test.html
+Python_library.html
+Python_pylammps.html
+Python_examples.html
+Python_call.html
+Errors.html
+Errors_common.html
+Errors_bugs.html
+Errors_messages.html
+Errors_warnings.html
+Manual_build.html
lammps_commands.html
atom_modify.html
@@ -283,6 +382,8 @@ fix_vector.html
fix_viscosity.html
fix_viscous.html
fix_wall.html
+fix_wall_body_polygon.html
+fix_wall_body_polyhedron.html
fix_wall_ees.html
fix_wall_gran.html
fix_wall_gran_region.html
@@ -424,8 +525,9 @@ pair_agni.html
pair_airebo.html
pair_awpmd.html
pair_beck.html
-pair_body.html
+pair_body_nparticle.html
pair_body_rounded_polygon.html
+pair_body_rounded_polyhedron.html
pair_bop.html
pair_born.html
pair_brownian.html
diff --git a/doc/src/lammps_support.txt b/doc/src/lammps_support.txt
deleted file mode 100644
index fa460ce6c23054e8409ad9b6e5392173c0972995..0000000000000000000000000000000000000000
--- a/doc/src/lammps_support.txt
+++ /dev/null
@@ -1,7 +0,0 @@
-
-Supporting Information :h1
-
-This section of the manual contains supporting information that
-is not documenting individual commands but general concepts and
-supporting information about entities like body particles or
-manifolds.
diff --git a/doc/src/lammps_tutorials.txt b/doc/src/lammps_tutorials.txt
deleted file mode 100644
index 5ceda65b600744e9133168348bcc55ea78629bfc..0000000000000000000000000000000000000000
--- a/doc/src/lammps_tutorials.txt
+++ /dev/null
@@ -1,6 +0,0 @@
-
-Tutorials :h2
-
-The following pages contain some in-depth tutorials for
-selected topics, that did not fit into any other place
-in the manual.
diff --git a/doc/src/lattice.txt b/doc/src/lattice.txt
index 7a90df1f5d553697e7433d4b41cc4a2b241a4531..6f16dc54323ae72ec99eed888f2c1a953e124647 100644
--- a/doc/src/lattice.txt
+++ b/doc/src/lattice.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/log.txt b/doc/src/log.txt
index 92bb12e6dbccf42c9c8d1b80d587088e91bf88c7..d526158a3c6a59919fe5a6fdfcba5e5adf3e3889 100644
--- a/doc/src/log.txt
+++ b/doc/src/log.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -33,9 +33,8 @@ be a variable, so that different processors do not attempt to write to
the same log file.
The file "log.lammps" is the default log file for a LAMMPS run. The
-name of the initial log file can also be set by the command-line
-switch -log. See "Section 2.6"_Section_start.html#start_6 for
-details.
+name of the initial log file can also be set by the "-log command-line
+switch"_Run_options.html.
[Restrictions:] none
diff --git a/doc/src/mass.txt b/doc/src/mass.txt
index 4b75132ccfb63a763cb6f238201e19216b736d0a..c6939630441165e80bd0bacb0007e56fedbec7af 100644
--- a/doc/src/mass.txt
+++ b/doc/src/mass.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/min_modify.txt b/doc/src/min_modify.txt
index 73d142f5fabe4556a91064f674e62a37bed26773..9408eea167bbc49274a203b0fe4586f724e8659a 100644
--- a/doc/src/min_modify.txt
+++ b/doc/src/min_modify.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/min_style.txt b/doc/src/min_style.txt
index 245ac5864c1d41bdbce4a42568e5ee555a25bb3d..4948a34864a4424a031e86ab4ace7937c1fd09fe 100644
--- a/doc/src/min_style.txt
+++ b/doc/src/min_style.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
min_style command :h3
diff --git a/doc/src/minimize.txt b/doc/src/minimize.txt
index a3f2c5d0bf5aaa430740076b09ea39fad0b35baa..910fc7f821051bee5f28753442d479e85f7f27e7 100644
--- a/doc/src/minimize.txt
+++ b/doc/src/minimize.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/molecule.txt b/doc/src/molecule.txt
index cd9ecce42c8b8750e52389e6b48c08885a7cae3f..88c6292d8b6d3bc63f075917f38df9f9482fcbae 100644
--- a/doc/src/molecule.txt
+++ b/doc/src/molecule.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -176,9 +176,8 @@ LAMMPS uses this info to properly exclude or weight bonded pairwise
interactions between bonded atoms. See the
"special_bonds"_special_bonds.html command for more details. One
reason to list the special bond info explicitly is for the
-"thermalized Drude oscillator model"_tutorial_drude.html which treats
-the bonds between nuclear cores and Drude electrons in a different
-manner.
+"thermalized Drude oscillator model"_Howto_drude.html which treats the
+bonds between nuclear cores and Drude electrons in a different manner.
NOTE: Whether a section is required depends on how the molecule
template is used by other LAMMPS commands. For example, to add a
diff --git a/doc/src/neb.txt b/doc/src/neb.txt
index 56f075c301046d40a0e940045225d5c3019458e9..57e122fdcd53cec635f42746fd23c475f8fca7fc 100644
--- a/doc/src/neb.txt
+++ b/doc/src/neb.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -50,15 +50,14 @@ follows the discussion in these 4 papers: "(HenkelmanA)"_#HenkelmanA,
"(HenkelmanB)"_#HenkelmanB, "(Nakano)"_#Nakano3 and "(Maras)"_#Maras2.
Each replica runs on a partition of one or more processors. Processor
-partitions are defined at run-time using the -partition command-line
-switch; see "Section 2.6"_Section_start.html#start_6 of the manual.
-Note that if you have MPI installed, you can run a multi-replica
-simulation with more replicas (partitions) than you have physical
-processors, e.g you can run a 10-replica simulation on just one or two
-processors. You will simply not get the performance speed-up you
-would see with one or more physical processors per replica. See
-"Section 6.5"_Section_howto.html#howto_5 of the manual for further
-discussion.
+partitions are defined at run-time using the "-partition command-line
+switch"_Run_options.html. Note that if you have MPI installed, you
+can run a multi-replica simulation with more replicas (partitions)
+than you have physical processors, e.g you can run a 10-replica
+simulation on just one or two processors. You will simply not get the
+performance speed-up you would see with one or more physical
+processors per replica. See the "Howto replica"_Howto_replica.html
+doc page for further discussion.
NOTE: As explained below, a NEB calculation perfoms a damped dynamics
minimization across all the replicas. The minimizer uses whatever
@@ -396,8 +395,8 @@ image.
[Restrictions:]
This command can only be used if LAMMPS was built with the REPLICA
-package. See the "Making LAMMPS"_Section_start.html#start_3 section
-for more info on packages.
+package. See the "Build package"_Build_package.html doc
+page for more info.
:line
diff --git a/doc/src/neigh_modify.txt b/doc/src/neigh_modify.txt
index c4544cb29bde3ccf25b708e7d2ad552fc97e7eea..6c4218cff56589fca8b41d6c8c8ab2fa96ee2c5b 100644
--- a/doc/src/neigh_modify.txt
+++ b/doc/src/neigh_modify.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/neighbor.txt b/doc/src/neighbor.txt
index 062f79a5bbba0bc7e9042145dd03cebbf1ceebe3..3e590eaff109e524fc08986bd5275ff858a651e1 100644
--- a/doc/src/neighbor.txt
+++ b/doc/src/neighbor.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -65,8 +65,8 @@ stored in the list.
When a run is finished, counts of the number of neighbors stored in
the pairwise list and the number of times neighbor lists were built
-are printed to the screen and log file. See "this
-section"_Section_start.html#start_7 for details.
+are printed to the screen and log file. See the "Run
+output"_Run_output.html doc page for details.
[Restrictions:] none
diff --git a/doc/src/newton.txt b/doc/src/newton.txt
index a3e7f4fa91eec43b623a57f58be483f35ba982e1..fd7b5369203f25c957f62e34d9d68960fee87495 100644
--- a/doc/src/newton.txt
+++ b/doc/src/newton.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/next.txt b/doc/src/next.txt
index 08f73b896cb7ef13f74c5dd982f07d021fe44eea..aefb2ca5949f16001a1016ac94aa07984082c491 100644
--- a/doc/src/next.txt
+++ b/doc/src/next.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -70,11 +70,11 @@ incrementing is done, using a single lock file for all variables. The
next value (for each variable) is assigned to whichever processor
partition executes the command first. All processors in the partition
are assigned the same value(s). Running LAMMPS on multiple partitions
-of processors via the "-partition" command-line switch is described in
-"this section"_Section_start.html#start_6 of the manual. {Universe}-
-and {uloop}-style variables are incremented using the files
-"tmp.lammps.variable" and "tmp.lammps.variable.lock" which you will
-see in your directory during and after such a LAMMPS run.
+of processors via the "-partition command-line
+switch"_Run_options.html. {Universe}- and {uloop}-style variables are
+incremented using the files "tmp.lammps.variable" and
+"tmp.lammps.variable.lock" which you will see in your directory during
+and after such a LAMMPS run.
Here is an example of running a series of simulations using the next
command with an {index}-style variable. If this input script is named
diff --git a/doc/src/package.txt b/doc/src/package.txt
index 5c698934e857bfa31bdceac69bb3296ff76961c3..8b0581929ff10cffd2661b5268761e61a276e418 100644
--- a/doc/src/package.txt
+++ b/doc/src/package.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -33,8 +33,10 @@ args = arguments specific to the style :l
last = ID of last GPU to be used on each node
{tpa} value = Nthreads
Nthreads = # of GPU threads used per atom
- {device} value = device_type
- device_type = {kepler} or {fermi} or {cypress} or {generic}
+ {device} value = device_type or platform_id:device_type or platform_id:custom,val1,val2,val3,..,val13
+ platform_id = numerical OpenCL platform id (default: -1)
+ device_type = {kepler} or {fermi} or {cypress} or {intel} or {phi} or {generic} or {custom}
+ val1,val2,... = custom OpenCL tune parameters (see below for details)
{blocksize} value = size
size = thread block size for pair force computation
{intel} args = NPhi keyword value ...
@@ -82,6 +84,9 @@ args = arguments specific to the style :l
no = perform communication pack/unpack in non-KOKKOS mode
host = perform pack/unpack on host (e.g. with OpenMP threading)
device = perform pack/unpack on device (e.g. on GPU)
+ {gpu/direct} = {off} or {on}
+ off = do not use GPU-direct
+ on = use GPU-direct (default)
{omp} args = Nthreads keyword value ...
Nthread = # of OpenMP threads to associate with each MPI process
zero or more keyword/value pairs may be appended
@@ -96,6 +101,9 @@ args = arguments specific to the style :l
package gpu 1
package gpu 1 split 0.75
package gpu 2 split -1.0
+package gpu 1 device kepler
+package gpu 1 device 2:generic
+package gpu 1 device custom,32,4,8,256,11,128,256,128,32,64,8,128,128
package kokkos neigh half comm device
package omp 0 neigh no
package omp 4
@@ -116,8 +124,8 @@ their initialization, before a simulation is defined.
This command can also be specified from the command-line when
launching LAMMPS, using the "-pk" "command-line
-switch"_Section_start.html#start_6. The syntax is exactly the same as
-when used in an input script.
+switch"_Run_options.html. The syntax is exactly the same as when used
+in an input script.
Note that all of the accelerator packages require the package command
to be specified (except the OPT package), if the package is to be used
@@ -127,26 +135,25 @@ a default version of the command is typically invoked by other
accelerator settings.
The KOKKOS package requires a "-k on" "command-line
-switch"_Section_start.html#start_6 respectively, which invokes a
-"package kokkos" command with default settings.
+switch"_Run_options.html respectively, which invokes a "package
+kokkos" command with default settings.
For the GPU, USER-INTEL, and USER-OMP packages, if a "-sf gpu" or "-sf
-intel" or "-sf omp" "command-line switch"_Section_start.html#start_6
-is used to auto-append accelerator suffixes to various styles in the
-input script, then those switches also invoke a "package gpu",
-"package intel", or "package omp" command with default settings.
+intel" or "-sf omp" "command-line switch"_Run_options.html is used to
+auto-append accelerator suffixes to various styles in the input
+script, then those switches also invoke a "package gpu", "package
+intel", or "package omp" command with default settings.
NOTE: A package command for a particular style can be invoked multiple
-times when a simulation is setup, e.g. by the "-c on", "-k on", "-sf",
-and "-pk" "command-line switches"_Section_start.html#start_6, and by
-using this command in an input script. Each time it is used all of
-the style options are set, either to default values or to specified
-settings. I.e. settings from previous invocations do not persist
-across multiple invocations.
+times when a simulation is setup, e.g. by the "-c on, -k on, -sf, and
+-pk command-line switches"_Run_options.html, and by using this command
+in an input script. Each time it is used all of the style options are
+set, either to default values or to specified settings. I.e. settings
+from previous invocations do not persist across multiple invocations.
-See the "Section 5.3"_Section_accelerate.html#acc_3 section of the
-manual for more details about using the various accelerator packages
-for speeding up LAMMPS simulations.
+See the "Speed packages"_Speed_packages.html doc page for more details
+about using the various accelerator packages for speeding up LAMMPS
+simulations.
:line
@@ -244,12 +251,40 @@ the value can improve performance. The number of threads per atom must
be a power of 2 and currently cannot be greater than 32.
The {device} keyword can be used to tune parameters optimized for a
-specific accelerator, when using OpenCL. For CUDA, the {device}
-keyword is ignored. Currently, the device type is limited to NVIDIA
-Kepler, NVIDIA Fermi, AMD Cypress, or a generic device. More devices
-may be added later. The default device type can be specified when
-building LAMMPS with the GPU library, via settings in the
-lib/gpu/Makefile that is used.
+specific accelerator and platform when using OpenCL. OpenCL supports
+the concept of a [platform], which represents one or more devices that
+share the same driver (e.g. there would be a different platform for
+GPUs from different vendors or for CPU based accelerator support).
+In LAMMPS only one platform can be active at a time and by default
+the first platform with an accelerator is selected. This is equivalent
+to using a platform ID of -1. The platform ID is a number corresponding
+to the output of the ocl_get_devices tool. The platform ID is passed
+to the GPU library, by prefixing the {device} keyword with that number
+separated by a colon. For CUDA, the {device} keyword is ignored.
+Currently, the device tuning support is limited to NVIDIA Kepler, NVIDIA
+Fermi, AMD Cypress, Intel x86_64 CPU, Intel Xeon Phi, or a generic device.
+More devices may be added later. The default device type can be
+specified when building LAMMPS with the GPU library, via setting a
+variable in the lib/gpu/Makefile that is used.
+
+In addition, a device type {custom} is available, which is followed by
+13 comma separated numbers, which allows to set those tweakable parameters
+from the package command. It can be combined with the (colon separated)
+platform id. The individual settings are:
+
+MEM_THREADS
+THREADS_PER_ATOM
+THREADS_PER_CHARGE
+BLOCK_PAIR
+MAX_SHARED_TYPES
+BLOCK_NBOR_BUILD
+BLOCK_BIO_PAIR
+BLOCK_ELLIPSE
+WARP_SIZE
+PPPM_BLOCK_1D
+BLOCK_CELL_2D
+BLOCK_CELL_ID
+MAX_BIO_SHARED_TYPES :ul
The {blocksize} keyword allows you to tweak the number of threads used
per thread block. This number should be a multiple of 32 (for GPUs)
@@ -305,10 +340,10 @@ value via their package commands, but there is only a single global
{Nthreads} value used by OpenMP. Thus if both package commands are
invoked, you should insure the two values are consistent. If they are
not, the last one invoked will take precedence, for both packages.
-Also note that if the "-sf hybrid intel omp" "command-line
-switch"_"_Section_start.html#start_6 is used, it invokes a "package
-intel" command, followed by a "package omp" command, both with a
-setting of {Nthreads} = 0.
+Also note that if the "-sf hybrid intel omp command-line
+switch"_Run_options.html is used, it invokes a "package intel"
+command, followed by a "package omp" command, both with a setting of
+{Nthreads} = 0.
The {mode} keyword determines the precision mode to use for
computing pair style forces, either on the CPU or on the coprocessor,
@@ -447,15 +482,15 @@ The value options for all 3 keywords are {no} or {host} or {device}.
A value of {no} means to use the standard non-KOKKOS method of
packing/unpacking data for the communication. A value of {host} means
to use the host, typically a multi-core CPU, and perform the
-packing/unpacking in parallel with threads. A value of {device} means
-to use the device, typically a GPU, to perform the packing/unpacking
-operation.
+packing/unpacking in parallel with threads. A value of {device}
+means to use the device, typically a GPU, to perform the
+packing/unpacking operation.
The optimal choice for these keywords depends on the input script and
the hardware used. The {no} value is useful for verifying that the
-Kokkos-based {host} and {device} values are working correctly. It may
-also be the fastest choice when using Kokkos styles in MPI-only mode
-(i.e. with a thread count of 1).
+Kokkos-based {host} and {device} values are working correctly.
+It may also be the fastest choice when using Kokkos styles in
+MPI-only mode (i.e. with a thread count of 1).
When running on CPUs or Xeon Phi, the {host} and {device} values work
identically. When using GPUs, the {device} value will typically be
@@ -471,6 +506,18 @@ typically faster to let the host handle communication, by using the
{host} value. Using {host} instead of {no} will enable use of
multiple threads to pack/unpack communicated data.
+The {gpu/direct} keyword chooses whether GPU-direct will be used. When
+this keyword is set to {on}, buffers in GPU memory are passed directly
+through MPI send/receive calls. This reduces overhead of first copying
+the data to the host CPU. However GPU-direct is not supported on all
+systems, which can lead to segmentation faults and would require
+using a value of {off}. If LAMMPS can safely detect that GPU-direct is
+not available (currently only possible with OpenMPI v2.0.0 or later),
+then the {gpu/direct} keyword is automatically set to {off} by default.
+When the {gpu/direct} keyword is set to {off} while any of the {comm}
+keywords are set to {device}, the value for these {comm} keywords will
+be automatically changed to {host}.
+
:line
The {omp} style invokes settings associated with the use of the
@@ -535,58 +582,58 @@ 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.
The gpu style of this command can only be invoked if LAMMPS was built
-with the GPU package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+with the GPU package. See the "Build package"_Build_package.html doc
+page for more info.
The intel style of this command can only be invoked if LAMMPS was
-built with the USER-INTEL package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+built with the USER-INTEL package. See the "Build
+package"_Build_package.html doc page for more info.
The kk style of this command can only be invoked if LAMMPS was built
-with the KOKKOS package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+with the KOKKOS package. See the "Build package"_Build_package.html
+doc page for more info.
The omp style of this command can only be invoked if LAMMPS was built
-with the USER-OMP package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+with the USER-OMP package. See the "Build package"_Build_package.html
+doc page for more info.
[Related commands:]
-"suffix"_suffix.html, "-pk" "command-line
-setting"_Section_start.html#start_6
+"suffix"_suffix.html, "-pk command-line switch"_Run_options.html
[Default:]
For the GPU package, the default is Ngpu = 1 and the option defaults
are neigh = yes, newton = off, binsize = 0.0, split = 1.0, gpuID = 0
to Ngpu-1, tpa = 1, and device = not used. These settings are made
-automatically if the "-sf gpu" "command-line
-switch"_Section_start.html#start_6 is used. If it is not used, you
-must invoke the package gpu command in your input script or via the
-"-pk gpu" "command-line switch"_Section_start.html#start_6.
+automatically if the "-sf gpu" "command-line switch"_Run_options.html
+is used. If it is not used, you must invoke the package gpu command
+in your input script or via the "-pk gpu" "command-line
+switch"_Run_options.html.
For the USER-INTEL package, the default is Nphi = 1 and the option
defaults are omp = 0, mode = mixed, lrt = no, balance = -1, tpc = 4,
tptask = 240. The default ghost option is determined by the pair
style being used. This value is output to the screen in the offload
report at the end of each run. Note that all of these settings,
-except "omp" and "mode", are ignored if LAMMPS was not built with
-Xeon Phi coprocessor support. These settings are made automatically
-if the "-sf intel" "command-line switch"_Section_start.html#start_6
-is used. If it is not used, you must invoke the package intel
-command in your input script or or via the "-pk intel" "command-line
-switch"_Section_start.html#start_6.
-
-For the KOKKOS package, the option defaults neigh = full,
-neigh/qeq = full, newton = off, binsize = 0.0, and comm = device.
-These settings are made automatically by the required "-k on" "command-line
-switch"_Section_start.html#start_6. You can change them bu using the
-package kokkos command in your input script or via the "-pk kokkos"
-"command-line switch"_Section_start.html#start_6.
+except "omp" and "mode", are ignored if LAMMPS was not built with Xeon
+Phi coprocessor support. These settings are made automatically if the
+"-sf intel" "command-line switch"_Run_options.html is used. If it is
+not used, you must invoke the package intel command in your input
+script or or via the "-pk intel" "command-line
+switch"_Run_options.html.
+
+For the KOKKOS package, the option defaults neigh = full, neigh/qeq =
+full, newton = off, binsize = 0.0, and comm = device, gpu/direct = on.
+When LAMMPS can safely detect, that GPU-direct is not available, the
+default value of gpu/direct becomes "off".
+These settings are made automatically by the required "-k on"
+"command-line switch"_Run_options.html. You can change them by
+using the package kokkos command in your input script or via the
+"-pk kokkos command-line switch"_Run_options.html.
For the OMP package, the default is Nthreads = 0 and the option
defaults are neigh = yes. These settings are made automatically if
-the "-sf omp" "command-line switch"_Section_start.html#start_6 is
-used. If it is not used, you must invoke the package omp command in
-your input script or via the "-pk omp" "command-line
-switch"_Section_start.html#start_6.
+the "-sf omp" "command-line switch"_Run_options.html is used. If it
+is not used, you must invoke the package omp command in your input
+script or via the "-pk omp" "command-line switch"_Run_options.html.
diff --git a/doc/src/pair_adp.txt b/doc/src/pair_adp.txt
index 9d2a48dcbca399bc00f09458c56941cf3f622b5e..fc888ffbffa7b38779ddaa9730316c787445d3cc 100644
--- a/doc/src/pair_adp.txt
+++ b/doc/src/pair_adp.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -125,23 +125,22 @@ array tabulated with a scaling by r.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
diff --git a/doc/src/pair_agni.txt b/doc/src/pair_agni.txt
index 402e537dadf39bc5728d6001d32a0709d17e54c0..74aef4125575d02b79436b7e8c79b6c468757f0e 100644
--- a/doc/src/pair_agni.txt
+++ b/doc/src/pair_agni.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -58,23 +58,23 @@ and input files are provided in the examples/USER/misc/agni directory.
:line
Styles with {omp} suffix is functionally the same as the corresponding
-style without the suffix. They have been optimized to run faster, depending
-on your available hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated style takes the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+style without the suffix. They have been optimized to run faster,
+depending on your available hardware, as discussed on the "Speed
+packages"_Speed_packages.html doc page. The accelerated style takes
+the same arguments and should produce the same results, except for
+round-off and precision issues.
-The accelerated style is part of the USER-OMP. They are only enabled if
-LAMMPS was built with those packages. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+The accelerated style is part of the USER-OMP. They are only enabled
+if LAMMPS was built with those packages. See the "Build
+package"_Build_package.html doc page for more info.
You can specify the accelerated style 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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -96,13 +96,14 @@ This pair style can only be used via the {pair} keyword of the
[Restrictions:]
-Currently, only elemental systems are implemented. Also, the method only
-provides access to the forces and not energies or stresses. However, one
-can access the energy via thermodynamic integration of the forces as
-discussed in "(Botu3)"_#Botu2016construct. This pair style is part
-of the USER-MISC package. It is only enabled if LAMMPS was built with
-that package. See the "Making LAMMPS"_Section_start.html#start_3 section
-for more info.
+Currently, only elemental systems are implemented. Also, the method
+only provides access to the forces and not energies or
+stresses. However, one can access the energy via thermodynamic
+integration of the forces as discussed in
+"(Botu3)"_#Botu2016construct. This pair style is part of the
+USER-MISC package. It is only enabled if LAMMPS was built with that
+package. See the "Build package"_Build_package.html doc page for more
+info.
The AGNI force field files provided with LAMMPS (see the
potentials directory) are parameterized for metal "units"_units.html.
diff --git a/doc/src/pair_airebo.txt b/doc/src/pair_airebo.txt
index 1aa017f2786ac95e60556d84b5a900fcab5a1704..c090a39af756189a63728c59b4c58e369c847111 100644
--- a/doc/src/pair_airebo.txt
+++ b/doc/src/pair_airebo.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -176,23 +176,22 @@ thermo_style custom step temp epair v_REBO v_LJ v_TORSION :pre
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -213,8 +212,8 @@ These pair styles can only be used via the {pair} keyword of the
[Restrictions:]
These pair styles are part of the MANYBODY package. They are only
-enabled if LAMMPS was built with that package. See the
-"Making LAMMPS"_Section_start.html#start_3 section for more info.
+enabled if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
These pair potentials require the "newton"_newton.html setting to be
"on" for pair interactions.
diff --git a/doc/src/pair_awpmd.txt b/doc/src/pair_awpmd.txt
index fe0e3c952a759234f79234c60d825524b8984023..ec87101d0dc2fa89ed9089e13b37ca061ed3a9d9 100644
--- a/doc/src/pair_awpmd.txt
+++ b/doc/src/pair_awpmd.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/pair_beck.txt b/doc/src/pair_beck.txt
index e160f09b3d6fc5764c24bdd367d284e93db55622..af60041ff98b6a14e0bc84117a14082691a071b0 100644
--- a/doc/src/pair_beck.txt
+++ b/doc/src/pair_beck.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -51,23 +51,22 @@ Rc is used.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
diff --git a/doc/src/pair_body.txt b/doc/src/pair_body_nparticle.txt
similarity index 84%
rename from doc/src/pair_body.txt
rename to doc/src/pair_body_nparticle.txt
index 7899da832bdbf722bb1c5403dd547890bae5cdb1..158eb68ca8f4c8357167534d0e936db7c4de2cff 100644
--- a/doc/src/pair_body.txt
+++ b/doc/src/pair_body_nparticle.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -10,29 +10,28 @@ pair_style body command :h3
[Syntax:]
-pair_style body cutoff :pre
+pair_style body/nparticle cutoff :pre
cutoff = global cutoff for interactions (distance units)
[Examples:]
-pair_style body 3.0
+pair_style body/nparticle 3.0
pair_coeff * * 1.0 1.0
pair_coeff 1 1 1.0 1.5 2.5 :pre
[Description:]
-Style {body} is for use with body particles and calculates pairwise
-body/body interactions as well as interactions between body and
-point-particles. See "Section 6.14"_Section_howto.html#howto_14
-of the manual and the "body"_body.html doc page for more details on
-using body particles.
+Style {body/nparticle} is for use with body particles and calculates
+pairwise body/body interactions as well as interactions between body
+and point-particles. See the "Howto body"_Howto_body.html doc page
+for more details on using body particles.
This pair style is designed for use with the "nparticle" body style,
which is specified as an argument to the "atom-style body" command.
-See the "body"_body.html doc page for more details about the body
-styles LAMMPS supports. The "nparticle" style treats a body particle
-as a rigid body composed of N sub-particles.
+See the "Howto body"_Howto_body.html doc page for more details about
+the body styles LAMMPS supports. The "nparticle" style treats a body
+particle as a rigid body composed of N sub-particles.
The coordinates of a body particle are its center-of-mass (COM). If
the COMs of a pair of body particles are within the cutoff (global or
@@ -104,8 +103,8 @@ This pair style can only be used via the {pair} keyword of the
[Restrictions:]
This style is part of the BODY package. It is only enabled if LAMMPS
-was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_2_3 section for more info.
+was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
Defining particles to be bodies so they participate in body/body or
body/particle interactions requires the use of the "atom_style
diff --git a/doc/src/pair_body_rounded_polygon.txt b/doc/src/pair_body_rounded_polygon.txt
index b6dc2e37b5a80fce04b7b753ffb7e007c4703ae6..fc07d8faddc61a91dcba3cbcf32eb36211df8cff 100644
--- a/doc/src/pair_body_rounded_polygon.txt
+++ b/doc/src/pair_body_rounded_polygon.txt
@@ -2,18 +2,132 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
pair_style body/rounded/polygon command :h3
+[Syntax:]
+
+pair_style body/rounded/polygon c_n c_t mu delta_ua cutoff :pre
+
+c_n = normal damping coefficient
+c_t = tangential damping coefficient
+mu = normal friction coefficient during gross sliding
+delta_ua = multiple contact scaling factor
+cutoff = global separation cutoff for interactions (distance units), see below for definition :pre
+
+[Examples:]
+
+pair_style body/rounded/polygon 20.0 5.0 0.0 1.0 0.5
+pair_coeff * * 100.0 1.0
+pair_coeff 1 1 100.0 1.0 :pre
+
[Description:]
-Note: This feature is not yet implemented.
+Style {body/rounded/polygon} is for use with 2d models of body
+particles of style {rounded/polygon}. It calculates pairwise
+body/body interactions which can include body particles modeled as
+1-vertex circular disks with a specified diameter. See the "Howto
+body"_Howto_body.html doc page for more details on using body
+rounded/polygon particles.
+
+This pairwise interaction between rounded polygons is described in
+"Fraige"_#pair-Fraige, where a polygon does not have sharp corners,
+but is rounded at its vertices by circles centered on each vertex with
+a specified diameter. The edges of the polygon are defined between
+pairs of adjacent vertices. The circle diameter for each polygon is
+specified in the data file read by the "read data"_read_data.html
+command. This is a 2d discrete element model (DEM) which allows for
+multiple contact points.
+
+Note that when two particles interact, the effective surface of each
+polygon particle is displaced outward from each of its vertices and
+edges by half its circle diameter (as in the diagram below of a gray
+and yellow square particle). The interaction forces and energies
+between two particles are defined with respect to the separation of
+their respective rounded surfaces, not by the separation of the
+vertices and edges themselves.
+
+This means that the specified cutoff in the pair_style command is the
+cutoff distance, r_c, for the surface separation, \delta_n (see figure
+below). This is the distance at which two particles no longer
+interact. If r_c is specified as 0.0, then it is a contact-only
+interaction. I.e. the two particles must overlap in order to exert a
+repulsive force on each other. If r_c > 0.0, then the force between
+two particles will be attractive for surface separations from 0 to
+r_c, and repulsive once the particles overlap.
+
+Note that unlike for other pair styles, the specified cutoff is not
+the distance between the centers of two particles at which they stop
+interacting. This center-to-center distance depends on the shape and
+size of the two particles and their relative orientation. LAMMPS
+takes that into account when computing the surface separation distance
+and applying the r_c cutoff.
+
+The forces between vertex-vertex, vertex-edge, and edge-edge overlaps
+are given by:
+
+:c,image(Eqs/pair_body_rounded.jpg)
+
+:c,image(JPG/pair_body_rounded.jpg)
+
+Note that F_n and F_t are functions of the surface separation \delta_n
+= d - (R_i + R_j). In this model, when (R_i + R_j) < d < (R_i + R_j)
++ r_c, that is, 0 < \delta_n < r_c, the cohesive region of the two
+surfaces overlap and the two surfaces are attractive to each other.
+
+In "Fraige"_#pair-Fraige, the tangential friction force between two
+particles that are in contact is modeled differently prior to gross
+sliding (i.e. static friction) and during gross-sliding (kinetic
+friction). The latter takes place when the tangential deformation
+exceeds the Coulomb frictional limit. In the current implementation,
+however, we do not take into account frictional history, i.e. we do
+not keep track of how many time steps the two particles have been in
+contact nor calculate the tangential deformation. Instead, we assume
+that gross sliding takes place as soon as two particles are in
+contact.
+
+The following coefficients must be defined for each pair of atom types
+via the "pair_coeff"_pair_coeff.html command as in the examples above,
+or in the data file read by the "read_data"_read_data.html command:
+
+k_n (energy/distance^2 units)
+k_na (energy/distance^2 units) :ul
+
+Effectively, k_n and k_na are the slopes of the red lines in the plot
+above for force versus surface separation, for \delta_n < 0 and 0 <
+\delta_n < r_c respectively.
+
+[Mixing, shift, table, tail correction, restart, rRESPA info]:
+
+This pair style does not support the "pair_modify"_pair_modify.html
+mix, shift, table, and tail options.
+
+This pair style does not write its information to "binary restart
+files"_restart.html. Thus, you need to re-specify the pair_style and
+pair_coeff commands in an input script that reads a restart file.
+
+This pair style can only be used via the {pair} keyword of the
+"run_style respa"_run_style.html command. It does not support the
+{inner}, {middle}, {outer} keywords.
+
+[Restrictions:]
+
+These pair styles are part of the BODY package. They are only enabled
+if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
+
+This pair style requires the "newton"_newton.html setting to be "on"
+for pair interactions.
[Related commands:]
-"pair_style body"_pair_body.html
+"pair_coeff"_pair_coeff.html
[Default:] none
+
+:link(pair-Fraige)
+[(Fraige)] F. Y. Fraige, P. A. Langston, A. J. Matchett, J. Dodds,
+Particuology, 6, 455 (2008).
diff --git a/doc/src/pair_body_rounded_polyhedron.txt b/doc/src/pair_body_rounded_polyhedron.txt
new file mode 100644
index 0000000000000000000000000000000000000000..e650e5138ac456a405448f1476e29ec5cf7e754a
--- /dev/null
+++ b/doc/src/pair_body_rounded_polyhedron.txt
@@ -0,0 +1,129 @@
+"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
+
+pair_style body/rounded/polyhedron command :h3
+
+[Syntax:]
+
+pair_style body/rounded/polyhedron c_n c_t mu delta_ua cutoff :pre
+
+c_n = normal damping coefficient
+c_t = tangential damping coefficient
+mu = normal friction coefficient during gross sliding
+delta_ua = multiple contact scaling factor
+cutoff = global separation cutoff for interactions (distance units), see below for definition :pre
+
+[Examples:]
+
+pair_style body/rounded/polyhedron 20.0 5.0 0.0 1.0 0.5
+pair_coeff * * 100.0 1.0
+pair_coeff 1 1 100.0 1.0 :pre
+
+[Description:]
+
+Style {body/rounded/polygon} is for use with 3d models of body
+particles of style {rounded/polyhedron}. It calculates pairwise
+body/body interactions which can include body particles modeled as
+1-vertex spheres with a specified diameter. See the "Howto
+body"_Howto_body.html doc page for more details on using body
+rounded/polyhedron particles.
+
+This pairwise interaction between the rounded polyhedra is described
+in "Wang"_#pair-Wang, where a polyhedron does not have sharp corners
+and edges, but is rounded at its vertices and edges by spheres
+centered on each vertex with a specified diameter. The edges if the
+polyhedron are defined between pairs of adjacent vertices. Its faces
+are defined by a loop of edges. The sphere diameter for each polygon
+is specified in the data file read by the "read data"_read_data.html
+command. This is a discrete element model (DEM) which allows for
+multiple contact points.
+
+Note that when two particles interact, the effective surface of each
+polyhedron particle is displaced outward from each of its vertices,
+edges, and faces by half its sphere diameter. The interaction forces
+and energies between two particles are defined with respect to the
+separation of their respective rounded surfaces, not by the separation
+of the vertices, edges, and faces themselves.
+
+This means that the specified cutoff in the pair_style command is the
+cutoff distance, r_c, for the surface separation, \delta_n (see figure
+below). This is the distance at which two particles no longer
+interact. If r_c is specified as 0.0, then it is a contact-only
+interaction. I.e. the two particles must overlap in order to exert a
+repulsive force on each other. If r_c > 0.0, then the force between
+two particles will be attractive for surface separations from 0 to
+r_c, and repulsive once the particles overlap.
+
+Note that unlike for other pair styles, the specified cutoff is not
+the distance between the centers of two particles at which they stop
+interacting. This center-to-center distance depends on the shape and
+size of the two particles and their relative orientation. LAMMPS
+takes that into account when computing the surface separation distance
+and applying the r_c cutoff.
+
+The forces between vertex-vertex, vertex-edge, vertex-face, edge-edge,
+and edge-face overlaps are given by:
+
+:c,image(Eqs/pair_body_rounded.jpg)
+
+:c,image(JPG/pair_body_rounded.jpg)
+
+In "Wang"_#pair-Wang, the tangential friction force between two
+particles that are in contact is modeled differently prior to gross
+sliding (i.e. static friction) and during gross-sliding (kinetic
+friction). The latter takes place when the tangential deformation
+exceeds the Coulomb frictional limit. In the current implementation,
+however, we do not take into account frictional history, i.e. we do
+not keep track of how many time steps the two particles have been in
+contact nor calculate the tangential deformation. Instead, we assume
+that gross sliding takes place as soon as two particles are in
+contact.
+
+The following coefficients must be defined for each pair of atom types
+via the "pair_coeff"_pair_coeff.html command as in the examples above,
+or in the data file read by the "read_data"_read_data.html command:
+
+k_n (energy/distance^2 units)
+k_na (energy/distance^2 units) :ul
+
+Effectively, k_n and k_na are the slopes of the red lines in the plot
+above for force versus surface separation, for \delta_n < 0 and 0 <
+\delta_n < r_c respectively.
+
+[Mixing, shift, table, tail correction, restart, rRESPA info]:
+
+This pair style does not support the "pair_modify"_pair_modify.html
+mix, shift, table, and tail options.
+
+This pair style does not write its information to "binary restart
+files"_restart.html. Thus, you need to re-specify the pair_style and
+pair_coeff commands in an input script that reads a restart file.
+
+This pair style can only be used via the {pair} keyword of the
+"run_style respa"_run_style.html command. It does not support the
+{inner}, {middle}, {outer} keywords.
+
+[Restrictions:]
+
+These pair styles are part of the BODY package. They are only enabled
+if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
+
+This pair style requires the "newton"_newton.html setting to be "on"
+for pair interactions.
+
+[Related commands:]
+
+"pair_coeff"_pair_coeff.html
+
+[Default:] none
+
+:link(pair-Wang)
+[(Wang)] J. Wang, H. S. Yu, P. A. Langston, F. Y. Fraige, Granular
+Matter, 13, 1 (2011).
+
diff --git a/doc/src/pair_bop.txt b/doc/src/pair_bop.txt
index 2a611e4bd038a50685897244936677ba09311cb9..f9b4262f0c5f9717854e7c0bfeedefe831eeed46 100644
--- a/doc/src/pair_bop.txt
+++ b/doc/src/pair_bop.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -382,9 +382,8 @@ This pair style can only be used via the {pair} keyword of the
[Restrictions:]
These pair styles are part of the MANYBODY package. They are only
-enabled if LAMMPS was built with that package.
-See the "Making LAMMPS"_Section_start.html#start_3 section for more
-info.
+enabled if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
These pair potentials require the "newtion"_newton.html setting to be
"on" for pair interactions.
diff --git a/doc/src/pair_born.txt b/doc/src/pair_born.txt
index f867107426b04b7c4f92ddafafe75ed3687b2c16..195d3e666961c321638fe03c1cfc0c67cb2c6c96 100644
--- a/doc/src/pair_born.txt
+++ b/doc/src/pair_born.txt
@@ -3,7 +3,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -108,10 +108,10 @@ The {born/coul/dsf} style computes the Coulomb contribution with the
damped shifted force model as in the "coul/dsf"_pair_coul.html style.
Style {born/coul/long/cs} is identical to {born/coul/long} except that
-a term is added for the "core/shell model"_Section_howto.html#howto_25
-to allow charges on core and shell particles to be separated by r =
-0.0. The same correction is introduced for the {born/coul/dsf/cs}
-style which is identical to {born/coul/dsf}. And likewise for
+a term is added for the "core/shell model"_Howto_coreshell.html to
+allow charges on core and shell particles to be separated by r = 0.0.
+The same correction is introduced for the {born/coul/dsf/cs} style
+which is identical to {born/coul/dsf}. And likewise for
{born/coul/wolf/cs} style which is identical to {born/coul/wolf}.
Note that these potentials are related to the "Buckingham
@@ -145,23 +145,22 @@ pair_style command.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -194,8 +193,8 @@ respa"_run_style.html command. They do not support the {inner},
[Restrictions:]
The {born/coul/long} style is part of the KSPACE package. It is only
-enabled if LAMMPS was built with that package. See the
-"Making LAMMPS"_Section_start.html#start_3 section for more info.
+enabled if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/pair_brownian.txt b/doc/src/pair_brownian.txt
index 79b71e91c73e3d6a99b129472cea4831e6905324..52720daa23f4c67a88e7ce88b43fb23524a4eac5 100644
--- a/doc/src/pair_brownian.txt
+++ b/doc/src/pair_brownian.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -74,21 +74,21 @@ must be specified.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "this section"_Section_accelerate.html of
+hardware, as discussed in "this section"_Speed.html of
the manual. The accelerated styles take the same arguments and should
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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "this section"_Section_accelerate.html of the manual for more
+See "this section"_Speed.html of the manual for more
instructions on how to use the accelerated styles effectively.
:line
@@ -122,8 +122,8 @@ This pair style can only be used via the {pair} keyword of the
[Restrictions:]
These styles are part of the COLLOID package. They are only enabled
-if LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
Only spherical monodisperse particles are allowed for pair_style
brownian.
diff --git a/doc/src/pair_buck.txt b/doc/src/pair_buck.txt
index d18b39d5d92b0bf7882f51a3a32149ed5d9e56d6..5b1688e8687345464fb832161360f15700608320 100644
--- a/doc/src/pair_buck.txt
+++ b/doc/src/pair_buck.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -93,9 +93,8 @@ used as the cutoff for the A,C terms, and the second is the cutoff for
the Coulombic term.
Style {buck/coul/long/cs} is identical to {buck/coul/long} except that
-a term is added for the "core/shell model"_Section_howto.html#howto_25
-to allow charges on core and shell particles to be separated by r =
-0.0.
+a term is added for the "core/shell model"_Howto_coreshell.html to
+allow charges on core and shell particles to be separated by r = 0.0.
Note that these potentials are related to the "Born-Mayer-Huggins
potential"_pair_born.html.
@@ -140,23 +139,22 @@ pair_style command.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -188,8 +186,8 @@ respa"_run_style.html command. They do not support the {inner},
The {buck/coul/long} style is part of the KSPACE package. The
{buck/coul/long/cs} style is part of the CORESHELL package. They are
-only enabled if LAMMPS was built with that package. See the
-"Making LAMMPS"_Section_start.html#start_3 section for more info.
+only enabled if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/pair_buck6d_coul_gauss.txt b/doc/src/pair_buck6d_coul_gauss.txt
index 879972772ba1aceed1ebe3992725373955840ef1..4c43978fe5a44eae7d15fc21aecf5e2d2c8f780c 100644
--- a/doc/src/pair_buck6d_coul_gauss.txt
+++ b/doc/src/pair_buck6d_coul_gauss.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -122,9 +122,9 @@ to be specified in an input script that reads a restart file.
[Restrictions:]
-These styles are part of the USER-MOFFF package. They are only enabled
-if LAMMPS was built with that package. See the
-"Making LAMMPS"_Section_start.html#start_3 section for more info.
+These styles are part of the USER-MOFFF package. They are only
+enabled if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/pair_buck_long.txt b/doc/src/pair_buck_long.txt
index 05e760e1b22b44c5901f9160b9fa4f3eaaa44c5c..7f3a959ad620a39db19c466ad7012b6412740cc6 100644
--- a/doc/src/pair_buck_long.txt
+++ b/doc/src/pair_buck_long.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -102,23 +102,22 @@ global Coulombic cutoff is allowed.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -154,9 +153,9 @@ details.
[Restrictions:]
This style is part of the KSPACE package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info. Note that
-the KSPACE package is installed by default.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info. Note that the
+KSPACE package is installed by default.
[Related commands:]
diff --git a/doc/src/pair_charmm.txt b/doc/src/pair_charmm.txt
index 75a8e4bff944f8b6786f61bb50aa7eefe1e082c7..dfc87e1bcebf2c650867f24436da365ce516a40a 100644
--- a/doc/src/pair_charmm.txt
+++ b/doc/src/pair_charmm.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -184,23 +184,22 @@ the pair_style command.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -246,9 +245,9 @@ details.
All the styles with {coul/charmm} or {coul/charmmfsh} styles are part
of the MOLECULE package. All the styles with {coul/long} style are
part of the KSPACE package. They are only enabled if LAMMPS was built
-with those packages. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info. Note that
-the MOLECULE and KSPACE packages are installed by default.
+with those packages. See the "Build package"_Build_package.html doc
+page for more info. Note that the MOLECULE and KSPACE packages are
+installed by default.
[Related commands:]
diff --git a/doc/src/pair_class2.txt b/doc/src/pair_class2.txt
index 36fae5068b6e055adac9b7a2fb475e0df513968c..5fc42e78f9f9b4a34d854e30d9bd96999177252b 100644
--- a/doc/src/pair_class2.txt
+++ b/doc/src/pair_class2.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -102,23 +102,22 @@ cutoff distance.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -155,8 +154,8 @@ support the {inner}, {middle}, {outer} keywords.
[Restrictions:]
These styles are part of the CLASS2 package. They are only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/pair_coeff.txt b/doc/src/pair_coeff.txt
index fe9238f423d22af362c51940a639fbc32312fb7e..63f85f23d5e480a77ccc5f0c673cdde81d5a2d16 100644
--- a/doc/src/pair_coeff.txt
+++ b/doc/src/pair_coeff.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -111,9 +111,8 @@ Windows:
:line
The alphabetic list of pair styles defined in LAMMPS is given on the
-"pair_style"_pair_style.html doc page. They are also given in more
-compact form in the pair section of "this
-page"_Section_commands.html#cmd_5.
+"pair_style"_pair_style.html doc page. They are also listed in more
+compact form on the "Commands pair"_Commands_pair.html doc page.
Click on the style to display the formula it computes, arguments
specified in the pair_style command, and coefficients specified by the
@@ -121,15 +120,15 @@ associated "pair_coeff"_pair_coeff.html command.
Note that there are also additional pair styles (not listed on the
"pair_style"_pair_style.html doc page) submitted by users which are
-included in the LAMMPS distribution. The list of these with links to
-the individual styles are given in the pair section of "this
-page"_Section_commands.html#cmd_5.
+included in the LAMMPS distribution. The full list of all pair styles
+is on the "Commands pair"_Commands_pair.html doc page.
There are also additional accelerated pair styles (not listed on the
"pair_style"_pair_style.html doc page) included in the LAMMPS
-distribution for faster performance on CPUs and GPUs. The list of
-these with links to the individual styles are given in the pair
-section of "this page"_Section_commands.html#cmd_5.
+distribution for faster performance on CPUs, GPUs, and KNLs. The
+individual style names on the "Commands pair"_Commands_pair.html doc
+page are followed by one or more of (g,i,k,o,t) to indicate which
+accerlerated styles exist.
:line
diff --git a/doc/src/pair_colloid.txt b/doc/src/pair_colloid.txt
index 83b15b358bf532f6725853f8fc7e7b2329419ac5..e8a44e1cba7ec053e09831ee1201d074f62db215 100644
--- a/doc/src/pair_colloid.txt
+++ b/doc/src/pair_colloid.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -127,23 +127,22 @@ commands for efficiency: "neighbor multi"_neighbor.html and
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -178,8 +177,8 @@ This pair style can only be used via the {pair} keyword of the
[Restrictions:]
This style is part of the COLLOID package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
Normally, this pair style should be used with finite-size particles
which have a diameter, e.g. see the "atom_style
diff --git a/doc/src/pair_comb.txt b/doc/src/pair_comb.txt
index f5461b1cbc208ca0c5cd01583416f1821b0a6ec8..45ce3a3b7611d0847ef3aa05886d0a6dd6fb20b4 100644
--- a/doc/src/pair_comb.txt
+++ b/doc/src/pair_comb.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -112,23 +112,22 @@ nor file {ffield.comb3} with style {comb}.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -155,9 +154,9 @@ These pair styles can only be used via the {pair} keyword of the
[Restrictions:]
-These pair styles are part of the MANYBODY package. It is only enabled
-if LAMMPS was built with that package. See
-the "Making LAMMPS"_Section_start.html#start_3 section for more info.
+These pair styles are part of the MANYBODY package. It is only
+enabled if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
These pair styles requires the "newton"_newton.html setting to be "on"
for pair interactions.
diff --git a/doc/src/pair_coul.txt b/doc/src/pair_coul.txt
index aa3a008bd36f2e4b4c0f51da19390d1c8a5bb80a..bc0d76a071829dba2182fede5e1aadcc725a5759 100644
--- a/doc/src/pair_coul.txt
+++ b/doc/src/pair_coul.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -205,9 +205,9 @@ pairwise interactions within this distance are computed directly;
interactions outside that distance are computed in reciprocal space.
Style {coul/long/cs} is identical to {coul/long} except that a term is
-added for the "core/shell model"_Section_howto.html#howto_25 to allow
-charges on core and shell particles to be separated by r = 0.0. The
-same correction is introduced for the {coul/wolf/cs} style which is
+added for the "core/shell model"_Howto_coreshell.html to allow charges
+on core and shell particles to be separated by r = 0.0. The same
+correction is introduced for the {coul/wolf/cs} style which is
identical to {coul/wolf}.
Styles {tip4p/cut} and {tip4p/long} implement the coulomb part of
@@ -226,16 +226,16 @@ is to enable LAMMPS to "find" the 2 H atoms associated with each O
atom. For example, if the atom ID of an O atom in a TIP4P water
molecule is 500, then its 2 H atoms must have IDs 501 and 502.
-See the "howto section"_Section_howto.html#howto_8 for more
-information on how to use the TIP4P pair styles and lists of
-parameters to set. Note that the neighbor list cutoff for Coulomb
-interactions is effectively extended by a distance 2*qdist when using
-the TIP4P pair style, to account for the offset distance of the
-fictitious charges on O atoms in water molecules. Thus it is
-typically best in an efficiency sense to use a LJ cutoff >= Coulomb
-cutoff + 2*qdist, to shrink the size of the neighbor list. This leads
-to slightly larger cost for the long-range calculation, so you can
-test the trade-off for your model.
+See the "Howto tip4p"_Howto_tip4p.html doc page for more information
+on how to use the TIP4P pair styles and lists of parameters to set.
+Note that the neighbor list cutoff for Coulomb interactions is
+effectively extended by a distance 2*qdist when using the TIP4P pair
+style, to account for the offset distance of the fictitious charges on
+O atoms in water molecules. Thus it is typically best in an
+efficiency sense to use a LJ cutoff >= Coulomb cutoff + 2*qdist, to
+shrink the size of the neighbor list. This leads to slightly larger
+cost for the long-range calculation, so you can test the trade-off for
+your model.
:line
@@ -268,23 +268,22 @@ command.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -320,7 +319,7 @@ This pair style can only be used via the {pair} keyword of the
The {coul/long}, {coul/msm} and {tip4p/long} styles are part of the
KSPACE package. The {coul/long/cs} style is part of the CORESHELL
package. They are only enabled if LAMMPS was built with that package.
-See the "Making LAMMPS"_Section_start.html#start_3 section for more info.
+See the "Build package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/pair_coul_diel.txt b/doc/src/pair_coul_diel.txt
index f651cb4b5e4e927d6d9d230bcfe5e37d9260885f..7708287db9e476c18c13932906ba885aa2e94fa9 100644
--- a/doc/src/pair_coul_diel.txt
+++ b/doc/src/pair_coul_diel.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -67,7 +67,8 @@ The global cutoff (r_c) specified in the pair_style command is used.
[Mixing, shift, table, tail correction, restart, rRESPA info]:
-This pair style does not support parameter mixing. Coefficients must be given explicitly for each type of particle pairs.
+This pair style does not support parameter mixing. Coefficients must
+be given explicitly for each type of particle pairs.
This pair style supports the "pair_modify"_pair_modify.html shift
option for the energy of the Gauss-potential portion of the pair
@@ -86,9 +87,9 @@ This pair style can only be used via the {pair} keyword of the
[Restrictions:]
-This style is part of the "user-misc" package. It is only enabled
-if LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_2_3 section for more info.
+This style is part of the "USER-MISC" package. It is only enabled if
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/pair_coul_shield.txt b/doc/src/pair_coul_shield.txt
index 19f69688d5b6b1d3da1af094a81340cf8cab1b5d..62ac157e76cf4b78797dfc2a073d9007c7eee270 100644
--- a/doc/src/pair_coul_shield.txt
+++ b/doc/src/pair_coul_shield.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -69,9 +69,9 @@ This pair style can only be used via the {pair} keyword of the
[Restrictions:]
-This style is part of the USER-MISC package. It is only enabled
-if LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_2_3 section for more info.
+This style is part of the USER-MISC package. It is only enabled if
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/pair_cs.txt b/doc/src/pair_cs.txt
index c1084c608797863a3ecc7528cdb457298d8c3512..8bd4abed68bb8bac94116d77c575453eb0c6d717 100644
--- a/doc/src/pair_cs.txt
+++ b/doc/src/pair_cs.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -54,8 +54,8 @@ pair_coeff 1 1 480.0 0.25 0.00 1.05 0.50 :pre
These pair styles are designed to be used with the adiabatic
core/shell model of "(Mitchell and Finchham)"_#MitchellFinchham2. See
-"Section 6.25"_Section_howto.html#howto_25 of the manual for an
-overview of the model as implemented in LAMMPS.
+the "Howto coreshell"_Howto_coreshell.html doc page for an overview of
+the model as implemented in LAMMPS.
The styles with a {coul/long} term are identical to the "pair_style
born/coul/long"_pair_born.html and "pair_style
@@ -100,8 +100,8 @@ core/shell pair.
[Restrictions:]
These pair styles are part of the CORESHELL package. They are only
-enabled if LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+enabled if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/pair_dipole.txt b/doc/src/pair_dipole.txt
index 2516e5eae4d00113892dd8e97558b59ca13b97e3..dcb2448949699655f3021a860ca3112ae398d542 100644
--- a/doc/src/pair_dipole.txt
+++ b/doc/src/pair_dipole.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -186,23 +186,22 @@ type pair.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -241,12 +240,12 @@ This pair style can only be used via the {pair} keyword of the
The {lj/cut/dipole/cut}, {lj/cut/dipole/long}, and
{lj/long/dipole/long} styles are part of the DIPOLE package. They are
-only enabled if LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+only enabled if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
The {lj/sf/dipole/sf} style is part of the USER-MISC package. It is
-only enabled if LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+only enabled if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
Using dipole pair styles with {electron} "units"_units.html is not
currently supported.
diff --git a/doc/src/pair_dpd.txt b/doc/src/pair_dpd.txt
index 9e29e93430602fd485bef467602d7001c8534fab..55ae2986824e0c8baf92c5bf8cd4ba555837fdb9 100644
--- a/doc/src/pair_dpd.txt
+++ b/doc/src/pair_dpd.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -110,23 +110,22 @@ random force.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
diff --git a/doc/src/pair_dpd_fdt.txt b/doc/src/pair_dpd_fdt.txt
index 867f3f2315dcb9d908438f91710016abe4ccf9d8..4f2459588a9b317d3f92b3bc732536d10ec2dbc4 100644
--- a/doc/src/pair_dpd_fdt.txt
+++ b/doc/src/pair_dpd_fdt.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -129,31 +129,30 @@ significantly larger timesteps to be taken.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
These commands are part of the USER-DPD package. They are only
-enabled if LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+enabled if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
Pair styles {dpd/fdt} and {dpd/fdt/energy} require use of the
"comm_modify vel yes"_comm_modify.html option so that velocites are
diff --git a/doc/src/pair_dsmc.txt b/doc/src/pair_dsmc.txt
index 9e24100ab7cf4ce5d6676060370e75e3ef172aa1..adaeeb8390e07f080259009962109f909857f56b 100644
--- a/doc/src/pair_dsmc.txt
+++ b/doc/src/pair_dsmc.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -130,8 +130,8 @@ This pair style can only be used via the {pair} keyword of the
[Restrictions:]
This style is part of the MC package. It is only enabled if LAMMPS
-was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/pair_eam.txt b/doc/src/pair_eam.txt
index 03e77f53ab0f291be3054b1464d1936b057e95e6..6c3793cb61bc2ad74102e02f1f9b73c9dcf2be74 100644
--- a/doc/src/pair_eam.txt
+++ b/doc/src/pair_eam.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -371,22 +371,21 @@ are listed.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for more
+See the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
:line
@@ -414,14 +413,9 @@ The eam pair styles can only be used via the {pair} keyword of the
[Restrictions:]
-All of these styles except the {eam/cd} style are part of the MANYBODY
-package. They are only enabled if LAMMPS was built with that package.
-See the "Making LAMMPS"_Section_start.html#start_3 section for more info.
-
-The {eam/cd} style is part of the USER-MISC package and also requires
-the MANYBODY package. It is only enabled if LAMMPS was built with
-those packages. See the "Making LAMMPS"_Section_start.html#start_3
-section for more info.
+All of these styles are part of the MANYBODY package. They are only
+enabled if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/pair_edip.txt b/doc/src/pair_edip.txt
index e5b1420b5938eed1008b780fc226e1258d0c3fa5..053d43b2baeed3cd87cfb17e57aabb60335ca7d8 100644
--- a/doc/src/pair_edip.txt
+++ b/doc/src/pair_edip.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -109,23 +109,22 @@ the EDIP package.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -148,8 +147,8 @@ This pair style can only be used via the {pair} keyword of the
[Restrictions:]
This pair style can only be used if LAMMPS was built with the
-USER-MISC package. See the "Making LAMMPS"_Section_start.html#start_3
-section for more info on packages.
+USER-MISC package. See the "Build package"_Build_package.html doc
+page for more info.
This pair style requires the "newton"_newton.html setting to be "on"
for pair interactions.
diff --git a/doc/src/pair_eff.txt b/doc/src/pair_eff.txt
index ee7dc9993296b92e353961284670052624ce11b6..a665654af090af278e348dbd35e763df430cf547 100644
--- a/doc/src/pair_eff.txt
+++ b/doc/src/pair_eff.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -280,8 +280,8 @@ These pair styles can only be used via the {pair} keyword of the
These pair styles will only be enabled if LAMMPS is built with the
USER-EFF package. It will only be enabled if LAMMPS was built with
-that package. See the "Making LAMMPS"_Section_start.html#start_3
-section for more info.
+that package. See the "Build package"_Build_package.html doc page for
+more info.
These pair styles require that particles store electron attributes
such as radius, radial velocity, and radial force, as defined by the
diff --git a/doc/src/pair_eim.txt b/doc/src/pair_eim.txt
index 75ad2d4683ee64716ebc003ca5267d5733302760..5f9dcd4c5c349b5123a1539a8ee60db1a09d77b9 100644
--- a/doc/src/pair_eim.txt
+++ b/doc/src/pair_eim.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -136,23 +136,22 @@ needs.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
diff --git a/doc/src/pair_exp6_rx.txt b/doc/src/pair_exp6_rx.txt
index 7eafa235434386bcfe3438367cee1cec1852e74b..790674644d8223230329ce8c2387c9879e7670eb 100644
--- a/doc/src/pair_exp6_rx.txt
+++ b/doc/src/pair_exp6_rx.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -153,31 +153,30 @@ pair interaction.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This command is part of the USER-DPD package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/pair_extep.txt b/doc/src/pair_extep.txt
index 9a784e2501638ecda41031366b0777346115c94f..3acad1132d108f61a70bd4c336b63ee14a919601 100644
--- a/doc/src/pair_extep.txt
+++ b/doc/src/pair_extep.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/pair_gauss.txt b/doc/src/pair_gauss.txt
index f6f46a2de8ace2a7f982d305728b77f42f350ded..ef924b1ef07bffe80ba266df8b111fe8395ddb97 100644
--- a/doc/src/pair_gauss.txt
+++ b/doc/src/pair_gauss.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -84,23 +84,22 @@ is used.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-switch7_Section_start.html#start_6 when you invoke LAMMPS, or you can
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -168,8 +167,8 @@ thermo_style custom step temp epair v_occ :pre
[Restrictions:]
The {gauss/cut} style is part of the "user-misc" package. It is only
-enabled if LAMMPS is build with that package. See the "Making of
-LAMMPS"_Section_start.html#start_3 section for more info.
+enabled if LAMMPS is build with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/pair_gayberne.txt b/doc/src/pair_gayberne.txt
index c9235785866f6856ad438fb934afdcc64d4ba781..426352dc4cebe292b969fbdd5a2b119827fd8f3c 100644
--- a/doc/src/pair_gayberne.txt
+++ b/doc/src/pair_gayberne.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -133,23 +133,22 @@ pair_coeff sigma to 1.0 as well.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -185,8 +184,8 @@ This pair style can only be used via the {pair} keyword of the
[Restrictions:]
The {gayberne} style is part of the ASPHERE package. It is only
-enabled if LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+enabled if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
These pair style require that atoms store torque and a quaternion to
represent their orientation, as defined by the
diff --git a/doc/src/pair_gran.txt b/doc/src/pair_gran.txt
index d7e87af013f002a6e6472a4ae45e3f5c27fd3de5..bf759a71bc4853e2999616f9c7440183ea0b9cc4 100644
--- a/doc/src/pair_gran.txt
+++ b/doc/src/pair_gran.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -10,6 +10,7 @@ pair_style gran/hooke command :h3
pair_style gran/omp command :h3
pair_style gran/hooke/history command :h3
pair_style gran/hooke/history/omp command :h3
+pair_style gran/hooke/history/kk command :h3
pair_style gran/hertz/history command :h3
pair_style gran/hertz/history/omp command :h3
@@ -179,23 +180,22 @@ potential.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -233,8 +233,8 @@ pair/local"_compute_pair_local.html command, as {p1}, {p2}, ...,
[Restrictions:]
All the granular pair styles are part of the GRANULAR package. It is
-only enabled if LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+only enabled if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
These pair styles require that atoms store torque and angular velocity
(omega) as defined by the "atom_style"_atom_style.html. They also
diff --git a/doc/src/pair_gromacs.txt b/doc/src/pair_gromacs.txt
index ec84a2d57a13d7066fb49624cba932a425447656..6a36a036c93b2a8af88ebb62bdfac7f53dc243aa 100644
--- a/doc/src/pair_gromacs.txt
+++ b/doc/src/pair_gromacs.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -91,23 +91,22 @@ cutoff(s) specified in the pair_style command.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
diff --git a/doc/src/pair_gw.txt b/doc/src/pair_gw.txt
index 8f1251cf1f3a96aa50e8f9339a69f20b893336bb..ff85955dc006e05da8cf6fb22a8ebe8859979c09 100644
--- a/doc/src/pair_gw.txt
+++ b/doc/src/pair_gw.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -96,8 +96,8 @@ This pair style can only be used via the {pair} keyword of the
[Restrictions:]
This pair style is part of the MANYBODY package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This pair style requires the "newton"_newton.html setting to be "on"
for pair interactions.
diff --git a/doc/src/pair_hbond_dreiding.txt b/doc/src/pair_hbond_dreiding.txt
index d3cf90ec14c2172faf4eec91a5247724acc3428a..d4bdcd9258750593512a9acf727f476d7e0321de 100644
--- a/doc/src/pair_hbond_dreiding.txt
+++ b/doc/src/pair_hbond_dreiding.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -33,8 +33,8 @@ pair_coeff 1 2 hbond/dreiding/morse 3 i 3.88 1.7241379 2.9 2 9 11 90 :pre
[Description:]
The {hbond/dreiding} styles compute the Acceptor-Hydrogen-Donor (AHD)
-3-body hydrogen bond interaction for the
-"DREIDING"_Section_howto.html#howto_4 force field, given by:
+3-body hydrogen bond interaction for the "DREIDING"_Howto_bioFF.html
+force field, given by:
:c,image(Eqs/pair_hbond_dreiding.jpg)
@@ -65,8 +65,8 @@ potential for the Donor-Acceptor interactions. "(Liu)"_#Liu showed
that the Morse form gives improved results for Dendrimer simulations,
when n = 2.
-See this "howto section"_Section_howto.html#howto_4 of the manual for
-more information on the DREIDING forcefield.
+See the "Howto bioFF"_Howto_bioFF.html doc page for more information
+on the DREIDING forcefield.
NOTE: Because the Dreiding hydrogen bond potential is only one portion
of an overall force field which typically includes other pairwise
@@ -166,23 +166,22 @@ optional parameters.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
diff --git a/doc/src/pair_hybrid.txt b/doc/src/pair_hybrid.txt
index d37dedc709b82c43e6c49701f3b7916db93ef6d8..6e68e820a883184ac4c1927fd232a3ce05c048a4 100644
--- a/doc/src/pair_hybrid.txt
+++ b/doc/src/pair_hybrid.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -315,8 +315,8 @@ off C/C interaction, i.e. by setting the appropriate coefficients to
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page.
Since the {hybrid} and {hybrid/overlay} styles delegate computation to
the individual sub-styles, the suffix versions of the {hybrid} and
@@ -324,18 +324,18 @@ the individual sub-styles, the suffix versions of the {hybrid} and
to all sub-styles, if those versions exist. Otherwise the
non-accelerated version will be used.
-The individual accelerated sub-styles are part of the GPU,
-USER-OMP and OPT packages, respectively. They are only enabled if
-LAMMPS was built with those packages. See the
-"Making LAMMPS"_Section_start.html#start_3 section for more info.
+The individual accelerated sub-styles are part of the GPU, USER-OMP
+and OPT packages, respectively. They are only enabled if LAMMPS was
+built with those packages. See the "Build 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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
diff --git a/doc/src/pair_ilp_graphene_hbn.txt b/doc/src/pair_ilp_graphene_hbn.txt
index dbc9c458e2997d372b58b7aae7a87cca389c2168..02d0db7af25e6c86f6ece52e56623bf71825173a 100644
--- a/doc/src/pair_ilp_graphene_hbn.txt
+++ b/doc/src/pair_ilp_graphene_hbn.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -87,8 +87,8 @@ that reads a restart file.
[Restrictions:]
This fix is part of the USER-MISC package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This pair potential requires the newton setting to be {on} for pair
interactions.
diff --git a/doc/src/pair_kim.txt b/doc/src/pair_kim.txt
index c5d910e27c841f9d71e5e6dfd160bfce0a949b46..e1bde4f10e1b445e978185286c1fc7d0a906542d 100644
--- a/doc/src/pair_kim.txt
+++ b/doc/src/pair_kim.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -46,8 +46,8 @@ are included in the KIM library by default, in the "What is in the KIM
API source package?" section.
To use this pair style, you must first download and install the KIM
-API library from the "OpenKIM website"_https://openkim.org. The "KIM
-section of Section packages"_Section_packages.html#KIM has
+API library from the "OpenKIM website"_https://openkim.org. The KIM
+section of the "Packages details"_Packages_details.html doc page has
instructions on how to do this with a simple make command, when
building LAMMPS.
@@ -126,8 +126,8 @@ This pair style can only be used via the {pair} keyword of the
[Restrictions:]
This pair style is part of the KIM package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This current version of pair_style kim is compatible with the
kim-api package version 1.6.0 and higher.
diff --git a/doc/src/pair_kolmogorov_crespi_full.txt b/doc/src/pair_kolmogorov_crespi_full.txt
index a16d123b89abc938fe172a3a73d123c896687588..358d2168df277c2ce74e00992dfb87fe403817e5 100644
--- a/doc/src/pair_kolmogorov_crespi_full.txt
+++ b/doc/src/pair_kolmogorov_crespi_full.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -78,8 +78,8 @@ that reads a restart file.
[Restrictions:]
This fix is part of the USER-MISC package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This pair potential requires the newton setting to be {on} for pair
interactions.
diff --git a/doc/src/pair_kolmogorov_crespi_z.txt b/doc/src/pair_kolmogorov_crespi_z.txt
index 97f132eacd41e00cd4318cfde24b09e29b4a6ae1..f557e6c731db499de0820bbb39ef9aab1aa0f46a 100644
--- a/doc/src/pair_kolmogorov_crespi_z.txt
+++ b/doc/src/pair_kolmogorov_crespi_z.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -51,8 +51,8 @@ Other interactions can be set to zero using pair_style {none}.
[Restrictions:]
This fix is part of the USER-MISC package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/pair_lcbop.txt b/doc/src/pair_lcbop.txt
index 148a1d47a067c014d193b14eb3647bbe9c2cd3be..21c809bf6a2f3a5b853b2dcbbde5296ca81008e1 100644
--- a/doc/src/pair_lcbop.txt
+++ b/doc/src/pair_lcbop.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -72,8 +72,8 @@ This pair style can only be used via the {pair} keyword of the
[Restrictions:]
This pair styles is part of the MANYBODY package. It is only enabled
-if LAMMPS was built with that package. See
-the "Making LAMMPS"_Section_start.html#start_3 section for more info.
+if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This pair potential requires the "newton"_newton.html setting to be
"on" for pair interactions.
diff --git a/doc/src/pair_line_lj.txt b/doc/src/pair_line_lj.txt
index 44cfeb48e96ca4043c8e811d2950ae1243dc126a..ca5ececa5697f6cd6d90bda77e9aa62497f90f0b 100644
--- a/doc/src/pair_line_lj.txt
+++ b/doc/src/pair_line_lj.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -130,8 +130,8 @@ This pair style can only be used via the {pair} keyword of the
[Restrictions:]
This style is part of the ASPHERE package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
Defining particles to be line segments so they participate in
line/line or line/particle interactions requires the use the
diff --git a/doc/src/pair_list.txt b/doc/src/pair_list.txt
index 653e8b0c2d1635c4d10a43889af4b5bd5e99767d..9500a4c508ad061b585dd695b3fe02b7ad4324cb 100644
--- a/doc/src/pair_list.txt
+++ b/doc/src/pair_list.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -130,8 +130,8 @@ atom J (assuming the images are within the cutoff distance), but only
with the nearest image.
This style is part of the USER-MISC package. It is only enabled if
-LAMMPS is build with that package. See the "Making of
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS is build with that package. See the "Build
+package"_Build_package.html doc page on for more info.
[Related commands:]
diff --git a/doc/src/pair_lj.txt b/doc/src/pair_lj.txt
index e297d479bc3ae16d3054130ba67d9bb7fe3a0a97..b5a572618228d0b8e514e8157ad0347fc2690481 100644
--- a/doc/src/pair_lj.txt
+++ b/doc/src/pair_lj.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -185,9 +185,9 @@ distance are computed directly; interactions outside that distance are
computed in reciprocal space.
Style {lj/cut/coul/long/cs} is identical to {lj/cut/coul/long} except
-that a term is added for the "core/shell
-model"_Section_howto.html#howto_25 to allow charges on core and shell
-particles to be separated by r = 0.0.
+that a term is added for the "core/shell model"_Howto_coreshell.html
+to allow charges on core and shell particles to be separated by r =
+0.0.
Style {coul/wolf} adds a Coulombic pairwise interaction via the Wolf
summation method, described in "Wolf"_#Wolf1, given by:
@@ -223,16 +223,16 @@ is to enable LAMMPS to "find" the 2 H atoms associated with each O
atom. For example, if the atom ID of an O atom in a TIP4P water
molecule is 500, then its 2 H atoms must have IDs 501 and 502.
-See the "howto section"_Section_howto.html#howto_8 for more
-information on how to use the TIP4P pair styles and lists of
-parameters to set. Note that the neighbor list cutoff for Coulomb
-interactions is effectively extended by a distance 2*qdist when using
-the TIP4P pair style, to account for the offset distance of the
-fictitious charges on O atoms in water molecules. Thus it is
-typically best in an efficiency sense to use a LJ cutoff >= Coulomb
-cutoff + 2*qdist, to shrink the size of the neighbor list. This leads
-to slightly larger cost for the long-range calculation, so you can
-test the trade-off for your model.
+See the "Howto tip4p"_Howto_tip4p.html doc page for more information
+on how to use the TIP4P pair styles and lists of parameters to set.
+Note that the neighbor list cutoff for Coulomb interactions is
+effectively extended by a distance 2*qdist when using the TIP4P pair
+style, to account for the offset distance of the fictitious charges on
+O atoms in water molecules. Thus it is typically best in an
+efficiency sense to use a LJ cutoff >= Coulomb cutoff + 2*qdist, to
+shrink the size of the neighbor list. This leads to slightly larger
+cost for the long-range calculation, so you can test the trade-off for
+your model.
For all of the {lj/cut} pair styles, the following coefficients must
be defined for each pair of atoms types via the
@@ -269,23 +269,22 @@ pair_style command.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -327,9 +326,9 @@ See the "run_style"_run_style.html command for details.
The {lj/cut/coul/long} and {lj/cut/tip4p/long} styles are part of the
KSPACE package. The {lj/cut/tip4p/cut} style is part of the MOLECULE
package. These styles are only enabled if LAMMPS was built with those
-packages. See the "Making LAMMPS"_Section_start.html#start_3 section
-for more info. Note that the KSPACE and MOLECULE packages are
-installed by default.
+packages. See the "Build package"_Build_package.html doc page for
+more info. Note that the KSPACE and MOLECULE packages are installed
+by default.
[Related commands:]
diff --git a/doc/src/pair_lj96.txt b/doc/src/pair_lj96.txt
index 83f6ec063d4dd6476555a068a7eac6374544a3be..19369adc66d1074ce4b5410f8c634cee68860ea6 100644
--- a/doc/src/pair_lj96.txt
+++ b/doc/src/pair_lj96.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -49,23 +49,22 @@ cutoff specified in the pair_style command is used.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
diff --git a/doc/src/pair_lj_cubic.txt b/doc/src/pair_lj_cubic.txt
index 4ca8c3c141c39c9c874902f96f5178a1b1941d7a..0a56672d2861ff2d7b8555a684141d58149524b6 100644
--- a/doc/src/pair_lj_cubic.txt
+++ b/doc/src/pair_lj_cubic.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -63,23 +63,22 @@ located at rmin = 2^(1/6)*sigma. In the above example, sigma =
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
diff --git a/doc/src/pair_lj_expand.txt b/doc/src/pair_lj_expand.txt
index e0838426f637da3e3669fc4c35a17afaa6d6083b..d26c88e4f76f50db857c8510be9e6c23fdd77beb 100644
--- a/doc/src/pair_lj_expand.txt
+++ b/doc/src/pair_lj_expand.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -53,23 +53,22 @@ optional. If not specified, the global LJ cutoff is used.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
diff --git a/doc/src/pair_lj_long.txt b/doc/src/pair_lj_long.txt
index 6be4562d18849130536383878ac5acc084b20f20..2bc2b656ac7b95832c60e7304b5ccd254e04953c 100644
--- a/doc/src/pair_lj_long.txt
+++ b/doc/src/pair_lj_long.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -90,7 +90,7 @@ is to enable LAMMPS to "find" the 2 H atoms associated with each O
atom. For example, if the atom ID of an O atom in a TIP4P water
molecule is 500, then its 2 H atoms must have IDs 501 and 502.
-See the "howto section"_Section_howto.html#howto_8 for more
+See the the "Howto tip4p"_Howto_tip4p.html doc page for more
information on how to use the TIP4P pair style. Note that the
neighbor list cutoff for Coulomb interactions is effectively extended
by a distance 2*qdist when using the TIP4P pair style, to account for
@@ -156,23 +156,22 @@ specified in the pair_style command.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -210,9 +209,9 @@ different levels of the rRESPA hierarchy. See the
[Restrictions:]
These styles are part of the KSPACE package. They are only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info. Note that
-the KSPACE package is installed by default.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info. Note that the
+KSPACE package is installed by default.
[Related commands:]
diff --git a/doc/src/pair_lj_smooth.txt b/doc/src/pair_lj_smooth.txt
index b1678cad5862cf4670a80a68e7c2074337250ba9..0c66dd0f669f199f06bcb1d9878120bc1b44a070 100644
--- a/doc/src/pair_lj_smooth.txt
+++ b/doc/src/pair_lj_smooth.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -62,23 +62,22 @@ specified, the global values for Rin and Rc are used.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
diff --git a/doc/src/pair_lj_smooth_linear.txt b/doc/src/pair_lj_smooth_linear.txt
index 5f7c226cee3ccc7b83c6139bf2a6c25dd2c13468..9c509515c0d71d1f1788e49a24f9176340ff254c 100644
--- a/doc/src/pair_lj_smooth_linear.txt
+++ b/doc/src/pair_lj_smooth_linear.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -49,23 +49,22 @@ LJ cutoff specified in the pair_style command is used.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
diff --git a/doc/src/pair_lj_soft.txt b/doc/src/pair_lj_soft.txt
index 2ef133da554adf3d141e337e3c1b9f4139f72f35..9bcc83fa66fcdf39c81a0375bce48aa69bcf89d3 100644
--- a/doc/src/pair_lj_soft.txt
+++ b/doc/src/pair_lj_soft.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -207,23 +207,22 @@ directory tree, under examples/USER/fep.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -262,7 +261,7 @@ similar substyle can be used via the
All of the plain {soft} pair styles are part of the USER-FEP package.
The {long} styles also requires the KSPACE package to be installed.
They are only enabled if LAMMPS was built with those packages. See
-the "Making LAMMPS"_Section_start.html#start_3 section for more info.
+the "Build package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/pair_lubricate.txt b/doc/src/pair_lubricate.txt
index b39c7545c7e2bdbc90f72631eaadeca06cfe40c5..83a67d03006390b7031a73d03d4c35d03adc8e1d 100644
--- a/doc/src/pair_lubricate.txt
+++ b/doc/src/pair_lubricate.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -143,21 +143,21 @@ must be specified.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "this section"_Section_accelerate.html of
+hardware, as discussed in "this section"_Speed.html of
the manual. The accelerated styles take the same arguments and should
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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "this section"_Section_accelerate.html of the manual for more
+See "this section"_Speed.html of the manual for more
instructions on how to use the accelerated styles effectively.
:line
@@ -191,8 +191,8 @@ This pair style can only be used via the {pair} keyword of the
[Restrictions:]
These styles are part of the COLLOID package. They are only enabled
-if LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_2_3 section for more info.
+if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
Only spherical monodisperse particles are allowed for pair_style
lubricate.
diff --git a/doc/src/pair_lubricateU.txt b/doc/src/pair_lubricateU.txt
index 720a8539b890c917ab41aa1f0db151c0520a8280..bfc7c36013d2c7060686a20ee99440712e66fca0 100644
--- a/doc/src/pair_lubricateU.txt
+++ b/doc/src/pair_lubricateU.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -179,8 +179,8 @@ This pair style can only be used via the {pair} keyword of the
[Restrictions:]
These styles are part of the COLLOID package. They are only enabled
-if LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_2_3 section for more info.
+if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
Currently, these pair styles assume that all other types of
forces/torques on the particles have been already been computed when
diff --git a/doc/src/pair_mdf.txt b/doc/src/pair_mdf.txt
index ca06f1bf8eb12ad7b4050aaa79359f09a100e6fc..8a1551ddedf3b3ba964691798e7844693cc719ba 100644
--- a/doc/src/pair_mdf.txt
+++ b/doc/src/pair_mdf.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -148,8 +148,8 @@ See the "run_style"_run_style.html command for details.
[Restrictions:]
These pair styles can only be used if LAMMPS was built with the
-USER-MISC package. See the "Making LAMMPS"_Section_start.html#start_3
-section for more info on packages.
+USER-MISC package. See the "Build package"_Build_package.html doc
+page for more info.
[Related commands:]
diff --git a/doc/src/pair_meam.txt b/doc/src/pair_meam.txt
index c7449428bd05aa010182dc17cb2f9206b69e5303..0b1c1ac767eb987adbc0af82adbf67633f4dfef7 100644
--- a/doc/src/pair_meam.txt
+++ b/doc/src/pair_meam.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -352,14 +352,14 @@ This pair style can only be used via the {pair} keyword of the
[Restrictions:]
-The {meam} style is part of the MEAM package. It is only enabled if LAMMPS
-was built with that package, which also requires the MEAM library be
-built and linked with LAMMPS.
-The {meam/c} style is provided in the USER-MEAMC package. It is only enabled
-if LAMMPS was built with that package. In contrast to the {meam} style,
-{meam/c} does not require a separate library to be compiled and it can be
+The {meam} style is part of the MEAM package. It is only enabled if
+LAMMPS was built with that package, which also requires the MEAM
+library be built and linked with LAMMPS. The {meam/c} style is
+provided in the USER-MEAMC package. It is only enabled if LAMMPS was
+built with that package. In contrast to the {meam} style, {meam/c}
+does not require a separate library to be compiled and it can be
instantiated multiple times in a "hybrid"_pair_hybrid.html pair style.
-See the "Making LAMMPS"_Section_start.html#start_3 section for more info.
+See the "Build package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/pair_meam_spline.txt b/doc/src/pair_meam_spline.txt
index 6653b397a0cd04e7dfb56aa1f4c8df9159a9e4a9..df5db812648a9c4ff87e1e723578118d3b5075db 100644
--- a/doc/src/pair_meam_spline.txt
+++ b/doc/src/pair_meam_spline.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -106,23 +106,22 @@ MEAM files.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -148,8 +147,8 @@ This pair style requires the "newton"_newton.html setting to be "on"
for pair interactions.
This pair style is only enabled if LAMMPS was built with the USER-MISC
-package. See the "Making LAMMPS"_Section_start.html#start_3 section
-for more info.
+package. See the "Build package"_Build_package.html doc page for more
+info.
[Related commands:]
diff --git a/doc/src/pair_meam_sw_spline.txt b/doc/src/pair_meam_sw_spline.txt
index fa731799ddd450445ee07d19f4b45c7cc44cc866..2e8c26658aea1de5840ba254fbeb7029640f194a 100644
--- a/doc/src/pair_meam_sw_spline.txt
+++ b/doc/src/pair_meam_sw_spline.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -111,8 +111,9 @@ support the {inner}, {middle}, {outer} keywords.
This pair style requires the "newton"_newton.html setting to be "on"
for pair interactions.
-This pair style is only enabled if LAMMPS was built with the USER-MISC package.
-See the "Making LAMMPS"_Section_start.html#start_3 section for more info.
+This pair style is only enabled if LAMMPS was built with the USER-MISC
+package. See the "Build package"_Build_package.html doc page for more
+info.
[Related commands:]
diff --git a/doc/src/pair_meso.txt b/doc/src/pair_meso.txt
index bcdf717d68cb6d06e84422abffe278f6c382eb94..005498d8bfdd1f1080f1bc297d4b1b3f1513ba5c 100644
--- a/doc/src/pair_meso.txt
+++ b/doc/src/pair_meso.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -245,8 +245,8 @@ that reads a restart file.
The pair styles {edpd}, {mdpd}, {mdpd/rhosum} and {tdpd} are part of
the USER-MESO package. It is only enabled if LAMMPS was built with
-that package. See the "Making LAMMPS"_Section_start.html#start_3
-section for more info.
+that package. See the "Build package"_Build_package.html doc page for
+more info.
[Related commands:]
diff --git a/doc/src/pair_mgpt.txt b/doc/src/pair_mgpt.txt
index f8b0c9f0713c99856cbce64bb199ee55068bebbf..bd55d529b8177f52e0589fbf0fafc19b0b82a72d 100644
--- a/doc/src/pair_mgpt.txt
+++ b/doc/src/pair_mgpt.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -159,8 +159,8 @@ This pair style can only be used via the {pair} keyword of the
[Restrictions:]
This pair style is part of the USER-MGPT package and is only enabled
-if LAMMPS is built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+if LAMMPS is built with that package. See the "Build
+package"_Build_package.html doc page for more info.
The MGPT potentials require the "newtion"_newton.html setting to be
"on" for pair style interactions.
diff --git a/doc/src/pair_mie.txt b/doc/src/pair_mie.txt
index ad602db9f1e02cb1792acb2d1711ad0e189eacdc..818e37272bdd28f962195de66868aee119637d79 100644
--- a/doc/src/pair_mie.txt
+++ b/doc/src/pair_mie.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/pair_modify.txt b/doc/src/pair_modify.txt
index 34dbb5bc3de7acc4f89588d730dc76b407c07d8e..c043fde5a77f7bb68ed0b74dc52d516589ee88f8 100644
--- a/doc/src/pair_modify.txt
+++ b/doc/src/pair_modify.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/pair_momb.txt b/doc/src/pair_momb.txt
index 77c4f184d9380f11848bb7e0deedc719802d130d..f1989f56f49a39d66bf8242522cc07987984c9ce 100644
--- a/doc/src/pair_momb.txt
+++ b/doc/src/pair_momb.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -50,8 +50,8 @@ Rr (distance units, typically sum of atomic vdW radii) :ul
[Restrictions:]
This style is part of the USER-MISC package. It is only enabled if
-LAMMPS is built with that package. See the "Making of
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS is built with that package. See the "Build
+package"_Build_package.html doc page on for more info.
[Related commands:]
diff --git a/doc/src/pair_morse.txt b/doc/src/pair_morse.txt
index 3eb5ac5afe5b8cb089d5dea24ed02cdea1ec0eec..68894f691384d7445196aa4783dbb882964d6b3f 100644
--- a/doc/src/pair_morse.txt
+++ b/doc/src/pair_morse.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -101,23 +101,22 @@ cutoff is used.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -149,12 +148,12 @@ These pair styles can only be used via the {pair} keyword of the
[Restrictions:]
The {morse/smooth/linear} pair style is only enabled if LAMMPS was
-built with the USER-MISC package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+built with the USER-MISC package. See the "Build
+package"_Build_package.html doc page for more info.
The {morse/soft} pair style is only enabled if LAMMPS was built with
-the USER-FEP package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+the USER-FEP package. See the "Build package"_Build_package.html doc
+page for more info.
[Related commands:]
diff --git a/doc/src/pair_multi_lucy.txt b/doc/src/pair_multi_lucy.txt
index 38fd1ede4aa2201cb8e2cb2733877272f4b91e5c..0b3a430417370765db40d4ef682f70040ddb1863 100644
--- a/doc/src/pair_multi_lucy.txt
+++ b/doc/src/pair_multi_lucy.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -177,8 +177,8 @@ This pair style can only be used via the {pair} keyword of the
[Restrictions:]
This command is part of the USER-DPD package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/pair_multi_lucy_rx.txt b/doc/src/pair_multi_lucy_rx.txt
index 57abcf4a4c30c904b55cd07464ca60118ca13d3c..819a15b6244bb557c3d1b2f43f19aac2d8c8ec51 100644
--- a/doc/src/pair_multi_lucy_rx.txt
+++ b/doc/src/pair_multi_lucy_rx.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -204,31 +204,30 @@ This pair style can only be used via the {pair} keyword of the
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This command is part of the USER-DPD package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/pair_nb3b_harmonic.txt b/doc/src/pair_nb3b_harmonic.txt
index 2395707fb45b63425456a1ca612895b90bc289c8..6a119d74e160da95d9a61e522e6c87d75ad1627d 100644
--- a/doc/src/pair_nb3b_harmonic.txt
+++ b/doc/src/pair_nb3b_harmonic.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -92,31 +92,30 @@ a particular simulation; LAMMPS ignores those entries.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This pair style can only be used if LAMMPS was built with the MANYBODY
-package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+package. See the "Build package"_Build_package.html doc page for more
+info.
[Related commands:]
diff --git a/doc/src/pair_nm.txt b/doc/src/pair_nm.txt
index 81cea1a38d4a255b6fdd01d080cecc67602c3a89..a42dfa3c98a632e2decfc4564940501957be9cf5 100644
--- a/doc/src/pair_nm.txt
+++ b/doc/src/pair_nm.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -133,29 +133,28 @@ the "run_style respa"_run_style.html command. They do not support the
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
[Restrictions:]
These pair styles are part of the MISC package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/pair_none.txt b/doc/src/pair_none.txt
index f4e9525198413d49fe26c94ce2795ea12d826d9f..960dc05d97be7d7dda8889bb129d348c9578f374 100644
--- a/doc/src/pair_none.txt
+++ b/doc/src/pair_none.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/pair_oxdna.txt b/doc/src/pair_oxdna.txt
index f272d15a8680d6499df5f7164186789426589413..b24e3c07dfad96f51a4d74dccf885b525f502427 100644
--- a/doc/src/pair_oxdna.txt
+++ b/doc/src/pair_oxdna.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -82,8 +82,8 @@ The preprint version of the article can be found "here"_PDF/USER-CGDNA.pdf.
[Restrictions:]
These pair styles can only be used if LAMMPS was built with the
-USER-CGDNA package and the MOLECULE and ASPHERE package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+USER-CGDNA package and the MOLECULE and ASPHERE package. See the
+"Build package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/pair_oxdna2.txt b/doc/src/pair_oxdna2.txt
index 1b55031b2c97dc8c935c0ddb83a567f24d64ab6f..c5662abdeb9dbfc49959af673d3f54992c1d9b67 100644
--- a/doc/src/pair_oxdna2.txt
+++ b/doc/src/pair_oxdna2.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -88,8 +88,8 @@ The preprint version of the article can be found "here"_PDF/USER-CGDNA.pdf.
[Restrictions:]
These pair styles can only be used if LAMMPS was built with the
-USER-CGDNA package and the MOLECULE and ASPHERE package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
+USER-CGDNA package and the MOLECULE and ASPHERE package. See the
+"Build package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/pair_peri.txt b/doc/src/pair_peri.txt
index deca093e3bb1cebb7183f9bb7b8b0df866c09df8..b6baa4edc5790ef45d0f56264b1d2d240b8c2b2a 100644
--- a/doc/src/pair_peri.txt
+++ b/doc/src/pair_peri.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -139,23 +139,22 @@ details please see the description in "(Mtchell2011a)".
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -183,8 +182,8 @@ These pair styles can only be used via the {pair} keyword of the
[Restrictions:]
All of these styles are part of the PERI package. They are only
-enabled if LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+enabled if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/pair_polymorphic.txt b/doc/src/pair_polymorphic.txt
index c088e8bb2242918fe221ab1241cba70129d6c5f7..7460044043754ae55519a714cbb91396b1fbabc9 100644
--- a/doc/src/pair_polymorphic.txt
+++ b/doc/src/pair_polymorphic.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -191,8 +191,8 @@ input script. If using read_data, atomic masses must be defined in the
atomic structure data file.
This pair style is part of the MANYBODY package. It is only enabled if
-LAMMPS was built with that package. See the
-"Making LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This pair potential requires the "newtion"_newton.html setting to be
"on" for pair interactions.
diff --git a/doc/src/pair_python.txt b/doc/src/pair_python.txt
index 2f8ed7a27c6702b9e80a82d0a14201f714430bd7..23da86fc495a6daabdee6048cc4d8dcb72525b6b 100644
--- a/doc/src/pair_python.txt
+++ b/doc/src/pair_python.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -204,8 +204,8 @@ This pair style can only be used via the {pair} keyword of the
[Restrictions:]
This pair style is part of the PYTHON package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/pair_quip.txt b/doc/src/pair_quip.txt
index 9436b0c4ed1f71b78d18880d411e64855e727aca..1f794d0c84b87d72dbbcbed8603cdeca00c9e526 100644
--- a/doc/src/pair_quip.txt
+++ b/doc/src/pair_quip.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -74,8 +74,8 @@ This pair style can only be used via the {pair} keyword of the
[Restrictions:]
This pair style is part of the USER-QUIP package. It is only enabled
-if LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
QUIP potentials are parametrized in electron-volts and Angstroms and
therefore should be used with LAMMPS metal "units"_units.html.
diff --git a/doc/src/pair_reax.txt b/doc/src/pair_reax.txt
index 1d13f937061c95963165efc936a680ca14415147..a3b84955cd058937fd28cb84732656e2f3f055ef 100644
--- a/doc/src/pair_reax.txt
+++ b/doc/src/pair_reax.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/pair_reaxc.txt b/doc/src/pair_reaxc.txt
index 39759b3111825077e3ee0e4dffe54b2eeecd4915..e63f4a90eef6a957787fabcfa43084c00d090ff7 100644
--- a/doc/src/pair_reaxc.txt
+++ b/doc/src/pair_reaxc.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -50,11 +50,11 @@ as a package.
The {reax/c/kk} style is a Kokkos version of the ReaxFF potential that
is derived from the {reax/c} style. The Kokkos version can run on GPUs
and can also use OpenMP multithreading. For more information about the
-Kokkos package, see "Section 4"_Section_packages.html#kokkos and
-"Section 5.3.3"_accelerate_kokkos.html. One important consideration
-when using the {reax/c/kk} style is the choice of either half or full
-neighbor lists. This setting can be changed using the Kokkos
-"package"_package.html command.
+Kokkos package, see "Packages details"_Packages_details.html and
+"Speed kokkos"_Speed_kokkos.html doc pages. One important
+consideration when using the {reax/c/kk} style is the choice of either
+half or full neighbor lists. This setting can be changed using the
+Kokkos "package"_package.html command.
The {reax/c} style differs from the "pair_style reax"_pair_reax.html
command in the lo-level implementation details. The {reax} style is a
@@ -303,31 +303,30 @@ This pair style can only be used via the {pair} keyword of the
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This pair style is part of the USER-REAXC package. It is only enabled
-if LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
The ReaxFF potential files provided with LAMMPS in the potentials
directory are parameterized for real "units"_units.html. You can use
diff --git a/doc/src/pair_resquared.txt b/doc/src/pair_resquared.txt
index 9ad95eb5fc4e9ddc0bb3f9eda4a1751b0afba726..5e760be495e0a52e9b7294ed73b1e756a403e2c9 100644
--- a/doc/src/pair_resquared.txt
+++ b/doc/src/pair_resquared.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -145,23 +145,22 @@ specified in the pair_style command is used.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -204,8 +203,8 @@ command"_run_style.html.
[Restrictions:]
This style is part of the ASPHERE package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This pair style requires that atoms be ellipsoids as defined by the
"atom_style ellipsoid"_atom_style.html command.
diff --git a/doc/src/pair_sdk.txt b/doc/src/pair_sdk.txt
index 360136a4eaef3df735b65cfc0f8e7ce5ca78dc16..b977aefe889c25f066e509efacba760ac71842a4 100644
--- a/doc/src/pair_sdk.txt
+++ b/doc/src/pair_sdk.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -85,23 +85,22 @@ pair_style command.
Styles with a {gpu}, {intel}, {kk}, {omp} or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -134,11 +133,11 @@ respa"_run_style.html command.
[Restrictions:]
-All of the lj/sdk pair styles are part of the USER-CGSDK package.
-The {lj/sdk/coul/long} style also requires the KSPACE package to be
-built (which is enabled by default). They are only enabled if LAMMPS
-was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+All of the lj/sdk pair styles are part of the USER-CGSDK package. The
+{lj/sdk/coul/long} style also requires the KSPACE package to be built
+(which is enabled by default). They are only enabled if LAMMPS was
+built with that package. See the "Build package"_Build_package.html
+doc page for more info.
[Related commands:]
diff --git a/doc/src/pair_smd_hertz.txt b/doc/src/pair_smd_hertz.txt
index eeaa3387a44a834cfe4361a75e40d2610d29bdb6..2581c84dc97d647ec69c67c6590c52a5b8cc6740 100644
--- a/doc/src/pair_smd_hertz.txt
+++ b/doc/src/pair_smd_hertz.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -19,32 +19,36 @@ pair_coeff 1 1 <contact_stiffness>
[Description:]
-The {smd/hertz} style calculates contact forces between SPH particles belonging to different physical bodies.
+The {smd/hertz} style calculates contact forces between SPH particles
+belonging to different physical bodies.
-The contact forces are calculated using a Hertz potential, which evaluates the overlap between two particles
-(whose spatial extents are defined via its contact radius).
-The effect is that a particles cannot penetrate into each other.
-The parameter <contact_stiffness> has units of pressure and should equal roughly one half
-of the Young's modulus (or bulk modulus in the case of fluids) of the material model associated with the SPH particles.
+The contact forces are calculated using a Hertz potential, which
+evaluates the overlap between two particles (whose spatial extents are
+defined via its contact radius). The effect is that a particles
+cannot penetrate into each other. The parameter <contact_stiffness>
+has units of pressure and should equal roughly one half of the Young's
+modulus (or bulk modulus in the case of fluids) of the material model
+associated with the SPH particles.
-The parameter {scale_factor} can be used to scale the particles' contact radii. This can be useful to control how close
-particles can approach each other. Usually, {scale_factor} =1.0.
+The parameter {scale_factor} can be used to scale the particles'
+contact radii. This can be useful to control how close particles can
+approach each other. Usually, {scale_factor} =1.0.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
-No mixing is performed automatically.
-Currently, no part of USER-SMD supports restarting nor minimization.
-rRESPA does not apply to this pair style.
+No mixing is performed automatically. Currently, no part of USER-SMD
+supports restarting nor minimization. rRESPA does not apply to this
+pair style.
:line
[Restrictions:]
This fix is part of the USER-SMD package. It is only enabled if
-LAMMPS was built with that package. See the "Making LAMMPS"_Section_start.html#start_3
-section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/pair_smd_tlsph.txt b/doc/src/pair_smd_tlsph.txt
index f73acf74ee5b1a842d2b8cd1a7ed7c632885dd75..44b0c6cae81961bf6f08abf04815937ff694e78e 100644
--- a/doc/src/pair_smd_tlsph.txt
+++ b/doc/src/pair_smd_tlsph.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -16,10 +16,11 @@ pair_style smd/tlsph args :pre
pair_style smd/tlsph
-
[Description:]
-The {smd/tlsph} style computes particle interactions according to continuum mechanics constitutive laws and a Total-Lagrangian Smooth-Particle Hydrodynamics algorithm.
+The {smd/tlsph} style computes particle interactions according to
+continuum mechanics constitutive laws and a Total-Lagrangian
+Smooth-Particle Hydrodynamics algorithm.
This pair style is invoked with the following command:
@@ -27,35 +28,40 @@ pair_style smd/tlsph
pair_coeff i j *COMMON rho0 E nu Q1 Q2 hg Cp &
*END :pre
-Here, {i} and {j} denote the {LAMMPS} particle types for which this pair style is
-defined. Note that {i} and {j} must be equal, i.e., no {tlsph} cross interactions
-between different particle types are allowed.
-In contrast to the usual {LAMMPS} {pair coeff} definitions, which are given solely a
-number of floats and integers, the {tlsph} {pair coeff} definition is organised using
-keywords. These keywords mark the beginning of different sets of parameters for particle properties,
-material constitutive models, and damage models. The {pair coeff} line must be terminated with
-the {*END} keyword. The use the line continuation operator {&} is recommended. A typical
-invocation of the {tlsph} for a solid body would consist of an equation of state for computing
-the pressure (the diagonal components of the stress tensor), and a material model to compute shear
-stresses (the off-diagonal components of the stress tensor). Damage and failure models can also be added.
-
-Please see the "SMD user guide"_PDF/SMD_LAMMPS_userguide.pdf for a complete listing of the possible keywords and material models.
+Here, {i} and {j} denote the {LAMMPS} particle types for which this
+pair style is defined. Note that {i} and {j} must be equal, i.e., no
+{tlsph} cross interactions between different particle types are
+allowed. In contrast to the usual {LAMMPS} {pair coeff} definitions,
+which are given solely a number of floats and integers, the {tlsph}
+{pair coeff} definition is organised using keywords. These keywords
+mark the beginning of different sets of parameters for particle
+properties, material constitutive models, and damage models. The {pair
+coeff} line must be terminated with the {*END} keyword. The use the
+line continuation operator {&} is recommended. A typical invocation of
+the {tlsph} for a solid body would consist of an equation of state for
+computing the pressure (the diagonal components of the stress tensor),
+and a material model to compute shear stresses (the off-diagonal
+components of the stress tensor). Damage and failure models can also
+be added.
+
+Please see the "SMD user guide"_PDF/SMD_LAMMPS_userguide.pdf for a
+complete listing of the possible keywords and material models.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
-No mixing is performed automatically.
-Currently, no part of USER-SMD supports restarting nor minimization.
-rRESPA does not apply to this pair style.
+No mixing is performed automatically. Currently, no part of USER-SMD
+supports restarting nor minimization. rRESPA does not apply to this
+pair style.
:line
[Restrictions:]
This fix is part of the USER-SMD package. It is only enabled if
-LAMMPS was built with that package. See the "Making LAMMPS"_Section_start.html#start_3
-section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/pair_smd_triangulated_surface.txt b/doc/src/pair_smd_triangulated_surface.txt
index c32bf3a22ea89c35efd3231b0ffbfdd72590a810..9eb5e311b8e20dec7a7f51756b02454260d7879e 100644
--- a/doc/src/pair_smd_triangulated_surface.txt
+++ b/doc/src/pair_smd_triangulated_surface.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -19,17 +19,21 @@ pair_coeff 1 1 <contact_stiffness>
[Description:]
-The {smd/tri_surface} style calculates contact forces between SPH particles and a rigid wall boundary defined via the
+The {smd/tri_surface} style calculates contact forces between SPH
+particles and a rigid wall boundary defined via the
"smd/wall_surface"_fix_smd_wall_surface.html fix.
-The contact forces are calculated using a Hertz potential, which evaluates the overlap between a particle
-(whose spatial extents are defined via its contact radius) and the triangle.
-The effect is that a particle cannot penetrate into the triangular surface.
-The parameter <contact_stiffness> has units of pressure and should equal roughly one half
-of the Young's modulus (or bulk modulus in the case of fluids) of the material model associated with the SPH particle
+The contact forces are calculated using a Hertz potential, which
+evaluates the overlap between a particle (whose spatial extents are
+defined via its contact radius) and the triangle. The effect is that
+a particle cannot penetrate into the triangular surface. The
+parameter <contact_stiffness> has units of pressure and should equal
+roughly one half of the Young's modulus (or bulk modulus in the case
+of fluids) of the material model associated with the SPH particle
-The parameter {scale_factor} can be used to scale the particles' contact radii. This can be useful to control how close
-particles can approach the triangulated surface. Usually, {scale_factor} =1.0.
+The parameter {scale_factor} can be used to scale the particles'
+contact radii. This can be useful to control how close particles can
+approach the triangulated surface. Usually, {scale_factor} =1.0.
:line
@@ -44,8 +48,8 @@ rRESPA does not apply to this pair style.
[Restrictions:]
This fix is part of the USER-SMD package. It is only enabled if
-LAMMPS was built with that package. See the "Making LAMMPS"_Section_start.html#start_3
-section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/pair_smd_ulsph.txt b/doc/src/pair_smd_ulsph.txt
index 268fe78d02294eca17134ff7fcffb276512db2be..f28dd9043cec1e504df6c89a28c1f2fd4dcbb4d6 100644
--- a/doc/src/pair_smd_ulsph.txt
+++ b/doc/src/pair_smd_ulsph.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -17,11 +17,13 @@ keyword = {*DENSITY_SUMMATION} or {*DENSITY_CONTINUITY} and {*VELOCITY_GRADIENT}
[Examples:]
-pair_style smd/ulsph *DENSITY_CONTINUITY *VELOCITY_GRADIENT *NO_GRADIENT_CORRECTION
+pair_style smd/ulsph *DENSITY_CONTINUITY *VELOCITY_GRADIENT *NO_GRADIENT_CORRECTION :pre
[Description:]
-The {smd/ulsph} style computes particle interactions according to continuum mechanics constitutive laws and an updated Lagrangian Smooth-Particle Hydrodynamics algorithm.
+The {smd/ulsph} style computes particle interactions according to
+continuum mechanics constitutive laws and an updated Lagrangian
+Smooth-Particle Hydrodynamics algorithm.
This pair style is invoked similar to the following command:
@@ -29,37 +31,45 @@ pair_style smd/ulsph *DENSITY_CONTINUITY *VELOCITY_GRADIENT *NO_GRADIENT_CORRECT
pair_coeff i j *COMMON rho0 c0 Q1 Cp hg &
*END :pre
-Here, {i} and {j} denote the {LAMMPS} particle types for which this pair style is
-defined. Note that {i} and {j} can be different, i.e., {ulsph} cross interactions
-between different particle types are allowed. However, {i}--{i} respectively {j}--{j} pair_coeff lines have to precede a cross interaction.
-In contrast to the usual {LAMMPS} {pair coeff} definitions, which are given solely a
-number of floats and integers, the {ulsph} {pair coeff} definition is organised using
-keywords. These keywords mark the beginning of different sets of parameters for particle properties,
-material constitutive models, and damage models. The {pair coeff} line must be terminated with
-the {*END} keyword. The use the line continuation operator {&} is recommended. A typical
-invocation of the {ulsph} for a solid body would consist of an equation of state for computing
-the pressure (the diagonal components of the stress tensor), and a material model to compute shear
-stresses (the off-diagonal components of the stress tensor).
-
-Note that the use of *GRADIENT_CORRECTION can lead to severe numerical instabilities. For a general fluid simulation, *NO_GRADIENT_CORRECTION is recommended.
-
-Please see the "SMD user guide"_PDF/SMD_LAMMPS_userguide.pdf for a complete listing of the possible keywords and material models.
+Here, {i} and {j} denote the {LAMMPS} particle types for which this
+pair style is defined. Note that {i} and {j} can be different, i.e.,
+{ulsph} cross interactions between different particle types are
+allowed. However, {i}--{i} respectively {j}--{j} pair_coeff lines have
+to precede a cross interaction. In contrast to the usual {LAMMPS}
+{pair coeff} definitions, which are given solely a number of floats
+and integers, the {ulsph} {pair coeff} definition is organised using
+keywords. These keywords mark the beginning of different sets of
+parameters for particle properties, material constitutive models, and
+damage models. The {pair coeff} line must be terminated with the
+{*END} keyword. The use the line continuation operator {&} is
+recommended. A typical invocation of the {ulsph} for a solid body
+would consist of an equation of state for computing the pressure (the
+diagonal components of the stress tensor), and a material model to
+compute shear stresses (the off-diagonal components of the stress
+tensor).
+
+Note that the use of *GRADIENT_CORRECTION can lead to severe numerical
+instabilities. For a general fluid simulation, *NO_GRADIENT_CORRECTION
+is recommended.
+
+Please see the "SMD user guide"_PDF/SMD_LAMMPS_userguide.pdf for a
+complete listing of the possible keywords and material models.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
-No mixing is performed automatically.
-Currently, no part of USER-SMD supports restarting nor minimization.
-rRESPA does not apply to this pair style.
+No mixing is performed automatically. Currently, no part of USER-SMD
+supports restarting nor minimization. rRESPA does not apply to this
+pair style.
:line
[Restrictions:]
This fix is part of the USER-SMD package. It is only enabled if
-LAMMPS was built with that package. See the "Making LAMMPS"_Section_start.html#start_3
-section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/pair_smtbq.txt b/doc/src/pair_smtbq.txt
index c8d6b21b3f1f024421dc56426aa32da817d887f7..e81411678a71e9347811d0a3990b442db26d1fe8 100644
--- a/doc/src/pair_smtbq.txt
+++ b/doc/src/pair_smtbq.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -219,8 +219,8 @@ This pair style can only be used via the {pair} keyword of the
[Restriction:]
This pair style is part of the USER-SMTBQ package and is only enabled
-if LAMMPS is built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+if LAMMPS is built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This potential requires using atom type 1 for oxygen and atom type
higher than 1 for metal atoms.
diff --git a/doc/src/pair_snap.txt b/doc/src/pair_snap.txt
index 27dcf6082b892b5a5df64442f2045215c8d5dbd8..6f8cc3d8a8b9998f28775ad20fcbe920efdc5e52 100644
--- a/doc/src/pair_snap.txt
+++ b/doc/src/pair_snap.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -175,31 +175,30 @@ This pair style can only be used via the {pair} keyword of the
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
-This style is part of the SNAP package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+This style is part of the SNAP package. It is only enabled if LAMMPS
+was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/pair_soft.txt b/doc/src/pair_soft.txt
index 08fa88c477961677b4aafd786e13ad1b89befed9..ca0266f34a7842c8f273a076f087ce442a6b92d0 100644
--- a/doc/src/pair_soft.txt
+++ b/doc/src/pair_soft.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -82,23 +82,22 @@ variables.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
diff --git a/doc/src/pair_sph_heatconduction.txt b/doc/src/pair_sph_heatconduction.txt
index 2387056a1b7b4b06235c3d8d88ad5edec4bccbdf..78a9cf2b63bc7906d737f0c81f78759082c0bea2 100644
--- a/doc/src/pair_sph_heatconduction.txt
+++ b/doc/src/pair_sph_heatconduction.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -53,8 +53,8 @@ respa"_run_style.html command. It does not support the {inner},
[Restrictions:]
This pair style is part of the USER-SPH package. It is only enabled
-if LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/pair_sph_idealgas.txt b/doc/src/pair_sph_idealgas.txt
index 957f901425993d91b248c9a7172a45b0753abd44..59513e7a7370845c3e3dd43f81cd4b90d5627a7d 100644
--- a/doc/src/pair_sph_idealgas.txt
+++ b/doc/src/pair_sph_idealgas.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -60,8 +60,8 @@ respa"_run_style.html command. It does not support the {inner},
[Restrictions:]
This pair style is part of the USER-SPH package. It is only enabled
-if LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/pair_sph_lj.txt b/doc/src/pair_sph_lj.txt
index ef89c4ad3eaf351d07dad07e953b6dc4ea3eb139..43e77f1aae2d8cfbecd4539ce1b0b7ce35183937 100644
--- a/doc/src/pair_sph_lj.txt
+++ b/doc/src/pair_sph_lj.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -60,8 +60,8 @@ As noted above, the Lennard-Jones parameters epsilon and sigma are set
to unity.
This pair style is part of the USER-SPH package. It is only enabled
-if LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/pair_sph_rhosum.txt b/doc/src/pair_sph_rhosum.txt
index 352e717f76484a2b3c2c993560646fd110869b60..9069176f29388ea1a0a1f2e3b24283d183f91214 100644
--- a/doc/src/pair_sph_rhosum.txt
+++ b/doc/src/pair_sph_rhosum.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -54,8 +54,8 @@ respa"_run_style.html command. It does not support the {inner},
[Restrictions:]
This pair style is part of the USER-SPH package. It is only enabled
-if LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/pair_sph_taitwater.txt b/doc/src/pair_sph_taitwater.txt
index 9177ca80b868e417e3bf8a23d30f267fd882f3ff..dcb9e39603ff0440d2beb97dafb847f4320df47f 100644
--- a/doc/src/pair_sph_taitwater.txt
+++ b/doc/src/pair_sph_taitwater.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -63,8 +63,8 @@ respa"_run_style.html command. It does not support the {inner},
[Restrictions:]
This pair style is part of the USER-SPH package. It is only enabled
-if LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/pair_sph_taitwater_morris.txt b/doc/src/pair_sph_taitwater_morris.txt
index e6c5a6bb20dc302fa3105af4c3c224d9e2411b98..b88707d1afa1e43a3fc2885993db6d544b86391b 100644
--- a/doc/src/pair_sph_taitwater_morris.txt
+++ b/doc/src/pair_sph_taitwater_morris.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -62,8 +62,8 @@ respa"_run_style.html command. It does not support the {inner},
[Restrictions:]
This pair style is part of the USER-SPH package. It is only enabled
-if LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/pair_spin_dmi.txt b/doc/src/pair_spin_dmi.txt
index 9fe53df18a5cf81b6c1a838b968567d8220f1d36..bd605bd064637191044f1cfbba122632d5cbb98a 100644
--- a/doc/src/pair_spin_dmi.txt
+++ b/doc/src/pair_spin_dmi.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -25,32 +25,54 @@ pair_coeff 1 2 dmi 4.0 0.00109 0.0 0.0 1.0 :pre
[Description:]
Style {spin/dmi} computes the Dzyaloshinskii-Moriya (DM) interaction
-between pairs of magnetic spins:
+between pairs of magnetic spins.
+According to the expression reported in "(Rohart)"_#Rohart, one has
+the following DM energy:
:c,image(Eqs/pair_spin_dmi_interaction.jpg)
where si and sj are two neighboring magnetic spins of two particles,
-eij = (ri - rj)/|ri-rj| is the normalized separation vector between the
-two particles, and D is the DM vector defining the intensity and the
-sign of the interaction.
+eij = (ri - rj)/|ri-rj| is the unit vector between sites i and j,
+and D is the DM vector defining the intensity (in eV) and the direction
+of the interaction.
-Examples and more explanations about this interaction and its parametrization are
-reported in "(Tranchida)"_#Tranchida5.
+In "(Rohart)"_#Rohart, D is defined as the direction normal to the film oriented
+from the high spin-orbit layer to the magnetic ultrathin film.
-From this DM interaction, each spin i will be submitted to a magnetic torque
-omega and its associated atom to a force F (for spin-lattice calculations only).
+The application of a spin-lattice Poisson bracket to this energy (as described
+in "(Tranchida)"_#Tranchida5) allows to derive a magnetic torque omega, and a
+mechanical force F (for spin-lattice calculations only) for each magnetic
+particle i:
+
+:c,image(Eqs/pair_spin_dmi_forces.jpg)
More details about the derivation of these torques/forces are reported in
"(Tranchida)"_#Tranchida5.
+For the {spin/dmi} pair style, the following coefficients must be defined for
+each pair of atoms types via the "pair_coeff"_pair_coeff.html command as in
+the examples above, or in the data file or restart files read by the
+"read_data"_read_data.html or "read_restart"_read_restart.html commands, and
+set in the following order:
+
+rc (distance units)
+|D| (energy units)
+Dx, Dy, Dz (direction of D) :ul
+
+Note that rc is the radius cutoff of the considered DM interaction, |D| is
+the norm of the DM vector (in eV), and Dx, Dy and Dz define its direction.
+
+None of those coefficients is optional. If not specified, the {spin/dmi}
+pair style cannot be used.
+
:line
[Restrictions:]
-All the {pair/spin} styles are part of the SPIN package.
-These styles are only enabled if LAMMPS was built with this package, and
-if the atom_style "spin" was declared.
-See the "Making LAMMPS"_Section_start.html#start_3 section for more info.
+All the {pair/spin} styles are part of the SPIN package. These styles
+are only enabled if LAMMPS was built with this package, and if the
+atom_style "spin" was declared. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
@@ -61,6 +83,9 @@ See the "Making LAMMPS"_Section_start.html#start_3 section for more info.
:line
+:link(Rohart)
+[(Rohart)] Rohart and Thiaville,
+Physical Review B, 88(18), 184422. (2013).
:link(Tranchida5)
[(Tranchida)] Tranchida, Plimpton, Thibaudeau and Thompson,
-arXiv preprint arXiv:1801.10233, (2018).
+Journal of Computational Physics, (2018).
diff --git a/doc/src/pair_spin_exchange.txt b/doc/src/pair_spin_exchange.txt
index 97b6d0b34f90a13e399d50f9b77a1b9587698b76..2f158704a98007ba083e4b3e90cf67dbb4c5e5bc 100644
--- a/doc/src/pair_spin_exchange.txt
+++ b/doc/src/pair_spin_exchange.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -32,18 +32,15 @@ pairs of magnetic spins:
where si and sj are two neighboring magnetic spins of two particles,
rij = ri - rj is the inter-atomic distance between the two particles,
and J(rij) is a function defining the intensity and the sign of the exchange
-interaction.
-
-This function is defined as:
+interaction for different neighboring shells. This function is defined as:
:c,image(Eqs/pair_spin_exchange_function.jpg)
where a, b and d are the three constant coefficients defined in the associated
-"pair_coeff" command.
+"pair_coeff" command (see below for more explanations).
The coefficients a, b, and d need to be fitted so that the function above matches with
the value of the exchange interaction for the N neighbor shells taken into account.
-
Examples and more explanations about this function and its parametrization are reported
in "(Tranchida)"_#Tranchida3.
@@ -54,19 +51,38 @@ such as:
:c,image(Eqs/pair_spin_exchange_forces.jpg)
-with h the Planck constant (in metal units).
+with h the Planck constant (in metal units), and eij = (ri - rj)/|ri-rj| the unit
+vector between sites i and j.
More details about the derivation of these torques/forces are reported in
"(Tranchida)"_#Tranchida3.
+For the {spin/exchange} pair style, the following coefficients must be defined
+for each pair of atoms types via the "pair_coeff"_pair_coeff.html command as in
+the examples above, or in the data file or restart files read by the
+"read_data"_read_data.html or "read_restart"_read_restart.html commands, and
+set in the following order:
+
+rc (distance units)
+a (energy units)
+b (adim parameter)
+d (distance units) :ul
+
+Note that rc is the radius cutoff of the considered exchange interaction,
+and a, b and d are the three coefficients performing the parametrization
+of the function J(rij) defined above.
+
+None of those coefficients is optional. If not specified, the
+{spin/exchange} pair style cannot be used.
+
:line
[Restrictions:]
-All the {pair/spin} styles are part of the SPIN package.
-These styles are only enabled if LAMMPS was built with this package, and
-if the atom_style "spin" was declared.
-See the "Making LAMMPS"_Section_start.html#start_3 section for more info.
+All the {pair/spin} styles are part of the SPIN package. These styles
+are only enabled if LAMMPS was built with this package, and if the
+atom_style "spin" was declared. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
@@ -79,4 +95,4 @@ See the "Making LAMMPS"_Section_start.html#start_3 section for more info.
:link(Tranchida3)
[(Tranchida)] Tranchida, Plimpton, Thibaudeau and Thompson,
-arXiv preprint arXiv:1801.10233, (2018).
+Journal of Computational Physics, (2018).
diff --git a/doc/src/pair_spin_magelec.txt b/doc/src/pair_spin_magelec.txt
index 0185a5abb2ea0fedb47b747e35eec04b9cf108ee..f552c56a4bd34b93f68beb5b95f0146785908e3b 100644
--- a/doc/src/pair_spin_magelec.txt
+++ b/doc/src/pair_spin_magelec.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -51,10 +51,10 @@ More details about the derivation of these torques/forces are reported in
[Restrictions:]
-All the {pair/spin} styles are part of the SPIN package.
-These styles are only enabled if LAMMPS was built with this package, and
-if the atom_style "spin" was declared.
-See the "Making LAMMPS"_Section_start.html#start_3 section for more info.
+All the {pair/spin} styles are part of the SPIN package. These styles
+are only enabled if LAMMPS was built with this package, and if the
+atom_style "spin" was declared. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
@@ -70,4 +70,4 @@ See the "Making LAMMPS"_Section_start.html#start_3 section for more info.
:link(Tranchida4)
[(Tranchida)] Tranchida, Plimpton, Thibaudeau, and Thompson,
-arXiv preprint arXiv:1801.10233, (2018).
+Journal of Computational Physics, (2018).
diff --git a/doc/src/pair_spin_neel.txt b/doc/src/pair_spin_neel.txt
index f7c9608a9398638378b0f9b1d039f56b07b199c8..fe3bb1ad14ea69240f6bd71b4f9bf06fd63278ef 100644
--- a/doc/src/pair_spin_neel.txt
+++ b/doc/src/pair_spin_neel.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -62,10 +62,10 @@ More details about the derivation of these torques/forces are reported in
[Restrictions:]
-All the {pair/spin} styles are part of the SPIN package.
-These styles are only enabled if LAMMPS was built with this package, and
-if the atom_style "spin" was declared.
-See the "Making LAMMPS"_Section_start.html#start_3 section for more info.
+All the {pair/spin} styles are part of the SPIN package. These styles
+are only enabled if LAMMPS was built with this package, and if the
+atom_style "spin" was declared. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
@@ -78,4 +78,4 @@ See the "Making LAMMPS"_Section_start.html#start_3 section for more info.
:link(Tranchida6)
[(Tranchida)] Tranchida, Plimpton, Thibaudeau and Thompson,
-arXiv preprint arXiv:1801.10233, (2018).
+Journal of Computational Physics, (2018).
diff --git a/doc/src/pair_srp.txt b/doc/src/pair_srp.txt
index e7f1e00d1028635db3c8cce28097cf62d54fa7d3..e784ac3d17d5f8fc0415003a6a084560d3a6a3c3 100644
--- a/doc/src/pair_srp.txt
+++ b/doc/src/pair_srp.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/pair_style.txt b/doc/src/pair_style.txt
index 475761add76d11df7035cab25631028270e5ba63..b33897c5aa506cd6be92ef275194ec2ceb83ce44 100644
--- a/doc/src/pair_style.txt
+++ b/doc/src/pair_style.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -78,22 +78,22 @@ previously specified pair_coeff values.
:line
Here is an alphabetic list of pair styles defined in LAMMPS. They are
-also given in more compact form in the pair section of "this
-page"_Section_commands.html#cmd_5.
+also listed in more compact form on the "Commands
+pair"_Commands_pair.html doc page.
Click on the style to display the formula it computes, arguments
specified in the pair_style command, and coefficients specified by the
associated "pair_coeff"_pair_coeff.html command.
There are also additional pair styles (not listed here) submitted by
-users which are included in the LAMMPS distribution. The list of
-these with links to the individual styles are given in the pair
-section of "this page"_Section_commands.html#cmd_5.
+users which are included in the LAMMPS distribution. The full list of
+all pair styles is on the "Commands pair"_Commands_pair.html doc page.
There are also additional accelerated pair styles (not listed here)
-included in the LAMMPS distribution for faster performance on CPUs and
-GPUs. The list of these with links to the individual styles are given
-in the pair section of "this page"_Section_commands.html#cmd_5.
+included in the LAMMPS distribution for faster performance on CPUs,
+GPUs, and KNLs. The individual style names on the "Commands
+pair"_Commands_pair.html doc page are followed by one or more of
+(g,i,k,o,t) to indicate which accerlerated styles exist.
"pair_style none"_pair_none.html - turn off pairwise interactions
"pair_style hybrid"_pair_hybrid.html - multiple styles of pairwise interactions
@@ -104,7 +104,7 @@ in the pair section of "this page"_Section_commands.html#cmd_5.
"pair_style airebo"_pair_airebo.html - AIREBO potential of Stuart
"pair_style airebo/morse"_pair_airebo.html - AIREBO with Morse instead of LJ
"pair_style beck"_pair_beck.html - Beck potential
-"pair_style body"_pair_body.html - interactions between body particles
+"pair_style body/nparticle"_pair_body_nparticle.html - interactions between body particles
"pair_style bop"_pair_bop.html - BOP potential of Pettifor
"pair_style born"_pair_born.html - Born-Mayer-Huggins potential
"pair_style born/coul/long"_pair_born.html - Born-Mayer-Huggins with long-range Coulombics
@@ -218,10 +218,9 @@ This command must be used before any coefficients are set by the
"read_restart"_read_restart.html commands.
Some pair styles are part of specific packages. They are only enabled
-if LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info on packages.
-The doc pages for individual pair potentials tell if it is part of a
-package.
+if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info. The doc pages for
+individual pair potentials tell if it is part of a package.
[Related commands:]
diff --git a/doc/src/pair_sw.txt b/doc/src/pair_sw.txt
index 4932fe55d335bb101db35e478f0681ffe416a69d..ff83316419081f1e25b0778a66aaa00b78535819 100644
--- a/doc/src/pair_sw.txt
+++ b/doc/src/pair_sw.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -144,28 +144,27 @@ taken from the ij and ik pairs (sigma, a, gamma)
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
When using the USER-INTEL package with this style, there is an
additional 5 to 10 percent performance improvement when the
Stillinger-Weber parameters p and q are set to 4 and 0 respectively.
These parameters are common for modeling silicon and water.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -192,8 +191,8 @@ This pair style can only be used via the {pair} keyword of the
[Restrictions:]
This pair style is part of the MANYBODY package. It is only enabled
-if LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This pair style requires the "newton"_newton.html setting to be "on"
for pair interactions.
diff --git a/doc/src/pair_table.txt b/doc/src/pair_table.txt
index b99491b477224e621da4429d10c0b20b84c66c0d..22c63a1f32b2d347884218f4cb449f95beb7e219 100644
--- a/doc/src/pair_table.txt
+++ b/doc/src/pair_table.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -217,23 +217,22 @@ one that matches the specified keyword.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
diff --git a/doc/src/pair_table_rx.txt b/doc/src/pair_table_rx.txt
index cd3a7ef31b87d15268cfe93050889b4699a4adc7..9b9a6abff861daab0e499ee53e7276e138631e0e 100644
--- a/doc/src/pair_table_rx.txt
+++ b/doc/src/pair_table_rx.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -227,31 +227,30 @@ This pair style can only be used via the {pair} keyword of the
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This command is part of the USER-DPD package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/pair_tersoff.txt b/doc/src/pair_tersoff.txt
index 918e88992440045bda099cb2ad9849ab4faeff14..20744bc2a9ae3928a98f3d7dc23e361067d35b73 100644
--- a/doc/src/pair_tersoff.txt
+++ b/doc/src/pair_tersoff.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -179,23 +179,22 @@ defined in various papers.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -222,8 +221,8 @@ This pair style can only be used via the {pair} keyword of the
[Restrictions:]
This pair style is part of the MANYBODY package. It is only enabled
-if LAMMPS was built with that package. See
-the "Making LAMMPS"_Section_start.html#start_3 section for more info.
+if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This pair style requires the "newton"_newton.html setting to be "on"
for pair interactions.
diff --git a/doc/src/pair_tersoff_mod.txt b/doc/src/pair_tersoff_mod.txt
index e0c2b5a5cbb07b7c525d58d48eab97cb763971ca..2df23045a397b16e56409ec506d8bfeeae85a1a1 100644
--- a/doc/src/pair_tersoff_mod.txt
+++ b/doc/src/pair_tersoff_mod.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -131,23 +131,22 @@ for SiSiSi means Si bonded to a Si with another Si atom influencing the bond.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -170,8 +169,8 @@ This pair style can only be used via the {pair} keyword of the
[Restrictions:]
This pair style is part of the MANYBODY package. It is only enabled
-if LAMMPS was built with that package. See
-the "Making LAMMPS"_Section_start.html#start_3 section for more info.
+if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This pair style requires the "newton"_newton.html setting to be "on"
for pair interactions.
diff --git a/doc/src/pair_tersoff_zbl.txt b/doc/src/pair_tersoff_zbl.txt
index 21d57e4e8841570f44f114961af653ad9dde93b4..5f03ffd94eca4028b40283b554815d7e67c9198c 100644
--- a/doc/src/pair_tersoff_zbl.txt
+++ b/doc/src/pair_tersoff_zbl.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -189,23 +189,22 @@ providing the base ZBL implementation.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -232,8 +231,8 @@ This pair style can only be used via the {pair} keyword of the
[Restrictions:]
This pair style is part of the MANYBODY package. It is only enabled
-if LAMMPS was built with that package. See
-the "Making LAMMPS"_Section_start.html#start_3 section for more info.
+if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This pair style requires the "newton"_newton.html setting to be "on"
for pair interactions.
diff --git a/doc/src/pair_thole.txt b/doc/src/pair_thole.txt
index 41a4059cee8d4de828d136343a282310f493403d..c7a304ca41689df96344438eb094796a0108657c 100644
--- a/doc/src/pair_thole.txt
+++ b/doc/src/pair_thole.txt
@@ -9,7 +9,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -45,8 +45,8 @@ pair_style lj/cut/thole/long 2.6 12.0 :pre
The {thole} pair styles are meant to be used with force fields that
include explicit polarization through Drude dipoles. This link
describes how to use the "thermalized Drude oscillator
-model"_tutorial_drude.html in LAMMPS and polarizable models in LAMMPS
-are discussed in "this Section"_Section_howto.html#howto_25.
+model"_Howto_drude.html in LAMMPS and polarizable models in LAMMPS are
+discussed on the "Howto polarizable"_Howto_polarizable.html doc page.
The {thole} pair style should be used as a sub-style within in the
"pair_hybrid/overlay"_pair_hybrid.html command, in conjunction with a
@@ -130,23 +130,22 @@ the {pair_style} command line.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
[Mixing]:
@@ -162,8 +161,8 @@ are defined using
[Restrictions:]
These pair styles are part of the USER-DRUDE package. They are only
-enabled if LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+enabled if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This pair_style should currently not be used with the "charmm dihedral
style"_dihedral_charmm.html if the latter has non-zero 1-4 weighting
diff --git a/doc/src/pair_tri_lj.txt b/doc/src/pair_tri_lj.txt
index 42a5bbdfe2285c61c67ad980eecca779666f553b..98bb4e284efcad05315c08b7a0d542febf3e5d2d 100644
--- a/doc/src/pair_tri_lj.txt
+++ b/doc/src/pair_tri_lj.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -101,8 +101,8 @@ This pair style can only be used via the {pair} keyword of the
[Restrictions:]
This style is part of the ASPHERE package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
Defining particles to be triangles so they participate in tri/tri or
tri/particle interactions requires the use the "atom_style
diff --git a/doc/src/pair_ufm.txt b/doc/src/pair_ufm.txt
index 88a22864ccaf960472dbe5ea3f985ea2d375ab23..787c60a1bd8a8565f880863178d2d959528bf5e5 100644
--- a/doc/src/pair_ufm.txt
+++ b/doc/src/pair_ufm.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -69,23 +69,22 @@ NOTE: The thermodynamic integration procedure can be performed with this potenti
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
diff --git a/doc/src/pair_vashishta.txt b/doc/src/pair_vashishta.txt
index d9c66d45c0cae201fa12b3799bdf562dc9f55a91..01d089b4de9b0727103d4b1fd653b2684cf711a5 100644
--- a/doc/src/pair_vashishta.txt
+++ b/doc/src/pair_vashishta.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -171,23 +171,22 @@ two-body parameters from the CCC and CSiSi entries.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -214,8 +213,8 @@ This pair style can only be used via the {pair} keyword of the
[Restrictions:]
These pair style are part of the MANYBODY package. They is only
-enabled if LAMMPS was built with that package. See the
-"Making LAMMPS"_Section_start.html#start_3 section for more info.
+enabled if LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
These pair styles requires the "newton"_newton.html setting to be "on"
for pair interactions.
diff --git a/doc/src/pair_write.txt b/doc/src/pair_write.txt
index 9f5970fcbc6c8c406746d752ac281e2eec3ebc9e..48ad76e76eabf624459cb37139e77ef4a09385f0 100644
--- a/doc/src/pair_write.txt
+++ b/doc/src/pair_write.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/pair_yukawa.txt b/doc/src/pair_yukawa.txt
index e7c063ded9f41227210e17970dc9fb7cc59ed757..154fd3e8367620af646bd283270f4d71ffafe507 100644
--- a/doc/src/pair_yukawa.txt
+++ b/doc/src/pair_yukawa.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -49,23 +49,22 @@ cutoff is used.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
diff --git a/doc/src/pair_yukawa_colloid.txt b/doc/src/pair_yukawa_colloid.txt
index 2037a9451f9e77079971382afde16709657c88e7..b36c4c235c6cefef90ade34eaabf4b3fe7b08b36 100644
--- a/doc/src/pair_yukawa_colloid.txt
+++ b/doc/src/pair_yukawa_colloid.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -80,23 +80,22 @@ yukawa/colloid cutoff is used.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
@@ -130,8 +129,8 @@ This pair style can only be used via the {pair} keyword of the
[Restrictions:]
This style is part of the COLLOID package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
This pair style requires that atoms be finite-size spheres with a
diameter, as defined by the "atom_style sphere"_atom_style.html
diff --git a/doc/src/pair_zbl.txt b/doc/src/pair_zbl.txt
index 1984cd831f6bf2fef81c9f2ef39c16b04284e309..4c8dfb545526e07e11979d911856b1c3becdf341 100644
--- a/doc/src/pair_zbl.txt
+++ b/doc/src/pair_zbl.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -71,23 +71,22 @@ copper.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
-hardware, as discussed in "Section 5"_Section_accelerate.html
-of the manual. The accelerated styles take the same arguments and
-should produce the same results, except for round-off and precision
-issues.
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+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"_Section_start.html#start_3 section for more info.
+LAMMPS was built with those packages. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
diff --git a/doc/src/pair_zero.txt b/doc/src/pair_zero.txt
index e58b33c75f4d0261d43a6eafee975c470e79c627..b324003bd1ca252e6ecaa8a341219dfb11d521cd 100644
--- a/doc/src/pair_zero.txt
+++ b/doc/src/pair_zero.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/pairs.txt b/doc/src/pairs.txt
index 1a5e98a10964f63e7c2c3cfbf8a4faaef3967271..4c3eef2cd11c32ea4801ebb830a6a985cc5a734b 100644
--- a/doc/src/pairs.txt
+++ b/doc/src/pairs.txt
@@ -10,8 +10,9 @@ Pair Styles :h1
pair_airebo
pair_awpmd
pair_beck
- pair_body
+ pair_body_nparticle
pair_body_rounded_polygon
+ pair_body_rounded_polyhedron
pair_bop
pair_born
pair_brownian
diff --git a/doc/src/partition.txt b/doc/src/partition.txt
index 610eee99b300bd96486991c1841cfde1a2b1d8e5..86673c226bd5ef463e1723fb9f0fcdc023f4a678 100644
--- a/doc/src/partition.txt
+++ b/doc/src/partition.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -26,9 +26,8 @@ partition yes 6* fix all nvt temp 1.0 1.0 0.1 :pre
[Description:]
This command invokes the specified command on a subset of the
-partitions of processors you have defined via the -partition
-command-line switch. See "Section 2.6"_Section_start.html#start_6
-for an explanation of the switch.
+partitions of processors you have defined via the "-partition
+command-line switch"_Run_options.html.
Normally, every input script command in your script is invoked by
every partition. This behavior can be modified by defining world- or
@@ -49,7 +48,7 @@ argument.
Partitions are numbered from 1 to Np, where Np is the number of
partitions specified by the "-partition command-line
-switch"_Section_start.html#start_6.
+switch"_Run_options.html.
{N} can be specified in one of two ways. An explicit numeric value
can be used, as in the 1st example above. Or a wild-card asterisk can
diff --git a/doc/src/prd.txt b/doc/src/prd.txt
index 3c0305e316d4e5c8a321e27ad4662a5dc1807d40..f71f285336ff716db8af3da6f05b232932629ae2 100644
--- a/doc/src/prd.txt
+++ b/doc/src/prd.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -62,15 +62,15 @@ timescale spanned by the multiple simulations, while waiting for an
event to occur.
Each replica runs on a partition of one or more processors. Processor
-partitions are defined at run-time using the -partition command-line
-switch; see "Section 2.6"_Section_start.html#start_6 of the manual.
-Note that if you have MPI installed, you can run a multi-replica
-simulation with more replicas (partitions) than you have physical
-processors, e.g you can run a 10-replica simulation on one or two
-processors. However for PRD, this makes little sense, since running a
-replica on virtual instead of physical processors,offers no effective
-parallel speed-up in searching for infrequent events. See "Section
-6.5"_Section_howto.html#howto_5 of the manual for further discussion.
+partitions are defined at run-time using the "-partition command-line
+switch"_Run_options.html. Note that if you have MPI installed, you
+can run a multi-replica simulation with more replicas (partitions)
+than you have physical processors, e.g you can run a 10-replica
+simulation on one or two processors. However for PRD, this makes
+little sense, since running a replica on virtual instead of physical
+processors,offers no effective parallel speed-up in searching for
+infrequent events. See the "Howto replica"_Howto_replica.html doc
+page for further discussion.
When a PRD simulation is performed, it is assumed that each replica is
running the same model, though LAMMPS does not check for this.
@@ -285,8 +285,8 @@ value for the first event in the new run will be slightly off.
[Restrictions:]
This command can only be used if LAMMPS was built with the REPLICA
-package. See the "Making LAMMPS"_Section_start.html#start_3 section
-for more info on packages.
+package. See the "Build package"_Build_package.html doc
+page for more info.
The {N} and {t_correlate} settings must be integer multiples of
{t_event}.
diff --git a/doc/src/print.txt b/doc/src/print.txt
index 77e0c7cfd3d64ed7a6bfeb6dcd17b716f0b1e1f3..476d4104fab9bfcf41aa9ef7b7216523e6faf0d4 100644
--- a/doc/src/print.txt
+++ b/doc/src/print.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/processors.txt b/doc/src/processors.txt
index e54b2cede3b94e8bb13324c22f3352601b8b79d8..b9bd927f9688efbde7448eaa025bd111335eca4b 100644
--- a/doc/src/processors.txt
+++ b/doc/src/processors.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -81,11 +81,11 @@ communication costs due to the high surface area of each processor's
sub-domain.
Also note that if multiple partitions are being used then P is the
-number of processors in this partition; see "this
-section"_Section_start.html#start_6 for an explanation of the
--partition command-line switch. Also note that you can prefix the
-processors command with the "partition"_partition.html command to
-easily specify different Px,Py,Pz values for different partitions.
+number of processors in this partition; see the "-partition
+command-line switch"_Run_options.html doc page for details. Also note
+that you can prefix the processors command with the
+"partition"_partition.html command to easily specify different
+Px,Py,Pz values for different partitions.
You can use the "partition"_partition.html command to specify
different processor grids for different partitions, e.g.
@@ -249,7 +249,7 @@ partition {Precv} which is enforced when each is setting up their own
mapping of their processors to the simulation box. Each of {Psend}
and {Precv} must be integers from 1 to Np, where Np is the number of
partitions you have defined via the "-partition command-line
-switch"_Section_start.html#start_6.
+switch"_Run_options.html.
A "dependency" means that the sending partition will create its
regular 3d grid as Px by Py by Pz and after it has done this, it will
@@ -286,8 +286,8 @@ processors and their mapping to the 3d grid to the specified file
processors in the manner you desired, which can be tricky to figure
out, especially when running on multiple partitions or on, a multicore
machine or when the processor ranks were reordered by use of the
-"-reorder command-line switch"_Section_start.html#start_6 or due to
-use of MPI-specific launch options such as a config file.
+"-reorder command-line switch"_Run_options.html or due to use of
+MPI-specific launch options such as a config file.
If you have multiple partitions you should insure that each one writes
to a different file, e.g. using a "world-style variable"_variable.html
@@ -300,11 +300,11 @@ The IDs are the processor's rank in this simulation (the world), the
universe (of multiple simulations), and the original MPI communicator
used to instantiate LAMMPS, respectively. The world and universe IDs
will only be different if you are running on more than one partition;
-see the "-partition command-line switch"_Section_start.html#start_6.
-The universe and original IDs will only be different if you used the
-"-reorder command-line switch"_Section_start.html#start_6 to reorder
-the processors differently than their rank in the original
-communicator LAMMPS was instantiated with.
+see the "-partition command-line switch"_Run_options.html. The
+universe and original IDs will only be different if you used the
+"-reorder command-line switch"_Run_options.html to reorder the
+processors differently than their rank in the original communicator
+LAMMPS was instantiated with.
I,J,K are the indices of the processor in the regular 3d grid, each
from 1 to Nd, where Nd is the number of processors in that dimension
@@ -332,7 +332,8 @@ The {part} keyword (for the receiving partition) only works with the
[Related commands:]
-"partition"_partition.html, "-reorder command-line switch"_Section_start.html#start_6
+"partition"_partition.html, "-reorder command-line
+switch"_Run_options.html
[Default:]
diff --git a/doc/src/python.txt b/doc/src/python.txt
index 1ac2b48528c073a1b40ea4fd210dfb5dfb91a1ae..54d18d2f6069c8e23400b9fd10be83083006c54a 100644
--- a/doc/src/python.txt
+++ b/doc/src/python.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -99,10 +99,9 @@ They can be substituted for directly in an input script. Or they can
be passed to various commands as arguments, so that the variable is
evaluated during a simulation run.
-A broader overview of how Python can be used with LAMMPS is
-given in "Section 11"_Section_python.html. There is an
-examples/python directory which illustrates use of the python
-command.
+A broader overview of how Python can be used with LAMMPS is given on
+the "Python"_Python_head.html doc page. There is an examples/python
+directory which illustrates use of the python command.
:line
@@ -200,9 +199,9 @@ The {here} keyword does the same thing, except that the Python code
follows as a single argument to the {here} keyword. This can be done
using triple quotes as delimiters, as in the examples above. This
allows Python code to be listed verbatim in your input script, with
-proper indentation, blank lines, and comments, as desired. See
-"Section 3.2"_Section_commands.html#cmd_2, for an explanation of how
-triple quotes can be used as part of input script syntax.
+proper indentation, blank lines, and comments, as desired. See the
+"Commands parse"_Commands_parse.html doc page, for an explanation of
+how triple quotes can be used as part of input script syntax.
The {exists} keyword takes no argument. It means that Python code
containing the required Python function defined by the {func} setting,
@@ -331,9 +330,9 @@ to the screen and log file. Note that since the LAMMPS print command
itself takes a string in quotes as its argument, the Python string
must be delimited with a different style of quotes.
-"Section 11.7"_Section_python.html#py_7 describes the syntax for how
-Python wraps the various functions included in the LAMMPS library
-interface.
+The "Pytnon library"_Python_library.html doc page describes the syntax
+for how Python wraps the various functions included in the LAMMPS
+library interface.
A more interesting example is in the examples/python/in.python script
which loads and runs the following function from examples/python/funcs.py:
@@ -470,8 +469,8 @@ sys.exit() in the except clause).
[Restrictions:]
This command is part of the PYTHON package. It is only enabled if
-LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+LAMMPS was built with that package. See the "Build
+package"_Build_package.html doc page for more info.
Building LAMMPS with the PYTHON package will link LAMMPS with the
Python library on your system. Settings to enable this are in the
@@ -484,15 +483,16 @@ building LAMMPS. LAMMPS must also be built as a shared library and
your Python function must be able to to load the Python module in
python/lammps.py that wraps the LAMMPS library interface. These are
the same steps required to use Python by itself to wrap LAMMPS.
-Details on these steps are explained in "Section
-python"_Section_python.html. Note that it is important that the
-stand-alone LAMMPS executable and the LAMMPS shared library be
-consistent (built from the same source code files) in order for this
-to work. If the two have been built at different times using
-different source files, problems may occur.
+Details on these steps are explained on the "Python"_Python_head.html
+doc page. Note that it is important that the stand-alone LAMMPS
+executable and the LAMMPS shared library be consistent (built from the
+same source code files) in order for this to work. If the two have
+been built at different times using different source files, problems
+may occur.
[Related commands:]
-"shell"_shell.html, "variable"_variable.html, "fix python/invoke"_fix_python_invoke.html
+"shell"_shell.html, "variable"_variable.html, "fix
+python/invoke"_fix_python_invoke.html
[Default:] none
diff --git a/doc/src/quit.txt b/doc/src/quit.txt
index 843d3de7f3545dfd330f7e7624fe21a3c3c6e430..802df97711e5c4b38e816f12f18043440cb669f3 100644
--- a/doc/src/quit.txt
+++ b/doc/src/quit.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/read_data.txt b/doc/src/read_data.txt
index fd297e36c121e1efb8f631c95c182a51587a60c0..ef899a15b44b153621cc194d317c3a313bd9afac 100644
--- a/doc/src/read_data.txt
+++ b/doc/src/read_data.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -63,8 +63,8 @@ simulation. The file can be ASCII text or a gzipped text file
atom coordinates; see the "read_restart"_read_restart.html and
"create_atoms"_create_atoms.html commands for alternative methods.
Also see the explanation of the "-restart command-line
-switch"_Section_start.html#start_6 which can convert a restart file to
-a data file.
+switch"_Run_options.html which can convert a restart file to a data
+file.
This command can be used multiple times to add new atoms and their
properties to an existing system by using the {add}, {offset}, and
@@ -322,9 +322,9 @@ with tilt factors that exceed these limits, you can use the "box
tilt"_box.html command, with a setting of {large}; a setting of
{small} is the default.
-See "Section 6.12"_Section_howto.html#howto_12 of the doc pages
-for a geometric description of triclinic boxes, as defined by LAMMPS,
-and how to transform these parameters to and from other commonly used
+See the "Howto triclinic"_Howto_triclinic.html doc page for a
+geometric description of triclinic boxes, as defined by LAMMPS, and
+how to transform these parameters to and from other commonly used
triclinic representations.
When a triclinic system is used, the simulation domain should normally
@@ -772,9 +772,9 @@ the "bodies" keyword.
Each body can have a variable number of integer and/or floating-point
values. The number and meaning of the values is defined by the body
-style, as described in the "body"_body.html doc page. The body style
-is given as an argument to the "atom_style body"_atom_style.html
-command.
+style, as described in the "Howto body"_Howto_body.html doc page. The
+body style is given as an argument to the "atom_style
+body"_atom_style.html command.
The Ninteger and Ndouble values determine how many integer and
floating-point values are specified for this particle. Ninteger and
@@ -1153,8 +1153,8 @@ Translational velocities can also be set by the
[Restrictions:]
To read gzipped data files, you must compile LAMMPS with the
--DLAMMPS_GZIP option - see the "Making
-LAMMPS"_Section_start.html#start_2 section of the documentation.
+-DLAMMPS_GZIP option. See the "Build settings"_Build_settings.html
+doc page for details.
[Related commands:]
diff --git a/doc/src/read_dump.txt b/doc/src/read_dump.txt
index 23f6274582ee9d1ef579ce96ce9692a892866f29..db9cfca825b10f19a55292b8e78da88ce8a15950 100644
--- a/doc/src/read_dump.txt
+++ b/doc/src/read_dump.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -282,11 +282,11 @@ conditions are applied to remap an atom back into the simulation box.
NOTE: If you get a warning about inconsistent image flags after
reading in a dump snapshot, it means one or more pairs of bonded atoms
-now have inconsistent image flags. As discussed in "Section
-errors"_Section_errors.html this may or may not cause problems for
-subsequent simulations, One way this can happen is if you read image
-flag fields from the dump file but do not also use the dump file box
-parameters.
+now have inconsistent image flags. As discussed on the "Errors
+common"_Errors_common.html doc page this may or may not cause problems
+for subsequent simulations. One way this can happen is if you read
+image flag fields from the dump file but do not also use the dump file
+box parameters.
LAMMPS knows how to compute unscaled and remapped coordinates for the
snapshot column labels discussed above, e.g. {x}, {xs}, {xu}, {xsu}.
@@ -311,12 +311,12 @@ needed to generate absolute, unscaled coordinates.
[Restrictions:]
To read gzipped dump files, you must compile LAMMPS with the
--DLAMMPS_GZIP option - see the "Making
-LAMMPS"_Section_start.html#start_2 section of the documentation.
+-DLAMMPS_GZIP option. See the "Build settings"_Build_settings.html
+doc page for details.
The {molfile} dump file formats are part of the USER-MOLFILE package.
They are only enabled if LAMMPS was built with that packages. See the
-"Making LAMMPS"_Section_start.html#start_3 section for more info.
+"Build package"_Build_package.html doc page for more info.
[Related commands:]
diff --git a/doc/src/read_restart.txt b/doc/src/read_restart.txt
index a5a2bfcc9743d7402eeb57bfa3dcda678f357829..08cb6a2e6cc459351e5b7598c95bcbabe939e2b1 100644
--- a/doc/src/read_restart.txt
+++ b/doc/src/read_restart.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -76,13 +76,11 @@ different than if the run had continued. These pair styles include
If a restarted run is immediately different than the run which
produced the restart file, it could be a LAMMPS bug, so consider
-"reporting it"_Section_errors.html#err_2 if you think the behavior is
-wrong.
+"reporting it"_Errors_bugs.html if you think the behavior is a bug.
Because restart files are binary, they may not be portable to other
machines. In this case, you can use the "-restart command-line
-switch"_Section_start.html#start_6 to convert a restart file to a data
-file.
+switch"_Run_options.html to convert a restart file to a data file.
Similar to how restart files are written (see the
"write_restart"_write_restart.html and "restart"_restart.html
diff --git a/doc/src/region.txt b/doc/src/region.txt
index 5039e4a51615164a410bd85ff6572ac41d3a8bf6..acc85dcebbd89986d59da3f09a59ea45bf35ee29 100644
--- a/doc/src/region.txt
+++ b/doc/src/region.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -186,9 +186,9 @@ functions, and include "thermo_style"_thermo_style.html command
keywords for the simulation box parameters and timestep and elapsed
time. Thus it is easy to specify a time-dependent radius.
-See "Section 6.12"_Section_howto.html#howto_12 of the doc pages
-for a geometric description of triclinic boxes, as defined by LAMMPS,
-and how to transform these parameters to and from other commonly used
+See the "Howto tricilinc"_Howto_triclinic.html doc page for a
+geometric description of triclinic boxes, as defined by LAMMPS, and
+how to transform these parameters to and from other commonly used
triclinic representations.
The {union} style creates a region consisting of the volume of all the
@@ -358,28 +358,28 @@ sub-regions can be defined with the {open} keyword.
:line
-Styles with a {kk} suffix are functionally the same as the
-corresponding style without the suffix. They have been optimized to
-run faster, depending on your available hardware, as discussed in
-"Section 5"_Section_accelerate.html of the manual. The
-accelerated styles take the same arguments and should produce the same
-results, except for round-off and precision issues.
+Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
+functionally the same as the corresponding style without the suffix.
+They have been optimized to run faster, depending on your available
+hardware, as discussed on the "Speed packages"_Speed_packages.html doc
+page. The accelerated styles take the same arguments and should
+produce the same results, except for round-off and precision issues.
The code using the region (such as a fix or compute) must also be supported
by Kokkos or no acceleration will occur. Currently, only {block} style
regions are supported by Kokkos.
These accelerated styles are part of the Kokkos package. They are
-only enabled if LAMMPS was built with that package. See the "Making
-LAMMPS"_Section_start.html#start_3 section for more info.
+only enabled if LAMMPS was built with that package. See the "Build
+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
-use the "suffix"_suffix.html command in your input script.
+switch"_Run_options.html when you invoke LAMMPS, or you can use the
+"suffix"_suffix.html command in your input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
diff --git a/doc/src/replicate.txt b/doc/src/replicate.txt
index 08523ecdd848a58ff04b8b63747fcd6c5c388914..0195dce9114f4a3d0bf30a805a1c0f0e31a70be7 100644
--- a/doc/src/replicate.txt
+++ b/doc/src/replicate.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/rerun.txt b/doc/src/rerun.txt
index edf94cc711c2e5a1ff7b34efed059b7e77327981..71ad464bb0015a109bca2f812ac8fe289d99c1b2 100644
--- a/doc/src/rerun.txt
+++ b/doc/src/rerun.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -189,8 +189,8 @@ every 1000 steps, then you will only see thermodynamic output every
[Restrictions:]
To read gzipped dump files, you must compile LAMMPS with the
--DLAMMPS_GZIP option - see the "Making
-LAMMPS"_Section_start.html#start_2 section of the documentation.
+-DLAMMPS_GZIP option. See the "Build settings"_Build_settings.html
+doc page for details.
[Related commands:]
diff --git a/doc/src/reset_ids.txt b/doc/src/reset_ids.txt
index 8655a9d54f3c5b0f7e97512f6553dd6246bfa321..391b51fde99e167d813bef98b3a62f96786ed1de 100644
--- a/doc/src/reset_ids.txt
+++ b/doc/src/reset_ids.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/reset_timestep.txt b/doc/src/reset_timestep.txt
index 79a5812ca1f2a569c23d71e48a6dc8ffcc89d002..0d518655fb774108eb95da66297d854300d945b5 100644
--- a/doc/src/reset_timestep.txt
+++ b/doc/src/reset_timestep.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/restart.txt b/doc/src/restart.txt
index 7c39ae1404eebb9c70d1c7a99730d00200a25af2..7c034f36e0c6d002739c35362afca8440f9358a5 100644
--- a/doc/src/restart.txt
+++ b/doc/src/restart.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -125,8 +125,7 @@ Restart files can be read by a "read_restart"_read_restart.html
command to restart a simulation from a particular state. Because the
file is binary (to enable exact restarts), it may not be readable on
another machine. In this case, you can use the "-r command-line
-switch"_Section_start.html#start_6 to convert a restart file to a data
-file.
+switch"_Run_options.html to convert a restart file to a data file.
NOTE: Although the purpose of restart files is to enable restarting a
simulation from where it left off, not all information about a
diff --git a/doc/src/run.txt b/doc/src/run.txt
index 311560d66b57585c0dfb9e0fae8c64d8f39ea236..c7c73463d92d49bb8e72ca9b549e38d50960f67a 100644
--- a/doc/src/run.txt
+++ b/doc/src/run.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -126,11 +126,10 @@ and interleaving commands in your input script. For example, a
be redefined, e.g. to reset a thermostat temperature. Or this could
be useful for invoking a command you have added to LAMMPS that wraps
some other code (e.g. as a library) to perform a computation
-periodically during a long LAMMPS run. See "this
-section"_Section_modify.html of the documentation for info about how
-to add new commands to LAMMPS. See "this
-section"_Section_howto.html#howto_10 of the documentation for ideas
-about how to couple LAMMPS to other codes.
+periodically during a long LAMMPS run. See the "Modify"_Modify.html
+doc page for info about how to add new commands to LAMMPS. See the
+"Howto couple"_Howto_couple.html doc page for ideas about how to
+couple LAMMPS to other codes.
With the {every} option, N total steps are simulated, in shorter runs
of M steps each. After each M-length run, the specified commands are
diff --git a/doc/src/run_style.txt b/doc/src/run_style.txt
index ba836a07dd1510b48e48ad5c8f2714bd5c6252b9..6dd9b56908960bbbe820bcd7f2667a3faf158a73 100644
--- a/doc/src/run_style.txt
+++ b/doc/src/run_style.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -69,8 +69,8 @@ The {verlet} style is a standard velocity-Verlet integrator.
The {verlet/split} style is also a velocity-Verlet integrator, but it
splits the force calculation within each timestep over 2 partitions of
-processors. See "Section 2.6"_Section_start.html#start_6 for an
-explanation of the -partition command-line switch.
+processors. See the "-partition command-line switch"_Run_options.html
+for info on how to run LAMMPS with multiple partitions.
Specifically, this style performs all computation except the
"kspace_style"_kspace_style.html portion of the force field on the 1st
@@ -115,17 +115,17 @@ When you run in 2-partition mode with the {verlet/split} style, the
thermodynamic data for the entire simulation will be output to the log
and screen file of the 1st partition, which are log.lammps.0 and
screen.0 by default; see the "-plog and -pscreen command-line
-switches"_Section_start.html#start_6 to change this. The log and
-screen file for the 2nd partition will not contain thermodynamic
-output beyond the 1st timestep of the run.
-
-See "Section 5"_Section_accelerate.html of the manual for
-performance details of the speed-up offered by the {verlet/split}
-style. One important performance consideration is the assignment of
-logical processors in the 2 partitions to the physical cores of a
-parallel machine. The "processors"_processors.html command has
-options to support this, and strategies are discussed in
-"Section 5"_Section_accelerate.html of the manual.
+switches"_Run_options.html to change this. The log and screen file
+for the 2nd partition will not contain thermodynamic output beyond the
+1st timestep of the run.
+
+See the "Speed packages"_Speed_packages.html doc page for performance
+details of the speed-up offered by the {verlet/split} style. One
+important performance consideration is the assignment of logical
+processors in the 2 partitions to the physical cores of a parallel
+machine. The "processors"_processors.html command has options to
+support this, and strategies are discussed in "Section
+5"_Speed.html of the manual.
:line
@@ -138,13 +138,19 @@ iterations of level 1 for a single iteration of level 2, N2 is the
iterations of level 2 per iteration of level 3, etc. N-1 looping
parameters must be specified.
-The "timestep"_timestep.html command sets the timestep for the
-outermost rRESPA level. Thus if the example command above for a
-4-level rRESPA had an outer timestep of 4.0 fmsec, the inner timestep
-would be 8x smaller or 0.5 fmsec. All other LAMMPS commands that
-specify number of timesteps (e.g. "neigh_modify"_neigh_modify.html
-parameters, "dump"_dump.html every N timesteps, etc) refer to the
-outermost timesteps.
+Thus with a 4-level respa setting of "2 2 2" for the 3 loop factors,
+you could choose to have bond interactions computed 8x per large
+timestep, angle interactions computed 4x, pair interactions computed
+2x, and long-range interactions once per large timestep.
+
+The "timestep"_timestep.html command sets the large timestep for the
+outermost rRESPA level. Thus if the 3 loop factors are "2 2 2" for
+4-level rRESPA, and the outer timestep is set to 4.0 fmsec, then the
+inner timestep would be 8x smaller or 0.5 fmsec. All other LAMMPS
+commands that specify number of timesteps (e.g. "thermo"_thermo.html
+for thermo output every N steps, "neigh_modify
+delay/every"_neigh_modify.html parameters, "dump"_dump.html every N
+steps, etc) refer to the outermost timesteps.
The rRESPA keywords enable you to specify at what level of the
hierarchy various forces will be computed. If not specified, the
@@ -167,11 +173,17 @@ have their force go ramped to 0.0 so the overlap with the next regime
compute forces for all pairs from 5.0 outward, with those from 5.0 to
6.0 having their value ramped in an inverse manner.
-Only some pair potentials support the use of the {inner} and {middle}
-and {outer} keywords. If not, only the {pair} keyword can be used
-with that pair style, meaning all pairwise forces are computed at the
-same rRESPA level. See the doc pages for individual pair styles for
-details.i
+Note that you can use {inner} and {outer} without using {middle} to
+split the pairwise computations into two portions instead of three.
+Unless you are using a very long pairwise cutoff, a 2-way split is
+often faster than a 3-way split, since it avoids too much duplicate
+computation of pairwise interactions near the intermediate cutoffs.
+
+Also note that only a few pair potentials support the use of the
+{inner} and {middle} and {outer} keywords. If not, only the {pair}
+keyword can be used with that pair style, meaning all pairwise forces
+are computed at the same rRESPA level. See the doc pages for
+individual pair styles for details.
Another option for using pair potentials with rRESPA is with the
{hybrid} keyword, which requires the use of the "pair_style hybrid or
@@ -238,42 +250,54 @@ roughly a 1.5 fold speedup over the {verlet} style with SHAKE and a
For non-biomolecular simulations, the {respa} style can be
advantageous if there is a clear separation of time scales - fast and
-slow modes in the simulation. Even a LJ system can benefit from
-rRESPA if the interactions are divided by the inner, middle and outer
-keywords. A 2-fold or more speedup can be obtained while maintaining
-good energy conservation. In real units, for a pure LJ fluid at
-liquid density, with a sigma of 3.0 angstroms, and epsilon of 0.1
-Kcal/mol, the following settings seem to work well:
+slow modes in the simulation. For example, a system of slowly-moving
+charged polymer chains could be setup as follows:
+
+timestep 4.0
+run_style respa 2 8 :pre
+
+This is two-level rRESPA with an 8x difference between the short and
+long timesteps. The bonds, angles, dihedrals will be computed every
+0.5 fs (assuming real units), while the pair and kspace interactions
+will be computed once every 4 fs. These are the default settings for
+each kind of interaction, so no additional keywords are necessary.
+
+Even a LJ system can benefit from rRESPA if the interactions are
+divided by the inner, middle and outer keywords. A 2-fold or more
+speedup can be obtained while maintaining good energy conservation.
+In real units, for a pure LJ fluid at liquid density, with a sigma of
+3.0 angstroms, and epsilon of 0.1 Kcal/mol, the following settings
+seem to work well:
timestep 36.0
run_style respa 3 3 4 inner 1 3.0 4.0 middle 2 6.0 7.0 outer 3 :pre
:line
-The {respa/omp} styles is a variant of {respa} adapted for use with
+The {respa/omp} style is a variant of {respa} adapted for use with
pair, bond, angle, dihedral, improper, or kspace styles with an {omp}
-suffix. It is functionally equivalent to {respa} but performs additional
-operations required for managing {omp} styles. For more on {omp} styles
-see the "Section 5"_Section_accelerate.html of the manual.
-Accelerated styles take the same arguments and should produce the same
-results, except for round-off and precision issues.
+suffix. It is functionally equivalent to {respa} but performs
+additional operations required for managing {omp} styles. For more on
+{omp} styles see the "Speed omp"_Speed_omp.html doc page. Accelerated
+styles take the same arguments and should produce the same results,
+except for round-off and precision issues.
-You can specify {respa/omp} explicitly in your input script, or
-you can use the "-suffix command-line switch"_Section_start.html#start_6
-when you invoke LAMMPS, or you can use the "suffix"_suffix.html
-command in your input script.
+You can specify {respa/omp} explicitly in your input script, or you
+can use the "-suffix command-line switch"_Run_options.html when you
+invoke LAMMPS, or you can use the "suffix"_suffix.html command in your
+input script.
-See "Section 5"_Section_accelerate.html of the manual for
-more instructions on how to use the accelerated styles effectively.
+See the "Speed packages"_Speed_packages.html doc page for more
+instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
The {verlet/split} style can only be used if LAMMPS was built with the
-REPLICA package. Correspondingly the {respa/omp} style is available only
-if the USER-OMP package was included. See the "Making LAMMPS"_Section_start.html#start_3
-section for more info on packages.
+REPLICA package. Correspondingly the {respa/omp} style is available
+only if the USER-OMP package was included. See the "Build
+package"_Build_package.html doc page for more info.
Whenever using rRESPA, the user should experiment with trade-offs in
speed and accuracy for their system, and verify that they are
@@ -287,6 +311,17 @@ conserving energy to adequate precision.
run_style verlet :pre
+For run_style respa, the default assignment of interactions
+to rRESPA levels is as follows:
+
+bond forces = level 1 (innermost loop)
+angle forces = same level as bond forces
+dihedral forces = same level as angle forces
+improper forces = same level as dihedral forces
+pair forces = leven N (outermost level)
+kspace forces = same level as pair forces
+inner, middle, outer forces = no default :ul
+
:line
:link(Tuckerman3)
diff --git a/doc/src/set.txt b/doc/src/set.txt
index 4757d1c5758f9ed027a9932c07452ddcc2567f95..b83ad54f4e5fbef3b26a01372e0f3d959db90c9a 100644
--- a/doc/src/set.txt
+++ b/doc/src/set.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -17,6 +17,7 @@ ID = atom ID range or type range or mol ID range or group ID or region ID :l
one or more keyword/value pairs may be appended :l
keyword = {type} or {type/fraction} or {mol} or {x} or {y} or {z} or \
{charge} or {dipole} or {dipole/random} or {quat} or \
+ {spin} or {spin/random} or {quat} or \
{quat/random} or {diameter} or {shape} or \
{length} or {tri} or {theta} or {theta/random} or \
{angmom} or {omega} or \
@@ -35,6 +36,8 @@ keyword = {type} or {type/fraction} or {mol} or {x} or {y} or {z} or \
value can be an atom-style variable (see below)
{x},{y},{z} value = atom coordinate (distance units)
value can be an atom-style variable (see below)
+ {vx},{vy},{vz} value = atom velocity (velocity units)
+ value can be an atom-style variable (see below)
{charge} value = atomic charge (charge units)
value can be an atom-style variable (see below)
{dipole} values = x y z
@@ -43,6 +46,13 @@ keyword = {type} or {type/fraction} or {mol} or {x} or {y} or {z} or \
{dipole/random} value = seed Dlen
seed = random # seed (positive integer) for dipole moment orientations
Dlen = magnitude of dipole moment (dipole units)
+ {spin} values = g x y z
+ g = magnitude of magnetic spin vector (in Bohr magneton's unit)
+ x,y,z = orientation of magnetic spin vector
+ any of x,y,z can be an atom-style variable (see below)
+ {spin/random} value = seed Dlen
+ seed = random # seed (positive integer) for magnetic spin orientations
+ Dlen = magnitude of magnetic spin vector (in Bohr magneton's unit)
{quat} values = a b c theta
a,b,c = unit vector to rotate particle around via right-hand rule
theta = rotation angle (degrees)
@@ -119,6 +129,7 @@ set type 3 charge 0.5
set type 1*3 charge 0.5
set atom * charge v_atomfile
set atom 100*200 x 0.5 y 1.0
+set atom 100 vx 0.0 vy 0.0 vz -1.0
set atom 1492 type 3 :pre
[Description:]
@@ -217,7 +228,8 @@ IDs.
Keywords {x}, {y}, {z}, and {charge} set the coordinates or charge of
all selected atoms. For {charge}, the "atom style"_atom_style.html
-being used must support the use of atomic charge.
+being used must support the use of atomic charge. Keywords {vx}, {vy},
+and {vz} set the velocities of all selected atoms.
Keyword {dipole} uses the specified x,y,z values as components of a
vector to set as the orientation of the dipole moment vectors of the
@@ -232,6 +244,15 @@ the orientation of a particular atom is the same, regardless of how
many processors are being used. This keyword does not allow use of an
atom-style variable.
+Keyword {spin} uses the specified g value to set the magnitude of the
+magnetic spin vectors, and the x,y,z values as components of a vector
+to set as the orientation of the magnetic spin vectors of the selected
+atoms.
+
+Keyword {spin/random} randomizes the orientation of the magnetic spin
+vectors for the selected atoms and sets the magnitude of each to the
+specified {Dlen} value.
+
Keyword {quat} uses the specified values to create a quaternion
(4-vector) that represents the orientation of the selected atoms. The
particles must define a quaternion for their orientation
diff --git a/doc/src/shell.txt b/doc/src/shell.txt
index 205164f874173abd4de45b045e91ec741092acb9..d274f498e595c5abcfca59c182bd36c827016c90 100644
--- a/doc/src/shell.txt
+++ b/doc/src/shell.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/special_bonds.txt b/doc/src/special_bonds.txt
index 1021c4856b02cc7cb91901d429eb8c1fc2ca22c4..a57b61664d56e76b28d3aad9f2059bdbb24a9c31 100644
--- a/doc/src/special_bonds.txt
+++ b/doc/src/special_bonds.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/suffix.txt b/doc/src/suffix.txt
index 74f69b6dfe96296259f536c80e621b23b89edef1..62e41ed29a10a1a7d077cbbbef7074fdb45412c5 100644
--- a/doc/src/suffix.txt
+++ b/doc/src/suffix.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -28,16 +28,16 @@ suffix kk :pre
This command allows you to use variants of various styles if they
exist. In that respect it operates the same as the "-suffix
-command-line switch"_Section_start.html#start_6. It also has options
-to turn off or back on any suffix setting made via the command line.
+command-line switch"_Run_options.html. It also has options to turn
+off or back on any suffix setting made via the command line.
The specified style can be {gpu}, {intel}, {kk}, {omp}, {opt} or
{hybrid}. These refer to optional packages that LAMMPS can be built
-with, as described in "this section of the
-manual"_Section_start.html#start_3. The "gpu" style corresponds to
-the GPU package, the "intel" style to the USER-INTEL package, the "kk"
-style to the KOKKOS package, the "omp" style to the USER-OMP package,
-and the "opt" style to the OPT package.
+with, as described on the "Build package"_Build_package.html doc page.
+The "gpu" style corresponds to the GPU package, the "intel" style to
+the USER-INTEL package, the "kk" style to the KOKKOS package, the
+"omp" style to the USER-OMP package, and the "opt" style to the OPT
+package.
These are the variants these packages provide:
@@ -105,6 +105,6 @@ input script.
[Related commands:]
-"Command-line switch -suffix"_Section_start.html#start_6
+"-suffix command-line switch"_Run_options.html
[Default:] none
diff --git a/doc/src/tad.txt b/doc/src/tad.txt
index f5e7c6d6537cc50d6e3905249b847cca20cc7eed..9b34a68636c1eaa0b37ddbc9dce9ca6a5f61bd27 100644
--- a/doc/src/tad.txt
+++ b/doc/src/tad.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -92,9 +92,8 @@ restricts you to having exactly one processor per replica. For more
information, see the documentation for the "neb"_neb.html command. In
the current LAMMPS implementation of TAD, all the non-NEB TAD
operations are performed on the first partition, while the other
-partitions remain idle. See "Section
-6.5"_Section_howto.html#howto_5 of the manual for further discussion of
-multi-replica simulations.
+partitions remain idle. See the "Howto replica"_Howto_replica.html doc
+page for further discussion of multi-replica simulations.
A TAD run has several stages, which are repeated each time an event is
performed. The logic for a TAD run is as follows:
@@ -272,8 +271,8 @@ are always monotonically increasing.
[Restrictions:]
This command can only be used if LAMMPS was built with the REPLICA
-package. See the "Making LAMMPS"_Section_start.html#start_3 section
-for more info on packages.
+package. See the "Build package"_Build_package.html doc
+page for more info.
{N} setting must be integer multiple of {t_event}.
diff --git a/doc/src/temper.txt b/doc/src/temper.txt
index b1c47c8076e1affde9b4c4ecc45c89148ddbd412..edd578fbc93449e4d3eb3e0c4fb15dad6bad507f 100644
--- a/doc/src/temper.txt
+++ b/doc/src/temper.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -31,15 +31,14 @@ Run a parallel tempering or replica exchange simulation using multiple
replicas (ensembles) of a system. Two or more replicas must be used.
Each replica runs on a partition of one or more processors. Processor
-partitions are defined at run-time using the -partition command-line
-switch; see "Section 2.6"_Section_start.html#start_6 of the
-manual. Note that if you have MPI installed, you can run a
-multi-replica simulation with more replicas (partitions) than you have
-physical processors, e.g you can run a 10-replica simulation on one or
-two processors. You will simply not get the performance speed-up you
-would see with one or more physical processors per replica. See "this
-section"_Section_howto.html#howto_5 of the manual for further
-discussion.
+partitions are defined at run-time using the "-partition command-line
+switch"_Run_options.html. Note that if you have MPI installed, you
+can run a multi-replica simulation with more replicas (partitions)
+than you have physical processors, e.g you can run a 10-replica
+simulation on one or two processors. You will simply not get the
+performance speed-up you would see with one or more physical
+processors per replica. See the "Howto replica"_Howto_replica.html
+doc page for further discussion.
Each replica's temperature is controlled at a different value by a fix
with {fix-ID} that controls temperature. Most thermostat fix styles
@@ -69,9 +68,8 @@ rejected based on a Boltzmann-weighted Metropolis criterion which uses
As a tempering run proceeds, multiple log files and screen output
files are created, one per replica. By default these files are named
log.lammps.M and screen.M where M is the replica number from 0 to N-1,
-with N = # of replicas. See the "section on command-line
-switches"_Section_start.html#start_6 for info on how to change these
-names.
+with N = # of replicas. See the "-log and -screen command-line
+swiches"_Run_options.html for info on how to change these names.
The main screen and log file (log.lammps) will list information about
which temperature is assigned to each replica at each thermodynamic
@@ -139,8 +137,8 @@ example above with $w as the last argument.
[Restrictions:]
This command can only be used if LAMMPS was built with the REPLICA
-package. See the "Making LAMMPS"_Section_start.html#start_3 section
-for more info on packages.
+package. See the "Build package"_Build_package.html doc
+page for more info.
[Related commands:]
diff --git a/doc/src/temper_grem.txt b/doc/src/temper_grem.txt
index 6145c8704cc131b96d21464031c9697733be02d1..7d22e464032dc8dbf93580eb33779f16b068c37e 100644
--- a/doc/src/temper_grem.txt
+++ b/doc/src/temper_grem.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -94,8 +94,8 @@ identical to "temper"_temper.html.
[Restrictions:]
This command can only be used if LAMMPS was built with the USER-MISC
-package. See the "Making LAMMPS"_Section_start.html#start_3 section
-for more info on packages.
+package. See the "Build package"_Build_package.html doc
+page for more info.
This command must be used with "fix grem"_fix_grem.html.
diff --git a/doc/src/temper_npt.txt b/doc/src/temper_npt.txt
index 4ad49f9e3327ded89da41c2fd405929175990a67..50ac5615f69ad6ca5282fa959db24ad231612274 100644
--- a/doc/src/temper_npt.txt
+++ b/doc/src/temper_npt.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
temper/npt command :h3
@@ -48,8 +48,8 @@ on how the parallel tempering is handled in general.
[Restrictions:]
This command can only be used if LAMMPS was built with the USER-MISC
-package. See the "Making LAMMPS"_Section_start.html#start_3 section
-for more info on packages.
+package. See the "Build package"_Build_package.html doc page for more
+info.
This command should be used with a fix that maintains the
isothermal-isobaric (NPT) ensemble.
diff --git a/doc/src/thermo.txt b/doc/src/thermo.txt
index 1d5d34995cd3cc979f3537b529950032be2ea4ba..5f12f987076bc54f50df9cbd5f37aa9c2be40b7e 100644
--- a/doc/src/thermo.txt
+++ b/doc/src/thermo.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/thermo_modify.txt b/doc/src/thermo_modify.txt
index e9aca0f20a1b2ed5c2d90ec3a70714c2dea25bf4..ca2957de776a5d3054da85a0eddfbcaad25bedf9 100644
--- a/doc/src/thermo_modify.txt
+++ b/doc/src/thermo_modify.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/thermo_style.txt b/doc/src/thermo_style.txt
index 6102169ee363ca2bdb9dc41d1663f9c1dcb442aa..4d294c1df7b4c6d6a364448304c535ba7d44b950 100644
--- a/doc/src/thermo_style.txt
+++ b/doc/src/thermo_style.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -108,12 +108,11 @@ Style {custom} is the most general setting and allows you to specify
which of the keywords listed above you want printed on each
thermodynamic timestep. Note that the keywords c_ID, f_ID, v_name are
references to "computes"_compute.html, "fixes"_fix.html, and
-equal-style "variables"_variable.html that have been defined
-elsewhere in the input script or can even be new styles which users
-have added to LAMMPS (see the "Section 10"_Section_modify.html
-section of the documentation). Thus the {custom} style provides a
-flexible means of outputting essentially any desired quantity as a
-simulation proceeds.
+equal-style "variables"_variable.html that have been defined elsewhere
+in the input script or can even be new styles which users have added
+to LAMMPS. See the "Modify"_Modify.html doc page for details on the
+latter. Thus the {custom} style provides a flexible means of
+outputting essentially any desired quantity as a simulation proceeds.
All styles except {custom} have {vol} appended to their list of
outputs if the simulation box volume changes during the simulation.
@@ -254,9 +253,9 @@ proceed for the maximum number of allowed iterations.
The {part} keyword is useful for multi-replica or multi-partition
simulations to indicate which partition this output and this file
corresponds to, or for use in a "variable"_variable.html to append to
-a filename for output specific to this partition. See "Section
-2.6"_Section_start.html#start_6 of the manual for details on running
-in multi-partition mode.
+a filename for output specific to this partition. See discussion of
+the "-partition command-line switch"_Run_options.html for details on
+running in multi-partition mode.
The {timeremain} keyword returns the remaining seconds when a
timeout has been configured via the "timer timeout"_timer.html command.
@@ -287,11 +286,11 @@ takes place.
The keywords {cella}, {cellb}, {cellc}, {cellalpha}, {cellbeta},
{cellgamma}, correspond to the usual crystallographic quantities that
-define the periodic unit cell of a crystal. See "this
-section"_Section_howto.html#howto_12 of the doc pages for a geometric
-description of triclinic periodic cells, including a precise definition
-of these quantities in terms of the internal LAMMPS cell dimensions
-{lx}, {ly}, {lz}, {yz}, {xz}, {xy}.
+define the periodic unit cell of a crystal. See the "Howto
+triclinic"_Howto_triclinic.html doc page for a geometric description
+of triclinic periodic cells, including a precise definition of these
+quantities in terms of the internal LAMMPS cell dimensions {lx}, {ly},
+{lz}, {yz}, {xz}, {xy}.
:line
diff --git a/doc/src/timer.txt b/doc/src/timer.txt
index 768c3e1353fb3e6495f63f2d84830c060b4bf74a..4025af9ea623a0de7e9a13b5b7994387e76fb58d 100644
--- a/doc/src/timer.txt
+++ b/doc/src/timer.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -39,8 +39,8 @@ During a simulation run LAMMPS collects information about how much
time is spent in different sections of the code and thus can provide
information for determining performance and load imbalance problems.
This can be done at different levels of detail and accuracy. For more
-information about the timing output, see this "discussion of screen
-output in Section 2.7"_Section_start.html#start_7.
+information about the timing output, see the "Run
+output"_Run_output.html doc page.
The {off} setting will turn all time measurements off. The {loop}
setting will only measure the total time for a run and not collect any
diff --git a/doc/src/timestep.txt b/doc/src/timestep.txt
index 639ad6f31136ff9a34f085b8d254b983a9e1ba4d..ee0ace05b9cf7397539cf615e4a87217270f4949 100644
--- a/doc/src/timestep.txt
+++ b/doc/src/timestep.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/tutorials.txt b/doc/src/tutorials.txt
deleted file mode 100644
index 338439ac8e9387c080e8bfd32bf237e85984ec0e..0000000000000000000000000000000000000000
--- a/doc/src/tutorials.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-Tutorials :h1
-
-<!-- RST
-
-.. toctree::
- :maxdepth: 1
-
- tutorial_drude
- tutorial_github
- tutorial_pylammps
- tutorial_bash_on_windows
- body
- manifolds
-
-END_RST -->
diff --git a/doc/src/uncompute.txt b/doc/src/uncompute.txt
index 49b46781d7ac363156674ef935881dacab2e048f..4c788d472207b302a51f73abddaf34803cae5062 100644
--- a/doc/src/uncompute.txt
+++ b/doc/src/uncompute.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/undump.txt b/doc/src/undump.txt
index a2a371aca5187a9248e8e33e33792087040a66e7..cc3d8b9103ffd2d9eff33bf3dbaefda820c29903 100644
--- a/doc/src/undump.txt
+++ b/doc/src/undump.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/unfix.txt b/doc/src/unfix.txt
index dcc4499b20b4b784779f9038b30c541a5585335e..9608b39c7e2c2056023b9da6607b8e280ed52a11 100644
--- a/doc/src/unfix.txt
+++ b/doc/src/unfix.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/units.txt b/doc/src/units.txt
index 0b856dcc68b67a9f7df9f159e779f8fb5a097379..8df8fe6810ec1163f366a7e53ad4f019418425da 100644
--- a/doc/src/units.txt
+++ b/doc/src/units.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/variable.txt b/doc/src/variable.txt
index 717c77c07908099a76f4f32991697bfcb8294bc6..a8d50503ac96bb6ea49041c6469449ae9438ee05 100644
--- a/doc/src/variable.txt
+++ b/doc/src/variable.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -124,8 +124,8 @@ provide, so that the variable gets its value from the evaluation of
the Python code. Variables of style {internal} are used by a few
commands which set their value directly.
-NOTE: As discussed in "Section 3.2"_Section_commands.html#cmd_2 of the
-manual, an input script can use "immediate" variables, specified as
+NOTE: As discussed on the "Commands parse"_Commands_parse.html doc
+page, an input script can use "immediate" variables, specified as
$(formula) with parenthesis, where the formula has the same syntax as
equal-style variables described on this page. This is a convenient
way to evaluate a formula immediately without using the variable
@@ -178,9 +178,8 @@ This means variables can NOT be re-defined in an input script (with
two exceptions, read further). This is to allow an input script to be
processed multiple times without resetting the variables; see the
"jump"_jump.html or "include"_include.html commands. It also means
-that using the "command-line switch"_Section_start.html#start_6 -var
-will override a corresponding index variable setting in the input
-script.
+that using the "command-line switch"_Run_options.html -var will
+override a corresponding index variable setting in the input script.
There are two exceptions to this rule. First, variables of style
{string}, {getenv}, {internal}, {equal}, {vector}, {atom}, and
@@ -198,7 +197,7 @@ the same thing.
:line
-"This section"_Section_commands.html#cmd_2 of the manual explains how
+The "Commands parse"_Commands_parse.html doc page explains how
occurrences of a variable name in an input script line are replaced by
the variable's string. The variable name can be referenced as $x if
the name "x" is a single character, or as $\{LoopVar\} if the name
@@ -247,8 +246,7 @@ string is assigned. All processors assign the same string to the
variable.
{Index} style variables with a single string value can also be set by
-using the command-line switch -var; see "this
-section"_Section_start.html#start_6 for details.
+using the "command-line switch -var"_Run_options.html.
The {loop} style is identical to the {index} style except that the
strings are the integers from 1 to N inclusive, if only one argument N
@@ -263,32 +261,31 @@ inclusive, and the string N1 is initially assigned to the variable.
N1 <= N2 and N2 >= 0 is required.
For the {world} style, one or more strings are specified. There must
-be one string for each processor partition or "world". See "this
-section"_Section_start.html#start_6 of the manual for information on
-running LAMMPS with multiple partitions via the "-partition"
-command-line switch. This variable command assigns one string to each
-world. All processors in the world are assigned the same string. The
-next command cannot be used with {equal} style variables, since there
-is only one value per world. This style of variable is useful when
-you wish to run different simulations on different partitions, or when
-performing a parallel tempering simulation (see the
+be one string for each processor partition or "world". LAMMPS can be
+run with multiple partitions via the "-partition command-line
+switch"_Run_options.html. This variable command assigns one string to
+each world. All processors in the world are assigned the same string.
+The next command cannot be used with {equal} style variables, since
+there is only one value per world. This style of variable is useful
+when you wish to run different simulations on different partitions, or
+when performing a parallel tempering simulation (see the
"temper"_temper.html command), to assign different temperatures to
different partitions.
For the {universe} style, one or more strings are specified. There
must be at least as many strings as there are processor partitions or
-"worlds". See "this page"_Section_start.html#start_6 for information
-on running LAMMPS with multiple partitions via the "-partition"
-command-line switch. This variable command initially assigns one
-string to each world. When a "next"_next.html command is encountered
-using this variable, the first processor partition to encounter it, is
-assigned the next available string. This continues until all the
-variable strings are consumed. Thus, this command can be used to run
-50 simulations on 8 processor partitions. The simulations will be run
-one after the other on whatever partition becomes available, until
-they are all finished. {Universe} style variables are incremented
-using the files "tmp.lammps.variable" and "tmp.lammps.variable.lock"
-which you will see in your directory during such a LAMMPS run.
+"worlds". LAMMPS can be run with multiple partitions via the
+"-partition command-line switch"_Run_options.html. This variable
+command initially assigns one string to each world. When a
+"next"_next.html command is encountered using this variable, the first
+processor partition to encounter it, is assigned the next available
+string. This continues until all the variable strings are consumed.
+Thus, this command can be used to run 50 simulations on 8 processor
+partitions. The simulations will be run one after the other on
+whatever partition becomes available, until they are all finished.
+{Universe} style variables are incremented using the files
+"tmp.lammps.variable" and "tmp.lammps.variable.lock" which you will
+see in your directory during such a LAMMPS run.
The {uloop} style is identical to the {universe} style except that the
strings are the integers from 1 to N. This allows generation of long
@@ -312,8 +309,8 @@ If you simply wish to print a variable value with desired precision to
the screen or logfile via the "print"_print.html or "fix
print"_fix_print.html commands, you can also do this by specifying an
"immediate" variable with a trailing colon and format string, as part
-of the string argument of those commands. This is explained in
-"Section 3.2"_Section_commands.html#cmd_2.
+of the string argument of those commands. This is explained on the
+"Commands parse"_Commands_parse.html doc page.
For the {getenv} style, a single string is assigned to the variable
which should be the name of an environment variable. When the
@@ -1119,24 +1116,23 @@ Vectors" discussion above.
If you want an equal-style variable to be evaluated immediately, it
may be the case that you do not need to define a variable at all. See
-"Section 3.2"_Section_commands.html#cmd_2 of the manual, which
-describes the use of "immediate" variables in an input script,
-specified as $(formula) with parenthesis, where the formula has the
-same syntax as equal-style variables described on this page. This
-effectively evaluates a formula immediately without using the variable
-command to define a named variable.
+the "Commands parse"_Commands_parse.html doc page for info on how to
+use "immediate" variables in an input script, specified as $(formula)
+with parenthesis, where the formula has the same syntax as equal-style
+variables described on this page. This effectively evaluates a
+formula immediately without using the variable command to define a
+named variable.
More generally, there is a difference between referencing a variable
with a leading $ sign (e.g. $x or $\{abc\}) versus with a leading "v_"
(e.g. v_x or v_abc). The former can be used in any input script
command, including a variable command. The input script parser
evaluates the reference variable immediately and substitutes its value
-into the command. As explained in "Section
-3.2"_Section_commands.html#cmd_2 for "Parsing rules", you can also use
-un-named "immediate" variables for this purpose. For example, a
-string like this $((xlo+xhi)/2+sqrt(v_area)) in an input script
-command evaluates the string between the parenthesis as an equal-style
-variable formula.
+into the command. As explained on the "Commands
+parse"_Commands_parse.html doc page, you can also use un-named
+"immediate" variables for this purpose. For example, a string like
+this $((xlo+xhi)/2+sqrt(v_area)) in an input script command evaluates
+the string between the parenthesis as an equal-style variable formula.
Referencing a variable with a leading "v_" is an optional or required
kind of argument for some commands (e.g. the "fix
@@ -1180,10 +1176,9 @@ quotes if it contains variables preceded by $ signs. For example,
variable vratio equal "$\{vfinal\}/$\{v0\}" :pre
-This is because the quotes prevent variable substitution (see "this
-section"_Section_commands.html#cmd_2 on parsing input script
-commands), and thus an error will occur when the formula for "vratio"
-is evaluated later.
+This is because the quotes prevent variable substitution (explained on
+the "Commands parse"_Commands_parse.html doc page), and thus an error
+will occur when the formula for "vratio" is evaluated later.
:line
diff --git a/doc/src/velocity.txt b/doc/src/velocity.txt
index b8299a5acfc1576484c8f3683eba5eb9e947e4d0..96d3fa6dc4fa53e1b7d399fc2d774afbff682de5 100644
--- a/doc/src/velocity.txt
+++ b/doc/src/velocity.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -139,10 +139,9 @@ if rot = yes, the angular momentum is zeroed.
If specified, the {temp} keyword is used by {create} and {scale} to
specify a "compute"_compute.html that calculates temperature in a
desired way, e.g. by first subtracting out a velocity bias, as
-discussed in "Section 6.16"_Section_howto.html#howto_16 of the doc
-pages. If this keyword is not specified, {create} and {scale}
-calculate temperature using a compute that is defined internally as
-follows:
+discussed on the "Howto thermostat"_Howto_thermostat.html doc page.
+If this keyword is not specified, {create} and {scale} calculate
+temperature using a compute that is defined internally as follows:
compute velocity_temp group-ID temp :pre
@@ -161,11 +160,11 @@ The {bias} keyword with a {yes} setting is used by {create} and
If the temperature compute also calculates a velocity bias, the the
bias is subtracted from atom velocities before the {create} and
{scale} operations are performed. After the operations, the bias is
-added back to the atom velocities. See "Section
-6.16"_Section_howto.html#howto_16 of the doc pages for more discussion
-of temperature computes with biases. Note that the velocity bias is
-only applied to atoms in the temperature compute specified with the
-{temp} keyword.
+added back to the atom velocities. See the "Howto
+thermostat"_Howto_thermostat.html doc page for more discussion of
+temperature computes with biases. Note that the velocity bias is only
+applied to atoms in the temperature compute specified with the {temp}
+keyword.
As an example, assume atoms are currently streaming in a flow
direction (which could be separately initialized with the {ramp}
diff --git a/doc/src/write_coeff.txt b/doc/src/write_coeff.txt
index 764e119a9d1d310ae5f969a9163d1ec5753ebe1d..5dc4b331dedbe2940286af653c81a76654cb1347 100644
--- a/doc/src/write_coeff.txt
+++ b/doc/src/write_coeff.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/write_data.txt b/doc/src/write_data.txt
index c76f20319c3182a2d9298d8aada887cb806878f3..b6002b52529a14621623a490316d751c0ad421bc 100644
--- a/doc/src/write_data.txt
+++ b/doc/src/write_data.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -60,7 +60,7 @@ If you want to do more exact restarts, using binary files, see the
"restart"_restart.html, "write_restart"_write_restart.html, and
"read_restart"_read_restart.html commands. You can also convert
binary restart files to text data files, after a simulation has run,
-using the "-r command-line switch"_Section_start.html#start_6.
+using the "-r command-line switch"_Run_options.html.
NOTE: Only limited information about a simulation is stored in a data
file. For example, no information about atom "groups"_group.html and
diff --git a/doc/src/write_dump.txt b/doc/src/write_dump.txt
index 840716085feff0aaf6b7790befc98b902be87ea3..e67697900129a153801eb53f454641075955189d 100644
--- a/doc/src/write_dump.txt
+++ b/doc/src/write_dump.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
diff --git a/doc/src/write_restart.txt b/doc/src/write_restart.txt
index ff3b652dba75feefdb3841bf764f885cc0b3a9d1..c393c7f735ece6718966ad7bf37fd31194b0408c 100644
--- a/doc/src/write_restart.txt
+++ b/doc/src/write_restart.txt
@@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
:line
@@ -66,8 +66,7 @@ Restart files can be read by a "read_restart"_read_restart.html
command to restart a simulation from a particular state. Because the
file is binary (to enable exact restarts), it may not be readable on
another machine. In this case, you can use the "-r command-line
-switch"_Section_start.html#start_6 to convert a restart file to a data
-file.
+switch"_Run_options.html to convert a restart file to a data file.
NOTE: Although the purpose of restart files is to enable restarting a
simulation from where it left off, not all information about a
diff --git a/doc/utils/converters/lammpsdoc/txt2html.py b/doc/utils/converters/lammpsdoc/txt2html.py
index 79a75d72f6e4be7796e685e7025adbef0d9eb5ff..ed9f47a4e4ae3cfe4c6363a34ab9b7deb42b8c0c 100755
--- a/doc/utils/converters/lammpsdoc/txt2html.py
+++ b/doc/utils/converters/lammpsdoc/txt2html.py
@@ -662,14 +662,15 @@ class TxtConverter:
parser = self.get_argument_parser()
parsed_args = parser.parse_args(args)
- write_to_files = len(parsed_args.files) > 1
+ write_to_files = parsed_args.output_dir or (len(parsed_args.files) > 1)
for filename in parsed_args.files:
if parsed_args.skip_files and filename in parsed_args.skip_files:
continue
with open(filename, 'r') as f:
- print("Converting", filename, "...", file=err)
+ if parsed_args.verbose:
+ print("Converting", filename, "...", file=err)
content = f.read()
converter = self.create_converter(parsed_args)
@@ -683,7 +684,10 @@ class TxtConverter:
result = msg
if write_to_files:
- output_filename = self.get_output_filename(filename)
+ if parsed_args.output_dir:
+ output_filename = os.path.join(parsed_args.output_dir, os.path.basename(self.get_output_filename(filename)))
+ else:
+ output_filename = self.get_output_filename(filename)
with open(output_filename, "w+t") as outfile:
outfile.write(result)
else:
@@ -698,6 +702,8 @@ class Txt2HtmlConverter(TxtConverter):
'HTML file. useful when set of HTML files'
' will be converted to PDF')
parser.add_argument('-x', metavar='file-to-skip', dest='skip_files', action='append')
+ parser.add_argument('--verbose', '-v', dest='verbose', action='store_true')
+ parser.add_argument('--output-directory', '-o', dest='output_dir')
parser.add_argument('--generate-title', dest='create_title', action='store_true', help='add HTML head page'
'title based on first '
'h1,h2,h3,h4... element')
diff --git a/doc/utils/converters/lammpsdoc/txt2rst.py b/doc/utils/converters/lammpsdoc/txt2rst.py
index 17d0916157a4f2d9b07ec655522ac6999b6978cb..8119ad3a7869c5345ffad166536f98ffa7bd20ba 100755
--- a/doc/utils/converters/lammpsdoc/txt2rst.py
+++ b/doc/utils/converters/lammpsdoc/txt2rst.py
@@ -395,6 +395,8 @@ class Txt2RstConverter(TxtConverter):
parser = argparse.ArgumentParser(description='converts a text file with simple formatting & markup into '
'Restructured Text for Sphinx.')
parser.add_argument('-x', metavar='file-to-skip', dest='skip_files', action='append')
+ parser.add_argument('--verbose', '-v', dest='verbose', action='store_true')
+ parser.add_argument('--output-directory', '-o', dest='output_dir')
parser.add_argument('files', metavar='file', nargs='+', help='one or more files to convert')
return parser
diff --git a/doc/utils/requirements.txt b/doc/utils/requirements.txt
new file mode 100644
index 0000000000000000000000000000000000000000..2806c164989aa9137a6c1860716ae9abccef75ad
--- /dev/null
+++ b/doc/utils/requirements.txt
@@ -0,0 +1 @@
+Sphinx
diff --git a/examples/DIFFUSE/README b/examples/DIFFUSE/README
index df2a675f73b778dd3d4fda1bafff791f2bebf4a6..e78ca2eacf1a109ec3aeb79b3b13e3444ed7d7a9 100644
--- a/examples/DIFFUSE/README
+++ b/examples/DIFFUSE/README
@@ -47,7 +47,7 @@ compute the diffusion coefficient. You can see that both measures
give roughly the same answer and rapidly become roughly constant for
the 100K step simulation.
-Dcoeff = 0.36
+Dcoeff = 0.33
(2) in.vacf.2d
@@ -58,4 +58,4 @@ that point in time, converted into the diffusion coefficient. You can
see the VACF approach gives a more noise, fluctuating value for the
diffusion coefficient, compared to the MSD approach.
-Dcoeff = 0.25 to 0.45
+Dcoeff = ~0.25
diff --git a/examples/DIFFUSE/log.13Oct16.msd.2d.g++.8 b/examples/DIFFUSE/log.13Oct16.msd.2d.g++.8
deleted file mode 100644
index 473aa565278ec6802b78373adcf4b510722c93da..0000000000000000000000000000000000000000
--- a/examples/DIFFUSE/log.13Oct16.msd.2d.g++.8
+++ /dev/null
@@ -1,245 +0,0 @@
-LAMMPS (13 Oct 2016)
-# sample LAMMPS input script for diffusion of 2d LJ liquid
-# mean-squared displacement via compute msd
-
-# settings
-
-variable x equal 40
-variable y equal 40
-
-variable rho equal 0.6
-variable t equal 1.0
-variable rc equal 2.5
-
-# problem setup
-
-units lj
-dimension 2
-atom_style atomic
-neigh_modify delay 0 every 1
-
-lattice sq2 ${rho}
-lattice sq2 0.6
-Lattice spacing in x,y,z = 1.82574 1.82574 1.82574
-region simbox block 0 $x 0 $y -0.1 0.1
-region simbox block 0 40 0 $y -0.1 0.1
-region simbox block 0 40 0 40 -0.1 0.1
-create_box 1 simbox
-Created orthogonal box = (0 0 -0.182574) to (73.0297 73.0297 0.182574)
- 4 by 2 by 1 MPI processor grid
-create_atoms 1 box
-Created 3200 atoms
-
-pair_style lj/cut ${rc}
-pair_style lj/cut 2.5
-pair_coeff * * 1 1
-
-mass * 1.0
-velocity all create $t 97287
-velocity all create 1 97287
-
-fix 1 all nve
-fix 2 all langevin $t $t 0.1 498094
-fix 2 all langevin 1 $t 0.1 498094
-fix 2 all langevin 1 1 0.1 498094
-fix 3 all enforce2d
-
-# equilibration run
-
-thermo 1000
-run 5000
-Neighbor list info ...
- 1 neighbor list requests
- update every 1 steps, delay 0 steps, check yes
- max neighbors/atom: 2000, page size: 100000
- master list distance cutoff = 2.8
- ghost atom cutoff = 2.8
- binsize = 1.4 -> bins = 53 53 1
-Memory usage per processor = 2.478 Mbytes
-Step Temp E_pair E_mol TotEng Press
- 0 1 -1.56492 0 -0.5652325 -1.5346995
- 1000 0.97537833 -1.5723957 0 -0.5973222 0.92877783
- 2000 0.99008371 -1.5748206 0 -0.58504633 1.0809416
- 3000 1.0111412 -1.5848987 0 -0.57407352 1.0174297
- 4000 1.0055417 -1.5857581 0 -0.58053054 0.95647691
- 5000 0.97069905 -1.5851114 0 -0.61471567 0.90108287
-Loop time of 0.554412 on 8 procs for 5000 steps with 3200 atoms
-
-Performance: 3896017.421 tau/day, 9018.559 timesteps/s
-98.9% CPU use with 8 MPI tasks x no OpenMP threads
-
-MPI task timing breakdown:
-Section | min time | avg time | max time |%varavg| %total
----------------------------------------------------------------
-Pair | 0.23992 | 0.24608 | 0.25161 | 0.7 | 44.39
-Neigh | 0.063106 | 0.064417 | 0.066279 | 0.4 | 11.62
-Comm | 0.072465 | 0.085066 | 0.094837 | 2.3 | 15.34
-Output | 0.00013208 | 0.00013691 | 0.00014591 | 0.0 | 0.02
-Modify | 0.11441 | 0.11621 | 0.11769 | 0.3 | 20.96
-Other | | 0.04251 | | | 7.67
-
-Nlocal: 400 ave 406 max 394 min
-Histogram: 1 1 0 1 0 2 1 0 1 1
-Nghost: 202.5 ave 212 max 191 min
-Histogram: 1 0 0 0 3 1 0 2 0 1
-Neighs: 2800.88 ave 2903 max 2690 min
-Histogram: 1 1 0 0 1 2 1 0 1 1
-
-Total # of neighbors = 22407
-Ave neighs/atom = 7.00219
-Neighbor list builds = 599
-Dangerous builds = 0
-
-unfix 2
-
-# data gathering run
-
-reset_timestep 0
-
-# factor of 4 in 2 variables is for 2d
-
-compute msd all msd com yes
-variable twopoint equal c_msd[4]/4/(step*dt+1.0e-6)
-fix 9 all vector 10 c_msd[4]
-variable fitslope equal slope(f_9)/4/(10*dt)
-
-thermo_style custom step temp c_msd[4] v_twopoint v_fitslope
-
-# only need to run for 10K steps to make a good 100-frame movie
-
-#dump 1 all custom 1 tmp.dump id type vx vy vz
-
-#dump 2 all image 100 image.*.jpg type type zoom 1.6 adiam 1.2
-
-thermo 1000
-run 100000
-Memory usage per processor = 2.853 Mbytes
-Step Temp c_msd[4] v_twopoint v_fitslope
- 0 0.97069905 0 0 5e+20
- 1000 0.98138076 4.0484996 0.20242494 0.18046446
- 2000 0.97606079 9.2121392 0.23030346 0.2091528
- 3000 0.97924866 14.815034 0.24691721 0.22619184
- 4000 0.98568451 20.516817 0.25646019 0.23715506
- 5000 0.97551815 27.33922 0.27339219 0.24709999
- 6000 0.98482252 34.37734 0.28647782 0.25735178
- 7000 0.9672559 41.696689 0.29783348 0.26654059
- 8000 0.9836541 48.340277 0.30212673 0.27440308
- 9000 0.99087147 56.042692 0.31134828 0.28113047
- 10000 0.99663166 63.69663 0.31848314 0.28767921
- 11000 0.97776688 71.144109 0.32338231 0.29344527
- 12000 0.98246011 78.301774 0.32625739 0.29849471
- 13000 0.98788732 85.061923 0.32716124 0.3026655
- 14000 0.96872483 91.1658 0.32559214 0.30601023
- 15000 0.98955796 97.278388 0.32426129 0.3084275
- 16000 0.99855196 104.23997 0.3257499 0.31049883
- 17000 0.98600861 110.66055 0.3254722 0.31220348
- 18000 0.98696963 116.90111 0.32472531 0.31352676
- 19000 0.9881192 124.21305 0.32687644 0.31480062
- 20000 0.98527319 131.09874 0.32774685 0.31596198
- 21000 0.99015191 137.89263 0.32831579 0.31705324
- 22000 0.97972418 146.68982 0.33338595 0.31833889
- 23000 0.98911012 155.1264 0.33723129 0.31979515
- 24000 0.98810498 162.88634 0.33934653 0.32131187
- 25000 0.96961962 170.37907 0.34075814 0.32276215
- 26000 0.99118408 179.26511 0.34474059 0.32427111
- 27000 0.98515159 185.90764 0.3442734 0.32574529
- 28000 0.98951677 192.12183 0.34307469 0.32700292
- 29000 0.9832026 196.99457 0.33964581 0.32799023
- 30000 0.98449493 203.48475 0.33914124 0.3287171
- 31000 0.96585993 210.06193 0.33880956 0.32935775
- 32000 0.98758117 218.94174 0.34209646 0.33001591
- 33000 0.98875584 225.96489 0.34237104 0.33072947
- 34000 0.98007229 233.5792 0.34349882 0.3314385
- 35000 0.98415295 241.98148 0.34568783 0.33216634
- 36000 0.98101154 250.30876 0.34765106 0.33295272
- 37000 0.97606878 258.2127 0.34893608 0.33377673
- 38000 0.97220293 266.40464 0.35053242 0.33459273
- 39000 0.979783 272.8578 0.34981769 0.33539728
- 40000 0.98375673 279.87598 0.34984497 0.33609699
- 41000 0.97506523 288.07676 0.35131312 0.33677708
- 42000 0.97106749 296.11647 0.3525196 0.33751312
- 43000 0.97717259 304.46747 0.35403194 0.33823441
- 44000 0.98541435 312.57228 0.35519578 0.3389771
- 45000 0.97678287 321.82674 0.35758527 0.33973306
- 46000 0.98169719 329.78197 0.35845866 0.34051748
- 47000 0.99471466 337.11283 0.35863066 0.34127239
- 48000 0.98332437 346.0754 0.3604952 0.34202442
- 49000 0.98126947 356.11859 0.36338631 0.34282132
- 50000 0.98809751 365.65248 0.36565248 0.34368171
- 51000 0.95919516 373.91833 0.36658659 0.34454516
- 52000 0.98097913 381.26492 0.36660089 0.34538506
- 53000 0.97774072 388.81031 0.36680218 0.34618232
- 54000 0.99096915 395.56767 0.36626636 0.3469296
- 55000 0.97652739 401.72735 0.36520668 0.34760374
- 56000 0.99185306 407.28834 0.3636503 0.34819906
- 57000 0.96289342 414.75298 0.3638184 0.34871992
- 58000 0.97871716 424.69443 0.36611588 0.34927986
- 59000 0.98637393 433.14205 0.36706953 0.34986296
- 60000 0.98009845 438.14533 0.36512111 0.35040349
- 61000 0.99416712 446.08007 0.3656394 0.35088379
- 62000 0.97612483 450.90846 0.36363585 0.35132647
- 63000 0.97786531 455.36749 0.36140277 0.35167458
- 64000 0.99080668 458.04873 0.35785057 0.3519105
- 65000 0.97952497 461.31241 0.3548557 0.3520506
- 66000 0.98095955 463.91727 0.35145248 0.35207764
- 67000 0.98370788 468.93 0.34994776 0.35204043
- 68000 0.96931818 471.07765 0.34638063 0.35192685
- 69000 0.98512552 474.59146 0.34390685 0.35174053
- 70000 0.98065743 478.66071 0.3419005 0.35149002
- 71000 0.98971283 482.57357 0.33984054 0.35119434
- 72000 0.99890324 485.32018 0.3370279 0.35084345
- 73000 0.98649924 490.19497 0.33574998 0.35043722
- 74000 0.98723422 496.04991 0.33516886 0.35003351
- 75000 1.0025633 501.6313 0.33442087 0.34962094
- 76000 0.97859959 505.97813 0.33288035 0.34921013
- 77000 0.97973006 510.55334 0.33152814 0.3487692
- 78000 0.9903944 515.06966 0.33017286 0.34830833
- 79000 0.96847518 518.76483 0.32833217 0.3478214
- 80000 0.99171112 524.18127 0.32761329 0.34733349
- 81000 0.97202573 529.09959 0.32660468 0.3468315
- 82000 0.99368438 535.80271 0.32670897 0.34633058
- 83000 0.97932483 543.08233 0.32715803 0.34586259
- 84000 0.99078651 547.57861 0.32593965 0.34540839
- 85000 0.98973457 552.24581 0.32485048 0.34493584
- 86000 0.9835873 557.3493 0.32404029 0.34446152
- 87000 0.97180564 564.93434 0.32467491 0.34400358
- 88000 0.99743353 571.39837 0.32465817 0.3435667
- 89000 0.98993437 577.81703 0.32461631 0.3431411
- 90000 0.9926071 583.39378 0.32410765 0.342724
- 91000 0.98800458 591.08741 0.3247733 0.34232767
- 92000 0.98501879 596.10133 0.32396811 0.34193949
- 93000 0.98810082 604.02652 0.32474544 0.3415681
- 94000 0.97563748 609.43676 0.32416849 0.341209
- 95000 0.97283448 615.15754 0.32376713 0.34084828
- 96000 0.9883071 622.30912 0.32411933 0.34049871
- 97000 0.97717678 628.84457 0.32414669 0.34016355
- 98000 0.97190208 634.37377 0.32366009 0.3398341
- 99000 0.98687379 640.66666 0.32356902 0.33950845
- 100000 0.97559757 646.96406 0.32348203 0.33919036
-Loop time of 9.58779 on 8 procs for 100000 steps with 3200 atoms
-
-Performance: 4505729.040 tau/day, 10429.928 timesteps/s
-99.4% CPU use with 8 MPI tasks x no OpenMP threads
-
-MPI task timing breakdown:
-Section | min time | avg time | max time |%varavg| %total
----------------------------------------------------------------
-Pair | 4.8572 | 4.9363 | 4.9822 | 1.7 | 51.49
-Neigh | 1.3583 | 1.376 | 1.3991 | 1.2 | 14.35
-Comm | 1.5192 | 1.7079 | 1.8264 | 7.2 | 17.81
-Output | 0.0085125 | 0.0086059 | 0.0089455 | 0.1 | 0.09
-Modify | 0.77663 | 0.7903 | 0.81378 | 1.3 | 8.24
-Other | | 0.7686 | | | 8.02
-
-Nlocal: 400 ave 413 max 391 min
-Histogram: 2 1 0 2 0 0 1 1 0 1
-Nghost: 204.75 ave 213 max 197 min
-Histogram: 1 1 0 1 0 3 0 1 0 1
-Neighs: 2800.62 ave 2959 max 2661 min
-Histogram: 1 1 1 2 0 0 0 1 1 1
-
-Total # of neighbors = 22405
-Ave neighs/atom = 7.00156
-Neighbor list builds = 12728
-Dangerous builds = 0
-Total wall time: 0:00:10
diff --git a/examples/DIFFUSE/log.3Aug18.msd.2d.g++.8 b/examples/DIFFUSE/log.3Aug18.msd.2d.g++.8
new file mode 100644
index 0000000000000000000000000000000000000000..113da9040d8a8eb37b84a4245ce3d904e219db3c
--- /dev/null
+++ b/examples/DIFFUSE/log.3Aug18.msd.2d.g++.8
@@ -0,0 +1,251 @@
+LAMMPS (2 Aug 2018)
+# sample LAMMPS input script for diffusion of 2d LJ liquid
+# mean-squared displacement via compute msd
+
+# settings
+
+variable x equal 40
+variable y equal 40
+
+variable rho equal 0.6
+variable t equal 1.0
+variable rc equal 2.5
+
+# problem setup
+
+units lj
+dimension 2
+atom_style atomic
+neigh_modify delay 0 every 1
+
+lattice sq2 ${rho}
+lattice sq2 0.6
+Lattice spacing in x,y,z = 1.82574 1.82574 1.82574
+region simbox block 0 $x 0 $y -0.1 0.1
+region simbox block 0 40 0 $y -0.1 0.1
+region simbox block 0 40 0 40 -0.1 0.1
+create_box 1 simbox
+Created orthogonal box = (0 0 -0.182574) to (73.0297 73.0297 0.182574)
+ 4 by 2 by 1 MPI processor grid
+create_atoms 1 box
+Created 3200 atoms
+ Time spent = 0.000706911 secs
+
+pair_style lj/cut ${rc}
+pair_style lj/cut 2.5
+pair_coeff * * 1 1
+
+mass * 1.0
+velocity all create $t 97287
+velocity all create 1 97287
+
+fix 1 all nve
+fix 2 all langevin $t $t 0.1 498094
+fix 2 all langevin 1 $t 0.1 498094
+fix 2 all langevin 1 1 0.1 498094
+fix 3 all enforce2d
+
+# equilibration run
+
+thermo 1000
+run 5000
+Neighbor list info ...
+ update every 1 steps, delay 0 steps, check yes
+ max neighbors/atom: 2000, page size: 100000
+ master list distance cutoff = 2.8
+ ghost atom cutoff = 2.8
+ binsize = 1.4, bins = 53 53 1
+ 1 neighbor lists, perpetual/occasional/extra = 1 0 0
+ (1) pair lj/cut, perpetual
+ attributes: half, newton on
+ pair build: half/bin/atomonly/newton
+ stencil: half/bin/2d/newton
+ bin: standard
+Per MPI rank memory allocation (min/avg/max) = 3.052 | 3.052 | 3.052 Mbytes
+Step Temp E_pair E_mol TotEng Press
+ 0 1 -1.56492 0 -0.5652325 -1.5346995
+ 1000 0.97537833 -1.5723957 0 -0.5973222 0.92877783
+ 2000 0.99008371 -1.5748206 0 -0.58504633 1.0809416
+ 3000 1.0111412 -1.5848987 0 -0.57407352 1.0174297
+ 4000 1.0055417 -1.5857581 0 -0.58053054 0.95647691
+ 5000 0.97069905 -1.5851114 0 -0.61471567 0.90108287
+Loop time of 0.667446 on 8 procs for 5000 steps with 3200 atoms
+
+Performance: 3236214.756 tau/day, 7491.238 timesteps/s
+99.9% CPU use with 8 MPI tasks x no OpenMP threads
+
+MPI task timing breakdown:
+Section | min time | avg time | max time |%varavg| %total
+---------------------------------------------------------------
+Pair | 0.22913 | 0.24877 | 0.28382 | 3.6 | 37.27
+Neigh | 0.064419 | 0.071256 | 0.080013 | 1.7 | 10.68
+Comm | 0.103 | 0.14054 | 0.17204 | 5.5 | 21.06
+Output | 0.00010705 | 0.00013995 | 0.00021911 | 0.0 | 0.02
+Modify | 0.13457 | 0.14973 | 0.16887 | 2.6 | 22.43
+Other | | 0.05701 | | | 8.54
+
+Nlocal: 400 ave 406 max 394 min
+Histogram: 1 1 0 1 0 2 1 0 1 1
+Nghost: 202.5 ave 212 max 191 min
+Histogram: 1 0 0 0 3 1 0 2 0 1
+Neighs: 2800.88 ave 2903 max 2690 min
+Histogram: 1 1 0 0 1 2 1 0 1 1
+
+Total # of neighbors = 22407
+Ave neighs/atom = 7.00219
+Neighbor list builds = 599
+Dangerous builds = 0
+
+unfix 2
+
+# data gathering run
+
+reset_timestep 0
+
+# factor of 4 in 2 variables is for 2d
+
+compute msd all msd com yes
+variable twopoint equal c_msd[4]/4/(step*dt+1.0e-6)
+fix 9 all vector 10 c_msd[4]
+variable fitslope equal slope(f_9)/4/(10*dt)
+
+thermo_style custom step temp c_msd[4] v_twopoint v_fitslope
+
+# only need to run for 10K steps to make a good 100-frame movie
+
+#dump 1 all custom 1 tmp.dump id type vx vy vz
+
+#dump 2 all image 100 image.*.jpg type type zoom 1.6 adiam 1.2
+
+thermo 1000
+run 100000
+Per MPI rank memory allocation (min/avg/max) = 3.427 | 3.427 | 3.427 Mbytes
+Step Temp c_msd[4] v_twopoint v_fitslope
+ 0 0.97069905 0 0 5e+20
+ 1000 0.98138076 4.0484996 0.20242494 0.20685564
+ 2000 0.97606079 9.2121392 0.23030346 0.23687918
+ 3000 0.97924866 14.815034 0.24691721 0.25405247
+ 4000 0.98568451 20.516817 0.25646019 0.26353644
+ 5000 0.97551815 27.33922 0.27339219 0.27544492
+ 6000 0.98482252 34.37734 0.28647782 0.28966619
+ 7000 0.9672559 41.696689 0.29783348 0.30165524
+ 8000 0.9836541 48.340277 0.30212673 0.31085371
+ 9000 0.99087147 56.042692 0.31134828 0.31811489
+ 10000 0.99663166 63.69663 0.31848314 0.32589374
+ 11000 0.97776688 71.144109 0.32338231 0.33219745
+ 12000 0.98246011 78.301774 0.32625739 0.33723
+ 13000 0.98788732 85.061923 0.32716124 0.34053027
+ 14000 0.96872483 91.1658 0.32559214 0.34231162
+ 15000 0.98955796 97.278388 0.32426129 0.34229511
+ 16000 0.99855196 104.23997 0.3257499 0.34217252
+ 17000 0.98600861 110.66055 0.3254722 0.34172446
+ 18000 0.98696963 116.90111 0.32472531 0.3408227
+ 19000 0.9881192 124.21305 0.32687644 0.34036538
+ 20000 0.98527319 131.09874 0.32774685 0.34003478
+ 21000 0.99015191 137.89263 0.32831579 0.33987868
+ 22000 0.97972418 146.68982 0.33338595 0.34060035
+ 23000 0.98911012 155.1264 0.33723129 0.34201036
+ 24000 0.98810498 162.88634 0.33934653 0.34371488
+ 25000 0.96961962 170.37907 0.34075814 0.34531409
+ 26000 0.99118408 179.26511 0.34474059 0.34717195
+ 27000 0.98515159 185.90764 0.3442734 0.34898035
+ 28000 0.98951677 192.12183 0.34307469 0.35021808
+ 29000 0.9832026 196.99457 0.33964581 0.35075459
+ 30000 0.98449493 203.48475 0.33914124 0.35066186
+ 31000 0.96585993 210.06193 0.33880956 0.35046715
+ 32000 0.98758117 218.94174 0.34209646 0.35046623
+ 33000 0.98875584 225.96489 0.34237104 0.35073944
+ 34000 0.98007229 233.5792 0.34349882 0.35109188
+ 35000 0.98415295 241.98148 0.34568783 0.35157879
+ 36000 0.98101154 250.30876 0.34765106 0.3523013
+ 37000 0.97606878 258.2127 0.34893608 0.35318097
+ 38000 0.97220293 266.40464 0.35053242 0.3540743
+ 39000 0.979783 272.8578 0.34981769 0.35496561
+ 40000 0.98375673 279.87598 0.34984497 0.35558182
+ 41000 0.97506523 288.07676 0.35131312 0.35618259
+ 42000 0.97106749 296.11647 0.3525196 0.35698571
+ 43000 0.97717259 304.46747 0.35403194 0.3577736
+ 44000 0.98541435 312.57228 0.35519578 0.35865003
+ 45000 0.97678287 321.82674 0.35758527 0.35958623
+ 46000 0.98169719 329.78197 0.35845866 0.36062236
+ 47000 0.99471466 337.11283 0.35863066 0.36158322
+ 48000 0.98332437 346.0754 0.3604952 0.36255042
+ 49000 0.98126947 356.11859 0.36338631 0.3636628
+ 50000 0.98809751 365.65248 0.36565248 0.36496809
+ 51000 0.95919516 373.91833 0.36658659 0.36628073
+ 52000 0.98097913 381.26492 0.36660089 0.36752237
+ 53000 0.97774072 388.81031 0.36680218 0.36863962
+ 54000 0.99096915 395.56767 0.36626636 0.36961521
+ 55000 0.97652739 401.72735 0.36520668 0.37038579
+ 56000 0.99185306 407.28834 0.3636503 0.37094092
+ 57000 0.96289342 414.75298 0.3638184 0.37130039
+ 58000 0.97871716 424.69443 0.36611588 0.37180428
+ 59000 0.98637393 433.14205 0.36706953 0.37239862
+ 60000 0.98009845 438.14533 0.36512111 0.37288487
+ 61000 0.99416712 446.08007 0.3656394 0.37321496
+ 62000 0.97612483 450.90846 0.36363585 0.37345792
+ 63000 0.97786531 455.36749 0.36140277 0.37344803
+ 64000 0.99080668 458.04873 0.35785057 0.37313914
+ 65000 0.97952497 461.31241 0.3548557 0.3725875
+ 66000 0.98095955 463.91727 0.35145248 0.37174735
+ 67000 0.98370788 468.93 0.34994776 0.37076942
+ 68000 0.96931818 471.07765 0.34638063 0.36961868
+ 69000 0.98512552 474.59146 0.34390685 0.36830908
+ 70000 0.98065743 478.66071 0.3419005 0.36686789
+ 71000 0.98971283 482.57357 0.33984054 0.36535224
+ 72000 0.99890324 485.32018 0.3370279 0.36373174
+ 73000 0.98649924 490.19497 0.33574998 0.36200692
+ 74000 0.98723422 496.04991 0.33516886 0.36034919
+ 75000 1.0025633 501.6313 0.33442087 0.35872052
+ 76000 0.97859959 505.97813 0.33288035 0.35714939
+ 77000 0.97973006 510.55334 0.33152814 0.35553808
+ 78000 0.9903944 515.06966 0.33017286 0.35391584
+ 79000 0.96847518 518.76483 0.32833217 0.35226287
+ 80000 0.99171112 524.18127 0.32761329 0.35065267
+ 81000 0.97202573 529.09959 0.32660468 0.34904364
+ 82000 0.99368438 535.80271 0.32670897 0.34747913
+ 83000 0.97932483 543.08233 0.32715803 0.34605097
+ 84000 0.99078651 547.57861 0.32593965 0.34469765
+ 85000 0.98973457 552.24581 0.32485048 0.34332115
+ 86000 0.9835873 557.3493 0.32404029 0.34197018
+ 87000 0.97180564 564.93434 0.32467491 0.34069702
+ 88000 0.99743353 571.39837 0.32465817 0.33951258
+ 89000 0.98993437 577.81703 0.32461631 0.33838511
+ 90000 0.9926071 583.39378 0.32410765 0.33730429
+ 91000 0.98800458 591.08741 0.3247733 0.33630505
+ 92000 0.98501879 596.10133 0.32396811 0.33534725
+ 93000 0.98810082 604.02652 0.32474544 0.33445545
+ 94000 0.97563748 609.43676 0.32416849 0.33361404
+ 95000 0.97283448 615.15754 0.32376713 0.33278044
+ 96000 0.9883071 622.30912 0.32411933 0.33199212
+ 97000 0.97717678 628.84457 0.32414669 0.33125729
+ 98000 0.97190208 634.37377 0.32366009 0.33054877
+ 99000 0.98687379 640.66666 0.32356902 0.32986014
+ 100000 0.97559757 646.96406 0.32348203 0.32920186
+Loop time of 7.61838 on 8 procs for 100000 steps with 3200 atoms
+
+Performance: 5670494.518 tau/day, 13126.145 timesteps/s
+100.0% CPU use with 8 MPI tasks x no OpenMP threads
+
+MPI task timing breakdown:
+Section | min time | avg time | max time |%varavg| %total
+---------------------------------------------------------------
+Pair | 3.5458 | 3.6709 | 3.8234 | 4.3 | 48.19
+Neigh | 1.1363 | 1.1513 | 1.1753 | 1.0 | 15.11
+Comm | 1.5901 | 1.7017 | 1.8664 | 6.9 | 22.34
+Output | 0.0041966 | 0.0043583 | 0.0050626 | 0.4 | 0.06
+Modify | 0.63816 | 0.65537 | 0.68918 | 2.0 | 8.60
+Other | | 0.4348 | | | 5.71
+
+Nlocal: 400 ave 413 max 391 min
+Histogram: 2 1 0 2 0 0 1 1 0 1
+Nghost: 204.75 ave 213 max 197 min
+Histogram: 1 1 0 1 0 3 0 1 0 1
+Neighs: 2800.62 ave 2959 max 2661 min
+Histogram: 1 1 1 2 0 0 0 1 1 1
+
+Total # of neighbors = 22405
+Ave neighs/atom = 7.00156
+Neighbor list builds = 12728
+Dangerous builds = 0
+Total wall time: 0:00:08
diff --git a/examples/DIFFUSE/log.13Oct16.vacf.2d.g++.8 b/examples/DIFFUSE/log.3Aug18.vacf.2d.g++.8
similarity index 84%
rename from examples/DIFFUSE/log.13Oct16.vacf.2d.g++.8
rename to examples/DIFFUSE/log.3Aug18.vacf.2d.g++.8
index 458315bc29de64e5a2102de7e98ed958e591252c..80c57ada9c31b8e299944689fd1cba2f6afb95f4 100644
--- a/examples/DIFFUSE/log.13Oct16.vacf.2d.g++.8
+++ b/examples/DIFFUSE/log.3Aug18.vacf.2d.g++.8
@@ -1,4 +1,4 @@
-LAMMPS (13 Oct 2016)
+LAMMPS (2 Aug 2018)
# sample LAMMPS input script for diffusion of 2d LJ liquid
# mean-squared displacement via compute msd
@@ -29,6 +29,7 @@ Created orthogonal box = (0 0 -0.182574) to (73.0297 73.0297 0.182574)
4 by 2 by 1 MPI processor grid
create_atoms 1 box
Created 3200 atoms
+ Time spent = 0.000712872 secs
pair_style lj/cut ${rc}
pair_style lj/cut 2.5
@@ -49,13 +50,18 @@ fix 3 all enforce2d
thermo 1000
run 5000
Neighbor list info ...
- 1 neighbor list requests
update every 1 steps, delay 0 steps, check yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 2.8
ghost atom cutoff = 2.8
- binsize = 1.4 -> bins = 53 53 1
-Memory usage per processor = 2.478 Mbytes
+ binsize = 1.4, bins = 53 53 1
+ 1 neighbor lists, perpetual/occasional/extra = 1 0 0
+ (1) pair lj/cut, perpetual
+ attributes: half, newton on
+ pair build: half/bin/atomonly/newton
+ stencil: half/bin/2d/newton
+ bin: standard
+Per MPI rank memory allocation (min/avg/max) = 3.052 | 3.052 | 3.052 Mbytes
Step Temp E_pair E_mol TotEng Press
0 1 -1.56492 0 -0.5652325 -1.5346995
1000 0.97537833 -1.5723957 0 -0.5973222 0.92877783
@@ -63,20 +69,20 @@ Step Temp E_pair E_mol TotEng Press
3000 1.0111412 -1.5848987 0 -0.57407352 1.0174297
4000 1.0055417 -1.5857581 0 -0.58053054 0.95647691
5000 0.97069905 -1.5851114 0 -0.61471567 0.90108287
-Loop time of 0.557588 on 8 procs for 5000 steps with 3200 atoms
+Loop time of 0.648098 on 8 procs for 5000 steps with 3200 atoms
-Performance: 3873826.669 tau/day, 8967.191 timesteps/s
-99.1% CPU use with 8 MPI tasks x no OpenMP threads
+Performance: 3332829.949 tau/day, 7714.884 timesteps/s
+99.9% CPU use with 8 MPI tasks x no OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
-Pair | 0.23784 | 0.24683 | 0.25594 | 1.0 | 44.27
-Neigh | 0.062975 | 0.06439 | 0.0662 | 0.4 | 11.55
-Comm | 0.083826 | 0.092564 | 0.1035 | 2.1 | 16.60
-Output | 0.00011778 | 0.00012615 | 0.00014257 | 0.1 | 0.02
-Modify | 0.11466 | 0.11648 | 0.1187 | 0.4 | 20.89
-Other | | 0.0372 | | | 6.67
+Pair | 0.22614 | 0.24602 | 0.27481 | 2.8 | 37.96
+Neigh | 0.066875 | 0.07135 | 0.077825 | 1.2 | 11.01
+Comm | 0.098293 | 0.12744 | 0.1569 | 5.6 | 19.66
+Output | 0.0001049 | 0.00012228 | 0.00014496 | 0.0 | 0.02
+Modify | 0.13725 | 0.14919 | 0.16903 | 2.4 | 23.02
+Other | | 0.05398 | | | 8.33
Nlocal: 400 ave 406 max 394 min
Histogram: 1 1 0 1 0 2 1 0 1 1
@@ -114,7 +120,7 @@ thermo_style custom step temp c_vacf[4] v_vacf
thermo 1000
run 100000
-Memory usage per processor = 2.853 Mbytes
+Per MPI rank memory allocation (min/avg/max) = 3.427 | 3.427 | 3.427 Mbytes
Step Temp c_vacf[4] v_vacf
0 0.97069905 1.9407914 0
1000 0.98138076 0.029239763 0.22157396
@@ -217,20 +223,20 @@ Step Temp c_vacf[4] v_vacf
98000 0.97190208 0.015065013 0.20906937
99000 0.98687379 -0.036869401 0.22993959
100000 0.97559757 0.045464091 0.23369283
-Loop time of 10.8346 on 8 procs for 100000 steps with 3200 atoms
+Loop time of 8.16691 on 8 procs for 100000 steps with 3200 atoms
-Performance: 3987213.825 tau/day, 9229.662 timesteps/s
-99.5% CPU use with 8 MPI tasks x no OpenMP threads
+Performance: 5289636.190 tau/day, 12244.528 timesteps/s
+100.0% CPU use with 8 MPI tasks x no OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
-Pair | 4.8486 | 4.9469 | 5.0248 | 2.8 | 45.66
-Neigh | 1.3613 | 1.374 | 1.3916 | 0.8 | 12.68
-Comm | 1.8181 | 1.9534 | 2.0665 | 5.7 | 18.03
-Output | 0.016565 | 0.016701 | 0.017039 | 0.1 | 0.15
-Modify | 1.8395 | 1.9053 | 1.9704 | 2.8 | 17.59
-Other | | 0.6383 | | | 5.89
+Pair | 3.5668 | 3.6612 | 3.7867 | 4.0 | 44.83
+Neigh | 1.1409 | 1.1555 | 1.1804 | 1.4 | 14.15
+Comm | 1.581 | 1.711 | 1.8239 | 7.1 | 20.95
+Output | 0.016626 | 0.016831 | 0.017569 | 0.2 | 0.21
+Modify | 1.225 | 1.2594 | 1.3008 | 2.0 | 15.42
+Other | | 0.363 | | | 4.45
Nlocal: 400 ave 413 max 391 min
Histogram: 2 1 0 2 0 0 1 1 0 1
@@ -243,4 +249,4 @@ Total # of neighbors = 22405
Ave neighs/atom = 7.00156
Neighbor list builds = 12728
Dangerous builds = 0
-Total wall time: 0:00:11
+Total wall time: 0:00:08
diff --git a/examples/SPIN/README b/examples/SPIN/README
new file mode 100644
index 0000000000000000000000000000000000000000..5ad252e7f2c71ee1d0232ec1f67f4ee39a91f612
--- /dev/null
+++ b/examples/SPIN/README
@@ -0,0 +1,20 @@
+This directory contains examples and applications of the SPIN package
+=====================================================================
+
+- the iron, cobalt_hcp, cobalt_fcc and nickel directories provide
+examples of spin-lattice calculations.
+
+- the bfo repository provides an example of spin dynamics calculation
+performed on a fixed lattice, and applied to the multiferroic
+material bismuth-oxide.
+
+- the read_restart directory provides examples allowing to write or
+read data files, and restart magneto-mechanical simulations.
+
+- vizualization of the dump files can be achieved using Ovito or
+VMD. See the vmd repository for help vizualizing results with VMD.
+
+** Note, the aim of this repository is mainly to provide users with
+examples. Better values and tuning of the magnetic and mechanical
+interactions can be achieved for more accurate materials
+simulations. **
diff --git a/examples/SPIN/bfo/in.spin.bfo b/examples/SPIN/bfo/in.spin.bfo
index 2442b12b72294d2b138831565a868a65c5395af5..de23ba87ba2b825c129b88fd55fcfcb33703eb01 100644
--- a/examples/SPIN/bfo/in.spin.bfo
+++ b/examples/SPIN/bfo/in.spin.bfo
@@ -21,9 +21,11 @@ mass 1 1.0
set group all spin/random 11 2.50
-pair_style hybrid/overlay spin/exchange 6.0 spin/magelec 4.5
+#pair_style hybrid/overlay spin/exchange 6.0 spin/magelec 4.5
+pair_style hybrid/overlay spin/exchange 6.0 spin/magelec 4.5 spin/dmi 4.5
pair_coeff * * spin/exchange exchange 6.0 -0.01575 0.0 1.965
pair_coeff * * spin/magelec magelec 4.5 0.000109 1.0 1.0 1.0
+pair_coeff * * spin/dmi dmi 4.5 0.00005 1.0 1.0 1.0
neighbor 0.1 bin
neigh_modify every 10 check yes delay 20
@@ -44,10 +46,11 @@ variable magnorm equal c_out_mag[4]
variable emag equal c_out_mag[5]
variable tmag equal c_out_mag[6]
-thermo_style custom step time v_magnorm v_emag temp etotal
-thermo 50
+#thermo_style custom step time v_magnorm v_emag temp etotal
+thermo_style custom step time v_magnorm pe ke v_emag temp etotal
+thermo 10
compute outsp all property/atom spx spy spz sp fmx fmy fmz
dump 100 all custom 1 dump_bfo.lammpstrj type x y z c_outsp[1] c_outsp[2] c_outsp[3]
-run 5000
+run 2000
diff --git a/examples/SPIN/cobalt_hcp/in.spin.cobalt_hcp b/examples/SPIN/cobalt_hcp/in.spin.cobalt_hcp
index 4a42ec419aeb1a02603d86cb748d8964b439ea06..35aa1df86c4a2c2bdfff40f3e35f032939311b90 100644
--- a/examples/SPIN/cobalt_hcp/in.spin.cobalt_hcp
+++ b/examples/SPIN/cobalt_hcp/in.spin.cobalt_hcp
@@ -19,8 +19,8 @@ create_atoms 1 box
mass 1 58.93
-#set group all spin/random 31 1.72
-set group all spin 1.72 0.0 0.0 1.0
+set group all spin/random 31 1.72
+#set group all spin 1.72 0.0 0.0 1.0
velocity all create 100 4928459 rot yes dist gaussian
#pair_style hybrid/overlay eam/alloy spin/exchange 4.0 spin/neel 4.0
@@ -29,11 +29,11 @@ pair_coeff * * eam/alloy Co_PurjaPun_2012.eam.alloy Co
pair_coeff * * spin/exchange exchange 4.0 0.3593 1.135028015e-05 1.064568567
#pair_coeff * * spin/neel neel 4.0 0.0048 0.234 1.168 2.6905 0.705 0.652
-
neighbor 0.1 bin
neigh_modify every 10 check yes delay 20
-fix 1 all precession/spin zeeman 1.0 0.0 0.0 1.0
+#fix 1 all precession/spin zeeman 1.0 0.0 0.0 1.0
+fix 1 all precession/spin zeeman 0.0 0.0 0.0 1.0
fix 2 all langevin/spin 0.0 0.0 21
fix 3 all nve/spin lattice yes
@@ -56,4 +56,4 @@ thermo 10
compute outsp all property/atom spx spy spz sp fmx fmy fmz
dump 100 all custom 1 dump_cobalt_hcp.lammpstrj type x y z c_outsp[1] c_outsp[2] c_outsp[3]
-run 2000
+run 20000
diff --git a/examples/USER/diffraction/BulkNi.in b/examples/USER/diffraction/BulkNi.in
index a18163175cf35f9d125307df4dc8c7534d5526a5..0fa9c1b74c2c41d9917d21b7167d4761403a2c2b 100644
--- a/examples/USER/diffraction/BulkNi.in
+++ b/examples/USER/diffraction/BulkNi.in
@@ -20,7 +20,7 @@ compute XRD all xrd 1.541838 Ni 2Theta 40 80 c 2 2 2 LP 1 echo
compute SAED all saed 0.0251 Ni Kmax 0.85 Zone 1 0 0 c 0.025 0.025 0.025 &
dR_Ewald 0.05 echo manual
-fix 1 all ave/histo 1 1 1 40 80 200 c_XRD[1] c_XRD[2] &
+fix 1 all ave/histo/weight 1 1 1 40 80 200 c_XRD[1] c_XRD[2] &
mode vector file $A.hist.xrd
fix 2 all saed/vtk 1 1 1 c_SAED file $A_001.saed
diff --git a/examples/body/data.cubes b/examples/body/data.cubes
new file mode 100644
index 0000000000000000000000000000000000000000..c1323ca3503bb10745df9a9bc176ce531850a4eb
--- /dev/null
+++ b/examples/body/data.cubes
@@ -0,0 +1,76 @@
+LAMMPS data file for polygons: cubes, moment of inertia I = m edge^2/ 6
+2 atoms
+2 bodies
+1 atom types
+0 6 xlo xhi
+0 6 ylo yhi
+0 6 zlo zhi
+
+Atoms
+
+1 1 1 1 1.5 1.5 1.5
+2 1 1 1 4.0 4.0 4.0
+
+Bodies
+
+1 3 79
+8 12 6
+0.667 0.667 0.667 0 0 0
+1 1 1
+1 -1 1
+-1 -1 1
+-1 1 1
+1 1 -1
+1 -1 -1
+-1 -1 -1
+-1 1 -1
+0 1
+1 2
+2 3
+3 0
+4 5
+5 6
+6 7
+7 4
+0 4
+1 5
+2 6
+3 7
+0 1 2 3
+4 5 6 7
+0 1 5 4
+1 2 6 5
+2 3 7 6
+3 0 4 7
+0.5
+2 3 79
+8 12 6
+0.667 0.667 0.667 0 0 0
+1 1 1
+1 -1 1
+-1 -1 1
+-1 1 1
+1 1 -1
+1 -1 -1
+-1 -1 -1
+-1 1 -1
+0 1
+1 2
+2 3
+3 0
+4 5
+5 6
+6 7
+7 4
+0 4
+1 5
+2 6
+3 7
+0 1 2 3
+4 5 6 7
+0 1 5 4
+1 2 6 5
+2 3 7 6
+3 0 4 7
+0.5
+
diff --git a/examples/body/data.squares b/examples/body/data.squares
new file mode 100755
index 0000000000000000000000000000000000000000..6b198fd422dc0e5d8f736d70bcd9906ca133898e
--- /dev/null
+++ b/examples/body/data.squares
@@ -0,0 +1,32 @@
+LAMMPS data file for polygons: squares of edge length L: Izz = 1/6mL^2
+2 atoms
+2 bodies
+1 atom types
+0 12 xlo xhi
+0 12 ylo yhi
+-0.5 0.5 zlo zhi
+
+Atoms
+
+1 1 1 1 4 5 0
+2 1 1 1 9 6 0
+
+Bodies
+
+1 1 19
+4
+1 1 2.67 0 0 0
+-2 -2 0
+-2 2 0
+2 2 0
+2 -2 0
+0.5
+2 1 19
+4
+1 1 2.67 0 0 0
+-2 -2 0
+-2 2 0
+2 2 0
+2 -2 0
+0.5
+
diff --git a/examples/body/in.body b/examples/body/in.body
index 5879ed5e45bc8810e82df81fdac0928306ae9e23..815b8531545a4348fb54dd1553abcfb642f44bf5 100644
--- a/examples/body/in.body
+++ b/examples/body/in.body
@@ -8,7 +8,7 @@ read_data data.body
velocity all create 1.44 87287 loop geom
-pair_style body 5.0
+pair_style body/nparticle 5.0
pair_coeff * * 1.0 1.0
neighbor 0.5 bin
diff --git a/examples/body/in.cubes b/examples/body/in.cubes
new file mode 100644
index 0000000000000000000000000000000000000000..a22599fe9607873aab7bc2214f59b8268415814d
--- /dev/null
+++ b/examples/body/in.cubes
@@ -0,0 +1,53 @@
+# 3d rounded cubes
+
+variable r index 3
+variable steps index 10000
+
+units lj
+dimension 3
+
+atom_style body rounded/polyhedron 1 10
+
+read_data data.cubes
+
+replicate $r $r $r
+
+velocity all create 1.2 187287 dist gaussian mom yes rot yes
+
+variable cut_inner equal 0.5
+variable k_n equal 100
+variable k_na equal 1
+variable c_n equal 20
+variable c_t equal 5
+variable mu equal 0
+variable A_ua equal 1
+
+pair_style body/rounded/polyhedron ${c_n} ${c_t} ${mu} ${A_ua} ${cut_inner}
+pair_coeff * * ${k_n} ${k_na}
+
+comm_modify vel yes
+
+neighbor 0.5 bin
+neigh_modify every 1 delay 0 check yes
+
+timestep 0.001
+
+#fix 1 all nve/body
+fix 1 all nvt/body temp 1.2 1.2 0.1
+#fix 1 all npt/body temp 1.2 1.2 0.1 iso 0.002 0.02 1.0
+
+compute p2 all pressure 1_temp
+
+#compute 1 all body/local id 1 2 3
+#dump 1 all local 1000 dump.* index c_1[1] c_1[2] c_1[3] c_1[4]
+
+#dump 2 all image 1000 image.*.jpg type type &
+# zoom 1.5 adiam 1.5 body type 0 0 view 60 15
+#dump_modify 2 pad 6
+
+thermo_style custom step ke pe etotal c_p2 c_1_temp
+
+thermo 1000
+
+run ${steps}
+
diff --git a/examples/body/in.pour3d b/examples/body/in.pour3d
new file mode 100644
index 0000000000000000000000000000000000000000..bcba950e593606065837cdbaeb85a4376fd0c4c4
--- /dev/null
+++ b/examples/body/in.pour3d
@@ -0,0 +1,57 @@
+# pouring 3d rounded polyhedron bodies
+
+variable steps index 6000
+
+units lj
+boundary p p fm
+comm_modify vel yes
+
+atom_style body rounded/polyhedron 1 8
+atom_modify map array
+
+region reg block 0 50 0 50 0 50 units box
+create_box 4 reg
+
+variable cut_inner equal 0.5
+variable k_n equal 100
+variable k_na equal 5
+variable c_n equal 20
+variable c_t equal 5
+variable mu equal 0
+variable A_ua equal 1
+
+pair_style body/rounded/polyhedron ${c_n} ${c_t} ${mu} ${A_ua} ${cut_inner}
+pair_coeff * * ${k_n} ${k_na}
+
+neighbor 0.5 bin
+neigh_modify every 1 delay 0 check yes
+
+timestep 0.001
+
+fix 1 all nve/body
+fix 2 all gravity 1.0 spherical 0.0 -180.0
+
+molecule object molecule.cube molecule.tetra toff 1 &
+ molecule.rod3d toff 2 molecule.point3d toff 3
+
+region slab block 5 45 5 45 25 35 units box
+fix ins all pour 500 0 4767548 vol 0.4 10 region slab mol object &
+ molfrac 0.25 0.25 0.25 0.25
+
+fix 4 all wall/body/polyhedron 2000 50 50 zplane 0.0 NULL
+
+#compute 1 all body/local type 1 2 3
+#dump 1 all local 1000 dump.polyhedron index c_1[1] c_1[2] c_1[3] c_1[4]
+#dump 10 all custom 1000 tmp.dump id type x y z radius
+
+thermo_style custom step atoms ke pe etotal press
+
+thermo 1000
+
+#dump 2 all image 500 image.*.jpg type type &
+# zoom 1.5 adiam 1.5 body type 0 0 view 75 15
+#dump_modify 2 pad 6
+
+run ${steps}
+
+
diff --git a/examples/body/in.squares b/examples/body/in.squares
new file mode 100755
index 0000000000000000000000000000000000000000..3b05b5cead88cd6265b17ce2772873b97c475383
--- /dev/null
+++ b/examples/body/in.squares
@@ -0,0 +1,55 @@
+# 2d rounded polygon bodies
+
+variable r index 4
+variable steps index 100000
+variable T index 0.5
+variable P index 0.1
+variable seed index 980411
+
+units lj
+dimension 2
+
+atom_style body rounded/polygon 1 6
+atom_modify map array
+read_data data.squares
+
+replicate $r $r 1
+
+velocity all create $T ${seed} dist gaussian mom yes rot yes
+
+variable cut_inner equal 0.5
+variable k_n equal 100
+variable k_na equal 2
+variable c_n equal 1
+variable c_t equal 1
+variable mu equal 0.1
+variable delta_ua equal 0.5
+
+pair_style body/rounded/polygon ${c_n} ${c_t} ${mu} ${delta_ua} ${cut_inner}
+pair_coeff * * ${k_n} ${k_na}
+
+comm_modify vel yes
+
+neighbor 0.5 bin
+neigh_modify every 1 delay 0 check yes
+
+timestep 0.001
+
+#fix 1 all nve/body
+#fix 1 all nvt/body temp $T $T 1.0
+fix 1 all npt/body temp $T $T 1.0 x 0.001 $P 1.0 &
+ y 0.001 $P 1.0 couple xy fixedpoint 0 0 0
+
+fix 2 all enforce2d
+
+#compute 1 all body/local id 1 2 3
+#dump 1 all local 100000 dump.polygon.* index c_1[1] c_1[2] c_1[3] c_1[4]
+
+thermo_style custom step ke pe etotal press
+thermo 1000
+
+#dump 2 all image 10000 image.*.jpg type type zoom 2.0 &
+# adiam 1.5 body type 0 0
+#dump_modify 2 pad 6
+
+run ${steps}
diff --git a/examples/body/in.wall2d b/examples/body/in.wall2d
new file mode 100755
index 0000000000000000000000000000000000000000..04e7f31cb6810151570f164353f683ac6b675afa
--- /dev/null
+++ b/examples/body/in.wall2d
@@ -0,0 +1,57 @@
+# 2d rounded polygon bodies
+
+variable r index 4
+variable steps index 100000
+variable T index 0.5
+variable P index 0.1
+variable seed index 980411
+
+units lj
+dimension 2
+
+atom_style body rounded/polygon 1 6
+atom_modify map array
+read_data data.squares
+
+replicate $r $r 1
+
+velocity all create $T ${seed} dist gaussian mom yes rot yes
+
+change_box all boundary p f p
+
+variable cut_inner equal 0.5
+variable k_n equal 100
+variable k_na equal 2
+variable c_n equal 0.1
+variable c_t equal 0.1
+variable mu equal 0.1
+variable delta_ua equal 0.5
+
+pair_style body/rounded/polygon ${c_n} ${c_t} ${mu} ${delta_ua} ${cut_inner}
+pair_coeff * * ${k_n} ${k_na}
+
+comm_modify vel yes
+
+neighbor 0.5 bin
+neigh_modify every 1 delay 0 check yes
+
+timestep 0.001
+
+#fix 1 all nve/body
+#fix 1 all nvt/body temp $T $T 1.0
+fix 1 all npt/body temp $T $T 1.0 x 0.001 $P 1.0 fixedpoint 0 0 0
+
+fix 2 all enforce2d
+fix 3 all wall/body/polygon 2000 50 50 yplane 0.0 48.0
+
+#compute 1 all body/local id 1 2 3
+#dump 1 all local 100000 dump.polygon.* index c_1[1] c_1[2] c_1[3] c_1[4]
+
+thermo_style custom step ke pe etotal press
+thermo 1000
+
+#dump 2 all image 10000 image.*.jpg type type zoom 2.0 &
+# adiam 1.5 body type 0 0
+#dump_modify 2 pad 6
+
+run ${steps}
diff --git a/examples/body/log.9Jul18.body.cubes.g++.1 b/examples/body/log.9Jul18.body.cubes.g++.1
new file mode 100644
index 0000000000000000000000000000000000000000..c9a799c0b51192a5420fb75fb8aeaa32a0b1a3df
--- /dev/null
+++ b/examples/body/log.9Jul18.body.cubes.g++.1
@@ -0,0 +1,125 @@
+LAMMPS (29 Jun 2018)
+# 3d rounded cubes
+
+variable r index 3
+variable steps index 10000
+
+units lj
+dimension 3
+
+atom_style body rounded/polyhedron 1 10
+
+read_data data.cubes
+ orthogonal box = (0 0 0) to (6 6 6)
+ 1 by 1 by 1 MPI processor grid
+ reading atoms ...
+ 2 atoms
+ 2 bodies
+
+replicate $r $r $r
+replicate 3 $r $r
+replicate 3 3 $r
+replicate 3 3 3
+ orthogonal box = (0 0 0) to (18 18 18)
+ 1 by 1 by 1 MPI processor grid
+ 54 atoms
+ Time spent = 0.000217915 secs
+
+velocity all create 1.2 187287 dist gaussian mom yes rot yes
+
+variable cut_inner equal 0.5
+variable k_n equal 100
+variable k_na equal 1
+variable c_n equal 20
+variable c_t equal 5
+variable mu equal 0
+variable A_ua equal 1
+
+pair_style body/rounded/polyhedron ${c_n} ${c_t} ${mu} ${A_ua} ${cut_inner}
+pair_style body/rounded/polyhedron 20 ${c_t} ${mu} ${A_ua} ${cut_inner}
+pair_style body/rounded/polyhedron 20 5 ${mu} ${A_ua} ${cut_inner}
+pair_style body/rounded/polyhedron 20 5 0 ${A_ua} ${cut_inner}
+pair_style body/rounded/polyhedron 20 5 0 1 ${cut_inner}
+pair_style body/rounded/polyhedron 20 5 0 1 0.5
+pair_coeff * * ${k_n} ${k_na}
+pair_coeff * * 100 ${k_na}
+pair_coeff * * 100 1
+
+comm_modify vel yes
+
+neighbor 0.5 bin
+neigh_modify every 1 delay 0 check yes
+
+timestep 0.001
+
+#fix 1 all nve/body
+fix 1 all nvt/body temp 1.2 1.2 0.1
+#fix 1 all npt/body temp 1.2 1.2 0.1 iso 0.002 0.02 1.0
+
+compute p2 all pressure 1_temp
+
+#compute 1 all body/local id 1 2 3
+#dump 1 all local 1000 dump.* index c_1[1] c_1[2] c_1[3] c_1[4]
+
+#dump 2 all image 1000 image.*.jpg type type # zoom 1.5 adiam 1.5 body type 0 0 view 60 15
+#dump_modify 2 pad 6
+
+thermo_style custom step ke pe etotal c_p2 c_1_temp
+
+thermo 1000
+
+run ${steps}
+run 10000
+Neighbor list info ...
+ update every 1 steps, delay 0 steps, check yes
+ max neighbors/atom: 2000, page size: 100000
+ master list distance cutoff = 3.9641
+ ghost atom cutoff = 3.9641
+ binsize = 1.98205, bins = 10 10 10
+ 1 neighbor lists, perpetual/occasional/extra = 1 0 0
+ (1) pair body/rounded/polyhedron, perpetual
+ attributes: half, newton on
+ pair build: half/bin/atomonly/newton
+ stencil: half/bin/3d/newton
+ bin: standard
+Per MPI rank memory allocation (min/avg/max) = 4.952 | 4.952 | 4.952 Mbytes
+Step KinEng PotEng TotEng c_p2 c_1_temp
+ 0 1.7666667 0 1.7666667 0.01090535 0.59439252
+ 1000 3.1462962 0.17392649 3.3202227 0.02361912 1.1654694
+ 2000 2.9311648 0.13836102 3.0695258 0.021748224 1.1950624
+ 3000 3.090491 0.16511199 3.255603 0.018691142 1.23672
+ 4000 2.7401565 0.17792155 2.9180781 0.015093853 1.1180839
+ 5000 3.0880849 0.17587085 3.2639557 0.030563042 1.2831154
+ 6000 3.2180776 0.19732251 3.4154001 0.028338151 1.258839
+ 7000 2.9514882 0.25088882 3.202377 0.025296925 1.1746326
+ 8000 3.0101226 0.28825968 3.2983823 0.027273454 1.2138056
+ 9000 3.0164253 0.1901733 3.2065986 0.033228915 1.3095914
+ 10000 2.3780401 0.34082434 2.7188644 0.031838531 1.0208679
+Loop time of 38.5686 on 1 procs for 10000 steps with 54 atoms
+
+Performance: 22401.653 tau/day, 259.278 timesteps/s
+100.0% CPU use with 1 MPI tasks x no OpenMP threads
+
+MPI task timing breakdown:
+Section | min time | avg time | max time |%varavg| %total
+---------------------------------------------------------------
+Pair | 38.426 | 38.426 | 38.426 | 0.0 | 99.63
+Neigh | 0.0043154 | 0.0043154 | 0.0043154 | 0.0 | 0.01
+Comm | 0.047616 | 0.047616 | 0.047616 | 0.0 | 0.12
+Output | 0.00017595 | 0.00017595 | 0.00017595 | 0.0 | 0.00
+Modify | 0.082948 | 0.082948 | 0.082948 | 0.0 | 0.22
+Other | | 0.007761 | | | 0.02
+
+Nlocal: 54 ave 54 max 54 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+Nghost: 96 ave 96 max 96 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+Neighs: 100 ave 100 max 100 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+
+Total # of neighbors = 100
+Ave neighs/atom = 1.85185
+Neighbor list builds = 268
+Dangerous builds = 0
+
+Total wall time: 0:00:38
diff --git a/examples/body/log.9Jul18.body.cubes.g++.4 b/examples/body/log.9Jul18.body.cubes.g++.4
new file mode 100644
index 0000000000000000000000000000000000000000..e2407e972532938d39ba0e62964d74dc9c69740f
--- /dev/null
+++ b/examples/body/log.9Jul18.body.cubes.g++.4
@@ -0,0 +1,125 @@
+LAMMPS (29 Jun 2018)
+# 3d rounded cubes
+
+variable r index 3
+variable steps index 10000
+
+units lj
+dimension 3
+
+atom_style body rounded/polyhedron 1 10
+
+read_data data.cubes
+ orthogonal box = (0 0 0) to (6 6 6)
+ 1 by 2 by 2 MPI processor grid
+ reading atoms ...
+ 2 atoms
+ 2 bodies
+
+replicate $r $r $r
+replicate 3 $r $r
+replicate 3 3 $r
+replicate 3 3 3
+ orthogonal box = (0 0 0) to (18 18 18)
+ 1 by 2 by 2 MPI processor grid
+ 54 atoms
+ Time spent = 0.00103807 secs
+
+velocity all create 1.2 187287 dist gaussian mom yes rot yes
+
+variable cut_inner equal 0.5
+variable k_n equal 100
+variable k_na equal 1
+variable c_n equal 20
+variable c_t equal 5
+variable mu equal 0
+variable A_ua equal 1
+
+pair_style body/rounded/polyhedron ${c_n} ${c_t} ${mu} ${A_ua} ${cut_inner}
+pair_style body/rounded/polyhedron 20 ${c_t} ${mu} ${A_ua} ${cut_inner}
+pair_style body/rounded/polyhedron 20 5 ${mu} ${A_ua} ${cut_inner}
+pair_style body/rounded/polyhedron 20 5 0 ${A_ua} ${cut_inner}
+pair_style body/rounded/polyhedron 20 5 0 1 ${cut_inner}
+pair_style body/rounded/polyhedron 20 5 0 1 0.5
+pair_coeff * * ${k_n} ${k_na}
+pair_coeff * * 100 ${k_na}
+pair_coeff * * 100 1
+
+comm_modify vel yes
+
+neighbor 0.5 bin
+neigh_modify every 1 delay 0 check yes
+
+timestep 0.001
+
+#fix 1 all nve/body
+fix 1 all nvt/body temp 1.2 1.2 0.1
+#fix 1 all npt/body temp 1.2 1.2 0.1 iso 0.002 0.02 1.0
+
+compute p2 all pressure 1_temp
+
+#compute 1 all body/local id 1 2 3
+#dump 1 all local 1000 dump.* index c_1[1] c_1[2] c_1[3] c_1[4]
+
+#dump 2 all image 1000 image.*.jpg type type # zoom 1.5 adiam 1.5 body type 0 0 view 60 15
+#dump_modify 2 pad 6
+
+thermo_style custom step ke pe etotal c_p2 c_1_temp
+
+thermo 1000
+
+run ${steps}
+run 10000
+Neighbor list info ...
+ update every 1 steps, delay 0 steps, check yes
+ max neighbors/atom: 2000, page size: 100000
+ master list distance cutoff = 3.9641
+ ghost atom cutoff = 3.9641
+ binsize = 1.98205, bins = 10 10 10
+ 1 neighbor lists, perpetual/occasional/extra = 1 0 0
+ (1) pair body/rounded/polyhedron, perpetual
+ attributes: half, newton on
+ pair build: half/bin/atomonly/newton
+ stencil: half/bin/3d/newton
+ bin: standard
+Per MPI rank memory allocation (min/avg/max) = 4.879 | 5.068 | 5.256 Mbytes
+Step KinEng PotEng TotEng c_p2 c_1_temp
+ 0 1.7666667 0 1.7666667 0.01090535 0.59439252
+ 1000 3.1462962 0.17392649 3.3202227 0.02361912 1.1654694
+ 2000 2.9311648 0.13836102 3.0695258 0.021748224 1.1950624
+ 3000 3.090491 0.16511199 3.255603 0.018691142 1.23672
+ 4000 2.7401565 0.17792155 2.9180781 0.015093853 1.1180839
+ 5000 3.0880849 0.17587085 3.2639557 0.030563042 1.2831154
+ 6000 3.2180776 0.19732251 3.4154001 0.028338151 1.258839
+ 7000 2.9514882 0.25088882 3.202377 0.025296925 1.1746326
+ 8000 3.0101226 0.28825968 3.2983823 0.027273454 1.2138056
+ 9000 3.0164253 0.1901733 3.2065986 0.033228915 1.3095914
+ 10000 2.3780401 0.34082434 2.7188644 0.031838531 1.0208679
+Loop time of 20.5306 on 4 procs for 10000 steps with 54 atoms
+
+Performance: 42083.509 tau/day, 487.078 timesteps/s
+100.0% CPU use with 4 MPI tasks x no OpenMP threads
+
+MPI task timing breakdown:
+Section | min time | avg time | max time |%varavg| %total
+---------------------------------------------------------------
+Pair | 7.5288 | 10.878 | 19.952 | 159.0 | 52.98
+Neigh | 0.0014424 | 0.0016552 | 0.0021195 | 0.7 | 0.01
+Comm | 0.50623 | 9.5805 | 12.93 | 169.4 | 46.66
+Output | 0.00011921 | 0.00014341 | 0.00021386 | 0.0 | 0.00
+Modify | 0.044663 | 0.047684 | 0.05382 | 1.6 | 0.23
+Other | | 0.023 | | | 0.11
+
+Nlocal: 13.5 ave 17 max 9 min
+Histogram: 1 0 0 1 0 0 0 0 1 1
+Nghost: 63.5 ave 68 max 58 min
+Histogram: 1 0 0 1 0 0 0 0 0 2
+Neighs: 25 ave 38 max 6 min
+Histogram: 1 0 0 0 0 1 0 0 1 1
+
+Total # of neighbors = 100
+Ave neighs/atom = 1.85185
+Neighbor list builds = 268
+Dangerous builds = 0
+
+Total wall time: 0:00:20
diff --git a/examples/body/log.9Jul18.body.pour3d.g++.1 b/examples/body/log.9Jul18.body.pour3d.g++.1
new file mode 100644
index 0000000000000000000000000000000000000000..213dd2e18fa9959a87ca922760e53508cace973d
--- /dev/null
+++ b/examples/body/log.9Jul18.body.pour3d.g++.1
@@ -0,0 +1,138 @@
+LAMMPS (29 Jun 2018)
+# pouring 3d rounded polyhedron bodies
+
+variable steps index 6000
+
+units lj
+boundary p p fm
+comm_modify vel yes
+
+atom_style body rounded/polyhedron 1 8
+atom_modify map array
+
+region reg block 0 50 0 50 0 50 units box
+create_box 4 reg
+Created orthogonal box = (0 0 0) to (50 50 50)
+ 1 by 1 by 1 MPI processor grid
+
+variable cut_inner equal 0.5
+variable k_n equal 100
+variable k_na equal 5
+variable c_n equal 20
+variable c_t equal 5
+variable mu equal 0
+variable A_ua equal 1
+
+pair_style body/rounded/polyhedron ${c_n} ${c_t} ${mu} ${A_ua} ${cut_inner}
+pair_style body/rounded/polyhedron 20 ${c_t} ${mu} ${A_ua} ${cut_inner}
+pair_style body/rounded/polyhedron 20 5 ${mu} ${A_ua} ${cut_inner}
+pair_style body/rounded/polyhedron 20 5 0 ${A_ua} ${cut_inner}
+pair_style body/rounded/polyhedron 20 5 0 1 ${cut_inner}
+pair_style body/rounded/polyhedron 20 5 0 1 0.5
+pair_coeff * * ${k_n} ${k_na}
+pair_coeff * * 100 ${k_na}
+pair_coeff * * 100 5
+
+neighbor 0.5 bin
+neigh_modify every 1 delay 0 check yes
+
+timestep 0.001
+
+fix 1 all nve/body
+fix 2 all gravity 1.0 spherical 0.0 -180.0
+
+molecule object molecule.cube molecule.tetra toff 1 molecule.rod3d toff 2 molecule.point3d toff 3
+Read molecule object:
+ 1 atoms with max type 1
+ 0 bonds with max type 0
+ 0 angles with max type 0
+ 0 dihedrals with max type 0
+ 0 impropers with max type 0
+Read molecule object:
+ 1 atoms with max type 2
+ 0 bonds with max type 0
+ 0 angles with max type 0
+ 0 dihedrals with max type 0
+ 0 impropers with max type 0
+Read molecule object:
+ 1 atoms with max type 3
+ 0 bonds with max type 0
+ 0 angles with max type 0
+ 0 dihedrals with max type 0
+ 0 impropers with max type 0
+Read molecule object:
+ 1 atoms with max type 4
+ 0 bonds with max type 0
+ 0 angles with max type 0
+ 0 dihedrals with max type 0
+ 0 impropers with max type 0
+
+region slab block 5 45 5 45 25 35 units box
+fix ins all pour 500 0 4767548 vol 0.4 10 region slab mol object molfrac 0.25 0.25 0.25 0.25
+Particle insertion: 134 every 4472 steps, 500 by step 13417
+
+fix 4 all wall/body/polyhedron 2000 50 50 zplane 0.0 NULL
+
+#compute 1 all body/local type 1 2 3
+#dump 1 all local 1000 dump.polyhedron index c_1[1] c_1[2] c_1[3] c_1[4]
+#dump 10 all custom 1000 tmp.dump id type x y z radius
+
+thermo_style custom step atoms ke pe etotal press
+
+thermo 1000
+
+#dump 2 all image 500 image.*.jpg type type # zoom 1.5 adiam 1.5 body type 0 0 view 75 15
+#dump_modify 2 pad 6
+
+run ${steps}
+run 6000
+Neighbor list info ...
+ update every 1 steps, delay 0 steps, check yes
+ max neighbors/atom: 2000, page size: 100000
+ master list distance cutoff = 5
+ ghost atom cutoff = 5
+ binsize = 2.5, bins = 20 20 20
+ 1 neighbor lists, perpetual/occasional/extra = 1 0 0
+ (1) pair body/rounded/polyhedron, perpetual
+ attributes: half, newton on
+ pair build: half/bin/atomonly/newton
+ stencil: half/bin/3d/newton
+ bin: standard
+Per MPI rank memory allocation (min/avg/max) = 0.5065 | 0.5065 | 0.5065 Mbytes
+Step Atoms KinEng PotEng TotEng Press
+ 0 0 -0 0 0 0
+ 1000 134 -0 0.00083010524 0.00083010524 -2.1515152e-06
+ 2000 134 -0 -0.00069962476 -0.00069962476 -1.4170663e-08
+ 3000 134 -0 -0.00069962687 -0.00069962687 -4.1478181e-11
+ 4000 134 -0 -0.00069962687 -0.00069962687 -1.2141026e-13
+ 5000 268 -0 0.014969705 0.014969705 3.0797164e-05
+ 6000 268 -0 0.042467887 0.042467887 0.00056148005
+Loop time of 0.634737 on 1 procs for 6000 steps with 268 atoms
+
+Performance: 816716.196 tau/day, 9452.734 timesteps/s
+100.0% CPU use with 1 MPI tasks x no OpenMP threads
+
+MPI task timing breakdown:
+Section | min time | avg time | max time |%varavg| %total
+---------------------------------------------------------------
+Pair | 0.41391 | 0.41391 | 0.41391 | 0.0 | 65.21
+Neigh | 0.010547 | 0.010547 | 0.010547 | 0.0 | 1.66
+Comm | 0.0030921 | 0.0030921 | 0.0030921 | 0.0 | 0.49
+Output | 0.00011492 | 0.00011492 | 0.00011492 | 0.0 | 0.02
+Modify | 0.19736 | 0.19736 | 0.19736 | 0.0 | 31.09
+Other | | 0.009719 | | | 1.53
+
+Nlocal: 268 ave 268 max 268 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+Nghost: 3 ave 3 max 3 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+Neighs: 68 ave 68 max 68 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+
+Total # of neighbors = 68
+Ave neighs/atom = 0.253731
+Neighbor list builds = 168
+Dangerous builds = 0
+
+
+Total wall time: 0:00:00
diff --git a/examples/body/log.9Jul18.body.squares.g++.1 b/examples/body/log.9Jul18.body.squares.g++.1
new file mode 100644
index 0000000000000000000000000000000000000000..7b539797bd6d399ade37eeb28d580447c8721d9e
--- /dev/null
+++ b/examples/body/log.9Jul18.body.squares.g++.1
@@ -0,0 +1,221 @@
+LAMMPS (29 Jun 2018)
+# 2d rounded polygon bodies
+
+variable r index 4
+variable steps index 100000
+variable T index 0.5
+variable P index 0.1
+variable seed index 980411
+
+units lj
+dimension 2
+
+atom_style body rounded/polygon 1 6
+atom_modify map array
+read_data data.squares
+ orthogonal box = (0 0 -0.5) to (12 12 0.5)
+ 1 by 1 by 1 MPI processor grid
+ reading atoms ...
+ 2 atoms
+ 2 bodies
+
+replicate $r $r 1
+replicate 4 $r 1
+replicate 4 4 1
+ orthogonal box = (0 0 -0.5) to (48 48 0.5)
+ 1 by 1 by 1 MPI processor grid
+ 32 atoms
+ Time spent = 0.00020504 secs
+
+velocity all create $T ${seed} dist gaussian mom yes rot yes
+velocity all create 0.5 ${seed} dist gaussian mom yes rot yes
+velocity all create 0.5 980411 dist gaussian mom yes rot yes
+
+variable cut_inner equal 0.5
+variable k_n equal 100
+variable k_na equal 2
+variable c_n equal 1
+variable c_t equal 1
+variable mu equal 0.1
+variable delta_ua equal 0.5
+
+pair_style body/rounded/polygon ${c_n} ${c_t} ${mu} ${delta_ua} ${cut_inner}
+pair_style body/rounded/polygon 1 ${c_t} ${mu} ${delta_ua} ${cut_inner}
+pair_style body/rounded/polygon 1 1 ${mu} ${delta_ua} ${cut_inner}
+pair_style body/rounded/polygon 1 1 0.1 ${delta_ua} ${cut_inner}
+pair_style body/rounded/polygon 1 1 0.1 0.5 ${cut_inner}
+pair_style body/rounded/polygon 1 1 0.1 0.5 0.5
+pair_coeff * * ${k_n} ${k_na}
+pair_coeff * * 100 ${k_na}
+pair_coeff * * 100 2
+
+comm_modify vel yes
+
+neighbor 0.5 bin
+neigh_modify every 1 delay 0 check yes
+
+timestep 0.001
+
+#fix 1 all nve/body
+#fix 1 all nvt/body temp $T $T 1.0
+fix 1 all npt/body temp $T $T 1.0 x 0.001 $P 1.0 y 0.001 $P 1.0 couple xy fixedpoint 0 0 0
+fix 1 all npt/body temp 0.5 $T 1.0 x 0.001 $P 1.0 y 0.001 $P 1.0 couple xy fixedpoint 0 0 0
+fix 1 all npt/body temp 0.5 0.5 1.0 x 0.001 $P 1.0 y 0.001 $P 1.0 couple xy fixedpoint 0 0 0
+fix 1 all npt/body temp 0.5 0.5 1.0 x 0.001 0.1 1.0 y 0.001 $P 1.0 couple xy fixedpoint 0 0 0
+fix 1 all npt/body temp 0.5 0.5 1.0 x 0.001 0.1 1.0 y 0.001 0.1 1.0 couple xy fixedpoint 0 0 0
+
+fix 2 all enforce2d
+
+#compute 1 all body/local id 1 2 3
+#dump 1 all local 100000 dump.polygon.* index c_1[1] c_1[2] c_1[3] c_1[4]
+
+thermo_style custom step ke pe etotal press
+thermo 1000
+
+#dump 2 all image 10000 image.*.jpg type type zoom 2.0 # adiam 1.5 body type 0 0
+#dump_modify 2 pad 6
+
+run ${steps}
+run 100000
+Neighbor list info ...
+ update every 1 steps, delay 0 steps, check yes
+ max neighbors/atom: 2000, page size: 100000
+ master list distance cutoff = 6.15685
+ ghost atom cutoff = 6.15685
+ binsize = 3.07843, bins = 16 16 1
+ 1 neighbor lists, perpetual/occasional/extra = 1 0 0
+ (1) pair body/rounded/polygon, perpetual
+ attributes: half, newton on
+ pair build: half/bin/atomonly/newton
+ stencil: half/bin/2d/newton
+ bin: standard
+Per MPI rank memory allocation (min/avg/max) = 4.781 | 4.781 | 4.781 Mbytes
+Step KinEng PotEng TotEng Press
+ 0 0.484375 0.25 0.734375 0.0067274306
+ 1000 0.39423376 0.0017918048 0.39602557 0.0021941612
+ 2000 0.42284177 0.01346585 0.43630762 0.0029377883
+ 3000 0.58154405 0.011321689 0.59286574 0.003667871
+ 4000 0.73518304 0.034603175 0.76978621 0.0018689207
+ 5000 0.84367476 0.025292163 0.86896692 0.0089161373
+ 6000 0.70803236 0.0085631016 0.71659546 0.0045552895
+ 7000 0.56206452 0.10453031 0.66659483 0.010255161
+ 8000 0.64538994 0.088817673 0.73420761 0.0037633655
+ 9000 0.90540819 0.063696004 0.96910419 0.0077673359
+ 10000 0.68632042 0.093265016 0.77958544 0.0057864838
+ 11000 0.59118074 0.025654748 0.61683549 0.012518759
+ 12000 0.67522767 0.038176401 0.71340407 0.01741153
+ 13000 0.7644843 0.10429844 0.86878274 0.013161339
+ 14000 0.56152694 0.067836655 0.62936359 0.016852121
+ 15000 0.41895506 0.019513348 0.43846841 0.015225695
+ 16000 0.55799421 0.1564559 0.71445011 0.011703561
+ 17000 0.59391964 0.034450221 0.62836986 0.026215002
+ 18000 0.75911858 0.030885726 0.7900043 0.018396366
+ 19000 0.64417995 0.12110912 0.76528907 0.010247952
+ 20000 0.57751435 0.16965651 0.74717086 0.023392323
+ 21000 0.7613368 0.13405354 0.89539034 0.021498982
+ 22000 0.57676692 0.18011879 0.75688571 0.024469161
+ 23000 0.54043723 0.11842026 0.65885749 0.019799067
+ 24000 0.62276061 0.038967924 0.66172853 0.019080086
+ 25000 0.53157536 0.11651937 0.64809473 0.017019298
+ 26000 0.72213293 0.039012448 0.76114538 0.015434904
+ 27000 0.62157832 0.13697494 0.75855326 0.028711011
+ 28000 0.41323738 0.16301101 0.57624839 0.041792632
+ 29000 0.45774328 0.17569066 0.63343394 0.019975231
+ 30000 0.78901796 0.099791386 0.88880934 0.024116947
+ 31000 0.85205397 0.11977547 0.97182945 0.026667489
+ 32000 0.37137095 0.1232622 0.49463315 0.00087637364
+ 33000 0.26860871 0.26056381 0.52917252 0.036110517
+ 34000 0.3018636 0.21336905 0.51523265 0.040315549
+ 35000 0.39915129 0.28245957 0.68161085 0.034876856
+ 36000 0.25761236 0.2352705 0.49288286 0.022772767
+ 37000 0.1071233 0.31692858 0.42405188 0.017994666
+ 38000 0.083729577 0.28473145 0.36846103 -0.0045370431
+ 39000 0.070355565 0.26682083 0.33717639 0.017921556
+ 40000 0.075894079 0.20077896 0.27667304 0.014873186
+ 41000 0.05891028 0.15989064 0.21880092 0.025547873
+ 42000 0.1225107 0.16583605 0.28834675 0.038842785
+ 43000 0.17049189 0.14323991 0.3137318 0.029550161
+ 44000 0.26823939 0.15208257 0.42032196 0.028113612
+ 45000 0.10172203 0.1729706 0.27469264 -0.013769913
+ 46000 0.14841355 0.19085074 0.33926429 -0.00073741985
+ 47000 0.27654927 0.19097937 0.46752864 0.04021431
+ 48000 0.53432331 0.080769923 0.61509323 0.029932845
+ 49000 0.69111634 0.13064951 0.82176585 0.028985406
+ 50000 0.24520806 0.18317453 0.42838258 0.05179746
+ 51000 0.23541368 0.14281364 0.37822732 0.071884238
+ 52000 0.25464996 0.095730242 0.3503802 0.034488204
+ 53000 0.53677633 0.1058745 0.64265084 0.059932498
+ 54000 0.32970921 0.27979128 0.60950049 0.062869716
+ 55000 0.49094054 0.096735015 0.58767556 0.04728005
+ 56000 0.54398249 0.2216472 0.76562969 0.056712022
+ 57000 0.60869068 0.2338422 0.84253288 0.077143302
+ 58000 0.72175509 0.18687368 0.90862877 0.019357656
+ 59000 0.79442757 0.092502981 0.88693055 0.066882632
+ 60000 0.6810555 0.077699385 0.75875488 0.095975173
+ 61000 0.63178834 0.05071143 0.68249977 0.043586668
+ 62000 0.76589344 0.044615704 0.81050914 0.085718411
+ 63000 0.84815889 0.030527848 0.87868674 0.053072795
+ 64000 0.7309043 0.051938637 0.78284294 0.058887766
+ 65000 0.62498816 0.034474465 0.65946262 0.068446407
+ 66000 0.69817494 0.068546004 0.76672094 0.062634433
+ 67000 0.86444275 0.010184259 0.87462701 0.073635055
+ 68000 0.77820319 0.0079319524 0.78613515 0.090330925
+ 69000 0.56938919 0.0092629332 0.57865213 0.061838729
+ 70000 0.61870712 0.010047381 0.6287545 0.066501338
+ 71000 0.71651803 0.0088366199 0.72535465 0.079136316
+ 72000 0.76278925 0.008828151 0.77161741 0.063672771
+ 73000 0.75447428 0.0083985526 0.76287283 0.078256913
+ 74000 0.66185251 0.0091910052 0.67104351 0.069840511
+ 75000 0.58458829 0.0097671568 0.59435544 0.076123422
+ 76000 0.7487564 0.0100022 0.7587586 0.076171741
+ 77000 0.89505465 0.009250681 0.90430533 0.074921699
+ 78000 0.73738164 0.0092029279 0.74658457 0.078835344
+ 79000 0.65735281 0.010099528 0.66745233 0.077940627
+ 80000 0.70247542 0.010306464 0.71278189 0.079560093
+ 81000 0.74839505 0.010199092 0.75859415 0.080835104
+ 82000 0.75193767 0.010274058 0.76221173 0.081086684
+ 83000 0.71392598 0.010495573 0.72442156 0.082746145
+ 84000 0.58498928 0.011027388 0.59601667 0.08356465
+ 85000 0.59022869 0.011729474 0.60195817 0.084519397
+ 86000 0.81753578 0.011208964 0.82874475 0.085490261
+ 87000 0.83480682 0.010542579 0.8453494 0.086268527
+ 88000 0.67322538 0.011170734 0.68439611 0.08751623
+ 89000 0.62637389 0.012033316 0.6384072 0.088548094
+ 90000 0.92828557 0.011750388 0.94003596 0.089199823
+ 91000 0.96072564 0.010324509 0.97105015 0.090204803
+ 92000 0.72105071 0.011484152 0.73253486 0.09140819
+ 93000 0.65762527 0.012558219 0.67018349 0.092453474
+ 94000 0.73991591 0.01261909 0.752535 0.093373477
+ 95000 0.91791653 0.011980455 0.92989699 0.094182136
+ 96000 0.76562561 0.011807085 0.7774327 0.095323684
+ 97000 0.57292104 0.013610205 0.58653124 0.096505977
+ 98000 0.68141076 0.013863204 0.69527396 0.097380069
+ 99000 0.82390969 0.013002341 0.83691203 0.098235926
+ 100000 0.77639728 0.012989342 0.78938662 0.099274147
+Loop time of 3.88899 on 1 procs for 100000 steps with 32 atoms
+
+Performance: 2221655.884 tau/day, 25713.610 timesteps/s
+99.9% CPU use with 1 MPI tasks x no OpenMP threads
+
+MPI task timing breakdown:
+Section | min time | avg time | max time |%varavg| %total
+---------------------------------------------------------------
+Pair | 3.056 | 3.056 | 3.056 | 0.0 | 78.58
+Neigh | 0.0051048 | 0.0051048 | 0.0051048 | 0.0 | 0.13
+Comm | 0.091444 | 0.091444 | 0.091444 | 0.0 | 2.35
+Output | 0.0011995 | 0.0011995 | 0.0011995 | 0.0 | 0.03
+Modify | 0.69909 | 0.69909 | 0.69909 | 0.0 | 17.98
+Other | | 0.03616 | | | 0.93
+
+Nlocal: 32 ave 32 max 32 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+Nghost: 21 ave 21 max 21 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+Neighs: 57 ave 57 max 57 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+
+Total # of neighbors = 57
+Ave neighs/atom = 1.78125
+Neighbor list builds = 1445
+Dangerous builds = 0
+Total wall time: 0:00:03
diff --git a/examples/body/log.9Jul18.body.squares.g++.4 b/examples/body/log.9Jul18.body.squares.g++.4
new file mode 100644
index 0000000000000000000000000000000000000000..56d7734b7ba2a1919c1581799bb2eb83660aa4c9
--- /dev/null
+++ b/examples/body/log.9Jul18.body.squares.g++.4
@@ -0,0 +1,221 @@
+LAMMPS (29 Jun 2018)
+# 2d rounded polygon bodies
+
+variable r index 4
+variable steps index 100000
+variable T index 0.5
+variable P index 0.1
+variable seed index 980411
+
+units lj
+dimension 2
+
+atom_style body rounded/polygon 1 6
+atom_modify map array
+read_data data.squares
+ orthogonal box = (0 0 -0.5) to (12 12 0.5)
+ 2 by 2 by 1 MPI processor grid
+ reading atoms ...
+ 2 atoms
+ 2 bodies
+
+replicate $r $r 1
+replicate 4 $r 1
+replicate 4 4 1
+ orthogonal box = (0 0 -0.5) to (48 48 0.5)
+ 2 by 2 by 1 MPI processor grid
+ 32 atoms
+ Time spent = 0.000324011 secs
+
+velocity all create $T ${seed} dist gaussian mom yes rot yes
+velocity all create 0.5 ${seed} dist gaussian mom yes rot yes
+velocity all create 0.5 980411 dist gaussian mom yes rot yes
+
+variable cut_inner equal 0.5
+variable k_n equal 100
+variable k_na equal 2
+variable c_n equal 1
+variable c_t equal 1
+variable mu equal 0.1
+variable delta_ua equal 0.5
+
+pair_style body/rounded/polygon ${c_n} ${c_t} ${mu} ${delta_ua} ${cut_inner}
+pair_style body/rounded/polygon 1 ${c_t} ${mu} ${delta_ua} ${cut_inner}
+pair_style body/rounded/polygon 1 1 ${mu} ${delta_ua} ${cut_inner}
+pair_style body/rounded/polygon 1 1 0.1 ${delta_ua} ${cut_inner}
+pair_style body/rounded/polygon 1 1 0.1 0.5 ${cut_inner}
+pair_style body/rounded/polygon 1 1 0.1 0.5 0.5
+pair_coeff * * ${k_n} ${k_na}
+pair_coeff * * 100 ${k_na}
+pair_coeff * * 100 2
+
+comm_modify vel yes
+
+neighbor 0.5 bin
+neigh_modify every 1 delay 0 check yes
+
+timestep 0.001
+
+#fix 1 all nve/body
+#fix 1 all nvt/body temp $T $T 1.0
+fix 1 all npt/body temp $T $T 1.0 x 0.001 $P 1.0 y 0.001 $P 1.0 couple xy fixedpoint 0 0 0
+fix 1 all npt/body temp 0.5 $T 1.0 x 0.001 $P 1.0 y 0.001 $P 1.0 couple xy fixedpoint 0 0 0
+fix 1 all npt/body temp 0.5 0.5 1.0 x 0.001 $P 1.0 y 0.001 $P 1.0 couple xy fixedpoint 0 0 0
+fix 1 all npt/body temp 0.5 0.5 1.0 x 0.001 0.1 1.0 y 0.001 $P 1.0 couple xy fixedpoint 0 0 0
+fix 1 all npt/body temp 0.5 0.5 1.0 x 0.001 0.1 1.0 y 0.001 0.1 1.0 couple xy fixedpoint 0 0 0
+
+fix 2 all enforce2d
+
+#compute 1 all body/local id 1 2 3
+#dump 1 all local 100000 dump.polygon.* index c_1[1] c_1[2] c_1[3] c_1[4]
+
+thermo_style custom step ke pe etotal press
+thermo 1000
+
+#dump 2 all image 10000 image.*.jpg type type zoom 2.0 # adiam 1.5 body type 0 0
+#dump_modify 2 pad 6
+
+run ${steps}
+run 100000
+Neighbor list info ...
+ update every 1 steps, delay 0 steps, check yes
+ max neighbors/atom: 2000, page size: 100000
+ master list distance cutoff = 6.15685
+ ghost atom cutoff = 6.15685
+ binsize = 3.07843, bins = 16 16 1
+ 1 neighbor lists, perpetual/occasional/extra = 1 0 0
+ (1) pair body/rounded/polygon, perpetual
+ attributes: half, newton on
+ pair build: half/bin/atomonly/newton
+ stencil: half/bin/2d/newton
+ bin: standard
+Per MPI rank memory allocation (min/avg/max) = 4.774 | 4.774 | 4.774 Mbytes
+Step KinEng PotEng TotEng Press
+ 0 0.484375 0.25 0.734375 0.0067274306
+ 1000 0.39423376 0.0017918048 0.39602557 0.0021941612
+ 2000 0.42284177 0.01346585 0.43630762 0.0029377883
+ 3000 0.58154405 0.011321689 0.59286574 0.003667871
+ 4000 0.73518304 0.034603175 0.76978621 0.0018689207
+ 5000 0.84367476 0.025292163 0.86896692 0.0089161373
+ 6000 0.70803236 0.0085631016 0.71659546 0.0045552895
+ 7000 0.56206452 0.10453031 0.66659483 0.010255161
+ 8000 0.64538994 0.088817673 0.73420761 0.0037633655
+ 9000 0.90540819 0.063696004 0.96910419 0.0077673359
+ 10000 0.68632042 0.093265016 0.77958544 0.0057864837
+ 11000 0.59118074 0.025654748 0.61683549 0.012518759
+ 12000 0.67522767 0.038176401 0.71340407 0.01741153
+ 13000 0.7644843 0.10429844 0.86878274 0.013161339
+ 14000 0.56152694 0.067836656 0.6293636 0.016852113
+ 15000 0.41895505 0.019513353 0.43846841 0.015225696
+ 16000 0.55799443 0.15645637 0.7144508 0.011703646
+ 17000 0.59385248 0.03451986 0.62837234 0.025482966
+ 18000 0.75902169 0.031103586 0.79012527 0.018263354
+ 19000 0.64266826 0.12535314 0.76802141 0.014884119
+ 20000 0.57836261 0.16581188 0.74417449 0.024667165
+ 21000 0.78281936 0.11877527 0.90159464 -0.0090089213
+ 22000 0.5312006 0.13300874 0.66420934 0.025797278
+ 23000 0.56458861 0.084369128 0.64895774 0.024630917
+ 24000 0.65126875 0.06122992 0.71249867 0.034377198
+ 25000 0.55173441 0.15694886 0.70868327 0.021634086
+ 26000 0.59121615 0.17071182 0.76192797 0.024758366
+ 27000 0.6394843 0.17442949 0.81391378 0.034919937
+ 28000 0.31144221 0.41243036 0.72387256 0.074115225
+ 29000 0.13516917 0.3075419 0.44271107 0.023861298
+ 30000 0.14094934 0.24407203 0.38502137 0.037030438
+ 31000 0.26313749 0.087395422 0.35053291 0.042347005
+ 32000 0.51602457 0.063012079 0.57903664 0.018550299
+ 33000 0.55628829 0.200213 0.75650129 0.026507686
+ 34000 0.97399408 0.082504517 1.0564986 0.037889878
+ 35000 0.64710533 0.17662002 0.82372535 0.058295508
+ 36000 0.45769083 0.08241194 0.54010277 0.014957415
+ 37000 0.72850105 0.053874061 0.78237512 0.037194593
+ 38000 0.44177995 0.28939498 0.73117493 0.045194029
+ 39000 0.46828451 0.077630686 0.54591519 0.089849009
+ 40000 0.46786451 0.092828423 0.56069294 0.028042052
+ 41000 0.71861856 0.097085715 0.81570427 0.036473296
+ 42000 0.74121021 0.10553127 0.84674148 0.054058843
+ 43000 0.62945489 0.12770673 0.75716161 0.047267994
+ 44000 0.49900638 0.085150056 0.58415644 0.054798793
+ 45000 0.70199572 0.063415877 0.7654116 0.038363546
+ 46000 0.49513142 0.10649384 0.60162526 0.059392561
+ 47000 0.3858898 0.079458749 0.46534855 0.051825764
+ 48000 0.62585854 0.028585902 0.65444444 0.054074424
+ 49000 0.65934482 0.51865062 1.1779954 -0.035272836
+ 50000 0.5420438 0.082056756 0.62410056 0.031187494
+ 51000 0.36685223 0.14224019 0.50909241 0.073790397
+ 52000 0.19044627 0.15368389 0.34413016 0.059034266
+ 53000 0.26847678 0.075693324 0.3441701 0.032276915
+ 54000 0.3593711 0.19034549 0.54971659 0.070827883
+ 55000 0.21659198 0.1929074 0.40949939 0.035916364
+ 56000 0.28242715 0.12313241 0.40555956 0.062083926
+ 57000 0.34067475 0.14711992 0.48779467 0.059321458
+ 58000 0.4842796 0.16143425 0.64571385 0.059048247
+ 59000 0.84438871 0.076546849 0.92093556 0.048046901
+ 60000 0.92794849 0.054331626 0.98228012 0.058392272
+ 61000 0.6916736 0.076168342 0.76784194 0.058654987
+ 62000 0.63317965 0.094506389 0.72768604 0.061044719
+ 63000 0.63317266 0.038785593 0.67195825 0.097236147
+ 64000 0.81696668 0.121811 0.93877769 0.064935373
+ 65000 0.82644758 0.25188344 1.078331 0.093352359
+ 66000 0.64975019 0.17930857 0.82905876 0.058805254
+ 67000 0.63487678 0.16877059 0.80364737 0.070254696
+ 68000 0.79140717 0.11631004 0.9077172 0.064646394
+ 69000 0.85687272 0.057835331 0.91470805 0.071057291
+ 70000 0.67785976 0.040686768 0.71854653 0.074687222
+ 71000 0.60594577 0.032193155 0.63813893 0.069349268
+ 72000 0.77586745 0.024068533 0.79993598 0.083394193
+ 73000 0.88877625 0.025746326 0.91452258 0.081511105
+ 74000 0.73507888 0.036574786 0.77165367 0.075360233
+ 75000 0.68787782 0.042098622 0.72997644 0.068651098
+ 76000 0.72515745 0.04360868 0.76876613 0.069594624
+ 77000 0.77580944 0.041826702 0.81763614 0.071937144
+ 78000 0.76640394 0.039285046 0.80568899 0.074274921
+ 79000 0.62504309 0.039593585 0.66463667 0.076443295
+ 80000 0.60001642 0.043468215 0.64348464 0.094547719
+ 81000 0.82175037 0.045608873 0.86735924 0.080186295
+ 82000 0.85783276 0.042692576 0.90052534 0.081576548
+ 83000 0.71367707 0.042172193 0.75584926 0.08256625
+ 84000 0.68532406 0.044724759 0.73004882 0.083672013
+ 85000 0.72576789 0.046982462 0.77275035 0.084789331
+ 86000 0.75597701 0.04765086 0.80362787 0.085758056
+ 87000 0.74190598 0.047629096 0.78953507 0.086679976
+ 88000 0.60967704 0.049906172 0.65958321 0.085526191
+ 89000 0.54490288 0.054768238 0.59967112 0.090604027
+ 90000 0.75398341 0.057153453 0.81113686 0.091900858
+ 91000 0.84577472 0.052753512 0.89852823 0.091913909
+ 92000 0.7176235 0.050677427 0.76830093 0.092032507
+ 93000 0.61699446 0.054097013 0.67109147 0.092071275
+ 94000 0.76330752 0.057398618 0.82070614 0.092435043
+ 95000 0.98754458 0.053801311 1.0413459 0.093526707
+ 96000 0.7405897 0.052135628 0.79272533 0.095011929
+ 97000 0.65587599 0.057011962 0.71288795 0.096692123
+ 98000 0.72345634 0.060700171 0.78415651 0.097510345
+ 99000 0.88283624 0.061795247 0.94463149 0.09799633
+ 100000 0.86303812 0.058912988 0.92195111 0.09892993
+Loop time of 2.80074 on 4 procs for 100000 steps with 32 atoms
+
+Performance: 3084895.573 tau/day, 35704.810 timesteps/s
+99.9% CPU use with 4 MPI tasks x no OpenMP threads
+
+MPI task timing breakdown:
+Section | min time | avg time | max time |%varavg| %total
+---------------------------------------------------------------
+Pair | 0.81169 | 0.89466 | 0.97669 | 8.4 | 31.94
+Neigh | 0.0017524 | 0.0018129 | 0.0018773 | 0.1 | 0.06
+Comm | 0.91307 | 0.99193 | 1.0691 | 7.3 | 35.42
+Output | 0.00076914 | 0.00093722 | 0.0013936 | 0.0 | 0.03
+Modify | 0.75335 | 0.75779 | 0.76346 | 0.4 | 27.06
+Other | | 0.1536 | | | 5.48
+
+Nlocal: 8 ave 10 max 4 min
+Histogram: 1 0 0 0 0 0 1 0 0 2
+Nghost: 17.25 ave 19 max 15 min
+Histogram: 1 0 1 0 0 0 0 0 0 2
+Neighs: 13.5 ave 21 max 5 min
+Histogram: 1 0 0 0 1 0 1 0 0 1
+
+Total # of neighbors = 54
+Ave neighs/atom = 1.6875
+Neighbor list builds = 1443
+Dangerous builds = 0
+Total wall time: 0:00:02
diff --git a/examples/body/log.9Jul18.body.wall2d.g++.1 b/examples/body/log.9Jul18.body.wall2d.g++.1
new file mode 100644
index 0000000000000000000000000000000000000000..f22c3663802a487158fffc74c13931f9d83a9416
--- /dev/null
+++ b/examples/body/log.9Jul18.body.wall2d.g++.1
@@ -0,0 +1,223 @@
+LAMMPS (29 Jun 2018)
+# 2d rounded polygon bodies
+
+variable r index 4
+variable steps index 100000
+variable T index 0.5
+variable P index 0.1
+variable seed index 980411
+
+units lj
+dimension 2
+
+atom_style body rounded/polygon 1 6
+atom_modify map array
+read_data data.squares
+ orthogonal box = (0 0 -0.5) to (12 12 0.5)
+ 1 by 1 by 1 MPI processor grid
+ reading atoms ...
+ 2 atoms
+ 2 bodies
+
+replicate $r $r 1
+replicate 4 $r 1
+replicate 4 4 1
+ orthogonal box = (0 0 -0.5) to (48 48 0.5)
+ 1 by 1 by 1 MPI processor grid
+ 32 atoms
+ Time spent = 0.00029707 secs
+
+velocity all create $T ${seed} dist gaussian mom yes rot yes
+velocity all create 0.5 ${seed} dist gaussian mom yes rot yes
+velocity all create 0.5 980411 dist gaussian mom yes rot yes
+
+change_box all boundary p f p
+
+variable cut_inner equal 0.5
+variable k_n equal 100
+variable k_na equal 2
+variable c_n equal 0.1
+variable c_t equal 0.1
+variable mu equal 0.1
+variable delta_ua equal 0.5
+
+pair_style body/rounded/polygon ${c_n} ${c_t} ${mu} ${delta_ua} ${cut_inner}
+pair_style body/rounded/polygon 0.1 ${c_t} ${mu} ${delta_ua} ${cut_inner}
+pair_style body/rounded/polygon 0.1 0.1 ${mu} ${delta_ua} ${cut_inner}
+pair_style body/rounded/polygon 0.1 0.1 0.1 ${delta_ua} ${cut_inner}
+pair_style body/rounded/polygon 0.1 0.1 0.1 0.5 ${cut_inner}
+pair_style body/rounded/polygon 0.1 0.1 0.1 0.5 0.5
+pair_coeff * * ${k_n} ${k_na}
+pair_coeff * * 100 ${k_na}
+pair_coeff * * 100 2
+
+comm_modify vel yes
+
+neighbor 0.5 bin
+neigh_modify every 1 delay 0 check yes
+
+timestep 0.001
+
+#fix 1 all nve/body
+#fix 1 all nvt/body temp $T $T 1.0
+fix 1 all npt/body temp $T $T 1.0 x 0.001 $P 1.0 fixedpoint 0 0 0
+fix 1 all npt/body temp 0.5 $T 1.0 x 0.001 $P 1.0 fixedpoint 0 0 0
+fix 1 all npt/body temp 0.5 0.5 1.0 x 0.001 $P 1.0 fixedpoint 0 0 0
+fix 1 all npt/body temp 0.5 0.5 1.0 x 0.001 0.1 1.0 fixedpoint 0 0 0
+
+fix 2 all enforce2d
+fix 3 all wall/body/polygon 2000 50 50 yplane 0.0 48.0
+
+#compute 1 all body/local id 1 2 3
+#dump 1 all local 100000 dump.polygon.* index c_1[1] c_1[2] c_1[3] c_1[4]
+
+thermo_style custom step ke pe etotal press
+thermo 1000
+
+#dump 2 all image 10000 image.*.jpg type type zoom 2.0 # adiam 1.5 body type 0 0
+#dump_modify 2 pad 6
+
+run ${steps}
+run 100000
+Neighbor list info ...
+ update every 1 steps, delay 0 steps, check yes
+ max neighbors/atom: 2000, page size: 100000
+ master list distance cutoff = 6.15685
+ ghost atom cutoff = 6.15685
+ binsize = 3.07843, bins = 16 16 1
+ 1 neighbor lists, perpetual/occasional/extra = 1 0 0
+ (1) pair body/rounded/polygon, perpetual
+ attributes: half, newton on
+ pair build: half/bin/atomonly/newton
+ stencil: half/bin/2d/newton
+ bin: standard
+Per MPI rank memory allocation (min/avg/max) = 4.771 | 4.771 | 4.771 Mbytes
+Step KinEng PotEng TotEng Press
+ 0 0.484375 0.25 0.734375 0.0067274306
+ 1000 0.49241101 0.0031318767 0.49554289 0.017768281
+ 2000 0.56118632 0.0026068888 0.56379321 0.003410416
+ 3000 0.75565115 0.025578366 0.78122951 0.0071862988
+ 4000 0.72298647 0.093150646 0.81613712 0.003190158
+ 5000 0.51684166 0.049164868 0.56600653 0.0096960168
+ 6000 0.56627905 0.048132853 0.6144119 0.020733586
+ 7000 0.58122129 0.018223718 0.59944501 0.0038160759
+ 8000 0.64297977 0.025934821 0.66891459 0.0041091784
+ 9000 0.41748404 0.0077890042 0.42527305 0.0039270065
+ 10000 0.35738377 0.078487805 0.43587158 3.9079782e-05
+ 11000 0.41529308 0.13619284 0.55148592 -0.0067482285
+ 12000 0.43274718 0.071315497 0.50406268 0.007006378
+ 13000 0.4748331 0.069904647 0.54473775 0.0010384372
+ 14000 0.6287791 0.12721033 0.75598943 0.0047792448
+ 15000 0.4692413 0.12344005 0.59268136 0.018033616
+ 16000 0.43157074 0.14306789 0.57463862 0.042356676
+ 17000 0.53085999 0.22126296 0.75212294 0.027509646
+ 18000 0.52688968 0.13225282 0.6591425 0.0021558013
+ 19000 0.55032328 0.12513047 0.67545375 0.025036251
+ 20000 0.48465097 0.1431055 0.62775647 0.017193781
+ 21000 0.53166734 0.21928574 0.75095307 0.011564317
+ 22000 0.62177353 0.09296159 0.71473512 0.017660922
+ 23000 0.6972939 0.12434123 0.82163514 0.024432327
+ 24000 0.42767372 0.22152311 0.64919684 -0.013712449
+ 25000 0.4816037 0.19272865 0.67433236 0.052386055
+ 26000 0.72642579 0.19697046 0.92339625 0.020407694
+ 27000 0.39649144 0.15058326 0.5470747 0.023705766
+ 28000 0.44896324 0.18500106 0.6339643 -0.0089410286
+ 29000 0.5565759 0.11085772 0.66743362 0.048437166
+ 30000 0.58173584 0.21773281 0.79946865 0.0057357773
+ 31000 0.49199415 0.23601982 0.72801397 0.046744152
+ 32000 0.55665496 0.20542161 0.76207658 -0.0038756805
+ 33000 0.62730739 0.24460524 0.87191263 0.045330682
+ 34000 0.58107044 0.16395278 0.74502322 -0.0049496051
+ 35000 0.56838849 0.21842922 0.78681771 0.0062086036
+ 36000 0.45910273 0.28464172 0.74374445 -0.011700747
+ 37000 0.37092037 0.27646862 0.647389 0.022305679
+ 38000 0.7278047 0.30674438 1.0345491 0.07698342
+ 39000 0.5132923 0.27395066 0.78724295 0.026898634
+ 40000 0.62348649 0.24424644 0.86773293 0.039403899
+ 41000 0.3658401 0.15512326 0.52096337 0.022559003
+ 42000 0.4912253 0.35712978 0.84835508 -0.010336341
+ 43000 0.70225957 0.36314638 1.0654059 0.004148866
+ 44000 0.56958157 0.25488927 0.82447084 0.067537066
+ 45000 0.45854352 0.30149439 0.76003791 -0.017002401
+ 46000 0.62787247 0.34567995 0.97355242 0.11894801
+ 47000 0.61348914 0.29378625 0.90727539 0.067873976
+ 48000 0.71301829 0.34135284 1.0543711 0.021077736
+ 49000 0.53520804 0.30593196 0.84113999 0.0059257647
+ 50000 0.44966403 0.35370793 0.80337195 0.0020395669
+ 51000 0.5236113 0.32296924 0.84658054 -0.051011506
+ 52000 0.53905573 0.351771 0.89082672 0.013720106
+ 53000 0.55978158 0.41293947 0.97272106 0.068558589
+ 54000 0.52170459 0.2718066 0.7935112 0.0093138985
+ 55000 0.61078876 0.43353897 1.0443277 0.045377392
+ 56000 0.51300655 0.33182278 0.84482933 -0.018418487
+ 57000 0.54882822 0.38380093 0.93262915 0.10249946
+ 58000 0.72106212 0.45361279 1.1746749 0.030313481
+ 59000 0.55871447 0.63823029 1.1969448 0.019079703
+ 60000 0.49395192 0.58283102 1.0767829 0.0179349
+ 61000 0.45991079 0.62540573 1.0853165 0.074398804
+ 62000 0.4655788 0.60862262 1.0742014 0.11472976
+ 63000 0.55634524 0.63069255 1.1870378 -0.0025676135
+ 64000 0.57688903 0.45435264 1.0312417 0.0083813852
+ 65000 0.57168922 0.42217005 0.99385927 0.044931269
+ 66000 0.6206044 0.46727538 1.0878798 0.019686229
+ 67000 0.61037155 0.41840109 1.0287726 0.0195109
+ 68000 0.63848598 0.41305347 1.0515395 0.072940144
+ 69000 0.49244916 0.3834095 0.87585866 0.07963677
+ 70000 0.41847062 0.51907975 0.93755037 0.18447904
+ 71000 0.45198986 0.52973709 0.98172695 0.078419371
+ 72000 0.47064262 0.37808165 0.84872427 -0.00046308054
+ 73000 0.6690143 0.37549359 1.0445079 0.061208432
+ 74000 0.60444955 0.33779636 0.94224592 -0.068840321
+ 75000 0.61762382 0.3916421 1.0092659 0.16253292
+ 76000 0.63657961 0.50277989 1.1393595 0.013857508
+ 77000 0.52524028 0.43597896 0.96121924 -0.03296482
+ 78000 0.43803533 0.33172284 0.76975817 0.078763029
+ 79000 0.67156089 0.55272177 1.2242827 0.080822223
+ 80000 0.68678238 0.46061627 1.1473987 0.0027036992
+ 81000 0.64956678 0.44959229 1.0991591 0.11201483
+ 82000 0.51060477 0.43508342 0.9456882 0.028000608
+ 83000 0.59550548 0.69026083 1.2857663 -0.0015809004
+ 84000 0.64222145 0.38768816 1.0299096 0.014153173
+ 85000 0.7661229 0.43445261 1.2005755 0.048034534
+ 86000 0.60025257 0.53027929 1.1305319 0.0056865157
+ 87000 0.46220939 0.47470035 0.93690974 0.075311946
+ 88000 0.54123847 0.62899839 1.1702369 0.13260162
+ 89000 0.61212272 0.6114241 1.2235468 0.033284822
+ 90000 0.63924773 0.6916249 1.3308726 0.045088296
+ 91000 0.49316865 0.51037033 1.003539 0.023203598
+ 92000 0.57572123 0.43496319 1.0106844 0.297092
+ 93000 0.65187559 0.56815972 1.2200353 0.1538215
+ 94000 0.64107331 0.58948521 1.2305585 0.031117778
+ 95000 0.64584158 0.6364688 1.2823104 0.096154676
+ 96000 0.60509093 0.601487 1.2065779 0.03457172
+ 97000 0.68837218 0.77974186 1.468114 0.17801164
+ 98000 0.62725266 0.64137144 1.2686241 0.17449001
+ 99000 0.46861221 0.67000291 1.1386151 0.2429588
+ 100000 0.5879119 0.7140612 1.3019731 0.064634257
+Loop time of 2.50594 on 1 procs for 100000 steps with 32 atoms
+
+Performance: 3447804.126 tau/day, 39905.140 timesteps/s
+100.0% CPU use with 1 MPI tasks x no OpenMP threads
+
+MPI task timing breakdown:
+Section | min time | avg time | max time |%varavg| %total
+---------------------------------------------------------------
+Pair | 1.5639 | 1.5639 | 1.5639 | 0.0 | 62.41
+Neigh | 0.0086911 | 0.0086911 | 0.0086911 | 0.0 | 0.35
+Comm | 0.058926 | 0.058926 | 0.058926 | 0.0 | 2.35
+Output | 0.0012379 | 0.0012379 | 0.0012379 | 0.0 | 0.05
+Modify | 0.83537 | 0.83537 | 0.83537 | 0.0 | 33.34
+Other | | 0.03781 | | | 1.51
+
+Nlocal: 32 ave 32 max 32 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+Nghost: 20 ave 20 max 20 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+Neighs: 57 ave 57 max 57 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+
+Total # of neighbors = 57
+Ave neighs/atom = 1.78125
+Neighbor list builds = 2705
+Dangerous builds = 0
+Total wall time: 0:00:02
diff --git a/examples/body/log.9Jul18.body.wall2d.g++.4 b/examples/body/log.9Jul18.body.wall2d.g++.4
new file mode 100644
index 0000000000000000000000000000000000000000..7239fd4dcd4fc6a55886d0bfd11a401ab3e97f23
--- /dev/null
+++ b/examples/body/log.9Jul18.body.wall2d.g++.4
@@ -0,0 +1,223 @@
+LAMMPS (29 Jun 2018)
+# 2d rounded polygon bodies
+
+variable r index 4
+variable steps index 100000
+variable T index 0.5
+variable P index 0.1
+variable seed index 980411
+
+units lj
+dimension 2
+
+atom_style body rounded/polygon 1 6
+atom_modify map array
+read_data data.squares
+ orthogonal box = (0 0 -0.5) to (12 12 0.5)
+ 2 by 2 by 1 MPI processor grid
+ reading atoms ...
+ 2 atoms
+ 2 bodies
+
+replicate $r $r 1
+replicate 4 $r 1
+replicate 4 4 1
+ orthogonal box = (0 0 -0.5) to (48 48 0.5)
+ 2 by 2 by 1 MPI processor grid
+ 32 atoms
+ Time spent = 0.000386 secs
+
+velocity all create $T ${seed} dist gaussian mom yes rot yes
+velocity all create 0.5 ${seed} dist gaussian mom yes rot yes
+velocity all create 0.5 980411 dist gaussian mom yes rot yes
+
+change_box all boundary p f p
+
+variable cut_inner equal 0.5
+variable k_n equal 100
+variable k_na equal 2
+variable c_n equal 0.1
+variable c_t equal 0.1
+variable mu equal 0.1
+variable delta_ua equal 0.5
+
+pair_style body/rounded/polygon ${c_n} ${c_t} ${mu} ${delta_ua} ${cut_inner}
+pair_style body/rounded/polygon 0.1 ${c_t} ${mu} ${delta_ua} ${cut_inner}
+pair_style body/rounded/polygon 0.1 0.1 ${mu} ${delta_ua} ${cut_inner}
+pair_style body/rounded/polygon 0.1 0.1 0.1 ${delta_ua} ${cut_inner}
+pair_style body/rounded/polygon 0.1 0.1 0.1 0.5 ${cut_inner}
+pair_style body/rounded/polygon 0.1 0.1 0.1 0.5 0.5
+pair_coeff * * ${k_n} ${k_na}
+pair_coeff * * 100 ${k_na}
+pair_coeff * * 100 2
+
+comm_modify vel yes
+
+neighbor 0.5 bin
+neigh_modify every 1 delay 0 check yes
+
+timestep 0.001
+
+#fix 1 all nve/body
+#fix 1 all nvt/body temp $T $T 1.0
+fix 1 all npt/body temp $T $T 1.0 x 0.001 $P 1.0 fixedpoint 0 0 0
+fix 1 all npt/body temp 0.5 $T 1.0 x 0.001 $P 1.0 fixedpoint 0 0 0
+fix 1 all npt/body temp 0.5 0.5 1.0 x 0.001 $P 1.0 fixedpoint 0 0 0
+fix 1 all npt/body temp 0.5 0.5 1.0 x 0.001 0.1 1.0 fixedpoint 0 0 0
+
+fix 2 all enforce2d
+fix 3 all wall/body/polygon 2000 50 50 yplane 0.0 48.0
+
+#compute 1 all body/local id 1 2 3
+#dump 1 all local 100000 dump.polygon.* index c_1[1] c_1[2] c_1[3] c_1[4]
+
+thermo_style custom step ke pe etotal press
+thermo 1000
+
+#dump 2 all image 10000 image.*.jpg type type zoom 2.0 # adiam 1.5 body type 0 0
+#dump_modify 2 pad 6
+
+run ${steps}
+run 100000
+Neighbor list info ...
+ update every 1 steps, delay 0 steps, check yes
+ max neighbors/atom: 2000, page size: 100000
+ master list distance cutoff = 6.15685
+ ghost atom cutoff = 6.15685
+ binsize = 3.07843, bins = 16 16 1
+ 1 neighbor lists, perpetual/occasional/extra = 1 0 0
+ (1) pair body/rounded/polygon, perpetual
+ attributes: half, newton on
+ pair build: half/bin/atomonly/newton
+ stencil: half/bin/2d/newton
+ bin: standard
+Per MPI rank memory allocation (min/avg/max) = 4.773 | 4.773 | 4.773 Mbytes
+Step KinEng PotEng TotEng Press
+ 0 0.484375 0.25 0.734375 0.0067274306
+ 1000 0.49241101 0.0031318767 0.49554289 0.017768281
+ 2000 0.56118632 0.0026068888 0.56379321 0.003410416
+ 3000 0.75565115 0.025578366 0.78122951 0.0071862988
+ 4000 0.72298647 0.093150646 0.81613712 0.003190158
+ 5000 0.51684166 0.049164868 0.56600653 0.0096960168
+ 6000 0.56627905 0.048132853 0.6144119 0.020733586
+ 7000 0.58122129 0.018223718 0.59944501 0.0038160759
+ 8000 0.64297977 0.025934821 0.66891459 0.0041091784
+ 9000 0.41748404 0.0077890042 0.42527305 0.0039270065
+ 10000 0.35738377 0.078487805 0.43587158 3.9079865e-05
+ 11000 0.41529307 0.13619284 0.55148591 -0.0067482285
+ 12000 0.43274718 0.071315527 0.50406271 0.007006369
+ 13000 0.4748324 0.069905666 0.54473807 0.0010385254
+ 14000 0.62603727 0.098905625 0.7249429 0.0048876764
+ 15000 0.44512086 0.10415235 0.54927321 0.01902062
+ 16000 0.47460177 0.18053316 0.65513493 0.045013976
+ 17000 0.52742676 0.10110706 0.62853382 0.013615471
+ 18000 0.46111734 0.096118795 0.55723613 0.0073676834
+ 19000 0.59668439 0.13652292 0.73320731 0.029403553
+ 20000 0.46840192 0.11611719 0.58451911 -0.00034412499
+ 21000 0.53550533 0.096457461 0.6319628 0.0019785732
+ 22000 0.46599715 0.13206373 0.59806087 0.031970672
+ 23000 0.49280776 0.20404726 0.69685501 0.03657433
+ 24000 0.60901688 0.18255214 0.79156902 0.044955017
+ 25000 0.47345185 0.13671357 0.61016542 0.020313539
+ 26000 0.47653832 0.12448225 0.60102057 0.01878099
+ 27000 0.50008212 0.24740634 0.74748845 0.021862639
+ 28000 0.41627204 0.2519463 0.66821834 0.054683701
+ 29000 0.55608273 0.23100212 0.78708485 -0.0043318497
+ 30000 0.53884537 0.3001584 0.83900377 -0.012838186
+ 31000 0.53036238 0.2300328 0.76039518 -0.0061688449
+ 32000 0.42666792 0.20536256 0.63203048 0.045305282
+ 33000 0.62908185 0.1652033 0.79428515 0.0072777588
+ 34000 0.47028154 0.388736 0.85901754 0.04332288
+ 35000 0.54602322 0.2775624 0.82358562 0.02898206
+ 36000 0.59860544 0.21824655 0.81685199 0.0025936194
+ 37000 0.62467827 0.11983499 0.74451326 0.050052743
+ 38000 0.72594229 0.36584781 1.0917901 0.04280621
+ 39000 0.51129656 0.23859043 0.74988699 0.050817447
+ 40000 0.53263836 0.24212889 0.77476725 0.036245922
+ 41000 0.50288088 0.36668283 0.86956371 0.018381415
+ 42000 0.46653688 0.21974887 0.68628574 0.012661062
+ 43000 0.61738785 0.32131037 0.93869821 0.012709433
+ 44000 0.56603903 0.26515554 0.83119457 0.03315102
+ 45000 0.56231638 0.32111693 0.88343331 0.06079756
+ 46000 0.7096208 0.2570131 0.96663391 0.048770468
+ 47000 0.588755 0.1880748 0.7768298 0.035962604
+ 48000 0.56296339 0.25783519 0.82079858 0.053019928
+ 49000 0.419885 0.42328618 0.84317118 0.038105269
+ 50000 0.63073351 0.41426285 1.0449964 0.0015271048
+ 51000 0.59357935 0.184222 0.77780136 0.015996218
+ 52000 0.60608471 0.36247533 0.96856003 0.10984665
+ 53000 0.5227842 0.27686739 0.79965159 0.02761699
+ 54000 0.39435923 0.34197355 0.73633278 0.061183263
+ 55000 0.46748455 0.34230903 0.80979358 0.077441382
+ 56000 0.59819827 0.29212061 0.89031889 0.043772353
+ 57000 0.61682559 0.32788566 0.94471124 0.03992069
+ 58000 0.52702478 0.24891506 0.77593984 0.058480883
+ 59000 0.66925719 0.4109031 1.0801603 0.072434423
+ 60000 0.66807714 0.39233068 1.0604078 0.082370324
+ 61000 0.5724275 0.43308567 1.0055132 0.0072945426
+ 62000 0.49433556 0.38453743 0.87887299 0.0036097443
+ 63000 0.57575143 0.54067119 1.1164226 0.073339638
+ 64000 0.68045383 0.38246533 1.0629192 0.025314593
+ 65000 0.59843527 0.42928622 1.0277215 -0.030096445
+ 66000 0.60274797 0.50186417 1.1046121 0.069797184
+ 67000 0.47450407 0.52689807 1.0014021 0.008758012
+ 68000 0.5514135 0.64113187 1.1925454 0.093863314
+ 69000 0.52008074 0.45749565 0.97757639 -0.066061381
+ 70000 0.69042662 0.50416006 1.1945867 0.014128617
+ 71000 0.63925854 0.35153425 0.9907928 -0.01134957
+ 72000 0.52088835 0.47626986 0.99715821 0.10198133
+ 73000 0.46333852 0.5515537 1.0148922 0.00060582772
+ 74000 0.53481418 0.50409531 1.0389095 0.00919451
+ 75000 0.67182749 0.50380162 1.1756291 0.043301985
+ 76000 0.70492289 0.4112122 1.1161351 0.14880484
+ 77000 0.59781817 0.50197661 1.0997948 -0.057111711
+ 78000 0.51677429 0.4348232 0.95159749 -0.0074619446
+ 79000 0.50663297 0.55000424 1.0566372 0.0052071216
+ 80000 0.59392006 0.48394003 1.0778601 -0.018990234
+ 81000 0.66323593 0.40358336 1.0668193 -0.02961345
+ 82000 0.61596979 0.49177944 1.1077492 0.1314853
+ 83000 0.63917554 0.61656584 1.2557414 0.11908351
+ 84000 0.49305291 0.46161646 0.95466937 0.033558488
+ 85000 0.52552044 0.54250555 1.068026 0.13015174
+ 86000 0.55140914 0.38924725 0.94065638 0.047412499
+ 87000 0.60952504 0.52603688 1.1355619 0.039230066
+ 88000 0.50119735 0.547539 1.0487364 0.019659933
+ 89000 0.40331401 0.50331134 0.90662535 -0.056906034
+ 90000 0.47067839 0.51306911 0.9837475 0.11918166
+ 91000 0.45564995 0.38693455 0.8425845 0.12040045
+ 92000 0.64163032 0.34232532 0.98395564 0.0057051641
+ 93000 0.70375593 0.53646186 1.2402178 0.16044241
+ 94000 0.53378112 0.51971406 1.0534952 0.11389004
+ 95000 0.47055342 0.50396004 0.97451346 0.079424215
+ 96000 0.59543473 0.40204536 0.99748009 0.096813093
+ 97000 0.64821917 0.50051728 1.1487365 0.054071312
+ 98000 0.55723937 0.4945909 1.0518303 0.047316424
+ 99000 0.56044424 0.50773312 1.0681774 0.0149959
+ 100000 0.68254229 0.32704484 1.0095871 0.0069212661
+Loop time of 2.20043 on 4 procs for 100000 steps with 32 atoms
+
+Performance: 3926501.701 tau/day, 45445.622 timesteps/s
+100.0% CPU use with 4 MPI tasks x no OpenMP threads
+
+MPI task timing breakdown:
+Section | min time | avg time | max time |%varavg| %total
+---------------------------------------------------------------
+Pair | 0.41008 | 0.41366 | 0.41719 | 0.4 | 18.80
+Neigh | 0.0027823 | 0.0030481 | 0.0034747 | 0.5 | 0.14
+Comm | 0.74581 | 0.7675 | 0.78684 | 2.0 | 34.88
+Output | 0.00082111 | 0.0010884 | 0.0016899 | 1.1 | 0.05
+Modify | 0.83828 | 0.85329 | 0.86656 | 1.4 | 38.78
+Other | | 0.1618 | | | 7.36
+
+Nlocal: 8 ave 9 max 7 min
+Histogram: 1 0 0 0 0 2 0 0 0 1
+Nghost: 12.75 ave 14 max 12 min
+Histogram: 2 0 0 0 0 1 0 0 0 1
+Neighs: 11 ave 19 max 5 min
+Histogram: 1 0 0 2 0 0 0 0 0 1
+
+Total # of neighbors = 44
+Ave neighs/atom = 1.375
+Neighbor list builds = 2663
+Dangerous builds = 0
+Total wall time: 0:00:02
diff --git a/examples/body/molecule.cube b/examples/body/molecule.cube
new file mode 100644
index 0000000000000000000000000000000000000000..2a8a7bca5023155889095b303b22d3aef201d2cc
--- /dev/null
+++ b/examples/body/molecule.cube
@@ -0,0 +1,52 @@
+# 3d polygon body: cubes, moment of inertia I = m edge^2/ 6
+
+1 atoms
+3 79 body
+
+Coords
+
+1 0 0 0
+
+Types
+
+1 1
+
+Masses
+
+1 1.0
+
+Body Integers
+
+8 12 6
+
+Body Doubles
+
+0.667 0.667 0.667 0 0 0
+1 1 1
+1 -1 1
+-1 -1 1
+-1 1 1
+1 1 -1
+1 -1 -1
+-1 -1 -1
+-1 1 -1
+0 1
+1 2
+2 3
+3 0
+4 5
+5 6
+6 7
+7 4
+0 4
+1 5
+2 6
+3 7
+0 1 2 3
+4 5 6 7
+0 1 5 4
+1 2 6 5
+2 3 7 6
+3 0 4 7
+0.5
+
diff --git a/examples/body/molecule.point3d b/examples/body/molecule.point3d
new file mode 100644
index 0000000000000000000000000000000000000000..d22bfbe6fa9d58e0df10b2cba22dd1b402185e9a
--- /dev/null
+++ b/examples/body/molecule.point3d
@@ -0,0 +1,26 @@
+# 2d polygon body: disks Izz = 1/2 m radius^2
+
+1 atoms
+3 10 body
+
+Coords
+
+1 0 0 0
+
+Types
+
+1 1
+
+Masses
+
+1 1.0
+
+Body Integers
+
+1 0 0
+
+Body Doubles
+
+1 1 1.125 0 0 0
+0 0 0
+3.0
diff --git a/examples/body/molecule.rod3d b/examples/body/molecule.rod3d
new file mode 100644
index 0000000000000000000000000000000000000000..1c8a0a8cd3eecfa325d2a1c99a38edca26d0a789
--- /dev/null
+++ b/examples/body/molecule.rod3d
@@ -0,0 +1,27 @@
+# 2d polygon body: rods Izz = 1/12 m length^2
+
+1 atoms
+3 13 body
+
+Coords
+
+1 0 0 0
+
+Types
+
+1 1
+
+Masses
+
+1 1.0
+
+Body Integers
+
+2 1 0
+
+Body Doubles
+
+1 1 1.333 0 0 0
+-2 0 0
+2 0 0
+0.5
diff --git a/examples/body/molecule.tetra b/examples/body/molecule.tetra
new file mode 100644
index 0000000000000000000000000000000000000000..d67ec906c64868521eaae59f8284697e18ff7d72
--- /dev/null
+++ b/examples/body/molecule.tetra
@@ -0,0 +1,39 @@
+# 3d polygon body: regular tetrahedra, moment of inertia I = m edge^2/ 20
+
+1 atoms
+3 47 body
+
+Coords
+
+1 0 0 0
+
+Types
+
+1 1
+
+Masses
+
+1 1.0
+
+Body Integers
+
+4 6 4
+
+Body Doubles
+
+0.4 0.4 0.4 0 0 0
+1 1 1
+1 -1 -1
+-1 1 -1
+-1 -1 1
+0 1
+0 2
+0 3
+1 2
+2 3
+3 1
+0 1 2 -1
+0 1 3 -1
+0 2 3 -1
+1 2 3 -1
+0.5
diff --git a/lib/gpu/Install.py b/lib/gpu/Install.py
index 13d7ad157ef6435c5c6f03e743ccdd1bd2d6fa63..d1024c0085eb230a004efce14c6a38227a6221a6 100644
--- a/lib/gpu/Install.py
+++ b/lib/gpu/Install.py
@@ -23,15 +23,17 @@ optionally copies Makefile.auto to a new Makefile.osuffix
-m = use Makefile.machine as starting point, copy to Makefile.auto
default machine = linux
+ default for -h, -a, -p, -e settings are those in -m Makefile
-h = set CUDA_HOME variable in Makefile.auto to hdir
hdir = path to NVIDIA Cuda software, e.g. /usr/local/cuda
-a = set CUDA_ARCH variable in Makefile.auto to arch
- use arch = 20 for Tesla C2050/C2070 (Fermi) (deprecated as of CUDA 8.0)
- or GeForce GTX 580 or similar
- use arch = 30 for Tesla K10 (Kepler)
- use arch = 35 for Tesla K40 (Kepler) or GeForce GTX Titan or similar
- use arch = 37 for Tesla dual K80 (Kepler)
- use arch = 60 for Tesla P100 (Pascal)
+ use arch = sm_20 for Fermi (C2050/C2070, deprecated as of CUDA 8.0)
+ or GeForce GTX 580 or similar
+ use arch = sm_30 for Kepler (K10)
+ use arch = sm_35 for Kepler (K40) or GeForce GTX Titan or similar
+ use arch = sm_37 for Kepler (dual K80)
+ use arch = sm_60 for Pascal (P100)
+ use arch = sm_70 for Volta
-p = set CUDA_PRECISION variable in Makefile.auto to precision
use precision = double or mixed or single
-e = set EXTRAMAKE variable in Makefile.auto to Makefile.lammps.esuffix
@@ -46,7 +48,7 @@ Examples:
make lib-gpu args="-b" # build GPU lib 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 35 -p single -o mpi.mixed -b" # create new Makefile.mpi.mixed, also build GPU lib with these settings
+make lib-gpu args="-m mpi -a sm_35 -p single -o mpi.mixed -b" # create new Makefile.mpi.mixed, also build GPU lib with these settings
"""
# print error message or help
@@ -127,7 +129,7 @@ for line in lines:
if hflag and words[0] == "CUDA_HOME" and words[1] == '=':
line = line.replace(words[2],hdir)
if aflag and words[0] == "CUDA_ARCH" and words[1] == '=':
- line = line.replace(words[2],"-arch=sm_%s" % arch)
+ line = line.replace(words[2],"-arch=%s" % arch)
if pflag and words[0] == "CUDA_PRECISION" and words[1] == '=':
line = line.replace(words[2],precstr)
if eflag and words[0] == "EXTRAMAKE" and words[1] == '=':
diff --git a/lib/gpu/Makefile.linux b/lib/gpu/Makefile.linux
index ed5b6092d3fdbd0c710ee94fe9ca4138cb369e89..9580bfd4ae32cfe68d094e04ed9e6cbb995551b5 100644
--- a/lib/gpu/Makefile.linux
+++ b/lib/gpu/Makefile.linux
@@ -13,8 +13,8 @@ endif
NVCC = nvcc
-# Tesla CUDA
-CUDA_ARCH = -arch=sm_21
+# older CUDA
+#CUDA_ARCH = -arch=sm_21
# newer CUDA
#CUDA_ARCH = -arch=sm_13
# older CUDA
diff --git a/lib/gpu/Nvidia.makefile_multi b/lib/gpu/Nvidia.makefile_multi
index 5fb35cce3c30cdb55f5ca5ff76dcb0569c8d3920..94cfd4af6b8cd376a2c4497011f8ab71a7b63b5f 100644
--- a/lib/gpu/Nvidia.makefile_multi
+++ b/lib/gpu/Nvidia.makefile_multi
@@ -79,7 +79,10 @@ OBJS = $(OBJ_DIR)/lal_atom.o $(OBJ_DIR)/lal_ans.o \
$(OBJ_DIR)/lal_lj_cubic.o $(OBJ_DIR)/lal_lj_cubic_ext.o \
$(OBJ_DIR)/lal_ufm.o $(OBJ_DIR)/lal_ufm_ext.o \
$(OBJ_DIR)/lal_dipole_long_lj.o $(OBJ_DIR)/lal_dipole_long_lj_ext.o \
- $(OBJ_DIR)/lal_lj_expand_coul_long.o $(OBJ_DIR)/lal_lj_expand_coul_long_ext.o
+ $(OBJ_DIR)/lal_lj_expand_coul_long.o $(OBJ_DIR)/lal_lj_expand_coul_long_ext.o \
+ $(OBJ_DIR)/lal_coul_long_cs.o $(OBJ_DIR)/lal_coul_long_cs_ext.o \
+ $(OBJ_DIR)/lal_born_coul_long_cs.o $(OBJ_DIR)/lal_born_coul_long_cs_ext.o \
+ $(OBJ_DIR)/lal_born_coul_wolf_cs.o $(OBJ_DIR)/lal_born_coul_wolf_cs_ext.o
CBNS = $(OBJ_DIR)/device.cubin $(OBJ_DIR)/device_cubin.h \
$(OBJ_DIR)/atom.cubin $(OBJ_DIR)/atom_cubin.h \
@@ -137,7 +140,10 @@ CBNS = $(OBJ_DIR)/device.cubin $(OBJ_DIR)/device_cubin.h \
$(OBJ_DIR)/lj_cubic.cubin $(OBJ_DIR)/lj_cubic_cubin.h \
$(OBJ_DIR)/ufm.cubin $(OBJ_DIR)/ufm_cubin.h \
$(OBJ_DIR)/dipole_long_lj.cubin $(OBJ_DIR)/dipole_long_lj_cubin.h \
- $(OBJ_DIR)/lj_expand_coul_long.cubin $(OBJ_DIR)/lj_expand_coul_long_cubin.h
+ $(OBJ_DIR)/lj_expand_coul_long.cubin $(OBJ_DIR)/lj_expand_coul_long_cubin.h \
+ $(OBJ_DIR)/coul_long_cs.cubin $(OBJ_DIR)/coul_long_cs_cubin.h \
+ $(OBJ_DIR)/born_coul_long_cs.cubin $(OBJ_DIR)/born_coul_long_cs_cubin.h \
+ $(OBJ_DIR)/born_coul_wolf_cs.cubin $(OBJ_DIR)/born_coul_wolf_cs_cubin.h
all: $(OBJ_DIR) $(GPU_LIB) $(EXECS)
@@ -837,6 +843,42 @@ $(OBJ_DIR)/lal_lj_expand_coul_long.o: $(ALL_H) lal_lj_expand_coul_long.h lal_lj_
$(OBJ_DIR)/lal_lj_expand_coul_long_ext.o: $(ALL_H) lal_lj_expand_coul_long.h lal_lj_expand_coul_long_ext.cpp lal_base_charge.h
$(CUDR) -o $@ -c lal_lj_expand_coul_long_ext.cpp -I$(OBJ_DIR)
+$(OBJ_DIR)/coul_long_cs.cubin: lal_coul_long_cs.cu lal_precision.h lal_preprocessor.h
+ $(CUDA) --fatbin -DNV_KERNEL -o $@ lal_coul_long_cs.cu
+
+$(OBJ_DIR)/coul_long_cs_cubin.h: $(OBJ_DIR)/coul_long_cs.cubin $(OBJ_DIR)/coul_long_cs.cubin
+ $(BIN2C) -c -n coul_long_cs $(OBJ_DIR)/coul_long_cs.cubin > $(OBJ_DIR)/coul_long_cs_cubin.h
+
+$(OBJ_DIR)/lal_coul_long_cs.o: $(ALL_H) lal_coul_long_cs.h lal_coul_long_cs.cpp $(OBJ_DIR)/coul_long_cs_cubin.h $(OBJ_DIR)/lal_base_charge.o $(OBJ_DIR)/lal_coul_long.o
+ $(CUDR) -o $@ -c lal_coul_long_cs.cpp -I$(OBJ_DIR)
+
+$(OBJ_DIR)/lal_coul_long_cs_ext.o: $(ALL_H) lal_coul_long_cs.h lal_coul_long_cs_ext.cpp lal_coul_long.h
+ $(CUDR) -o $@ -c lal_coul_long_cs_ext.cpp -I$(OBJ_DIR)
+
+$(OBJ_DIR)/born_coul_long_cs.cubin: lal_born_coul_long_cs.cu lal_precision.h lal_preprocessor.h
+ $(CUDA) --fatbin -DNV_KERNEL -o $@ lal_born_coul_long_cs.cu
+
+$(OBJ_DIR)/born_coul_long_cs_cubin.h: $(OBJ_DIR)/born_coul_long_cs.cubin $(OBJ_DIR)/born_coul_long_cs.cubin
+ $(BIN2C) -c -n born_coul_long_cs $(OBJ_DIR)/born_coul_long_cs.cubin > $(OBJ_DIR)/born_coul_long_cs_cubin.h
+
+$(OBJ_DIR)/lal_born_coul_long_cs.o: $(ALL_H) lal_born_coul_long_cs.h lal_born_coul_long_cs.cpp $(OBJ_DIR)/born_coul_long_cs_cubin.h $(OBJ_DIR)/lal_base_charge.o $(OBJ_DIR)/lal_born_coul_long.o
+ $(CUDR) -o $@ -c lal_born_coul_long_cs.cpp -I$(OBJ_DIR)
+
+$(OBJ_DIR)/lal_born_coul_long_cs_ext.o: $(ALL_H) lal_born_coul_long_cs.h lal_born_coul_long_cs_ext.cpp lal_born_coul_long.h
+ $(CUDR) -o $@ -c lal_born_coul_long_cs_ext.cpp -I$(OBJ_DIR)
+
+$(OBJ_DIR)/born_coul_wolf_cs.cubin: lal_born_coul_wolf_cs.cu lal_precision.h lal_preprocessor.h
+ $(CUDA) --fatbin -DNV_KERNEL -o $@ lal_born_coul_wolf_cs.cu
+
+$(OBJ_DIR)/born_coul_wolf_cs_cubin.h: $(OBJ_DIR)/born_coul_wolf_cs.cubin $(OBJ_DIR)/born_coul_wolf_cs.cubin
+ $(BIN2C) -c -n born_coul_wolf_cs $(OBJ_DIR)/born_coul_wolf_cs.cubin > $(OBJ_DIR)/born_coul_wolf_cs_cubin.h
+
+$(OBJ_DIR)/lal_born_coul_wolf_cs.o: $(ALL_H) lal_born_coul_wolf_cs.h lal_born_coul_wolf_cs.cpp $(OBJ_DIR)/born_coul_wolf_cs_cubin.h $(OBJ_DIR)/lal_base_charge.o $(OBJ_DIR)/lal_born_coul_wolf.o
+ $(CUDR) -o $@ -c lal_born_coul_wolf_cs.cpp -I$(OBJ_DIR)
+
+$(OBJ_DIR)/lal_born_coul_wolf_cs_ext.o: $(ALL_H) lal_born_coul_wolf_cs.h lal_born_coul_wolf_cs_ext.cpp lal_born_coul_wolf.h
+ $(CUDR) -o $@ -c lal_born_coul_wolf_cs_ext.cpp -I$(OBJ_DIR)
+
$(BIN_DIR)/nvc_get_devices: ./geryon/ucl_get_devices.cpp $(NVD_H)
$(CUDR) -o $@ ./geryon/ucl_get_devices.cpp -DUCL_CUDADR $(CUDA_LIB) -lcuda
diff --git a/lib/gpu/geryon/nvd_device.h b/lib/gpu/geryon/nvd_device.h
index 2d2a751f85b47dbef4e08bb0ec69858a8ecc4798..42f176bcbf1ced3e3512457b99248237b83c8907 100644
--- a/lib/gpu/geryon/nvd_device.h
+++ b/lib/gpu/geryon/nvd_device.h
@@ -48,7 +48,18 @@ struct NVDProperties {
int minor;
CUDA_INT_TYPE totalGlobalMem;
int multiProcessorCount;
- CUdevprop_st p;
+
+ int maxThreadsPerBlock;
+ int maxThreadsDim[3];
+ int maxGridSize[3];
+ int sharedMemPerBlock;
+ int totalConstantMemory;
+ int SIMDWidth;
+ int memPitch;
+ int regsPerBlock;
+ int clockRate;
+ int textureAlign;
+
int kernelExecTimeoutEnabled;
int integrated;
int canMapHostMemory;
@@ -210,18 +221,18 @@ class UCL_Device {
inline double clock_rate() { return clock_rate(_device); }
/// Clock rate in GHz
inline double clock_rate(const int i)
- { return _properties[i].p.clockRate*1e-6;}
+ { return _properties[i].clockRate*1e-6;}
/// Get the maximum number of threads per block
inline size_t group_size() { return group_size(_device); }
/// Get the maximum number of threads per block
inline size_t group_size(const int i)
- { return _properties[i].p.maxThreadsPerBlock; }
+ { return _properties[i].maxThreadsPerBlock; }
/// Return the maximum memory pitch in bytes for current device
inline size_t max_pitch() { return max_pitch(_device); }
/// Return the maximum memory pitch in bytes
- inline size_t max_pitch(const int i) { return _properties[i].p.memPitch; }
+ inline size_t max_pitch(const int i) { return _properties[i].memPitch; }
/// Returns false if accelerator cannot be shared by multiple processes
/** If it cannot be determined, true is returned **/
@@ -260,6 +271,9 @@ class UCL_Device {
/// List all devices along with all properties
inline void print_all(std::ostream &out);
+ /// Select the platform that has accelerators (for compatibility with OpenCL)
+ inline int set_platform_accelerator(int pid=-1) { return UCL_SUCCESS; }
+
private:
int _device, _num_devices;
std::vector<NVDProperties> _properties;
@@ -272,49 +286,54 @@ class UCL_Device {
UCL_Device::UCL_Device() {
CU_SAFE_CALL_NS(cuInit(0));
CU_SAFE_CALL_NS(cuDeviceGetCount(&_num_devices));
- for (int dev=0; dev<_num_devices; ++dev) {
- CUdevice m;
- CU_SAFE_CALL_NS(cuDeviceGet(&m,dev));
+ for (int i=0; i<_num_devices; ++i) {
+ CUdevice dev;
+ CU_SAFE_CALL_NS(cuDeviceGet(&dev,i));
int major, minor;
- CU_SAFE_CALL_NS(cuDeviceComputeCapability(&major,&minor,m));
+ CU_SAFE_CALL_NS(cuDeviceGetAttribute(&major, CU_DEVICE_ATTRIBUTE_COMPUTE_CAPABILITY_MAJOR, dev));
+ CU_SAFE_CALL_NS(cuDeviceGetAttribute(&minor, CU_DEVICE_ATTRIBUTE_COMPUTE_CAPABILITY_MINOR, dev));
if (major==9999)
continue;
- _properties.push_back(NVDProperties());
- _properties.back().device_id=dev;
- _properties.back().major=major;
- _properties.back().minor=minor;
+ NVDProperties prop;
+ prop.device_id = i;
+ prop.major=major;
+ prop.minor=minor;
char namecstr[1024];
- CU_SAFE_CALL_NS(cuDeviceGetName(namecstr,1024,m));
- _properties.back().name=namecstr;
-
- CU_SAFE_CALL_NS(cuDeviceTotalMem(&_properties.back().totalGlobalMem,m));
- CU_SAFE_CALL_NS(cuDeviceGetAttribute(&_properties.back().multiProcessorCount,
- CU_DEVICE_ATTRIBUTE_MULTIPROCESSOR_COUNT,
- m));
- CU_SAFE_CALL_NS(cuDeviceGetProperties(&_properties.back().p,m));
+ CU_SAFE_CALL_NS(cuDeviceGetName(namecstr,1024,dev));
+ prop.name=namecstr;
+
+ CU_SAFE_CALL_NS(cuDeviceTotalMem(&prop.totalGlobalMem,dev));
+ CU_SAFE_CALL_NS(cuDeviceGetAttribute(&prop.multiProcessorCount, CU_DEVICE_ATTRIBUTE_MULTIPROCESSOR_COUNT, dev));
+
+ CU_SAFE_CALL_NS(cuDeviceGetAttribute(&prop.maxThreadsPerBlock, CU_DEVICE_ATTRIBUTE_MAX_THREADS_PER_BLOCK, dev));
+ CU_SAFE_CALL_NS(cuDeviceGetAttribute(&prop.maxThreadsDim[0], CU_DEVICE_ATTRIBUTE_MAX_BLOCK_DIM_X, dev));
+ CU_SAFE_CALL_NS(cuDeviceGetAttribute(&prop.maxThreadsDim[1], CU_DEVICE_ATTRIBUTE_MAX_BLOCK_DIM_Y, dev));
+ CU_SAFE_CALL_NS(cuDeviceGetAttribute(&prop.maxThreadsDim[2], CU_DEVICE_ATTRIBUTE_MAX_BLOCK_DIM_Z, dev));
+ CU_SAFE_CALL_NS(cuDeviceGetAttribute(&prop.maxGridSize[0], CU_DEVICE_ATTRIBUTE_MAX_GRID_DIM_X, dev));
+ CU_SAFE_CALL_NS(cuDeviceGetAttribute(&prop.maxGridSize[1], CU_DEVICE_ATTRIBUTE_MAX_GRID_DIM_Y, dev));
+ CU_SAFE_CALL_NS(cuDeviceGetAttribute(&prop.maxGridSize[2], CU_DEVICE_ATTRIBUTE_MAX_GRID_DIM_Z, dev));
+ CU_SAFE_CALL_NS(cuDeviceGetAttribute(&prop.sharedMemPerBlock, CU_DEVICE_ATTRIBUTE_MAX_SHARED_MEMORY_PER_BLOCK, dev));
+ CU_SAFE_CALL_NS(cuDeviceGetAttribute(&prop.totalConstantMemory, CU_DEVICE_ATTRIBUTE_TOTAL_CONSTANT_MEMORY, dev));
+ CU_SAFE_CALL_NS(cuDeviceGetAttribute(&prop.SIMDWidth, CU_DEVICE_ATTRIBUTE_WARP_SIZE, dev));
+ CU_SAFE_CALL_NS(cuDeviceGetAttribute(&prop.memPitch, CU_DEVICE_ATTRIBUTE_MAX_PITCH, dev));
+ CU_SAFE_CALL_NS(cuDeviceGetAttribute(&prop.regsPerBlock, CU_DEVICE_ATTRIBUTE_MAX_REGISTERS_PER_BLOCK, dev));
+ CU_SAFE_CALL_NS(cuDeviceGetAttribute(&prop.clockRate, CU_DEVICE_ATTRIBUTE_CLOCK_RATE, dev));
+ CU_SAFE_CALL_NS(cuDeviceGetAttribute(&prop.textureAlign, CU_DEVICE_ATTRIBUTE_TEXTURE_ALIGNMENT, dev));
+
#if CUDA_VERSION >= 2020
- CU_SAFE_CALL_NS(cuDeviceGetAttribute(
- &_properties.back().kernelExecTimeoutEnabled,
- CU_DEVICE_ATTRIBUTE_KERNEL_EXEC_TIMEOUT,dev));
- CU_SAFE_CALL_NS(cuDeviceGetAttribute(
- &_properties.back().integrated,
- CU_DEVICE_ATTRIBUTE_INTEGRATED, dev));
- CU_SAFE_CALL_NS(cuDeviceGetAttribute(
- &_properties.back().canMapHostMemory,
- CU_DEVICE_ATTRIBUTE_CAN_MAP_HOST_MEMORY, dev));
- CU_SAFE_CALL_NS(cuDeviceGetAttribute(&_properties.back().computeMode,
- CU_DEVICE_ATTRIBUTE_COMPUTE_MODE,dev));
+ CU_SAFE_CALL_NS(cuDeviceGetAttribute(&prop.kernelExecTimeoutEnabled, CU_DEVICE_ATTRIBUTE_KERNEL_EXEC_TIMEOUT,dev));
+ CU_SAFE_CALL_NS(cuDeviceGetAttribute(&prop.integrated, CU_DEVICE_ATTRIBUTE_INTEGRATED, dev));
+ CU_SAFE_CALL_NS(cuDeviceGetAttribute(&prop.canMapHostMemory, CU_DEVICE_ATTRIBUTE_CAN_MAP_HOST_MEMORY, dev));
+ CU_SAFE_CALL_NS(cuDeviceGetAttribute(&prop.computeMode, CU_DEVICE_ATTRIBUTE_COMPUTE_MODE,dev));
#endif
#if CUDA_VERSION >= 3010
- CU_SAFE_CALL_NS(cuDeviceGetAttribute(
- &_properties.back().concurrentKernels,
- CU_DEVICE_ATTRIBUTE_CONCURRENT_KERNELS, dev));
- CU_SAFE_CALL_NS(cuDeviceGetAttribute(
- &_properties.back().ECCEnabled,
- CU_DEVICE_ATTRIBUTE_ECC_ENABLED, dev));
+ CU_SAFE_CALL_NS(cuDeviceGetAttribute(&prop.concurrentKernels, CU_DEVICE_ATTRIBUTE_CONCURRENT_KERNELS, dev));
+ CU_SAFE_CALL_NS(cuDeviceGetAttribute(&prop.ECCEnabled, CU_DEVICE_ATTRIBUTE_ECC_ENABLED, dev));
#endif
+
+ _properties.push_back(prop);
}
_device=-1;
_cq.push_back(CUstream());
@@ -390,27 +409,27 @@ void UCL_Device::print_all(std::ostream &out) {
<< cores(i) << std::endl;
#endif
out << " Total amount of constant memory: "
- << _properties[i].p.totalConstantMemory << " bytes\n";
+ << _properties[i].totalConstantMemory << " bytes\n";
out << " Total amount of local/shared memory per block: "
- << _properties[i].p.sharedMemPerBlock << " bytes\n";
+ << _properties[i].sharedMemPerBlock << " bytes\n";
out << " Total number of registers available per block: "
- << _properties[i].p.regsPerBlock << std::endl;
+ << _properties[i].regsPerBlock << std::endl;
out << " Warp size: "
- << _properties[i].p.SIMDWidth << std::endl;
+ << _properties[i].SIMDWidth << std::endl;
out << " Maximum number of threads per block: "
- << _properties[i].p.maxThreadsPerBlock << std::endl;
+ << _properties[i].maxThreadsPerBlock << std::endl;
out << " Maximum group size (# of threads per block) "
- << _properties[i].p.maxThreadsDim[0] << " x "
- << _properties[i].p.maxThreadsDim[1] << " x "
- << _properties[i].p.maxThreadsDim[2] << std::endl;
+ << _properties[i].maxThreadsDim[0] << " x "
+ << _properties[i].maxThreadsDim[1] << " x "
+ << _properties[i].maxThreadsDim[2] << std::endl;
out << " Maximum item sizes (# threads for each dim) "
- << _properties[i].p.maxGridSize[0] << " x "
- << _properties[i].p.maxGridSize[1] << " x "
- << _properties[i].p.maxGridSize[2] << std::endl;
+ << _properties[i].maxGridSize[0] << " x "
+ << _properties[i].maxGridSize[1] << " x "
+ << _properties[i].maxGridSize[2] << std::endl;
out << " Maximum memory pitch: "
<< max_pitch(i) << " bytes\n";
out << " Texture alignment: "
- << _properties[i].p.textureAlign << " bytes\n";
+ << _properties[i].textureAlign << " bytes\n";
out << " Clock rate: "
<< clock_rate(i) << " GHz\n";
#if CUDA_VERSION >= 2020
diff --git a/lib/gpu/geryon/ocl_device.h b/lib/gpu/geryon/ocl_device.h
index 2b2367545e837427527cad44843a5cb31fd09d30..14455e38a50740784fe2c28fc3ae5a6673c85796 100644
--- a/lib/gpu/geryon/ocl_device.h
+++ b/lib/gpu/geryon/ocl_device.h
@@ -165,8 +165,8 @@ class UCL_Device {
/// Get the current OpenCL device name
inline std::string name() { return name(_device); }
/// Get the OpenCL device name
- inline std::string name(const int i)
- { return std::string(_properties[i].name); }
+ inline std::string name(const int i) {
+ return std::string(_properties[i].name); }
/// Get a string telling the type of the current device
inline std::string device_type_name() { return device_type_name(_device); }
@@ -281,7 +281,7 @@ class UCL_Device {
inline cl_device_id & cl_device() { return _cl_device; }
/// Select the platform that has accelerators
- inline void set_platform_accelerator(int pid=-1);
+ inline int set_platform_accelerator(int pid=-1);
private:
int _num_platforms; // Number of platforms
@@ -324,6 +324,7 @@ UCL_Device::~UCL_Device() {
void UCL_Device::clear() {
_properties.clear();
+ _cl_devices.clear();
if (_device>-1) {
for (size_t i=0; i<_cq.size(); i++) {
CL_DESTRUCT_CALL(clReleaseCommandQueue(_cq.back()));
@@ -520,8 +521,6 @@ int UCL_Device::device_type(const int i) {
// Set the CUDA device to the specified device number
int UCL_Device::set(int num) {
- clear();
-
cl_device_id *device_list = new cl_device_id[_num_devices];
cl_uint n;
CL_SAFE_CALL(clGetDeviceIDs(_cl_platform,CL_DEVICE_TYPE_ALL,_num_devices,
@@ -612,7 +611,7 @@ void UCL_Device::print_all(std::ostream &out) {
// Select the platform that is associated with accelerators
// if pid < 0, select the first platform
-void UCL_Device::set_platform_accelerator(int pid) {
+int UCL_Device::set_platform_accelerator(int pid) {
if (pid < 0) {
int found = 0;
for (int n=0; n<_num_platforms; n++) {
@@ -625,10 +624,11 @@ void UCL_Device::set_platform_accelerator(int pid) {
break;
}
}
- if (found) break;
+ if (found) return UCL_SUCCESS;
}
+ return UCL_ERROR;
} else {
- set_platform(pid);
+ return set_platform(pid);
}
}
diff --git a/lib/gpu/geryon/ocl_timer.h b/lib/gpu/geryon/ocl_timer.h
index 66b79dcab101db3cbc31bbaa00263d5b563081f8..bdfec64f542f3ab29835190e8408e4a788e6569b 100644
--- a/lib/gpu/geryon/ocl_timer.h
+++ b/lib/gpu/geryon/ocl_timer.h
@@ -38,8 +38,8 @@ namespace ucl_opencl {
/// Class for timing OpenCL events
class UCL_Timer {
public:
- inline UCL_Timer() : _total_time(0.0f), _initialized(false) { }
- inline UCL_Timer(UCL_Device &dev) : _total_time(0.0f), _initialized(false)
+ inline UCL_Timer() : _total_time(0.0f), _initialized(false), has_measured_time(false) { }
+ inline UCL_Timer(UCL_Device &dev) : _total_time(0.0f), _initialized(false), has_measured_time(false)
{ init(dev); }
inline ~UCL_Timer() { clear(); }
@@ -49,11 +49,10 @@ class UCL_Timer {
inline void clear() {
if (_initialized) {
CL_DESTRUCT_CALL(clReleaseCommandQueue(_cq));
- clReleaseEvent(start_event);
- clReleaseEvent(stop_event);
_initialized=false;
_total_time=0.0;
}
+ has_measured_time = false;
}
/// Initialize default command queue for timing
@@ -66,25 +65,39 @@ class UCL_Timer {
_cq=cq;
clRetainCommandQueue(_cq);
_initialized=true;
+ has_measured_time = false;
}
/// Start timing on default command queue
- inline void start() { UCL_OCL_MARKER(_cq,&start_event); }
+ inline void start() {
+ UCL_OCL_MARKER(_cq,&start_event);
+ has_measured_time = false;
+ }
/// Stop timing on default command queue
- inline void stop() { UCL_OCL_MARKER(_cq,&stop_event); }
+ inline void stop() {
+ UCL_OCL_MARKER(_cq,&stop_event);
+ has_measured_time = true;
+ }
/// Block until the start event has been reached on device
- inline void sync_start()
- { CL_SAFE_CALL(clWaitForEvents(1,&start_event)); }
+ inline void sync_start() {
+ CL_SAFE_CALL(clWaitForEvents(1,&start_event));
+ has_measured_time = false;
+ }
/// Block until the stop event has been reached on device
- inline void sync_stop()
- { CL_SAFE_CALL(clWaitForEvents(1,&stop_event)); }
+ inline void sync_stop() {
+ CL_SAFE_CALL(clWaitForEvents(1,&stop_event));
+ has_measured_time = true;
+ }
/// Set the time elapsed to zero (not the total_time)
- inline void zero()
- { UCL_OCL_MARKER(_cq,&start_event); UCL_OCL_MARKER(_cq,&stop_event); }
+ inline void zero() {
+ has_measured_time = false;
+ UCL_OCL_MARKER(_cq,&start_event);
+ UCL_OCL_MARKER(_cq,&stop_event);
+ }
/// Set the total time to zero
inline void zero_total() { _total_time=0.0; }
@@ -99,6 +112,7 @@ class UCL_Timer {
/// Return the time (ms) of last start to stop - Forces synchronization
inline double time() {
+ if(!has_measured_time) return 0.0;
cl_ulong tstart,tend;
CL_SAFE_CALL(clWaitForEvents(1,&stop_event));
CL_SAFE_CALL(clGetEventProfilingInfo(stop_event,
@@ -107,6 +121,9 @@ class UCL_Timer {
CL_SAFE_CALL(clGetEventProfilingInfo(start_event,
CL_PROFILING_COMMAND_END,
sizeof(cl_ulong), &tstart, NULL));
+ clReleaseEvent(start_event);
+ clReleaseEvent(stop_event);
+ has_measured_time = false;
return (tend-tstart)*t_factor;
}
@@ -123,8 +140,9 @@ class UCL_Timer {
cl_event start_event, stop_event;
cl_command_queue _cq;
double _total_time;
- bool _initialized;
double t_factor;
+ bool _initialized;
+ bool has_measured_time;
};
} // namespace
diff --git a/lib/gpu/lal_atom.h b/lib/gpu/lal_atom.h
index f6a0b109f2143889e5cde02f546de6e017d15561..57880d7ca976c029ab7006b9c2a5035da8018cfc 100644
--- a/lib/gpu/lal_atom.h
+++ b/lib/gpu/lal_atom.h
@@ -322,10 +322,12 @@ class Atom {
// Copy charges to device asynchronously
inline void add_q_data() {
+ time_q.start();
if (_q_avail==false) {
q.update_device(_nall,true);
_q_avail=true;
}
+ time_q.stop();
}
// Cast quaternions to write buffer
@@ -347,10 +349,12 @@ class Atom {
// Copy quaternions to device
/** Copies nall()*4 elements **/
inline void add_quat_data() {
+ time_quat.start();
if (_quat_avail==false) {
quat.update_device(_nall*4,true);
_quat_avail=true;
}
+ time_quat.stop();
}
/// Cast velocities and tags to write buffer
diff --git a/lib/gpu/lal_device.cpp b/lib/gpu/lal_device.cpp
index 0ea128a5b38a0b5007052e14d23cc24019eab8d4..6b4d0ab2a504e404a72af7bf35d3bc436f9fdd8a 100644
--- a/lib/gpu/lal_device.cpp
+++ b/lib/gpu/lal_device.cpp
@@ -34,8 +34,8 @@ using namespace LAMMPS_AL;
template <class numtyp, class acctyp>
DeviceT::Device() : _init_count(0), _device_init(false),
- _gpu_mode(GPU_FORCE), _first_device(0),
- _last_device(0), _compiled(false) {
+ _gpu_mode(GPU_FORCE), _first_device(0),
+ _last_device(0), _platform_id(-1), _compiled(false) {
}
template <class numtyp, class acctyp>
@@ -67,6 +67,17 @@ int DeviceT::init_device(MPI_Comm world, MPI_Comm replica, const int first_gpu,
_particle_split=p_split;
_cell_size=cell_size;
_block_pair=block_pair;
+ // support selecting platform though "package device" keyword.
+ // "0:generic" will select platform 0 and tune for generic device
+ // "1:fermi" will select platform 1 and tune for Nvidia Fermi gpu
+ if (ocl_vendor) {
+ char *sep = NULL;
+ if ((sep = strstr(ocl_vendor,":"))) {
+ *sep = '\0';
+ _platform_id = atoi(ocl_vendor);
+ ocl_vendor = sep+1;
+ }
+ }
// Get the rank/size within the world
MPI_Comm_rank(_comm_world,&_world_me);
@@ -119,8 +130,16 @@ int DeviceT::init_device(MPI_Comm world, MPI_Comm replica, const int first_gpu,
// Time on the device only if 1 proc per gpu
_time_device=true;
+
+#if 0
+ // XXX: the following setting triggers a memory leak with OpenCL and MPI
+ // setting _time_device=true for all processes doesn't seem to be a
+ // problem with either (no segfault, no (large) memory leak.
+ // thus keeping this disabled for now. may need to review later.
+ // 2018-07-23 <akohlmey@gmail.com>
if (_procs_per_gpu>1)
_time_device=false;
+#endif
// Set up a per device communicator
MPI_Comm_split(node_comm,my_gpu,0,&_comm_gpu);
@@ -135,6 +154,9 @@ int DeviceT::init_device(MPI_Comm world, MPI_Comm replica, const int first_gpu,
return -7;
#endif
+ if (gpu->set_platform_accelerator(_platform_id)!=UCL_SUCCESS)
+ return -12;
+
if (gpu->set(my_gpu)!=UCL_SUCCESS)
return -6;
@@ -191,13 +213,15 @@ int DeviceT::set_ocl_params(char *ocl_vendor) {
_ocl_vendor_string="-DUSE_OPENCL";
int token_count=0;
std::string params[13];
- char *pch = strtok(ocl_vendor,"\" ");
+ char *pch = strtok(ocl_vendor,",");
+ pch = strtok(NULL,",");
+ if (pch == NULL) return -11;
while (pch != NULL) {
if (token_count==13)
return -11;
params[token_count]=pch;
token_count++;
- pch = strtok(NULL,"\" ");
+ pch = strtok(NULL,",");
}
_ocl_vendor_string+=" -DMEM_THREADS="+params[0]+
" -DTHREADS_PER_ATOM="+params[1]+
@@ -656,7 +680,7 @@ int DeviceT::compile_kernels() {
dev_program=new UCL_Program(*gpu);
int success=dev_program->load_string(device,compile_string().c_str());
if (success!=UCL_SUCCESS)
- return -4;
+ return -6;
k_zero.set_function(*dev_program,"kernel_zero");
k_info.set_function(*dev_program,"kernel_info");
_compiled=true;
diff --git a/lib/gpu/lal_device.h b/lib/gpu/lal_device.h
index 95e9f2a4309fa755bf10458f6c07ae12a8196191..695b0a62f9236f9f4e16119391ce05c6eafbf8e8 100644
--- a/lib/gpu/lal_device.h
+++ b/lib/gpu/lal_device.h
@@ -292,7 +292,7 @@ class Device {
MPI_Comm _comm_world, _comm_replica, _comm_gpu;
int _procs_per_gpu, _gpu_rank, _world_me, _world_size, _replica_me,
_replica_size;
- int _gpu_mode, _first_device, _last_device, _nthreads;
+ int _gpu_mode, _first_device, _last_device, _platform_id, _nthreads;
double _particle_split;
double _cpu_full;
double _ptx_arch;
diff --git a/lib/gpu/lal_neighbor.cpp b/lib/gpu/lal_neighbor.cpp
index 04e08c3e9c25d07b7a637b100b1d9ed4c3c3a01a..3e128bcf57349d39399f5cf625e5f863186a3630 100644
--- a/lib/gpu/lal_neighbor.cpp
+++ b/lib/gpu/lal_neighbor.cpp
@@ -127,10 +127,10 @@ void Neighbor::alloc(bool &success) {
dev_packed.clear();
success=success && (dev_packed.alloc((_max_nbors+2)*_max_atoms,*dev,
_packed_permissions)==UCL_SUCCESS);
- dev_acc.clear();
- success=success && (dev_acc.alloc(_max_atoms,*dev,
+ dev_ilist.clear();
+ success=success && (dev_ilist.alloc(_max_atoms,*dev,
UCL_READ_WRITE)==UCL_SUCCESS);
- _c_bytes+=dev_packed.row_bytes()+dev_acc.row_bytes();
+ _c_bytes+=dev_packed.row_bytes()+dev_ilist.row_bytes();
}
if (_max_host>0) {
nbor_host.clear();
@@ -197,7 +197,7 @@ void Neighbor::clear() {
host_packed.clear();
host_acc.clear();
- dev_acc.clear();
+ dev_ilist.clear();
dev_nbor.clear();
nbor_host.clear();
dev_packed.clear();
@@ -281,7 +281,7 @@ void Neighbor::get_host(const int inum, int *ilist, int *numj,
}
UCL_D_Vec<int> acc_view;
acc_view.view_offset(inum,dev_nbor,inum*2);
- ucl_copy(acc_view,host_acc,true);
+ ucl_copy(acc_view,host_acc,inum*2,true);
UCL_H_Vec<int> host_view;
host_view.alloc(_max_atoms,*dev,UCL_READ_WRITE);
@@ -289,7 +289,7 @@ void Neighbor::get_host(const int inum, int *ilist, int *numj,
int i=ilist[ii];
host_view[i] = ii;
}
- ucl_copy(dev_acc,host_view,true);
+ ucl_copy(dev_ilist,host_view,true);
time_nbor.stop();
@@ -364,7 +364,7 @@ void Neighbor::get_host3(const int inum, const int nlist, int *ilist, int *numj,
}
UCL_D_Vec<int> acc_view;
acc_view.view_offset(inum,dev_nbor,inum*2);
- ucl_copy(acc_view,host_acc,true);
+ ucl_copy(acc_view,host_acc,inum*2,true);
time_nbor.stop();
if (_use_packing==false) {
diff --git a/lib/gpu/lal_neighbor.h b/lib/gpu/lal_neighbor.h
index 05168834c6034a3cc336ef429242d441a63c9945..996deaff6d12bbbfa6789ac12dae0910b7f7f699 100644
--- a/lib/gpu/lal_neighbor.h
+++ b/lib/gpu/lal_neighbor.h
@@ -110,7 +110,7 @@ class Neighbor {
}
if (_time_device) {
time_nbor.add_to_total();
- time_kernel.add_to_total();
+ if (_use_packing==false) time_kernel.add_to_total();
if (_gpu_nbor==2) {
time_hybrid1.add_to_total();
time_hybrid2.add_to_total();
@@ -200,7 +200,7 @@ class Neighbor {
/// Host storage for nbor counts (row 1) & accumulated neighbor counts (row2)
UCL_H_Vec<int> host_acc;
/// Device storage for accessing atom indices from the neighbor list (3-body)
- UCL_D_Vec<int> dev_acc;
+ UCL_D_Vec<int> dev_ilist;
// ----------------- Data for GPU Neighbor Calculation ---------------
diff --git a/lib/gpu/lal_preprocessor.h b/lib/gpu/lal_preprocessor.h
index 69a8e61bd481b5caeedfa46991dcfcb8a9f0e9e6..566a451c21b83c34090fcc8a8a150fe42d4eef17 100644
--- a/lib/gpu/lal_preprocessor.h
+++ b/lib/gpu/lal_preprocessor.h
@@ -119,6 +119,8 @@
#define BLOCK_ELLIPSE 128
#define MAX_SHARED_TYPES 11
+#if (__CUDACC_VER_MAJOR__ < 9)
+
#ifdef _SINGLE_SINGLE
#define shfl_xor __shfl_xor
#else
@@ -132,6 +134,25 @@ ucl_inline double shfl_xor(double var, int laneMask, int width) {
}
#endif
+#else
+
+#ifdef _SINGLE_SINGLE
+ucl_inline double shfl_xor(double var, int laneMask, int width) {
+ return __shfl_xor_sync(0xffffffff, var, laneMask, width);
+}
+#else
+ucl_inline double shfl_xor(double var, int laneMask, int width) {
+ int2 tmp;
+ tmp.x = __double2hiint(var);
+ tmp.y = __double2loint(var);
+ tmp.x = __shfl_xor_sync(0xffffffff,tmp.x,laneMask,width);
+ tmp.y = __shfl_xor_sync(0xffffffff,tmp.y,laneMask,width);
+ return __hiloint2double(tmp.x,tmp.y);
+}
+#endif
+
+#endif
+
#endif
#endif
diff --git a/lib/gpu/lal_sw.cpp b/lib/gpu/lal_sw.cpp
index 24984e48785d665c63ad9cae54dc45812846a5f2..46b6382a6097aeaab518a2cc509b6eeb5d92e41b 100644
--- a/lib/gpu/lal_sw.cpp
+++ b/lib/gpu/lal_sw.cpp
@@ -243,7 +243,7 @@ void SWT::loop(const bool _eflag, const bool _vflag, const int evatom) {
this->k_three_end_vatom.run(&this->atom->x, &sw1, &sw2, &sw3,
&map, &elem2param, &_nelements,
&this->nbor->dev_nbor, &this->_nbor_data->begin(),
- &this->nbor->dev_acc, &this->dev_short_nbor,
+ &this->nbor->dev_ilist, &this->dev_short_nbor,
&end_ans->force, &end_ans->engv, &eflag, &vflag, &ainum,
&nbor_pitch, &this->_threads_per_atom, &this->_gpu_nbor);
@@ -252,7 +252,7 @@ void SWT::loop(const bool _eflag, const bool _vflag, const int evatom) {
this->k_three_end.run(&this->atom->x, &sw1, &sw2, &sw3,
&map, &elem2param, &_nelements,
&this->nbor->dev_nbor, &this->_nbor_data->begin(),
- &this->nbor->dev_acc, &this->dev_short_nbor,
+ &this->nbor->dev_ilist, &this->dev_short_nbor,
&end_ans->force, &end_ans->engv, &eflag, &vflag, &ainum,
&nbor_pitch, &this->_threads_per_atom, &this->_gpu_nbor);
diff --git a/lib/gpu/lal_sw.cu b/lib/gpu/lal_sw.cu
index 517de70691cd735cac9c9dab5cc849a257f5d373..3b6de5a683d603e74f53b8c2364942fd0f83f2cf 100644
--- a/lib/gpu/lal_sw.cu
+++ b/lib/gpu/lal_sw.cu
@@ -544,7 +544,7 @@ __kernel void k_sw_three_end(const __global numtyp4 *restrict x_,
const int nelements,
const __global int * dev_nbor,
const __global int * dev_packed,
- const __global int * dev_acc,
+ const __global int * dev_ilist,
const __global int * dev_short_nbor,
__global acctyp4 *restrict ans,
__global acctyp *restrict engv,
@@ -614,13 +614,13 @@ __kernel void k_sw_three_end(const __global numtyp4 *restrict x_,
int nbor_k,numk;
if (dev_nbor==dev_packed) {
if (gpu_nbor) nbor_k=j+nbor_pitch;
- else nbor_k=dev_acc[j]+nbor_pitch;
+ else nbor_k=dev_ilist[j]+nbor_pitch;
numk=dev_nbor[nbor_k];
nbor_k+=nbor_pitch+fast_mul(j,t_per_atom-1);
k_end=nbor_k+fast_mul(numk/t_per_atom,n_stride)+(numk & (t_per_atom-1));
nbor_k+=offset_k;
} else {
- nbor_k=dev_acc[j]+nbor_pitch;
+ nbor_k=dev_ilist[j]+nbor_pitch;
numk=dev_nbor[nbor_k];
nbor_k+=nbor_pitch;
nbor_k=dev_nbor[nbor_k];
@@ -698,7 +698,7 @@ __kernel void k_sw_three_end_vatom(const __global numtyp4 *restrict x_,
const int nelements,
const __global int * dev_nbor,
const __global int * dev_packed,
- const __global int * dev_acc,
+ const __global int * dev_ilist,
const __global int * dev_short_nbor,
__global acctyp4 *restrict ans,
__global acctyp *restrict engv,
@@ -768,13 +768,13 @@ __kernel void k_sw_three_end_vatom(const __global numtyp4 *restrict x_,
int nbor_k,numk;
if (dev_nbor==dev_packed) {
if (gpu_nbor) nbor_k=j+nbor_pitch;
- else nbor_k=dev_acc[j]+nbor_pitch;
+ else nbor_k=dev_ilist[j]+nbor_pitch;
numk=dev_nbor[nbor_k];
nbor_k+=nbor_pitch+fast_mul(j,t_per_atom-1);
k_end=nbor_k+fast_mul(numk/t_per_atom,n_stride)+(numk & (t_per_atom-1));
nbor_k+=offset_k;
} else {
- nbor_k=dev_acc[j]+nbor_pitch;
+ nbor_k=dev_ilist[j]+nbor_pitch;
numk=dev_nbor[nbor_k];
nbor_k+=nbor_pitch;
nbor_k=dev_nbor[nbor_k];
diff --git a/lib/gpu/lal_tersoff.cpp b/lib/gpu/lal_tersoff.cpp
index a63d286d9c16a9120ee9e300f16d9fda4e5ecdfc..ef55b98a2dba21347cc9830858f9663f0ff21b31 100644
--- a/lib/gpu/lal_tersoff.cpp
+++ b/lib/gpu/lal_tersoff.cpp
@@ -272,7 +272,7 @@ void TersoffT::loop(const bool _eflag, const bool _vflag, const int evatom) {
&map, &elem2param, &_nelements, &_nparams, &_zetaij,
&this->nbor->dev_nbor, &this->_nbor_data->begin(),
&this->dev_short_nbor,
- &_eflag, &this->_ainum, &nbor_pitch, &this->_threads_per_atom);
+ &eflag, &this->_ainum, &nbor_pitch, &this->_threads_per_atom);
ainum=this->ans->inum();
nbor_pitch=this->nbor->nbor_pitch();
@@ -311,7 +311,7 @@ void TersoffT::loop(const bool _eflag, const bool _vflag, const int evatom) {
this->k_three_end_vatom.run(&this->atom->x, &ts1, &ts2, &ts4, &cutsq,
&map, &elem2param, &_nelements, &_nparams, &_zetaij,
&this->nbor->dev_nbor, &this->_nbor_data->begin(),
- &this->nbor->dev_acc, &this->dev_short_nbor,
+ &this->nbor->dev_ilist, &this->dev_short_nbor,
&end_ans->force, &end_ans->engv, &eflag, &vflag, &ainum,
&nbor_pitch, &this->_threads_per_atom, &this->_gpu_nbor);
@@ -320,7 +320,7 @@ void TersoffT::loop(const bool _eflag, const bool _vflag, const int evatom) {
this->k_three_end.run(&this->atom->x, &ts1, &ts2, &ts4, &cutsq,
&map, &elem2param, &_nelements, &_nparams, &_zetaij,
&this->nbor->dev_nbor, &this->_nbor_data->begin(),
- &this->nbor->dev_acc, &this->dev_short_nbor,
+ &this->nbor->dev_ilist, &this->dev_short_nbor,
&end_ans->force, &end_ans->engv, &eflag, &vflag, &ainum,
&nbor_pitch, &this->_threads_per_atom, &this->_gpu_nbor);
}
diff --git a/lib/gpu/lal_tersoff.cu b/lib/gpu/lal_tersoff.cu
index cec0ccc44341c10f9678e57b8de628d169980262..836f05660d7b066dcaf7398ed11e10e96eec7b07 100644
--- a/lib/gpu/lal_tersoff.cu
+++ b/lib/gpu/lal_tersoff.cu
@@ -696,7 +696,7 @@ __kernel void k_tersoff_three_end(const __global numtyp4 *restrict x_,
const __global acctyp4 *restrict zetaij,
const __global int * dev_nbor,
const __global int * dev_packed,
- const __global int * dev_acc,
+ const __global int * dev_ilist,
const __global int * dev_short_nbor,
__global acctyp4 *restrict ans,
__global acctyp *restrict engv,
@@ -777,13 +777,13 @@ __kernel void k_tersoff_three_end(const __global numtyp4 *restrict x_,
int nbor_k,numk;
if (dev_nbor==dev_packed) {
if (gpu_nbor) nbor_k=j+nbor_pitch;
- else nbor_k=dev_acc[j]+nbor_pitch;
+ else nbor_k=dev_ilist[j]+nbor_pitch;
numk=dev_nbor[nbor_k];
nbor_k+=nbor_pitch+fast_mul(j,t_per_atom-1);
k_end=nbor_k+fast_mul(numk/t_per_atom,n_stride)+(numk & (t_per_atom-1));
nbor_k+=offset_k;
} else {
- nbor_k=dev_acc[j]+nbor_pitch;
+ nbor_k=dev_ilist[j]+nbor_pitch;
numk=dev_nbor[nbor_k];
nbor_k+=nbor_pitch;
nbor_k=dev_nbor[nbor_k];
@@ -941,7 +941,7 @@ __kernel void k_tersoff_three_end_vatom(const __global numtyp4 *restrict x_,
const __global acctyp4 *restrict zetaij,
const __global int * dev_nbor,
const __global int * dev_packed,
- const __global int * dev_acc,
+ const __global int * dev_ilist,
const __global int * dev_short_nbor,
__global acctyp4 *restrict ans,
__global acctyp *restrict engv,
@@ -1022,13 +1022,13 @@ __kernel void k_tersoff_three_end_vatom(const __global numtyp4 *restrict x_,
int nbor_k,numk;
if (dev_nbor==dev_packed) {
if (gpu_nbor) nbor_k=j+nbor_pitch;
- else nbor_k=dev_acc[j]+nbor_pitch;
+ else nbor_k=dev_ilist[j]+nbor_pitch;
numk=dev_nbor[nbor_k];
nbor_k+=nbor_pitch+fast_mul(j,t_per_atom-1);
k_end=nbor_k+fast_mul(numk/t_per_atom,n_stride)+(numk & (t_per_atom-1));
nbor_k+=offset_k;
} else {
- nbor_k=dev_acc[j]+nbor_pitch;
+ nbor_k=dev_ilist[j]+nbor_pitch;
numk=dev_nbor[nbor_k];
nbor_k+=nbor_pitch;
nbor_k=dev_nbor[nbor_k];
diff --git a/lib/gpu/lal_tersoff_mod.cpp b/lib/gpu/lal_tersoff_mod.cpp
index c37c07f1a1234d1945cfefdac45d42f9be446458..3cbb488cab878c497c0f0cf7eede5f9c5ce9663c 100644
--- a/lib/gpu/lal_tersoff_mod.cpp
+++ b/lib/gpu/lal_tersoff_mod.cpp
@@ -272,7 +272,7 @@ void TersoffMT::loop(const bool _eflag, const bool _vflag, const int evatom) {
&map, &elem2param, &_nelements, &_nparams, &_zetaij,
&this->nbor->dev_nbor, &this->_nbor_data->begin(),
&this->dev_short_nbor,
- &_eflag, &this->_ainum, &nbor_pitch, &this->_threads_per_atom);
+ &eflag, &this->_ainum, &nbor_pitch, &this->_threads_per_atom);
ainum=this->ans->inum();
nbor_pitch=this->nbor->nbor_pitch();
@@ -311,7 +311,7 @@ void TersoffMT::loop(const bool _eflag, const bool _vflag, const int evatom) {
this->k_three_end_vatom.run(&this->atom->x, &ts1, &ts2, &ts4, &ts5, &cutsq,
&map, &elem2param, &_nelements, &_nparams, &_zetaij,
&this->nbor->dev_nbor, &this->_nbor_data->begin(),
- &this->nbor->dev_acc, &this->dev_short_nbor,
+ &this->nbor->dev_ilist, &this->dev_short_nbor,
&end_ans->force, &end_ans->engv, &eflag, &vflag, &ainum,
&nbor_pitch, &this->_threads_per_atom, &this->_gpu_nbor);
@@ -320,7 +320,7 @@ void TersoffMT::loop(const bool _eflag, const bool _vflag, const int evatom) {
this->k_three_end.run(&this->atom->x, &ts1, &ts2, &ts4, &ts5, &cutsq,
&map, &elem2param, &_nelements, &_nparams, &_zetaij,
&this->nbor->dev_nbor, &this->_nbor_data->begin(),
- &this->nbor->dev_acc, &this->dev_short_nbor,
+ &this->nbor->dev_ilist, &this->dev_short_nbor,
&end_ans->force, &end_ans->engv, &eflag, &vflag, &ainum,
&nbor_pitch, &this->_threads_per_atom, &this->_gpu_nbor);
}
diff --git a/lib/gpu/lal_tersoff_mod.cu b/lib/gpu/lal_tersoff_mod.cu
index 576359b5146246d74078b0deff98a700bbdcb533..dfb94c41451c4a553a244e14c2aa05710cf1ebe6 100644
--- a/lib/gpu/lal_tersoff_mod.cu
+++ b/lib/gpu/lal_tersoff_mod.cu
@@ -272,7 +272,7 @@ __kernel void k_tersoff_mod_zeta(const __global numtyp4 *restrict x_,
if (ii<inum) {
int nbor_j, nbor_end, i, numj;
- const int* nbor_mem=dev_packed;
+ const __global int* nbor_mem=dev_packed;
int offset_j=offset/t_per_atom;
nbor_info(dev_nbor,dev_packed,nbor_pitch,t_per_atom,ii,offset_j,i,numj,
n_stride,nbor_end,nbor_j);
@@ -432,7 +432,7 @@ __kernel void k_tersoff_mod_repulsive(const __global numtyp4 *restrict x_,
if (ii<inum) {
int nbor, nbor_end, i, numj;
- const int* nbor_mem=dev_packed;
+ const __global int* nbor_mem=dev_packed;
nbor_info(dev_nbor,dev_packed,nbor_pitch,t_per_atom,ii,offset,i,numj,
n_stride,nbor_end,nbor);
@@ -547,7 +547,7 @@ __kernel void k_tersoff_mod_three_center(const __global numtyp4 *restrict x_,
if (ii<inum) {
int i, numj, nbor_j, nbor_end;
- const int* nbor_mem=dev_packed;
+ const __global int* nbor_mem=dev_packed;
int offset_j=offset/t_per_atom;
nbor_info(dev_nbor,dev_packed,nbor_pitch,t_per_atom,ii,offset_j,i,numj,
n_stride,nbor_end,nbor_j);
@@ -702,7 +702,7 @@ __kernel void k_tersoff_mod_three_end(const __global numtyp4 *restrict x_,
const __global acctyp4 *restrict zetaij,
const __global int * dev_nbor,
const __global int * dev_packed,
- const __global int * dev_acc,
+ const __global int * dev_ilist,
const __global int * dev_short_nbor,
__global acctyp4 *restrict ans,
__global acctyp *restrict engv,
@@ -740,7 +740,7 @@ __kernel void k_tersoff_mod_three_end(const __global numtyp4 *restrict x_,
if (ii<inum) {
int i, numj, nbor_j, nbor_end, k_end;
- const int* nbor_mem=dev_packed;
+ const __global int* nbor_mem=dev_packed;
int offset_j=offset/t_per_atom;
nbor_info(dev_nbor,dev_packed,nbor_pitch,t_per_atom,ii,offset_j,i,numj,
n_stride,nbor_end,nbor_j);
@@ -785,13 +785,13 @@ __kernel void k_tersoff_mod_three_end(const __global numtyp4 *restrict x_,
int nbor_k,numk;
if (dev_nbor==dev_packed) {
if (gpu_nbor) nbor_k=j+nbor_pitch;
- else nbor_k=dev_acc[j]+nbor_pitch;
+ else nbor_k=dev_ilist[j]+nbor_pitch;
numk=dev_nbor[nbor_k];
nbor_k+=nbor_pitch+fast_mul(j,t_per_atom-1);
k_end=nbor_k+fast_mul(numk/t_per_atom,n_stride)+(numk & (t_per_atom-1));
nbor_k+=offset_k;
} else {
- nbor_k=dev_acc[j]+nbor_pitch;
+ nbor_k=dev_ilist[j]+nbor_pitch;
numk=dev_nbor[nbor_k];
nbor_k+=nbor_pitch;
nbor_k=dev_nbor[nbor_k];
@@ -956,7 +956,7 @@ __kernel void k_tersoff_mod_three_end_vatom(const __global numtyp4 *restrict x_,
const __global acctyp4 *restrict zetaij,
const __global int * dev_nbor,
const __global int * dev_packed,
- const __global int * dev_acc,
+ const __global int * dev_ilist,
const __global int * dev_short_nbor,
__global acctyp4 *restrict ans,
__global acctyp *restrict engv,
@@ -994,7 +994,7 @@ __kernel void k_tersoff_mod_three_end_vatom(const __global numtyp4 *restrict x_,
if (ii<inum) {
int i, numj, nbor_j, nbor_end, k_end;
- const int* nbor_mem = dev_packed;
+ const __global int* nbor_mem = dev_packed;
int offset_j=offset/t_per_atom;
nbor_info(dev_nbor,dev_packed,nbor_pitch,t_per_atom,ii,offset_j,i,numj,
n_stride,nbor_end,nbor_j);
@@ -1039,13 +1039,13 @@ __kernel void k_tersoff_mod_three_end_vatom(const __global numtyp4 *restrict x_,
int nbor_k,numk;
if (dev_nbor==dev_packed) {
if (gpu_nbor) nbor_k=j+nbor_pitch;
- else nbor_k=dev_acc[j]+nbor_pitch;
+ else nbor_k=dev_ilist[j]+nbor_pitch;
numk=dev_nbor[nbor_k];
nbor_k+=nbor_pitch+fast_mul(j,t_per_atom-1);
k_end=nbor_k+fast_mul(numk/t_per_atom,n_stride)+(numk & (t_per_atom-1));
nbor_k+=offset_k;
} else {
- nbor_k=dev_acc[j]+nbor_pitch;
+ nbor_k=dev_ilist[j]+nbor_pitch;
numk=dev_nbor[nbor_k];
nbor_k+=nbor_pitch;
nbor_k=dev_nbor[nbor_k];
diff --git a/lib/gpu/lal_tersoff_zbl.cpp b/lib/gpu/lal_tersoff_zbl.cpp
index 341f663030f6330ec0ffbfd97526a24e5e59e87a..ebf67285eda47914ed06f3d0ec4abe3d4d4084aa 100644
--- a/lib/gpu/lal_tersoff_zbl.cpp
+++ b/lib/gpu/lal_tersoff_zbl.cpp
@@ -297,7 +297,7 @@ void TersoffZT::loop(const bool _eflag, const bool _vflag, const int evatom) {
&map, &elem2param, &_nelements, &_nparams, &_zetaij,
&this->nbor->dev_nbor, &this->_nbor_data->begin(),
&this->dev_short_nbor,
- &_eflag, &this->_ainum, &nbor_pitch, &this->_threads_per_atom);
+ &eflag, &this->_ainum, &nbor_pitch, &this->_threads_per_atom);
ainum=this->ans->inum();
nbor_pitch=this->nbor->nbor_pitch();
@@ -337,7 +337,7 @@ void TersoffZT::loop(const bool _eflag, const bool _vflag, const int evatom) {
this->k_three_end_vatom.run(&this->atom->x, &ts1, &ts2, &ts4, &cutsq,
&map, &elem2param, &_nelements, &_nparams, &_zetaij,
&this->nbor->dev_nbor, &this->_nbor_data->begin(),
- &this->nbor->dev_acc, &this->dev_short_nbor,
+ &this->nbor->dev_ilist, &this->dev_short_nbor,
&end_ans->force, &end_ans->engv, &eflag, &vflag, &ainum,
&nbor_pitch, &this->_threads_per_atom, &this->_gpu_nbor);
@@ -346,7 +346,7 @@ void TersoffZT::loop(const bool _eflag, const bool _vflag, const int evatom) {
this->k_three_end.run(&this->atom->x, &ts1, &ts2, &ts4, &cutsq,
&map, &elem2param, &_nelements, &_nparams, &_zetaij,
&this->nbor->dev_nbor, &this->_nbor_data->begin(),
- &this->nbor->dev_acc, &this->dev_short_nbor,
+ &this->nbor->dev_ilist, &this->dev_short_nbor,
&end_ans->force, &end_ans->engv, &eflag, &vflag, &ainum,
&nbor_pitch, &this->_threads_per_atom, &this->_gpu_nbor);
}
diff --git a/lib/gpu/lal_tersoff_zbl.cu b/lib/gpu/lal_tersoff_zbl.cu
index e8bb017f5901a9184b80403d8814aab50794500c..73ff51c70404cfea89fa7c9195e26ac12b6fbbcd 100644
--- a/lib/gpu/lal_tersoff_zbl.cu
+++ b/lib/gpu/lal_tersoff_zbl.cu
@@ -278,7 +278,7 @@ __kernel void k_tersoff_zbl_zeta(const __global numtyp4 *restrict x_,
if (ii<inum) {
int nbor_j, nbor_end, i, numj;
- const int* nbor_mem=dev_packed;
+ const __global int* nbor_mem=dev_packed;
int offset_j=offset/t_per_atom;
nbor_info(dev_nbor,dev_packed,nbor_pitch,t_per_atom,ii,offset_j,i,numj,
n_stride,nbor_end,nbor_j);
@@ -445,7 +445,7 @@ __kernel void k_tersoff_zbl_repulsive(const __global numtyp4 *restrict x_,
if (ii<inum) {
int nbor, nbor_end, i, numj;
- const int* nbor_mem=dev_packed;
+ const __global int* nbor_mem=dev_packed;
nbor_info(dev_nbor,dev_packed,nbor_pitch,t_per_atom,ii,offset,i,numj,
n_stride,nbor_end,nbor);
@@ -563,7 +563,7 @@ __kernel void k_tersoff_zbl_three_center(const __global numtyp4 *restrict x_,
if (ii<inum) {
int i, numj, nbor_j, nbor_end;
- const int* nbor_mem=dev_packed;
+ const __global int* nbor_mem=dev_packed;
int offset_j=offset/t_per_atom;
nbor_info(dev_nbor,dev_packed,nbor_pitch,t_per_atom,ii,offset_j,i,numj,
n_stride,nbor_end,nbor_j);
@@ -714,7 +714,7 @@ __kernel void k_tersoff_zbl_three_end(const __global numtyp4 *restrict x_,
const __global acctyp4 *restrict zetaij,
const __global int * dev_nbor,
const __global int * dev_packed,
- const __global int * dev_acc,
+ const __global int * dev_ilist,
const __global int * dev_short_nbor,
__global acctyp4 *restrict ans,
__global acctyp *restrict engv,
@@ -750,7 +750,7 @@ __kernel void k_tersoff_zbl_three_end(const __global numtyp4 *restrict x_,
if (ii<inum) {
int i, numj, nbor_j, nbor_end, k_end;
- const int* nbor_mem=dev_packed;
+ const __global int* nbor_mem=dev_packed;
int offset_j=offset/t_per_atom;
nbor_info(dev_nbor,dev_packed,nbor_pitch,t_per_atom,ii,offset_j,i,numj,
n_stride,nbor_end,nbor_j);
@@ -795,13 +795,13 @@ __kernel void k_tersoff_zbl_three_end(const __global numtyp4 *restrict x_,
int nbor_k,numk;
if (dev_nbor==dev_packed) {
if (gpu_nbor) nbor_k=j+nbor_pitch;
- else nbor_k=dev_acc[j]+nbor_pitch;
+ else nbor_k=dev_ilist[j]+nbor_pitch;
numk=dev_nbor[nbor_k];
nbor_k+=nbor_pitch+fast_mul(j,t_per_atom-1);
k_end=nbor_k+fast_mul(numk/t_per_atom,n_stride)+(numk & (t_per_atom-1));
nbor_k+=offset_k;
} else {
- nbor_k=dev_acc[j]+nbor_pitch;
+ nbor_k=dev_ilist[j]+nbor_pitch;
numk=dev_nbor[nbor_k];
nbor_k+=nbor_pitch;
nbor_k=dev_nbor[nbor_k];
@@ -959,7 +959,7 @@ __kernel void k_tersoff_zbl_three_end_vatom(const __global numtyp4 *restrict x_,
const __global acctyp4 *restrict zetaij,
const __global int * dev_nbor,
const __global int * dev_packed,
- const __global int * dev_acc,
+ const __global int * dev_ilist,
const __global int * dev_short_nbor,
__global acctyp4 *restrict ans,
__global acctyp *restrict engv,
@@ -995,7 +995,7 @@ __kernel void k_tersoff_zbl_three_end_vatom(const __global numtyp4 *restrict x_,
if (ii<inum) {
int i, numj, nbor_j, nbor_end, k_end;
- const int* nbor_mem = dev_packed;
+ const __global int* nbor_mem = dev_packed;
int offset_j=offset/t_per_atom;
nbor_info(dev_nbor,dev_packed,nbor_pitch,t_per_atom,ii,offset_j,i,numj,
n_stride,nbor_end,nbor_j);
@@ -1040,13 +1040,13 @@ __kernel void k_tersoff_zbl_three_end_vatom(const __global numtyp4 *restrict x_,
int nbor_k,numk;
if (dev_nbor==dev_packed) {
if (gpu_nbor) nbor_k=j+nbor_pitch;
- else nbor_k=dev_acc[j]+nbor_pitch;
+ else nbor_k=dev_ilist[j]+nbor_pitch;
numk=dev_nbor[nbor_k];
nbor_k+=nbor_pitch+fast_mul(j,t_per_atom-1);
k_end=nbor_k+fast_mul(numk/t_per_atom,n_stride)+(numk & (t_per_atom-1));
nbor_k+=offset_k;
} else {
- nbor_k=dev_acc[j]+nbor_pitch;
+ nbor_k=dev_ilist[j]+nbor_pitch;
numk=dev_nbor[nbor_k];
nbor_k+=nbor_pitch;
nbor_k=dev_nbor[nbor_k];
diff --git a/lib/gpu/lal_vashishta.cpp b/lib/gpu/lal_vashishta.cpp
index d03ac992bd468ea0677a6b537468016f56b7b3e0..5a01a9bd46f185938710ab65cfd75761b3f5fb1e 100644
--- a/lib/gpu/lal_vashishta.cpp
+++ b/lib/gpu/lal_vashishta.cpp
@@ -278,7 +278,7 @@ void VashishtaT::loop(const bool _eflag, const bool _vflag, const int evatom) {
this->k_three_end_vatom.run(&this->atom->x, ¶m1, ¶m2, ¶m3, ¶m4, ¶m5,
&map, &elem2param, &_nelements,
&this->nbor->dev_nbor, &this->_nbor_data->begin(),
- &this->nbor->dev_acc, &this->dev_short_nbor,
+ &this->nbor->dev_ilist, &this->dev_short_nbor,
&end_ans->force, &end_ans->engv, &eflag, &vflag, &ainum,
&nbor_pitch, &this->_threads_per_atom, &this->_gpu_nbor);
} else {
@@ -286,7 +286,7 @@ void VashishtaT::loop(const bool _eflag, const bool _vflag, const int evatom) {
this->k_three_end.run(&this->atom->x, ¶m1, ¶m2, ¶m3, ¶m4, ¶m5,
&map, &elem2param, &_nelements,
&this->nbor->dev_nbor, &this->_nbor_data->begin(),
- &this->nbor->dev_acc, &this->dev_short_nbor,
+ &this->nbor->dev_ilist, &this->dev_short_nbor,
&end_ans->force, &end_ans->engv, &eflag, &vflag, &ainum,
&nbor_pitch, &this->_threads_per_atom, &this->_gpu_nbor);
}
diff --git a/lib/gpu/lal_vashishta.cu b/lib/gpu/lal_vashishta.cu
index d2e8bb1496abfd7355f88730cbb0d69c1c22339d..0da46c3b534cc29cba600851db0dda05a2cf38da 100644
--- a/lib/gpu/lal_vashishta.cu
+++ b/lib/gpu/lal_vashishta.cu
@@ -554,7 +554,7 @@ __kernel void k_vashishta_three_end(const __global numtyp4 *restrict x_,
const int nelements,
const __global int * dev_nbor,
const __global int * dev_packed,
- const __global int * dev_acc,
+ const __global int * dev_ilist,
const __global int * dev_short_nbor,
__global acctyp4 *restrict ans,
__global acctyp *restrict engv,
@@ -623,13 +623,13 @@ __kernel void k_vashishta_three_end(const __global numtyp4 *restrict x_,
int nbor_k,numk;
if (dev_nbor==dev_packed) {
if (gpu_nbor) nbor_k=j+nbor_pitch;
- else nbor_k=dev_acc[j]+nbor_pitch;
+ else nbor_k=dev_ilist[j]+nbor_pitch;
numk=dev_nbor[nbor_k];
nbor_k+=nbor_pitch+fast_mul(j,t_per_atom-1);
k_end=nbor_k+fast_mul(numk/t_per_atom,n_stride)+(numk & (t_per_atom-1));
nbor_k+=offset_k;
} else {
- nbor_k=dev_acc[j]+nbor_pitch;
+ nbor_k=dev_ilist[j]+nbor_pitch;
numk=dev_nbor[nbor_k];
nbor_k+=nbor_pitch;
nbor_k=dev_nbor[nbor_k];
@@ -709,7 +709,7 @@ __kernel void k_vashishta_three_end_vatom(const __global numtyp4 *restrict x_,
const int nelements,
const __global int * dev_nbor,
const __global int * dev_packed,
- const __global int * dev_acc,
+ const __global int * dev_ilist,
const __global int * dev_short_nbor,
__global acctyp4 *restrict ans,
__global acctyp *restrict engv,
@@ -778,13 +778,13 @@ __kernel void k_vashishta_three_end_vatom(const __global numtyp4 *restrict x_,
int nbor_k,numk;
if (dev_nbor==dev_packed) {
if (gpu_nbor) nbor_k=j+nbor_pitch;
- else nbor_k=dev_acc[j]+nbor_pitch;
+ else nbor_k=dev_ilist[j]+nbor_pitch;
numk=dev_nbor[nbor_k];
nbor_k+=nbor_pitch+fast_mul(j,t_per_atom-1);
k_end=nbor_k+fast_mul(numk/t_per_atom,n_stride)+(numk & (t_per_atom-1));
nbor_k+=offset_k;
} else {
- nbor_k=dev_acc[j]+nbor_pitch;
+ nbor_k=dev_ilist[j]+nbor_pitch;
numk=dev_nbor[nbor_k];
nbor_k+=nbor_pitch;
nbor_k=dev_nbor[nbor_k];
diff --git a/lib/kokkos/cmake/kokkos_settings.cmake b/lib/kokkos/cmake/kokkos_settings.cmake
index 21c9d75a96aa52fd349c751aa0c2fa0f12316c91..58b30ba24d7b3aa8324f26da07bcceb436c28bb2 100644
--- a/lib/kokkos/cmake/kokkos_settings.cmake
+++ b/lib/kokkos/cmake/kokkos_settings.cmake
@@ -158,7 +158,7 @@ if (NOT "${KOKKOS_INTERNAL_PATHS}" STREQUAL "")
set(KOKKOS_SETTINGS ${KOKKOS_SETTINGS} ${KOKKOS_INTERNAL_PATHS})
endif()
if (NOT "${KOKKOS_INTERNAL_ADDTOPATH}" STREQUAL "")
- set(KOKKOS_SETTINGS ${KOKKOS_SETTINGS} "PATH=\"${KOKKOS_INTERNAL_ADDTOPATH}:$ENV{PATH}\"")
+ set(KOKKOS_SETTINGS ${KOKKOS_SETTINGS} "PATH=${KOKKOS_INTERNAL_ADDTOPATH}:$ENV{PATH}")
endif()
if (CMAKE_CXX_STANDARD)
diff --git a/lib/kokkos/core/src/Cuda/Kokkos_Cuda_View.hpp b/lib/kokkos/core/src/Cuda/Kokkos_Cuda_View.hpp
index 49b11f3ae0a4a0fcc9b462412ad2b0fa9baf16cf..11aa695f087255e7cfbc4bd166acab40ce2f73d7 100644
--- a/lib/kokkos/core/src/Cuda/Kokkos_Cuda_View.hpp
+++ b/lib/kokkos/core/src/Cuda/Kokkos_Cuda_View.hpp
@@ -292,7 +292,8 @@ public:
#if ! defined( KOKKOS_ENABLE_CUDA_LDG_INTRINSIC )
if ( 0 == r ) {
- Kokkos::abort("Cuda const random access View using Cuda texture memory requires Kokkos to allocate the View's memory");
+ //Kokkos::abort("Cuda const random access View using Cuda texture memory requires Kokkos to allocate the View's memory");
+ return handle_type();
}
#endif
diff --git a/lib/latte/Install.py b/lib/latte/Install.py
index e1ed9d4eaaf4c95c2d3f09b91dee4f9db4441702..3b211858dd15b5336c0d962e7bf9bcbe88edcf08 100644
--- a/lib/latte/Install.py
+++ b/lib/latte/Install.py
@@ -40,7 +40,7 @@ version = '1.2.1'
checksums = { \
'1.1.0' : '533635721ee222d0ed2925a18fb5b294', \
'1.2.0' : '68bf0db879da5e068a71281020239ae7', \
- '1.2.1' : 'bed76e7e76c545c36dd848a8f1fd35eb' \
+ '1.2.1' : '85ac414fdada2d04619c8f936344df14', \
}
# print error message or help
diff --git a/lib/latte/Makefile.lammps.ifort b/lib/latte/Makefile.lammps.ifort
index 0491bdd8a5f41065df995def3b3c0105600fdf28..90010210af583dfd2a38823a82f64222ea0c460a 100644
--- a/lib/latte/Makefile.lammps.ifort
+++ b/lib/latte/Makefile.lammps.ifort
@@ -4,9 +4,9 @@
latte_SYSINC =
latte_SYSLIB = ../../lib/latte/filelink.o \
- -llatte -lifcore -lsvml -lompstub -limf -lmkl_intel_lp64 \
- -lmkl_intel_thread -lmkl_core -lmkl_intel_thread -lpthread \
- -openmp -O0
+ -llatte -lifport -lifcore -lsvml -lompstub -limf \
+ -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core \
+ -lmkl_intel_thread -lpthread -openmp
latte_SYSPATH = -openmp -L${MKLROOT}/lib/intel64 -lmkl_lapack95_lp64 \
-L/opt/intel/composer_xe_2013_sp1.2.144/compiler/lib/intel64
diff --git a/python/lammps.py b/python/lammps.py
index e7d703e12a5eef9bdd8e5378e0795fe0e21a8e3c..2f4ffb642ef084fbbd1b7567bfc363220288dafc 100644
--- a/python/lammps.py
+++ b/python/lammps.py
@@ -708,6 +708,12 @@ class Atom(object):
self.lmp.eval("vy[%d]" % self.index),
self.lmp.eval("vz[%d]" % self.index))
+ @velocity.setter
+ def velocity(self, value):
+ self.lmp.set("atom", self.index, "vx", value[0])
+ self.lmp.set("atom", self.index, "vy", value[1])
+ self.lmp.set("atom", self.index, "vz", value[2])
+
@property
def force(self):
return (self.lmp.eval("fx[%d]" % self.index),
@@ -738,6 +744,11 @@ class Atom2D(Atom):
return (self.lmp.eval("vx[%d]" % self.index),
self.lmp.eval("vy[%d]" % self.index))
+ @velocity.setter
+ def velocity(self, value):
+ self.lmp.set("atom", self.index, "vx", value[0])
+ self.lmp.set("atom", self.index, "vy", value[1])
+
@property
def force(self):
return (self.lmp.eval("fx[%d]" % self.index),
diff --git a/src/.gitignore b/src/.gitignore
index 058833ffb38dfca1ea188bebfe5522f943a1c6df..df3a22a5cd08b1a924aadde018674d972f340a5f 100644
--- a/src/.gitignore
+++ b/src/.gitignore
@@ -729,6 +729,8 @@
/pair_eam.h
/pair_eam_alloy.cpp
/pair_eam_alloy.h
+/pair_eam_cd.cpp
+/pair_eam_cd.h
/pair_eam_fs.cpp
/pair_eam_fs.h
/pair_edip.cpp
diff --git a/src/BODY/body_rounded_polygon.cpp b/src/BODY/body_rounded_polygon.cpp
new file mode 100644
index 0000000000000000000000000000000000000000..1e232f0f3f59fbbdab6bf470920bcf2a70ff2036
--- /dev/null
+++ b/src/BODY/body_rounded_polygon.cpp
@@ -0,0 +1,452 @@
+/* ----------------------------------------------------------------------
+ LAMMPS - Large-scale Atomic/Molecular Massively Parallel Simulator
+ http://lammps.sandia.gov, Sandia National Laboratories
+ Steve Plimpton, sjplimp@sandia.gov
+
+ Copyright (2003) Sandia Corporation. Under the terms of Contract
+ DE-AC04-94AL85000 with Sandia Corporation, the U.S. Government retains
+ certain rights in this software. This software is distributed under
+ the GNU General Public License.
+
+ See the README file in the top-level LAMMPS directory.
+------------------------------------------------------------------------- */
+
+/* ----------------------------------------------------------------------
+ Contributing author: Trung Dac Nguyen (ndactrung@gmail.com)
+------------------------------------------------------------------------- */
+
+#include <cstdlib>
+#include "body_rounded_polygon.h"
+#include "atom_vec_body.h"
+#include "atom.h"
+#include "force.h"
+#include "domain.h"
+#include "math_extra.h"
+#include "memory.h"
+#include "error.h"
+
+using namespace LAMMPS_NS;
+
+#define EPSILON 1.0e-7
+enum{SPHERE,LINE}; // also in DumpImage
+
+/* ---------------------------------------------------------------------- */
+
+BodyRoundedPolygon::BodyRoundedPolygon(LAMMPS *lmp, int narg, char **arg) :
+ Body(lmp, narg, arg)
+{
+ if (narg != 3) error->all(FLERR,"Invalid body rounded/polygon command");
+
+ if (domain->dimension != 2)
+ error->all(FLERR,"Atom_style body rounded/polygon "
+ "can only be used in 2d simulations");
+
+ // nmin and nmax are minimum and maximum number of vertices
+
+ int nmin = force->inumeric(FLERR,arg[1]);
+ int nmax = force->inumeric(FLERR,arg[2]);
+ if (nmin <= 0 || nmin > nmax)
+ error->all(FLERR,"Invalid body rounded/polygon command");
+
+ size_forward = 0;
+
+ // 1 integer for number of vertices,
+ // 3*nmax doubles for vertex coordinates + 2*nmax doubles for edge ends
+ // 1 double for the enclosing radius
+ // 1 double for the rounded radius
+
+ size_border = 1 + 3*nmax + 2*nmax + 1 + 1;
+
+ // NOTE: need to set appropriate nnbin param for dcp
+
+ icp = new MyPoolChunk<int>(1,1);
+ dcp = new MyPoolChunk<double>(3*nmin+2*nmin+1+1,3*nmax+2*nmax+1+1);
+
+ memory->create(imflag,nmax,"body/rounded/polygon:imflag");
+ memory->create(imdata,nmax,7,"body/nparticle:imdata");
+}
+
+/* ---------------------------------------------------------------------- */
+
+BodyRoundedPolygon::~BodyRoundedPolygon()
+{
+ delete icp;
+ delete dcp;
+ memory->destroy(imflag);
+ memory->destroy(imdata);
+}
+
+/* ---------------------------------------------------------------------- */
+
+int BodyRoundedPolygon::nsub(AtomVecBody::Bonus *bonus)
+{
+ return bonus->ivalue[0];
+}
+
+/* ---------------------------------------------------------------------- */
+
+double *BodyRoundedPolygon::coords(AtomVecBody::Bonus *bonus)
+{
+ return bonus->dvalue;
+}
+
+/* ---------------------------------------------------------------------- */
+
+int BodyRoundedPolygon::nedges(AtomVecBody::Bonus *bonus)
+{
+ int nvertices = bonus->ivalue[0];
+ if (nvertices == 1) return 0;
+ else if (nvertices == 2) return 1;
+ return nvertices;
+}
+
+/* ---------------------------------------------------------------------- */
+
+double *BodyRoundedPolygon::edges(AtomVecBody::Bonus *bonus)
+{
+ return bonus->dvalue+3*nsub(bonus);
+}
+
+/* ---------------------------------------------------------------------- */
+
+double BodyRoundedPolygon::enclosing_radius(struct AtomVecBody::Bonus *bonus)
+{
+ int nvertices = bonus->ivalue[0];
+ if (nvertices == 1 || nvertices == 2)
+ return *(bonus->dvalue+3*nsub(bonus)+2);
+ return *(bonus->dvalue + 3*nsub(bonus) + 2*nsub(bonus));
+}
+
+/* ---------------------------------------------------------------------- */
+
+double BodyRoundedPolygon::rounded_radius(struct AtomVecBody::Bonus *bonus)
+{
+ int nvertices = bonus->ivalue[0];
+ if (nvertices == 1 || nvertices == 2)
+ return *(bonus->dvalue+3*nsub(bonus)+2+1);
+ return *(bonus->dvalue + 3*nsub(bonus) + 2*nsub(bonus)+1);
+}
+
+/* ---------------------------------------------------------------------- */
+
+int BodyRoundedPolygon::pack_border_body(AtomVecBody::Bonus *bonus, double *buf)
+{
+ int nsub = bonus->ivalue[0];
+ buf[0] = nsub;
+ memcpy(&buf[1],bonus->dvalue,(3*nsub+2*nsub+1+1)*sizeof(double));
+ return 1+(3*nsub+2*nsub+1+1);
+}
+
+/* ---------------------------------------------------------------------- */
+
+int BodyRoundedPolygon::unpack_border_body(AtomVecBody::Bonus *bonus,
+ double *buf)
+{
+ int nsub = static_cast<int> (buf[0]);
+ bonus->ivalue[0] = nsub;
+ memcpy(bonus->dvalue,&buf[1],(3*nsub+2*nsub+1+1)*sizeof(double));
+ return 1+(3*nsub+2*nsub+1+1);
+}
+
+/* ----------------------------------------------------------------------
+ populate bonus data structure with data file values
+------------------------------------------------------------------------- */
+
+void BodyRoundedPolygon::data_body(int ibonus, int ninteger, int ndouble,
+ int *ifile, double *dfile)
+{
+ AtomVecBody::Bonus *bonus = &avec->bonus[ibonus];
+
+ // set ninteger, ndouble in bonus and allocate 2 vectors of ints, doubles
+
+ if (ninteger != 1)
+ error->one(FLERR,"Incorrect # of integer values in "
+ "Bodies section of data file");
+ int nsub = ifile[0];
+ if (nsub < 1)
+ error->one(FLERR,"Incorrect integer value in "
+ "Bodies section of data file");
+
+ // nentries = number of double entries to be read from Body section:
+ // 6 for inertia + 3*nsub for vertex coords + 1 for rounded radius
+
+ int nentries = 6 + 3*nsub + 1;
+ if (ndouble != nentries)
+ error->one(FLERR,"Incorrect # of floating-point values in "
+ "Bodies section of data file");
+
+ bonus->ninteger = 1;
+ bonus->ivalue = icp->get(bonus->iindex);
+ bonus->ivalue[0] = nsub;
+ bonus->ndouble = 3*nsub + 2*nsub + 1 + 1;
+ bonus->dvalue = dcp->get(bonus->ndouble,bonus->dindex);
+
+ // diagonalize inertia tensor
+
+ double tensor[3][3];
+ tensor[0][0] = dfile[0];
+ tensor[1][1] = dfile[1];
+ tensor[2][2] = dfile[2];
+ tensor[0][1] = tensor[1][0] = dfile[3];
+ tensor[0][2] = tensor[2][0] = dfile[4];
+ tensor[1][2] = tensor[2][1] = dfile[5];
+
+ double *inertia = bonus->inertia;
+ double evectors[3][3];
+ int ierror = MathExtra::jacobi(tensor,inertia,evectors);
+ if (ierror) error->one(FLERR,
+ "Insufficient Jacobi rotations for body nparticle");
+
+ // if any principal moment < scaled EPSILON, set to 0.0
+
+ double max;
+ max = MAX(inertia[0],inertia[1]);
+ max = MAX(max,inertia[2]);
+
+ if (inertia[0] < EPSILON*max) inertia[0] = 0.0;
+ if (inertia[1] < EPSILON*max) inertia[1] = 0.0;
+ if (inertia[2] < EPSILON*max) inertia[2] = 0.0;
+
+ // exyz_space = principal axes in space frame
+
+ double ex_space[3],ey_space[3],ez_space[3];
+
+ ex_space[0] = evectors[0][0];
+ ex_space[1] = evectors[1][0];
+ ex_space[2] = evectors[2][0];
+ ey_space[0] = evectors[0][1];
+ ey_space[1] = evectors[1][1];
+ ey_space[2] = evectors[2][1];
+ ez_space[0] = evectors[0][2];
+ ez_space[1] = evectors[1][2];
+ ez_space[2] = evectors[2][2];
+
+ // enforce 3 evectors as a right-handed coordinate system
+ // flip 3rd vector if needed
+
+ double cross[3];
+ MathExtra::cross3(ex_space,ey_space,cross);
+ if (MathExtra::dot3(cross,ez_space) < 0.0) MathExtra::negate3(ez_space);
+
+ // create initial quaternion
+
+ MathExtra::exyz_to_q(ex_space,ey_space,ez_space,bonus->quat);
+
+ // bonus->dvalue = the first 3*nsub elements are sub-particle displacements
+ // find the enclosing radius of the body from the maximum displacement
+
+ int i,m;
+ double delta[3], rsq, erad, rrad;
+ double erad2 = 0;
+ int j = 6;
+ int k = 0;
+ for (i = 0; i < nsub; i++) {
+ delta[0] = dfile[j];
+ delta[1] = dfile[j+1];
+ delta[2] = dfile[j+2];
+ MathExtra::transpose_matvec(ex_space,ey_space,ez_space,
+ delta,&bonus->dvalue[k]);
+ rsq = delta[0] * delta[0] + delta[1] * delta[1] +
+ delta[2] * delta[2];
+ if (rsq > erad2) erad2 = rsq;
+ j += 3;
+ k += 3;
+ }
+
+ // .. the next 2*nsub elements are edge ends
+
+ int nedges;
+ if (nsub == 1) { // spheres
+ nedges = 0;
+ bonus->dvalue[k] = 0;
+ *(&bonus->dvalue[k]+1) = 0;
+ k += 2;
+
+ // the last element of bonus->dvalue is the rounded & enclosing radius
+
+ rrad = 0.5 * dfile[j];
+ bonus->dvalue[k] = rrad;
+ erad = rrad;
+
+ k++;
+ bonus->dvalue[k] = rrad;
+
+ atom->radius[bonus->ilocal] = erad;
+
+ } else if (nsub == 2) { // rods
+ nedges = 1;
+ for (i = 0; i < nedges; i++) {
+ bonus->dvalue[k] = 0;
+ *(&bonus->dvalue[k]+1) = 1;
+ k += 2;
+ }
+
+ erad = sqrt(erad2);
+ bonus->dvalue[k] = erad;
+
+ // the last element of bonus->dvalue is the rounded radius
+
+ rrad = 0.5 * dfile[j];
+ k++;
+ bonus->dvalue[k] = rrad;
+
+ atom->radius[bonus->ilocal] = erad + rrad;
+
+ } else { // polygons
+ nedges = nsub;
+ for (i = 0; i < nedges; i++) {
+ bonus->dvalue[k] = i;
+ m = i+1;
+ if (m == nedges) m = 0;
+ *(&bonus->dvalue[k]+1) = m;
+ k += 2;
+ }
+
+ // the next to last element is the enclosing radius
+
+ erad = sqrt(erad2);
+ bonus->dvalue[k] = erad;
+
+ // the last element of bonus->dvalue is the rounded radius
+
+ rrad = 0.5 * dfile[j];
+ k++;
+ bonus->dvalue[k] = rrad;
+
+ atom->radius[bonus->ilocal] = erad + rrad;
+ }
+}
+
+/* ----------------------------------------------------------------------
+ return radius of body particle defined by ifile/dfile params
+ params are ordered as in data file
+ called by Molecule class which needs single body size
+------------------------------------------------------------------------- */
+
+double BodyRoundedPolygon::radius_body(int ninteger, int ndouble,
+ int *ifile, double *dfile)
+{
+ int nsub = ifile[0];
+ if (nsub < 1)
+ error->one(FLERR,"Incorrect integer value in "
+ "Bodies section of data file");
+ if (ndouble != 6 + 3*nsub + 1)
+ error->one(FLERR,"Incorrect # of floating-point values in "
+ "Bodies section of data file");
+
+ // sub-particle coords are relative to body center at (0,0,0)
+ // offset = 6 for sub-particle coords
+
+ double onerad;
+ double maxrad = 0.0;
+ double delta[3];
+
+ int offset = 6;
+ for (int i = 0; i < nsub; i++) {
+ delta[0] = dfile[offset];
+ delta[1] = dfile[offset+1];
+ delta[2] = dfile[offset+2];
+ offset += 3;
+ onerad = MathExtra::len3(delta);
+ maxrad = MAX(maxrad,onerad);
+ }
+
+ // add in radius of rounded corners
+
+ return maxrad + 0.5*dfile[offset];
+}
+
+/* ---------------------------------------------------------------------- */
+
+int BodyRoundedPolygon::noutcol()
+{
+ // the number of columns for the vertex coordinates
+
+ return 3;
+}
+
+/* ---------------------------------------------------------------------- */
+
+int BodyRoundedPolygon::noutrow(int ibonus)
+{
+ // only return the first nsub rows for the vertex coordinates
+
+ return avec->bonus[ibonus].ivalue[0];
+}
+
+/* ---------------------------------------------------------------------- */
+
+void BodyRoundedPolygon::output(int ibonus, int m, double *values)
+{
+ AtomVecBody::Bonus *bonus = &avec->bonus[ibonus];
+
+ double p[3][3];
+ MathExtra::quat_to_mat(bonus->quat,p);
+ MathExtra::matvec(p,&bonus->dvalue[3*m],values);
+
+ double *x = atom->x[bonus->ilocal];
+ values[0] += x[0];
+ values[1] += x[1];
+ values[2] += x[2];
+}
+
+/* ---------------------------------------------------------------------- */
+
+int BodyRoundedPolygon::image(int ibonus, double flag1, double flag2,
+ int *&ivec, double **&darray)
+{
+ int j;
+ double p[3][3];
+ double *x, rrad;
+
+ AtomVecBody::Bonus *bonus = &avec->bonus[ibonus];
+ int n = bonus->ivalue[0];
+
+ if (n == 1) {
+ for (int i = 0; i < n; i++) {
+ imflag[i] = SPHERE;
+ MathExtra::quat_to_mat(bonus->quat,p);
+ MathExtra::matvec(p,&bonus->dvalue[3*i],imdata[i]);
+
+ rrad = enclosing_radius(bonus);
+ x = atom->x[bonus->ilocal];
+ imdata[i][0] += x[0];
+ imdata[i][1] += x[1];
+ imdata[i][2] += x[2];
+ if (flag1 <= 0) imdata[i][3] = 2*rrad;
+ else imdata[i][3] = flag1;
+ }
+
+ } else {
+
+ // first end pt of each line
+
+ for (int i = 0; i < n; i++) {
+ imflag[i] = LINE;
+ MathExtra::quat_to_mat(bonus->quat,p);
+ MathExtra::matvec(p,&bonus->dvalue[3*i],imdata[i]);
+
+ rrad = rounded_radius(bonus);
+ x = atom->x[bonus->ilocal];
+ imdata[i][0] += x[0];
+ imdata[i][1] += x[1];
+ imdata[i][2] += x[2];
+ if (flag1 <= 0) imdata[i][6] = 2*rrad;
+ else imdata[i][6] = flag1;
+ }
+
+ // second end pt of each line
+
+ for (int i = 0; i < n; i++) {
+ j = i+1;
+ if (j == n) j = 0;
+ imdata[i][3] = imdata[j][0];
+ imdata[i][4] = imdata[j][1];
+ imdata[i][5] = imdata[j][2];
+ }
+ }
+
+ ivec = imflag;
+ darray = imdata;
+ return n;
+}
diff --git a/src/BODY/body_rounded_polygon.h b/src/BODY/body_rounded_polygon.h
new file mode 100644
index 0000000000000000000000000000000000000000..b6f45c5cf551cc35fc1ff2d817684f5250cf23f4
--- /dev/null
+++ b/src/BODY/body_rounded_polygon.h
@@ -0,0 +1,86 @@
+/* -*- c++ -*- ----------------------------------------------------------
+ LAMMPS - Large-scale Atomic/Molecular Massively Parallel Simulator
+ http://lammps.sandia.gov, Sandia National Laboratories
+ Steve Plimpton, sjplimp@sandia.gov
+
+ Copyright (2003) Sandia Corporation. Under the terms of Contract
+ DE-AC04-94AL85000 with Sandia Corporation, the U.S. Government retains
+ certain rights in this software. This software is distributed under
+ the GNU General Public License.
+
+ See the README file in the top-level LAMMPS directory.
+------------------------------------------------------------------------- */
+
+#ifdef BODY_CLASS
+
+BodyStyle(rounded/polygon,BodyRoundedPolygon)
+
+#else
+
+#ifndef LMP_BODY_ROUNDED_POLYGON_H
+#define LMP_BODY_ROUNDED_POLYGON_H
+
+#include "body.h"
+#include "atom_vec_body.h"
+
+namespace LAMMPS_NS {
+
+class BodyRoundedPolygon : public Body {
+ public:
+ BodyRoundedPolygon(class LAMMPS *, int, char **);
+ ~BodyRoundedPolygon();
+ int nsub(struct AtomVecBody::Bonus *);
+ double *coords(struct AtomVecBody::Bonus *);
+ int nedges(struct AtomVecBody::Bonus *);
+ double *edges(struct AtomVecBody::Bonus *);
+ double enclosing_radius(struct AtomVecBody::Bonus *);
+ double rounded_radius(struct AtomVecBody::Bonus *);
+
+ int pack_border_body(struct AtomVecBody::Bonus *, double *);
+ int unpack_border_body(struct AtomVecBody::Bonus *, double *);
+ void data_body(int, int, int, int *, double *);
+ double radius_body(int, int, int *, double *);
+
+ int noutrow(int);
+ int noutcol();
+ void output(int, int, double *);
+ int image(int, double, double, int *&, double **&);
+
+ private:
+ int *imflag;
+ double **imdata;
+};
+
+}
+
+#endif
+#endif
+
+/* ERROR/WARNING messages:
+
+E: Invalid body rounded/polygon command
+
+Arguments in atom-style command are not correct.
+
+E: Invalid format in Bodies section of data file
+
+The specified number of integer or floating point values does not
+appear.
+
+E: Incorrect # of integer values in Bodies section of data file
+
+See doc page for body style.
+
+E: Incorrect integer value in Bodies section of data file
+
+See doc page for body style.
+
+E: Incorrect # of floating-point values in Bodies section of data file
+
+See doc page for body style.
+
+E: Insufficient Jacobi rotations for body nparticle
+
+Eigensolve for rigid body was not sufficiently accurate.
+
+*/
diff --git a/src/BODY/body_rounded_polyhedron.cpp b/src/BODY/body_rounded_polyhedron.cpp
new file mode 100644
index 0000000000000000000000000000000000000000..6a9b97ae2348ec344b75656afbb3d5261282e5b5
--- /dev/null
+++ b/src/BODY/body_rounded_polyhedron.cpp
@@ -0,0 +1,526 @@
+/* ----------------------------------------------------------------------
+ LAMMPS - Large-scale Atomic/Molecular Massively Parallel Simulator
+ http://lammps.sandia.gov, Sandia National Laboratories
+ Steve Plimpton, sjplimp@sandia.gov
+
+ Copyright (2003) Sandia Corporation. Under the terms of Contract
+ DE-AC04-94AL85000 with Sandia Corporation, the U.S. Government retains
+ certain rights in this software. This software is distributed under
+ the GNU General Public License.
+
+ See the README file in the top-level LAMMPS directory.
+------------------------------------------------------------------------- */
+
+/* ----------------------------------------------------------------------
+ Contributing author: Trung Dac Nguyen (ndactrung@gmail.com)
+------------------------------------------------------------------------- */
+
+#include <cstdlib>
+#include "body_rounded_polyhedron.h"
+#include "atom_vec_body.h"
+#include "atom.h"
+#include "force.h"
+#include "domain.h"
+#include "math_extra.h"
+#include "memory.h"
+#include "error.h"
+
+using namespace LAMMPS_NS;
+
+#define EPSILON 1.0e-7
+#define MAX_FACE_SIZE 4 // maximum number of vertices per face (for now)
+
+enum{SPHERE,LINE}; // also in DumpImage
+
+/* ---------------------------------------------------------------------- */
+
+BodyRoundedPolyhedron::BodyRoundedPolyhedron(LAMMPS *lmp, int narg, char **arg) :
+ Body(lmp, narg, arg)
+{
+ if (narg != 3) error->all(FLERR,"Invalid body rounded/polygon command");
+
+ // nmin and nmax are minimum and maximum number of vertices
+
+ int nmin = force->inumeric(FLERR,arg[1]);
+ int nmax = force->inumeric(FLERR,arg[2]);
+ if (nmin <= 0 || nmin > nmax)
+ error->all(FLERR,"Invalid body rounded/polyhedron command");
+
+ size_forward = 0;
+
+ // 3 integers: 1 for no. of vertices, 1 for no. of edges, 1 for no. of faces
+ // 3*nmax doubles for vertex coordinates + 2*nmax doubles for edge ends +
+ // (MAX_FACE_SIZE+1)*nmax for faces
+ // 1 double for the enclosing radius
+ // 1 double for the rounded radius
+
+ size_border = 3 + 3*nmax + 2*nmax + MAX_FACE_SIZE*nmax + 1 + 1;
+
+ // NOTE: need to set appropriate nnbin param for dcp
+
+ icp = new MyPoolChunk<int>(1,3);
+ dcp = new MyPoolChunk<double>(3*nmin+2+1+1,
+ 3*nmax+2*nmax+MAX_FACE_SIZE*nmax+1+1);
+
+ memory->create(imflag,2*nmax,"body/rounded/polyhedron:imflag");
+ memory->create(imdata,2*nmax,7,"body/polyhedron:imdata");
+}
+
+/* ---------------------------------------------------------------------- */
+
+BodyRoundedPolyhedron::~BodyRoundedPolyhedron()
+{
+ delete icp;
+ delete dcp;
+ memory->destroy(imflag);
+ memory->destroy(imdata);
+}
+
+/* ---------------------------------------------------------------------- */
+
+int BodyRoundedPolyhedron::nsub(AtomVecBody::Bonus *bonus)
+{
+ return bonus->ivalue[0];
+}
+
+/* ---------------------------------------------------------------------- */
+
+double *BodyRoundedPolyhedron::coords(AtomVecBody::Bonus *bonus)
+{
+ return bonus->dvalue;
+}
+
+/* ---------------------------------------------------------------------- */
+
+int BodyRoundedPolyhedron::nedges(AtomVecBody::Bonus *bonus)
+{
+ int nvertices = bonus->ivalue[0];
+ int nedges = bonus->ivalue[1];
+ int nfaces = bonus->ivalue[2];
+ if (nvertices == 1) return 0;
+ else if (nvertices == 2) return 1;
+ return nedges; //(nvertices+nfaces-2); // Euler's polyon formula: V-E+F=2
+}
+
+/* ---------------------------------------------------------------------- */
+
+double *BodyRoundedPolyhedron::edges(AtomVecBody::Bonus *bonus)
+{
+ return bonus->dvalue+3*nsub(bonus);
+}
+
+/* ---------------------------------------------------------------------- */
+
+int BodyRoundedPolyhedron::nfaces(AtomVecBody::Bonus *bonus)
+{
+ return bonus->ivalue[2];
+}
+
+/* ---------------------------------------------------------------------- */
+
+double *BodyRoundedPolyhedron::faces(AtomVecBody::Bonus *bonus)
+{
+ int nvertices = bonus->ivalue[0];
+ if (nvertices == 1 || nvertices == 2) return NULL;
+ return bonus->dvalue+3*nsub(bonus)+2*nedges(bonus);
+}
+
+/* ---------------------------------------------------------------------- */
+
+double BodyRoundedPolyhedron::enclosing_radius(struct AtomVecBody::Bonus *bonus)
+{
+ int nvertices = bonus->ivalue[0];
+ if (nvertices == 1 || nvertices == 2)
+ return *(bonus->dvalue+3*nsub(bonus)+2);
+ return *(bonus->dvalue+3*nsub(bonus) + 2*nedges(bonus) +
+ MAX_FACE_SIZE*nfaces(bonus));
+}
+
+/* ---------------------------------------------------------------------- */
+
+double BodyRoundedPolyhedron::rounded_radius(struct AtomVecBody::Bonus *bonus)
+{
+ int nvertices = bonus->ivalue[0];
+ if (nvertices == 1 || nvertices == 2)
+ return *(bonus->dvalue+3*nsub(bonus)+2+1);
+ return *(bonus->dvalue+3*nsub(bonus) + 2*nedges(bonus) +
+ MAX_FACE_SIZE*nfaces(bonus)+1);
+}
+
+/* ---------------------------------------------------------------------- */
+
+int BodyRoundedPolyhedron::pack_border_body(AtomVecBody::Bonus *bonus, double *buf)
+{
+ int nsub = bonus->ivalue[0];
+ int ned = bonus->ivalue[1];
+ int nfac = bonus->ivalue[2];
+ buf[0] = nsub;
+ buf[1] = ned;
+ buf[2] = nfac;
+ int ndouble;
+ if (nsub == 1 || nsub == 2) ndouble = 3*nsub+2+MAX_FACE_SIZE*nfac+1+1;
+ else ndouble = 3*nsub+2*ned+MAX_FACE_SIZE*nfac+1+1;
+ memcpy(&buf[3],bonus->dvalue,ndouble*sizeof(double));
+ return 3+ndouble;
+}
+
+/* ---------------------------------------------------------------------- */
+
+int BodyRoundedPolyhedron::unpack_border_body(AtomVecBody::Bonus *bonus,
+ double *buf)
+{
+ int nsub = static_cast<int> (buf[0]);
+ int ned = static_cast<int> (buf[1]);
+ int nfac = static_cast<int> (buf[2]);
+ bonus->ivalue[0] = nsub;
+ bonus->ivalue[1] = ned;
+ bonus->ivalue[2] = nfac;
+ int ndouble;
+ if (nsub == 1 || nsub == 2) ndouble = 3*nsub+2+MAX_FACE_SIZE*nfac+1+1;
+ else ndouble = 3*nsub+2*ned+MAX_FACE_SIZE*nfac+1+1;
+ memcpy(bonus->dvalue,&buf[3],ndouble*sizeof(double));
+ return 3+ndouble;
+}
+
+/* ----------------------------------------------------------------------
+ populate bonus data structure with data file values
+------------------------------------------------------------------------- */
+
+void BodyRoundedPolyhedron::data_body(int ibonus, int ninteger, int ndouble,
+ int *ifile, double *dfile)
+{
+ AtomVecBody::Bonus *bonus = &avec->bonus[ibonus];
+
+ // set ninteger, ndouble in bonus and allocate 2 vectors of ints, doubles
+
+ if (ninteger != 3)
+ error->one(FLERR,"Incorrect # of integer values in "
+ "Bodies section of data file");
+ int nsub = ifile[0];
+ int ned = ifile[1];
+ int nfac = ifile[2];
+ if (nsub < 1)
+ error->one(FLERR,"Incorrect integer value in "
+ "Bodies section of data file");
+
+ // nentries = number of double entries to be read from Body section:
+ // nsub == 1 || nsub == 2 || nsub == 3:
+ // 6 for inertia + 3*nsub for vertex coords + 1 for rounded radius
+ // nsub > 3:
+ // 6 for inertia + 3*nsub for vertex coords + 2*nsub for edges +
+ // 3*nfaces + 1 for rounded radius
+
+ int nedges,nentries;
+ if (nsub == 1 || nsub == 2) {
+ nentries = 6 + 3*nsub + 1;
+ } else {
+ nedges = ned; //nsub + nfac - 2;
+ nentries = 6 + 3*nsub + 2*nedges + MAX_FACE_SIZE*nfac + 1;
+ }
+ if (ndouble != nentries)
+ error->one(FLERR,"Incorrect # of floating-point values in "
+ "Bodies section of data file");
+
+ bonus->ninteger = 3;
+ bonus->ivalue = icp->get(bonus->iindex);
+ bonus->ivalue[0] = nsub;
+ bonus->ivalue[1] = ned;
+ bonus->ivalue[2] = nfac;
+ if (nsub == 1 || nsub == 2) bonus->ndouble = 3*nsub + 2*nsub + 1 + 1;
+ else bonus->ndouble = 3*nsub + 2*nedges + MAX_FACE_SIZE*nfac + 1 + 1;
+ bonus->dvalue = dcp->get(bonus->ndouble,bonus->dindex);
+
+ // diagonalize inertia tensor
+
+ double tensor[3][3];
+ tensor[0][0] = dfile[0];
+ tensor[1][1] = dfile[1];
+ tensor[2][2] = dfile[2];
+ tensor[0][1] = tensor[1][0] = dfile[3];
+ tensor[0][2] = tensor[2][0] = dfile[4];
+ tensor[1][2] = tensor[2][1] = dfile[5];
+
+ double *inertia = bonus->inertia;
+ double evectors[3][3];
+ int ierror = MathExtra::jacobi(tensor,inertia,evectors);
+ if (ierror) error->one(FLERR,
+ "Insufficient Jacobi rotations for body nparticle");
+
+ // if any principal moment < scaled EPSILON, set to 0.0
+
+ double max;
+ max = MAX(inertia[0],inertia[1]);
+ max = MAX(max,inertia[2]);
+
+ if (inertia[0] < EPSILON*max) inertia[0] = 0.0;
+ if (inertia[1] < EPSILON*max) inertia[1] = 0.0;
+ if (inertia[2] < EPSILON*max) inertia[2] = 0.0;
+
+ // exyz_space = principal axes in space frame
+
+ double ex_space[3],ey_space[3],ez_space[3];
+
+ ex_space[0] = evectors[0][0];
+ ex_space[1] = evectors[1][0];
+ ex_space[2] = evectors[2][0];
+ ey_space[0] = evectors[0][1];
+ ey_space[1] = evectors[1][1];
+ ey_space[2] = evectors[2][1];
+ ez_space[0] = evectors[0][2];
+ ez_space[1] = evectors[1][2];
+ ez_space[2] = evectors[2][2];
+
+ // enforce 3 evectors as a right-handed coordinate system
+ // flip 3rd vector if needed
+
+ double cross[3];
+ MathExtra::cross3(ex_space,ey_space,cross);
+ if (MathExtra::dot3(cross,ez_space) < 0.0) MathExtra::negate3(ez_space);
+
+ // create initial quaternion
+
+ MathExtra::exyz_to_q(ex_space,ey_space,ez_space,bonus->quat);
+
+ // bonus->dvalue = the first 3*nsub elements are sub-particle displacements
+ // find the enclosing radius of the body from the maximum displacement
+
+ int i,m;
+ double delta[3], rsq, erad, rrad;
+ double erad2 = 0;
+ int j = 6;
+ int k = 0;
+ for (i = 0; i < nsub; i++) {
+ delta[0] = dfile[j];
+ delta[1] = dfile[j+1];
+ delta[2] = dfile[j+2];
+ MathExtra::transpose_matvec(ex_space,ey_space,ez_space,
+ delta,&bonus->dvalue[k]);
+ rsq = delta[0] * delta[0] + delta[1] * delta[1] +
+ delta[2] * delta[2];
+ if (rsq > erad2) erad2 = rsq;
+ j += 3;
+ k += 3;
+ }
+
+ // .. the next 2*nsub elements are edge ends
+
+ if (nsub == 1) { // spheres
+ nedges = 0;
+ bonus->dvalue[k] = 0;
+ *(&bonus->dvalue[k]+1) = 0;
+ k += 2;
+
+ rrad = 0.5 * dfile[j];
+ bonus->dvalue[k] = rrad;
+ erad = rrad; // enclosing radius = rounded_radius
+
+ // the last element of bonus->dvalue is the rounded radius
+
+ k++;
+ bonus->dvalue[k] = rrad;
+
+ atom->radius[bonus->ilocal] = erad;
+
+ } else if (nsub == 2) { // rods
+ nedges = 1;
+ for (i = 0; i < nedges; i++) {
+ bonus->dvalue[k] = 0;
+ *(&bonus->dvalue[k]+1) = 1;
+ k += 2;
+ }
+
+ erad = sqrt(erad2);
+ bonus->dvalue[k] = erad;
+
+ // the last element of bonus->dvalue is the rounded radius
+
+ rrad = 0.5 * dfile[j];
+ k++;
+ bonus->dvalue[k] = rrad;
+
+ atom->radius[bonus->ilocal] = erad + rrad;
+
+ } else { // polyhedra
+
+ // edges
+
+ for (i = 0; i < nedges; i++) {
+ bonus->dvalue[k] = dfile[j];
+ *(&bonus->dvalue[k]+1) = dfile[j+1];
+ k += 2;
+ j += 2;
+ }
+
+ // faces
+
+ for (i = 0; i < nfac; i++) {
+ for (m = 0; m < MAX_FACE_SIZE; m++)
+ *(&bonus->dvalue[k]+m) = dfile[j+m];
+ k += MAX_FACE_SIZE;
+ j += MAX_FACE_SIZE;
+ }
+
+ // the next to last element is the enclosing radius
+
+ erad = sqrt(erad2);
+ bonus->dvalue[k] = erad;
+
+ // the last element bonus-> dvalue is the rounded radius
+
+ rrad = 0.5 * dfile[j];
+ k++;
+ bonus->dvalue[k] = rrad;
+
+ atom->radius[bonus->ilocal] = erad + rrad;
+ }
+}
+
+/* ----------------------------------------------------------------------
+ return radius of body particle defined by ifile/dfile params
+ params are ordered as in data file
+ called by Molecule class which needs single body size
+------------------------------------------------------------------------- */
+
+double BodyRoundedPolyhedron::radius_body(int ninteger, int ndouble,
+ int *ifile, double *dfile)
+{
+ int nsub = ifile[0];
+ int ned = ifile[1];
+ int nfac = ifile[2];
+ int nedges = ned; //nsub + nfac - 2;
+
+ int nentries;
+ if (nsub == 1 || nsub == 2) nentries = 6 + 3*nsub + 1;
+ else nentries = 6 + 3*nsub + 2*nedges + MAX_FACE_SIZE*nfac + 1;
+
+ if (nsub < 1)
+ error->one(FLERR,"Incorrect integer value in "
+ "Bodies section of data file");
+ if (ndouble != nentries)
+ error->one(FLERR,"Incorrect # of floating-point values in "
+ "Bodies section of data file");
+
+ // sub-particle coords are relative to body center at (0,0,0)
+ // offset = 6 for sub-particle coords
+
+ double onerad;
+ double maxrad = 0.0;
+ double delta[3];
+
+ int offset = 6;
+ for (int i = 0; i < nsub; i++) {
+ delta[0] = dfile[offset];
+ delta[1] = dfile[offset+1];
+ delta[2] = dfile[offset+2];
+ offset += 3;
+ onerad = MathExtra::len3(delta);
+ maxrad = MAX(maxrad,onerad);
+ }
+
+ if (nsub > 2) offset += (2*nedges+MAX_FACE_SIZE*nfac);
+
+ // add in radius of rounded corners
+
+ return maxrad + 0.5*dfile[offset];
+}
+
+/* ---------------------------------------------------------------------- */
+
+int BodyRoundedPolyhedron::noutcol()
+{
+ // the number of columns for the vertex coordinates
+
+ return 3;
+}
+
+/* ---------------------------------------------------------------------- */
+
+int BodyRoundedPolyhedron::noutrow(int ibonus)
+{
+ // only return the first nsub rows for the vertex coordinates
+
+ return avec->bonus[ibonus].ivalue[0];
+}
+
+/* ---------------------------------------------------------------------- */
+
+void BodyRoundedPolyhedron::output(int ibonus, int m, double *values)
+{
+ AtomVecBody::Bonus *bonus = &avec->bonus[ibonus];
+
+ double p[3][3];
+ MathExtra::quat_to_mat(bonus->quat,p);
+ MathExtra::matvec(p,&bonus->dvalue[3*m],values);
+
+ double *x = atom->x[bonus->ilocal];
+ values[0] += x[0];
+ values[1] += x[1];
+ values[2] += x[2];
+}
+
+/* ---------------------------------------------------------------------- */
+
+int BodyRoundedPolyhedron::image(int ibonus, double flag1, double flag2,
+ int *&ivec, double **&darray)
+{
+ int j, nelements;
+ double p[3][3];
+ double *x, rrad;
+
+ AtomVecBody::Bonus *bonus = &avec->bonus[ibonus];
+ int nvertices = bonus->ivalue[0];
+
+ if (nvertices == 1) { // spheres
+
+ for (int i = 0; i < nvertices; i++) {
+ imflag[i] = SPHERE;
+ MathExtra::quat_to_mat(bonus->quat,p);
+ MathExtra::matvec(p,&bonus->dvalue[3*i],imdata[i]);
+
+ rrad = enclosing_radius(bonus);
+ x = atom->x[bonus->ilocal];
+ imdata[i][0] += x[0];
+ imdata[i][1] += x[1];
+ imdata[i][2] += x[2];
+ if (flag1 <= 0) imdata[i][3] = 2*rrad;
+ else imdata[i][3] = flag1;
+ }
+
+ nelements = nvertices;
+ } else {
+ int nfaces = bonus->ivalue[2];
+ int nedges = bonus->ivalue[1]; //nvertices + nfaces - 2;
+ if (nvertices == 2) nedges = 1; // special case: rods
+ double* edge_ends = &bonus->dvalue[3*nvertices];
+ int pt1, pt2;
+
+ for (int i = 0; i < nedges; i++) {
+ imflag[i] = LINE;
+
+ pt1 = static_cast<int>(edge_ends[2*i]);
+ pt2 = static_cast<int>(edge_ends[2*i+1]);
+
+ MathExtra::quat_to_mat(bonus->quat,p);
+ MathExtra::matvec(p,&bonus->dvalue[3*pt1],imdata[i]);
+ MathExtra::matvec(p,&bonus->dvalue[3*pt2],&imdata[i][3]);
+
+ rrad = rounded_radius(bonus);
+ x = atom->x[bonus->ilocal];
+ imdata[i][0] += x[0];
+ imdata[i][1] += x[1];
+ imdata[i][2] += x[2];
+ imdata[i][3] += x[0];
+ imdata[i][4] += x[1];
+ imdata[i][5] += x[2];
+
+ if (flag1 <= 0) imdata[i][6] = 2*rrad;
+ else imdata[i][6] = flag1;
+ }
+
+ nelements = nedges;
+ }
+
+ ivec = imflag;
+ darray = imdata;
+ return nelements;
+}
diff --git a/src/BODY/body_rounded_polyhedron.h b/src/BODY/body_rounded_polyhedron.h
new file mode 100644
index 0000000000000000000000000000000000000000..e5b15fd8f93f6c0a65d896262a52dd85d7569c41
--- /dev/null
+++ b/src/BODY/body_rounded_polyhedron.h
@@ -0,0 +1,88 @@
+/* -*- c++ -*- ----------------------------------------------------------
+ LAMMPS - Large-scale Atomic/Molecular Massively Parallel Simulator
+ http://lammps.sandia.gov, Sandia National Laboratories
+ Steve Plimpton, sjplimp@sandia.gov
+
+ Copyright (2003) Sandia Corporation. Under the terms of Contract
+ DE-AC04-94AL85000 with Sandia Corporation, the U.S. Government retains
+ certain rights in this software. This software is distributed under
+ the GNU General Public License.
+
+ See the README file in the top-level LAMMPS directory.
+------------------------------------------------------------------------- */
+
+#ifdef BODY_CLASS
+
+BodyStyle(rounded/polyhedron,BodyRoundedPolyhedron)
+
+#else
+
+#ifndef LMP_BODY_ROUNDED_POLYHEDRON_H
+#define LMP_BODY_ROUNDED_POLYHEDRON_H
+
+#include "body.h"
+#include "atom_vec_body.h"
+
+namespace LAMMPS_NS {
+
+class BodyRoundedPolyhedron : public Body {
+ public:
+ BodyRoundedPolyhedron(class LAMMPS *, int, char **);
+ ~BodyRoundedPolyhedron();
+ int nsub(struct AtomVecBody::Bonus *);
+ double *coords(struct AtomVecBody::Bonus *);
+ int nedges(struct AtomVecBody::Bonus *);
+ double *edges(struct AtomVecBody::Bonus *);
+ int nfaces(struct AtomVecBody::Bonus *);
+ double *faces(struct AtomVecBody::Bonus *);
+ double enclosing_radius(struct AtomVecBody::Bonus *);
+ double rounded_radius(struct AtomVecBody::Bonus *);
+
+ int pack_border_body(struct AtomVecBody::Bonus *, double *);
+ int unpack_border_body(struct AtomVecBody::Bonus *, double *);
+ void data_body(int, int, int, int *, double *);
+ double radius_body(int, int, int *, double *);
+
+ int noutrow(int);
+ int noutcol();
+ void output(int, int, double *);
+ int image(int, double, double, int *&, double **&);
+
+ private:
+ int *imflag;
+ double **imdata;
+};
+
+}
+
+#endif
+#endif
+
+/* ERROR/WARNING messages:
+
+E: Invalid body rounded/polyhedron command
+
+Arguments in atom-style command are not correct.
+
+E: Invalid format in Bodies section of data file
+
+The specified number of integer or floating point values does not
+appear.
+
+E: Incorrect # of integer values in Bodies section of data file
+
+See doc page for body style.
+
+E: Incorrect integer value in Bodies section of data file
+
+See doc page for body style.
+
+E: Incorrect # of floating-point values in Bodies section of data file
+
+See doc page for body style.
+
+E: Insufficient Jacobi rotations for body rounded/polyhedron
+
+Eigensolve for rigid body was not sufficiently accurate.
+
+*/
diff --git a/src/BODY/fix_wall_body_polygon.cpp b/src/BODY/fix_wall_body_polygon.cpp
new file mode 100644
index 0000000000000000000000000000000000000000..0e7aaea1e1a2a6c9ac0060c092eb703eaf90f2b6
--- /dev/null
+++ b/src/BODY/fix_wall_body_polygon.cpp
@@ -0,0 +1,829 @@
+/* ----------------------------------------------------------------------
+ LAMMPS - Large-scale Atomic/Molecular Massively Parallel Simulator
+ http://lammps.sandia.gov, Sandia National Laboratories
+ Steve Plimpton, sjplimp@sandia.gov
+
+ Copyright (2003) Sandia Corporation. Under the terms of Contract
+ DE-AC04-94AL85000 with Sandia Corporation, the U.S. Government retains
+ certain rights in this software. This software is distributed under
+ the GNU General Public License.
+
+ See the README file in the top-level LAMMPS directory.
+------------------------------------------------------------------------- */
+
+/* ----------------------------------------------------------------------
+ Contributing author: Trung Dac Nguyen (ndactrung@gmail.com)
+------------------------------------------------------------------------- */
+
+#include <cmath>
+#include <cstdlib>
+#include <cstring>
+#include "fix_wall_body_polygon.h"
+#include "atom.h"
+#include "atom_vec_body.h"
+#include "body_rounded_polygon.h"
+#include "domain.h"
+#include "update.h"
+#include "force.h"
+#include "pair.h"
+#include "modify.h"
+#include "respa.h"
+#include "math_const.h"
+#include "math_extra.h"
+#include "memory.h"
+#include "error.h"
+
+using namespace LAMMPS_NS;
+using namespace FixConst;
+using namespace MathConst;
+
+enum{XPLANE=0,YPLANE=1,ZCYLINDER}; // XYZ PLANE need to be 0,1,2
+enum{HOOKE,HOOKE_HISTORY};
+
+enum {INVALID=0,NONE=1,VERTEX=2};
+enum {FAR=0,XLO,XHI,YLO,YHI};
+
+//#define _POLYGON_DEBUG
+#define DELTA 10000
+#define EPSILON 1e-2
+#define BIG 1.0e20
+#define MAX_CONTACTS 4 // maximum number of contacts for 2D models
+#define EFF_CONTACTS 2 // effective contacts for 2D models
+
+/* ---------------------------------------------------------------------- */
+
+FixWallBodyPolygon::FixWallBodyPolygon(LAMMPS *lmp, int narg, char **arg) :
+ Fix(lmp, narg, arg)
+{
+ if (narg < 7) error->all(FLERR,"Illegal fix wall/body/polygon command");
+
+ if (!atom->body_flag)
+ error->all(FLERR,"Fix wall/body/polygon requires "
+ "atom style body/rounded/polygon");
+
+ restart_peratom = 1;
+ create_attribute = 1;
+
+ // wall/particle coefficients
+
+ kn = force->numeric(FLERR,arg[3]);
+
+ c_n = force->numeric(FLERR,arg[4]);
+ if (strcmp(arg[5],"NULL") == 0) c_t = 0.5 * c_n;
+ else c_t = force->numeric(FLERR,arg[5]);
+
+ if (kn < 0.0 || c_n < 0.0 || c_t < 0.0)
+ error->all(FLERR,"Illegal fix wall/body/polygon command");
+
+ // wallstyle args
+
+ int iarg = 6;
+ if (strcmp(arg[iarg],"xplane") == 0) {
+ if (narg < iarg+3) error->all(FLERR,"Illegal fix wall/body/polygon command");
+ wallstyle = XPLANE;
+ if (strcmp(arg[iarg+1],"NULL") == 0) lo = -BIG;
+ else lo = force->numeric(FLERR,arg[iarg+1]);
+ if (strcmp(arg[iarg+2],"NULL") == 0) hi = BIG;
+ else hi = force->numeric(FLERR,arg[iarg+2]);
+ iarg += 3;
+ } else if (strcmp(arg[iarg],"yplane") == 0) {
+ if (narg < iarg+3) error->all(FLERR,"Illegal fix wall/body/polygon command");
+ wallstyle = YPLANE;
+ if (strcmp(arg[iarg+1],"NULL") == 0) lo = -BIG;
+ else lo = force->numeric(FLERR,arg[iarg+1]);
+ if (strcmp(arg[iarg+2],"NULL") == 0) hi = BIG;
+ else hi = force->numeric(FLERR,arg[iarg+2]);
+ iarg += 3;
+ } else if (strcmp(arg[iarg],"zcylinder") == 0) {
+ if (narg < iarg+2) error->all(FLERR,"Illegal fix wall/body/polygon command");
+ wallstyle = ZCYLINDER;
+ lo = hi = 0.0;
+ cylradius = force->numeric(FLERR,arg[iarg+1]);
+ iarg += 2;
+ }
+
+ // check for trailing keyword/values
+
+ wiggle = 0;
+
+ while (iarg < narg) {
+ if (strcmp(arg[iarg],"wiggle") == 0) {
+ if (iarg+4 > narg) error->all(FLERR,"Illegal fix wall/body/polygon command");
+ if (strcmp(arg[iarg+1],"x") == 0) axis = 0;
+ else if (strcmp(arg[iarg+1],"y") == 0) axis = 1;
+ else if (strcmp(arg[iarg+1],"z") == 0) axis = 2;
+ else error->all(FLERR,"Illegal fix wall/body/polygon command");
+ amplitude = force->numeric(FLERR,arg[iarg+2]);
+ period = force->numeric(FLERR,arg[iarg+3]);
+ wiggle = 1;
+ iarg += 4;
+ } else error->all(FLERR,"Illegal fix wall/body/polygon command");
+ }
+
+ if (wallstyle == XPLANE && domain->xperiodic)
+ error->all(FLERR,"Cannot use wall in periodic dimension");
+ if (wallstyle == YPLANE && domain->yperiodic)
+ error->all(FLERR,"Cannot use wall in periodic dimension");
+ if (wallstyle == ZCYLINDER && (domain->xperiodic || domain->yperiodic))
+ error->all(FLERR,"Cannot use wall in periodic dimension");
+
+ if (wiggle && wallstyle == ZCYLINDER && axis != 2)
+ error->all(FLERR,"Invalid wiggle direction for fix wall/body/polygon");
+
+ // setup oscillations
+
+ if (wiggle) omega = 2.0*MY_PI / period;
+
+ time_origin = update->ntimestep;
+
+ dmax = nmax = 0;
+ discrete = NULL;
+ dnum = dfirst = NULL;
+
+ edmax = ednummax = 0;
+ edge = NULL;
+ ednum = edfirst = NULL;
+
+ enclosing_radius = NULL;
+ rounded_radius = NULL;
+}
+
+/* ---------------------------------------------------------------------- */
+
+FixWallBodyPolygon::~FixWallBodyPolygon()
+{
+ memory->destroy(discrete);
+ memory->destroy(dnum);
+ memory->destroy(dfirst);
+
+ memory->destroy(edge);
+ memory->destroy(ednum);
+ memory->destroy(edfirst);
+
+ memory->destroy(enclosing_radius);
+ memory->destroy(rounded_radius);
+}
+
+/* ---------------------------------------------------------------------- */
+
+int FixWallBodyPolygon::setmask()
+{
+ int mask = 0;
+ mask |= POST_FORCE;
+ return mask;
+}
+
+/* ---------------------------------------------------------------------- */
+
+void FixWallBodyPolygon::init()
+{
+ dt = update->dt;
+
+ avec = (AtomVecBody *) atom->style_match("body");
+ if (!avec)
+ error->all(FLERR,"Pair body/rounded/polygon requires atom style body");
+ if (strcmp(avec->bptr->style,"rounded/polygon") != 0)
+ error->all(FLERR,"Pair body/rounded/polygon requires "
+ "body style rounded/polygon");
+ bptr = (BodyRoundedPolygon *) avec->bptr;
+
+ // set pairstyle from body/polygonular pair style
+
+ if (force->pair_match("body/rounded/polygon",1))
+ pairstyle = HOOKE;
+ else error->all(FLERR,"Fix wall/body/polygon is incompatible with Pair style");
+}
+
+/* ---------------------------------------------------------------------- */
+
+void FixWallBodyPolygon::setup(int vflag)
+{
+ if (strstr(update->integrate_style,"verlet"))
+ post_force(vflag);
+}
+
+/* ---------------------------------------------------------------------- */
+
+void FixWallBodyPolygon::post_force(int vflag)
+{
+ double vwall[3],dx,dy,dz,del1,del2,delxy,delr,rsq,eradi,rradi,wall_pos;
+ int i,ni,npi,ifirst,nei,iefirst,side;
+ double facc[3];
+
+ // set position of wall to initial settings and velocity to 0.0
+ // if wiggle, set wall position and velocity accordingly
+
+ double wlo = lo;
+ double whi = hi;
+ vwall[0] = vwall[1] = vwall[2] = 0.0;
+ if (wiggle) {
+ double arg = omega * (update->ntimestep - time_origin) * dt;
+ if (wallstyle == axis) {
+ wlo = lo + amplitude - amplitude*cos(arg);
+ whi = hi + amplitude - amplitude*cos(arg);
+ }
+ vwall[axis] = amplitude*omega*sin(arg);
+ }
+
+ // loop over all my atoms
+ // rsq = distance from wall
+ // dx,dy,dz = signed distance from wall
+ // for rotating cylinder, reset vwall based on particle position
+ // skip atom if not close enough to wall
+ // if wall was set to NULL, it's skipped since lo/hi are infinity
+ // compute force and torque on atom if close enough to wall
+ // via wall potential matched to pair potential
+
+ double **x = atom->x;
+ double **v = atom->v;
+ double **f = atom->f;
+ int *body = atom->body;
+ double *radius = atom->radius;
+ double **torque = atom->torque;
+ double **angmom = atom->angmom;
+ int *mask = atom->mask;
+ int nlocal = atom->nlocal;
+
+ // grow the per-atom lists if necessary and initialize
+
+ if (atom->nmax > nmax) {
+ memory->destroy(dnum);
+ memory->destroy(dfirst);
+ memory->destroy(ednum);
+ memory->destroy(edfirst);
+ memory->destroy(enclosing_radius);
+ memory->destroy(rounded_radius);
+ nmax = atom->nmax;
+ memory->create(dnum,nmax,"fix:dnum");
+ memory->create(dfirst,nmax,"fix:dfirst");
+ memory->create(ednum,nmax,"fix:ednum");
+ memory->create(edfirst,nmax,"fix:edfirst");
+ memory->create(enclosing_radius,nmax,"fix:enclosing_radius");
+ memory->create(rounded_radius,nmax,"fix:rounded_radius");
+ }
+
+ ndiscrete = nedge = 0;
+ for (i = 0; i < nlocal; i++)
+ dnum[i] = ednum[i] = 0;
+
+ for (i = 0; i < nlocal; i++) {
+ if (mask[i] & groupbit) {
+
+ if (body[i] < 0) continue;
+
+ dx = dy = dz = 0.0;
+ side = FAR;
+ if (wallstyle == XPLANE) {
+ del1 = x[i][0] - wlo;
+ del2 = whi - x[i][0];
+ if (del1 < del2) {
+ dx = del1;
+ wall_pos = wlo;
+ side = XLO;
+ } else {
+ dx = -del2;
+ wall_pos = whi;
+ side = XHI;
+ }
+ } else if (wallstyle == YPLANE) {
+ del1 = x[i][1] - wlo;
+ del2 = whi - x[i][1];
+ if (del1 < del2) {
+ dy = del1;
+ wall_pos = wlo;
+ side = YLO;
+ } else {
+ dy = -del2;
+ wall_pos = whi;
+ side = YHI;
+ }
+ } else if (wallstyle == ZCYLINDER) {
+ delxy = sqrt(x[i][0]*x[i][0] + x[i][1]*x[i][1]);
+ delr = cylradius - delxy;
+ if (delr > eradi) dz = cylradius;
+ else {
+ dx = -delr/delxy * x[i][0];
+ dy = -delr/delxy * x[i][1];
+ }
+ }
+
+ rsq = dx*dx + dy*dy + dz*dz;
+ if (rsq > radius[i]*radius[i]) continue;
+
+ double r = sqrt(rsq);
+ double rsqinv = 1.0 / rsq;
+
+ if (dnum[i] == 0) body2space(i);
+ npi = dnum[i];
+ ifirst = dfirst[i];
+ nei = ednum[i];
+ iefirst = edfirst[i];
+ eradi = enclosing_radius[i];
+ rradi = rounded_radius[i];
+
+ // reset vertex and edge forces
+
+ for (ni = 0; ni < npi; ni++) {
+ discrete[ifirst+ni][3] = 0;
+ discrete[ifirst+ni][4] = 0;
+ discrete[ifirst+ni][5] = 0;
+ }
+
+ for (ni = 0; ni < nei; ni++) {
+ edge[iefirst+ni][2] = 0;
+ edge[iefirst+ni][3] = 0;
+ edge[iefirst+ni][4] = 0;
+ }
+
+ int interact, num_contacts, done;
+ double delta_a, delta_ua, j_a;
+ Contact contact_list[MAX_CONTACTS];
+
+ num_contacts = 0;
+ facc[0] = facc[1] = facc[2] = 0;
+ interact = vertex_against_wall(i, wall_pos, x, f, torque, side,
+ contact_list, num_contacts, facc);
+
+ if (num_contacts >= 2) {
+
+ // find the first two distinct contacts
+
+ done = 0;
+ for (int m = 0; m < num_contacts-1; m++) {
+ for (int n = m+1; n < num_contacts; n++) {
+ delta_a = contact_separation(contact_list[m], contact_list[n]);
+ if (delta_a > 0) {
+ delta_ua = 1.0;
+ j_a = delta_a / (EFF_CONTACTS * delta_ua);
+ if (j_a < 1.0) j_a = 1.0;
+
+ // scale the force at both contacts
+
+ contact_forces(contact_list[m], j_a, x, v, angmom, f, torque,
+ vwall, facc);
+ contact_forces(contact_list[n], j_a, x, v, angmom, f, torque,
+ vwall, facc);
+ done = 1;
+ break;
+ }
+ }
+ if (done == 1) break;
+ }
+
+ } else if (num_contacts == 1) {
+
+ // if there's only one contact, it should be handled here
+ // since forces/torques have not been accumulated from vertex2wall()
+
+ contact_forces(contact_list[0], 1.0, x, v, angmom, f, torque,
+ vwall, facc);
+ }
+ } // group bit
+ }
+}
+
+/* ---------------------------------------------------------------------- */
+
+void FixWallBodyPolygon::reset_dt()
+{
+ dt = update->dt;
+}
+
+/* ----------------------------------------------------------------------
+ convert N sub-particles in body I to space frame using current quaternion
+ store sub-particle space-frame displacements from COM in discrete list
+------------------------------------------------------------------------- */
+
+void FixWallBodyPolygon::body2space(int i)
+{
+ int ibonus = atom->body[i];
+ AtomVecBody::Bonus *bonus = &avec->bonus[ibonus];
+ int nsub = bptr->nsub(bonus);
+ double *coords = bptr->coords(bonus);
+ int body_num_edges = bptr->nedges(bonus);
+ double* vertices = bptr->edges(bonus);
+ double eradius = bptr->enclosing_radius(bonus);
+ double rradius = bptr->rounded_radius(bonus);
+
+ // get the number of sub-particles (vertices)
+ // and the index of the first vertex of my body in the list
+
+ dnum[i] = nsub;
+ dfirst[i] = ndiscrete;
+
+ // grow the vertex list if necessary
+ // the first 3 columns are for coords, the last 3 for forces
+
+ if (ndiscrete + nsub > dmax) {
+ dmax += DELTA;
+ memory->grow(discrete,dmax,6,"fix:discrete");
+ }
+
+ double p[3][3];
+ MathExtra::quat_to_mat(bonus->quat,p);
+
+ for (int m = 0; m < nsub; m++) {
+ MathExtra::matvec(p,&coords[3*m],discrete[ndiscrete]);
+ discrete[ndiscrete][3] = 0;
+ discrete[ndiscrete][4] = 0;
+ discrete[ndiscrete][5] = 0;
+ ndiscrete++;
+ }
+
+ // get the number of edges (vertices)
+ // and the index of the first edge of my body in the list
+
+ ednum[i] = body_num_edges;
+ edfirst[i] = nedge;
+
+ // grow the edge list if necessary
+ // the first 2 columns are for vertex indices within body,
+ // the last 3 for forces
+
+ if (nedge + body_num_edges > edmax) {
+ edmax += DELTA;
+ memory->grow(edge,edmax,5,"fix:edge");
+ }
+
+ for (int m = 0; m < body_num_edges; m++) {
+ edge[nedge][0] = static_cast<int>(vertices[2*m+0]);
+ edge[nedge][1] = static_cast<int>(vertices[2*m+1]);
+ edge[nedge][2] = 0;
+ edge[nedge][3] = 0;
+ edge[nedge][4] = 0;
+ nedge++;
+ }
+
+ enclosing_radius[i] = eradius;
+ rounded_radius[i] = rradius;
+}
+
+/* ----------------------------------------------------------------------
+ Determine the interaction mode between i's vertices against the wall
+
+ i = atom i (body i)
+ x = atoms' coordinates
+ f = atoms' forces
+ torque = atoms' torques
+ Return:
+ contact_list = list of contacts between i and the wall
+ num_contacts = number of contacts between i's vertices and the wall
+ interact = 0 no interaction with the wall
+ 1 there's at least one vertex of i interacts
+ with the wall
+---------------------------------------------------------------------- */
+
+int FixWallBodyPolygon::vertex_against_wall(int i, double wall_pos,
+ double** x, double** f, double** torque, int side,
+ Contact* contact_list, int &num_contacts, double* facc)
+{
+ int ni, npi, ifirst, interact;
+ double xpi[3], xpj[3], dist, eradi, rradi;
+ double fx, fy, fz, rx, ry, rz;
+ int nlocal = atom->nlocal;
+
+ npi = dnum[i];
+ ifirst = dfirst[i];
+ eradi = enclosing_radius[i];
+ rradi = rounded_radius[i];
+
+ interact = 0;
+
+ // loop through body i's vertices
+
+ for (ni = 0; ni < npi; ni++) {
+
+ // convert body-fixed coordinates to space-fixed, xi
+
+ xpi[0] = x[i][0] + discrete[ifirst+ni][0];
+ xpi[1] = x[i][1] + discrete[ifirst+ni][1];
+ xpi[2] = x[i][2] + discrete[ifirst+ni][2];
+
+ int mode, contact, p2vertex;
+ double d, R, hi[3], t, delx, dely, delz, fpair, shift;
+ double xj[3], rij;
+
+ // compute the distance from the vertex xpi to the wall
+
+ mode = compute_distance_to_wall(xpi, rradi, wall_pos, side,
+ d, hi, contact);
+
+ if (mode == INVALID || mode == NONE) continue;
+
+ if (mode == VERTEX) {
+
+ interact = 1;
+
+ // vertex i interacts with the wall
+
+ delx = xpi[0] - hi[0];
+ dely = xpi[1] - hi[1];
+ delz = xpi[2] - hi[2];
+
+ // R = surface separation = d shifted by the rounded radius
+ // R = d - p1.rounded_radius;
+ // note: the force is defined for R, not for d
+ // R > 0: no interaction
+ // R <= 0: deformation between vertex i and the wall
+
+ rij = sqrt(delx*delx + dely*dely + delz*delz);
+ R = rij - rradi;
+
+ // the normal frictional term -c_n * vn will be added later
+
+ if (R <= 0) { // deformation occurs
+ fpair = -kn * R;
+ } else fpair = 0.0;
+
+ fx = delx*fpair/rij;
+ fy = dely*fpair/rij;
+ fz = delz*fpair/rij;
+
+ #ifdef _POLYGON_DEBUG
+ printf(" Interaction between vertex %d of %d and wall:", ni);
+ printf(" mode = %d; contact = %d; d = %f; rij = %f\n",
+ mode, contact, d, rij);
+ printf(" R = %f\n", R);
+ printf(" fpair = %f\n", fpair);
+ #endif
+
+ if (contact == 1) {
+
+ // vertex ni of body i contacts with edge nj of body j
+
+ contact_list[num_contacts].ibody = i;
+ contact_list[num_contacts].jbody = -1;
+ contact_list[num_contacts].vertex = ni;
+ contact_list[num_contacts].edge = -1;
+ contact_list[num_contacts].xv[0] = xpi[0];
+ contact_list[num_contacts].xv[1] = xpi[1];
+ contact_list[num_contacts].xv[2] = xpi[2];
+ contact_list[num_contacts].xe[0] = hi[0];
+ contact_list[num_contacts].xe[1] = hi[1];
+ contact_list[num_contacts].xe[2] = hi[2];
+ contact_list[num_contacts].separation = R;
+ num_contacts++;
+
+ // store forces to vertex ni to be rescaled later,
+ // if there are 2 contacts
+
+ discrete[ifirst+ni][3] = fx;
+ discrete[ifirst+ni][4] = fy;
+ discrete[ifirst+ni][5] = fz;
+
+ #ifdef _POLYGON_DEBUG
+ printf(" Stored forces at vertex and edge for accumulating later.\n");
+ #endif
+
+ } else { // no contact
+
+ // accumulate force and torque to the body directly
+
+ f[i][0] += fx;
+ f[i][1] += fy;
+ f[i][2] += fz;
+ sum_torque(x[i], xpi, fx, fy, fz, torque[i]);
+
+ } // end if contact
+
+ } // end if mode
+
+ } // end for looping through the vertices of body i
+
+ return interact;
+}
+
+/* -------------------------------------------------------------------------
+ Compute the distance between a vertex to the wall
+ another body
+ Input:
+ x0 = coordinate of the tested vertex
+ rradi = rounded radius of the vertex
+ wall_pos = position of the wall
+ Output:
+ d = Distance from a point x0 to an wall
+ hi = coordinates of the projection of x0 on the wall
+ contact = 0 no contact between the queried vertex and the wall
+ 1 contact detected
+ return NONE if there is no interaction
+ EDGE if the tested vertex interacts with the wall
+------------------------------------------------------------------------- */
+
+int FixWallBodyPolygon::compute_distance_to_wall(double* x0, double rradi,
+ double wall_pos, int side, double &d, double hi[3], int &contact)
+{
+ int mode;
+ double delxy;
+
+ // h0 = position of the projection of x0 on the wall
+ if (wallstyle == XPLANE) {
+ hi[0] = wall_pos;
+ hi[1] = x0[1];
+ hi[2] = x0[2];
+ } else if (wallstyle == YPLANE) {
+ hi[0] = x0[0];
+ hi[1] = wall_pos;
+ hi[2] = x0[2];
+ } else if (wallstyle == ZCYLINDER) {
+ delxy = sqrt(x0[0]*x0[0] + x0[1]*x0[1]);
+ hi[0] = x0[0]*cylradius/delxy;
+ hi[1] = x0[1]*cylradius/delxy;
+ hi[2] = x0[2];
+ }
+
+ // distance from x0 to the wall = distance from x0 to hi
+
+ distance(hi, x0, d);
+
+ // determine the interaction mode
+
+ if (d < rradi) {
+ mode = VERTEX;
+ contact = 1;
+ } else {
+ mode = NONE;
+ if (side == XLO) {
+ if (x0[0] < wall_pos) mode = VERTEX;
+ } else if (side == XHI) {
+ if (x0[0] > wall_pos) mode = VERTEX;
+ } else if (side == YLO) {
+ if (x0[1] < wall_pos) mode = VERTEX;
+ } else if (side == YHI) {
+ if (x0[1] > wall_pos) mode = VERTEX;
+ }
+ }
+
+ if (mode == NONE) contact = 0;
+ else contact = 1;
+
+ return mode;
+}
+
+/* ----------------------------------------------------------------------
+ Compute the contact forces between two bodies
+ modify the force stored at the vertex and edge in contact by j_a
+ sum forces and torque to the corresponding bodies
+ fn = normal friction component
+ ft = tangential friction component (-c_t * vrt)
+------------------------------------------------------------------------- */
+
+void FixWallBodyPolygon::contact_forces(Contact& contact, double j_a,
+ double** x, double** v, double** angmom, double** f,
+ double** torque, double* vwall, double* facc)
+{
+ int ibody,ibonus,ifirst, jefirst, ni;
+ double fx,fy,fz,delx,dely,delz,rsq,rsqinv;
+ double vr1,vr2,vr3,vnnr,vn1,vn2,vn3,vt1,vt2,vt3;
+ double fn[3],ft[3],vi[3];
+ double *quat, *inertia;
+ AtomVecBody::Bonus *bonus;
+
+ ibody = contact.ibody;
+
+ // compute the velocity of the vertex in the space-fixed frame
+
+ ibonus = atom->body[ibody];
+ bonus = &avec->bonus[ibonus];
+ quat = bonus->quat;
+ inertia = bonus->inertia;
+ total_velocity(contact.xv, x[ibody], v[ibody], angmom[ibody],
+ inertia, quat, vi);
+
+ // vector pointing from the vertex to the point on the wall
+
+ delx = contact.xv[0] - contact.xe[0];
+ dely = contact.xv[1] - contact.xe[1];
+ delz = contact.xv[2] - contact.xe[2];
+ rsq = delx*delx + dely*dely + delz*delz;
+ rsqinv = 1.0/rsq;
+
+ // relative translational velocity
+
+ vr1 = vi[0] - vwall[0];
+ vr2 = vi[1] - vwall[1];
+ vr3 = vi[2] - vwall[2];
+
+ // normal component
+
+ vnnr = vr1*delx + vr2*dely + vr3*delz;
+ vn1 = delx*vnnr * rsqinv;
+ vn2 = dely*vnnr * rsqinv;
+ vn3 = delz*vnnr * rsqinv;
+
+ // tangential component
+
+ vt1 = vr1 - vn1;
+ vt2 = vr2 - vn2;
+ vt3 = vr3 - vn3;
+
+ // normal friction term at contact
+
+ fn[0] = -c_n * vn1;
+ fn[1] = -c_n * vn2;
+ fn[2] = -c_n * vn3;
+
+ // tangential friction term at contact
+ // excluding the tangential deformation term for now
+
+ ft[0] = -c_t * vt1;
+ ft[1] = -c_t * vt2;
+ ft[2] = -c_t * vt3;
+
+ // only the cohesive force is scaled by j_a
+
+ ifirst = dfirst[ibody];
+ ni = contact.vertex;
+
+ fx = discrete[ifirst+ni][3] * j_a + fn[0] + ft[0];
+ fy = discrete[ifirst+ni][4] * j_a + fn[1] + ft[1];
+ fz = discrete[ifirst+ni][5] * j_a + fn[2] + ft[2];
+ f[ibody][0] += fx;
+ f[ibody][1] += fy;
+ f[ibody][2] += fz;
+ sum_torque(x[ibody], contact.xv, fx, fy, fz, torque[ibody]);
+
+ // accumulate forces to the vertex only
+
+ facc[0] += fx; facc[1] += fy; facc[2] += fz;
+
+ #ifdef _POLYGON_DEBUG
+ printf("From contact forces: vertex fx %f fy %f fz %f\n"
+ " torque body %d: %f %f %f\n",
+ discrete[ifirst+ni][3], discrete[ifirst+ni][4], discrete[ifirst+ni][5],
+ atom->tag[ibody],torque[ibody][0],torque[ibody][1],torque[ibody][2]);
+ #endif
+}
+
+/* ----------------------------------------------------------------------
+ Determine the length of the contact segment, i.e. the separation between
+ 2 contacts
+------------------------------------------------------------------------- */
+
+double FixWallBodyPolygon::contact_separation(const Contact& c1,
+ const Contact& c2)
+{
+ double x1 = c1.xv[0];
+ double y1 = c1.xv[1];
+ double x2 = c1.xe[0];
+ double y2 = c1.xe[1];
+ double x3 = c2.xv[0];
+ double y3 = c2.xv[1];
+
+ double delta_a = 0.0;
+ if (fabs(x2 - x1) > EPSILON) {
+ double A = (y2 - y1) / (x2 - x1);
+ delta_a = fabs(y1 - A * x1 - y3 + A * x3) / sqrt(1 + A * A);
+ } else {
+ delta_a = fabs(x1 - x3);
+ }
+
+ return delta_a;
+}
+
+/* ----------------------------------------------------------------------
+ Accumulate torque to body from the force f=(fx,fy,fz) acting at point x
+------------------------------------------------------------------------- */
+
+void FixWallBodyPolygon::sum_torque(double* xm, double *x, double fx,
+ double fy, double fz, double* torque)
+{
+ double rx = x[0] - xm[0];
+ double ry = x[1] - xm[1];
+ double rz = x[2] - xm[2];
+ double tx = ry * fz - rz * fy;
+ double ty = rz * fx - rx * fz;
+ double tz = rx * fy - ry * fx;
+ torque[0] += tx;
+ torque[1] += ty;
+ torque[2] += tz;
+}
+
+/* ----------------------------------------------------------------------
+ Calculate the total velocity of a point (vertex, a point on an edge):
+ vi = vcm + omega ^ (p - xcm)
+------------------------------------------------------------------------- */
+
+void FixWallBodyPolygon::total_velocity(double* p, double *xcm,
+ double* vcm, double *angmom, double *inertia,
+ double *quat, double* vi)
+{
+ double r[3],omega[3],ex_space[3],ey_space[3],ez_space[3];
+ r[0] = p[0] - xcm[0];
+ r[1] = p[1] - xcm[1];
+ r[2] = p[2] - xcm[2];
+ MathExtra::q_to_exyz(quat,ex_space,ey_space,ez_space);
+ MathExtra::angmom_to_omega(angmom,ex_space,ey_space,ez_space,
+ inertia,omega);
+ vi[0] = omega[1]*r[2] - omega[2]*r[1] + vcm[0];
+ vi[1] = omega[2]*r[0] - omega[0]*r[2] + vcm[1];
+ vi[2] = omega[0]*r[1] - omega[1]*r[0] + vcm[2];
+}
+
+/* ---------------------------------------------------------------------- */
+
+void FixWallBodyPolygon::distance(const double* x2, const double* x1,
+ double& r) {
+ r = sqrt((x2[0] - x1[0]) * (x2[0] - x1[0])
+ + (x2[1] - x1[1]) * (x2[1] - x1[1])
+ + (x2[2] - x1[2]) * (x2[2] - x1[2]));
+}
diff --git a/src/BODY/fix_wall_body_polygon.h b/src/BODY/fix_wall_body_polygon.h
new file mode 100644
index 0000000000000000000000000000000000000000..b71dcb06832ba312fb6a3853d185d1c37d23d314
--- /dev/null
+++ b/src/BODY/fix_wall_body_polygon.h
@@ -0,0 +1,131 @@
+/* -*- c++ -*- ----------------------------------------------------------
+ LAMMPS - Large-scale Atomic/Molecular Massively Parallel Simulator
+ http://lammps.sandia.gov, Sandia National Laboratories
+ Steve Plimpton, sjplimp@sandia.gov
+
+ Copyright (2003) Sandia Corporation. Under the terms of Contract
+ DE-AC04-94AL85000 with Sandia Corporation, the U.S. Government retains
+ certain rights in this software. This software is distributed under
+ the GNU General Public License.
+
+ See the README file in the top-level LAMMPS directory.
+------------------------------------------------------------------------- */
+
+#ifdef FIX_CLASS
+
+FixStyle(wall/body/polygon,FixWallBodyPolygon)
+
+#else
+
+#ifndef LMP_FIX_WALL_BODY_POLYGON_H
+#define LMP_FIX_WALL_BODY_POLYGON_H
+
+#include "fix.h"
+
+namespace LAMMPS_NS {
+
+class FixWallBodyPolygon : public Fix {
+ public:
+ FixWallBodyPolygon(class LAMMPS *, int, char **);
+ virtual ~FixWallBodyPolygon();
+ int setmask();
+ void init();
+ void setup(int);
+ virtual void post_force(int);
+ void reset_dt();
+
+ struct Contact {
+ int ibody, jbody; // body (i.e. atom) indices (not tags)
+ int vertex; // vertex of the first polygon
+ int edge; // edge of the second polygon
+ double xv[3]; // coordinates of the vertex
+ double xe[3]; // coordinates of the projection of the vertex on the edge
+ double separation;// separation at contact
+ };
+
+ protected:
+ int wallstyle,pairstyle,wiggle,axis;
+ double kn; // normal repulsion strength
+ double c_n; // normal damping coefficient
+ double c_t; // tangential damping coefficient
+ double lo,hi,cylradius;
+ double amplitude,period,omega;
+ double dt;
+ int time_origin;
+
+ class AtomVecBody *avec;
+ class BodyRoundedPolygon *bptr;
+
+ double **discrete; // list of all sub-particles for all bodies
+ int ndiscrete; // number of discretes in list
+ int dmax; // allocated size of discrete list
+ int *dnum; // number of discretes per line, 0 if uninit
+ int *dfirst; // index of first discrete per each line
+ int nmax; // allocated size of dnum,dfirst vectors
+
+ double **edge; // list of all edge for all bodies
+ int nedge; // number of edge in list
+ int edmax; // allocated size of edge list
+ int *ednum; // number of edges per line, 0 if uninit
+ int *edfirst; // index of first edge per each line
+ int ednummax; // allocated size of ednum,edfirst vectors
+
+ double *enclosing_radius; // enclosing radii for all bodies
+ double *rounded_radius; // rounded radii for all bodies
+
+ void body2space(int);
+
+ int vertex_against_wall(int ibody, double wall_pos, double** x,
+ double** f, double** torque, int side,
+ Contact* contact_list, int &num_contacts,
+ double* facc);
+
+ int compute_distance_to_wall(double* x0, double rradi, double wall_pos,
+ int side, double &d, double hi[3], int &contact);
+ double contact_separation(const Contact& c1, const Contact& c2);
+ void contact_forces(Contact& contact, double j_a, double** x,
+ double** v, double** angmom, double** f, double** torque,
+ double* vwall, double* facc);
+ void sum_torque(double* xm, double *x, double fx,
+ double fy, double fz, double* torque);
+ void total_velocity(double* p, double *xcm, double* vcm, double *angmom,
+ double *inertia, double *quat, double* vi);
+ void distance(const double* x2, const double* x1, double& r);
+
+};
+
+}
+
+#endif
+#endif
+
+/* ERROR/WARNING messages:
+
+E: Illegal ... command
+
+Self-explanatory. Check the input script syntax and compare to the
+documentation for the command. You can use -echo screen as a
+command-line option when running LAMMPS to see the offending line.
+
+E: Fix wall/body/polygon requires atom style body rounded/polygon
+
+Self-explanatory.
+
+E: Cannot use wall in periodic dimension
+
+Self-explanatory.
+
+E: Cannot wiggle and shear fix wall/body/polygon
+
+Cannot specify both options at the same time.
+
+E: Invalid wiggle direction for fix wall/body/polygon
+
+Self-explanatory.
+
+E: Fix wall/body/polygon is incompatible with Pair style
+
+Must use a body pair style to define the parameters needed for
+this fix.
+
+*/
diff --git a/src/BODY/fix_wall_body_polyhedron.cpp b/src/BODY/fix_wall_body_polyhedron.cpp
new file mode 100644
index 0000000000000000000000000000000000000000..17e9f0b8b5e05441dff0c93f333dde24793fd3e8
--- /dev/null
+++ b/src/BODY/fix_wall_body_polyhedron.cpp
@@ -0,0 +1,945 @@
+/* ----------------------------------------------------------------------
+ LAMMPS - Large-scale Atomic/Molecular Massively Parallel Simulator
+ http://lammps.sandia.gov, Sandia National Laboratories
+ Steve Plimpton, sjplimp@sandia.gov
+
+ Copyright (2003) Sandia Corporation. Under the terms of Contract
+ DE-AC04-94AL85000 with Sandia Corporation, the U.S. Government retains
+ certain rights in this software. This software is distributed under
+ the GNU General Public License.
+
+ See the README file in the top-level LAMMPS directory.
+------------------------------------------------------------------------- */
+
+/* ----------------------------------------------------------------------
+ Contributing author: Trung Dac Nguyen (ndactrung@gmail.com)
+------------------------------------------------------------------------- */
+
+#include <cmath>
+#include <cstdlib>
+#include <cstring>
+#include "fix_wall_body_polyhedron.h"
+#include "atom.h"
+#include "atom_vec_body.h"
+#include "body_rounded_polyhedron.h"
+#include "domain.h"
+#include "update.h"
+#include "force.h"
+#include "pair.h"
+#include "modify.h"
+#include "respa.h"
+#include "math_const.h"
+#include "math_extra.h"
+#include "memory.h"
+#include "error.h"
+
+using namespace LAMMPS_NS;
+using namespace FixConst;
+using namespace MathConst;
+
+enum{XPLANE=0,YPLANE=1,ZPLANE}; // XYZ PLANE need to be 0,1,2
+enum{HOOKE,HOOKE_HISTORY};
+
+enum {INVALID=0,NONE=1,VERTEX=2};
+enum {FAR=0,XLO,XHI,YLO,YHI,ZLO,ZHI};
+
+//#define _POLYHEDRON_DEBUG
+#define DELTA 10000
+#define EPSILON 1e-2
+#define BIG 1.0e20
+#define MAX_CONTACTS 4 // maximum number of contacts for 2D models
+#define EFF_CONTACTS 2 // effective contacts for 2D models
+
+/* ---------------------------------------------------------------------- */
+
+FixWallBodyPolyhedron::FixWallBodyPolyhedron(LAMMPS *lmp, int narg, char **arg) :
+ Fix(lmp, narg, arg)
+{
+ if (narg < 7) error->all(FLERR,"Illegal fix wall/body/polyhedron command");
+
+ if (!atom->body_flag)
+ error->all(FLERR,"Fix wall/body/polyhedron requires "
+ "atom style body/rounded/polyhedron");
+
+ restart_peratom = 1;
+ create_attribute = 1;
+
+ // wall/particle coefficients
+
+ kn = force->numeric(FLERR,arg[3]);
+
+ c_n = force->numeric(FLERR,arg[4]);
+ if (strcmp(arg[5],"NULL") == 0) c_t = 0.5 * c_n;
+ else c_t = force->numeric(FLERR,arg[5]);
+
+ if (kn < 0.0 || c_n < 0.0 || c_t < 0.0)
+ error->all(FLERR,"Illegal fix wall/body/polyhedron command");
+
+ // wallstyle args
+
+ int iarg = 6;
+ if (strcmp(arg[iarg],"xplane") == 0) {
+ if (narg < iarg+3) error->all(FLERR,"Illegal fix wall/body/polyhedron command");
+ wallstyle = XPLANE;
+ if (strcmp(arg[iarg+1],"NULL") == 0) lo = -BIG;
+ else lo = force->numeric(FLERR,arg[iarg+1]);
+ if (strcmp(arg[iarg+2],"NULL") == 0) hi = BIG;
+ else hi = force->numeric(FLERR,arg[iarg+2]);
+ iarg += 3;
+ } else if (strcmp(arg[iarg],"yplane") == 0) {
+ if (narg < iarg+3) error->all(FLERR,"Illegal fix wall/body/polyhedron command");
+ wallstyle = YPLANE;
+ if (strcmp(arg[iarg+1],"NULL") == 0) lo = -BIG;
+ else lo = force->numeric(FLERR,arg[iarg+1]);
+ if (strcmp(arg[iarg+2],"NULL") == 0) hi = BIG;
+ else hi = force->numeric(FLERR,arg[iarg+2]);
+ iarg += 3;
+ } else if (strcmp(arg[iarg],"zplane") == 0) {
+ if (narg < iarg+3) error->all(FLERR,"Illegal fix wall/body/polyhedron command");
+ wallstyle = ZPLANE;
+ if (strcmp(arg[iarg+1],"NULL") == 0) lo = -BIG;
+ else lo = force->numeric(FLERR,arg[iarg+1]);
+ if (strcmp(arg[iarg+2],"NULL") == 0) hi = BIG;
+ else hi = force->numeric(FLERR,arg[iarg+2]);
+ iarg += 3;
+ }
+
+ // check for trailing keyword/values
+
+ wiggle = 0;
+
+ while (iarg < narg) {
+ if (strcmp(arg[iarg],"wiggle") == 0) {
+ if (iarg+4 > narg) error->all(FLERR,"Illegal fix wall/body/polyhedron command");
+ if (strcmp(arg[iarg+1],"x") == 0) axis = 0;
+ else if (strcmp(arg[iarg+1],"y") == 0) axis = 1;
+ else if (strcmp(arg[iarg+1],"z") == 0) axis = 2;
+ else error->all(FLERR,"Illegal fix wall/body/polyhedron command");
+ amplitude = force->numeric(FLERR,arg[iarg+2]);
+ period = force->numeric(FLERR,arg[iarg+3]);
+ wiggle = 1;
+ iarg += 4;
+ } else error->all(FLERR,"Illegal fix wall/body/polyhedron command");
+ }
+
+ if (wallstyle == XPLANE && domain->xperiodic)
+ error->all(FLERR,"Cannot use wall in periodic dimension");
+ if (wallstyle == YPLANE && domain->yperiodic)
+ error->all(FLERR,"Cannot use wall in periodic dimension");
+ if (wallstyle == ZPLANE && domain->zperiodic)
+ error->all(FLERR,"Cannot use wall in periodic dimension");
+
+ // setup oscillations
+
+ if (wiggle) omega = 2.0*MY_PI / period;
+
+ time_origin = update->ntimestep;
+
+ dmax = nmax = 0;
+ discrete = NULL;
+ dnum = dfirst = NULL;
+
+ edmax = ednummax = 0;
+ edge = NULL;
+ ednum = edfirst = NULL;
+
+ facmax = facnummax = 0;
+ face = NULL;
+ facnum = facfirst = NULL;
+
+ enclosing_radius = NULL;
+ rounded_radius = NULL;
+}
+
+/* ---------------------------------------------------------------------- */
+
+FixWallBodyPolyhedron::~FixWallBodyPolyhedron()
+{
+ memory->destroy(discrete);
+ memory->destroy(dnum);
+ memory->destroy(dfirst);
+
+ memory->destroy(edge);
+ memory->destroy(ednum);
+ memory->destroy(edfirst);
+
+ memory->destroy(face);
+ memory->destroy(facnum);
+ memory->destroy(facfirst);
+
+ memory->destroy(enclosing_radius);
+ memory->destroy(rounded_radius);
+}
+
+/* ---------------------------------------------------------------------- */
+
+int FixWallBodyPolyhedron::setmask()
+{
+ int mask = 0;
+ mask |= POST_FORCE;
+ return mask;
+}
+
+/* ---------------------------------------------------------------------- */
+
+void FixWallBodyPolyhedron::init()
+{
+ dt = update->dt;
+
+ avec = (AtomVecBody *) atom->style_match("body");
+ if (!avec)
+ error->all(FLERR,"Pair body/rounded/polyhedron requires atom style body");
+ if (strcmp(avec->bptr->style,"rounded/polyhedron") != 0)
+ error->all(FLERR,"Pair body/rounded/polyhedron requires "
+ "body style rounded/polyhedron");
+ bptr = (BodyRoundedPolyhedron *) avec->bptr;
+
+ // set pairstyle from body/polyhedronular pair style
+
+ if (force->pair_match("body/rounded/polyhedron",1))
+ pairstyle = HOOKE;
+ else error->all(FLERR,"Fix wall/body/polyhedron is incompatible with Pair style");
+}
+
+/* ---------------------------------------------------------------------- */
+
+void FixWallBodyPolyhedron::setup(int vflag)
+{
+ if (strstr(update->integrate_style,"verlet"))
+ post_force(vflag);
+}
+
+/* ---------------------------------------------------------------------- */
+
+void FixWallBodyPolyhedron::post_force(int vflag)
+{
+ double vwall[3],dx,dy,dz,del1,del2,delxy,delr,rsq,eradi,rradi,wall_pos;
+ int i,ni,npi,ifirst,nei,iefirst,nfi,iffirst,side;
+ double facc[3];
+
+ // set position of wall to initial settings and velocity to 0.0
+ // if wiggle, set wall position and velocity accordingly
+
+ double wlo = lo;
+ double whi = hi;
+ vwall[0] = vwall[1] = vwall[2] = 0.0;
+ if (wiggle) {
+ double arg = omega * (update->ntimestep - time_origin) * dt;
+ if (wallstyle == axis) {
+ wlo = lo + amplitude - amplitude*cos(arg);
+ whi = hi + amplitude - amplitude*cos(arg);
+ }
+ vwall[axis] = amplitude*omega*sin(arg);
+ }
+
+ // loop over all my atoms
+ // rsq = distance from wall
+ // dx,dy,dz = signed distance from wall
+ // for rotating cylinder, reset vwall based on particle position
+ // skip atom if not close enough to wall
+ // if wall was set to NULL, it's skipped since lo/hi are infinity
+ // compute force and torque on atom if close enough to wall
+ // via wall potential matched to pair potential
+
+ double **x = atom->x;
+ double **v = atom->v;
+ double **f = atom->f;
+ int *body = atom->body;
+ double *radius = atom->radius;
+ double **torque = atom->torque;
+ double **angmom = atom->angmom;
+ int *mask = atom->mask;
+ int nlocal = atom->nlocal;
+
+ // grow the per-atom lists if necessary and initialize
+
+ if (atom->nmax > nmax) {
+ memory->destroy(dnum);
+ memory->destroy(dfirst);
+ memory->destroy(ednum);
+ memory->destroy(edfirst);
+ memory->destroy(facnum);
+ memory->destroy(facfirst);
+ memory->destroy(enclosing_radius);
+ memory->destroy(rounded_radius);
+ nmax = atom->nmax;
+ memory->create(dnum,nmax,"fix:dnum");
+ memory->create(dfirst,nmax,"fix:dfirst");
+ memory->create(ednum,nmax,"fix:ednum");
+ memory->create(edfirst,nmax,"fix:edfirst");
+ memory->create(facnum,nmax,"fix:facnum");
+ memory->create(facfirst,nmax,"fix:facfirst");
+ memory->create(enclosing_radius,nmax,"fix:enclosing_radius");
+ memory->create(rounded_radius,nmax,"fix:rounded_radius");
+ }
+
+ ndiscrete = nedge = nface = 0;
+ for (i = 0; i < nlocal; i++)
+ dnum[i] = ednum[i] = facnum[i] = 0;
+
+ for (i = 0; i < nlocal; i++) {
+ if (mask[i] & groupbit) {
+
+ if (body[i] < 0) continue;
+
+ dx = dy = dz = 0.0;
+ side = FAR;
+ if (wallstyle == XPLANE) {
+ del1 = x[i][0] - wlo;
+ del2 = whi - x[i][0];
+ if (del1 < del2) {
+ dx = del1;
+ wall_pos = wlo;
+ side = XLO;
+ } else {
+ dx = -del2;
+ wall_pos = whi;
+ side = XHI;
+ }
+ } else if (wallstyle == YPLANE) {
+ del1 = x[i][1] - wlo;
+ del2 = whi - x[i][1];
+ if (del1 < del2) {
+ dy = del1;
+ wall_pos = wlo;
+ side = YLO;
+ } else {
+ dy = -del2;
+ wall_pos = whi;
+ side = YHI;
+ }
+ } else if (wallstyle == ZPLANE) {
+ del1 = x[i][2] - wlo;
+ del2 = whi - x[i][2];
+ if (del1 < del2) {
+ dy = del1;
+ wall_pos = wlo;
+ side = ZLO;
+ } else {
+ dy = -del2;
+ wall_pos = whi;
+ side = ZHI;
+ }
+ }
+
+ rsq = dx*dx + dy*dy + dz*dz;
+ if (rsq > radius[i]*radius[i]) continue;
+
+ double r = sqrt(rsq);
+ double rsqinv = 1.0 / rsq;
+
+ if (dnum[i] == 0) body2space(i);
+ npi = dnum[i];
+ ifirst = dfirst[i];
+ nei = ednum[i];
+ iefirst = edfirst[i];
+ nfi = facnum[i];
+ iffirst = facfirst[i];
+ eradi = enclosing_radius[i];
+ rradi = rounded_radius[i];
+
+ if (npi == 1) {
+ sphere_against_wall(i, wall_pos, side, vwall, x, v, f, angmom, torque);
+ continue;
+ }
+
+ // reset vertex and edge forces
+
+ for (ni = 0; ni < npi; ni++) {
+ discrete[ifirst+ni][3] = 0;
+ discrete[ifirst+ni][4] = 0;
+ discrete[ifirst+ni][5] = 0;
+ discrete[ifirst+ni][6] = 0;
+ }
+
+ for (ni = 0; ni < nei; ni++) {
+ edge[iefirst+ni][2] = 0;
+ edge[iefirst+ni][3] = 0;
+ edge[iefirst+ni][4] = 0;
+ edge[iefirst+ni][5] = 0;
+ }
+
+ int interact, num_contacts, done;
+ double delta_a, delta_ua, j_a;
+ Contact contact_list[MAX_CONTACTS];
+
+ num_contacts = 0;
+ facc[0] = facc[1] = facc[2] = 0;
+ interact = edge_against_wall(i, wall_pos, side, vwall, x, f, torque,
+ contact_list, num_contacts, facc);
+
+ } // group bit
+ }
+}
+
+/* ---------------------------------------------------------------------- */
+
+void FixWallBodyPolyhedron::reset_dt()
+{
+ dt = update->dt;
+}
+
+/* ----------------------------------------------------------------------
+ convert N sub-particles in body I to space frame using current quaternion
+ store sub-particle space-frame displacements from COM in discrete list
+------------------------------------------------------------------------- */
+
+void FixWallBodyPolyhedron::body2space(int i)
+{
+ int ibonus = atom->body[i];
+ AtomVecBody::Bonus *bonus = &avec->bonus[ibonus];
+ int nsub = bptr->nsub(bonus);
+ double *coords = bptr->coords(bonus);
+ int body_num_edges = bptr->nedges(bonus);
+ double* edge_ends = bptr->edges(bonus);
+ int body_num_faces = bptr->nfaces(bonus);
+ double* face_pts = bptr->faces(bonus);
+ double eradius = bptr->enclosing_radius(bonus);
+ double rradius = bptr->rounded_radius(bonus);
+
+ // get the number of sub-particles (vertices)
+ // and the index of the first vertex of my body in the list
+
+ dnum[i] = nsub;
+ dfirst[i] = ndiscrete;
+
+ // grow the vertex list if necessary
+ // the first 3 columns are for coords, the last 3 for forces
+
+ if (ndiscrete + nsub > dmax) {
+ dmax += DELTA;
+ memory->grow(discrete,dmax,7,"fix:discrete");
+ }
+
+ double p[3][3];
+ MathExtra::quat_to_mat(bonus->quat,p);
+
+ for (int m = 0; m < nsub; m++) {
+ MathExtra::matvec(p,&coords[3*m],discrete[ndiscrete]);
+ discrete[ndiscrete][3] = 0;
+ discrete[ndiscrete][4] = 0;
+ discrete[ndiscrete][5] = 0;
+ discrete[ndiscrete][6] = 0;
+ ndiscrete++;
+ }
+
+ // get the number of edges (vertices)
+ // and the index of the first edge of my body in the list
+
+ ednum[i] = body_num_edges;
+ edfirst[i] = nedge;
+
+ // grow the edge list if necessary
+ // the first 2 columns are for vertex indices within body,
+ // the last 3 for forces
+
+ if (nedge + body_num_edges > edmax) {
+ edmax += DELTA;
+ memory->grow(edge,edmax,6,"fix:edge");
+ }
+
+ for (int m = 0; m < body_num_edges; m++) {
+ edge[nedge][0] = static_cast<int>(edge_ends[2*m+0]);
+ edge[nedge][1] = static_cast<int>(edge_ends[2*m+1]);
+ edge[nedge][2] = 0;
+ edge[nedge][3] = 0;
+ edge[nedge][4] = 0;
+ edge[nedge][5] = 0;
+ nedge++;
+ }
+
+ // get the number of faces and the index of the first face
+
+ facnum[i] = body_num_faces;
+ facfirst[i] = nface;
+
+ // grow the face list if necessary
+ // the first 3 columns are for vertex indices within body, the last 3 for forces
+
+ if (nface + body_num_faces > facmax) {
+ facmax += DELTA;
+ memory->grow(face,facmax,6,"pair:face");
+ }
+
+ for (int m = 0; m < body_num_faces; m++) {
+ face[nface][0] = static_cast<int>(face_pts[3*m+0]);
+ face[nface][1] = static_cast<int>(face_pts[3*m+1]);
+ face[nface][2] = static_cast<int>(face_pts[3*m+2]);
+ face[nface][3] = 0;
+ face[nface][4] = 0;
+ face[nface][5] = 0;
+ nface++;
+ }
+
+ enclosing_radius[i] = eradius;
+ rounded_radius[i] = rradius;
+}
+
+/* ----------------------------------------------------------------------
+ Determine the interaction mode between a sphere against the wall
+
+ i = atom i (body i)
+ x = atoms' coordinates
+ f = atoms' forces
+ torque = atoms' torques
+---------------------------------------------------------------------- */
+
+int FixWallBodyPolyhedron::sphere_against_wall(int i, double wall_pos,
+ int side, double* vwall, double** x, double** v, double** f,
+ double** angmom, double** torque)
+{
+ int mode;
+ double rradi,hi[3],d,delx,dely,delz,R,fpair,fx,fy,fz;
+
+ rradi = rounded_radius[i];
+ mode = NONE;
+
+ if (wallstyle == XPLANE) {
+ hi[0] = wall_pos;
+ hi[1] = x[i][1];
+ hi[2] = x[i][2];
+ } else if (wallstyle == YPLANE) {
+ hi[0] = x[i][0];
+ hi[1] = wall_pos;
+ hi[2] = x[i][2];
+ } else if (wallstyle == ZPLANE) {
+ hi[0] = x[i][0];
+ hi[1] = x[i][1];
+ hi[2] = wall_pos;
+ }
+
+ distance(hi, x[i], d);
+
+ if (d <= rradi) {
+ delx = x[i][0] - hi[0];
+ dely = x[i][1] - hi[1];
+ delz = x[i][2] - hi[2];
+ R = d - rradi;
+
+ fpair = -kn * R;
+
+ fx = delx*fpair/d;
+ fy = dely*fpair/d;
+ fz = delz*fpair/d;
+
+ contact_forces(i, 1.0, x[i], hi, delx, dely, delz,
+ fx, fy, fz, x, v, angmom, f, torque, vwall);
+ mode = VERTEX;
+ }
+
+ return mode;
+}
+
+/* ----------------------------------------------------------------------
+ Determine the interaction mode between i's vertices against the wall
+
+ i = atom i (body i)
+ x = atoms' coordinates
+ f = atoms' forces
+ torque = atoms' torques
+ Output:
+ contact_list = list of contacts between i and the wall
+ num_contacts = number of contacts between i's vertices and the wall
+ Return:
+ number of contacts of the edge to the wall (0, 1 or 2)
+---------------------------------------------------------------------- */
+
+int FixWallBodyPolyhedron::edge_against_wall(int i, double wall_pos,
+ int side, double* vwall, double** x, double** f, double** torque,
+ Contact* contact_list, int &num_contacts, double* facc)
+{
+ int ni, nei, mode, contact;
+ double rradi;
+ int nlocal = atom->nlocal;
+
+ nei = ednum[i];
+ rradi = rounded_radius[i];
+
+ contact = 0;
+
+ // loop through body i's edges
+
+ for (ni = 0; ni < nei; ni++)
+ mode = compute_distance_to_wall(i, ni, x[i], rradi, wall_pos, side, vwall,
+ contact);
+
+ return contact;
+}
+
+/* -------------------------------------------------------------------------
+ Compute the distance between a vertex to the wall
+ another body
+ Input:
+ x0 = coordinate of the tested vertex
+ rradi = rounded radius of the vertex
+ wall_pos = position of the wall
+ Output:
+ d = Distance from a point x0 to an wall
+ hi = coordinates of the projection of x0 on the wall
+ contact = 0 no contact between the queried vertex and the wall
+ 1 contact detected
+ return NONE if there is no interaction
+ VERTEX if the tested vertex interacts with the wall
+------------------------------------------------------------------------- */
+
+int FixWallBodyPolyhedron::compute_distance_to_wall(int ibody, int edge_index,
+ double *xmi, double rounded_radius_i, double wall_pos,
+ int side, double* vwall, int &contact)
+{
+ int mode,ifirst,iefirst,npi1,npi2;
+ double d1,d2,xpi1[3],xpi2[3],hi[3];
+ double fx,fy,fz,fpair,delx,dely,delz,R;
+
+ double** x = atom->x;
+ double** v = atom->v;
+ double** f = atom->f;
+ double** torque = atom->torque;
+ double** angmom = atom->angmom;
+
+ // two ends of the edge from body i
+
+ ifirst = dfirst[ibody];
+ iefirst = edfirst[ibody];
+ npi1 = static_cast<int>(edge[iefirst+edge_index][0]);
+ npi2 = static_cast<int>(edge[iefirst+edge_index][1]);
+
+ xpi1[0] = xmi[0] + discrete[ifirst+npi1][0];
+ xpi1[1] = xmi[1] + discrete[ifirst+npi1][1];
+ xpi1[2] = xmi[2] + discrete[ifirst+npi1][2];
+
+ xpi2[0] = xmi[0] + discrete[ifirst+npi2][0];
+ xpi2[1] = xmi[1] + discrete[ifirst+npi2][1];
+ xpi2[2] = xmi[2] + discrete[ifirst+npi2][2];
+
+ // determine the intersection of the edge to the wall
+
+ mode = NONE;
+ double j_a = 1.0;
+
+ if (wallstyle == XPLANE) {
+ hi[0] = wall_pos;
+ hi[1] = xpi1[1];
+ hi[2] = xpi1[2];
+ } else if (wallstyle == YPLANE) {
+ hi[0] = xpi1[0];
+ hi[1] = wall_pos;
+ hi[2] = xpi1[2];
+ } else if (wallstyle == ZPLANE) {
+ hi[0] = xpi1[0];
+ hi[1] = xpi1[1];
+ hi[2] = wall_pos;
+ }
+
+ distance(hi, xpi1, d1);
+
+ if (d1 <= rounded_radius_i && static_cast<int>(discrete[ifirst+npi1][6]) == 0) {
+ delx = xpi1[0] - hi[0];
+ dely = xpi1[1] - hi[1];
+ delz = xpi1[2] - hi[2];
+ R = d1 - rounded_radius_i;
+
+ fpair = -kn * R;
+
+ fx = delx*fpair/d1;
+ fy = dely*fpair/d1;
+ fz = delz*fpair/d1;
+
+ contact_forces(ibody, j_a, xpi1, hi, delx, dely, delz,
+ fx, fy, fz, x, v, angmom, f, torque, vwall);
+ discrete[ifirst+npi1][6] = 1;
+ contact++;
+ mode = VERTEX;
+ }
+
+ if (wallstyle == XPLANE) {
+ hi[0] = wall_pos;
+ hi[1] = xpi2[1];
+ hi[2] = xpi2[2];
+ } else if (wallstyle == YPLANE) {
+ hi[0] = xpi2[0];
+ hi[1] = wall_pos;
+ hi[2] = xpi2[2];
+ } else if (wallstyle == ZPLANE) {
+ hi[0] = xpi2[0];
+ hi[1] = xpi2[1];
+ hi[2] = wall_pos;
+ }
+
+ distance(hi, xpi2, d2);
+
+ if (d2 <= rounded_radius_i && static_cast<int>(discrete[ifirst+npi2][6]) == 0) {
+ delx = xpi2[0] - hi[0];
+ dely = xpi2[1] - hi[1];
+ delz = xpi2[2] - hi[2];
+ R = d2 - rounded_radius_i;
+
+ fpair = -kn * R;
+
+ fx = delx*fpair/d2;
+ fy = dely*fpair/d2;
+ fz = delz*fpair/d2;
+
+ contact_forces(ibody, j_a, xpi2, hi, delx, dely, delz,
+ fx, fy, fz, x, v, angmom, f, torque, vwall);
+ discrete[ifirst+npi2][6] = 1;
+ contact++;
+ mode = VERTEX;
+ }
+
+ return mode;
+}
+
+/* ----------------------------------------------------------------------
+ Compute contact forces between two bodies
+ modify the force stored at the vertex and edge in contact by j_a
+ sum forces and torque to the corresponding bodies
+ fn = normal friction component
+ ft = tangential friction component (-c_t * v_t)
+------------------------------------------------------------------------- */
+
+void FixWallBodyPolyhedron::contact_forces(int ibody,
+ double j_a, double *xi, double *xj, double delx, double dely, double delz,
+ double fx, double fy, double fz, double** x, double** v, double** angmom,
+ double** f, double** torque, double* vwall)
+{
+ int ibonus,jbonus;
+ double fxt,fyt,fzt,rsq,rsqinv;
+ double vr1,vr2,vr3,vnnr,vn1,vn2,vn3,vt1,vt2,vt3;
+ double fn[3],ft[3],vi[3],vj[3];
+ double *quat, *inertia;
+ AtomVecBody::Bonus *bonus;
+
+ // compute the velocity of the vertex in the space-fixed frame
+
+ ibonus = atom->body[ibody];
+ bonus = &avec->bonus[ibonus];
+ quat = bonus->quat;
+ inertia = bonus->inertia;
+ total_velocity(xi, x[ibody], v[ibody], angmom[ibody],
+ inertia, quat, vi);
+
+ // vector pointing from the contact point on ibody to the wall
+
+ rsq = delx*delx + dely*dely + delz*delz;
+ rsqinv = 1.0/rsq;
+
+ // relative translational velocity
+
+ vr1 = vi[0] - vwall[0];
+ vr2 = vi[1] - vwall[1];
+ vr3 = vi[2] - vwall[2];
+
+ // normal component
+
+ vnnr = vr1*delx + vr2*dely + vr3*delz;
+ vn1 = delx*vnnr * rsqinv;
+ vn2 = dely*vnnr * rsqinv;
+ vn3 = delz*vnnr * rsqinv;
+
+ // tangential component
+
+ vt1 = vr1 - vn1;
+ vt2 = vr2 - vn2;
+ vt3 = vr3 - vn3;
+
+ // normal friction term at contact
+
+ fn[0] = -c_n * vn1;
+ fn[1] = -c_n * vn2;
+ fn[2] = -c_n * vn3;
+
+ // tangential friction term at contact
+ // excluding the tangential deformation term for now
+
+ ft[0] = -c_t * vt1;
+ ft[1] = -c_t * vt2;
+ ft[2] = -c_t * vt3;
+
+ fxt = fx; fyt = fy; fzt = fz;
+ fx = fxt * j_a + fn[0] + ft[0];
+ fy = fyt * j_a + fn[1] + ft[1];
+ fz = fzt * j_a + fn[2] + ft[2];
+
+ f[ibody][0] += fx;
+ f[ibody][1] += fy;
+ f[ibody][2] += fz;
+ sum_torque(x[ibody], xi, fx, fy, fz, torque[ibody]);
+
+ #ifdef _POLYHEDRON_DEBUG
+ printf("From contact forces: vertex fx %f fy %f fz %f\n"
+ " torque body %d: %f %f %f\n"
+ " torque body %d: %f %f %f\n",
+ fxt, fyt, fzt,
+ atom->tag[ibody],torque[ibody][0],torque[ibody][1],torque[ibody][2],
+ atom->tag[jbody],torque[jbody][0],torque[jbody][1],torque[jbody][2]);
+ #endif
+}
+
+/* ----------------------------------------------------------------------
+ Compute the contact forces between two bodies
+ modify the force stored at the vertex and edge in contact by j_a
+ sum forces and torque to the corresponding bodies
+ fn = normal friction component
+ ft = tangential friction component (-c_t * vrt)
+------------------------------------------------------------------------- */
+
+void FixWallBodyPolyhedron::contact_forces(Contact& contact, double j_a,
+ double** x, double** v, double** angmom, double** f,
+ double** torque, double* vwall, double* facc)
+{
+ int ibody,ibonus,ifirst, jefirst, ni;
+ double fx,fy,fz,delx,dely,delz,rsq,rsqinv;
+ double vr1,vr2,vr3,vnnr,vn1,vn2,vn3,vt1,vt2,vt3;
+ double fn[3],ft[3],vi[3];
+ double *quat, *inertia;
+ AtomVecBody::Bonus *bonus;
+
+ ibody = contact.ibody;
+
+ // compute the velocity of the vertex in the space-fixed frame
+
+ ibonus = atom->body[ibody];
+ bonus = &avec->bonus[ibonus];
+ quat = bonus->quat;
+ inertia = bonus->inertia;
+ total_velocity(contact.xv, x[ibody], v[ibody], angmom[ibody],
+ inertia, quat, vi);
+
+ // vector pointing from the vertex to the point on the wall
+
+ delx = contact.xv[0] - contact.xe[0];
+ dely = contact.xv[1] - contact.xe[1];
+ delz = contact.xv[2] - contact.xe[2];
+ rsq = delx*delx + dely*dely + delz*delz;
+ rsqinv = 1.0/rsq;
+
+ // relative translational velocity
+
+ vr1 = vi[0] - vwall[0];
+ vr2 = vi[1] - vwall[1];
+ vr3 = vi[2] - vwall[2];
+
+ // normal component
+
+ vnnr = vr1*delx + vr2*dely + vr3*delz;
+ vn1 = delx*vnnr * rsqinv;
+ vn2 = dely*vnnr * rsqinv;
+ vn3 = delz*vnnr * rsqinv;
+
+ // tangential component
+
+ vt1 = vr1 - vn1;
+ vt2 = vr2 - vn2;
+ vt3 = vr3 - vn3;
+
+ // normal friction term at contact
+
+ fn[0] = -c_n * vn1;
+ fn[1] = -c_n * vn2;
+ fn[2] = -c_n * vn3;
+
+ // tangential friction term at contact
+ // excluding the tangential deformation term for now
+
+ ft[0] = -c_t * vt1;
+ ft[1] = -c_t * vt2;
+ ft[2] = -c_t * vt3;
+
+ // only the cohesive force is scaled by j_a
+
+ ifirst = dfirst[ibody];
+ ni = contact.vertex;
+
+ fx = discrete[ifirst+ni][3] * j_a + fn[0] + ft[0];
+ fy = discrete[ifirst+ni][4] * j_a + fn[1] + ft[1];
+ fz = discrete[ifirst+ni][5] * j_a + fn[2] + ft[2];
+ f[ibody][0] += fx;
+ f[ibody][1] += fy;
+ f[ibody][2] += fz;
+ sum_torque(x[ibody], contact.xv, fx, fy, fz, torque[ibody]);
+
+ // accumulate forces to the vertex only
+
+ facc[0] += fx; facc[1] += fy; facc[2] += fz;
+
+ #ifdef _POLYHEDRON_DEBUG
+ printf("From contact forces: vertex fx %f fy %f fz %f\n"
+ " torque body %d: %f %f %f\n",
+ discrete[ifirst+ni][3], discrete[ifirst+ni][4], discrete[ifirst+ni][5],
+ atom->tag[ibody],torque[ibody][0],torque[ibody][1],torque[ibody][2]);
+ #endif
+}
+
+/* ----------------------------------------------------------------------
+ Determine the length of the contact segment, i.e. the separation between
+ 2 contacts
+------------------------------------------------------------------------- */
+
+double FixWallBodyPolyhedron::contact_separation(const Contact& c1,
+ const Contact& c2)
+{
+ double x1 = c1.xv[0];
+ double y1 = c1.xv[1];
+ double x2 = c1.xe[0];
+ double y2 = c1.xe[1];
+ double x3 = c2.xv[0];
+ double y3 = c2.xv[1];
+
+ double delta_a = 0.0;
+ if (fabs(x2 - x1) > EPSILON) {
+ double A = (y2 - y1) / (x2 - x1);
+ delta_a = fabs(y1 - A * x1 - y3 + A * x3) / sqrt(1 + A * A);
+ } else {
+ delta_a = fabs(x1 - x3);
+ }
+
+ return delta_a;
+}
+
+/* ----------------------------------------------------------------------
+ Accumulate torque to body from the force f=(fx,fy,fz) acting at point x
+------------------------------------------------------------------------- */
+
+void FixWallBodyPolyhedron::sum_torque(double* xm, double *x, double fx,
+ double fy, double fz, double* torque)
+{
+ double rx = x[0] - xm[0];
+ double ry = x[1] - xm[1];
+ double rz = x[2] - xm[2];
+ double tx = ry * fz - rz * fy;
+ double ty = rz * fx - rx * fz;
+ double tz = rx * fy - ry * fx;
+ torque[0] += tx;
+ torque[1] += ty;
+ torque[2] += tz;
+}
+
+/* ----------------------------------------------------------------------
+ Calculate the total velocity of a point (vertex, a point on an edge):
+ vi = vcm + omega ^ (p - xcm)
+------------------------------------------------------------------------- */
+
+void FixWallBodyPolyhedron::total_velocity(double* p, double *xcm,
+ double* vcm, double *angmom, double *inertia,
+ double *quat, double* vi)
+{
+ double r[3],omega[3],ex_space[3],ey_space[3],ez_space[3];
+ r[0] = p[0] - xcm[0];
+ r[1] = p[1] - xcm[1];
+ r[2] = p[2] - xcm[2];
+ MathExtra::q_to_exyz(quat,ex_space,ey_space,ez_space);
+ MathExtra::angmom_to_omega(angmom,ex_space,ey_space,ez_space,
+ inertia,omega);
+ vi[0] = omega[1]*r[2] - omega[2]*r[1] + vcm[0];
+ vi[1] = omega[2]*r[0] - omega[0]*r[2] + vcm[1];
+ vi[2] = omega[0]*r[1] - omega[1]*r[0] + vcm[2];
+}
+
+/* ---------------------------------------------------------------------- */
+
+void FixWallBodyPolyhedron::distance(const double* x2, const double* x1,
+ double& r) {
+ r = sqrt((x2[0] - x1[0]) * (x2[0] - x1[0])
+ + (x2[1] - x1[1]) * (x2[1] - x1[1])
+ + (x2[2] - x1[2]) * (x2[2] - x1[2]));
+}
diff --git a/src/BODY/fix_wall_body_polyhedron.h b/src/BODY/fix_wall_body_polyhedron.h
new file mode 100644
index 0000000000000000000000000000000000000000..ff7b7ca7cfd0806de2d5f4fcd16c79b48c980954
--- /dev/null
+++ b/src/BODY/fix_wall_body_polyhedron.h
@@ -0,0 +1,143 @@
+/* -*- c++ -*- ----------------------------------------------------------
+ LAMMPS - Large-scale Atomic/Molecular Massively Parallel Simulator
+ http://lammps.sandia.gov, Sandia National Laboratories
+ Steve Plimpton, sjplimp@sandia.gov
+
+ Copyright (2003) Sandia Corporation. Under the terms of Contract
+ DE-AC04-94AL85000 with Sandia Corporation, the U.S. Government retains
+ certain rights in this software. This software is distributed under
+ the GNU General Public License.
+
+ See the README file in the top-level LAMMPS directory.
+------------------------------------------------------------------------- */
+
+#ifdef FIX_CLASS
+
+FixStyle(wall/body/polyhedron,FixWallBodyPolyhedron)
+
+#else
+
+#ifndef LMP_FIX_WALL_BODY_POLYHERON_H
+#define LMP_FIX_WALL_BODY_POLYHERON_H
+
+#include "fix.h"
+
+namespace LAMMPS_NS {
+
+class FixWallBodyPolyhedron : public Fix {
+ public:
+ FixWallBodyPolyhedron(class LAMMPS *, int, char **);
+ virtual ~FixWallBodyPolyhedron();
+ int setmask();
+ void init();
+ void setup(int);
+ virtual void post_force(int);
+ void reset_dt();
+
+ struct Contact {
+ int ibody, jbody; // body (i.e. atom) indices (not tags)
+ int vertex; // vertex of the first polygon
+ int edge; // edge of the second polygon
+ double xv[3]; // coordinates of the vertex
+ double xe[3]; // coordinates of the projection of the vertex on the edge
+ double separation;// separation at contact
+ };
+
+ protected:
+ int wallstyle,pairstyle,wiggle,axis;
+ double kn,c_n,c_t;
+ double lo,hi,cylradius;
+ double amplitude,period,omega;
+ double dt;
+ int time_origin;
+
+ class AtomVecBody *avec;
+ class BodyRoundedPolyhedron *bptr;
+
+ double **discrete; // list of all sub-particles for all bodies
+ int ndiscrete; // number of discretes in list
+ int dmax; // allocated size of discrete list
+ int *dnum; // number of discretes per line, 0 if uninit
+ int *dfirst; // index of first discrete per each line
+ int nmax; // allocated size of dnum,dfirst vectors
+
+ double **edge; // list of all edge for all bodies
+ int nedge; // number of edge in list
+ int edmax; // allocated size of edge list
+ int *ednum; // number of edges per line, 0 if uninit
+ int *edfirst; // index of first edge per each line
+ int ednummax; // allocated size of ednum,edfirst vectors
+
+ double **face; // list of all edge for all bodies
+ int nface; // number of faces in list
+ int facmax; // allocated size of face list
+ int *facnum; // number of faces per line, 0 if uninit
+ int *facfirst; // index of first face per each line
+ int facnummax; // allocated size of facnum,facfirst vectors
+
+ double *enclosing_radius; // enclosing radii for all bodies
+ double *rounded_radius; // rounded radii for all bodies
+
+ void body2space(int);
+
+ int edge_against_wall(int ibody, double wall_pos, int side, double* vwall,
+ double** x, double** f, double** torque, Contact* contact_list,
+ int &num_contacts, double* facc);
+ int sphere_against_wall(int i, double wall_pos, int side, double* vwall,
+ double** x, double** v, double** f, double** angmom, double** torque);
+
+ int compute_distance_to_wall(int ibody, int edge_index, double *xmi,
+ double rounded_radius_i, double wall_pos, int side,
+ double* vwall, int &contact);
+ double contact_separation(const Contact& c1, const Contact& c2);
+ void contact_forces(int ibody, double j_a, double *xi, double *xj,
+ double delx, double dely, double delz,
+ double fx, double fy, double fz, double** x, double** v,
+ double** angmom, double** f, double** torque, double* vwall);
+
+ void contact_forces(Contact& contact, double j_a, double** x,
+ double** v, double** angmom, double** f, double** torque,
+ double* vwall, double* facc);
+ void sum_torque(double* xm, double *x, double fx,
+ double fy, double fz, double* torque);
+ void total_velocity(double* p, double *xcm, double* vcm, double *angmom,
+ double *inertia, double *quat, double* vi);
+ void distance(const double* x2, const double* x1, double& r);
+
+};
+
+}
+
+#endif
+#endif
+
+/* ERROR/WARNING messages:
+
+E: Illegal ... command
+
+Self-explanatory. Check the input script syntax and compare to the
+documentation for the command. You can use -echo screen as a
+command-line option when running LAMMPS to see the offending line.
+
+E: Fix wall/body/polyhedron requires atom style body rounded/polyhedron
+
+Self-explanatory.
+
+E: Cannot use wall in periodic dimension
+
+Self-explanatory.
+
+E: Cannot wiggle and shear fix wall/body/polygon
+
+Cannot specify both options at the same time.
+
+E: Invalid wiggle direction for fix wall/body/polygon
+
+Self-explanatory.
+
+E: Fix wall/body/polygon is incompatible with Pair style
+
+Must use a body pair style to define the parameters needed for
+this fix.
+
+*/
diff --git a/src/BODY/pair_body.cpp b/src/BODY/pair_body_nparticle.cpp
similarity index 95%
rename from src/BODY/pair_body.cpp
rename to src/BODY/pair_body_nparticle.cpp
index 8c12c0cf36aa0384c50e3745b45c969c8aa29cc2..80b45beb4e9ecf174503ea7f46c19c0e8a7f46a1 100644
--- a/src/BODY/pair_body.cpp
+++ b/src/BODY/pair_body_nparticle.cpp
@@ -15,7 +15,7 @@
#include <cstdio>
#include <cstdlib>
#include <cstring>
-#include "pair_body.h"
+#include "pair_body_nparticle.h"
#include "math_extra.h"
#include "atom.h"
#include "atom_vec_body.h"
@@ -32,7 +32,7 @@ using namespace LAMMPS_NS;
/* ---------------------------------------------------------------------- */
-PairBody::PairBody(LAMMPS *lmp) : Pair(lmp)
+PairBodyNparticle::PairBodyNparticle(LAMMPS *lmp) : Pair(lmp)
{
dmax = nmax = 0;
discrete = NULL;
@@ -44,7 +44,7 @@ PairBody::PairBody(LAMMPS *lmp) : Pair(lmp)
/* ---------------------------------------------------------------------- */
-PairBody::~PairBody()
+PairBodyNparticle::~PairBodyNparticle()
{
memory->destroy(discrete);
memory->destroy(dnum);
@@ -66,7 +66,7 @@ PairBody::~PairBody()
/* ---------------------------------------------------------------------- */
-void PairBody::compute(int eflag, int vflag)
+void PairBodyNparticle::compute(int eflag, int vflag)
{
int i,j,ii,jj,inum,jnum,itype,jtype;
int ni,nj,npi,npj,ifirst,jfirst;
@@ -336,7 +336,7 @@ void PairBody::compute(int eflag, int vflag)
allocate all arrays
------------------------------------------------------------------------- */
-void PairBody::allocate()
+void PairBodyNparticle::allocate()
{
allocated = 1;
int n = atom->ntypes;
@@ -361,7 +361,7 @@ void PairBody::allocate()
global settings
------------------------------------------------------------------------- */
-void PairBody::settings(int narg, char **arg)
+void PairBodyNparticle::settings(int narg, char **arg)
{
if (narg != 1) error->all(FLERR,"Illegal pair_style command");
@@ -381,7 +381,7 @@ void PairBody::settings(int narg, char **arg)
set coeffs for one or more type pairs
------------------------------------------------------------------------- */
-void PairBody::coeff(int narg, char **arg)
+void PairBodyNparticle::coeff(int narg, char **arg)
{
if (narg < 4 || narg > 5)
error->all(FLERR,"Incorrect args for pair coefficients");
@@ -415,12 +415,12 @@ void PairBody::coeff(int narg, char **arg)
init specific to this pair style
------------------------------------------------------------------------- */
-void PairBody::init_style()
+void PairBodyNparticle::init_style()
{
avec = (AtomVecBody *) atom->style_match("body");
- if (!avec) error->all(FLERR,"Pair body requires atom style body");
+ if (!avec) error->all(FLERR,"Pair body/nparticle requires atom style body");
if (strcmp(avec->bptr->style,"nparticle") != 0)
- error->all(FLERR,"Pair body requires body style nparticle");
+ error->all(FLERR,"Pair body/nparticle requires body style nparticle");
bptr = (BodyNparticle *) avec->bptr;
neighbor->request(this,instance_me);
@@ -430,7 +430,7 @@ void PairBody::init_style()
init for one type pair i,j and corresponding j,i
------------------------------------------------------------------------- */
-double PairBody::init_one(int i, int j)
+double PairBodyNparticle::init_one(int i, int j)
{
if (setflag[i][j] == 0) {
epsilon[i][j] = mix_energy(epsilon[i][i],epsilon[j][j],
@@ -459,7 +459,7 @@ double PairBody::init_one(int i, int j)
store sub-particle space-frame displacements from COM in discrete list
------------------------------------------------------------------------- */
-void PairBody::body2space(int i)
+void PairBodyNparticle::body2space(int i)
{
int ibonus = atom->body[i];
AtomVecBody::Bonus *bonus = &avec->bonus[ibonus];
diff --git a/src/BODY/pair_body.h b/src/BODY/pair_body_nparticle.h
similarity index 90%
rename from src/BODY/pair_body.h
rename to src/BODY/pair_body_nparticle.h
index 94fbdf34dffd12000165d4f0e936bc64dcc5ae00..9c7d832b64bcacf7fa61baaa0b3ca917f9cbd4ce 100644
--- a/src/BODY/pair_body.h
+++ b/src/BODY/pair_body_nparticle.h
@@ -13,21 +13,21 @@
#ifdef PAIR_CLASS
-PairStyle(body,PairBody)
+PairStyle(body/nparticle,PairBodyNparticle)
#else
-#ifndef LMP_PAIR_BODY_H
-#define LMP_PAIR_BODY_H
+#ifndef LMP_PAIR_BODY_NPARTICLE_H
+#define LMP_PAIR_BODY_NPARTICLE_H
#include "pair.h"
namespace LAMMPS_NS {
-class PairBody : public Pair {
+class PairBodyNparticle : public Pair {
public:
- PairBody(class LAMMPS *);
- ~PairBody();
+ PairBodyNparticle(class LAMMPS *);
+ ~PairBodyNparticle();
void compute(int, int);
void settings(int, char **);
void coeff(int, char **);
diff --git a/src/BODY/pair_body_rounded_polygon.cpp b/src/BODY/pair_body_rounded_polygon.cpp
new file mode 100644
index 0000000000000000000000000000000000000000..14ef70f476061f1240dad92b7e694e6aa1f5957c
--- /dev/null
+++ b/src/BODY/pair_body_rounded_polygon.cpp
@@ -0,0 +1,1380 @@
+/* ----------------------------------------------------------------------
+ LAMMPS - Large-scale Atomic/Molecular Massively Parallel Simulator
+ http://lammps.sandia.gov, Sandia National Laboratories
+ Steve Plimpton, sjplimp@sandia.gov
+
+ Copyright (2003) Sandia Corporation. Under the terms of Contract
+ DE-AC04-94AL85000 with Sandia Corporation, the U.S. Government retains
+ certain rights in this software. This software is distributed under
+ the GNU General Public License.
+
+ See the README file in the top-level LAMMPS directory.
+------------------------------------------------------------------------- */
+
+/* ----------------------------------------------------------------------
+ Contributing author: Trung Dac Nguyen (ndactrung@gmail.com)
+ Ref: Fraige, Langston, Matchett and Dodds, Particuology 2008, 6:455-466
+ Note: The current implementation has not taken into account
+ the contact history for friction forces.
+------------------------------------------------------------------------- */
+
+#include <cmath>
+#include <cstdio>
+#include <cstdlib>
+#include <cstring>
+#include "pair_body_rounded_polygon.h"
+#include "math_extra.h"
+#include "atom.h"
+#include "atom_vec_body.h"
+#include "body_rounded_polygon.h"
+#include "comm.h"
+#include "force.h"
+#include "fix.h"
+#include "modify.h"
+#include "neighbor.h"
+#include "neigh_list.h"
+#include "memory.h"
+#include "error.h"
+
+using namespace LAMMPS_NS;
+
+#define DELTA 10000
+#define EPSILON 1e-3
+#define MAX_CONTACTS 4 // maximum number of contacts for 2D models
+#define EFF_CONTACTS 2 // effective contacts for 2D models
+
+//#define _CONVEX_POLYGON
+//#define _POLYGON_DEBUG
+
+enum {INVALID=0,NONE=1,VERTEXI=2,VERTEXJ=3,EDGE=4};
+
+/* ---------------------------------------------------------------------- */
+
+PairBodyRoundedPolygon::PairBodyRoundedPolygon(LAMMPS *lmp) : Pair(lmp)
+{
+ dmax = nmax = 0;
+ discrete = NULL;
+ dnum = dfirst = NULL;
+
+ edmax = ednummax = 0;
+ edge = NULL;
+ ednum = edfirst = NULL;
+
+ enclosing_radius = NULL;
+ rounded_radius = NULL;
+ maxerad = NULL;
+
+ single_enable = 0;
+ restartinfo = 0;
+
+ c_n = 0.1;
+ c_t = 0.2;
+ mu = 0.0;
+ delta_ua = 1.0;
+}
+
+/* ---------------------------------------------------------------------- */
+
+PairBodyRoundedPolygon::~PairBodyRoundedPolygon()
+{
+ memory->destroy(discrete);
+ memory->destroy(dnum);
+ memory->destroy(dfirst);
+
+ memory->destroy(edge);
+ memory->destroy(ednum);
+ memory->destroy(edfirst);
+
+ memory->destroy(enclosing_radius);
+ memory->destroy(rounded_radius);
+
+ if (allocated) {
+ memory->destroy(setflag);
+ memory->destroy(cutsq);
+
+ memory->destroy(k_n);
+ memory->destroy(k_na);
+ memory->destroy(maxerad);
+ }
+}
+
+/* ---------------------------------------------------------------------- */
+
+void PairBodyRoundedPolygon::compute(int eflag, int vflag)
+{
+ int i,j,ii,jj,inum,jnum,itype,jtype;
+ int ni,nj,npi,npj,ifirst,jfirst;
+ int nei,nej,iefirst,jefirst;
+ double xtmp,ytmp,ztmp,delx,dely,delz,evdwl,fx,fy,fz;
+ double rsq,rsqinv,r,radi,radj,eradi,eradj,rradi,rradj,k_nij,k_naij;
+ double xi[3],xj[3],fi[3],fj[3],ti[3],tj[3],facc[3];
+ double *dxi,*dxj;
+ int *ilist,*jlist,*numneigh,**firstneigh;
+
+ evdwl = 0.0;
+ if (eflag || vflag) ev_setup(eflag,vflag);
+ else evflag = vflag_fdotr = 0;
+
+ double **x = atom->x;
+ double **v = atom->v;
+ double **f = atom->f;
+ double **torque = atom->torque;
+ double **angmom = atom->angmom;
+ double *radius = atom->radius;
+ tagint* tag = atom->tag;
+ int *body = atom->body;
+ int *type = atom->type;
+ int nlocal = atom->nlocal;
+ int nall = nlocal + atom->nghost;
+ int newton_pair = force->newton_pair;
+
+ inum = list->inum;
+ ilist = list->ilist;
+ numneigh = list->numneigh;
+ firstneigh = list->firstneigh;
+
+ // grow the per-atom lists if necessary and initialize
+
+ if (atom->nmax > nmax) {
+ memory->destroy(dnum);
+ memory->destroy(dfirst);
+ memory->destroy(ednum);
+ memory->destroy(edfirst);
+ memory->destroy(enclosing_radius);
+ memory->destroy(rounded_radius);
+ nmax = atom->nmax;
+ memory->create(dnum,nmax,"pair:dnum");
+ memory->create(dfirst,nmax,"pair:dfirst");
+ memory->create(ednum,nmax,"pair:ednum");
+ memory->create(edfirst,nmax,"pair:edfirst");
+ memory->create(enclosing_radius,nmax,"pair:enclosing_radius");
+ memory->create(rounded_radius,nmax,"pair:rounded_radius");
+ }
+
+ ndiscrete = nedge = 0;
+ for (i = 0; i < nall; i++)
+ dnum[i] = ednum[i] = 0;
+
+ // loop over neighbors of my atoms
+
+ for (ii = 0; ii < inum; ii++) {
+ i = ilist[ii];
+ xtmp = x[i][0];
+ ytmp = x[i][1];
+ ztmp = x[i][2];
+ itype = type[i];
+ radi = radius[i];
+ jlist = firstneigh[i];
+ jnum = numneigh[i];
+
+ if (body[i] >= 0) {
+ if (dnum[i] == 0) body2space(i);
+ npi = dnum[i];
+ ifirst = dfirst[i];
+ nei = ednum[i];
+ iefirst = edfirst[i];
+ eradi = enclosing_radius[i];
+ rradi = rounded_radius[i];
+ }
+
+ for (jj = 0; jj < jnum; jj++) {
+ j = jlist[jj];
+ j &= NEIGHMASK;
+
+ delx = xtmp - x[j][0];
+ dely = ytmp - x[j][1];
+ delz = ztmp - x[j][2];
+ rsq = delx*delx + dely*dely + delz*delz;
+ jtype = type[j];
+ radj = radius[j];
+
+ // body/body interactions
+
+ evdwl = 0.0;
+ facc[0] = facc[1] = facc[2] = 0;
+
+ if (body[i] < 0 || body[j] < 0) continue;
+
+ if (dnum[j] == 0) body2space(j);
+ npj = dnum[j];
+ jfirst = dfirst[j];
+ nej = ednum[j];
+ jefirst = edfirst[j];
+ eradj = enclosing_radius[j];
+ rradj = rounded_radius[j];
+
+ k_nij = k_n[itype][jtype];
+ k_naij = k_na[itype][jtype];
+
+ // no interaction
+
+ r = sqrt(rsq);
+ if (r > radi + radj + cut_inner) continue;
+ rsqinv = 1.0 / rsq;
+
+ if (npi == 1 && npj == 1) {
+ sphere_against_sphere(i, j, delx, dely, delz, rsq,
+ k_nij, k_naij, x, v, f, evflag);
+ continue;
+ }
+
+ // reset vertex and edge forces
+
+ for (ni = 0; ni < npi; ni++) {
+ discrete[ifirst+ni][3] = 0;
+ discrete[ifirst+ni][4] = 0;
+ discrete[ifirst+ni][5] = 0;
+ }
+
+ for (nj = 0; nj < npj; nj++) {
+ discrete[jfirst+nj][3] = 0;
+ discrete[jfirst+nj][4] = 0;
+ discrete[jfirst+nj][5] = 0;
+ }
+
+ for (ni = 0; ni < nei; ni++) {
+ edge[iefirst+ni][2] = 0;
+ edge[iefirst+ni][3] = 0;
+ edge[iefirst+ni][4] = 0;
+ }
+
+ for (nj = 0; nj < nej; nj++) {
+ edge[jefirst+nj][2] = 0;
+ edge[jefirst+nj][3] = 0;
+ edge[jefirst+nj][4] = 0;
+ }
+
+ int interact, num_contacts, done;
+ double delta_a, j_a;
+ Contact contact_list[MAX_CONTACTS];
+
+ num_contacts = 0;
+
+ // check interaction between i's vertices and j' edges
+
+ interact = vertex_against_edge(i, j, k_nij, k_naij,
+ x, f, torque, tag, contact_list,
+ num_contacts, evdwl, facc);
+
+ // check interaction between j's vertices and i' edges
+
+ interact = vertex_against_edge(j, i, k_nij, k_naij,
+ x, f, torque, tag, contact_list,
+ num_contacts, evdwl, facc);
+
+ if (num_contacts >= 2) {
+
+ // find the first two distinct contacts
+
+ done = 0;
+ for (int m = 0; m < num_contacts-1; m++) {
+ for (int n = m+1; n < num_contacts; n++) {
+ delta_a = contact_separation(contact_list[m], contact_list[n]);
+ if (delta_a > 0) {
+ j_a = delta_a / (EFF_CONTACTS * delta_ua);
+ if (j_a < 1.0) j_a = 1.0;
+
+ // scale the force at both contacts
+
+ contact_forces(contact_list[m], j_a, x, v, angmom, f, torque,
+ evdwl, facc);
+ contact_forces(contact_list[n], j_a, x, v, angmom, f, torque,
+ evdwl, facc);
+ done = 1;
+
+ #ifdef _POLYGON_DEBUG
+ printf(" Two separate contacts %d and %d: delta_a = %f; j_a = %f\n",
+ m, n, delta_a, j_a);
+ printf(" %d: vertex %d of body %d and edge %d of body %d; "
+ "xv = %f %f %f; xe = %f %f %f\n",
+ m, contact_list[m].vertex, contact_list[m].ibody,
+ contact_list[m].edge, contact_list[m].jbody,
+ contact_list[m].xv[0], contact_list[m].xv[1],
+ contact_list[m].xv[2], contact_list[m].xe[0],
+ contact_list[m].xe[1], contact_list[m].xe[2]);
+ printf(" %d: vertex %d of body %d and edge %d of body %d; "
+ "xv = %f %f %f; xe = %f %f %f\n",
+ n, contact_list[n].vertex, contact_list[n].ibody,
+ contact_list[n].edge, contact_list[n].jbody,
+ contact_list[n].xv[0], contact_list[n].xv[1],
+ contact_list[n].xv[2], contact_list[n].xe[0],
+ contact_list[n].xe[1], contact_list[n].xe[2]);
+ #endif
+
+ break;
+ }
+ }
+ if (done == 1) break;
+ }
+
+
+ } else if (num_contacts == 1) {
+
+ // if there's only one contact, it should be handled here
+ // since forces/torques have not been accumulated from vertex2edge()
+
+ contact_forces(contact_list[0], 1.0, x, v, angmom, f, torque, evdwl, facc);
+
+ #ifdef _POLYGON_DEBUG
+ printf("One contact between vertex %d of body %d and edge %d of body %d:\n",
+ contact_list[0].vertex, tag[contact_list[0].ibody],
+ contact_list[0].edge, tag[contact_list[0].jbody]);
+ printf("xv = %f %f %f; xe = %f %f %f\n",
+ contact_list[0].xv[0], contact_list[0].xv[1], contact_list[0].xv[2],
+ contact_list[0].xe[0], contact_list[0].xe[1], contact_list[0].xe[2]);
+ #endif
+ }
+
+ #ifdef _POLYGON_DEBUG
+ int num_overlapping_contacts = 0;
+ for (int m = 0; m < num_contacts-1; m++) {
+ for (int n = m+1; n < num_contacts; n++) {
+ double l = contact_separation(contact_list[m], contact_list[n]);
+ if (l < EPSILON) num_overlapping_contacts++;
+ }
+ }
+ printf("There are %d contacts detected, %d of which overlap.\n",
+ num_contacts, num_overlapping_contacts);
+ #endif
+
+ if (evflag) ev_tally_xyz(i,j,nlocal,newton_pair,evdwl,0.0,
+ facc[0],facc[1],facc[2],delx,dely,delz);
+
+ } // end for jj
+ }
+
+ if (vflag_fdotr) virial_fdotr_compute();
+}
+
+/* ----------------------------------------------------------------------
+ allocate all arrays
+------------------------------------------------------------------------- */
+
+void PairBodyRoundedPolygon::allocate()
+{
+ allocated = 1;
+ int n = atom->ntypes;
+
+ memory->create(setflag,n+1,n+1,"pair:setflag");
+ for (int i = 1; i <= n; i++)
+ for (int j = i; j <= n; j++)
+ setflag[i][j] = 0;
+
+ memory->create(cutsq,n+1,n+1,"pair:cutsq");
+
+ memory->create(k_n,n+1,n+1,"pair:k_n");
+ memory->create(k_na,n+1,n+1,"pair:k_na");
+ memory->create(maxerad,n+1,"pair:maxerad");
+}
+
+/* ----------------------------------------------------------------------
+ global settings
+------------------------------------------------------------------------- */
+
+void PairBodyRoundedPolygon::settings(int narg, char **arg)
+{
+ if (narg < 5) error->all(FLERR,"Illegal pair_style command");
+
+ c_n = force->numeric(FLERR,arg[0]);
+ c_t = force->numeric(FLERR,arg[1]);
+ mu = force->numeric(FLERR,arg[2]);
+ delta_ua = force->numeric(FLERR,arg[3]);
+ cut_inner = force->numeric(FLERR,arg[4]);
+
+ if (delta_ua < 0) delta_ua = 1;
+}
+
+/* ----------------------------------------------------------------------
+ set coeffs for one or more type pairs
+------------------------------------------------------------------------- */
+
+void PairBodyRoundedPolygon::coeff(int narg, char **arg)
+{
+ if (narg < 4 || narg > 5)
+ error->all(FLERR,"Incorrect args for pair coefficients");
+ if (!allocated) allocate();
+
+ int ilo,ihi,jlo,jhi;
+ force->bounds(FLERR,arg[0],atom->ntypes,ilo,ihi);
+ force->bounds(FLERR,arg[1],atom->ntypes,jlo,jhi);
+
+ double k_n_one = force->numeric(FLERR,arg[2]);
+ double k_na_one = force->numeric(FLERR,arg[3]);
+
+ int count = 0;
+ for (int i = ilo; i <= ihi; i++) {
+ for (int j = MAX(jlo,i); j <= jhi; j++) {
+ k_n[i][j] = k_n_one;
+ k_na[i][j] = k_na_one;
+ setflag[i][j] = 1;
+ count++;
+ }
+ }
+
+ if (count == 0) error->all(FLERR,"Incorrect args for pair coefficients");
+}
+
+/* ----------------------------------------------------------------------
+ init specific to this pair style
+------------------------------------------------------------------------- */
+
+void PairBodyRoundedPolygon::init_style()
+{
+ avec = (AtomVecBody *) atom->style_match("body");
+ if (!avec)
+ error->all(FLERR,"Pair body/rounded/polygon requires atom style body");
+ if (strcmp(avec->bptr->style,"rounded/polygon") != 0)
+ error->all(FLERR,"Pair body/rounded/polygon requires "
+ "body style rounded/polygon");
+ bptr = (BodyRoundedPolygon *) avec->bptr;
+
+ if (force->newton_pair == 0)
+ error->all(FLERR,"Pair style body/rounded/polygon requires "
+ "newton pair on");
+
+ if (comm->ghost_velocity == 0)
+ error->all(FLERR,"Pair body/rounded/polygon requires "
+ "ghost atoms store velocity");
+
+ neighbor->request(this);
+
+ // find the maximum enclosing radius for each atom type
+
+ int i, itype;
+ double eradi;
+ int* body = atom->body;
+ int* type = atom->type;
+ int ntypes = atom->ntypes;
+ int nlocal = atom->nlocal;
+
+ if (atom->nmax > nmax) {
+ memory->destroy(dnum);
+ memory->destroy(dfirst);
+ memory->destroy(ednum);
+ memory->destroy(edfirst);
+ memory->destroy(enclosing_radius);
+ memory->destroy(rounded_radius);
+ nmax = atom->nmax;
+ memory->create(dnum,nmax,"pair:dnum");
+ memory->create(dfirst,nmax,"pair:dfirst");
+ memory->create(ednum,nmax,"pair:ednum");
+ memory->create(edfirst,nmax,"pair:edfirst");
+ memory->create(enclosing_radius,nmax,"pair:enclosing_radius");
+ memory->create(rounded_radius,nmax,"pair:rounded_radius");
+ }
+
+ ndiscrete = nedge = 0;
+ for (i = 0; i < nlocal; i++)
+ dnum[i] = ednum[i] = 0;
+
+ double *merad = NULL;
+ memory->create(merad,ntypes+1,"pair:merad");
+ for (i = 1; i <= ntypes; i++)
+ maxerad[i] = merad[i] = 0;
+
+ int ipour;
+ for (ipour = 0; ipour < modify->nfix; ipour++)
+ if (strcmp(modify->fix[ipour]->style,"pour") == 0) break;
+ if (ipour == modify->nfix) ipour = -1;
+
+ int idep;
+ for (idep = 0; idep < modify->nfix; idep++)
+ if (strcmp(modify->fix[idep]->style,"deposit") == 0) break;
+ if (idep == modify->nfix) idep = -1;
+
+ for (i = 1; i <= ntypes; i++) {
+ merad[i] = 0.0;
+ if (ipour >= 0) {
+ itype = i;
+ merad[i] =
+ *((double *) modify->fix[ipour]->extract("radius",itype));
+ }
+ if (idep >= 0) {
+ itype = i;
+ merad[i] =
+ *((double *) modify->fix[idep]->extract("radius",itype));
+ }
+ }
+
+ for (i = 0; i < nlocal; i++) {
+ itype = type[i];
+ if (body[i] >= 0) {
+ if (dnum[i] == 0) body2space(i);
+ eradi = enclosing_radius[i];
+ if (eradi > merad[itype]) merad[itype] = eradi;
+ } else
+ merad[itype] = 0;
+ }
+
+ MPI_Allreduce(&merad[1],&maxerad[1],ntypes,MPI_DOUBLE,MPI_MAX,world);
+
+ memory->destroy(merad);
+}
+
+/* ----------------------------------------------------------------------
+ init for one type pair i,j and corresponding j,i
+------------------------------------------------------------------------- */
+
+double PairBodyRoundedPolygon::init_one(int i, int j)
+{
+ k_n[j][i] = k_n[i][j];
+ k_na[j][i] = k_na[i][j];
+
+ return (maxerad[i]+maxerad[j]);
+}
+
+/* ----------------------------------------------------------------------
+ convert N sub-particles in body I to space frame using current quaternion
+ store sub-particle space-frame displacements from COM in discrete list
+------------------------------------------------------------------------- */
+
+void PairBodyRoundedPolygon::body2space(int i)
+{
+ int ibonus = atom->body[i];
+ AtomVecBody::Bonus *bonus = &avec->bonus[ibonus];
+ int nsub = bptr->nsub(bonus);
+ double *coords = bptr->coords(bonus);
+ int body_num_edges = bptr->nedges(bonus);
+ double* edge_ends = bptr->edges(bonus);
+ double eradius = bptr->enclosing_radius(bonus);
+ double rradius = bptr->rounded_radius(bonus);
+
+ // get the number of sub-particles (vertices)
+ // and the index of the first vertex of my body in the list
+
+ dnum[i] = nsub;
+ dfirst[i] = ndiscrete;
+
+ // grow the vertex list if necessary
+ // the first 3 columns are for coords, the last 3 for forces
+
+ if (ndiscrete + nsub > dmax) {
+ dmax += DELTA;
+ memory->grow(discrete,dmax,6,"pair:discrete");
+ }
+
+ double p[3][3];
+ MathExtra::quat_to_mat(bonus->quat,p);
+
+ for (int m = 0; m < nsub; m++) {
+ MathExtra::matvec(p,&coords[3*m],discrete[ndiscrete]);
+ discrete[ndiscrete][3] = 0;
+ discrete[ndiscrete][4] = 0;
+ discrete[ndiscrete][5] = 0;
+ ndiscrete++;
+ }
+
+ // get the number of edges (vertices)
+ // and the index of the first edge of my body in the list
+
+ ednum[i] = body_num_edges;
+ edfirst[i] = nedge;
+
+ // grow the edge list if necessary
+ // the first 2 columns are for vertex indices within body, the last 3 for forces
+
+ if (nedge + body_num_edges > edmax) {
+ edmax += DELTA;
+ memory->grow(edge,edmax,5,"pair:edge");
+ }
+
+ for (int m = 0; m < body_num_edges; m++) {
+ edge[nedge][0] = static_cast<int>(edge_ends[2*m+0]);
+ edge[nedge][1] = static_cast<int>(edge_ends[2*m+1]);
+ edge[nedge][2] = 0;
+ edge[nedge][3] = 0;
+ edge[nedge][4] = 0;
+ nedge++;
+ }
+
+ enclosing_radius[i] = eradius;
+ rounded_radius[i] = rradius;
+}
+
+/* ----------------------------------------------------------------------
+ Interaction between two spheres with different radii
+ according to the 2D model from Fraige et al.
+---------------------------------------------------------------------- */
+
+void PairBodyRoundedPolygon::sphere_against_sphere(int i, int j,
+ double delx, double dely, double delz, double rsq,
+ double k_n, double k_na, double** x, double** v,
+ double** f, int evflag)
+{
+ double eradi,eradj,rradi,rradj;
+ double vr1,vr2,vr3,vnnr,vn1,vn2,vn3,vt1,vt2,vt3;
+ double rij,rsqinv,R,fx,fy,fz,fn[3],ft[3],fpair,shift,energy;
+ int nlocal = atom->nlocal;
+ int newton_pair = force->newton_pair;
+
+ eradi = enclosing_radius[i];
+ rradi = rounded_radius[i];
+
+ eradj = enclosing_radius[j];
+ rradj = rounded_radius[j];
+
+ rsqinv = 1.0/rsq;
+ rij = sqrt(rsq);
+ R = rij - (rradi + rradj);
+ shift = k_na * cut_inner;
+
+ energy = 0;
+
+ if (R <= 0) { // deformation occurs
+ fpair = -k_n * R - shift;
+ energy = (0.5 * k_n * R + shift) * R;
+ } else if (R <= cut_inner) { // not deforming but cohesive ranges overlap
+ fpair = k_na * R - shift;
+ energy = (-0.5 * k_na * R + shift) * R;
+ } else fpair = 0.0;
+
+ fx = delx*fpair/rij;
+ fy = dely*fpair/rij;
+ fz = delz*fpair/rij;
+
+ if (R <= EPSILON) { // in contact
+
+ // relative translational velocity
+
+ vr1 = v[i][0] - v[j][0];
+ vr2 = v[i][1] - v[j][1];
+ vr3 = v[i][2] - v[j][2];
+
+ // normal component
+
+ vnnr = vr1*delx + vr2*dely + vr3*delz;
+ vn1 = delx*vnnr * rsqinv;
+ vn2 = dely*vnnr * rsqinv;
+ vn3 = delz*vnnr * rsqinv;
+
+ // tangential component
+
+ vt1 = vr1 - vn1;
+ vt2 = vr2 - vn2;
+ vt3 = vr3 - vn3;
+
+ // normal friction term at contact
+
+ fn[0] = -c_n * vn1;
+ fn[1] = -c_n * vn2;
+ fn[2] = -c_n * vn3;
+
+ // tangential friction term at contact
+ // excluding the tangential deformation term
+
+ ft[0] = -c_t * vt1;
+ ft[1] = -c_t * vt2;
+ ft[2] = -c_t * vt3;
+ }
+
+ f[i][0] += fx;
+ f[i][1] += fy;
+ f[i][2] += fz;
+
+ if (newton_pair || j < nlocal) {
+ f[j][0] -= fx;
+ f[j][1] -= fy;
+ f[j][2] -= fz;
+ }
+
+ if (evflag) ev_tally_xyz(i,j,nlocal,newton_pair,
+ energy,0.0,fx,fy,fz,delx,dely,delz);
+}
+
+/* ----------------------------------------------------------------------
+ Determine the interaction mode between i's vertices against j's edges
+
+ i = atom i (body i)
+ j = atom j (body j)
+ x = atoms' coordinates
+ f = atoms' forces
+ torque = atoms' torques
+ tag = atoms' tags
+ contact_list = list of contacts
+ num_contacts = number of contacts between i's vertices and j's edges
+ Return:
+ interact = 0 no interaction at all
+ 1 there's at least one case where i's vertices interacts
+ with j's edges
+---------------------------------------------------------------------- */
+
+int PairBodyRoundedPolygon::vertex_against_edge(int i, int j,
+ double k_n, double k_na,
+ double** x, double** f,
+ double** torque, tagint* tag,
+ Contact* contact_list,
+ int &num_contacts,
+ double &evdwl, double* facc)
+{
+ int ni, npi, ifirst, nei, iefirst;
+ int nj, npj, jfirst, nej, jefirst;
+ double xpi[3], xpj[3], dist, eradi, eradj, rradi, rradj;
+ double fx, fy, fz, rx, ry, rz, energy;
+ int interact;
+ int nlocal = atom->nlocal;
+
+ npi = dnum[i];
+ ifirst = dfirst[i];
+ nei = ednum[i];
+ iefirst = edfirst[i];
+ eradi = enclosing_radius[i];
+ rradi = rounded_radius[i];
+
+ npj = dnum[j];
+ jfirst = dfirst[j];
+ nej = ednum[j];
+ jefirst = edfirst[j];
+ eradj = enclosing_radius[j];
+ rradj = rounded_radius[j];
+
+ energy = 0;
+ interact = 0;
+
+ // loop through body i's vertices
+
+ for (ni = 0; ni < npi; ni++) {
+
+ // convert body-fixed coordinates to space-fixed, xi
+
+ xpi[0] = x[i][0] + discrete[ifirst+ni][0];
+ xpi[1] = x[i][1] + discrete[ifirst+ni][1];
+ xpi[2] = x[i][2] + discrete[ifirst+ni][2];
+
+ // compute the distance from the vertex to the COM of body j
+
+ distance(xpi, x[j], dist);
+
+ #ifdef _POLYGON_DEBUG
+ printf("Distance between vertex %d of body %d (%0.1f %0.1f %0.1f) "
+ "to body %d's COM: %f (cut = %0.1f)\n",
+ ni, xpi[0], xpi[1], xpi[2], atom->tag[i], atom->tag[j], dist,
+ eradj + rradi + rradj + cut_inner);
+ #endif
+
+ // the vertex is within the enclosing circle (sphere) of body j,
+ // possibly interacting
+
+ if (dist > eradj + rradj + rradi + cut_inner) continue;
+
+ int mode, contact, p2vertex;
+ double d, R, hi[3], t, delx, dely, delz, fpair, shift;
+ double xj[3], rij;
+
+ // loop through body j's edges
+
+ for (nj = 0; nj < nej; nj++) {
+
+ // compute the distance between the edge nj to the vertex xpi
+
+ mode = compute_distance_to_vertex(j, nj, x[j], rradj,
+ xpi, rradi, cut_inner,
+ d, hi, t, contact);
+
+ if (mode == INVALID || mode == NONE) continue;
+
+ if (mode == VERTEXI || mode == VERTEXJ) {
+
+ interact = 1;
+
+ // vertex i interacts with a vertex of the edge, but does not contact
+
+ if (mode == VERTEXI) p2vertex = edge[jefirst+nj][0];
+ else if (mode == VERTEXJ) p2vertex = edge[jefirst+nj][1];
+
+ // p2.body2space(p2vertex, xj);
+ xpj[0] = x[j][0] + discrete[jfirst+p2vertex][0];
+ xpj[1] = x[j][1] + discrete[jfirst+p2vertex][1];
+ xpj[2] = x[j][2] + discrete[jfirst+p2vertex][2];
+
+ delx = xpi[0] - xpj[0];
+ dely = xpi[1] - xpj[1];
+ delz = xpi[2] - xpj[2];
+
+ // R = surface separation = rij shifted by the rounded radii
+ // R = rij - (p1.rounded_radius + p2.rounded_radius);
+ // note: the force is defined for R, not for rij
+ // R > rc: no interaction between vertex ni and p2vertex
+ // 0 < R < rc: cohesion between vertex ni and p2vertex
+ // R < 0: deformation between vertex ni and p2vertex
+
+ rij = sqrt(delx*delx + dely*dely + delz*delz);
+ R = rij - (rradi + rradj);
+ shift = k_na * cut_inner;
+
+ // the normal frictional term -c_n * vn will be added later
+
+ if (R <= 0) { // deformation occurs
+ fpair = -k_n * R - shift;
+ energy += (0.5 * k_n * R + shift) * R;
+ } else if (R <= cut_inner) { // not deforming but cohesive ranges overlap
+ fpair = k_na * R - shift;
+ energy += (-0.5 * k_na * R + shift) * R;
+ } else fpair = 0.0;
+
+ fx = delx*fpair/rij;
+ fy = dely*fpair/rij;
+ fz = delz*fpair/rij;
+
+ #ifdef _POLYGON_DEBUG
+ printf(" Interaction between vertex %d of %d and vertex %d of %d:",
+ ni, tag[i], p2vertex, tag[j]);
+ printf(" mode = %d; contact = %d; d = %f; rij = %f, t = %f\n",
+ mode, contact, d, rij, t);
+ printf(" R = %f; cut_inner = %f\n", R, cut_inner);
+ printf(" fpair = %f\n", fpair);
+ #endif
+
+ // add forces to body i and body j directly
+ // avoid double counts this pair of vertices
+ // i and j can be either local or ghost atoms (bodies)
+ // probably need more work here when the vertices' interaction
+ // are not symmetric, e.g. j interacts with the edge
+ // consisting of i but in mode = EDGE instead of VERTEX*.
+ // OR, for the time being assume that the edge length is
+ // sufficiently greater than the rounded radius to distinguish
+ // vertex-vertex from vertex-edge contact modes.
+ // Special case: when i is a sphere, also accumulate
+
+ if (tag[i] < tag[j] || npi == 1) {
+
+ f[i][0] += fx;
+ f[i][1] += fy;
+ f[i][2] += fz;
+ sum_torque(x[i], xpi, fx, fy, fz, torque[i]);
+
+ f[j][0] -= fx;
+ f[j][1] -= fy;
+ f[j][2] -= fz;
+ sum_torque(x[j], xpj, -fx, -fy, -fz, torque[j]);
+
+ facc[0] += fx; facc[1] += fy; facc[2] += fz;
+
+ #ifdef _POLYGON_DEBUG
+ printf(" from vertex-vertex: "
+ "force on vertex %d of body %d: fx %f fy %f fz %f\n"
+ " torque body %d: %f %f %f\n"
+ " torque body %d: %f %f %f\n", ni, tag[i], fx, fy, fz,
+ tag[i],torque[i][0],torque[i][1],torque[i][2],
+ tag[j],torque[j][0],torque[j][1],torque[j][2]);
+ #endif
+ }
+
+ #ifdef _CONVEX_POLYGON
+ // done with the edges from body j,
+ // given that vertex ni interacts with only one vertex
+ // from one edge of body j
+ break;
+ #endif
+
+ } else if (mode == EDGE) {
+
+ interact = 1;
+
+ // vertex i interacts with the edge
+
+ delx = xpi[0] - hi[0];
+ dely = xpi[1] - hi[1];
+ delz = xpi[2] - hi[2];
+
+ // R = surface separation = d shifted by the rounded radii
+ // R = d - (p1.rounded_radius + p2.rounded_radius);
+ // Note: the force is defined for R, not for d
+ // R > rc: no interaction between vertex i and edge j
+ // 0 < R < rc: cohesion between vertex i and edge j
+ // R < 0: deformation between vertex i and edge j
+ // rij = sqrt(delx*delx + dely*dely + delz*delz);
+
+ R = d - (rradi + rradj);
+ shift = k_na * cut_inner;
+
+ // the normal frictional term -c_n * vn will be added later
+
+ if (R <= 0) { // deformation occurs
+ fpair = -k_n * R - shift;
+ energy += (0.5 * k_n * R + shift) * R;
+ } else if (R <= cut_inner) { // not deforming but cohesive ranges overlap
+ fpair = k_na * R - shift;
+ energy += (-0.5 * k_na * R + shift) * R;
+ } else fpair = 0.0;
+
+ fx = delx*fpair/d;
+ fy = dely*fpair/d;
+ fz = delz*fpair/d;
+
+ #ifdef _POLYGON_DEBUG
+ printf(" Interaction between vertex %d of %d and edge %d of %d:",
+ ni, tag[i], nj, tag[j]);
+ printf(" mode = %d; contact = %d; d = %f; t = %f\n",
+ mode, contact, d, t);
+ printf(" R = %f; cut_inner = %f\n", R, cut_inner);
+ printf(" fpair = %f\n", fpair);
+ #endif
+
+ if (contact == 1) {
+
+ // vertex ni of body i contacts with edge nj of body j
+
+ contact_list[num_contacts].ibody = i;
+ contact_list[num_contacts].jbody = j;
+ contact_list[num_contacts].vertex = ni;
+ contact_list[num_contacts].edge = nj;
+ contact_list[num_contacts].xv[0] = xpi[0];
+ contact_list[num_contacts].xv[1] = xpi[1];
+ contact_list[num_contacts].xv[2] = xpi[2];
+ contact_list[num_contacts].xe[0] = hi[0];
+ contact_list[num_contacts].xe[1] = hi[1];
+ contact_list[num_contacts].xe[2] = hi[2];
+ contact_list[num_contacts].separation = R;
+ num_contacts++;
+
+ // store forces to vertex ni and the edge nj
+ // to be rescaled later
+
+ discrete[ifirst+ni][3] = fx;
+ discrete[ifirst+ni][4] = fy;
+ discrete[ifirst+ni][5] = fz;
+
+ edge[jefirst+nj][2] = -fx;
+ edge[jefirst+nj][3] = -fy;
+ edge[jefirst+nj][4] = -fz;
+
+ #ifdef _POLYGON_DEBUG
+ printf(" Stored forces at vertex and edge for accumulating later.\n");
+ #endif
+
+ } else { // no contact
+
+ // accumulate force and torque to both bodies directly
+
+ f[i][0] += fx;
+ f[i][1] += fy;
+ f[i][2] += fz;
+ sum_torque(x[i], xpi, fx, fy, fz, torque[i]);
+
+ f[j][0] -= fx;
+ f[j][1] -= fy;
+ f[j][2] -= fz;
+ sum_torque(x[j], hi, -fx, -fy, -fz, torque[j]);
+
+ facc[0] += fx; facc[1] += fy; facc[2] += fz;
+
+ #ifdef _POLYGON_DEBUG
+ printf(" from vertex-edge, no contact: "
+ "force on vertex %d of body %d: fx %f fy %f fz %f\n"
+ " torque body %d: %f %f %f\n"
+ " torque body %d: %f %f %f\n", ni, tag[i], fx, fy, fz,
+ tag[i],torque[i][0],torque[i][1],torque[i][2],
+ tag[j],torque[j][0],torque[j][1],torque[j][2]);
+ #endif
+ } // end if contact
+
+ #ifdef _CONVEX_POLYGON
+ // done with the edges from body j,
+ // given that vertex ni interacts with only one edge from body j
+ break;
+ #endif
+ } // end if mode
+
+ } // end for looping through the edges of body j
+
+ } // end for looping through the vertices of body i
+
+ evdwl += energy;
+
+ return interact;
+}
+
+/* -------------------------------------------------------------------------
+ Compute the distance between an edge of body i and a vertex from
+ another body
+ Input:
+ ibody = body i (i.e. atom i)
+ edge_index = edge index of body i
+ xmi = atom i's coordinates (body i's center of mass)
+ x0 = coordinate of the tested vertex from another body
+ x0_rounded_radius = rounded radius of the tested vertex
+ cut_inner = cutoff for vertex-vertex and vertex-edge interaction
+ Output:
+ d = Distance from a point x0 to an edge
+ hi = coordinates of the projection of x0 on the edge
+ t = ratio to determine the relative position of hi
+ wrt xi and xj on the segment
+ contact = 0 no contact between the queried vertex and the edge
+ 1 contact detected
+ return
+ INVALID if the edge index is invalid
+ NONE if there is no interaction
+ VERTEXI if the tested vertex interacts with the first vertex of the edge
+ VERTEXJ if the tested vertex interacts with the second vertex of the edge
+ EDGE if the tested vertex interacts with the edge
+------------------------------------------------------------------------- */
+
+int PairBodyRoundedPolygon::compute_distance_to_vertex(int ibody,
+ int edge_index,
+ double *xmi,
+ double rounded_radius,
+ double* x0,
+ double x0_rounded_radius,
+ double cut_inner,
+ double &d,
+ double hi[3],
+ double &t,
+ int &contact)
+{
+ if (edge_index >= ednum[ibody]) return INVALID;
+
+ int mode,ifirst,iefirst,npi1,npi2;
+ double xi1[3],xi2[3],u[3],v[3],uij[3];
+ double udotv, magv, magucostheta;
+ double delx,dely,delz;
+
+ ifirst = dfirst[ibody];
+ iefirst = edfirst[ibody];
+ npi1 = static_cast<int>(edge[iefirst+edge_index][0]);
+ npi2 = static_cast<int>(edge[iefirst+edge_index][1]);
+
+ // compute the space-fixed coordinates for the vertices of the edge
+
+ xi1[0] = xmi[0] + discrete[ifirst+npi1][0];
+ xi1[1] = xmi[1] + discrete[ifirst+npi1][1];
+ xi1[2] = xmi[2] + discrete[ifirst+npi1][2];
+
+ xi2[0] = xmi[0] + discrete[ifirst+npi2][0];
+ xi2[1] = xmi[1] + discrete[ifirst+npi2][1];
+ xi2[2] = xmi[2] + discrete[ifirst+npi2][2];
+
+ // u = x0 - xi1
+
+ u[0] = x0[0] - xi1[0];
+ u[1] = x0[1] - xi1[1];
+ u[2] = x0[2] - xi1[2];
+
+ // v = xi2 - xi1
+
+ v[0] = xi2[0] - xi1[0];
+ v[1] = xi2[1] - xi1[1];
+ v[2] = xi2[2] - xi1[2];
+
+ // dot product between u and v = magu * magv * costheta
+
+ udotv = u[0] * v[0] + u[1] * v[1] + u[2] * v[2];
+ magv = sqrt(v[0] * v[0] + v[1] * v[1] + v[2] * v[2]);
+ magucostheta = udotv / magv;
+
+ // uij is the unit vector pointing from xi to xj
+
+ uij[0] = v[0] / magv;
+ uij[1] = v[1] / magv;
+ uij[2] = v[2] / magv;
+
+ // position of the projection of x0 on the line (xi, xj)
+
+ hi[0] = xi1[0] + magucostheta * uij[0];
+ hi[1] = xi1[1] + magucostheta * uij[1];
+ hi[2] = xi1[2] + magucostheta * uij[2];
+
+ // distance from x0 to the line (xi, xj) = distance from x0 to hi
+
+ distance(hi, x0, d);
+
+ // determine the interaction mode
+ // for 2D: a vertex can interact with one edge at most
+ // for 3D: a vertex can interact with one face at most
+
+ mode = NONE;
+ contact = 0;
+
+ if (d > rounded_radius + x0_rounded_radius + cut_inner) {
+
+ // if the vertex is far away from the edge
+
+ mode = NONE;
+
+ } else {
+
+ // check if x0 (the queried vertex) and xmi (the body's center of mass)
+ // are on the different sides of the edge
+
+ #ifdef _CONVEX_POLYGON
+ int m = opposite_sides(xi1, xi2, x0, xmi);
+ #else
+ int m = 1;
+ #endif
+
+ if (m == 0) {
+
+ // x0 and xmi are on not the opposite sides of the edge
+ // leave xpi for another edge to detect
+
+ mode = NONE;
+
+ } else {
+
+ // x0 and xmi are on the different sides
+ // t is the ratio to detect if x0 is closer to the vertices xi or xj
+
+ if (fabs(xi2[0] - xi1[0]) > EPSILON)
+ t = (hi[0] - xi1[0]) / (xi2[0] - xi1[0]);
+ else if (fabs(xi2[1] - xi1[1]) > EPSILON)
+ t = (hi[1] - xi1[1]) / (xi2[1] - xi1[1]);
+ else if (fabs(xi2[2] - xi1[2]) > EPSILON)
+ t = (hi[2] - xi1[2]) / (xi2[2] - xi1[2]);
+
+ double contact_dist = rounded_radius + x0_rounded_radius;
+ if (t >= 0 && t <= 1) {
+ mode = EDGE;
+ if (d < contact_dist + EPSILON)
+ contact = 1;
+
+ } else { // t < 0 || t > 1: closer to either vertices of the edge
+
+ if (t < 0) {
+ // measure the distance from x0 to xi1
+ delx = x0[0] - xi1[0];
+ dely = x0[1] - xi1[1];
+ delz = x0[2] - xi1[2];
+ double dx0xi1 = sqrt(delx*delx + dely*dely + delz*delz);
+ if (dx0xi1 > contact_dist + cut_inner)
+ mode = NONE;
+ else
+ mode = VERTEXI;
+ } else {
+ // measure the distance from x0 to xi2
+ delx = x0[0] - xi2[0];
+ dely = x0[1] - xi2[1];
+ delz = x0[2] - xi2[2];
+ double dx0xi2 = sqrt(delx*delx + dely*dely + delz*delz);
+ if (dx0xi2 > contact_dist + cut_inner)
+ mode = NONE;
+ else
+ mode = VERTEXJ;
+ }
+ } // end if t >= 0 && t <= 1
+ } // end if x0 and xmi are on the same side of the edge
+ }
+
+ return mode;
+}
+
+/* ----------------------------------------------------------------------
+ Compute contact forces between two bodies
+ modify the force stored at the vertex and edge in contact by j_a
+ sum forces and torque to the corresponding bodies
+ fn = normal friction component
+ ft = tangential friction component (-c_t * v_t)
+------------------------------------------------------------------------- */
+
+void PairBodyRoundedPolygon::contact_forces(Contact& contact, double j_a,
+ double** x, double** v, double** angmom, double** f,
+ double** torque, double &evdwl, double* facc)
+{
+ int ibody,jbody,ibonus,jbonus,ifirst,jefirst,ni,nj;
+ double fx,fy,fz,delx,dely,delz,rsq,rsqinv;
+ double vr1,vr2,vr3,vnnr,vn1,vn2,vn3,vt1,vt2,vt3;
+ double fn[3],ft[3],vi[3],vj[3];
+ double *quat, *inertia;
+ AtomVecBody::Bonus *bonus;
+
+ ibody = contact.ibody;
+ jbody = contact.jbody;
+
+ // compute the velocity of the vertex in the space-fixed frame
+
+ ibonus = atom->body[ibody];
+ bonus = &avec->bonus[ibonus];
+ quat = bonus->quat;
+ inertia = bonus->inertia;
+ total_velocity(contact.xv, x[ibody], v[ibody], angmom[ibody],
+ inertia, quat, vi);
+
+ // compute the velocity of the point on the edge in the space-fixed frame
+
+ jbonus = atom->body[jbody];
+ bonus = &avec->bonus[jbonus];
+ quat = bonus->quat;
+ inertia = bonus->inertia;
+ total_velocity(contact.xe, x[jbody], v[jbody], angmom[jbody],
+ inertia, quat, vj);
+
+ // vector pointing from the vertex to the point on the edge
+
+ delx = contact.xv[0] - contact.xe[0];
+ dely = contact.xv[1] - contact.xe[1];
+ delz = contact.xv[2] - contact.xe[2];
+ rsq = delx*delx + dely*dely + delz*delz;
+ rsqinv = 1.0/rsq;
+
+ // relative translational velocity
+
+ vr1 = vi[0] - vj[0];
+ vr2 = vi[1] - vj[1];
+ vr3 = vi[2] - vj[2];
+
+ // normal component
+
+ vnnr = vr1*delx + vr2*dely + vr3*delz;
+ vn1 = delx*vnnr * rsqinv;
+ vn2 = dely*vnnr * rsqinv;
+ vn3 = delz*vnnr * rsqinv;
+
+ // tangential component
+
+ vt1 = vr1 - vn1;
+ vt2 = vr2 - vn2;
+ vt3 = vr3 - vn3;
+
+ // normal friction term at contact
+
+ fn[0] = -c_n * vn1;
+ fn[1] = -c_n * vn2;
+ fn[2] = -c_n * vn3;
+
+ // tangential friction term at contact
+ // excluding the tangential deformation term for now
+
+ ft[0] = -c_t * vt1;
+ ft[1] = -c_t * vt2;
+ ft[2] = -c_t * vt3;
+
+ // only the cohesive force is scaled by j_a
+ // mu * fne = tangential friction deformation during gross sliding
+ // see Eq. 4, Fraige et al.
+
+ ifirst = dfirst[ibody];
+ ni = contact.vertex;
+
+ fx = discrete[ifirst+ni][3] * j_a + fn[0] + ft[0] +
+ mu * discrete[ifirst+ni][3];
+ fy = discrete[ifirst+ni][4] * j_a + fn[1] + ft[1] +
+ mu * discrete[ifirst+ni][4];
+ fz = discrete[ifirst+ni][5] * j_a + fn[2] + ft[2] +
+ mu * discrete[ifirst+ni][5];
+ f[ibody][0] += fx;
+ f[ibody][1] += fy;
+ f[ibody][2] += fz;
+ sum_torque(x[ibody], contact.xv, fx, fy, fz, torque[ibody]);
+
+ // accumulate forces to the vertex only
+
+ facc[0] += fx; facc[1] += fy; facc[2] += fz;
+
+ // only the cohesive force is scaled by j_a
+ // mu * fne = tangential friction deformation during gross sliding
+ // Eq. 4, Fraige et al.
+
+ jefirst = edfirst[jbody];
+ nj = contact.edge;
+
+ fx = edge[jefirst+nj][2] * j_a - fn[0] - ft[0] +
+ mu * edge[jefirst+nj][2];
+ fy = edge[jefirst+nj][3] * j_a - fn[1] - ft[1] +
+ mu * edge[jefirst+nj][3];
+ fz = edge[jefirst+nj][4] * j_a - fn[2] - ft[2] +
+ mu * edge[jefirst+nj][4];
+ f[jbody][0] += fx;
+ f[jbody][1] += fy;
+ f[jbody][2] += fz;
+ sum_torque(x[jbody], contact.xe, fx, fy, fz, torque[jbody]);
+
+ #ifdef _POLYGON_DEBUG
+ printf("From contact forces: vertex fx %f fy %f fz %f\n"
+ " torque body %d: %f %f %f\n"
+ " torque body %d: %f %f %f\n",
+ discrete[ifirst+ni][3], discrete[ifirst+ni][4], discrete[ifirst+ni][5],
+ atom->tag[ibody],torque[ibody][0],torque[ibody][1],torque[ibody][2],
+ atom->tag[jbody],torque[jbody][0],torque[jbody][1],torque[jbody][2]);
+ #endif
+}
+
+/* ----------------------------------------------------------------------
+ Determine the length of the contact segment, i.e. the separation between
+ 2 contacts, should be extended for 3D models.
+------------------------------------------------------------------------- */
+
+double PairBodyRoundedPolygon::contact_separation(const Contact& c1,
+ const Contact& c2)
+{
+ double x1 = c1.xv[0];
+ double y1 = c1.xv[1];
+ double x2 = c1.xe[0];
+ double y2 = c1.xe[1];
+ double x3 = c2.xv[0];
+ double y3 = c2.xv[1];
+
+ double delta_a = 0.0;
+ if (fabs(x2 - x1) > EPSILON) {
+ double A = (y2 - y1) / (x2 - x1);
+ delta_a = fabs(y1 - A * x1 - y3 + A * x3) / sqrt(1 + A * A);
+ } else {
+ delta_a = fabs(x1 - x3);
+ }
+
+ return delta_a;
+}
+
+/* ----------------------------------------------------------------------
+ Accumulate torque to body from the force f=(fx,fy,fz) acting at point x
+------------------------------------------------------------------------- */
+
+void PairBodyRoundedPolygon::sum_torque(double* xm, double *x, double fx,
+ double fy, double fz, double* torque)
+{
+ double rx = x[0] - xm[0];
+ double ry = x[1] - xm[1];
+ double rz = x[2] - xm[2];
+ double tx = ry * fz - rz * fy;
+ double ty = rz * fx - rx * fz;
+ double tz = rx * fy - ry * fx;
+ torque[0] += tx;
+ torque[1] += ty;
+ torque[2] += tz;
+}
+
+/* ----------------------------------------------------------------------
+ Test if two points a and b are in opposite sides of the line that
+ connects two points x1 and x2
+------------------------------------------------------------------------- */
+
+int PairBodyRoundedPolygon::opposite_sides(double* x1, double* x2,
+ double* a, double* b)
+{
+ double m_a = (x1[1] - x2[1])*(a[0] - x1[0]) + (x2[0] - x1[0])*(a[1] - x1[1]);
+ double m_b = (x1[1] - x2[1])*(b[0] - x1[0]) + (x2[0] - x1[0])*(b[1] - x1[1]);
+ // equal to zero when either a or b is inline with the line x1-x2
+ if (m_a * m_b <= 0)
+ return 1;
+ else
+ return 0;
+}
+
+/* ----------------------------------------------------------------------
+ Calculate the total velocity of a point (vertex, a point on an edge):
+ vi = vcm + omega ^ (p - xcm)
+------------------------------------------------------------------------- */
+
+void PairBodyRoundedPolygon::total_velocity(double* p, double *xcm,
+ double* vcm, double *angmom, double *inertia,
+ double *quat, double* vi)
+{
+ double r[3],omega[3],ex_space[3],ey_space[3],ez_space[3];
+ r[0] = p[0] - xcm[0];
+ r[1] = p[1] - xcm[1];
+ r[2] = p[2] - xcm[2];
+ MathExtra::q_to_exyz(quat,ex_space,ey_space,ez_space);
+ MathExtra::angmom_to_omega(angmom,ex_space,ey_space,ez_space,
+ inertia,omega);
+ vi[0] = omega[1]*r[2] - omega[2]*r[1] + vcm[0];
+ vi[1] = omega[2]*r[0] - omega[0]*r[2] + vcm[1];
+ vi[2] = omega[0]*r[1] - omega[1]*r[0] + vcm[2];
+}
+
+/* ---------------------------------------------------------------------- */
+
+void PairBodyRoundedPolygon::distance(const double* x2, const double* x1,
+ double& r)
+{
+ r = sqrt((x2[0] - x1[0]) * (x2[0] - x1[0])
+ + (x2[1] - x1[1]) * (x2[1] - x1[1])
+ + (x2[2] - x1[2]) * (x2[2] - x1[2]));
+}
+
diff --git a/src/BODY/pair_body_rounded_polygon.h b/src/BODY/pair_body_rounded_polygon.h
new file mode 100644
index 0000000000000000000000000000000000000000..aabe86270cd621a56836370130532cf42c93be59
--- /dev/null
+++ b/src/BODY/pair_body_rounded_polygon.h
@@ -0,0 +1,137 @@
+/* -*- c++ -*- ----------------------------------------------------------
+ LAMMPS - Large-scale Atomic/Molecular Massively Parallel Simulator
+ http://lammps.sandia.gov, Sandia National Laboratories
+ Steve Plimpton, sjplimp@sandia.gov
+
+ Copyright (2003) Sandia Corporation. Under the terms of Contract
+ DE-AC04-94AL85000 with Sandia Corporation, the U.S. Government retains
+ certain rights in this software. This software is distributed under
+ the GNU General Public License.
+
+ See the README file in the top-level LAMMPS directory.
+------------------------------------------------------------------------- */
+
+#ifdef PAIR_CLASS
+
+PairStyle(body/rounded/polygon,PairBodyRoundedPolygon)
+
+#else
+
+#ifndef LMP_PAIR_BODY_ROUNDED_POLYGON_H
+#define LMP_PAIR_BODY_ROUNDED_POLYGON_H
+
+#include "pair.h"
+
+namespace LAMMPS_NS {
+
+class PairBodyRoundedPolygon : public Pair {
+ public:
+ PairBodyRoundedPolygon(class LAMMPS *);
+ ~PairBodyRoundedPolygon();
+ void compute(int, int);
+ void settings(int, char **);
+ void coeff(int, char **);
+ void init_style();
+ double init_one(int, int);
+
+ struct Contact {
+ int ibody, jbody; // body (i.e. atom) indices (not tags)
+ int vertex; // vertex of the first polygon
+ int edge; // edge of the second polygon
+ double xv[3]; // coordinates of the vertex
+ double xe[3]; // coordinates of the projection of the vertex on the edge
+ double separation;// separation at contact
+ };
+
+ protected:
+ double **k_n; // normal repulsion strength
+ double **k_na; // normal attraction strength
+ double c_n; // normal damping coefficient
+ double c_t; // tangential damping coefficient
+ double mu; // normal friction coefficient during gross sliding
+ double delta_ua; // contact line (area for 3D models) modification factor
+ double cut_inner; // cutoff for interaction between vertex-edge surfaces
+
+ class AtomVecBody *avec;
+ class BodyRoundedPolygon *bptr;
+
+ double **discrete; // list of all sub-particles for all bodies
+ int ndiscrete; // number of discretes in list
+ int dmax; // allocated size of discrete list
+ int *dnum; // number of discretes per line, 0 if uninit
+ int *dfirst; // index of first discrete per each line
+ int nmax; // allocated size of dnum,dfirst vectors
+
+ double **edge; // list of all edge for all bodies
+ int nedge; // number of edge in list
+ int edmax; // allocated size of edge list
+ int *ednum; // number of edges per line, 0 if uninit
+ int *edfirst; // index of first edge per each line
+ int ednummax; // allocated size of ednum,edfirst vectors
+
+ double *enclosing_radius; // enclosing radii for all bodies
+ double *rounded_radius; // rounded radii for all bodies
+ double *maxerad; // per-type maximum enclosing radius
+
+ void allocate();
+ void body2space(int);
+
+ // sphere-sphere interaction
+ void sphere_against_sphere(int i, int j, double delx, double dely, double delz,
+ double rsq, double k_n, double k_na,
+ double** x, double** v, double** f, int evflag);
+ // vertex-edge interaction
+ int vertex_against_edge(int i, int j, double k_n, double k_na,
+ double** x, double** f, double** torque,
+ tagint* tag, Contact* contact_list,
+ int &num_contacts, double &evdwl, double* facc);
+ // compute distance between a point and an edge from another body
+ int compute_distance_to_vertex(int ibody, int edge_index, double* xmi,
+ double rounded_radius, double* x0,
+ double x0_rounded_radius, double cut_inner,
+ double &d, double hi[3], double &t,
+ int &contact);
+ // compute contact forces if contact points are detected
+ void contact_forces(Contact& contact, double j_a,
+ double** x, double** v, double** angmom, double** f,
+ double** torque, double &evdwl, double* facc);
+
+ // compute the separation between two contacts
+ double contact_separation(const Contact& c1, const Contact& c2);
+
+ // accumulate torque to a body given a force at a given point
+ void sum_torque(double* xm, double *x, double fx,
+ double fy, double fz, double* torque);
+ // helper functions
+ int opposite_sides(double* x1, double* x2, double* a, double* b);
+ void total_velocity(double* p, double *xcm, double* vcm, double *angmom,
+ double *inertia, double *quat, double* vi);
+ inline void distance(const double* x2, const double* x1, double& r);
+};
+
+}
+
+#endif
+#endif
+
+/* ERROR/WARNING messages:
+
+E: Illegal ... command
+
+Self-explanatory. Check the input script syntax and compare to the
+documentation for the command. You can use -echo screen as a
+command-line option when running LAMMPS to see the offending line.
+
+E: Incorrect args for pair coefficients
+
+Self-explanatory. Check the input script or data file.
+
+E: Pair body/rounded/polygon requires atom style body rounded/polygon
+
+Self-explanatory.
+
+E: Pair body requires body style rounded/polygon
+
+This pair style is specific to the rounded/polygon body style.
+
+*/
diff --git a/src/BODY/pair_body_rounded_polyhedron.cpp b/src/BODY/pair_body_rounded_polyhedron.cpp
new file mode 100644
index 0000000000000000000000000000000000000000..051be762e5a432193326596e6acbc3ad7bb9e616
--- /dev/null
+++ b/src/BODY/pair_body_rounded_polyhedron.cpp
@@ -0,0 +1,2389 @@
+/* ----------------------------------------------------------------------
+ LAMMPS - Large-scale Atomic/Molecular Massively Parallel Simulator
+ http://lammps.sandia.gov, Sandia National Laboratories
+ Steve Plimpton, sjplimp@sandia.gov
+
+ Copyright (2003) Sandia Corporation. Under the terms of Contract
+ DE-AC04-94AL85000 with Sandia Corporation, the U.S. Government retains
+ certain rights in this software. This software is distributed under
+ the GNU General Public License.
+
+ See the README file in the top-level LAMMPS directory.
+------------------------------------------------------------------------- */
+
+/* ----------------------------------------------------------------------
+ Contributing author: Trung Dac Nguyen (ndactrung@gmail.com)
+ Ref: Wang, Yu, Langston, Fraige, Particle shape effects in discrete
+ element modelling of cohesive angular particles, Granular Matter 2011,
+ 13:1-12.
+ Note: The current implementation has not taken into account
+ the contact history for friction forces.
+------------------------------------------------------------------------- */
+
+#include <cmath>
+#include <cstdio>
+#include <cstdlib>
+#include <cstring>
+#include "pair_body_rounded_polyhedron.h"
+#include "math_extra.h"
+#include "atom.h"
+#include "atom_vec_body.h"
+#include "body_rounded_polyhedron.h"
+#include "comm.h"
+#include "force.h"
+#include "fix.h"
+#include "modify.h"
+#include "neighbor.h"
+#include "neigh_list.h"
+#include "memory.h"
+#include "error.h"
+#include "math_extra.h"
+#include "math_const.h"
+
+using namespace LAMMPS_NS;
+using namespace MathExtra;
+using namespace MathConst;
+
+#define DELTA 10000
+#define EPSILON 1e-3
+#define MAX_FACE_SIZE 4 // maximum number of vertices per face (same as BodyRoundedPolyhedron)
+#define MAX_CONTACTS 32 // for 3D models (including duplicated counts)
+
+//#define _POLYHEDRON_DEBUG
+
+enum {EE_INVALID=0,EE_NONE,EE_INTERACT};
+enum {EF_INVALID=0,EF_NONE,EF_PARALLEL,EF_SAME_SIDE_OF_FACE,
+ EF_INTERSECT_INSIDE,EF_INTERSECT_OUTSIDE};
+
+/* ---------------------------------------------------------------------- */
+
+PairBodyRoundedPolyhedron::PairBodyRoundedPolyhedron(LAMMPS *lmp) : Pair(lmp)
+{
+ dmax = nmax = 0;
+ discrete = NULL;
+ dnum = dfirst = NULL;
+
+ edmax = ednummax = 0;
+ edge = NULL;
+ ednum = edfirst = NULL;
+
+ facmax = facnummax = 0;
+ face = NULL;
+ facnum = facfirst = NULL;
+
+ enclosing_radius = NULL;
+ rounded_radius = NULL;
+ maxerad = NULL;
+
+ single_enable = 0;
+ restartinfo = 0;
+
+ c_n = 0.1;
+ c_t = 0.2;
+ mu = 0.0;
+ A_ua = 1.0;
+
+ k_n = NULL;
+ k_na = NULL;
+}
+
+/* ---------------------------------------------------------------------- */
+
+PairBodyRoundedPolyhedron::~PairBodyRoundedPolyhedron()
+{
+ memory->destroy(discrete);
+ memory->destroy(dnum);
+ memory->destroy(dfirst);
+
+ memory->destroy(edge);
+ memory->destroy(ednum);
+ memory->destroy(edfirst);
+
+ memory->destroy(face);
+ memory->destroy(facnum);
+ memory->destroy(facfirst);
+
+ memory->destroy(enclosing_radius);
+ memory->destroy(rounded_radius);
+ memory->destroy(maxerad);
+
+ if (allocated) {
+ memory->destroy(setflag);
+ memory->destroy(cutsq);
+
+ memory->destroy(k_n);
+ memory->destroy(k_na);
+ }
+}
+
+/* ---------------------------------------------------------------------- */
+
+void PairBodyRoundedPolyhedron::compute(int eflag, int vflag)
+{
+ int i,j,ii,jj,inum,jnum,itype,jtype;
+ int ni,nj,npi,npj,ifirst,jfirst,nei,nej,iefirst,jefirst;
+ double xtmp,ytmp,ztmp,delx,dely,delz,evdwl,facc[3];
+ double rsq,eradi,eradj;
+ int *ilist,*jlist,*numneigh,**firstneigh;
+
+ evdwl = 0.0;
+ if (eflag || vflag) ev_setup(eflag,vflag);
+ else evflag = vflag_fdotr = 0;
+
+ double **x = atom->x;
+ double **v = atom->v;
+ double **f = atom->f;
+ double **torque = atom->torque;
+ double **angmom = atom->angmom;
+ int *body = atom->body;
+ int *type = atom->type;
+ int nlocal = atom->nlocal;
+ int nall = nlocal + atom->nghost;
+ int newton_pair = force->newton_pair;
+
+ inum = list->inum;
+ ilist = list->ilist;
+ numneigh = list->numneigh;
+ firstneigh = list->firstneigh;
+
+ // grow the per-atom lists if necessary and initialize
+
+ if (atom->nmax > nmax) {
+ memory->destroy(dnum);
+ memory->destroy(dfirst);
+ memory->destroy(ednum);
+ memory->destroy(edfirst);
+ memory->destroy(facnum);
+ memory->destroy(facfirst);
+ memory->destroy(enclosing_radius);
+ memory->destroy(rounded_radius);
+ nmax = atom->nmax;
+ memory->create(dnum,nmax,"pair:dnum");
+ memory->create(dfirst,nmax,"pair:dfirst");
+ memory->create(ednum,nmax,"pair:ednum");
+ memory->create(edfirst,nmax,"pair:edfirst");
+ memory->create(facnum,nmax,"pair:facnum");
+ memory->create(facfirst,nmax,"pair:facfirst");
+ memory->create(enclosing_radius,nmax,"pair:enclosing_radius");
+ memory->create(rounded_radius,nmax,"pair:rounded_radius");
+ }
+
+ ndiscrete = nedge = nface = 0;
+ for (i = 0; i < nall; i++)
+ dnum[i] = ednum[i] = facnum[i] = 0;
+
+ // loop over neighbors of my atoms
+
+ for (ii = 0; ii < inum; ii++) {
+ i = ilist[ii];
+ xtmp = x[i][0];
+ ytmp = x[i][1];
+ ztmp = x[i][2];
+ itype = type[i];
+ jlist = firstneigh[i];
+ jnum = numneigh[i];
+
+ if (body[i] >= 0) {
+ if (dnum[i] == 0) body2space(i);
+ npi = dnum[i];
+ ifirst = dfirst[i];
+ nei = ednum[i];
+ iefirst = edfirst[i];
+ eradi = enclosing_radius[i];
+ }
+
+ for (jj = 0; jj < jnum; jj++) {
+ j = jlist[jj];
+ j &= NEIGHMASK;
+
+ delx = xtmp - x[j][0];
+ dely = ytmp - x[j][1];
+ delz = ztmp - x[j][2];
+ rsq = delx*delx + dely*dely + delz*delz;
+ jtype = type[j];
+
+ // body/body interactions
+
+ evdwl = 0.0;
+ facc[0] = facc[1] = facc[2] = 0;
+
+ if (body[i] < 0 || body[j] < 0) continue;
+
+ if (dnum[j] == 0) body2space(j);
+ npj = dnum[j];
+ jfirst = dfirst[j];
+ nej = ednum[j];
+ jefirst = edfirst[j];
+ eradj = enclosing_radius[j];
+
+ // no interaction
+
+ double r = sqrt(rsq);
+ if (r > eradi + eradj + cut_inner) continue;
+
+ // sphere-sphere interaction
+
+ if (npi == 1 && npj == 1) {
+ sphere_against_sphere(i, j, itype, jtype, delx, dely, delz,
+ rsq, v, f, evflag);
+ continue;
+ }
+
+ // reset vertex and edge forces
+
+ for (ni = 0; ni < npi; ni++) {
+ discrete[ifirst+ni][3] = 0;
+ discrete[ifirst+ni][4] = 0;
+ discrete[ifirst+ni][5] = 0;
+ discrete[ifirst+ni][6] = 0;
+ }
+
+ for (nj = 0; nj < npj; nj++) {
+ discrete[jfirst+nj][3] = 0;
+ discrete[jfirst+nj][4] = 0;
+ discrete[jfirst+nj][5] = 0;
+ discrete[jfirst+nj][6] = 0;
+ }
+
+ for (ni = 0; ni < nei; ni++) {
+ edge[iefirst+ni][2] = 0;
+ edge[iefirst+ni][3] = 0;
+ edge[iefirst+ni][4] = 0;
+ edge[iefirst+ni][5] = 0;
+ }
+
+ for (nj = 0; nj < nej; nj++) {
+ edge[jefirst+nj][2] = 0;
+ edge[jefirst+nj][3] = 0;
+ edge[jefirst+nj][4] = 0;
+ edge[jefirst+nj][5] = 0;
+ }
+
+ // one of the two bodies is a sphere
+
+ if (npj == 1) {
+ sphere_against_face(i, j, itype, jtype, x, v, f, torque,
+ angmom, evflag);
+ sphere_against_edge(i, j, itype, jtype, x, v, f, torque,
+ angmom, evflag);
+ continue;
+ } else if (npi == 1) {
+ sphere_against_face(j, i, jtype, itype, x, v, f, torque,
+ angmom, evflag);
+ sphere_against_edge(j, i, jtype, itype, x, v, f, torque,
+ angmom, evflag);
+ continue;
+ }
+
+ int interact, num_contacts;
+ Contact contact_list[MAX_CONTACTS];
+
+ num_contacts = 0;
+
+ // check interaction between i's edges and j' faces
+ #ifdef _POLYHEDRON_DEBUG
+ printf("INTERACTION between edges of %d vs. faces of %d:\n", i, j);
+ #endif
+ interact = edge_against_face(i, j, itype, jtype, x, contact_list,
+ num_contacts, evdwl, facc);
+
+ // check interaction between j's edges and i' faces
+ #ifdef _POLYHEDRON_DEBUG
+ printf("\nINTERACTION between edges of %d vs. faces of %d:\n", j, i);
+ #endif
+ interact = edge_against_face(j, i, jtype, itype, x, contact_list,
+ num_contacts, evdwl, facc);
+
+ // check interaction between i's edges and j' edges
+ #ifdef _POLYHEDRON_DEBUG
+ printf("INTERACTION between edges of %d vs. edges of %d:\n", i, j);
+ #endif
+ interact = edge_against_edge(i, j, itype, jtype, x, contact_list,
+ num_contacts, evdwl, facc);
+
+ // estimate the contact area
+ // also consider point contacts and line contacts
+
+ if (num_contacts > 0) {
+ rescale_cohesive_forces(x, f, torque, contact_list, num_contacts,
+ itype, jtype, facc);
+ }
+
+ if (evflag) ev_tally_xyz(i,j,nlocal,newton_pair,evdwl,0.0,
+ facc[0],facc[1],facc[2],delx,dely,delz);
+
+ } // end for jj
+ }
+
+ if (vflag_fdotr) virial_fdotr_compute();
+}
+
+/* ----------------------------------------------------------------------
+ allocate all arrays
+------------------------------------------------------------------------- */
+
+void PairBodyRoundedPolyhedron::allocate()
+{
+ allocated = 1;
+ int n = atom->ntypes;
+
+ memory->create(setflag,n+1,n+1,"pair:setflag");
+ for (int i = 1; i <= n; i++)
+ for (int j = i; j <= n; j++)
+ setflag[i][j] = 0;
+
+ memory->create(cutsq,n+1,n+1,"pair:cutsq");
+
+ memory->create(k_n,n+1,n+1,"pair:k_n");
+ memory->create(k_na,n+1,n+1,"pair:k_na");
+ memory->create(maxerad,n+1,"pair:maxerad");
+}
+
+/* ----------------------------------------------------------------------
+ global settings
+------------------------------------------------------------------------- */
+
+void PairBodyRoundedPolyhedron::settings(int narg, char **arg)
+{
+ if (narg < 5) error->all(FLERR,"Illegal pair_style command");
+
+ c_n = force->numeric(FLERR,arg[0]);
+ c_t = force->numeric(FLERR,arg[1]);
+ mu = force->numeric(FLERR,arg[2]);
+ A_ua = force->numeric(FLERR,arg[3]);
+ cut_inner = force->numeric(FLERR,arg[4]);
+
+ if (A_ua < 0) A_ua = 1;
+}
+
+/* ----------------------------------------------------------------------
+ set coeffs for one or more type pairs
+------------------------------------------------------------------------- */
+
+void PairBodyRoundedPolyhedron::coeff(int narg, char **arg)
+{
+ if (narg < 4 || narg > 5)
+ error->all(FLERR,"Incorrect args for pair coefficients");
+ if (!allocated) allocate();
+
+ int ilo,ihi,jlo,jhi;
+ force->bounds(FLERR,arg[0],atom->ntypes,ilo,ihi);
+ force->bounds(FLERR,arg[1],atom->ntypes,jlo,jhi);
+
+ double k_n_one = force->numeric(FLERR,arg[2]);
+ double k_na_one = force->numeric(FLERR,arg[3]);
+
+ int count = 0;
+ for (int i = ilo; i <= ihi; i++) {
+ for (int j = MAX(jlo,i); j <= jhi; j++) {
+ k_n[i][j] = k_n_one;
+ k_na[i][j] = k_na_one;
+ setflag[i][j] = 1;
+ count++;
+ }
+ }
+
+ if (count == 0) error->all(FLERR,"Incorrect args for pair coefficients");
+}
+
+/* ----------------------------------------------------------------------
+ init specific to this pair style
+------------------------------------------------------------------------- */
+
+void PairBodyRoundedPolyhedron::init_style()
+{
+ avec = (AtomVecBody *) atom->style_match("body");
+ if (!avec) error->all(FLERR,"Pair body/rounded/polyhedron requires "
+ "atom style body");
+ if (strcmp(avec->bptr->style,"rounded/polyhedron") != 0)
+ error->all(FLERR,"Pair body/rounded/polyhedron requires "
+ "body style rounded/polyhedron");
+ bptr = (BodyRoundedPolyhedron *) avec->bptr;
+
+ if (force->newton_pair == 0)
+ error->all(FLERR,"Pair style body/rounded/polyhedron requires "
+ "newton pair on");
+
+ if (comm->ghost_velocity == 0)
+ error->all(FLERR,"Pair body/rounded/polyhedron requires "
+ "ghost atoms store velocity");
+
+ neighbor->request(this);
+
+ // find the maximum enclosing radius for each atom type
+
+ int i, itype;
+ double eradi;
+ int* body = atom->body;
+ int* type = atom->type;
+ int ntypes = atom->ntypes;
+ int nlocal = atom->nlocal;
+
+ if (atom->nmax > nmax) {
+ memory->destroy(dnum);
+ memory->destroy(dfirst);
+ memory->destroy(ednum);
+ memory->destroy(edfirst);
+ memory->destroy(facnum);
+ memory->destroy(facfirst);
+ memory->destroy(enclosing_radius);
+ memory->destroy(rounded_radius);
+ nmax = atom->nmax;
+ memory->create(dnum,nmax,"pair:dnum");
+ memory->create(dfirst,nmax,"pair:dfirst");
+ memory->create(ednum,nmax,"pair:ednum");
+ memory->create(edfirst,nmax,"pair:edfirst");
+ memory->create(facnum,nmax,"pair:facnum");
+ memory->create(facfirst,nmax,"pair:facfirst");
+ memory->create(enclosing_radius,nmax,"pair:enclosing_radius");
+ memory->create(rounded_radius,nmax,"pair:rounded_radius");
+ }
+
+ ndiscrete = nedge = nface = 0;
+ for (i = 0; i < nlocal; i++)
+ dnum[i] = ednum[i] = facnum[i] = 0;
+
+ double *merad = NULL;
+ memory->create(merad,ntypes+1,"pair:merad");
+ for (i = 1; i <= ntypes; i++)
+ maxerad[i] = merad[i] = 0;
+
+ int ipour;
+ for (ipour = 0; ipour < modify->nfix; ipour++)
+ if (strcmp(modify->fix[ipour]->style,"pour") == 0) break;
+ if (ipour == modify->nfix) ipour = -1;
+
+ int idep;
+ for (idep = 0; idep < modify->nfix; idep++)
+ if (strcmp(modify->fix[idep]->style,"deposit") == 0) break;
+ if (idep == modify->nfix) idep = -1;
+
+ for (i = 1; i <= ntypes; i++) {
+ merad[i] = 0.0;
+ if (ipour >= 0) {
+ itype = i;
+ merad[i] =
+ *((double *) modify->fix[ipour]->extract("radius",itype));
+ }
+ if (idep >= 0) {
+ itype = i;
+ merad[i] =
+ *((double *) modify->fix[idep]->extract("radius",itype));
+ }
+ }
+
+ for (i = 0; i < nlocal; i++) {
+ itype = type[i];
+ if (body[i] >= 0) {
+ if (dnum[i] == 0) body2space(i);
+ eradi = enclosing_radius[i];
+ if (eradi > merad[itype]) merad[itype] = eradi;
+ } else
+ merad[itype] = 0;
+ }
+
+ MPI_Allreduce(&merad[1],&maxerad[1],ntypes,MPI_DOUBLE,MPI_MAX,world);
+
+ memory->destroy(merad);
+
+ sanity_check();
+}
+
+/* ----------------------------------------------------------------------
+ init for one type pair i,j and corresponding j,i
+------------------------------------------------------------------------- */
+
+double PairBodyRoundedPolyhedron::init_one(int i, int j)
+{
+ k_n[j][i] = k_n[i][j];
+ k_na[j][i] = k_na[i][j];
+
+ return (maxerad[i]+maxerad[j]);
+}
+
+/* ----------------------------------------------------------------------
+ convert N sub-particles in body I to space frame using current quaternion
+ store sub-particle space-frame displacements from COM in discrete list
+------------------------------------------------------------------------- */
+
+void PairBodyRoundedPolyhedron::body2space(int i)
+{
+ int ibonus = atom->body[i];
+ AtomVecBody::Bonus *bonus = &avec->bonus[ibonus];
+ int nsub = bptr->nsub(bonus);
+ double *coords = bptr->coords(bonus);
+ int body_num_edges = bptr->nedges(bonus);
+ double* edge_ends = bptr->edges(bonus);
+ int body_num_faces = bptr->nfaces(bonus);
+ double* face_pts = bptr->faces(bonus);
+ double eradius = bptr->enclosing_radius(bonus);
+ double rradius = bptr->rounded_radius(bonus);
+
+ // get the number of sub-particles (vertices)
+ // and the index of the first vertex of my body in the list
+
+ dnum[i] = nsub;
+ dfirst[i] = ndiscrete;
+
+ // grow the vertex list if necessary
+ // the first 3 columns are for coords, the last 3 for forces
+
+ if (ndiscrete + nsub > dmax) {
+ dmax += DELTA;
+ memory->grow(discrete,dmax,7,"pair:discrete");
+ }
+
+ double p[3][3];
+ MathExtra::quat_to_mat(bonus->quat,p);
+
+ for (int m = 0; m < nsub; m++) {
+ MathExtra::matvec(p,&coords[3*m],discrete[ndiscrete]);
+ discrete[ndiscrete][3] = 0;
+ discrete[ndiscrete][4] = 0;
+ discrete[ndiscrete][5] = 0;
+ discrete[ndiscrete][6] = 0;
+ ndiscrete++;
+ }
+
+ // get the number of edges (vertices)
+ // and the index of the first edge of my body in the list
+
+ ednum[i] = body_num_edges;
+ edfirst[i] = nedge;
+
+ // grow the edge list if necessary
+ // the first 2 columns are for vertex indices within body, the last 3 for forces
+
+ if (nedge + body_num_edges > edmax) {
+ edmax += DELTA;
+ memory->grow(edge,edmax,6,"pair:edge");
+ }
+
+ for (int m = 0; m < body_num_edges; m++) {
+ edge[nedge][0] = static_cast<int>(edge_ends[2*m+0]);
+ edge[nedge][1] = static_cast<int>(edge_ends[2*m+1]);
+ edge[nedge][2] = 0;
+ edge[nedge][3] = 0;
+ edge[nedge][4] = 0;
+ edge[nedge][5] = 0;
+ nedge++;
+ }
+
+ // get the number of faces and the index of the first face
+
+ facnum[i] = body_num_faces;
+ facfirst[i] = nface;
+
+ // grow the face list if necessary
+ // the first 3 columns are for vertex indices within body, the last 3 for forces
+
+ if (nface + body_num_faces > facmax) {
+ facmax += DELTA;
+ memory->grow(face,facmax,MAX_FACE_SIZE,"pair:face");
+ }
+
+ for (int m = 0; m < body_num_faces; m++) {
+ for (int k = 0; k < MAX_FACE_SIZE; k++)
+ face[nface][k] = static_cast<int>(face_pts[MAX_FACE_SIZE*m+k]);
+ nface++;
+ }
+
+ enclosing_radius[i] = eradius;
+ rounded_radius[i] = rradius;
+}
+
+/* ----------------------------------------------------------------------
+ Interaction between two spheres with different radii
+ according to the 2D model from Fraige et al.
+---------------------------------------------------------------------- */
+
+void PairBodyRoundedPolyhedron::sphere_against_sphere(int ibody, int jbody,
+ int itype, int jtype, double delx, double dely, double delz, double rsq,
+ double** v, double** f, int evflag)
+{
+ double rradi,rradj,contact_dist;
+ double vr1,vr2,vr3,vnnr,vn1,vn2,vn3,vt1,vt2,vt3;
+ double rij,rsqinv,R,fx,fy,fz,fn[3],ft[3],fpair,shift,energy;
+ int nlocal = atom->nlocal;
+ int newton_pair = force->newton_pair;
+
+ rradi = rounded_radius[ibody];
+ rradj = rounded_radius[jbody];
+ contact_dist = rradi + rradj;
+
+ rij = sqrt(rsq);
+ R = rij - contact_dist;
+
+ energy = 0;
+ kernel_force(R, itype, jtype, energy, fpair);
+
+ fx = delx*fpair/rij;
+ fy = dely*fpair/rij;
+ fz = delz*fpair/rij;
+
+ if (R <= 0) { // in contact
+
+ // relative translational velocity
+
+ vr1 = v[ibody][0] - v[jbody][0];
+ vr2 = v[ibody][1] - v[jbody][1];
+ vr3 = v[ibody][2] - v[jbody][2];
+
+ // normal component
+
+ rsqinv = 1.0/rsq;
+ vnnr = vr1*delx + vr2*dely + vr3*delz;
+ vn1 = delx*vnnr * rsqinv;
+ vn2 = dely*vnnr * rsqinv;
+ vn3 = delz*vnnr * rsqinv;
+
+ // tangential component
+
+ vt1 = vr1 - vn1;
+ vt2 = vr2 - vn2;
+ vt3 = vr3 - vn3;
+
+ // normal friction term at contact
+
+ fn[0] = -c_n * vn1;
+ fn[1] = -c_n * vn2;
+ fn[2] = -c_n * vn3;
+
+ // tangential friction term at contact,
+ // excluding the tangential deformation term for now
+
+ ft[0] = -c_t * vt1;
+ ft[1] = -c_t * vt2;
+ ft[2] = -c_t * vt3;
+
+ fx += fn[0] + ft[0];
+ fy += fn[1] + ft[1];
+ fz += fn[2] + ft[2];
+ }
+
+ f[ibody][0] += fx;
+ f[ibody][1] += fy;
+ f[ibody][2] += fz;
+
+ if (newton_pair || jbody < nlocal) {
+ f[jbody][0] -= fx;
+ f[jbody][1] -= fy;
+ f[jbody][2] -= fz;
+ }
+
+ if (evflag) ev_tally_xyz(ibody,jbody,nlocal,newton_pair,
+ energy,0.0,fx,fy,fz,delx,dely,delz);
+}
+
+/* ----------------------------------------------------------------------
+ Interaction bt the edges of a polyhedron (ibody) and a sphere (jbody)
+---------------------------------------------------------------------- */
+
+void PairBodyRoundedPolyhedron::sphere_against_edge(int ibody, int jbody,
+ int itype, int jtype, double** x, double** v, double** f, double** torque,
+ double** angmom, int evflag)
+{
+ int ni,nei,ifirst,iefirst,npi1,npi2,ibonus;
+ double xi1[3],xi2[3],vti[3],h[3],fn[3],ft[3],d,t;
+ double delx,dely,delz,rsq,rij,rsqinv,R,fx,fy,fz,fpair,shift,energy;
+ double rradi,rradj,contact_dist;
+ double vr1,vr2,vr3,vnnr,vn1,vn2,vn3,vt1,vt2,vt3;
+ double *quat, *inertia;
+ AtomVecBody::Bonus *bonus;
+
+ int nlocal = atom->nlocal;
+ int newton_pair = force->newton_pair;
+
+ ifirst = dfirst[ibody];
+ iefirst = edfirst[ibody];
+ nei = ednum[ibody];
+
+ rradi = rounded_radius[ibody];
+ rradj = rounded_radius[jbody];
+ contact_dist = rradi + rradj;
+
+ for (ni = 0; ni < nei; ni++) {
+
+ npi1 = static_cast<int>(edge[iefirst+ni][0]);
+ npi2 = static_cast<int>(edge[iefirst+ni][1]);
+
+ // compute the space-fixed coordinates for the vertices of the face
+
+ xi1[0] = x[ibody][0] + discrete[ifirst+npi1][0];
+ xi1[1] = x[ibody][1] + discrete[ifirst+npi1][1];
+ xi1[2] = x[ibody][2] + discrete[ifirst+npi1][2];
+
+ xi2[0] = x[ibody][0] + discrete[ifirst+npi2][0];
+ xi2[1] = x[ibody][1] + discrete[ifirst+npi2][1];
+ xi2[2] = x[ibody][2] + discrete[ifirst+npi2][2];
+
+ // find the projection of the jbody's COM on the edge
+
+ project_pt_line(x[jbody], xi1, xi2, h, d, t);
+
+ if (d > contact_dist + cut_inner) continue;
+ if (t < 0 || t > 1) continue;
+
+ if (fabs(t) < EPSILON) {
+ if (static_cast<int>(discrete[ifirst+npi1][6]) == 1)
+ continue;
+ else {
+ h[0] = xi1[0];
+ h[1] = xi1[1];
+ h[2] = xi1[2];
+ discrete[ifirst+npi1][6] = 1;
+ }
+ }
+
+ if (fabs(t-1) < EPSILON) {
+ if (static_cast<int>(discrete[ifirst+npi2][6]) == 1)
+ continue;
+ else {
+ h[0] = xi2[0];
+ h[1] = xi2[1];
+ h[2] = xi2[2];
+ discrete[ifirst+npi2][6] = 1;
+ }
+ }
+
+ delx = h[0] - x[jbody][0];
+ dely = h[1] - x[jbody][1];
+ delz = h[2] - x[jbody][2];
+ rsq = delx*delx + dely*dely + delz*delz;
+ rsqinv = (rsq == 0.0) ? 0.0 : 1.0/rsq;
+ rij = sqrt(rsq);
+ R = rij - contact_dist;
+
+ energy = 0;
+ kernel_force(R, itype, jtype, energy, fpair);
+
+ fx = delx*fpair/rij;
+ fy = dely*fpair/rij;
+ fz = delz*fpair/rij;
+
+ if (R <= 0) { // in contact
+
+ // compute the velocity of the vertex in the space-fixed frame
+
+ ibonus = atom->body[ibody];
+ bonus = &avec->bonus[ibonus];
+ quat = bonus->quat;
+ inertia = bonus->inertia;
+ total_velocity(h, x[ibody], v[ibody], angmom[ibody],
+ inertia, quat, vti);
+
+ // relative translational velocity
+
+ vr1 = vti[0] - v[jbody][0];
+ vr2 = vti[1] - v[jbody][1];
+ vr3 = vti[2] - v[jbody][2];
+
+ // normal component
+
+ vnnr = vr1*delx + vr2*dely + vr3*delz;
+ vn1 = delx*vnnr * rsqinv;
+ vn2 = dely*vnnr * rsqinv;
+ vn3 = delz*vnnr * rsqinv;
+
+ // tangential component
+
+ vt1 = vr1 - vn1;
+ vt2 = vr2 - vn2;
+ vt3 = vr3 - vn3;
+
+ // normal friction term at contact
+
+ fn[0] = -c_n * vn1;
+ fn[1] = -c_n * vn2;
+ fn[2] = -c_n * vn3;
+
+ // tangential friction term at contact,
+ // excluding the tangential deformation term
+
+ ft[0] = -c_t * vt1;
+ ft[1] = -c_t * vt2;
+ ft[2] = -c_t * vt3;
+
+ fx += fn[0] + ft[0];
+ fy += fn[1] + ft[1];
+ fz += fn[2] + ft[2];
+ }
+
+ f[ibody][0] += fx;
+ f[ibody][1] += fy;
+ f[ibody][2] += fz;
+ sum_torque(x[ibody], h, fx, fy, fz, torque[ibody]);
+
+ if (newton_pair || jbody < nlocal) {
+ f[jbody][0] -= fx;
+ f[jbody][1] -= fy;
+ f[jbody][2] -= fz;
+ }
+
+ if (evflag) ev_tally_xyz(ibody,jbody,nlocal,newton_pair,
+ energy,0.0,fx,fy,fz,delx,dely,delz);
+ }
+}
+
+/* ----------------------------------------------------------------------
+ Interaction bt the faces of a polyhedron (ibody) and a sphere (jbody)
+---------------------------------------------------------------------- */
+
+void PairBodyRoundedPolyhedron::sphere_against_face(int ibody, int jbody,
+ int itype, int jtype, double** x, double** v, double** f, double** torque,
+ double** angmom, int evflag)
+{
+ int ni,nfi,inside,ifirst,iffirst,npi1,npi2,npi3,ibonus,tmp;
+ double xi1[3],xi2[3],xi3[3],ui[3],vi[3],vti[3],n[3],h[3],fn[3],ft[3],d;
+ double delx,dely,delz,rsq,rij,rsqinv,R,fx,fy,fz,fpair,shift,energy;
+ double rradi,rradj,contact_dist;
+ double vr1,vr2,vr3,vnnr,vn1,vn2,vn3,vt1,vt2,vt3;
+ double *quat, *inertia;
+ AtomVecBody::Bonus *bonus;
+
+ int nlocal = atom->nlocal;
+ int newton_pair = force->newton_pair;
+
+ ifirst = dfirst[ibody];
+ iffirst = facfirst[ibody];
+ nfi = facnum[ibody];
+
+ rradi = rounded_radius[ibody];
+ rradj = rounded_radius[jbody];
+ contact_dist = rradi + rradj;
+
+ for (ni = 0; ni < nfi; ni++) {
+
+ npi1 = static_cast<int>(face[iffirst+ni][0]);
+ npi2 = static_cast<int>(face[iffirst+ni][1]);
+ npi3 = static_cast<int>(face[iffirst+ni][2]);
+
+ // compute the space-fixed coordinates for the vertices of the face
+
+ xi1[0] = x[ibody][0] + discrete[ifirst+npi1][0];
+ xi1[1] = x[ibody][1] + discrete[ifirst+npi1][1];
+ xi1[2] = x[ibody][2] + discrete[ifirst+npi1][2];
+
+ xi2[0] = x[ibody][0] + discrete[ifirst+npi2][0];
+ xi2[1] = x[ibody][1] + discrete[ifirst+npi2][1];
+ xi2[2] = x[ibody][2] + discrete[ifirst+npi2][2];
+
+ xi3[0] = x[ibody][0] + discrete[ifirst+npi3][0];
+ xi3[1] = x[ibody][1] + discrete[ifirst+npi3][1];
+ xi3[2] = x[ibody][2] + discrete[ifirst+npi3][2];
+
+ // find the normal unit vector of the face
+
+ MathExtra::sub3(xi2, xi1, ui);
+ MathExtra::sub3(xi3, xi1, vi);
+ MathExtra::cross3(ui, vi, n);
+ MathExtra::norm3(n);
+
+ // skip if the COM of the two bodies are in the same side of the face
+
+ if (opposite_sides(n, xi1, x[ibody], x[jbody]) == 0) continue;
+
+ // find the projection of the sphere on the face
+
+ project_pt_plane(x[jbody], xi1, xi2, xi3, h, d, inside);
+
+ inside_polygon(ibody, ni, x[ibody], h, NULL, inside, tmp);
+ if (inside == 0) continue;
+
+ delx = h[0] - x[jbody][0];
+ dely = h[1] - x[jbody][1];
+ delz = h[2] - x[jbody][2];
+ rsq = delx*delx + dely*dely + delz*delz;
+ rij = sqrt(rsq);
+ R = rij - contact_dist;
+
+ energy = 0;
+ kernel_force(R, itype, jtype, energy, fpair);
+
+ fx = delx*fpair/rij;
+ fy = dely*fpair/rij;
+ fz = delz*fpair/rij;
+
+ if (R <= 0) { // in contact
+
+ // compute the velocity of the vertex in the space-fixed frame
+
+ ibonus = atom->body[ibody];
+ bonus = &avec->bonus[ibonus];
+ quat = bonus->quat;
+ inertia = bonus->inertia;
+ total_velocity(h, x[ibody], v[ibody], angmom[ibody],
+ inertia, quat, vti);
+
+ // relative translational velocity
+
+ vr1 = vti[0] - v[jbody][0];
+ vr2 = vti[1] - v[jbody][1];
+ vr3 = vti[2] - v[jbody][2];
+
+ // normal component
+
+ rsqinv = 1.0/rsq;
+ vnnr = vr1*delx + vr2*dely + vr3*delz;
+ vn1 = delx*vnnr * rsqinv;
+ vn2 = dely*vnnr * rsqinv;
+ vn3 = delz*vnnr * rsqinv;
+
+ // tangential component
+
+ vt1 = vr1 - vn1;
+ vt2 = vr2 - vn2;
+ vt3 = vr3 - vn3;
+
+ // normal friction term at contact
+
+ fn[0] = -c_n * vn1;
+ fn[1] = -c_n * vn2;
+ fn[2] = -c_n * vn3;
+
+ // tangential friction term at contact,
+ // excluding the tangential deformation term for now
+
+ ft[0] = -c_t * vt1;
+ ft[1] = -c_t * vt2;
+ ft[2] = -c_t * vt3;
+
+ fx += fn[0] + ft[0];
+ fy += fn[1] + ft[1];
+ fz += fn[2] + ft[2];
+ }
+
+ f[ibody][0] += fx;
+ f[ibody][1] += fy;
+ f[ibody][2] += fz;
+ sum_torque(x[ibody], h, fx, fy, fz, torque[ibody]);
+
+ if (newton_pair || jbody < nlocal) {
+ f[jbody][0] -= fx;
+ f[jbody][1] -= fy;
+ f[jbody][2] -= fz;
+ }
+
+ if (evflag) ev_tally_xyz(ibody,jbody,nlocal,newton_pair,
+ energy,0.0,fx,fy,fz,delx,dely,delz);
+ }
+}
+
+/* ----------------------------------------------------------------------
+ Determine the interaction mode between i's edges against j's edges
+
+ i = atom i (body i)
+ j = atom j (body j)
+ x = atoms' coordinates
+ f = atoms' forces
+ torque = atoms' torques
+ tag = atoms' tags
+ contact_list = list of contacts
+ num_contacts = number of contacts between i's edges and j's edges
+ Return:
+
+---------------------------------------------------------------------- */
+
+int PairBodyRoundedPolyhedron::edge_against_edge(int ibody, int jbody,
+ int itype, int jtype, double** x, Contact* contact_list, int &num_contacts,
+ double &evdwl, double* facc)
+{
+ int ni,nei,nj,nej,contact,interact;
+ double rradi,rradj,energy;
+
+ nei = ednum[ibody];
+ rradi = rounded_radius[ibody];
+ nej = ednum[jbody];
+ rradj = rounded_radius[jbody];
+
+ energy = 0;
+ interact = EE_NONE;
+
+ // loop through body i's edges
+
+ for (ni = 0; ni < nei; ni++) {
+
+ for (nj = 0; nj < nej; nj++) {
+
+ // compute the distance between the edge nj to the edge ni
+ #ifdef _POLYHEDRON_DEBUG
+ printf("Compute interaction between edge %d of body %d "
+ "with edge %d of body %d:\n",
+ nj, jbody, ni, ibody);
+ #endif
+
+ interact = interaction_edge_to_edge(ibody, ni, x[ibody], rradi,
+ jbody, nj, x[jbody], rradj,
+ itype, jtype, cut_inner,
+ contact_list, num_contacts,
+ energy, facc);
+ }
+
+ } // end for looping through the edges of body i
+
+ evdwl += energy;
+
+ return interact;
+}
+
+/* ----------------------------------------------------------------------
+ Determine the interaction mode between i's edges against j's faces
+
+ i = atom i (body i)
+ j = atom j (body j)
+ x = atoms' coordinates
+ f = atoms' forces
+ torque = atoms' torques
+ tag = atoms' tags
+ contact_list = list of contacts
+ num_contacts = number of contacts between i's edges and j's faces
+ Return:
+
+---------------------------------------------------------------------- */
+
+int PairBodyRoundedPolyhedron::edge_against_face(int ibody, int jbody,
+ int itype, int jtype, double** x, Contact* contact_list, int &num_contacts,
+ double &evdwl, double* facc)
+{
+ int ni,nei,nj,nfj,contact,interact;
+ double rradi,rradj,energy;
+
+ nei = ednum[ibody];
+ rradi = rounded_radius[ibody];
+ nfj = facnum[jbody];
+ rradj = rounded_radius[jbody];
+
+ energy = 0;
+ interact = EF_NONE;
+
+ // loop through body i's edges
+
+ for (ni = 0; ni < nei; ni++) {
+
+ // loop through body j's faces
+
+ for (nj = 0; nj < nfj; nj++) {
+
+ // compute the distance between the face nj to the edge ni
+ #ifdef _POLYHEDRON_DEBUG
+ printf("Compute interaction between face %d of body %d with "
+ "edge %d of body %d:\n",
+ nj, jbody, ni, ibody);
+ #endif
+
+ interact = interaction_face_to_edge(jbody, nj, x[jbody], rradj,
+ ibody, ni, x[ibody], rradi,
+ itype, jtype, cut_inner,
+ contact_list, num_contacts,
+ energy, facc);
+ }
+
+ } // end for looping through the edges of body i
+
+ evdwl += energy;
+
+ return interact;
+}
+
+/* -------------------------------------------------------------------------
+ Compute the distance between an edge of body i and an edge from
+ another body
+ Input:
+ ibody = body i (i.e. atom i)
+ face_index = face index of body i
+ xmi = atom i's coordinates (body i's center of mass)
+ rounded_radius_i = rounded radius of the body i
+ jbody = body i (i.e. atom j)
+ edge_index = coordinate of the tested edge from another body
+ xmj = atom j's coordinates (body j's center of mass)
+ rounded_radius_j = rounded radius of the body j
+ cut_inner = cutoff for vertex-vertex and vertex-edge interaction
+ Output:
+ d = Distance from a point x0 to an edge
+ hi = coordinates of the projection of x0 on the edge
+
+ contact = 0 no contact between the queried edge and the face
+ 1 contact detected
+ return
+ INVALID if the face index is invalid
+ NONE if there is no interaction
+------------------------------------------------------------------------- */
+
+int PairBodyRoundedPolyhedron::interaction_edge_to_edge(int ibody,
+ int edge_index_i, double *xmi, double rounded_radius_i,
+ int jbody, int edge_index_j, double *xmj, double rounded_radius_j,
+ int itype, int jtype, double cut_inner,
+ Contact* contact_list, int &num_contacts, double &energy, double* facc)
+{
+ int ifirst,iefirst,jfirst,jefirst,npi1,npi2,npj1,npj2,interact;
+ double xi1[3],xi2[3],xpj1[3],xpj2[3];
+ double r,t1,t2,h1[3],h2[3];
+ double contact_dist, shift;
+
+ double** x = atom->x;
+ double** v = atom->v;
+ double** f = atom->f;
+ double** torque = atom->torque;
+ double** angmom = atom->angmom;
+
+ ifirst = dfirst[ibody];
+ iefirst = edfirst[ibody];
+ npi1 = static_cast<int>(edge[iefirst+edge_index_i][0]);
+ npi2 = static_cast<int>(edge[iefirst+edge_index_i][1]);
+
+ // compute the space-fixed coordinates for the edge ends
+
+ xi1[0] = xmi[0] + discrete[ifirst+npi1][0];
+ xi1[1] = xmi[1] + discrete[ifirst+npi1][1];
+ xi1[2] = xmi[2] + discrete[ifirst+npi1][2];
+
+ xi2[0] = xmi[0] + discrete[ifirst+npi2][0];
+ xi2[1] = xmi[1] + discrete[ifirst+npi2][1];
+ xi2[2] = xmi[2] + discrete[ifirst+npi2][2];
+
+ // two ends of the edge from body j
+
+ jfirst = dfirst[jbody];
+ jefirst = edfirst[jbody];
+ npj1 = static_cast<int>(edge[jefirst+edge_index_j][0]);
+ npj2 = static_cast<int>(edge[jefirst+edge_index_j][1]);
+
+ xpj1[0] = xmj[0] + discrete[jfirst+npj1][0];
+ xpj1[1] = xmj[1] + discrete[jfirst+npj1][1];
+ xpj1[2] = xmj[2] + discrete[jfirst+npj1][2];
+
+ xpj2[0] = xmj[0] + discrete[jfirst+npj2][0];
+ xpj2[1] = xmj[1] + discrete[jfirst+npj2][1];
+ xpj2[2] = xmj[2] + discrete[jfirst+npj2][2];
+
+ contact_dist = rounded_radius_i + rounded_radius_j;
+
+ int jflag = 1;
+ distance_bt_edges(xpj1, xpj2, xi1, xi2, h1, h2, t1, t2, r);
+
+ #ifdef _POLYHEDRON_DEBUG
+ double ui[3],uj[3];
+ MathExtra::sub3(xi1,xi2,ui);
+ MathExtra::norm3(ui);
+ MathExtra::sub3(xpj1,xpj2,uj);
+ MathExtra::norm3(uj);
+ double dot = MathExtra::dot3(ui, uj);
+ printf(" edge npi1 = %d (%f %f %f); npi2 = %d (%f %f %f) vs."
+ " edge npj1 = %d (%f %f %f); npj2 = %d (%f %f %f): "
+ "t1 = %f; t2 = %f; r = %f; dot = %f\n",
+ npi1, xi1[0], xi1[1], xi1[2], npi2, xi2[0], xi2[1], xi2[2],
+ npj1, xpj1[0], xpj1[1], xpj1[2], npj2, xpj2[0], xpj2[1], xpj2[2],
+ t1, t2, r, dot);
+ #endif
+
+ interact = EE_NONE;
+
+ // singularity case, ignore interactions
+
+ if (r < EPSILON) return interact;
+
+ // include the vertices for interactions
+
+ if (t1 >= 0 && t1 <= 1 && t2 >= 0 && t2 <= 1 &&
+ r < contact_dist + cut_inner) {
+ pair_force_and_torque(jbody, ibody, h1, h2, r, contact_dist,
+ jtype, itype, x, v, f, torque, angmom,
+ jflag, energy, facc);
+
+ interact = EE_INTERACT;
+ if (r <= contact_dist) {
+ // store the contact info
+ contact_list[num_contacts].ibody = ibody;
+ contact_list[num_contacts].jbody = jbody;
+ contact_list[num_contacts].xi[0] = h2[0];
+ contact_list[num_contacts].xi[1] = h2[1];
+ contact_list[num_contacts].xi[2] = h2[2];
+ contact_list[num_contacts].xj[0] = h1[0];
+ contact_list[num_contacts].xj[1] = h1[1];
+ contact_list[num_contacts].xj[2] = h1[2];
+ contact_list[num_contacts].type = 1;
+ contact_list[num_contacts].separation = r - contact_dist;
+ contact_list[num_contacts].unique = 1;
+ num_contacts++;
+ }
+ } else {
+
+ }
+
+ return interact;
+}
+
+/* -------------------------------------------------------------------------
+ Compute the interaction between a face of body i and an edge from
+ another body
+ Input:
+ ibody = body i (i.e. atom i)
+ face_index = face index of body i
+ xmi = atom i's coordinates (body i's center of mass)
+ rounded_radius_i = rounded radius of the body i
+ jbody = body i (i.e. atom j)
+ edge_index = coordinate of the tested edge from another body
+ xmj = atom j's coordinates (body j's center of mass)
+ rounded_radius_j = rounded radius of the body j
+ cut_inner = cutoff for vertex-vertex and vertex-edge interaction
+ Output:
+ d = Distance from a point x0 to an edge
+ hi = coordinates of the projection of x0 on the edge
+
+ contact = 0 no contact between the queried edge and the face
+ 1 contact detected
+ return
+ INVALID if the face index is invalid
+ NONE if there is no interaction
+------------------------------------------------------------------------- */
+
+int PairBodyRoundedPolyhedron::interaction_face_to_edge(int ibody,
+ int face_index, double *xmi, double rounded_radius_i,
+ int jbody, int edge_index, double *xmj, double rounded_radius_j,
+ int itype, int jtype, double cut_inner,
+ Contact* contact_list, int &num_contacts, double &energy, double* facc)
+{
+ if (face_index >= facnum[ibody]) return EF_INVALID;
+
+ int ifirst,iffirst,jfirst,npi1,npi2,npi3;
+ int jefirst,npj1,npj2;
+ double xi1[3],xi2[3],xi3[3],xpj1[3],xpj2[3],ui[3],vi[3],n[3];
+
+ double** x = atom->x;
+ double** v = atom->v;
+ double** f = atom->f;
+ double** torque = atom->torque;
+ double** angmom = atom->angmom;
+
+ ifirst = dfirst[ibody];
+ iffirst = facfirst[ibody];
+ npi1 = static_cast<int>(face[iffirst+face_index][0]);
+ npi2 = static_cast<int>(face[iffirst+face_index][1]);
+ npi3 = static_cast<int>(face[iffirst+face_index][2]);
+
+ // compute the space-fixed coordinates for the vertices of the face
+
+ xi1[0] = xmi[0] + discrete[ifirst+npi1][0];
+ xi1[1] = xmi[1] + discrete[ifirst+npi1][1];
+ xi1[2] = xmi[2] + discrete[ifirst+npi1][2];
+
+ xi2[0] = xmi[0] + discrete[ifirst+npi2][0];
+ xi2[1] = xmi[1] + discrete[ifirst+npi2][1];
+ xi2[2] = xmi[2] + discrete[ifirst+npi2][2];
+
+ xi3[0] = xmi[0] + discrete[ifirst+npi3][0];
+ xi3[1] = xmi[1] + discrete[ifirst+npi3][1];
+ xi3[2] = xmi[2] + discrete[ifirst+npi3][2];
+
+ // find the normal unit vector of the face, ensure it point outward of the body
+
+ MathExtra::sub3(xi2, xi1, ui);
+ MathExtra::sub3(xi3, xi1, vi);
+ MathExtra::cross3(ui, vi, n);
+ MathExtra::norm3(n);
+
+ double xc[3], dot, ans[3];
+ xc[0] = (xi1[0] + xi2[0] + xi3[0])/3.0;
+ xc[1] = (xi1[1] + xi2[1] + xi3[1])/3.0;
+ xc[2] = (xi1[2] + xi2[2] + xi3[2])/3.0;
+ MathExtra::sub3(xc, xmi, ans);
+ dot = MathExtra::dot3(ans, n);
+ if (dot < 0) MathExtra::negate3(n);
+
+ // two ends of the edge from body j
+
+ jfirst = dfirst[jbody];
+ jefirst = edfirst[jbody];
+ npj1 = static_cast<int>(edge[jefirst+edge_index][0]);
+ npj2 = static_cast<int>(edge[jefirst+edge_index][1]);
+
+ xpj1[0] = xmj[0] + discrete[jfirst+npj1][0];
+ xpj1[1] = xmj[1] + discrete[jfirst+npj1][1];
+ xpj1[2] = xmj[2] + discrete[jfirst+npj1][2];
+
+ xpj2[0] = xmj[0] + discrete[jfirst+npj2][0];
+ xpj2[1] = xmj[1] + discrete[jfirst+npj2][1];
+ xpj2[2] = xmj[2] + discrete[jfirst+npj2][2];
+
+ // no interaction if two ends of the edge
+ // are on the same side with the COM wrt the face
+
+ if (opposite_sides(n, xi1, xmi, xpj1) == 0 &&
+ opposite_sides(n, xi1, xmi, xpj2) == 0)
+ return EF_NONE;
+
+ // determine the intersection of the edge to the face
+
+ double hi1[3], hi2[3], d1, d2, contact_dist, shift;
+ int inside1 = 0;
+ int inside2 = 0;
+
+ // enum {EF_PARALLEL=0,EF_SAME_SIDE_OF_FACE,
+ // EF_INTERSECT_INSIDE,EF_INTERSECT_OUTSIDE};
+
+ int interact = edge_face_intersect(xi1, xi2, xi3, xpj1, xpj2,
+ hi1, hi2, d1, d2, inside1, inside2);
+
+ inside_polygon(ibody, face_index, xmi, hi1, hi2, inside1, inside2);
+
+ contact_dist = rounded_radius_i + rounded_radius_j;
+
+ // both endpoints are on the same side of, or parallel to, the face
+ // and both are out of the interaction zone
+
+ if (interact == EF_SAME_SIDE_OF_FACE || interact == EF_PARALLEL) {
+
+ if (d1 > contact_dist + cut_inner && d2 > contact_dist + cut_inner)
+ return EF_NONE;
+
+ int num_outside = 0;
+ int jflag = 1;
+
+ #ifdef _POLYHEDRON_DEBUG
+ if (interact == EF_SAME_SIDE_OF_FACE)
+ printf(" - same side of face\n");
+ else if (interact == EF_PARALLEL)
+ printf(" - parallel\n");
+ printf(" face: xi1 (%f %f %f) xi2 (%f %f %f) xi3 (%f %f %f)\n",
+ xi1[0], xi1[1], xi1[2], xi2[0], xi2[1], xi2[2], xi3[0], xi3[1], xi3[2]);
+ printf(" edge: xpj1 (%f %f %f) xpj2 (%f %f %f)\n",
+ xpj1[0], xpj1[1], xpj1[2], xpj2[0], xpj2[1], xpj2[2]);
+ #endif
+
+ // xpj1 is in the interaction zone
+ // and its projection on the face is inside the triangle
+ // compute vertex-face interaction and accumulate force/torque to both bodies
+
+ if (d1 <= contact_dist + cut_inner) {
+ if (inside1) {
+ if (static_cast<int>(discrete[jfirst+npj1][6]) == 0) {
+ pair_force_and_torque(jbody, ibody, xpj1, hi1, d1, contact_dist,
+ jtype, itype, x, v, f, torque, angmom,
+ jflag, energy, facc);
+ #ifdef _POLYHEDRON_DEBUG
+ printf(" - compute pair force between vertex %d from edge %d of body %d "
+ "with face %d of body %d: d1 = %f\n",
+ npj1, edge_index, jbody, face_index, ibody, d1);
+ #endif
+
+ if (d1 <= contact_dist) {
+ // store the contact info
+ contact_list[num_contacts].ibody = ibody;
+ contact_list[num_contacts].jbody = jbody;
+ contact_list[num_contacts].xi[0] = hi1[0];
+ contact_list[num_contacts].xi[1] = hi1[1];
+ contact_list[num_contacts].xi[2] = hi1[2];
+ contact_list[num_contacts].xj[0] = xpj1[0];
+ contact_list[num_contacts].xj[1] = xpj1[1];
+ contact_list[num_contacts].xj[2] = xpj1[2];
+ contact_list[num_contacts].type = 0;
+ contact_list[num_contacts].separation = d1 - contact_dist;
+ contact_list[num_contacts].unique = 1;
+ num_contacts++;
+ }
+
+ discrete[jfirst+npj1][6] = 1;
+ }
+ } else {
+ num_outside++;
+ }
+ }
+
+ // xpj2 is in the interaction zone
+ // and its projection on the face is inside the triangle
+ // compute vertex-face interaction and accumulate force/torque to both bodies
+
+ if (d2 <= contact_dist + cut_inner) {
+ if (inside2) {
+ if (static_cast<int>(discrete[jfirst+npj2][6]) == 0) {
+ pair_force_and_torque(jbody, ibody, xpj2, hi2, d2, contact_dist,
+ jtype, itype, x, v, f, torque, angmom,
+ jflag, energy, facc);
+ #ifdef _POLYHEDRON_DEBUG
+ printf(" - compute pair force between vertex %d from edge %d of body %d "
+ "with face %d of body %d: d2 = %f\n",
+ npj2, edge_index, jbody, face_index, ibody, d2);
+ #endif
+
+ if (d2 <= contact_dist) {
+ // store the contact info
+ contact_list[num_contacts].ibody = ibody;
+ contact_list[num_contacts].jbody = jbody;
+ contact_list[num_contacts].xi[0] = hi2[0];
+ contact_list[num_contacts].xi[1] = hi2[1];
+ contact_list[num_contacts].xi[2] = hi2[2];
+ contact_list[num_contacts].xj[0] = xpj2[0];
+ contact_list[num_contacts].xj[1] = xpj2[1];
+ contact_list[num_contacts].xj[2] = xpj2[2];
+ contact_list[num_contacts].type = 0;
+ contact_list[num_contacts].separation = d2 - contact_dist;
+ contact_list[num_contacts].unique = 1;
+ num_contacts++;
+ }
+ discrete[jfirst+npj2][6] = 1;
+ }
+ } else {
+ num_outside++;
+ }
+ }
+
+ // both ends have projection outside of the face
+ // compute interaction between the edge with the three edges of the face
+
+ if (num_outside == 2) {
+
+ #ifdef _POLYHEDRON_DEBUG
+ printf(" - outside = 2\n");
+ printf(" - compute pair force between edge %d of body %d "
+ "with 3 edges of face %d of body %d\n",
+ edge_index, jbody, face_index, ibody);
+ #endif
+
+ interact = EF_INTERSECT_OUTSIDE;
+
+ }
+
+ } else if (interact == EF_INTERSECT_OUTSIDE) {
+
+ // compute interaction between the edge with the three edges of the face
+
+ #ifdef _POLYHEDRON_DEBUG
+ printf(" - intersect outside triangle\n");
+ printf(" - compute pair force between edge %d of body %d "
+ "with face %d of body %d\n", edge_index, jbody, face_index, ibody);
+ printf(" face: xi1 (%f %f %f) xi2 (%f %f %f) xi3 (%f %f %f)\n",
+ xi1[0], xi1[1], xi1[2], xi2[0], xi2[1], xi2[2], xi3[0], xi3[1], xi3[2]);
+ printf(" edge: xpj1 (%f %f %f) xpj2 (%f %f %f)\n",
+ xpj1[0], xpj1[1], xpj1[2], xpj2[0], xpj2[1], xpj2[2]);
+
+ #endif
+ } else if (interact == EF_INTERSECT_INSIDE) {
+ // need to do something here to resolve overlap!!
+ // p is the intersection between the edge and the face
+ int jflag = 1;
+ if (d1 < d2)
+ pair_force_and_torque(jbody, ibody, xpj1, hi1, d1, contact_dist,
+ jtype, itype, x, v, f, torque, angmom,
+ jflag, energy, facc);
+ else
+ pair_force_and_torque(jbody, ibody, xpj2, hi2, d2, contact_dist,
+ jtype, itype, x, v, f, torque, angmom,
+ jflag, energy, facc);
+ }
+
+ return interact;
+}
+
+/* ----------------------------------------------------------------------
+ Compute forces and torques between two bodies caused by the interaction
+ between a pair of points on either bodies (similar to sphere-sphere)
+------------------------------------------------------------------------- */
+
+void PairBodyRoundedPolyhedron::pair_force_and_torque(int ibody, int jbody,
+ double* pi, double* pj, double r, double contact_dist,
+ int itype, int jtype, double** x,
+ double** v, double** f, double** torque, double** angmom,
+ int jflag, double& energy, double* facc)
+{
+ double delx,dely,delz,R,fx,fy,fz,fpair;
+
+ delx = pi[0] - pj[0];
+ dely = pi[1] - pj[1];
+ delz = pi[2] - pj[2];
+ R = r - contact_dist;
+
+ kernel_force(R, itype, jtype, energy, fpair);
+
+ fx = delx*fpair/r;
+ fy = dely*fpair/r;
+ fz = delz*fpair/r;
+
+ #ifdef _POLYHEDRON_DEBUG
+ printf(" - R = %f; r = %f; k_na = %f; shift = %f; fpair = %f;"
+ " energy = %f; jflag = %d\n", R, r, k_na, shift, fpair,
+ energy, jflag);
+ #endif
+
+ if (R <= 0) {
+
+ // contact: accumulate normal and tangential contact force components
+
+ contact_forces(ibody, jbody, pi, pj, delx, dely, delz, fx, fy, fz,
+ x, v, angmom, f, torque, facc);
+ } else {
+
+ // accumulate force and torque to both bodies directly
+
+ f[ibody][0] += fx;
+ f[ibody][1] += fy;
+ f[ibody][2] += fz;
+ sum_torque(x[ibody], pi, fx, fy, fz, torque[ibody]);
+
+ facc[0] += fx; facc[1] += fy; facc[2] += fz;
+
+ if (jflag) {
+ f[jbody][0] -= fx;
+ f[jbody][1] -= fy;
+ f[jbody][2] -= fz;
+ sum_torque(x[jbody], pj, -fx, -fy, -fz, torque[jbody]);
+ }
+ }
+}
+
+/* ----------------------------------------------------------------------
+ Kernel force is model-dependent and can be derived for other styles
+ here is the harmonic potential (linear piece-wise forces) in Wang et al.
+------------------------------------------------------------------------- */
+
+void PairBodyRoundedPolyhedron::kernel_force(double R, int itype, int jtype,
+ double& energy, double& fpair)
+{
+ double kn = k_n[itype][jtype];
+ double kna = k_na[itype][jtype];
+ double shift = kna * cut_inner;
+ double e = 0;
+ if (R <= 0) { // deformation occurs
+ fpair = -kn * R - shift;
+ e = (0.5 * kn * R + shift) * R;
+ } else if (R <= cut_inner) { // not deforming but cohesive ranges overlap
+ fpair = kna * R - shift;
+ e = (-0.5 * kna * R + shift) * R;
+ } else fpair = 0.0;
+ energy += e;
+}
+
+/* ----------------------------------------------------------------------
+ Compute contact forces between two bodies
+ modify the force stored at the vertex and edge in contact by j_a
+ sum forces and torque to the corresponding bodies
+ fx,fy,fz = unscaled cohesive forces
+ fn = normal friction component
+ ft = tangential friction component (-c_t * v_t)
+------------------------------------------------------------------------- */
+
+void PairBodyRoundedPolyhedron::contact_forces(int ibody, int jbody,
+ double *xi, double *xj, double delx, double dely, double delz,
+ double fx, double fy, double fz, double** x, double** v, double** angmom,
+ double** f, double** torque, double* facc)
+{
+ int ibonus,jbonus;
+ double rsq,rsqinv,vr1,vr2,vr3,vnnr,vn1,vn2,vn3,vt1,vt2,vt3;
+ double fn[3],ft[3],vi[3],vj[3];
+ double *quat, *inertia;
+ AtomVecBody::Bonus *bonus;
+
+ // compute the velocity of the vertex in the space-fixed frame
+
+ ibonus = atom->body[ibody];
+ bonus = &avec->bonus[ibonus];
+ quat = bonus->quat;
+ inertia = bonus->inertia;
+ total_velocity(xi, x[ibody], v[ibody], angmom[ibody],
+ inertia, quat, vi);
+
+ // compute the velocity of the point on the edge in the space-fixed frame
+
+ jbonus = atom->body[jbody];
+ bonus = &avec->bonus[jbonus];
+ quat = bonus->quat;
+ inertia = bonus->inertia;
+ total_velocity(xj, x[jbody], v[jbody], angmom[jbody],
+ inertia, quat, vj);
+
+ // vector pointing from the contact point on ibody to that on jbody
+
+ rsq = delx*delx + dely*dely + delz*delz;
+ rsqinv = 1.0/rsq;
+
+ // relative translational velocity
+
+ vr1 = vi[0] - vj[0];
+ vr2 = vi[1] - vj[1];
+ vr3 = vi[2] - vj[2];
+
+ // normal component
+
+ vnnr = vr1*delx + vr2*dely + vr3*delz;
+ vn1 = delx*vnnr * rsqinv;
+ vn2 = dely*vnnr * rsqinv;
+ vn3 = delz*vnnr * rsqinv;
+
+ // tangential component
+
+ vt1 = vr1 - vn1;
+ vt2 = vr2 - vn2;
+ vt3 = vr3 - vn3;
+
+ // normal friction term at contact
+
+ fn[0] = -c_n * vn1;
+ fn[1] = -c_n * vn2;
+ fn[2] = -c_n * vn3;
+
+ // tangential friction term at contact
+ // excluding the tangential deformation term for now
+
+ ft[0] = -c_t * vt1;
+ ft[1] = -c_t * vt2;
+ ft[2] = -c_t * vt3;
+
+ // these are contact forces (F_n, F_t and F_ne) only
+ // cohesive forces will be scaled by j_a after contact area is computed
+ // mu * fne = tangential friction deformation during gross sliding
+ // see Eq. 4, Fraige et al.
+
+ fx = fn[0] + ft[0] + mu * fx;
+ fy = fn[1] + ft[1] + mu * fy;
+ fz = fn[2] + ft[2] + mu * fz;
+
+ f[ibody][0] += fx;
+ f[ibody][1] += fy;
+ f[ibody][2] += fz;
+ sum_torque(x[ibody], xi, fx, fy, fz, torque[ibody]);
+
+ f[jbody][0] -= fx;
+ f[jbody][1] -= fy;
+ f[jbody][2] -= fz;
+ sum_torque(x[jbody], xj, -fx, -fy, -fz, torque[jbody]);
+
+ facc[0] += fx; facc[1] += fy; facc[2] += fz;
+
+ #ifdef _POLYHEDRON_DEBUG
+ printf("contact ibody = %d: f = %f %f %f; torque = %f %f %f\n", ibody,
+ f[ibody][0], f[ibody][1], f[ibody][2],
+ torque[ibody][0], torque[ibody][1], torque[ibody][2]);
+ printf("contact jbody = %d: f = %f %f %f; torque = %f %f %f\n", jbody,
+ f[jbody][0], f[jbody][1], f[jbody][2],
+ torque[jbody][0], torque[jbody][1], torque[jbody][2]);
+ #endif
+}
+
+/* ----------------------------------------------------------------------
+ Rescale the forces and torques for all the contacts
+------------------------------------------------------------------------- */
+
+void PairBodyRoundedPolyhedron::rescale_cohesive_forces(double** x,
+ double** f, double** torque, Contact* contact_list, int &num_contacts,
+ int itype, int jtype, double* facc)
+{
+ int m,ibody,jbody;
+ double delx,dely,delz,fx,fy,fz,R,fpair,r,contact_area;
+
+ int num_unique_contacts = 0;
+ if (num_contacts == 1) {
+ num_unique_contacts = 1;
+ contact_area = 0;
+ } else if (num_contacts == 2) {
+ num_unique_contacts = 2;
+ contact_area = num_contacts * A_ua;
+ } else {
+ find_unique_contacts(contact_list, num_contacts);
+
+ double xc[3],dx,dy,dz;
+ xc[0] = xc[1] = xc[2] = 0;
+ num_unique_contacts = 0;
+ for (int m = 0; m < num_contacts; m++) {
+ if (contact_list[m].unique == 0) continue;
+ xc[0] += contact_list[m].xi[0];
+ xc[1] += contact_list[m].xi[1];
+ xc[2] += contact_list[m].xi[2];
+ num_unique_contacts++;
+ }
+
+ xc[0] /= (double)num_unique_contacts;
+ xc[1] /= (double)num_unique_contacts;
+ xc[2] /= (double)num_unique_contacts;
+
+ contact_area = 0.0;
+ for (int m = 0; m < num_contacts; m++) {
+ if (contact_list[m].unique == 0) continue;
+ dx = contact_list[m].xi[0] - xc[0];
+ dy = contact_list[m].xi[1] - xc[1];
+ dz = contact_list[m].xi[2] - xc[2];
+ contact_area += (dx*dx + dy*dy + dz*dz);
+ }
+ contact_area *= (MY_PI/(double)num_unique_contacts);
+ }
+
+ double j_a = contact_area / (num_unique_contacts * A_ua);
+ if (j_a < 1.0) j_a = 1.0;
+ for (m = 0; m < num_contacts; m++) {
+ if (contact_list[m].unique == 0) continue;
+
+ ibody = contact_list[m].ibody;
+ jbody = contact_list[m].jbody;
+
+ delx = contact_list[m].xi[0] - contact_list[m].xj[0];
+ dely = contact_list[m].xi[1] - contact_list[m].xj[1];
+ delz = contact_list[m].xi[2] - contact_list[m].xj[2];
+ r = sqrt(delx*delx + dely*dely + delz*delz);
+ R = contact_list[m].separation;
+
+ double energy = 0;
+ kernel_force(R, itype, jtype, energy, fpair);
+
+ fpair *= j_a;
+ fx = delx*fpair/r;
+ fy = dely*fpair/r;
+ fz = delz*fpair/r;
+
+ f[ibody][0] += fx;
+ f[ibody][1] += fy;
+ f[ibody][2] += fz;
+ sum_torque(x[ibody], contact_list[m].xi, fx, fy, fz, torque[ibody]);
+
+ f[jbody][0] -= fx;
+ f[jbody][1] -= fy;
+ f[jbody][2] -= fz;
+ sum_torque(x[jbody], contact_list[m].xj, -fx, -fy, -fz, torque[jbody]);
+
+ facc[0] += fx; facc[1] += fy; facc[2] += fz;
+ }
+}
+
+/* ----------------------------------------------------------------------
+ Accumulate torque to body from the force f=(fx,fy,fz) acting at point x
+------------------------------------------------------------------------- */
+
+void PairBodyRoundedPolyhedron::sum_torque(double* xm, double *x, double fx,
+ double fy, double fz, double* torque)
+{
+ double rx = x[0] - xm[0];
+ double ry = x[1] - xm[1];
+ double rz = x[2] - xm[2];
+ double tx = ry * fz - rz * fy;
+ double ty = rz * fx - rx * fz;
+ double tz = rx * fy - ry * fx;
+ torque[0] += tx;
+ torque[1] += ty;
+ torque[2] += tz;
+}
+
+/* ----------------------------------------------------------------------
+ Test if two points a and b are in opposite sides of a plane defined by
+ a normal vector n and a point x0
+------------------------------------------------------------------------- */
+
+int PairBodyRoundedPolyhedron::opposite_sides(double* n, double* x0,
+ double* a, double* b)
+{
+ double m_a = n[0]*(a[0] - x0[0])+n[1]*(a[1] - x0[1])+n[2]*(a[2] - x0[2]);
+ double m_b = n[0]*(b[0] - x0[0])+n[1]*(b[1] - x0[1])+n[2]*(b[2] - x0[2]);
+ // equal to zero when either a or b is on the plane
+ if (m_a * m_b <= 0)
+ return 1;
+ else
+ return 0;
+}
+
+/* ----------------------------------------------------------------------
+ Test if a line segment defined by two points a and b intersects with
+ a triangle defined by three points x1, x2 and x3
+------------------------------------------------------------------------- */
+
+int PairBodyRoundedPolyhedron::edge_face_intersect(double* x1, double* x2,
+ double* x3, double* a, double* b, double* h_a, double* h_b,
+ double& d_a, double& d_b, int& inside_a, int& inside_b)
+{
+ double s[3], u[3], v[3], n[3];
+
+ // line director
+
+ MathExtra::sub3(b, a, s);
+
+ // plane normal vector
+
+ MathExtra::sub3(x2, x1, u);
+ MathExtra::sub3(x3, x1, v);
+ MathExtra::cross3(u, v, n);
+ MathExtra::norm3(n);
+
+ // find the projection of a and b to the plane and the corresponding distances
+
+ project_pt_plane(a, x1, x2, x3, h_a, d_a, inside_a);
+
+ project_pt_plane(b, x1, x2, x3, h_b, d_b, inside_b);
+
+ // check if the line segment is parallel to the plane
+
+ double dot = MathExtra::dot3(s, n);
+ if (fabs(dot) < EPSILON) return EF_PARALLEL;
+
+ // solve for the intersection between the line and the plane
+
+ double m[3][3], invm[3][3], p[3], ans[3];
+ m[0][0] = -s[0];
+ m[0][1] = u[0];
+ m[0][2] = v[0];
+
+ m[1][0] = -s[1];
+ m[1][1] = u[1];
+ m[1][2] = v[1];
+
+ m[2][0] = -s[2];
+ m[2][1] = u[2];
+ m[2][2] = v[2];
+
+ MathExtra::sub3(a, x1, p);
+ MathExtra::invert3(m, invm);
+ MathExtra::matvec(invm, p, ans);
+
+ // p is reused for the intersection point
+ // s = b - a
+
+ double t = ans[0];
+ p[0] = a[0] + s[0] * t;
+ p[1] = a[1] + s[1] * t;
+ p[2] = a[2] + s[2] * t;
+
+ // check if p is inside the triangle, excluding the edges and vertices
+ // the edge-edge and edge-vertices are handled separately
+
+ int inside = 0;
+ if (ans[1] > 0 && ans[2] > 0 && ans[1] + ans[2] < 1)
+ inside = 1;
+
+ int interact;
+ if (t < 0 || t > 1) {
+ interact = EF_SAME_SIDE_OF_FACE;
+ } else {
+ if (inside == 1)
+ interact = EF_INTERSECT_INSIDE;
+ else
+ interact = EF_INTERSECT_OUTSIDE;
+ }
+
+ return interact;
+}
+
+/* ----------------------------------------------------------------------
+ Find the projection of q on the plane defined by point p and the normal
+ unit vector n: q_proj = q - dot(q - p, n) * n
+ and the distance d from q to the plane
+------------------------------------------------------------------------- */
+
+void PairBodyRoundedPolyhedron::project_pt_plane(const double* q,
+ const double* p, const double* n,
+ double* q_proj, double &d)
+{
+ double dot, ans[3], n_p[3];
+ n_p[0] = n[0]; n_p[1] = n[1]; n_p[2] = n[2];
+ MathExtra::sub3(q, p, ans);
+ dot = MathExtra::dot3(ans, n_p);
+ MathExtra::scale3(dot, n_p);
+ MathExtra::sub3(q, n_p, q_proj);
+ MathExtra::sub3(q, q_proj, ans);
+ d = MathExtra::len3(ans);
+}
+
+/* ----------------------------------------------------------------------
+ Check if points q1 and q2 are inside a convex polygon, i.e. a face of
+ a polyhedron
+ ibody = atom i's index
+ face_index = face index of the body
+ xmi = atom i's coordinates
+ q1 = tested point on the face (e.g. the projection of a point)
+ q2 = another point (can be NULL) for face-edge intersection
+ Output:
+ inside1 = 1 if q1 is inside the polygon, 0 otherwise
+ inside2 = 1 if q2 is inside the polygon, 0 otherwise
+------------------------------------------------------------------------- */
+
+void PairBodyRoundedPolyhedron::inside_polygon(int ibody, int face_index,
+ double* xmi, const double* q1, const double* q2,
+ int& inside1, int& inside2)
+
+{
+ int i,n,ifirst,iffirst,npi1,npi2;
+ double xi1[3],xi2[3],u[3],v[3],costheta,anglesum1,anglesum2,magu,magv;
+
+ ifirst = dfirst[ibody];
+ iffirst = facfirst[ibody];
+ anglesum1 = anglesum2 = 0;;
+ for (i = 0; i < MAX_FACE_SIZE; i++) {
+ npi1 = static_cast<int>(face[iffirst+face_index][i]);
+ if (npi1 < 0) break;
+ n = i + 1;
+ if (n <= MAX_FACE_SIZE - 1) {
+ npi2 = static_cast<int>(face[iffirst+face_index][n]);
+ if (npi2 < 0) npi2 = static_cast<int>(face[iffirst+face_index][0]);
+ } else {
+ npi2 = static_cast<int>(face[iffirst+face_index][0]);
+ }
+
+ xi1[0] = xmi[0] + discrete[ifirst+npi1][0];
+ xi1[1] = xmi[1] + discrete[ifirst+npi1][1];
+ xi1[2] = xmi[2] + discrete[ifirst+npi1][2];
+
+ xi2[0] = xmi[0] + discrete[ifirst+npi2][0];
+ xi2[1] = xmi[1] + discrete[ifirst+npi2][1];
+ xi2[2] = xmi[2] + discrete[ifirst+npi2][2];
+
+ MathExtra::sub3(xi1,q1,u);
+ MathExtra::sub3(xi2,q1,v);
+ magu = MathExtra::len3(u);
+ magv = MathExtra::len3(v);
+
+ // the point is at either vertices
+
+ if (magu * magv < EPSILON) inside1 = 1;
+ else {
+ costheta = MathExtra::dot3(u,v)/(magu*magv);
+ anglesum1 += acos(costheta);
+ }
+
+ if (q2 != NULL) {
+ MathExtra::sub3(xi1,q2,u);
+ MathExtra::sub3(xi2,q2,v);
+ magu = MathExtra::len3(u);
+ magv = MathExtra::len3(v);
+ if (magu * magv < EPSILON) inside2 = 1;
+ else {
+ costheta = MathExtra::dot3(u,v)/(magu*magv);
+ anglesum2 += acos(costheta);
+ }
+ }
+ }
+
+ if (fabs(anglesum1 - MY_2PI) < EPSILON) inside1 = 1;
+ else inside1 = 0;
+
+ if (q2 != NULL) {
+ if (fabs(anglesum2 - MY_2PI) < EPSILON) inside2 = 1;
+ else inside2 = 0;
+ }
+}
+
+/* ----------------------------------------------------------------------
+ Find the projection of q on the plane defined by 3 points x1, x2 and x3
+ returns the distance d from q to the plane and whether the projected
+ point is inside the triangle defined by (x1, x2, x3)
+------------------------------------------------------------------------- */
+
+void PairBodyRoundedPolyhedron::project_pt_plane(const double* q,
+ const double* x1, const double* x2, const double* x3, double* q_proj,
+ double &d, int& inside)
+{
+ double u[3],v[3],n[3];
+
+ // plane normal vector
+
+ MathExtra::sub3(x2, x1, u);
+ MathExtra::sub3(x3, x1, v);
+ MathExtra::cross3(u, v, n);
+ MathExtra::norm3(n);
+
+ // solve for the intersection between the line and the plane
+
+ double m[3][3], invm[3][3], p[3], ans[3];
+ m[0][0] = -n[0];
+ m[0][1] = u[0];
+ m[0][2] = v[0];
+
+ m[1][0] = -n[1];
+ m[1][1] = u[1];
+ m[1][2] = v[1];
+
+ m[2][0] = -n[2];
+ m[2][1] = u[2];
+ m[2][2] = v[2];
+
+ MathExtra::sub3(q, x1, p);
+ MathExtra::invert3(m, invm);
+ MathExtra::matvec(invm, p, ans);
+
+ double t = ans[0];
+ q_proj[0] = q[0] + n[0] * t;
+ q_proj[1] = q[1] + n[1] * t;
+ q_proj[2] = q[2] + n[2] * t;
+
+ // check if the projection point is inside the triangle
+ // exclude the edges and vertices
+ // edge-sphere and sphere-sphere interactions are handled separately
+
+ inside = 0;
+ if (ans[1] > 0 && ans[2] > 0 && ans[1] + ans[2] < 1) {
+ inside = 1;
+ }
+
+ // distance from q to q_proj
+
+ MathExtra::sub3(q, q_proj, ans);
+ d = MathExtra::len3(ans);
+}
+
+/* ---------------------------------------------------------------------- */
+
+void PairBodyRoundedPolyhedron::project_pt_line(const double* q,
+ const double* xi1, const double* xi2, double* h, double& d, double& t)
+{
+ double u[3],v[3],r[3],s;
+
+ MathExtra::sub3(xi2, xi1, u);
+ MathExtra::norm3(u);
+ MathExtra::sub3(q, xi1, v);
+
+ s = MathExtra::dot3(u, v);
+ h[0] = xi1[0] + s * u[0];
+ h[1] = xi1[1] + s * u[1];
+ h[2] = xi1[2] + s * u[2];
+
+ MathExtra::sub3(q, h, r);
+ d = MathExtra::len3(r);
+
+ if (fabs(xi2[0] - xi1[0]) > 0)
+ t = (h[0] - xi1[0])/(xi2[0] - xi1[0]);
+ else if (fabs(xi2[1] - xi1[1]) > 0)
+ t = (h[1] - xi1[1])/(xi2[1] - xi1[1]);
+ else if (fabs(xi2[2] - xi1[2]) > 0)
+ t = (h[2] - xi1[2])/(xi2[2] - xi1[2]);
+}
+
+/* ----------------------------------------------------------------------
+ compute the shortest distance between two edges (line segments)
+ x1, x2: two endpoints of the first edge
+ x3, x4: two endpoints of the second edge
+ h1: the end point of the shortest segment perpendicular to both edges
+ on the line (x1;x2)
+ h2: the end point of the shortest segment perpendicular to both edges
+ on the line (x3;x4)
+ t1: fraction of h1 in the segment (x1,x2)
+ t2: fraction of h2 in the segment (x3,x4)
+------------------------------------------------------------------------- */
+
+void PairBodyRoundedPolyhedron::distance_bt_edges(const double* x1,
+ const double* x2, const double* x3, const double* x4,
+ double* h1, double* h2, double& t1, double& t2, double& r)
+{
+ double u[3],v[3],n[3],dot;
+
+ // set the default returned values
+
+ t1 = -2;
+ t2 = 2;
+ r = 0;
+
+ // find the edge unit directors and their dot product
+
+ MathExtra::sub3(x2, x1, u);
+ MathExtra::norm3(u);
+ MathExtra::sub3(x4, x3, v);
+ MathExtra::norm3(v);
+ dot = MathExtra::dot3(u,v);
+ dot = fabs(dot);
+
+ // check if two edges are parallel
+ // find the two ends of the overlapping segment, if any
+
+ if (fabs(dot - 1.0) < EPSILON) {
+
+ double s1,s2,x13[3],x23[3],x13h[3];
+ double t13,t23,t31,t41,x31[3],x41[3];
+ t13=t23=t31=t41=0.0;
+
+ MathExtra::sub3(x1,x3,x13); // x13 = x1 - x3
+ MathExtra::sub3(x2,x3,x23); // x23 = x2 - x3
+
+ s1 = MathExtra::dot3(x13,v);
+ x13h[0] = x13[0] - s1*v[0];
+ x13h[1] = x13[1] - s1*v[1];
+ x13h[2] = x13[2] - s1*v[2];
+ r = MathExtra::len3(x13h);
+
+ // x13 is the projection of x1 on x3-x4
+
+ x13[0] = x3[0] + s1*v[0];
+ x13[1] = x3[1] + s1*v[1];
+ x13[2] = x3[2] + s1*v[2];
+
+ // x23 is the projection of x2 on x3-x4
+
+ s2 = MathExtra::dot3(x23,v);
+ x23[0] = x3[0] + s2*v[0];
+ x23[1] = x3[1] + s2*v[1];
+ x23[2] = x3[2] + s2*v[2];
+
+ // find the fraction of the projection points on the edges
+
+ if (fabs(x4[0] - x3[0]) > 0)
+ t13 = (x13[0] - x3[0])/(x4[0] - x3[0]);
+ else if (fabs(x4[1] - x3[1]) > 0)
+ t13 = (x13[1] - x3[1])/(x4[1] - x3[1]);
+ else if (fabs(x4[2] - x3[2]) > 0)
+ t13 = (x13[2] - x3[2])/(x4[2] - x3[2]);
+
+ if (fabs(x4[0] - x3[0]) > 0)
+ t23 = (x23[0] - x3[0])/(x4[0] - x3[0]);
+ else if (fabs(x4[1] - x3[1]) > 0)
+ t23 = (x23[1] - x3[1])/(x4[1] - x3[1]);
+ else if (fabs(x4[2] - x3[2]) > 0)
+ t23 = (x23[2] - x3[2])/(x4[2] - x3[2]);
+
+ if (fabs(x23[0] - x13[0]) > 0)
+ t31 = (x3[0] - x13[0])/(x23[0] - x13[0]);
+ else if (fabs(x23[1] - x13[1]) > 0)
+ t31 = (x3[1] - x13[1])/(x23[1] - x13[1]);
+ else if (fabs(x23[2] - x13[2]) > 0)
+ t31 = (x3[2] - x13[2])/(x23[2] - x13[2]);
+
+ // x31 is the projection of x3 on x1-x2
+
+ x31[0] = x1[0] + t31*(x2[0] - x1[0]);
+ x31[1] = x1[1] + t31*(x2[1] - x1[1]);
+ x31[2] = x1[2] + t31*(x2[2] - x1[2]);
+
+ if (fabs(x23[0] - x13[0]) > 0)
+ t41 = (x4[0] - x13[0])/(x23[0] - x13[0]);
+ else if (fabs(x23[1] - x13[1]) > 0)
+ t41 = (x4[1] - x13[1])/(x23[1] - x13[1]);
+ else if (fabs(x23[2] - x13[2]) > 0)
+ t41 = (x4[2] - x13[2])/(x23[2] - x13[2]);
+
+ // x41 is the projection of x4 on x1-x2
+
+ x41[0] = x1[0] + t41*(x2[0] - x1[0]);
+ x41[1] = x1[1] + t41*(x2[1] - x1[1]);
+ x41[2] = x1[2] + t41*(x2[2] - x1[2]);
+
+ // determine two ends from the overlapping segments
+
+ int n1 = 0;
+ int n2 = 0;
+ if (t13 >= 0 && t13 <= 1) {
+ h1[0] = x1[0];
+ h1[1] = x1[1];
+ h1[2] = x1[2];
+ h2[0] = x13[0];
+ h2[1] = x13[1];
+ h2[2] = x13[2];
+ t1 = 0;
+ t2 = t13;
+ n1++;
+ n2++;
+ }
+ if (t23 >= 0 && t23 <= 1) {
+ if (n1 == 0) {
+ h1[0] = x2[0];
+ h1[1] = x2[1];
+ h1[2] = x2[2];
+ h2[0] = x23[0];
+ h2[1] = x23[1];
+ h2[2] = x23[2];
+ t1 = 1;
+ t2 = t23;
+ n1++;
+ n2++;
+ } else {
+ h1[0] = (x1[0]+x2[0])/2;
+ h1[1] = (x1[1]+x2[1])/2;
+ h1[2] = (x1[2]+x2[2])/2;
+ h2[0] = (x13[0]+x23[0])/2;
+ h2[1] = (x13[1]+x23[1])/2;
+ h2[2] = (x13[2]+x23[2])/2;
+ t1 = 0.5;
+ t2 = (t13+t23)/2;
+ n1++;
+ n2++;
+ }
+ }
+
+ if (n1 == 0 && n2 == 0) {
+ if (t31 >= 0 && t31 <= 1) {
+ h1[0] = x31[0];
+ h1[1] = x31[1];
+ h1[2] = x31[2];
+ h2[0] = x3[0];
+ h2[1] = x3[1];
+ h2[2] = x3[2];
+ t1 = t31;
+ t2 = 0;
+ n1++;
+ n2++;
+ }
+ if (t41 >= 0 && t41 <= 1) {
+ if (n1 == 0) {
+ h1[0] = x41[0];
+ h1[1] = x41[1];
+ h1[2] = x41[2];
+ h2[0] = x4[0];
+ h2[1] = x4[1];
+ h2[2] = x4[2];
+ t1 = t41;
+ t2 = 1;
+ n1++;
+ n2++;
+ } else {
+ h1[0] = (x31[0]+x41[0])/2;
+ h1[1] = (x31[1]+x41[1])/2;
+ h1[2] = (x31[2]+x41[2])/2;
+ h2[0] = (x3[0]+x4[0])/2;
+ h2[1] = (x3[1]+x4[1])/2;
+ h2[2] = (x3[2]+x4[2])/2;
+ t1 = (t31+t41)/2;
+ t2 = 0.5;
+ n1++;
+ n2++;
+ }
+ }
+ }
+
+ // if n1 == 0 and n2 == 0 at this point,
+ // which means no overlapping segments bt two parallel edges,
+ // return the default values of t1 and t2
+
+ return;
+
+ }
+
+ // find the vector n perpendicular to both edges
+
+ MathExtra::cross3(u, v, n);
+ MathExtra::norm3(n);
+
+ // find the intersection of the line (x3,x4) and the plane (x1,x2,n)
+ // s = director of the line (x3,x4)
+ // n_p = plane normal vector of the plane (x1,x2,n)
+
+ double s[3], n_p[3];
+ MathExtra::sub3(x4, x3, s);
+ MathExtra::sub3(x2, x1, u);
+ MathExtra::cross3(u, n, n_p);
+ MathExtra::norm3(n_p);
+
+ // solve for the intersection between the line and the plane
+
+ double m[3][3], invm[3][3], p[3], ans[3];
+ m[0][0] = -s[0];
+ m[0][1] = u[0];
+ m[0][2] = n[0];
+
+ m[1][0] = -s[1];
+ m[1][1] = u[1];
+ m[1][2] = n[1];
+
+ m[2][0] = -s[2];
+ m[2][1] = u[2];
+ m[2][2] = n[2];
+
+ MathExtra::sub3(x3, x1, p);
+ MathExtra::invert3(m, invm);
+ MathExtra::matvec(invm, p, ans);
+
+ t2 = ans[0];
+ h2[0] = x3[0] + s[0] * t2;
+ h2[1] = x3[1] + s[1] * t2;
+ h2[2] = x3[2] + s[2] * t2;
+
+ project_pt_plane(h2, x1, n, h1, r);
+
+ if (fabs(x2[0] - x1[0]) > 0)
+ t1 = (h1[0] - x1[0])/(x2[0] - x1[0]);
+ else if (fabs(x2[1] - x1[1]) > 0)
+ t1 = (h1[1] - x1[1])/(x2[1] - x1[1]);
+ else if (fabs(x2[2] - x1[2]) > 0)
+ t1 = (h1[2] - x1[2])/(x2[2] - x1[2]);
+}
+
+/* ----------------------------------------------------------------------
+ Calculate the total velocity of a point (vertex, a point on an edge):
+ vi = vcm + omega ^ (p - xcm)
+------------------------------------------------------------------------- */
+
+void PairBodyRoundedPolyhedron::total_velocity(double* p, double *xcm,
+ double* vcm, double *angmom, double *inertia, double *quat, double* vi)
+{
+ double r[3],omega[3],ex_space[3],ey_space[3],ez_space[3];
+ r[0] = p[0] - xcm[0];
+ r[1] = p[1] - xcm[1];
+ r[2] = p[2] - xcm[2];
+ MathExtra::q_to_exyz(quat,ex_space,ey_space,ez_space);
+ MathExtra::angmom_to_omega(angmom,ex_space,ey_space,ez_space,
+ inertia,omega);
+ vi[0] = omega[1]*r[2] - omega[2]*r[1] + vcm[0];
+ vi[1] = omega[2]*r[0] - omega[0]*r[2] + vcm[1];
+ vi[2] = omega[0]*r[1] - omega[1]*r[0] + vcm[2];
+}
+
+/* ----------------------------------------------------------------------
+ Determine the length of the contact segment, i.e. the separation between
+ 2 contacts, should be extended for 3D models.
+------------------------------------------------------------------------- */
+
+double PairBodyRoundedPolyhedron::contact_separation(const Contact& c1,
+ const Contact& c2)
+{
+ double x1 = 0.5*(c1.xi[0] + c1.xj[0]);
+ double y1 = 0.5*(c1.xi[1] + c1.xj[1]);
+ double z1 = 0.5*(c1.xi[2] + c1.xj[2]);
+ double x2 = 0.5*(c2.xi[0] + c2.xj[0]);
+ double y2 = 0.5*(c2.xi[1] + c2.xj[1]);
+ double z2 = 0.5*(c2.xi[2] + c2.xj[2]);
+ double rsq = (x2 - x1)*(x2 - x1) + (y2 - y1)*(y2 - y1) + (z2 - z1)*(z2 - z1);
+ return rsq;
+}
+
+/* ----------------------------------------------------------------------
+ find the number of unique contacts
+------------------------------------------------------------------------- */
+
+void PairBodyRoundedPolyhedron::find_unique_contacts(Contact* contact_list,
+ int& num_contacts)
+{
+ int n = num_contacts;
+ for (int i = 0; i < n - 1; i++) {
+
+ for (int j = i + 1; j < n; j++) {
+ if (contact_list[i].unique == 0) continue;
+ double d = contact_separation(contact_list[i], contact_list[j]);
+ if (d < EPSILON) contact_list[j].unique = 0;
+ }
+ }
+}
+
+/* ---------------------------------------------------------------------- */
+
+void PairBodyRoundedPolyhedron::sanity_check()
+{
+
+ double x1[3],x2[3],x3[3],x4[3],h_a[3],h_b[3],d_a,d_b,u[3],v[3],n[3];
+ double a[3],b[3],t_a,t_b;
+ int inside_a, inside_b;
+
+ x1[0] = 0; x1[1] = 3; x1[2] = 0;
+ x2[0] = 3; x2[1] = 0; x2[2] = 0;
+ x3[0] = 4; x3[1] = 3; x3[2] = 0;
+ x4[0] = 5; x4[1] = 3; x4[2] = 0;
+
+ a[0] = 0; a[1] = 0; a[2] = 0;
+ b[0] = 4; b[1] = 0; b[2] = 0;
+
+ project_pt_line(a, x1, x2, h_a, d_a, t_a);
+ project_pt_line(b, x1, x2, h_b, d_b, t_b);
+/*
+ printf("h_a: %f %f %f; h_b: %f %f %f; t_a = %f; t_b = %f; d = %f; d_b = %f\n",
+ h_a[0], h_a[1], h_a[2], h_b[0], h_b[1], h_b[2], t_a, t_b, d_a, d_b);
+*/
+/*
+ int mode = edge_face_intersect(x1, x2, x3, a, b, h_a, h_b, d_a, d_b,
+ inside_a, inside_b);
+
+ MathExtra::sub3(x2, x1, u);
+ MathExtra::sub3(x3, x1, v);
+ MathExtra::cross3(u, v, n);
+ MathExtra::norm3(n);
+*/
+/*
+ project_pt_plane(a, x1, x2, x3, h_a, d_a, inside_a);
+ printf("h_a: %f %f %f; d = %f: inside %d\n",
+ h_a[0], h_a[1], h_a[2], d_a, inside_a);
+ project_pt_plane(b, x1, x2, x3, h_b, d_b, inside_b);
+ printf("h_b: %f %f %f; d = %f: inside %d\n",
+ h_b[0], h_b[1], h_b[2], d_b, inside_b);
+*/
+/*
+ distance_bt_edges(x1, x2, x3, x4, h_a, h_b, t_a, t_b, d_a);
+ printf("h_a: %f %f %f; h_b: %f %f %f; t_a = %f; t_b = %f; d = %f\n",
+ h_a[0], h_a[1], h_a[2], h_b[0], h_b[1], h_b[2], t_a, t_b, d_a);
+*/
+}
+
diff --git a/src/BODY/pair_body_rounded_polyhedron.h b/src/BODY/pair_body_rounded_polyhedron.h
new file mode 100644
index 0000000000000000000000000000000000000000..71c04ff9665aa0b24b7e7f4069cc4f4f4766bf4d
--- /dev/null
+++ b/src/BODY/pair_body_rounded_polyhedron.h
@@ -0,0 +1,200 @@
+/* -*- c++ -*- ----------------------------------------------------------
+ LAMMPS - Large-scale Atomic/Molecular Massively Parallel Simulator
+ http://lammps.sandia.gov, Sandia National Laboratories
+ Steve Plimpton, sjplimp@sandia.gov
+
+ Copyright (2003) Sandia Corporation. Under the terms of Contract
+ DE-AC04-94AL85000 with Sandia Corporation, the U.S. Government retains
+ certain rights in this software. This software is distributed under
+ the GNU General Public License.
+
+ See the README file in the top-level LAMMPS directory.
+------------------------------------------------------------------------- */
+
+#ifdef PAIR_CLASS
+
+PairStyle(body/rounded/polyhedron,PairBodyRoundedPolyhedron)
+
+#else
+
+#ifndef LMP_PAIR_BODY_ROUNDED_POLYHEDRON_H
+#define LMP_PAIR_BODY_ROUNDED_POLYHEDRON_H
+
+#include "pair.h"
+
+namespace LAMMPS_NS {
+
+class PairBodyRoundedPolyhedron : public Pair {
+ public:
+ PairBodyRoundedPolyhedron(class LAMMPS *);
+ ~PairBodyRoundedPolyhedron();
+ void compute(int, int);
+ void settings(int, char **);
+ void coeff(int, char **);
+ void init_style();
+ double init_one(int, int);
+
+ virtual void kernel_force(double R, int itype, int jtype,
+ double& energy, double& fpair);
+
+ struct Contact {
+ int ibody, jbody; // body (i.e. atom) indices (not tags)
+ int type; // 0 = VERTEX-FACE; 1 = EDGE-EDGE
+ double fx,fy,fz; // unscaled cohesive forces at contact
+ double xi[3]; // coordinates of the contact point on ibody
+ double xj[3]; // coordinates of the contact point on jbody
+ double separation; // contact surface separation
+ int unique;
+ };
+
+ protected:
+ double **k_n; // normal repulsion strength
+ double **k_na; // normal attraction strength
+ double c_n; // normal damping coefficient
+ double c_t; // tangential damping coefficient
+ double mu; // normal friction coefficient during gross sliding
+ double A_ua; // characteristic contact area
+ double cut_inner; // cutoff for interaction between vertex-edge surfaces
+
+ class AtomVecBody *avec;
+ class BodyRoundedPolyhedron *bptr;
+
+ double **discrete; // list of all sub-particles for all bodies
+ int ndiscrete; // number of discretes in list
+ int dmax; // allocated size of discrete list
+ int *dnum; // number of discretes per line, 0 if uninit
+ int *dfirst; // index of first discrete per each line
+ int nmax; // allocated size of dnum,dfirst vectors
+
+ double **edge; // list of all edge for all bodies
+ int nedge; // number of edge in list
+ int edmax; // allocated size of edge list
+ int *ednum; // number of edges per line, 0 if uninit
+ int *edfirst; // index of first edge per each line
+ int ednummax; // allocated size of ednum,edfirst vectors
+
+ double **face; // list of all edge for all bodies
+ int nface; // number of faces in list
+ int facmax; // allocated size of face list
+ int *facnum; // number of faces per line, 0 if uninit
+ int *facfirst; // index of first face per each line
+ int facnummax; // allocated size of facnum,facfirst vectors
+
+ double *enclosing_radius; // enclosing radii for all bodies
+ double *rounded_radius; // rounded radii for all bodies
+ double *maxerad; // per-type maximum enclosing radius
+
+ void allocate();
+ void body2space(int);
+
+ // sphere-sphere interaction
+ void sphere_against_sphere(int ibody, int jbody, int itype, int jtype,
+ double delx, double dely, double delz, double rsq,
+ double** v, double** f, int evflag);
+ // sphere-edge interaction
+ void sphere_against_edge(int ibody, int jbody, int itype, int jtype,
+ double** x, double** v, double** f, double** torque,
+ double** angmom, int evflag);
+ // sphere-face interaction
+ void sphere_against_face(int ibody, int jbody, int itype, int jtype,
+ double** x, double** v, double** f, double** torque,
+ double** angmom, int evflag);
+ // edge-edge interactions
+ int edge_against_edge(int ibody, int jbody, int itype, int jtype,
+ double** x,Contact* contact_list, int &num_contacts,
+ double &evdwl, double* facc);
+ // edge-face interactions
+ int edge_against_face(int ibody, int jbody, int itype, int jtype,
+ double** x, Contact* contact_list, int &num_contacts,
+ double &evdwl, double* facc);
+
+ // a face vs. a single edge
+ int interaction_face_to_edge(int ibody, int face_index, double* xmi,
+ double rounded_radius_i, int jbody, int edge_index,
+ double* xmj, double rounded_radius_j,
+ int itype, int jtype, double cut_inner,
+ Contact* contact_list, int &num_contacts,
+ double& energy, double* facc);
+ // an edge vs. an edge from another body
+ int interaction_edge_to_edge(int ibody, int edge_index_i, double* xmi,
+ double rounded_radius_i, int jbody, int edge_index_j,
+ double* xmj, double rounded_radius_j,
+ int itype, int jtype, double cut_inner,
+ Contact* contact_list, int &num_contacts,
+ double& energy, double* facc);
+
+ // compute contact forces if contact points are detected
+ void contact_forces(int ibody, int jbody, double *xi, double *xj,
+ double delx, double dely, double delz, double fx, double fy, double fz,
+ double** x, double** v, double** angmom, double** f, double** torque,
+ double* facc);
+
+ // compute force and torque between two bodies given a pair of interacting points
+ void pair_force_and_torque(int ibody, int jbody, double* pi, double* pj,
+ double r, double contact_dist, int itype, int jtype,
+ double** x, double** v, double** f, double** torque,
+ double** angmom, int jflag, double& energy, double* facc);
+
+ // rescale the cohesive forces if a contact area is detected
+ void rescale_cohesive_forces(double** x, double** f, double** torque,
+ Contact* contact_list, int &num_contacts,
+ int itype, int jtype, double* facc);
+
+ // compute the separation between two contacts
+ double contact_separation(const Contact& c1, const Contact& c2);
+
+ // detect the unique contact points (as there may be double counts)
+ void find_unique_contacts(Contact* contact_list, int& num_contacts);
+
+ // accumulate torque to a body given a force at a given point
+ void sum_torque(double* xm, double *x, double fx, double fy, double fz, double* torque);
+
+ // find the intersection point (if any) between an edge and a face
+ int edge_face_intersect(double* x1, double* x2, double* x3, double* a, double* b,
+ double* hi1, double* hi2, double& d1, double& d2,
+ int& inside_a, int& inside_b);
+ // helper functions
+ int opposite_sides(double* n, double* x0, double* a, double* b);
+ void project_pt_plane(const double* q, const double* p,
+ const double* n, double* q_proj, double &d);
+ void project_pt_plane(const double* q, const double* x1, const double* x2,
+ const double* x3, double* q_proj, double &d, int& inside);
+ void project_pt_line(const double* q, const double* xi1, const double* xi2,
+ double* h, double& d, double& t);
+ void inside_polygon(int ibody, int face_index, double* xmi,
+ const double* q1, const double* q2, int& inside1, int& inside2);
+
+ void distance_bt_edges(const double* x1, const double* x2,
+ const double* x3, const double* x4,
+ double* h1, double* h2, double& t1, double& t2, double& r);
+ void total_velocity(double* p, double *xcm, double* vcm, double *angmom,
+ double *inertia, double *quat, double* vi);
+ void sanity_check();
+};
+
+}
+
+#endif
+#endif
+
+/* ERROR/WARNING messages:
+
+E: Illegal ... command
+
+Self-explanatory. Check the input script syntax and compare to the
+documentation for the command. You can use -echo screen as a
+command-line option when running LAMMPS to see the offending line.
+
+E: Incorrect args for pair coefficients
+
+Self-explanatory. Check the input script or data file.
+
+E: Pair body/rounded/polyhedron requires atom style body rounded/polyhedron
+
+Self-explanatory.
+
+E: Pair body requires body style rounded/polyhedron
+
+This pair style is specific to the rounded/polyhedron body style.
+
+*/
diff --git a/src/GPU/gpu_extra.h b/src/GPU/gpu_extra.h
index 56a4f15f1bff5a18ee050badf8acfb420c97b28b..111d13c563a2fc129c1d6e816f38dd7479c8c97a 100644
--- a/src/GPU/gpu_extra.h
+++ b/src/GPU/gpu_extra.h
@@ -58,6 +58,9 @@ namespace GPU_EXTRA {
else if (all_success == -11)
error->all(FLERR,
"Invalid custom OpenCL parameter string.");
+ else if (all_success == -12)
+ error->all(FLERR,
+ "Invalid OpenCL platform ID.");
else
error->all(FLERR,"Unknown error in GPU library");
}
diff --git a/src/KOKKOS/Install.sh b/src/KOKKOS/Install.sh
index 4926a288c4804683bef1fe00c65bd38a66de3be3..321fa34ad7657cb2eda951b32df114ef427091b9 100755
--- a/src/KOKKOS/Install.sh
+++ b/src/KOKKOS/Install.sh
@@ -95,6 +95,8 @@ action domain_kokkos.cpp
action domain_kokkos.h
action fix_deform_kokkos.cpp
action fix_deform_kokkos.h
+action fix_enforce2d_kokkos.cpp
+action fix_enforce2d_kokkos.h
action fix_eos_table_rx_kokkos.cpp fix_eos_table_rx.cpp
action fix_eos_table_rx_kokkos.h fix_eos_table_rx.h
action fix_freeze_kokkos.cpp fix_freeze.cpp
diff --git a/src/KOKKOS/comm_kokkos.cpp b/src/KOKKOS/comm_kokkos.cpp
index f6256275fbfe0c1b53225e9772c645331c0b9277..a9a26c0a3cd3535c4fc88a6c877e9534d198aebb 100644
--- a/src/KOKKOS/comm_kokkos.cpp
+++ b/src/KOKKOS/comm_kokkos.cpp
@@ -405,12 +405,30 @@ void CommKokkos::forward_comm_pair_device(Pair *pair)
// if self, set recv buffer to send buffer
if (sendproc[iswap] != me) {
- if (recvnum[iswap])
- MPI_Irecv(k_buf_recv_pair.view<DeviceType>().data(),nsize*recvnum[iswap],MPI_DOUBLE,
+ double* buf_send_pair;
+ double* buf_recv_pair;
+ if (lmp->kokkos->gpu_direct_flag) {
+ buf_send_pair = k_buf_send_pair.view<DeviceType>().data();
+ buf_recv_pair = k_buf_recv_pair.view<DeviceType>().data();
+ } else {
+ k_buf_send_pair.modify<DeviceType>();
+ k_buf_send_pair.sync<LMPHostType>();
+ buf_send_pair = k_buf_send_pair.h_view.data();
+ buf_recv_pair = k_buf_recv_pair.h_view.data();
+ }
+
+ if (recvnum[iswap]) {
+ MPI_Irecv(buf_recv_pair,nsize*recvnum[iswap],MPI_DOUBLE,
recvproc[iswap],0,world,&request);
+ }
if (sendnum[iswap])
- MPI_Send(k_buf_send_pair.view<DeviceType>().data(),n,MPI_DOUBLE,sendproc[iswap],0,world);
+ MPI_Send(buf_send_pair,n,MPI_DOUBLE,sendproc[iswap],0,world);
if (recvnum[iswap]) MPI_Wait(&request,MPI_STATUS_IGNORE);
+
+ if (!lmp->kokkos->gpu_direct_flag) {
+ k_buf_recv_pair.modify<LMPHostType>();
+ k_buf_recv_pair.sync<DeviceType>();
+ }
} else k_buf_recv_pair = k_buf_send_pair;
// unpack buffer
diff --git a/src/KOKKOS/fix_enforce2d_kokkos.cpp b/src/KOKKOS/fix_enforce2d_kokkos.cpp
new file mode 100644
index 0000000000000000000000000000000000000000..26075b269c1e5ad4b363a750d4e8d3ebf21580ab
--- /dev/null
+++ b/src/KOKKOS/fix_enforce2d_kokkos.cpp
@@ -0,0 +1,168 @@
+/* -*- c++ -*- ----------------------------------------------------------
+ LAMMPS - Large-scale Atomic/Molecular Massively Parallel Simulator
+ http://lammps.sandia.gov, Sandia National Laboratories
+ Steve Plimpton, sjplimp@sandia.gov
+
+ Copyright (2003) Sandia Corporation. Under the terms of Contract
+ DE-AC04-94AL85000 with Sandia Corporation, the U.S. Government retains
+ certain rights in this software. This software is distributed under
+ the GNU General Public License.
+
+ See the README file in the top-level LAMMPS directory.
+------------------------------------------------------------------------- */
+
+/* ----------------------------------------------------------------------
+ Contributing authors: Stefan Paquay & Matthew Peterson (Brandeis University)
+------------------------------------------------------------------------- */
+
+#include "atom_masks.h"
+#include "atom_kokkos.h"
+#include "comm.h"
+#include "error.h"
+#include "fix_enforce2d_kokkos.h"
+
+
+using namespace LAMMPS_NS;
+
+
+template <class DeviceType>
+FixEnforce2DKokkos<DeviceType>::FixEnforce2DKokkos(LAMMPS *lmp, int narg, char **arg) :
+ FixEnforce2D(lmp, narg, arg)
+{
+ kokkosable = 1;
+ atomKK = (AtomKokkos *) atom;
+ execution_space = ExecutionSpaceFromDevice<DeviceType>::space;
+
+ datamask_read = V_MASK | F_MASK | OMEGA_MASK | MASK_MASK
+ | TORQUE_MASK | ANGMOM_MASK;
+
+ datamask_modify = V_MASK | F_MASK | OMEGA_MASK
+ | TORQUE_MASK | ANGMOM_MASK;
+}
+
+
+template <class DeviceType>
+void FixEnforce2DKokkos<DeviceType>::setup(int vflag)
+{
+ post_force(vflag);
+}
+
+
+template <class DeviceType>
+void FixEnforce2DKokkos<DeviceType>::post_force(int vflag)
+{
+ atomKK->sync(execution_space,datamask_read);
+
+ v = atomKK->k_v.view<DeviceType>();
+ f = atomKK->k_f.view<DeviceType>();
+
+ if( atomKK->omega_flag )
+ omega = atomKK->k_omega.view<DeviceType>();
+
+ if( atomKK->angmom_flag )
+ angmom = atomKK->k_angmom.view<DeviceType>();
+
+ if( atomKK->torque_flag )
+ torque = atomKK->k_torque.view<DeviceType>();
+
+
+ mask = atomKK->k_mask.view<DeviceType>();
+
+ int nlocal = atomKK->nlocal;
+ if (igroup == atomKK->firstgroup) nlocal = atomKK->nfirst;
+
+ int flag_mask = 0;
+ if( atomKK->omega_flag ) flag_mask |= 1;
+ if( atomKK->angmom_flag ) flag_mask |= 2;
+ if( atomKK->torque_flag ) flag_mask |= 4;
+
+ copymode = 1;
+ switch( flag_mask ){
+ case 0:{
+ FixEnforce2DKokkosPostForceFunctor<DeviceType,0,0,0> functor(this);
+ Kokkos::parallel_for(nlocal,functor);
+ break;
+ }
+ case 1:{
+ FixEnforce2DKokkosPostForceFunctor<DeviceType,1,0,0> functor(this);
+ Kokkos::parallel_for(nlocal,functor);
+ break;
+ }
+ case 2:{
+ FixEnforce2DKokkosPostForceFunctor<DeviceType,0,1,0> functor(this);
+ Kokkos::parallel_for(nlocal,functor);
+ break;
+ }
+ case 3:{
+ FixEnforce2DKokkosPostForceFunctor<DeviceType,1,1,0> functor(this);
+ Kokkos::parallel_for(nlocal,functor);
+ break;
+ }
+ case 4:{
+ FixEnforce2DKokkosPostForceFunctor<DeviceType,0,0,1> functor(this);
+ Kokkos::parallel_for(nlocal,functor);
+ break;
+ }
+ case 5:{
+ FixEnforce2DKokkosPostForceFunctor<DeviceType,1,0,1> functor(this);
+ Kokkos::parallel_for(nlocal,functor);
+ break;
+ }
+ case 6:{
+ FixEnforce2DKokkosPostForceFunctor<DeviceType,0,1,1> functor(this);
+ Kokkos::parallel_for(nlocal,functor);
+ break;
+ }
+ case 7:{
+ FixEnforce2DKokkosPostForceFunctor<DeviceType,1,1,1> functor(this);
+ Kokkos::parallel_for(nlocal,functor);
+ break;
+ }
+ default:
+ error->all(FLERR, "Flag in fix_enforce2d_kokkos outside of what it should be");
+ }
+ copymode = 0;
+
+ atomKK->modified(execution_space,datamask_modify);
+
+ for (int m = 0; m < nfixlist; m++) {
+ atomKK->sync(flist[m]->execution_space,flist[m]->datamask_read);
+ flist[m]->enforce2d();
+ atomKK->modified(flist[m]->execution_space,flist[m]->datamask_modify);
+ }
+
+}
+
+
+template <class DeviceType>
+template <int omega_flag, int angmom_flag, int torque_flag>
+void FixEnforce2DKokkos<DeviceType>::post_force_item( int i ) const
+{
+ if (mask[i] & groupbit){
+ v(i,2) = 0.0;
+ f(i,2) = 0.0;
+
+ if(omega_flag){
+ omega(i,0) = 0.0;
+ omega(i,1) = 0.0;
+ }
+
+ if(angmom_flag){
+ angmom(i,0) = 0.0;
+ angmom(i,1) = 0.0;
+ }
+
+ if(torque_flag){
+ torque(i,0) = 0.0;
+ torque(i,1) = 0.0;
+ }
+ }
+}
+
+
+namespace LAMMPS_NS {
+template class FixEnforce2DKokkos<LMPDeviceType>;
+#ifdef KOKKOS_HAVE_CUDA
+template class FixEnforce2DKokkos<LMPHostType>;
+#endif
+}
diff --git a/src/KOKKOS/fix_enforce2d_kokkos.h b/src/KOKKOS/fix_enforce2d_kokkos.h
new file mode 100644
index 0000000000000000000000000000000000000000..520a58de04b51fa0547ab4b42796ebb53de4ec93
--- /dev/null
+++ b/src/KOKKOS/fix_enforce2d_kokkos.h
@@ -0,0 +1,84 @@
+/* -*- c++ -*- ----------------------------------------------------------
+ LAMMPS - Large-scale Atomic/Molecular Massively Parallel Simulator
+ http://lammps.sandia.gov, Sandia National Laboratories
+ Steve Plimpton, sjplimp@sandia.gov
+
+ Copyright (2003) Sandia Corporation. Under the terms of Contract
+ DE-AC04-94AL85000 with Sandia Corporation, the U.S. Government retains
+ certain rights in this software. This software is distributed under
+ the GNU General Public License.
+
+ See the README file in the top-level LAMMPS directory.
+------------------------------------------------------------------------- */
+
+#ifdef FIX_CLASS
+
+FixStyle(enforce2d/kk,FixEnforce2DKokkos<LMPDeviceType>)
+FixStyle(enforce2d/kk/device,FixEnforce2DKokkos<LMPDeviceType>)
+FixStyle(enforce2d/kk/host,FixEnforce2DKokkos<LMPHostType>)
+
+#else
+
+#ifndef LMP_FIX_ENFORCE2D_KOKKOS_H
+#define LMP_FIX_ENFORCE2D_KOKKOS_H
+
+#include "fix_enforce2d.h"
+#include "kokkos_type.h"
+
+namespace LAMMPS_NS {
+
+template<class DeviceType>
+class FixEnforce2DKokkos : public FixEnforce2D {
+ public:
+ FixEnforce2DKokkos(class LAMMPS *, int, char **);
+ // ~FixEnforce2DKokkos() {}
+ void setup(int);
+ void post_force(int);
+
+ template <int omega_flag, int angmom_flag, int torque_flag>
+ KOKKOS_INLINE_FUNCTION
+ void post_force_item(const int i) const;
+
+ // void min_setup(int); Kokkos does not support minimization (yet)
+ // void min_post_force(int); Kokkos does not support minimization (yet)
+ // void post_force_respa(int, int, int); No RRESPA support yet.
+
+ private:
+ typename ArrayTypes<DeviceType>::t_v_array v;
+ typename ArrayTypes<DeviceType>::t_f_array f;
+
+ typename ArrayTypes<DeviceType>::t_v_array omega;
+ typename ArrayTypes<DeviceType>::t_v_array angmom;
+ typename ArrayTypes<DeviceType>::t_f_array torque;
+
+ typename ArrayTypes<DeviceType>::t_int_1d mask;
+};
+
+
+template <class DeviceType, int omega_flag, int angmom_flag, int torque_flag>
+struct FixEnforce2DKokkosPostForceFunctor {
+ typedef DeviceType device_type;
+ FixEnforce2DKokkos<DeviceType> c;
+
+ FixEnforce2DKokkosPostForceFunctor(FixEnforce2DKokkos<DeviceType>* c_ptr):
+ c(*c_ptr) {};
+
+ KOKKOS_INLINE_FUNCTION
+ void operator()(const int i) const {
+ c.template post_force_item <omega_flag, angmom_flag, torque_flag>(i);
+ }
+};
+
+
+}
+
+#endif
+#endif
+
+/* ERROR/WARNING messages:
+
+E: Flag in fix_enforce2d_kokkos outside of what it should be
+
+LAMMPS developer-only error.
+
+*/
diff --git a/src/KOKKOS/fix_nh_kokkos.cpp b/src/KOKKOS/fix_nh_kokkos.cpp
index 43b1845f357e04a22382bddc4d6105f2303cbfb5..42d421e92ef85bfc1539c808e61d55f508283b9f 100644
--- a/src/KOKKOS/fix_nh_kokkos.cpp
+++ b/src/KOKKOS/fix_nh_kokkos.cpp
@@ -148,7 +148,7 @@ void FixNHKokkos<DeviceType>::setup(int vflag)
if (pstat_flag) {
double kt = boltz * t_target;
- double nkt = atom->natoms * kt;
+ double nkt = (atom->natoms + 1) * kt;
for (int i = 0; i < 3; i++)
if (p_flag[i])
diff --git a/src/KOKKOS/fix_shardlow_kokkos.cpp b/src/KOKKOS/fix_shardlow_kokkos.cpp
index 70055bf8c9df4fd0f70f32b83e012e9eec0132c9..99e51ebe38e0a154683ff6b5476a467e3fba4941 100644
--- a/src/KOKKOS/fix_shardlow_kokkos.cpp
+++ b/src/KOKKOS/fix_shardlow_kokkos.cpp
@@ -157,7 +157,6 @@ void FixShardlowKokkos<DeviceType>::init()
k_pairDPDE->k_cutsq.template sync<DeviceType>();
d_cutsq = k_pairDPDE->k_cutsq.template view<DeviceType>();
- const double boltz2 = 2.0*force->boltz;
for (int i = 1; i <= ntypes; i++) {
for (int j = i; j <= ntypes; j++) {
F_FLOAT cutone = k_pairDPDE->cut[i][j];
@@ -165,7 +164,7 @@ void FixShardlowKokkos<DeviceType>::init()
else k_params.h_view(i,j).cutinv = FLT_MAX;
k_params.h_view(i,j).halfsigma = 0.5*k_pairDPDE->sigma[i][j];
k_params.h_view(i,j).kappa = k_pairDPDE->kappa[i][j];
- k_params.h_view(i,j).alpha = sqrt(boltz2*k_pairDPDE->kappa[i][j]);
+ k_params.h_view(i,j).alpha = k_pairDPDE->alpha[i][j];
k_params.h_view(j,i) = k_params.h_view(i,j);
diff --git a/src/KOKKOS/gridcomm_kokkos.cpp b/src/KOKKOS/gridcomm_kokkos.cpp
index 847fa5907a9f05cae3f8e4777097bc92029ebd09..64a9d6992f0f56a64e5cbbb3d6fb674929f5ca41 100644
--- a/src/KOKKOS/gridcomm_kokkos.cpp
+++ b/src/KOKKOS/gridcomm_kokkos.cpp
@@ -18,6 +18,7 @@
#include "memory_kokkos.h"
#include "error.h"
#include "kokkos_base.h"
+#include "kokkos.h"
using namespace LAMMPS_NS;
@@ -526,11 +527,28 @@ void GridCommKokkos<DeviceType>::forward_comm(KSpace *kspace, int which)
DeviceType::fence();
if (swap[m].sendproc != me) {
- MPI_Irecv(k_buf2.view<DeviceType>().data(),nforward*swap[m].nunpack,MPI_FFT_SCALAR,
+ FFT_SCALAR* buf1;
+ FFT_SCALAR* buf2;
+ if (lmp->kokkos->gpu_direct_flag) {
+ buf1 = k_buf1.view<DeviceType>().data();
+ buf2 = k_buf2.view<DeviceType>().data();
+ } else {
+ k_buf1.modify<DeviceType>();
+ k_buf1.sync<LMPHostType>();
+ buf1 = k_buf1.h_view.data();
+ buf2 = k_buf2.h_view.data();
+ }
+
+ MPI_Irecv(buf2,nforward*swap[m].nunpack,MPI_FFT_SCALAR,
swap[m].recvproc,0,gridcomm,&request);
- MPI_Send(k_buf1.view<DeviceType>().data(),nforward*swap[m].npack,MPI_FFT_SCALAR,
+ MPI_Send(buf1,nforward*swap[m].npack,MPI_FFT_SCALAR,
swap[m].sendproc,0,gridcomm);
MPI_Wait(&request,MPI_STATUS_IGNORE);
+
+ if (!lmp->kokkos->gpu_direct_flag) {
+ k_buf2.modify<LMPHostType>();
+ k_buf2.sync<DeviceType>();
+ }
}
kspaceKKBase->unpack_forward_kspace_kokkos(which,k_buf2,swap[m].nunpack,k_unpacklist,m);
@@ -559,11 +577,28 @@ void GridCommKokkos<DeviceType>::reverse_comm(KSpace *kspace, int which)
DeviceType::fence();
if (swap[m].recvproc != me) {
- MPI_Irecv(k_buf2.view<DeviceType>().data(),nreverse*swap[m].npack,MPI_FFT_SCALAR,
+ FFT_SCALAR* buf1;
+ FFT_SCALAR* buf2;
+ if (lmp->kokkos->gpu_direct_flag) {
+ buf1 = k_buf1.view<DeviceType>().data();
+ buf2 = k_buf2.view<DeviceType>().data();
+ } else {
+ k_buf1.modify<DeviceType>();
+ k_buf1.sync<LMPHostType>();
+ buf1 = k_buf1.h_view.data();
+ buf2 = k_buf2.h_view.data();
+ }
+
+ MPI_Irecv(buf2,nreverse*swap[m].npack,MPI_FFT_SCALAR,
swap[m].sendproc,0,gridcomm,&request);
- MPI_Send(k_buf1.view<DeviceType>().data(),nreverse*swap[m].nunpack,MPI_FFT_SCALAR,
+ MPI_Send(buf1,nreverse*swap[m].nunpack,MPI_FFT_SCALAR,
swap[m].recvproc,0,gridcomm);
MPI_Wait(&request,MPI_STATUS_IGNORE);
+
+ if (!lmp->kokkos->gpu_direct_flag) {
+ k_buf2.modify<LMPHostType>();
+ k_buf2.sync<DeviceType>();
+ }
}
kspaceKKBase->unpack_reverse_kspace_kokkos(which,k_buf2,swap[m].npack,k_packlist,m);
diff --git a/src/KOKKOS/kokkos.cpp b/src/KOKKOS/kokkos.cpp
index 3bbff6be7e77c93930b23b1bf937c28c1a2afd04..fb6b8d8d45aa5d4e1e582c9b745ec53906aa999b 100644
--- a/src/KOKKOS/kokkos.cpp
+++ b/src/KOKKOS/kokkos.cpp
@@ -11,6 +11,7 @@
See the README file in the top-level LAMMPS directory.
------------------------------------------------------------------------- */
+#include <mpi.h>
#include <cstdio>
#include <cstring>
#include <cstdlib>
@@ -25,6 +26,37 @@
#include "error.h"
#include "memory_kokkos.h"
+#ifdef KOKKOS_HAVE_CUDA
+
+// for detecting GPU-direct support:
+// the function int have_gpu_direct()
+// - returns -1 if GPU-direct support is unknown
+// - returns 0 if no GPU-direct support available
+// - returns 1 if GPU-direct support is available
+
+#define GPU_DIRECT_UNKNOWN static int have_gpu_direct() {return -1;}
+
+// OpenMPI supports detecting GPU-direct as of version 2.0.0
+#if OPEN_MPI
+
+#if (OMPI_MAJOR_VERSION >= 2)
+#include <mpi-ext.h>
+#if defined(MPIX_CUDA_AWARE_SUPPORT)
+static int have_gpu_direct() { return MPIX_Query_cuda_support(); }
+#else
+GPU_DIRECT_UNKNOWN
+#endif
+
+#else // old OpenMPI
+GPU_DIRECT_UNKNOWN
+#endif
+
+#else // unknown MPI library
+GPU_DIRECT_UNKNOWN
+#endif
+
+#endif // KOKKOS_HAVE_CUDA
+
using namespace LAMMPS_NS;
/* ---------------------------------------------------------------------- */
@@ -106,13 +138,32 @@ KokkosLMP::KokkosLMP(LAMMPS *lmp, int narg, char **arg) : Pointers(lmp)
// initialize Kokkos
if (me == 0) {
- if (screen) fprintf(screen," using %d GPU(s)\n",ngpu);
- if (logfile) fprintf(logfile," using %d GPU(s)\n",ngpu);
+ if (screen) fprintf(screen," will use up to %d GPU(s) per node\n",ngpu);
+ if (logfile) fprintf(logfile," will use up to %d GPU(s) per node\n",ngpu);
}
#ifdef KOKKOS_HAVE_CUDA
if (ngpu <= 0)
error->all(FLERR,"Kokkos has been compiled for CUDA but no GPUs are requested");
+
+ // check and warn about GPU-direct availability when using multiple MPI tasks
+
+ int nmpi = 0;
+ MPI_Comm_size(world,&nmpi);
+ if ((nmpi > 1) && (me == 0)) {
+ if ( 1 == have_gpu_direct() ) {
+ ; // all good, nothing to warn about
+ } else if (-1 == have_gpu_direct() ) {
+ error->warning(FLERR,"Kokkos with CUDA assumes GPU-direct is available,"
+ " but cannot determine if this is the case\n try"
+ " '-pk kokkos gpu/direct off' when getting segmentation faults");
+ } else if ( 0 == have_gpu_direct() ) {
+ error->warning(FLERR,"GPU-direct is NOT available, "
+ "using '-pk kokkos gpu/direct off' by default");
+ } else {
+ ; // should never get here
+ }
+ }
#endif
Kokkos::InitArguments args;
@@ -133,6 +184,12 @@ KokkosLMP::KokkosLMP(LAMMPS *lmp, int narg, char **arg) : Pointers(lmp)
exchange_comm_on_host = 0;
forward_comm_on_host = 0;
reverse_comm_on_host = 0;
+ gpu_direct_flag = 1;
+
+#if KOKKOS_USE_CUDA
+ // only if we can safely detect, that GPU-direct is not available, change default
+ if (0 == have_gpu_direct()) gpu_direct_flag = 0;
+#endif
#ifdef KILL_KOKKOS_ON_SIGSEGV
signal(SIGSEGV, my_signal_handler);
@@ -163,6 +220,7 @@ void KokkosLMP::accelerator(int narg, char **arg)
double binsize = 0.0;
exchange_comm_classic = forward_comm_classic = reverse_comm_classic = 0;
exchange_comm_on_host = forward_comm_on_host = reverse_comm_on_host = 0;
+ gpu_direct_flag = 1;
int iarg = 0;
while (iarg < narg) {
@@ -204,6 +262,7 @@ void KokkosLMP::accelerator(int narg, char **arg)
if (iarg+2 > narg) error->all(FLERR,"Illegal package kokkos command");
if (strcmp(arg[iarg+1],"no") == 0) {
exchange_comm_classic = forward_comm_classic = reverse_comm_classic = 1;
+ exchange_comm_on_host = forward_comm_on_host = reverse_comm_on_host = 0;
} else if (strcmp(arg[iarg+1],"host") == 0) {
exchange_comm_classic = forward_comm_classic = reverse_comm_classic = 0;
exchange_comm_on_host = forward_comm_on_host = reverse_comm_on_host = 1;
@@ -245,9 +304,26 @@ void KokkosLMP::accelerator(int narg, char **arg)
reverse_comm_on_host = 0;
} else error->all(FLERR,"Illegal package kokkos command");
iarg += 2;
+ } else if (strcmp(arg[iarg],"gpu/direct") == 0) {
+ if (iarg+2 > narg) error->all(FLERR,"Illegal package kokkos command");
+ if (strcmp(arg[iarg+1],"off") == 0) gpu_direct_flag = 0;
+ else if (strcmp(arg[iarg+1],"on") == 0) gpu_direct_flag = 1;
+ else error->all(FLERR,"Illegal package kokkos command");
+ iarg += 2;
} else error->all(FLERR,"Illegal package kokkos command");
}
+ // if "gpu/direct off" and "comm device", change to "comm host"
+
+ if (!gpu_direct_flag) {
+ if (exchange_comm_classic == 0 && exchange_comm_on_host == 0)
+ exchange_comm_on_host = 1;
+ if (forward_comm_classic == 0 && forward_comm_on_host == 0)
+ forward_comm_on_host = 1;
+ if (reverse_comm_classic == 0 && reverse_comm_on_host == 0)
+ reverse_comm_on_host = 1;
+ }
+
// set newton flags
// set neighbor binsize, same as neigh_modify command
diff --git a/src/KOKKOS/kokkos.h b/src/KOKKOS/kokkos.h
index 846b7254afe5de89f3739c8ef92ba41b83c078a6..cf209c0adb97e10a7bf5b45daa4502b3ad15d46a 100644
--- a/src/KOKKOS/kokkos.h
+++ b/src/KOKKOS/kokkos.h
@@ -34,6 +34,7 @@ class KokkosLMP : protected Pointers {
int num_threads,ngpu;
int numa;
int auto_sync;
+ int gpu_direct_flag;
KokkosLMP(class LAMMPS *, int, char **);
~KokkosLMP();
diff --git a/src/KOKKOS/pair_dpd_fdt_energy_kokkos.cpp b/src/KOKKOS/pair_dpd_fdt_energy_kokkos.cpp
index 63631119b002bb07737e723292a649f36ec7fa8c..3282c9da1e24057e8b8169faf8e525a035cf25f5 100644
--- a/src/KOKKOS/pair_dpd_fdt_energy_kokkos.cpp
+++ b/src/KOKKOS/pair_dpd_fdt_energy_kokkos.cpp
@@ -591,7 +591,7 @@ void PairDPDfdtEnergyKokkos<DeviceType>::operator()(TagPairDPDfdtEnergyComputeNo
// Compute uCond
randnum = rand_gen.normal();
kappa_ij = STACKPARAMS?m_params[itype][jtype].kappa:params(itype,jtype).kappa;
- alpha_ij = sqrt(2.0*boltz*kappa_ij);
+ alpha_ij = STACKPARAMS?m_params[itype][jtype].alpha:params(itype,jtype).alpha;
randPair = alpha_ij*wr*randnum*dtinvsqrt;
uTmp = kappa_ij*(1.0/dpdTheta[i] - 1.0/dpdTheta[j])*wd;
@@ -676,6 +676,7 @@ double PairDPDfdtEnergyKokkos<DeviceType>::init_one(int i, int j)
k_params.h_view(i,j).a0 = a0[i][j];
k_params.h_view(i,j).sigma = sigma[i][j];
k_params.h_view(i,j).kappa = kappa[i][j];
+ k_params.h_view(i,j).alpha = alpha[i][j];
k_params.h_view(j,i) = k_params.h_view(i,j);
if(i<MAX_TYPES_STACKPARAMS+1 && j<MAX_TYPES_STACKPARAMS+1) {
m_params[i][j] = m_params[j][i] = k_params.h_view(i,j);
diff --git a/src/KOKKOS/pair_dpd_fdt_energy_kokkos.h b/src/KOKKOS/pair_dpd_fdt_energy_kokkos.h
index 81aba715c5b308e5a3d87030d36f3669f0d59e5a..9d316df1524faad52fce1d96c8cadedfe553248d 100644
--- a/src/KOKKOS/pair_dpd_fdt_energy_kokkos.h
+++ b/src/KOKKOS/pair_dpd_fdt_energy_kokkos.h
@@ -88,10 +88,10 @@ class PairDPDfdtEnergyKokkos : public PairDPDfdtEnergy {
struct params_dpd {
KOKKOS_INLINE_FUNCTION
- params_dpd(){cut=0;a0=0;sigma=0;kappa=0;};
+ params_dpd(){cut=0;a0=0;sigma=0;kappa=0;alpha=0;};
KOKKOS_INLINE_FUNCTION
- params_dpd(int i){cut=0;a0=0;sigma=0;kappa=0;};
- F_FLOAT cut,a0,sigma,kappa;
+ params_dpd(int i){cut=0;a0=0;sigma=0;kappa=0;alpha=0;};
+ F_FLOAT cut,a0,sigma,kappa,alpha;
};
DAT::tdual_efloat_1d k_duCond,k_duMech;
diff --git a/src/KOKKOS/pair_reaxc_kokkos.cpp b/src/KOKKOS/pair_reaxc_kokkos.cpp
index bb9f8ab417fab2f659f17f18b58ad38b51861279..e2e2e6f6de96197435a3bcb4dcca3af53ed3ec45 100644
--- a/src/KOKKOS/pair_reaxc_kokkos.cpp
+++ b/src/KOKKOS/pair_reaxc_kokkos.cpp
@@ -343,6 +343,7 @@ void PairReaxCKokkos<DeviceType>::init_md()
swa = control->nonb_low;
swb = control->nonb_cut;
+ enobondsflag = control->enobondsflag;
if (fabs(swa) > 0.01 )
error->warning(FLERR,"Warning: non-zero lower Taper-radius cutoff");
@@ -2272,12 +2273,12 @@ void PairReaxCKokkos<DeviceType>::operator()(PairReaxComputeMulti2<NEIGHFLAG,EVF
int numbonds = d_bo_num[i];
e_lp = 0.0;
- if (numbonds > 0 || control->enobondsflag)
+ if (numbonds > 0 || enobondsflag)
e_lp = p_lp2 * d_Delta_lp[i] * inv_expvd2;
const F_FLOAT dElp = p_lp2 * inv_expvd2 + 75.0 * p_lp2 * d_Delta_lp[i] * expvd2 * inv_expvd2*inv_expvd2;
const F_FLOAT CElp = dElp * d_dDelta_lp[i];
- if (numbonds > 0 || control->enobondsflag)
+ if (numbonds > 0 || enobondsflag)
a_CdDelta[i] += CElp;
if (eflag) ev.ereax[0] += e_lp;
@@ -2314,7 +2315,7 @@ void PairReaxCKokkos<DeviceType>::operator()(PairReaxComputeMulti2<NEIGHFLAG,EVF
const F_FLOAT inv_exp_ovun8 = 1.0 / (1.0 + exp_ovun8);
e_un = 0;
- if (numbonds > 0 || control->enobondsflag)
+ if (numbonds > 0 || enobondsflag)
e_un = -p_ovun5 * (1.0 - exp_ovun6) * inv_exp_ovun2n * inv_exp_ovun8;
if (eflag) ev.ereax[2] += e_un;
@@ -2334,7 +2335,7 @@ void PairReaxCKokkos<DeviceType>::operator()(PairReaxComputeMulti2<NEIGHFLAG,EVF
// multibody forces
a_CdDelta[i] += CEover3;
- if (numbonds > 0 || control->enobondsflag)
+ if (numbonds > 0 || enobondsflag)
a_CdDelta[i] += CEunder3;
const int j_start = d_bo_first[i];
diff --git a/src/KOKKOS/pair_reaxc_kokkos.h b/src/KOKKOS/pair_reaxc_kokkos.h
index 5175e274a8998f45ee6d8f40116f1bf47f671af3..5c96d44618361ca3828ba26ceb1738a1dac4de51 100644
--- a/src/KOKKOS/pair_reaxc_kokkos.h
+++ b/src/KOKKOS/pair_reaxc_kokkos.h
@@ -427,7 +427,7 @@ class PairReaxCKokkos : public PairReaxC {
friend void pair_virial_fdotr_compute<PairReaxCKokkos>(PairReaxCKokkos*);
- int bocnt,hbcnt;
+ int bocnt,hbcnt,enobondsflag;
typedef LR_lookup_table_kk<DeviceType> LR_lookup_table_kk_DT;
diff --git a/src/KSPACE/fft3d.cpp b/src/KSPACE/fft3d.cpp
index 6da7f197ee7024bb3a6457f33a21138ad24d0a73..7d3c8c83f2a785e77fe84a10d0658bde2d7a53e6 100644
--- a/src/KSPACE/fft3d.cpp
+++ b/src/KSPACE/fft3d.cpp
@@ -14,7 +14,7 @@
/* ----------------------------------------------------------------------
Contributing authors: Jim Shepherd (GA Tech) added SGI SCSL support
Axel Kohlmeyer (Temple U) added support for
- FFTW3, KISSFFT, Dfti/MKL, and ACML.
+ FFTW3, KISS FFT, Dfti/MKL, and ACML.
Phil Blood (PSC) added single precision FFT.
Paul Coffman (IBM) added MPI collectives remap
------------------------------------------------------------------------- */
@@ -26,7 +26,7 @@
#include "fft3d.h"
#include "remap.h"
-#ifdef FFT_KISSFFT
+#ifdef FFT_KISS
/* include kissfft implementation */
#include "kissfft.h"
#endif
@@ -104,11 +104,13 @@ void fft_3d(FFT_DATA *in, FFT_DATA *out, int flag, struct fft_plan_3d *plan)
DftiComputeForward(plan->handle_fast,data);
else
DftiComputeBackward(plan->handle_fast,data);
+ /*
#elif defined(FFT_FFTW2)
if (flag == -1)
fftw(plan->plan_fast_forward,total/length,data,1,length,NULL,0,0);
else
- fftw(plan->plan_fast_backward,total/length,data,1,length,NULL,0,0);
+ fftw(plan->plan_fast_backward,total/length,data,1,length,NULL,0,0);
+ */
#elif defined(FFT_FFTW3)
if (flag == -1)
theplan=plan->plan_fast_forward;
@@ -143,11 +145,13 @@ void fft_3d(FFT_DATA *in, FFT_DATA *out, int flag, struct fft_plan_3d *plan)
DftiComputeForward(plan->handle_mid,data);
else
DftiComputeBackward(plan->handle_mid,data);
+ /*
#elif defined(FFT_FFTW2)
if (flag == -1)
fftw(plan->plan_mid_forward,total/length,data,1,length,NULL,0,0);
else
fftw(plan->plan_mid_backward,total/length,data,1,length,NULL,0,0);
+ */
#elif defined(FFT_FFTW3)
if (flag == -1)
theplan=plan->plan_mid_forward;
@@ -182,11 +186,13 @@ void fft_3d(FFT_DATA *in, FFT_DATA *out, int flag, struct fft_plan_3d *plan)
DftiComputeForward(plan->handle_slow,data);
else
DftiComputeBackward(plan->handle_slow,data);
+ /*
#elif defined(FFT_FFTW2)
if (flag == -1)
fftw(plan->plan_slow_forward,total/length,data,1,length,NULL,0,0);
else
fftw(plan->plan_slow_backward,total/length,data,1,length,NULL,0,0);
+ */
#elif defined(FFT_FFTW3)
if (flag == -1)
theplan=plan->plan_slow_forward;
@@ -520,6 +526,7 @@ struct fft_plan_3d *fft_3d_create_plan(
(out_khi-out_klo+1);
}
+ /*
#elif defined(FFT_FFTW2)
plan->plan_fast_forward =
@@ -561,6 +568,7 @@ struct fft_plan_3d *fft_3d_create_plan(
plan->normnum = (out_ihi-out_ilo+1) * (out_jhi-out_jlo+1) *
(out_khi-out_klo+1);
}
+ */
#elif defined(FFT_FFTW3)
plan->plan_fast_forward =
@@ -660,6 +668,7 @@ void fft_3d_destroy_plan(struct fft_plan_3d *plan)
DftiFreeDescriptor(&(plan->handle_fast));
DftiFreeDescriptor(&(plan->handle_mid));
DftiFreeDescriptor(&(plan->handle_slow));
+ /*
#elif defined(FFT_FFTW2)
if (plan->plan_slow_forward != plan->plan_fast_forward &&
plan->plan_slow_forward != plan->plan_mid_forward) {
@@ -672,6 +681,7 @@ void fft_3d_destroy_plan(struct fft_plan_3d *plan)
}
fftw_destroy_plan(plan->plan_fast_forward);
fftw_destroy_plan(plan->plan_fast_backward);
+ */
#elif defined(FFT_FFTW3)
FFTW_API(destroy_plan)(plan->plan_slow_forward);
FFTW_API(destroy_plan)(plan->plan_slow_backward);
@@ -809,6 +819,7 @@ void fft_1d_only(FFT_DATA *data, int nsize, int flag, struct fft_plan_3d *plan)
DftiComputeBackward(plan->handle_mid,data);
DftiComputeBackward(plan->handle_slow,data);
}
+ /*
#elif defined(FFT_FFTW2)
if (flag == -1) {
fftw(plan->plan_fast_forward,total1/length1,data,1,0,NULL,0,0);
@@ -819,6 +830,7 @@ void fft_1d_only(FFT_DATA *data, int nsize, int flag, struct fft_plan_3d *plan)
fftw(plan->plan_mid_backward,total2/length2,data,1,0,NULL,0,0);
fftw(plan->plan_slow_backward,total3/length3,data,1,0,NULL,0,0);
}
+ */
#elif defined(FFT_FFTW3)
FFTW_API(plan) theplan;
if (flag == -1)
diff --git a/src/KSPACE/fft3d.h b/src/KSPACE/fft3d.h
index 9a9caaef2626b66d3a6666556d39a8ab7d9658b5..a51818d986f6f4b5a9e5c2e2ead828f04b7acb86 100644
--- a/src/KSPACE/fft3d.h
+++ b/src/KSPACE/fft3d.h
@@ -24,8 +24,8 @@ typedef float FFT_SCALAR;
typedef double FFT_SCALAR;
#endif
+// if user set FFTW, it means FFTW3
-// set default fftw library. switch to FFT_FFTW3 when convenient.
#ifdef FFT_FFTW
#define FFT_FFTW3
#endif
@@ -41,13 +41,13 @@ typedef double FFT_SCALAR;
typedef float _Complex FFT_DATA;
#define FFT_MKL_PREC DFTI_SINGLE
-#elif defined(FFT_FFTW2)
-#if defined(FFTW_SIZE)
-#include "sfftw.h"
-#else
-#include "fftw.h"
-#endif
-typedef FFTW_COMPLEX FFT_DATA;
+//#elif defined(FFT_FFTW2)
+//#if defined(FFTW_SIZE)
+//#include "sfftw.h"
+//#else
+//#include "fftw.h"
+//#endif
+//typedef FFTW_COMPLEX FFT_DATA;
#elif defined(FFT_FFTW3)
#include "fftw3.h"
@@ -57,8 +57,9 @@ typedef fftwf_complex FFT_DATA;
#else
/* use a stripped down version of kiss fft as default fft */
-#ifndef FFT_KISSFFT
-#define FFT_KISSFFT
+
+#ifndef FFT_KISS
+#define FFT_KISS
#endif
#define kiss_fft_scalar float
typedef struct {
@@ -81,13 +82,13 @@ typedef struct kiss_fft_state* kiss_fft_cfg;
typedef double _Complex FFT_DATA;
#define FFT_MKL_PREC DFTI_DOUBLE
-#elif defined(FFT_FFTW2)
-#if defined(FFTW_SIZE)
-#include "dfftw.h"
-#else
-#include "fftw.h"
-#endif
-typedef FFTW_COMPLEX FFT_DATA;
+//#elif defined(FFT_FFTW2)
+//#if defined(FFTW_SIZE)
+//#include "dfftw.h"
+//#else
+//#include "fftw.h"
+//#endif
+//typedef FFTW_COMPLEX FFT_DATA;
#elif defined(FFT_FFTW3)
#include "fftw3.h"
@@ -97,8 +98,8 @@ typedef fftw_complex FFT_DATA;
#else
/* use a stripped down version of kiss fft as default fft */
-#ifndef FFT_KISSFFT
-#define FFT_KISSFFT
+#ifndef FFT_KISS
+#define FFT_KISS
#endif
#define kiss_fft_scalar double
typedef struct {
@@ -138,13 +139,13 @@ struct fft_plan_3d {
DFTI_DESCRIPTOR *handle_fast;
DFTI_DESCRIPTOR *handle_mid;
DFTI_DESCRIPTOR *handle_slow;
-#elif defined(FFT_FFTW2)
- fftw_plan plan_fast_forward;
- fftw_plan plan_fast_backward;
- fftw_plan plan_mid_forward;
- fftw_plan plan_mid_backward;
- fftw_plan plan_slow_forward;
- fftw_plan plan_slow_backward;
+//#elif defined(FFT_FFTW2)
+// fftw_plan plan_fast_forward;
+// fftw_plan plan_fast_backward;
+// fftw_plan plan_mid_forward;
+// fftw_plan plan_mid_backward;
+//fftw_plan plan_slow_forward;
+//fftw_plan plan_slow_backward;
#elif defined(FFT_FFTW3)
FFTW_API(plan) plan_fast_forward;
FFTW_API(plan) plan_fast_backward;
@@ -152,7 +153,7 @@ struct fft_plan_3d {
FFTW_API(plan) plan_mid_backward;
FFTW_API(plan) plan_slow_forward;
FFTW_API(plan) plan_slow_backward;
-#elif defined(FFT_KISSFFT)
+#elif defined(FFT_KISS)
kiss_fft_cfg cfg_fast_forward;
kiss_fft_cfg cfg_fast_backward;
kiss_fft_cfg cfg_mid_forward;
diff --git a/src/KSPACE/kissfft.h b/src/KSPACE/kissfft.h
index 4e15f494a972f817a23208d53b6d5c80e1f121ad..c95b648dcb2213c100e8f82a06cdbaf676af0f7d 100644
--- a/src/KSPACE/kissfft.h
+++ b/src/KSPACE/kissfft.h
@@ -13,6 +13,7 @@
changes 2008-2011 by Axel Kohlmeyer <akohlmey@gmail.com>
*/
+
#ifndef LMP_FFT_KISSFFT
#define LMP_FFT_KISSFFT
diff --git a/src/MAKE/MACHINES/Makefile.theta b/src/MAKE/MACHINES/Makefile.theta
new file mode 100644
index 0000000000000000000000000000000000000000..cad5a03b420274d6f99eed1f2a730ee671638eb9
--- /dev/null
+++ b/src/MAKE/MACHINES/Makefile.theta
@@ -0,0 +1,133 @@
+# knl = Flags for Knights Landing Xeon Phi Processor,Intel Compiler/MPI,MKL FFT
+# module load perftools-base perftools
+# make theta -j 8
+# pat_build -g mpi -u ./lmp_theta
+
+SHELL = /bin/sh
+
+# ---------------------------------------------------------------------
+# compiler/linker settings
+# specify flags and libraries needed for your compiler
+
+CC = CC -mkl
+#OPTFLAGS = -O0
+OPTFLAGS = -xMIC-AVX512 -O3 -fp-model fast=2 -no-prec-div -qoverride-limits
+CCFLAGS = -g -qopenmp -DLAMMPS_MEMALIGN=64 -qno-offload \
+ -fno-alias -ansi-alias -restrict $(OPTFLAGS)
+#CCFLAGS += -DLMP_INTEL_NO_TBB
+#CCFLAGS += -DLAMMPS_BIGBIG
+#CCFLAGS += -D_USE_PAPI
+#CCFLAGS += -D_USE_CRAYPAT_API
+SHFLAGS = -fPIC
+DEPFLAGS = -M
+
+LINK = $(CC)
+LINKFLAGS = -g -qopenmp $(OPTFLAGS)
+LINKFLAGS += -dynamic
+LIB =
+#LIB += -L${TBBROOT}/lib/intel64/gcc4.7 -ltbbmalloc
+LIB += -ltbbmalloc
+#LIB += /soft/debuggers/forge-7.0-2017-02-16/lib/64/libdmallocthcxx.a -zmuldefs
+SIZE = size
+
+ARCHIVE = ar
+ARFLAGS = -rc
+SHLIBFLAGS = -shared
+
+# ---------------------------------------------------------------------
+# LAMMPS-specific settings, all OPTIONAL
+# specify settings for LAMMPS features you will use
+# if you change any -D setting, do full re-compile after "make clean"
+
+# LAMMPS ifdef settings
+# see possible settings in Section 2.2 (step 4) of manual
+
+LMP_INC = -DLAMMPS_GZIP #-DLAMMPS_JPEG
+
+# MPI library
+# see discussion in Section 2.2 (step 5) of manual
+# MPI wrapper compiler/linker can provide this info
+# can point to dummy MPI library in src/STUBS as in Makefile.serial
+# use -D MPICH and OMPI settings in INC to avoid C++ lib conflicts
+# INC = path for mpi.h, MPI compiler settings
+# PATH = path for MPI library
+# LIB = name of MPI library
+
+MPI_INC = -DMPICH_SKIP_MPICXX -DOMPI_SKIP_MPICXX=1
+MPI_PATH =
+MPI_LIB =
+
+# FFT library
+# see discussion in Section 2.2 (step 6) of manaul
+# can be left blank to use provided KISS FFT library
+# INC = -DFFT setting, e.g. -DFFT_FFTW, FFT compiler settings
+# PATH = path for FFT library
+# LIB = name of FFT library
+
+FFT_INC = -DFFT_MKL -DFFT_SINGLE
+FFT_PATH =
+FFT_LIB = -L$(MKLROOT)/lib/intel64/ -Wl,--start-group -lmkl_intel_ilp64 \
+ -lmkl_intel_thread -lmkl_core -Wl,--end-group
+
+# JPEG and/or PNG library
+# see discussion in Section 2.2 (step 7) of manual
+# only needed if -DLAMMPS_JPEG or -DLAMMPS_PNG listed with LMP_INC
+# INC = path(s) for jpeglib.h and/or png.h
+# PATH = path(s) for JPEG library and/or PNG library
+# LIB = name(s) of JPEG library and/or PNG library
+
+JPG_INC =
+JPG_PATH =
+JPG_LIB =
+
+# ---------------------------------------------------------------------
+# build rules and dependencies
+# do not edit this section
+
+include Makefile.package.settings
+include Makefile.package
+
+EXTRA_INC = $(LMP_INC) $(PKG_INC) $(MPI_INC) $(FFT_INC) $(JPG_INC) $(PKG_SYSINC)
+EXTRA_PATH = $(PKG_PATH) $(MPI_PATH) $(FFT_PATH) $(JPG_PATH) $(PKG_SYSPATH)
+EXTRA_LIB = $(PKG_LIB) $(MPI_LIB) $(FFT_LIB) $(JPG_LIB) $(PKG_SYSLIB)
+
+# Path to src files
+
+vpath %.cpp ..
+vpath %.h ..
+
+# Link target
+
+$(EXE): $(OBJ)
+ $(LINK) $(LINKFLAGS) $(EXTRA_PATH) $(OBJ) $(EXTRA_LIB) $(LIB) -o $(EXE)
+ $(SIZE) $(EXE)
+
+# Library targets
+
+lib: $(OBJ)
+ $(ARCHIVE) $(ARFLAGS) $(EXE) $(OBJ)
+
+shlib: $(OBJ)
+ $(CC) $(CCFLAGS) $(SHFLAGS) $(SHLIBFLAGS) $(EXTRA_PATH) -o $(EXE) \
+ $(OBJ) $(EXTRA_LIB) $(LIB)
+
+# Compilation rules
+
+%.o:%.cpp
+ $(CC) $(CCFLAGS) $(SHFLAGS) $(EXTRA_INC) -c $<
+
+%.d:%.cpp
+ $(CC) $(CCFLAGS) $(EXTRA_INC) $(DEPFLAGS) $< > $@
+
+%.o:%.cu
+ $(CC) $(CCFLAGS) $(SHFLAGS) $(EXTRA_INC) -c $<
+
+# Individual dependencies
+
+depend : fastdep.exe $(SRC)
+ @./fastdep.exe $(EXTRA_INC) -- $^ > .depend || exit 1
+
+fastdep.exe: ../DEPEND/fastdep.c
+ icc -O -o $@ $<
+
+sinclude .depend
diff --git a/src/MANYBODY/pair_eam_cd.cpp b/src/MANYBODY/pair_eam_cd.cpp
new file mode 100644
index 0000000000000000000000000000000000000000..66ebad6244a9d16b939bfb61c63862742e709cc8
--- /dev/null
+++ b/src/MANYBODY/pair_eam_cd.cpp
@@ -0,0 +1,677 @@
+/* ----------------------------------------------------------------------
+ LAMMPS - Large-scale Atomic/Molecular Massively Parallel Simulator
+ http://lammps.sandia.gov, Sandia National Laboratories
+ Steve Plimpton, sjplimp@sandia.gov
+
+ Copyright (2003) Sandia Corporation. Under the terms of Contract
+ DE-AC04-94AL85000 with Sandia Corporation, the U.S. Government retains
+ certain rights in this software. This software is distributed under
+ the GNU General Public License.
+
+ See the README file in the top-level LAMMPS directory.
+------------------------------------------------------------------------- */
+
+/* ----------------------------------------------------------------------
+ Contributing author: Alexander Stukowski
+ Technical University of Darmstadt,
+ Germany Department of Materials Science
+------------------------------------------------------------------------- */
+
+#include <cmath>
+#include <cstdio>
+#include <cstdlib>
+#include <cstring>
+#include "pair_eam_cd.h"
+#include "atom.h"
+#include "force.h"
+#include "comm.h"
+#include "neighbor.h"
+#include "neigh_list.h"
+#include "memory.h"
+#include "error.h"
+
+using namespace LAMMPS_NS;
+
+#define ASSERT(cond)
+#define MAXLINE 1024 // This sets the maximum line length in EAM input files.
+
+PairEAMCD::PairEAMCD(LAMMPS *lmp, int _cdeamVersion)
+ : PairEAM(lmp), PairEAMAlloy(lmp), cdeamVersion(_cdeamVersion)
+{
+ single_enable = 0;
+ restartinfo = 0;
+
+ rhoB = NULL;
+ D_values = NULL;
+ hcoeff = NULL;
+
+ // Set communication buffer sizes needed by this pair style.
+
+ if (cdeamVersion == 1) {
+ comm_forward = 4;
+ comm_reverse = 3;
+ } else if (cdeamVersion == 2) {
+ comm_forward = 3;
+ comm_reverse = 2;
+ } else {
+ error->all(FLERR,"Invalid eam/cd potential version.");
+ }
+}
+
+PairEAMCD::~PairEAMCD()
+{
+ memory->destroy(rhoB);
+ memory->destroy(D_values);
+ if (hcoeff) delete[] hcoeff;
+}
+
+void PairEAMCD::compute(int eflag, int vflag)
+{
+ int i,j,ii,jj,inum,jnum,itype,jtype;
+ double xtmp,ytmp,ztmp,delx,dely,delz,evdwl,fpair;
+ double rsq,rhoip,rhojp,recip,phi;
+ int *ilist,*jlist,*numneigh,**firstneigh;
+
+ evdwl = 0.0;
+ if (eflag || vflag) ev_setup(eflag,vflag);
+ else evflag = vflag_fdotr = eflag_global = eflag_atom = 0;
+
+ // Grow per-atom arrays if necessary
+
+ if (atom->nmax > nmax) {
+ memory->destroy(rho);
+ memory->destroy(fp);
+ memory->destroy(rhoB);
+ memory->destroy(D_values);
+ nmax = atom->nmax;
+ memory->create(rho,nmax,"pair:rho");
+ memory->create(rhoB,nmax,"pair:rhoB");
+ memory->create(fp,nmax,"pair:fp");
+ memory->create(D_values,nmax,"pair:D_values");
+ }
+
+ double **x = atom->x;
+ double **f = atom->f;
+ int *type = atom->type;
+ int nlocal = atom->nlocal;
+ int newton_pair = force->newton_pair;
+
+ inum = list->inum;
+ ilist = list->ilist;
+ numneigh = list->numneigh;
+ firstneigh = list->firstneigh;
+
+ // Zero out per-atom arrays.
+
+ int m = nlocal + atom->nghost;
+ for (i = 0; i < m; i++) {
+ rho[i] = 0.0;
+ rhoB[i] = 0.0;
+ D_values[i] = 0.0;
+ }
+
+ // Stage I
+
+ // Compute rho and rhoB at each local atom site.
+
+ // Additionally calculate the D_i values here if we are using the
+ // one-site formulation. For the two-site formulation we have to
+ // calculate the D values in an extra loop (Stage II).
+
+ for (ii = 0; ii < inum; ii++) {
+ i = ilist[ii];
+ xtmp = x[i][0];
+ ytmp = x[i][1];
+ ztmp = x[i][2];
+ itype = type[i];
+ jlist = firstneigh[i];
+ jnum = numneigh[i];
+
+ for (jj = 0; jj < jnum; jj++) {
+ j = jlist[jj];
+ j &= NEIGHMASK;
+
+ delx = xtmp - x[j][0];
+ dely = ytmp - x[j][1];
+ delz = ztmp - x[j][2];
+ rsq = delx*delx + dely*dely + delz*delz;
+
+ if (rsq < cutforcesq) {
+ jtype = type[j];
+ double r = sqrt(rsq);
+ const EAMTableIndex index = radiusToTableIndex(r);
+ double localrho = RhoOfR(index, jtype, itype);
+ rho[i] += localrho;
+ if (jtype == speciesB) rhoB[i] += localrho;
+ if (newton_pair || j < nlocal) {
+ localrho = RhoOfR(index, itype, jtype);
+ rho[j] += localrho;
+ if (itype == speciesB) rhoB[j] += localrho;
+ }
+
+ if (cdeamVersion == 1 && itype != jtype) {
+
+ // Note: if the i-j interaction is not concentration dependent (because either
+ // i or j are not species A or B) then its contribution to D_i and D_j should
+ // be ignored.
+ // This if-clause is only required for a ternary.
+
+ if ((itype == speciesA && jtype == speciesB)
+ || (jtype == speciesA && itype == speciesB)) {
+ double Phi_AB = PhiOfR(index, itype, jtype, 1.0 / r);
+ D_values[i] += Phi_AB;
+ if (newton_pair || j < nlocal)
+ D_values[j] += Phi_AB;
+ }
+ }
+ }
+ }
+ }
+
+ // Communicate and sum densities.
+
+ if (newton_pair) {
+ communicationStage = 1;
+ comm->reverse_comm_pair(this);
+ }
+
+ // fp = derivative of embedding energy at each atom
+ // phi = embedding energy at each atom
+
+ for (ii = 0; ii < inum; ii++) {
+ i = ilist[ii];
+ EAMTableIndex index = rhoToTableIndex(rho[i]);
+ fp[i] = FPrimeOfRho(index, type[i]);
+ if (eflag) {
+ phi = FofRho(index, type[i]);
+ if (eflag_global) eng_vdwl += phi;
+ if (eflag_atom) eatom[i] += phi;
+ }
+ }
+
+ // Communicate derivative of embedding function and densities
+ // and D_values (this for one-site formulation only).
+
+ communicationStage = 2;
+ comm->forward_comm_pair(this);
+
+ // The electron densities may not drop to zero because then the
+ // concentration would no longer be defined. But the concentration
+ // is not needed anyway if there is no interaction with another atom,
+ // which is the case if the electron density is exactly zero.
+ // That's why the following lines have been commented out.
+ //
+ //for (i = 0; i < nlocal + atom->nghost; i++) {
+ // if (rho[i] == 0 && (type[i] == speciesA || type[i] == speciesB))
+ // error->one(FLERR,"CD-EAM potential routine: Detected atom with zero electron density.");
+ //}
+
+ // Stage II
+ // This is only required for the original two-site formulation of the CD-EAM potential.
+
+ if (cdeamVersion == 2) {
+
+ // Compute intermediate value D_i for each atom.
+
+ for (ii = 0; ii < inum; ii++) {
+ i = ilist[ii];
+ xtmp = x[i][0];
+ ytmp = x[i][1];
+ ztmp = x[i][2];
+ itype = type[i];
+ jlist = firstneigh[i];
+ jnum = numneigh[i];
+
+ // This code line is required for ternary alloys.
+
+ if (itype != speciesA && itype != speciesB) continue;
+
+ double x_i = rhoB[i] / rho[i]; // Concentration at atom i.
+
+ for (jj = 0; jj < jnum; jj++) {
+ j = jlist[jj];
+ j &= NEIGHMASK;
+ jtype = type[j];
+ if (itype == jtype) continue;
+
+ // This code line is required for ternary alloys.
+
+ if (jtype != speciesA && jtype != speciesB) continue;
+
+ delx = xtmp - x[j][0];
+ dely = ytmp - x[j][1];
+ delz = ztmp - x[j][2];
+ rsq = delx*delx + dely*dely + delz*delz;
+
+ if (rsq < cutforcesq) {
+ double r = sqrt(rsq);
+ const EAMTableIndex index = radiusToTableIndex(r);
+
+ // The concentration independent part of the cross pair potential.
+
+ double Phi_AB = PhiOfR(index, itype, jtype, 1.0 / r);
+
+ // Average concentration of two sites
+
+ double x_ij = 0.5 * (x_i + rhoB[j]/rho[j]);
+
+ // Calculate derivative of h(x_ij) polynomial function.
+
+ double h_prime = evalHprime(x_ij);
+
+ D_values[i] += h_prime * Phi_AB / (2.0 * rho[i] * rho[i]);
+ if (newton_pair || j < nlocal)
+ D_values[j] += h_prime * Phi_AB / (2.0 * rho[j] * rho[j]);
+ }
+ }
+ }
+
+ // Communicate and sum D values.
+
+ if (newton_pair) {
+ communicationStage = 3;
+ comm->reverse_comm_pair(this);
+ }
+ communicationStage = 4;
+ comm->forward_comm_pair(this);
+ }
+
+ // Stage III
+
+ // Compute force acting on each atom.
+
+ for (ii = 0; ii < inum; ii++) {
+ i = ilist[ii];
+ xtmp = x[i][0];
+ ytmp = x[i][1];
+ ztmp = x[i][2];
+ itype = type[i];
+
+ jlist = firstneigh[i];
+ jnum = numneigh[i];
+
+ // Concentration at site i
+ // The value -1 indicates: no concentration dependence for all interactions of atom i.
+ // It will be replaced by the concentration at site i if atom i is either A or B.
+
+ double x_i = -1.0;
+ double D_i, h_prime_i;
+
+ // This if-clause is only required for ternary alloys.
+
+ if ((itype == speciesA || itype == speciesB) && rho[i] != 0.0) {
+
+ // Compute local concentration at site i.
+
+ x_i = rhoB[i]/rho[i];
+ ASSERT(x_i >= 0 && x_i<=1.0);
+
+ if (cdeamVersion == 1) {
+
+ // Calculate derivative of h(x_i) polynomial function.
+
+ h_prime_i = evalHprime(x_i);
+ D_i = D_values[i] * h_prime_i / (2.0 * rho[i] * rho[i]);
+ } else if (cdeamVersion == 2) {
+ D_i = D_values[i];
+ } else {
+ ASSERT(false);
+ }
+ }
+
+ for (jj = 0; jj < jnum; jj++) {
+ j = jlist[jj];
+ j &= NEIGHMASK;
+
+ delx = xtmp - x[j][0];
+ dely = ytmp - x[j][1];
+ delz = ztmp - x[j][2];
+ rsq = delx*delx + dely*dely + delz*delz;
+
+ if (rsq < cutforcesq) {
+ jtype = type[j];
+ double r = sqrt(rsq);
+ const EAMTableIndex index = radiusToTableIndex(r);
+
+ // rhoip = derivative of (density at atom j due to atom i)
+ // rhojp = derivative of (density at atom i due to atom j)
+ // psip needs both fp[i] and fp[j] terms since r_ij appears in two
+ // terms of embed eng: Fi(sum rho_ij) and Fj(sum rho_ji)
+ // hence embed' = Fi(sum rho_ij) rhojp + Fj(sum rho_ji) rhoip
+
+ rhoip = RhoPrimeOfR(index, itype, jtype);
+ rhojp = RhoPrimeOfR(index, jtype, itype);
+ fpair = fp[i]*rhojp + fp[j]*rhoip;
+ recip = 1.0/r;
+
+ // The value -1 indicates: no concentration dependence for this
+ // i-j pair because atom j is not of species A nor B.
+
+ double x_j = -1;
+
+ // This code line is required for ternary alloy.
+
+ if (jtype == speciesA || jtype == speciesB) {
+ ASSERT(rho[i] != 0.0);
+ ASSERT(rho[j] != 0.0);
+
+ // Compute local concentration at site j.
+
+ x_j = rhoB[j]/rho[j];
+ ASSERT(x_j >= 0 && x_j<=1.0);
+
+ double D_j=0.0;
+ if (cdeamVersion == 1) {
+
+ // Calculate derivative of h(x_j) polynomial function.
+
+ double h_prime_j = evalHprime(x_j);
+ D_j = D_values[j] * h_prime_j / (2.0 * rho[j] * rho[j]);
+ } else if (cdeamVersion == 2) {
+ D_j = D_values[j];
+ } else {
+ ASSERT(false);
+ }
+ double t2 = -rhoB[j];
+ if (itype == speciesB) t2 += rho[j];
+ fpair += D_j * rhoip * t2;
+ }
+
+ // This if-clause is only required for a ternary alloy.
+ // Actually we don't need it at all because D_i should be zero
+ // anyway if atom i has no concentration dependent interactions
+ // (because it is not species A or B).
+
+ if (x_i != -1.0) {
+ double t1 = -rhoB[i];
+ if (jtype == speciesB) t1 += rho[i];
+ fpair += D_i * rhojp * t1;
+ }
+
+ double phip;
+ double phi = PhiOfR(index, itype, jtype, recip, phip);
+ if (itype == jtype || x_i == -1.0 || x_j == -1.0) {
+
+ // Case of no concentration dependence.
+
+ fpair += phip;
+ } else {
+
+ // We have a concentration dependence for the i-j interaction.
+
+ double h=0.0;
+ if (cdeamVersion == 1) {
+
+ // Calculate h(x_i) polynomial function.
+
+ double h_i = evalH(x_i);
+
+ // Calculate h(x_j) polynomial function.
+
+ double h_j = evalH(x_j);
+ h = 0.5 * (h_i + h_j);
+ } else if (cdeamVersion == 2) {
+
+ // Average concentration.
+
+ double x_ij = 0.5 * (x_i + x_j);
+
+ // Calculate h(x_ij) polynomial function.
+
+ h = evalH(x_ij);
+ } else {
+ ASSERT(false);
+ }
+ fpair += h * phip;
+ phi *= h;
+ }
+
+ // Divide by r_ij and negate to get forces from gradient.
+
+ fpair /= -r;
+
+ f[i][0] += delx*fpair;
+ f[i][1] += dely*fpair;
+ f[i][2] += delz*fpair;
+ if (newton_pair || j < nlocal) {
+ f[j][0] -= delx*fpair;
+ f[j][1] -= dely*fpair;
+ f[j][2] -= delz*fpair;
+ }
+
+ if (eflag) evdwl = phi;
+ if (evflag) ev_tally(i,j,nlocal,newton_pair,evdwl,0.0,fpair,delx,dely,delz);
+ }
+ }
+ }
+
+ if (vflag_fdotr) virial_fdotr_compute();
+}
+
+/* ---------------------------------------------------------------------- */
+
+void PairEAMCD::coeff(int narg, char **arg)
+{
+ PairEAMAlloy::coeff(narg, arg);
+
+ // Make sure the EAM file is a CD-EAM binary alloy.
+
+ if (setfl->nelements < 2)
+ error->all(FLERR,"The EAM file must contain at least 2 elements to be used with the eam/cd pair style.");
+
+ // Read in the coefficients of the h polynomial from the end of the EAM file.
+
+ read_h_coeff(arg[2]);
+
+ // Determine which atom type is the A species and which is the B
+ // species in the alloy. By default take the first element (index 0)
+ // in the EAM file as the A species and the second element (index 1)
+ // in the EAM file as the B species.
+
+ speciesA = -1;
+ speciesB = -1;
+ for (int i = 1; i <= atom->ntypes; i++) {
+ if (map[i] == 0) {
+ if (speciesA >= 0)
+ error->all(FLERR,"The first element from the EAM file may only be mapped to a single atom type.");
+ speciesA = i;
+ }
+ if (map[i] == 1) {
+ if (speciesB >= 0)
+ error->all(FLERR,"The second element from the EAM file may only be mapped to a single atom type.");
+ speciesB = i;
+ }
+ }
+ if (speciesA < 0)
+ error->all(FLERR,"The first element from the EAM file must be mapped to exactly one atom type.");
+ if (speciesB < 0)
+ error->all(FLERR,"The second element from the EAM file must be mapped to exactly one atom type.");
+}
+
+/* ----------------------------------------------------------------------
+ Reads in the h(x) polynomial coefficients
+------------------------------------------------------------------------- */
+
+void PairEAMCD::read_h_coeff(char *filename)
+{
+ if (comm->me == 0) {
+
+ // Open potential file
+
+ FILE *fptr;
+ char line[MAXLINE];
+ char nextline[MAXLINE];
+ fptr = force->open_potential(filename);
+ if (fptr == NULL) {
+ char str[128];
+ sprintf(str,"Cannot open EAM potential file %s", filename);
+ error->one(FLERR,str);
+ }
+
+ // h coefficients are stored at the end of the file.
+ // Skip to last line of file.
+
+ while(fgets(nextline, MAXLINE, fptr) != NULL) {
+ strcpy(line, nextline);
+ }
+ char* ptr = strtok(line, " \t\n\r\f");
+ int degree = atoi(ptr);
+ nhcoeff = degree+1;
+ hcoeff = new double[nhcoeff];
+ int i = 0;
+ while((ptr = strtok(NULL," \t\n\r\f")) != NULL && i < nhcoeff) {
+ hcoeff[i++] = atof(ptr);
+ }
+ if (i != nhcoeff || nhcoeff < 1)
+ error->one(FLERR,"Failed to read h(x) function coefficients from EAM file.");
+
+ // Close the potential file.
+
+ fclose(fptr);
+ }
+
+ MPI_Bcast(&nhcoeff, 1, MPI_INT, 0, world);
+ if (comm->me != 0) hcoeff = new double[nhcoeff];
+ MPI_Bcast(hcoeff, nhcoeff, MPI_DOUBLE, 0, world);
+}
+
+
+/* ---------------------------------------------------------------------- */
+
+int PairEAMCD::pack_forward_comm(int n, int *list, double *buf,
+ int pbc_flag, int *pbc)
+{
+ int i,j,m;
+
+ m = 0;
+ if (communicationStage == 2) {
+ if (cdeamVersion == 1) {
+ for (i = 0; i < n; i++) {
+ j = list[i];
+ buf[m++] = fp[j];
+ buf[m++] = rho[j];
+ buf[m++] = rhoB[j];
+ buf[m++] = D_values[j];
+ }
+ return m;
+ } else if (cdeamVersion == 2) {
+ for (i = 0; i < n; i++) {
+ j = list[i];
+ buf[m++] = fp[j];
+ buf[m++] = rho[j];
+ buf[m++] = rhoB[j];
+ }
+ return m;
+ } else { ASSERT(false); return 0; }
+ } else if (communicationStage == 4) {
+ for (i = 0; i < n; i++) {
+ j = list[i];
+ buf[m++] = D_values[j];
+ }
+ return m;
+ } else return 0;
+}
+
+/* ---------------------------------------------------------------------- */
+
+void PairEAMCD::unpack_forward_comm(int n, int first, double *buf)
+{
+ int i,m,last;
+
+ m = 0;
+ last = first + n;
+ if (communicationStage == 2) {
+ if (cdeamVersion == 1) {
+ for (i = first; i < last; i++) {
+ fp[i] = buf[m++];
+ rho[i] = buf[m++];
+ rhoB[i] = buf[m++];
+ D_values[i] = buf[m++];
+ }
+ } else if (cdeamVersion == 2) {
+ for (i = first; i < last; i++) {
+ fp[i] = buf[m++];
+ rho[i] = buf[m++];
+ rhoB[i] = buf[m++];
+ }
+ } else {
+ ASSERT(false);
+ }
+ } else if (communicationStage == 4) {
+ for (i = first; i < last; i++) {
+ D_values[i] = buf[m++];
+ }
+ }
+}
+
+/* ---------------------------------------------------------------------- */
+int PairEAMCD::pack_reverse_comm(int n, int first, double *buf)
+{
+ int i,m,last;
+
+ m = 0;
+ last = first + n;
+
+ if (communicationStage == 1) {
+ if (cdeamVersion == 1) {
+ for (i = first; i < last; i++) {
+ buf[m++] = rho[i];
+ buf[m++] = rhoB[i];
+ buf[m++] = D_values[i];
+ }
+ return m;
+ } else if (cdeamVersion == 2) {
+ for (i = first; i < last; i++) {
+ buf[m++] = rho[i];
+ buf[m++] = rhoB[i];
+ }
+ return m;
+ } else { ASSERT(false); return 0; }
+ } else if (communicationStage == 3) {
+ for (i = first; i < last; i++) {
+ buf[m++] = D_values[i];
+ }
+ return m;
+ } else return 0;
+}
+
+/* ---------------------------------------------------------------------- */
+
+void PairEAMCD::unpack_reverse_comm(int n, int *list, double *buf)
+{
+ int i,j,m;
+
+ m = 0;
+ if (communicationStage == 1) {
+ if (cdeamVersion == 1) {
+ for (i = 0; i < n; i++) {
+ j = list[i];
+ rho[j] += buf[m++];
+ rhoB[j] += buf[m++];
+ D_values[j] += buf[m++];
+ }
+ } else if (cdeamVersion == 2) {
+ for (i = 0; i < n; i++) {
+ j = list[i];
+ rho[j] += buf[m++];
+ rhoB[j] += buf[m++];
+ }
+ } else {
+ ASSERT(false);
+ }
+ } else if (communicationStage == 3) {
+ for (i = 0; i < n; i++) {
+ j = list[i];
+ D_values[j] += buf[m++];
+ }
+ }
+}
+
+/* ----------------------------------------------------------------------
+ memory usage of local atom-based arrays
+------------------------------------------------------------------------- */
+double PairEAMCD::memory_usage()
+{
+ double bytes = 2 * nmax * sizeof(double);
+ return PairEAMAlloy::memory_usage() + bytes;
+}
diff --git a/src/USER-MISC/pair_cdeam.h b/src/MANYBODY/pair_eam_cd.h
similarity index 93%
rename from src/USER-MISC/pair_cdeam.h
rename to src/MANYBODY/pair_eam_cd.h
index 934b7601a4bfac37bbad057f94ed8a373a6848fe..ee84fb09c53f9fed5c2808f8e784340b705b7679 100644
--- a/src/USER-MISC/pair_cdeam.h
+++ b/src/MANYBODY/pair_eam_cd.h
@@ -13,26 +13,26 @@
#ifdef PAIR_CLASS
-PairStyle(eam/cd,PairCDEAM_OneSite)
-PairStyle(eam/cd/old,PairCDEAM_TwoSite)
+PairStyle(eam/cd,PairEAMCD_OneSite)
+PairStyle(eam/cd/old,PairEAMCD_TwoSite)
#else
-#ifndef LMP_PAIR_CDEAM_H
-#define LMP_PAIR_CDEAM_H
+#ifndef LMP_PAIR_EAM_CD_H
+#define LMP_PAIR_EAM_CD_H
#include "pair_eam_alloy.h"
namespace LAMMPS_NS {
-class PairCDEAM : public PairEAMAlloy
+class PairEAMCD : public PairEAMAlloy
{
public:
/// Constructor.
- PairCDEAM(class LAMMPS*, int cdeamVersion);
+ PairEAMCD(class LAMMPS*, int cdeamVersion);
/// Destructor.
- virtual ~PairCDEAM();
+ virtual ~PairEAMCD();
/// Calculates the energies and forces for all atoms in the system.
virtual void compute(int, int);
@@ -211,19 +211,19 @@ public:
};
/// The one-site concentration formulation of CD-EAM.
- class PairCDEAM_OneSite : public PairCDEAM
+ class PairEAMCD_OneSite : public PairEAMCD
{
public:
/// Constructor.
- PairCDEAM_OneSite(class LAMMPS* lmp) : PairEAM(lmp), PairCDEAM(lmp, 1) {}
+ PairEAMCD_OneSite(class LAMMPS* lmp) : PairEAM(lmp), PairEAMCD(lmp, 1) {}
};
/// The two-site concentration formulation of CD-EAM.
- class PairCDEAM_TwoSite : public PairCDEAM
+ class PairEAMCD_TwoSite : public PairEAMCD
{
public:
/// Constructor.
- PairCDEAM_TwoSite(class LAMMPS* lmp) : PairEAM(lmp), PairCDEAM(lmp, 2) {}
+ PairEAMCD_TwoSite(class LAMMPS* lmp) : PairEAM(lmp), PairEAMCD(lmp, 2) {}
};
}
diff --git a/src/MC/fix_gcmc.cpp b/src/MC/fix_gcmc.cpp
index 6221e6d52c26b359d9efd7d87460a1ed3ceacaf3..b40ce6a1b3342bf185846a37b7caa0ca8c6a0c10 100644
--- a/src/MC/fix_gcmc.cpp
+++ b/src/MC/fix_gcmc.cpp
@@ -1589,6 +1589,7 @@ void FixGCMC::attempt_atomic_deletion_full()
}
}
if (force->kspace) force->kspace->qsum_qsq();
+ if (force->pair->tail_flag) force->pair->reinit();
double energy_after = energy_full();
if (random_equal->uniform() <
@@ -1607,6 +1608,7 @@ void FixGCMC::attempt_atomic_deletion_full()
if (q_flag) atom->q[i] = q_tmp;
}
if (force->kspace) force->kspace->qsum_qsq();
+ if (force->pair->tail_flag) force->pair->reinit();
energy_stored = energy_before;
}
update_gas_atoms_list();
@@ -1700,6 +1702,7 @@ void FixGCMC::attempt_atomic_insertion_full()
comm->borders();
if (triclinic) domain->lamda2x(atom->nlocal+atom->nghost);
if (force->kspace) force->kspace->qsum_qsq();
+ if (force->pair->tail_flag) force->pair->reinit();
double energy_after = energy_full();
if (energy_after < MAXENERGYTEST &&
@@ -1712,6 +1715,7 @@ void FixGCMC::attempt_atomic_insertion_full()
atom->natoms--;
if (proc_flag) atom->nlocal--;
if (force->kspace) force->kspace->qsum_qsq();
+ if (force->pair->tail_flag) force->pair->reinit();
energy_stored = energy_before;
}
update_gas_atoms_list();
@@ -1949,6 +1953,7 @@ void FixGCMC::attempt_molecule_deletion_full()
}
}
if (force->kspace) force->kspace->qsum_qsq();
+ if (force->pair->tail_flag) force->pair->reinit();
double energy_after = energy_full();
// energy_before corrected by energy_intra
@@ -1981,6 +1986,7 @@ void FixGCMC::attempt_molecule_deletion_full()
}
}
if (force->kspace) force->kspace->qsum_qsq();
+ if (force->pair->tail_flag) force->pair->reinit();
}
update_gas_atoms_list();
delete[] tmpmask;
@@ -2151,6 +2157,7 @@ void FixGCMC::attempt_molecule_insertion_full()
comm->borders();
if (triclinic) domain->lamda2x(atom->nlocal+atom->nghost);
if (force->kspace) force->kspace->qsum_qsq();
+ if (force->pair->tail_flag) force->pair->reinit();
double energy_after = energy_full();
// energy_after corrected by energy_intra
@@ -2181,6 +2188,7 @@ void FixGCMC::attempt_molecule_insertion_full()
} else i++;
}
if (force->kspace) force->kspace->qsum_qsq();
+ if (force->pair->tail_flag) force->pair->reinit();
}
update_gas_atoms_list();
}
diff --git a/src/Purge.list b/src/Purge.list
index 402fc409e6069980a034b9cc83aefa4d06d3b6a0..cb98636b1c17860fab98343824d10bf5f2063bbf 100644
--- a/src/Purge.list
+++ b/src/Purge.list
@@ -24,6 +24,12 @@ style_nstencil.h
style_ntopo.h
# other auto-generated files
lmpinstalledpkgs.h
+# renamed on 31 July 2018
+pair_cdeam.h
+pair_cdeam.cpp
+# renamed on 20 July 2018
+pair_body.h
+pair_body.cpp
# deleted on 4 April 2018
pair_kim_version.h
# deleted on 15 December 2017
diff --git a/src/SPIN/atom_vec_spin.cpp b/src/SPIN/atom_vec_spin.cpp
index 4871fe0c4046bbd70aab02845fe9281af0ffde6c..6460a6185fb72d0635b623dbd7e8a2e7a2d27ba6 100644
--- a/src/SPIN/atom_vec_spin.cpp
+++ b/src/SPIN/atom_vec_spin.cpp
@@ -20,12 +20,12 @@
Please cite the related publication:
Tranchida, J., Plimpton, S. J., Thibaudeau, P., & Thompson, A. P. (2018).
Massively parallel symplectic algorithm for coupled magnetic spin dynamics
- and molecular dynamics. arXiv preprint arXiv:1801.10233.
+ and molecular dynamics. Journal of Computational Physics.
------------------------------------------------------------------------- */
-#include <math.h>
-#include <stdlib.h>
-#include <string.h>
+#include <cmath>
+#include <cstdlib>
+#include <cstring>
#include "atom.h"
#include "atom_vec_spin.h"
#include "comm.h"
@@ -54,7 +54,7 @@ AtomVecSpin::AtomVecSpin(LAMMPS *lmp) : AtomVec(lmp)
size_data_atom = 9;
size_data_vel = 4;
xcol_data = 4;
-
+
atom->sp_flag = 1;
}
@@ -816,9 +816,9 @@ void AtomVecSpin::data_atom(double *coord, imageint imagetmp, char **values)
x[nlocal][2] = coord[2];
sp[nlocal][3] = atof(values[2]);
- sp[nlocal][0] = atof(values[5]);
- sp[nlocal][1] = atof(values[6]);
- sp[nlocal][2] = atof(values[7]);
+ sp[nlocal][0] = atof(values[6]);
+ sp[nlocal][1] = atof(values[7]);
+ sp[nlocal][2] = atof(values[8]);
double inorm = 1.0/sqrt(sp[nlocal][0]*sp[nlocal][0] +
sp[nlocal][1]*sp[nlocal][1] +
sp[nlocal][2]*sp[nlocal][2]);
diff --git a/src/SPIN/compute_spin.cpp b/src/SPIN/compute_spin.cpp
index 54818a9b7083e1b85883da4ac8bd43ce14c718d6..dc16190c98763053d76fb84e5a423eca570f860d 100644
--- a/src/SPIN/compute_spin.cpp
+++ b/src/SPIN/compute_spin.cpp
@@ -18,11 +18,11 @@
Please cite the related publication:
Tranchida, J., Plimpton, S. J., Thibaudeau, P., & Thompson, A. P. (2018).
Massively parallel symplectic algorithm for coupled magnetic spin dynamics
- and molecular dynamics. arXiv preprint arXiv:1801.10233.
+ and molecular dynamics. Journal of Computational Physics.
------------------------------------------------------------------------- */
#include <mpi.h>
-#include <string.h>
+#include <cstring>
#include "atom.h"
#include "compute_spin.h"
#include "domain.h"
@@ -105,16 +105,16 @@ void ComputeSpin::compute_vector()
for (i = 0; i < nlocal; i++) {
if (mask[i] & groupbit) {
if (atom->sp_flag) {
- mag[0] += sp[i][0];
- mag[1] += sp[i][1];
- mag[2] += sp[i][2];
- magenergy -= (sp[i][0]*fm[i][0] + sp[i][1]*fm[i][1] + sp[i][2]*fm[i][2]);
- tx = sp[i][1]*fm[i][2]-sp[i][2]*fm[i][1];
- ty = sp[i][2]*fm[i][0]-sp[i][0]*fm[i][2];
- tz = sp[i][0]*fm[i][1]-sp[i][1]*fm[i][0];
- tempnum += tx*tx+ty*ty+tz*tz;
- tempdenom += sp[i][0]*fm[i][0]+fm[i][1]*sp[i][1]+sp[i][2]*fm[i][2];
- countsp++;
+ mag[0] += sp[i][0];
+ mag[1] += sp[i][1];
+ mag[2] += sp[i][2];
+ magenergy -= (sp[i][0]*fm[i][0] + sp[i][1]*fm[i][1] + sp[i][2]*fm[i][2]);
+ tx = sp[i][1]*fm[i][2]-sp[i][2]*fm[i][1];
+ ty = sp[i][2]*fm[i][0]-sp[i][0]*fm[i][2];
+ tz = sp[i][0]*fm[i][1]-sp[i][1]*fm[i][0];
+ tempnum += tx*tx+ty*ty+tz*tz;
+ tempdenom += sp[i][0]*fm[i][0]+fm[i][1]*sp[i][1]+sp[i][2]*fm[i][2];
+ countsp++;
}
}
else error->all(FLERR,"Compute compute/spin requires atom/spin style");
diff --git a/src/SPIN/fix_langevin_spin.cpp b/src/SPIN/fix_langevin_spin.cpp
index 97b33197ce3ca966bd3d822b081a13fa544eb2e2..cb344654826883c41b7d6fcf8802d5ebacdccd0d 100644
--- a/src/SPIN/fix_langevin_spin.cpp
+++ b/src/SPIN/fix_langevin_spin.cpp
@@ -18,13 +18,13 @@
Please cite the related publication:
Tranchida, J., Plimpton, S. J., Thibaudeau, P., & Thompson, A. P. (2018).
Massively parallel symplectic algorithm for coupled magnetic spin dynamics
- and molecular dynamics. arXiv preprint arXiv:1801.10233.
+ and molecular dynamics. Journal of Computational Physics.
------------------------------------------------------------------------- */
#include <mpi.h>
-#include <math.h>
-#include <string.h>
-#include <stdlib.h>
+#include <cmath>
+#include <cstring>
+#include <cstdlib>
#include "atom.h"
#include "atom_vec_ellipsoid.h"
diff --git a/src/SPIN/fix_nve_spin.cpp b/src/SPIN/fix_nve_spin.cpp
index d91636af58bf3454fd2e9723f9de2b32686c36a1..b75f03212a143e0e5ebab08afd6d026834a6f210 100644
--- a/src/SPIN/fix_nve_spin.cpp
+++ b/src/SPIN/fix_nve_spin.cpp
@@ -18,12 +18,12 @@
Please cite the related publication:
Tranchida, J., Plimpton, S. J., Thibaudeau, P., & Thompson, A. P. (2018).
Massively parallel symplectic algorithm for coupled magnetic spin dynamics
- and molecular dynamics. arXiv preprint arXiv:1801.10233.
+ and molecular dynamics. Journal of Computational Physics.
------------------------------------------------------------------------- */
-#include <math.h>
-#include <stdio.h>
-#include <string.h>
+#include <cmath>
+#include <cstdio>
+#include <cstring>
#include "atom.h"
#include "atom_vec.h"
@@ -59,8 +59,9 @@ static const char cite_fix_nve_spin[] =
"title={Massively parallel symplectic algorithm for coupled magnetic spin "
"dynamics and molecular dynamics},\n"
"author={Tranchida, J and Plimpton, SJ and Thibaudeau, P and Thompson, AP},\n"
- "journal={arXiv preprint arXiv:1801.10233},\n"
- "year={2018}\n"
+ "journal={Journal of Computational Physics},\n"
+ "year={2018},\n"
+ "publisher={Elsevier}\n"
"}\n\n";
enum{NONE};
diff --git a/src/SPIN/fix_precession_spin.cpp b/src/SPIN/fix_precession_spin.cpp
index eedf0becb74f4e24c05d3130309ae61ff9c8b90e..b908478952941416546c4b083833f59dd9729a1c 100644
--- a/src/SPIN/fix_precession_spin.cpp
+++ b/src/SPIN/fix_precession_spin.cpp
@@ -18,13 +18,13 @@
Please cite the related publication:
Tranchida, J., Plimpton, S. J., Thibaudeau, P., & Thompson, A. P. (2018).
Massively parallel symplectic algorithm for coupled magnetic spin dynamics
- and molecular dynamics. arXiv preprint arXiv:1801.10233.
+ and molecular dynamics. Journal of Computational Physics.
------------------------------------------------------------------------- */
-#include <math.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
+#include <cmath>
+#include <cstdio>
+#include <cstdlib>
+#include <cstring>
#include "atom.h"
#include "domain.h"
diff --git a/src/SPIN/pair_spin.cpp b/src/SPIN/pair_spin.cpp
index acb7ffe54862d7048317cca89107ff2f1666bcca..398206b26ee3233b42707585d4bb2dd7dac0c4c6 100644
--- a/src/SPIN/pair_spin.cpp
+++ b/src/SPIN/pair_spin.cpp
@@ -18,12 +18,12 @@
Please cite the related publication:
Tranchida, J., Plimpton, S. J., Thibaudeau, P., & Thompson, A. P. (2018).
Massively parallel symplectic algorithm for coupled magnetic spin dynamics
- and molecular dynamics. arXiv preprint arXiv:1801.10233.
+ and molecular dynamics. Journal of Computational Physics.
------------------------------------------------------------------------- */
-#include <math.h>
-#include <stdlib.h>
-#include <string.h>
+#include <cmath>
+#include <cstdlib>
+#include <cstring>
#include "atom.h"
#include "comm.h"
diff --git a/src/SPIN/pair_spin_dmi.cpp b/src/SPIN/pair_spin_dmi.cpp
index 07ae6849390ff7f9471b005f912eb7f5b94413ce..08e2c63e7f6ba147c6062da17f92a68b2a5d090a 100644
--- a/src/SPIN/pair_spin_dmi.cpp
+++ b/src/SPIN/pair_spin_dmi.cpp
@@ -18,12 +18,12 @@
Please cite the related publication:
Tranchida, J., Plimpton, S. J., Thibaudeau, P., & Thompson, A. P. (2018).
Massively parallel symplectic algorithm for coupled magnetic spin dynamics
- and molecular dynamics. arXiv preprint arXiv:1801.10233.
+ and molecular dynamics. Journal of Computational Physics.
------------------------------------------------------------------------- */
-#include <math.h>
-#include <stdlib.h>
-#include <string.h>
+#include <cmath>
+#include <cstdlib>
+#include <cstring>
#include "atom.h"
#include "comm.h"
@@ -65,6 +65,9 @@ PairSpinDmi::~PairSpinDmi()
memory->destroy(v_dmx);
memory->destroy(v_dmy);
memory->destroy(v_dmz);
+ memory->destroy(vmech_dmx);
+ memory->destroy(vmech_dmy);
+ memory->destroy(vmech_dmz);
memory->destroy(cutsq);
}
}
@@ -118,7 +121,7 @@ void PairSpinDmi::coeff(int narg, char **arg)
force->bounds(FLERR,arg[1],atom->ntypes,jlo,jhi);
const double rij = force->numeric(FLERR,arg[3]);
- const double dm = (force->numeric(FLERR,arg[4]))/hbar;
+ const double dm = (force->numeric(FLERR,arg[4]));
double dmx = force->numeric(FLERR,arg[5]);
double dmy = force->numeric(FLERR,arg[6]);
double dmz = force->numeric(FLERR,arg[7]);
@@ -133,9 +136,12 @@ void PairSpinDmi::coeff(int narg, char **arg)
for (int j = MAX(jlo,i); j <= jhi; j++) {
cut_spin_dmi[i][j] = rij;
DM[i][j] = dm;
- v_dmx[i][j] = dmx * dm;
- v_dmy[i][j] = dmy * dm;
- v_dmz[i][j] = dmz * dm;
+ v_dmx[i][j] = dmx * dm / hbar;
+ v_dmy[i][j] = dmy * dm / hbar;
+ v_dmz[i][j] = dmz * dm / hbar;
+ vmech_dmx[i][j] = dmx * dm;
+ vmech_dmy[i][j] = dmy * dm;
+ vmech_dmz[i][j] = dmz * dm;
setflag[i][j] = 1;
count++;
}
@@ -187,9 +193,17 @@ void PairSpinDmi::init_style()
double PairSpinDmi::init_one(int i, int j)
{
-
if (setflag[i][j] == 0) error->all(FLERR,"All pair coeffs are not set");
+ DM[j][i] = DM[i][j];
+ v_dmx[j][i] = v_dmx[i][j];
+ v_dmy[j][i] = v_dmy[i][j];
+ v_dmz[j][i] = v_dmz[i][j];
+ vmech_dmx[j][i] = vmech_dmx[i][j];
+ vmech_dmy[j][i] = vmech_dmy[i][j];
+ vmech_dmz[j][i] = vmech_dmz[i][j];
+ cut_spin_dmi[j][i] = cut_spin_dmi[i][j];
+
return cut_spin_dmi_global;
}
@@ -210,7 +224,8 @@ void PairSpinDmi::compute(int eflag, int vflag)
{
int i,j,ii,jj,inum,jnum,itype,jtype;
double evdwl, ecoul;
- double xi[3], rij[3], eij[3];
+ double xi[3], eij[3];
+ double delx,dely,delz;
double spi[3], spj[3];
double fi[3], fmi[3];
double local_cut2;
@@ -264,20 +279,17 @@ void PairSpinDmi::compute(int eflag, int vflag)
spj[2] = sp[j][2];
evdwl = 0.0;
-
fi[0] = fi[1] = fi[2] = 0.0;
fmi[0] = fmi[1] = fmi[2] = 0.0;
- rij[0] = rij[1] = rij[2] = 0.0;
- eij[0] = eij[1] = eij[2] = 0.0;
- rij[0] = x[j][0] - xi[0];
- rij[1] = x[j][1] - xi[1];
- rij[2] = x[j][2] - xi[2];
- rsq = rij[0]*rij[0] + rij[1]*rij[1] + rij[2]*rij[2];
+ delx = xi[0] - x[j][0];
+ dely = xi[1] - x[j][1];
+ delz = xi[2] - x[j][2];
+ rsq = delx*delx + dely*dely + delz*delz;
inorm = 1.0/sqrt(rsq);
- eij[0] = rij[0]*inorm;
- eij[1] = rij[1]*inorm;
- eij[2] = rij[2]*inorm;
+ eij[0] = -inorm*delx;
+ eij[1] = -inorm*dely;
+ eij[2] = -inorm*delz;
local_cut2 = cut_spin_dmi[itype][jtype]*cut_spin_dmi[itype][jtype];
@@ -286,7 +298,7 @@ void PairSpinDmi::compute(int eflag, int vflag)
if (rsq <= local_cut2) {
compute_dmi(i,j,eij,fmi,spj);
if (lattice_flag) {
- compute_dmi_mech(fi);
+ compute_dmi_mech(i,j,rsq,eij,fi,spi,spj);
}
}
@@ -309,7 +321,7 @@ void PairSpinDmi::compute(int eflag, int vflag)
} else evdwl = 0.0;
if (evflag) ev_tally_xyz(i,j,nlocal,newton_pair,
- evdwl,ecoul,fi[0],fi[1],fi[2],rij[0],rij[1],rij[2]);
+ evdwl,ecoul,fi[0],fi[1],fi[2],delx,dely,delz);
}
}
@@ -325,8 +337,8 @@ void PairSpinDmi::compute_single_pair(int ii, double fmi[3])
double **x = atom->x;
double **sp = atom->sp;
double local_cut2;
-
- double xi[3], rij[3], eij[3];
+ double xi[3], eij[3];
+ double delx,dely,delz;
double spj[3];
int i,j,jnum,itype,jtype;
@@ -358,14 +370,14 @@ void PairSpinDmi::compute_single_pair(int ii, double fmi[3])
spj[1] = sp[j][1];
spj[2] = sp[j][2];
- rij[0] = x[j][0] - xi[0];
- rij[1] = x[j][1] - xi[1];
- rij[2] = x[j][2] - xi[2];
- rsq = rij[0]*rij[0] + rij[1]*rij[1] + rij[2]*rij[2];
+ delx = xi[0] - x[j][0];
+ dely = xi[1] - x[j][1];
+ delz = xi[2] - x[j][2];
+ rsq = delx*delx + dely*dely + delz*delz;
inorm = 1.0/sqrt(rsq);
- eij[0] = rij[0]*inorm;
- eij[1] = rij[1]*inorm;
- eij[2] = rij[2]*inorm;
+ eij[0] = -inorm*delx;
+ eij[1] = -inorm*dely;
+ eij[2] = -inorm*delz;
local_cut2 = cut_spin_dmi[itype][jtype]*cut_spin_dmi[itype][jtype];
@@ -390,23 +402,45 @@ void PairSpinDmi::compute_dmi(int i, int j, double eij[3], double fmi[3], double
jtype = type[j];
dmix = eij[1]*v_dmz[itype][jtype] - eij[2]*v_dmy[itype][jtype];
- dmiy = eij[2]*v_dmx[itype][jtype] - eij[2]*v_dmz[itype][jtype];
+ dmiy = eij[2]*v_dmx[itype][jtype] - eij[0]*v_dmz[itype][jtype];
dmiz = eij[0]*v_dmy[itype][jtype] - eij[1]*v_dmx[itype][jtype];
- fmi[0] += (spj[1]*dmiz - spj[2]*dmiy);
- fmi[1] += (spj[2]*dmix - spj[0]*dmiz);
- fmi[2] += (spj[0]*dmiy - spj[1]*dmix);
+ fmi[0] -= (spj[1]*dmiz - spj[2]*dmiy);
+ fmi[1] -= (spj[2]*dmix - spj[0]*dmiz);
+ fmi[2] -= (spj[0]*dmiy - spj[1]*dmix);
}
/* ----------------------------------------------------------------------
compute the mechanical force due to the dmi interaction between atom i and atom j
------------------------------------------------------------------------- */
-void PairSpinDmi::compute_dmi_mech(double fi[3])
+void PairSpinDmi::compute_dmi_mech(int i, int j, double rsq, double eij[3],
+ double fi[3], double spi[3], double spj[3])
{
- fi[0] += 0.0;
- fi[1] += 0.0;
- fi[2] += 0.0;
+ int *type = atom->type;
+ int itype, jtype;
+ double dmix,dmiy,dmiz;
+ itype = type[i];
+ jtype = type[j];
+ double csx,csy,csz,cdmx,cdmy,cdmz,irij;
+
+ irij = 1.0/sqrt(rsq);
+
+ dmix = vmech_dmx[itype][jtype];
+ dmiy = vmech_dmy[itype][jtype];
+ dmiz = vmech_dmz[itype][jtype];
+
+ csx = (spi[1]*spj[2] - spi[2]*spj[1]);
+ csy = (spi[2]*spj[0] - spi[0]*spj[2]);
+ csz = (spi[0]*spj[1] - spi[1]*spj[0]);
+
+ cdmx = (dmiy*csz - dmiz*csy);
+ cdmy = (dmiz*csx - dmix*csz);
+ cdmz = (dmix*csy - dmiy*csz);
+
+ fi[0] += irij*cdmx;
+ fi[1] += irij*cdmy;
+ fi[2] += irij*cdmz;
}
/* ----------------------------------------------------------------------
@@ -428,6 +462,9 @@ void PairSpinDmi::allocate()
memory->create(v_dmx,n+1,n+1,"pair:DM_vector_x");
memory->create(v_dmy,n+1,n+1,"pair:DM_vector_y");
memory->create(v_dmz,n+1,n+1,"pair:DM_vector_z");
+ memory->create(vmech_dmx,n+1,n+1,"pair:DMmech_vector_x");
+ memory->create(vmech_dmy,n+1,n+1,"pair:DMmech_vector_y");
+ memory->create(vmech_dmz,n+1,n+1,"pair:DMmech_vector_z");
memory->create(cutsq,n+1,n+1,"pair:cutsq");
@@ -451,6 +488,9 @@ void PairSpinDmi::write_restart(FILE *fp)
fwrite(&v_dmx[i][j],sizeof(double),1,fp);
fwrite(&v_dmy[i][j],sizeof(double),1,fp);
fwrite(&v_dmz[i][j],sizeof(double),1,fp);
+ fwrite(&vmech_dmx[i][j],sizeof(double),1,fp);
+ fwrite(&vmech_dmy[i][j],sizeof(double),1,fp);
+ fwrite(&vmech_dmz[i][j],sizeof(double),1,fp);
fwrite(&cut_spin_dmi[i][j],sizeof(double),1,fp);
}
}
@@ -478,12 +518,18 @@ void PairSpinDmi::read_restart(FILE *fp)
fread(&v_dmx[i][j],sizeof(double),1,fp);
fread(&v_dmy[i][j],sizeof(double),1,fp);
fread(&v_dmz[i][j],sizeof(double),1,fp);
+ fread(&vmech_dmx[i][j],sizeof(double),1,fp);
+ fread(&vmech_dmy[i][j],sizeof(double),1,fp);
+ fread(&vmech_dmz[i][j],sizeof(double),1,fp);
fread(&cut_spin_dmi[i][j],sizeof(double),1,fp);
}
MPI_Bcast(&DM[i][j],1,MPI_DOUBLE,0,world);
MPI_Bcast(&v_dmx[i][j],1,MPI_DOUBLE,0,world);
MPI_Bcast(&v_dmy[i][j],1,MPI_DOUBLE,0,world);
MPI_Bcast(&v_dmz[i][j],1,MPI_DOUBLE,0,world);
+ MPI_Bcast(&vmech_dmx[i][j],1,MPI_DOUBLE,0,world);
+ MPI_Bcast(&vmech_dmy[i][j],1,MPI_DOUBLE,0,world);
+ MPI_Bcast(&vmech_dmz[i][j],1,MPI_DOUBLE,0,world);
MPI_Bcast(&cut_spin_dmi[i][j],1,MPI_DOUBLE,0,world);
}
}
diff --git a/src/SPIN/pair_spin_dmi.h b/src/SPIN/pair_spin_dmi.h
index a309f0c8d52ade48d42cffc26254e5a5c6839988..68e42e879dfe15577d6bf73fe8f80a5593530dfd 100644
--- a/src/SPIN/pair_spin_dmi.h
+++ b/src/SPIN/pair_spin_dmi.h
@@ -38,22 +38,23 @@ class PairSpinDmi : public PairSpin {
void compute_single_pair(int, double *);
void compute_dmi(int, int, double *, double *, double *);
- void compute_dmi_mech(double *);
+ void compute_dmi_mech(int, int, double, double *, double *, double *, double *);
void write_restart(FILE *);
void read_restart(FILE *);
void write_restart_settings(FILE *);
void read_restart_settings(FILE *);
- double cut_spin_dmi_global; // short range pair cutoff
+ double cut_spin_dmi_global; // short range pair cutoff
protected:
- double **DM; // dmi coeff in eV
- double **v_dmx, **v_dmy, **v_dmz; // dmi direction
- double **cut_spin_dmi; // cutoff distance dmi
+ double **DM; // dmi coeff in eV
+ double **v_dmx, **v_dmy, **v_dmz; // dmi direction
+ double **vmech_dmx, **vmech_dmy, **vmech_dmz; // dmi mech direction
+ double **cut_spin_dmi; // cutoff distance dmi
- int lattice_flag; // flag for mech force computation
- class FixNVESpin *lockfixnvespin; // ptr to FixNVESpin for setups
+ int lattice_flag; // flag for mech force computation
+ class FixNVESpin *lockfixnvespin; // ptr to FixNVESpin for setups
void allocate();
};
diff --git a/src/SPIN/pair_spin_exchange.cpp b/src/SPIN/pair_spin_exchange.cpp
index 7b05d7337ead8a161f7fb88107bc322bd2ef86a3..cc074bb97d9b9dd91d2bfcc8e378d7cd56a7ba5e 100644
--- a/src/SPIN/pair_spin_exchange.cpp
+++ b/src/SPIN/pair_spin_exchange.cpp
@@ -18,12 +18,12 @@
Please cite the related publication:
Tranchida, J., Plimpton, S. J., Thibaudeau, P., & Thompson, A. P. (2018).
Massively parallel symplectic algorithm for coupled magnetic spin dynamics
- and molecular dynamics. arXiv preprint arXiv:1801.10233.
+ and molecular dynamics. Journal of Computational Physics.
------------------------------------------------------------------------- */
-#include <math.h>
-#include <stdlib.h>
-#include <string.h>
+#include <cmath>
+#include <cstdlib>
+#include <cstring>
#include "atom.h"
#include "comm.h"
@@ -65,7 +65,7 @@ PairSpinExchange::~PairSpinExchange()
memory->destroy(J1_mech);
memory->destroy(J2);
memory->destroy(J3);
- memory->destroy(cutsq); // to be deleted
+ memory->destroy(cutsq); // to be implemented
}
}
@@ -134,8 +134,8 @@ void PairSpinExchange::coeff(int narg, char **arg)
count++;
}
}
- if (count == 0)
- error->all(FLERR,"Incorrect args in pair_style command");
+
+ if (count == 0) error->all(FLERR,"Incorrect args in pair_style command");
}
/* ----------------------------------------------------------------------
@@ -183,6 +183,12 @@ double PairSpinExchange::init_one(int i, int j)
if (setflag[i][j] == 0) error->all(FLERR,"All pair coeffs are not set");
+ J1_mag[j][i] = J1_mag[i][j];
+ J1_mech[j][i] = J1_mech[i][j];
+ J2[j][i] = J2[i][j];
+ J3[j][i] = J3[i][j];
+ cut_spin_exchange[j][i] = cut_spin_exchange[i][j];
+
return cut_spin_exchange_global;
}
@@ -203,7 +209,8 @@ void PairSpinExchange::compute(int eflag, int vflag)
{
int i,j,ii,jj,inum,jnum,itype,jtype;
double evdwl, ecoul;
- double xi[3], rij[3], eij[3];
+ double xi[3], eij[3];
+ double delx,dely,delz;
double spi[3], spj[3];
double fi[3], fmi[3];
double local_cut2;
@@ -255,18 +262,17 @@ void PairSpinExchange::compute(int eflag, int vflag)
spj[2] = sp[j][2];
evdwl = 0.0;
-
fi[0] = fi[1] = fi[2] = 0.0;
fmi[0] = fmi[1] = fmi[2] = 0.0;
- rij[0] = x[j][0] - xi[0];
- rij[1] = x[j][1] - xi[1];
- rij[2] = x[j][2] - xi[2];
- rsq = rij[0]*rij[0] + rij[1]*rij[1] + rij[2]*rij[2];
+ delx = xi[0] - x[j][0];
+ dely = xi[1] - x[j][1];
+ delz = xi[2] - x[j][2];
+ rsq = delx*delx + dely*dely + delz*delz;
inorm = 1.0/sqrt(rsq);
- eij[0] = inorm*rij[0];
- eij[1] = inorm*rij[1];
- eij[2] = inorm*rij[2];
+ eij[0] = -inorm*delx;
+ eij[1] = -inorm*dely;
+ eij[2] = -inorm*delz;
local_cut2 = cut_spin_exchange[itype][jtype]*cut_spin_exchange[itype][jtype];
@@ -298,7 +304,7 @@ void PairSpinExchange::compute(int eflag, int vflag)
} else evdwl = 0.0;
if (evflag) ev_tally_xyz(i,j,nlocal,newton_pair,
- evdwl,ecoul,fi[0],fi[1],fi[2],rij[0],rij[1],rij[2]);
+ evdwl,ecoul,fi[0],fi[1],fi[2],delx,dely,delz);
}
}
@@ -317,8 +323,8 @@ void PairSpinExchange::compute_single_pair(int ii, double fmi[3])
double **x = atom->x;
double **sp = atom->sp;
double local_cut2;
-
double xi[3], rij[3];
+ double delx,dely,delz;
double spj[3];
int i,j,jnum,itype,jtype;
@@ -351,15 +357,14 @@ void PairSpinExchange::compute_single_pair(int ii, double fmi[3])
spj[1] = sp[j][1];
spj[2] = sp[j][2];
- rij[0] = x[j][0] - xi[0];
- rij[1] = x[j][1] - xi[1];
- rij[2] = x[j][2] - xi[2];
- rsq = rij[0]*rij[0] + rij[1]*rij[1] + rij[2]*rij[2];
+ delx = xi[0] - x[j][0];
+ dely = xi[1] - x[j][1];
+ delz = xi[2] - x[j][2];
+ rsq = delx*delx + dely*dely + delz*delz;
if (rsq <= local_cut2) {
compute_exchange(i,j,rsq,fmi,spj);
}
-
}
}
@@ -390,7 +395,8 @@ void PairSpinExchange::compute_exchange(int i, int j, double rsq, double fmi[3],
compute the mechanical force due to the exchange interaction between atom i and atom j
------------------------------------------------------------------------- */
-void PairSpinExchange::compute_exchange_mech(int i, int j, double rsq, double rij[3], double fi[3], double spi[3], double spj[3])
+void PairSpinExchange::compute_exchange_mech(int i, int j, double rsq, double eij[3],
+ double fi[3], double spi[3], double spj[3])
{
int *type = atom->type;
int itype, jtype;
@@ -408,9 +414,9 @@ void PairSpinExchange::compute_exchange_mech(int i, int j, double rsq, double ri
Jex_mech *= 8.0*Jex*rr*exp(-ra);
Jex_mech *= (spi[0]*spj[0]+spi[1]*spj[1]+spi[2]*spj[2]);
- fi[0] -= Jex_mech*rij[0];
- fi[1] -= Jex_mech*rij[1];
- fi[2] -= Jex_mech*rij[2];
+ fi[0] -= Jex_mech*eij[0];
+ fi[1] -= Jex_mech*eij[1];
+ fi[2] -= Jex_mech*eij[2];
}
/* ----------------------------------------------------------------------
diff --git a/src/SPIN/pair_spin_magelec.cpp b/src/SPIN/pair_spin_magelec.cpp
index e9e7c1fb3f11df2da5cb64d4cea1f1f1d50c09ee..6bc1f71947333ac405e29d6342696165b47379ab 100644
--- a/src/SPIN/pair_spin_magelec.cpp
+++ b/src/SPIN/pair_spin_magelec.cpp
@@ -18,12 +18,12 @@
Please cite the related publication:
Tranchida, J., Plimpton, S. J., Thibaudeau, P., & Thompson, A. P. (2018).
Massively parallel symplectic algorithm for coupled magnetic spin dynamics
- and molecular dynamics. arXiv preprint arXiv:1801.10233.
+ and molecular dynamics. Journal of Computational Physics.
------------------------------------------------------------------------- */
-#include <math.h>
-#include <stdlib.h>
-#include <string.h>
+#include <cmath>
+#include <cstdlib>
+#include <cstring>
#include "atom.h"
#include "comm.h"
@@ -187,8 +187,14 @@ void PairSpinMagelec::init_style()
double PairSpinMagelec::init_one(int i, int j)
{
+ if (setflag[i][j] == 0) error->all(FLERR,"All pair coeffs are not set");
- if (setflag[i][j] == 0) error->all(FLERR,"All pair coeffs are not set");
+ ME[j][i] = ME[i][j];
+ ME_mech[j][i] = ME_mech[i][j];
+ v_mex[j][i] = v_mex[i][j];
+ v_mey[j][i] = v_mey[i][j];
+ v_mez[j][i] = v_mez[i][j];
+ cut_spin_magelec[j][i] = cut_spin_magelec[i][j];
return cut_spin_magelec_global;
}
@@ -211,7 +217,8 @@ void PairSpinMagelec::compute(int eflag, int vflag)
{
int i,j,ii,jj,inum,jnum,itype,jtype;
double evdwl, ecoul;
- double xi[3], rij[3], eij[3];
+ double xi[3], eij[3];
+ double delx,dely,delz;
double spi[3], spj[3];
double fi[3], fmi[3];
double local_cut2;
@@ -263,18 +270,17 @@ void PairSpinMagelec::compute(int eflag, int vflag)
spj[2] = sp[j][2];
evdwl = 0.0;
-
fi[0] = fi[1] = fi[2] = 0.0;
fmi[0] = fmi[1] = fmi[2] = 0.0;
- rij[0] = x[j][0] - xi[0];
- rij[1] = x[j][1] - xi[1];
- rij[2] = x[j][2] - xi[2];
- rsq = rij[0]*rij[0] + rij[1]*rij[1] + rij[2]*rij[2];
+ delx = xi[0] - x[j][0];
+ dely = xi[1] - x[j][1];
+ delz = xi[2] - x[j][2];
+ rsq = delx*delx + dely*dely + delz*delz;
inorm = 1.0/sqrt(rsq);
- eij[0] = inorm*rij[0];
- eij[1] = inorm*rij[1];
- eij[2] = inorm*rij[2];
+ eij[0] = -inorm*delx;
+ eij[1] = -inorm*dely;
+ eij[2] = -inorm*delz;
local_cut2 = cut_spin_magelec[itype][jtype]*cut_spin_magelec[itype][jtype];
@@ -301,12 +307,12 @@ void PairSpinMagelec::compute(int eflag, int vflag)
}
if (eflag) {
- evdwl = (spi[0]*fmi[0] + spi[1]*fmi[1] + spi[2]*fmi[2]);
+ evdwl -= (spi[0]*fmi[0] + spi[1]*fmi[1] + spi[2]*fmi[2]);
evdwl *= hbar;
} else evdwl = 0.0;
if (evflag) ev_tally_xyz(i,j,nlocal,newton_pair,
- evdwl,ecoul,fi[0],fi[1],fi[2],rij[0],rij[1],rij[2]);
+ evdwl,ecoul,fi[0],fi[1],fi[2],delx,dely,delz);
}
}
@@ -322,8 +328,8 @@ void PairSpinMagelec::compute_single_pair(int ii, double fmi[3])
double **x = atom->x;
double **sp = atom->sp;
double local_cut2;
-
- double xi[3], rij[3], eij[3];
+ double xi[3], eij[3];
+ double delx,dely,delz;
double spj[3];
int i,j,jnum,itype,jtype;
@@ -342,8 +348,6 @@ void PairSpinMagelec::compute_single_pair(int ii, double fmi[3])
xi[1] = x[i][1];
xi[2] = x[i][2];
- eij[0] = eij[1] = eij[2] = 0.0;
-
jlist = firstneigh[i];
jnum = numneigh[i];
@@ -358,14 +362,14 @@ void PairSpinMagelec::compute_single_pair(int ii, double fmi[3])
spj[1] = sp[j][1];
spj[2] = sp[j][2];
- rij[0] = x[j][0] - xi[0];
- rij[1] = x[j][1] - xi[1];
- rij[2] = x[j][2] - xi[2];
- rsq = rij[0]*rij[0] + rij[1]*rij[1] + rij[2]*rij[2];
+ delx = xi[0] - x[j][0];
+ dely = xi[1] - x[j][1];
+ delz = xi[2] - x[j][2];
+ rsq = delx*delx + dely*dely + delz*delz;
inorm = 1.0/sqrt(rsq);
- eij[0] = inorm*rij[0];
- eij[1] = inorm*rij[1];
- eij[2] = inorm*rij[2];
+ eij[0] = -inorm*delx;
+ eij[1] = -inorm*dely;
+ eij[2] = -inorm*delz;
if (rsq <= local_cut2) {
compute_magelec(i,j,rsq,eij,fmi,spj);
@@ -380,36 +384,26 @@ void PairSpinMagelec::compute_magelec(int i, int j, double rsq, double eij[3], d
{
int *type = atom->type;
int itype, jtype;
+ double meix,meiy,meiz;
+ double vx,vy,vz;
itype = type[i];
jtype = type[j];
- double local_cut2 = cut_spin_magelec[itype][jtype]*cut_spin_magelec[itype][jtype];
-
- if (rsq <= local_cut2) {
- double meix,meiy,meiz;
- double rx, ry, rz;
- double vx, vy, vz;
-
- rx = eij[0];
- ry = eij[1];
- rz = eij[2];
-
- vx = v_mex[itype][jtype];
- vy = v_mey[itype][jtype];
- vz = v_mez[itype][jtype];
+ vx = v_mex[itype][jtype];
+ vy = v_mey[itype][jtype];
+ vz = v_mez[itype][jtype];
- meix = vy*rz - vz*ry;
- meiy = vz*rx - vx*rz;
- meiz = vx*ry - vy*rx;
+ meix = vy*eij[2] - vz*eij[1];
+ meiy = vz*eij[0] - vx*eij[2];
+ meiz = vx*eij[1] - vy*eij[0];
- meix *= ME[itype][jtype];
- meiy *= ME[itype][jtype];
- meiz *= ME[itype][jtype];
+ meix *= ME[itype][jtype];
+ meiy *= ME[itype][jtype];
+ meiz *= ME[itype][jtype];
- fmi[0] += spj[1]*meiz - spj[2]*meiy;
- fmi[1] += spj[2]*meix - spj[0]*meiz;
- fmi[2] += spj[0]*meiy - spj[1]*meix;
- }
+ fmi[0] += spj[1]*meiz - spj[2]*meiy;
+ fmi[1] += spj[2]*meix - spj[0]*meiz;
+ fmi[2] += spj[0]*meiy - spj[1]*meix;
}
/* ---------------------------------------------------------------------- */
@@ -436,9 +430,9 @@ void PairSpinMagelec::compute_magelec_mech(int i, int j, double fi[3], double sp
meiy *= ME_mech[itype][jtype];
meiz *= ME_mech[itype][jtype];
- fi[0] = meiy*vz - meiz*vy;
- fi[1] = meiz*vx - meix*vz;
- fi[2] = meix*vy - meiy*vx;
+ fi[0] += meiy*vz - meiz*vy;
+ fi[1] += meiz*vx - meix*vz;
+ fi[2] += meix*vy - meiy*vx;
}
diff --git a/src/SPIN/pair_spin_neel.cpp b/src/SPIN/pair_spin_neel.cpp
index d74db638bd6b1081b827d808d505a6700a3ebfa0..55f537cf4fe1c4b2af7de3dc3a1945cca14b4f0e 100644
--- a/src/SPIN/pair_spin_neel.cpp
+++ b/src/SPIN/pair_spin_neel.cpp
@@ -18,12 +18,12 @@
Please cite the related publication:
Tranchida, J., Plimpton, S. J., Thibaudeau, P., & Thompson, A. P. (2018).
Massively parallel symplectic algorithm for coupled magnetic spin dynamics
- and molecular dynamics. arXiv preprint arXiv:1801.10233.
+ and molecular dynamics. Journal of Computational Physics.
------------------------------------------------------------------------- */
-#include <math.h>
-#include <stdlib.h>
-#include <string.h>
+#include <cmath>
+#include <cstdlib>
+#include <cstring>
#include "atom.h"
#include "comm.h"
@@ -193,8 +193,16 @@ void PairSpinNeel::init_style()
double PairSpinNeel::init_one(int i, int j)
{
-
- if (setflag[i][j] == 0) error->all(FLERR,"All pair coeffs are not set");
+ if (setflag[i][j] == 0) error->all(FLERR,"All pair coeffs are not set");
+
+ g1[j][i] = g1[i][j];
+ g1_mech[j][i] = g1_mech[i][j];
+ g2[j][i] = g2[i][j];
+ g3[j][i] = g3[i][j];
+ q1[j][i] = q1[i][j];
+ q1_mech[j][i] = q1_mech[i][j];
+ q2[j][i] = q2[i][j];
+ q3[j][i] = q3[i][j];
return cut_spin_neel_global;
}
diff --git a/src/SPIN/pair_spin_neel.h b/src/SPIN/pair_spin_neel.h
index 934d4a93ad5f2bdd37a53da2403d9c7d7c049c76..f60d7d2dca0e6ac72ea3c0111698f79d60ea2f37 100644
--- a/src/SPIN/pair_spin_neel.h
+++ b/src/SPIN/pair_spin_neel.h
@@ -51,9 +51,9 @@ class PairSpinNeel : public PairSpin {
// pseudo-dipolar and pseudo-quadrupolar coeff.
- double **g1, **g1_mech; // exchange coeffs gij
+ double **g1, **g1_mech; // neel coeffs gij
double **g2, **g3; // g1 in eV, g2 adim, g3 in Ang
- double **q1, **q1_mech; // exchange coeffs qij
+ double **q1, **q1_mech; // neel coeffs qij
double **q2, **q3; // q1 in eV, q2 adim, q3 in Ang
double **cut_spin_neel; // cutoff distance exchange
diff --git a/src/USER-BOCS/fix_bocs.cpp b/src/USER-BOCS/fix_bocs.cpp
index 37e128f55662a6e6c9152abb518d3233845604fd..7fb8a27110ba2528bf81e53f4e6e9c78de23ee54 100644
--- a/src/USER-BOCS/fix_bocs.cpp
+++ b/src/USER-BOCS/fix_bocs.cpp
@@ -846,7 +846,7 @@ void FixBocs::setup(int vflag)
if (pstat_flag) {
double kt = boltz * t_target;
- double nkt = atom->natoms * kt;
+ double nkt = (atom->natoms + 1) * kt;
for (int i = 0; i < 3; i++)
if (p_flag[i])
@@ -1508,7 +1508,7 @@ double FixBocs::compute_scalar()
double volume;
double energy;
double kt = boltz * t_target;
- double lkt_press = kt;
+ double lkt_press = 0.0;
int ich;
if (dimension == 3) volume = domain->xprd * domain->yprd * domain->zprd;
else volume = domain->xprd * domain->yprd;
@@ -1539,15 +1539,21 @@ double FixBocs::compute_scalar()
// sum is over barostatted dimensions
if (pstat_flag) {
- for (i = 0; i < 3; i++)
- if (p_flag[i])
+ for (i = 0; i < 3; i++) {
+ if (p_flag[i]) {
energy += 0.5*omega_dot[i]*omega_dot[i]*omega_mass[i] +
p_hydro*(volume-vol0) / (pdim*nktv2p);
+ lkt_press += kt;
+ }
+ }
if (pstyle == TRICLINIC) {
- for (i = 3; i < 6; i++)
- if (p_flag[i])
+ for (i = 3; i < 6; i++) {
+ if (p_flag[i]) {
energy += 0.5*omega_dot[i]*omega_dot[i]*omega_mass[i];
+ lkt_press += kt;
+ }
+ }
}
// extra contributions from thermostat chain for barostat
@@ -1880,15 +1886,14 @@ void FixBocs::nhc_temp_integrate()
void FixBocs::nhc_press_integrate()
{
- int ich,i;
+ int ich,i,pdof;
double expfac,factor_etap,kecurrent;
double kt = boltz * t_target;
- double lkt_press = kt;
// Update masses, to preserve initial freq, if flag set
if (omega_mass_flag) {
- double nkt = atom->natoms * kt;
+ double nkt = (atom->natoms + 1) * kt;
for (int i = 0; i < 3; i++)
if (p_flag[i])
omega_mass[i] = nkt/(p_freq[i]*p_freq[i]);
@@ -1912,14 +1917,24 @@ void FixBocs::nhc_press_integrate()
}
kecurrent = 0.0;
- for (i = 0; i < 3; i++)
- if (p_flag[i]) kecurrent += omega_mass[i]*omega_dot[i]*omega_dot[i];
+ pdof = 0;
+ for (i = 0; i < 3; i++) {
+ if (p_flag[i]) {
+ kecurrent += omega_mass[i]*omega_dot[i]*omega_dot[i];
+ pdof++;
+ }
+ }
if (pstyle == TRICLINIC) {
- for (i = 3; i < 6; i++)
- if (p_flag[i]) kecurrent += omega_mass[i]*omega_dot[i]*omega_dot[i];
+ for (i = 3; i < 6; i++) {
+ if (p_flag[i]) {
+ kecurrent += omega_mass[i]*omega_dot[i]*omega_dot[i];
+ pdof++;
+ }
+ }
}
+ double lkt_press = pdof * kt;
etap_dotdot[0] = (kecurrent - lkt_press)/etap_mass[0];
double ncfac = 1.0/nc_pchain;
diff --git a/src/USER-COLVARS/fix_colvars.h b/src/USER-COLVARS/fix_colvars.h
index 509eca5de35892b3094cf5749b7d6d088d7b0d18..3029ba9db541e095af265657d5f940998cce224f 100644
--- a/src/USER-COLVARS/fix_colvars.h
+++ b/src/USER-COLVARS/fix_colvars.h
@@ -34,7 +34,6 @@ FixStyle(colvars,FixColvars)
#define LMP_FIX_COLVARS_H
#include "fix.h"
-#include <vector>
// forward declaration
class colvarproxy_lammps;
@@ -77,13 +76,6 @@ class FixColvars : public Fix {
int num_coords; // total number of atoms controlled by this fix
tagint *taglist; // list of all atom IDs referenced by colvars.
- // TODO get rid of these
- // std::vector<cvm::atom_pos> *coords; // coordinates of colvar atoms
- // std::vector<cvm::rvector> *forces; // received forces of colvar atoms
- // std::vector<cvm::rvector> *oforce; // old total forces of colvar atoms
- // std::vector<cvm::real> *masses;
- // std::vector<cvm::real> *charges;
-
int nmax; // size of atom communication buffer.
int size_one; // bytes per atom in communication buffer.
struct commdata *comm_buf; // communication buffer
diff --git a/src/USER-DPD/fix_shardlow.cpp b/src/USER-DPD/fix_shardlow.cpp
index 06185dee7ec702d2dfb3a4686fa88c2c7e3b16f8..7fe865c8e6a9bce50d863c5f5cb14d8b119c1fef 100644
--- a/src/USER-DPD/fix_shardlow.cpp
+++ b/src/USER-DPD/fix_shardlow.cpp
@@ -354,9 +354,8 @@ void FixShardlow::ssa_update_dpde(
double *uMech = atom->uMech;
double *dpdTheta = atom->dpdTheta;
- double *cut_i, *cut2_i, *sigma_i, *kappa_i;
+ double *cut_i, *cut2_i, *sigma_i, *kappa_i, *alpha_i;
double theta_ij_inv, theta_i_inv;
- const double boltz2 = 2.0*force->boltz;
const double boltz_inv = 1.0/force->boltz;
const double ftm2v = force->ftm2v;
@@ -389,6 +388,7 @@ while (ct-- > 0) {
cut_i = pairDPDE->cut[itype];
sigma_i = pairDPDE->sigma[itype];
kappa_i = pairDPDE->kappa[itype];
+ alpha_i = pairDPDE->alpha[itype];
theta_i_inv = 1.0/dpdTheta[i];
const double mass_i = (rmass) ? rmass[i] : mass[itype];
const double massinv_i = 1.0 / mass_i;
@@ -448,7 +448,7 @@ while (ct-- > 0) {
// Compute uCond
double kappa_ij = kappa_i[jtype];
- double alpha_ij = sqrt(boltz2*kappa_ij);
+ double alpha_ij = alpha_i[jtype];
double del_uCond = alpha_ij*wr*dtsqrt * es_normal(RNGstate);
del_uCond += kappa_ij*(theta_i_inv - theta_j_inv)*wdt;
diff --git a/src/USER-DPD/pair_dpd_fdt_energy.cpp b/src/USER-DPD/pair_dpd_fdt_energy.cpp
index d1f3cceed4ca14db73014d7e252770b007d8db95..05dc52eac787b974cf628bf9fd22b984763fab57 100644
--- a/src/USER-DPD/pair_dpd_fdt_energy.cpp
+++ b/src/USER-DPD/pair_dpd_fdt_energy.cpp
@@ -65,6 +65,7 @@ PairDPDfdtEnergy::~PairDPDfdtEnergy()
memory->destroy(a0);
memory->destroy(sigma);
memory->destroy(kappa);
+ memory->destroy(alpha);
memory->destroy(duCond);
memory->destroy(duMech);
}
@@ -269,7 +270,7 @@ void PairDPDfdtEnergy::compute(int eflag, int vflag)
// Compute uCond
randnum = random->gaussian();
kappa_ij = kappa[itype][jtype];
- alpha_ij = sqrt(2.0*force->boltz*kappa_ij);
+ alpha_ij = alpha[itype][jtype];
randPair = alpha_ij*wr*randnum*dtinvsqrt;
uTmp = kappa_ij*(1.0/dpdTheta[i] - 1.0/dpdTheta[j])*wd;
@@ -322,6 +323,7 @@ void PairDPDfdtEnergy::allocate()
memory->create(a0,n+1,n+1,"pair:a0");
memory->create(sigma,n+1,n+1,"pair:sigma");
memory->create(kappa,n+1,n+1,"pair:kappa");
+ memory->create(alpha,n+1,n+1,"pair:alpha");
if (!splitFDT_flag) {
memory->create(duCond,nlocal+nghost+1,"pair:duCond");
memory->create(duMech,nlocal+nghost+1,"pair:duMech");
@@ -374,11 +376,12 @@ void PairDPDfdtEnergy::coeff(int narg, char **arg)
double a0_one = force->numeric(FLERR,arg[2]);
double sigma_one = force->numeric(FLERR,arg[3]);
double cut_one = cut_global;
- double kappa_one;
+ double kappa_one, alpha_one;
a0_is_zero = (a0_one == 0.0); // Typical use with SSA is to set a0 to zero
kappa_one = force->numeric(FLERR,arg[4]);
+ alpha_one = sqrt(2.0*force->boltz*kappa_one);
if (narg == 6) cut_one = force->numeric(FLERR,arg[5]);
int count = 0;
@@ -387,6 +390,7 @@ void PairDPDfdtEnergy::coeff(int narg, char **arg)
a0[i][j] = a0_one;
sigma[i][j] = sigma_one;
kappa[i][j] = kappa_one;
+ alpha[i][j] = alpha_one;
cut[i][j] = cut_one;
setflag[i][j] = 1;
count++;
@@ -435,6 +439,7 @@ double PairDPDfdtEnergy::init_one(int i, int j)
a0[j][i] = a0[i][j];
sigma[j][i] = sigma[i][j];
kappa[j][i] = kappa[i][j];
+ alpha[j][i] = alpha[i][j];
return cut[i][j];
}
@@ -488,6 +493,7 @@ void PairDPDfdtEnergy::read_restart(FILE *fp)
MPI_Bcast(&sigma[i][j],1,MPI_DOUBLE,0,world);
MPI_Bcast(&kappa[i][j],1,MPI_DOUBLE,0,world);
MPI_Bcast(&cut[i][j],1,MPI_DOUBLE,0,world);
+ alpha[i][j] = sqrt(2.0*force->boltz*kappa[i][j]);
a0_is_zero = a0_is_zero && (a0[i][j] == 0.0); // verify the zero assumption
}
}
diff --git a/src/USER-DPD/pair_dpd_fdt_energy.h b/src/USER-DPD/pair_dpd_fdt_energy.h
index dce39f83f071904a0e8d832095edc0f1a7d85a0a..e21b48f7bdb99a28b0735f1a25d38f47c60a8ada 100644
--- a/src/USER-DPD/pair_dpd_fdt_energy.h
+++ b/src/USER-DPD/pair_dpd_fdt_energy.h
@@ -43,7 +43,7 @@ class PairDPDfdtEnergy : public Pair {
double **cut;
double **a0;
- double **sigma,**kappa;
+ double **sigma,**kappa,**alpha;
double *duCond,*duMech;
int seed;
diff --git a/src/USER-MISC/Install.sh b/src/USER-MISC/Install.sh
deleted file mode 100755
index 2d42125ec3a79cdb00cc88cb31d12b8be3959f4d..0000000000000000000000000000000000000000
--- a/src/USER-MISC/Install.sh
+++ /dev/null
@@ -1,40 +0,0 @@
-# Install/unInstall package files in LAMMPS
-# mode = 0/1/2 for uninstall/install/update
-
-mode=$1
-
-# enforce using portable C locale
-LC_ALL=C
-export LC_ALL
-
-# arg1 = file, arg2 = file it depends on
-
-action () {
- if (test $mode = 0) then
- rm -f ../$1
- elif (! cmp -s $1 ../$1) then
- if (test -z "$2" || test -e ../$2) then
- cp $1 ..
- if (test $mode = 2) then
- echo " updating src/$1"
- fi
- fi
- elif (test ! -n "$2") then
- if (test ! -e ../$2) then
- rm -f ../$1
- fi
- fi
-}
-
-# all package files
-# only a few files have dependencies
-
-for file in *.cpp *.h; do
- if (test $file = "pair_cdeam.cpp") then
- action pair_cdeam.cpp pair_eam_alloy.cpp
- elif (test $file = "pair_cdeam.h") then
- action pair_cdeam.h pair_eam_alloy.cpp
- else
- test -f ${file} && action $file
- fi
-done
diff --git a/src/USER-MISC/README b/src/USER-MISC/README
index 68a6252d8dc692285b5577c6281723c4515f8d54..0f9e7bf383bf3e005b828672ad24b360d6f9b440 100644
--- a/src/USER-MISC/README
+++ b/src/USER-MISC/README
@@ -65,7 +65,6 @@ pair_style buck/mdf, Paolo Raiteri, p.raiteri at curtin.edu.au, 2 Dec 15
pair_style coul/diel, Axel Kohlmeyer, akohlmey at gmail.com, 1 Dec 11
pair_style dipole/sf, Mario Orsi, orsimario at gmail.com, 8 Aug 11
pair_style edip, Luca Ferraro, luca.ferraro at caspur.it, 15 Sep 11
-pair_style eam/cd, Alexander Stukowski, stukowski at mm.tu-darmstadt.de, 7 Nov 09
pair_style extep, Jaap Kroes (Radboud U), jaapkroes at gmail dot com, 28 Nov 17
pair_style gauss/cut, Axel Kohlmeyer, akohlmey at gmail.com, 1 Dec 11
pair_style lennard/mdf, Paolo Raiteri, p.raiteri at curtin.edu.au, 2 Dec 15
diff --git a/src/USER-MISC/pair_cdeam.cpp b/src/USER-MISC/pair_cdeam.cpp
deleted file mode 100644
index 53d9036a61d44da205f921c3272ccf41b9075cde..0000000000000000000000000000000000000000
--- a/src/USER-MISC/pair_cdeam.cpp
+++ /dev/null
@@ -1,644 +0,0 @@
-/* ----------------------------------------------------------------------
- LAMMPS - Large-scale Atomic/Molecular Massively Parallel Simulator
- http://lammps.sandia.gov, Sandia National Laboratories
- Steve Plimpton, sjplimp@sandia.gov
-
- Copyright (2003) Sandia Corporation. Under the terms of Contract
- DE-AC04-94AL85000 with Sandia Corporation, the U.S. Government retains
- certain rights in this software. This software is distributed under
- the GNU General Public License.
-
- See the README file in the top-level LAMMPS directory.
-------------------------------------------------------------------------- */
-
-/* ----------------------------------------------------------------------
- Contributing author: Alexander Stukowski
- Technical University of Darmstadt,
- Germany Department of Materials Science
-------------------------------------------------------------------------- */
-
-#include <cmath>
-#include <cstdio>
-#include <cstdlib>
-#include <cstring>
-#include "pair_cdeam.h"
-#include "atom.h"
-#include "force.h"
-#include "comm.h"
-#include "neighbor.h"
-#include "neigh_list.h"
-#include "memory.h"
-#include "error.h"
-
-using namespace LAMMPS_NS;
-
-// This is for debugging purposes. The ASSERT() macro is used in the code to check
-// if everything runs as expected. Change this to #if 0 if you don't need the checking.
-#if 0
- #define ASSERT(cond) ((!(cond)) ? my_failure(error,__FILE__,__LINE__) : my_noop())
-
- inline void my_noop() {}
- inline void my_failure(Error* error, const char* file, int line) {
- char str[1024];
- sprintf(str,"Assertion failure: File %s, line %i", file, line);
- error->one(FLERR,str);
- }
-#else
- #define ASSERT(cond)
-#endif
-
-#define MAXLINE 1024 // This sets the maximum line length in EAM input files.
-
-PairCDEAM::PairCDEAM(LAMMPS *lmp, int _cdeamVersion) : PairEAM(lmp), PairEAMAlloy(lmp), cdeamVersion(_cdeamVersion)
-{
- single_enable = 0;
- restartinfo = 0;
-
- rhoB = NULL;
- D_values = NULL;
- hcoeff = NULL;
-
- // Set communication buffer sizes needed by this pair style.
- if(cdeamVersion == 1) {
- comm_forward = 4;
- comm_reverse = 3;
- }
- else if(cdeamVersion == 2) {
- comm_forward = 3;
- comm_reverse = 2;
- }
- else {
- error->all(FLERR,"Invalid CD-EAM potential version.");
- }
-}
-
-PairCDEAM::~PairCDEAM()
-{
- memory->destroy(rhoB);
- memory->destroy(D_values);
- if(hcoeff) delete[] hcoeff;
-}
-
-void PairCDEAM::compute(int eflag, int vflag)
-{
- int i,j,ii,jj,inum,jnum,itype,jtype;
- double xtmp,ytmp,ztmp,delx,dely,delz,evdwl,fpair;
- double rsq,rhoip,rhojp,recip,phi;
- int *ilist,*jlist,*numneigh,**firstneigh;
-
- evdwl = 0.0;
- if (eflag || vflag) ev_setup(eflag,vflag);
- else evflag = vflag_fdotr = eflag_global = eflag_atom = 0;
-
- // Grow per-atom arrays if necessary
- if(atom->nmax > nmax) {
- memory->destroy(rho);
- memory->destroy(fp);
- memory->destroy(rhoB);
- memory->destroy(D_values);
- nmax = atom->nmax;
- memory->create(rho,nmax,"pair:rho");
- memory->create(rhoB,nmax,"pair:rhoB");
- memory->create(fp,nmax,"pair:fp");
- memory->create(D_values,nmax,"pair:D_values");
- }
-
- double **x = atom->x;
- double **f = atom->f;
- int *type = atom->type;
- int nlocal = atom->nlocal;
- int newton_pair = force->newton_pair;
-
- inum = list->inum;
- ilist = list->ilist;
- numneigh = list->numneigh;
- firstneigh = list->firstneigh;
-
- // Zero out per-atom arrays.
- int m = nlocal + atom->nghost;
- for(i = 0; i < m; i++) {
- rho[i] = 0.0;
- rhoB[i] = 0.0;
- D_values[i] = 0.0;
- }
-
- // Stage I
-
- // Compute rho and rhoB at each local atom site.
- // Additionally calculate the D_i values here if we are using the one-site formulation.
- // For the two-site formulation we have to calculate the D values in an extra loop (Stage II).
- for(ii = 0; ii < inum; ii++) {
- i = ilist[ii];
- xtmp = x[i][0];
- ytmp = x[i][1];
- ztmp = x[i][2];
- itype = type[i];
- jlist = firstneigh[i];
- jnum = numneigh[i];
-
- for(jj = 0; jj < jnum; jj++) {
- j = jlist[jj];
- j &= NEIGHMASK;
-
- delx = xtmp - x[j][0];
- dely = ytmp - x[j][1];
- delz = ztmp - x[j][2];
- rsq = delx*delx + dely*dely + delz*delz;
-
- if(rsq < cutforcesq) {
- jtype = type[j];
- double r = sqrt(rsq);
- const EAMTableIndex index = radiusToTableIndex(r);
- double localrho = RhoOfR(index, jtype, itype);
- rho[i] += localrho;
- if(jtype == speciesB) rhoB[i] += localrho;
- if(newton_pair || j < nlocal) {
- localrho = RhoOfR(index, itype, jtype);
- rho[j] += localrho;
- if(itype == speciesB) rhoB[j] += localrho;
- }
-
- if(cdeamVersion == 1 && itype != jtype) {
- // Note: if the i-j interaction is not concentration dependent (because either
- // i or j are not species A or B) then its contribution to D_i and D_j should
- // be ignored.
- // This if-clause is only required for a ternary.
- if((itype == speciesA && jtype == speciesB) || (jtype == speciesA && itype == speciesB)) {
- double Phi_AB = PhiOfR(index, itype, jtype, 1.0 / r);
- D_values[i] += Phi_AB;
- if(newton_pair || j < nlocal)
- D_values[j] += Phi_AB;
- }
- }
- }
- }
- }
-
- // Communicate and sum densities.
- if(newton_pair) {
- communicationStage = 1;
- comm->reverse_comm_pair(this);
- }
-
- // fp = derivative of embedding energy at each atom
- // phi = embedding energy at each atom
- for(ii = 0; ii < inum; ii++) {
- i = ilist[ii];
- EAMTableIndex index = rhoToTableIndex(rho[i]);
- fp[i] = FPrimeOfRho(index, type[i]);
- if(eflag) {
- phi = FofRho(index, type[i]);
- if (eflag_global) eng_vdwl += phi;
- if (eflag_atom) eatom[i] += phi;
- }
- }
-
- // Communicate derivative of embedding function and densities
- // and D_values (this for one-site formulation only).
- communicationStage = 2;
- comm->forward_comm_pair(this);
-
- // The electron densities may not drop to zero because then the concentration would no longer be defined.
- // But the concentration is not needed anyway if there is no interaction with another atom, which is the case
- // if the electron density is exactly zero. That's why the following lines have been commented out.
- //
- //for(i = 0; i < nlocal + atom->nghost; i++) {
- // if(rho[i] == 0 && (type[i] == speciesA || type[i] == speciesB))
- // error->one(FLERR,"CD-EAM potential routine: Detected atom with zero electron density.");
- //}
-
- // Stage II
- // This is only required for the original two-site formulation of the CD-EAM potential.
-
- if(cdeamVersion == 2) {
- // Compute intermediate value D_i for each atom.
- for(ii = 0; ii < inum; ii++) {
- i = ilist[ii];
- xtmp = x[i][0];
- ytmp = x[i][1];
- ztmp = x[i][2];
- itype = type[i];
- jlist = firstneigh[i];
- jnum = numneigh[i];
-
- // This code line is required for ternary alloys.
- if(itype != speciesA && itype != speciesB) continue;
-
- double x_i = rhoB[i] / rho[i]; // Concentration at atom i.
-
- for(jj = 0; jj < jnum; jj++) {
- j = jlist[jj];
- j &= NEIGHMASK;
- jtype = type[j];
- if(itype == jtype) continue;
-
- // This code line is required for ternary alloys.
- if(jtype != speciesA && jtype != speciesB) continue;
-
- delx = xtmp - x[j][0];
- dely = ytmp - x[j][1];
- delz = ztmp - x[j][2];
- rsq = delx*delx + dely*dely + delz*delz;
-
- if(rsq < cutforcesq) {
- double r = sqrt(rsq);
- const EAMTableIndex index = radiusToTableIndex(r);
-
- // The concentration independent part of the cross pair potential.
- double Phi_AB = PhiOfR(index, itype, jtype, 1.0 / r);
-
- // Average concentration of two sites
- double x_ij = 0.5 * (x_i + rhoB[j]/rho[j]);
-
- // Calculate derivative of h(x_ij) polynomial function.
- double h_prime = evalHprime(x_ij);
-
- D_values[i] += h_prime * Phi_AB / (2.0 * rho[i] * rho[i]);
- if(newton_pair || j < nlocal)
- D_values[j] += h_prime * Phi_AB / (2.0 * rho[j] * rho[j]);
- }
- }
- }
-
- // Communicate and sum D values.
- if(newton_pair) {
- communicationStage = 3;
- comm->reverse_comm_pair(this);
- }
- communicationStage = 4;
- comm->forward_comm_pair(this);
- }
-
- // Stage III
-
- // Compute force acting on each atom.
- for(ii = 0; ii < inum; ii++) {
- i = ilist[ii];
- xtmp = x[i][0];
- ytmp = x[i][1];
- ztmp = x[i][2];
- itype = type[i];
-
- jlist = firstneigh[i];
- jnum = numneigh[i];
-
- // Concentration at site i
- double x_i = -1.0; // The value -1 indicates: no concentration dependence for all interactions of atom i.
- // It will be replaced by the concentration at site i if atom i is either A or B.
-
- double D_i, h_prime_i;
-
- // This if-clause is only required for ternary alloys.
- if((itype == speciesA || itype == speciesB) && rho[i] != 0.0) {
-
- // Compute local concentration at site i.
- x_i = rhoB[i]/rho[i];
- ASSERT(x_i >= 0 && x_i<=1.0);
-
- if(cdeamVersion == 1) {
- // Calculate derivative of h(x_i) polynomial function.
- h_prime_i = evalHprime(x_i);
- D_i = D_values[i] * h_prime_i / (2.0 * rho[i] * rho[i]);
- } else if(cdeamVersion == 2) {
- D_i = D_values[i];
- } else {
- ASSERT(false);
- }
- }
-
- for(jj = 0; jj < jnum; jj++) {
- j = jlist[jj];
- j &= NEIGHMASK;
-
- delx = xtmp - x[j][0];
- dely = ytmp - x[j][1];
- delz = ztmp - x[j][2];
- rsq = delx*delx + dely*dely + delz*delz;
-
- if(rsq < cutforcesq) {
- jtype = type[j];
- double r = sqrt(rsq);
- const EAMTableIndex index = radiusToTableIndex(r);
-
- // rhoip = derivative of (density at atom j due to atom i)
- // rhojp = derivative of (density at atom i due to atom j)
- // psip needs both fp[i] and fp[j] terms since r_ij appears in two
- // terms of embed eng: Fi(sum rho_ij) and Fj(sum rho_ji)
- // hence embed' = Fi(sum rho_ij) rhojp + Fj(sum rho_ji) rhoip
- rhoip = RhoPrimeOfR(index, itype, jtype);
- rhojp = RhoPrimeOfR(index, jtype, itype);
- fpair = fp[i]*rhojp + fp[j]*rhoip;
- recip = 1.0/r;
-
- double x_j = -1; // The value -1 indicates: no concentration dependence for this i-j pair
- // because atom j is not of species A nor B.
-
- // This code line is required for ternary alloy.
- if(jtype == speciesA || jtype == speciesB) {
- ASSERT(rho[i] != 0.0);
- ASSERT(rho[j] != 0.0);
-
- // Compute local concentration at site j.
- x_j = rhoB[j]/rho[j];
- ASSERT(x_j >= 0 && x_j<=1.0);
-
- double D_j=0.0;
- if(cdeamVersion == 1) {
- // Calculate derivative of h(x_j) polynomial function.
- double h_prime_j = evalHprime(x_j);
- D_j = D_values[j] * h_prime_j / (2.0 * rho[j] * rho[j]);
- } else if(cdeamVersion == 2) {
- D_j = D_values[j];
- } else {
- ASSERT(false);
- }
- double t2 = -rhoB[j];
- if(itype == speciesB) t2 += rho[j];
- fpair += D_j * rhoip * t2;
- }
-
- // This if-clause is only required for a ternary alloy.
- // Actually we don't need it at all because D_i should be zero anyway if
- // atom i has no concentration dependent interactions (because it is not species A or B).
- if(x_i != -1.0) {
- double t1 = -rhoB[i];
- if(jtype == speciesB) t1 += rho[i];
- fpair += D_i * rhojp * t1;
- }
-
- double phip;
- double phi = PhiOfR(index, itype, jtype, recip, phip);
- if(itype == jtype || x_i == -1.0 || x_j == -1.0) {
- // Case of no concentration dependence.
- fpair += phip;
- } else {
- // We have a concentration dependence for the i-j interaction.
- double h=0.0;
- if(cdeamVersion == 1) {
- // Calculate h(x_i) polynomial function.
- double h_i = evalH(x_i);
- // Calculate h(x_j) polynomial function.
- double h_j = evalH(x_j);
- h = 0.5 * (h_i + h_j);
- } else if(cdeamVersion == 2) {
- // Average concentration.
- double x_ij = 0.5 * (x_i + x_j);
- // Calculate h(x_ij) polynomial function.
- h = evalH(x_ij);
- } else {
- ASSERT(false);
- }
- fpair += h * phip;
- phi *= h;
- }
-
- // Divide by r_ij and negate to get forces from gradient.
- fpair /= -r;
-
- f[i][0] += delx*fpair;
- f[i][1] += dely*fpair;
- f[i][2] += delz*fpair;
- if(newton_pair || j < nlocal) {
- f[j][0] -= delx*fpair;
- f[j][1] -= dely*fpair;
- f[j][2] -= delz*fpair;
- }
-
- if(eflag) evdwl = phi;
- if(evflag) ev_tally(i,j,nlocal,newton_pair,evdwl,0.0,fpair,delx,dely,delz);
- }
- }
- }
-
- if(vflag_fdotr) virial_fdotr_compute();
-}
-
-/* ---------------------------------------------------------------------- */
-
-void PairCDEAM::coeff(int narg, char **arg)
-{
- PairEAMAlloy::coeff(narg, arg);
-
- // Make sure the EAM file is a CD-EAM binary alloy.
- if(setfl->nelements < 2)
- error->all(FLERR,"The EAM file must contain at least 2 elements to be used with the eam/cd pair style.");
-
- // Read in the coefficients of the h polynomial from the end of the EAM file.
- read_h_coeff(arg[2]);
-
- // Determine which atom type is the A species and which is the B species in the alloy.
- // By default take the first element (index 0) in the EAM file as the A species
- // and the second element (index 1) in the EAM file as the B species.
- speciesA = -1;
- speciesB = -1;
- for(int i = 1; i <= atom->ntypes; i++) {
- if(map[i] == 0) {
- if(speciesA >= 0)
- error->all(FLERR,"The first element from the EAM file may only be mapped to a single atom type.");
- speciesA = i;
- }
- if(map[i] == 1) {
- if(speciesB >= 0)
- error->all(FLERR,"The second element from the EAM file may only be mapped to a single atom type.");
- speciesB = i;
- }
- }
- if(speciesA < 0)
- error->all(FLERR,"The first element from the EAM file must be mapped to exactly one atom type.");
- if(speciesB < 0)
- error->all(FLERR,"The second element from the EAM file must be mapped to exactly one atom type.");
-}
-
-/* ----------------------------------------------------------------------
- Reads in the h(x) polynomial coefficients
-------------------------------------------------------------------------- */
-void PairCDEAM::read_h_coeff(char *filename)
-{
- if(comm->me == 0) {
- // Open potential file
- FILE *fptr;
- char line[MAXLINE];
- char nextline[MAXLINE];
- fptr = force->open_potential(filename);
- if (fptr == NULL) {
- char str[128];
- sprintf(str,"Cannot open EAM potential file %s", filename);
- error->one(FLERR,str);
- }
-
- // h coefficients are stored at the end of the file.
- // Skip to last line of file.
- while(fgets(nextline, MAXLINE, fptr) != NULL) {
- strcpy(line, nextline);
- }
- char* ptr = strtok(line, " \t\n\r\f");
- int degree = atoi(ptr);
- nhcoeff = degree+1;
- hcoeff = new double[nhcoeff];
- int i = 0;
- while((ptr = strtok(NULL," \t\n\r\f")) != NULL && i < nhcoeff) {
- hcoeff[i++] = atof(ptr);
- }
- if(i != nhcoeff || nhcoeff < 1)
- error->one(FLERR,"Failed to read h(x) function coefficients from EAM file.");
-
- // Close the potential file.
- fclose(fptr);
- }
-
- MPI_Bcast(&nhcoeff, 1, MPI_INT, 0, world);
- if(comm->me != 0) hcoeff = new double[nhcoeff];
- MPI_Bcast(hcoeff, nhcoeff, MPI_DOUBLE, 0, world);
-}
-
-
-/* ---------------------------------------------------------------------- */
-
-int PairCDEAM::pack_forward_comm(int n, int *list, double *buf,
- int pbc_flag, int *pbc)
-{
- int i,j,m;
-
- m = 0;
- if(communicationStage == 2) {
- if(cdeamVersion == 1) {
- for (i = 0; i < n; i++) {
- j = list[i];
- buf[m++] = fp[j];
- buf[m++] = rho[j];
- buf[m++] = rhoB[j];
- buf[m++] = D_values[j];
- }
- return m;
- }
- else if(cdeamVersion == 2) {
- for (i = 0; i < n; i++) {
- j = list[i];
- buf[m++] = fp[j];
- buf[m++] = rho[j];
- buf[m++] = rhoB[j];
- }
- return m;
- }
- else { ASSERT(false); return 0; }
- }
- else if(communicationStage == 4) {
- for (i = 0; i < n; i++) {
- j = list[i];
- buf[m++] = D_values[j];
- }
- return m;
- }
- else return 0;
-}
-
-/* ---------------------------------------------------------------------- */
-
-void PairCDEAM::unpack_forward_comm(int n, int first, double *buf)
-{
- int i,m,last;
-
- m = 0;
- last = first + n;
- if(communicationStage == 2) {
- if(cdeamVersion == 1) {
- for(i = first; i < last; i++) {
- fp[i] = buf[m++];
- rho[i] = buf[m++];
- rhoB[i] = buf[m++];
- D_values[i] = buf[m++];
- }
- }
- else if(cdeamVersion == 2) {
- for(i = first; i < last; i++) {
- fp[i] = buf[m++];
- rho[i] = buf[m++];
- rhoB[i] = buf[m++];
- }
- } else {
- ASSERT(false);
- }
- }
- else if(communicationStage == 4) {
- for(i = first; i < last; i++) {
- D_values[i] = buf[m++];
- }
- }
-}
-
-/* ---------------------------------------------------------------------- */
-int PairCDEAM::pack_reverse_comm(int n, int first, double *buf)
-{
- int i,m,last;
-
- m = 0;
- last = first + n;
-
- if(communicationStage == 1) {
- if(cdeamVersion == 1) {
- for(i = first; i < last; i++) {
- buf[m++] = rho[i];
- buf[m++] = rhoB[i];
- buf[m++] = D_values[i];
- }
- return m;
- }
- else if(cdeamVersion == 2) {
- for(i = first; i < last; i++) {
- buf[m++] = rho[i];
- buf[m++] = rhoB[i];
- }
- return m;
- }
- else { ASSERT(false); return 0; }
- }
- else if(communicationStage == 3) {
- for(i = first; i < last; i++) {
- buf[m++] = D_values[i];
- }
- return m;
- }
- else return 0;
-}
-
-/* ---------------------------------------------------------------------- */
-
-void PairCDEAM::unpack_reverse_comm(int n, int *list, double *buf)
-{
- int i,j,m;
-
- m = 0;
- if(communicationStage == 1) {
- if(cdeamVersion == 1) {
- for(i = 0; i < n; i++) {
- j = list[i];
- rho[j] += buf[m++];
- rhoB[j] += buf[m++];
- D_values[j] += buf[m++];
- }
- } else if(cdeamVersion == 2) {
- for(i = 0; i < n; i++) {
- j = list[i];
- rho[j] += buf[m++];
- rhoB[j] += buf[m++];
- }
- } else {
- ASSERT(false);
- }
- }
- else if(communicationStage == 3) {
- for(i = 0; i < n; i++) {
- j = list[i];
- D_values[j] += buf[m++];
- }
- }
-}
-
-/* ----------------------------------------------------------------------
- memory usage of local atom-based arrays
-------------------------------------------------------------------------- */
-double PairCDEAM::memory_usage()
-{
- double bytes = 2 * nmax * sizeof(double);
- return PairEAMAlloy::memory_usage() + bytes;
-}
diff --git a/src/USER-UEF/fix_nh_uef.cpp b/src/USER-UEF/fix_nh_uef.cpp
index cd0b2ba2683742ab1140ce3a41e0e7c506a40a33..bfa45492864ff4708fb0e22167b04b69ca95cbc1 100644
--- a/src/USER-UEF/fix_nh_uef.cpp
+++ b/src/USER-UEF/fix_nh_uef.cpp
@@ -536,10 +536,26 @@ void FixNHUef::pre_exchange()
rotate_x(rot);
rotate_f(rot);
- // put all atoms in the new box
- double **x = atom->x;
+ // this is a generalization of what is done in domain->image_flip(...)
+ int ri[3][3];
+ uefbox->get_inverse_cob(ri);
imageint *image = atom->image;
int nlocal = atom->nlocal;
+ for (int i=0; i<nlocal; i++) {
+ int iold[3],inew[3];
+ iold[0] = (image[i] & IMGMASK) - IMGMAX;
+ iold[1] = (image[i] >> IMGBITS & IMGMASK) - IMGMAX;
+ iold[2] = (image[i] >> IMG2BITS) - IMGMAX;
+ inew[0] = ri[0][0]*iold[0] + ri[0][1]*iold[1] + ri[0][2]*iold[2];
+ inew[1] = ri[1][0]*iold[0] + ri[1][1]*iold[1] + ri[1][2]*iold[2];
+ inew[2] = ri[2][0]*iold[0] + ri[2][1]*iold[1] + ri[2][2]*iold[2];
+ image[i] = ((imageint) (inew[0] + IMGMAX) & IMGMASK) |
+ (((imageint) (inew[1] + IMGMAX) & IMGMASK) << IMGBITS) |
+ (((imageint) (inew[2] + IMGMAX) & IMGMASK) << IMG2BITS);
+ }
+
+ // put all atoms in the new box
+ double **x = atom->x;
for (int i=0; i<nlocal; i++) domain->remap(x[i],image[i]);
// move atoms to the right processors
diff --git a/src/USER-UEF/uef_utils.cpp b/src/USER-UEF/uef_utils.cpp
index a5498d605f3d28291d91dcc320a4cd41dd999ce2..a2e6cb291e0cb4c7b4ff48e9d1d181d0b7f65e4a 100644
--- a/src/USER-UEF/uef_utils.cpp
+++ b/src/USER-UEF/uef_utils.cpp
@@ -30,47 +30,54 @@ namespace LAMMPS_NS {
UEFBox::UEFBox()
{
+
// initial box (also an inverse eigenvector matrix of automorphisms)
+
double x = 0.327985277605681;
double y = 0.591009048506103;
double z = 0.736976229099578;
l0[0][0]= z; l0[0][1]= y; l0[0][2]= x;
l0[1][0]=-x; l0[1][1]= z; l0[1][2]=-y;
l0[2][0]=-y; l0[2][1]= x; l0[2][2]= z;
+
// spectra of the two automorpisms (log of eigenvalues)
+
w1[0]=-1.177725211523360;
w1[1]=-0.441448620566067;
w1[2]= 1.619173832089425;
w2[0]= w1[1];
w2[1]= w1[2];
w2[2]= w1[0];
+
// initialize theta
// strain = w1 * theta1 + w2 * theta2
- theta[0]=theta[1]=0;
+ theta[0]=theta[1]=0;
//set up the initial box l and change of basis matrix r
+
for (int k=0;k<3;k++)
- for (int j=0;j<3;j++)
- {
+ for (int j=0;j<3;j++) {
l[k][j] = l0[k][j];
r[j][k]=(j==k);
+ ri[j][k]=(j==k);
}
// get the initial rotation and upper triangular matrix
+
rotation_matrix(rot, lrot ,l);
// this is just a way to calculate the automorphisms
// themselves, which play a minor role in the calculations
// it's overkill, but only called once
+
double t1[3][3];
double t1i[3][3];
double t2[3][3];
double t2i[3][3];
double l0t[3][3];
for (int k=0; k<3; ++k)
- for (int j=0; j<3; ++j)
- {
+ for (int j=0; j<3; ++j) {
t1[k][j] = exp(w1[k])*l0[k][j];
t1i[k][j] = exp(-w1[k])*l0[k][j];
t2[k][j] = exp(w2[k])*l0[k][j];
@@ -82,8 +89,7 @@ UEFBox::UEFBox()
mul_m2(l0t,t2);
mul_m2(l0t,t2i);
for (int k=0; k<3; ++k)
- for (int j=0; j<3; ++j)
- {
+ for (int j=0; j<3; ++j) {
a1[k][j] = round(t1[k][j]);
a1i[k][j] = round(t1i[k][j]);
a2[k][j] = round(t2[k][j]);
@@ -92,6 +98,7 @@ UEFBox::UEFBox()
// winv used to transform between
// strain increments and theta increments
+
winv[0][0] = w2[1];
winv[0][1] = -w2[0];
winv[1][0] = -w1[1];
@@ -102,7 +109,9 @@ UEFBox::UEFBox()
winv[k][j] /= d;
}
-// get volume-correct r basis in: basis*cbrt(vol) = q*r
+/* ----------------------------------------------------------------------
+ get volume-correct r basis in: basis*cbrt(vol) = q*r
+------------------------------------------------------------------------- */
void UEFBox::get_box(double x[3][3], double v)
{
v = cbrtf(v);
@@ -111,7 +120,9 @@ void UEFBox::get_box(double x[3][3], double v)
x[k][j] = lrot[k][j]*v;
}
-// get rotation matrix q in: basis = q*r
+/* ----------------------------------------------------------------------
+ get rotation matrix q in: basis = q*r
+------------------------------------------------------------------------- */
void UEFBox::get_rot(double x[3][3])
{
for (int k=0;k<3;k++)
@@ -119,20 +130,32 @@ void UEFBox::get_rot(double x[3][3])
x[k][j]=rot[k][j];
}
-// diagonal, incompressible deformation
+/* ----------------------------------------------------------------------
+ get inverse change of basis matrix
+------------------------------------------------------------------------- */
+void UEFBox::get_inverse_cob(int x[3][3])
+{
+ for (int k=0;k<3;k++)
+ for (int j=0;j<3;j++)
+ x[k][j]=ri[k][j];
+}
+
+/* ----------------------------------------------------------------------
+ apply diagonal, incompressible deformation
+------------------------------------------------------------------------- */
void UEFBox::step_deform(const double ex, const double ey)
{
// increment theta values used in the reduction
+
theta[0] +=winv[0][0]*ex + winv[0][1]*ey;
theta[1] +=winv[1][0]*ex + winv[1][1]*ey;
- // deformation of the box. reduce() needs to
- // be called regularly or calculation will become
- // unstable
+ // deformation of the box. reduce() needs to be called regularly or
+ // calculation will become unstable
+
double eps[3];
eps[0]=ex; eps[1] = ey; eps[2] = -ex-ey;
- for (int k=0;k<3;k++)
- {
+ for (int k=0;k<3;k++) {
eps[k] = exp(eps[k]);
l[k][0] = eps[k]*l[k][0];
l[k][1] = eps[k]*l[k][1];
@@ -140,68 +163,84 @@ void UEFBox::step_deform(const double ex, const double ey)
}
rotation_matrix(rot,lrot, l);
}
-// reuduce the current basis
+
+/* ----------------------------------------------------------------------
+ reduce the current basis
+------------------------------------------------------------------------- */
bool UEFBox::reduce()
{
- // determine how many times to apply the automorphisms
- // and find new theta values
+ // determine how many times to apply the automorphisms and find new theta
+ // values
+
int f1 = round(theta[0]);
int f2 = round(theta[1]);
theta[0] -= f1;
theta[1] -= f2;
- // store old change or basis matrix to determine if it
- // changes
+ // store old change or basis matrix to determine if it changes
+
int r0[3][3];
for (int k=0;k<3;k++)
for (int j=0;j<3;j++)
r0[k][j]=r[k][j];
- // this modifies the old change basis matrix to
- // handle the case where the automorphism transforms
- // the box but the reduced basis doesn't change
+ // this modifies the old change basis matrix to handle the case where the
+ // automorphism transforms the box but the reduced basis doesn't change
// (r0 should still equal r at the end)
+
if (f1 > 0) for (int k=0;k<f1;k++) mul_m2 (a1,r0);
if (f1 < 0) for (int k=0;k<-f1;k++) mul_m2 (a1i,r0);
if (f2 > 0) for (int k=0;k<f2;k++) mul_m2 (a2,r0);
if (f2 < 0) for (int k=0;k<-f2;k++) mul_m2 (a2i,r0);
// robust reduction to the box defined by Dobson
- for (int k=0;k<3;k++)
- {
+
+ for (int k=0;k<3;k++) {
double eps = exp(theta[0]*w1[k]+theta[1]*w2[k]);
l[k][0] = eps*l0[k][0];
l[k][1] = eps*l0[k][1];
l[k][2] = eps*l0[k][2];
}
+
// further reduce the box using greedy reduction and check
// if it changed from the last step using the change of basis
// matrices r and r0
- greedy(l,r);
+
+ greedy(l,r,ri);
+
+ // multiplying the inverse by the old change of basis matrix gives
+ // the inverse of the transformation itself (should be identity if
+ // no reduction takes place). This is used for image flags only.
+
+ mul_m1(ri,r0);
rotation_matrix(rot,lrot, l);
return !mat_same(r,r0);
}
+
+/* ----------------------------------------------------------------------
+ set the strain to a specific value
+------------------------------------------------------------------------- */
void UEFBox::set_strain(const double ex, const double ey)
{
- theta[0] =winv[0][0]*ex + winv[0][1]*ey;
- theta[1] =winv[1][0]*ex + winv[1][1]*ey;
+ theta[0] = winv[0][0]*ex + winv[0][1]*ey;
+ theta[1] = winv[1][0]*ex + winv[1][1]*ey;
theta[0] -= round(theta[0]);
theta[1] -= round(theta[1]);
- for (int k=0;k<3;k++)
- {
+ for (int k=0;k<3;k++) {
double eps = exp(theta[0]*w1[k]+theta[1]*w2[k]);
l[k][0] = eps*l0[k][0];
l[k][1] = eps*l0[k][1];
l[k][2] = eps*l0[k][2];
}
- greedy(l,r);
+ greedy(l,r,ri);
rotation_matrix(rot,lrot, l);
}
-// this is just qr reduction using householder reflections
-// m is input matrix, q is a rotation, r is upper triangular
-// q*m = r
+/* ----------------------------------------------------------------------
+ qr reduction using householder reflections
+ q*m = r. q is orthogonal. m is input matrix. r is upper triangular
+------------------------------------------------------------------------- */
void rotation_matrix(double q[3][3], double r[3][3], const double m[3][3])
{
for (int k=0;k<3;k++)
@@ -217,8 +256,7 @@ void rotation_matrix(double q[3][3], double r[3][3], const double m[3][3])
v[0] /= a; v[1] /= a; v[2] /= a;
double qt[3][3];
for (int k=0;k<3;k++)
- for (int j=0;j<3;j++)
- {
+ for (int j=0;j<3;j++) {
qt[k][j] = (k==j) - 2*v[k]*v[j];
q[k][j]= qt[k][j];
}
@@ -235,38 +273,42 @@ void rotation_matrix(double q[3][3], double r[3][3], const double m[3][3])
qt[k][j] = (k==j) - 2*v[k]*v[j];
mul_m2(qt,r);
mul_m2(qt,q);
+
// this makes r have positive diagonals
// q*m = r <==> (-q)*m = (-r) will hold row-wise
+
if (r[0][0] < 0){ neg_row(q,0); neg_row(r,0); }
if (r[1][1] < 0){ neg_row(q,1); neg_row(r,1); }
if (r[2][2] < 0){ neg_row(q,2); neg_row(r,2); }
}
-
-
-//sort columns in order of increasing length
-void col_sort(double b[3][3],int r[3][3])
+/* ----------------------------------------------------------------------
+ sort columns of b in order of increasing length
+ mimic column operations on ri and r
+------------------------------------------------------------------------- */
+void col_sort(double b[3][3],int r[3][3],int ri[3][3])
{
- if (col_prod(b,0,0)>col_prod(b,1,1))
- {
+ if (col_prod(b,0,0)>col_prod(b,1,1)) {
col_swap(b,0,1);
col_swap(r,0,1);
+ col_swap(ri,0,1);
}
- if (col_prod(b,0,0)>col_prod(b,2,2))
- {
+ if (col_prod(b,0,0)>col_prod(b,2,2)) {
col_swap(b,0,2);
col_swap(r,0,2);
+ col_swap(ri,0,2);
}
- if (col_prod(b,1,1)>col_prod(b,2,2))
- {
+ if (col_prod(b,1,1)>col_prod(b,2,2)) {
col_swap(b,1,2);
col_swap(r,1,2);
+ col_swap(ri,1,2);
}
}
-
-// 1-2 reduction (Graham-Schmidt)
-void red12(double b[3][3],int r[3][3])
+/* ----------------------------------------------------------------------
+ 1-2 reduction (Graham-Schmidt)
+------------------------------------------------------------------------- */
+void red12(double b[3][3],int r[3][3],int ri[3][3])
{
int y = round(col_prod(b,0,1)/col_prod(b,0,0));
b[0][1] -= y*b[0][0];
@@ -276,16 +318,23 @@ void red12(double b[3][3],int r[3][3])
r[0][1] -= y*r[0][0];
r[1][1] -= y*r[1][0];
r[2][1] -= y*r[2][0];
- if (col_prod(b,1,1) < col_prod(b,0,0))
- {
+
+ ri[0][0] += y*ri[0][1];
+ ri[1][0] += y*ri[1][1];
+ ri[2][0] += y*ri[2][1];
+
+ if (col_prod(b,1,1) < col_prod(b,0,0)) {
col_swap(b,0,1);
col_swap(r,0,1);
- red12(b,r);
+ col_swap(ri,0,1);
+ red12(b,r,ri);
}
}
-// The Semaev condition for a 3-reduced basis
-void red3(double b[3][3], int r[3][3])
+/* ----------------------------------------------------------------------
+ Apply the Semaev condition for a 3-reduced basis
+------------------------------------------------------------------------- */
+void red3(double b[3][3], int r[3][3], int ri[3][3])
{
double b11 = col_prod(b,0,0);
double b22 = col_prod(b,1,1);
@@ -304,63 +353,97 @@ void red3(double b[3][3], int r[3][3])
x1v[0] = floor(y1); x1v[1] = x1v[0]+1;
x2v[0] = floor(y2); x2v[1] = x2v[0]+1;
for (int k=0;k<2;k++)
- for (int j=0;j<2;j++)
- {
+ for (int j=0;j<2;j++) {
double a[3];
a[0] = b[0][2] + x1v[k]*b[0][0] + x2v[j]*b[0][1];
a[1] = b[1][2] + x1v[k]*b[1][0] + x2v[j]*b[1][1];
a[2] = b[2][2] + x1v[k]*b[2][0] + x2v[j]*b[2][1];
double val=a[0]*a[0]+a[1]*a[1]+a[2]*a[2];
- if (val<min)
- {
+ if (val<min) {
min = val;
x1 = x1v[k];
x2 = x2v[j];
}
}
- if (x1 || x2)
- {
+ if (x1 || x2) {
b[0][2] += x1*b[0][0] + x2*b[0][1];
b[1][2] += x1*b[1][0] + x2*b[1][1];
b[2][2] += x1*b[2][0] + x2*b[2][1];
r[0][2] += x1*r[0][0] + x2*r[0][1];
r[1][2] += x1*r[1][0] + x2*r[1][1];
r[2][2] += x1*r[2][0] + x2*r[2][1];
- greedy_recurse(b,r); // note the recursion step is here
+ ri[0][0] += -x1*ri[0][2];
+ ri[1][0] += -x1*ri[1][2];
+ ri[2][0] += -x1*ri[2][2];
+ ri[0][1] += -x2*ri[0][2];
+ ri[1][1] += -x2*ri[1][2];
+ ri[2][1] += -x2*ri[2][2];
+ greedy_recurse(b,r,ri); // note the recursion step is here
}
}
-// the meat of the greedy reduction algorithm
-void greedy_recurse(double b[3][3], int r[3][3])
+/* ----------------------------------------------------------------------
+ the meat of the greedy reduction algorithm
+------------------------------------------------------------------------- */
+void greedy_recurse(double b[3][3], int r[3][3], int ri[3][3])
{
- col_sort(b,r);
- red12(b,r);
- red3(b,r); // recursive caller
+ col_sort(b,r,ri);
+ red12(b,r,ri);
+ red3(b,r,ri); // recursive caller
}
-// set r (change of basis) to be identity then reduce basis and make it unique
-void greedy(double b[3][3],int r[3][3])
+/* ----------------------------------------------------------------------
+ reduce the basis b. also output the change of basis matrix r and its
+ inverse ri
+------------------------------------------------------------------------- */
+void greedy(double b[3][3],int r[3][3],int ri[3][3])
{
r[0][1]=r[0][2]=r[1][0]=r[1][2]=r[2][0]=r[2][1]=0;
r[0][0]=r[1][1]=r[2][2]=1;
- greedy_recurse(b,r);
- make_unique(b,r);
+ ri[0][1]=ri[0][2]=ri[1][0]=ri[1][2]=ri[2][0]=ri[2][1]=0;
+ ri[0][0]=ri[1][1]=ri[2][2]=1;
+ greedy_recurse(b,r,ri);
+ make_unique(b,r,ri);
+ transpose(ri);
}
-// A reduced basis isn't unique. This procedure will make it
-// "more" unique. Degenerate cases are possible, but unlikely
-// with floating point math.
-void make_unique(double b[3][3], int r[3][3])
+/* ----------------------------------------------------------------------
+ A reduced basis isn't unique. This procedure will make it
+ "more" unique. Degenerate cases are possible, but unlikely
+ with floating point math.
+------------------------------------------------------------------------- */
+void make_unique(double b[3][3], int r[3][3], int ri[3][3])
{
- if (fabs(b[0][0]) < fabs(b[0][1]))
- { col_swap(b,0,1); col_swap(r,0,1); }
- if (fabs(b[0][0]) < fabs(b[0][2]))
- { col_swap(b,0,2); col_swap(r,0,2); }
- if (fabs(b[1][1]) < fabs(b[1][2]))
- { col_swap(b,1,2); col_swap(r,1,2); }
-
- if (b[0][0] < 0){ neg_col(b,0); neg_col(r,0); }
- if (b[1][1] < 0){ neg_col(b,1); neg_col(r,1); }
- if (det(b) < 0){ neg_col(b,2); neg_col(r,2); }
+ if (fabs(b[0][0]) < fabs(b[0][1])) {
+ col_swap(b,0,1);
+ col_swap(r,0,1);
+ col_swap(ri,0,1);
+ }
+ if (fabs(b[0][0]) < fabs(b[0][2])) {
+ col_swap(b,0,2);
+ col_swap(r,0,2);
+ col_swap(ri,0,2);
+ }
+ if (fabs(b[1][1]) < fabs(b[1][2])) {
+ col_swap(b,1,2);
+ col_swap(r,1,2);
+ col_swap(ri,1,2);
+ }
+
+ if (b[0][0] < 0) {
+ neg_col(b,0);
+ neg_col(r,0);
+ neg_col(ri,0);
+ }
+ if (b[1][1] < 0) {
+ neg_col(b,1);
+ neg_col(r,1);
+ neg_col(ri,1);
+ }
+ if (det(b) < 0) {
+ neg_col(b,2);
+ neg_col(r,2);
+ neg_col(ri,2);
+ }
}
}}
diff --git a/src/USER-UEF/uef_utils.h b/src/USER-UEF/uef_utils.h
index a16f6fff1a70f1e5e15b3f993efc702deaaf034f..0a1cfcc9b2ca9f897d9bf4caed142644d24cf3fe 100644
--- a/src/USER-UEF/uef_utils.h
+++ b/src/USER-UEF/uef_utils.h
@@ -27,26 +27,27 @@ class UEFBox
bool reduce();
void get_box(double[3][3], double);
void get_rot(double[3][3]);
+ void get_inverse_cob(int[3][3]);
private:
double l0[3][3]; // initial basis
- double w1[3],w2[3], winv[3][3]; // omega1 and omega2 (spectra of automorphisms)
- //double edot[3], delta[2];
+ double w1[3],w2[3],winv[3][3];//omega1 and omega2 (spectra of automorphisms)
double theta[2];
double l[3][3], rot[3][3], lrot[3][3];
- int r[3][3],a1[3][3],a2[3][3],a1i[3][3],a2i[3][3];
+ int r[3][3],ri[3][3],a1[3][3],a2[3][3],a1i[3][3],a2i[3][3];
};
-
// lattice reduction routines
-void greedy(double[3][3],int[3][3]);
-void col_sort(double[3][3],int[3][3]);
-void red12(double[3][3],int[3][3]);
-void greedy_recurse(double[3][3],int[3][3]);
-void red3(double [3][3],int r[3][3]);
-void make_unique(double[3][3],int[3][3]);
+
+void greedy(double[3][3],int[3][3],int[3][3]);
+void col_sort(double[3][3],int[3][3],int[3][3]);
+void red12(double[3][3],int[3][3],int[3][3]);
+void greedy_recurse(double[3][3],int[3][3],int[3][3]);
+void red3(double [3][3],int r[3][3],int[3][3]);
+void make_unique(double[3][3],int[3][3],int[3][3]);
void rotation_matrix(double[3][3],double[3][3],const double [3][3]);
// A few utility functions for 3x3 arrays
+
template<typename T>
T col_prod(T x[3][3], int c1, int c2)
{
@@ -56,8 +57,7 @@ T col_prod(T x[3][3], int c1, int c2)
template<typename T>
void col_swap(T x[3][3], int c1, int c2)
{
- for (int k=0;k<3;k++)
- {
+ for (int k=0;k<3;k++) {
T t = x[k][c2];
x[k][c2]=x[k][c1];
x[k][c1]=t;
@@ -101,9 +101,21 @@ bool mat_same(T x1[3][3], T x2[3][3])
}
template<typename T>
-void mul_m1(T m1[3][3], const T m2[3][3])
+void transpose(T m[3][3])
{
T t[3][3];
+ for (int k=0;k<3;k++)
+ for (int j=k+1;j<3;j++) {
+ T x = m[k][j];
+ m[k][j] = m[j][k];
+ m[j][k] = x;
+ }
+}
+
+template<typename T1,typename T2>
+void mul_m1(T1 m1[3][3], const T2 m2[3][3])
+{
+ T1 t[3][3];
for (int k=0;k<3;k++)
for (int j=0;j<3;j++)
t[k][j]=m1[k][j];
@@ -113,10 +125,10 @@ void mul_m1(T m1[3][3], const T m2[3][3])
m1[k][j] = t[k][0]*m2[0][j] + t[k][1]*m2[1][j] + t[k][2]*m2[2][j];
}
-template<typename T>
-void mul_m2(const T m1[3][3], T m2[3][3])
+template<typename T1, typename T2>
+void mul_m2(const T1 m1[3][3], T2 m2[3][3])
{
- T t[3][3];
+ T2 t[3][3];
for (int k=0;k<3;k++)
for (int j=0;j<3;j++)
t[k][j]=m2[k][j];
diff --git a/src/balance.cpp b/src/balance.cpp
index 86deb55b47ff716f6e05f1ce0d4adcc3f7d4d793..2a953caf477acc84863fa3f39e4ad54e518128cd 100644
--- a/src/balance.cpp
+++ b/src/balance.cpp
@@ -350,13 +350,13 @@ void Balance::command(int narg, char **arg)
domain->set_local_box();
// move particles to new processors via irregular()
+ // set disable = 0, so weights migrate with atoms for imbfinal calculation
if (domain->triclinic) domain->x2lamda(atom->nlocal);
Irregular *irregular = new Irregular(lmp);
if (wtflag) fixstore->disable = 0;
if (style == BISECTION) irregular->migrate_atoms(1,1,rcb->sendproc);
else irregular->migrate_atoms(1);
- if (wtflag) fixstore->disable = 1;
delete irregular;
if (domain->triclinic) domain->lamda2x(atom->nlocal);
@@ -377,9 +377,11 @@ void Balance::command(int narg, char **arg)
}
// imbfinal = final imbalance
+ // set disable = 1, so weights no longer migrate with atoms
double maxfinal;
double imbfinal = imbalance_factor(maxfinal);
+ if (wtflag) fixstore->disable = 1;
// stats output
@@ -540,6 +542,8 @@ void Balance::weight_storage(char *prefix)
fixstore = (FixStore *) modify->fix[modify->nfix-1];
} else fixstore = (FixStore *) modify->fix[ifix];
+ // do not carry weights with atoms during normal atom migration
+
fixstore->disable = 1;
if (prefix) delete [] fixargs[0];
@@ -643,6 +647,21 @@ int *Balance::bisection(int sortflag)
double *shrinklo = &shrinkall[0];
double *shrinkhi = &shrinkall[3];
+ // if shrink size in any dim is zero, use box size in that dim
+
+ if (shrinklo[0] == shrinkhi[0]) {
+ shrinklo[0] = boxlo[0];
+ shrinkhi[0] = boxhi[0];
+ }
+ if (shrinklo[1] == shrinkhi[1]) {
+ shrinklo[1] = boxlo[1];
+ shrinkhi[1] = boxhi[1];
+ }
+ if (shrinklo[2] == shrinkhi[2]) {
+ shrinklo[2] = boxlo[2];
+ shrinkhi[2] = boxhi[2];
+ }
+
// invoke RCB
// then invert() to create list of proc assignments for my atoms
// NOTE: (3/2017) can remove undocumented "old" option at some point
diff --git a/src/compute_cluster_atom.cpp b/src/compute_cluster_atom.cpp
index 146f8fd1b3c7d64491e1213038b94c4ba9d0a32a..85934c5e6d20df3a6eaa915d8269d32988147120 100644
--- a/src/compute_cluster_atom.cpp
+++ b/src/compute_cluster_atom.cpp
@@ -31,6 +31,8 @@
using namespace LAMMPS_NS;
+enum{CLUSTER,MASK,COORDS};
+
/* ---------------------------------------------------------------------- */
ComputeClusterAtom::ComputeClusterAtom(LAMMPS *lmp, int narg, char **arg) :
@@ -44,7 +46,7 @@ ComputeClusterAtom::ComputeClusterAtom(LAMMPS *lmp, int narg, char **arg) :
peratom_flag = 1;
size_peratom_cols = 0;
- comm_forward = 1;
+ comm_forward = 3;
nmax = 0;
}
@@ -122,10 +124,19 @@ void ComputeClusterAtom::compute_peratom()
numneigh = list->numneigh;
firstneigh = list->firstneigh;
+ // if update->post_integrate set:
+ // a dynamic group in FixGroup is invoking a variable with this compute
+ // thus ghost atom coords need to be up-to-date after initial_integrate()
+
+ if (update->post_integrate) {
+ commflag = COORDS;
+ comm->forward_comm_compute(this);
+ }
+
// if group is dynamic, insure ghost atom masks are current
if (group->dynamic[igroup]) {
- commflag = 0;
+ commflag = MASK;
comm->forward_comm_compute(this);
}
@@ -147,7 +158,7 @@ void ComputeClusterAtom::compute_peratom()
// iterate until no changes in my atoms
// then check if any proc made changes
- commflag = 1;
+ commflag = CLUSTER;
double **x = atom->x;
int change,done,anychange;
@@ -203,17 +214,25 @@ int ComputeClusterAtom::pack_forward_comm(int n, int *list, double *buf,
int i,j,m;
m = 0;
- if (commflag) {
+ if (commflag == CLUSTER) {
for (i = 0; i < n; i++) {
j = list[i];
buf[m++] = clusterID[j];
}
- } else {
+ } else if (commflag == MASK) {
int *mask = atom->mask;
for (i = 0; i < n; i++) {
j = list[i];
buf[m++] = ubuf(mask[j]).d;
}
+ } else if (commflag == COORDS) {
+ double **x = atom->x;
+ for (i = 0; i < n; i++) {
+ j = list[i];
+ buf[m++] = x[j][0];
+ buf[m++] = x[j][1];
+ buf[m++] = x[j][2];
+ }
}
return m;
@@ -227,11 +246,18 @@ void ComputeClusterAtom::unpack_forward_comm(int n, int first, double *buf)
m = 0;
last = first + n;
- if (commflag)
+ if (commflag == CLUSTER) {
for (i = first; i < last; i++) clusterID[i] = buf[m++];
- else {
+ } else if (commflag == MASK) {
int *mask = atom->mask;
for (i = first; i < last; i++) mask[i] = (int) ubuf(buf[m++]).i;
+ } else if (commflag == COORDS) {
+ double **x = atom->x;
+ for (i = first; i < last; i++) {
+ x[i][0] = buf[m++];
+ x[i][1] = buf[m++];
+ x[i][2] = buf[m++];
+ }
}
}
diff --git a/src/error.cpp b/src/error.cpp
index d516050385c212ae0c8eb7da4466778baf96a447..3feaf1d1acde855d71ca3d3fd79ed5afd83934d2 100644
--- a/src/error.cpp
+++ b/src/error.cpp
@@ -16,6 +16,7 @@
#include <cstring>
#include "error.h"
#include "universe.h"
+#include "update.h"
#include "output.h"
#include "input.h"
@@ -69,6 +70,10 @@ void Error::universe_all(const char *file, int line, const char *str)
if (universe->ulogfile) fclose(universe->ulogfile);
#ifdef LAMMPS_EXCEPTIONS
+
+ // allow commands if an exception was caught in a run
+ update->whichflag = 0;
+
char msg[100];
sprintf(msg, "ERROR: %s (%s:%d)\n", str, file, line);
throw LAMMPSException(msg);
@@ -90,6 +95,10 @@ void Error::universe_one(const char *file, int line, const char *str)
universe->me,str,truncpath(file),line);
#ifdef LAMMPS_EXCEPTIONS
+
+ // allow commands if an exception was caught in a run
+ update->whichflag = 0;
+
char msg[100];
sprintf(msg, "ERROR: %s (%s:%d)\n", str, file, line);
throw LAMMPSAbortException(msg, universe->uworld);
@@ -137,6 +146,10 @@ void Error::all(const char *file, int line, const char *str)
}
#ifdef LAMMPS_EXCEPTIONS
+
+ // allow commands if an exception was caught in a run
+ update->whichflag = 0;
+
char msg[100];
sprintf(msg, "ERROR: %s (%s:%d)\n", str, file, line);
@@ -183,6 +196,10 @@ void Error::one(const char *file, int line, const char *str)
universe->me,str,truncpath(file),line);
#ifdef LAMMPS_EXCEPTIONS
+
+ // allow commands if an exception was caught in a run
+ update->whichflag = 0;
+
char msg[100];
sprintf(msg, "ERROR on proc %d: %s (%s:%d)\n", me, str, file, line);
throw LAMMPSAbortException(msg, world);
diff --git a/src/fix_balance.cpp b/src/fix_balance.cpp
index b2f545c73fbbefa4af2f2a46d244ea78be352a60..e748e0ae31c0fd0e550d35dff5b5f3898daeccac 100644
--- a/src/fix_balance.cpp
+++ b/src/fix_balance.cpp
@@ -114,6 +114,7 @@ FixBalance::FixBalance(LAMMPS *lmp, int narg, char **arg) :
if (nevery) force_reneighbor = 1;
lastbalance = -1;
+ next_reneighbor = -1;
// compute initial outputs
@@ -248,6 +249,10 @@ void FixBalance::pre_neighbor()
if (!pending) return;
imbfinal = balance->imbalance_factor(maxloadperproc);
pending = 0;
+
+ // set disable = 1, so weights no longer migrate with atoms
+
+ if (wtflag) balance->fixstore->disable = 1;
}
/* ----------------------------------------------------------------------
@@ -275,21 +280,23 @@ void FixBalance::rebalance()
// reset proc sub-domains
// check and warn if any proc's subbox is smaller than neigh skin
- // since may lead to lost atoms in exchange()
+ // since may lead to lost atoms in comm->exchange()
if (domain->triclinic) domain->set_lamda_box();
domain->set_local_box();
domain->subbox_too_small_check(neighbor->skin);
// move atoms to new processors via irregular()
- // only needed if migrate_check() says an atom moves to far
+ // for non-RCB only needed if migrate_check() says an atom moves too far
// else allow caller's comm->exchange() to do it
+ // set disable = 0, so weights migrate with atoms
+ // important to delay disable = 1 until after pre_neighbor imbfinal calc
+ // b/c atoms may migrate again in comm->exchange()
if (domain->triclinic) domain->x2lamda(atom->nlocal);
if (wtflag) balance->fixstore->disable = 0;
if (lbstyle == BISECTION) irregular->migrate_atoms(0,1,sendproc);
else if (irregular->migrate_check()) irregular->migrate_atoms();
- if (wtflag) balance->fixstore->disable = 1;
if (domain->triclinic) domain->lamda2x(atom->nlocal);
// invoke KSpace setup_grid() to adjust to new proc sub-domains
diff --git a/src/fix_enforce2d.cpp b/src/fix_enforce2d.cpp
index 4ffd2ca7ac233342910b495e839ac293f5583dd4..791a52c50cb39e13c61d2d8159820c71c03dbb87 100644
--- a/src/fix_enforce2d.cpp
+++ b/src/fix_enforce2d.cpp
@@ -38,6 +38,8 @@ FixEnforce2D::FixEnforce2D(LAMMPS *lmp, int narg, char **arg) :
FixEnforce2D::~FixEnforce2D()
{
+ if (copymode) return;
+
delete [] flist;
}
diff --git a/src/fix_enforce2d.h b/src/fix_enforce2d.h
index cdead78f6a0755daa47bdf740ba3962ee95a602d..a3f79309dccd2f9b83d4f2ef02f4b311af7c40b7 100644
--- a/src/fix_enforce2d.h
+++ b/src/fix_enforce2d.h
@@ -36,7 +36,7 @@ class FixEnforce2D : public Fix {
void post_force_respa(int, int, int);
void min_post_force(int);
- private:
+ protected:
int nfixlist;
class Fix **flist;
};
diff --git a/src/fix_group.cpp b/src/fix_group.cpp
index 2447002bc5202350b779d390dc31124a7f5dd5a1..10736964e788d5b76d47ea392737c35f714fedb9 100644
--- a/src/fix_group.cpp
+++ b/src/fix_group.cpp
@@ -84,7 +84,7 @@ idregion(NULL), idvar(NULL), idprop(NULL)
idprop = new char[n];
strcpy(idprop,arg[iarg+1]);
iarg += 2;
- } else if (strcmp(arg[iarg],"every") == 0) {
+ } else if (strcmp(arg[iarg],"every") == 0) {
if (iarg+2 > narg) error->all(FLERR,"Illegal group command");
nevery = force->inumeric(FLERR,arg[iarg+1]);
if (nevery <= 0) error->all(FLERR,"Illegal group command");
@@ -204,17 +204,22 @@ void FixGroup::set_group()
int nlocal = atom->nlocal;
// invoke atom-style variable if defined
+ // set post_integrate flag to 1, then unset after
+ // this is for any compute to check if it needs to
+ // operate differently due to invocation this early in timestep
+ // e.g. perform ghost comm update due to atoms having just moved
double *var = NULL;
int *ivector = NULL;
double *dvector = NULL;
-
if (varflag) {
+ update->post_integrate = 1;
modify->clearstep_compute();
memory->create(var,nlocal,"fix/group:varvalue");
input->variable->compute_atom(ivar,igroup,var,1,0);
modify->addstep_compute(update->ntimestep + nevery);
+ update->post_integrate = 0;
}
// invoke per-atom property if defined
diff --git a/src/fix_nh.cpp b/src/fix_nh.cpp
index 186376d95230bc8d2bbbf977c95fba8c5c16243f..73c70420c5bc84e001d448a5d580b1fe10ce9ece 100644
--- a/src/fix_nh.cpp
+++ b/src/fix_nh.cpp
@@ -798,7 +798,7 @@ void FixNH::setup(int vflag)
if (pstat_flag) {
double kt = boltz * t_target;
- double nkt = atom->natoms * kt;
+ double nkt = (atom->natoms + 1) * kt;
for (int i = 0; i < 3; i++)
if (p_flag[i])
@@ -1446,7 +1446,7 @@ double FixNH::compute_scalar()
double volume;
double energy;
double kt = boltz * t_target;
- double lkt_press = kt;
+ double lkt_press = 0.0;
int ich;
if (dimension == 3) volume = domain->xprd * domain->yprd * domain->zprd;
else volume = domain->xprd * domain->yprd;
@@ -1477,15 +1477,21 @@ double FixNH::compute_scalar()
// sum is over barostatted dimensions
if (pstat_flag) {
- for (i = 0; i < 3; i++)
- if (p_flag[i])
+ for (i = 0; i < 3; i++) {
+ if (p_flag[i]) {
energy += 0.5*omega_dot[i]*omega_dot[i]*omega_mass[i] +
p_hydro*(volume-vol0) / (pdim*nktv2p);
+ lkt_press += kt;
+ }
+ }
if (pstyle == TRICLINIC) {
- for (i = 3; i < 6; i++)
- if (p_flag[i])
+ for (i = 3; i < 6; i++) {
+ if (p_flag[i]) {
energy += 0.5*omega_dot[i]*omega_dot[i]*omega_mass[i];
+ lkt_press += kt;
+ }
+ }
}
// extra contributions from thermostat chain for barostat
@@ -1818,15 +1824,15 @@ void FixNH::nhc_temp_integrate()
void FixNH::nhc_press_integrate()
{
- int ich,i;
+ int ich,i,pdof;
double expfac,factor_etap,kecurrent;
double kt = boltz * t_target;
- double lkt_press = kt;
+ double lkt_press;
// Update masses, to preserve initial freq, if flag set
if (omega_mass_flag) {
- double nkt = atom->natoms * kt;
+ double nkt = (atom->natoms + 1) * kt;
for (int i = 0; i < 3; i++)
if (p_flag[i])
omega_mass[i] = nkt/(p_freq[i]*p_freq[i]);
@@ -1850,14 +1856,22 @@ void FixNH::nhc_press_integrate()
}
kecurrent = 0.0;
+ pdof = 0;
for (i = 0; i < 3; i++)
- if (p_flag[i]) kecurrent += omega_mass[i]*omega_dot[i]*omega_dot[i];
+ if (p_flag[i]) {
+ kecurrent += omega_mass[i]*omega_dot[i]*omega_dot[i];
+ pdof++;
+ }
if (pstyle == TRICLINIC) {
for (i = 3; i < 6; i++)
- if (p_flag[i]) kecurrent += omega_mass[i]*omega_dot[i]*omega_dot[i];
+ if (p_flag[i]) {
+ kecurrent += omega_mass[i]*omega_dot[i]*omega_dot[i];
+ pdof++;
+ }
}
+ lkt_press = pdof * kt;
etap_dotdot[0] = (kecurrent - lkt_press)/etap_mass[0];
double ncfac = 1.0/nc_pchain;
diff --git a/src/fix_store.cpp b/src/fix_store.cpp
index 3b1f3dca77dde1d15d645938e000a012c202ee9c..350e12097270c1e64f80313af5665ca60e719963 100644
--- a/src/fix_store.cpp
+++ b/src/fix_store.cpp
@@ -154,8 +154,6 @@ void FixStore::reset_global(int nrow_caller, int ncol_caller)
if (vecflag) memory->create(vstore,nrow,"fix/store:vstore");
else memory->create(astore,nrow,ncol,"fix/store:astore");
memory->create(rbuf,nrow*ncol+2,"fix/store:rbuf");
-
- // printf("AAA HOW GET HERE\n");
}
/* ----------------------------------------------------------------------
diff --git a/src/group.cpp b/src/group.cpp
index 9d33da9acb4e623ea80a0e1f5e9e5fe1928ada07..dd5e53bb3c58234655c8fcf76c171dc84cf386b1 100644
--- a/src/group.cpp
+++ b/src/group.cpp
@@ -754,6 +754,18 @@ void Group::read_restart(FILE *fp)
// computations on a group of atoms
// ----------------------------------------------------------------------
+/* ----------------------------------------------------------------------
+ count atoms in group all
+------------------------------------------------------------------------- */
+
+bigint Group::count_all()
+{
+ bigint nme = atom->nlocal;
+ bigint nall;
+ MPI_Allreduce(&nme,&nall,1,MPI_LMP_BIGINT,MPI_SUM,world);
+ return nall;
+}
+
/* ----------------------------------------------------------------------
count atoms in group
------------------------------------------------------------------------- */
diff --git a/src/group.h b/src/group.h
index 6b6cbb1def7e4d2e5340fa6ce3f0b14664f642f3..962d37b32ad53538dba1fa36f31e1338d79f6b37 100644
--- a/src/group.h
+++ b/src/group.h
@@ -37,6 +37,7 @@ class Group : protected Pointers {
void write_restart(FILE *);
void read_restart(FILE *);
+ bigint count_all(); // count atoms in group all
bigint count(int); // count atoms in group
bigint count(int,int); // count atoms in group & region
double mass(int); // total mass of atoms in group
diff --git a/src/lmptype.h b/src/lmptype.h
index 2be1d2ac385ccdb0e1dad96a4c23f2143a4bf10a..7e359d2abeda05c1b0ec992cb7b113b9be7e67ab 100644
--- a/src/lmptype.h
+++ b/src/lmptype.h
@@ -46,6 +46,13 @@
#define PRId64 "ld"
#endif
+// favor qsort over mergesort for stable release
+// TODO: to be removed after stable release
+
+#ifndef LMP_QSORT
+#define LMP_QSORT
+#endif
+
namespace LAMMPS_NS {
// enum used for KOKKOS host/device flags
diff --git a/src/pack.h b/src/pack.h
index 066535f5c9fc576094ef9a059e090a2d10393286..837c33d14bc4b284eb8df25585d6b8ae34181f44 100644
--- a/src/pack.h
+++ b/src/pack.h
@@ -22,9 +22,8 @@ struct pack_plan_3d {
int nqty; // # of values/element
};
-
-#if !defined(PACK_POINTER) && !defined(PACK_MEMCPY)
-#define PACK_ARRAY
+#if !defined(FFT_PACK_POINTER) && !defined(FFT_PACK_MEMCPY)
+#define FFT_PACK_ARRAY
#endif
#ifndef PACK_DATA
@@ -47,7 +46,7 @@ struct pack_plan_3d {
pack/unpack with array indices
------------------------------------------------------------------------- */
-#ifdef PACK_ARRAY
+#ifdef FFT_PACK_ARRAY
/* ----------------------------------------------------------------------
pack from data -> buf
@@ -274,7 +273,7 @@ static void unpack_3d_permute2_n(PACK_DATA *buf, PACK_DATA *data, struct pack_pl
pack/unpack with pointers
------------------------------------------------------------------------- */
-#ifdef PACK_POINTER
+#ifdef FFT_PACK_POINTER
/* ----------------------------------------------------------------------
pack from data -> buf
@@ -523,7 +522,7 @@ static void unpack_3d_permute2_n(PACK_DATA *buf, PACK_DATA *data, struct pack_pl
just use PACK_POINTER versions
------------------------------------------------------------------------- */
-#ifdef PACK_MEMCPY
+#ifdef FFT_PACK_MEMCPY
/* ----------------------------------------------------------------------
pack from data -> buf
diff --git a/src/pair.cpp b/src/pair.cpp
index 9bb1ad212f19de34473e5f115d22b3c8bebe2acb..5c308cc7ce51e840713abfaeacdcbd8190ce95e9 100644
--- a/src/pair.cpp
+++ b/src/pair.cpp
@@ -693,17 +693,19 @@ void Pair::compute_dummy(int eflag, int vflag)
}
/* ---------------------------------------------------------------------- */
+
void Pair::read_restart(FILE *)
{
if (comm->me == 0)
- error->warning(FLERR,"BUG: restartinfo=1 but no restart support in pair style");
+ error->warning(FLERR,"Pair style restartinfo set but has no restart support");
}
/* ---------------------------------------------------------------------- */
+
void Pair::write_restart(FILE *)
{
if (comm->me == 0)
- error->warning(FLERR,"BUG: restartinfo=1 but no restart support in pair style");
+ error->warning(FLERR,"Pair style restartinfo set but has no restart support");
}
/* -------------------------------------------------------------------
diff --git a/src/rcb.cpp b/src/rcb.cpp
index 3027920310055351370fd6bff70f61038f01b726..13e27b6fbfda836c53b381db8171f59f4b921e0d 100644
--- a/src/rcb.cpp
+++ b/src/rcb.cpp
@@ -241,9 +241,11 @@ void RCB::compute(int dimension, int n, double **x, double *wt,
// dim_select = selected cut dimension
// valuehalf_select = valuehalf in that dimension
// dotmark_select = dot markings in that dimension
+ // initialize largest = -1.0 to insure a cut in some dim is accepted
+ // e.g. if current recursed box is size 0 in all dims
int dim_select = -1;
- double largest = 0.0;
+ double largest = -1.0;
for (dim = 0; dim < dimension; dim++) {
diff --git a/src/read_restart.cpp b/src/read_restart.cpp
index 1164de6faa91acea7ebc08b985d317618c723e9f..7d8e6ca3955c0d547e354cde414ba3838864cf18 100644
--- a/src/read_restart.cpp
+++ b/src/read_restart.cpp
@@ -62,7 +62,9 @@ enum{VERSION,SMALLINT,TAGINT,BIGINT,
MULTIPROC,MPIIO,PROCSPERFILE,PERPROC,
IMAGEINT,BOUNDMIN,TIMESTEP,
ATOM_ID,ATOM_MAP_STYLE,ATOM_MAP_USER,ATOM_SORTFREQ,ATOM_SORTBIN,
- COMM_MODE,COMM_CUTOFF,COMM_VEL,NO_PAIR};
+ COMM_MODE,COMM_CUTOFF,COMM_VEL,NO_PAIR,
+ EXTRA_BOND_PER_ATOM,EXTRA_ANGLE_PER_ATOM,EXTRA_DIHEDRAL_PER_ATOM,
+ EXTRA_IMPROPER_PER_ATOM,EXTRA_SPECIAL_PER_ATOM};
#define LB_FACTOR 1.1
@@ -914,6 +916,17 @@ void ReadRestart::header(int incompatible)
} else if (flag == COMM_VEL) {
comm->ghost_velocity = read_int();
+ } else if (flag == EXTRA_BOND_PER_ATOM) {
+ atom->extra_bond_per_atom = read_int();
+ } else if (flag == EXTRA_ANGLE_PER_ATOM) {
+ atom->extra_angle_per_atom = read_int();
+ } else if (flag == EXTRA_DIHEDRAL_PER_ATOM) {
+ atom->extra_dihedral_per_atom = read_int();
+ } else if (flag == EXTRA_IMPROPER_PER_ATOM) {
+ atom->extra_improper_per_atom = read_int();
+ } else if (flag == EXTRA_SPECIAL_PER_ATOM) {
+ force->special_extra = read_int();
+
} else error->all(FLERR,"Invalid flag in header section of restart file");
flag = read_int();
diff --git a/src/reset_ids.cpp b/src/reset_ids.cpp
index 8a33cd535bf9d60746b90910e370145dd1f31113..fd898bd3ab63db79f7b45e659ae346e6d19bdab9 100644
--- a/src/reset_ids.cpp
+++ b/src/reset_ids.cpp
@@ -16,6 +16,7 @@
#include "atom_vec.h"
#include "domain.h"
#include "comm.h"
+#include "special.h"
#include "memory.h"
#include "error.h"
@@ -44,7 +45,7 @@ void ResetIDs::command(int narg, char **arg)
}
// create an atom map if one doesn't exist already
-
+
int mapflag = 0;
if (atom->map_style == 0) {
mapflag = 1;
@@ -93,7 +94,7 @@ void ResetIDs::command(int narg, char **arg)
// forward_comm_array acquires new IDs for ghost atoms
double **newIDs;
- memory->create(newIDs,nall,1,"reset_ids:newIDs");
+ memory->create(newIDs,nall,1,"reset_ids:newIDs");
for (int i = 0; i < nlocal; i++) {
newIDs[i][0] = tag[i];
@@ -105,7 +106,7 @@ void ResetIDs::command(int narg, char **arg)
// loop over bonds, angles, etc and reset IDs in stored topology arrays
// only necessary for molecular = 1, not molecular = 2
// badcount = atom IDs that could not be found
-
+
int badcount = 0;
if (atom->molecular == 1) {
@@ -232,8 +233,15 @@ void ResetIDs::command(int narg, char **arg)
atom->map_init();
atom->map_set();
+ // need to update exclusions with new atom IDs
+
+ if (atom->molecular == 1) {
+ Special special(lmp);
+ special.build();
+ }
+
// delete temporary atom map
-
+
if (mapflag) {
atom->map_delete();
atom->map_style = 0;
diff --git a/src/set.cpp b/src/set.cpp
index 0294f93e5dfa0a4bb61edc8d08eca145c7bdb5f3..7eca4e9a9c64c0db21618933d8747d903441cea6 100644
--- a/src/set.cpp
+++ b/src/set.cpp
@@ -48,7 +48,7 @@ enum{TYPE,TYPE_FRACTION,MOLECULE,X,Y,Z,CHARGE,MASS,SHAPE,LENGTH,TRI,
THETA,THETA_RANDOM,ANGMOM,OMEGA,
DIAMETER,DENSITY,VOLUME,IMAGE,BOND,ANGLE,DIHEDRAL,IMPROPER,
MESO_E,MESO_CV,MESO_RHO,EDPD_TEMP,EDPD_CV,CC,SMD_MASS_DENSITY,
- SMD_CONTACT_RADIUS,DPDTHETA,INAME,DNAME};
+ SMD_CONTACT_RADIUS,DPDTHETA,INAME,DNAME,VX,VY,VZ};
#define BIG INT_MAX
@@ -141,6 +141,27 @@ void Set::command(int narg, char **arg)
set(Z);
iarg += 2;
+ } else if (strcmp(arg[iarg],"vx") == 0) {
+ if (iarg+2 > narg) error->all(FLERR,"Illegal set command");
+ if (strstr(arg[iarg+1],"v_") == arg[iarg+1]) varparse(arg[iarg+1],1);
+ else dvalue = force->numeric(FLERR,arg[iarg+1]);
+ set(VX);
+ iarg += 2;
+
+ } else if (strcmp(arg[iarg],"vy") == 0) {
+ if (iarg+2 > narg) error->all(FLERR,"Illegal set command");
+ if (strstr(arg[iarg+1],"v_") == arg[iarg+1]) varparse(arg[iarg+1],1);
+ else dvalue = force->numeric(FLERR,arg[iarg+1]);
+ set(VY);
+ iarg += 2;
+
+ } else if (strcmp(arg[iarg],"vz") == 0) {
+ if (iarg+2 > narg) error->all(FLERR,"Illegal set command");
+ if (strstr(arg[iarg+1],"v_") == arg[iarg+1]) varparse(arg[iarg+1],1);
+ else dvalue = force->numeric(FLERR,arg[iarg+1]);
+ set(VZ);
+ iarg += 2;
+
} else if (strcmp(arg[iarg],"charge") == 0) {
if (iarg+2 > narg) error->all(FLERR,"Illegal set command");
if (strstr(arg[iarg+1],"v_") == arg[iarg+1]) varparse(arg[iarg+1],1);
@@ -732,6 +753,9 @@ void Set::set(int keyword)
else if (keyword == X) atom->x[i][0] = dvalue;
else if (keyword == Y) atom->x[i][1] = dvalue;
else if (keyword == Z) atom->x[i][2] = dvalue;
+ else if (keyword == VX) atom->v[i][0] = dvalue;
+ else if (keyword == VY) atom->v[i][1] = dvalue;
+ else if (keyword == VZ) atom->v[i][2] = dvalue;
else if (keyword == CHARGE) atom->q[i] = dvalue;
else if (keyword == MASS) {
if (dvalue <= 0.0) error->one(FLERR,"Invalid mass in set command");
diff --git a/src/thermo.cpp b/src/thermo.cpp
index ade7a3c333ab893fdd14a17adaa94a966328b64a..ddbbd0f496eab5c87b59f028a5b4adaac8f1b764 100644
--- a/src/thermo.cpp
+++ b/src/thermo.cpp
@@ -1698,7 +1698,7 @@ void Thermo::compute_timeremain()
void Thermo::compute_atoms()
{
- bivalue = atom->natoms;
+ bivalue = group->count_all();
}
/* ---------------------------------------------------------------------- */
diff --git a/src/update.cpp b/src/update.cpp
index aa152a850857e729f78da1db98e678e41140f1d7..6f9c2c9a076ff8b911431bf623efd4a47301f6fe 100644
--- a/src/update.cpp
+++ b/src/update.cpp
@@ -46,11 +46,11 @@ Update::Update(LAMMPS *lmp) : Pointers(lmp)
whichflag = 0;
firststep = laststep = 0;
beginstep = endstep = 0;
+ restrict_output = 0;
setupflag = 0;
+ post_integrate = 0;
multireplica = 0;
- restrict_output = 0;
-
eflag_global = vflag_global = -1;
unit_style = NULL;
diff --git a/src/update.h b/src/update.h
index 79964403182db7add9289a3dc4945ef14eaf9386..d3602ef21e98b0dfcbc036e29625831d3a27be3a 100644
--- a/src/update.h
+++ b/src/update.h
@@ -35,6 +35,7 @@ class Update : protected Pointers {
int max_eval; // max force evaluations for minimizer
int restrict_output; // 1 if output should not write dump/restart
int setupflag; // set when setup() is computing forces
+ int post_integrate; // 1 if now at post_integrate() in timestep
int multireplica; // 1 if min across replicas, else 0
bigint eflag_global,eflag_atom; // timestep global/peratom eng is tallied on
diff --git a/src/variable.cpp b/src/variable.cpp
index 86296b4b402e4c066d2692d5362d579be635c54d..f005221400509f76fd5887f0323fa11cc8f30a32 100644
--- a/src/variable.cpp
+++ b/src/variable.cpp
@@ -1576,7 +1576,8 @@ double Variable::evaluate(char *str, Tree **tree, int ivar)
newtree->nextra = 0;
treestack[ntreestack++] = newtree;
- } else print_var_error(FLERR,"Mismatched compute in variable formula",ivar);
+ } else print_var_error(FLERR,
+ "Mismatched compute in variable formula",ivar);
// ----------------
// fix
@@ -1584,7 +1585,8 @@ double Variable::evaluate(char *str, Tree **tree, int ivar)
} else if (strncmp(word,"f_",2) == 0 || strncmp(word,"F_",2) == 0) {
if (domain->box_exist == 0)
- print_var_error(FLERR,"Variable evaluation before simulation box is defined",ivar);
+ print_var_error(FLERR,"Variable evaluation before "
+ "simulation box is defined",ivar);
// uppercase used to force access of
// global vector vs global scalar, and global array vs global vector
@@ -1667,11 +1669,14 @@ double Variable::evaluate(char *str, Tree **tree, int ivar)
if (index1 > fix->size_array_rows &&
fix->size_array_rows_variable == 0)
- print_var_error(FLERR,"Variable formula fix array is accessed out-of-range",ivar);
+ print_var_error(FLERR,"Variable formula fix array is "
+ "accessed out-of-range",ivar);
if (index2 > fix->size_array_cols)
- print_var_error(FLERR,"Variable formula fix array is accessed out-of-range",ivar);
+ print_var_error(FLERR,"Variable formula fix array is "
+ "accessed out-of-range",ivar);
if (update->whichflag > 0 && update->ntimestep % fix->global_freq)
- print_var_error(FLERR,"Fix in variable not computed at a compatible time",ivar);
+ print_var_error(FLERR,"Fix in variable not computed at a "
+ "compatible time",ivar);
value1 = fix->compute_array(index1-1,index2-1);
if (tree) {
@@ -1688,13 +1693,17 @@ double Variable::evaluate(char *str, Tree **tree, int ivar)
} else if (nbracket == 0 && fix->vector_flag) {
if (update->whichflag > 0 && update->ntimestep % fix->global_freq)
- print_var_error(FLERR,"Fix in variable not computed at compatible time",ivar);
+ print_var_error(FLERR,"Fix in variable not computed at "
+ "compatible time",ivar);
if (tree == NULL)
- print_var_error(FLERR,"Fix global vector in ""equal-style variable formula",ivar);
+ print_var_error(FLERR,"Fix global vector in "
+ "equal-style variable formula",ivar);
if (treetype == ATOM)
- print_var_error(FLERR,"Fix global vector in ""atom-style variable formula",ivar);
+ print_var_error(FLERR,"Fix global vector in "
+ "atom-style variable formula",ivar);
if (fix->size_vector == 0)
- print_var_error(FLERR,"Variable formula fix vector is zero length",ivar);
+ print_var_error(FLERR,"Variable formula "
+ "fix vector is zero length",ivar);
int nvec = fix->size_vector;
double *vec;
@@ -1726,7 +1735,8 @@ double Variable::evaluate(char *str, Tree **tree, int ivar)
print_var_error(FLERR,"Fix global vector in "
"atom-style variable formula",ivar);
if (fix->size_array_rows == 0)
- print_var_error(FLERR,"Variable formula fix array is zero length",ivar);
+ print_var_error(FLERR,"Variable formula fix array is "
+ "zero length",ivar);
int nvec = fix->size_array_rows;
double *vec;
@@ -1785,10 +1795,12 @@ double Variable::evaluate(char *str, Tree **tree, int ivar)
fix->size_peratom_cols == 0) {
if (tree == NULL)
- print_var_error(FLERR,"Per-atom fix in equal-style variable formula",ivar);
+ print_var_error(FLERR,"Per-atom fix in "
+ "equal-style variable formula",ivar);
if (update->whichflag > 0 &&
update->ntimestep % fix->peratom_freq)
- print_var_error(FLERR,"Fix in variable not computed at compatible time",ivar);
+ print_var_error(FLERR,"Fix in variable not computed at "
+ "compatible time",ivar);
Tree *newtree = new Tree();
newtree->type = ATOMARRAY;
@@ -1805,13 +1817,15 @@ double Variable::evaluate(char *str, Tree **tree, int ivar)
fix->size_peratom_cols > 0) {
if (tree == NULL)
- print_var_error(FLERR,"Per-atom fix in equal-style variable formula",ivar);
+ print_var_error(FLERR,"Per-atom fix in "
+ "equal-style variable formula",ivar);
if (index1 > fix->size_peratom_cols)
print_var_error(FLERR,"Variable formula fix array "
"is accessed out-of-range",ivar);
if (update->whichflag > 0 &&
update->ntimestep % fix->peratom_freq)
- print_var_error(FLERR,"Fix in variable not computed at compatible time",ivar);
+ print_var_error(FLERR,"Fix in variable not computed at "
+ "compatible time",ivar);
Tree *newtree = new Tree();
newtree->type = ATOMARRAY;
@@ -1878,7 +1892,8 @@ double Variable::evaluate(char *str, Tree **tree, int ivar)
char *var = retrieve(word+2);
if (var == NULL)
- print_var_error(FLERR,"Invalid variable evaluation in variable formula",ivar);
+ print_var_error(FLERR,"Invalid variable evaluation in "
+ "variable formula",ivar);
if (tree) {
Tree *newtree = new Tree();
newtree->type = VALUE;
@@ -1977,7 +1992,8 @@ double Variable::evaluate(char *str, Tree **tree, int ivar)
double *vec;
int nvec = compute_vector(ivar,&vec);
if (index <= 0 || index > nvec)
- print_var_error(FLERR,"Invalid index into vector-style variable",ivar);
+ print_var_error(FLERR,"Invalid index into "
+ "vector-style variable",ivar);
int m = index; // convert from tagint to int
if (tree) {
@@ -1989,7 +2005,8 @@ double Variable::evaluate(char *str, Tree **tree, int ivar)
treestack[ntreestack++] = newtree;
} else argstack[nargstack++] = vec[m-1];
- } else print_var_error(FLERR,"Mismatched variable in variable formula",ivar);
+ } else print_var_error(FLERR,"Mismatched variable in "
+ "variable formula",ivar);
// ----------------
// math/group/special function or atom value/vector or
@@ -2194,7 +2211,8 @@ double Variable::evaluate(char *str, Tree **tree, int ivar)
if (value2 == 0.0)
argstack[nargstack++] = 1.0;
else if ((value1 == 0.0) && (value2 < 0.0))
- print_var_error(FLERR,"Invalid power expression in variable formula",ivar);
+ print_var_error(FLERR,"Invalid power expression in "
+ "variable formula",ivar);
else argstack[nargstack++] = pow(value1,value2);
} else if (opprevious == UNARY) {
argstack[nargstack++] = -value2;
@@ -3368,7 +3386,8 @@ int Variable::math_function(char *word, char *contents, Tree **tree,
if (tree) newtree->type = LN;
else {
if (value1 <= 0.0)
- print_var_error(FLERR,"Log of zero/negative value in variable formula",ivar);
+ print_var_error(FLERR,"Log of zero/negative value in "
+ "variable formula",ivar);
argstack[nargstack++] = log(value1);
}
} else if (strcmp(word,"log") == 0) {
@@ -3377,7 +3396,8 @@ int Variable::math_function(char *word, char *contents, Tree **tree,
if (tree) newtree->type = LOG;
else {
if (value1 <= 0.0)
- print_var_error(FLERR,"Log of zero/negative value in variable formula",ivar);
+ print_var_error(FLERR,"Log of zero/negative value in "
+ "variable formula",ivar);
argstack[nargstack++] = log10(value1);
}
} else if (strcmp(word,"abs") == 0) {
@@ -3482,7 +3502,8 @@ int Variable::math_function(char *word, char *contents, Tree **tree,
if (narg != 2)
print_var_error(FLERR,"Invalid math function in variable formula",ivar);
if (update->whichflag == 0)
- print_var_error(FLERR,"Cannot use ramp in variable formula between runs",ivar);
+ print_var_error(FLERR,"Cannot use ramp in "
+ "variable formula between runs",ivar);
if (tree) newtree->type = RAMP;
else {
double delta = update->ntimestep - update->beginstep;
@@ -3617,7 +3638,8 @@ int Variable::math_function(char *word, char *contents, Tree **tree,
if (narg != 2)
print_var_error(FLERR,"Invalid math function in variable formula",ivar);
if (update->whichflag == 0)
- print_var_error(FLERR,"Cannot use vdisplace in variable formula between runs",ivar);
+ print_var_error(FLERR,"Cannot use vdisplace in "
+ "variable formula between runs",ivar);
if (tree) newtree->type = VDISPLACE;
else {
double delta = update->ntimestep - update->beginstep;
@@ -3629,7 +3651,8 @@ int Variable::math_function(char *word, char *contents, Tree **tree,
if (narg != 3)
print_var_error(FLERR,"Invalid math function in variable formula",ivar);
if (update->whichflag == 0)
- print_var_error(FLERR,"Cannot use swiggle in variable formula between runs",ivar);
+ print_var_error(FLERR,"Cannot use swiggle in "
+ "variable formula between runs",ivar);
if (tree) newtree->type = CWIGGLE;
else {
if (values[0] == 0.0)
@@ -3644,7 +3667,8 @@ int Variable::math_function(char *word, char *contents, Tree **tree,
if (narg != 3)
print_var_error(FLERR,"Invalid math function in variable formula",ivar);
if (update->whichflag == 0)
- print_var_error(FLERR,"Cannot use cwiggle in variable formula between runs",ivar);
+ print_var_error(FLERR,"Cannot use cwiggle in "
+ "variable formula between runs",ivar);
if (tree) newtree->type = CWIGGLE;
else {
if (values[0] == 0.0)
@@ -3709,7 +3733,8 @@ int Variable::group_function(char *word, char *contents, Tree **tree,
if (strcmp(word,"count") == 0) {
if (narg == 1) value = group->count(igroup);
- else if (narg == 2) value = group->count(igroup,region_function(args[1],ivar));
+ else if (narg == 2)
+ value = group->count(igroup,region_function(args[1],ivar));
else print_var_error(FLERR,"Invalid group function in variable formula",ivar);
} else if (strcmp(word,"mass") == 0) {
@@ -3719,7 +3744,8 @@ int Variable::group_function(char *word, char *contents, Tree **tree,
} else if (strcmp(word,"charge") == 0) {
if (narg == 1) value = group->charge(igroup);
- else if (narg == 2) value = group->charge(igroup,region_function(args[1],ivar));
+ else if (narg == 2)
+ value = group->charge(igroup,region_function(args[1],ivar));
else print_var_error(FLERR,"Invalid group function in variable formula",ivar);
} else if (strcmp(word,"xcm") == 0) {
@@ -3732,7 +3758,8 @@ int Variable::group_function(char *word, char *contents, Tree **tree,
int iregion = region_function(args[2],ivar);
double masstotal = group->mass(igroup,iregion);
group->xcm(igroup,masstotal,xcm,iregion);
- } else print_var_error(FLERR,"Invalid group function in variable formula",ivar);
+ } else print_var_error(FLERR,"Invalid group function in "
+ "variable formula",ivar);
if (strcmp(args[1],"x") == 0) value = xcm[0];
else if (strcmp(args[1],"y") == 0) value = xcm[1];
else if (strcmp(args[1],"z") == 0) value = xcm[2];
@@ -3748,7 +3775,8 @@ int Variable::group_function(char *word, char *contents, Tree **tree,
int iregion = region_function(args[2],ivar);
double masstotal = group->mass(igroup,iregion);
group->vcm(igroup,masstotal,vcm,iregion);
- } else print_var_error(FLERR,"Invalid group function in variable formula",ivar);
+ } else print_var_error(FLERR,"Invalid group function in "
+ "variable formula",ivar);
if (strcmp(args[1],"x") == 0) value = vcm[0];
else if (strcmp(args[1],"y") == 0) value = vcm[1];
else if (strcmp(args[1],"z") == 0) value = vcm[2];
@@ -3767,7 +3795,8 @@ int Variable::group_function(char *word, char *contents, Tree **tree,
} else if (strcmp(word,"bound") == 0) {
double minmax[6];
if (narg == 2) group->bounds(igroup,minmax);
- else if (narg == 3) group->bounds(igroup,minmax,region_function(args[2],ivar));
+ else if (narg == 3)
+ group->bounds(igroup,minmax,region_function(args[2],ivar));
else print_var_error(FLERR,"Invalid group function in variable formula",ivar);
if (strcmp(args[1],"xmin") == 0) value = minmax[0];
else if (strcmp(args[1],"xmax") == 0) value = minmax[1];
@@ -3789,7 +3818,8 @@ int Variable::group_function(char *word, char *contents, Tree **tree,
double masstotal = group->mass(igroup,iregion);
group->xcm(igroup,masstotal,xcm,iregion);
value = group->gyration(igroup,masstotal,xcm,iregion);
- } else print_var_error(FLERR,"Invalid group function in variable formula",ivar);
+ } else print_var_error(FLERR,"Invalid group function in "
+ "variable formula",ivar);
} else if (strcmp(word,"ke") == 0) {
if (narg == 1) value = group->ke(igroup);
@@ -3808,7 +3838,8 @@ int Variable::group_function(char *word, char *contents, Tree **tree,
double masstotal = group->mass(igroup,iregion);
group->xcm(igroup,masstotal,xcm,iregion);
group->angmom(igroup,xcm,lmom,iregion);
- } else print_var_error(FLERR,"Invalid group function in variable formula",ivar);
+ } else print_var_error(FLERR,"Invalid group function in "
+ "variable formula",ivar);
if (strcmp(args[1],"x") == 0) value = lmom[0];
else if (strcmp(args[1],"y") == 0) value = lmom[1];
else if (strcmp(args[1],"z") == 0) value = lmom[2];
@@ -3826,7 +3857,8 @@ int Variable::group_function(char *word, char *contents, Tree **tree,
double masstotal = group->mass(igroup,iregion);
group->xcm(igroup,masstotal,xcm,iregion);
group->torque(igroup,xcm,tq,iregion);
- } else print_var_error(FLERR,"Invalid group function in variable formula",ivar);
+ } else print_var_error(FLERR,"Invalid group function in "
+ "variable formula",ivar);
if (strcmp(args[1],"x") == 0) value = tq[0];
else if (strcmp(args[1],"y") == 0) value = tq[1];
else if (strcmp(args[1],"z") == 0) value = tq[2];
@@ -3844,7 +3876,8 @@ int Variable::group_function(char *word, char *contents, Tree **tree,
double masstotal = group->mass(igroup,iregion);
group->xcm(igroup,masstotal,xcm,iregion);
group->inertia(igroup,xcm,inertia,iregion);
- } else print_var_error(FLERR,"Invalid group function in variable formula",ivar);
+ } else print_var_error(FLERR,"Invalid group function in "
+ "variable formula",ivar);
if (strcmp(args[1],"xx") == 0) value = inertia[0][0];
else if (strcmp(args[1],"yy") == 0) value = inertia[1][1];
else if (strcmp(args[1],"zz") == 0) value = inertia[2][2];
@@ -3869,7 +3902,8 @@ int Variable::group_function(char *word, char *contents, Tree **tree,
group->angmom(igroup,xcm,angmom,iregion);
group->inertia(igroup,xcm,inertia,iregion);
group->omega(angmom,inertia,omega);
- } else print_var_error(FLERR,"Invalid group function in variable formula",ivar);
+ } else print_var_error(FLERR,"Invalid group function in "
+ "variable formula",ivar);
if (strcmp(args[1],"x") == 0) value = omega[0];
else if (strcmp(args[1],"y") == 0) value = omega[1];
else if (strcmp(args[1],"z") == 0) value = omega[2];
@@ -3924,7 +3958,8 @@ int Variable::special_function(char *word, char *contents, Tree **tree,
Tree **treestack, int &ntreestack,
double *argstack, int &nargstack, int ivar)
{
- double value,xvalue,sx,sy,sxx,sxy;
+ bigint sx,sxx;
+ double value,xvalue,sy,sxy;
// word not a match to any special function
@@ -4020,11 +4055,13 @@ int Variable::special_function(char *word, char *contents, Tree **tree,
} else index = 0;
int ifix = modify->find_fix(&args[0][2]);
- if (ifix < 0) print_var_error(FLERR,"Invalid fix ID in variable formula",ivar);
+ if (ifix < 0)
+ print_var_error(FLERR,"Invalid fix ID in variable formula",ivar);
fix = modify->fix[ifix];
if (index == 0 && fix->vector_flag) {
if (update->whichflag > 0 && update->ntimestep % fix->global_freq)
- print_var_error(FLERR,"Fix in variable not computed at compatible time",ivar);
+ print_var_error(FLERR,"Fix in variable not computed at "
+ "compatible time",ivar);
nvec = fix->size_vector;
nstride = 1;
} else if (index && fix->array_flag) {
@@ -4032,7 +4069,8 @@ int Variable::special_function(char *word, char *contents, Tree **tree,
print_var_error(FLERR,"Variable formula fix array "
"is accessed out-of-range",ivar);
if (update->whichflag > 0 && update->ntimestep % fix->global_freq)
- print_var_error(FLERR,"Fix in variable not computed at compatible time",ivar);
+ print_var_error(FLERR,"Fix in variable not computed at "
+ "compatible time",ivar);
nvec = fix->size_array_rows;
nstride = fix->size_array_cols;
} else print_var_error(FLERR,"Mismatched fix in variable formula",ivar);
@@ -4048,10 +4086,12 @@ int Variable::special_function(char *word, char *contents, Tree **tree,
} else index = 0;
if (index)
- print_var_error(FLERR,"Invalid special function in variable formula",ivar);
+ print_var_error(FLERR,"Invalid special function in "
+ "variable formula",ivar);
ivar = find(&args[0][2]);
if (ivar < 0)
- print_var_error(FLERR,"Invalid special function in variable formula",ivar);
+ print_var_error(FLERR,"Invalid special function in "
+ "variable formula",ivar);
if (style[ivar] != VECTOR)
print_var_error(FLERR,"Mis-matched special function variable "
"in variable formula",ivar);
@@ -4062,12 +4102,16 @@ int Variable::special_function(char *word, char *contents, Tree **tree,
nvec = compute_vector(ivar,&vec);
nstride = 1;
- } else print_var_error(FLERR,"Invalid special function in variable formula",ivar);
+ } else print_var_error(FLERR,"Invalid special function in "
+ "variable formula",ivar);
value = 0.0;
- if (method == SLOPE) sx = sy = sxx = sxy = 0.0;
- if (method == XMIN) value = BIG;
- if (method == XMAX) value = -BIG;
+ if (method == SLOPE) {
+ sx = sxx = 0;
+ sy = sxy = 0.0;
+ }
+ else if (method == XMIN) value = BIG;
+ else if (method == XMAX) value = -BIG;
if (compute) {
double *vec;
@@ -4084,12 +4128,10 @@ int Variable::special_function(char *word, char *contents, Tree **tree,
else if (method == AVE) value += vec[j];
else if (method == TRAP) value += vec[j];
else if (method == SLOPE) {
- if (nvec > 1) xvalue = (double) i / (nvec-1);
- else xvalue = 0.0;
- sx += xvalue;
+ sx += i;
sy += vec[j];
- sxx += xvalue*xvalue;
- sxy += xvalue*vec[j];
+ sxx += i*i;
+ sxy += i*vec[j];
}
j += nstride;
}
@@ -4107,12 +4149,10 @@ int Variable::special_function(char *word, char *contents, Tree **tree,
else if (method == AVE) value += one;
else if (method == TRAP) value += one;
else if (method == SLOPE) {
- if (nvec > 1) xvalue = (double) i / (nvec-1);
- else xvalue = 0.0;
- sx += xvalue;
+ sx += i;
sy += one;
- sxx += xvalue*xvalue;
- sxy += xvalue*one;
+ sxx += i*i;
+ sxy += i*one;
}
}
if (method == TRAP) {
@@ -4134,12 +4174,10 @@ int Variable::special_function(char *word, char *contents, Tree **tree,
else if (method == AVE) value += one;
else if (method == TRAP) value += one;
else if (method == SLOPE) {
- if (nvec > 1) xvalue = (double) i / (nvec-1);
- else xvalue = 0.0;
- sx += xvalue;
+ sx += i;
sy += one;
- sxx += xvalue*xvalue;
- sxy += xvalue*one;
+ sxx += i*i;
+ sxy += i*one;
}
}
if (method == TRAP) value -= 0.5*vec[0] + 0.5*vec[nvec-1];
@@ -4148,9 +4186,9 @@ int Variable::special_function(char *word, char *contents, Tree **tree,
if (method == AVE) value /= nvec;
if (method == SLOPE) {
- double numerator = sxy - sx*sy;
- double denominator = sxx - sx*sx;
- if (denominator != 0.0) value = numerator/denominator / nvec;
+ double numerator = nvec*sxy - sx*sy;
+ double denominator = nvec*sxx - sx*sx;
+ if (denominator != 0.0) value = numerator/denominator;
else value = BIG;
}
@@ -4169,7 +4207,8 @@ int Variable::special_function(char *word, char *contents, Tree **tree,
} else if (strcmp(word,"gmask") == 0) {
if (tree == NULL)
- print_var_error(FLERR,"Gmask function in equal-style variable formula",ivar);
+ print_var_error(FLERR,"Gmask function in equal-style "
+ "variable formula",ivar);
if (narg != 1)
print_var_error(FLERR,"Invalid special function in variable formula",ivar);
@@ -4186,7 +4225,8 @@ int Variable::special_function(char *word, char *contents, Tree **tree,
} else if (strcmp(word,"rmask") == 0) {
if (tree == NULL)
- print_var_error(FLERR,"Rmask function in equal-style variable formula",ivar);
+ print_var_error(FLERR,"Rmask function in equal-style "
+ "variable formula",ivar);
if (narg != 1)
print_var_error(FLERR,"Invalid special function in variable formula",ivar);
@@ -4202,7 +4242,8 @@ int Variable::special_function(char *word, char *contents, Tree **tree,
} else if (strcmp(word,"grmask") == 0) {
if (tree == NULL)
- print_var_error(FLERR,"Grmask function in equal-style variable formula",ivar);
+ print_var_error(FLERR,"Grmask function in equal-style "
+ "variable formula",ivar);
if (narg != 2)
print_var_error(FLERR,"Invalid special function in variable formula",ivar);
@@ -4228,7 +4269,8 @@ int Variable::special_function(char *word, char *contents, Tree **tree,
int ivar = find(args[0]);
if (ivar < 0)
- print_var_error(FLERR,"Variable ID in variable formula does not exist",ivar);
+ print_var_error(FLERR,"Variable ID in "
+ "variable formula does not exist",ivar);
// SCALARFILE has single current value, read next one
// save value in tree or on argstack
@@ -4253,7 +4295,8 @@ int Variable::special_function(char *word, char *contents, Tree **tree,
} else if (style[ivar] == ATOMFILE) {
if (tree == NULL)
- print_var_error(FLERR,"Atomfile variable in equal-style variable formula",ivar);
+ print_var_error(FLERR,"Atomfile variable in "
+ "equal-style variable formula",ivar);
double *result;
memory->create(result,atom->nlocal,"variable:result");
@@ -4271,11 +4314,13 @@ int Variable::special_function(char *word, char *contents, Tree **tree,
newtree->nextra = 0;
treestack[ntreestack++] = newtree;
- } else print_var_error(FLERR,"Invalid variable style in special function next",ivar);
+ } else print_var_error(FLERR,"Invalid variable style in "
+ "special function next",ivar);
} else if (strcmp(word,"is_active") == 0) {
if (narg != 2)
- print_var_error(FLERR,"Invalid is_active() function in variable formula",ivar);
+ print_var_error(FLERR,"Invalid is_active() function in "
+ "variable formula",ivar);
Info info(lmp);
value = (info.is_active(args[0],args[1])) ? 1.0 : 0.0;
@@ -4293,7 +4338,8 @@ int Variable::special_function(char *word, char *contents, Tree **tree,
} else if (strcmp(word,"is_available") == 0) {
if (narg != 2)
- print_var_error(FLERR,"Invalid is_available() function in variable formula",ivar);
+ print_var_error(FLERR,"Invalid is_available() function in "
+ "variable formula",ivar);
Info info(lmp);
value = (info.is_available(args[0],args[1])) ? 1.0 : 0.0;
@@ -4311,7 +4357,8 @@ int Variable::special_function(char *word, char *contents, Tree **tree,
} else if (strcmp(word,"is_defined") == 0) {
if (narg != 2)
- print_var_error(FLERR,"Invalid is_defined() function in variable formula",ivar);
+ print_var_error(FLERR,"Invalid is_defined() function in "
+ "variable formula",ivar);
Info info(lmp);
value = (info.is_defined(args[0],args[1])) ? 1.0 : 0.0;
diff --git a/src/version.h b/src/version.h
index 2833430defffdb2affbaa0c746767ac20baea792..db73df1ad124b44dd86c4e3f314a9bdcb162255a 100644
--- a/src/version.h
+++ b/src/version.h
@@ -1 +1 @@
-#define LAMMPS_VERSION "29 Jun 2018"
+#define LAMMPS_VERSION "16 Aug 2018"
diff --git a/src/write_restart.cpp b/src/write_restart.cpp
index 69b731870d0c28fe6f389da0183f1905664a0400..1bfbb382a8c6b835bb315652a91c93c90fd7123d 100644
--- a/src/write_restart.cpp
+++ b/src/write_restart.cpp
@@ -61,7 +61,9 @@ enum{VERSION,SMALLINT,TAGINT,BIGINT,
MULTIPROC,MPIIO,PROCSPERFILE,PERPROC,
IMAGEINT,BOUNDMIN,TIMESTEP,
ATOM_ID,ATOM_MAP_STYLE,ATOM_MAP_USER,ATOM_SORTFREQ,ATOM_SORTBIN,
- COMM_MODE,COMM_CUTOFF,COMM_VEL,NO_PAIR};
+ COMM_MODE,COMM_CUTOFF,COMM_VEL,NO_PAIR,
+ EXTRA_BOND_PER_ATOM,EXTRA_ANGLE_PER_ATOM,EXTRA_DIHEDRAL_PER_ATOM,
+ EXTRA_IMPROPER_PER_ATOM,EXTRA_SPECIAL_PER_ATOM};
/* ---------------------------------------------------------------------- */
@@ -527,6 +529,12 @@ void WriteRestart::header()
write_double(COMM_CUTOFF,comm->cutghostuser);
write_int(COMM_VEL,comm->ghost_velocity);
+ write_int(EXTRA_BOND_PER_ATOM,atom->extra_bond_per_atom);
+ write_int(EXTRA_ANGLE_PER_ATOM,atom->extra_angle_per_atom);
+ write_int(EXTRA_DIHEDRAL_PER_ATOM,atom->extra_dihedral_per_atom);
+ write_int(EXTRA_IMPROPER_PER_ATOM,atom->extra_improper_per_atom);
+ write_int(EXTRA_SPECIAL_PER_ATOM,force->special_extra);
+
// -1 flag signals end of header
int flag = -1;
diff --git a/tools/emacs/README.md b/tools/emacs/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..75504a7000a0dcb9b5876985fe9ae4fafb63a912
--- /dev/null
+++ b/tools/emacs/README.md
@@ -0,0 +1,82 @@
+# GNU Emacs Syntax Highlighting
+
+> Copyright (C) 2010-2018 Aidan Thompson <athomps at sandia.gov>
+> Copyright (C) 2018 Rohit Goswami <r95g10 at gmail.com>
+
+The `lammps-mode.el` file provided in this directory will enable syntax
+highlighting for the lammps script syntax in GNU Emacs. The groupings of
+commands were originally copied from `tools/vim`.
+
+## Installation
+**Requirements: GNU Emacs 24.\***
+
+### Obtaining the Package
+
+#### MELPA
+
+The easiest installation method is via MELPA and it is advisable to use one of
+the many [MELPA installation methods](https://melpa.org/#/getting-started).
+
+For example, with [use-package](https://github.com/jwiegley/use-package) one can
+simply use the following:
+
+``` emacs-lisp
+(use-package lammps-mode)
+```
+
+#### Manually
+
+Assuming for some reason you have downloaded the file to `~/.emacs.d/lisp` you
+would do the following (kanged [from here](http://ergoemacs.org/emacs/emacs_installing_packages.html)):
+
+``` emacs-lisp
+;; Tell emacs where is your personal elisp lib dir
+(add-to-list 'load-path "~/.emacs.d/lisp/")
+
+;; load the package.
+(load "lammps-mode")
+```
+
+### Autoloading \& Auto-recognition
+
+To automatically turn on the LAMMPS mode for editing your input scripts,
+use the following line as the **first** line of your script:
+```
+# -*- lammps -*-
+```
+
+For automatically switching on the LAMMPS mode based on filename patterns,
+e.g. for `in.*` and `*.lmp` files, add the following code to your `.emacs`:
+
+``` emacs-lisp
+(autoload 'lammps-mode "lammps-mode.el" "LAMMPS mode." t)
+(setq auto-mode-alist (append auto-mode-alist
+ '(("in\\." . lammps-mode))
+ '(("\\.lmp\\'" . lammps-mode))
+ ))
+```
+
+## Status
+
+By far not all commands are included in the syntax file (lammps-mode.el). You
+can easily add new ones to the existing classes.
+
+## Implementation Details
+
+`lammps-mode` is derived from `shell-script-mode` which provides some basic
+syntax highlighting of strings, comments, etc.
+
+The MELPA recipe used for this package is simply:
+
+``` emacs-lisp
+(lammps-mode :fetcher github :repo "HaoZeke/lammps-mode")
+```
+
+## Caveats
+
+* Does not work with Xemacs [See [this comment](https://github.com/lammps/lammps/pull/1022#issuecomment-408871233)]
+
+## License
+
+[GNU GPL v2](https://github.com/HaoZeke/lammps-mode/blob/master/LICENSE).
+Check the file for more details.
diff --git a/tools/emacs/README.txt b/tools/emacs/README.txt
deleted file mode 100644
index 8dfc37cb851d3100ec052a7550d9b839f856c146..0000000000000000000000000000000000000000
--- a/tools/emacs/README.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-=== Emacs Syntax Highlighting ===
-Created by Aidan Thompson 12/2010
-===============================
-
-The lammps.el file provided in this directory will enable syntax
-highlighting for the lammps script syntax in emacs. The groupings
-of commands were copied from tools/vim. The simulation scripts have to
-end on *.lmp or start with in.* (see lammps.el). By far not all
-commands are included in the syntax file (lammps.el).
-You can easily add new ones to the existing classes.
-'lammps-mode' is derived from 'shell-script-mode' which provides
-some basic syntax highlighting of strings, comments, etc.
-
-=To enable the highlighting:
-============================
-(0) Create/edit the emacs init file ~/.emacs to contain:
-
-(load "~/.emacs.d/lammps")
-
-This file may also be called ~/.emacs.el, or ~/.emacs.d/init.el
-
-(1) Copy lammps.el to the directory ~/.emacs.d
-
diff --git a/tools/emacs/lammps.el b/tools/emacs/lammps-mode.el
similarity index 73%
rename from tools/emacs/lammps.el
rename to tools/emacs/lammps-mode.el
index d1ebebbbbfe9e9e75ca9c8403f0e9e54719ed515..37e8a32116755ff967380b772c442ef436b88341 100644
--- a/tools/emacs/lammps.el
+++ b/tools/emacs/lammps-mode.el
@@ -1,7 +1,48 @@
-;; LAMMPS auto-mode
+;;; lammps-mode.el --- basic syntax highlighting for LAMMPS files
+
+;; Copyright (C) 2010-18 Aidan Thompson
+;; Copyright (C) 2018 Rohit Goswami
+
+;; Author: Aidan Thompson <athomps at sandia.gov>
+;; Maintainer: Rohit Goswami <r95g10 at gmail.com>
+;; Created: December 4, 2010
+;; Modified: July 30, 2018
+;; Version: 1.5.0
+;; Keywords: languages, faces
+;; Homepage: https://github.com/lammps/lammps/tree/master/tools/emacs
+;; Package-Requires: ((emacs "24.4"))
+
+;; This file is not part of GNU Emacs.
+
+;; This program is free software; you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation; either version 2 of the License, or
+;; (at your option) any later version.
+
+;; This program is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License along
+;; with this program; if not, write to the Free Software Foundation, Inc.,
+;; 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+
+;;; Commentary:
;; translation of keyword classes from tools/vim
;; see http://xahlee.org/emacs/elisp_syntax_coloring.html
+;; Put this in your .emacs file to enable autoloading of lammps-mode
+;; and auto-recognition of "in.*" and "*.lmp" files:
+;;
+;; (autoload 'lammps-mode "lammps-mode.el" "LAMMPS mode." t)
+;; (setq auto-mode-alist (append auto-mode-alist
+;; '(("in\\." . lammps-mode))
+;; '(("\\.lmp\\'" . lammps-mode))
+;; ))
+;;
+
+;;; Code:
;; define several keyword classes
(defvar lammps-output
'("log"
@@ -136,6 +177,8 @@
(defvar lammps-variable-regexp
"\\$\\({[a-zA-Z0-9_]+}\\)\\|\\$[A-Za-z]")
+(defvar lammps-font-lock-keywords)
+
;; clear memory
(setq lammps-output nil)
(setq lammps-read nil)
@@ -151,8 +194,7 @@
;; create the list for font-lock.
;; each class of keyword is given a particular face
-(setq
- lammps-font-lock-keywords
+(setq lammps-font-lock-keywords
`((,lammps-output-regexp . font-lock-function-name-face)
(,lammps-read-regexp . font-lock-preprocessor-face)
(,lammps-lattice-regexp . font-lock-type-face)
@@ -199,12 +241,5 @@
(setq lammps-comment-regexp nil)
(setq lammps-variable-regexp nil))
-;; apply it to specified filename patterns
-(setq
- auto-mode-alist
- (append
- auto-mode-alist
- '(("in\\." . lammps-mode))
- '(("\\.lmp\\'" . lammps-mode))
- ))
-
+(provide 'lammps-mode)
+;;; lammps-mode.el ends here