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

Merge branch 'master' into kim-v2-update

This commit is contained in:
Ryan S. Elliott 2018-08-18 12:23:19 -05:00
parent 7aa7002347 6c5d339a94
commit d0667d21cc
812 changed files with 22873 additions and 20117 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
.github/CODEOWNERS vendored
View File

@ -17,6 +17,7 @@ src/GPU/* @ndtrung81
src/KOKKOS/* @stanmoore1
src/KIM/* @ellio167
src/LATTE/* @cnegre
src/SPIN/* @julient31
src/USER-CGDNA/* @ohenrich
src/USER-CGSDK/* @akohlmey
src/USER-COLVARS/* @giacomofiorin
@ -44,6 +45,7 @@ src/USER-MISC/*_grem.* @dstelter92
# tools
tools/msi2lmp/* @akohlmey
tools/emacs/* @HaoZeke
# cmake
cmake/* @junghans @rbberger

363
cmake/CMakeLists.txt
View File

@ -9,6 +9,7 @@ set(SOVERSION 0)
get_filename_component(LAMMPS_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../src ABSOLUTE)
get_filename_component(LAMMPS_LIB_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../lib ABSOLUTE)
get_filename_component(LAMMPS_LIB_BINARY_DIR ${CMAKE_BINARY_DIR}/lib ABSOLUTE)
get_filename_component(LAMMPS_DOC_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../doc ABSOLUTE)
# To avoid conflicts with the conventional Makefile build system, we build everything here
@ -16,6 +17,32 @@ file(GLOB LIB_SOURCES ${LAMMPS_SOURCE_DIR}/*.cpp)
file(GLOB LMP_SOURCES ${LAMMPS_SOURCE_DIR}/main.cpp)
list(REMOVE_ITEM LIB_SOURCES ${LMP_SOURCES})
# Utility functions
function(list_to_bulletpoints result)
list(REMOVE_AT ARGV 0)
set(temp "")
foreach(item ${ARGV})
set(temp "${temp}* ${item}\n")
endforeach()
set(${result} "${temp}" PARENT_SCOPE)
endfunction(list_to_bulletpoints)
function(validate_option name values)
string(TOLOWER ${${name}} needle_lower)
string(TOUPPER ${${name}} needle_upper)
list(FIND ${values} ${needle_lower} IDX_LOWER)
list(FIND ${values} ${needle_upper} IDX_UPPER)
if(${IDX_LOWER} LESS 0 AND ${IDX_UPPER} LESS 0)
list_to_bulletpoints(POSSIBLE_VALUE_LIST ${${values}})
message(FATAL_ERROR "\n########################################################################\n"
"Invalid value '${${name}}' for option ${name}\n"
"\n"
"Possible values are:\n"
"${POSSIBLE_VALUE_LIST}"
"########################################################################")
endif()
endfunction(validate_option)
# Cmake modules/macros are in a subdirectory to keep this file cleaner
set(CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR}/Modules)
@ -105,8 +132,6 @@ if(NOT BUILD_EXE AND NOT BUILD_LIB)
message(FATAL_ERROR "You need to at least enable one of two following options: BUILD_LIB or BUILD_EXE")
endif()
option(DEVELOPER_MODE "Enable developer mode" OFF)
mark_as_advanced(DEVELOPER_MODE)
option(CMAKE_VERBOSE_MAKEFILE "Generate verbose Makefiles" OFF)
include(GNUInstallDirs)
@ -132,13 +157,22 @@ else()
list(APPEND LAMMPS_LINK_LIBS mpi_stubs)
endif()
set(LAMMPS_SIZE_LIMIT "LAMMPS_SMALLBIG" CACHE STRING "Lammps size limit")
set_property(CACHE LAMMPS_SIZE_LIMIT PROPERTY STRINGS LAMMPS_SMALLBIG LAMMPS_BIGBIG LAMMPS_SMALLSMALL)
add_definitions(-D${LAMMPS_SIZE_LIMIT})
set(LAMMPS_API_DEFINES "${LAMMPS_API_DEFINES} -D${LAMMPS_SIZE_LIMIT}")
set(LAMMPS_MEMALIGN "64" CACHE STRING "enables the use of the posix_memalign() call instead of malloc() when large chunks or memory are allocated by LAMMPS")
add_definitions(-DLAMMPS_MEMALIGN=${LAMMPS_MEMALIGN})
set(LAMMPS_SIZES "smallbig" CACHE STRING "LAMMPS size limit")
set(LAMMPS_SIZES_VALUES smallbig bigbig smallsmall)
set_property(CACHE LAMMPS_SIZES PROPERTY STRINGS ${LAMMPS_SIZES_VALUES})
validate_option(LAMMPS_SIZES LAMMPS_SIZES_VALUES)
string(TOUPPER ${LAMMPS_SIZES} LAMMPS_SIZES)
add_definitions(-DLAMMPS_${LAMMPS_SIZES})
set(LAMMPS_API_DEFINES "${LAMMPS_API_DEFINES} -DLAMMPS_${LAMMPS_SIZES}")
# posix_memalign is not available on Windows
if(NOT ${CMAKE_SYSTEM_NAME} STREQUAL "Windows")
set(LAMMPS_MEMALIGN "64" CACHE STRING "enables the use of the posix_memalign() call instead of malloc() when large chunks or memory are allocated by LAMMPS. Set to 0 to disable")
if(NOT ${LAMMPS_MEMALIGN} STREQUAL "0")
add_definitions(-DLAMMPS_MEMALIGN=${LAMMPS_MEMALIGN})
endif()
endif()
option(LAMMPS_EXCEPTIONS "enable the use of C++ exceptions for error messages (useful for library interface)" OFF)
if(LAMMPS_EXCEPTIONS)
@ -153,14 +187,15 @@ if(ENABLE_TESTING)
enable_testing()
endif(ENABLE_TESTING)
set(DEFAULT_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE GRANULAR
KSPACE MANYBODY MC MEAM MISC MOLECULE PERI QEQ REAX REPLICA RIGID SHOCK SPIN SNAP
set(DEFAULT_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS DIPOLE GRANULAR
KSPACE MANYBODY MC MEAM MISC MOLECULE PERI REAX REPLICA RIGID SHOCK SPIN SNAP
SRD KIM PYTHON MSCG MPIIO VORONOI POEMS LATTE USER-ATC USER-AWPMD USER-BOCS
USER-CGDNA USER-MESO USER-CGSDK USER-COLVARS USER-DIFFRACTION USER-DPD USER-DRUDE
USER-EFF USER-FEP USER-H5MD USER-LB USER-MANIFOLD USER-MEAMC USER-MGPT USER-MISC
USER-MOFFF USER-MOLFILE USER-NETCDF USER-PHONON USER-QTB USER-REAXC USER-SMD
USER-SMTBQ USER-SPH USER-TALLY USER-UEF USER-VTK USER-QUIP USER-QMMM)
set(ACCEL_PACKAGES USER-OMP KOKKOS OPT USER-INTEL GPU)
set(OTHER_PACKAGES CORESHELL QEQ)
foreach(PKG ${DEFAULT_PACKAGES})
option(PKG_${PKG} "Build ${PKG} Package" OFF)
endforeach()
@ -174,13 +209,12 @@ macro(pkg_depends PKG1 PKG2)
endif()
endmacro()
# "hard" dependencies between packages resulting
# in an error instead of skipping over files
pkg_depends(MPIIO MPI)
pkg_depends(QEQ MANYBODY)
pkg_depends(USER-ATC MANYBODY)
pkg_depends(USER-LB MPI)
pkg_depends(USER-MISC MANYBODY)
pkg_depends(USER-PHONON KSPACE)
pkg_depends(CORESHELL KSPACE)
######################################################
# packages with special compiler needs or external libs
@ -212,10 +246,13 @@ if(PKG_KSPACE)
if(${FFTW}_FOUND)
set(FFT "${FFTW}" CACHE STRING "FFT library for KSPACE package")
else()
set(FFT "KISSFFT" CACHE STRING "FFT library for KSPACE package")
set(FFT "KISS" CACHE STRING "FFT library for KSPACE package")
endif()
set_property(CACHE FFT PROPERTY STRINGS KISSFFT ${FFTW} MKL)
if(NOT FFT STREQUAL "KISSFFT")
set(FFT_VALUES KISS ${FFTW} MKL)
set_property(CACHE FFT PROPERTY STRINGS ${FFT_VALUES})
validate_option(FFT FFT_VALUES)
string(TOUPPER ${FFT} FFT)
if(NOT FFT STREQUAL "KISS")
find_package(${FFT} REQUIRED)
if(NOT FFT STREQUAL "FFTW3F")
add_definitions(-DFFT_FFTW)
@ -224,11 +261,16 @@ if(PKG_KSPACE)
endif()
include_directories(${${FFT}_INCLUDE_DIRS})
list(APPEND LAMMPS_LINK_LIBS ${${FFT}_LIBRARIES})
else()
add_definitions(-DFFT_KISS)
endif()
set(PACK_OPTIMIZATION "PACK_ARRAY" CACHE STRING "Optimization for FFT")
set_property(CACHE PACK_OPTIMIZATION PROPERTY STRINGS PACK_ARRAY PACK_POINTER PACK_MEMCPY)
if(NOT PACK_OPTIMIZATION STREQUAL "PACK_ARRAY")
add_definitions(-D${PACK_OPTIMIZATION})
set(FFT_PACK "array" CACHE STRING "Optimization for FFT")
set(FFT_PACK_VALUES array pointer memcpy)
set_property(CACHE FFT_PACK PROPERTY STRINGS ${FFT_PACK_VALUES})
validate_option(FFT_PACK FFT_PACK_VALUES)
if(NOT FFT_PACK STREQUAL "array")
string(TOUPPER ${FFT_PACK} FFT_PACK)
add_definitions(-DFFT_PACK_${FFT_PACK})
endif()
endif()
@ -306,10 +348,17 @@ if(PKG_VORONOI)
option(DOWNLOAD_VORO "Download voro++ (instead of using the system's one)" OFF)
if(DOWNLOAD_VORO)
include(ExternalProject)
if(BUILD_SHARED_LIBS)
set(VORO_BUILD_OPTIONS "CFLAGS=-fPIC")
else()
set(VORO_BUILD_OPTIONS)
endif()
ExternalProject_Add(voro_build
URL http://math.lbl.gov/voro++/download/dir/voro++-0.4.6.tar.gz
URL_MD5 2338b824c3b7b25590e18e8df5d68af9
CONFIGURE_COMMAND "" BUILD_IN_SOURCE 1 INSTALL_COMMAND ""
CONFIGURE_COMMAND "" BUILD_COMMAND make ${VORO_BUILD_OPTIONS} BUILD_IN_SOURCE 1 INSTALL_COMMAND ""
)
ExternalProject_get_property(voro_build SOURCE_DIR)
set(VORO_LIBRARIES ${SOURCE_DIR}/src/libvoro++.a)
@ -332,7 +381,7 @@ if(PKG_LATTE)
include(ExternalProject)
ExternalProject_Add(latte_build
URL https://github.com/lanl/LATTE/archive/v1.2.1.tar.gz
URL_MD5 bed76e7e76c545c36dd848a8f1fd35eb
URL_MD5 85ac414fdada2d04619c8f936344df14
SOURCE_SUBDIR cmake
CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=<INSTALL_DIR> -DCMAKE_POSITION_INDEPENDENT_CODE=${CMAKE_POSITION_INDEPENDENT_CODE}
)
@ -363,11 +412,11 @@ 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
URL http://bitbucket.org/eigen/eigen/get/3.3.4.tar.gz
URL_MD5 1a47e78efe365a97de0c022d127607c3
CONFIGURE_COMMAND "" BUILD_COMMAND "" INSTALL_COMMAND ""
)
@ -377,7 +426,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})
@ -407,14 +456,14 @@ if(PKG_KIM)
if(DOWNLOAD_KIM)
include(ExternalProject)
ExternalProject_Add(kim_build
URL https://github.com/openkim/kim-api/archive/v2.0.0-beta.1.tar.gz
URL_MD5 633e331cc7942c1f0462da71f41f94be
URL https://github.com/openkim/kim-api/archive/v1.9.5.tar.gz
URL_MD5 9f66efc128da33039e30659f36fc6d00
BUILD_IN_SOURCE 1
CONFIGURE_COMMAND <SOURCE_DIR>/configure --prefix=<INSTALL_DIR>
)
ExternalProject_get_property(kim_build INSTALL_DIR)
set(KIM_INCLUDE_DIRS ${INSTALL_DIR}/include/kim-api-v2)
set(KIM_LIBRARIES ${INSTALL_DIR}/lib/libkim-api-v2.so)
set(KIM_INCLUDE_DIRS ${INSTALL_DIR}/include/kim-api-v1)
set(KIM_LIBRARIES ${INSTALL_DIR}/lib/libkim-api-v1.so)
list(APPEND LAMMPS_DEPS kim_build)
else()
find_package(KIM)
@ -466,6 +515,11 @@ if(PKG_COMPRESS)
list(APPEND LAMMPS_LINK_LIBS ${ZLIB_LIBRARIES})
endif()
# the windows version of LAMMPS requires a couple extra libraries
if(${CMAKE_SYSTEM_NAME} STREQUAL "Windows")
list(APPEND LAMMPS_LINK_LIBS -lwsock32 -lpsapi)
endif()
########################################################################
# Basic system tests (standard libraries, headers, functions, types) #
########################################################################
@ -483,12 +537,13 @@ include(CheckLibraryExists)
if (CMAKE_VERSION VERSION_LESS "3.4")
enable_language(C) # check_library_exists isn't supported without a c compiler before v3.4
endif()
foreach(FUNC sin cos)
check_library_exists(${MATH_LIBRARIES} ${FUNC} "" FOUND_${FUNC}_${MATH_LIBRARIES})
if(NOT FOUND_${FUNC}_${MATH_LIBRARIES})
message(FATAL_ERROR "Could not find needed math function - ${FUNC}")
endif(NOT FOUND_${FUNC}_${MATH_LIBRARIES})
endforeach(FUNC)
# RB: disabled this check because it breaks with KOKKOS CUDA enabled
#foreach(FUNC sin cos)
# check_library_exists(${MATH_LIBRARIES} ${FUNC} "" FOUND_${FUNC}_${MATH_LIBRARIES})
# if(NOT FOUND_${FUNC}_${MATH_LIBRARIES})
# message(FATAL_ERROR "Could not find needed math function - ${FUNC}")
# endif(NOT FOUND_${FUNC}_${MATH_LIBRARIES})
#endforeach(FUNC)
list(APPEND LAMMPS_LINK_LIBS ${MATH_LIBRARIES})
######################################
@ -574,6 +629,41 @@ endif()
# packages which selectively include variants based on enabled styles
# e.g. accelerator packages
######################################################################
if(PKG_CORESHELL)
set(CORESHELL_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/CORESHELL)
set(CORESHELL_SOURCES)
set_property(GLOBAL PROPERTY "CORESHELL_SOURCES" "${CORESHELL_SOURCES}")
# detects styles which have a CORESHELL version
RegisterStylesExt(${CORESHELL_SOURCES_DIR} cs CORESHELL_SOURCES)
get_property(CORESHELL_SOURCES GLOBAL PROPERTY CORESHELL_SOURCES)
list(APPEND LIB_SOURCES ${CORESHELL_SOURCES})
include_directories(${CORESHELL_SOURCES_DIR})
endif()
# Fix qeq/fire requires MANYBODY (i.e. COMB and COMB3) to be installed
if(PKG_QEQ)
set(QEQ_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/QEQ)
file(GLOB QEQ_HEADERS ${QEQ_SOURCES_DIR}/fix*.h)
file(GLOB QEQ_SOURCES ${QEQ_SOURCES_DIR}/fix*.cpp)
if(NOT PKG_MANYBODY)
list(REMOVE_ITEM QEQ_HEADERS ${QEQ_SOURCES_DIR}/fix_qeq_fire.h)
list(REMOVE_ITEM QEQ_SOURCES ${QEQ_SOURCES_DIR}/fix_qeq_fire.cpp)
endif()
set_property(GLOBAL PROPERTY "QEQ_SOURCES" "${QEQ_SOURCES}")
foreach(MY_HEADER ${QEQ_HEADERS})
AddStyleHeader(${MY_HEADER} FIX)
endforeach()
get_property(QEQ_SOURCES GLOBAL PROPERTY QEQ_SOURCES)
list(APPEND LIB_SOURCES ${QEQ_SOURCES})
include_directories(${QEQ_SOURCES_DIR})
endif()
if(PKG_USER-OMP)
set(USER-OMP_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/USER-OMP)
set(USER-OMP_SOURCES ${USER-OMP_SOURCES_DIR}/thr_data.cpp
@ -585,8 +675,31 @@ if(PKG_USER-OMP)
# detects styles which have USER-OMP version
RegisterStylesExt(${USER-OMP_SOURCES_DIR} omp OMP_SOURCES)
get_property(USER-OMP_SOURCES GLOBAL PROPERTY OMP_SOURCES)
# manually add package dependent source files from USER-OMP that do not provide styles
if(PKG_ASPHERE)
list(APPEND USER-OMP_SOURCES ${USER-OMP_SOURCES_DIR}/fix_nh_asphere_omp.cpp)
endif()
if(PKG_RIGID)
list(APPEND USER-OMP_SOURCES ${USER-OMP_SOURCES_DIR}/fix_rigid_nh_omp.cpp)
endif()
if(PKG_USER-REAXC)
list(APPEND USER-OMP_SOURCES ${USER-OMP_SOURCES_DIR}/reaxc_bond_orders_omp.cpp
${USER-OMP_SOURCES_DIR}/reaxc_hydrogen_bonds_omp.cpp
${USER-OMP_SOURCES_DIR}/reaxc_nonbonded_omp.cpp
${USER-OMP_SOURCES_DIR}/reaxc_bonds_omp.cpp
${USER-OMP_SOURCES_DIR}/reaxc_init_md_omp.cpp
${USER-OMP_SOURCES_DIR}/reaxc_torsion_angles_omp.cpp
${USER-OMP_SOURCES_DIR}/reaxc_forces_omp.cpp
${USER-OMP_SOURCES_DIR}/reaxc_multi_body_omp.cpp
${USER-OMP_SOURCES_DIR}/reaxc_valence_angles_omp.cpp)
endif()
list(APPEND LIB_SOURCES ${USER-OMP_SOURCES})
include_directories(${USER-OMP_SOURCES_DIR})
endif()
@ -618,6 +731,11 @@ if(PKG_KOKKOS)
${KOKKOS_PKG_SOURCES_DIR}/npair_kokkos.cpp
${KOKKOS_PKG_SOURCES_DIR}/domain_kokkos.cpp
${KOKKOS_PKG_SOURCES_DIR}/modify_kokkos.cpp)
if(PKG_KSPACE)
list(APPEND KOKKOS_PKG_SOURCES ${KOKKOS_PKG_SOURCES_DIR}/gridcomm_kokkos.cpp)
endif()
set_property(GLOBAL PROPERTY "KOKKOS_PKG_SOURCES" "${KOKKOS_PKG_SOURCES}")
# detects styles which have KOKKOS version
@ -655,33 +773,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
@ -706,7 +846,7 @@ if(PKG_USER-INTEL)
endif()
if(PKG_GPU)
if (CMAKE_VERSION VERSION_LESS "3.1")
if (CMAKE_VERSION VERSION_LESS "3.1")
message(FATAL_ERROR "For the GPU package you need at least cmake-3.1")
endif()
set(GPU_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/GPU)
@ -714,11 +854,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)
@ -731,7 +885,7 @@ if(PKG_GPU)
endif()
option(CUDPP_OPT "Enable CUDPP_OPT" ON)
set(GPU_ARCH "sm_30" CACHE STRING "LAMMPS GPU CUDA SM architecture (e.g. sm_60)")
set(GPU_ARCH "sm_30" CACHE STRING "LAMMPS GPU CUDA SM architecture (e.g. sm_60)")
file(GLOB GPU_LIB_CU ${LAMMPS_LIB_SOURCE_DIR}/gpu/*.cu ${CMAKE_CURRENT_SOURCE_DIR}/gpu/*.cu)
list(REMOVE_ITEM GPU_LIB_CU ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_pppm.cu)
@ -745,10 +899,10 @@ if(PKG_GPU)
endif()
cuda_compile_cubin(GPU_GEN_OBJS ${GPU_LIB_CU} OPTIONS
-DUNIX -O3 -Xptxas -v --use_fast_math -DNV_KERNEL -DUCL_CUDADR -arch=${GPU_ARCH} -D_${GPU_PREC})
-DUNIX -O3 -Xptxas -v --use_fast_math -DNV_KERNEL -DUCL_CUDADR -arch=${GPU_ARCH} -D_${GPU_PREC_SETTING})
cuda_compile(GPU_OBJS ${GPU_LIB_CUDPP_CU} OPTIONS $<$<BOOL:${BUILD_SHARED_LIBS}>:-Xcompiler=-fPIC>
-DUNIX -O3 -Xptxas -v --use_fast_math -DUCL_CUDADR -arch=${GPU_ARCH} -D_${GPU_PREC})
-DUNIX -O3 -Xptxas -v --use_fast_math -DUCL_CUDADR -arch=${GPU_ARCH} -D_${GPU_PREC_SETTING})
foreach(CU_OBJ ${GPU_GEN_OBJS})
get_filename_component(CU_NAME ${CU_OBJ} NAME_WE)
@ -765,7 +919,7 @@ if(PKG_GPU)
add_library(gpu STATIC ${GPU_LIB_SOURCES} ${GPU_LIB_CUDPP_SOURCES} ${GPU_OBJS})
target_link_libraries(gpu ${CUDA_LIBRARIES} ${CUDA_CUDA_LIBRARY})
target_include_directories(gpu PRIVATE ${LAMMPS_LIB_BINARY_DIR}/gpu ${CUDA_INCLUDE_DIRS})
target_compile_definitions(gpu PRIVATE -D_${GPU_PREC} -DMPI_GERYON -DUCL_NO_EXIT)
target_compile_definitions(gpu PRIVATE -D_${GPU_PREC_SETTING} -DMPI_GERYON -DUCL_NO_EXIT)
if(CUDPP_OPT)
target_include_directories(gpu PRIVATE ${LAMMPS_LIB_SOURCE_DIR}/gpu/cudpp_mini)
target_compile_definitions(gpu PRIVATE -DUSE_CUDPP)
@ -779,10 +933,13 @@ if(PKG_GPU)
target_include_directories(nvc_get_devices PRIVATE ${CUDA_INCLUDE_DIRS})
elseif(GPU_API STREQUAL "OpenCL")
elseif(GPU_API STREQUAL "OPENCL")
find_package(OpenCL REQUIRED)
set(OCL_TUNE "GENERIC" CACHE STRING "OpenCL Device Tuning")
set_property(CACHE OCL_TUNE PROPERTY STRINGS INTEL FERMI KEPLER CYPRESS GENERIC)
set(OCL_TUNE "generic" CACHE STRING "OpenCL Device Tuning")
set(OCL_TUNE_VALUES intel fermi kepler cypress generic)
set_property(CACHE OCL_TUNE PROPERTY STRINGS ${OCL_TUNE_VALUES})
validate_option(OCL_TUNE OCL_TUNE_VALUES)
string(TOUPPER ${OCL_TUNE} OCL_TUNE)
include(OpenCLUtils)
set(OCL_COMMON_HEADERS ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_preprocessor.h ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_aux_fun1.h)
@ -804,7 +961,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)
@ -892,7 +1049,7 @@ if(BUILD_EXE)
add_dependencies(lmp ${LAMMPS_DEPS})
endif()
endif()
set_target_properties(lmp PROPERTIES OUTPUT_NAME lmp${LAMMPS_MACHINE})
install(TARGETS lmp DESTINATION ${CMAKE_INSTALL_BINDIR})
if(ENABLE_TESTING)
@ -900,6 +1057,80 @@ if(BUILD_EXE)
endif()
endif()
###############################################################################
# Build documentation
###############################################################################
option(BUILD_DOC "Build LAMMPS documentation" OFF)
if(BUILD_DOC)
include(ProcessorCount)
ProcessorCount(NPROCS)
find_package(PythonInterp 3 REQUIRED)
set(VIRTUALENV ${PYTHON_EXECUTABLE} -m virtualenv)
file(GLOB DOC_SOURCES ${LAMMPS_DOC_DIR}/src/*.txt)
file(GLOB PDF_EXTRA_SOURCES ${LAMMPS_DOC_DIR}/src/lammps_commands*.txt ${LAMMPS_DOC_DIR}/src/lammps_support.txt ${LAMMPS_DOC_DIR}/src/lammps_tutorials.txt)
list(REMOVE_ITEM DOC_SOURCES ${PDF_EXTRA_SOURCES})
add_custom_command(
OUTPUT docenv
COMMAND ${VIRTUALENV} docenv
)
set(DOCENV_BINARY_DIR ${CMAKE_BINARY_DIR}/docenv/bin)
add_custom_command(
OUTPUT requirements.txt
DEPENDS docenv
COMMAND ${CMAKE_COMMAND} -E copy ${LAMMPS_DOC_DIR}/utils/requirements.txt requirements.txt
COMMAND ${DOCENV_BINARY_DIR}/pip install -r requirements.txt --upgrade
COMMAND ${DOCENV_BINARY_DIR}/pip install --upgrade ${LAMMPS_DOC_DIR}/utils/converters
)
set(RST_FILES "")
set(RST_DIR ${CMAKE_BINARY_DIR}/rst)
file(MAKE_DIRECTORY ${RST_DIR})
foreach(TXT_FILE ${DOC_SOURCES})
get_filename_component(FILENAME ${TXT_FILE} NAME_WE)
set(RST_FILE ${RST_DIR}/${FILENAME}.rst)
list(APPEND RST_FILES ${RST_FILE})
add_custom_command(
OUTPUT ${RST_FILE}
DEPENDS requirements.txt docenv ${TXT_FILE}
COMMAND ${DOCENV_BINARY_DIR}/txt2rst -o ${RST_DIR} ${TXT_FILE}
)
endforeach()
add_custom_command(
OUTPUT html
DEPENDS ${RST_FILES}
COMMAND ${CMAKE_COMMAND} -E copy_directory ${LAMMPS_DOC_DIR}/src ${RST_DIR}
COMMAND ${DOCENV_BINARY_DIR}/sphinx-build -j ${NPROCS} -b html -c ${LAMMPS_DOC_DIR}/utils/sphinx-config -d ${CMAKE_BINARY_DIR}/doctrees ${RST_DIR} html
)
add_custom_target(
doc ALL
DEPENDS html
SOURCES ${LAMMPS_DOC_DIR}/utils/requirements.txt ${DOC_SOURCES}
)
install(DIRECTORY ${CMAKE_BINARY_DIR}/html DESTINATION ${CMAKE_INSTALL_DOCDIR})
endif()
###############################################################################
# Install potential files in data directory
###############################################################################
set(LAMMPS_POTENTIALS_DIR ${CMAKE_INSTALL_FULL_DATADIR}/lammps/potentials)
install(DIRECTORY ${LAMMPS_SOURCE_DIR}/../potentials DESTINATION ${CMAKE_INSTALL_DATADIR}/lammps/potentials)
configure_file(etc/profile.d/lammps.sh.in ${CMAKE_BINARY_DIR}/etc/profile.d/lammps.sh @ONLY)
configure_file(etc/profile.d/lammps.csh.in ${CMAKE_BINARY_DIR}/etc/profile.d/lammps.csh @ONLY)
install(
FILES ${CMAKE_BINARY_DIR}/etc/profile.d/lammps.sh
${CMAKE_BINARY_DIR}/etc/profile.d/lammps.csh
DESTINATION ${CMAKE_INSTALL_SYSCONFDIR}/profile.d
)
###############################################################################
# Testing
#
@ -954,14 +1185,14 @@ message(STATUS "<<< Build configuration >>>
get_property(LANGUAGES GLOBAL PROPERTY ENABLED_LANGUAGES)
list (FIND LANGUAGES "Fortran" _index)
if (${_index} GREATER -1)
message(STATUS "Fortran Compiler ${CMAKE_Fortran_COMPILER}
message(STATUS "Fortran Compiler ${CMAKE_Fortran_COMPILER}
Type ${CMAKE_Fortran_COMPILER_ID}
Version ${CMAKE_Fortran_COMPILER_VERSION}
Fortran Flags ${CMAKE_Fortran_FLAGS} ${CMAKE_Fortran_FLAGS_${BTYPE}}")
endif()
list (FIND LANGUAGES "C" _index)
if (${_index} GREATER -1)
message(STATUS "C Compiler ${CMAKE_C_COMPILER}
message(STATUS "C Compiler ${CMAKE_C_COMPILER}
Type ${CMAKE_C_COMPILER_ID}
Version ${CMAKE_C_COMPILER_VERSION}
C Flags ${CMAKE_C_FLAGS} ${CMAKE_C_FLAGS_${BTYPE}}")
@ -983,7 +1214,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,16 @@ cmake -C ../cmake/presets/std_nolib.cmake ../cmake -DPKG_GPU=on
</dl>
</td>
</tr>
<tr>
<td><code>BUILD_LIB</code></td>
<td>control whether to build LAMMPS as a library</td>
<td>
<dl>
<dt><code>off</code> (default)</dt>
<dt><code>on</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>BUILD_SHARED_LIBS</code></td>
<td>control whether to build LAMMPS as a shared-library</td>
@ -275,6 +285,16 @@ cmake -C ../cmake/presets/std_nolib.cmake ../cmake -DPKG_GPU=on
</dl>
</td>
</tr>
<tr>
<td><code>BUILD_DOC</code></td>
<td>control whether to build LAMMPS documentation</td>
<td>
<dl>
<dt><code>off</code> (default)</dt>
<dt><code>on</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>LAMMPS_LONGLONG_TO_LONG</code></td>
<td>Workaround if your system or MPI version does not recognize <code>long long</code> data types</td>
@ -305,8 +325,8 @@ cmake -C ../cmake/presets/std_nolib.cmake ../cmake -DPKG_GPU=on
`mpicxx` in your path and use this MPI implementation.</td>
<td>
<dl>
<dt><code>off</code> (default)</dt>
<dt><code>on</code></dt>
<dt><code>on</code> (default, if found)</dt>
<dt><code>off</code></dt>
</dl>
</td>
</tr>
@ -315,8 +335,8 @@ cmake -C ../cmake/presets/std_nolib.cmake ../cmake -DPKG_GPU=on
<td>control whether to build LAMMPS with OpenMP support.</td>
<td>
<dl>
<dt><code>off</code> (default)</dt>
<dt><code>on</code></dt>
<dt><code>on</code> (default, if found)</dt>
<dt><code>off</code></dt>
</dl>
</td>
</tr>
@ -1261,7 +1281,7 @@ providing the identical features and USER interface.</strong></p>
</td>
<td>
<dl>
<dt><code>KISSFFT</code></dt>
<dt><code>KISS</code></dt>
<dt><code>FFTW3</code></dt>
<dt><code>FFTW2</code></dt>
<dt><code>MKL</code></dt>
@ -1269,13 +1289,13 @@ providing the identical features and USER interface.</strong></p>
</td>
</tr>
<tr>
<td><code>PACK_ARRAY</code></td>
<td><code>FFT_PACK</code></td>
<td>Optimization for FFT</td>
<td>
<dl>
<dt><code>PACK_ARRAY</code></dt>
<dt><code>PACK_POINTER</code></dt>
<dt><code>PACK_MEMCPY</code></dt>
<dt><code>array (default)</code></dt>
<dt><code>pointer</code></dt>
<dt><code>memcpy</code></dt>
</dl>
</td>
</tr>
@ -1367,6 +1387,29 @@ TODO
### PYTHON Package
### USER-INTEL Package
<table>
<thead>
<tr>
<th>Option</th>
<th>Description</th>
<th>Values</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>INTEL_ARCH</code></td>
<td>Target architecture for USER-INTEL package</td>
<td>
<dl>
<dt><code>cpu</code> (default)</dt>
<dt><code>knl</code></dt>
</dl>
</td>
</tr>
</tbody>
</table>
### GPU Package
The GPU package builds a support library which can either use OpenCL or CUDA as
@ -1386,8 +1429,8 @@ target API.
<td>API used by GPU package</td>
<td>
<dl>
<dt><code>OpenCL</code> (default)</dt>
<dt><code>CUDA</code></dt>
<dt><code>opencl</code> (default)</dt>
<dt><code>cuda</code></dt>
</dl>
</td>
</tr>
@ -1396,9 +1439,9 @@ target API.
<td>Precision size used by GPU package kernels</td>
<td>
<dl>
<dt><code>SINGLE_DOUBLE</code></dt>
<dt><code>SINGLE_SINGLE</code></dt>
<dt><code>DOUBLE_DOUBLE</code></dt>
<dt><code>mixed</code> (default)</dt>
<dt><code>single</code></dt>
<dt><code>double</code></dt>
</dl>
</td>
</tr>
@ -1407,12 +1450,12 @@ target API.
<td>Tuning target for OpenCL driver code</td>
<td>
<dl>
<dt><code>GENERIC</code> (default)</dt>
<dt><code>INTEL</code> (Intel CPU)</dt>
<dt><code>PHI</code> (Intel Xeon Phi)</dt>
<dt><code>FERMI</code> (NVIDIA)</dt>
<dt><code>KEPLER</code> (NVIDIA)</dt>
<dt><code>CYPRESS</code> (AMD)</dt>
<dt><code>generic</code> (default)</dt>
<dt><code>intel</code> (Intel CPU)</dt>
<dt><code>phi</code> (Intel Xeon Phi)</dt>
<dt><code>fermi</code> (NVIDIA)</dt>
<dt><code>kepler</code> (NVIDIA)</dt>
<dt><code>cypress</code> (AMD)</dt>
</dl>
</td>
</tr>
@ -1507,6 +1550,16 @@ Requires a Eigen3 installation
</tr>
</thead>
<tbody>
<tr>
<td><code>WITH_JPEG</code></td>
<td>Enables/Disable JPEG support in LAMMPS</td>
<td>
<dl>
<dt><code>yes</code> (default, if found)</dt>
<dt><code>no</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>JPEG_INCLUDE_DIR</code></td>
<td></td>
@ -1534,6 +1587,16 @@ Requires a Eigen3 installation
</tr>
</thead>
<tbody>
<tr>
<td><code>WITH_PNG</code></td>
<td>Enables/Disable PNG support in LAMMPS</td>
<td>
<dl>
<dt><code>yes</code> (default, if found)</dt>
<dt><code>no</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>PNG_INCLUDE_DIR</code></td>
<td></td>
@ -1562,6 +1625,16 @@ requires `gzip` to be in your `PATH`
</tr>
</thead>
<tbody>
<tr>
<td><code>WITH_GZIP</code></td>
<td>Enables/Disable GZIP support in LAMMPS</td>
<td>
<dl>
<dt><code>yes</code> (default, if found)</dt>
<dt><code>no</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>GZIP_EXECUTABLE</code></td>
<td></td>
@ -1584,6 +1657,16 @@ requires `ffmpeg` to be in your `PATH`
</tr>
</thead>
<tbody>
<tr>
<td><code>WITH_FFMPEG</code></td>
<td>Enables/Disable FFMPEG support in LAMMPS</td>
<td>
<dl>
<dt><code>yes</code> (default, if found)</dt>
<dt><code>no</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>FFMPEG_EXECUTABLE</code></td>
<td></td>
@ -1596,8 +1679,13 @@ requires `ffmpeg` to be in your `PATH`
## Compilers
By default, `cmake` will use your environment C/C++/Fortran compilers for a build. It uses the `CC`, `CXX` and `FC` environment variables to detect which compilers should be used. However, these values
will be cached after the first run of `cmake`. Subsequent runs of `cmake` will ignore changes in these environment variables. To ensure the correct values are used you avoid the cache by setting the `CMAKE_C_COMPILER`, `CMAKE_CXX_COMPILER`, `CMAKE_Fortran_COMPILER` options directly.
By default, `cmake` will use your environment C/C++/Fortran compilers for a
build. It uses the `CC`, `CXX` and `FC` environment variables to detect which
compilers should be used. However, these values will be cached after the first
run of `cmake`. Subsequent runs of `cmake` will ignore changes in these
environment variables. To ensure the correct values are used you avoid the
cache by setting the `CMAKE_C_COMPILER`, `CMAKE_CXX_COMPILER`,
`CMAKE_Fortran_COMPILER` options directly.
<table>
<thead>
@ -1633,20 +1721,20 @@ will be cached after the first run of `cmake`. Subsequent runs of `cmake` will i
### Building with GNU Compilers
```bash
cmake ../cmake -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ -DCMAKE_Fortran_COMPILER=gfortran
cmake -D CMAKE_C_COMPILER=gcc -D CMAKE_CXX_COMPILER=g++ -D CMAKE_Fortran_COMPILER=gfortran ../cmake
```
### Building with Intel Compilers
```bash
cmake ../cmake -DCMAKE_C_COMPILER=icc -DCMAKE_CXX_COMPILER=icpc -DCMAKE_Fortran_COMPILER=ifort
cmake -D CMAKE_C_COMPILER=icc -D CMAKE_CXX_COMPILER=icpc -D CMAKE_Fortran_COMPILER=ifort ../cmake
```
### Building with LLVM/Clang Compilers
```bash
cmake ../cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_Fortran_COMPILER=flang
cmake -D CMAKE_C_COMPILER=clang -D CMAKE_CXX_COMPILER=clang++ -D CMAKE_Fortran_COMPILER=flang ../cmake
```

2
cmake/etc/profile.d/lammps.csh.in Normal file
View File

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

2
cmake/etc/profile.d/lammps.sh.in Normal file
View File

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

6
doc/Makefile
View File

@ -49,11 +49,11 @@ help:
# ------------------------------------------
clean-all:
clean-all: clean
rm -rf $(BUILDDIR)/* utils/txt2html/txt2html.exe
clean:
rm -rf $(RSTDIR) html
rm -rf $(RSTDIR) html old epub
rm -rf spelling
clean-spelling:
@ -157,7 +157,7 @@ $(RSTDIR)/%.rst : src/%.txt $(TXT2RST)
@(\
mkdir -p $(RSTDIR) ; \
. $(VENV)/bin/activate ;\
txt2rst $< > $@ ;\
txt2rst -v $< > $@ ;\
deactivate ;\
)

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

@ -0,0 +1,47 @@
"Previous Section"_Install.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Run_head.html :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Build LAMMPS :h2
LAMMPS can be built as an executable or library from source code via
either traditional makefiles (which may require manual editing)
for use with GNU make or gmake, or a build environment generated by CMake
(Unix Makefiles, Xcode, Visual Studio, KDevelop or more). As an
alternative you can download a package with pre-built executables
as described on the "Install"_Install.html doc page.
<!-- RST
.. toctree::
:maxdepth: 1
Build_cmake
Build_make
Build_link
Build_basics
Build_settings
Build_package
Build_extras
END_RST -->
<!-- HTML_ONLY -->
"Build LAMMPS with CMake"_Build_cmake.html
"Build LAMMPS with make"_Build_make.html
"Link LAMMPS as a library to another code"_Build_link.html
"Basic build options"_Build_basics.html
"Optional build settings"_Build_settings.html
"Include packages in build"_Build_package.html
"Packages with extra build options"_Build_extras.html :all(b)
If you have problems building LAMMPS, it is often due to software
issues on your local machine. If you can, find a local expert to
help. If you're still stuck, send an email to the "LAMMPS mail
list"_http://lammps.sandia.gov/mail.html.

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.

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

@ -0,0 +1,197 @@
"Higher level section"_Build.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Build LAMMPS with CMake :h3
This page is a short summary of how to use CMake to build LAMMPS.
Details on CMake variables that enable specific LAMMPS build options
are given on the pages linked to from the "Build"_Build.html doc page.
Richard Berger (Temple U) has also written a more comprehensive guide
for how to use CMake to build LAMMPS. If you are new to CMake it is a
good place to start:
"Bulding LAMMPS using
CMake"_https://github.com/lammps/lammps/blob/master/cmake/README.md
:line
Building LAMMPS with CMake is a two-step process. First you use CMake
to create a build environment in a new directory. On Linux systems,
this will be based on makefiles for use with make. Then you use the
make command to build LAMMPS, which uses the created
Makefile(s). Example:
cd lammps # change to the LAMMPS distribution directory
mkdir build; cd build # create a new directory (folder) for build
cmake ../cmake \[options ...\] # configuration with (command-line) cmake
make # compilation :pre
The cmake command will detect available features, enable selected
packages and options, and will generate the build environment. The make
command will then compile and link LAMMPS, producing (by default) an
executable called "lmp" and a library called "liblammps.a" in the
"build" folder.
If your machine has multiple CPU cores (most do these days), using a
command like "make -jN" (with N being the number of available local
CPU cores) can be much faster. If you plan to do development on
LAMMPS or need to recompile LAMMPS repeatedly, installation of the
ccache (= Compiler Cache) software may speed up compilation even more.
After compilation, you can optionally copy the LAMMPS executable and
library into your system folders (by default under /usr/local) with:
make install # optional, copy LAMMPS executable & library elsewhere :pre
:line
There are 3 variants of CMake: a command-line verison (cmake), a text mode
UI version (ccmake), and a graphical GUI version (cmake-GUI). You can use
any of them interchangeably to configure and create the LAMMPS build
environment. On Linux all the versions produce a Makefile as their
output. See more details on each below.
You can specify a variety of options with any of the 3 versions, which
affect how the build is performed and what is included in the LAMMPS
executable. Links to pages explaining all the options are listed on
the "Build"_Build.html doc page.
You must perform the CMake build system generation and compilation in
a new directory you create. It can be anywhere on your local machine.
In these Build pages we assume that you are building in a directory
called "lammps/build". You can perform separate builds independently
with different options, so long as you perform each of them in a
separate directory you create. All the auxiliary files created by one
build process (executable, object files, log files, etc) are stored in
this directory or sub-directories within it that CMake creates.
NOTE: To perform a CMake build, no packages can be installed or a
build been previously attempted in the LAMMPS src directory by using
"make" commands to "perform a conventional LAMMPS
build"_Build_make.html. CMake detects if this is the case and
generates an error, telling you to type "make no-all purge" in the src
directory to un-install all packages. The purge removes all the *.h
files auto-generated by make.
You must have CMake version 2.8 or later on your system to build
LAMMPS. If you include the GPU or KOKKOS packages, CMake version 3.2
or later is required. Installation instructions for CMake are below.
After the initial build, if you edit LAMMPS source files, or add your
own new files to the source directory, you can just re-type make from
your build directory and it will re-compile only the files that have
changed. If you want to change CMake options you can run cmake (or
ccmake or cmake-gui) again from the same build directory and alter
various options; see details below. Or you can remove the entire build
folder, recreate the directory and start over.
:line
[Command-line version of CMake]:
cmake \[options ...\] /path/to/lammps/cmake # build from any dir
cmake \[options ...\] ../cmake # build from lammps/build :pre
The cmake command takes one required argument, which is the LAMMPS
cmake directory which contains the CMakeLists.txt file.
The argument can be preceeded or followed by various CMake
command-line options. Several useful ones are:
-D CMAKE_INSTALL_PREFIX=path # where to install LAMMPS executable/lib if desired
-D CMAKE_BUILD_TYPE=type # type = Release or Debug
-G output # style of output CMake generates
-DVARIABLE=value # setting for a LAMMPS feature to enable
-D VARIABLE=value # ditto, but cannot come after CMakeLists.txt dir :pre
All the LAMMPS-specific -D variables that a LAMMPS build supports are
described on the pages linked to from the "Build"_Build.html doc page.
All of these variable names are upper-case and their values are
lower-case, e.g. -D LAMMPS_SIZES=smallbig. For boolean values, any of
these forms can be used: yes/no, on/off, 1/0.
On Unix/Linux machines, CMake generates a Makefile by default to
perform the LAMMPS build. Alternate forms of build info can be
generated via the -G switch, e.g. Visual Studio on a Windows machine,
Xcode on MacOS, or KDevelop on Linux. Type "cmake --help" to see the
"Generator" styles of output your system supports.
NOTE: When CMake runs, it prints configuration info to the screen.
You should review this to verify all the features you requested were
enabled, including packages. You can also see what compilers and
compile options will be used for the build. Any errors in CMake
variable syntax will also be flagged, e.g. mis-typed variable names or
variable values.
CMake creates a CMakeCache.txt file when it runs. This stores all the
settings, so that when running CMake again you can use the current
folder '.' instead of the path to the LAMMPS cmake folder as the
required argument to the CMake command. Either way the existing
settings will be inherited unless the CMakeCache.txt file is removed.
If you later want to change a setting you can rerun cmake in the build
directory with different setting. Please note that some automatically
detected variables will not change their value when you rerun cmake.
In these cases it is usually better to first remove all the
files/directories in the build directory, or start with a fresh build
directory.
:line
[Curses version (terminal-style menu) of CMake]:
ccmake ../cmake :pre
You initiate the configuration and build environment generation steps
separately. For the first you have to type [c], for the second you
have to type [g]. You may need to type [c] multiple times, and may be
required to edit some of the entries of CMake configuration variables
in between. Please see the "ccmake
manual"_https://cmake.org/cmake/help/latest/manual/ccmake.1.html for
more information.
:line
[GUI version of CMake]:
cmake-gui ../cmake :pre
You initiate the configuration and build environment generation steps
separately. For the first you have to click on the [Configure] button,
for the second you have to click on the [Generate] button. You may
need to click on [Configure] multiple times, and may be required to
edit some of the entries of CMake configuration variables in between.
Please see the "cmake-gui
manual"_https://cmake.org/cmake/help/latest/manual/cmake-gui.1.html
for more information.
:line
[Installing CMake]
Check if your machine already has CMake installed:
which cmake # do you have it?
which cmake3 # version 3 may have this name
cmake --version # what specific version you have :pre
On clusters or supercomputers which use environment modules to manage
software packages, do this:
module list # is a cmake module already loaded?
module avail # is a cmake module available?
module load cmake3 # load cmake module with appropriate name :pre
Most Linux distributions offer precompiled cmake packages through
their package management system. If you do not have CMake or a new
enough version, you can download the latest version at
"https://cmake.org/download/"_https://cmake.org/download/.
Instructions on how to install it on various platforms can be found
"on this page"_https://cmake.org/install/.

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

@ -0,0 +1,922 @@
"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)
:line
COMPRESS package :h4,link(compress)
To build with this package you must have the zlib compression library
available on your system.
[CMake build]:
If CMake cannot find the library, you can set these variables:
-D ZLIB_INCLUDE_DIR=path # path to zlib.h header file
-D ZLIB_LIBRARIES=path # path to libz.a (.so) file :pre
[Traditional make]:
If make cannot find the library, you can edit the
lib/compress/Makefile.lammps file to specify the paths and library
name.
:line
GPU package :h4,link(gpu)
To build with this package, you must choose options for precision and
which GPU hardware to build for.
[CMake build]:
-D GPU_API=value # value = opencl (default) or cuda
-D GPU_PREC=value # precision setting
# value = double or mixed (default) or single
-D OCL_TUNE=value # hardware choice for GPU_API=opencl
# generic (default) or intel (Intel CPU) or fermi, kepler, cypress (NVIDIA)
-D GPU_ARCH=value # hardware choice for GPU_API=cuda
# value = sm_XX, see below
# default is Cuda-compiler dependent, but typically sm_20
-D CUDPP_OPT=value # optimization setting for GPU_API=cudea
# enables CUDA Performance Primitives Optimizations
# yes (default) or no :pre
GPU_ARCH settings for different GPU hardware is as follows:
sm_20 for Fermi (C2050/C2070, deprecated as of CUDA 8.0) or GeForce GTX 580 or similar
sm_30 for Kepler (K10)
sm_35 for Kepler (K40) or GeForce GTX Titan or similar
sm_37 for Kepler (dual K80)
sm_50 for Maxwell
sm_60 for Pascal (P100)
sm_70 for Volta :ul
[Traditional make]:
Before building LAMMPS, you must build the GPU library in lib/gpu.
You can do this manually if you prefer; follow the instructions in
lib/gpu/README. Note that the GPU library uses MPI calls, so you must
use the same MPI library (or the STUBS library) settings as the main
LAMMPS code. This also applies to the -DLAMMPS_BIGBIG,
-DLAMMPS_SMALLBIG, or -DLAMMPS_SMALLSMALL settings in whichever
Makefile you use.
You can also build the library in one step from the lammps/src dir,
using a command like these, which simply invoke the lib/gpu/Install.py
script with the specified args:
make lib-gpu # print help message
make lib-gpu args="-b" # build GPU library with default Makefile.linux
make lib-gpu args="-m xk7 -p single -o xk7.single" # create new Makefile.xk7.single, altered for single-precision
make lib-gpu args="-m mpi -a sm_60 -p mixed -b" # build GPU library with mixed precision and P100 using other settings in Makefile.mpi :pre
Note that this procedure starts with a Makefile.machine in lib/gpu, as
specified by the "-m" switch. For your convenience, machine makefiles
for "mpi" and "serial" are provided, which have the same settings as
the corresponding machine makefiles in the main LAMMPS source
folder. In addition you can alter 4 important settings in the
Makefile.machine you start from via the corresponding -h, -a, -p, -e
switches (as in the examples above), and also save a copy of the new
Makefile if desired:
CUDA_HOME = where NVIDIA CUDA software is installed on your system
CUDA_ARCH = sm_XX, what GPU hardware you have, same as CMake GPU_ARCH above
CUDA_PRECISION = precision (double, mixed, single)
EXTRAMAKE = which Makefile.lammps.* file to copy to Makefile.lammps :ul
If the library build is successful, 3 files should be created:
lib/gpu/libgpu.a, lib/gpu/nvc_get_devices, and
lib/gpu/Makefile.lammps. The latter has settings that enable LAMMPS
to link with CUDA libraries. If the settings in Makefile.lammps for
your machine are not correct, the LAMMPS build will fail, and
lib/gpu/Makefile.lammps may need to be edited.
NOTE: If you re-build the GPU library in lib/gpu, you should always
un-install the GPU package in lammps/src, then re-install it and
re-build LAMMPS. This is because the compilation of files in the GPU
package uses the library settings from the lib/gpu/Makefile.machine
used to build the GPU library.
:line
KIM package :h4,link(kim)
To build with this package, the KIM library must be downloaded and
built on your system. It must include the KIM models that you want to
use with LAMMPS.
Note that in LAMMPS lingo, a KIM model driver is a pair style
(e.g. EAM or Tersoff). A KIM model is a pair style for a particular
element or alloy and set of parameters, e.g. EAM for Cu with a
specific EAM potential file. Also note that installing the KIM API
library with all its models, may take around 30 min to build. Of
course you only need to do that once.
See the list of KIM model drivers here:
https://openkim.org/kim-items/model-drivers/alphabetical
See the list of all KIM models here:
https://openkim.org/kim-items/models/by-model-drivers
See the list of example KIM models included by default here:
https://openkim.org/kim-api on the "What is in the KIM API source
package?" page.
[CMake build]:
-D DOWNLOAD_KIM=value # download OpenKIM API v1 for build, value = no (default) or yes
-D KIM_LIBRARY=path # path to KIM shared library (only needed if a custom location)
-D KIM_INCLUDE_DIR=path # path to KIM include directory (only needed if a custom location) :pre
[Traditional make]:
You can download and build the KIM library manually if you prefer;
follow the instructions in lib/kim/README. You can also do it in one
step from the lammps/src dir, using a command like these, which simply
invoke the lib/kim/Install.py script with the specified args.
make lib-kim # print help message
make lib-kim args="-b " # (re-)install KIM API lib with only example models
make lib-kim args="-b -a Glue_Ercolessi_Adams_Al__MO_324507536345_001" # ditto plus one model
make lib-kim args="-b -a everything" # install KIM API lib with all models
make lib-kim args="-n -a EAM_Dynamo_Ackland_W__MO_141627196590_002" # add one model or model driver
make lib-kim args="-p /usr/local/kim-api" # use an existing KIM API installation at the provided location
make lib-kim args="-p /usr/local/kim-api -a EAM_Dynamo_Ackland_W__MO_141627196590_002" # ditto but add one model or driver :pre
:line
KOKKOS package :h4,link(kokkos)
To build with this package, you must choose which hardware you want to
build for, either CPUs (multi-threading via OpenMP) or KNLs (OpenMP)
or GPUs (NVIDIA Cuda).
For a CMake or make build, these are the possible choices for the
KOKKOS_ARCH settings described below. Note that for CMake, these are
really Kokkos variables, not LAMMPS variables. Hence you must use
case-sensitive values, e.g. BDW, not bdw.
ARMv80 = ARMv8.0 Compatible CPU
ARMv81 = ARMv8.1 Compatible CPU
ARMv8-ThunderX = ARMv8 Cavium ThunderX CPU
BGQ = IBM Blue Gene/Q CPUs
Power8 = IBM POWER8 CPUs
Power9 = IBM POWER9 CPUs
SNB = Intel Sandy/Ivy Bridge CPUs
HSW = Intel Haswell CPUs
BDW = Intel Broadwell Xeon E-class CPUs
SKX = Intel Sky Lake Xeon E-class HPC CPUs (AVX512)
KNC = Intel Knights Corner Xeon Phi
KNL = Intel Knights Landing Xeon Phi
Kepler30 = NVIDIA Kepler generation CC 3.0
Kepler32 = NVIDIA Kepler generation CC 3.2
Kepler35 = NVIDIA Kepler generation CC 3.5
Kepler37 = NVIDIA Kepler generation CC 3.7
Maxwell50 = NVIDIA Maxwell generation CC 5.0
Maxwell52 = NVIDIA Maxwell generation CC 5.2
Maxwell53 = NVIDIA Maxwell generation CC 5.3
Pascal60 = NVIDIA Pascal generation CC 6.0
Pascal61 = NVIDIA Pascal generation CC 6.1 :ul
[CMake build]:
For multicore CPUs using OpenMP, set these 2 variables.
-D KOKKOS_ARCH=archCPU # archCPU = CPU from list above
-D KOKKOS_ENABLE_OPENMP=yes :pre
For Intel KNLs using OpenMP, set these 2 variables:
-D KOKKOS_ARCH=KNL
-D KOKKOS_ENABLE_OPENMP=yes :pre
For NVIDIA GPUs using CUDA, set these 4 variables:
-D KOKKOS_ARCH="archCPU;archGPU" # archCPU = CPU from list above that is hosting the GPU
# archGPU = GPU from list above
-D KOKKOS_ENABLE_CUDA=yes
-D KOKKOS_ENABLE_OPENMP=yes
-D CMAKE_CXX_COMPILER=wrapper # wrapper = full path to Cuda nvcc wrapper :pre
The wrapper value is the Cuda nvcc compiler wrapper provided in the
Kokkos library: lib/kokkos/bin/nvcc_wrapper. The setting should
include the full path name to the wrapper, e.g.
-D CMAKE_CXX_COMPILER=/home/username/lammps/lib/kokkos/bin/nvcc_wrapper :pre
[Traditional make]:
Choose which hardware to support in Makefile.machine via
KOKKOS_DEVICES and KOKKOS_ARCH settings. See the
src/MAKE/OPTIONS/Makefile.kokkos* files for examples.
For multicore CPUs using OpenMP:
KOKKOS_DEVICES = OpenMP
KOKKOS_ARCH = archCPU # archCPU = CPU from list above :pre
For Intel KNLs using OpenMP:
KOKKOS_DEVICES = OpenMP
KOKKOS_ARCH = KNL :pre
For NVIDIA GPUs using CUDA:
KOKKOS_DEVICES = Cuda
KOKKOS_ARCH = archCPU,archGPU # archCPU = CPU from list above that is hosting the GPU
# archGPU = GPU from list above :pre
For GPUs, you also need these 2 lines in your Makefile.machine before
the CC line is defined, in this case for use with OpenMPI mpicxx. The
2 lines define a nvcc wrapper compiler, which will use nvcc for
compiling CUDA files and use a C++ compiler for non-Kokkos, non-CUDA
files.
KOKKOS_ABSOLUTE_PATH = $(shell cd $(KOKKOS_PATH); pwd)
export OMPI_CXX = $(KOKKOS_ABSOLUTE_PATH)/config/nvcc_wrapper
CC = mpicxx :pre
:line
LATTE package :h4,link(latte)
To build with this package, you must download and build the LATTE
library.
[CMake build]:
-D DOWNLOAD_LATTE=value # download LATTE for build, value = no (default) or yes
-D LATTE_LIBRARY=path # path to LATTE shared library (only needed if a custom location) :pre
[Traditional make]:
You can download and build the LATTE library manually if you prefer;
follow the instructions in lib/latte/README. You can also do it in
one step from the lammps/src dir, using a command like these, which
simply invokes the lib/latte/Install.py script with the specified
args:
make lib-latte # print help message
make lib-latte args="-b" # download and build in lib/latte/LATTE-master
make lib-latte args="-p $HOME/latte" # use existing LATTE installation in $HOME/latte
make lib-latte args="-b -m gfortran" # download and build in lib/latte and
# copy Makefile.lammps.gfortran to Makefile.lammps
:pre
Note that 3 symbolic (soft) links, "includelink" and "liblink" and
"filelink.o", are created in lib/latte to point into the LATTE home
dir. When LAMMPS itself is built it will use these links. You should
also check that the Makefile.lammps file you create is appropriate for
the compiler you use on your system to build LATTE.
:line
MEAM package :h4,link(meam)
NOTE: the use of the MEAM package is discouraged, as it has been
superseded by the USER-MEAMC package, which is a direct translation of
the Fortran code in the MEAM library to C++. The code in USER-MEAMC
should be functionally equivalent to the MEAM package, fully supports
use of "pair_style hybrid"_pair_hybrid.html (the MEAM packaged doesn
not), and has optimizations that make it significantly faster than the
MEAM package.
[CMake build]:
No additional settings are needed besides "-D PKG_MEAM=yes".
[Traditional make]:
Before building LAMMPS, you must build the MEAM library in lib/meam.
You can build the MEAM library manually if you prefer; follow the
instructions in lib/meam/README. You can also do it in one step from
the lammps/src dir, using a command like these, which simply invoke
the lib/meam/Install.py script with the specified args:
make lib-meam # print help message
make lib-meam args="-m mpi" # build with default Fortran compiler compatible with your MPI library
make lib-meam args="-m serial" # build with compiler compatible with "make serial" (GNU Fortran)
make lib-meam args="-m ifort" # build with Intel Fortran compiler using Makefile.ifort :pre
The build should produce two files: lib/meam/libmeam.a and
lib/meam/Makefile.lammps. The latter is copied from an existing
Makefile.lammps.* and has settings needed to link C++ (LAMMPS) with
Fortran (MEAM library). Typically the two compilers used for LAMMPS
and the MEAM library need to be consistent (e.g. both Intel or both
GNU compilers). If necessary, you can edit/create a new
lib/meam/Makefile.machine file for your system, which should define an
EXTRAMAKE variable to specify a corresponding Makefile.lammps.machine
file.
:line
MSCG package :h4,link(mscg)
To build with this package, you must download and build the MS-CG
library. Building the MS-CG library and using it from LAMMPS requires
a C++11 compatible compiler and that the GSL (GNU Scientific Library)
headers and libraries are installed on your machine. See the
lib/mscg/README and MSCG/Install files for more details.
[CMake build]:
-D DOWNLOAD_MSCG=value # download MSCG for build, value = no (default) or yes
-D MSCG_LIBRARY=path # path to MSCG shared library (only needed if a custom location)
-D MSCG_INCLUDE_DIR=path # path to MSCG include directory (only needed if a custom location) :pre
[Traditional make]:
You can download and build the MS-CG library manually if you prefer;
follow the instructions in lib/mscg/README. You can also do it in one
step from the lammps/src dir, using a command like these, which simply
invoke the lib/mscg/Install.py script with the specified args:
make lib-mscg # print help message
make lib-mscg args="-b -m serial" # download and build in lib/mscg/MSCG-release-master
# with the settings compatible with "make serial"
make lib-mscg args="-b -m mpi" # download and build in lib/mscg/MSCG-release-master
# with the settings compatible with "make mpi"
make lib-mscg args="-p /usr/local/mscg-release" # use the existing MS-CG installation in /usr/local/mscg-release :pre
Note that 2 symbolic (soft) links, "includelink" and "liblink", will
be created in lib/mscg to point to the MS-CG src/installation dir.
When LAMMPS is built in src it will use these links. You should not
need to edit the lib/mscg/Makefile.lammps file.
:line
OPT package :h4,link(opt)
[CMake build]:
No additional settings are needed besides "-D PKG_OPT=yes".
[Traditional make]:
The compile flag "-restrict" must be used to build LAMMPS with the OPT
package when using Intel compilers. It should be added to the CCFLAGS
line of your Makefile.machine. See src/MAKE/OPTIONS/Makefile.opt for
an example.
:line
POEMS package :h4,link(poems)
[CMake build]:
No additional settings are needed besides "-D PKG_OPT=yes".
[Traditional make]:
Before building LAMMPS, you must build the POEMS library in lib/poems.
You can do this manually if you prefer; follow the instructions in
lib/poems/README. You can also do it in one step from the lammps/src
dir, using a command like these, which simply invoke the
lib/poems/Install.py script with the specified args:
make lib-poems # print help message
make lib-poems args="-m serial" # build with GNU g++ compiler (settings as with "make serial")
make lib-poems args="-m mpi" # build with default MPI C++ compiler (settings as with "make mpi")
make lib-poems args="-m icc" # build with Intel icc compiler :pre
The build should produce two files: lib/poems/libpoems.a and
lib/poems/Makefile.lammps. The latter is copied from an existing
Makefile.lammps.* and has settings needed to build LAMMPS with the
POEMS library (though typically the settings are just blank). If
necessary, you can edit/create a new lib/poems/Makefile.machine file
for your system, which should define an EXTRAMAKE variable to specify
a corresponding Makefile.lammps.machine file.
:line
PYTHON package :h4,link(python)
Building with the PYTHON package requires you have a Python shared
library available on your system, which needs to be a Python 2
version, 2.6 or later. Python 3 is not yet supported. See
lib/python/README for more details.
[CMake build]:
-D PYTHON_EXECUTABLE=path # path to Python executable to use :pre
Without this setting, CMake will ues the default Python on your
system. To use a different Python version, you can either create a
virtualenv, activate it and then run cmake. Or you can set the
PYTHON_EXECUTABLE variable to specify which Python interpreter should
be used. Note note that you will also need to have the development
headers installed for this version, e.g. python2-devel.
[Traditional make]:
The build uses the lib/python/Makefile.lammps file in the compile/link
process to find Python. You should only need to create a new
Makefile.lammps.* file (and copy it to Makefile.lammps) if the LAMMPS
build fails.
:line
REAX package :h4,link(reax)
NOTE: the use of the REAX package and its "pair_style
reax"_pair_reax.html command is discouraged, as it is no longer
maintained. Please use the USER-REAXC package and its "pair_style
reax/c"_pair_reaxc.html command instead, and possibly its KOKKOS
enabled variant (pair_style reax/c/kk), which has a more robust memory
management. See the "pair_style reax/c"_pair_reaxc.html doc page for
details.
[CMake build]:
No additional settings are needed besides "-D PKG_REAX=yes".
[Traditional make]:
Before building LAMMPS, you must build the REAX library in lib/reax.
You can do this manually if you prefer; follow the instructions in
lib/reax/README. You can also do it in one step from the lammps/src
dir, using a command like these, which simply invoke the
lib/reax/Install.py script with the specified args:
make lib-reax # print help message
make lib-reax args="-m serial" # build with GNU Fortran compiler (settings as with "make serial")
make lib-reax args="-m mpi" # build with default MPI Fortran compiler (settings as with "make mpi")
make lib-reax args="-m ifort" # build with Intel ifort compiler :pre
The build should produce two files: lib/reax/libreax.a and
lib/reax/Makefile.lammps. The latter is copied from an existing
Makefile.lammps.* and has settings needed to link C++ (LAMMPS) with
Fortran (REAX library). Typically the two compilers used for LAMMPS
and the REAX library need to be consistent (e.g. both Intel or both
GNU compilers). If necessary, you can edit/create a new
lib/reax/Makefile.machine file for your system, which should define an
EXTRAMAKE variable to specify a corresponding Makefile.lammps.machine
file.
:line
VORONOI package :h4,link(voronoi)
To build with this package, you must download and build the "Voro++
library"_voro_home.
:link(voro_home,http://math.lbl.gov/voro++)
[CMake build]:
-D DOWNLOAD_VORO=value # download Voro++ for build, value = no (default) or yes
-D VORO_LIBRARY=path # (only needed if at custom location) path to VORO shared library
-D VORO_INCLUDE_DIR=path # (only needed if at custom location) path to VORO include directory :pre
[Traditional make]:
You can download and build the Voro++ library manually if you prefer;
follow the instructions in lib/voronoi/README. You can also do it in
one step from the lammps/src dir, using a command like these, which
simply invoke the lib/voronoi/Install.py script with the specified
args:
make lib-voronoi # print help message
make lib-voronoi args="-b" # download and build the default version in lib/voronoi/voro++-<version>
make lib-voronoi args="-p $HOME/voro++" # use existing Voro++ installation in $HOME/voro++
make lib-voronoi args="-b -v voro++0.4.6" # download and build the 0.4.6 version in lib/voronoi/voro++-0.4.6 :pre
Note that 2 symbolic (soft) links, "includelink" and "liblink", are
created in lib/voronoi to point to the Voro++ src dir. When LAMMPS
builds in src it will use these links. You should not need to edit
the lib/voronoi/Makefile.lammps file.
:line
USER-ATC package :h4,link(user-atc)
The USER-ATC package requires the MANYBODY package also be installed.
[CMake build]:
No additional settings are needed besides "-D PKG_REAX=yes" and "-D
PKG_MANYBODY=yes".
[Traditional make]:
Before building LAMMPS, you must build the ATC library in lib/atc.
You can do this manually if you prefer; follow the instructions in
lib/atc/README. You can also do it in one step from the lammps/src
dir, using a command like these, which simply invoke the
lib/atc/Install.py script with the specified args:
make lib-atc # print help message
make lib-atc args="-m serial" # build with GNU g++ compiler and MPI STUBS (settings as with "make serial")
make lib-atc args="-m mpi" # build with default MPI compiler (settings as with "make mpi")
make lib-atc args="-m icc" # build with Intel icc compiler :pre
The build should produce two files: lib/atc/libatc.a and
lib/atc/Makefile.lammps. The latter is copied from an existing
Makefile.lammps.* and has settings needed to build LAMMPS with the ATC
library. If necessary, you can edit/create a new
lib/atc/Makefile.machine file for your system, which should define an
EXTRAMAKE variable to specify a corresponding Makefile.lammps.machine
file.
Note that the Makefile.lammps file has settings for the BLAS and
LAPACK linear algebra libraries. As explained in lib/atc/README these
can either exist on your system, or you can use the files provided in
lib/linalg. In the latter case you also need to build the library in
lib/linalg with a command like these:
make lib-linalg # print help message
make lib-linalg args="-m serial" # build with GNU Fortran compiler (settings as with "make serial")
make lib-linalg args="-m mpi" # build with default MPI Fortran compiler (settings as with "make mpi")
make lib-linalg args="-m gfortran" # build with GNU Fortran compiler :pre
:line
USER-AWPMD package :h4,link(user-awpmd)
[CMake build]:
No additional settings are needed besides "-D PKG_USER-AQPMD=yes".
[Traditional make]:
Before building LAMMPS, you must build the AWPMD library in lib/awpmd.
You can do this manually if you prefer; follow the instructions in
lib/awpmd/README. You can also do it in one step from the lammps/src
dir, using a command like these, which simply invoke the
lib/awpmd/Install.py script with the specified args:
make lib-awpmd # print help message
make lib-awpmd args="-m serial" # build with GNU g++ compiler and MPI STUBS (settings as with "make serial")
make lib-awpmd args="-m mpi" # build with default MPI compiler (settings as with "make mpi")
make lib-awpmd args="-m icc" # build with Intel icc compiler :pre
The build should produce two files: lib/awpmd/libawpmd.a and
lib/awpmd/Makefile.lammps. The latter is copied from an existing
Makefile.lammps.* and has settings needed to build LAMMPS with the
AWPMD library. If necessary, you can edit/create a new
lib/awpmd/Makefile.machine file for your system, which should define
an EXTRAMAKE variable to specify a corresponding
Makefile.lammps.machine file.
Note that the Makefile.lammps file has settings for the BLAS and
LAPACK linear algebra libraries. As explained in lib/awpmd/README
these can either exist on your system, or you can use the files
provided in lib/linalg. In the latter case you also need to build the
library in lib/linalg with a command like these:
make lib-linalg # print help message
make lib-linalg args="-m serial" # build with GNU Fortran compiler (settings as with "make serial")
make lib-linalg args="-m mpi" # build with default MPI Fortran compiler (settings as with "make mpi")
make lib-linalg args="-m gfortran" # build with GNU Fortran compiler :pre
:line
USER-COLVARS package :h4,link(user-colvars)
[CMake build]:
No additional settings are needed besides "-D PKG_USER-COLVARS=yes".
[Traditional make]:
Before building LAMMPS, you must build the COLVARS library in
lib/colvars. You can do this manually if you prefer; follow the
instructions in lib/colvars/README. You can also do it in one step
from the lammps/src dir, using a command like these, which simply
invoke the lib/colvars/Install.py script with the specified args:
make lib-colvars # print help message
make lib-colvars args="-m serial" # build with GNU g++ compiler (settings as with "make serial")
make lib-colvars args="-m mpi" # build with default MPI compiler (settings as with "make mpi")
make lib-colvars args="-m g++-debug" # build with GNU g++ compiler and colvars debugging enabled :pre
The build should produce two files: lib/colvars/libcolvars.a and
lib/colvars/Makefile.lammps. The latter is copied from an existing
Makefile.lammps.* and has settings needed to build LAMMPS with the
COLVARS library (though typically the settings are just blank). If
necessary, you can edit/create a new lib/colvars/Makefile.machine file
for your system, which should define an EXTRAMAKE variable to specify
a corresponding Makefile.lammps.machine file.
:line
USER-H5MD package :h4,link(user-h5md)
To build with this package you must have the HDF5 software package
installed on your system, which should include the h5cc compiler and
the HDF5 library.
[CMake build]:
No additional settings are needed besides "-D PKG_USER-H5MD=yes".
This should autodetect the H5MD library on your system. Several
advanced CMake H5MD options exist if you need to specify where it is
installed. Use the ccmake (terminal window) or cmake-gui (graphical)
tools to see these options and set them interactively from their user
interfaces.
[Traditional make]:
Before building LAMMPS, you must build the CH5MD library in lib/h5md.
You can do this manually if you prefer; follow the instructions in
lib/h5md/README. You can also do it in one step from the lammps/src
dir, using a command like these, which simply invoke the
lib/h5md/Install.py script with the specified args:
make lib-h5md # print help message
make lib-hm5d args="-m h5cc" # build with h5cc compiler :pre
The build should produce two files: lib/h5md/libch5md.a and
lib/h5md/Makefile.lammps. The latter is copied from an existing
Makefile.lammps.* and has settings needed to build LAMMPS with the
system HDF5 library. If necessary, you can edit/create a new
lib/h5md/Makefile.machine file for your system, which should define an
EXTRAMAKE variable to specify a corresponding Makefile.lammps.machine
file.
:line
USER-INTEL package :h4,link(user-intel)
To build with this package, you must choose which hardware you want to
build for, either Intel CPUs or Intel KNLs. You should also typically
"install the USER-OMP package"_#user-omp, as it can be used in tandem
with the USER-INTEL package to good effect, as explained on the "Speed
intel"_Speed_intel.html doc page.
[CMake build]:
-D INTEL_ARCH=value # value = cpu (default) or knl
-D BUILD_OMP=yes # also required to build with the USER-INTEl package :pre
Requires an Intel compiler as well as the Intel TBB and MKL libraries.
[Traditional make]:
Choose which hardware to compile for in Makefile.machine via the
following settings. See src/MAKE/OPTIONS/Makefile.intel_cpu* and
Makefile.knl files for examples.
For CPUs:
OPTFLAGS = -xHost -O2 -fp-model fast=2 -no-prec-div -qoverride-limits -qopt-zmm-usage=high
CCFLAGS = -g -qopenmp -DLAMMPS_MEMALIGN=64 -no-offload -fno-alias -ansi-alias -restrict $(OPTFLAGS)
LINKFLAGS = -g -qopenmp $(OPTFLAGS)
LIB = -ltbbmalloc :pre
For KNLs:
OPTFLAGS = -xMIC-AVX512 -O2 -fp-model fast=2 -no-prec-div -qoverride-limits
CCFLAGS = -g -qopenmp -DLAMMPS_MEMALIGN=64 -no-offload -fno-alias -ansi-alias -restrict $(OPTFLAGS)
LINKFLAGS = -g -qopenmp $(OPTFLAGS)
LIB = -ltbbmalloc :pre
:line
USER-MOLFILE package :h4,link(user-molfile)
[CMake build]:
No additional settings are needed besides "-D PKG_USER-MOLFILE=yes".
[Traditional make]:
The lib/molfile/Makefile.lammps file has a setting for a dynamic
loading library libdl.a that is typically present on all systems. It
is required for LAMMPS to link with this package. If the setting is
not valid for your system, you will need to edit the Makefile.lammps
file. See lib/molfile/README and lib/molfile/Makefile.lammps for
details.
:line
USER-NETCDF package :h4,link(user-netcdf)
To build with this package you must have the NetCDF library installed
on your system.
[CMake build]:
No additional settings are needed besides "-D PKG_USER-NETCDF=yes".
This should autodetect the NETCDF library if it is installed on your
system at standard locations. Several advanced CMake NETCDF options
exist if you need to specify where it was installed. Use the ccmake
(terminal window) or cmake-gui (graphical) tools to see these options
and set them interactively from their user interfaces.
[Traditional make]:
The lib/netcdf/Makefile.lammps file has settings for NetCDF include
and library files which LAMMPS needs to build with this package. If
the settings are not valid for your system, you will need to edit the
Makefile.lammps file. See lib/netcdf/README for details.
:line
USER-OMP package :h4,link(user-omp)
[CMake build]:
No additional settings are required besides "-D PKG_USER-OMP=yes". If
CMake detects OpenMP support, the USER-OMP code will be compiled with
multi-threading support enabled, otherwise as optimized serial code.
[Traditional make]:
To enable multi-threading support in the USER-OMP package (and other
styles supporting OpenMP) the following compile and link flags must
be added to your Makefile.machine file.
See src/MAKE/OPTIONS/Makefile.omp for an example.
CCFLAGS: -fopenmp # for GNU Compilers
CCFLAGS: -qopenmp -restrict # for Intel compilers on Linux
LINKFLAGS: -fopenmp # for GNU Compilers
LINKFLAGS: -qopenmp # for Intel compilers on Linux :pre
For other platforms and compilers, please consult the documentation
about OpenMP support for your compiler.
:line
USER-QMMM package :h4,link(user-qmmm)
NOTE: The LAMMPS executable these steps produce is not yet functional
for a QM/MM simulation. You must also build Quantum ESPRESSO and
create a new executable (pwqmmm.x) which links LAMMPS and Quantum
ESPRESSO together. These are steps 3 and 4 described in the
lib/qmmm/README file. Unfortunately, the Quantum ESPRESSO developers
have been breaking the interface that the QM/MM code in LAMMPS is using,
so that currently (Summer 2018) using this feature requires either
correcting the library interface feature in recent Quantum ESPRESSO
releases, or using an outdated version of QE. The last version of
Quantum ESPRESSO known to work with this QM/MM interface was version
5.4.1 from 2016.
[CMake build]:
The CMake build system currently does not support building the full
QM/MM-capable hybrid executable of LAMMPS and QE called pwqmmm.x.
You must use the traditional make build for this package.
[Traditional make]:
Before building LAMMPS, you must build the QMMM library in lib/qmmm.
You can do this manually if you prefer; follow the first two steps
explained in lib/qmmm/README. You can also do it in one step from the
lammps/src dir, using a command like these, which simply invoke the
lib/qmmm/Install.py script with the specified args:
make lib-qmmm # print help message
make lib-qmmm args="-m serial" # build with GNU Fortran compiler (settings as in "make serial")
make lib-qmmm args="-m mpi" # build with default MPI compiler (settings as in "make mpi")
make lib-qmmm args="-m gfortran" # build with GNU Fortran compiler :pre
The build should produce two files: lib/qmmm/libqmmm.a and
lib/qmmm/Makefile.lammps. The latter is copied from an existing
Makefile.lammps.* and has settings needed to build LAMMPS with the
QMMM library (though typically the settings are just blank). If
necessary, you can edit/create a new lib/qmmm/Makefile.machine file
for your system, which should define an EXTRAMAKE variable to specify
a corresponding Makefile.lammps.machine file.
You can then install QMMM package and build LAMMPS in the usual
manner. After completing the LAMMPS build and compiling Quantum
ESPRESSO with external library support, go back to the lib/qmmm folder
and follow the instructions on the README file to build the combined
LAMMPS/QE QM/MM executable (pwqmmm.x) in the lib/qmmm folder.
:line
USER-QUIP package :h4,link(user-quip)
To build with this package, you must download and build the QUIP
library. It can be obtained from GitHub. For support of GAP
potentials, additional files with specific licensing conditions need
to be downloaded and configured. See step 1 and step 1.1 in the
lib/quip/README file for details on how to do this.
[CMake build]:
-D QUIP_LIBRARIES=path # path to libquip.a (only needed if a custom location) :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
Set EIGEN3_INCLUDE_DIR if CMake cannot find the Eigen3 library.
[Traditional make]:
You can download the Eigen3 library manually if you prefer; follow the
instructions in lib/smd/README. You can also do it in one step from
the lammps/src dir, using a command like these, which simply invoke
the lib/smd/Install.py script with the specified args:
make lib-smd # print help message
make lib-smd args="-b" # download to lib/smd/eigen3
make lib-smd args="-p /usr/include/eigen3" # use existing Eigen installation in /usr/include/eigen3 :pre
Note that a symbolic (soft) link named "includelink" is created in
lib/smd to point to the Eigen dir. When LAMMPS builds it will use
this link. You should not need to edit the lib/smd/Makefile.lammps
file.
:line
USER-VTK package :h4,link(user-vtk)
To build with this package you must have the VTK library installed on
your system.
[CMake build]:
No additional settings are needed besides "-D PKG_USER-VTK=yes".
This should autodetect the VTK library if it is installed on your
system at standard locations. Several advanced VTK options exist if
you need to specify where it was installed. Use the ccmake (terminal
window) or cmake-gui (graphical) tools to see these options and set
them interactively from their user interfaces.
[Traditional make]:
The lib/vtk/Makefile.lammps file has settings for accessing VTK files
and its library, which LAMMPS needs to build with this package. If
the settings are not valid for your system, check if one of the other
lib/vtk/Makefile.lammps.* files is compatible and copy it to
Makefile.lammps. If none of the provided files work, you will need to
edit the Makefile.lammps file. See lib/vtk/README for details.

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

53
doc/src/Commands.txt Normal file
View File

@ -0,0 +1,53 @@
"Previous Section"_Run_head.html - "LAMMPS WWW Site"_lws -
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
Section"_Packages.html :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html#comm)
:line
Commands :h2
These pages describe how a LAMMPS input script is formatted and the
commands in it are used to define a LAMMPS simulation.
<!-- RST
.. toctree::
:maxdepth: 1
Commands_input
Commands_parse
Commands_structure
Commands_category
.. toctree::
:maxdepth: 1
Commands_all
Commands_fix
Commands_compute
Commands_pair
Commands_bond
Commands_kspace
END_RST -->
<!-- HTML_ONLY -->
"LAMMPS input scripts"_Commands_input.html
"Parsing rules for input scripts"_Commands_parse.html
"Input script structure"_Commands_structure.html
"Commands by category"_Commands_category.html :all(b)
"All commands"_Commands_all.html
"Fix commands"_Commands_fix.html
"Compute commands"_Commands_compute.html
"Pair commands"_Commands_pair.html
"Bond, angle, dihedral, improper commands"_Commands_bond.html
"KSpace solvers"_Commands_kspace.html :all(b)
<!-- END_HTML_ONLY -->

128
doc/src/Commands_all.txt Normal file
View File

@ -0,0 +1,128 @@
"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
"All commands"_Commands_all.html,
"Fix styles"_Commands_fix.html,
"Compute styles"_Commands_compute.html,
"Pair styles"_Commands_pair.html,
"Bond styles"_Commands_bond.html,
"Angle styles"_Commands_bond.html#angle,
"Dihedral styles"_Commands_bond.html#dihedral,
"Improper styles"_Commands_bond.html#improper,
"KSpace styles"_Commands_kspace.html :tb(c=3,ea=c)
All commands :h3
An alphabetic list of all LAMMPS commmands.
"angle_coeff"_angle_coeff.html,
"angle_style"_angle_style.html,
"atom_modify"_atom_modify.html,
"atom_style"_atom_style.html,
"balance"_balance.html,
"bond_coeff"_bond_coeff.html,
"bond_style"_bond_style.html,
"bond_write"_bond_write.html,
"boundary"_boundary.html,
"box"_box.html,
"change_box"_change_box.html,
"clear"_clear.html,
"comm_modify"_comm_modify.html,
"comm_style"_comm_style.html,
"compute"_compute.html,
"compute_modify"_compute_modify.html,
"create_atoms"_create_atoms.html,
"create_bonds"_create_bonds.html,
"create_box"_create_box.html,
"delete_atoms"_delete_atoms.html,
"delete_bonds"_delete_bonds.html,
"dielectric"_dielectric.html,
"dihedral_coeff"_dihedral_coeff.html,
"dihedral_style"_dihedral_style.html,
"dimension"_dimension.html,
"displace_atoms"_displace_atoms.html,
"dump"_dump.html,
"dump image"_dump_image.html,
"dump_modify"_dump_modify.html,
"dump movie"_dump_image.html,
"dump netcdf"_dump_netcdf.html,
"dump netcdf/mpiio"_dump_netcdf.html,
"dump vtk"_dump_vtk.html,
"echo"_echo.html,
"fix"_fix.html,
"fix_modify"_fix_modify.html,
"group"_group.html,
"group2ndx"_group2ndx.html,
"if"_if.html,
"info"_info.html,
"improper_coeff"_improper_coeff.html,
"improper_style"_improper_style.html,
"include"_include.html,
"jump"_jump.html,
"kspace_modify"_kspace_modify.html,
"kspace_style"_kspace_style.html,
"label"_label.html,
"lattice"_lattice.html,
"log"_log.html,
"mass"_mass.html,
"minimize"_minimize.html,
"min_modify"_min_modify.html,
"min_style"_min_style.html,
"molecule"_molecule.html,
"ndx2group"_group2ndx.html,
"neb"_neb.html,
"neigh_modify"_neigh_modify.html,
"neighbor"_neighbor.html,
"newton"_newton.html,
"next"_next.html,
"package"_package.html,
"pair_coeff"_pair_coeff.html,
"pair_modify"_pair_modify.html,
"pair_style"_pair_style.html,
"pair_write"_pair_write.html,
"partition"_partition.html,
"prd"_prd.html,
"print"_print.html,
"processors"_processors.html,
"python"_python.html,
"quit"_quit.html,
"read_data"_read_data.html,
"read_dump"_read_dump.html,
"read_restart"_read_restart.html,
"region"_region.html,
"replicate"_replicate.html,
"rerun"_rerun.html,
"reset_ids"_reset_ids.html,
"reset_timestep"_reset_timestep.html,
"restart"_restart.html,
"run"_run.html,
"run_style"_run_style.html,
"set"_set.html,
"shell"_shell.html,
"special_bonds"_special_bonds.html,
"suffix"_suffix.html,
"tad"_tad.html,
"temper"_temper.html,
"temper/grem"_temper_grem.html,
"temper/npt"_temper_npt.html,
"thermo"_thermo.html,
"thermo_modify"_thermo_modify.html,
"thermo_style"_thermo_style.html,
"timer"_timer.html,
"timestep"_timestep.html,
"uncompute"_uncompute.html,
"undump"_undump.html,
"unfix"_unfix.html,
"units"_units.html,
"variable"_variable.html,
"velocity"_velocity.html,
"write_coeff"_write_coeff.html,
"write_data"_write_data.html,
"write_dump"_write_dump.html,
"write_restart"_write_restart.html :tb(c=6,ea=c)

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

@ -0,0 +1,124 @@
"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
"All commands"_Commands_all.html,
"Fix styles"_Commands_fix.html,
"Compute styles"_Commands_compute.html,
"Pair styles"_Commands_pair.html,
"Bond styles"_Commands_bond.html#bond,
"Angle styles"_Commands_bond.html#angle,
"Dihedral styles"_Commands_bond.html#dihedral,
"Improper styles"_Commands_bond.html#improper,
"KSpace styles"_Commands_kspace.html :tb(c=3,ea=c)
Bond, angle, dihedral, and improper commands :h3
:line
Bond_style potentials :h3,link(bond)
All LAMMPS "bond_style"_bond_style.html commands. Some styles have
accelerated versions. This is indicated by additional letters in
parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
OPT.
"none"_bond_none.html,
"zero"_bond_zero.html,
"hybrid"_bond_hybrid.html :tb(c=3,ea=c)
"class2 (ko)"_bond_class2.html,
"fene (iko)"_bond_fene.html,
"fene/expand (o)"_bond_fene_expand.html,
"gromos (o)"_bond_gromos.html,
"harmonic (ko)"_bond_harmonic.html,
"harmonic/shift (o)"_bond_harmonic_shift.html,
"harmonic/shift/cut (o)"_bond_harmonic_shift_cut.html,
"morse (o)"_bond_morse.html,
"nonlinear (o)"_bond_nonlinear.html,
"oxdna/fene"_bond_oxdna.html,
"oxdna2/fene"_bond_oxdna.html,
"quartic (o)"_bond_quartic.html,
"table (o)"_bond_table.html :tb(c=4,ea=c)
:line
Angle_style potentials :h3,link(angle)
All LAMMPS "angle_style"_angle_style.html commands. Some styles have
accelerated versions. This is indicated by additional letters in
parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
OPT.
"none"_angle_none.html,
"zero"_angle_zero.html,
"hybrid"_angle_hybrid.html :tb(c=3,ea=c)
"charmm (ko)"_angle_charmm.html,
"class2 (ko)"_angle_class2.html,
"cosine (o)"_angle_cosine.html,
"cosine/delta (o)"_angle_cosine_delta.html,
"cosine/periodic (o)"_angle_cosine_periodic.html,
"cosine/shift (o)"_angle_cosine_shift.html,
"cosine/shift/exp (o)"_angle_cosine_shift_exp.html,
"cosine/squared (o)"_angle_cosine_squared.html,
"dipole (o)"_angle_dipole.html,
"fourier (o)"_angle_fourier.html,
"fourier/simple (o)"_angle_fourier_simple.html,
"harmonic (iko)"_angle_harmonic.html,
"quartic (o)"_angle_quartic.html,
"sdk"_angle_sdk.html,
"table (o)"_angle_table.html :tb(c=4,ea=c)
:line
Dihedral_style potentials :h3,link(dihedral)
All LAMMPS "dihedral_style"_dihedral_style.html commands. Some styles
have accelerated versions. This is indicated by additional letters in
parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
OPT.
"none"_dihedral_none.html,
"zero"_dihedral_zero.html,
"hybrid"_dihedral_hybrid.html :tb(c=3,ea=c)
"charmm (iko)"_dihedral_charmm.html,
"charmmfsw"_dihedral_charmm.html,
"class2 (ko)"_dihedral_class2.html,
"cosine/shift/exp (o)"_dihedral_cosine_shift_exp.html,
"fourier (io)"_dihedral_fourier.html,
"harmonic (io)"_dihedral_harmonic.html,
"helix (o)"_dihedral_helix.html,
"multi/harmonic (o)"_dihedral_multi_harmonic.html,
"nharmonic (o)"_dihedral_nharmonic.html,
"opls (iko)"_dihedral_opls.htm;,
"quadratic (o)"_dihedral_quadratic.html,
"spherical (o)"_dihedral_spherical.html,
"table (o)"_dihedral_table.html,
"table/cut"_dihedral_table_cut.html :tb(c=4,ea=c)
:line
Improper_style potentials :h3,link(improper)
All LAMMPS "improper_style"_improper_style.html commands. Some styles
have accelerated versions. This is indicated by additional letters in
parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
OPT.
"none"_improper_none.html,
"zero"_improper_zero.html,
"hybrid"_improper_hybrid.html :tb(c=3,ea=c)
"class2 (ko)"_improper_class2.html,
"cossq (o)"_improper_cossq.html,
"cvff (io)"_improper_cvff.html,
"distance"_improper_distance.html,
"fourier (o)"_improper_fourier.html,
"harmonic (iko)"_improper_harmonic.html,
"ring (o)"_improper_ring.html,
"umbrella (o)"_improper_umbrella.html :tb(c=4,ea=c)

141
doc/src/Commands_category.txt Normal file
View File

@ -0,0 +1,141 @@
"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Commands by category :h3
This page lists most of the LAMMPS commands, grouped by category. The
"Commands all"_Commands_all.html doc page lists all commands
alphabetically. It also includes long lists of style options for
entries that appear in the following categories as a single command
(fix, compute, pair, etc).
Initialization:
"newton"_newton.html,
"package"_package.html,
"processors"_processors.html,
"suffix"_suffix.html,
"units"_units.html :ul
Setup simulation box:
"boundary"_boundary.html,
"box"_box.html,
"change_box"_change_box.html,
"create_box"_create_box.html,
"dimension"_dimension.html,
"lattice"_lattice.html,
"region"_region.html :ul
Setup atoms:
"atom_modify"_atom_modify.html,
"atom_style"_atom_style.html,
"balance"_balance.html,
"create_atoms"_create_atoms.html,
"create_bonds"_create_bonds.html,
"delete_atoms"_delete_atoms.html,
"delete_bonds"_delete_bonds.html,
"displace_atoms"_displace_atoms.html,
"group"_group.html,
"mass"_mass.html,
"molecule"_molecule.html,
"read_data"_read_data.html,
"read_dump"_read_dump.html,
"read_restart"_read_restart.html,
"replicate"_replicate.html,
"set"_set.html,
"velocity"_velocity.html :ul
Force fields:
"angle_coeff"_angle_coeff.html,
"angle_style"_angle_style.html,
"bond_coeff"_bond_coeff.html,
"bond_style"_bond_style.html,
"bond_write"_bond_write.html,
"dielectric"_dielectric.html,
"dihedral_coeff"_dihedral_coeff.html,
"dihedral_style"_dihedral_style.html,
"improper_coeff"_improper_coeff.html,
"improper_style"_improper_style.html,
"kspace_modify"_kspace_modify.html,
"kspace_style"_kspace_style.html,
"pair_coeff"_pair_coeff.html,
"pair_modify"_pair_modify.html,
"pair_style"_pair_style.html,
"pair_write"_pair_write.html,
"special_bonds"_special_bonds.html :ul
Settings:
"comm_modify"_comm_modify.html,
"comm_style"_comm_style.html,
"info"_info.html,
"min_modify"_min_modify.html,
"min_style"_min_style.html,
"neigh_modify"_neigh_modify.html,
"neighbor"_neighbor.html,
"partition"_partition.html,
"reset_timestep"_reset_timestep.html,
"run_style"_run_style.html,
"timer"_timer.html,
"timestep"_timestep.html :ul
Operations within timestepping (fixes) and diagnostics (computes):
"compute"_compute.html,
"compute_modify"_compute_modify.html,
"fix"_fix.html,
"fix_modify"_fix_modify.html,
"uncompute"_uncompute.html,
"unfix"_unfix.html :ul
Output:
"dump image"_dump_image.html,
"dump movie"_dump_image.html,
"dump"_dump.html,
"dump_modify"_dump_modify.html,
"restart"_restart.html,
"thermo"_thermo.html,
"thermo_modify"_thermo_modify.html,
"thermo_style"_thermo_style.html,
"undump"_undump.html,
"write_coeff"_write_coeff.html,
"write_data"_write_data.html,
"write_dump"_write_dump.html,
"write_restart"_write_restart.html :ul
Actions:
"minimize"_minimize.html,
"neb"_neb.html,
"prd"_prd.html,
"rerun"_rerun.html,
"run"_run.html,
"tad"_tad.html,
"temper"_temper.html :ul
Input script control:
"clear"_clear.html,
"echo"_echo.html,
"if"_if.html,
"include"_include.html,
"jump"_jump.html,
"label"_label.html,
"log"_log.html,
"next"_next.html,
"print"_print.html,
"python"_python.html,
"quit"_quit.html,
"shell"_shell.html,
"variable"_variable.html :ul

153
doc/src/Commands_compute.txt Normal file
View File

@ -0,0 +1,153 @@
"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
"All commands"_Commands_all.html,
"Fix styles"_Commands_fix.html,
"Compute styles"_Commands_compute.html,
"Pair styles"_Commands_pair.html,
"Bond styles"_Commands_bond.html,
"Angle styles"_Commands_bond.html#angle,
"Dihedral styles"_Commands_bond.html#dihedral,
"Improper styles"_Commands_bond.html#improper,
"KSpace styles"_Commands_kspace.html :tb(c=3,ea=c)
Compute commands :h3
An alphabetic list of all LAMMPS "compute"_compute.html commands.
Some styles have accelerated versions. This is indicated by
additional letters in parenthesis: g = GPU, i = USER-INTEL, k =
KOKKOS, o = USER-OMP, t = OPT.
"ackland/atom"_compute_ackland_atom.html,
"aggregate/atom"_compute_cluster_atom.html,
"angle"_compute_angle.html,
"angle/local"_compute_angle_local.html,
"angmom/chunk"_compute_angmom_chunk.html,
"basal/atom"_compute_basal_atom.html,
"body/local"_compute_body_local.html,
"bond"_compute_bond.html,
"bond/local"_compute_bond_local.html,
"centro/atom"_compute_centro_atom.html,
"chunk/atom"_compute_chunk_atom.html,
"cluster/atom"_compute_cluster_atom.html,
"cna/atom"_compute_cna_atom.html,
"cnp/atom"_compute_cnp_atom.html,
"com"_compute_com.html,
"com/chunk"_compute_com_chunk.html,
"contact/atom"_compute_contact_atom.html,
"coord/atom"_compute_coord_atom.html,
"damage/atom"_compute_damage_atom.html,
"dihedral"_compute_dihedral.html,
"dihedral/local"_compute_dihedral_local.html,
"dilatation/atom"_compute_dilatation_atom.html,
"dipole/chunk"_compute_dipole_chunk.html,
"displace/atom"_compute_displace_atom.html,
"dpd"_compute_dpd.html,
"dpd/atom"_compute_dpd_atom.html,
"edpd/temp/atom"_compute_edpd_temp_atom.html,
"entropy/atom"_compute_entropy_atom.html,
"erotate/asphere"_compute_erotate_asphere.html,
"erotate/rigid"_compute_erotate_rigid.html,
"erotate/sphere"_compute_erotate_sphere.html,
"erotate/sphere/atom"_compute_erotate_sphere_atom.html,
"event/displace"_compute_event_displace.html,
"fep"_compute_fep.html,
"force/tally"_compute_tally.html,
"fragment/atom"_compute_cluster_atom.html,
"global/atom"_compute_global_atom.html,
"group/group"_compute_group_group.html,
"gyration"_compute_gyration.html,
"gyration/chunk"_compute_gyration_chunk.html,
"heat/flux"_compute_heat_flux.html,
"heat/flux/tally"_compute_tally.html,
"hexorder/atom"_compute_hexorder_atom.html,
"improper"_compute_improper.html,
"improper/local"_compute_improper_local.html,
"inertia/chunk"_compute_inertia_chunk.html,
"ke"_compute_ke.html,
"ke/atom"_compute_ke_atom.html,
"ke/atom/eff"_compute_ke_atom_eff.html,
"ke/eff"_compute_ke_eff.html,
"ke/rigid"_compute_ke_rigid.html,
"meso/e/atom"_compute_meso_e_atom.html,
"meso/rho/atom"_compute_meso_rho_atom.html,
"meso/t/atom"_compute_meso_t_atom.html,
"msd"_compute_msd.html,
"msd/chunk"_compute_msd_chunk.html,
"msd/nongauss"_compute_msd_nongauss.html,
"omega/chunk"_compute_omega_chunk.html,
"orientorder/atom"_compute_orientorder_atom.html,
"pair"_compute_pair.html,
"pair/local"_compute_pair_local.html,
"pe"_compute_pe.html,
"pe/atom"_compute_pe_atom.html,
"pe/mol/tally"_compute_tally.html,
"pe/tally"_compute_tally.html,
"plasticity/atom"_compute_plasticity_atom.html,
"pressure"_compute_pressure.html,
"pressure/uef"_compute_pressure_uef.html,
"property/atom"_compute_property_atom.html,
"property/chunk"_compute_property_chunk.html,
"property/local"_compute_property_local.html,
"rdf"_compute_rdf.html,
"reduce"_compute_reduce.html,
"reduce/region"_compute_reduce.html,
"rigid/local"_compute_rigid_local.html,
"saed"_compute_saed.html,
"slice"_compute_slice.html,
"smd/contact/radius"_compute_smd_contact_radius.html,
"smd/damage"_compute_smd_damage.html,
"smd/hourglass/error"_compute_smd_hourglass_error.html,
"smd/internal/energy"_compute_smd_internal_energy.html,
"smd/plastic/strain"_compute_smd_plastic_strain.html,
"smd/plastic/strain/rate"_compute_smd_plastic_strain_rate.html,
"smd/rho"_compute_smd_rho.html,
"smd/tlsph/defgrad"_compute_smd_tlsph_defgrad.html,
"smd/tlsph/dt"_compute_smd_tlsph_dt.html,
"smd/tlsph/num/neighs"_compute_smd_tlsph_num_neighs.html,
"smd/tlsph/shape"_compute_smd_tlsph_shape.html,
"smd/tlsph/strain"_compute_smd_tlsph_strain.html,
"smd/tlsph/strain/rate"_compute_smd_tlsph_strain_rate.html,
"smd/tlsph/stress"_compute_smd_tlsph_stress.html,
"smd/triangle/mesh/vertices"_compute_smd_triangle_mesh_vertices.html,
"smd/ulsph/num/neighs"_compute_smd_ulsph_num_neighs.html,
"smd/ulsph/strain"_compute_smd_ulsph_strain.html,
"smd/ulsph/strain/rate"_compute_smd_ulsph_strain_rate.html,
"smd/ulsph/stress"_compute_smd_ulsph_stress.html,
"smd/vol"_compute_smd_vol.html,
"sna/atom"_compute_sna_atom.html,
"snad/atom"_compute_sna_atom.html,
"snav/atom"_compute_sna_atom.html,
"spin"_compute_spin.html,
"stress/atom"_compute_stress_atom.html,
"stress/tally"_compute_tally.html,
"tdpd/cc/atom"_compute_tdpd_cc_atom.html,
"temp (k)"_compute_temp.html,
"temp/asphere"_compute_temp_asphere.html,
"temp/body"_compute_temp_body.html,
"temp/chunk"_compute_temp_chunk.html,
"temp/com"_compute_temp_com.html,
"temp/deform"_compute_temp_deform.html,
"temp/deform/eff"_compute_temp_deform_eff.html,
"temp/drude"_compute_temp_drude.html,
"temp/eff"_compute_temp_eff.html,
"temp/partial"_compute_temp_partial.html,
"temp/profile"_compute_temp_profile.html,
"temp/ramp"_compute_temp_ramp.html,
"temp/region"_compute_temp_region.html,
"temp/region/eff"_compute_temp_region_eff.html,
"temp/rotate"_compute_temp_rotate.html,
"temp/sphere"_compute_temp_sphere.html,
"temp/uef"_compute_temp_uef.html,
"ti"_compute_ti.html,
"torque/chunk"_compute_torque_chunk.html,
"vacf"_compute_vacf.html,
"vcm/chunk"_compute_vcm_chunk.html,
"voronoi/atom"_compute_voronoi_atom.html,
"xrd"_compute_xrd.html :tb(c=6,ea=c)

229
doc/src/Commands_fix.txt Normal file
View File

@ -0,0 +1,229 @@
"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
"All commands"_Commands_all.html,
"Fix styles"_Commands_fix.html,
"Compute styles"_Commands_compute.html,
"Pair styles"_Commands_pair.html,
"Bond styles"_Commands_bond.html,
"Angle styles"_Commands_bond.html#angle,
"Dihedral styles"_Commands_bond.html#dihedral,
"Improper styles"_Commands_bond.html#improper,
"KSpace styles"_Commands_kspace.html :tb(c=3,ea=c)
Fix commands :h3
An alphabetic list of all LAMMPS "fix"_fix.html commands. Some styles
have accelerated versions. This is indicated by additional letters in
parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
OPT.
"adapt"_fix_adapt.html,
"adapt/fep"_fix_adapt_fep.html,
"addforce"_fix_addforce.html,
"addtorque"_fix_addtorque.html,
"append/atoms"_fix_append_atoms.html,
"atc"_fix_atc.html,
"atom/swap"_fix_atom_swap.html,
"ave/atom"_fix_ave_atom.html,
"ave/chunk"_fix_ave_chunk.html,
"ave/correlate"_fix_ave_correlate.html,
"ave/correlate/long"_fix_ave_correlate_long.html,
"ave/histo"_fix_ave_histo.html,
"ave/histo/weight"_fix_ave_histo.html,
"ave/time"_fix_ave_time.html,
"aveforce"_fix_aveforce.html,
"balance"_fix_balance.html,
"bond/break"_fix_bond_break.html,
"bond/create"_fix_bond_create.html,
"bond/react"_fix_bond_react.html,
"bond/swap"_fix_bond_swap.html,
"box/relax"_fix_box_relax.html,
"cmap"_fix_cmap.html,
"colvars"_fix_colvars.html,
"controller"_fix_controller.html,
"deform (k)"_fix_deform.html,
"deposit"_fix_deposit.html,
"dpd/energy (k)"_fix_dpd_energy.html,
"drag"_fix_drag.html,
"drude"_fix_drude.html,
"drude/transform/direct"_fix_drude_transform.html,
"drude/transform/reverse"_fix_drude_transform.html,
"dt/reset"_fix_dt_reset.html,
"edpd/source"_fix_dpd_source.html,
"efield"_fix_efield.html,
"ehex"_fix_ehex.html,
"enforce2d (k)"_fix_enforce2d.html,
"eos/cv"_fix_eos_cv.html,
"eos/table"_fix_eos_table.html,
"eos/table/rx (k)"_fix_eos_table_rx.html,
"evaporate"_fix_evaporate.html,
"external"_fix_external.html,
"filter/corotate"_fix_filter_corotate.html,
"flow/gauss"_fix_flow_gauss.html,
"freeze"_fix_freeze.html,
"gcmc"_fix_gcmc.html,
"gld"_fix_gld.html,
"gle"_fix_gle.html,
"gravity (o)"_fix_gravity.html,
"grem"_fix_grem.html,
"halt"_fix_halt.html,
"heat"_fix_heat.html,
"imd"_fix_imd.html,
"indent"_fix_indent.html,
"ipi"_fix_ipi.html,
"langevin (k)"_fix_langevin.html,
"langevin/drude"_fix_langevin_drude.html,
"langevin/eff"_fix_langevin_eff.html,
"langevin/spin"_fix_langevin_spin.html,
"latte"_fix_latte.html,
"lb/fluid"_fix_lb_fluid.html,
"lb/momentum"_fix_lb_momentum.html,
"lb/pc"_fix_lb_pc.html,
"lb/rigid/pc/sphere"_fix_lb_rigid_pc_sphere.html,
"lb/viscous"_fix_lb_viscous.html,
"lineforce"_fix_lineforce.html,
"manifoldforce"_fix_manifoldforce.html,
"meso"_fix_meso.html,
"meso/stationary"_fix_meso_stationary.html,
"momentum (k)"_fix_momentum.html,
"move"_fix_move.html,
"mscg"_fix_mscg.html,
"msst"_fix_msst.html,
"mvv/dpd"_fix_mvv_dpd.html,
"mvv/edpd"_fix_mvv_dpd.html,
"mvv/tdpd"_fix_mvv_dpd.html,
"neb"_fix_neb.html,
"nph (ko)"_fix_nh.html,
"nph/asphere (o)"_fix_nph_asphere.html,
"nph/body"_fix_nph_body.html,
"nph/eff"_fix_nh_eff.html,
"nph/sphere (o)"_fix_nph_sphere.html,
"nphug (o)"_fix_nphug.html,
"npt (kio)"_fix_nh.html,
"npt/asphere (o)"_fix_npt_asphere.html,
"npt/body"_fix_npt_body.html,
"npt/eff"_fix_nh_eff.html,
"npt/sphere (o)"_fix_npt_sphere.html,
"npt/uef"_fix_nh_uef.html,
"nve (kio)"_fix_nve.html,
"nve/asphere (i)"_fix_nve_asphere.html,
"nve/asphere/noforce"_fix_nve_asphere_noforce.html,
"nve/body"_fix_nve_body.html,
"nve/dot"_fix_nve_dot.html,
"nve/dotc/langevin"_fix_nve_dotc_langevin.html,
"nve/eff"_fix_nve_eff.html,
"nve/limit"_fix_nve_limit.html,
"nve/line"_fix_nve_line.html,
"nve/manifold/rattle"_fix_nve_manifold_rattle.html,
"nve/noforce"_fix_nve_noforce.html,
"nve/sphere (o)"_fix_nve_sphere.html,
"nve/spin"_fix_nve_spin.html,
"nve/tri"_fix_nve_tri.html,
"nvk"_fix_nvk.html,
"nvt (iko)"_fix_nh.html,
"nvt/asphere (o)"_fix_nvt_asphere.html,
"nvt/body"_fix_nvt_body.html,
"nvt/eff"_fix_nh_eff.html,
"nvt/manifold/rattle"_fix_nvt_manifold_rattle.html,
"nvt/sllod (io)"_fix_nvt_sllod.html,
"nvt/sllod/eff"_fix_nvt_sllod_eff.html,
"nvt/sphere (o)"_fix_nvt_sphere.html,
"nvt/uef"_fix_nh_uef.html,
"oneway"_fix_oneway.html,
"orient/bcc"_fix_orient.html,
"orient/fcc"_fix_orient.html,
"phonon"_fix_phonon.html,
"pimd"_fix_pimd.html,
"planeforce"_fix_planeforce.html,
"poems"_fix_poems.html,
"pour"_fix_pour.html,
"precession/spin"_fix_precession_spin.html,
"press/berendsen"_fix_press_berendsen.html,
"print"_fix_print.html,
"property/atom (k)"_fix_property_atom.html,
"python/invoke"_fix_python_invoke.html,
"python/move"_fix_python_move.html,
"qbmsst"_fix_qbmsst.html,
"qeq/comb (o)"_fix_qeq_comb.html,
"qeq/dynamic"_fix_qeq.html,
"qeq/fire"_fix_qeq.html,
"qeq/point"_fix_qeq.html,
"qeq/reax (ko)"_fix_qeq_reax.html,
"qeq/shielded"_fix_qeq.html,
"qeq/slater"_fix_qeq.html,
"qmmm"_fix_qmmm.html,
"qtb"_fix_qtb.html,
"rattle"_fix_shake.html,
"reax/bonds"_fix_reax_bonds.html,
"reax/c/bonds (k)"_fix_reax_bonds.html,
"reax/c/species (k)"_fix_reaxc_species.html,
"recenter"_fix_recenter.html,
"restrain"_fix_restrain.html,
"rhok"_fix_rhok.html,
"rigid (o)"_fix_rigid.html,
"rigid/nph (o)"_fix_rigid.html,
"rigid/npt (o)"_fix_rigid.html,
"rigid/nve (o)"_fix_rigid.html,
"rigid/nvt (o)"_fix_rigid.html,
"rigid/small (o)"_fix_rigid.html,
"rigid/small/nph"_fix_rigid.html,
"rigid/small/npt"_fix_rigid.html,
"rigid/small/nve"_fix_rigid.html,
"rigid/small/nvt"_fix_rigid.html,
"rx (k)"_fix_rx.html,
"saed/vtk"_fix_saed_vtk.html,
"setforce (k)"_fix_setforce.html,
"shake"_fix_shake.html,
"shardlow (k)"_fix_shardlow.html,
"smd"_fix_smd.html,
"smd/adjust/dt"_fix_smd_adjust_dt.html,
"smd/integrate/tlsph"_fix_smd_integrate_tlsph.html,
"smd/integrate/ulsph"_fix_smd_integrate_ulsph.html,
"smd/move/triangulated/surface"_fix_smd_move_triangulated_surface.html,
"smd/setvel"_fix_smd_setvel.html,
"smd/wall/surface"_fix_smd_wall_surface.html,
"spring"_fix_spring.html,
"spring/chunk"_fix_spring_chunk.html,
"spring/rg"_fix_spring_rg.html,
"spring/self"_fix_spring_self.html,
"srd"_fix_srd.html,
"store/force"_fix_store_force.html,
"store/state"_fix_store_state.html,
"tdpd/source"_fix_dpd_source.html,
"temp/berendsen"_fix_temp_berendsen.html,
"temp/csld"_fix_temp_csvr.html,
"temp/csvr"_fix_temp_csvr.html,
"temp/rescale"_fix_temp_rescale.html,
"temp/rescale/eff"_fix_temp_rescale_eff.html,
"tfmc"_fix_tfmc.html,
"thermal/conductivity"_fix_thermal_conductivity.html,
"ti/spring"_fix_ti_spring.html,
"tmd"_fix_tmd.html,
"ttm"_fix_ttm.html,
"ttm/mod"_fix_ttm.html,
"tune/kspace"_fix_tune_kspace.html,
"vector"_fix_vector.html,
"viscosity"_fix_viscosity.html,
"viscous"_fix_viscous.html,
"wall/body/polygon"_fix_wall_body_polygon.html,
"wall/body/polyhedron"_fix_wall_body_polyhedron.html,
"wall/colloid"_fix_wall.html,
"wall/ees"_fix_wall_ees.html,
"wall/gran"_fix_wall_gran.html,
"wall/gran/region"_fix_wall_gran_region.html,
"wall/harmonic"_fix_wall.html,
"wall/lj1043"_fix_wall.html,
"wall/lj126"_fix_wall.html,
"wall/lj93 (k)"_fix_wall.html,
"wall/piston"_fix_wall_piston.html,
"wall/reflect (k)"_fix_wall_reflect.html,
"wall/region"_fix_wall_region.html,
"wall/region/ees"_fix_wall_ees.html,
"wall/srd"_fix_wall_srd.html :tb(c=8,ea=c)

60
doc/src/Commands_input.txt Normal file
View File

@ -0,0 +1,60 @@
"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
LAMMPS input scripts :h3
LAMMPS executes by reading commands from a input script (text file),
one line at a time. When the input script ends, LAMMPS exits. Each
command causes LAMMPS to take some action. It may set an internal
variable, read in a file, or run a simulation. Most commands have
default settings, which means you only need to use the command if you
wish to change the default.
In many cases, the ordering of commands in an input script is not
important. However the following rules apply:
(1) LAMMPS does not read your entire input script and then perform a
simulation with all the settings. Rather, the input script is read
one line at a time and each command takes effect when it is read.
Thus this sequence of commands:
timestep 0.5
run 100
run 100 :pre
does something different than this sequence:
run 100
timestep 0.5
run 100 :pre
In the first case, the specified timestep (0.5 fs) is used for two
simulations of 100 timesteps each. In the 2nd case, the default
timestep (1.0 fs) is used for the 1st 100 step simulation and a 0.5 fs
timestep is used for the 2nd one.
(2) Some commands are only valid when they follow other commands. For
example you cannot set the temperature of a group of atoms until atoms
have been defined and a group command is used to define which atoms
belong to the group.
(3) Sometimes command B will use values that can be set by command A.
This means command A must precede command B in the input script if it
is to have the desired effect. For example, the
"read_data"_read_data.html command initializes the system by setting
up the simulation box and assigning atoms to processors. If default
values are not desired, the "processors"_processors.html and
"boundary"_boundary.html commands need to be used before read_data to
tell LAMMPS how to map processors to the simulation box.
Many input script errors are detected by LAMMPS and an ERROR or
WARNING message is printed. The "Errors"_Errors.html doc page gives
more information on what errors mean. The documentation for each
command lists restrictions on how the command can be used.

36
doc/src/Commands_kspace.txt Normal file
View File

@ -0,0 +1,36 @@
"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands.html)
:line
"All commands"_Commands_all.html,
"Fix styles"_Commands_fix.html,
"Compute styles"_Commands_compute.html,
"Pair styles"_Commands_pair.html,
"Bond styles"_Commands_bond.html,
"Angle styles"_Commands_bond.html#angle,
"Dihedral styles"_Commands_bond.html#dihedral,
"Improper styles"_Commands_bond.html#improper,
"KSpace styles"_Commands_kspace.html :tb(c=3,ea=c)
KSpace solvers :h3
All LAMMPS "kspace_style"_kspace_style.html solvers. Some styles have
accelerated versions. This is indicated by additional letters in
parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
OPT.
"ewald (o)"_kspace_style.html,
"ewald/disp"_kspace_style.html,
"msm (o)"_kspace_style.html,
"msm/cg (o)"_kspace_style.html,
"pppm (gok)"_kspace_style.html,
"pppm/cg (o)"_kspace_style.html,
"pppm/disp (i)"_kspace_style.html,
"pppm/disp/tip4p"_kspace_style.html,
"pppm/stagger"_kspace_style.html,
"pppm/tip4p (o)"_kspace_style.html :tb(c=4,ea=c)

231
doc/src/Commands_pair.txt Normal file
View File

@ -0,0 +1,231 @@
"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
"All commands"_Commands_all.html,
"Fix styles"_Commands_fix.html,
"Compute styles"_Commands_compute.html,
"Pair styles"_Commands_pair.html,
"Bond styles"_Commands_bond.html,
"Angle styles"_Commands_bond.html#angle,
"Dihedral styles"_Commands_bond.html#dihedral,
"Improper styles"_Commands_bond.html#improper,
"KSpace styles"_Commands_kspace.html :tb(c=3,ea=c)
Pair_style potentials :h3
All LAMMPS "pair_style"_pair_style.html commands. Some styles have
accelerated versions. This is indicated by additional letters in
parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
OPT.
"none"_pair_none.html,
"zero"_pair_zero.html,
"hybrid"_pair_hybrid.html,
"hybrid/overlay (k)"_pair_hybrid.html :tb(c=4,ea=c)
"adp (o)"_pair_adp.html,
"agni (o)"_pair_agni.html,
"airebo (oi)"_pair_airebo.html,
"airebo/morse (oi)"_pair_airebo.html,
"awpmd/cut"_pair_awpmd.html,
"beck (go)"_pair_beck.html,
"body/nparticle"_pair_body_nparticle.html,
"body/rounded/polygon"_pair_body_rounded_polygon.html,
"body/rounded/polyhedron"_pair_body_rounded_polyhedron.html,
"bop"_pair_bop.html,
"born (go)"_pair_born.html,
"born/coul/dsf"_pair_born.html,
"born/coul/dsf/cs"_pair_born.html,
"born/coul/long (go)"_pair_born.html,
"born/coul/long/cs"_pair_born.html,
"born/coul/msm (o)"_pair_born.html,
"born/coul/wolf (go)"_pair_born.html,
"born/coul/wolf/cs"_pair_born.html,
"brownian (o)"_pair_brownian.html,
"brownian/poly (o)"_pair_brownian.html,
"buck (giko)"_pair_buck.html,
"buck/coul/cut (giko)"_pair_buck.html,
"buck/coul/long (giko)"_pair_buck.html,
"buck/coul/long/cs"_pair_buck.html,
"buck/coul/msm (o)"_pair_buck.html,
"buck/long/coul/long (o)"_pair_buck_long.html,
"buck/mdf"_pair_mdf.html,
"colloid (go)"_pair_colloid.html,
"comb (o)"_pair_comb.html,
"comb3"_pair_comb.html,
"coul/cut (gko)"_pair_coul.html,
"coul/cut/soft (o)"_pair_lj_soft.html,
"coul/debye (gko)"_pair_coul.html,
"coul/diel (o)"_pair_coul_diel.html,
"coul/dsf (gko)"_pair_coul.html,
"coul/long (gko)"_pair_coul.html,
"coul/long/cs"_pair_coul.html,
"coul/long/soft (o)"_pair_lj_soft.html,
"coul/msm"_pair_coul.html,
"coul/shield"_pair_coul_shield.html,
"coul/streitz"_pair_coul.html,
"coul/wolf (ko)"_pair_coul.html,
"coul/wolf/cs"_pair_coul.html,
"dpd (gio)"_pair_dpd.html,
"dpd/fdt"_pair_dpd_fdt.html,
"dpd/fdt/energy (k)"_pair_dpd_fdt.html,
"dpd/tstat (go)"_pair_dpd.html,
"dsmc"_pair_dsmc.html,
"eam (gikot)"_pair_eam.html,
"eam/alloy (gikot)"_pair_eam.html,
"eam/cd (o)"_pair_eam.html,
"eam/fs (gikot)"_pair_eam.html,
"edip (o)"_pair_edip.html,
"edip/multi"_pair_edip.html,
"edpd"_pair_meso.html,
"eff/cut"_pair_eff.html,
"eim (o)"_pair_eim.html,
"exp6/rx (k)"_pair_exp6_rx.html,
"extep"_pair_extep.html,
"gauss (go)"_pair_gauss.html,
"gauss/cut"_pair_gauss.html,
"gayberne (gio)"_pair_gayberne.html,
"gran/hertz/history (o)"_pair_gran.html,
"gran/hooke (o)"_pair_gran.html,
"gran/hooke/history (o)"_pair_gran.html,
"gw"_pair_gw.html,
"gw/zbl"_pair_gw.html,
"hbond/dreiding/lj (o)"_pair_hbond_dreiding.html,
"hbond/dreiding/morse (o)"_pair_hbond_dreiding.html,
"ilp/graphene/hbn"_pair_ilp_graphene_hbn.html,
"kim"_pair_kim.html,
"kolmogorov/crespi/full"_pair_kolmogorov_crespi_full.html,
"kolmogorov/crespi/z"_pair_kolmogorov_crespi_z.html,
"lcbop"_pair_lcbop.html,
"lennard/mdf"_pair_mdf.html,
"line/lj"_pair_line_lj.html,
"list"_pair_list.html,
"lj/charmm/coul/charmm (iko)"_pair_charmm.html,
"lj/charmm/coul/charmm/implicit (ko)"_pair_charmm.html,
"lj/charmm/coul/long (giko)"_pair_charmm.html,
"lj/charmm/coul/long/soft (o)"_pair_charmm.html,
"lj/charmm/coul/msm"_pair_charmm.html,
"lj/charmmfsw/coul/charmmfsh"_pair_charmm.html,
"lj/charmmfsw/coul/long"_pair_charmm.html,
"lj/class2 (gko)"_pair_class2.html,
"lj/class2/coul/cut (ko)"_pair_class2.html,
"lj/class2/coul/long (gko)"_pair_class2.html,
"lj/cubic (go)"_pair_lj_cubic.html,
"lj/cut (gikot)"_pair_lj.html,
"lj/cut/coul/cut (gko)"_pair_lj.html,
"lj/cut/coul/cut/soft (o)"_pair_lj_soft.html,
"lj/cut/coul/debye (gko)"_pair_lj.html,
"lj/cut/coul/dsf (gko)"_pair_lj.html,
"lj/cut/coul/long (gikot)"_pair_lj.html,
"lj/cut/coul/long/cs"_pair_lj.html,
"lj/cut/coul/long/soft (o)"_pair_lj_soft.html,
"lj/cut/coul/msm (go)"_pair_lj.html,
"lj/cut/coul/wolf (o)"_pair_lj.html,
"lj/cut/dipole/cut (go)"_pair_dipole.html,
"lj/cut/dipole/long"_pair_dipole.html,
"lj/cut/dipole/sf (go)"_pair_dipole.html,
"lj/cut/soft (o)"_pair_lj_soft.html,
"lj/cut/thole/long (o)"_pair_thole.html,
"lj/cut/tip4p/cut (o)"_pair_lj.html,
"lj/cut/tip4p/long (ot)"_pair_lj.html,
"lj/cut/tip4p/long/soft (o)"_pair_lj_soft.html,
"lj/expand (gko)"_pair_lj_expand.html,
"lj/gromacs (gko)"_pair_gromacs.html,
"lj/gromacs/coul/gromacs (ko)"_pair_gromacs.html,
"lj/long/coul/long (io)"_pair_lj_long.html,
"lj/long/dipole/long"_pair_dipole.html,
"lj/long/tip4p/long"_pair_lj_long.html,
"lj/mdf"_pair_mdf.html,
"lj/sdk (gko)"_pair_sdk.html,
"lj/sdk/coul/long (go)"_pair_sdk.html,
"lj/sdk/coul/msm (o)"_pair_sdk.html,
"lj/smooth (o)"_pair_lj_smooth.html,
"lj/smooth/linear (o)"_pair_lj_smooth_linear.html,
"lj96/cut (go)"_pair_lj96.html,
"lubricate (o)"_pair_lubricate.html,
"lubricate/poly (o)"_pair_lubricate.html,
"lubricateU"_pair_lubricateU.html,
"lubricateU/poly"_pair_lubricateU.html,
"mdpd"_pair_meso.html,
"mdpd/rhosum"_pair_meso.html,
"meam"_pair_meam.html,
"meam/c"_pair_meam.html,
"meam/spline (o)"_pair_meam_spline.html,
"meam/sw/spline"_pair_meam_sw_spline.html,
"mgpt"_pair_mgpt.html,
"mie/cut (o)"_pair_mie.html,
"momb"_pair_momb.html,
"morse (gkot)"_pair_morse.html,
"morse/smooth/linear"_pair_morse.html,
"morse/soft"_pair_morse.html,
"multi/lucy"_pair_multi_lucy.html,
"multi/lucy/rx (k)"_pair_multi_lucy_rx.html,
"nb3b/harmonic (o)"_pair_nb3b_harmonic.html,
"nm/cut (o)"_pair_nm.html,
"nm/cut/coul/cut (o)"_pair_nm.html,
"nm/cut/coul/long (o)"_pair_nm.html,
"oxdna/coaxstk"_pair_oxdna.html,
"oxdna/excv"_pair_oxdna.html,
"oxdna/hbond"_pair_oxdna.html,
"oxdna/stk"_pair_oxdna.html,
"oxdna/xstk"_pair_oxdna.html,
"oxdna2/coaxstk"_pair_oxdna2.html,
"oxdna2/dh"_pair_oxdna2.html,
"oxdna2/excv"_pair_oxdna2.html,
"oxdna2/stk"_pair_oxdna2.html,
"peri/eps"_pair_peri.html,
"peri/lps (o)"_pair_peri.html,
"peri/pmb (o)"_pair_peri.html,
"peri/ves"_pair_peri.html,
"polymorphic"_pair_polymorphic.html,
"python"_pair_python.html,
"quip"_pair_quip.html,
"reax"_pair_reax.html,
"reax/c (ko)"_pair_reaxc.html,
"rebo (oi)"_pair_airebo.html,
"resquared (go)"_pair_resquared.html,
"smd/hertz"_pair_smd_hertz.html,
"smd/tlsph"_pair_smd_tlsph.html,
"smd/triangulated/surface"_pair_smd_triangulated_surface.html,
"smd/ulsph"_pair_smd_ulsph.html,
"smtbq"_pair_smtbq.html,
"snap (k)"_pair_snap.html,
"snap (k)"_pair_snap.html,
"soft (go)"_pair_soft.html,
"sph/heatconduction"_pair_sph_heatconduction.html,
"sph/idealgas"_pair_sph_idealgas.html,
"sph/lj"_pair_sph_lj.html,
"sph/rhosum"_pair_sph_rhosum.html,
"sph/taitwater"_pair_sph_taitwater.html,
"sph/taitwater/morris"_pair_sph_taitwater_morris.html,
"spin/dmi"_pair_spin_dmi.html,
"spin/exchange"_pair_spin_exchange.html,
"spin/magelec"_pair_spin_magelec.html,
"spin/neel"_pair_spin_neel.html,
"srp"_pair_srp.html,
"sw (giko)"_pair_sw.html,
"table (gko)"_pair_table.html,
"table/rx (k)"_pair_table_rx.html,
"tdpd"_pair_meso.html,
"tersoff (giko)"_pair_tersoff.html,
"tersoff/mod (gko)"_pair_tersoff_mod.html,
"tersoff/mod/c (o)"_pair_tersoff_mod.html,
"tersoff/table (o)"_pair_tersoff.html,
"tersoff/zbl (gko)"_pair_tersoff_zbl.html,
"thole"_pair_thole.html,
"tip4p/cut (o)"_pair_coul.html,
"tip4p/long (o)"_pair_coul.html,
"tip4p/long/soft (o)"_pair_lj_soft.html,
"tri/lj"_pair_tri_lj.html,
"ufm (got)"_pair_ufm.html,
"vashishta (ko)"_pair_vashishta.html,
"vashishta/table (o)"_pair_vashishta.html,
"yukawa (gok)"_pair_yukawa.html,
"yukawa/colloid (go)"_pair_yukawa_colloid.html,
"zbl (gok)"_pair_zbl.html :tb(c=4,ea=c)

136
doc/src/Commands_parse.txt Normal file
View File

@ -0,0 +1,136 @@
"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Parsing rules for input scripts :h3
Each non-blank line in the input script is treated as a command.
LAMMPS commands are case sensitive. Command names are lower-case, as
are specified command arguments. Upper case letters may be used in
file names or user-chosen ID strings.
Here are 6 rulse for how each line in the input script is parsed by
LAMMPS:
(1) If the last printable character on the line is a "&" character,
the command is assumed to continue on the next line. The next line is
concatenated to the previous line by removing the "&" character and
line break. This allows long commands to be continued across two or
more lines. See the discussion of triple quotes in (6) for how to
continue a command across multiple line without using "&" characters.
(2) All characters from the first "#" character onward are treated as
comment and discarded. See an exception in (6). Note that a
comment after a trailing "&" character will prevent the command from
continuing on the next line. Also note that for multi-line commands a
single leading "#" will comment out the entire command.
(3) The line is searched repeatedly for $ characters, which indicate
variables that are replaced with a text string. See an exception in
(6).
If the $ is followed by curly brackets, then the variable name is the
text inside the curly brackets. If no curly brackets follow the $,
then the variable name is the single character immediately following
the $. Thus $\{myTemp\} and $x refer to variable names "myTemp" and
"x".
How the variable is converted to a text string depends on what style
of variable it is; see the "variable"_variable.html doc page for details.
It can be a variable that stores multiple text strings, and return one
of them. The returned text string can be multiple "words" (space
separated) which will then be interpreted as multiple arguments in the
input command. The variable can also store a numeric formula which
will be evaluated and its numeric result returned as a string.
As a special case, if the $ is followed by parenthesis, then the text
inside the parenthesis is treated as an "immediate" variable and
evaluated as an "equal-style variable"_variable.html. This is a way
to use numeric formulas in an input script without having to assign
them to variable names. For example, these 3 input script lines:
variable X equal (xlo+xhi)/2+sqrt(v_area)
region 1 block $X 2 INF INF EDGE EDGE
variable X delete :pre
can be replaced by
region 1 block $((xlo+xhi)/2+sqrt(v_area)) 2 INF INF EDGE EDGE :pre
so that you do not have to define (or discard) a temporary variable X.
Additionally, the "immediate" variable expression may be followed by a
colon, followed by a C-style format string, e.g. ":%f" or ":%.10g".
The format string must be appropriate for a double-precision
floating-point value. The format string is used to output the result
of the variable expression evaluation. If a format string is not
specified a high-precision "%.20g" is used as the default.
This can be useful for formatting print output to a desired precion:
print "Final energy per atom: $(pe/atoms:%10.3f) eV/atom" :pre
Note that neither the curly-bracket or immediate form of variables can
contain nested $ characters for other variables to substitute for.
Thus you cannot do this:
variable a equal 2
variable b2 equal 4
print "B2 = $\{b$a\}" :pre
Nor can you specify this $($x-1.0) for an immediate variable, but
you could use $(v_x-1.0), since the latter is valid syntax for an
"equal-style variable"_variable.html.
See the "variable"_variable.html command for more details of how
strings are assigned to variables and evaluated, and how they can be
used in input script commands.
(4) The line is broken into "words" separated by whitespace (tabs,
spaces). Note that words can thus contain letters, digits,
underscores, or punctuation characters.
(5) The first word is the command name. All successive words in the
line are arguments.
(6) If you want text with spaces to be treated as a single argument,
it can be enclosed in either single or double or triple quotes. A
long single argument enclosed in single or double quotes can span
multiple lines if the "&" character is used, as described above. When
the lines are concatenated together (and the "&" characters and line
breaks removed), the text will become a single line. If you want
multiple lines of an argument to retain their line breaks, the text
can be enclosed in triple quotes, in which case "&" characters are not
needed. For example:
print "Volume = $v"
print 'Volume = $v'
if "$\{steps\} > 1000" then quit
variable a string "red green blue &
purple orange cyan"
print """
System volume = $v
System temperature = $t
""" :pre
In each case, the single, double, or triple quotes are removed when
the single argument they enclose is stored internally.
See the "dump modify format"_dump_modify.html, "print"_print.html,
"if"_if.html, and "python"_python.html commands for examples.
A "#" or "$" character that is between quotes will not be treated as a
comment indicator in (2) or substituted for as a variable in (3).
NOTE: If the argument is itself a command that requires a quoted
argument (e.g. using a "print"_print.html command as part of an
"if"_if.html or "run every"_run.html command), then single, double, or
triple quotes can be nested in the usual manner. See the doc pages
for those commands for examples. Only one of level of nesting is
allowed, but that should be sufficient for most use cases.

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

@ -0,0 +1,95 @@
"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Input script structure :h3
This page describes the structure of a typical LAMMPS input script.
The examples directory in the LAMMPS distribution contains many sample
input scripts; it is discussed on the "Examples"_Examples.html doc
page.
A LAMMPS input script typically has 4 parts:
Initialization
Atom definition
Settings
Run a simulation :ol
The last 2 parts can be repeated as many times as desired. I.e. run a
simulation, change some settings, run some more, etc. Each of the 4
parts is now described in more detail. Remember that almost all
commands need only be used if a non-default value is desired.
(1) Initialization
Set parameters that need to be defined before atoms are created or
read-in from a file.
The relevant commands are "units"_units.html,
"dimension"_dimension.html, "newton"_newton.html,
"processors"_processors.html, "boundary"_boundary.html,
"atom_style"_atom_style.html, "atom_modify"_atom_modify.html.
If force-field parameters appear in the files that will be read, these
commands tell LAMMPS what kinds of force fields are being used:
"pair_style"_pair_style.html, "bond_style"_bond_style.html,
"angle_style"_angle_style.html, "dihedral_style"_dihedral_style.html,
"improper_style"_improper_style.html.
(2) Atom definition
There are 3 ways to define atoms in LAMMPS. Read them in from a data
or restart file via the "read_data"_read_data.html or
"read_restart"_read_restart.html commands. These files can contain
molecular topology information. Or create atoms on a lattice (with no
molecular topology), using these commands: "lattice"_lattice.html,
"region"_region.html, "create_box"_create_box.html,
"create_atoms"_create_atoms.html. The entire set of atoms can be
duplicated to make a larger simulation using the
"replicate"_replicate.html command.
(3) Settings
Once atoms and molecular topology are defined, a variety of settings
can be specified: force field coefficients, simulation parameters,
output options, etc.
Force field coefficients are set by these commands (they can also be
set in the read-in files): "pair_coeff"_pair_coeff.html,
"bond_coeff"_bond_coeff.html, "angle_coeff"_angle_coeff.html,
"dihedral_coeff"_dihedral_coeff.html,
"improper_coeff"_improper_coeff.html,
"kspace_style"_kspace_style.html, "dielectric"_dielectric.html,
"special_bonds"_special_bonds.html.
Various simulation parameters are set by these commands:
"neighbor"_neighbor.html, "neigh_modify"_neigh_modify.html,
"group"_group.html, "timestep"_timestep.html,
"reset_timestep"_reset_timestep.html, "run_style"_run_style.html,
"min_style"_min_style.html, "min_modify"_min_modify.html.
Fixes impose a variety of boundary conditions, time integration, and
diagnostic options. The "fix"_fix.html command comes in many flavors.
Various computations can be specified for execution during a
simulation using the "compute"_compute.html,
"compute_modify"_compute_modify.html, and "variable"_variable.html
commands.
Output options are set by the "thermo"_thermo.html, "dump"_dump.html,
and "restart"_restart.html commands.
(4) Run a simulation
A molecular dynamics simulation is run using the "run"_run.html
command. Energy minimization (molecular statics) is performed using
the "minimize"_minimize.html command. A parallel tempering
(replica-exchange) simulation can be run using the
"temper"_temper.html command.

BIN
doc/src/Eqs/pair_spin_dmi_forces.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 13 KiB

14
doc/src/Eqs/pair_spin_dmi_forces.tex Normal file
View File

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

BIN
doc/src/Eqs/pair_spin_dmi_interaction.jpg
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 6.2 KiB

After

Width:  |  Height:  |  Size: 7.7 KiB

2
doc/src/Eqs/pair_spin_dmi_interaction.tex
View File

@ -5,7 +5,7 @@
\begin{document}
\begin{varwidth}{50in}
\begin{equation}
\bm{H}_{dm} = -\sum_{{ i,j}=1,i\neq j}^{N}
\bm{H}_{dm} = \sum_{{ i,j}=1,i\neq j}^{N}
\left( \vec{e}_{ij} \times \vec{D} \right)
\cdot\left(\vec{s}_{i}\times \vec{s}_{j}\right),
\nonumber

BIN
doc/src/Eqs/pair_spin_exchange_forces.jpg
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 13 KiB

After

Width:  |  Height:  |  Size: 13 KiB

10
doc/src/Eqs/pair_spin_exchange_forces.tex
View File

@ -5,10 +5,12 @@
\begin{document}
\begin{varwidth}{50in}
\begin{equation}
\vec{F}^{i} = \sum_{j}^{Neighbor} \frac{\partial {J} \left(r_{ij} \right)}{
\partial r_{ij}} \left( \vec{s}_{i}\cdot \vec{s}_{j} \right) \vec{r}_{ij}
~~{\rm and}~~ \vec{\omega}^{i} = \frac{1}{\hbar} \sum_{j}^{Neighbor} {J}
\left(r_{ij} \right)\,\vec{s}_{j} \nonumber
\vec{\omega}_{i} = \frac{1}{\hbar} \sum_{j}^{Neighb} {J}
\left(r_{ij} \right)\,\vec{s}_{j}
~~{\rm and}~~
\vec{F}_{i} = \sum_{j}^{Neighb} \frac{\partial {J} \left(r_{ij} \right)}{
\partial r_{ij}} \left( \vec{s}_{i}\cdot \vec{s}_{j} \right) \vec{e}_{ij}
\nonumber
\end{equation}
\end{varwidth}
\end{document}

BIN
doc/src/Eqs/pair_spin_exchange_interaction.jpg
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 6.5 KiB

After

Width:  |  Height:  |  Size: 5.8 KiB

2
doc/src/Eqs/pair_spin_exchange_interaction.tex
View File

@ -5,7 +5,7 @@
\begin{document}
\begin{varwidth}{50in}
\begin{equation}
\bm{H}_{exchange} ~=~ -\sum_{i,j,i\neq j}^{N} {J} \left(r_{ij} \right)\, \vec{s}_{i}\cdot \vec{s}_{j} \nonumber
\bm{H}_{ex} ~=~ -\sum_{i,j,i\neq j}^{N} {J} \left(r_{ij} \right)\, \vec{s}_{i}\cdot \vec{s}_{j} \nonumber
\end{equation}
\end{varwidth}
\end{document}

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

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

35
doc/src/Errors_bugs.txt Normal file
View File

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

123
doc/src/Errors_common.txt Normal file
View File

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

1103
doc/src/Section_errors.txt → doc/src/Errors_messages.txt
View File

File diff suppressed because it is too large Load Diff

934
doc/src/Errors_warnings.txt Normal file
View File

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

22
doc/src/Section_example.txt → doc/src/Examples.txt
View File

@ -1,12 +1,14 @@
"Previous Section"_Section_howto.html - "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Section_perf.html :c
"Previous Section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc - "Next
Section"_Tools.html :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:link(lc,Commands_all.html)
:line
7. Example problems :h2
Example scripts :h3
The LAMMPS distribution includes an examples sub-directory with many
sample problems. Many are 2d models that run quickly are are
@ -46,7 +48,7 @@ Lists of both kinds of directories are given below.
:line
Lowercase directories :h3
Lowercase directories :h4
accelerate: run with various acceleration options (OpenMP, GPU, Phi)
airebo: polyethylene with AIREBO potential
@ -110,10 +112,10 @@ web site.
If you uncomment the "dump image"_dump_image.html line(s) in the input
script a series of JPG images will be produced by the run (assuming
you built LAMMPS with JPG support; see "Section
2.2"_Section_start.html#start_2 for details). These can be viewed
individually or turned into a movie or animated by tools like
ImageMagick or QuickTime or various Windows-based tools. See the
you built LAMMPS with JPG support; see the
"Build_settings"_Build_settings.html doc page for details). These can
be viewed individually or turned into a movie or animated by tools
like ImageMagick or QuickTime or various Windows-based tools. See the
"dump image"_dump_image.html doc page for more details. E.g. this
Imagemagick command would create a GIF file suitable for viewing in a
browser.
@ -122,7 +124,7 @@ browser.
:line
Uppercase directories :h3
Uppercase directories :h4
ASPHERE: various aspherical particle models, using ellipsoids, rigid bodies, line/triangle particles, etc
COUPLE: examples of how to use LAMMPS as a library
@ -141,5 +143,5 @@ The USER directory has a large number of sub-directories which
correspond by name to a USER package. They contain scripts that
illustrate how to use the command(s) provided in that package. Many
of the sub-directories have their own README files which give further
instructions. See the "Section 4"_Section_packages.html doc
instructions. See the "Packages_details"_Packages_details.html doc
page for more info on specific USER packages.

135
doc/src/Howto.txt Normal file
View File

@ -0,0 +1,135 @@
"Previous Section"_Performance.html - "LAMMPS WWW Site"_lws -
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
Section"_Examples.html :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands.html#comm)
:line
How to discussions :h2
These doc pages describe how to perform various tasks with LAMMPS,
both for users and developers. The
"glossary"_http://lammps.sandia.gov website page also lists MD
terminology with links to corresponding LAMMPS manual pages.
The example input scripts included in the examples dir of the LAMMPS
distribution and highlighted on the "Examples"_Examples.html doc page
also show how to setup and run various kinds of simulations.
<!-- RST
.. toctree::
:maxdepth: 1
Howto_github
Howto_pylammps
Howto_bash
.. toctree::
:maxdepth: 1
Howto_restart
Howto_viz
Howto_multiple
Howto_replica
Howto_library
Howto_couple
.. toctree::
:maxdepth: 1
Howto_output
Howto_chunk
.. toctree::
:maxdepth: 1
Howto_2d
Howto_triclinic
Howto_walls
Howto_nemd
Howto_granular
Howto_spherical
Howto_dispersion
.. toctree::
:maxdepth: 1
Howto_temperature
Howto_thermostat
Howto_barostat
Howto_elastic
Howto_kappa
Howto_viscosity
Howto_diffusion
.. toctree::
:maxdepth: 1
Howto_bioFF
Howto_tip3p
Howto_tip4p
Howto_spc
.. toctree::
:maxdepth: 1
Howto_body
Howto_polarizable
Howto_coreshell
Howto_drude
Howto_drude2
Howto_manifold
Howto_spins
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)
"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)
"Body style particles"_Howto_body.html
"Polarizable models"_Howto_polarizable.html
"Adiabatic core/shell model"_Howto_coreshell.html
"Drude induced dipoles"_Howto_drude.html
"Drude induced dipoles (extended)"_Howto_drude2.html
"Manifolds (surfaces)"_Howto_manifold.html
"Magnetic spins"_Howto_spins.html :all(b)
<!-- END_HTML_ONLY -->

48
doc/src/Howto_2d.txt Normal file
View File

@ -0,0 +1,48 @@
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
2d simulations :h3
Use the "dimension"_dimension.html command to specify a 2d simulation.
Make the simulation box periodic in z via the "boundary"_boundary.html
command. This is the default.
If using the "create box"_create_box.html command to define a
simulation box, set the z dimensions narrow, but finite, so that the
create_atoms command will tile the 3d simulation box with a single z
plane of atoms - e.g.
"create box"_create_box.html 1 -10 10 -10 10 -0.25 0.25 :pre
If using the "read data"_read_data.html command to read in a file of
atom coordinates, set the "zlo zhi" values to be finite but narrow,
similar to the create_box command settings just described. For each
atom in the file, assign a z coordinate so it falls inside the
z-boundaries of the box - e.g. 0.0.
Use the "fix enforce2d"_fix_enforce2d.html command as the last
defined fix to insure that the z-components of velocities and forces
are zeroed out every timestep. The reason to make it the last fix is
so that any forces induced by other fixes will be zeroed out.
Many of the example input scripts included in the LAMMPS distribution
are for 2d models.
NOTE: Some models in LAMMPS treat particles as finite-size spheres, as
opposed to point particles. See the "atom_style
sphere"_atom_style.html and "fix nve/sphere"_fix_nve_sphere.html
commands for details. By default, for 2d simulations, such particles
will still be modeled as 3d spheres, not 2d discs (circles), meaning
their moment of inertia will be that of a sphere. If you wish to
model them as 2d discs, see the "set density/disc"_set.html command
and the {disc} option for the "fix nve/sphere"_fix_nve_sphere.html,
"fix nvt/sphere"_fix_nvt_sphere.html, "fix
nph/sphere"_fix_nph_sphere.html, "fix npt/sphere"_fix_npt_sphere.html
commands.

75
doc/src/Howto_barostat.txt Normal file
View File

@ -0,0 +1,75 @@
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Barostats :h3
Barostatting means controlling the pressure in an MD simulation.
"Thermostatting"_Howto_thermostat.html means controlling the
temperature of the particles. Since the pressure includes a kinetic
component due to particle velocities, both these operations require
calculation of the temperature. Typically a target temperature (T)
and/or pressure (P) is specified by the user, and the thermostat or
barostat attempts to equilibrate the system to the requested T and/or
P.
Barostatting in LAMMPS is performed by "fixes"_fix.html. Two
barosttating methods are currently available: Nose-Hoover (npt and
nph) and Berendsen:
"fix npt"_fix_nh.html
"fix npt/sphere"_fix_npt_sphere.html
"fix npt/asphere"_fix_npt_asphere.html
"fix nph"_fix_nh.html
"fix press/berendsen"_fix_press_berendsen.html :ul
The "fix npt"_fix_nh.html commands include a Nose-Hoover thermostat
and barostat. "Fix nph"_fix_nh.html is just a Nose/Hoover barostat;
it does no thermostatting. Both "fix nph"_fix_nh.html and "fix
press/berendsen"_fix_press_berendsen.html can be used in conjunction
with any of the thermostatting fixes.
As with the "thermostats"_Howto_thermostat.html, "fix npt"_fix_nh.html
and "fix nph"_fix_nh.html only use translational motion of the
particles in computing T and P and performing thermo/barostatting.
"Fix npt/sphere"_fix_npt_sphere.html and "fix
npt/asphere"_fix_npt_asphere.html thermo/barostat using not only
translation velocities but also rotational velocities for spherical
and aspherical particles.
All of the barostatting fixes use the "compute
pressure"_compute_pressure.html compute to calculate a current
pressure. By default, this compute is created with a simple "compute
temp"_compute_temp.html (see the last argument of the "compute
pressure"_compute_pressure.html command), which is used to calculated
the kinetic component of the pressure. The barostatting fixes can
also use temperature computes that remove bias for the purpose of
computing the kinetic component which contributes to the current
pressure. See the doc pages for the individual fixes and for the
"fix_modify"_fix_modify.html command for instructions on how to assign
a temperature or pressure compute to a barostatting fix.
NOTE: As with the thermostats, the Nose/Hoover methods ("fix
npt"_fix_nh.html and "fix nph"_fix_nh.html) perform time integration.
"Fix press/berendsen"_fix_press_berendsen.html does NOT, so it should
be used with one of the constant NVE fixes or with one of the NVT
fixes.
Thermodynamic output, which can be setup via the
"thermo_style"_thermo_style.html command, often includes pressure
values. As explained on the doc page for the
"thermo_style"_thermo_style.html command, the default pressure is
setup by the thermo command itself. It is NOT the presure associated
with any barostatting fix you have defined or with any compute you
have defined that calculates a presure. The doc pages for the
barostatting fixes explain the ID of the pressure compute they create.
Thus if you want to view these pressurse, you need to specify them
explicitly via the "thermo_style custom"_thermo_style.html command.
Or you can use the "thermo_modify"_thermo_modify.html command to
re-define what pressure compute is used for default thermodynamic
output.

3
doc/src/tutorial_bash_on_windows.txt → doc/src/Howto_bash.txt Normal file → Executable file
View File

@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:link(lc,Commands_all.html)
:line
@ -10,6 +10,7 @@ Using LAMMPS with Bash on Windows :h3
[written by Richard Berger]
:line
Starting with Windows 10 you can install Linux tools directly in Windows. This
allows you to compile LAMMPS following the same procedure as on a real Ubuntu
Linux installation. Software can be easily installed using the package manager

105
doc/src/Howto_bioFF.txt Normal file
View File

@ -0,0 +1,105 @@
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
CHARMM, AMBER, and DREIDING force fields :h3
A force field has 2 parts: the formulas that define it and the
coefficients used for a particular system. Here we only discuss
formulas implemented in LAMMPS that correspond to formulas commonly
used in the CHARMM, AMBER, and DREIDING force fields. Setting
coefficients is done in the input data file via the
"read_data"_read_data.html command or in the input script with
commands like "pair_coeff"_pair_coeff.html or
"bond_coeff"_bond_coeff.html. See the "Tools"_Tools.html doc page for
additional tools that can use CHARMM or AMBER to assign force field
coefficients and convert their output into LAMMPS input.
See "(MacKerell)"_#howto-MacKerell for a description of the CHARMM force
field. See "(Cornell)"_#howto-Cornell for a description of the AMBER force
field.
:link(charmm,http://www.scripps.edu/brooks)
:link(amber,http://amber.scripps.edu)
These style choices compute force field formulas that are consistent
with common options in CHARMM or AMBER. See each command's
documentation for the formula it computes.
"bond_style"_bond_harmonic.html harmonic
"angle_style"_angle_charmm.html charmm
"dihedral_style"_dihedral_charmm.html charmmfsh
"dihedral_style"_dihedral_charmm.html charmm
"pair_style"_pair_charmm.html lj/charmmfsw/coul/charmmfsh
"pair_style"_pair_charmm.html lj/charmmfsw/coul/long
"pair_style"_pair_charmm.html lj/charmm/coul/charmm
"pair_style"_pair_charmm.html lj/charmm/coul/charmm/implicit
"pair_style"_pair_charmm.html lj/charmm/coul/long :ul
"special_bonds"_special_bonds.html charmm
"special_bonds"_special_bonds.html amber :ul
NOTE: For CHARMM, newer {charmmfsw} or {charmmfsh} styles were
released in March 2017. We recommend they be used instead of the
older {charmm} styles. See discussion of the differences on the "pair
charmm"_pair_charmm.html and "dihedral charmm"_dihedral_charmm.html
doc pages.
DREIDING is a generic force field developed by the "Goddard
group"_http://www.wag.caltech.edu at Caltech and is useful for
predicting structures and dynamics of organic, biological and
main-group inorganic molecules. The philosophy in DREIDING is to use
general force constants and geometry parameters based on simple
hybridization considerations, rather than individual force constants
and geometric parameters that depend on the particular combinations of
atoms involved in the bond, angle, or torsion terms. DREIDING has an
"explicit hydrogen bond term"_pair_hbond_dreiding.html to describe
interactions involving a hydrogen atom on very electronegative atoms
(N, O, F).
See "(Mayo)"_#howto-Mayo for a description of the DREIDING force field
These style choices compute force field formulas that are consistent
with the DREIDING force field. See each command's
documentation for the formula it computes.
"bond_style"_bond_harmonic.html harmonic
"bond_style"_bond_morse.html morse :ul
"angle_style"_angle_harmonic.html harmonic
"angle_style"_angle_cosine.html cosine
"angle_style"_angle_cosine_periodic.html cosine/periodic :ul
"dihedral_style"_dihedral_charmm.html charmm
"improper_style"_improper_umbrella.html umbrella :ul
"pair_style"_pair_buck.html buck
"pair_style"_pair_buck.html buck/coul/cut
"pair_style"_pair_buck.html buck/coul/long
"pair_style"_pair_lj.html lj/cut
"pair_style"_pair_lj.html lj/cut/coul/cut
"pair_style"_pair_lj.html lj/cut/coul/long :ul
"pair_style"_pair_hbond_dreiding.html hbond/dreiding/lj
"pair_style"_pair_hbond_dreiding.html hbond/dreiding/morse :ul
"special_bonds"_special_bonds.html dreiding :ul
:line
:link(howto-MacKerell)
[(MacKerell)] MacKerell, Bashford, Bellott, Dunbrack, Evanseck, Field,
Fischer, Gao, Guo, Ha, et al, J Phys Chem, 102, 3586 (1998).
:link(howto-Cornell)
[(Cornell)] Cornell, Cieplak, Bayly, Gould, Merz, Ferguson,
Spellmeyer, Fox, Caldwell, Kollman, JACS 117, 5179-5197 (1995).
:link(howto-Mayo)
[(Mayo)] Mayo, Olfason, Goddard III, J Phys Chem, 94, 8897-8909
(1990).

22
doc/src/body.txt → doc/src/Howto_body.txt
View File

@ -1,24 +1,24 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:link(lc,Commands_all.html)
:line
Body particles :h2
Body particles :h3
[Overview:]
This doc page is not about a LAMMPS input script command, but about
body particles, which are generalized finite-size particles.
In LAMMPS, body particles are generalized finite-size particles.
Individual body particles can represent complex entities, such as
surface meshes of discrete points, collections of sub-particles,
deformable objects, etc. Note that other kinds of finite-size
spherical and aspherical particles are also supported by LAMMPS, such
as spheres, ellipsoids, line segments, and triangles, but they are
simpler entities that body particles. See "Section
6.14"_Section_howto.html#howto_14 for a general overview of all
simpler entities that body particles. See the "Howto
spherical"_Howto_spherical.html doc page for a general overview of all
these particle types.
Body particles are used via the "atom_style body"_atom_style.html
@ -36,8 +36,8 @@ thus how they can be used to compute pairwise body/body or
bond/non-body (point particle) interactions. More details of each
style are described below.
More styles may be added in the future. See "Section
10.12"_Section_modify.html#mod_12 for details on how to add a new body
More styles may be added in the future. See the "Modify
body"_Modify_body.html doc page for details on how to add a new body
style to the code.
:line
@ -151,8 +151,8 @@ center-of-mass position of the particle is specified by the x,y,z
values in the {Atoms} section of the data file, as is the total mass
of the body particle.
The "pair_style body"_pair_body.html command can be used with this
body style to compute body/body and body/non-body interactions.
The "pair_style body/nparticle"_pair_body_nparticle.html command can be used
with this body style to compute body/body and body/non-body interactions.
For output purposes via the "compute
body/local"_compute_body_local.html and "dump local"_dump.html

166
doc/src/Howto_chunk.txt Normal file
View File

@ -0,0 +1,166 @@
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Use chunks to calculate system properties :h3
In LAMMS, "chunks" are collections of atoms, as defined by the
"compute chunk/atom"_compute_chunk_atom.html command, which assigns
each atom to a chunk ID (or to no chunk at all). The number of chunks
and the assignment of chunk IDs to atoms can be static or change over
time. Examples of "chunks" are molecules or spatial bins or atoms
with similar values (e.g. coordination number or potential energy).
The per-atom chunk IDs can be used as input to two other kinds of
commands, to calculate various properties of a system:
"fix ave/chunk"_fix_ave_chunk.html
any of the "compute */chunk"_compute.html commands :ul
Here, each of the 3 kinds of chunk-related commands is briefly
overviewed. Then some examples are given of how to compute different
properties with chunk commands.
Compute chunk/atom command: :h4
This compute can assign atoms to chunks of various styles. Only atoms
in the specified group and optional specified region are assigned to a
chunk. Here are some possible chunk definitions:
atoms in same molecule | chunk ID = molecule ID |
atoms of same atom type | chunk ID = atom type |
all atoms with same atom property (charge, radius, etc) | chunk ID = output of compute property/atom |
atoms in same cluster | chunk ID = output of "compute cluster/atom"_compute_cluster_atom.html command |
atoms in same spatial bin | chunk ID = bin ID |
atoms in same rigid body | chunk ID = molecule ID used to define rigid bodies |
atoms with similar potential energy | chunk ID = output of "compute pe/atom"_compute_pe_atom.html |
atoms with same local defect structure | chunk ID = output of "compute centro/atom"_compute_centro_atom.html or "compute coord/atom"_compute_coord_atom.html command :tb(s=|,c=2)
Note that chunk IDs are integer values, so for atom properties or
computes that produce a floating point value, they will be truncated
to an integer. You could also use the compute in a variable that
scales the floating point value to spread it across multiple integers.
Spatial bins can be of various kinds, e.g. 1d bins = slabs, 2d bins =
pencils, 3d bins = boxes, spherical bins, cylindrical bins.
This compute also calculates the number of chunks {Nchunk}, which is
used by other commands to tally per-chunk data. {Nchunk} can be a
static value or change over time (e.g. the number of clusters). The
chunk ID for an individual atom can also be static (e.g. a molecule
ID), or dynamic (e.g. what spatial bin an atom is in as it moves).
Note that this compute allows the per-atom output of other
"computes"_compute.html, "fixes"_fix.html, and
"variables"_variable.html to be used to define chunk IDs for each
atom. This means you can write your own compute or fix to output a
per-atom quantity to use as chunk ID. See the "Modify"_Modify.html
doc pages for info on how to do this. You can also define a "per-atom
variable"_variable.html in the input script that uses a formula to
generate a chunk ID for each atom.
Fix ave/chunk command: :h4
This fix takes the ID of a "compute
chunk/atom"_compute_chunk_atom.html command as input. For each chunk,
it then sums one or more specified per-atom values over the atoms in
each chunk. The per-atom values can be any atom property, such as
velocity, force, charge, potential energy, kinetic energy, stress,
etc. Additional keywords are defined for per-chunk properties like
density and temperature. More generally any per-atom value generated
by other "computes"_compute.html, "fixes"_fix.html, and "per-atom
variables"_variable.html, can be summed over atoms in each chunk.
Similar to other averaging fixes, this fix allows the summed per-chunk
values to be time-averaged in various ways, and output to a file. The
fix produces a global array as output with one row of values per
chunk.
Compute */chunk commands: :h4
Currently the following computes operate on chunks of atoms to produce
per-chunk values.
"compute com/chunk"_compute_com_chunk.html
"compute gyration/chunk"_compute_gyration_chunk.html
"compute inertia/chunk"_compute_inertia_chunk.html
"compute msd/chunk"_compute_msd_chunk.html
"compute property/chunk"_compute_property_chunk.html
"compute temp/chunk"_compute_temp_chunk.html
"compute torque/chunk"_compute_vcm_chunk.html
"compute vcm/chunk"_compute_vcm_chunk.html :ul
They each take the ID of a "compute
chunk/atom"_compute_chunk_atom.html command as input. As their names
indicate, they calculate the center-of-mass, radius of gyration,
moments of inertia, mean-squared displacement, temperature, torque,
and velocity of center-of-mass for each chunk of atoms. The "compute
property/chunk"_compute_property_chunk.html command can tally the
count of atoms in each chunk and extract other per-chunk properties.
The reason these various calculations are not part of the "fix
ave/chunk command"_fix_ave_chunk.html, is that each requires a more
complicated operation than simply summing and averaging over per-atom
values in each chunk. For example, many of them require calculation
of a center of mass, which requires summing mass*position over the
atoms and then dividing by summed mass.
All of these computes produce a global vector or global array as
output, wih one or more values per chunk. They can be used
in various ways:
As input to the "fix ave/time"_fix_ave_time.html command, which can
write the values to a file and optionally time average them. :ulb,l
As input to the "fix ave/histo"_fix_ave_histo.html command to
histogram values across chunks. E.g. a histogram of cluster sizes or
molecule diffusion rates. :l
As input to special functions of "equal-style
variables"_variable.html, like sum() and max(). E.g. to find the
largest cluster or fastest diffusing molecule. :l
:ule
Example calculations with chunks :h4
Here are examples using chunk commands to calculate various
properties:
(1) Average velocity in each of 1000 2d spatial bins:
compute cc1 all chunk/atom bin/2d x 0.0 0.1 y lower 0.01 units reduced
fix 1 all ave/chunk 100 10 1000 cc1 vx vy file tmp.out :pre
(2) Temperature in each spatial bin, after subtracting a flow
velocity:
compute cc1 all chunk/atom bin/2d x 0.0 0.1 y lower 0.1 units reduced
compute vbias all temp/profile 1 0 0 y 10
fix 1 all ave/chunk 100 10 1000 cc1 temp bias vbias file tmp.out :pre
(3) Center of mass of each molecule:
compute cc1 all chunk/atom molecule
compute myChunk all com/chunk cc1
fix 1 all ave/time 100 1 100 c_myChunk\[*\] file tmp.out mode vector :pre
(4) Total force on each molecule and ave/max across all molecules:
compute cc1 all chunk/atom molecule
fix 1 all ave/chunk 1000 1 1000 cc1 fx fy fz file tmp.out
variable xave equal ave(f_1\[2\])
variable xmax equal max(f_1\[2\])
thermo 1000
thermo_style custom step temp v_xave v_xmax :pre
(5) Histogram of cluster sizes:
compute cluster all cluster/atom 1.0
compute cc1 all chunk/atom c_cluster compress yes
compute size all property/chunk cc1 count
fix 1 all ave/histo 100 1 100 0 20 20 c_size mode vector ave running beyond ignore file tmp.histo :pre

