jianmu
/
lammps
forked from lijiext/lammps
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Merge branch 'master' into scafacos

This commit is contained in:
Steven J. Plimpton 2018-08-22 09:25:29 -06:00
parent f466c64071 b47e492233
commit 9a15d0bd83
508 changed files with 7161 additions and 4807 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
README
View File

@ -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

198
cmake/CMakeLists.txt
View File

@ -17,6 +17,32 @@ file(GLOB LIB_SOURCES ${LAMMPS_SOURCE_DIR}/*.cpp)
file(GLOB LMP_SOURCES ${LAMMPS_SOURCE_DIR}/main.cpp)
list(REMOVE_ITEM LIB_SOURCES ${LMP_SOURCES})
# Utility functions
function(list_to_bulletpoints result)
list(REMOVE_AT ARGV 0)
set(temp "")
foreach(item ${ARGV})
set(temp "${temp}* ${item}\n")
endforeach()
set(${result} "${temp}" PARENT_SCOPE)
endfunction(list_to_bulletpoints)
function(validate_option name values)
string(TOLOWER ${${name}} needle_lower)
string(TOUPPER ${${name}} needle_upper)
list(FIND ${values} ${needle_lower} IDX_LOWER)
list(FIND ${values} ${needle_upper} IDX_UPPER)
if(${IDX_LOWER} LESS 0 AND ${IDX_UPPER} LESS 0)
list_to_bulletpoints(POSSIBLE_VALUE_LIST ${${values}})
message(FATAL_ERROR "\n########################################################################\n"
"Invalid value '${${name}}' for option ${name}\n"
"\n"
"Possible values are:\n"
"${POSSIBLE_VALUE_LIST}"
"########################################################################")
endif()
endfunction(validate_option)
# Cmake modules/macros are in a subdirectory to keep this file cleaner
set(CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR}/Modules)
@ -106,8 +132,6 @@ if(NOT BUILD_EXE AND NOT BUILD_LIB)
message(FATAL_ERROR "You need to at least enable one of two following options: BUILD_LIB or BUILD_EXE")
endif()
option(DEVELOPER_MODE "Enable developer mode" OFF)
mark_as_advanced(DEVELOPER_MODE)
option(CMAKE_VERBOSE_MAKEFILE "Generate verbose Makefiles" OFF)
include(GNUInstallDirs)
@ -161,15 +185,21 @@ else()
list(APPEND LAMMPS_LINK_LIBS mpi_stubs)
endif()
set(LAMMPS_SIZE_LIMIT "LAMMPS_SMALLBIG" CACHE STRING "Lammps size limit")
set_property(CACHE LAMMPS_SIZE_LIMIT PROPERTY STRINGS LAMMPS_SMALLBIG LAMMPS_BIGBIG LAMMPS_SMALLSMALL)
add_definitions(-D${LAMMPS_SIZE_LIMIT})
set(LAMMPS_API_DEFINES "${LAMMPS_API_DEFINES} -D${LAMMPS_SIZE_LIMIT}")
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")
add_definitions(-DLAMMPS_MEMALIGN=${LAMMPS_MEMALIGN})
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)
@ -218,10 +248,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)
@ -230,11 +263,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()
@ -312,10 +350,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)
@ -334,6 +379,9 @@ 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
@ -420,8 +468,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
@ -434,7 +482,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})
@ -487,6 +535,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")
@ -545,12 +596,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})
######################################
@ -738,6 +790,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
@ -775,33 +832,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
@ -834,11 +913,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_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 "SINGLE_DOUBLE" CACHE STRING "LAMMPS GPU precision size")
set_property(CACHE GPU_PREC PROPERTY STRINGS SINGLE_DOUBLE SINGLE_SINGLE DOUBLE_DOUBLE)
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)
@ -851,7 +944,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)
@ -865,10 +958,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)
@ -885,7 +978,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)
@ -899,10 +992,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)
@ -924,7 +1020,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)
@ -1177,7 +1273,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}")

4
cmake/Modules/FindQUIP.cmake
View File

@ -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)

46
cmake/Modules/FindTBB.cmake Normal file
View File

@ -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 )

142
cmake/README.md
View File

@ -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,26 @@ 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_EXE</code></td>
<td>control whether to build LAMMPS executable</td>
<td>
<dl>
<dt><code>on</code> (default)</dt>
<dt><code>off</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>BUILD_SHARED_LIBS</code></td>
<td>control whether to build LAMMPS as a shared-library</td>
@ -315,8 +335,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>
@ -325,8 +345,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>
@ -1271,7 +1291,7 @@ providing the identical features and USER interface.</strong></p>
</td>
<td>
<dl>
<dt><code>KISSFFT</code></dt>
<dt><code>KISS</code></dt>
<dt><code>FFTW3</code></dt>
<dt><code>FFTW2</code></dt>
<dt><code>MKL</code></dt>
@ -1279,13 +1299,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>
@ -1377,6 +1397,29 @@ TODO
### PYTHON Package
### USER-INTEL Package
<table>
<thead>
<tr>
<th>Option</th>
<th>Description</th>
<th>Values</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>INTEL_ARCH</code></td>
<td>Target architecture for USER-INTEL package</td>
<td>
<dl>
<dt><code>cpu</code> (default)</dt>
<dt><code>knl</code></dt>
</dl>
</td>
</tr>
</tbody>
</table>
### GPU Package
The GPU package builds a support library which can either use OpenCL or CUDA as
@ -1396,8 +1439,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>
@ -1406,9 +1449,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>
@ -1417,12 +1460,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>
@ -1517,6 +1560,16 @@ Requires a Eigen3 installation
</tr>
</thead>
<tbody>
<tr>
<td><code>WITH_JPEG</code></td>
<td>Enables/Disable JPEG support in LAMMPS</td>
<td>
<dl>
<dt><code>yes</code> (default, if found)</dt>
<dt><code>no</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>JPEG_INCLUDE_DIR</code></td>
<td></td>
@ -1544,6 +1597,16 @@ Requires a Eigen3 installation
</tr>
</thead>
<tbody>
<tr>
<td><code>WITH_PNG</code></td>
<td>Enables/Disable PNG support in LAMMPS</td>
<td>
<dl>
<dt><code>yes</code> (default, if found)</dt>
<dt><code>no</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>PNG_INCLUDE_DIR</code></td>
<td></td>
@ -1572,6 +1635,16 @@ requires `gzip` to be in your `PATH`
</tr>
</thead>
<tbody>
<tr>
<td><code>WITH_GZIP</code></td>
<td>Enables/Disable GZIP support in LAMMPS</td>
<td>
<dl>
<dt><code>yes</code> (default, if found)</dt>
<dt><code>no</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>GZIP_EXECUTABLE</code></td>
<td></td>
@ -1594,6 +1667,16 @@ requires `ffmpeg` to be in your `PATH`
</tr>
</thead>
<tbody>
<tr>
<td><code>WITH_FFMPEG</code></td>
<td>Enables/Disable FFMPEG support in LAMMPS</td>
<td>
<dl>
<dt><code>yes</code> (default, if found)</dt>
<dt><code>no</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>FFMPEG_EXECUTABLE</code></td>
<td></td>
@ -1606,8 +1689,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>
@ -1643,20 +1731,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
```

49
doc/src/Build.txt Normal file
View File

@ -0,0 +1,49 @@
"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
Build_windows
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
"Notes for building LAMMPS on Windows"_Build_windows.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.

315
doc/src/Build_basics.txt Normal file
View File

@ -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.

196
doc/src/Build_cmake.txt Normal file
View File

@ -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/.

952
doc/src/Build_extras.txt Normal file
View File

@ -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.

85
doc/src/Build_link.txt Normal file
View File

@ -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.

85
doc/src/Build_make.txt Normal file
View File

@ -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

223
doc/src/Build_package.txt Normal file
View File

@ -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.

341
doc/src/Build_settings.txt Normal file
View File

@ -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

97
doc/src/Build_windows.txt Normal file
View File

@ -0,0 +1,97 @@
"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
Notes for building LAMMPS on Windows :h3
"General remarks"_#generic
"Running Linux on Windows"_#linux
"Using GNU GCC ported to Windows"_#gnu
"Using a cross-compiler"_#cross :ul
:line
General remarks :h4,link(generic)
LAMMPS is developed and tested primarily on Linux machines. The vast
majority of HPC clusters and supercomputers today runs on Linux as well.
Thus portability to other platforms is desired, but not always achieved.
The LAMMPS developers strongly rely on LAMMPS users giving feedback and
providing assistance in resolving portability issues. This particularly
true for compiling LAMMPS on Windows, since this platform has significant
differences with some low-level functionality.
Running Linux on Windows :h4,link(linux)
So before trying to build LAMMPS on Windows, please consider if using
the pre-compiled Windows binary packages are sufficient for your needs
(as an aside, those packages themselves are build on a Linux machine
using cross-compilers). If it is necessary for your to compile LAMMPS
on a Windows machine (e.g. because it is your main desktop), please also
consider using a virtual machine software and run a Linux virtual machine,
or - if have a recently updated Windows 10 installation - consider using
the Windows subsystem for Linux, which allows to run a bash shell from
Ubuntu and from there on, you can pretty much use that shell like you
are running on an Ubuntu Linux machine (e.g. installing software via
apt-get). For more details on that, please see "this tutorial"_Howto_bash.html
Using GNU GCC ported to Windows :h4,link(gnu)
One option for compiling LAMMPS on Windows natively, that has been known
to work in the past is to install a bash shell, unix shell utilities,
perl, GNU make, and a GNU compiler ported to Windows. The Cygwin package
provides a unix/linux interface to low-level Windows functions, so LAMMPS
can be compiled on Windows. The necessary (minor) modifications to LAMMPS
are included, but may not always up-to-date for recently added functionality
and the corresponding new code. A machine makefile for using cygwin for
the old build system is provided. The CMake build system is untested
for this; you will have to request that makefiles are generated and
manually set the compiler.
When compiling for Windows [not] set the -DLAMMPS_MEMALIGN define
in the LMP_INC makefile variable and add -lwsock32 -lpsapi to the linker
flags in LIB makefile variable. Try adding -static-libgcc or -static or
both to the linker flags when your resulting LAMMPS Windows executable
complains about missing .dll files. The CMake configuration should set
this up automatically, but is untested.
In case of problems, you are recommended to contact somebody with
experience in using cygwin. If you do come across portability problems
requiring changes to the LAMMPS source code, or figure out corrections
yourself, please report them on the lammps-users mailing list, or file
them as an issue or pull request on the LAMMPS github project.
Using a cross-compiler :h4,link(cross)
If you need to provide custom LAMMPS binaries for Windows, but do not
need to do the compilation on Windows, please consider using a Linux
to Windows cross-compiler. This is how currently the Windows binary
packages are created by the LAMMPS developers. Because of that, this is
probably the currently best tested and supported way to build LAMMPS
executables for Windows. There are makefiles provided for the
traditional build system, but CMake has also been successfully tested
using the mingw32-cmake and mingw64-cmake wrappers that are bundled
with the cross-compiler environment on Fedora machines.
Please keep in mind, though, that this only applies to compiling LAMMPS.
Whether the resulting binaries do work correctly is no tested by the
LAMMPS developers. We instead rely on the feedback of the users
of these precompiled LAMMPS packages for Windows. We will try to resolve
issues to the best of our abilities if we become aware of them. However
this is subject to time constraints and focus on HPC platforms.
Native Visual C++ support :h4,link(native)
Support for the Visual C++ compilers is currently not available. The
CMake build system is capable of creating suitable a Visual Studio
style build environment, but the LAMMPS code itself is not fully ported
to support Visual C++. Volunteers to take on this task are welcome.

4
doc/src/Commands.txt
View File

@ -1,4 +1,4 @@
"Previous Section"_Run.html - "LAMMPS WWW Site"_lws -
"Previous Section"_Run_head.html - "LAMMPS WWW Site"_lws -
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
Section"_Packages.html :c
@ -16,6 +16,7 @@ commands in it are used to define a LAMMPS simulation.
<!-- RST
.. toctree::
:maxdepth: 1
Commands_input
Commands_parse
@ -23,6 +24,7 @@ commands in it are used to define a LAMMPS simulation.
Commands_category
.. toctree::
:maxdepth: 1
Commands_all
Commands_fix

2
doc/src/Commands_bond.txt
View File

@ -9,7 +9,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
"Fix styles"_Commands_fix.html,
"Compute styles"_Commands_compute.html,
"Pair styles"_Commands_pair.html,
"Bond styles"_Commands_bond.html,
"Bond styles"_Commands_bond.html#bond,
"Angle styles"_Commands_bond.html#angle,
"Dihedral styles"_Commands_bond.html#dihedral,
"Improper styles"_Commands_bond.html#improper,

3
doc/src/Errors.txt
View File

@ -1,4 +1,4 @@
"Previous Section"_Python.html - "LAMMPS WWW Site"_lws -
"Previous Section"_Python_head.html - "LAMMPS WWW Site"_lws -
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
Section"_Manual.html :c
@ -19,6 +19,7 @@ additional details for many of them.
<!-- RST
.. toctree::
:maxdepth: 1
Errors_common
Errors_bugs

8
doc/src/Errors_common.txt
View File

@ -58,9 +58,9 @@ style", with ... being fix, compute, pair, etc, it means that you
mistyped the style name or that the command is part of an optional
package which was not compiled into your executable. The list of
available styles in your executable can be listed by using "the -h
command-line argument"_Section_start.html#start_6. The installation
and compilation of optional packages is explained in the "installation
instructions"_Section_start.html#start_3.
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
@ -93,7 +93,7 @@ decide if the WARNING is important or not. A WARNING message that is
generated in the middle of a run is only printed to the screen, not to
the logfile, to avoid cluttering up thermodynamic output. If LAMMPS
crashes or hangs without spitting out an error message first then it
could be a bug (see "this section"_#err_2) or one of the following
could be a bug (see "this section"_Errors_bugs.html) or one of the following
cases:
LAMMPS runs in the available memory a processor allows to be

4
doc/src/Errors_messages.txt
View File

@ -7911,8 +7911,8 @@ Atom IDs must be positive integers. :dd
{One or more atom IDs is too big} :dt
The limit on atom IDs is set by the SMALLBIG, BIGBIG, SMALLSMALL
setting in your Makefile. See Section_start 2.2 of the manual for
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

8
doc/src/Examples.txt
View File

@ -112,10 +112,10 @@ web site.
If you uncomment the "dump image"_dump_image.html line(s) in the input
script a series of JPG images will be produced by the run (assuming
you built LAMMPS with JPG support; see "Section
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.

167
doc/src/Howto.txt
View File

@ -8,26 +8,45 @@ Section"_Examples.html :c
:line
How to discussions :h2
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
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
@ -36,40 +55,114 @@ also show how to setup and run various kinds of simulations.
Howto_library
Howto_couple
.. toctree::
END_RST -->
Howto_output
Howto_chunk
<!-- 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_walls
Howto_nemd
Howto_granular
Howto_spherical
Howto_dispersion
.. toctree::
Howto_temperature
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
.. toctree::
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
@ -80,49 +173,17 @@ also show how to setup and run various kinds of simulations.
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
"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)
"Output from LAMMPS (thermo, dumps, computes, fixes, variables)"_Howto_output.html
"Use chunks to calculate system properties"_Howto_chunk.html :all(b)
"2d simulations"_Howto_2d.html
"Triclinic (non-orthogonal) simulation boxes"_Howto_triclinic.html
"Walls"_Howto_walls.html
"NEMD simulations"_Howto_nemd.html
"Granular models"_Howto_granular.html
"Finite-size spherical and aspherical particles"_Howto_spherical.html
"Long-range dispersion settings"_Howto_dispersion.html :all(b)
"Calculate temperature"_Howto_temperature.html
"Thermostats"_Howto_thermostat.html
"Barostats"_Howto_barostat.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)
"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)
"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 :all(b)
"Drude induced dipoles (extended)"_Howto_drude2.html
"Manifolds (surfaces)"_Howto_manifold.html
"Magnetic spins"_Howto_spins.html
"Magnetic spins"_Howto_spins.html :all(b)
<!-- END_HTML_ONLY -->

4
doc/src/Howto_bioFF.txt
View File

@ -96,6 +96,10 @@ documentation for the formula it computes.
[(MacKerell)] MacKerell, Bashford, Bellott, Dunbrack, Evanseck, Field,
Fischer, Gao, Guo, Ha, et al, J Phys Chem, 102, 3586 (1998).
:link(howto-Cornell)
[(Cornell)] Cornell, Cieplak, Bayly, Gould, Merz, Ferguson,
Spellmeyer, Fox, Caldwell, Kollman, JACS 117, 5179-5197 (1995).
:link(howto-Mayo)
[(Mayo)] Mayo, Olfason, Goddard III, J Phys Chem, 94, 8897-8909
(1990).

8
doc/src/Howto_coreshell.txt
View File

@ -119,7 +119,7 @@ the core/shell pair, which is an imaginary degree of freedom, from the
real physical system. To do that, the "compute
temp/cs"_compute_temp_cs.html command can be used, in conjunction with
any of the thermostat fixes, such as "fix nvt"_fix_nh.html or "fix
langevin"_fix_langevin. This compute uses the center-of-mass velocity
langevin"_fix_langevin.html. This compute uses the center-of-mass velocity
of the core/shell pairs to calculate a temperature, and insures that
velocity is what is rescaled for thermostatting purposes. This
compute also works for a system with both core/shell pairs and
@ -150,9 +150,9 @@ The pressure for the core/shell system is computed via the regular
LAMMPS convention by "treating the cores and shells as individual
particles"_#MitchellFincham2. For the thermo output of the pressure
as well as for the application of a barostat, it is necessary to
use an additional "pressure"_compute_pressure compute based on the
default "temperature"_compute_temp and specifying it as a second
argument in "fix modify"_fix_modify.html and
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:
(...)

21
doc/src/Howto_couple.txt
View File

@ -77,17 +77,16 @@ strain induced across grain boundaries :l
:link(quest,http://dft.sandia.gov/Quest)
:link(spparks,http://www.sandia.gov/~sjplimp/spparks.html)
"This section"_Section_start.html#start_5 of the documentation
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.html doc pages for a description of the Python wrapper
provided with LAMMPS that operates through the LAMMPS library
interface.
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

2
doc/src/Howto_diffusion.txt
View File

@ -7,7 +7,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
:line
Calculate a diffusion coefficient :h3
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

2
doc/src/Howto_dispersion.txt
View File

@ -7,7 +7,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
:line
Long-raage dispersion settings :h3
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,

2
doc/src/Howto_granular.txt
View File

@ -53,5 +53,5 @@ computations between frozen atoms by using this command:
NOTE: By default, for 2d systems, granular particles are still modeled
as 3d spheres, not 2d discs (circles), meaning their moment of inertia
will be the same as in 3d. If you wish to model granular particles in
2d as 2d discs, see the note on this topic on the "Howto 2d"_Howto_2d
2d as 2d discs, see the note on this topic on the "Howto 2d"_Howto_2d.html
doc page, where 2d simulations are discussed.

23
doc/src/Howto_library.txt
View File

@ -9,10 +9,10 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
Library interface to LAMMPS :h3
As described in "Section 2.5"_Section_start.html#start_5, LAMMPS can
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.html.
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
@ -35,8 +35,8 @@ details.
NOTE: You can write code for additional functions as needed to define
how your code talks to LAMMPS and add them to src/library.cpp and
src/library.h, as well as to the "Python interface"_Python.html. The
added functions can access or change any internal LAMMPS data you
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 **)
@ -51,12 +51,11 @@ void lammps_free(void *) :pre
The lammps_open() function is used to initialize LAMMPS, passing in a
list of strings as if they were "command-line
arguments"_Section_start.html#start_6 when LAMMPS is run in
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.
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

3
doc/src/Howto_multiple.txt
View File

@ -80,8 +80,7 @@ jump in.polymer :pre
All of the above examples work whether you are running on 1 or
multiple processors, but assumed you are running LAMMPS on a single
partition of processors. LAMMPS can be run on multiple partitions via
the "-partition" command-line switch as described in "this
section"_Section_start.html#start_6 of the manual.
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

17
doc/src/Howto_replica.txt
View File

@ -29,29 +29,28 @@ runs different replicas at a series of temperature to facilitate
rare-event sampling.
These commands can only be used if LAMMPS was built with the REPLICA
package. See the "Making LAMMPS"_Section_start.html#start_3 section
for more info on packages.
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 "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.
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:
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"_Section_start.html#start_6 to specify
the input script which is required when running in multi-replica mode.
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

4
doc/src/Howto_restart.txt
View File

@ -16,8 +16,8 @@ restart files can be saved to disk using the "restart"_restart.html
command. At a later time, these binary files can be read via a
"read_restart"_read_restart.html command in a new script. Or they can
be converted to text data files using the "-r command-line
switch"_Section_start.html#start_6 and read by a
"read_data"_read_data.html command in a new script.
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

13
doc/src/Howto_temperature.txt
View File

@ -7,7 +7,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
:line
Calcalate temperature :h3
Calculate temperature :h3
Temperature is computed as kinetic energy divided by some number of
degrees of freedom (and the Boltzmann constant). Since kinetic energy
@ -17,7 +17,10 @@ aggregate motion of particles) and its thermal velocity. The sum of
the two is the particle's total velocity, but the latter is often what
is wanted to compute a temperature.
LAMMPS has several options for computing temperatures, any of which can be used in "thermostatting"_Howto_thermostat.html and "barostatting"_Howto_barostat.html. These "compute commands"_compute.html calculate temperature:
LAMMPS has several options for computing temperatures, any of which
can be used in "thermostatting"_Howto_thermostat.html and
"barostatting"_Howto_barostat.html. These "compute
commands"_compute.html calculate temperature:
"compute temp"_compute_temp.html
"compute temp/sphere"_compute_temp_sphere.html
@ -35,6 +38,6 @@ velocities) that are removed when computing the thermal temperature.
temp/asphere"_compute_temp_asphere.html compute kinetic energy for
finite-size particles that includes rotational degrees of freedom.
They both allow for velocity biases indirectly, via an optional extra
argument which is another temperature compute that subtracts a velocity bias.
This allows the translational velocity of spherical or aspherical
particles to be adjusted in prescribed ways.
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.

4
doc/src/Howto_tip4p.txt
View File

@ -31,7 +31,7 @@ using the "fix shake"_fix_shake.html command.
These are the additional parameters (in real units) to set for O and H
atoms and the water molecule to run a rigid TIP4P model with a cutoff
"(Jorgensen)"_#Jorgensen1. Note that the OM distance is specified in
"(Jorgensen)"_#Jorgensen5. Note that the OM distance is specified in
the "pair_style"_pair_style.html command, not as part of the pair
coefficients.
@ -107,6 +107,6 @@ models"_http://en.wikipedia.org/wiki/Water_model.
:line
:link(Jorgensen1)
:link(Jorgensen5)
[(Jorgensen)] Jorgensen, Chandrasekhar, Madura, Impey, Klein, J Chem
Phys, 79, 926 (1983).

65
doc/src/Install.txt Normal file
View File

@ -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.

120
doc/src/Install_git.txt Normal file
View File

@ -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).

119
doc/src/Install_linux.txt Normal file
View File

@ -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.

55
doc/src/Install_mac.txt Normal file
View File

@ -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.

67
doc/src/Install_patch.txt Normal file
View File

@ -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".

95
doc/src/Install_svn.txt Normal file
View File

@ -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).

64
doc/src/Install_tarball.txt Normal file
View File

@ -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.

52
doc/src/Install_windows.txt Normal file
View File

@ -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.

2
doc/src/Intro.txt
View File

@ -15,8 +15,10 @@ These pages provide a brief introduction to LAMMPS.
<!-- RST
.. toctree::
:maxdepth: 1
Intro_overview
Manual_version
Intro_features
Intro_nonfeatures
Intro_opensource

365
doc/src/Intro_authors.txt
View File

@ -7,7 +7,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
:line
LAMMPS authors :h3
Authors of LAMMPS :h3
The primary LAMMPS developers are at Sandia National Labs and Temple
University:
@ -15,7 +15,8 @@ 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 :ul
Axel Kohlmeyer, akohlmey at gmail.com
Richard Berger, richard.berger at temple.edu :ul
:link(sjp,http://www.cs.sandia.gov/~sjplimp)
@ -24,26 +25,31 @@ and Ray Shan, now at Materials Design.
:line
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.
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.
Axel Kohlmeyer (Temple U), akohlmey at gmail.com, SVN and Git repositories, indefatigable mail list responder, USER-CG-CMM, USER-OMP, USER-COLVARS, USER-MOLFILE, USER-QMMM packages
: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
Mike Brown (ORNL), brownw at ornl.gov, GPU and USER-INTEL packages
Greg Wagner (Sandia), gjwagne at sandia.gov, MEAM package for MEAM potential
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 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, USER-LIGGGHTS package for granular models and granular/fluid coupling
Metin Aktulga (LBL), hmaktulga at lbl.gov, USER-REAXC package for C version of ReaxFF
Georg Gunzenmueller (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
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
@ -58,322 +64,3 @@ Terry Stouch (Lexicon Pharmaceuticals, formerly at Bristol Myers Squibb)
Steve Lustig (Dupont)
Jim Belak and Roy Pollock (LLNL) :ul
:line
:line
Here is a timeline for when various individuals contributed to a new
feature or command or tool added to LAMMPS:
Jul18 : DEM polygonal and polyhedron particles : Trung Nguyen (Northwestern U)
Jun18 : SPIN package : Julien Tranchida (Sandia and CEA)
Jun18 : compute entropy/atom : Pablo Piaggi (EPLF, Switzerland)
May18 : fix bond/react : Jake Gissinger (CU Boulder)
Apr18 : USER-BOCS package : Nicholas Dunn and Michael DeLyser (Penn State U)
Mar18: pair coul/shield, kolmogorov/crespi/full, ilp/graphene/hbn : Wengen Ouyang (Tel Aviv U)
Feb18 : pair lj/cut/coul/wolf : Vishal Boddu (U of Erlangen-Nuremberg)
Feb18 : USER-MOFFF package : Hendrik Heenen (Technical U of Munich) and Rochus Schmid (Ruhr-University Bochum)
Feb18 : pair ufm : Rodolfo Paula Leite and Maurice de Koning (Unicamp/Brazil)
Dec17 : fix python/move : Richard Berger (Temple U)
Nov17 : pair extep : Jaap Kroes (Radboud U)
Oct17 : USER-UEF package : David Nicholson (MIT)
Oct17 : fix rhok : Ulf Pederson (Roskilde U)
Oct17 : bond gromos : Axel Kohlmeyer (Temple U)
Oct17 : pair born/coul/wolf/cs and coul/wolf/cs : Vishal Boddu
Sep17 : fix latte : Christian Negre (LANL)
Sep17 : temper_npt : Amulya Pervaje and Cody Addington (NCSU)
Aug17 : USER-MESO package : Zhen Li (Brown University)
Aug17 : compute aggregate/atom & fragment/atom : Axel Kohlmeyer (Temple U)
Jul17 : pair meam/c : Sebastian Hutter (Otto-von-Guericke University)
Jun17 : pair reaxc/omp : Metin Aktulga (MSU) and Axel Kohlmeyer (Temple U)
Jun17 : pair vashishita/gpu : Anders Hafreager (UiO)
Jun17 : kspace pppm/disp/intel and pair lj/long/coul/long/intel : Mike Brown (Intel) and William McDoniel (RWTH Aachen U)
Jun17 : compute cnp/atom : Paulo Branicio (USC)
May17 : fix python and pair python : Richard Berger (Temple U)
May17 : pair edip/multi : Chao Jiang (U Wisconsin)
May17 : pair gw and gw/zbl : German Samolyuk (ORNL)
Mar17 : pair charmm fsw and fsh : Robert Meissner & Lucio Colombi Ciacchi (Bremen U), Robert Latour (Clemson U)
Mar17 : pair momb : Ya Zhou, Kristen Fichthorn, and Tonnam Balankura (PSU)
Mar17 : fix filter/corotate : Lukas Fath (KIT)
Mar17 : pair kolmogorov/crespi/z : Jaap Kroes (Radboud Universiteit)
Feb17 : Kokkos versions of the class2 bond/angle/dihedral/improper : Ray Shan (Materials Design)
Jan17 : USER-CGDNA package : Oliver Henrich (U Edinburgh)
Jan17 : fix mscg : Lauren Abbott (Sandia)
Nov16 : temper/grem and fix grem : David Stelter (BU), Edyta Malolepsza (Broad Institute), Tom Keyes (BU)
Nov16 : pair agni : Axel Kohlmeyer (Temple U) and Venkatesh Botu
Nov16 : pair tersoff/mod.c : Ganga P Purja Pun (George Mason University)
Nov16 : pair born/coul/dsf and pair born/coul/dsf/cs : Ariel Lozano
Nov16 : fix reaxc/species/kk & fix reaxc/bonds/kk : Stan Moore (Sandia)
Oct16 : fix wall/gran/region : Dan Bolintineanu (Sandia)
Sep16 : weight options for balance & fix balance : Axel Kohlmeyer (Temple U) & Iain Bethune (EPCC)
Sep16 : fix cmap : Xiaohu Hu (ORNL), David Hyde-Volpe & Tigran Abramyan & Robert Latour (Clemson U), Chris Lorenz (Kings College, London)
Sep16 : pair vashishta/table : Anders Hafreager (U Oslo)
Sep16 : kspace pppm/kk : Stan Moore (Sandia)
Aug16 : fix flow/gauss : Steve Strong and Joel Eaves (U Colorado)
Aug16 : fix controller : Aidan Thompson (Sandia)
Jul16 : dipole integration by DLM method : Iain Bethune (EPCC)
Jul16 : dihedral spherical : Andrew Jewett
Jun16 : pair reax/c/kk : Ray Shan (Materials Design), Stan Moore (Sandia)
Jun16 : fix orient/bcc : Tegar Wicaksono (UBC)
Jun16 : fix ehex : Peter Wirnsberger (University of Cambridge)
Jun16 : reactive DPD extensions to USER-DPD : James Larentzos (ARL), Timothy Mattox (Engility Corp), John Brennan (ARL), Christopher Stone (Computational Science & Engineering, LLC)
May16 : USER-MANIFOLD package : Stefan Paquay (Eindhoven U of Tech, The Netherlands)
Apr16 : write_coeff : Axel Kohlmeyer (Temple U)
Apr16 : pair morse/soft : Stefan Paquay (Eindhoven U of Tech, The Netherlands)
Apr16 : compute dipole/chunk : Axel Kohlmeyer (Temple U)
Apr16 : bond write : Axel Kohlmeyer (Temple U)
Mar16 : pair morse/smooth/linear : Stefan Paquay (Eindhoven U of Tech, The Netherlands)
Feb16 : pair/bond/angle/dihedral/improper zero : Carsten Svaneborg (SDU)
Feb16 : dump custom/vtk : Richard Berger (JKU) and Daniel Queteschiner (DCS Computing)
Feb16 : fix (nvt/npt/nph)/body and compute temp/body : Trung Nguyen
Feb16 : USER-DPD package : James Larentzos (ARL), Timothy Mattox (Engility Corp), John Brennan (ARL)
Dec15 : fix qeq/fire : Ray Shan (Sandia)
Dec15 : pair lj/mdf, pair lennard/mdf, pair buck/mdf, improper distance : Paolo Raiteri (Curtin University)
Nov15 : compute orientorder/atom : Aidan Thompson (Sandia) and Axel Kohlmeyer (U Temple)
Nov15 : compute hexorder/atom : Aidan Thompson (Sandia)
Oct15 : displace_atoms variable option : Reese Jones (Sandia)
Oct15 : pair mgpt & USER-MGPT package : Tomas Oppelstrup and John Moriarty (LLNL)
Oct15 : pair smtbq & USER-SMTBQ package : Nicolas Salles, Emile Maras, Olivier Politano, and Robert Tetot (LAAS-CNRS)
Oct15 : fix ave/correlate/long command : Jorge Ramirez (UPM) and Alexei Likhtman (U Reading)
Oct15 : pair vashishta command : Aidan Thompson (Sandia) and Yongnan Xiong (HNU)
Aug15 : USER-TALLY package : Axel Kohlmeyer (Temple U)
Aug15 : timer command : Axel Kohlmeyer (Temple U)
Aug15 : USER-H5MD package : Pierre de Buyl (KU Leuven)
Aug15 : COMPRESS package : Axel Kohlmeyer (Temple U)
Aug15 : USER-SMD package : Georg Gunzenmueller (EMI)
Jul15 : new HTML format for "doc pages"_Manual.html with search option : Richard Berger (JKU)
Jul15 : rRESPA with pair hybrid : Sam Genheden (U of Southampton)
Jul15 : pair_modify special : Axel Kohlmeyer (Temple U)
Jul15 : pair polymorphic : Xiaowang Zhou and Reese Jones (Sandia)
Jul15 : USER-DRUDE package : Alain Dequidt and Agilio Padua (U Blaise Pascal Clermont-Ferrand) and Julien Devemy (CNRS)
Jul15 : USER-QTB package : Yuan Shen, Tingting Qi, and Evan Reed (Stanford U)
Jul15 : USER-DIFFRACTION package : Shawn Coleman (ARL)
Mar15 : fix temp/csld : Axel Kohlmeyer (Temple U)
Mar15 : CORESHELL package : Hendrik Heenen (Technical University of Munich)
Feb15 : pair quip for GAP and other potentials : Albert Bartok-Partay (U Cambridge)
Feb15 : pair coul/streitz for Streitz-Mintmire potential : Ray Shan (Sandia)
Feb15 : fix tfmc : Kristof Bal (U of Antwerp)
Feb15 : fix ttm/mod : Sergey Starikov and Vasily Pisarev (JIHT of RAS)
Jan15 : fix atom/swap for MC swaps of atom types/charge : Paul Crozier (Sandia)
Nov14 : fix pimd for path-integral MD : Chris Knight and Yuxing Peng (U Chicago)
Nov14 : fix gle and fix ipi for path-integral MD : Michele Ceriotti (EPFL)
Nov14 : pair style srp : Tim Sirk (ARL) and Pieter in 't Veld (BASF)
Nov14 : fix ave/spatial/sphere : Niall Jackson (Imperial College)
Sep14 : QEQ package and several fix qeq/variant styles : Ray Shan (Sandia)
Sep14 : SNAP package and pair style : Aidan Thompson (Sandia) and collaborators
Aug14 : USER-INTEL package : Mike Brown (Intel)
May14 : KOKKOS pacakge : Christian Trott and Carter Edwards (Sandia)
May14 : USER-FEP pacakge : Agilio Padua (U Blaise Pascal Clermont-Ferrand)
Apr14 : fix rigid/small NVE/NVT/NPH/NPT : Trung Nguyen (ORNL)
Apr14 : fix qmmm for QM/MM coupling : Axel Kohlmeyer (Temple U)
Mar14 : kspace_modify collective for faster FFTs on BG/Q : Paul Coffman (IBM)
Mar14 : fix temp/csvr and fix oneway : Axel Kohlmeyer (Temple U)
Feb14 : pair peri/eps, compute dilatation/atom, compute plasticity/atom : Rezwanur Rahman and John Foster (UTSA)
Jan14 : MPI-IO options for dump and restart files : Paul Coffman (IBM)
Nov13 : USER-LB package for Lattice Boltzmann : Francis Mackay and Colin Denniston (U Western Ontario)
Nov13 : fix ti/rs and ti/spring : Rodrigo Freitas (UC Berkeley)
Nov13 : pair comb3 : Ray Shan (Sandia), Tao Liang and Dundar Yilmaz (U Florida)
Nov13 : write_dump and dump movie : Axel Kohlmeyer (Temple U)
Sep13 : xmgrace tool : Vikas Varshney
Sep13 : pair zbl : Aidan Thompson and Stephen Foiles (Sandia)
Aug13 : pair nm and variants : Julien Devemy (ICCF)
Aug13 : fix wall/lj1043 : Jonathan Lee (Sandia)
Jul13 : pair peri/ves : Rezwan Rahman, JT Foster (U Texas San Antonio)
Jul13 : pair tersoff/mod : Vitaly Dozhdikov (JIHT of RAS)
Jul13 : compute basal/atom : Christopher Barrett,(Mississippi State)
Jul13 : polybond tool : Zachary Kraus (Georgia Tech)
Jul13 : fix gld : Stephen Bond and Andrew Baczewski (Sandia)
Jun13 : pair nb3b/harmonic : Todd Zeitler (Sandia)
Jun13 : kspace_style pppm/stagger : Stan Moore (Sandia)
Jun13 : fix tune/kspace : Paul Crozier (Sandia)
Jun13 : long-range point dipoles : Stan Moore (Sandia) and Pieter in 't Veld (BASF)
May13 : compute msd/nongauss : Rob Hoy
May13 : pair list : Axel Kohlmeyer (Temple U)
May13 : triclinic support for long-range solvers : Stan Moore (Sandia)
Apr13 : dump_modify nfile and fileper : Christopher Knight
Mar13 : fix phonon : Ling-Ti Kong (Shanghai Jiao Tong University)
Mar13 : pair_style lj/cut/tip4p/cut : Pavel Elkind (Gothenburg University)
Feb13 : immediate variables in input script : Daniel Moller (Autonomous University of Barcelona)
Feb13 : fix species : Ray Shan (Sandia)
Jan13 : compute voronoi/atom : Daniel Schwen
Nov12 : pair_style mie/cut : Cassiano Aimoli Petrobras (U Notre Dame)
Oct12 : pair_style meam/sw/spline : Robert Rudd (LLNL)
Oct12 : angle_style fourier and fourier/simple and quartic : Loukas Peristeras (Scienomics)
Oct12 : dihedral_style fourier and nharmonic and quadratic : Loukas Peristeras (Scienomics)
Oct12 : improper_style fourier : Loukas Peristeras (Scienomics)
Oct12 : kspace_style pppm/disp for 1/r^6 : Rolf Isele-Holder (Aachen University)
Oct12 : moltemplate molecular builder tool : Andrew Jewett (UCSB)
Sep12 : pair_style lj/cut/coul/dsf and coul/dsf : Trung Nguyen (ORNL)
Sep12 : multi-level summation long-range solver : Stan Moore, Stephen Bond, and Paul Crozier (Sandia)
Aug12 : fix rigid/npt and fix rigid/nph : Trung Nguyen (ORNL)
Aug12 : Fortran wrapper on lib interface : Karl Hammond (UT, Knoxville)
Aug12 : kspace_modify diff for 2-FFT PPPM : Rolf Isele-Holder (Aachen University), Stan Moore (BYU), Paul Crozier (Sandia)
Jun12 : pair_style bop : Don Ward and Xiaowang Zhou (Sandia)
Jun12 : USER-MOLFILE package : Axel Kohlmeyer (U Temple)
Jun12 : USER-COLVARS package : Axel Kohlmeyer (U Temple)
May12 : read_dump : Tim Sirk (ARL)
May12 : improper_style cossq and ring : Georgios Vogiatzis (CoMSE, NTU Athens)
May12 : pair_style lcbop : Dominik Wojt (Wroclaw University of Technology)
Feb12 : PPPM per-atom energy/virial : Stan Moore (BYU)
Feb12 : Ewald per-atom energy/virial : German Samolyuk (ORNL), Stan Moore (BYU)
Feb12 : minimize forcezero linesearch : Asad Hasan (CMU)
Feb12 : pair_style beck : Jon Zimmerman (Sandia)
Feb12 : pair_style meam/spline : Alex Stukowski (LLNL)
Jan12 : pair_style kim : Valeriu Smirichinski, Ryan Elliott, Ellad Tadmor (U Minn)
Jan12 : dihedral_style table : Andrew Jewett (UCSB)
Jan12 : angle_style dipole : Mario Orsi
Jan12 : pair_style lj/smooth/linear : Jon Zimmerman (Sandia)
Jan12 : fix reax/c/bond : Tzu-Ray Shan (Sandia)
Dec11 : pair_style coul/wolf : Yongfeng Zhang (INL)
Dec11 : run_style verlet/split : Yuxing Peng and Chris Knight (U Chicago)
Dec11 : pair_style tersoff/table : Luca Ferraro (CASPUR)
Nov11 : per-atom energy/stress for reax/c : Tzu-Ray Shan (Sandia)
Oct11 : Fast Lubrication Dynamics (FLD) package: Amit Kumar, Michael Bybee, Jonathan Higdon (UIUC)
Oct11 : USER-OMP package : Axel Kohlmeyer (Temple U)
Sep11 : pair_style edip : Luca Ferraro (CASPUR)
Aug11 : USER-SPH package : Georg Ganzenmuller (FIHSD, EMI, Germany)
Aug11 : fix restrain : Craig Tenney (Sandia)
Aug11 : USER-CUDA package : Christian Trott (U Tech Ilmenau)
Aug11 : pair_style lj/sf : Laurent Joly (U Lyon)
Aug11 : bond_style harmonic/shift and harmonic/shift/cut : Carsten Svaneborg
Aug11 : angle_style cosine/shift and cosine/shift/exp : Carsten Svaneborg
Aug11 : dihedral_style cosine/shift/exp : Carsten Svaneborg
Aug11 : pair_style dipole/sf : Mario Orsi
Aug11 : fix addtorque and compute temp/rotate : Laurent Joly (U Lyon)
Aug11 : FFT support via FFTW3, MKL, ACML, KISSFFT libraries : \
Axel Kohlmeyer (Temple U)
Jun11 : pair_style adp : Chris Weinberger (Sandia), Stephen Foiles (Sandia), \
Chandra Veer Singh (Cornell)
Jun11 : Windows build option via Microsoft Visual Studio : \
Ilya Valuev (JIHT, Moscow, Russia)
Jun11 : antisymmetrized wave packet MD : Ilya Valuev (JIHT, Moscow, Russia)
Jun11 : dump image : Nathan Fabian (Sandia)
May11 : pppm GPU single and double : Mike Brown (ORNL)
May11 : pair_style lj/expand/gpu : Inderaj Bains (NVIDIA)
2010 : pair_style reax/c and fix qeq/reax : Metin Aktulga (Purdue, now LBNL)
- : DREIDING force field, pair_style hbond/dreiding, etc : Tod Pascal (Caltech)
- : fix adapt and compute ti for thermodynamic integration for \
free energies : Sai Jayaraman (Sandia)
- : pair_style born and gauss : Sai Jayaraman (Sandia)
- : stochastic rotation dynamics (SRD) via fix srd : \
Jeremy Lechman (Sandia) and Pieter in 't Veld (BASF)
- : ipp Perl script tool : Reese Jones (Sandia)
- : eam_database and createatoms tools : Xiaowang Zhou (Sandia)
- : electron force field (eFF) : Andres Jaramillo-Botero and Julius Su (Caltech)
- : embedded ion method (EIM) potential : Xiaowang Zhou (Sandia)
- : COMB potential with charge equilibration : Tzu-Ray Shan (U Florida)
- : fix ave/correlate : Benoit Leblanc, Dave Rigby, \
Paul Saxe (Materials Design) and Reese Jones (Sandia)
- : pair_style peri/lps : Mike Parks (Sandia)
- : fix msst : Lawrence Fried (LLNL), Evan Reed (LLNL, Stanford)
- : thermo_style custom tpcpu & spcpu keywords : Axel Kohlmeyer (Temple U)
- : fix rigid/nve, fix rigid/nvt : Tony Sheh and Trung Dac Nguyen (U Michigan)
- : public SVN & Git repositories for LAMMPS : \
Axel Kohlmeyer (Temple U) and Bill Goldman (Sandia)
- : compute heat/flux : German Samolyuk (ORNL) and \
Mario Pinto (Computational Research Lab, Pune, India)
- : pair_style yukawa/colloid : Randy Schunk (Sandia)
- : fix wall/colloid : Jeremy Lechman (Sandia)
2009 : fix imd for real-time viz and interactive MD : Axel Kohlmeyer (Temple Univ)
- : concentration-dependent EAM potential : \
Alexander Stukowski (Technical University of Darmstadt)
- : parallel replica dymamics (PRD) : Mike Brown (Sandia)
- : min_style hftn : Todd Plantenga (Sandia)
- : fix atc : Reese Jones, Jon Zimmerman, Jeremy Templeton (Sandia)
- : dump cfg : Liang Wan (Chinese Academy of Sciences)
- : fix nvt with Nose/Hoover chains : Andy Ballard (U Maryland)
- : pair_style lj/cut/gpu, pair_style gayberne/gpu : Mike Brown (Sandia)
- : pair_style lj96/cut, bond_style table, angle_style table : Chuanfu Luo
- : fix langevin tally : Carolyn Phillips (U Michigan)
- : compute heat/flux for Green-Kubo : Reese Jones (Sandia), \
Philip Howell (Siemens), Vikas Varsney (AFRL)
- : region cone : Pim Schravendijk
- : pair_style born/coul/long : Ahmed Ismail (Sandia)
- : fix ttm : Paul Crozier (Sandia) and Carolyn Phillips (U Michigan)
- : fix box/relax : Aidan Thompson and David Olmsted (Sandia)
- : ReaxFF potential : Aidan Thompson (Sandia) and Hansohl Cho (MIT)
- : compute cna/atom : Liang Wan (Chinese Academy of Sciences)
2008 : Tersoff/ZBL potential : Dave Farrell (Northwestern U)
- : peridynamics : Mike Parks (Sandia)
- : fix smd for steered MD : Axel Kohlmeyer (U Penn)
- : GROMACS pair potentials : Mark Stevens (Sandia)
- : lmp2vmd tool : Axel Kohlmeyer (U Penn)
- : compute group/group : Naveen Michaud-Agrawal (Johns Hopkins U)
- : USER-CG-CMM package for coarse-graining : Axel Kohlmeyer (U Penn)
- : cosine/delta angle potential : Axel Kohlmeyer (U Penn)
- : VIM editor add-ons for LAMMPS input scripts : Gerolf Ziegenhain
- : pair_style lubricate : Randy Schunk (Sandia)
- : compute ackland/atom : Gerolf Ziegenhain
- : kspace_style ewald/n, pair_style lj/coul, pair_style buck/coul : \
Pieter in 't Veld (Sandia)
- : AI-REBO bond-order potential : Ase Henry (MIT)
- : making LAMMPS a true "object" that can be instantiated \
multiple times, e.g. as a library : Ben FrantzDale (RPI)
- : pymol_asphere viz tool : Mike Brown (Sandia)
2007 : NEMD SLLOD integration : Pieter in 't Veld (Sandia)
- : tensile and shear deformations : Pieter in 't Veld (Sandia)
- : GayBerne potential : Mike Brown (Sandia)
- : ellipsoidal particles : Mike Brown (Sandia)
- : colloid potentials : Pieter in 't Veld (Sandia)
- : fix heat : Paul Crozier and Ed Webb (Sandia)
- : neighbor multi and communicate multi : Pieter in 't Veld (Sandia)
- : MATLAB post-processing scripts : Arun Subramaniyan (Purdue)
- : triclinic (non-orthogonal) simulation domains : Pieter in 't Veld (Sandia)
- : thermo_extract tool: Vikas Varshney (Wright Patterson AFB)
- : fix ave/time and fix ave/spatial : Pieter in 't Veld (Sandia)
- : MEAM potential : Greg Wagner (Sandia)
- : optimized pair potentials for lj/cut, charmm/long, eam, morse : \
James Fischer (High Performance Technologies), \
David Richie and Vincent Natoli (Stone Ridge Technologies)
2006 : fix wall/lj126 : Mark Stevens (Sandia)
- : Stillinger-Weber and Tersoff potentials : \
Aidan Thompson and Xiaowang Zhou (Sandia)
- : region prism : Pieter in 't Veld (Sandia)
- : fix momentum and recenter : Naveen Michaud-Agrawal (Johns Hopkins U)
- : multi-letter variable names : Naveen Michaud-Agrawal (Johns Hopkins U)
- : OPLS dihedral potential: Mark Stevens (Sandia)
- : POEMS coupled rigid body integrator: Rudranarayan Mukherjee (RPI)
- : faster pair hybrid potential: James Fischer \
(High Performance Technologies, Inc), Vincent Natoli and \
David Richie (Stone Ridge Technology)
- : breakable bond quartic potential: Chris Lorenz and Mark Stevens (Sandia)
- : DCD and XTC dump styles: Naveen Michaud-Agrawal (Johns Hopkins U)
- : grain boundary orientation fix : Koenraad Janssens and \
David Olmsted (Sandia)
- : pair_style lj/smooth potential : Craig Maloney (UCSB)
- : radius-of-gyration spring fix : Naveen Michaud-Agrawal \
(Johns Hopkins U) and Paul Crozier (Sandia)
- : self spring fix : Naveen Michaud-Agrawal (Johns Hopkins U)
- : EAM CoAl and AlCu potentials : Kwang-Reoul Lee (KIST, Korea)
- : cosine/squared angle potential : Naveen Michaud-Agrawal (Johns Hopkins U)
- : helix dihedral potential : Naveen Michaud-Agrawal (Johns Hopkins U) and \
Mark Stevens (Sandia)
- : Finnis/Sinclair EAM: Tim Lau (MIT)
- : dissipative particle dynamics (DPD) potentials: Kurt Smith (U Pitt) and \
Frank van Swol (Sandia)
- : TIP4P potential (4-site water): Ahmed Ismail and \
Amalie Frischknecht (Sandia)
2005 : uniaxial strain fix: Carsten Svaneborg (Max Planck Institute)
- : compressed dump files: Erik Luijten (U Illinois)
- : cylindrical indenter fix: Ravi Agrawal (Northwestern U)
- : electric field fix: Christina Payne (Vanderbilt U)
- : AMBER <-> LAMMPS tool: Keir Novik (Univ College London) and \
Vikas Varshney (U Akron)
- : CHARMM <-> LAMMPS tool: Pieter in 't Veld and Paul Crozier (Sandia)
- : Morse bond potential: Jeff Greathouse (Sandia)
- : radial distribution functions: Paul Crozier & Jeff Greathouse (Sandia)
- : force tables for long-range Coulombics: Paul Crozier (Sandia)
2004 : targeted molecular dynamics (TMD): Paul Crozier (Sandia) and \
Christian Burisch (Bochum University, Germany)
- : FFT support for SGI SCLS (Altix): Jim Shepherd (Ga Tech)
- : lmp2cfg and lmp2traj tools: Ara Kooser, Jeff Greathouse, \
Andrey Kalinichev (Sandia)
- : parallel tempering: Mark Sears (Sandia)
earlier : granular force fields and BC: Leo Silbert & Gary Grest (Sandia)
- : multi-harmonic dihedral potential: Mathias Putz (Sandia)
- : embedded atom method (EAM) potential: Stephen Foiles (Sandia)
- : msi2lmp tool: Steve Lustig (Dupont), Mike Peachey & John Carpenter (Cray)
- : HTFN energy minimizer: Todd Plantenga (Sandia)
- : class 2 force fields: Eric Simon (Cray)
- : NVT/NPT integrators: Mark Stevens (Sandia)
- : rRESPA: Mark Stevens & Paul Crozier (Sandia)
- : Ewald and PPPM solvers: Roy Pollock (LLNL) : :tb(s=:,ca1=c)

4
doc/src/Intro_features.txt
View File

@ -20,7 +20,7 @@ classes of functionality:
"Integrators"_#integrate
"Diagnostics"_#diag
"Output"_#output
"Multi-replica models"_#replica
"Multi-replica models"_#replica1
"Pre- and post-processing"_#prepost
"Specialized features (beyond MD itself)"_#special :ul
@ -154,7 +154,7 @@ Output :h4,link(output)
time averaging of system-wide quantities
atom snapshots in native, XYZ, XTC, DCD, CFG formats :ul
Multi-replica models :h4,link(replica)
Multi-replica models :h4,link(replica1)
"nudged elastic band"_neb.html
"parallel replica dynamics"_prd.html

18
doc/src/Intro_nonfeatures.txt
View File

@ -28,7 +28,7 @@ GUI: LAMMPS can be built as a library and a Python wrapper that wraps
the library interface is provided. Thus, GUI interfaces can be
written in Python (or C or C++ if desired) that run LAMMPS and
visualize or plot its output. Examples of this are provided in the
python directory and described on the "Python"_Python.html doc
python directory and described on the "Python"_Python_head.html doc
page. :ulb,l
Builder: Several pre-processing tools are packaged with LAMMPS. Some
@ -55,9 +55,9 @@ info on how to add your own analysis code or algorithms to LAMMPS.
For post-processing, LAMMPS output such as "dump file
snapshots"_dump.html can be converted into formats used by other MD or
post-processing codes. Some post-processing tools packaged with
LAMMPS will do these conversions. Scripts provided with the {python}
tool in the tools directory can extract and massage data in dump files
to make it easier to import into other programs. See the
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
@ -68,11 +68,11 @@ page"_http://lammps.sandia.gov/viz.html page of the LAMMPS website for
visualization packages that can use LAMMPS output data. :l
Plotting: See the next bullet about Pizza.py as well as the
"Python"_Python.html doc page for examples of plotting LAMMPS output.
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
"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

49
doc/src/Manual.txt
View File

@ -1,13 +1,15 @@
<!-- HTML_ONLY -->
<HEAD>
<TITLE>LAMMPS Users Manual</TITLE>
<META NAME="docnumber" CONTENT="2 Aug 2018 version">
<META NAME="docnumber" CONTENT="22 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
@ -18,10 +20,8 @@
:line
<H1></H1>
LAMMPS Documentation :c,h1
2 Aug 2018 version :c,h2
22 Aug 2018 version :c,h2
"What is a LAMMPS version?"_Manual_version.html
@ -47,9 +47,9 @@ all LAMMPS development is coordinated.
"PDF file"_Manual.pdf of the entire manual, generated by
"htmldoc"_http://freecode.com/projects/htmldoc
The content for this manual is part of the LAMMPS distribution.
You can build a local copy of the Manual as HTML pages or a PDF file,
by following the steps on the "this page"_Build_manual.html.
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.
There is also a "Developer.pdf"_Developer.pdf document which gives
a brief description of the basic code structure of LAMMPS.
@ -66,13 +66,15 @@ every LAMMPS command.
.. toctree::
:maxdepth: 2
:numbered:
:numbered: 3
:caption: User Documentation
:name: userdoc
:includehidden:
Intro
Section_start
Install
Build
Run_head
Commands
Packages
Speed
@ -80,15 +82,16 @@ every LAMMPS command.
Examples
Tools
Modify
Python
Python_head
Errors
Manual_build
.. toctree::
:caption: Index
:name: index
:hidden:
commands
commands_list
fixes
computes
pairs
@ -107,15 +110,9 @@ END_RST -->
<!-- HTML_ONLY -->
"Introduction"_Intro.html :olb,l
"Getting started"_Section_start.html :l
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
"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
@ -123,19 +120,11 @@ END_RST -->
"Example scripts"_Examples.html :l
"Auxiliary tools"_Tools.html :l
"Modify & extend LAMMPS"_Modify.html :l
"Use Python with LAMMPS"_Python.html :l
"Use Python with LAMMPS"_Python_head.html :l
"Errors"_Errors.html :l
"Building the LAMMPS manual"_Manual_build.html :l
:ole
:link(start_1,Section_start.html#start_1)
:link(start_2,Section_start.html#start_2)
:link(start_3,Section_start.html#start_3)
:link(start_4,Section_start.html#start_4)
:link(start_5,Section_start.html#start_5)
:link(start_6,Section_start.html#start_6)
:link(start_7,Section_start.html#start_7)
:link(start_8,Section_start.html#start_8)
<!-- END_HTML_ONLY -->
</BODY>

124
doc/src/Manual_build.txt Normal file
View File

@ -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

2
doc/src/Manual_version.txt
View File

@ -7,7 +7,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
:line
What does a LAMMPS version mean: :h3
What does a LAMMPS version mean :h3
The LAMMPS "version" is the date when it was released, such as 1 May
2014. LAMMPS is updated continuously. Whenever we fix a bug or add a

16
doc/src/Modify.txt
View File

@ -1,6 +1,6 @@
"Previous Section"_Tools.html - "LAMMPS WWW Site"_lws -
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
Section"_Python.html :c
Section"_Python_head.html :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
@ -24,11 +24,13 @@ contribute"_Modify_contribute.html doc page.
<!-- RST
.. toctree::
:maxdepth: 1
Modify_overview
Modify_contribute
.. toctree::
:maxdepth: 1
Modify_atom
Modify_pair
@ -36,17 +38,11 @@ contribute"_Modify_contribute.html doc page.
Modify_compute
Modify_fix
Modify_command
.. toctree::
Modify_dump
Modify_kspace
Modify_min
Modify_region
Modify_body
.. toctree::
Modify_thermo
Modify_variable
@ -62,14 +58,12 @@ END_RST -->
"Bond, angle, dihedral, improper styles"_Modify_bond.html
"Compute styles"_Modify_compute.html
"Fix styles"_Modify_fix.html
"Input script command styles"_Modify_command.html :all(b)
"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 :all(b)
"Body styles"_Modify_body.html
"Thermodynamic output options"_Modify_thermo.html
"Variable options"_Modify_variable.html :all(b)

15
doc/src/Modify_contribute.txt
View File

@ -44,13 +44,14 @@ compression, as this works well on all platforms.
If the new features/files are broadly useful we may add them as core
files to LAMMPS or as part of a "standard
package"_Section_start.html#start_3. Else we will add them as a
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.
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,

9
doc/src/Packages.txt
View File

@ -13,16 +13,17 @@ Optional packages :h2
This section gives an overview of the optional packages that extend
LAMMPS functionality. Packages are groups of files that enable a
specific set of features. For example, force fields for molecular
systems or rigid-body constraint are in packages. You can see the
systems or rigid-body constraints are in packages. You can see the
list of all packages and "make" commands to manage them by typing
"make package" from within the src directory of the LAMMPS
distribution. "Section 2.3"_Section_start.html#start_3 gives general
info on how to install and un-install packages as part of the LAMMPS
build process.
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

67
doc/src/Packages_standard.txt
View File

@ -25,41 +25,42 @@ 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
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#ASPHERE, aspherical particle models, "Howto spherical"_Howto_spherical.html, ellipse, -
"BODY"_Packages_details.html#BODY, body-style particles, "Howto body"_Howto_body.html, body, -
"CLASS2"_Packages_details.html#CLASS2, class 2 force fields, "pair_style lj/class2"_pair_class2.html, -, -
"COLLOID"_Packages_details.html#COLLOID, colloidal particles, "atom_style colloid"_atom_style.html, colloid, -
"COMPRESS"_Packages_details.html#COMPRESS, I/O compression, "dump */gz"_dump.html, -, sys
"CORESHELL"_Packages_details.html#CORESHELL, adiabatic core/shell model, "Howto coreshell"_Howto_coreshell.html, coreshell, -
"DIPOLE"_Packages_details.html#DIPOLE, point dipole particles, "pair_style dipole/cut"_pair_dipole.html, dipole, -
"GPU"_Packages_details.html#GPU, GPU-enabled styles, "Section gpu"_Speed_gpu.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, int
"GRANULAR"_Packages_details.html#GRANULAR, granular systems, "Howto granular"_Howto_granular.html, pour, -
"KIM"_Packages_details.html#KIM, OpenKIM wrapper, "pair_style kim"_pair_kim.html, kim, ext
"KOKKOS"_Packages_details.html#KOKKOS, Kokkos-enabled styles, "Speed kokkos"_Speed_kokkos.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, -
"KSPACE"_Packages_details.html#KSPACE, long-range Coulombic solvers, "kspace_style"_kspace_style.html, peptide, -
"LATTE"_Packages_details.html#LATTE, quantum DFTB forces via LATTE, "fix latte"_fix_latte.html, latte, ext
"MANYBODY"_Packages_details.html#MANYBODY, many-body potentials, "pair_style tersoff"_pair_tersoff.html, shear, -
"MC"_Packages_details.html#MC, Monte Carlo options, "fix gcmc"_fix_gcmc.html, -, -
"MEAM"_Packages_details.html#MEAM, modified EAM potential, "pair_style meam"_pair_meam.html, meam, int
"MISC"_Packages_details.html#MISC, miscellanous single-file commands, -, -, -
"MOLECULE"_Packages_details.html#MOLECULE, molecular system force fields, "Howto bioFF"_Howto_bioFF.html, peptide, -
"MPIIO"_Packages_details.html#MPIIO, MPI parallel I/O dump and restart, "dump"_dump.html, -, -
"MSCG"_Packages_details.html#MSCG, multi-scale coarse-graining wrapper, "fix mscg"_fix_mscg.html, mscg, ext
"OPT"_Packages_details.html#OPT, optimized pair styles, "Speed opt"_Speed_opt.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, -
"PERI"_Packages_details.html#PERI, Peridynamics models, "pair_style peri"_pair_peri.html, peri, -
"POEMS"_Packages_details.html#POEMS, coupled rigid body motion, "fix poems"_fix_poems.html, rigid, int
"PYTHON"_Packages_details.html#PYTHON, embed Python code in an input script, "python"_python.html, python, sys
"QEQ"_Packages_details.html#QEQ, QEq charge equilibration, "fix qeq"_fix_qeq.html, qeq, -
"REAX"_Packages_details.html#REAX, ReaxFF potential (Fortran), "pair_style reax"_pair_reax.html, reax, int
"REPLICA"_Packages_details.html#REPLICA, multi-replica methods, "Howto replica"_Howto_replica.html, tad, -
"RIGID"_Packages_details.html#RIGID, rigid bodies and constraints, "fix rigid"_fix_rigid.html, rigid, -
"SHOCK"_Packages_details.html#SHOCK, shock loading methods, "fix msst"_fix_msst.html, -, -
"SNAP"_Packages_details.html#SNAP, quantum-fitted potential, "pair_style snap"_pair_snap.html, snap, -
"SPIN"_#SPIN, magnetic atomic spin dynamics, "Howto spin"_Howto_spin.html, SPIN, -"SRD"_Packages_details.html#SRD, stochastic rotation dynamics, "fix srd"_fix_srd.html, srd, -
"VORONOI"_Packages_details.html#VORONOI, Voronoi tesselation, "compute voronoi/atom"_compute_voronoi_atom.html, -, ext :tb(ea=c,ca1=l)
"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)

70
doc/src/Packages_user.txt
View File

@ -32,43 +32,43 @@ 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
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#USER-ATC, atom-to-continuum coupling, "fix atc"_fix_atc.html, USER/atc, int
"USER-AWPMD"_Packages_details.html#USER-AWPMD, wave-packet MD, "pair_style awpmd/cut"_pair_awpmd.html, USER/awpmd, int
"USER-BOCS"_Packages_details.html#USER-BOCS, BOCS bottom up coarse graining, "fix bocs"_fix_bocs.html, USER/bocs, -
"USER-CGDNA"_Packages_details.html#USER-CGDNA, coarse-grained DNA force fields, src/USER-CGDNA/README, USER/cgdna, -
"USER-CGSDK"_Packages_details.html#USER-CGSDK, SDK coarse-graining model, "pair_style lj/sdk"_pair_sdk.html, USER/cgsdk, -
"USER-COLVARS"_Packages_details.html#USER-COLVARS, collective variables library, "fix colvars"_fix_colvars.html, USER/colvars, int
"USER-DIFFRACTION"_Packages_details.html#USER-DIFFRACTION, virtual x-ray and electron diffraction,"compute xrd"_compute_xrd.html, USER/diffraction, -
"USER-DPD"_Packages_details.html#USER-DPD, reactive dissipative particle dynamics, src/USER-DPD/README, USER/dpd, -
"USER-DRUDE"_Packages_details.html#USER-DRUDE, Drude oscillators, "Howto drude"_Howto_drude.html, USER/drude, -
"USER-EFF"_Packages_details.html#USER-EFF, electron force field,"pair_style eff/cut"_pair_eff.html, USER/eff, -
"USER-FEP"_Packages_details.html#USER-FEP, free energy perturbation,"compute fep"_compute_fep.html, USER/fep, -
"USER-H5MD"_Packages_details.html#USER-H5MD, dump output via HDF5,"dump h5md"_dump_h5md.html, -, ext
"USER-INTEL"_Packages_details.html#USER-INTEL, optimized Intel CPU and KNL styles,"Speed intel"_Speed_intel.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, -
"USER-LB"_Packages_details.html#USER-LB, Lattice Boltzmann fluid,"fix lb/fluid"_fix_lb_fluid.html, USER/lb, -
"USER-MANIFOLD"_Packages_details.html#USER-MANIFOLD, motion on 2d surfaces,"fix manifoldforce"_fix_manifoldforce.html, USER/manifold, -
"USER-MEAMC"_Packages_details.html#USER-MEAMC, modified EAM potential (C++), "pair_style meam/c"_pair_meam.html, meam, -
"USER-MESO"_Packages_details.html#USER-MESO, mesoscale DPD models, "pair_style edpd"_pair_meso.html, USER/meso, -
"USER-MGPT"_Packages_details.html#USER-MGPT, fast MGPT multi-ion potentials, "pair_style mgpt"_pair_mgpt.html, USER/mgpt, -
"USER-MISC"_Packages_details.html#USER-MISC, single-file contributions, USER-MISC/README, USER/misc, -
"USER-MOFFF"_Packages_details.html#USER-MOFFF, styles for "MOF-FF"_MOFplus force field, "pair_style buck6d/coul/gauss"_pair_buck6d_coul_gauss.html, USER/mofff, -
"USER-MOLFILE"_Packages_details.html#USER-MOLFILE, "VMD"_vmd_home molfile plug-ins,"dump molfile"_dump_molfile.html, -, ext
"USER-NETCDF"_Packages_details.html#USER-NETCDF, dump output via NetCDF,"dump netcdf"_dump_netcdf.html, -, ext
"USER-OMP"_Packages_details.html#USER-OMP, OpenMP-enabled styles,"Speed omp"_Speed_omp.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, -
"USER-PHONON"_Packages_details.html#USER-PHONON, phonon dynamical matrix,"fix phonon"_fix_phonon.html, USER/phonon, -
"USER-QMMM"_Packages_details.html#USER-QMMM, QM/MM coupling,"fix qmmm"_fix_qmmm.html, USER/qmmm, ext
"USER-QTB"_Packages_details.html#USER-QTB, quantum nuclear effects,"fix qtb"_fix_qtb.html "fix qbmsst"_fix_qbmsst.html, qtb, -
"USER-QUIP"_Packages_details.html#USER-QUIP, QUIP/libatoms interface,"pair_style quip"_pair_quip.html, USER/quip, ext
"USER-REAXC"_Packages_details.html#USER-REAXC, ReaxFF potential (C/C++) ,"pair_style reaxc"_pair_reaxc.html, reax, -
"USER-SMD"_Packages_details.html#USER-SMD, smoothed Mach dynamics,"SMD User Guide"_PDF/SMD_LAMMPS_userguide.pdf, USER/smd, ext
"USER-SMTBQ"_Packages_details.html#USER-SMTBQ, second moment tight binding QEq potential,"pair_style smtbq"_pair_smtbq.html, USER/smtbq, -
"USER-SPH"_Packages_details.html#USER-SPH, smoothed particle hydrodynamics,"SPH User Guide"_PDF/SPH_LAMMPS_userguide.pdf, USER/sph, -
"USER-TALLY"_Packages_details.html#USER-TALLY, pairwise tally computes,"compute XXX/tally"_compute_tally.html, USER/tally, -
"USER-UEF"_Packages_details.html#USER-UEF, extensional flow,"fix nvt/uef"_fix_nh_uef.html, USER/uef, -
"USER-VTK"_Packages_details.html#USER-VTK, dump output via VTK, "compute vtk"_dump_vtk.html, -, ext :tb(ea=c,ca1=l)
"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)

4
doc/src/Python_call.txt
View File

@ -1,5 +1,5 @@
"Higher level section"_Python.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
"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)

4
doc/src/Python_examples.txt
View File

@ -1,5 +1,5 @@
"Higher level section"_Python.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
"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)

13
doc/src/Python.txt → doc/src/Python_head.txt
View File

@ -16,11 +16,9 @@ used together.
<!-- RST
.. toctree::
:maxdepth: 1
Python_overview
.. toctree::
Python_run
Python_shlib
Python_install
@ -29,17 +27,13 @@ used together.
Python_library
Python_pylammps
Python_examples
.. toctree::
Python_call
END_RST -->
<!-- HTML_ONLY -->
"Overview of Python and LAMMPS"_Python_overview.html :all(b)
"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
@ -47,8 +41,7 @@ END_RST -->
"Test the Python/LAMMPS interface"_Python_test.html
"Python library interface"_Python_library.html
"PyLammps interface"_Python_pylammps.html
"Example Python scripts that use LAMMPS"_Python_examples.html :all(b)
"Example Python scripts that use LAMMPS"_Python_examples.html
"Call Python from a LAMMPS input script"_Python_call.html :all(b)
<!-- END_HTML_ONLY -->

6
doc/src/Python_install.txt
View File

@ -1,5 +1,5 @@
"Higher level section"_Python.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
"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)
@ -68,7 +68,7 @@ need to prefix this with "sudo". In this mode you cannot control
which Python is invoked by root.
Note that if you want Python to be able to load different versions of
the LAMMPS shared library (see "this section"_#py_5 below), you will
the LAMMPS shared library (see "this section"_Python_shlib.html), you will
need to manually copy files like liblammps_g++.so into the appropriate
system directory. This is not needed if you set the LD_LIBRARY_PATH
environment variable as described above.

4
doc/src/Python_library.txt
View File

@ -1,5 +1,5 @@
"Higher level section"_Python.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
"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)

4
doc/src/Python_mpi.txt
View File

@ -1,5 +1,5 @@
"Higher level section"_Python.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
"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)

4
doc/src/Python_pylammps.txt
View File

@ -1,5 +1,5 @@
"Higher level section"_Python.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
"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)

4
doc/src/Python_run.txt
View File

@ -1,5 +1,5 @@
"Higher level section"_Python.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
"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)

55
doc/src/Python_shlib.txt
View File

@ -1,5 +1,5 @@
"Higher level section"_Python.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
"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)
@ -9,10 +9,13 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
Build LAMMPS as a shared library :h3
Instructions on how to build LAMMPS as a shared library are given in
"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".
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
@ -29,6 +32,42 @@ NOTE: If you are building LAMMPS with an MPI or FFT library or other
auxiliary libraries (used by various packages), then all of these
extra libraries must also be shared libraries. If the LAMMPS
shared-library build fails with an error complaining about this, see
"Section 2.4"_Section_start.html#start_4 for more details.
the "Build_basics"_Build_basics.html doc page.
Also include CMake info on this
Build LAMMPS as a shared library using CMake :h4
When using CMake the following two options are necessary to generate the LAMMPS
shared library:
-D BUILD_LIB=on # enable building LAMMPS as a library
-D BUILD_SHARED_LIBS=on # enable building of LAMMPS shared library (both options are needed!) :pre
What this does is create a liblammps.so which contains the majority of LAMMPS
code. The generated lmp binary also dynamically links to this library. This
means that either this liblammps.so file has to be in the same directory, a system
library path (e.g. /usr/lib64/) or in the LD_LIBRARY_PATH.
If you want to use the shared library with Python the recommended way is to create a virtualenv and use it as
CMAKE_INSTALL_PREFIX.
# create virtualenv
virtualenv --python=$(which python3) myenv3
source myenv3/bin/activate :pre
# build library
mkdir build
cd build
cmake -D PKG_PYTHON=on -D BUILD_LIB=on -D BUILD_SHARED_LIBS=on -D CMAKE_INSTALL_PREFIX=$VIRTUAL_ENV ../cmake
make -j 4 :pre
# install into prefix
make install :pre
This will also install the Python module into your virtualenv. Since virtualenv
doesn't change your LD_LIBRARY_PATH, you still need to add its lib64 folder to
it, which contains the installed liblammps.so.
export LD_LIBRARY_PATH=$VIRTUAL_ENV/lib64:$LD_LIBRARY_PATH :pre
Starting Python outside (!) of your build directory, but with the virtualenv
enabled and with the LD_LIBRARY_PATH set gives you access to LAMMPS via Python.

12
doc/src/Python_test.txt
View File

@ -1,5 +1,5 @@
"Higher level section"_Python.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
"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)
@ -32,10 +32,10 @@ first importing from the lammps.py file:
>>> from ctypes import CDLL
>>> CDLL("liblammps.so") :pre
If an error occurs, carefully go thru the steps in "Section
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.
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

89
doc/src/Run_basics.txt Normal file
View File

@ -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.

38
doc/src/Run_head.txt Normal file
View File

@ -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 -->

469
doc/src/Run_options.txt Normal file
View File

@ -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.

176
doc/src/Run_output.txt Normal file
View File

@ -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.

73
doc/src/Run_windows.txt Normal file
View File

@ -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

1823
doc/src/Section_start.txt
View File

File diff suppressed because it is too large Load Diff

13
doc/src/Speed.txt
View File

@ -31,16 +31,11 @@ hardware platforms.
<!-- RST
.. toctree::
:maxdepth: 1
Speed_bench
Speed_measure
.. toctree::
Speed_tips
.. toctree::
Speed_packages
Speed_compare
@ -49,10 +44,8 @@ END_RST -->
<!-- HTML_ONLY -->
"Benchmarks"_Speed_bench.html
"Measuring performance"_Speed_measure.html :all(b)
"General tips"_Speed_tips.html :all(b)
"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

119
doc/src/Speed_compare.txt
View File

@ -9,65 +9,108 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
Comparison of various accelerator packages :h3
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.
run on GPUs, optimize for vector units on CPUs and run on Intel
Xeon Phi (co-)processors.
All 3 of these packages accelerate a LAMMPS calculation using NVIDIA
hardware, but they do it in different ways.
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 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
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:]
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
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)
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 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, 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
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 packages compute bonded interactions (bonds, angles, etc) on the
CPU. If the GPU package is running with several MPI processes
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. :l
spread across more CPUs and hence the GPU package can run faster in these
cases. :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
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 two packages:]
[Differences between the GPU and KOKKOS packages:]
The GPU package accelerates only pair force, neighbor list, and PPPM
calculations. :ulb,l
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