253
doc/src/Howto_coreshell.txt Normal file
View File

@ -0,0 +1,253 @@
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Adiabatic core/shell model :h3
The adiabatic core-shell model by "Mitchell and
Fincham"_#MitchellFincham is a simple method for adding polarizability
to a system. In order to mimic the electron shell of an ion, a
satellite particle is attached to it. This way the ions are split into
a core and a shell where the latter is meant to react to the
electrostatic environment inducing polarizability. See the "Howto
polarizable"_Howto_polarizable.html doc page for a discussion of all
the polarizable models available in LAMMPS.
Technically, shells are attached to the cores by a spring force f =
k*r where k is a parametrized spring constant and r is the distance
between the core and the shell. The charges of the core and the shell
add up to the ion charge, thus q(ion) = q(core) + q(shell). This
setup introduces the ion polarizability (alpha) given by
alpha = q(shell)^2 / k. In a
similar fashion the mass of the ion is distributed on the core and the
shell with the core having the larger mass.
To run this model in LAMMPS, "atom_style"_atom_style.html {full} can
be used since atom charge and bonds are needed. Each kind of
core/shell pair requires two atom types and a bond type. The core and
shell of a core/shell pair should be bonded to each other with a
harmonic bond that provides the spring force. For example, a data file
for NaCl, as found in examples/coreshell, has this format:
432 atoms # core and shell atoms
216 bonds # number of core/shell springs :pre
4 atom types # 2 cores and 2 shells for Na and Cl
2 bond types :pre
0.0 24.09597 xlo xhi
0.0 24.09597 ylo yhi
0.0 24.09597 zlo zhi :pre
Masses # core/shell mass ratio = 0.1 :pre
1 20.690784 # Na core
2 31.90500 # Cl core
3 2.298976 # Na shell
4 3.54500 # Cl shell :pre
Atoms :pre
1 1 2 1.5005 0.00000000 0.00000000 0.00000000 # core of core/shell pair 1
2 1 4 -2.5005 0.00000000 0.00000000 0.00000000 # shell of core/shell pair 1
3 2 1 1.5056 4.01599500 4.01599500 4.01599500 # core of core/shell pair 2
4 2 3 -0.5056 4.01599500 4.01599500 4.01599500 # shell of core/shell pair 2
(...) :pre
Bonds # Bond topology for spring forces :pre
1 2 1 2 # spring for core/shell pair 1
2 2 3 4 # spring for core/shell pair 2
(...) :pre
Non-Coulombic (e.g. Lennard-Jones) pairwise interactions are only
defined between the shells. Coulombic interactions are defined
between all cores and shells. If desired, additional bonds can be
specified between cores.
The "special_bonds"_special_bonds.html command should be used to
turn-off the Coulombic interaction within core/shell pairs, since that
interaction is set by the bond spring. This is done using the
"special_bonds"_special_bonds.html command with a 1-2 weight = 0.0,
which is the default value. It needs to be considered whether one has
to adjust the "special_bonds"_special_bonds.html weighting according
to the molecular topology since the interactions of the shells are
bypassed over an extra bond.
Note that this core/shell implementation does not require all ions to
be polarized. One can mix core/shell pairs and ions without a
satellite particle if desired.
Since the core/shell model permits distances of r = 0.0 between the
core and shell, a pair style with a "cs" suffix needs to be used to
implement a valid long-range Coulombic correction. Several such pair
styles are provided in the CORESHELL package. See "this doc
page"_pair_cs.html for details. All of the core/shell enabled pair
styles require the use of a long-range Coulombic solver, as specified
by the "kspace_style"_kspace_style.html command. Either the PPPM or
Ewald solvers can be used.
For the NaCL example problem, these pair style and bond style settings
are used:
pair_style born/coul/long/cs 20.0 20.0
pair_coeff * * 0.0 1.000 0.00 0.00 0.00
pair_coeff 3 3 487.0 0.23768 0.00 1.05 0.50 #Na-Na
pair_coeff 3 4 145134.0 0.23768 0.00 6.99 8.70 #Na-Cl
pair_coeff 4 4 405774.0 0.23768 0.00 72.40 145.40 #Cl-Cl :pre
bond_style harmonic
bond_coeff 1 63.014 0.0
bond_coeff 2 25.724 0.0 :pre
When running dynamics with the adiabatic core/shell model, the
following issues should be considered. The relative motion of
the core and shell particles corresponds to the polarization,
hereby an instantaneous relaxation of the shells is approximated
and a fast core/shell spring frequency ensures a nearly constant
internal kinetic energy during the simulation.
Thermostats can alter this polarization behaviour, by scaling the
internal kinetic energy, meaning the shell will not react freely to
its electrostatic environment.
Therefore it is typically desirable to decouple the relative motion of
the core/shell pair, which is an imaginary degree of freedom, from the
real physical system. To do that, the "compute
temp/cs"_compute_temp_cs.html command can be used, in conjunction with
any of the thermostat fixes, such as "fix nvt"_fix_nh.html or "fix
langevin"_fix_langevin.html. This compute uses the center-of-mass velocity
of the core/shell pairs to calculate a temperature, and insures that
velocity is what is rescaled for thermostatting purposes. This
compute also works for a system with both core/shell pairs and
non-polarized ions (ions without an attached satellite particle). The
"compute temp/cs"_compute_temp_cs.html command requires input of two
groups, one for the core atoms, another for the shell atoms.
Non-polarized ions which might also be included in the treated system
should not be included into either of these groups, they are taken
into account by the {group-ID} (2nd argument) of the compute. The
groups can be defined using the "group {type}"_group.html command.
Note that to perform thermostatting using this definition of
temperature, the "fix modify temp"_fix_modify.html command should be
used to assign the compute to the thermostat fix. Likewise the
"thermo_modify temp"_thermo_modify.html command can be used to make
this temperature be output for the overall system.
For the NaCl example, this can be done as follows:
group cores type 1 2
group shells type 3 4
compute CSequ all temp/cs cores shells
fix thermoberendsen all temp/berendsen 1427 1427 0.4 # thermostat for the true physical system
fix thermostatequ all nve # integrator as needed for the berendsen thermostat
fix_modify thermoberendsen temp CSequ
thermo_modify temp CSequ # output of center-of-mass derived temperature :pre
The pressure for the core/shell system is computed via the regular
LAMMPS convention by "treating the cores and shells as individual
particles"_#MitchellFincham2. For the thermo output of the pressure
as well as for the application of a barostat, it is necessary to
use an additional "pressure"_compute_pressure.html compute based on
the default "temperature"_compute_temp.html and specifying it as a
second argument in "fix modify"_fix_modify.html and
"thermo_modify"_thermo_modify.html resulting in:
(...)
compute CSequ all temp/cs cores shells
compute thermo_press_lmp all pressure thermo_temp # pressure for individual particles
thermo_modify temp CSequ press thermo_press_lmp # modify thermo to regular pressure
fix press_bar all npt temp 300 300 0.04 iso 0 0 0.4
fix_modify press_bar temp CSequ press thermo_press_lmp # pressure modification for correct kinetic scalar :pre
If "compute temp/cs"_compute_temp_cs.html is used, the decoupled
relative motion of the core and the shell should in theory be
stable. However numerical fluctuation can introduce a small
momentum to the system, which is noticable over long trajectories.
Therefore it is recommendable to use the "fix
momentum"_fix_momentum.html command in combination with "compute
temp/cs"_compute_temp_cs.html when equilibrating the system to
prevent any drift.
When initializing the velocities of a system with core/shell pairs, it
is also desirable to not introduce energy into the relative motion of
the core/shell particles, but only assign a center-of-mass velocity to
the pairs. This can be done by using the {bias} keyword of the
"velocity create"_velocity.html command and assigning the "compute
temp/cs"_compute_temp_cs.html command to the {temp} keyword of the
"velocity"_velocity.html command, e.g.
velocity all create 1427 134 bias yes temp CSequ
velocity all scale 1427 temp CSequ :pre
To maintain the correct polarizability of the core/shell pairs, the
kinetic energy of the internal motion shall remain nearly constant.
Therefore the choice of spring force and mass ratio need to ensure
much faster relative motion of the 2 atoms within the core/shell pair
than their center-of-mass velocity. This allows the shells to
effectively react instantaneously to the electrostatic environment and
limits energy transfer to or from the core/shell oscillators.
This fast movement also dictates the timestep that can be used.
The primary literature of the adiabatic core/shell model suggests that
the fast relative motion of the core/shell pairs only allows negligible
energy transfer to the environment.
The mentioned energy transfer will typically lead to a small drift
in total energy over time. This internal energy can be monitored
using the "compute chunk/atom"_compute_chunk_atom.html and "compute
temp/chunk"_compute_temp_chunk.html commands. The internal kinetic
energies of each core/shell pair can then be summed using the sum()
special function of the "variable"_variable.html command. Or they can
be time/averaged and output using the "fix ave/time"_fix_ave_time.html
command. To use these commands, each core/shell pair must be defined
as a "chunk". If each core/shell pair is defined as its own molecule,
the molecule ID can be used to define the chunks. If cores are bonded
to each other to form larger molecules, the chunks can be identified
by the "fix property/atom"_fix_property_atom.html via assigning a
core/shell ID to each atom using a special field in the data file read
by the "read_data"_read_data.html command. This field can then be
accessed by the "compute property/atom"_compute_property_atom.html
command, to use as input to the "compute
chunk/atom"_compute_chunk_atom.html command to define the core/shell
pairs as chunks.
For example if core/shell pairs are the only molecules:
read_data NaCl_CS_x0.1_prop.data
compute prop all property/atom molecule
compute cs_chunk all chunk/atom c_prop
compute cstherm all temp/chunk cs_chunk temp internal com yes cdof 3.0 # note the chosen degrees of freedom for the core/shell pairs
fix ave_chunk all ave/time 10 1 10 c_cstherm file chunk.dump mode vector :pre
For example if core/shell pairs and other molecules are present:
fix csinfo all property/atom i_CSID # property/atom command
read_data NaCl_CS_x0.1_prop.data fix csinfo NULL CS-Info # atom property added in the data-file
compute prop all property/atom i_CSID
(...) :pre
The additional section in the date file would be formatted like this:
CS-Info # header of additional section :pre
1 1 # column 1 = atom ID, column 2 = core/shell ID
2 1
3 2
4 2
5 3
6 3
7 4
8 4
(...) :pre
:line
:link(MitchellFincham)
[(Mitchell and Fincham)] Mitchell, Fincham, J Phys Condensed Matter,
5, 1031-1038 (1993).
:link(MitchellFincham2)
[(Fincham)] Fincham, Mackrodt and Mitchell, J Phys Condensed Matter,
6, 393-404 (1994).

104
doc/src/Howto_couple.txt Normal file
View File

@ -0,0 +1,104 @@
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Coupling LAMMPS to other codes :h3
LAMMPS is designed to allow it to be coupled to other codes. For
example, a quantum mechanics code might compute forces on a subset of
atoms and pass those forces to LAMMPS. Or a continuum finite element
(FE) simulation might use atom positions as boundary conditions on FE
nodal points, compute a FE solution, and return interpolated forces on
MD atoms.
LAMMPS can be coupled to other codes in at least 3 ways. Each has
advantages and disadvantages, which you'll have to think about in the
context of your application.
(1) Define a new "fix"_fix.html command that calls the other code. In
this scenario, LAMMPS is the driver code. During its timestepping,
the fix is invoked, and can make library calls to the other code,
which has been linked to LAMMPS as a library. This is the way the
"POEMS"_poems package that performs constrained rigid-body motion on
groups of atoms is hooked to LAMMPS. See the "fix
poems"_fix_poems.html command for more details. See the
"Modify"_Modify.html doc pages for info on how to add a new fix to
LAMMPS.
:link(poems,http://www.rpi.edu/~anderk5/lab)
(2) Define a new LAMMPS command that calls the other code. This is
conceptually similar to method (1), but in this case LAMMPS and the
other code are on a more equal footing. Note that now the other code
is not called during the timestepping of a LAMMPS run, but between
runs. The LAMMPS input script can be used to alternate LAMMPS runs
with calls to the other code, invoked via the new command. The
"run"_run.html command facilitates this with its {every} option, which
makes it easy to run a few steps, invoke the command, run a few steps,
invoke the command, etc.
In this scenario, the other code can be called as a library, as in
(1), or it could be a stand-alone code, invoked by a system() call
made by the command (assuming your parallel machine allows one or more
processors to start up another program). In the latter case the
stand-alone code could communicate with LAMMPS thru files that the
command writes and reads.
See the "Modify command"_Modify_command.html doc page for info on how
to add a new command to LAMMPS.
(3) Use LAMMPS as a library called by another code. In this case the
other code is the driver and calls LAMMPS as needed. Or a wrapper
code could link and call both LAMMPS and another code as libraries.
Again, the "run"_run.html command has options that allow it to be
invoked with minimal overhead (no setup or clean-up) if you wish to do
multiple short runs, driven by another program.
Examples of driver codes that call LAMMPS as a library are included in
the examples/COUPLE directory of the LAMMPS distribution; see
examples/COUPLE/README for more details:
simple: simple driver programs in C++ and C which invoke LAMMPS as a
library :ulb,l
lammps_quest: coupling of LAMMPS and "Quest"_quest, to run classical
MD with quantum forces calculated by a density functional code :l
lammps_spparks: coupling of LAMMPS and "SPPARKS"_spparks, to couple
a kinetic Monte Carlo model for grain growth using MD to calculate
strain induced across grain boundaries :l
:ule
:link(quest,http://dft.sandia.gov/Quest)
:link(spparks,http://www.sandia.gov/~sjplimp/spparks.html)
The "Build basics"_Build_basics.html doc page describes how to build
LAMMPS as a library. Once this is done, you can interface with LAMMPS
either via C++, C, Fortran, or Python (or any other language that
supports a vanilla C-like interface). For example, from C++ you could
create one (or more) "instances" of LAMMPS, pass it an input script to
process, or execute individual commands, all by invoking the correct
class methods in LAMMPS. From C or Fortran you can make function
calls to do the same things. See the "Python"_Python_head.html doc
pages for a description of the Python wrapper provided with LAMMPS
that operates through the LAMMPS library interface.
The files src/library.cpp and library.h contain the C-style interface
to LAMMPS. See the "Howto library"_Howto_library.html doc page for a
description of the interface and how to extend it for your needs.
Note that the lammps_open() function that creates an instance of
LAMMPS takes an MPI communicator as an argument. This means that
instance of LAMMPS will run on the set of processors in the
communicator. Thus the calling code can run LAMMPS on all or a subset
of processors. For example, a wrapper script might decide to
alternate between LAMMPS and another code, allowing them both to run
on all the processors. Or it might allocate half the processors to
LAMMPS and half to the other code and run both codes simultaneously
before syncing them up periodically. Or it might instantiate multiple
instances of LAMMPS to perform different calculations.

31
doc/src/Howto_diffusion.txt Normal file
View File

@ -0,0 +1,31 @@
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Calculate a diffusion coefficient :h3
The diffusion coefficient D of a material can be measured in at least
2 ways using various options in LAMMPS. See the examples/DIFFUSE
directory for scripts that implement the 2 methods discussed here for
a simple Lennard-Jones fluid model.
The first method is to measure the mean-squared displacement (MSD) of
the system, via the "compute msd"_compute_msd.html command. The slope
of the MSD versus time is proportional to the diffusion coefficient.
The instantaneous MSD values can be accumulated in a vector via the
"fix vector"_fix_vector.html command, and a line fit to the vector to
compute its slope via the "variable slope"_variable.html function, and
thus extract D.
The second method is to measure the velocity auto-correlation function
(VACF) of the system, via the "compute vacf"_compute_vacf.html
command. The time-integral of the VACF is proportional to the
diffusion coefficient. The instantaneous VACF values can be
accumulated in a vector via the "fix vector"_fix_vector.html command,
and time integrated via the "variable trap"_variable.html function,
and thus extract D.

108
doc/src/Howto_dispersion.txt Normal file
View File

@ -0,0 +1,108 @@
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Long-raage dispersion settings :h3
The PPPM method computes interactions by splitting the pair potential
into two parts, one of which is computed in a normal pairwise fashion,
the so-called real-space part, and one of which is computed using the
Fourier transform, the so called reciprocal-space or kspace part. For
both parts, the potential is not computed exactly but is approximated.
Thus, there is an error in both parts of the computation, the
real-space and the kspace error. The just mentioned facts are true
both for the PPPM for Coulomb as well as dispersion interactions. The
deciding difference - and also the reason why the parameters for
pppm/disp have to be selected with more care - is the impact of the
errors on the results: The kspace error of the PPPM for Coulomb and
dispersion interaction and the real-space error of the PPPM for
Coulomb interaction have the character of noise. In contrast, the
real-space error of the PPPM for dispersion has a clear physical
interpretation: the underprediction of cohesion. As a consequence, the
real-space error has a much stronger effect than the kspace error on
simulation results for pppm/disp. Parameters must thus be chosen in a
way that this error is much smaller than the kspace error.
When using pppm/disp and not making any specifications on the PPPM
parameters via the kspace modify command, parameters will be tuned
such that the real-space error and the kspace error are equal. This
will result in simulations that are either inaccurate or slow, both of
which is not desirable. For selecting parameters for the pppm/disp
that provide fast and accurate simulations, there are two approaches,
which both have their up- and downsides.
The first approach is to set desired real-space an kspace accuracies
via the {kspace_modify force/disp/real} and {kspace_modify
force/disp/kspace} commands. Note that the accuracies have to be
specified in force units and are thus dependent on the chosen unit
settings. For real units, 0.0001 and 0.002 seem to provide reasonable
accurate and efficient computations for the real-space and kspace
accuracies. 0.002 and 0.05 work well for most systems using lj
units. PPPM parameters will be generated based on the desired
accuracies. The upside of this approach is that it usually provides a
good set of parameters and will work for both the {kspace_modify diff
ad} and {kspace_modify diff ik} options. The downside of the method
is that setting the PPPM parameters will take some time during the
initialization of the simulation.
The second approach is to set the parameters for the pppm/disp
explicitly using the {kspace_modify mesh/disp}, {kspace_modify
order/disp}, and {kspace_modify gewald/disp} commands. This approach
requires a more experienced user who understands well the impact of
the choice of parameters on the simulation accuracy and
performance. This approach provides a fast initialization of the
simulation. However, it is sensitive to errors: A combination of
parameters that will perform well for one system might result in
far-from-optimal conditions for other simulations. For example,
parameters that provide accurate and fast computations for
all-atomistic force fields can provide insufficient accuracy or
united-atomistic force fields (which is related to that the latter
typically have larger dispersion coefficients).
To avoid inaccurate or inefficient simulations, the pppm/disp stops
simulations with an error message if no action is taken to control the
PPPM parameters. If the automatic parameter generation is desired and
real-space and kspace accuracies are desired to be equal, this error
message can be suppressed using the {kspace_modify disp/auto yes}
command.
A reasonable approach that combines the upsides of both methods is to
make the first run using the {kspace_modify force/disp/real} and
{kspace_modify force/disp/kspace} commands, write down the PPPM
parameters from the outut, and specify these parameters using the
second approach in subsequent runs (which have the same composition,
force field, and approximately the same volume).
Concerning the performance of the pppm/disp there are two more things
to consider. The first is that when using the pppm/disp, the cutoff
parameter does no longer affect the accuracy of the simulation
(subject to that gewald/disp is adjusted when changing the cutoff).
The performance can thus be increased by examining different values
for the cutoff parameter. A lower bound for the cutoff is only set by
the truncation error of the repulsive term of pair potentials.
The second is that the mixing rule of the pair style has an impact on
the computation time when using the pppm/disp. Fastest computations
are achieved when using the geometric mixing rule. Using the
arithmetic mixing rule substantially increases the computational cost.
The computational overhead can be reduced using the {kspace_modify
mix/disp geom} and {kspace_modify splittol} commands. The first
command simply enforces geometric mixing of the dispersion
coefficients in kspace computations. This introduces some error in
the computations but will also significantly speed-up the
simulations. The second keyword sets the accuracy with which the
dispersion coefficients are approximated using a matrix factorization
approach. This may result in better accuracy then using the first
command, but will usually also not provide an equally good increase of
efficiency.
Finally, pppm/disp can also be used when no mixing rules apply.
This can be achieved using the {kspace_modify mix/disp none} command.
Note that the code does not check automatically whether any mixing
rule is fulfilled. If mixing rules do not apply, the user will have
to specify this command explicitly.

77
doc/src/Howto_drude.txt Normal file
View File

@ -0,0 +1,77 @@
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Drude induced dipoles :h3
The thermalized Drude model represents induced dipoles by a pair of
charges (the core atom and the Drude particle) connected by a harmonic
spring. See the "Howto polarizable"_Howto_polarizable.html doc page
for a discussion of all the polarizable models available in LAMMPS.
The Drude model has a number of features aimed at its use in
molecular systems ("Lamoureux and Roux"_#howto-Lamoureux):
Thermostating of the additional degrees of freedom associated with the
induced dipoles at very low temperature, in terms of the reduced
coordinates of the Drude particles with respect to their cores. This
makes the trajectory close to that of relaxed induced dipoles. :ulb,l
Consistent definition of 1-2 to 1-4 neighbors. A core-Drude particle
pair represents a single (polarizable) atom, so the special screening
factors in a covalent structure should be the same for the core and
the Drude particle. Drude particles have to inherit the 1-2, 1-3, 1-4
special neighbor relations from their respective cores. :l
Stabilization of the interactions between induced dipoles. Drude
dipoles on covalently bonded atoms interact too strongly due to the
short distances, so an atom may capture the Drude particle of a
neighbor, or the induced dipoles within the same molecule may align
too much. To avoid this, damping at short range can be done by Thole
functions (for which there are physical grounds). This Thole damping
is applied to the point charges composing the induced dipole (the
charge of the Drude particle and the opposite charge on the core, not
to the total charge of the core atom). :l,ule
A detailed tutorial covering the usage of Drude induced dipoles in
LAMMPS is on the "Howto drude2e"_Howto_drude2.html doc page.
As with the core-shell model, the cores and Drude particles should
appear in the data file as standard atoms. The same holds for the
springs between them, which are described by standard harmonic bonds.
The nature of the atoms (core, Drude particle or non-polarizable) is
specified via the "fix drude"_fix_drude.html command. The special
list of neighbors is automatically refactored to account for the
equivalence of core and Drude particles as regards special 1-2 to 1-4
screening. It may be necessary to use the {extra/special/per/atom}
keyword of the "read_data"_read_data.html command. If using "fix
shake"_fix_shake.html, make sure no Drude particle is in this fix
group.
There are two ways to thermostat the Drude particles at a low
temperature: use either "fix langevin/drude"_fix_langevin_drude.html
for a Langevin thermostat, or "fix
drude/transform/*"_fix_drude_transform.html for a Nose-Hoover
thermostat. The former requires use of the command "comm_modify vel
yes"_comm_modify.html. The latter requires two separate integration
fixes like {nvt} or {npt}. The correct temperatures of the reduced
degrees of freedom can be calculated using the "compute
temp/drude"_compute_temp_drude.html. This requires also to use the
command {comm_modify vel yes}.
Short-range damping of the induced dipole interactions can be achieved
using Thole functions through the "pair style
thole"_pair_thole.html in "pair_style hybrid/overlay"_pair_hybrid.html
with a Coulomb pair style. It may be useful to use {coul/long/cs} or
similar from the CORESHELL package if the core and Drude particle come
too close, which can cause numerical issues.
:line
:link(howto-Lamoureux)
[(Lamoureux and Roux)] G. Lamoureux, B. Roux, J. Chem. Phys 119, 3025 (2003)

2
doc/src/tutorial_drude.txt → doc/src/Howto_drude2.txt
View File

@ -9,7 +9,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:link(lc,Commands_all.html)
:line

47
doc/src/Howto_elastic.txt Normal file
View File

@ -0,0 +1,47 @@
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Calculate elastic constants :h3
Elastic constants characterize the stiffness of a material. The formal
definition is provided by the linear relation that holds between the
stress and strain tensors in the limit of infinitesimal deformation.
In tensor notation, this is expressed as s_ij = C_ijkl * e_kl, where
the repeated indices imply summation. s_ij are the elements of the
symmetric stress tensor. e_kl are the elements of the symmetric strain
tensor. C_ijkl are the elements of the fourth rank tensor of elastic
constants. In three dimensions, this tensor has 3^4=81 elements. Using
Voigt notation, the tensor can be written as a 6x6 matrix, where C_ij
is now the derivative of s_i w.r.t. e_j. Because s_i is itself a
derivative w.r.t. e_i, it follows that C_ij is also symmetric, with at
most 7*6/2 = 21 distinct elements.
At zero temperature, it is easy to estimate these derivatives by
deforming the simulation box in one of the six directions using the
"change_box"_change_box.html command and measuring the change in the
stress tensor. A general-purpose script that does this is given in the
examples/elastic directory described on the "Examples"_Examples.html
doc page.
Calculating elastic constants at finite temperature is more
challenging, because it is necessary to run a simulation that perfoms
time averages of differential properties. One way to do this is to
measure the change in average stress tensor in an NVT simulations when
the cell volume undergoes a finite deformation. In order to balance
the systematic and statistical errors in this method, the magnitude of
the deformation must be chosen judiciously, and care must be taken to
fully equilibrate the deformed cell before sampling the stress
tensor. Another approach is to sample the triclinic cell fluctuations
that occur in an NPT simulation. This method can also be slow to
converge and requires careful post-processing "(Shinoda)"_#Shinoda1
:line
:link(Shinoda1)
[(Shinoda)] Shinoda, Shiga, and Mikami, Phys Rev B, 69, 134103 (2004).

10
doc/src/tutorial_github.txt → doc/src/Howto_github.txt
View File

@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:link(lc,Commands_all.html)
:line
@ -26,7 +26,7 @@ work required by the LAMMPS developers. Consequently, creating a pull
request will increase your chances to have your contribution included
and will reduce the time until the integration is complete. For more
information on the requirements to have your code included into LAMMPS
please see "Section 10.15"_Section_modify.html#mod_15
please see the "Modify contribute"_Modify_contribute.html doc page.
:line
@ -124,7 +124,7 @@ unrelated feature, you should switch branches!
After everything is done, add the files to the branch and commit them:
$ git add doc/src/tutorial_github.txt
$ git add doc/src/Howto_github.txt
$ git add doc/src/JPG/tutorial*.png :pre
IMPORTANT NOTE: Do not use {git commit -a} (or {git add -A}). The -a
@ -318,7 +318,7 @@ Because the changes are OK with us, we are going to merge by clicking on
Now, since in the meantime our local text for the tutorial also changed,
we need to pull Axel's change back into our branch, and merge them:
$ git add tutorial_github.txt
$ git add Howto_github.txt
$ git add JPG/tutorial_reverse_pull_request*.png
$ git commit -m "Updated text and images on reverse pull requests"
$ git pull :pre
@ -331,7 +331,7 @@ With Axel's changes merged in and some final text updates, our feature
branch is now perfect as far as we are concerned, so we are going to
commit and push again:
$ git add tutorial_github.txt
$ git add Howto_github.txt
$ git add JPG/tutorial_reverse_pull_request6.png
$ git commit -m "Merged Axel's suggestions and updated text"
$ git push git@github.com:Pakketeretet2/lammps :pre

57
doc/src/Howto_granular.txt Normal file
View File

@ -0,0 +1,57 @@
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Granular models :h3
Granular system are composed of spherical particles with a diameter,
as opposed to point particles. This means they have an angular
velocity and torque can be imparted to them to cause them to rotate.
To run a simulation of a granular model, you will want to use
the following commands:
"atom_style sphere"_atom_style.html
"fix nve/sphere"_fix_nve_sphere.html
"fix gravity"_fix_gravity.html :ul
This compute
"compute erotate/sphere"_compute_erotate_sphere.html :ul
calculates rotational kinetic energy which can be "output with
thermodynamic info"_Howto_output.html.
Use one of these 3 pair potentials, which compute forces and torques
between interacting pairs of particles:
"pair_style"_pair_style.html gran/history
"pair_style"_pair_style.html gran/no_history
"pair_style"_pair_style.html gran/hertzian :ul
These commands implement fix options specific to granular systems:
"fix freeze"_fix_freeze.html
"fix pour"_fix_pour.html
"fix viscous"_fix_viscous.html
"fix wall/gran"_fix_wall_gran.html :ul
The fix style {freeze} zeroes both the force and torque of frozen
atoms, and should be used for granular system instead of the fix style
{setforce}.
For computational efficiency, you can eliminate needless pairwise
computations between frozen atoms by using this command:
"neigh_modify"_neigh_modify.html exclude :ul
NOTE: By default, for 2d systems, granular particles are still modeled
as 3d spheres, not 2d discs (circles), meaning their moment of inertia
will be the same as in 3d. If you wish to model granular particles in
2d as 2d discs, see the note on this topic on the "Howto 2d"_Howto_2d.html
doc page, where 2d simulations are discussed.

90
doc/src/Howto_kappa.txt Normal file
View File

@ -0,0 +1,90 @@
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Calculate thermal conductivity :h3
The thermal conductivity kappa of a material can be measured in at
least 4 ways using various options in LAMMPS. See the examples/KAPPA
directory for scripts that implement the 4 methods discussed here for
a simple Lennard-Jones fluid model. Also, see the "Howto
viscosity"_Howto_viscosity.html doc page for an analogous discussion
for viscosity.
The thermal conductivity tensor kappa is a measure of the propensity
of a material to transmit heat energy in a diffusive manner as given
by Fourier's law
J = -kappa grad(T)
where J is the heat flux in units of energy per area per time and
grad(T) is the spatial gradient of temperature. The thermal
conductivity thus has units of energy per distance per time per degree
K and is often approximated as an isotropic quantity, i.e. as a
scalar.
The first method is to setup two thermostatted regions at opposite
ends of a simulation box, or one in the middle and one at the end of a
periodic box. By holding the two regions at different temperatures
with a "thermostatting fix"_Howto_thermostat.html, the energy added to
the hot region should equal the energy subtracted from the cold region
and be proportional to the heat flux moving between the regions. See
the papers by "Ikeshoji and Hafskjold"_#howto-Ikeshoji and
"Wirnsberger et al"_#howto-Wirnsberger for details of this idea. Note
that thermostatting fixes such as "fix nvt"_fix_nh.html, "fix
langevin"_fix_langevin.html, and "fix
temp/rescale"_fix_temp_rescale.html store the cumulative energy they
add/subtract.
Alternatively, as a second method, the "fix heat"_fix_heat.html or
"fix ehex"_fix_ehex.html commands can be used in place of thermostats
on each of two regions to add/subtract specified amounts of energy to
both regions. In both cases, the resulting temperatures of the two
regions can be monitored with the "compute temp/region" command and
the temperature profile of the intermediate region can be monitored
with the "fix ave/chunk"_fix_ave_chunk.html and "compute
ke/atom"_compute_ke_atom.html commands.
The third method is to perform a reverse non-equilibrium MD simulation
using the "fix thermal/conductivity"_fix_thermal_conductivity.html
command which implements the rNEMD algorithm of Muller-Plathe.
Kinetic energy is swapped between atoms in two different layers of the
simulation box. This induces a temperature gradient between the two
layers which can be monitored with the "fix
ave/chunk"_fix_ave_chunk.html and "compute
ke/atom"_compute_ke_atom.html commands. The fix tallies the
cumulative energy transfer that it performs. See the "fix
thermal/conductivity"_fix_thermal_conductivity.html command for
details.
The fourth method is based on the Green-Kubo (GK) formula which
relates the ensemble average of the auto-correlation of the heat flux
to kappa. The heat flux can be calculated from the fluctuations of
per-atom potential and kinetic energies and per-atom stress tensor in
a steady-state equilibrated simulation. This is in contrast to the
two preceding non-equilibrium methods, where energy flows continuously
between hot and cold regions of the simulation box.
The "compute heat/flux"_compute_heat_flux.html command can calculate
the needed heat flux and describes how to implement the Green_Kubo
formalism using additional LAMMPS commands, such as the "fix
ave/correlate"_fix_ave_correlate.html command to calculate the needed
auto-correlation. See the doc page for the "compute
heat/flux"_compute_heat_flux.html command for an example input script
that calculates the thermal conductivity of solid Ar via the GK
formalism.
:line
:link(howto-Ikeshoji)
[(Ikeshoji)] Ikeshoji and Hafskjold, Molecular Physics, 81, 251-261
(1994).
:link(howto-Wirnsberger)
[(Wirnsberger)] Wirnsberger, Frenkel, and Dellago, J Chem Phys, 143, 124104
(2015).

207
doc/src/Howto_library.txt Normal file
View File

@ -0,0 +1,207 @@
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Library interface to LAMMPS :h3
As described on the "Build basics"_Build_basics.html doc page, LAMMPS
can be built as a library, so that it can be called by another code,
used in a "coupled manner"_Howto_couple.html with other codes, or
driven through a "Python interface"_Python_head.html.
All of these methodologies use a C-style interface to LAMMPS that is
provided in the files src/library.cpp and src/library.h. The
functions therein have a C-style argument list, but contain C++ code
you could write yourself in a C++ application that was invoking LAMMPS
directly. The C++ code in the functions illustrates how to invoke
internal LAMMPS operations. Note that LAMMPS classes are defined
within a LAMMPS namespace (LAMMPS_NS) if you use them from another C++
application.
The examples/COUPLE and python/examples directories have example C++
and C and Python codes which show how a driver code can link to LAMMPS
as a library, run LAMMPS on a subset of processors, grab data from
LAMMPS, change it, and put it back into LAMMPS.
The file src/library.cpp contains the following functions for creating
and destroying an instance of LAMMPS and sending it commands to
execute. See the documentation in the src/library.cpp file for
details.
NOTE: You can write code for additional functions as needed to define
how your code talks to LAMMPS and add them to src/library.cpp and
src/library.h, as well as to the "Python interface"_Python_head.html.
The added functions can access or change any internal LAMMPS data you
wish.
void lammps_open(int, char **, MPI_Comm, void **)
void lammps_open_no_mpi(int, char **, void **)
void lammps_close(void *)
int lammps_version(void *)
void lammps_file(void *, char *)
char *lammps_command(void *, char *)
void lammps_commands_list(void *, int, char **)
void lammps_commands_string(void *, char *)
void lammps_free(void *) :pre
The lammps_open() function is used to initialize LAMMPS, passing in a
list of strings as if they were "command-line
arguments"_Run_options.html when LAMMPS is run in stand-alone mode
from the command line, and a MPI communicator for LAMMPS to run under.
It returns a ptr to the LAMMPS object that is created, and which is
used in subsequent library calls. The lammps_open() function can be
called multiple times, to create multiple instances of LAMMPS.
LAMMPS will run on the set of processors in the communicator. This
means the calling code can run LAMMPS on all or a subset of
processors. For example, a wrapper script might decide to alternate
between LAMMPS and another code, allowing them both to run on all the
processors. Or it might allocate half the processors to LAMMPS and
half to the other code and run both codes simultaneously before
syncing them up periodically. Or it might instantiate multiple
instances of LAMMPS to perform different calculations.
The lammps_open_no_mpi() function is similar except that no MPI
communicator is passed from the caller. Instead, MPI_COMM_WORLD is
used to instantiate LAMMPS, and MPI is initialized if necessary.
The lammps_close() function is used to shut down an instance of LAMMPS
and free all its memory.
The lammps_version() function can be used to determined the specific
version of the underlying LAMMPS code. This is particularly useful
when loading LAMMPS as a shared library via dlopen(). The code using
the library interface can than use this information to adapt to
changes to the LAMMPS command syntax between versions. The returned
LAMMPS version code is an integer (e.g. 2 Sep 2015 results in
20150902) that grows with every new LAMMPS version.
The lammps_file(), lammps_command(), lammps_commands_list(), and
lammps_commands_string() functions are used to pass one or more
commands to LAMMPS to execute, the same as if they were coming from an
input script.
Via these functions, the calling code can read or generate a series of
LAMMPS commands one or multiple at a time and pass it thru the library
interface to setup a problem and then run it in stages. The caller
can interleave the command function calls with operations it performs,
calls to extract information from or set information within LAMMPS, or
calls to another code's library.
The lammps_file() function passes the filename of an input script.
The lammps_command() function passes a single command as a string.
The lammps_commands_list() function passes multiple commands in a
char** list. In both lammps_command() and lammps_commands_list(),
individual commands may or may not have a trailing newline. The
lammps_commands_string() function passes multiple commands
concatenated into one long string, separated by newline characters.
In both lammps_commands_list() and lammps_commands_string(), a single
command can be spread across multiple lines, if the last printable
character of all but the last line is "&", the same as if the lines
appeared in an input script.
The lammps_free() function is a clean-up function to free memory that
the library allocated previously via other function calls. See
comments in src/library.cpp file for which other functions need this
clean-up.
The file src/library.cpp also contains these functions for extracting
information from LAMMPS and setting value within LAMMPS. Again, see
the documentation in the src/library.cpp file for details, including
which quantities can be queried by name:
int lammps_extract_setting(void *, char *)
void *lammps_extract_global(void *, char *)
void lammps_extract_box(void *, double *, double *,
double *, double *, double *, int *, int *)
void *lammps_extract_atom(void *, char *)
void *lammps_extract_compute(void *, char *, int, int)
void *lammps_extract_fix(void *, char *, int, int, int, int)
void *lammps_extract_variable(void *, char *, char *) :pre
The extract_setting() function returns info on the size
of data types (e.g. 32-bit or 64-bit atom IDs) used
by the LAMMPS executable (a compile-time choice).
The other extract functions return a pointer to various global or
per-atom quantities stored in LAMMPS or to values calculated by a
compute, fix, or variable. The pointer returned by the
extract_global() function can be used as a permanent reference to a
value which may change. For the extract_atom() method, see the
extract() method in the src/atom.cpp file for a list of valid per-atom
properties. New names could easily be added if the property you want
is not listed. For the other extract functions, the underlying
storage may be reallocated as LAMMPS runs, so you need to re-call the
function to assure a current pointer or returned value(s).
double lammps_get_thermo(void *, char *)
int lammps_get_natoms(void *) :pre
int lammps_set_variable(void *, char *, char *)
void lammps_reset_box(void *, double *, double *, double, double, double) :pre
The lammps_get_thermo() function returns the current value of a thermo
keyword as a double precision value.
The lammps_get_natoms() function returns the total number of atoms in
the system and can be used by the caller to allocate memory for the
lammps_gather_atoms() and lammps_scatter_atoms() functions.
The lammps_set_variable() function can set an existing string-style
variable to a new string value, so that subsequent LAMMPS commands can
access the variable.
The lammps_reset_box() function resets the size and shape of the
simulation box, e.g. as part of restoring a previously extracted and
saved state of a simulation.
void lammps_gather_atoms(void *, char *, int, int, void *)
void lammps_gather_atoms_concat(void *, char *, int, int, void *)
void lammps_gather_atoms_subset(void *, char *, int, int, int, int *, void *)
void lammps_scatter_atoms(void *, char *, int, int, void *)
void lammps_scatter_atoms_subset(void *, char *, int, int, int, int *, void *) :pre
void lammps_create_atoms(void *, int, tagint *, int *, double *, double *,
imageint *, int) :pre
The gather functions collect peratom info of the requested type (atom
coords, atom types, forces, etc) from all processors, and returns the
same vector of values to each callling processor. The scatter
functions do the inverse. They distribute a vector of peratom values,
passed by all calling processors, to invididual atoms, which may be
owned by different processos.
The lammps_gather_atoms() function does this for all N atoms in the
system, ordered by atom ID, from 1 to N. The
lammps_gather_atoms_concat() function does it for all N atoms, but
simply concatenates the subset of atoms owned by each processor. The
resulting vector is not ordered by atom ID. Atom IDs can be requetsed
by the same function if the caller needs to know the ordering. The
lammps_gather_subset() function allows the caller to request values
for only a subset of atoms (identified by ID).
For all 3 gather function, per-atom image flags can be retrieved in 2 ways.
If the count is specified as 1, they are returned
in a packed format with all three image flags stored in a single integer.
If the count is specified as 3, the values are unpacked into xyz flags
by the library before returning them.
The lammps_scatter_atoms() function takes a list of values for all N
atoms in the system, ordered by atom ID, from 1 to N, and assigns
those values to each atom in the system. The
lammps_scatter_atoms_subset() function takes a subset of IDs as an
argument and only scatters those values to the owning atoms.
The lammps_create_atoms() function takes a list of N atoms as input
with atom types and coords (required), an optionally atom IDs and
velocities and image flags. It uses the coords of each atom to assign
it as a new atom to the processor that owns it. This function is
useful to add atoms to a simulation or (in tandem with
lammps_reset_box()) to restore a previously extracted and saved state
of a simulation. Additional properties for the new atoms can then be
assigned via the lammps_scatter_atoms() or lammps_extract_atom()
functions.

4
doc/src/manifolds.txt → doc/src/Howto_manifold.txt
View File

@ -2,11 +2,11 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:link(lc,Commands_all.html)
:line
Manifolds (surfaces) :h2
Manifolds (surfaces) :h3
[Overview:]

94
doc/src/Howto_multiple.txt Normal file
View File

@ -0,0 +1,94 @@
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Run multiple simulations from one input script :h3
This can be done in several ways. See the documentation for
individual commands for more details on how these examples work.
If "multiple simulations" means continue a previous simulation for
more timesteps, then you simply use the "run"_run.html command
multiple times. For example, this script
units lj
atom_style atomic
read_data data.lj
run 10000
run 10000
run 10000
run 10000
run 10000 :pre
would run 5 successive simulations of the same system for a total of
50,000 timesteps.
If you wish to run totally different simulations, one after the other,
the "clear"_clear.html command can be used in between them to
re-initialize LAMMPS. For example, this script
units lj
atom_style atomic
read_data data.lj
run 10000
clear
units lj
atom_style atomic
read_data data.lj.new
run 10000 :pre
would run 2 independent simulations, one after the other.
For large numbers of independent simulations, you can use
"variables"_variable.html and the "next"_next.html and
"jump"_jump.html commands to loop over the same input script
multiple times with different settings. For example, this
script, named in.polymer
variable d index run1 run2 run3 run4 run5 run6 run7 run8
shell cd $d
read_data data.polymer
run 10000
shell cd ..
clear
next d
jump in.polymer :pre
would run 8 simulations in different directories, using a data.polymer
file in each directory. The same concept could be used to run the
same system at 8 different temperatures, using a temperature variable
and storing the output in different log and dump files, for example
variable a loop 8
variable t index 0.8 0.85 0.9 0.95 1.0 1.05 1.1 1.15
log log.$a
read data.polymer
velocity all create $t 352839
fix 1 all nvt $t $t 100.0
dump 1 all atom 1000 dump.$a
run 100000
clear
next t
next a
jump in.polymer :pre
All of the above examples work whether you are running on 1 or
multiple processors, but assumed you are running LAMMPS on a single
partition of processors. LAMMPS can be run on multiple partitions via
the "-partition command-line switch"_Run_options.html.
In the last 2 examples, if LAMMPS were run on 3 partitions, the same
scripts could be used if the "index" and "loop" variables were
replaced with {universe}-style variables, as described in the
"variable"_variable.html command. Also, the "next t" and "next a"
commands would need to be replaced with a single "next a t" command.
With these modifications, the 8 simulations of each script would run
on the 3 partitions one after the other until all were finished.
Initially, 3 simulations would be started simultaneously, one on each
partition. When one finished, that partition would then start
the 4th simulation, and so forth, until all 8 were completed.

48
doc/src/Howto_nemd.txt Normal file
View File

@ -0,0 +1,48 @@
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
NEMD simulations :h3
Non-equilibrium molecular dynamics or NEMD simulations are typically
used to measure a fluid's rheological properties such as viscosity.
In LAMMPS, such simulations can be performed by first setting up a
non-orthogonal simulation box (see the preceding Howto section).
A shear strain can be applied to the simulation box at a desired
strain rate by using the "fix deform"_fix_deform.html command. The
"fix nvt/sllod"_fix_nvt_sllod.html command can be used to thermostat
the sheared fluid and integrate the SLLOD equations of motion for the
system. Fix nvt/sllod uses "compute
temp/deform"_compute_temp_deform.html to compute a thermal temperature
by subtracting out the streaming velocity of the shearing atoms. The
velocity profile or other properties of the fluid can be monitored via
the "fix ave/chunk"_fix_ave_chunk.html command.
As discussed in the previous section on non-orthogonal simulation
boxes, the amount of tilt or skew that can be applied is limited by
LAMMPS for computational efficiency to be 1/2 of the parallel box
length. However, "fix deform"_fix_deform.html can continuously strain
a box by an arbitrary amount. As discussed in the "fix
deform"_fix_deform.html command, when the tilt value reaches a limit,
the box is flipped to the opposite limit which is an equivalent tiling
of periodic space. The strain rate can then continue to change as
before. In a long NEMD simulation these box re-shaping events may
occur many times.
In a NEMD simulation, the "remap" option of "fix
deform"_fix_deform.html should be set to "remap v", since that is what
"fix nvt/sllod"_fix_nvt_sllod.html assumes to generate a velocity
profile consistent with the applied shear strain rate.
An alternative method for calculating viscosities is provided via the
"fix viscosity"_fix_viscosity.html command.
NEMD simulations can also be used to measure transport properties of a fluid
through a pore or channel. Simulations of steady-state flow can be performed
using the "fix flow/gauss"_fix_flow_gauss.html command.

307
doc/src/Howto_output.txt Normal file
View File

@ -0,0 +1,307 @@
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Output from LAMMPS (thermo, dumps, computes, fixes, variables) :h3
There are four basic kinds of LAMMPS output:
"Thermodynamic output"_thermo_style.html, which is a list
of quantities printed every few timesteps to the screen and logfile. :ulb,l
"Dump files"_dump.html, which contain snapshots of atoms and various
per-atom values and are written at a specified frequency. :l
Certain fixes can output user-specified quantities to files: "fix
ave/time"_fix_ave_time.html for time averaging, "fix
ave/chunk"_fix_ave_chunk.html for spatial or other averaging, and "fix
print"_fix_print.html for single-line output of
"variables"_variable.html. Fix print can also output to the
screen. :l
"Restart files"_restart.html. :l
:ule
A simulation prints one set of thermodynamic output and (optionally)
restart files. It can generate any number of dump files and fix
output files, depending on what "dump"_dump.html and "fix"_fix.html
commands you specify.
As discussed below, LAMMPS gives you a variety of ways to determine
what quantities are computed and printed when the thermodynamics,
dump, or fix commands listed above perform output. Throughout this
discussion, note that users can also "add their own computes and fixes
to LAMMPS"_Modify.html which can then generate values that can then be
output with these commands.
The following sub-sections discuss different LAMMPS command related
to output and the kind of data they operate on and produce:
"Global/per-atom/local data"_#global
"Scalar/vector/array data"_#scalar
"Thermodynamic output"_#thermo
"Dump file output"_#dump
"Fixes that write output files"_#fixoutput
"Computes that process output quantities"_#computeoutput
"Fixes that process output quantities"_#fixprocoutput
"Computes that generate values to output"_#compute
"Fixes that generate values to output"_#fix
"Variables that generate values to output"_#variable
"Summary table of output options and data flow between commands"_#table :ul
Global/per-atom/local data :h4,link(global)
Various output-related commands work with three different styles of
data: global, per-atom, or local. A global datum is one or more
system-wide values, e.g. the temperature of the system. A per-atom
datum is one or more values per atom, e.g. the kinetic energy of each
atom. Local datums are calculated by each processor based on the
atoms it owns, but there may be zero or more per atom, e.g. a list of
bond distances.
Scalar/vector/array data :h4,link(scalar)
Global, per-atom, and local datums can each come in three kinds: a
single scalar value, a vector of values, or a 2d array of values. The
doc page for a "compute" or "fix" or "variable" that generates data
will specify both the style and kind of data it produces, e.g. a
per-atom vector.
When a quantity is accessed, as in many of the output commands
discussed below, it can be referenced via the following bracket
notation, where ID in this case is the ID of a compute. The leading
"c_" would be replaced by "f_" for a fix, or "v_" for a variable:
c_ID | entire scalar, vector, or array
c_ID\[I\] | one element of vector, one column of array
c_ID\[I\]\[J\] | one element of array :tb(s=|)
In other words, using one bracket reduces the dimension of the data
once (vector -> scalar, array -> vector). Using two brackets reduces
the dimension twice (array -> scalar). Thus a command that uses
scalar values as input can typically also process elements of a vector
or array.
Thermodynamic output :h4,link(thermo)
The frequency and format of thermodynamic output is set by the
"thermo"_thermo.html, "thermo_style"_thermo_style.html, and
"thermo_modify"_thermo_modify.html commands. The
"thermo_style"_thermo_style.html command also specifies what values
are calculated and written out. Pre-defined keywords can be specified
(e.g. press, etotal, etc). Three additional kinds of keywords can
also be specified (c_ID, f_ID, v_name), where a "compute"_compute.html
or "fix"_fix.html or "variable"_variable.html provides the value to be
output. In each case, the compute, fix, or variable must generate
global values for input to the "thermo_style custom"_dump.html
command.
Note that thermodynamic output values can be "extensive" or
"intensive". The former scale with the number of atoms in the system
(e.g. total energy), the latter do not (e.g. temperature). The
setting for "thermo_modify norm"_thermo_modify.html determines whether
extensive quantities are normalized or not. Computes and fixes
produce either extensive or intensive values; see their individual doc
pages for details. "Equal-style variables"_variable.html produce only
intensive values; you can include a division by "natoms" in the
formula if desired, to make an extensive calculation produce an
intensive result.
Dump file output :h4,link(dump)
Dump file output is specified by the "dump"_dump.html and
"dump_modify"_dump_modify.html commands. There are several
pre-defined formats (dump atom, dump xtc, etc).
There is also a "dump custom"_dump.html format where the user
specifies what values are output with each atom. Pre-defined atom
attributes can be specified (id, x, fx, etc). Three additional kinds
of keywords can also be specified (c_ID, f_ID, v_name), where a
"compute"_compute.html or "fix"_fix.html or "variable"_variable.html
provides the values to be output. In each case, the compute, fix, or
variable must generate per-atom values for input to the "dump
custom"_dump.html command.
There is also a "dump local"_dump.html format where the user specifies
what local values to output. A pre-defined index keyword can be
specified to enumerate the local values. Two additional kinds of
keywords can also be specified (c_ID, f_ID), where a
"compute"_compute.html or "fix"_fix.html or "variable"_variable.html
provides the values to be output. In each case, the compute or fix
must generate local values for input to the "dump local"_dump.html
command.
Fixes that write output files :h4,link(fixoutput)
Several fixes take various quantities as input and can write output
files: "fix ave/time"_fix_ave_time.html, "fix
ave/chunk"_fix_ave_chunk.html, "fix ave/histo"_fix_ave_histo.html,
"fix ave/correlate"_fix_ave_correlate.html, and "fix
print"_fix_print.html.
The "fix ave/time"_fix_ave_time.html command enables direct output to
a file and/or time-averaging of global scalars or vectors. The user
specifies one or more quantities as input. These can be global
"compute"_compute.html values, global "fix"_fix.html values, or
"variables"_variable.html of any style except the atom style which
produces per-atom values. Since a variable can refer to keywords used
by the "thermo_style custom"_thermo_style.html command (like temp or
press) and individual per-atom values, a wide variety of quantities
can be time averaged and/or output in this way. If the inputs are one
or more scalar values, then the fix generate a global scalar or vector
of output. If the inputs are one or more vector values, then the fix
generates a global vector or array of output. The time-averaged
output of this fix can also be used as input to other output commands.
The "fix ave/chunk"_fix_ave_chunk.html command enables direct output
to a file of chunk-averaged per-atom quantities like those output in
dump files. Chunks can represent spatial bins or other collections of
atoms, e.g. individual molecules. The per-atom quantities can be atom
density (mass or number) or atom attributes such as position,
velocity, force. They can also be per-atom quantities calculated by a
"compute"_compute.html, by a "fix"_fix.html, or by an atom-style
"variable"_variable.html. The chunk-averaged output of this fix can
also be used as input to other output commands.
The "fix ave/histo"_fix_ave_histo.html command enables direct output
to a file of histogrammed quantities, which can be global or per-atom
or local quantities. The histogram output of this fix can also be
used as input to other output commands.
The "fix ave/correlate"_fix_ave_correlate.html command enables direct
output to a file of time-correlated quantities, which can be global
values. The correlation matrix output of this fix can also be used as
input to other output commands.
The "fix print"_fix_print.html command can generate a line of output
written to the screen and log file or to a separate file, periodically
during a running simulation. The line can contain one or more
"variable"_variable.html values for any style variable except the
vector or atom styles). As explained above, variables themselves can
contain references to global values generated by "thermodynamic
keywords"_thermo_style.html, "computes"_compute.html,
"fixes"_fix.html, or other "variables"_variable.html, or to per-atom
values for a specific atom. Thus the "fix print"_fix_print.html
command is a means to output a wide variety of quantities separate
from normal thermodynamic or dump file output.
Computes that process output quantities :h4,link(computeoutput)
The "compute reduce"_compute_reduce.html and "compute
reduce/region"_compute_reduce.html commands take one or more per-atom
or local vector quantities as inputs and "reduce" them (sum, min, max,
ave) to scalar quantities. These are produced as output values which
can be used as input to other output commands.
The "compute slice"_compute_slice.html command take one or more global
vector or array quantities as inputs and extracts a subset of their
values to create a new vector or array. These are produced as output
values which can be used as input to other output commands.
The "compute property/atom"_compute_property_atom.html command takes a
list of one or more pre-defined atom attributes (id, x, fx, etc) and
stores the values in a per-atom vector or array. These are produced
as output values which can be used as input to other output commands.
The list of atom attributes is the same as for the "dump
custom"_dump.html command.
The "compute property/local"_compute_property_local.html command takes
a list of one or more pre-defined local attributes (bond info, angle
info, etc) and stores the values in a local vector or array. These
are produced as output values which can be used as input to other
output commands.
Fixes that process output quantities :h4,link(fixprocoutput)
The "fix vector"_fix_vector.html command can create global vectors as
output from global scalars as input, accumulating them one element at
a time.
The "fix ave/atom"_fix_ave_atom.html command performs time-averaging
of per-atom vectors. The per-atom quantities can be atom attributes
such as position, velocity, force. They can also be per-atom
quantities calculated by a "compute"_compute.html, by a
"fix"_fix.html, or by an atom-style "variable"_variable.html. The
time-averaged per-atom output of this fix can be used as input to
other output commands.
The "fix store/state"_fix_store_state.html command can archive one or
more per-atom attributes at a particular time, so that the old values
can be used in a future calculation or output. The list of atom
attributes is the same as for the "dump custom"_dump.html command,
including per-atom quantities calculated by a "compute"_compute.html,
by a "fix"_fix.html, or by an atom-style "variable"_variable.html.
The output of this fix can be used as input to other output commands.
Computes that generate values to output :h4,link(compute)
Every "compute"_compute.html in LAMMPS produces either global or
per-atom or local values. The values can be scalars or vectors or
arrays of data. These values can be output using the other commands
described in this section. The doc page for each compute command
describes what it produces. Computes that produce per-atom or local
values have the word "atom" or "local" in their style name. Computes
without the word "atom" or "local" produce global values.
Fixes that generate values to output :h4,link(fix)
Some "fixes"_fix.html in LAMMPS produces either global or per-atom or
local values which can be accessed by other commands. The values can
be scalars or vectors or arrays of data. These values can be output
using the other commands described in this section. The doc page for
each fix command tells whether it produces any output quantities and
describes them.
Variables that generate values to output :h4,link(variable)
"Variables"_variable.html defined in an input script can store one or
more strings. But equal-style, vector-style, and atom-style or
atomfile-style variables generate a global scalar value, global vector
or values, or a per-atom vector, respectively, when accessed. The
formulas used to define these variables can contain references to the
thermodynamic keywords and to global and per-atom data generated by
computes, fixes, and other variables. The values generated by
variables can be used as input to and thus output by the other
commands described in this section.
Summary table of output options and data flow between commands :h4,link(table)
This table summarizes the various commands that can be used for
generating output from LAMMPS. Each command produces output data of
some kind and/or writes data to a file. Most of the commands can take
data from other commands as input. Thus you can link many of these
commands together in pipeline form, where data produced by one command
is used as input to another command and eventually written to the
screen or to a file. Note that to hook two commands together the
output and input data types must match, e.g. global/per-atom/local
data and scalar/vector/array data.
Also note that, as described above, when a command takes a scalar as
input, that could be an element of a vector or array. Likewise a
vector input could be a column of an array.
Command: Input: Output:
"thermo_style custom"_thermo_style.html: global scalars: screen, log file:
"dump custom"_dump.html: per-atom vectors: dump file:
"dump local"_dump.html: local vectors: dump file:
"fix print"_fix_print.html: global scalar from variable: screen, file:
"print"_print.html: global scalar from variable: screen:
"computes"_compute.html: N/A: global/per-atom/local scalar/vector/array:
"fixes"_fix.html: N/A: global/per-atom/local scalar/vector/array:
"variables"_variable.html: global scalars and vectors, per-atom vectors: global scalar and vector, per-atom vector:
"compute reduce"_compute_reduce.html: per-atom/local vectors: global scalar/vector:
"compute slice"_compute_slice.html: global vectors/arrays: global vector/array:
"compute property/atom"_compute_property_atom.html: per-atom vectors: per-atom vector/array:
"compute property/local"_compute_property_local.html: local vectors: local vector/array:
"fix vector"_fix_vector.html: global scalars: global vector:
"fix ave/atom"_fix_ave_atom.html: per-atom vectors: per-atom vector/array:
"fix ave/time"_fix_ave_time.html: global scalars/vectors: global scalar/vector/array, file:
"fix ave/chunk"_fix_ave_chunk.html: per-atom vectors: global array, file:
"fix ave/histo"_fix_ave_histo.html: global/per-atom/local scalars and vectors: global array, file:
"fix ave/correlate"_fix_ave_correlate.html: global scalars: global array, file:
"fix store/state"_fix_store_state.html: per-atom vectors: per-atom vector/array :tb(c=3,s=:)

81
doc/src/Howto_polarizable.txt Normal file
View File

@ -0,0 +1,81 @@
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Polarizable models :h3
In polarizable force fields the charge distributions in molecules and
materials respond to their electrostatic environments. Polarizable
systems can be simulated in LAMMPS using three methods:
the fluctuating charge method, implemented in the "QEQ"_fix_qeq.html
package, :ulb,l
the adiabatic core-shell method, implemented in the
"CORESHELL"_Howto_coreshell.html package, :l
the thermalized Drude dipole method, implemented in the
"USER-DRUDE"_Howto_drude.html package. :l,ule
The fluctuating charge method calculates instantaneous charges on
interacting atoms based on the electronegativity equalization
principle. It is implemented in the "fix qeq"_fix_qeq.html which is
available in several variants. It is a relatively efficient technique
since no additional particles are introduced. This method allows for
charge transfer between molecules or atom groups. However, because the
charges are located at the interaction sites, off-plane components of
polarization cannot be represented in planar molecules or atom groups.
The two other methods share the same basic idea: polarizable atoms are
split into one core atom and one satellite particle (called shell or
Drude particle) attached to it by a harmonic spring. Both atoms bear
a charge and they represent collectively an induced electric dipole.
These techniques are computationally more expensive than the QEq
method because of additional particles and bonds. These two
charge-on-spring methods differ in certain features, with the
core-shell model being normally used for ionic/crystalline materials,
whereas the so-called Drude model is normally used for molecular
systems and fluid states.
The core-shell model is applicable to crystalline materials where the
high symmetry around each site leads to stable trajectories of the
core-shell pairs. However, bonded atoms in molecules can be so close
that a core would interact too strongly or even capture the Drude
particle of a neighbor. The Drude dipole model is relatively more
complex in order to remediate this and other issues. Specifically, the
Drude model includes specific thermostating of the core-Drude pairs
and short-range damping of the induced dipoles.
The three polarization methods can be implemented through a
self-consistent calculation of charges or induced dipoles at each
timestep. In the fluctuating charge scheme this is done by the matrix
inversion method in "fix qeq/point"_fix_qeq.html, but for core-shell
or Drude-dipoles the relaxed-dipoles technique would require an slow
iterative procedure. These self-consistent solutions yield accurate
trajectories since the additional degrees of freedom representing
polarization are massless. An alternative is to attribute a mass to
the additional degrees of freedom and perform time integration using
an extended Lagrangian technique. For the fluctuating charge scheme
this is done by "fix qeq/dynamic"_fix_qeq.html, and for the
charge-on-spring models by the methods outlined in the next two
sections. The assignment of masses to the additional degrees of
freedom can lead to unphysical trajectories if care is not exerted in
choosing the parameters of the polarizable models and the simulation
conditions.
In the core-shell model the vibration of the shells is kept faster
than the ionic vibrations to mimic the fast response of the
polarizable electrons. But in molecular systems thermalizing the
core-Drude pairs at temperatures comparable to the rest of the
simulation leads to several problems (kinetic energy transfer, too
short a timestep, etc.) In order to avoid these problems the relative
motion of the Drude particles with respect to their cores is kept
"cold" so the vibration of the core-Drude pairs is very slow,
approaching the self-consistent regime. In both models the
temperature is regulated using the velocities of the center of mass of
core+shell (or Drude) pairs, but in the Drude model the actual
relative core-Drude particle motion is thermostated separately as
well.

23
doc/src/tutorial_pylammps.txt → doc/src/Howto_pylammps.txt
View File

@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:link(lc,Commands_all.html)
:line
@ -15,13 +15,19 @@ END_RST -->
Overview :h4
PyLammps is a Python wrapper class which can be created on its own or use an
existing lammps Python object. It creates a simpler, Python-like interface to
common LAMMPS functionality. Unlike the original flat C-types interface, it
exposes a discoverable API. It no longer requires knowledge of the underlying
C++ code implementation. Finally, the IPyLammps wrapper builds on top of
PyLammps and adds some additional features for IPython integration into IPython
notebooks, e.g. for embedded visualization output from dump/image.
PyLammps is a Python wrapper class which can be created on its own or
use an existing lammps Python object. It creates a simpler,
Python-like interface to common LAMMPS functionality, in contrast to
the lammps.py wrapper on the C-style LAMMPS library interface which is
written using Python ctypes. The lammps.py wrapper is discussed on
the "Python library"_Python_library.html doc page.
Unlike the flat ctypes interface, PyLammps exposes a discoverable API.
It no longer requires knowledge of the underlying C++ code
implementation. Finally, the IPyLammps wrapper builds on top of
PyLammps and adds some additional features for IPython integration
into IPython notebooks, e.g. for embedded visualization output from
dump/image.
Comparison of lammps and PyLammps interfaces :h5
@ -40,7 +46,6 @@ communication with LAMMPS is hidden from API user
shorter, more concise Python
better IPython integration, designed for quick prototyping :ul
Quick Start :h4
System-wide Installation :h5

60
doc/src/Howto_replica.txt Normal file
View File

@ -0,0 +1,60 @@
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Multi-replica simulations :h3
Several commands in LAMMPS run mutli-replica simulations, meaning
that multiple instances (replicas) of your simulation are run
simultaneously, with small amounts of data exchanged between replicas
periodically.
These are the relevant commands:
"neb"_neb.html for nudged elastic band calculations
"prd"_prd.html for parallel replica dynamics
"tad"_tad.html for temperature accelerated dynamics
"temper"_temper.html for parallel tempering
"fix pimd"_fix_pimd.html for path-integral molecular dynamics (PIMD) :ul
NEB is a method for finding transition states and barrier energies.
PRD and TAD are methods for performing accelerated dynamics to find
and perform infrequent events. Parallel tempering or replica exchange
runs different replicas at a series of temperature to facilitate
rare-event sampling.
These commands can only be used if LAMMPS was built with the REPLICA
package. See the "Build package"_Build_package.html doc page for more
info.
PIMD runs different replicas whose individual particles are coupled
together by springs to model a system or ring-polymers.
This commands can only be used if LAMMPS was built with the USER-MISC
package. See the "Build package"_Build_package.html doc page for more
info.
In all these cases, you must run with one or more processors per
replica. The processors assigned to each replica are determined at
run-time by using the "-partition command-line
switch"_Run_options.html to launch LAMMPS on multiple partitions,
which in this context are the same as replicas. E.g. these commands:
mpirun -np 16 lmp_linux -partition 8x2 -in in.temper
mpirun -np 8 lmp_linux -partition 8x1 -in in.neb :pre
would each run 8 replicas, on either 16 or 8 processors. Note the use
of the "-in command-line switch"_Run_options.html to specify the input
script which is required when running in multi-replica mode.
Also note that with MPI installed on a machine (e.g. your desktop),
you can run on more (virtual) processors than you have physical
processors. Thus the above commands could be run on a
single-processor (or few-processor) desktop so that you can run
a multi-replica simulation on more replicas than you have
physical processors.

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

@ -0,0 +1,97 @@
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Restart a simulation :h3
There are 3 ways to continue a long LAMMPS simulation. Multiple
"run"_run.html commands can be used in the same input script. Each
run will continue from where the previous run left off. Or binary
restart files can be saved to disk using the "restart"_restart.html
command. At a later time, these binary files can be read via a
"read_restart"_read_restart.html command in a new script. Or they can
be converted to text data files using the "-r command-line
switch"_Run_options.html and read by a "read_data"_read_data.html
command in a new script.
Here we give examples of 2 scripts that read either a binary restart
file or a converted data file and then issue a new run command to
continue where the previous run left off. They illustrate what
settings must be made in the new script. Details are discussed in the
documentation for the "read_restart"_read_restart.html and
"read_data"_read_data.html commands.
Look at the {in.chain} input script provided in the {bench} directory
of the LAMMPS distribution to see the original script that these 2
scripts are based on. If that script had the line
restart 50 tmp.restart :pre
added to it, it would produce 2 binary restart files (tmp.restart.50
and tmp.restart.100) as it ran.
This script could be used to read the 1st restart file and re-run the
last 50 timesteps:
read_restart tmp.restart.50 :pre
neighbor 0.4 bin
neigh_modify every 1 delay 1 :pre
fix 1 all nve
fix 2 all langevin 1.0 1.0 10.0 904297 :pre
timestep 0.012 :pre
run 50 :pre
Note that the following commands do not need to be repeated because
their settings are included in the restart file: {units, atom_style,
special_bonds, pair_style, bond_style}. However these commands do
need to be used, since their settings are not in the restart file:
{neighbor, fix, timestep}.
If you actually use this script to perform a restarted run, you will
notice that the thermodynamic data match at step 50 (if you also put a
"thermo 50" command in the original script), but do not match at step
100. This is because the "fix langevin"_fix_langevin.html command
uses random numbers in a way that does not allow for perfect restarts.
As an alternate approach, the restart file could be converted to a data
file as follows:
lmp_g++ -r tmp.restart.50 tmp.restart.data :pre
Then, this script could be used to re-run the last 50 steps:
units lj
atom_style bond
pair_style lj/cut 1.12
pair_modify shift yes
bond_style fene
special_bonds 0.0 1.0 1.0 :pre
read_data tmp.restart.data :pre
neighbor 0.4 bin
neigh_modify every 1 delay 1 :pre
fix 1 all nve
fix 2 all langevin 1.0 1.0 10.0 904297 :pre
timestep 0.012 :pre
reset_timestep 50
run 50 :pre
Note that nearly all the settings specified in the original {in.chain}
script must be repeated, except the {pair_coeff} and {bond_coeff}
commands since the new data file lists the force field coefficients.
Also, the "reset_timestep"_reset_timestep.html command is used to tell
LAMMPS the current timestep. This value is stored in restart files,
but not in data files.

54
doc/src/Howto_spc.txt Normal file
View File

@ -0,0 +1,54 @@
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
SPC water model :h3
The SPC water model specifies a 3-site rigid water molecule with
charges and Lennard-Jones parameters assigned to each of the 3 atoms.
In LAMMPS the "fix shake"_fix_shake.html command can be used to hold
the two O-H bonds and the H-O-H angle rigid. A bond style of
{harmonic} and an angle style of {harmonic} or {charmm} should also be
used.
These are the additional parameters (in real units) to set for O and H
atoms and the water molecule to run a rigid SPC model.
O mass = 15.9994
H mass = 1.008
O charge = -0.820
H charge = 0.410
LJ epsilon of OO = 0.1553
LJ sigma of OO = 3.166
LJ epsilon, sigma of OH, HH = 0.0
r0 of OH bond = 1.0
theta of HOH angle = 109.47 :all(b),p
Note that as originally proposed, the SPC model was run with a 9
Angstrom cutoff for both LJ and Coulommbic terms. It can also be used
with long-range Coulombics (Ewald or PPPM in LAMMPS), without changing
any of the parameters above, though it becomes a different model in
that mode of usage.
The SPC/E (extended) water model is the same, except
the partial charge assignments change:
O charge = -0.8476
H charge = 0.4238 :all(b),p
See the "(Berendsen)"_#howto-Berendsen reference for more details on both
the SPC and SPC/E models.
Wikipedia also has a nice article on "water
models"_http://en.wikipedia.org/wiki/Water_model.
:line
:link(howto-Berendsen)
[(Berendsen)] Berendsen, Grigera, Straatsma, J Phys Chem, 91,
6269-6271 (1987).

243
doc/src/Howto_spherical.txt Normal file
View File

@ -0,0 +1,243 @@
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Finite-size spherical and aspherical particles :h3
Typical MD models treat atoms or particles as point masses. Sometimes
it is desirable to have a model with finite-size particles such as
spheroids or ellipsoids or generalized aspherical bodies. The
difference is that such particles have a moment of inertia, rotational
energy, and angular momentum. Rotation is induced by torque coming
from interactions with other particles.
LAMMPS has several options for running simulations with these kinds of
particles. The following aspects are discussed in turn:
atom styles
pair potentials
time integration
computes, thermodynamics, and dump output
rigid bodies composed of finite-size particles :ul
Example input scripts for these kinds of models are in the body,
colloid, dipole, ellipse, line, peri, pour, and tri directories of the
"examples directory"_Examples.html in the LAMMPS distribution.
Atom styles :h4
There are several "atom styles"_atom_style.html that allow for
definition of finite-size particles: sphere, dipole, ellipsoid, line,
tri, peri, and body.
The sphere style defines particles that are spheriods and each
particle can have a unique diameter and mass (or density). These
particles store an angular velocity (omega) and can be acted upon by
torque. The "set" command can be used to modify the diameter and mass
of individual particles, after then are created.
The dipole style does not actually define finite-size particles, but
is often used in conjunction with spherical particles, via a command
like
atom_style hybrid sphere dipole :pre
This is because when dipoles interact with each other, they induce
torques, and a particle must be finite-size (i.e. have a moment of
inertia) in order to respond and rotate. See the "atom_style
dipole"_atom_style.html command for details. The "set" command can be
used to modify the orientation and length of the dipole moment of
individual particles, after then are created.
The ellipsoid style defines particles that are ellipsoids and thus can
be aspherical. Each particle has a shape, specified by 3 diameters,
and mass (or density). These particles store an angular momentum and
their orientation (quaternion), and can be acted upon by torque. They
do not store an angular velocity (omega), which can be in a different
direction than angular momentum, rather they compute it as needed.
The "set" command can be used to modify the diameter, orientation, and
mass of individual particles, after then are created. It also has a
brief explanation of what quaternions are.
The line style defines line segment particles with two end points and
a mass (or density). They can be used in 2d simulations, and they can
be joined together to form rigid bodies which represent arbitrary
polygons.
The tri style defines triangular particles with three corner points
and a mass (or density). They can be used in 3d simulations, and they
can be joined together to form rigid bodies which represent arbitrary
particles with a triangulated surface.
The peri style is used with "Peridynamic models"_pair_peri.html and
defines particles as having a volume, that is used internally in the
"pair_style peri"_pair_peri.html potentials.
The body style allows for definition of particles which can represent
complex entities, such as surface meshes of discrete points,
collections of sub-particles, deformable objects, etc. The body style
is discussed in more detail on the "Howto body"_Howto_body.html doc
page.
Note that if one of these atom styles is used (or multiple styles via
the "atom_style hybrid"_atom_style.html command), not all particles in
the system are required to be finite-size or aspherical.
For example, in the ellipsoid style, if the 3 shape parameters are set
to the same value, the particle will be a sphere rather than an
ellipsoid. If the 3 shape parameters are all set to 0.0 or if the
diameter is set to 0.0, it will be a point particle. In the line or
tri style, if the lineflag or triflag is specified as 0, then it
will be a point particle.
Some of the pair styles used to compute pairwise interactions between
finite-size particles also compute the correct interaction with point
particles as well, e.g. the interaction between a point particle and a
finite-size particle or between two point particles. If necessary,
"pair_style hybrid"_pair_hybrid.html can be used to insure the correct
interactions are computed for the appropriate style of interactions.
Likewise, using groups to partition particles (ellipsoids versus
spheres versus point particles) will allow you to use the appropriate
time integrators and temperature computations for each class of
particles. See the doc pages for various commands for details.
Also note that for "2d simulations"_dimension.html, atom styles sphere
and ellipsoid still use 3d particles, rather than as circular disks or
ellipses. This means they have the same moment of inertia as the 3d
object. When temperature is computed, the correct degrees of freedom
are used for rotation in a 2d versus 3d system.
Pair potentials :h4
When a system with finite-size particles is defined, the particles
will only rotate and experience torque if the force field computes
such interactions. These are the various "pair
styles"_pair_style.html that generate torque:
"pair_style gran/history"_pair_gran.html
"pair_style gran/hertzian"_pair_gran.html
"pair_style gran/no_history"_pair_gran.html
"pair_style dipole/cut"_pair_dipole.html
"pair_style gayberne"_pair_gayberne.html
"pair_style resquared"_pair_resquared.html
"pair_style brownian"_pair_brownian.html
"pair_style lubricate"_pair_lubricate.html
"pair_style line/lj"_pair_line_lj.html
"pair_style tri/lj"_pair_tri_lj.html
"pair_style body/nparticle"_pair_body_nparticle.html :ul
The granular pair styles are used with spherical particles. The
dipole pair style is used with the dipole atom style, which could be
applied to spherical or ellipsoidal particles. The GayBerne and
REsquared potentials require ellipsoidal particles, though they will
also work if the 3 shape parameters are the same (a sphere). The
Brownian and lubrication potentials are used with spherical particles.
The line, tri, and body potentials are used with line segment,
triangular, and body particles respectively.
Time integration :h4
There are several fixes that perform time integration on finite-size
spherical particles, meaning the integrators update the rotational
orientation and angular velocity or angular momentum of the particles:
"fix nve/sphere"_fix_nve_sphere.html
"fix nvt/sphere"_fix_nvt_sphere.html
"fix npt/sphere"_fix_npt_sphere.html :ul
Likewise, there are 3 fixes that perform time integration on
ellipsoidal particles:
"fix nve/asphere"_fix_nve_asphere.html
"fix nvt/asphere"_fix_nvt_asphere.html
"fix npt/asphere"_fix_npt_asphere.html :ul
The advantage of these fixes is that those which thermostat the
particles include the rotational degrees of freedom in the temperature
calculation and thermostatting. The "fix langevin"_fix_langevin
command can also be used with its {omgea} or {angmom} options to
thermostat the rotational degrees of freedom for spherical or
ellipsoidal particles. Other thermostatting fixes only operate on the
translational kinetic energy of finite-size particles.
These fixes perform constant NVE time integration on line segment,
triangular, and body particles:
"fix nve/line"_fix_nve_line.html
"fix nve/tri"_fix_nve_tri.html
"fix nve/body"_fix_nve_body.html :ul
Note that for mixtures of point and finite-size particles, these
integration fixes can only be used with "groups"_group.html which
contain finite-size particles.
Computes, thermodynamics, and dump output :h4
There are several computes that calculate the temperature or
rotational energy of spherical or ellipsoidal particles:
"compute temp/sphere"_compute_temp_sphere.html
"compute temp/asphere"_compute_temp_asphere.html
"compute erotate/sphere"_compute_erotate_sphere.html
"compute erotate/asphere"_compute_erotate_asphere.html :ul
These include rotational degrees of freedom in their computation. If
you wish the thermodynamic output of temperature or pressure to use
one of these computes (e.g. for a system entirely composed of
finite-size particles), then the compute can be defined and the
"thermo_modify"_thermo_modify.html command used. Note that by default
thermodynamic quantities will be calculated with a temperature that
only includes translational degrees of freedom. See the
"thermo_style"_thermo_style.html command for details.
These commands can be used to output various attributes of finite-size
particles:
"dump custom"_dump.html
"compute property/atom"_compute_property_atom.html
"dump local"_dump.html
"compute body/local"_compute_body_local.html :ul
Attributes include the dipole moment, the angular velocity, the
angular momentum, the quaternion, the torque, the end-point and
corner-point coordinates (for line and tri particles), and
sub-particle attributes of body particles.
Rigid bodies composed of finite-size particles :h4
The "fix rigid"_fix_rigid.html command treats a collection of
particles as a rigid body, computes its inertia tensor, sums the total
force and torque on the rigid body each timestep due to forces on its
constituent particles, and integrates the motion of the rigid body.
If any of the constituent particles of a rigid body are finite-size
particles (spheres or ellipsoids or line segments or triangles), then
their contribution to the inertia tensor of the body is different than
if they were point particles. This means the rotational dynamics of
the rigid body will be different. Thus a model of a dimer is
different if the dimer consists of two point masses versus two
spheroids, even if the two particles have the same mass. Finite-size
particles that experience torque due to their interaction with other
particles will also impart that torque to a rigid body they are part
of.
See the "fix rigid" command for example of complex rigid-body models
it is possible to define in LAMMPS.
Note that the "fix shake"_fix_shake.html command can also be used to
treat 2, 3, or 4 particles as a rigid body, but it always assumes the
particles are point masses.
Also note that body particles cannot be modeled with the "fix
rigid"_fix_rigid.html command. Body particles are treated by LAMMPS
as single particles, though they can store internal state, such as a
list of sub-particles. Individual body partices are typically treated
as rigid bodies, and their motion integrated with a command like "fix
nve/body"_fix_nve_body.html. Interactions between pairs of body
particles are computed via a command like "pair_style
body/nparticle"_pair_body_nparticle.html.

59
doc/src/Howto_spins.txt Normal file
View File

@ -0,0 +1,59 @@
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Magnetic spins :h3
The magnetic spin simualtions are enabled by the SPIN package, whose
implementation is detailed in "Tranchida"_#Tranchida7.
The model representents the simulation of atomic magnetic spins coupled
to lattice vibrations. The dynamics of those magnetic spins can be used
to simulate a broad range a phenomena related to magneto-elasticity, or
or to study the influence of defects on the magnetic properties of
materials.
The magnetic spins are interacting with each others and with the
lattice via pair interactions. Typically, the magnetic exchange
interaction can be defined using the
"pair/spin/exchange"_pair_spin_exchange.html command. This exchange
applies a magnetic torque to a given spin, considering the orientation
of its neighboring spins and their relative distances.
It also applies a force on the atoms as a function of the spin
orientations and their associated inter-atomic distances.
The command "fix precession/spin"_fix_precession_spin.html allows to
apply a constant magnetic torque on all the spins in the system. This
torque can be an external magnetic field (Zeeman interaction), or an
uniaxial magnetic anisotropy.
A Langevin thermostat can be applied to those magnetic spins using
"fix langevin/spin"_fix_langevin_spin.html. Typically, this thermostat
can be coupled to another Langevin thermostat applied to the atoms
using "fix langevin"_fix_langevin.html in order to simulate
thermostated spin-lattice system.
The magnetic Gilbert damping can also be applied using "fix
langevin/spin"_fix_langevin_spin.html. It allows to either dissipate
the thermal energy of the Langevin thermostat, or to perform a
relaxation of the magnetic configuration toward an equilibrium state.
All the computed magnetic properties can be outputed by two main
commands. The first one is "compute spin"_compute_spin.html, that
enables to evaluate magnetic averaged quantities, such as the total
magnetization of the system along x, y, or z, the spin temperature, or
the magnetic energy. The second command is "compute
property/atom"_compute_property_atom.html. It enables to output all the
per atom magnetic quantities. Typically, the orientation of a given
magnetic spin, or the magnetic force acting on this spin.
:line
:link(Tranchida7)
[(Tranchida)] Tranchida, Plimpton, Thibaudeau and Thompson,
arXiv preprint arXiv:1801.10233, (2018).

43
doc/src/Howto_temperature.txt Normal file
View File

@ -0,0 +1,43 @@
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Calcalate temperature :h3
Temperature is computed as kinetic energy divided by some number of
degrees of freedom (and the Boltzmann constant). Since kinetic energy
is a function of particle velocity, there is often a need to
distinguish between a particle's advection velocity (due to some
aggregate motion of particles) and its thermal velocity. The sum of
the two is the particle's total velocity, but the latter is often what
is wanted to compute a temperature.
LAMMPS has several options for computing temperatures, any of which
can be used in "thermostatting"_Howto_thermostat.html and
"barostatting"_Howto_barostat.html. These "compute
commands"_compute.html calculate temperature:
"compute temp"_compute_temp.html
"compute temp/sphere"_compute_temp_sphere.html
"compute temp/asphere"_compute_temp_asphere.html
"compute temp/com"_compute_temp_com.html
"compute temp/deform"_compute_temp_deform.html
"compute temp/partial"_compute_temp_partial.html
"compute temp/profile"_compute_temp_profile.html
"compute temp/ramp"_compute_temp_ramp.html
"compute temp/region"_compute_temp_region.html :ul
All but the first 3 calculate velocity biases directly (e.g. advection
velocities) that are removed when computing the thermal temperature.
"Compute temp/sphere"_compute_temp_sphere.html and "compute
temp/asphere"_compute_temp_asphere.html compute kinetic energy for
finite-size particles that includes rotational degrees of freedom.
They both allow for velocity biases indirectly, via an optional extra
argument which is another temperature compute that subtracts a
velocity bias. This allows the translational velocity of spherical or
aspherical particles to be adjusted in prescribed ways.

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

@ -0,0 +1,89 @@
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Thermostats :h3
Thermostatting means controlling the temperature of particles in an MD
simulation. "Barostatting"_Howto_barostat.html means controlling the
pressure. Since the pressure includes a kinetic component due to
particle velocities, both these operations require calculation of the
temperature. Typically a target temperature (T) and/or pressure (P)
is specified by the user, and the thermostat or barostat attempts to
equilibrate the system to the requested T and/or P.
Thermostatting in LAMMPS is performed by "fixes"_fix.html, or in one
case by a pair style. Several thermostatting fixes are available:
Nose-Hoover (nvt), Berendsen, CSVR, Langevin, and direct rescaling
(temp/rescale). Dissipative particle dynamics (DPD) thermostatting
can be invoked via the {dpd/tstat} pair style:
"fix nvt"_fix_nh.html
"fix nvt/sphere"_fix_nvt_sphere.html
"fix nvt/asphere"_fix_nvt_asphere.html
"fix nvt/sllod"_fix_nvt_sllod.html
"fix temp/berendsen"_fix_temp_berendsen.html
"fix temp/csvr"_fix_temp_csvr.html
"fix langevin"_fix_langevin.html
"fix temp/rescale"_fix_temp_rescale.html
"pair_style dpd/tstat"_pair_dpd.html :ul
"Fix nvt"_fix_nh.html only thermostats the translational velocity of
particles. "Fix nvt/sllod"_fix_nvt_sllod.html also does this, except
that it subtracts out a velocity bias due to a deforming box and
integrates the SLLOD equations of motion. See the "Howto
nemd"_Howto_nemd.html doc page for further details. "Fix
nvt/sphere"_fix_nvt_sphere.html and "fix
nvt/asphere"_fix_nvt_asphere.html thermostat not only translation
velocities but also rotational velocities for spherical and aspherical
particles.
DPD thermostatting alters pairwise interactions in a manner analogous
to the per-particle thermostatting of "fix
langevin"_fix_langevin.html.
Any of the thermostatting fixes can use "temperature
computes"_Howto_thermostat.html that remove bias which has two
effects. First, the current calculated temperature, which is compared
to the requested target temperature, is calculated with the velocity
bias removed. Second, the thermostat adjusts only the thermal
temperature component of the particle's velocities, which are the
velocities with the bias removed. The removed bias is then added back
to the adjusted velocities. See the doc pages for the individual
fixes and for the "fix_modify"_fix_modify.html command for
instructions on how to assign a temperature compute to a
thermostatting fix. For example, you can apply a thermostat to only
the x and z components of velocity by using it in conjunction with
"compute temp/partial"_compute_temp_partial.html. Of you could
thermostat only the thermal temperature of a streaming flow of
particles without affecting the streaming velocity, by using "compute
temp/profile"_compute_temp_profile.html.
NOTE: Only the nvt fixes perform time integration, meaning they update
the velocities and positions of particles due to forces and velocities
respectively. The other thermostat fixes only adjust velocities; they
do NOT perform time integration updates. Thus they should be used in
conjunction with a constant NVE integration fix such as these:
"fix nve"_fix_nve.html
"fix nve/sphere"_fix_nve_sphere.html
"fix nve/asphere"_fix_nve_asphere.html :ul
Thermodynamic output, which can be setup via the
"thermo_style"_thermo_style.html command, often includes temperature
values. As explained on the doc page for the
"thermo_style"_thermo_style.html command, the default temperature is
setup by the thermo command itself. It is NOT the temperature
associated with any thermostatting fix you have defined or with any
compute you have defined that calculates a temperature. The doc pages
for the thermostatting fixes explain the ID of the temperature compute
they create. Thus if you want to view these temperatures, you need to
specify them explicitly via the "thermo_style
custom"_thermo_style.html command. Or you can use the
"thermo_modify"_thermo_modify.html command to re-define what
temperature compute is used for default thermodynamic output.

69
doc/src/Howto_tip3p.txt Normal file
View File

@ -0,0 +1,69 @@
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
TIP3P water model :h3
The TIP3P water model as implemented in CHARMM
"(MacKerell)"_#howto-MacKerell specifies a 3-site rigid water molecule with
charges and Lennard-Jones parameters assigned to each of the 3 atoms.
In LAMMPS the "fix shake"_fix_shake.html command can be used to hold
the two O-H bonds and the H-O-H angle rigid. A bond style of
{harmonic} and an angle style of {harmonic} or {charmm} should also be
used.
These are the additional parameters (in real units) to set for O and H
atoms and the water molecule to run a rigid TIP3P-CHARMM model with a
cutoff. The K values can be used if a flexible TIP3P model (without
fix shake) is desired. If the LJ epsilon and sigma for HH and OH are
set to 0.0, it corresponds to the original 1983 TIP3P model
"(Jorgensen)"_#Jorgensen1.
O mass = 15.9994
H mass = 1.008
O charge = -0.834
H charge = 0.417
LJ epsilon of OO = 0.1521
LJ sigma of OO = 3.1507
LJ epsilon of HH = 0.0460
LJ sigma of HH = 0.4000
LJ epsilon of OH = 0.0836
LJ sigma of OH = 1.7753
K of OH bond = 450
r0 of OH bond = 0.9572
K of HOH angle = 55
theta of HOH angle = 104.52 :all(b),p
These are the parameters to use for TIP3P with a long-range Coulombic
solver (e.g. Ewald or PPPM in LAMMPS), see "(Price)"_#Price1 for
details:
O mass = 15.9994
H mass = 1.008
O charge = -0.830
H charge = 0.415
LJ epsilon of OO = 0.102
LJ sigma of OO = 3.188
LJ epsilon, sigma of OH, HH = 0.0
K of OH bond = 450
r0 of OH bond = 0.9572
K of HOH angle = 55
theta of HOH angle = 104.52 :all(b),p
Wikipedia also has a nice article on "water
models"_http://en.wikipedia.org/wiki/Water_model.
:line
:link(Jorgensen1)
[(Jorgensen)] Jorgensen, Chandrasekhar, Madura, Impey, Klein, J Chem
Phys, 79, 926 (1983).
:link(Price1)
[(Price)] Price and Brooks, J Chem Phys, 121, 10096 (2004).

112
doc/src/Howto_tip4p.txt Normal file
View File

@ -0,0 +1,112 @@
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
TIP4P water model :h3
The four-point TIP4P rigid water model extends the traditional
three-point TIP3P model by adding an additional site, usually
massless, where the charge associated with the oxygen atom is placed.
This site M is located at a fixed distance away from the oxygen along
the bisector of the HOH bond angle. A bond style of {harmonic} and an
angle style of {harmonic} or {charmm} should also be used.
A TIP4P model is run with LAMMPS using either this command
for a cutoff model:
"pair_style lj/cut/tip4p/cut"_pair_lj.html
or these two commands for a long-range model:
"pair_style lj/cut/tip4p/long"_pair_lj.html
"kspace_style pppm/tip4p"_kspace_style.html :ul
For both models, the bond lengths and bond angles should be held fixed
using the "fix shake"_fix_shake.html command.
These are the additional parameters (in real units) to set for O and H
atoms and the water molecule to run a rigid TIP4P model with a cutoff
"(Jorgensen)"_#Jorgensen5. Note that the OM distance is specified in
the "pair_style"_pair_style.html command, not as part of the pair
coefficients.
O mass = 15.9994
H mass = 1.008
O charge = -1.040
H charge = 0.520
r0 of OH bond = 0.9572
theta of HOH angle = 104.52
OM distance = 0.15
LJ epsilon of O-O = 0.1550
LJ sigma of O-O = 3.1536
LJ epsilon, sigma of OH, HH = 0.0
Coulombic cutoff = 8.5 :all(b),p
For the TIP4/Ice model (J Chem Phys, 122, 234511 (2005);
http://dx.doi.org/10.1063/1.1931662) these values can be used:
O mass = 15.9994
H mass = 1.008
O charge = -1.1794
H charge = 0.5897
r0 of OH bond = 0.9572
theta of HOH angle = 104.52
OM distance = 0.1577
LJ epsilon of O-O = 0.21084
LJ sigma of O-O = 3.1668
LJ epsilon, sigma of OH, HH = 0.0
Coulombic cutoff = 8.5 :all(b),p
For the TIP4P/2005 model (J Chem Phys, 123, 234505 (2005);
http://dx.doi.org/10.1063/1.2121687), these values can be used:
O mass = 15.9994
H mass = 1.008
O charge = -1.1128
H charge = 0.5564
r0 of OH bond = 0.9572
theta of HOH angle = 104.52
OM distance = 0.1546
LJ epsilon of O-O = 0.1852
LJ sigma of O-O = 3.1589
LJ epsilon, sigma of OH, HH = 0.0
Coulombic cutoff = 8.5 :all(b),p
These are the parameters to use for TIP4P with a long-range Coulombic
solver (e.g. Ewald or PPPM in LAMMPS):
O mass = 15.9994
H mass = 1.008
O charge = -1.0484
H charge = 0.5242
r0 of OH bond = 0.9572
theta of HOH angle = 104.52
OM distance = 0.1250
LJ epsilon of O-O = 0.16275
LJ sigma of O-O = 3.16435
LJ epsilon, sigma of OH, HH = 0.0 :all(b),p
Note that the when using the TIP4P pair style, the neighbor list
cutoff for Coulomb interactions is effectively extended by a distance
2 * (OM distance), to account for the offset distance of the
fictitious charges on O atoms in water molecules. Thus it is
typically best in an efficiency sense to use a LJ cutoff >= Coulomb
cutoff + 2*(OM distance), to shrink the size of the neighbor list.
This leads to slightly larger cost for the long-range calculation, so
you can test the trade-off for your model. The OM distance and the LJ
and Coulombic cutoffs are set in the "pair_style
lj/cut/tip4p/long"_pair_lj.html command.
Wikipedia also has a nice article on "water
models"_http://en.wikipedia.org/wiki/Water_model.
:line
:link(Jorgensen5)
[(Jorgensen)] Jorgensen, Chandrasekhar, Madura, Impey, Klein, J Chem
Phys, 79, 926 (1983).

213
doc/src/Howto_triclinic.txt Normal file
View File

@ -0,0 +1,213 @@
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
Triclinic (non-orthogonal) simulation boxes :h3
By default, LAMMPS uses an orthogonal simulation box to encompass the
particles. The "boundary"_boundary.html command sets the boundary
conditions of the box (periodic, non-periodic, etc). The orthogonal
box has its "origin" at (xlo,ylo,zlo) and is defined by 3 edge vectors
starting from the origin given by [a] = (xhi-xlo,0,0); [b] =
(0,yhi-ylo,0); [c] = (0,0,zhi-zlo). The 6 parameters
(xlo,xhi,ylo,yhi,zlo,zhi) are defined at the time the simulation box
is created, e.g. by the "create_box"_create_box.html or
"read_data"_read_data.html or "read_restart"_read_restart.html
commands. Additionally, LAMMPS defines box size parameters lx,ly,lz
where lx = xhi-xlo, and similarly in the y and z dimensions. The 6
parameters, as well as lx,ly,lz, can be output via the "thermo_style
custom"_thermo_style.html command.
LAMMPS also allows simulations to be performed in triclinic
(non-orthogonal) simulation boxes shaped as a parallelepiped with
triclinic symmetry. The parallelepiped has its "origin" at
(xlo,ylo,zlo) and is defined by 3 edge vectors starting from the
origin given by [a] = (xhi-xlo,0,0); [b] = (xy,yhi-ylo,0); [c] =
(xz,yz,zhi-zlo). {xy,xz,yz} can be 0.0 or positive or negative values
and are called "tilt factors" because they are the amount of
displacement applied to faces of an originally orthogonal box to
transform it into the parallelepiped. In LAMMPS the triclinic
simulation box edge vectors [a], [b], and [c] cannot be arbitrary
vectors. As indicated, [a] must lie on the positive x axis. [b] must
lie in the xy plane, with strictly positive y component. [c] may have
any orientation with strictly positive z component. The requirement
that [a], [b], and [c] have strictly positive x, y, and z components,
respectively, ensures that [a], [b], and [c] form a complete
right-handed basis. These restrictions impose no loss of generality,
since it is possible to rotate/invert any set of 3 crystal basis
vectors so that they conform to the restrictions.
For example, assume that the 3 vectors [A],[B],[C] are the edge
vectors of a general parallelepiped, where there is no restriction on
[A],[B],[C] other than they form a complete right-handed basis i.e.
[A] x [B] . [C] > 0. The equivalent LAMMPS [a],[b],[c] are a linear
rotation of [A], [B], and [C] and can be computed as follows:
:c,image(Eqs/transform.jpg)
where A = | [A] | indicates the scalar length of [A]. The hat symbol (^)
indicates the corresponding unit vector. {beta} and {gamma} are angles
between the vectors described below. Note that by construction,
[a], [b], and [c] have strictly positive x, y, and z components, respectively.
If it should happen that
[A], [B], and [C] form a left-handed basis, then the above equations
are not valid for [c]. In this case, it is necessary
to first apply an inversion. This can be achieved
by interchanging two basis vectors or by changing the sign of one of them.
For consistency, the same rotation/inversion applied to the basis vectors
must also be applied to atom positions, velocities,
and any other vector quantities.
This can be conveniently achieved by first converting to
fractional coordinates in the
old basis and then converting to distance coordinates in the new basis.
The transformation is given by the following equation:
:c,image(Eqs/rotate.jpg)
where {V} is the volume of the box, [X] is the original vector quantity and
[x] is the vector in the LAMMPS basis.
There is no requirement that a triclinic box be periodic in any
dimension, though it typically should be in at least the 2nd dimension
of the tilt (y in xy) if you want to enforce a shift in periodic
boundary conditions across that boundary. Some commands that work
with triclinic boxes, e.g. the "fix deform"_fix_deform.html and "fix
npt"_fix_nh.html commands, require periodicity or non-shrink-wrap
boundary conditions in specific dimensions. See the command doc pages
for details.
The 9 parameters (xlo,xhi,ylo,yhi,zlo,zhi,xy,xz,yz) are defined at the
time the simulation box is created. This happens in one of 3 ways.
If the "create_box"_create_box.html command is used with a region of
style {prism}, then a triclinic box is setup. See the
"region"_region.html command for details. If the
"read_data"_read_data.html command is used to define the simulation
box, and the header of the data file contains a line with the "xy xz
yz" keyword, then a triclinic box is setup. See the
"read_data"_read_data.html command for details. Finally, if the
"read_restart"_read_restart.html command reads a restart file which
was written from a simulation using a triclinic box, then a triclinic
box will be setup for the restarted simulation.
Note that you can define a triclinic box with all 3 tilt factors =
0.0, so that it is initially orthogonal. This is necessary if the box
will become non-orthogonal, e.g. due to the "fix npt"_fix_nh.html or
"fix deform"_fix_deform.html commands. Alternatively, you can use the
"change_box"_change_box.html command to convert a simulation box from
orthogonal to triclinic and vice versa.
As with orthogonal boxes, LAMMPS defines triclinic box size parameters
lx,ly,lz where lx = xhi-xlo, and similarly in the y and z dimensions.
The 9 parameters, as well as lx,ly,lz, can be output via the
"thermo_style custom"_thermo_style.html command.
To avoid extremely tilted boxes (which would be computationally
inefficient), LAMMPS normally requires that no tilt factor can skew
the box more than half the distance of the parallel box length, which
is the 1st dimension in the tilt factor (x for xz). This is required
both when the simulation box is created, e.g. via the
"create_box"_create_box.html or "read_data"_read_data.html commands,
as well as when the box shape changes dynamically during a simulation,
e.g. via the "fix deform"_fix_deform.html or "fix npt"_fix_nh.html
commands.
For example, if xlo = 2 and xhi = 12, then the x box length is 10 and
the xy tilt factor must be between -5 and 5. Similarly, both xz and
yz must be between -(xhi-xlo)/2 and +(yhi-ylo)/2. Note that this is
not a limitation, since if the maximum tilt factor is 5 (as in this
example), then configurations with tilt = ..., -15, -5, 5, 15, 25,
... are geometrically all equivalent. If the box tilt exceeds this
limit during a dynamics run (e.g. via the "fix deform"_fix_deform.html
command), then the box is "flipped" to an equivalent shape with a tilt
factor within the bounds, so the run can continue. See the "fix
deform"_fix_deform.html doc page for further details.
One exception to this rule is if the 1st dimension in the tilt
factor (x for xy) is non-periodic. In that case, the limits on the
tilt factor are not enforced, since flipping the box in that dimension
does not change the atom positions due to non-periodicity. In this
mode, if you tilt the system to extreme angles, the simulation will
simply become inefficient, due to the highly skewed simulation box.
The limitation on not creating a simulation box with a tilt factor
skewing the box more than half the distance of the parallel box length
can be overridden via the "box"_box.html command. Setting the {tilt}
keyword to {large} allows any tilt factors to be specified.
Box flips that may occur using the "fix deform"_fix_deform.html or
"fix npt"_fix_nh.html commands can be turned off using the {flip no}
option with either of the commands.
Note that if a simulation box has a large tilt factor, LAMMPS will run
less efficiently, due to the large volume of communication needed to
acquire ghost atoms around a processor's irregular-shaped sub-domain.
For extreme values of tilt, LAMMPS may also lose atoms and generate an
error.
Triclinic crystal structures are often defined using three lattice
constants {a}, {b}, and {c}, and three angles {alpha}, {beta} and
{gamma}. Note that in this nomenclature, the a, b, and c lattice
constants are the scalar lengths of the edge vectors [a], [b], and [c]
defined above. The relationship between these 6 quantities
(a,b,c,alpha,beta,gamma) and the LAMMPS box sizes (lx,ly,lz) =
(xhi-xlo,yhi-ylo,zhi-zlo) and tilt factors (xy,xz,yz) is as follows:
:c,image(Eqs/box.jpg)
The inverse relationship can be written as follows:
:c,image(Eqs/box_inverse.jpg)
The values of {a}, {b}, {c} , {alpha}, {beta} , and {gamma} can be printed
out or accessed by computes using the
"thermo_style custom"_thermo_style.html keywords
{cella}, {cellb}, {cellc}, {cellalpha}, {cellbeta}, {cellgamma},
respectively.
As discussed on the "dump"_dump.html command doc page, when the BOX
BOUNDS for a snapshot is written to a dump file for a triclinic box,
an orthogonal bounding box which encloses the triclinic simulation box
is output, along with the 3 tilt factors (xy, xz, yz) of the triclinic
box, formatted as follows:
ITEM: BOX BOUNDS xy xz yz
xlo_bound xhi_bound xy
ylo_bound yhi_bound xz
zlo_bound zhi_bound yz :pre
This bounding box is convenient for many visualization programs and is
calculated from the 9 triclinic box parameters
(xlo,xhi,ylo,yhi,zlo,zhi,xy,xz,yz) as follows:
xlo_bound = xlo + MIN(0.0,xy,xz,xy+xz)
xhi_bound = xhi + MAX(0.0,xy,xz,xy+xz)
ylo_bound = ylo + MIN(0.0,yz)
yhi_bound = yhi + MAX(0.0,yz)
zlo_bound = zlo
zhi_bound = zhi :pre
These formulas can be inverted if you need to convert the bounding box
back into the triclinic box parameters, e.g. xlo = xlo_bound -
MIN(0.0,xy,xz,xy+xz).
One use of triclinic simulation boxes is to model solid-state crystals
with triclinic symmetry. The "lattice"_lattice.html command can be
used with non-orthogonal basis vectors to define a lattice that will
tile a triclinic simulation box via the
"create_atoms"_create_atoms.html command.
A second use is to run Parinello-Rahman dynamics via the "fix
npt"_fix_nh.html command, which will adjust the xy, xz, yz tilt
factors to compensate for off-diagonal components of the pressure
tensor. The analog for an "energy minimization"_minimize.html is
the "fix box/relax"_fix_box_relax.html command.
A third use is to shear a bulk solid to study the response of the
material. The "fix deform"_fix_deform.html command can be used for
this purpose. It allows dynamic control of the xy, xz, yz tilt
factors as a simulation runs. This is discussed in the next section
on non-equilibrium MD (NEMD) simulations.

133
doc/src/Howto_viscosity.txt Normal file
View File

@ -0,0 +1,133 @@
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Calculate viscosity :h3
The shear viscosity eta of a fluid can be measured in at least 5 ways
using various options in LAMMPS. See the examples/VISCOSITY directory
for scripts that implement the 5 methods discussed here for a simple
Lennard-Jones fluid model. Also, see the "Howto
kappa"_Howto_kappa.html doc page for an analogous discussion for
thermal conductivity.
Eta is a measure of the propensity of a fluid to transmit momentum in
a direction perpendicular to the direction of velocity or momentum
flow. Alternatively it is the resistance the fluid has to being
sheared. It is given by
J = -eta grad(Vstream)
where J is the momentum flux in units of momentum per area per time.
and grad(Vstream) is the spatial gradient of the velocity of the fluid
moving in another direction, normal to the area through which the
momentum flows. Viscosity thus has units of pressure-time.
The first method is to perform a non-equilibrium MD (NEMD) simulation
by shearing the simulation box via the "fix deform"_fix_deform.html
command, and using the "fix nvt/sllod"_fix_nvt_sllod.html command to
thermostat the fluid via the SLLOD equations of motion.
Alternatively, as a second method, one or more moving walls can be
used to shear the fluid in between them, again with some kind of
thermostat that modifies only the thermal (non-shearing) components of
velocity to prevent the fluid from heating up.
In both cases, the velocity profile setup in the fluid by this
procedure can be monitored by the "fix ave/chunk"_fix_ave_chunk.html
command, which determines grad(Vstream) in the equation above.
E.g. the derivative in the y-direction of the Vx component of fluid
motion or grad(Vstream) = dVx/dy. The Pxy off-diagonal component of
the pressure or stress tensor, as calculated by the "compute
pressure"_compute_pressure.html command, can also be monitored, which
is the J term in the equation above. See the "Howto
nemd"_Howto_nemd.html doc page for details on NEMD simulations.
The third method is to perform a reverse non-equilibrium MD simulation
using the "fix viscosity"_fix_viscosity.html command which implements
the rNEMD algorithm of Muller-Plathe. Momentum in one dimension is
swapped between atoms in two different layers of the simulation box in
a different dimension. This induces a velocity gradient which can be
monitored with the "fix ave/chunk"_fix_ave_chunk.html command.
The fix tallies the cumulative momentum transfer that it performs.
See the "fix viscosity"_fix_viscosity.html command for details.
The fourth method is based on the Green-Kubo (GK) formula which
relates the ensemble average of the auto-correlation of the
stress/pressure tensor to eta. This can be done in a fully
equilibrated simulation which is in contrast to the two preceding
non-equilibrium methods, where momentum flows continuously through the
simulation box.
Here is an example input script that calculates the viscosity of
liquid Ar via the GK formalism:
# Sample LAMMPS input script for viscosity of liquid Ar :pre
units real
variable T equal 86.4956
variable V equal vol
variable dt equal 4.0
variable p equal 400 # correlation length
variable s equal 5 # sample interval
variable d equal $p*$s # dump interval :pre
# convert from LAMMPS real units to SI :pre
variable kB equal 1.3806504e-23 # \[J/K/] Boltzmann
variable atm2Pa equal 101325.0
variable A2m equal 1.0e-10
variable fs2s equal 1.0e-15
variable convert equal $\{atm2Pa\}*$\{atm2Pa\}*$\{fs2s\}*$\{A2m\}*$\{A2m\}*$\{A2m\} :pre
# setup problem :pre
dimension 3
boundary p p p
lattice fcc 5.376 orient x 1 0 0 orient y 0 1 0 orient z 0 0 1
region box block 0 4 0 4 0 4
create_box 1 box
create_atoms 1 box
mass 1 39.948
pair_style lj/cut 13.0
pair_coeff * * 0.2381 3.405
timestep $\{dt\}
thermo $d :pre
# equilibration and thermalization :pre
velocity all create $T 102486 mom yes rot yes dist gaussian
fix NVT all nvt temp $T $T 10 drag 0.2
run 8000 :pre
# viscosity calculation, switch to NVE if desired :pre
#unfix NVT
#fix NVE all nve :pre
reset_timestep 0
variable pxy equal pxy
variable pxz equal pxz
variable pyz equal pyz
fix SS all ave/correlate $s $p $d &
v_pxy v_pxz v_pyz type auto file S0St.dat ave running
variable scale equal $\{convert\}/($\{kB\}*$T)*$V*$s*$\{dt\}
variable v11 equal trap(f_SS\[3\])*$\{scale\}
variable v22 equal trap(f_SS\[4\])*$\{scale\}
variable v33 equal trap(f_SS\[5\])*$\{scale\}
thermo_style custom step temp press v_pxy v_pxz v_pyz v_v11 v_v22 v_v33
run 100000
variable v equal (v_v11+v_v22+v_v33)/3.0
variable ndens equal count(all)/vol
print "average viscosity: $v \[Pa.s\] @ $T K, $\{ndens\} /A^3" :pre
The fifth method is related to the above Green-Kubo method,
but uses the Einstein formulation, analogous to the Einstein
mean-square-displacement formulation for self-diffusivity. The
time-integrated momentum fluxes play the role of Cartesian
coordinates, whose mean-square displacement increases linearly
with time at sufficiently long times.

40
doc/src/Howto_viz.txt Normal file
View File

@ -0,0 +1,40 @@
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Visualize LAMMPS snapshots :h3
LAMMPS itself does not do visualization, but snapshots from LAMMPS
simulations can be visualized (and analyzed) in a variety of ways.
Mention dump image and dump movie.
LAMMPS snapshots are created by the "dump"_dump.html command which can
create files in several formats. The native LAMMPS dump format is a
text file (see "dump atom" or "dump custom") which can be visualized
by several popular visualization tools. The "dump
image"_dump_image.html and "dump movie"_dump_image.html styles can
output internally rendered images and convert a sequence of them to a
movie during the MD run. Several programs included with LAMMPS as
auxiliary tools can convert between LAMMPS format files and other
formats. See the "Tools"_Tools.html doc page for details.
A Python-based toolkit distributed by our group can read native LAMMPS
dump files, including custom dump files with additional columns of
user-specified atom information, and convert them to various formats
or pipe them into visualization software directly. See the "Pizza.py
WWW site"_pizza for details. Specifically, Pizza.py can convert
LAMMPS dump files into PDB, XYZ, "Ensight"_ensight, and VTK formats.
Pizza.py can pipe LAMMPS dump files directly into the Raster3d and
RasMol visualization programs. Pizza.py has tools that do interactive
3d OpenGL visualization and one that creates SVG images of dump file
snapshots.
:link(pizza,http://www.sandia.gov/~sjplimp/pizza.html)
:link(ensight,http://www.ensight.com)
:link(atomeye,http://mt.seas.upenn.edu/Archive/Graphics/A)

80
doc/src/Howto_walls.txt Normal file
View File

@ -0,0 +1,80 @@
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Walls :h3
Walls in an MD simulation are typically used to bound particle motion,
i.e. to serve as a boundary condition.
Walls in LAMMPS can be of rough (made of particles) or idealized
surfaces. Ideal walls can be smooth, generating forces only in the
normal direction, or frictional, generating forces also in the
tangential direction.
Rough walls, built of particles, can be created in various ways. The
particles themselves can be generated like any other particle, via the
"lattice"_lattice.html and "create_atoms"_create_atoms.html commands,
or read in via the "read_data"_read_data.html command.
Their motion can be constrained by many different commands, so that
they do not move at all, move together as a group at constant velocity
or in response to a net force acting on them, move in a prescribed
fashion (e.g. rotate around a point), etc. Note that if a time
integration fix like "fix nve"_fix_nve.html or "fix nvt"_fix_nh.html
is not used with the group that contains wall particles, their
positions and velocities will not be updated.
"fix aveforce"_fix_aveforce.html - set force on particles to average value, so they move together
"fix setforce"_fix_setforce.html - set force on particles to a value, e.g. 0.0
"fix freeze"_fix_freeze.html - freeze particles for use as granular walls
"fix nve/noforce"_fix_nve_noforce.html - advect particles by their velocity, but without force
"fix move"_fix_move.html - prescribe motion of particles by a linear velocity, oscillation, rotation, variable :ul
The "fix move"_fix_move.html command offers the most generality, since
the motion of individual particles can be specified with
"variable"_variable.html formula which depends on time and/or the
particle position.
For rough walls, it may be useful to turn off pairwise interactions
between wall particles via the "neigh_modify
exclude"_neigh_modify.html command.
Rough walls can also be created by specifying frozen particles that do
not move and do not interact with mobile particles, and then tethering
other particles to the fixed particles, via a "bond"_bond_style.html.
The bonded particles do interact with other mobile particles.
Idealized walls can be specified via several fix commands. "Fix
wall/gran"_fix_wall_gran.html creates frictional walls for use with
granular particles; all the other commands create smooth walls.
"fix wall/reflect"_fix_wall_reflect.html - reflective flat walls
"fix wall/lj93"_fix_wall.html - flat walls, with Lennard-Jones 9/3 potential
"fix wall/lj126"_fix_wall.html - flat walls, with Lennard-Jones 12/6 potential
"fix wall/colloid"_fix_wall.html - flat walls, with "pair_style colloid"_pair_colloid.html potential
"fix wall/harmonic"_fix_wall.html - flat walls, with repulsive harmonic spring potential
"fix wall/region"_fix_wall_region.html - use region surface as wall
"fix wall/gran"_fix_wall_gran.html - flat or curved walls with "pair_style granular"_pair_gran.html potential :ul
The {lj93}, {lj126}, {colloid}, and {harmonic} styles all allow the
flat walls to move with a constant velocity, or oscillate in time.
The "fix wall/region"_fix_wall_region.html command offers the most
generality, since the region surface is treated as a wall, and the
geometry of the region can be a simple primitive volume (e.g. a
sphere, or cube, or plane), or a complex volume made from the union
and intersection of primitive volumes. "Regions"_region.html can also
specify a volume "interior" or "exterior" to the specified primitive
shape or {union} or {intersection}. "Regions"_region.html can also be
"dynamic" meaning they move with constant velocity, oscillate, or
rotate.
The only frictional idealized walls currently in LAMMPS are flat or
curved surfaces specified by the "fix wall/gran"_fix_wall_gran.html
command. At some point we plan to allow regoin surfaces to be used as
frictional walls, as well as triangulated surfaces.

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.

39
doc/src/Intro.txt Normal file
View File

@ -0,0 +1,39 @@
"Previous Section"_Manual.html - "LAMMPS WWW Site"_lws -
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
Section"_Install.html :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands.html#comm)
:line
Introduction :h2
These pages provide a brief introduction to LAMMPS.
<!-- RST
.. toctree::
:maxdepth: 1
Intro_overview
Manual_version
Intro_features
Intro_nonfeatures
Intro_opensource
Intro_authors
Intro_website
END_RST -->
<!-- HTML_ONLY -->
"Overview of LAMMPS"_Intro_overview.html
"LAMMPS features"_Intro_features.html
"LAMMPS non-features"_Intro_nonfeatures.html
"LAMMPS open-source license"_Intro_license.html
"LAMMPS authors"_Intro_authors.html
"Additional website links"_Intro_website.html :all(b)
<!-- END_HTML_ONLY -->

379
doc/src/Intro_authors.txt Normal file
View File

@ -0,0 +1,379 @@
"Higher level section"_Intro.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
LAMMPS authors :h3
The primary LAMMPS developers are at Sandia National Labs and Temple
University:
"Steve Plimpton"_sjp, sjplimp at sandia.gov
Aidan Thompson, athomps at sandia.gov
Stan Moore, stamoor at sandia.gov
Axel Kohlmeyer, akohlmey at gmail.com :ul
:link(sjp,http://www.cs.sandia.gov/~sjplimp)
Past developers include Paul Crozier and Mark Stevens, both at Sandia,
and Ray Shan, now at Materials Design.
:line
The 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.
Richard Berger (Temple U), Python interface, GitHub site, Sphinx doc pages
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
:line
As discussed on the "History
page"_http://lammps.sandia.gov/history.html of the website, LAMMPS
originated as a cooperative project between DOE labs and industrial
partners. Folks involved in the design and testing of the original
version of LAMMPS were the following:
John Carpenter (Mayo Clinic, formerly at Cray Research)
Terry Stouch (Lexicon Pharmaceuticals, formerly at Bristol Myers Squibb)
Steve Lustig (Dupont)
Jim Belak and Roy Pollock (LLNL) :ul
:line
Here is a timeline for when various individuals contributed to a new
feature or command or tool added to LAMMPS:
Aug18 : CMake build option for LAMMPS : Christoph Junghans (LANL), Richard Berger, and Axel Kohlmeyer (Temple U)
Jul18 : DEM polygonal and polyhedron particles : Trung Nguyen (Northwestern U)
Jun18 : SPIN package : Julien Tranchida (Sandia and CEA)
Jun18 : compute entropy/atom : Pablo Piaggi (EPLF, Switzerland)
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, KISS FFT 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)

202
doc/src/Intro_features.txt Normal file
View File

@ -0,0 +1,202 @@
"Higher level section"_Intro.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
LAMMPS features :h3
LAMMPS is a classical molecular dynamics (MD) code with these general
classes of functionality:
"General features"_#general
"Particle and model types"_#particle
"Interatomic potentials (force fields)"_#ff
"Atom creation"_#create
"Ensembles, constraints, and boundary conditions"_#ensemble
"Integrators"_#integrate
"Diagnostics"_#diag
"Output"_#output
"Multi-replica models"_#replica1
"Pre- and post-processing"_#prepost
"Specialized features (beyond MD itself)"_#special :ul
:line
General features :h4,link(general)
runs on a single processor or in parallel
distributed-memory message-passing parallelism (MPI)
spatial-decomposition of simulation domain for parallelism
open-source distribution
highly portable C++
optional libraries used: MPI and single-processor FFT
GPU (CUDA and OpenCL), Intel Xeon Phi, and OpenMP support for many code features
easy to extend with new features and functionality
runs from an input script
syntax for defining and using variables and formulas
syntax for looping over runs and breaking out of loops
run one or multiple simulations simultaneously (in parallel) from one script
build as library, invoke LAMMPS thru library interface or provided Python wrapper
couple with other codes: LAMMPS calls other code, other code calls LAMMPS, umbrella code calls both :ul
Particle and model types :h4,link(particle)
("atom style"_atom_style.html command)
atoms
coarse-grained particles (e.g. bead-spring polymers)
united-atom polymers or organic molecules
all-atom polymers, organic molecules, proteins, DNA
metals
granular materials
coarse-grained mesoscale models
finite-size spherical and ellipsoidal particles
finite-size line segment (2d) and triangle (3d) particles
point dipole particles
rigid collections of particles
hybrid combinations of these :ul
Interatomic potentials (force fields) :h4,link(ff)
("pair style"_pair_style.html, "bond style"_bond_style.html,
"angle style"_angle_style.html, "dihedral style"_dihedral_style.html,
"improper style"_improper_style.html, "kspace style"_kspace_style.html
commands)
pairwise potentials: Lennard-Jones, Buckingham, Morse, Born-Mayer-Huggins, \
Yukawa, soft, class 2 (COMPASS), hydrogen bond, tabulated
charged pairwise potentials: Coulombic, point-dipole
manybody potentials: EAM, Finnis/Sinclair EAM, modified EAM (MEAM), \
embedded ion method (EIM), EDIP, ADP, Stillinger-Weber, Tersoff, \
REBO, AIREBO, ReaxFF, COMB, SNAP, Streitz-Mintmire, 3-body polymorphic
long-range interactions for charge, point-dipoles, and LJ dispersion: \
Ewald, Wolf, PPPM (similar to particle-mesh Ewald)
polarization models: "QEq"_fix_qeq.html, \
"core/shell model"_Howto_coreshell.html, \
"Drude dipole model"_Howto_drude.html
charge equilibration (QEq via dynamic, point, shielded, Slater methods)
coarse-grained potentials: DPD, GayBerne, REsquared, colloidal, DLVO
mesoscopic potentials: granular, Peridynamics, SPH
electron force field (eFF, AWPMD)
bond potentials: harmonic, FENE, Morse, nonlinear, class 2, \
quartic (breakable)
angle potentials: harmonic, CHARMM, cosine, cosine/squared, cosine/periodic, \
class 2 (COMPASS)
dihedral potentials: harmonic, CHARMM, multi-harmonic, helix, \
class 2 (COMPASS), OPLS
improper potentials: harmonic, cvff, umbrella, class 2 (COMPASS)
polymer potentials: all-atom, united-atom, bead-spring, breakable
water potentials: TIP3P, TIP4P, SPC
implicit solvent potentials: hydrodynamic lubrication, Debye
force-field compatibility with common CHARMM, AMBER, DREIDING, \
OPLS, GROMACS, COMPASS options
access to "KIM archive"_http://openkim.org of potentials via \
"pair kim"_pair_kim.html
hybrid potentials: multiple pair, bond, angle, dihedral, improper \
potentials can be used in one simulation
overlaid potentials: superposition of multiple pair potentials :ul
Atom creation :h4,link(create)
("read_data"_read_data.html, "lattice"_lattice.html,
"create_atoms"_create_atoms.html, "delete_atoms"_delete_atoms.html,
"displace_atoms"_displace_atoms.html, "replicate"_replicate.html commands)
read in atom coords from files
create atoms on one or more lattices (e.g. grain boundaries)
delete geometric or logical groups of atoms (e.g. voids)
replicate existing atoms multiple times
displace atoms :ul
Ensembles, constraints, and boundary conditions :h4,link(ensemble)
("fix"_fix.html command)
2d or 3d systems
orthogonal or non-orthogonal (triclinic symmetry) simulation domains
constant NVE, NVT, NPT, NPH, Parinello/Rahman integrators
thermostatting options for groups and geometric regions of atoms
pressure control via Nose/Hoover or Berendsen barostatting in 1 to 3 dimensions
simulation box deformation (tensile and shear)
harmonic (umbrella) constraint forces
rigid body constraints
SHAKE bond and angle constraints
Monte Carlo bond breaking, formation, swapping
atom/molecule insertion and deletion
walls of various kinds
non-equilibrium molecular dynamics (NEMD)
variety of additional boundary conditions and constraints :ul
Integrators :h4,link(integrate)
("run"_run.html, "run_style"_run_style.html, "minimize"_minimize.html commands)
velocity-Verlet integrator
Brownian dynamics
rigid body integration
energy minimization via conjugate gradient or steepest descent relaxation
rRESPA hierarchical timestepping
rerun command for post-processing of dump files :ul
Diagnostics :h4,link(diag)
see various flavors of the "fix"_fix.html and "compute"_compute.html commands :ul
Output :h4,link(output)
("dump"_dump.html, "restart"_restart.html commands)
log file of thermodynamic info
text dump files of atom coords, velocities, other per-atom quantities
binary restart files
parallel I/O of dump and restart files
per-atom quantities (energy, stress, centro-symmetry parameter, CNA, etc)
user-defined system-wide (log file) or per-atom (dump file) calculations
spatial and time averaging of per-atom quantities
time averaging of system-wide quantities
atom snapshots in native, XYZ, XTC, DCD, CFG formats :ul
Multi-replica models :h4,link(replica1)
"nudged elastic band"_neb.html
"parallel replica dynamics"_prd.html
"temperature accelerated dynamics"_tad.html
"parallel tempering"_temper.html :ul
Pre- and post-processing :h4,link(prepost)
A handful of pre- and post-processing tools are packaged with LAMMPS,
some of which can convert input and output files to/from formats used
by other codes; see the "Toos"_Tools.html doc page. :ulb,l
Our group has also written and released a separate toolkit called
"Pizza.py"_pizza which provides tools for doing setup, analysis,
plotting, and visualization for LAMMPS simulations. Pizza.py is
written in "Python"_python and is available for download from "the
Pizza.py WWW site"_pizza. :l,ule
:link(pizza,http://www.sandia.gov/~sjplimp/pizza.html)
:link(python,http://www.python.org)
Specialized features :h4,link(special)
LAMMPS can be built with optional packages which implement a variety
of additional capabilities. See the "Packages"_Packages.html doc
page for details.
These are LAMMPS capabilities which you may not think of as typical
classical MD options:
"static"_balance.html and "dynamic load-balancing"_fix_balance.html
"generalized aspherical particles"_Howto_body.html
"stochastic rotation dynamics (SRD)"_fix_srd.html
"real-time visualization and interactive MD"_fix_imd.html
calculate "virtual diffraction patterns"_compute_xrd.html
"atom-to-continuum coupling"_fix_atc.html with finite elements
coupled rigid body integration via the "POEMS"_fix_poems.html library
"QM/MM coupling"_fix_qmmm.html
Monte Carlo via "GCMC"_fix_gcmc.html and "tfMC"_fix_tfmc.html and "atom swapping"_fix_atom_swap.html
"path-integral molecular dynamics (PIMD)"_fix_ipi.html and "this as well"_fix_pimd.html
"Direct Simulation Monte Carlo"_pair_dsmc.html for low-density fluids
"Peridynamics mesoscale modeling"_pair_peri.html
"Lattice Boltzmann fluid"_fix_lb_fluid.html
"targeted"_fix_tmd.html and "steered"_fix_smd.html molecular dynamics
"two-temperature electron model"_fix_ttm.html :ul

83
doc/src/Intro_nonfeatures.txt Normal file
View File

@ -0,0 +1,83 @@
"Higher level section"_Intro.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
LAMMPS non-features :h3
LAMMPS is designed to be a fast, parallel engine for molecular
dynamics (MD) simulations. It provides only a modest amount of
functionality for setting up simulations and analyzing their output.
Specifically, LAMMPS does not:
run thru a GUI
build molecular systems
assign force-field coefficients automagically
perform sophisticated analyses of your MD simulation
visualize your MD simulation interactively
plot your output data :ul
Here are suggestions on how to perform these tasks:
GUI: LAMMPS can be built as a library and a Python wrapper that wraps
the library interface is provided. Thus, GUI interfaces can be
written in Python (or C or C++ if desired) that run LAMMPS and
visualize or plot its output. Examples of this are provided in the
python directory and described on the "Python"_Python_head.html doc
page. :ulb,l
Builder: Several pre-processing tools are packaged with LAMMPS. Some
of them convert input files in formats produced by other MD codes such
as CHARMM, AMBER, or Insight into LAMMPS input formats. Some of them
are simple programs that will build simple molecular systems, such as
linear bead-spring polymer chains. The moltemplate program is a true
molecular builder that will generate complex molecular models. See
the "Tools"_Tools.html doc page for details on tools packaged with
LAMMPS. The "Pre/post processing
page"_http:/lammps.sandia.gov/prepost.html of the LAMMPS website
describes a variety of 3rd party tools for this task. :l
Force-field assignment: The conversion tools described in the previous
bullet for CHARMM, AMBER, and Insight will also assign force field
coefficients in the LAMMPS format, assuming you provide CHARMM, AMBER,
or Accelerys force field files. :l
Simulation analyses: If you want to perform analyses on-the-fly as
your simulation runs, see the "compute"_compute.html and
"fix"_fix.html doc pages, which list commands that can be used in a
LAMMPS input script. Also see the "Modify"_Modify.html doc page for
info on how to add your own analysis code or algorithms to LAMMPS.
For post-processing, LAMMPS output such as "dump file
snapshots"_dump.html can be converted into formats used by other MD or
post-processing codes. Some post-processing tools packaged with
LAMMPS will do these conversions. Scripts provided in the
tools/python directory can extract and massage data in dump files to
make it easier to import into other programs. See the
"Tools"_Tools.html doc page for details on these various options. :l
Visualization: LAMMPS can produce JPG or PNG snapshot images
on-the-fly via its "dump image"_dump_image.html command. For
high-quality, interactive visualization there are many excellent and
free tools available. See the "Other Codes
page"_http://lammps.sandia.gov/viz.html page of the LAMMPS website for
visualization packages that can use LAMMPS output data. :l
Plotting: See the next bullet about Pizza.py as well as the
"Python"_Python_head.html doc page for examples of plotting LAMMPS
output. Scripts provided with the {python} tool in the tools
directory will extract and massage data in log and dump files to make
it easier to analyze and plot. See the "Tools"_Tools.html doc page
for more discussion of the various tools. :l
Pizza.py: Our group has also written a separate toolkit called
"Pizza.py"_http://pizza.sandia.gov which can do certain kinds of
setup, analysis, plotting, and visualization (via OpenGL) for LAMMPS
simulations. It thus provides some functionality for several of the
above bullets. Pizza.py is written in "Python"_http://www.python.org
and is available for download from "this
page"_http://www.cs.sandia.gov/~sjplimp/download.html. :l,ule

44
doc/src/Intro_opensource.txt Normal file
View File

@ -0,0 +1,44 @@
"Higher level section"_Intro.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
LAMMPS open-source license :h3
LAMMPS is a freely-available open-source code, distributed under the
terms of the "GNU Public License"_gnu, which means you can use or
modify the code however you wish.
LAMMPS comes with no warranty of any kind. As each source file states
in its header, it is a copyrighted code that is distributed free-of-
charge, under the terms of the "GNU Public License"_gnu (GPL). This
is often referred to as open-source distribution - see
"www.gnu.org"_gnuorg or "www.opensource.org"_opensource. The legal
text of the GPL is in the LICENSE file included in the LAMMPS
distribution.
:link(gnu,http://www.gnu.org/copyleft/gpl.html)
:link(gnuorg,http://www.gnu.org)
:link(opensource,http://www.opensource.org)
Here is a summary of what the GPL means for LAMMPS users:
(1) Anyone is free to use, modify, or extend LAMMPS in any way they
choose, including for commercial purposes.
(2) If you distribute a modified version of LAMMPS, it must remain
open-source, meaning you distribute it under the terms of the GPL.
You should clearly annotate such a code as a derivative version of
LAMMPS.
(3) If you release any code that includes LAMMPS source code, then it
must also be open-sourced, meaning you distribute it under the terms
of the GPL.
(4) If you give LAMMPS files to someone else, the GPL LICENSE file and
source file headers (including the copyright and GPL notices) should
remain part of the code.

58
doc/src/Intro_overview.txt Normal file
View File

@ -0,0 +1,58 @@
"Higher level section"_Intro.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Overview of LAMMPS :h3
LAMMPS is a classical molecular dynamics (MD) code that models
ensembles of particles in a liquid, solid, or gaseous state. It can
model atomic, polymeric, biological, solid-state (metals, ceramics,
oxides), granular, coarse-grained, or macroscopic systems using a
variety of interatomic potentials (force fields) and boundary
conditions. It can model 2d or 3d systems with only a few particles
up to millions or billions.
LAMMPS can be built and run on a laptop or destop machine, but is
designed for parallel computers. It will run on any parallel machine
that supports the "MPI"_mpi message-passing library. This includes
shared-memory boxes and distributed-memory clusters and
supercomputers.
:link(mpi,http://www-unix.mcs.anl.gov/mpi)
LAMMPS is written in C++. Earlier versions were written in F77 and
F90. See the "History page"_http://lammps.sandia.gov/history.html of
the website for details. All versions can be downloaded from the
"LAMMPS website"_lws.
LAMMPS is designed to be easy to modify or extend with new
capabilities, such as new force fields, atom types, boundary
conditions, or diagnostics. See the "Modify"_Modify.html doc page for
more details.
In the most general sense, LAMMPS integrates Newton's equations of
motion for a collection of interacting particles. A single particle
can be an atom or molecule or electron, a coarse-grained cluster of
atoms, or a mesoscopic or macroscopic clump of material. The
interaction models that LAMMPS includes are mostly short-range in
nature; some long-range models are included as well.
LAMMPS uses neighbor lists to keep track of nearby particles. The
lists are optimized for systems with particles that are repulsive at
short distances, so that the local density of particles never becomes
too large. This is in contrast to methods used for modeling plasmas
or gravitational bodies (e.g. galaxy formation).
On parallel machines, LAMMPS uses spatial-decomposition techniques to
partition the simulation domain into small sub-domains of equal
computational cost, one of which is assigned to each processor.
Processors communicate and store "ghost" atom information for atoms
that border their sub-domain.

42
doc/src/Intro_website.txt Normal file
View File

@ -0,0 +1,42 @@
"Higher level section"_Intro.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Additional website links :h3
The "LAMMPS website"_lws has a variety of additional info about
LAMMPS, beyond what is in this manual. Some of the other pages in
this Intr are included in this list.
"Brief intro and recently added significant features"_lws
"List of features"_http://lammps.sandia.gov/features.html
"List of non-features"_http://lammps.sandia.gov/non_features.html
"Recent bug fixes and new features"_http://lammps.sandia.gov/bug.html :ul
"Download info"_http://lammps.sandia.gov/download.html
"GitHub site"_https://github.com/lammps/lammps
"SourceForge site"_https://sourceforge.net/projects/lammps
"LAMMPS open-source license"_http://lammps.sandia.gov/open_source.html :ul
"Glossary of MD terms relevant to LAMMPS"_http://lammps.sandia.gov/glossary.html
"LAMMPS highlights with images"_http://lammps.sandia.gov/pictures.html
"LAMMPS highlights with movies"_http://lammps.sandia.gov/movies.html
"Mail list"_http://lammps.sandia.gov/mail.html
"Workshops"_http://lammps.sandia.gov/workshops.html
"Tutorials"_http://lammps.sandia.gov/tutorials.html
"Developer guide"_http://lammps.sandia.gov/Developer.pdf :ul
"Pre- and post-processing tools for LAMMPS"_http://lammps.sandia.gov/prepost.html
"Other software usable with LAMMPS"_http://lammps.sandia.gov/offsite.html
"Viz tools usable with LAMMPS"_http://lammps.sandia.gov/viz.html :ul
"Benchmark performance"_http://lammps.sandia.gov/bench.html
"Publications that have cited LAMMPS"_http://lammps.sandia.gov/papers.html
"Authors of LAMMPS"_http://lammps.sandia.gov/authors.html
"History of LAMMPS development"_http://lammps.sandia.gov/history.html
"Funding for LAMMPS"_http://lammps.sandia.gov/funding.html :ul

330
doc/src/Manual.txt
View File

@ -1,104 +1,67 @@
<!-- HTML_ONLY -->
<HEAD>
<TITLE>LAMMPS Users Manual</TITLE>
<META NAME="docnumber" CONTENT="16 Jul 2018 version">
<META NAME="docnumber" CONTENT="16 Aug 2018 version">
<META NAME="author" CONTENT="http://lammps.sandia.gov - Sandia National Laboratories">
<META NAME="copyright" CONTENT="Copyright (2003) Sandia Corporation. This software and manual is distributed under the GNU General Public License.">
</HEAD>
<BODY>
<H1></H1>
<!-- END_HTML_ONLY -->
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:link(lc,Commands_all.html#comm)
:line
LAMMPS Documentation :c,h1
16 Jul 2018 version :c,h2
16 Aug 2018 version :c,h2
Version info: :h3
The LAMMPS "version" is the date when it was released, such as 1 May
2010. LAMMPS is updated continuously. Whenever we fix a bug or add a
feature, we release it immediately, and post a notice on "this page of
the WWW site"_bug. Every 2-4 months one of the incremental releases
is subjected to more thorough testing and labeled as a {stable} version.
Each dated copy of LAMMPS contains all the
features and bug-fixes up to and including that version date. The
version date is printed to the screen and logfile every time you run
LAMMPS. It is also in the file src/version.h and in the LAMMPS
directory name created when you unpack a tarball, and at the top of
the first page of the manual (this page).
If you browse the HTML doc pages on the LAMMPS WWW site, they always
describe the most current [development] version of LAMMPS. :ulb,l
If you browse the HTML doc pages included in your tarball, they
describe the version you have. :l
The "PDF file"_Manual.pdf on the WWW site or in the tarball is updated
about once per month. This is because it is large, and we don't want
it to be part of every patch. :l
There is also a "Developer.pdf"_Developer.pdf file in the doc
directory, which describes the internal structure and algorithms of
LAMMPS. :l
:ule
"What is a LAMMPS version?"_Manual_version.html
LAMMPS stands for Large-scale Atomic/Molecular Massively Parallel
Simulator.
LAMMPS is a classical molecular dynamics simulation code designed to
run efficiently on parallel computers. It was developed at Sandia
National Laboratories, a US Department of Energy facility, with
funding from the DOE. It is an open-source code, distributed freely
under the terms of the GNU Public License (GPL).
LAMMPS is a classical molecular dynamics simulation code with a focus
on materials modeling. It was designed to run efficiently on parallel
computers. It was developed originally at Sandia National
Laboratories, a US Department of Energy facility. The majority of
funding for LAMMPS has come from the US Department of Energy (DOE).
LAMMPS is an open-source code, distributed freely under the terms of
the GNU Public License (GPL).
The current core group of LAMMPS developers is at Sandia National
Labs and Temple University:
"Steve Plimpton"_sjp, sjplimp at sandia.gov :ulb,l
Aidan Thompson, athomps at sandia.gov :l
Stan Moore, stamoor at sandia.gov :l
"Axel Kohlmeyer"_ako, akohlmey at gmail.com :l
:ule
Past core developers include Paul Crozier, Ray Shan and Mark Stevens,
all at Sandia. The [LAMMPS home page] at
"http://lammps.sandia.gov"_http://lammps.sandia.gov has more information
about the code and its uses. Interaction with external LAMMPS developers,
bug reports and feature requests are mainly coordinated through the
"LAMMPS project on GitHub."_https://github.com/lammps/lammps
The lammps.org domain, currently hosting "public continuous integration
testing"_https://ci.lammps.org/job/lammps/ and "precompiled Linux
RPM and Windows installer packages"_http://packages.lammps.org is located
at Temple University and managed by Richard Berger,
richard.berger at temple.edu.
:link(bug,http://lammps.sandia.gov/bug.html)
:link(sjp,http://www.sandia.gov/~sjplimp)
:link(ako,http://goo.gl/1wk0)
The "LAMMPS website"_lws has a variety of information about the code.
It includes links to an on-line version of this manual, a "mail
list"_http://lammps.sandia.gov/mail.html where users can post
questions, and a "GitHub site"https://github.com/lammps/lammps where
all LAMMPS development is coordinated.
:line
The LAMMPS documentation is organized into the following sections. If
you find errors or omissions in this manual or have suggestions for
useful information to add, please send an email to the developers so
we can improve the LAMMPS documentation.
Once you are familiar with LAMMPS, you may want to bookmark "this
page"_Section_commands.html#comm at Section_commands.html#comm since
it gives quick access to documentation for all LAMMPS commands.
"PDF file"_Manual.pdf of the entire manual, generated by
"htmldoc"_http://freecode.com/projects/htmldoc
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.
:line
This manual is organized into the following sections.
Once you are familiar with LAMMPS, you may want to bookmark "this
page"_Commands.html since it gives quick access to a doc page for
every LAMMPS command.
<!-- RST
.. toctree::
@ -108,27 +71,27 @@ it gives quick access to documentation for all LAMMPS commands.
:name: userdoc
:includehidden:
Section_intro
Section_start
Section_commands
Section_packages
Section_accelerate
Section_howto
Section_example
Section_perf
Section_tools
Section_modify
Section_python
Section_errors
Section_history
Intro
Install
Build
Run_head
Commands
Packages
Speed
Howto
Examples
Tools
Modify
Python_head
Errors
Manual_build
.. toctree::
:caption: Index
:name: index
:hidden:
tutorials
commands
commands_list
fixes
computes
pairs
@ -146,191 +109,22 @@ Indices and tables
END_RST -->
<!-- HTML_ONLY -->
"Introduction"_Section_intro.html :olb,l
1.1 "What is LAMMPS"_intro_1 :ulb,b
1.2 "LAMMPS features"_intro_2 :b
1.3 "LAMMPS non-features"_intro_3 :b
1.4 "Open source distribution"_intro_4 :b
1.5 "Acknowledgments and citations"_intro_5 :ule,b
"Getting started"_Section_start.html :l
2.1 "What's in the LAMMPS distribution"_start_1 :ulb,b
2.2 "Making LAMMPS"_start_2 :b
2.3 "Making LAMMPS with optional packages"_start_3 :b
2.4 "Building LAMMPS as a library"_start_4 :b
2.5 "Running LAMMPS"_start_5 :b
2.6 "Command-line options"_start_6 :b
2.7 "Screen output"_start_7 :b
2.8 "Tips for users of previous versions"_start_8 :ule,b
"Commands"_Section_commands.html :l
3.1 "LAMMPS input script"_cmd_1 :ulb,b
3.2 "Parsing rules"_cmd_2 :b
3.3 "Input script structure"_cmd_3 :b
3.4 "Commands listed by category"_cmd_4 :b
3.5 "Commands listed alphabetically"_cmd_5 :ule,b
"Packages"_Section_packages.html :l
4.1 "Standard packages"_pkg_1 :ulb,b
4.2 "User packages"_pkg_2 :ule,b
"Accelerating LAMMPS performance"_Section_accelerate.html :l
5.1 "Measuring performance"_acc_1 :ulb,b
5.2 "Algorithms and code options to boost performace"_acc_2 :b
5.3 "Accelerator packages with optimized styles"_acc_3 :b
5.3.1 "GPU package"_accelerate_gpu.html :b
5.3.2 "USER-INTEL package"_accelerate_intel.html :b
5.3.3 "KOKKOS package"_accelerate_kokkos.html :b
5.3.4 "USER-OMP package"_accelerate_omp.html :b
5.3.5 "OPT package"_accelerate_opt.html :b
5.4 "Comparison of various accelerator packages"_acc_4 :ule,b
"How-to discussions"_Section_howto.html :l
6.1 "Restarting a simulation"_howto_1 :ulb,b
6.2 "2d simulations"_howto_2 :b
6.3 "CHARMM and AMBER force fields"_howto_3 :b
6.4 "Running multiple simulations from one input script"_howto_4 :b
6.5 "Multi-replica simulations"_howto_5 :b
6.6 "Granular models"_howto_6 :b
6.7 "TIP3P water model"_howto_7 :b
6.8 "TIP4P water model"_howto_8 :b
6.9 "SPC water model"_howto_9 :b
6.10 "Coupling LAMMPS to other codes"_howto_10 :b
6.11 "Visualizing LAMMPS snapshots"_howto_11 :b
6.12 "Triclinic (non-orthogonal) simulation boxes"_howto_12 :b
6.13 "NEMD simulations"_howto_13 :b
6.14 "Finite-size spherical and aspherical particles"_howto_14 :b
6.15 "Output from LAMMPS (thermo, dumps, computes, fixes, variables)"_howto_15 :b
6.16 "Thermostatting, barostatting, and compute temperature"_howto_16 :b
6.17 "Walls"_howto_17 :b
6.18 "Elastic constants"_howto_18 :b
6.19 "Library interface to LAMMPS"_howto_19 :b
6.20 "Calculating thermal conductivity"_howto_20 :b
6.21 "Calculating viscosity"_howto_21 :b
6.22 "Calculating a diffusion coefficient"_howto_22 :b
6.23 "Using chunks to calculate system properties"_howto_23 :b
6.24 "Setting parameters for pppm/disp"_howto_24 :b
6.25 "Polarizable models"_howto_25 :b
6.26 "Adiabatic core/shell model"_howto_26 :b
6.27 "Drude induced dipoles"_howto_27 :ule,b
"Example problems"_Section_example.html :l
"Performance & scalability"_Section_perf.html :l
"Additional tools"_Section_tools.html :l
"Modifying & extending LAMMPS"_Section_modify.html :l
10.1 "Atom styles"_mod_1 :ulb,b
10.2 "Bond, angle, dihedral, improper potentials"_mod_2 :b
10.3 "Compute styles"_mod_3 :b
10.4 "Dump styles"_mod_4 :b
10.5 "Dump custom output options"_mod_5 :b
10.6 "Fix styles"_mod_6 :b
10.7 "Input script commands"_mod_7 :b
10.8 "Kspace computations"_mod_8 :b
10.9 "Minimization styles"_mod_9 :b
10.10 "Pairwise potentials"_mod_10 :b
10.11 "Region styles"_mod_11 :b
10.12 "Body styles"_mod_12 :b
10.13 "Thermodynamic output options"_mod_13 :b
10.14 "Variable options"_mod_14 :b
10.15 "Submitting new features for inclusion in LAMMPS"_mod_15 :ule,b
"Python interface"_Section_python.html :l
11.1 "Overview of running LAMMPS from Python"_py_1 :ulb,b
11.2 "Overview of using Python from a LAMMPS script"_py_2 :b
11.3 "Building LAMMPS as a shared library"_py_3 :b
11.4 "Installing the Python wrapper into Python"_py_4 :b
11.5 "Extending Python with MPI to run in parallel"_py_5 :b
11.6 "Testing the Python-LAMMPS interface"_py_6 :b
11.7 "Using LAMMPS from Python"_py_7 :b
11.8 "Example Python scripts that use LAMMPS"_py_8 :ule,b
"Errors"_Section_errors.html :l
12.1 "Common problems"_err_1 :ulb,b
12.2 "Reporting bugs"_err_2 :b
12.3 "Error & warning messages"_err_3 :ule,b
"Future and history"_Section_history.html :l
13.1 "Coming attractions"_hist_1 :ulb,b
13.2 "Past versions"_hist_2 :ule,b
"Introduction"_Intro.html :olb,l
"Install LAMMPS"_Install.html :l
"Build LAMMPS"_Build.html :l
"Run LAMMPS"_Run_head.html :l
"Commands"_Commands.html :l
"Optional packages"_Packages.html :l
"Accelerate performance"_Speed.html :l
"How-to discussions"_Howto.html :l
"Example scripts"_Examples.html :l
"Auxiliary tools"_Tools.html :l
"Modify & extend LAMMPS"_Modify.html :l
"Use Python with LAMMPS"_Python_head.html :l
"Errors"_Errors.html :l
"Building the LAMMPS manual"_Manual_build.html :l
:ole
:link(intro_1,Section_intro.html#intro_1)
:link(intro_2,Section_intro.html#intro_2)
:link(intro_3,Section_intro.html#intro_3)
:link(intro_4,Section_intro.html#intro_4)
:link(intro_5,Section_intro.html#intro_5)
:link(start_1,Section_start.html#start_1)
:link(start_2,Section_start.html#start_2)
:link(start_3,Section_start.html#start_3)
:link(start_4,Section_start.html#start_4)
:link(start_5,Section_start.html#start_5)
:link(start_6,Section_start.html#start_6)
:link(start_7,Section_start.html#start_7)
:link(start_8,Section_start.html#start_8)
:link(cmd_1,Section_commands.html#cmd_1)
:link(cmd_2,Section_commands.html#cmd_2)
:link(cmd_3,Section_commands.html#cmd_3)
:link(cmd_4,Section_commands.html#cmd_4)
:link(cmd_5,Section_commands.html#cmd_5)
:link(pkg_1,Section_packages.html#pkg_1)
:link(pkg_2,Section_packages.html#pkg_2)
:link(acc_1,Section_accelerate.html#acc_1)
:link(acc_2,Section_accelerate.html#acc_2)
:link(acc_3,Section_accelerate.html#acc_3)
:link(acc_4,Section_accelerate.html#acc_4)
:link(howto_1,Section_howto.html#howto_1)
:link(howto_2,Section_howto.html#howto_2)
:link(howto_3,Section_howto.html#howto_3)
:link(howto_4,Section_howto.html#howto_4)
:link(howto_5,Section_howto.html#howto_5)
:link(howto_6,Section_howto.html#howto_6)
:link(howto_7,Section_howto.html#howto_7)
:link(howto_8,Section_howto.html#howto_8)
:link(howto_9,Section_howto.html#howto_9)
:link(howto_10,Section_howto.html#howto_10)
:link(howto_11,Section_howto.html#howto_11)
:link(howto_12,Section_howto.html#howto_12)
:link(howto_13,Section_howto.html#howto_13)
:link(howto_14,Section_howto.html#howto_14)
:link(howto_15,Section_howto.html#howto_15)
:link(howto_16,Section_howto.html#howto_16)
:link(howto_17,Section_howto.html#howto_17)
:link(howto_18,Section_howto.html#howto_18)
:link(howto_19,Section_howto.html#howto_19)
:link(howto_20,Section_howto.html#howto_20)
:link(howto_21,Section_howto.html#howto_21)
:link(howto_22,Section_howto.html#howto_22)
:link(howto_23,Section_howto.html#howto_23)
:link(howto_24,Section_howto.html#howto_24)
:link(howto_25,Section_howto.html#howto_25)
:link(howto_26,Section_howto.html#howto_26)
:link(howto_27,Section_howto.html#howto_27)
:link(mod_1,Section_modify.html#mod_1)
:link(mod_2,Section_modify.html#mod_2)
:link(mod_3,Section_modify.html#mod_3)
:link(mod_4,Section_modify.html#mod_4)
:link(mod_5,Section_modify.html#mod_5)
:link(mod_6,Section_modify.html#mod_6)
:link(mod_7,Section_modify.html#mod_7)
:link(mod_8,Section_modify.html#mod_8)
:link(mod_9,Section_modify.html#mod_9)
:link(mod_10,Section_modify.html#mod_10)
:link(mod_11,Section_modify.html#mod_11)
:link(mod_12,Section_modify.html#mod_12)
:link(mod_13,Section_modify.html#mod_13)
:link(mod_14,Section_modify.html#mod_14)
:link(mod_15,Section_modify.html#mod_15)
:link(py_1,Section_python.html#py_1)
:link(py_2,Section_python.html#py_2)
:link(py_3,Section_python.html#py_3)
:link(py_4,Section_python.html#py_4)
:link(py_5,Section_python.html#py_5)
:link(py_6,Section_python.html#py_6)
:link(err_1,Section_errors.html#err_1)
:link(err_2,Section_errors.html#err_2)
:link(err_3,Section_errors.html#err_3)
:link(hist_1,Section_history.html#hist_1)
:link(hist_2,Section_history.html#hist_2)
<!-- END_HTML_ONLY -->
</BODY>

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

33
doc/src/Manual_version.txt Normal file
View File

@ -0,0 +1,33 @@
"Higher level section"_Manual.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
What does a LAMMPS version mean :h3
The LAMMPS "version" is the date when it was released, such as 1 May
2014. LAMMPS is updated continuously. Whenever we fix a bug or add a
feature, we release it in the next {patch} release, which are
typically made every couple of weeks. Info on patch releases are on
"this website page"_http://lammps.sandia.gov/bug.html. Every few
months, the latest patch release is subjected to more thorough testing
and labeled as a {stable} version.
Each version of LAMMPS contains all the features and bug-fixes up to
and including its version date.
The version date is printed to the screen and logfile every time you
run LAMMPS. It is also in the file src/version.h and in the LAMMPS
directory name created when you unpack a tarball. And it is on the
first page of the "manual"_Manual.html.
If you browse the HTML doc pages on the LAMMPS WWW site, they always
describe the most current patch release of LAMMPS. :ulb,l
If you browse the HTML doc pages included in your tarball, they
describe the version you have, which may be older. :l,ule

70
doc/src/Modify.txt Normal file
View File

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

90
doc/src/Modify_atom.txt Normal file
View File

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

34
doc/src/Modify_body.txt Normal file
View File

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

33
doc/src/Modify_bond.txt Normal file
View File

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

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