137
doc/src/Speed_gpu.txt
View File

@ -9,17 +9,17 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
GPU package :h3
The GPU package was developed by Mike Brown at ORNL and his
collaborators, particularly Trung Nguyen (ORNL). It provides GPU
versions of many pair styles, including the 3-body Stillinger-Weber
pair style, and for "kspace_style pppm"_kspace_style.html for
long-range Coulombics. It has the following general features:
The GPU package was developed by Mike Brown while at SNL and ORNL
and his collaborators, particularly Trung Nguyen (now at Northwestern).
It provides GPU versions of many pair styles and for parts of the
"kspace_style pppm"_kspace_style.html for long-range Coulombics.
It has the following general features:
It is designed to exploit common GPU hardware configurations where one
or more GPUs are coupled to many cores of one or more multi-core CPUs,
e.g. within a node of a parallel machine. :ulb,l
Atom-based data (e.g. coordinates, forces) moves back-and-forth
Atom-based data (e.g. coordinates, forces) are moved back-and-forth
between the CPU(s) and GPU every timestep. :l
Neighbor lists can be built on the CPU or on the GPU :l
@ -28,8 +28,8 @@ The charge assignment and force interpolation portions of PPPM can be
run on the GPU. The FFT portion, which requires MPI communication
between processors, runs on the CPU. :l
Asynchronous force computations can be performed simultaneously on the
CPU(s) and GPU. :l
Force computations of different style (pair vs. bond/angle/dihedral/improper)
can be performed concurrently on the GPU and CPU(s), respectively. :l
It allows for GPU computations to be performed in single or double
precision, or in mixed-mode precision, where pairwise forces are
@ -39,93 +39,37 @@ force vectors. :l
LAMMPS-specific code is in the GPU package. It makes calls to a
generic GPU library in the lib/gpu directory. This library provides
NVIDIA support as well as more general OpenCL support, so that the
same functionality can eventually be supported on a variety of GPU
hardware. :l
same functionality is supported on a variety of 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:
To compile and use this package in CUDA mode, you currently need
to have an NVIDIA GPU and install the corresponding NVIDIA CUDA
toolkit software on your system (this is primarily tested on Linux
and completely unsupported on Windows):
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/*/information :ulb,l
Go to http://www.nvidia.com/object/cuda_get.html :l
Install a driver and toolkit appropriate for your system (SDK is not necessary) :l
Run lammps/lib/gpu/nvc_get_devices (after building the GPU library, see below) to
list supported devices and properties :ule,l
To compile and use this package in OpenCL mode, you currently need
to have the OpenCL headers and the (vendor neutral) OpenCL library installed.
In OpenCL mode, the acceleration depends on having an "OpenCL Installable Client
Driver (ICD)"_https://www.khronos.org/news/permalink/opencl-installable-client-driver-icd-loader
installed. There can be multiple of them for the same or different hardware
(GPUs, CPUs, Accelerators) installed at the same time. OpenCL refers to those
as 'platforms'. The GPU library will select the [first] suitable platform,
but this can be overridded using the device option of the "package"_package.html
command. run lammps/lib/gpu/ocl_get_devices to get a list of available
platforms and devices with a suitable ICD available.
[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 on the "Packages details"_Packages_details.html#GPU doc
page.
Or you can follow these two (a,b) steps:
(a) Build the GPU library
The GPU library is in lammps/lib/gpu. Select a Makefile.machine (in
lib/gpu) appropriate for your system. You should pay special
attention to 3 settings in this makefile.
CUDA_HOME = needs to be where NVIDIA CUDA software is installed on your system
CUDA_ARCH = needs to be appropriate to your GPUs
CUDA_PREC = precision (double, mixed, single) you desire :ul
See lib/gpu/Makefile.linux.double for examples of the ARCH settings
for different GPU choices, e.g. Fermi vs Kepler. It also lists the
possible precision settings:
CUDA_PREC = -D_SINGLE_SINGLE # single precision for all calculations
CUDA_PREC = -D_DOUBLE_DOUBLE # double precision for all calculations
CUDA_PREC = -D_SINGLE_DOUBLE # accumulation of forces, etc, in double :pre
The last setting is the mixed mode referred to above. Note that your
GPU must support double precision to use either the 2nd or 3rd of
these settings.
To build the library, type:
make -f Makefile.machine :pre
If successful, it will produce the files libgpu.a and Makefile.lammps.
The latter file has 3 settings that need to be appropriate for the
paths and settings for the CUDA system software on your machine.
Makefile.lammps is a copy of the file specified by the EXTRAMAKE
setting in Makefile.machine. You can change EXTRAMAKE or create your
own Makefile.lammps.machine if needed.
Note that to change the precision of the GPU library, you need to
re-build the entire library. Do a "clean" first, e.g. "make -f
Makefile.linux clean", followed by the make command above.
(b) Build LAMMPS with the GPU package
cd lammps/src
make yes-gpu
make machine :pre
No additional compile/link flags are needed in Makefile.machine.
Note that if you change the GPU library precision (discussed above)
and rebuild the GPU library, then you also need to re-install the GPU
package and re-build LAMMPS, so that all affected files are
re-compiled and linked to the new GPU library.
See the "Build extras"_Build_extras.html#gpu doc page for
instructions.
[Run with the GPU package from the command line:]
@ -143,10 +87,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
@ -180,14 +124,17 @@ 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:]
The performance of a GPU versus a multi-core CPU is a function of your
hardware, which pair style is used, the number of atoms/GPU, and the
precision used on the GPU (double, single, mixed).
precision used on the GPU (double, single, mixed). Using the GPU package
in OpenCL mode on CPUs (which uses vectorization and multithreading) is
usually resulting in inferior performance compared to using LAMMPS' native
threading and vectorization support in the USER-OMP and USER-INTEL packages.
See the "Benchmark page"_http://lammps.sandia.gov/bench.html of the
LAMMPS web site for performance of the GPU package on various
@ -213,7 +160,7 @@ The "package gpu"_package.html command has several options for tuning
performance. Neighbor lists can be built on the GPU or CPU. Force
calculations can be dynamically balanced across the CPU cores and
GPUs. GPU-specific settings can be made which can be optimized
for different hardware. See the "packakge"_package.html command
for different hardware. See the "package"_package.html command
doc page for details. :l
As described by the "package gpu"_package.html command, GPU

101
doc/src/Speed_intel.txt
View File

@ -203,16 +203,12 @@ cat /proc/cpuinfo :pre
[Building LAMMPS with the USER-INTEL package:]
NOTE: See the src/USER-INTEL/README file for additional flags that
might be needed for best performance on Intel server processors
code-named "Skylake".
See the "Build extras"_Build_extras.html#user-intel doc page for
instructions. Some additional details are covered here.
The USER-INTEL package must be installed into the source directory:
make yes-user-intel :pre
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
@ -221,20 +217,16 @@ Makefile.intel_cpu_openpmi # Intel Compiler, OpenMPI, No Offload
Makefile.intel_coprocessor # Intel Compiler, Intel MPI, Offload :pre
Makefile.knl is identical to Makefile.intel_cpu_intelmpi except that
it explicitly specifies that vectorization should be for Intel
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, as described on the "Packages
details"_Packages_details.html#USER-INTEL doc page.
Note that if you build with support for a Phi coprocessor, the same
binary can be used on nodes with or without coprocessors installed.
However, if you do not have coprocessors on your system, building
@ -253,6 +245,10 @@ required for CCFLAGS and "-qoffload" is required for LINKFLAGS. Other
recommended CCFLAG options for best performance are "-O2 -fno-alias
-ansi-alias -qoverride-limits fp-model fast=2 -no-prec-div".
NOTE: See the src/USER-INTEL/README file for additional flags that
might be needed for best performance on Intel server processors
code-named "Skylake".
NOTE: The vectorization and math capabilities can differ depending on
the CPU. For Intel compilers, the "-x" flag specifies the type of
processor for which to optimize. "-xHost" specifies that the compiler
@ -306,31 +302,31 @@ Hyper-Threading technology disabled.
[Run with the USER-INTEL package from the command line:]
To enable USER-INTEL optimizations for all available styles used in
the input script, the "-sf intel"
"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):
@ -390,19 +386,18 @@ lj/cut or when using LRT mode on processors supporting AVX-512.
Not all styles are supported in the USER-INTEL package. You can mix
the USER-INTEL package with styles from the "OPT"_Speed_opt.html
package or the "USER-OMP package"_Speed_omp.html. Of course,
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.
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
@ -496,8 +491,8 @@ sorting"_atom_modify.html is changed to 1 so that the per-atom data is
effectively sorted at every rebuild of the neighbor lists. All the
available coprocessor threads on each Phi will be divided among MPI
tasks, unless the {tptask} option of the "-pk intel" "command-line
switch"_Section_start.html#start_6 is used to limit the coprocessor
threads per MPI task.
switch"_Run_options.html is used to limit the coprocessor threads per
MPI task.
[Restrictions:]

200
doc/src/Speed_kokkos.txt
View File

@ -37,90 +37,29 @@ task). These are Serial (MPI-only for CPUs and Intel Phi), OpenMP
GPUs). You choose the mode at build time to produce an executable
compatible with specific hardware.
[Building LAMMPS with the KOKKOS package:]
NOTE: Kokkos support within LAMMPS must be built with a C++11 compatible
compiler. This means GCC version 4.7.2 or later, Intel 14.0.4 or later, or
Clang 3.5.2 or later is required.
The recommended method of building the KOKKOS package is to start with
the provided Kokkos Makefiles in /src/MAKE/OPTIONS/. You may need to
modify the KOKKOS_ARCH variable in the Makefile to match your specific
hardware. For example:
for Sandy Bridge CPUs, set KOKKOS_ARCH=SNB
for Broadwell CPUs, set KOKKOS_ARCH=BWD
for K80 GPUs, set KOKKOS_ARCH=Kepler37
for P100 GPUs and Power8 CPUs, set KOKKOS_ARCH=Pascal60,Power8 :ul
See the [Advanced Kokkos Options] section below for a listing of all
KOKKOS_ARCH options.
[Compile for CPU-only (MPI only, no threading):]
use a C++11 compatible compiler and set KOKKOS_ARCH variable in
/src/MAKE/OPTIONS/Makefile.kokkos_mpi_only as described above. Then do the
following:
cd lammps/src
make yes-kokkos
make kokkos_mpi_only :pre
[Compile for CPU-only (MPI plus OpenMP threading):]
NOTE: To build with Kokkos support for OpenMP threading, your compiler
must support the OpenMP interface. You should have one or more
multi-core CPUs so that multiple threads can be launched by each MPI
task running on a CPU.
Use a C++11 compatible compiler and set KOKKOS_ARCH variable in
/src/MAKE/OPTIONS/Makefile.kokkos_omp as described above. Then do the
following:
cd lammps/src
make yes-kokkos
make kokkos_omp :pre
[Compile for Intel KNL Xeon Phi (Intel Compiler, OpenMPI):]
use a C++11 compatible compiler and do the following:
cd lammps/src
make yes-kokkos
make kokkos_phi :pre
[Compile for CPUs and GPUs (with OpenMPI or MPICH):]
NOTE: To build with Kokkos support for NVIDIA GPUs, NVIDIA CUDA
software version 7.5 or later must be installed on your system. See
the discussion for the "GPU package"_Speed_gpu.html for details of how
to check and do this.
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:
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.
cd lammps/src
make yes-kokkos
make kokkos_cuda_mpi :pre
[Building LAMMPS with the KOKKOS package:]
[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.
See the "Build extras"_Build_extras.html#kokkos doc page for instructions.
[Running LAMMPS with the KOKKOS package:]
@ -142,12 +81,11 @@ mpirun -np 2 lmp_kokkos_omp -k on t 8 -sf kk -in in.lj # 1 node, 2 MPI
mpirun -np 32 -ppn 4 lmp_kokkos_omp -k on t 4 -sf kk -in in.lj # 8 nodes, 4 MPI tasks/node, 4 threads/task :pre
To run using the KOKKOS package, use the "-k on", "-sf kk" and "-pk
kokkos" "command-line switches"_Section_start.html#start_7 in your
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:
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
@ -162,11 +100,11 @@ command (with no additional arguments) which sets various KOKKOS
options to default values, as discussed on the "package"_package.html
command doc page.
The "-sf kk" "command-line switch"_Section_start.html#start_7 will
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.
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
@ -174,10 +112,10 @@ pairwise and bonded interactions. However, when running on CPUs, it
will typically be faster to use "half" neighbor lists and set the
Newton flag to "on", just as is the case for non-accelerated pair
styles. It can also be faster to use non-threaded communication. Use
the "-pk kokkos" "command-line switch"_Section_start.html#start_7 to
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:
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
@ -237,10 +175,10 @@ pairwise and bonded interactions. When running on KNL, this will
typically be best for pair-wise potentials. For manybody potentials,
using "half" neighbor lists and setting the Newton flag to "on" may be
faster. It can also be faster to use non-threaded communication. Use
the "-pk kokkos" "command-line switch"_Section_start.html#start_7 to
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:
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
@ -255,16 +193,19 @@ supports.
[Running on GPUs:]
Use the "-k" "command-line switch"_Section_start.html#start_7 to
Use the "-k" "command-line switch"_Run_options.html to
specify the number of GPUs per node. Typically the -np setting of the
mpirun command should set the number of MPI tasks/node to be equal to
the # of physical GPUs on the node. You can assign multiple MPI tasks
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.
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
@ -281,10 +222,10 @@ When running on Maxwell or Kepler GPUs, this will typically be
best. For Pascal GPUs, using "half" neighbor lists and setting the
Newton flag to "on" may be faster. For many pair styles, setting the
neighbor binsize equal to the ghost atom cutoff will give speedup.
Use the "-pk kokkos" "command-line switch"_Section_start.html#start_7
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:
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
@ -315,10 +256,9 @@ kk"_suffix.html commands to your input script.
The discussion above for building LAMMPS with the KOKKOS package, the
mpirun/mpiexec command, and setting appropriate thread are the same.
You must still use the "-k on" "command-line
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 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.
@ -327,7 +267,7 @@ pair_style lj/cut/kk 2.5 :pre
You only need to use the "package kokkos"_package.html command if you
wish to change any of its option defaults, as set by the "-k on"
"command-line switch"_Section_start.html#start_7.
"command-line switch"_Run_options.html.
[Using OpenMP threading and CUDA together (experimental):]
@ -399,50 +339,18 @@ hardware.
[Advanced Kokkos options:]
There are other allowed options when building with the KOKKOS package.
As above, they can be set either as variables on the make command line
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.
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_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

4
doc/src/Speed_measure.txt
View File

@ -21,8 +21,8 @@ typically no need to run for 1000s of timesteps to get accurate
timings; you can simply extrapolate from short runs.
For the set of runs, look at the timing data printed to the screen and
log file at the end of each LAMMPS run. "This
section"_Section_start.html#start_7 of the manual has an overview.
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

65
doc/src/Speed_omp.txt
View File

@ -10,42 +10,32 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
USER-OMP package :h3
The USER-OMP package was developed by Axel Kohlmeyer at Temple
University. It provides multi-threaded versions of most pair styles,
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 on the "Packages
details"_Packages_details.html#USER-OMP doc page.
Note that the CCFLAGS and LINKFLAGS settings in Makefile.machine must
include "-fopenmp". Likewise, if you use an Intel compiler, the
CCFLAGS setting must include "-restrict".
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
@ -57,19 +47,18 @@ threads/task should not exceed the physical number of cores (on a
node), otherwise performance will suffer.
As in the lines above, use the "-sf omp" "command-line
switch"_Section_start.html#start_6, which will automatically append
"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:]

25
doc/src/Speed_opt.txt
View File

@ -15,34 +15,21 @@ Technologies). It contains a handful of pair styles whose compute()
methods were rewritten in C++ templated form to reduce the overhead
due to if tests and other conditional code.
Here is a quick overview of how to use the OPT package. More details
follow.
make yes-opt
make mpi # build with the OPT package :pre
lmp_mpi -sf opt -in in.script # run in serial
mpirun -np 4 lmp_mpi -sf opt -in in.script # run in parallel :pre
[Required hardware/software:]
None.
[Building LAMMPS with the OPT package:]
The lines above illustrate how to build LAMMPS with the OPT package in
two steps, using the "make" command. Or how to do it with one command
as described on the "Packages details"_Packages_details.html#OPT doc
page.
Note that if you use an Intel compiler to build with the OPT package,
the CCFLAGS setting in your Makefile.machine must include "-restrict".
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:]

6
doc/src/Speed_packages.txt
View File

@ -93,11 +93,11 @@ re-build LAMMPS |
make machine |
prepare and test a regular LAMMPS simulation |
lmp_machine -in in.script; mpirun -np 32 lmp_machine -in in.script |
enable specific accelerator support via '-k on' "command-line switch"_Section_start.html#start_6, |
enable specific accelerator support via '-k on' "command-line switch"_Run_options.html, |
only needed for KOKKOS package |
set any needed options for the package via "-pk" "command-line switch"_Section_start.html#start_6 or "package"_package.html command, |
set any needed options for the package via "-pk" "command-line switch"_Run_options.html or "package"_package.html command, |
only if defaults need to be changed |
use accelerated styles in your input via "-sf" "command-line switch"_Section_start.html#start_6 or "suffix"_suffix.html command | lmp_machine -in in.script -sf gpu
use accelerated styles in your input via "-sf" "command-line switch"_Run_options.html or "suffix"_suffix.html command | lmp_machine -in in.script -sf gpu
:tb(c=2,s=|)
Note that the first 4 steps can be done as a single command with

22
doc/src/Speed_tips.txt
View File

@ -9,7 +9,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
General tips :h3
NOTE: this section 5.2 is still a work in progress
NOTE: this page is still a work in progress
Here is a list of general ideas for improving simulation performance.
Most of them are only applicable to certain models and certain
@ -20,13 +20,8 @@ problem size, number of processors used, and your machine. There is
no substitute for identifying performance bottlenecks, and trying out
various options.
make individual pages for these, or one for PPPM
one for timestepping, etc
one for balancing
or proc layout
rRESPA
2-FFT PPPM
Two-FFT PPPM
Staggered PPPM
single vs double PPPM
partial charge PPPM
@ -34,12 +29,13 @@ verlet/split run style
processor command for proc layout and numa layout
load-balancing: balance and fix balance :ul
2-FFT PPPM, also called {analytic differentiation} or {ad} PPPM, uses
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.
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

76
doc/src/Tools.txt
View File

@ -43,39 +43,53 @@ 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 :ul
: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
:line
Tool descriptions :h3
amber2lmp tool :h4,link(amber)

12
doc/src/angle_charmm.txt
View File

@ -57,13 +57,13 @@ produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_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 "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
@ -73,8 +73,8 @@ instructions on how to use the accelerated styles effectively.
[Restrictions:]
This angle style can only be used if LAMMPS was built with the
MOLECULE package. See the "Making
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:]

12
doc/src/angle_class2.txt
View File

@ -89,13 +89,13 @@ produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_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 the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
@ -123,8 +123,8 @@ The bond-bond and bond-angle terms remain unchanged.
This angle style can only be used if LAMMPS was built with the CLASS2
package. For the {class2/p6} style LAMMPS needs to be built with the
USER-MOFFF package. See the "Making LAMMPS"_Section_start.html#start_3
section for more info on packages.
USER-MOFFF package. See the "Build package"_Build_package.html doc
page for more info.
[Related commands:]

12
doc/src/angle_cosine.txt
View File

@ -44,13 +44,13 @@ produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_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 the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
@ -60,8 +60,8 @@ instructions on how to use the accelerated styles effectively.
[Restrictions:]
This angle style can only be used if LAMMPS was built with the
MOLECULE package. See the "Making
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:]

4
doc/src/angle_cosine_buck6d.txt
View File

@ -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:]

12
doc/src/angle_cosine_delta.txt
View File

@ -49,13 +49,13 @@ produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_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 the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
@ -65,8 +65,8 @@ instructions on how to use the accelerated styles effectively.
[Restrictions:]
This angle style can only be used if LAMMPS was built with the
MOLECULE package. See the "Making
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:]

12
doc/src/angle_cosine_periodic.txt
View File

@ -57,13 +57,13 @@ produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_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 the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
@ -73,8 +73,8 @@ instructions on how to use the accelerated styles effectively.
[Restrictions:]
This angle style can only be used if LAMMPS was built with the
MOLECULE package. See the "Making
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:]

11
doc/src/angle_cosine_shift.txt
View File

@ -47,13 +47,13 @@ produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_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 the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
@ -63,8 +63,7 @@ instructions on how to use the accelerated styles effectively.
[Restrictions:]
This angle style can only be used if LAMMPS was built with the
USER-MISC package. See the "Making LAMMPS"_Section_start.html#start_3
section for more info on packages.
USER-MISC package.
[Related commands:]

12
doc/src/angle_cosine_shift_exp.txt
View File

@ -59,13 +59,13 @@ produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_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 the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
@ -75,8 +75,8 @@ instructions on how to use the accelerated styles effectively.
[Restrictions:]
This angle style can only be used if LAMMPS was built with the
USER-MISC package. See the "Making LAMMPS"_Section_start.html#start_3
section for more info on packages.
USER-MISC package. See the "Build package"_Build_package.html doc
page for more info.
[Related commands:]

12
doc/src/angle_cosine_squared.txt
View File

@ -49,13 +49,13 @@ produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_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 the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
@ -65,8 +65,8 @@ instructions on how to use the accelerated styles effectively.
[Restrictions:]
This angle style can only be used if LAMMPS was built with the
MOLECULE package. See the "Making
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:]

12
doc/src/angle_dipole.txt
View File

@ -77,13 +77,13 @@ produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_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 the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
@ -91,8 +91,8 @@ instructions on how to use the accelerated styles effectively.
[Restrictions:]
This angle style can only be used if LAMMPS was built with the
USER-MISC package. See the "Making LAMMPS"_Section_start.html#start_2_3
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'
defining the direction of the dipole vector to restrain must come

12
doc/src/angle_fourier.txt
View File

@ -45,13 +45,13 @@ produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_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 the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
@ -61,8 +61,8 @@ instructions on how to use the accelerated styles effectively.
[Restrictions:]
This angle style can only be used if LAMMPS was built with the
USER_MISC package. See the "Making LAMMPS"_Section_start.html#start_3
section for more info on packages.
USER_MISC package. See the "Build package"_Build_package.html doc
page for more info.
[Related commands:]

12
doc/src/angle_fourier_simple.txt
View File

@ -44,13 +44,13 @@ produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_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 the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
@ -60,8 +60,8 @@ instructions on how to use the accelerated styles effectively.
[Restrictions:]
This angle style can only be used if LAMMPS was built with the
USER_MISC package. See the "Making LAMMPS"_Section_start.html#start_3
section for more info on packages.
USER_MISC package. See the "Build package"_Build_package.html doc
page for more info.
[Related commands:]

12
doc/src/angle_harmonic.txt
View File

@ -51,13 +51,13 @@ produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_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 the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
@ -67,8 +67,8 @@ instructions on how to use the accelerated styles effectively.
[Restrictions:]
This angle style can only be used if LAMMPS was built with the
MOLECULE package. See the "Making LAMMPS"_Section_start.html#start_3
section for more info on packages.
MOLECULE package. See the "Build package"_Build_package.html doc
page for more info.
[Related commands:]

4
doc/src/angle_hybrid.txt
View File

@ -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

12
doc/src/angle_quartic.txt
View File

@ -51,13 +51,13 @@ produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_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 the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
@ -67,8 +67,8 @@ instructions on how to use the accelerated styles effectively.
[Restrictions:]
This angle style can only be used if LAMMPS was built with the
USER_MISC package. See the "Making LAMMPS"_Section_start.html#start_3
section for more info on packages.
USER_MISC package. See the "Build package"_Build_package.html doc
page for more info.
[Related commands:]

4
doc/src/angle_sdk.txt
View File

@ -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:]

7
doc/src/angle_style.txt
View File

@ -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:]

12
doc/src/angle_table.txt
View File

@ -130,13 +130,13 @@ produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_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 the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
@ -146,8 +146,8 @@ instructions on how to use the accelerated styles effectively.
[Restrictions:]
This angle style can only be used if LAMMPS was built with the
MOLECULE package. See the "Making
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:]

6
doc/src/atom_modify.txt
View File

@ -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

12
doc/src/atom_style.txt
View File

@ -272,13 +272,13 @@ USER-INTEL, USER-OMP, and OPT packages do not use accelerated atom
styles.
The accelerated styles are part of the KOKKOS package. They are only
enabled if LAMMPS was built with those packages. See the "Making
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 the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
@ -289,8 +289,8 @@ This command cannot be used after the simulation box is defined by a
"read_data"_read_data.html or "create_box"_create_box.html command.
Many of the styles listed above are only enabled if LAMMPS was built
with a specific package, as listed below. See the "Making
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.

Some files were not shown because too many files have changed in this diff Show More