Merge branch 'master' into user-cgdna
This commit is contained in:
4
.github/CODEOWNERS
vendored
4
.github/CODEOWNERS
vendored
@ -29,6 +29,7 @@ src/USER-MEAMC/* @martok
|
||||
src/USER-MOFFF/* @hheenen
|
||||
src/USER-MOLFILE/* @akohlmey
|
||||
src/USER-NETCDF/* @pastewka
|
||||
src/USER-PLUMED/* @gtribello
|
||||
src/USER-PHONON/* @lingtikong
|
||||
src/USER-PTM/* @pmla
|
||||
src/USER-OMP/* @akohlmey
|
||||
@ -125,3 +126,6 @@ python/* @rbberger
|
||||
doc/utils/*/* @rbberger
|
||||
doc/Makefile @rbberger
|
||||
doc/README @rbberger
|
||||
|
||||
# for releases
|
||||
src/version.h @sjplimp
|
||||
|
||||
1
.gitignore
vendored
1
.gitignore
vendored
@ -22,6 +22,7 @@ log.cite
|
||||
.*.swp
|
||||
*.orig
|
||||
*.rej
|
||||
vgcore.*
|
||||
.vagrant
|
||||
\#*#
|
||||
.#*
|
||||
|
||||
@ -11,6 +11,10 @@ get_filename_component(LAMMPS_LIB_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../lib
|
||||
get_filename_component(LAMMPS_LIB_BINARY_DIR ${CMAKE_BINARY_DIR}/lib ABSOLUTE)
|
||||
get_filename_component(LAMMPS_DOC_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../doc ABSOLUTE)
|
||||
|
||||
# by default, install into $HOME/.local (not /usr/local), so that no root access (and sudo!!) is needed
|
||||
if (CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
|
||||
set(CMAKE_INSTALL_PREFIX "$ENV{HOME}/.local" CACHE PATH "default install path" FORCE )
|
||||
endif()
|
||||
|
||||
# To avoid conflicts with the conventional Makefile build system, we build everything here
|
||||
file(GLOB LIB_SOURCES ${LAMMPS_SOURCE_DIR}/[^.]*.cpp)
|
||||
@ -75,6 +79,7 @@ if(NOT CMAKE_BUILD_TYPE AND NOT CMAKE_CXX_FLAGS)
|
||||
#release comes with -O3 by default
|
||||
set(CMAKE_BUILD_TYPE Release CACHE STRING "Choose the type of build, options are: None Debug Release RelWithDebInfo MinSizeRel." FORCE)
|
||||
endif(NOT CMAKE_BUILD_TYPE AND NOT CMAKE_CXX_FLAGS)
|
||||
string(TOUPPER "${CMAKE_BUILD_TYPE}" BTYPE)
|
||||
|
||||
# check for files auto-generated by make-based buildsystem
|
||||
# this is fast, so check for it all the time
|
||||
@ -166,13 +171,14 @@ set(LAMMPS_DEPS)
|
||||
set(LAMMPS_API_DEFINES)
|
||||
|
||||
set(DEFAULT_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS DIPOLE GRANULAR
|
||||
KSPACE MANYBODY MC MEAM MESSAGE MISC MOLECULE PERI REAX REPLICA RIGID SHOCK
|
||||
KSPACE MANYBODY MC MESSAGE MISC MOLECULE PERI 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-PTM USER-QTB USER-REAXC USER-SCAFACOS USER-SMD USER-SMTBQ
|
||||
USER-SPH USER-TALLY USER-UEF USER-VTK USER-QUIP USER-QMMM)
|
||||
USER-PHONON USER-PLUMED USER-PTM USER-QTB USER-REAXC USER-SCAFACOS
|
||||
USER-SDPD 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})
|
||||
@ -185,11 +191,11 @@ endforeach()
|
||||
######################################################
|
||||
# packages with special compiler needs or external libs
|
||||
######################################################
|
||||
if(PKG_REAX OR PKG_MEAM OR PKG_USER-QUIP OR PKG_USER-QMMM OR PKG_LATTE OR PKG_USER-SCAFACOS)
|
||||
if(PKG_USER-QUIP OR PKG_USER-QMMM OR PKG_LATTE OR PKG_USER-SCAFACOS)
|
||||
enable_language(Fortran)
|
||||
endif()
|
||||
|
||||
if(PKG_MEAM OR PKG_USER-H5MD OR PKG_USER-QMMM OR PKG_USER-SCAFACOS)
|
||||
if(PKG_USER-H5MD OR PKG_USER-QMMM OR PKG_USER-SCAFACOS)
|
||||
enable_language(C)
|
||||
endif()
|
||||
|
||||
@ -215,7 +221,7 @@ else()
|
||||
endif()
|
||||
|
||||
|
||||
set(LAMMPS_SIZES "smallbig" CACHE STRING "LAMMPS size limit")
|
||||
set(LAMMPS_SIZES "smallbig" CACHE STRING "LAMMPS integer sizes (smallsmall: all 32-bit, smallbig: 64-bit #atoms #timesteps, bigbig: also 64-bit imageint, 64-bit atom ids)")
|
||||
set(LAMMPS_SIZES_VALUES smallbig bigbig smallsmall)
|
||||
set_property(CACHE LAMMPS_SIZES PROPERTY STRINGS ${LAMMPS_SIZES_VALUES})
|
||||
validate_option(LAMMPS_SIZES LAMMPS_SIZES_VALUES)
|
||||
@ -303,7 +309,7 @@ pkg_depends(USER-SCAFACOS MPI)
|
||||
|
||||
find_package(OpenMP QUIET)
|
||||
option(BUILD_OMP "Build with OpenMP support" ${OpenMP_FOUND})
|
||||
if(BUILD_OMP OR PKG_USER-OMP OR PKG_KOKKOS OR PKG_USER-INTEL)
|
||||
if(BUILD_OMP OR PKG_KOKKOS OR PKG_USER-INTEL)
|
||||
find_package(OpenMP REQUIRED)
|
||||
set (CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${OpenMP_C_FLAGS}")
|
||||
set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${OpenMP_CXX_FLAGS}")
|
||||
@ -421,16 +427,30 @@ if(WITH_FFMPEG)
|
||||
add_definitions(-DLAMMPS_FFMPEG)
|
||||
endif()
|
||||
|
||||
if(BUILD_SHARED_LIBS)
|
||||
set(CONFIGURE_REQUEST_PIC "--with-pic")
|
||||
set(CMAKE_REQUEST_PIC "-DCMAKE_POSITION_INDEPENDENT_CODE=${CMAKE_POSITION_INDEPENDENT_CODE}")
|
||||
set(CUDA_REQUEST_PIC "-Xcompiler ${CMAKE_SHARED_LIBRARY_CXX_FLAGS}")
|
||||
else()
|
||||
set(CONFIGURE_REQUEST_PIC)
|
||||
set(CMAKE_REQUEST_PIC)
|
||||
set(CUDA_REQUEST_PIC)
|
||||
endif()
|
||||
|
||||
|
||||
if(PKG_VORONOI)
|
||||
option(DOWNLOAD_VORO "Download voro++ (instead of using the system's one)" OFF)
|
||||
option(DOWNLOAD_VORO "Download and compile the Voro++ library instead of using an already installed one" OFF)
|
||||
if(DOWNLOAD_VORO)
|
||||
message(STATUS "Voro++ download requested - we will build our own")
|
||||
include(ExternalProject)
|
||||
|
||||
if(BUILD_SHARED_LIBS)
|
||||
set(VORO_BUILD_OPTIONS "CFLAGS=-fPIC")
|
||||
set(VORO_BUILD_CFLAGS "${CMAKE_SHARED_LIBRARY_CXX_FLAGS} ${CMAKE_CXX_FLAGS} ${CMAKE_CXX_FLAGS_${BTYPE}}")
|
||||
else()
|
||||
set(VORO_BUILD_OPTIONS)
|
||||
set(VORO_BUILD_CFLAGS "${CMAKE_CXX_FLAGS} ${CMAKE_CXX_FLAGS_${BTYPE}}")
|
||||
endif()
|
||||
string(APPEND VORO_BUILD_CFLAGS ${CMAKE_CXX_FLAGS})
|
||||
set(VORO_BUILD_OPTIONS CXX=${CMAKE_CXX_COMPILER} CFLAGS=${VORO_BUILD_CFLAGS})
|
||||
|
||||
ExternalProject_Add(voro_build
|
||||
URL http://math.lbl.gov/voro++/download/dir/voro++-0.4.6.tar.gz
|
||||
@ -444,7 +464,7 @@ if(PKG_VORONOI)
|
||||
else()
|
||||
find_package(VORO)
|
||||
if(NOT VORO_FOUND)
|
||||
message(FATAL_ERROR "VORO not found, help CMake to find it by setting VORO_LIBRARY and VORO_INCLUDE_DIR, or set DOWNLOAD_VORO=ON to download it")
|
||||
message(FATAL_ERROR "Voro++ library not found. Help CMake to find it by setting VORO_LIBRARY and VORO_INCLUDE_DIR, or set DOWNLOAD_VORO=ON to download it")
|
||||
endif()
|
||||
endif()
|
||||
include_directories(${VORO_INCLUDE_DIRS})
|
||||
@ -452,26 +472,26 @@ if(PKG_VORONOI)
|
||||
endif()
|
||||
|
||||
if(PKG_LATTE)
|
||||
option(DOWNLOAD_LATTE "Download latte (instead of using the system's one)" OFF)
|
||||
option(DOWNLOAD_LATTE "Download the LATTE library instead of using an already installed one" OFF)
|
||||
if(DOWNLOAD_LATTE)
|
||||
if (CMAKE_VERSION VERSION_LESS "3.7") # due to SOURCE_SUBDIR
|
||||
if (CMAKE_VERSION VERSION_LESS "3.7") # due to SOURCE_SUBDIR
|
||||
message(FATAL_ERROR "For downlading LATTE you need at least cmake-3.7")
|
||||
endif()
|
||||
message(STATUS "LATTE not found - we will build our own")
|
||||
message(STATUS "LATTE download requested - we will build our own")
|
||||
include(ExternalProject)
|
||||
ExternalProject_Add(latte_build
|
||||
URL https://github.com/lanl/LATTE/archive/v1.2.1.tar.gz
|
||||
URL_MD5 85ac414fdada2d04619c8f936344df14
|
||||
SOURCE_SUBDIR cmake
|
||||
CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=<INSTALL_DIR> -DCMAKE_POSITION_INDEPENDENT_CODE=${CMAKE_POSITION_INDEPENDENT_CODE}
|
||||
)
|
||||
CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=<INSTALL_DIR> ${CMAKE_REQUEST_PIC}
|
||||
)
|
||||
ExternalProject_get_property(latte_build INSTALL_DIR)
|
||||
set(LATTE_LIBRARIES ${INSTALL_DIR}/${CMAKE_INSTALL_LIBDIR}/liblatte.a)
|
||||
list(APPEND LAMMPS_DEPS latte_build)
|
||||
else()
|
||||
find_package(LATTE)
|
||||
if(NOT LATTE_FOUND)
|
||||
message(FATAL_ERROR "LATTE not found, help CMake to find it by setting LATTE_LIBRARY, or set DOWNLOAD_LATTE=ON to download it")
|
||||
message(FATAL_ERROR "LATTE library not found, help CMake to find it by setting LATTE_LIBRARY, or set DOWNLOAD_LATTE=ON to download it")
|
||||
endif()
|
||||
endif()
|
||||
list(APPEND LAMMPS_LINK_LIBS ${LATTE_LIBRARIES} ${LAPACK_LIBRARIES})
|
||||
@ -479,24 +499,22 @@ endif()
|
||||
|
||||
if(PKG_USER-SCAFACOS)
|
||||
find_package(GSL REQUIRED)
|
||||
option(DOWNLOAD_SCAFACOS "Download ScaFaCoS (instead of using the system's one)" OFF)
|
||||
option(DOWNLOAD_SCAFACOS "Download ScaFaCoS library instead of using an already installed one" OFF)
|
||||
if(DOWNLOAD_SCAFACOS)
|
||||
message(STATUS "ScaFaCoS download requested - we will build our own")
|
||||
include(ExternalProject)
|
||||
ExternalProject_Add(scafacos_build
|
||||
URL https://github.com/scafacos/scafacos/releases/download/v1.0.1/scafacos-1.0.1.tar.gz
|
||||
URL_MD5 bd46d74e3296bd8a444d731bb10c1738
|
||||
CONFIGURE_COMMAND <SOURCE_DIR>/configure --prefix=<INSTALL_DIR>
|
||||
--disable-doc
|
||||
CONFIGURE_COMMAND <SOURCE_DIR>/configure --prefix=<INSTALL_DIR> --disable-doc
|
||||
--enable-fcs-solvers=fmm,p2nfft,direct,ewald,p3m
|
||||
--with-internal-fftw
|
||||
--with-internal-pfft
|
||||
--with-internal-pnfft
|
||||
$<$<BOOL:${BUILD_SHARED_LIBS}>:--with-pic>
|
||||
FC=${CMAKE_MPI_Fortran_COMPILER}
|
||||
CXX=${CMAKE_MPI_CXX_COMPILER}
|
||||
--with-internal-fftw --with-internal-pfft
|
||||
--with-internal-pnfft ${CONFIGURE_REQUEST_PIC}
|
||||
FC=${CMAKE_MPI_Fortran_COMPILER}
|
||||
CXX=${CMAKE_MPI_CXX_COMPILER}
|
||||
CC=${CMAKE_MPI_C_COMPILER}
|
||||
F77=
|
||||
)
|
||||
)
|
||||
ExternalProject_get_property(scafacos_build INSTALL_DIR)
|
||||
set(SCAFACOS_BUILD_DIR ${INSTALL_DIR})
|
||||
set(SCAFACOS_INCLUDE_DIRS ${SCAFACOS_BUILD_DIR}/include)
|
||||
@ -528,6 +546,54 @@ if(PKG_USER-SCAFACOS)
|
||||
include_directories(${SCAFACOS_INCLUDE_DIRS})
|
||||
endif()
|
||||
|
||||
if(PKG_USER-PLUMED)
|
||||
find_package(GSL REQUIRED)
|
||||
set(PLUMED_MODE "static" CACHE STRING "Linkage mode for Plumed2 library")
|
||||
set(PLUMED_MODE_VALUES static shared runtime)
|
||||
set_property(CACHE PLUMED_MODE PROPERTY STRINGS ${PLUMED_MODE_VALUES})
|
||||
validate_option(PLUMED_MODE PLUMED_MODE_VALUES)
|
||||
string(TOUPPER ${PLUMED_MODE} PLUMED_MODE)
|
||||
|
||||
option(DOWNLOAD_PLUMED "Download Plumed package instead of using an already installed one" OFF)
|
||||
if(DOWNLOAD_PLUMED)
|
||||
message(STATUS "PLUMED download requested - we will build our own")
|
||||
include(ExternalProject)
|
||||
ExternalProject_Add(plumed_build
|
||||
URL https://github.com/plumed/plumed2/releases/download/v2.4.3/plumed-src-2.4.3.tgz
|
||||
URL_MD5 b1be7c48971627febc11c61b70767fc5
|
||||
BUILD_IN_SOURCE 1
|
||||
CONFIGURE_COMMAND <SOURCE_DIR>/configure --prefix=<INSTALL_DIR> ${CONFIGURE_REQUEST_PIC})
|
||||
ExternalProject_get_property(plumed_build INSTALL_DIR)
|
||||
set(PLUMED_INSTALL_DIR ${INSTALL_DIR})
|
||||
list(APPEND LAMMPS_DEPS plumed_build)
|
||||
if(PLUMED_MODE STREQUAL "STATIC")
|
||||
add_definitions(-D__PLUMED_WRAPPER_CXX=1)
|
||||
list(APPEND LAMMPS_LINK_LIBS ${PLUMED_INSTALL_DIR}/lib/plumed/obj/kernel.o
|
||||
"${PLUMED_INSTALL_DIR}/lib/plumed/obj/PlumedStatic.o" ${GSL_LIBRARIES} ${CMAKE_DL_LIBS})
|
||||
elseif(PLUMED_MODE STREQUAL "SHARED")
|
||||
list(APPEND LAMMPS_LINK_LIBS ${PLUMED_INSTALL_DIR}/lib/libplumed.so ${CMAKE_DL_LIBS})
|
||||
elseif(PLUMED_MODE STREQUAL "RUNTIME")
|
||||
add_definitions(-D__PLUMED_HAS_DLOPEN=1 -D__PLUMED_DEFAULT_KERNEL=${PLUMED_INSTALL_DIR}/lib/libplumedKernel.so)
|
||||
list(APPEND LAMMPS_LINK_LIBS ${PLUMED_INSTALL_DIR}/lib/libplumedWrapper.a -rdynamic ${CMAKE_DL_LIBS})
|
||||
endif()
|
||||
set(PLUMED_INCLUDE_DIRS "${PLUMED_INSTALL_DIR}/include")
|
||||
else()
|
||||
find_package(PkgConfig REQUIRED)
|
||||
pkg_check_modules(PLUMED plumed REQUIRED)
|
||||
if(PLUMED_MODE STREQUAL "STATIC")
|
||||
add_definitions(-D__PLUMED_WRAPPER_CXX=1)
|
||||
include(${PLUMED_LIBDIR}/plumed/src/lib/Plumed.cmake.static)
|
||||
elseif(PLUMED_MODE STREQUAL "SHARED")
|
||||
include(${PLUMED_LIBDIR}/plumed/src/lib/Plumed.cmake.shared)
|
||||
elseif(PLUMED_MODE STREQUAL "RUNTIME")
|
||||
add_definitions(-D__PLUMED_HAS_DLOPEN=1 -D__PLUMED_DEFAULT_KERNEL=${PLUMED_LIBDIR}/libplumedKernel.so)
|
||||
include(${PLUMED_LIBDIR}/plumed/src/lib/Plumed.cmake.runtime)
|
||||
endif()
|
||||
list(APPEND LAMMPS_LINK_LIBS ${PLUMED_LOAD})
|
||||
endif()
|
||||
include_directories(${PLUMED_INCLUDE_DIRS})
|
||||
endif()
|
||||
|
||||
if(PKG_USER-MOLFILE)
|
||||
add_library(molfile INTERFACE)
|
||||
target_include_directories(molfile INTERFACE ${LAMMPS_LIB_SOURCE_DIR}/molfile)
|
||||
@ -543,11 +609,12 @@ if(PKG_USER-NETCDF)
|
||||
endif()
|
||||
|
||||
if(PKG_USER-SMD)
|
||||
option(DOWNLOAD_EIGEN3 "Download Eigen3 (instead of using the system's one)" OFF)
|
||||
option(DOWNLOAD_EIGEN3 "Download Eigen3 instead of using an already installed one)" OFF)
|
||||
if(DOWNLOAD_EIGEN3)
|
||||
message(STATUS "Eigen3 download requested - we will build our own")
|
||||
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 ""
|
||||
)
|
||||
@ -584,8 +651,9 @@ if(PKG_USER-VTK)
|
||||
endif()
|
||||
|
||||
if(PKG_KIM)
|
||||
option(DOWNLOAD_KIM "Download kim-api (instead of using the system's one)" OFF)
|
||||
option(DOWNLOAD_KIM "Download KIM-API v1 from OpenKIM instead of using an already installed one)" OFF)
|
||||
if(DOWNLOAD_KIM)
|
||||
message(STATUS "KIM-API v1 download requested - we will build our own")
|
||||
include(ExternalProject)
|
||||
ExternalProject_Add(kim_build
|
||||
URL https://github.com/openkim/kim-api/archive/v1.9.5.tar.gz
|
||||
@ -600,7 +668,7 @@ if(PKG_KIM)
|
||||
else()
|
||||
find_package(KIM)
|
||||
if(NOT KIM_FOUND)
|
||||
message(FATAL_ERROR "KIM not found, help CMake to find it by setting KIM_LIBRARY and KIM_INCLUDE_DIR, or set DOWNLOAD_KIM=ON to download it")
|
||||
message(FATAL_ERROR "KIM-API v1 not found, help CMake to find it by setting KIM_LIBRARY and KIM_INCLUDE_DIR, or set DOWNLOAD_KIM=ON to download it")
|
||||
endif()
|
||||
endif()
|
||||
list(APPEND LAMMPS_LINK_LIBS ${KIM_LIBRARIES})
|
||||
@ -613,12 +681,7 @@ if(PKG_MESSAGE)
|
||||
${LAMMPS_LIB_SOURCE_DIR}/message/cslib/[^.]*.c
|
||||
${LAMMPS_LIB_SOURCE_DIR}/message/cslib/[^.]*.cpp)
|
||||
|
||||
if(BUILD_SHARED_LIBS)
|
||||
add_library(cslib SHARED ${cslib_SOURCES})
|
||||
else()
|
||||
add_library(cslib STATIC ${cslib_SOURCES})
|
||||
endif()
|
||||
|
||||
add_library(cslib STATIC ${cslib_SOURCES})
|
||||
if(BUILD_MPI)
|
||||
target_compile_definitions(cslib PRIVATE -DMPI_YES)
|
||||
set_target_properties(cslib PROPERTIES OUTPUT_NAME "csmpi")
|
||||
@ -643,10 +706,10 @@ endif()
|
||||
|
||||
if(PKG_MSCG)
|
||||
find_package(GSL REQUIRED)
|
||||
option(DOWNLOAD_MSCG "Download latte (instead of using the system's one)" OFF)
|
||||
option(DOWNLOAD_MSCG "Download MSCG library instead of using an already installed one)" OFF)
|
||||
if(DOWNLOAD_MSCG)
|
||||
if (CMAKE_VERSION VERSION_LESS "3.7") # due to SOURCE_SUBDIR
|
||||
message(FATAL_ERROR "For downlading LATTE you need at least cmake-3.7")
|
||||
if (CMAKE_VERSION VERSION_LESS "3.7") # due to SOURCE_SUBDIR
|
||||
message(FATAL_ERROR "For downlading MSCG you need at least cmake-3.7")
|
||||
endif()
|
||||
include(ExternalProject)
|
||||
if(NOT LAPACK_FOUND)
|
||||
@ -656,7 +719,7 @@ if(PKG_MSCG)
|
||||
URL https://github.com/uchicago-voth/MSCG-release/archive/1.7.3.1.tar.gz
|
||||
URL_MD5 8c45e269ee13f60b303edd7823866a91
|
||||
SOURCE_SUBDIR src/CMake
|
||||
CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=<INSTALL_DIR> -DCMAKE_POSITION_INDEPENDENT_CODE=${CMAKE_POSITION_INDEPENDENT_CODE} ${EXTRA_MSCG_OPTS}
|
||||
CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=<INSTALL_DIR> ${CMAKE_REQUEST_PIC} ${EXTRA_MSCG_OPTS}
|
||||
BUILD_COMMAND make mscg INSTALL_COMMAND ""
|
||||
)
|
||||
ExternalProject_get_property(mscg_build BINARY_DIR)
|
||||
@ -704,7 +767,7 @@ set(MATH_LIBRARIES "m" CACHE STRING "math library")
|
||||
mark_as_advanced( MATH_LIBRARIES )
|
||||
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
|
||||
enable_language(C) # check_library_exists isn't supported without a C compiler before v3.4
|
||||
endif()
|
||||
# RB: disabled this check because it breaks with KOKKOS CUDA enabled
|
||||
#foreach(FUNC sin cos)
|
||||
@ -742,6 +805,13 @@ foreach(PKG ${DEFAULT_PACKAGES})
|
||||
endif()
|
||||
endforeach()
|
||||
|
||||
# packages that need defines set
|
||||
foreach(PKG MPIIO)
|
||||
if(PKG_${PKG})
|
||||
add_definitions(-DLMP_${PKG})
|
||||
endif()
|
||||
endforeach()
|
||||
|
||||
# dedicated check for entire contents of accelerator packages
|
||||
foreach(PKG ${ACCEL_PACKAGES})
|
||||
set(${PKG}_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/${PKG})
|
||||
@ -756,7 +826,7 @@ endforeach()
|
||||
##############################################
|
||||
# add lib sources of (simple) enabled packages
|
||||
############################################
|
||||
foreach(SIMPLE_LIB REAX MEAM POEMS USER-ATC USER-AWPMD USER-COLVARS USER-H5MD
|
||||
foreach(SIMPLE_LIB POEMS USER-ATC USER-AWPMD USER-COLVARS USER-H5MD
|
||||
USER-QMMM)
|
||||
if(PKG_${SIMPLE_LIB})
|
||||
string(REGEX REPLACE "^USER-" "" PKG_LIB "${SIMPLE_LIB}")
|
||||
@ -770,7 +840,7 @@ foreach(SIMPLE_LIB REAX MEAM POEMS USER-ATC USER-AWPMD USER-COLVARS USER-H5MD
|
||||
if(PKG_LIB STREQUAL awpmd)
|
||||
target_include_directories(awpmd PUBLIC ${LAMMPS_LIB_SOURCE_DIR}/awpmd/systems/interact ${LAMMPS_LIB_SOURCE_DIR}/awpmd/ivutils/include)
|
||||
elseif(PKG_LIB STREQUAL h5md)
|
||||
target_include_directories(h5md PUBLIC ${LAMMPS_LIB_SOURCE_DIR}/h5md/include)
|
||||
target_include_directories(h5md PUBLIC ${LAMMPS_LIB_SOURCE_DIR}/h5md/include ${HDF5_INCLUDE_DIRS})
|
||||
elseif(PKG_LIB STREQUAL colvars)
|
||||
target_compile_options(colvars PRIVATE -DLEPTON)
|
||||
target_include_directories(colvars PRIVATE ${LAMMPS_LIB_SOURCE_DIR}/colvars/lepton/include)
|
||||
@ -786,6 +856,9 @@ if(PKG_USER-AWPMD)
|
||||
endif()
|
||||
|
||||
if(PKG_USER-ATC)
|
||||
if(LAMMPS_SIZES STREQUAL BIGBIG)
|
||||
message(FATAL_ERROR "The USER-ATC Package is not compatible with -DLAMMPS_BIGBIG")
|
||||
endif()
|
||||
target_link_libraries(atc ${LAPACK_LIBRARIES})
|
||||
endif()
|
||||
|
||||
@ -793,6 +866,7 @@ if(PKG_USER-H5MD)
|
||||
find_package(HDF5 REQUIRED)
|
||||
target_link_libraries(h5md ${HDF5_LIBRARIES})
|
||||
target_include_directories(h5md PRIVATE ${HDF5_INCLUDE_DIRS})
|
||||
include_directories(${HDF5_INCLUDE_DIRS})
|
||||
endif()
|
||||
|
||||
|
||||
@ -878,6 +952,20 @@ if(PKG_USER-OMP)
|
||||
include_directories(${USER-OMP_SOURCES_DIR})
|
||||
endif()
|
||||
|
||||
# Fix rigid/meso requires RIGID to be installed
|
||||
if(PKG_USER-SDPD)
|
||||
set(USER-SDPD_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/USER-SDPD)
|
||||
|
||||
get_property(hlist GLOBAL PROPERTY FIX)
|
||||
if(NOT PKG_RIGID)
|
||||
list(REMOVE_ITEM hlist ${USER-SDPD_SOURCES_DIR}/fix_rigid_meso.h)
|
||||
list(REMOVE_ITEM LIB_SOURCES ${USER-SDPD_SOURCES_DIR}/fix_rigid_meso.cpp)
|
||||
endif()
|
||||
set_property(GLOBAL PROPERTY FIX "${hlist}")
|
||||
|
||||
include_directories(${USER-SDPD_SOURCES_DIR})
|
||||
endif()
|
||||
|
||||
if(PKG_KOKKOS)
|
||||
set(LAMMPS_LIB_KOKKOS_SRC_DIR ${LAMMPS_LIB_SOURCE_DIR}/kokkos)
|
||||
set(LAMMPS_LIB_KOKKOS_BIN_DIR ${LAMMPS_LIB_BINARY_DIR}/kokkos)
|
||||
@ -955,7 +1043,7 @@ if(PKG_USER-INTEL)
|
||||
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}")
|
||||
message(FATAL_ERROR "USER-INTEL needs at least a 2016 intel compiler, found ${CMAKE_CXX_COMPILER_VERSION}")
|
||||
endif()
|
||||
|
||||
if(NOT BUILD_OMP)
|
||||
@ -1020,7 +1108,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)
|
||||
@ -1055,11 +1143,11 @@ if(PKG_GPU)
|
||||
find_package(CUDA REQUIRED)
|
||||
find_program(BIN2C bin2c)
|
||||
if(NOT BIN2C)
|
||||
message(FATAL_ERROR "Couldn't find bin2c, use -DBIN2C helping cmake to find it.")
|
||||
message(FATAL_ERROR "Could not find bin2c, use -DBIN2C=/path/to/bin2c to help cmake finding it.")
|
||||
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 primary 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)
|
||||
@ -1072,11 +1160,39 @@ if(PKG_GPU)
|
||||
file(GLOB GPU_LIB_CUDPP_CU ${LAMMPS_LIB_SOURCE_DIR}/gpu/cudpp_mini/[^.]*.cu)
|
||||
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_SETTING})
|
||||
# build arch/gencode commands for nvcc based on CUDA toolkit version and use choice
|
||||
# --arch translates directly instead of JIT, so this should be for the preferred or most common architecture
|
||||
set(GPU_CUDA_GENCODE "-arch=${GPU_ARCH} ")
|
||||
# Fermi (GPU Arch 2.x) is supported by CUDA 3.2 to CUDA 8.0
|
||||
if((CUDA_VERSION VERSION_GREATER "3.1") AND (CUDA_VERSION VERSION_LESS "9.0"))
|
||||
string(APPEND GPU_CUDA_GENCODE "-gencode arch=compute_20,code=[sm_20,compute_20] ")
|
||||
endif()
|
||||
# Kepler (GPU Arch 3.x) is supported by CUDA 5 and later
|
||||
if(CUDA_VERSION VERSION_GREATER "4.9")
|
||||
string(APPEND GPU_CUDA_GENCODE "-gencode arch=compute_30,code=[sm_30,compute_30] -gencode arch=compute_35,code=[sm_35,compute_35] ")
|
||||
endif()
|
||||
# Maxwell (GPU Arch 5.x) is supported by CUDA 6 and later
|
||||
if(CUDA_VERSION VERSION_GREATER "5.9")
|
||||
string(APPEND GPU_CUDA_GENCODE "-gencode arch=compute_50,code=[sm_50,compute_50] -gencode arch=compute_52,code=[sm_52,compute_52] ")
|
||||
endif()
|
||||
# Pascal (GPU Arch 6.x) is supported by CUDA 8 and later
|
||||
if(CUDA_VERSION VERSION_GREATER "7.9")
|
||||
string(APPEND GPU_CUDA_GENCODE "-gencode arch=compute_60,code=[sm_60,compute_60] -gencode arch=compute_61,code=[sm_61,compute_61] ")
|
||||
endif()
|
||||
# Volta (GPU Arch 7.0) is supported by CUDA 9 and later
|
||||
if(CUDA_VERSION VERSION_GREATER "8.9")
|
||||
string(APPEND GPU_CUDA_GENCODE "-gencode arch=compute_70,code=[sm_70,compute_70] ")
|
||||
endif()
|
||||
# Turing (GPU Arch 7.5) is supported by CUDA 10 and later
|
||||
if(CUDA_VERSION VERSION_GREATER "9.9")
|
||||
string(APPEND GPU_CUDA_GENCODE "-gencode arch=compute_75,code=[sm_75,compute_75] ")
|
||||
endif()
|
||||
|
||||
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_SETTING})
|
||||
cuda_compile_fatbin(GPU_GEN_OBJS ${GPU_LIB_CU} OPTIONS
|
||||
-DUNIX -O3 --use_fast_math -Wno-deprecated-gpu-targets -DNV_KERNEL -DUCL_CUDADR ${GPU_CUDA_GENCODE} -D_${GPU_PREC_SETTING})
|
||||
|
||||
cuda_compile(GPU_OBJS ${GPU_LIB_CUDPP_CU} OPTIONS ${CUDA_REQUEST_PIC}
|
||||
-DUNIX -O3 --use_fast_math -Wno-deprecated-gpu-targets -DUCL_CUDADR ${GPU_CUDA_GENCODE} -D_${GPU_PREC_SETTING})
|
||||
|
||||
foreach(CU_OBJ ${GPU_GEN_OBJS})
|
||||
get_filename_component(CU_NAME ${CU_OBJ} NAME_WE)
|
||||
@ -1209,7 +1325,7 @@ if(BUILD_LIB)
|
||||
configure_file(pkgconfig/liblammps.pc.in ${CMAKE_CURRENT_BINARY_DIR}/liblammps${LAMMPS_LIB_SUFFIX}.pc @ONLY)
|
||||
install(FILES ${CMAKE_CURRENT_BINARY_DIR}/liblammps${LAMMPS_LIB_SUFFIX}.pc DESTINATION ${CMAKE_INSTALL_LIBDIR}/pkgconfig)
|
||||
configure_file(FindLAMMPS.cmake.in ${CMAKE_CURRENT_BINARY_DIR}/FindLAMMPS${LAMMPS_LIB_SUFFIX}.cmake @ONLY)
|
||||
install(FILES ${CMAKE_CURRENT_BINARY_DIR}/FindLAMMPS${LAMMPS_LIB_SUFFIX}.cmake DESTINATION ${CMAKE_INSTALL_DATADIR}/cmake/Module)
|
||||
install(FILES ${CMAKE_CURRENT_BINARY_DIR}/FindLAMMPS${LAMMPS_LIB_SUFFIX}.cmake DESTINATION ${CMAKE_INSTALL_DATADIR}/cmake/Modules)
|
||||
else()
|
||||
list(APPEND LMP_SOURCES ${LIB_SOURCES})
|
||||
endif()
|
||||
@ -1224,7 +1340,7 @@ if(BUILD_EXE)
|
||||
add_dependencies(lmp ${LAMMPS_DEPS})
|
||||
endif()
|
||||
endif()
|
||||
|
||||
|
||||
set_target_properties(lmp PROPERTIES OUTPUT_NAME ${LAMMPS_BINARY})
|
||||
install(TARGETS lmp DESTINATION ${CMAKE_INSTALL_BINDIR})
|
||||
install(FILES ${LAMMPS_DOC_DIR}/lammps.1 DESTINATION ${CMAKE_INSTALL_MANDIR}/man1 RENAME ${LAMMPS_BINARY}.1)
|
||||
@ -1345,7 +1461,6 @@ foreach(PKG ${DEFAULT_PACKAGES} ${ACCEL_PACKAGES} ${OTHER_PACKAGES})
|
||||
endif()
|
||||
endforeach()
|
||||
|
||||
string(TOUPPER "${CMAKE_BUILD_TYPE}" BTYPE)
|
||||
get_directory_property(CPPFLAGS DIRECTORY ${CMAKE_SOURCE_DIR} COMPILE_DEFINITIONS)
|
||||
include(FeatureSummary)
|
||||
feature_summary(DESCRIPTION "The following packages have been found:" WHAT PACKAGES_FOUND)
|
||||
@ -1361,14 +1476,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}}")
|
||||
@ -1376,7 +1491,7 @@ endif()
|
||||
if(CMAKE_EXE_LINKER_FLAGS)
|
||||
message(STATUS "Linker flags:
|
||||
Executable ${CMAKE_EXE_LINKER_FLAGS}")
|
||||
endif()
|
||||
endif()
|
||||
if(BUILD_SHARED_LIBS)
|
||||
message(STATUS "Shared libraries ${CMAKE_SHARED_LINKER_FLAGS}")
|
||||
else()
|
||||
|
||||
@ -24,7 +24,7 @@ tasks, act as a reference and provide examples of typical use cases.
|
||||
* [Build directory vs. Source Directory](#build-directory-vs-source-directory)
|
||||
* [Defining and using presets](#defining-and-using-presets)
|
||||
* [Reference](#reference)
|
||||
* [Common CMAKE Configuration Options](#common-cmake-configuration-options)
|
||||
* [Common CMake Configuration Options](#common-cmake-configuration-options)
|
||||
* [LAMMPS Configuration Options](#lammps-configuration-options)
|
||||
* [Parallelization and Accelerator Packages](#parallelization-and-accelerator-packages)
|
||||
* [Default Packages](#default-packages)
|
||||
@ -179,7 +179,7 @@ cmake -C ../cmake/presets/std_nolib.cmake -D PKG_GPU=on ../cmake
|
||||
|
||||
# Reference
|
||||
|
||||
## Common CMAKE Configuration Options
|
||||
## Common CMake Configuration Options
|
||||
|
||||
|
||||
<table>
|
||||
@ -195,6 +195,7 @@ cmake -C ../cmake/presets/std_nolib.cmake -D PKG_GPU=on ../cmake
|
||||
<td><code>CMAKE_INSTALL_PREFIX</code></td>
|
||||
<td>Install location where LAMMPS files will be copied to. In the Unix/Linux case with Makefiles this controls what `make install` will do.</td>
|
||||
<td>
|
||||
Default setting is <code>$HOME/.local</code>.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
@ -207,6 +208,16 @@ cmake -C ../cmake/presets/std_nolib.cmake -D PKG_GPU=on ../cmake
|
||||
</dl>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code><CMAKE_VERBOSE_MAKEFILE/code></td>
|
||||
<td>Enable verbose output from Makefile builds (useful for debugging), the same can be achived by adding `VERBOSE=1` to the `make` call.</td>
|
||||
<td>
|
||||
<dl>
|
||||
<dt><code>off</code> (default)</dt>
|
||||
<dt><code>on</code></dt>
|
||||
</dl>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
@ -1492,6 +1503,11 @@ target API.
|
||||
</dl>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>BIN2C</code> (CUDA only)</td>
|
||||
<td>Path to bin2c executable, will automatically pick up the first one in your $PATH.</td>
|
||||
<td>(automatic)</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
@ -1647,9 +1663,8 @@ requires `gzip` to be in your `PATH`
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>GZIP_EXECUTABLE</code></td>
|
||||
<td></td>
|
||||
<td>
|
||||
</td>
|
||||
<td>Path to gzip executable, will automatically pick up the first one in your $PATH.</td>
|
||||
<td>(automatic)</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
@ -1679,9 +1694,8 @@ requires `ffmpeg` to be in your `PATH`
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>FFMPEG_EXECUTABLE</code></td>
|
||||
<td></td>
|
||||
<td>
|
||||
</td>
|
||||
<td>Path to ffmpeg executable, will automatically pick up the first one in your $PATH.</td>
|
||||
<td>(automatic)</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
@ -1725,6 +1739,13 @@ cache by setting the `CMAKE_C_COMPILER`, `CMAKE_CXX_COMPILER`,
|
||||
value of `FC` environment variable at first `cmake` run
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>CXX_COMPILER_LAUNCHER</code></td>
|
||||
<td>CMake will run this tool and pass the compiler and its arguments to the tool. Some example tools are distcc and ccache.</td>
|
||||
<td>
|
||||
(empty)
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
@ -1,9 +1,29 @@
|
||||
# pkg-config file for lammps
|
||||
# https://people.freedesktop.org/~dbn/pkg-config-guide.html
|
||||
# Usage: cc `pkg-config --cflags --libs liblammps` -o myapp myapp.c
|
||||
# after you added @CMAKE_INSTALL_FULL_LIBDIR@/pkg-config to PKG_CONFIG_PATH,
|
||||
|
||||
# Add the directory where lammps.pc got installed to your PKG_CONFIG_PATH
|
||||
# e.g. export PKG_CONFIG_PATH=@CMAKE_INSTALL_FULL_LIBDIR@/pkgconfig
|
||||
|
||||
# Use this on commandline with:
|
||||
# c++ `pkg-config --cflags --libs lammps` -o myapp myapp.cpp
|
||||
|
||||
# Use this in a Makefile:
|
||||
# myapp: myapp.cpp
|
||||
# $(CC) `pkg-config --cflags --libs lammps` -o $@ $<
|
||||
|
||||
# Use this in autotools:
|
||||
# configure.ac:
|
||||
# PKG_CHECK_MODULES([LAMMPS], [lammps])
|
||||
# Makefile.am:
|
||||
# myapp_CFLAGS = $(LAMMPS_CFLAGS)
|
||||
# myapp_LDADD = $(LAMMPS_LIBS)
|
||||
|
||||
# Use this in CMake:
|
||||
# CMakeLists.txt:
|
||||
# find_package(PkgConfig)
|
||||
# pkg_check_modules(LAMMPS IMPORTED_TARGET lammps)
|
||||
# target_link_libraries(<lib> PkgConfig::LAMMPS)
|
||||
|
||||
prefix=@CMAKE_INSTALL_PREFIX@
|
||||
libdir=@CMAKE_INSTALL_FULL_LIBDIR@
|
||||
includedir=@CMAKE_INSTALL_FULL_INCLUDEDIR@
|
||||
|
||||
@ -8,12 +8,12 @@ set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVA
|
||||
USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
|
||||
USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
|
||||
USER-NETCDF USER-OMP USER-PHONON USER-QMMM USER-QTB
|
||||
USER-QUIP USER-REAXC USER-SMD USER-SMTBQ USER-SPH USER-TALLY
|
||||
USER-QUIP USER-REAXC USER-SDPD USER-SMD USER-SMTBQ USER-SPH USER-TALLY
|
||||
USER-UEF USER-VTK)
|
||||
|
||||
set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MEAM MPIIO MSCG POEMS PYTHON REAX VORONOI
|
||||
USER-ATC USER-AWPMD USER-COLVARS USER-H5MD USER-LB USER-MOLFILE
|
||||
USER-NETCDF USER-QMMM USER-QUIP USER-SMD USER-VTK)
|
||||
USER-NETCDF USER-PLUMED USER-QMMM USER-QUIP USER-SMD USER-VTK)
|
||||
|
||||
set(ALL_PACKAGES ${STANDARD_PACKAGES} ${USER_PACKAGES})
|
||||
|
||||
|
||||
@ -8,12 +8,12 @@ set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVA
|
||||
USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
|
||||
USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
|
||||
USER-NETCDF USER-OMP USER-PHONON USER-QMMM USER-QTB
|
||||
USER-QUIP USER-REAXC USER-SMD USER-SMTBQ USER-SPH USER-TALLY
|
||||
USER-QUIP USER-REAXC USER-SDPD USER-SMD USER-SMTBQ USER-SPH USER-TALLY
|
||||
USER-UEF USER-VTK)
|
||||
|
||||
set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MEAM MPIIO MSCG POEMS PYTHON REAX VORONOI
|
||||
USER-ATC USER-AWPMD USER-COLVARS USER-H5MD USER-LB USER-MOLFILE
|
||||
USER-NETCDF USER-QMMM USER-QUIP USER-SMD USER-VTK)
|
||||
USER-NETCDF USER-PLUMED USER-QMMM USER-QUIP USER-SMD USER-VTK)
|
||||
|
||||
set(ALL_PACKAGES ${STANDARD_PACKAGES} ${USER_PACKAGES})
|
||||
|
||||
|
||||
@ -56,11 +56,13 @@ set(PKG_USER-MOFFF OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-MOLFILE OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-NETCDF OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-OMP OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-PHOFFOFF OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-PHONON OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-PLUMED OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-QMMM OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-QTB OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-QUIP OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-REAXC OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-SDPD OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-SMD OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-SMTBQ OFF CACHE BOOL "" FORCE)
|
||||
set(PKG_USER-SPH OFF CACHE BOOL "" FORCE)
|
||||
|
||||
@ -8,12 +8,12 @@ set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVA
|
||||
USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
|
||||
USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
|
||||
USER-NETCDF USER-OMP USER-PHONON USER-QMMM USER-QTB
|
||||
USER-QUIP USER-REAXC USER-SMD USER-SMTBQ USER-SPH USER-TALLY
|
||||
USER-QUIP USER-REAXC USER-SDPD USER-SMD USER-SMTBQ USER-SPH USER-TALLY
|
||||
USER-UEF USER-VTK)
|
||||
|
||||
set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MEAM MPIIO MSCG POEMS PYTHON REAX VORONOI
|
||||
USER-ATC USER-AWPMD USER-COLVARS USER-H5MD USER-LB USER-MOLFILE
|
||||
USER-NETCDF USER-QMMM USER-QUIP USER-SMD USER-VTK)
|
||||
USER-NETCDF USER-PLUMED USER-QMMM USER-QUIP USER-SMD USER-VTK)
|
||||
|
||||
set(ALL_PACKAGES ${STANDARD_PACKAGES} ${USER_PACKAGES})
|
||||
|
||||
|
||||
@ -8,7 +8,7 @@ set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVA
|
||||
USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
|
||||
USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
|
||||
USER-NETCDF USER-OMP USER-PHONON USER-QMMM USER-QTB
|
||||
USER-QUIP USER-REAXC USER-SMD USER-SMTBQ USER-SPH USER-TALLY
|
||||
USER-QUIP USER-REAXC USER-SDPD USER-SMD USER-SMTBQ USER-SPH USER-TALLY
|
||||
USER-UEF USER-VTK)
|
||||
|
||||
set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MEAM MPIIO MSCG POEMS PYTHON REAX VORONOI
|
||||
|
||||
@ -8,7 +8,7 @@ set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVA
|
||||
USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
|
||||
USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
|
||||
USER-NETCDF USER-OMP USER-PHONON USER-QMMM USER-QTB
|
||||
USER-QUIP USER-REAXC USER-SMD USER-SMTBQ USER-SPH USER-TALLY
|
||||
USER-QUIP USER-REAXC USER-SDPD USER-SMD USER-SMTBQ USER-SPH USER-TALLY
|
||||
USER-UEF USER-VTK)
|
||||
|
||||
set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MEAM MPIIO MSCG POEMS PYTHON REAX VORONOI
|
||||
|
||||
@ -8,12 +8,12 @@ set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVA
|
||||
USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
|
||||
USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
|
||||
USER-NETCDF USER-OMP USER-PHONON USER-QMMM USER-QTB
|
||||
USER-QUIP USER-REAXC USER-SMD USER-SMTBQ USER-SPH USER-TALLY
|
||||
USER-QUIP USER-REAXC USER-SDPD USER-SMD USER-SMTBQ USER-SPH USER-TALLY
|
||||
USER-UEF USER-VTK)
|
||||
|
||||
set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MEAM MPIIO MSCG POEMS PYTHON REAX VORONOI
|
||||
USER-ATC USER-AWPMD USER-COLVARS USER-H5MD USER-LB USER-MOLFILE
|
||||
USER-NETCDF USER-QMMM USER-QUIP USER-SMD USER-VTK)
|
||||
USER-NETCDF USER-PLUMED USER-QMMM USER-QUIP USER-SMD USER-VTK)
|
||||
|
||||
set(ALL_PACKAGES ${STANDARD_PACKAGES} ${USER_PACKAGES})
|
||||
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
# Makefile for LAMMPS documentation
|
||||
|
||||
SHELL = /bin/bash
|
||||
SHA1 = $(shell echo $USER-$PWD | python utils/sha1sum.py)
|
||||
SHELL = /bin/bash
|
||||
SHA1 = $(shell echo ${USER}-${PWD} | python utils/sha1sum.py)
|
||||
BUILDDIR = /tmp/lammps-docs-$(SHA1)
|
||||
RSTDIR = $(BUILDDIR)/rst
|
||||
VENV = $(BUILDDIR)/docenv
|
||||
@ -48,6 +48,7 @@ help:
|
||||
@echo " clean-all reset the entire build environment"
|
||||
@echo " txt2html build txt2html tool"
|
||||
@echo " anchor_check scan for duplicate anchor labels"
|
||||
@echo " spelling spell-check the manual"
|
||||
|
||||
# ------------------------------------------
|
||||
|
||||
@ -176,7 +177,6 @@ $(VENV):
|
||||
$(VIRTUALENV) -p $(PYTHON) $(VENV); \
|
||||
. $(VENV)/bin/activate; \
|
||||
pip install Sphinx; \
|
||||
pip install sphinxcontrib-images; \
|
||||
deactivate;\
|
||||
)
|
||||
|
||||
|
||||
193
doc/github-development-workflow.md
Normal file
193
doc/github-development-workflow.md
Normal file
@ -0,0 +1,193 @@
|
||||
# Outline of the GitHub Development Workflow
|
||||
|
||||
This purpose of this document is to provide a point of reference for the
|
||||
core LAMMPS developers and other LAMMPS contributors to understand the
|
||||
choices the LAMMPS developers have agreed on. Git and GitHub provide the
|
||||
tools, but do not set policies, so it is up to the developers to come to
|
||||
an agreement as to how to define and interpret policies. This document
|
||||
is likely to change as our experiences and needs change and we try to
|
||||
adapt accordingly. Last change 2018-12-19.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
* [GitHub Merge Management](#github-merge-management)
|
||||
* [Pull Requests](#pull-requests)
|
||||
* [Pull Request Assignments](#pull-request-assignments)
|
||||
* [Pull Request Reviews](#pull-request-reviews)
|
||||
* [Pull Request Discussions](#pull-request-discussions)
|
||||
* [Checklist for Pull Requests](#checklist-for-pull-requests)
|
||||
* [GitHub Issues](#github-issues)
|
||||
* [Milestones and Release Planning](#milestones-and-release-planning)
|
||||
|
||||
## GitHub Merge Management
|
||||
|
||||
In the interest of consistency, ONLY ONE of the core LAMMPS developers
|
||||
should doing the merging itself. This is currently
|
||||
[@akohlmey](https://github.com/akohlmey) (Axel Kohlmeyer).
|
||||
If this assignment needs to be changed, it shall be done right after a
|
||||
stable release. If the currently assigned developer cannot merge outstanding pull
|
||||
requests in a timely manner, or in other extenuating circumstances,
|
||||
other core LAMMPS developers with merge rights can merge pull requests,
|
||||
when necessary.
|
||||
|
||||
## Pull Requests
|
||||
|
||||
ALL changes to the LAMMPS code and documentation, however trivial, MUST
|
||||
be submitted as a pull request to GitHub. All changes to the "master"
|
||||
branch must be made exclusively through merging pull requests. The
|
||||
"unstable" and "stable" branches, respectively are only to be updated
|
||||
upon patch or stable releases with fast-forward merges based on the
|
||||
associated tags. Pull requests may also be submitted to (long-running)
|
||||
feature branches created by LAMMPS developers inside the LAMMPS project,
|
||||
if needed. Those are not subject to the merge and review restrictions
|
||||
discussed in this document, though, but get managed as needed on a
|
||||
case-by-case basis.
|
||||
|
||||
### Pull Request Assignments
|
||||
|
||||
Pull requests can be "chaperoned" by one of the LAMMPS core developers.
|
||||
This is indicated by who the pull request is assigned to. LAMMPS core
|
||||
developers can self-assign or they can decide to assign a pull request
|
||||
to a different LAMMPS developer. Being assigned to a pull request means,
|
||||
that this pull request may need some work and the assignee is tasked to
|
||||
determine what this might be needed or not, and may either implement the
|
||||
required changes or ask the submitter of the pull request to implement
|
||||
them. Even though, all LAMMPS developers may have write access to pull
|
||||
requests (if enabled by the submitter, which is the default), only the
|
||||
submitter or the assignee of a pull request may do so. During this
|
||||
period the `work_in_progress` label shall be applied to the pull
|
||||
request. The assignee gets to decide what happens to the pull request
|
||||
next, e.g. whether it should be assigned to a different developer for
|
||||
additional checks and changes, or is recommended to be merged. Removing
|
||||
the `work_in_progress` label and assigning the pull request to the
|
||||
developer tasked with merging signals that a pull request is ready to be
|
||||
merged.
|
||||
|
||||
### Pull Request Reviews
|
||||
|
||||
People can be assigned to review a pull request in two ways:
|
||||
|
||||
* They can be assigned manually to review a pull request
|
||||
by the submitter or a LAMMPS developer
|
||||
* They can be automatically assigned, because a developers matches
|
||||
a file pattern in the `.github/CODEOWNERS` file, which associates
|
||||
developers with the code they contributed and maintain.
|
||||
|
||||
Reviewers are requested to state their appraisal of the proposed changes
|
||||
and either approve or request changes. People may unassign themselves
|
||||
from review, if they feel not competent about the changes proposed. At
|
||||
least one review from a LAMMPS developer with write access is required
|
||||
before merging in addition to the automated compilation tests. The
|
||||
feature, that reviews from code owners are "hard" reviews (i.e. they
|
||||
must all be approved before merging is allowed), is currently disabled
|
||||
and it is in the discretion of the merge maintainer to assess when
|
||||
a sufficient degree of approval has been reached. Reviews may be
|
||||
(automatically) dismissed, when the reviewed code has been changed,
|
||||
and then approval is required a second time.
|
||||
|
||||
### Pull Request Discussions
|
||||
|
||||
All discussions about a pull request should be kept as much as possible
|
||||
on the pull request discussion page on GitHub, so that other developers
|
||||
can later review the entire discussion after the fact and understand the
|
||||
rationale behind choices made. Exceptions to this policy are technical
|
||||
discussions, that are centered on tools or policies themselves
|
||||
(git, github, c++) rather than on the content of the pull request.
|
||||
|
||||
### Checklist for Pull Requests
|
||||
|
||||
Here are some items to check:
|
||||
* source and text files should not have CR/LF line endings (use dos2unix to remove)
|
||||
* every new command or style should have documentation. The names of
|
||||
source files (c++ and manual) should follow the name of the style.
|
||||
(example: `src/fix_nve.cpp`, `src/fix_nve.h` for `fix nve` command,
|
||||
implementing the class `FixNVE`, documented in `doc/src/fix_nve.txt`)
|
||||
* all new style names should be lower case, the must be no dashes,
|
||||
blanks, or underscores separating words, only forward slashes.
|
||||
* new style docs should be added to the "overview" files in
|
||||
`doc/src/Commands_*.txt`, `doc/src/{fixes,computes,pairs,bonds,...}.txt`
|
||||
and `doc/src/lammps.book`
|
||||
* check whether manual cleanly translates with `make html` and `make pdf`
|
||||
* check spelling of manual with `make spelling` in doc folder
|
||||
* new source files in packages should be added to `src/.gitignore`
|
||||
* removed or renamed files in packages should be added to `src/Purge.list`
|
||||
* C++ source files should use C++ style include files for accessing
|
||||
C-library APIs, e.g. `#include <cstdlib>` instead of `#include <stdlib.h>`.
|
||||
And they should use angular brackets instead of double quotes. Full list:
|
||||
* assert.h -> cassert
|
||||
* ctype.h -> cctype
|
||||
* errno.h -> cerrno
|
||||
* float.h -> cfloat
|
||||
* limits.h -> climits
|
||||
* math.h -> cmath
|
||||
* omplex.h -> complex
|
||||
* setjmp.h -> csetjmp
|
||||
* signal.h -> csignal
|
||||
* stddef.h -> cstddef
|
||||
* stdint.h -> cstdint
|
||||
* stdio.h -> cstdio
|
||||
* stdlib.h -> cstdlib
|
||||
* string.h -> cstring
|
||||
* time.h -> ctime
|
||||
* Do NOT replace (as they are C++-11): `inttypes.h` and `stdint.h`.
|
||||
* Code should follow the C++-98 standard. C++-11 is only accepted
|
||||
in individual special purpose packages
|
||||
* indentation is 2 spaces per level
|
||||
* there should be NO tabs and no trailing whitespace
|
||||
* header files, especially of new styles, should not include any
|
||||
other headers, except the header with the base class or cstdio.
|
||||
Forward declarations should be used instead when possible.
|
||||
* iostreams should be avoided. LAMMPS uses stdio from the C-library.
|
||||
* use of STL in headers and class definitions should be avoided.
|
||||
* there MUST NOT be any "using namespace XXX;" statements in headers.
|
||||
* static class members should be avoided at all cost.
|
||||
* anything storing atom IDs should be using `tagint` and not `int`.
|
||||
This can be flagged by the compiler only for pointers and only when
|
||||
compiling LAMMPS with `-DLAMMPS_BIGBIG`.
|
||||
* when including both `lmptype.h` (and using defines or macros from it)
|
||||
and `mpi.h`, `lmptype.h` must be included first.
|
||||
* when pair styles are added, check if settings for flags like
|
||||
`single_enable`, `writedata`, `reinitflag`, `manybody_flag`
|
||||
and others are correctly set and supported.
|
||||
|
||||
## GitHub Issues
|
||||
|
||||
The GitHub issue tracker is the location where the LAMMPS developers
|
||||
and other contributors or LAMMPS users can report issues or bugs with
|
||||
the LAMMPS code or request new features to be added. Feature requests
|
||||
are usually indicated by a `[Feature Request]` marker in the subject.
|
||||
Issues are assigned to a person, if this person is working on this
|
||||
feature or working to resolve an issue. Issues that have nobody working
|
||||
on them at the moment, have the label `volunteer needed` attached.
|
||||
|
||||
When an issue, say `#125` is resolved by a specific pull request,
|
||||
the comment for the pull request shall contain the text `closes #125`
|
||||
or `fixes #125`, so that the issue is automatically deleted when
|
||||
the pull request is merged.
|
||||
|
||||
## Milestones and Release Planning
|
||||
|
||||
LAMMPS uses a continuous release development model with incremental
|
||||
changes, i.e. significant effort is made - including automated pre-merge
|
||||
testing - that the code in the branch "master" does not get broken.
|
||||
More extensive testing (including regression testing) is performed after
|
||||
code is merged to the "master" branch. There are patch releases of
|
||||
LAMMPS every 1-3 weeks at a point, when the LAMMPS developers feel, that
|
||||
a sufficient amount of changes have happened, and the post-merge testing
|
||||
has been successful. These patch releases are marked with a
|
||||
`patch_<version date>` tag and the "unstable" branch follows only these
|
||||
versions (and thus is always supposed to be of production quality,
|
||||
unlike "master", which may be temporary broken, in the case of larger
|
||||
change sets or unexpected incompatibilities or side effects.
|
||||
|
||||
About 3-4 times each year, there are going to be "stable" releases
|
||||
of LAMMPS. These have seen additional, manual testing and review of
|
||||
results from testing with instrumented code and static code analysis.
|
||||
Also, in the last 2-3 patch releases before a stable release are
|
||||
"release candidate" versions which only contain bugfixes and
|
||||
documentation updates. For release planning and the information of
|
||||
code contributors, issues and pull requests being actively worked on
|
||||
are assigned a "milestone", which corresponds to the next stable
|
||||
release or the stable release after that, with a tentative release
|
||||
date.
|
||||
|
||||
@ -49,7 +49,7 @@ make mybox :pre # uses Makefile.mybox to produce lmp_mybox :pre
|
||||
|
||||
Serial build (see src/MAKE/Makefile.serial):
|
||||
|
||||
MPI_INC = -I../STUBS
|
||||
MPI_INC = -I../STUBS
|
||||
MPI_PATH = -L../STUBS
|
||||
MPI_LIB = -lmpi_stubs :pre
|
||||
|
||||
@ -137,9 +137,9 @@ simply loading the appropriate module before building LAMMPS.
|
||||
-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
|
||||
-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
|
||||
@ -172,7 +172,7 @@ want.
|
||||
Parallel build (see src/MAKE/Makefile.mpi):
|
||||
|
||||
CC = mpicxx
|
||||
CCFLAGS = -g -O3
|
||||
CCFLAGS = -g -O3
|
||||
LINK = mpicxx
|
||||
LINKFLAGS = -g -O :pre
|
||||
|
||||
@ -292,7 +292,7 @@ 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.
|
||||
|
||||
NOTE: You can also download a tarball of the documention for the
|
||||
NOTE: You can also download a tarball of the documentation for the
|
||||
current LAMMPS version (HTML and PDF files), from the website
|
||||
"download page"_http://lammps.sandia.gov/download.html.
|
||||
|
||||
|
||||
@ -27,7 +27,7 @@ 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
|
||||
mkdir build; cd build # create a new directory (folder) for build
|
||||
cmake ../cmake \[options ...\] # configuration with (command-line) cmake
|
||||
make # compilation :pre
|
||||
|
||||
@ -44,7 +44,7 @@ LAMMPS or need to re-compile 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:
|
||||
library into your system folders (by default under $HOME/.local) with:
|
||||
|
||||
make install # optional, copy LAMMPS executable & library elsewhere :pre
|
||||
|
||||
|
||||
@ -36,7 +36,6 @@ This is the list of packages that may require additional steps.
|
||||
"OPT"_#opt,
|
||||
"POEMS"_#poems,
|
||||
"PYTHON"_#python,
|
||||
"REAX"_#reax,
|
||||
"VORONOI"_#voronoi,
|
||||
"USER-ATC"_#user-atc,
|
||||
"USER-AWPMD"_#user-awpmd,
|
||||
@ -45,6 +44,7 @@ This is the list of packages that may require additional steps.
|
||||
"USER-INTEL"_#user-intel,
|
||||
"USER-MOLFILE"_#user-molfile,
|
||||
"USER-NETCDF"_#user-netcdf,
|
||||
"USER-PLUMED"_#user-plumed,
|
||||
"USER-OMP"_#user-omp,
|
||||
"USER-QMMM"_#user-qmmm,
|
||||
"USER-QUIP"_#user-quip,
|
||||
@ -63,7 +63,7 @@ available on your system.
|
||||
|
||||
If CMake cannot find the library, you can set these variables:
|
||||
|
||||
-D ZLIB_INCLUDE_DIR=path # path to zlib.h header file
|
||||
-D ZLIB_INCLUDE_DIR=path # path to zlib.h header file
|
||||
-D ZLIB_LIBRARIES=path # path to libz.a (.so) file :pre
|
||||
|
||||
[Traditional make]:
|
||||
@ -86,22 +86,30 @@ which GPU hardware to build for.
|
||||
# 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
|
||||
-D GPU_ARCH=value # primary GPU 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
|
||||
-D CUDPP_OPT=value # optimization setting for GPU_API=cuda
|
||||
# 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
|
||||
sm_20 or sm_21 for Fermi (supported by CUDA 3.2 until CUDA 7.5)
|
||||
sm_30 or sm_35 or sm_37 for Kepler (supported since CUDA 5)
|
||||
sm_50 or sm_52 for Maxwell (supported since CUDA 6)
|
||||
sm_60 or sm_61 for Pascal (supported since CUDA 8)
|
||||
sm_70 for Volta (supported since CUDA 9)
|
||||
sm_75 for Turing (supported since CUDA 10) :ul
|
||||
|
||||
A more detailed list can be found, for example,
|
||||
at "Wikipedia's CUDA article"_https://en.wikipedia.org/wiki/CUDA#GPUs_supported
|
||||
|
||||
CMake can detect which version of the CUDA toolkit is used and thus can
|
||||
include support for [all] major GPU architectures supported by this toolkit.
|
||||
Thus the GPU_ARCH setting is merely an optimization, to have code for
|
||||
the preferred GPU architecture directly included rather than having to wait
|
||||
for the JIT compiler of the CUDA driver to translate it.
|
||||
|
||||
[Traditional make]:
|
||||
|
||||
@ -136,6 +144,11 @@ 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
|
||||
|
||||
The file Makefile.linux_multi is set up to include support for multiple
|
||||
GPU architectures as supported by the CUDA toolkit in use. This is done
|
||||
through using the "--gencode " flag, which can be used multiple times and
|
||||
thus support all GPU architectures supported by your CUDA compiler.
|
||||
|
||||
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
|
||||
@ -149,8 +162,9 @@ 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
|
||||
@ -177,7 +191,7 @@ package?" page.
|
||||
[CMake build]:
|
||||
|
||||
-D DOWNLOAD_KIM=value # download OpenKIM API v1 for build, value = no (default) or yes
|
||||
-D KIM_LIBRARY=path # KIM library file (only needed if a custom location)
|
||||
-D KIM_LIBRARY=path # KIM library file (only needed if a custom location)
|
||||
-D KIM_INCLUDE_DIR=path # KIM include directory (only needed if a custom location) :pre
|
||||
|
||||
If DOWNLOAD_KIM is set, the KIM library will be downloaded and built
|
||||
@ -254,7 +268,7 @@ 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 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
|
||||
@ -296,7 +310,7 @@ 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
|
||||
@ -324,7 +338,7 @@ 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
|
||||
make lib-latte args="-b -m gfortran" # download and build in lib/latte and
|
||||
# copy Makefile.lammps.gfortran to Makefile.lammps
|
||||
:pre
|
||||
|
||||
@ -335,7 +349,7 @@ 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
|
||||
@ -378,7 +392,7 @@ EXTRAMAKE variable to specify a corresponding Makefile.lammps.machine
|
||||
file.
|
||||
|
||||
:line
|
||||
|
||||
|
||||
MESSAGE package :h4,link(message)
|
||||
|
||||
This package can optionally include support for messaging via sockets,
|
||||
@ -407,7 +421,7 @@ existing Makefile.lammps.* and has settings to link with the ZeroMQ
|
||||
library if requested in the build.
|
||||
|
||||
:line
|
||||
|
||||
|
||||
MSCG package :h4,link(mscg)
|
||||
|
||||
To build with this package, you must download and build the MS-CG
|
||||
@ -419,7 +433,7 @@ lib/mscg/README and MSCG/Install files for more details.
|
||||
[CMake build]:
|
||||
|
||||
-D DOWNLOAD_MSCG=value # download MSCG for build, value = no (default) or yes
|
||||
-D MSCG_LIBRARY=path # MSCG library file (only needed if a custom location)
|
||||
-D MSCG_LIBRARY=path # MSCG library file (only needed if a custom location)
|
||||
-D MSCG_INCLUDE_DIR=path # MSCG include directory (only needed if a custom location) :pre
|
||||
|
||||
If DOWNLOAD_MSCG is set, the MSCG library will be downloaded and built
|
||||
@ -464,7 +478,7 @@ line of your Makefile.machine. See src/MAKE/OPTIONS/Makefile.opt for
|
||||
an example.
|
||||
|
||||
:line
|
||||
|
||||
|
||||
POEMS package :h4,link(poems)
|
||||
|
||||
[CMake build]:
|
||||
@ -493,7 +507,7 @@ 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
|
||||
@ -519,45 +533,6 @@ 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)
|
||||
@ -570,7 +545,7 @@ library"_voro-home.
|
||||
[CMake build]:
|
||||
|
||||
-D DOWNLOAD_VORO=value # download Voro++ for build, value = no (default) or yes
|
||||
-D VORO_LIBRARY=path # Voro++ library file (only needed if at custom location)
|
||||
-D VORO_LIBRARY=path # Voro++ library file (only needed if at custom location)
|
||||
-D VORO_INCLUDE_DIR=path # Voro++ include directory (only needed if at custom location) :pre
|
||||
|
||||
If DOWNLOAD_VORO is set, the Voro++ library will be downloaded and
|
||||
@ -606,8 +581,8 @@ 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".
|
||||
No additional settings are needed besides "-D PKG_USER-ATC=yes"
|
||||
and "-D PKG_MANYBODY=yes".
|
||||
|
||||
[Traditional make]:
|
||||
|
||||
@ -712,6 +687,114 @@ a corresponding Makefile.lammps.machine file.
|
||||
|
||||
:line
|
||||
|
||||
USER-PLUMED package :h4,link(user-plumed)
|
||||
|
||||
Before building LAMMPS with this package, you must first build PLUMED.
|
||||
PLUMED can be built as part of the LAMMPS build or installed separately
|
||||
from LAMMPS using the generic "plumed installation instructions"_plumedinstall.
|
||||
:link(plumedinstall,http://plumed.github.io/doc-master/user-doc/html/_installation.html)
|
||||
|
||||
PLUMED can be linked into MD codes in three different modes: static,
|
||||
shared, and runtime. With the "static" mode, all the code that PLUMED
|
||||
requires is linked statically into LAMMPS. LAMMPS is then fully
|
||||
independent from the PLUMED installation, but you have to rebuild/relink
|
||||
it in order to update the PLUMED code inside it. With the "shared"
|
||||
linkage mode, LAMMPS is linked to a shared library that contains the
|
||||
PLUMED code. This library should preferably be installed in a globally
|
||||
accessible location. When PLUMED is linked in this way the same library
|
||||
can be used by multiple MD packages. Furthermore, the PLUMED library
|
||||
LAMMPS uses can be updated without the need for a recompile of LAMMPS
|
||||
for as long as the shared PLUMED library is ABI-compatible.
|
||||
|
||||
The third linkage mode is "runtime" which allows the user to specify
|
||||
which PLUMED kernel should be used at runtime by using the PLUMED_KERNEL
|
||||
environment variable. This variable should point to the location of the
|
||||
libplumedKernel.so dynamical shared object, which is then loaded at
|
||||
runtime. This mode of linking is particularly convenient for doing
|
||||
PLUMED development and comparing multiple PLUMED versions as these sorts
|
||||
of comparisons can be done without recompiling the hosting MD code. All
|
||||
three linkage modes are supported by LAMMPS on selected operating
|
||||
systems (e.g. Linux) and using either CMake or traditional make
|
||||
build. The "static" mode should be the most portable, while the
|
||||
"runtime" mode support in LAMMPS makes the most assumptions about
|
||||
operating system and compiler environment. If one mode does not work,
|
||||
try a different one, switch to a different build system, consider a
|
||||
global PLUMED installation or consider downloading PLUMED during the
|
||||
LAMMPS build.
|
||||
|
||||
[CMake build]:
|
||||
|
||||
When the "-D PKG_USER-PLUMED" flag is included in the cmake command you
|
||||
must ensure that GSL is installed in locations that are specified in
|
||||
your environment. There are then two additional commands that control
|
||||
the manner in which PLUMED is obtained and linked into LAMMPS.
|
||||
|
||||
-D DOWNLOAD_PLUMED=value # download PLUMED for build, value = no (default) or yes
|
||||
-D PLUMED_MODE=value # Linkage mode for PLUMED, value = static (default), shared, or runtime :pre
|
||||
|
||||
If DOWNLOAD_PLUMED is set to "yes", the PLUMED library will be
|
||||
downloaded (the version of PLUMED that will be downloaded is hard-coded
|
||||
to a vetted version of PLUMED, usually a recent stable release version)
|
||||
and built inside the CMake build directory. If DOWNLOAD_PLUMED is set
|
||||
to "no" (the default), CMake will try to detect and link to an installed
|
||||
version of PLUMED. For this to work, the PLUMED library has to be
|
||||
installed into a location where the pkg-config tool can find it or the
|
||||
PKG_CONFIG_PATH environment variable has to be set up accordingly.
|
||||
PLUMED should be installed in such a location if you compile it using
|
||||
the default make; make install commands.
|
||||
|
||||
The PLUMED_MODE setting determines the linkage mode for the PLUMED
|
||||
library. The allowed values for this flag are "static" (default),
|
||||
"shared", or "runtime". For a discussion of PLUMED linkage modes,
|
||||
please see above. When DOWNLOAD_PLUMED is enabled the static linkage
|
||||
mode is recommended.
|
||||
|
||||
[Traditional make]:
|
||||
|
||||
PLUMED needs to be installed before the USER-PLUMED package is installed
|
||||
so that LAMMPS can find the right settings when compiling and linking
|
||||
the LAMMPS executable. You can either download and build PLUMED inside
|
||||
the LAMMPS plumed library folder or use a previously installed PLUMED
|
||||
library and point LAMMPS to its location. You also have to choose the
|
||||
linkage mode: "static" (default), "shared" or "runtime". For a
|
||||
discussion of PLUMED linkage modes, please see above.
|
||||
|
||||
Download/compilation/configuration of the plumed library can be done
|
||||
from the src folder through the following make args:
|
||||
|
||||
make lib-plumed # print help message
|
||||
make lib-plumed args="-b" # download and build PLUMED in lib/plumed/plumed2
|
||||
make lib-plumed args="-p $HOME/.local" # use existing PLUMED installation in $HOME/.local
|
||||
make lib-plumed args="-p /usr/local -m shared" # use existing PLUMED installation in
|
||||
# /usr/local and use shared linkage mode
|
||||
:pre
|
||||
|
||||
Note that 2 symbolic (soft) links, "includelink" and "liblink" are
|
||||
created in lib/plumed that point to the location of the PLUMED build to
|
||||
use. A new file lib/plumed/Makefile.lammps is also created with settings
|
||||
suitable for LAMMPS to compile and link PLUMED using the desired linkage
|
||||
mode. After this step is completed, you can install the USER-PLUMED
|
||||
package and compile LAMMPS in the usual manner:
|
||||
|
||||
make yes-user-plumed
|
||||
make machine :pre
|
||||
|
||||
Once this compilation completes you should be able to run LAMMPS in the
|
||||
usual way. For shared linkage mode, libplumed.so must be found by the
|
||||
LAMMPS executable, which on many operating systems means, you have to
|
||||
set the LD_LIBRARY_PATH environment variable accordingly.
|
||||
|
||||
Support for the different linkage modes in LAMMPS varies for different
|
||||
operating systems, using the static linkage is expected to be the most
|
||||
portable, and thus set to be the default.
|
||||
|
||||
If you want to change the linkage mode, you have to re-run "make
|
||||
lib-plumed" with the desired settings [and] do a re-install if the
|
||||
USER-PLUMED package with "make yes-user-plumed" to update the required
|
||||
makefile settings with the changes in the lib/plumed folder.
|
||||
|
||||
:line
|
||||
|
||||
USER-H5MD package :h4,link(user-h5md)
|
||||
|
||||
To build with this package you must have the HDF5 software package
|
||||
@ -869,7 +952,7 @@ Quantum ESPRESSO known to work with this QM/MM interface was version
|
||||
[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.
|
||||
QM/MM-capable hybrid executable of LAMMPS and QE called pwqmmm.x.
|
||||
You must use the traditional make build for this package.
|
||||
|
||||
[Traditional make]:
|
||||
@ -939,7 +1022,7 @@ Coulomb solver library"_scafacos-home
|
||||
[CMake build]:
|
||||
|
||||
-D DOWNLOAD_SCAFACOS=value # download ScaFaCoS for build, value = no (default) or yes
|
||||
-D SCAFACOS_LIBRARY=path # ScaFaCos library file (only needed if at custom location)
|
||||
-D SCAFACOS_LIBRARY=path # ScaFaCos library file (only needed if at custom location)
|
||||
-D SCAFACOS_INCLUDE_DIR=path # ScaFaCoS include directory (only needed if at custom location) :pre
|
||||
|
||||
If DOWNLOAD_SCAFACOS is set, the ScaFaCoS library will be downloaded
|
||||
|
||||
@ -47,7 +47,6 @@ packages:
|
||||
"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,
|
||||
@ -56,6 +55,7 @@ packages:
|
||||
"USER-INTEL"_Build_extras.html#user-intel,
|
||||
"USER-MOLFILE"_Build_extras.html#user-molfile,
|
||||
"USER-NETCDF"_Build_extras.html#user-netcdf,
|
||||
"USER-PLUMED"_Build_extras.html#user-plumed,
|
||||
"USER-OMP"_Build_extras.html#user-omp,
|
||||
"USER-QMMM"_Build_extras.html#user-qmmm,
|
||||
"USER-QUIP"_Build_extras.html#user-quip,
|
||||
|
||||
@ -22,7 +22,7 @@ explain how to do this for building both with CMake and make.
|
||||
"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
|
||||
@ -73,7 +73,7 @@ FFT_LIB with the appropriate FFT libraries to include in the link.
|
||||
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.
|
||||
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
|
||||
@ -92,7 +92,7 @@ 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.
|
||||
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).
|
||||
@ -139,16 +139,16 @@ adequate.
|
||||
[Makefile.machine setting]:
|
||||
|
||||
LMP_INC = -DLAMMPS_SMALLBIG # or -DLAMMPS_BIGBIG or -DLAMMPS_SMALLSMALL :pre
|
||||
# default is LAMMMPS_SMALLBIG if not specified
|
||||
# default is LAMMPS_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)
|
||||
@ -209,12 +209,12 @@ Usually these settings are all that is needed. If CMake cannot find
|
||||
the graphics header, library, executable 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 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]:
|
||||
|
||||
@ -53,20 +53,20 @@ are included, but may not always up-to-date for recently added functionality
|
||||
and the corresponding new code. A machine makefile for using cygwin for
|
||||
the old build system is provided. The CMake build system is untested
|
||||
for this; you will have to request that makefiles are generated and
|
||||
manually set the compiler.
|
||||
manually set the compiler.
|
||||
|
||||
When compiling for Windows [not] set the -DLAMMPS_MEMALIGN define
|
||||
in the LMP_INC makefile variable and add -lwsock32 -lpsapi to the linker
|
||||
flags in LIB makefile variable. Try adding -static-libgcc or -static or
|
||||
flags in LIB makefile variable. Try adding -static-libgcc or -static or
|
||||
both to the linker flags when your resulting LAMMPS Windows executable
|
||||
complains about missing .dll files. The CMake configuration should set
|
||||
this up automatically, but is untested.
|
||||
this up automatically, but is untested.
|
||||
|
||||
In case of problems, you are recommended to contact somebody with
|
||||
experience in using cygwin. If you do come across portability problems
|
||||
requiring changes to the LAMMPS source code, or figure out corrections
|
||||
yourself, please report them on the lammps-users mailing list, or file
|
||||
them as an issue or pull request on the LAMMPS github project.
|
||||
them as an issue or pull request on the LAMMPS GitHub project.
|
||||
|
||||
|
||||
Using a cross-compiler :h4,link(cross)
|
||||
|
||||
@ -42,10 +42,10 @@ END_RST -->
|
||||
"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
|
||||
"General 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)
|
||||
|
||||
|
||||
@ -7,7 +7,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:line
|
||||
|
||||
"All commands"_Commands_all.html,
|
||||
"General commands"_Commands_all.html,
|
||||
"Fix styles"_Commands_fix.html,
|
||||
"Compute styles"_Commands_compute.html,
|
||||
"Pair styles"_Commands_pair.html,
|
||||
@ -17,9 +17,9 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
"Improper styles"_Commands_bond.html#improper,
|
||||
"KSpace styles"_Commands_kspace.html :tb(c=3,ea=c)
|
||||
|
||||
All commands :h3
|
||||
General commands :h3
|
||||
|
||||
An alphabetic list of all LAMMPS commands.
|
||||
An alphabetic list of all general LAMMPS commands.
|
||||
|
||||
"angle_coeff"_angle_coeff.html,
|
||||
"angle_style"_angle_style.html,
|
||||
@ -59,6 +59,7 @@ An alphabetic list of all LAMMPS commands.
|
||||
"fix_modify"_fix_modify.html,
|
||||
"group"_group.html,
|
||||
"group2ndx"_group2ndx.html,
|
||||
"hyper"_hyper.html,
|
||||
"if"_if.html,
|
||||
"info"_info.html,
|
||||
"improper_coeff"_improper_coeff.html,
|
||||
|
||||
@ -5,7 +5,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
"All commands"_Commands_all.html,
|
||||
"General commands"_Commands_all.html,
|
||||
"Fix styles"_Commands_fix.html,
|
||||
"Compute styles"_Commands_compute.html,
|
||||
"Pair styles"_Commands_pair.html,
|
||||
|
||||
@ -10,10 +10,9 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
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).
|
||||
"General commands"_Commands_all.html doc page lists all general commands
|
||||
alphabetically. Style options for entries like fix, compute, pair etc.
|
||||
have their own pages where they are listed alphabetically.
|
||||
|
||||
Initialization:
|
||||
|
||||
|
||||
@ -7,7 +7,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:line
|
||||
|
||||
"All commands"_Commands_all.html,
|
||||
"General commands"_Commands_all.html,
|
||||
"Fix styles"_Commands_fix.html,
|
||||
"Compute styles"_Commands_compute.html,
|
||||
"Pair styles"_Commands_pair.html,
|
||||
|
||||
@ -7,7 +7,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:line
|
||||
|
||||
"All commands"_Commands_all.html,
|
||||
"General commands"_Commands_all.html,
|
||||
"Fix styles"_Commands_fix.html,
|
||||
"Compute styles"_Commands_compute.html,
|
||||
"Pair styles"_Commands_pair.html,
|
||||
@ -78,6 +78,8 @@ OPT.
|
||||
"grem"_fix_grem.html,
|
||||
"halt"_fix_halt.html,
|
||||
"heat"_fix_heat.html,
|
||||
"hyper/global"_fix_hyper_global.html,
|
||||
"hyper/local"_fix_hyper_local.html,
|
||||
"imd"_fix_imd.html,
|
||||
"indent"_fix_indent.html,
|
||||
"ipi"_fix_ipi.html,
|
||||
@ -94,6 +96,7 @@ OPT.
|
||||
"lineforce"_fix_lineforce.html,
|
||||
"manifoldforce"_fix_manifoldforce.html,
|
||||
"meso"_fix_meso.html,
|
||||
"meso/move"_fix_meso_move.html,
|
||||
"meso/stationary"_fix_meso_stationary.html,
|
||||
"momentum (k)"_fix_momentum.html,
|
||||
"move"_fix_move.html,
|
||||
@ -107,7 +110,7 @@ OPT.
|
||||
"nph/asphere (o)"_fix_nph_asphere.html,
|
||||
"nph/body"_fix_nph_body.html,
|
||||
"nph/eff"_fix_nh_eff.html,
|
||||
"nph/sphere (ko)"_fix_nph_sphere.html,
|
||||
"nph/sphere (o)"_fix_nph_sphere.html,
|
||||
"nphug (o)"_fix_nphug.html,
|
||||
"npt (iko)"_fix_nh.html,
|
||||
"npt/asphere (o)"_fix_npt_asphere.html,
|
||||
@ -127,7 +130,7 @@ OPT.
|
||||
"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/sphere (ko)"_fix_nve_sphere.html,
|
||||
"nve/spin"_fix_nve_spin.html,
|
||||
"nve/tri"_fix_nve_tri.html,
|
||||
"nvk"_fix_nvk.html,
|
||||
@ -146,6 +149,7 @@ OPT.
|
||||
"phonon"_fix_phonon.html,
|
||||
"pimd"_fix_pimd.html,
|
||||
"planeforce"_fix_planeforce.html,
|
||||
"plumed"_fix_plumed.html,
|
||||
"poems"_fix_poems.html,
|
||||
"pour"_fix_pour.html,
|
||||
"precession/spin"_fix_precession_spin.html,
|
||||
@ -165,13 +169,13 @@ OPT.
|
||||
"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/bonds (k)"_fix_reaxc_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/meso"_fix_rigid_meso.html,
|
||||
"rigid/nph (o)"_fix_rigid.html,
|
||||
"rigid/nph/small"_fix_rigid.html,
|
||||
"rigid/npt (o)"_fix_rigid.html,
|
||||
@ -230,4 +234,4 @@ OPT.
|
||||
"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)
|
||||
"wall/srd"_fix_wall_srd.html :tb(c=6,ea=c)
|
||||
|
||||
@ -7,7 +7,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:line
|
||||
|
||||
"All commands"_Commands_all.html,
|
||||
"General commands"_Commands_all.html,
|
||||
"Fix styles"_Commands_fix.html,
|
||||
"Compute styles"_Commands_compute.html,
|
||||
"Pair styles"_Commands_pair.html,
|
||||
|
||||
@ -7,7 +7,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:line
|
||||
|
||||
"All commands"_Commands_all.html,
|
||||
"General commands"_Commands_all.html,
|
||||
"Fix styles"_Commands_fix.html,
|
||||
"Compute styles"_Commands_compute.html,
|
||||
"Pair styles"_Commands_pair.html,
|
||||
@ -107,6 +107,7 @@ OPT.
|
||||
"kolmogorov/crespi/full"_pair_kolmogorov_crespi_full.html,
|
||||
"kolmogorov/crespi/z"_pair_kolmogorov_crespi_z.html,
|
||||
"lcbop"_pair_lcbop.html,
|
||||
"lebedeva/z"_pair_lebedeva_z.html,
|
||||
"lennard/mdf"_pair_mdf.html,
|
||||
"line/lj"_pair_line_lj.html,
|
||||
"list"_pair_list.html,
|
||||
@ -160,8 +161,7 @@ OPT.
|
||||
"lubricateU/poly"_pair_lubricateU.html,
|
||||
"mdpd"_pair_meso.html,
|
||||
"mdpd/rhosum"_pair_meso.html,
|
||||
"meam"_pair_meam.html,
|
||||
"meam/c"_pair_meam.html,
|
||||
"meam/c"_pair_meamc.html,
|
||||
"meam/spline (o)"_pair_meam_spline.html,
|
||||
"meam/sw/spline"_pair_meam_sw_spline.html,
|
||||
"mgpt"_pair_mgpt.html,
|
||||
@ -194,10 +194,10 @@ OPT.
|
||||
"polymorphic"_pair_polymorphic.html,
|
||||
"python"_pair_python.html,
|
||||
"quip"_pair_quip.html,
|
||||
"reax"_pair_reax.html,
|
||||
"reax/c (ko)"_pair_reaxc.html,
|
||||
"rebo (io)"_pair_airebo.html,
|
||||
"resquared (go)"_pair_resquared.html,
|
||||
"sdpd/taitwater/isothermal"_pair_sdpd_taitwater_isothermal.html,
|
||||
"smd/hertz"_pair_smd_hertz.html,
|
||||
"smd/tlsph"_pair_smd_tlsph.html,
|
||||
"smd/tri_surface"_pair_smd_triangulated_surface.html,
|
||||
|
||||
@ -91,7 +91,7 @@ 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,
|
||||
(4) The line is broken into "words" separated by white-space (tabs,
|
||||
spaces). Note that words can thus contain letters, digits,
|
||||
underscores, or punctuation characters.
|
||||
|
||||
|
||||
3
doc/src/Developer/.gitignore
vendored
Normal file
3
doc/src/Developer/.gitignore
vendored
Normal file
@ -0,0 +1,3 @@
|
||||
/developer.aux
|
||||
/developer.log
|
||||
/developer.toc
|
||||
BIN
doc/src/Eqs/pair_lebedeva.png
Normal file
BIN
doc/src/Eqs/pair_lebedeva.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 30 KiB |
@ -32,7 +32,7 @@ END_RST -->
|
||||
|
||||
"Common problems"_Errors_common.html
|
||||
"Reporting bugs"_Errors_bugs.html
|
||||
"Error messages"_Errors_messages.html
|
||||
"Error messages"_Errors_messages.html
|
||||
"Warning messages"_Errors_warnings.html :all(b)
|
||||
|
||||
<!-- END_HTML_ONLY -->
|
||||
|
||||
@ -74,7 +74,7 @@ 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
|
||||
ERROR: Expected integer parameter instead of '1.0' 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
|
||||
@ -85,6 +85,9 @@ 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.
|
||||
Otherwise, you will receive an error message of this kind:
|
||||
|
||||
ERROR: Expected floating point parameter instead of 'v_name' in input script or data file :pre
|
||||
|
||||
Generally, LAMMPS will print a message to the screen and logfile and
|
||||
exit gracefully when it encounters a fatal error. Sometimes it will
|
||||
|
||||
@ -279,12 +279,6 @@ multibody joint). The bodies you have defined exceed this limit. :dd
|
||||
This is an internal LAMMPS error. Please report it to the
|
||||
developers. :dd
|
||||
|
||||
{Atom sorting has bin size = 0.0} :dt
|
||||
|
||||
The neighbor cutoff is being used as the bin size, but it is zero.
|
||||
Thus you must explicitly list a bin size in the atom_modify sort
|
||||
command or turn off sorting. :dd
|
||||
|
||||
{Atom style hybrid cannot have hybrid as an argument} :dt
|
||||
|
||||
Self-explanatory. :dd
|
||||
@ -421,9 +415,9 @@ This is an internal error. It should normally not occur. :dd
|
||||
|
||||
This is an internal error. It should normally not occur. :dd
|
||||
|
||||
{Bad real space Coulomb cutoff in fix tune/kspace} :dt
|
||||
{Bad real space Coulombic cutoff in fix tune/kspace} :dt
|
||||
|
||||
Fix tune/kspace tried to find the optimal real space Coulomb cutoff using
|
||||
Fix tune/kspace tried to find the optimal real space Coulombic cutoff using
|
||||
the Newton-Rhaphson method, but found a non-positive or NaN cutoff :dd
|
||||
|
||||
{Balance command before simulation box is defined} :dt
|
||||
@ -460,7 +454,7 @@ compute. :dd
|
||||
|
||||
{Big particle in fix srd cannot be point particle} :dt
|
||||
|
||||
Big particles must be extended spheriods or ellipsoids. :dd
|
||||
Big particles must be extended spheroids or ellipsoids. :dd
|
||||
|
||||
{Bigint setting in lmptype.h is invalid} :dt
|
||||
|
||||
@ -780,7 +774,7 @@ Cannot use tilt factors unless the simulation box is non-orthogonal. :dd
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{Cannot change box z boundary to nonperiodic for a 2d simulation} :dt
|
||||
{Cannot change box z boundary to non-periodic for a 2d simulation} :dt
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
@ -1288,7 +1282,7 @@ are defined. :dd
|
||||
You cannot reset the timestep when a fix that keeps track of elapsed
|
||||
time is in place. :dd
|
||||
|
||||
{Cannot run 2d simulation with nonperiodic Z dimension} :dt
|
||||
{Cannot run 2d simulation with non-periodic Z dimension} :dt
|
||||
|
||||
Use the boundary command to make the z dimension periodic in order to
|
||||
run a 2d simulation. :dd
|
||||
@ -2116,29 +2110,29 @@ Self-explanatory. :dd
|
||||
Fix setforce cannot be used in this manner. Use fix addforce
|
||||
instead. :dd
|
||||
|
||||
{Cannot use nonperiodic boundares with fix ttm} :dt
|
||||
{Cannot use non-periodic boundares with fix ttm} :dt
|
||||
|
||||
This fix requires a fully periodic simulation box. :dd
|
||||
|
||||
{Cannot use nonperiodic boundaries with Ewald} :dt
|
||||
{Cannot use non-periodic boundaries with Ewald} :dt
|
||||
|
||||
For kspace style ewald, all 3 dimensions must have periodic boundaries
|
||||
unless you use the kspace_modify command to define a 2d slab with a
|
||||
non-periodic z dimension. :dd
|
||||
|
||||
{Cannot use nonperiodic boundaries with EwaldDisp} :dt
|
||||
{Cannot use non-periodic boundaries with EwaldDisp} :dt
|
||||
|
||||
For kspace style ewald/disp, all 3 dimensions must have periodic
|
||||
boundaries unless you use the kspace_modify command to define a 2d
|
||||
slab with a non-periodic z dimension. :dd
|
||||
|
||||
{Cannot use nonperiodic boundaries with PPPM} :dt
|
||||
{Cannot use non-periodic boundaries with PPPM} :dt
|
||||
|
||||
For kspace style pppm, all 3 dimensions must have periodic boundaries
|
||||
unless you use the kspace_modify command to define a 2d slab with a
|
||||
non-periodic z dimension. :dd
|
||||
|
||||
{Cannot use nonperiodic boundaries with PPPMDisp} :dt
|
||||
{Cannot use non-periodic boundaries with PPPMDisp} :dt
|
||||
|
||||
For kspace style pppm/disp, all 3 dimensions must have periodic
|
||||
boundaries unless you use the kspace_modify command to define a 2d
|
||||
@ -3351,21 +3345,21 @@ probably due to errors in the Python code. :dd
|
||||
The default minimum order is 2. This can be reset by the
|
||||
kspace_modify minorder command. :dd
|
||||
|
||||
{Coulomb cut not supported in pair_style buck/long/coul/coul} :dt
|
||||
{Coulombic cutoff not supported in pair_style buck/long/coul/coul} :dt
|
||||
|
||||
Must use long-range Coulombic interactions. :dd
|
||||
|
||||
{Coulomb cut not supported in pair_style lj/long/coul/long} :dt
|
||||
{Coulombic cutoff not supported in pair_style lj/long/coul/long} :dt
|
||||
|
||||
Must use long-range Coulombic interactions. :dd
|
||||
|
||||
{Coulomb cut not supported in pair_style lj/long/tip4p/long} :dt
|
||||
{Coulombic cutoff not supported in pair_style lj/long/tip4p/long} :dt
|
||||
|
||||
Must use long-range Coulombic interactions. :dd
|
||||
|
||||
{Coulomb cutoffs of pair hybrid sub-styles do not match} :dt
|
||||
{Coulombic cutoffs of pair hybrid sub-styles do not match} :dt
|
||||
|
||||
If using a Kspace solver, all Coulomb cutoffs of long pair styles must
|
||||
If using a Kspace solver, all Coulombic cutoffs of long pair styles must
|
||||
be the same. :dd
|
||||
|
||||
{Coulombic cut not supported in pair_style lj/long/dipole/long} :dt
|
||||
@ -5938,9 +5932,9 @@ map command will force an atom map to be created. :dd
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{Input line quote not followed by whitespace} :dt
|
||||
{Input line quote not followed by white-space} :dt
|
||||
|
||||
An end quote must be followed by whitespace. :dd
|
||||
An end quote must be followed by white-space. :dd
|
||||
|
||||
{Insertion region extends outside simulation box} :dt
|
||||
|
||||
@ -7014,7 +7008,7 @@ The kspace accuracy designated in the input must be greater than zero. :dd
|
||||
|
||||
{KSpace accuracy too large to estimate G vector} :dt
|
||||
|
||||
Reduce the accuracy request or specify gwald explicitly
|
||||
Reduce the accuracy request or specify gewald explicitly
|
||||
via the kspace_modify command. :dd
|
||||
|
||||
{KSpace accuracy too low} :dt
|
||||
@ -8014,7 +8008,7 @@ Self-explanatory. :dd
|
||||
|
||||
{Package command after simulation box is defined} :dt
|
||||
|
||||
The package command cannot be used afer a read_data, read_restart, or
|
||||
The package command cannot be used after a read_data, read_restart, or
|
||||
create_box command. :dd
|
||||
|
||||
{Package gpu command without GPU package installed} :dt
|
||||
@ -9198,7 +9192,7 @@ creates one large file for all processors. :dd
|
||||
{Restart file byte ordering is not recognized} :dt
|
||||
|
||||
The file does not appear to be a LAMMPS restart file since it doesn't
|
||||
contain a recognized byte-orderomg flag at the beginning. :dd
|
||||
contain a recognized byte-ordering flag at the beginning. :dd
|
||||
|
||||
{Restart file byte ordering is swapped} :dt
|
||||
|
||||
@ -9410,7 +9404,7 @@ You may also want to boost the page size. :dd
|
||||
|
||||
{Small to big integers are not sized correctly} :dt
|
||||
|
||||
This error occurs whenthe sizes of smallint, imageint, tagint, bigint,
|
||||
This error occurs when the sizes of smallint, imageint, tagint, bigint,
|
||||
as defined in src/lmptype.h are not what is expected. Contact
|
||||
the developers if this occurs. :dd
|
||||
|
||||
|
||||
@ -757,7 +757,7 @@ Self-explanatory. :dd
|
||||
|
||||
This may indicate the shell command did not operate as expected. :dd
|
||||
|
||||
{Should not allow rigid bodies to bounce off relecting walls} :dt
|
||||
{Should not allow rigid bodies to bounce off reflecting walls} :dt
|
||||
|
||||
LAMMPS allows this, but their dynamics are not computed correctly. :dd
|
||||
|
||||
@ -850,10 +850,10 @@ Most FENE models need this setting for the special_bonds command. :dd
|
||||
|
||||
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
|
||||
{Using a many-body 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
|
||||
eliminate neighbors in the neighbor list, which the many-body potential
|
||||
needs to calculated its terms correctly. :dd
|
||||
|
||||
{Using compute temp/deform with inconsistent fix deform remap option} :dt
|
||||
|
||||
@ -78,7 +78,7 @@ micelle: self-assembly of small lipid-like molecules into 2d bilayers
|
||||
min: energy minimization of 2d LJ melt
|
||||
mscg: parameterize a multi-scale coarse-graining (MSCG) model
|
||||
msst: MSST shock dynamics
|
||||
nb3b: use of nonbonded 3-body harmonic pair style
|
||||
nb3b: use of non-bonded 3-body harmonic pair style
|
||||
neb: nudged elastic band (NEB) calculation for barrier finding
|
||||
nemd: non-equilibrium MD of 2d sheared system
|
||||
obstacle: flow around two voids in a 2d channel
|
||||
|
||||
@ -45,7 +45,7 @@ General howto :h3
|
||||
<!-- RST
|
||||
|
||||
.. toctree::
|
||||
:name: general
|
||||
:name: general_howto
|
||||
:maxdepth: 1
|
||||
|
||||
Howto_restart
|
||||
|
||||
@ -19,7 +19,7 @@ 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
|
||||
barostatting methods are currently available: Nose-Hoover (npt and
|
||||
nph) and Berendsen:
|
||||
|
||||
"fix npt"_fix_nh.html
|
||||
|
||||
@ -40,7 +40,7 @@ Install Windows Subsystem for Linux :h5
|
||||
Next you must ensure that the Window Subsystem for Linux is installed. Again,
|
||||
search for "enable windows features" in the Settings dialog. This opens a
|
||||
dialog with a list of features you can install. Add a checkmark to Windows
|
||||
Subsystem for Linux (Beta) and press OK.
|
||||
Subsystem for Linux (Beta) and press OK.
|
||||
|
||||
:image(JPG/bow_tutorial_04_small.png,JPG/bow_tutorial_04.png)
|
||||
:image(JPG/bow_tutorial_05.png,JPG/bow_tutorial_05.png)
|
||||
@ -54,12 +54,12 @@ enter. This will then download Ubuntu for Windows.
|
||||
|
||||
:image(JPG/bow_tutorial_06.png)
|
||||
:image(JPG/bow_tutorial_07.png)
|
||||
|
||||
|
||||
During installation, you will be asked for a new password. This will be used
|
||||
for installing new software and running commands with sudo.
|
||||
|
||||
:image(JPG/bow_tutorial_08.png)
|
||||
|
||||
|
||||
Type exit to close the command-line window.
|
||||
|
||||
Go to the Start menu and type "bash" again. This time you will see a "Bash on
|
||||
|
||||
@ -132,7 +132,7 @@ x1 y1 z1
|
||||
xN yN zN :pre
|
||||
|
||||
where M = 6 + 3*N, and N is the number of sub-particles in the body
|
||||
particle.
|
||||
particle.
|
||||
|
||||
The integer line has a single value N. The floating point line(s)
|
||||
list 6 moments of inertia followed by the coordinates of the N
|
||||
@ -315,7 +315,7 @@ x1 y1 z1
|
||||
...
|
||||
xN yN zN
|
||||
0 1
|
||||
1 2
|
||||
1 2
|
||||
2 3
|
||||
...
|
||||
0 1 2 -1
|
||||
|
||||
@ -22,8 +22,8 @@ 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 4 kinds of chunk-related commands is briefly
|
||||
overviewed. Then some examples are given of how to compute different
|
||||
Here a brief overview for each of the 4 kinds of chunk-related commands
|
||||
is provided. Then some examples are given of how to compute different
|
||||
properties with chunk commands.
|
||||
|
||||
Compute chunk/atom command: :h4
|
||||
|
||||
@ -64,7 +64,7 @@ client or server.
|
||||
"server mc"_server_mc.html = LAMMPS is a server for computing a Monte Carlo energy :ul
|
||||
|
||||
The server doc files give details of the message protocols
|
||||
for data that is exchanged bewteen the client and server.
|
||||
for data that is exchanged between the client and server.
|
||||
|
||||
These example directories illustrate how to use LAMMPS as either a
|
||||
client or server code:
|
||||
@ -75,7 +75,7 @@ examples/COUPLE/lammps_mc
|
||||
examples/COUPLE/lammps_vasp :ul
|
||||
|
||||
The examples/message dir couples a client instance of LAMMPS to a
|
||||
server instance of LAMMPS.
|
||||
server instance of LAMMPS.
|
||||
|
||||
The lammps_mc dir shows how to couple LAMMPS as a server to a simple
|
||||
Monte Carlo client code as the driver.
|
||||
@ -87,7 +87,7 @@ DFT forces, thru a Python wrapper script on VASP.
|
||||
Here is how to launch a client and server code together for any of the
|
||||
4 modes of message exchange that the "message"_message.html command
|
||||
and the CSlib support. Here LAMMPS is used as both the client and
|
||||
server code. Another code could be subsitituted for either.
|
||||
server code. Another code could be substituted for either.
|
||||
|
||||
The examples below show launching both codes from the same window (or
|
||||
batch script), using the "&" character to launch the first code in the
|
||||
@ -106,13 +106,13 @@ together to exchange MPI messages between them.
|
||||
|
||||
For message exchange in {file}, {zmq}, or {mpi/two} modes:
|
||||
|
||||
% mpirun -np 1 lmp_mpi -log log.client < in.client &
|
||||
% mpirun -np 1 lmp_mpi -log log.client < in.client &
|
||||
% mpirun -np 2 lmp_mpi -log log.server < in.server :pre
|
||||
|
||||
% mpirun -np 4 lmp_mpi -log log.client < in.client &
|
||||
% mpirun -np 4 lmp_mpi -log log.client < in.client &
|
||||
% mpirun -np 1 lmp_mpi -log log.server < in.server :pre
|
||||
|
||||
% mpirun -np 2 lmp_mpi -log log.client < in.client &
|
||||
% mpirun -np 2 lmp_mpi -log log.client < in.client &
|
||||
% mpirun -np 4 lmp_mpi -log log.server < in.server :pre
|
||||
|
||||
For message exchange in {mpi/one} mode:
|
||||
|
||||
@ -19,7 +19,7 @@ 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
|
||||
k*r where k is a parameterized 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
|
||||
@ -111,7 +111,7 @@ 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
|
||||
Thermostats can alter this polarization behavior, 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
|
||||
@ -165,7 +165,7 @@ fix_modify press_bar temp CSequ press thermo_press_lmp # pressure modification
|
||||
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.
|
||||
momentum to the system, which is noticeable 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
|
||||
|
||||
@ -74,7 +74,7 @@ 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
|
||||
parameters from the output, and specify these parameters using the
|
||||
second approach in subsequent runs (which have the same composition,
|
||||
force field, and approximately the same volume).
|
||||
|
||||
|
||||
@ -17,7 +17,7 @@ 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
|
||||
Thermostatting 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
|
||||
|
||||
@ -82,7 +82,7 @@ decouple the degrees of freedom associated with the Drude oscillators
|
||||
from those of the normal atoms. Thermalizing the Drude dipoles at
|
||||
temperatures comparable to the rest of the simulation leads to several
|
||||
problems (kinetic energy transfer, very short timestep, etc.), which
|
||||
can be remediate by the "cold Drude" technique ("Lamoureux and
|
||||
can be remedied by the "cold Drude" technique ("Lamoureux and
|
||||
Roux"_#Lamoureux2).
|
||||
|
||||
Two closely related models are used to represent polarization through
|
||||
@ -213,7 +213,7 @@ of mass of the DC-DP pairs, with relaxation time 100 and with random
|
||||
seed 12345. This fix applies also a Langevin thermostat at temperature
|
||||
1. to the relative motion of the DPs around their DCs, with relaxation
|
||||
time 20 and random seed 13977. Only the DCs and non-polarizable
|
||||
atoms need to be in this fix's group. LAMMPS will thermostate the DPs
|
||||
atoms need to be in this fix's group. LAMMPS will thermostat the DPs
|
||||
together with their DC. For this, ghost atoms need to know their
|
||||
velocities. Thus you need to add the following command:
|
||||
|
||||
@ -360,7 +360,7 @@ fix NPH all nph iso 1. 1. 500 :pre
|
||||
It is also possible to use a Nose-Hoover instead of a Langevin
|
||||
thermostat. This requires to use "{fix
|
||||
drude/transform}"_fix_drude_transform.html just before and after the
|
||||
time intergation fixes. The {fix drude/transform/direct} converts the
|
||||
time integration fixes. The {fix drude/transform/direct} converts the
|
||||
atomic masses, positions, velocities and forces into a reduced
|
||||
representation, where the DCs transform into the centers of mass of
|
||||
the DC-DP pairs and the DPs transform into their relative position
|
||||
@ -396,7 +396,7 @@ global pressure and thus a global temperature whatever the fix group.
|
||||
We do want the pressure to correspond to the whole system, but we want
|
||||
the temperature to correspond to the fix group only. We must then use
|
||||
the {fix_modify} command for this. In the end, the block of
|
||||
instructions for thermostating and barostating will look like
|
||||
instructions for thermostatting and barostatting will look like
|
||||
|
||||
compute TATOMS ATOMS temp
|
||||
fix DIRECT all drude/transform/direct
|
||||
|
||||
@ -30,7 +30,7 @@ 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
|
||||
challenging, because it is necessary to run a simulation that performs
|
||||
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
|
||||
|
||||
@ -96,7 +96,7 @@ machine to a directory with the name you chose. If none is given, it will
|
||||
default to "lammps". Typical names are "mylammps" or something similar.
|
||||
|
||||
You can use this local clone to make changes and
|
||||
test them without interfering with the repository on Github.
|
||||
test them without interfering with the repository on GitHub.
|
||||
|
||||
To pull changes from upstream into this copy, you can go to the directory
|
||||
and use git pull:
|
||||
@ -150,7 +150,7 @@ After the commit, the changes can be pushed to the same branch on GitHub:
|
||||
$ git push :pre
|
||||
|
||||
Git will ask you for your user name and password on GitHub if you have
|
||||
not configured anything. If your local branch is not present on Github yet,
|
||||
not configured anything. If your local branch is not present on GitHub yet,
|
||||
it will ask you to add it by running
|
||||
|
||||
$ git push --set-upstream origin github-tutorial-update :pre
|
||||
@ -254,20 +254,53 @@ them, or if a developer has requested that something needs to be changed
|
||||
before the feature can be accepted into the official LAMMPS version.
|
||||
After each push, the automated checks are run again.
|
||||
|
||||
[Labels]
|
||||
|
||||
LAMMPS developers may add labels to your pull request to assign it to
|
||||
categories (mostly for bookkeeping purposes), but a few of them are
|
||||
important: needs_work, work_in_progress, test-for-regression, and
|
||||
full-regression-test. The first two indicate, that your pull request
|
||||
is not considered to be complete. With "needs_work" the burden is on
|
||||
exclusively on you; while "work_in_progress" can also mean, that a
|
||||
LAMMPS developer may want to add changes. Please watch the comments
|
||||
to the pull requests. The two "test" labels are used to trigger
|
||||
extended tests before the code is merged. This is sometimes done by
|
||||
LAMMPS developers, if they suspect that there may be some subtle
|
||||
side effects from your changes. It is not done by default, because
|
||||
those tests are very time consuming.
|
||||
|
||||
[Reviews]
|
||||
|
||||
As of Summer 2018, a pull request needs at least 1 approving review
|
||||
from a LAMMPS developer with write access to the repository.
|
||||
In case your changes touch code that certain developers are associated
|
||||
with, they are auto-requested by the GitHub software. Those associations
|
||||
are set in the file
|
||||
".github/CODEOWNERS"_https://github.com/lammps/lammps/blob/master/.github/CODEOWNERS
|
||||
Thus if you want to be automatically notified to review when anybody
|
||||
changes files or packages, that you have contributed to LAMMPS, you can
|
||||
add suitable patterns to that file, or a LAMMPS developer may add you.
|
||||
|
||||
Otherwise, you can also manually request reviews from specific developers,
|
||||
or LAMMPS developers - in their assessment of your pull request - may
|
||||
determine who else should be reviewing your contribution and add that person.
|
||||
Through reviews, LAMMPS developers also may request specific changes from you.
|
||||
If those are not addressed, your pull requests cannot be merged.
|
||||
|
||||
[Assignees]
|
||||
|
||||
There is an assignee label for pull requests. If the request has not
|
||||
There is an assignee property for pull requests. If the request has not
|
||||
been reviewed by any developer yet, it is not assigned to anyone. After
|
||||
revision, a developer can choose to assign it to either a) you, b) a
|
||||
LAMMPS developer (including him/herself) or c) Steve Plimpton (sjplimp).
|
||||
LAMMPS developer (including him/herself) or c) Axel Kohlmeyer (akohlmey).
|
||||
|
||||
Case a) happens if changes are required on your part :ulb,l
|
||||
Case b) means that at the moment, it is being tested and reviewed by a
|
||||
LAMMPS developer with the expectation that some changes would be required.
|
||||
After the review, the developer can choose to implement changes directly
|
||||
or suggest them to you. :l
|
||||
Case c) means that the pull request has been assigned to the lead
|
||||
developer Steve Plimpton and means it is considered ready for merging. :ule,l
|
||||
Case c) means that the pull request has been assigned to the developer
|
||||
overseeing the merging of pull requests into the master branch. :ule,l
|
||||
|
||||
In this case, Axel assigned the tutorial to Steve:
|
||||
|
||||
@ -336,7 +369,7 @@ commit and push again:
|
||||
$ git commit -m "Merged Axel's suggestions and updated text"
|
||||
$ git push git@github.com:Pakketeretet2/lammps :pre
|
||||
|
||||
This merge also shows up on the lammps Github page:
|
||||
This merge also shows up on the lammps GitHub page:
|
||||
|
||||
:c,image(JPG/tutorial_reverse_pull_request7.png)
|
||||
|
||||
@ -381,3 +414,6 @@ Furthermore, the naming of the patches now follow the pattern
|
||||
"patch_<Day><Month><Year>" to simplify comparisons between releases.
|
||||
Finally, all patches and submissions are subject to automatic testing
|
||||
and code checks to make sure they at the very least compile.
|
||||
|
||||
A discussion of the LAMMPS developer GitHub workflow can be found in the file
|
||||
"doc/github-development-workflow.md"_https://github.com/lammps/lammps/blob/master/doc/github-development-workflow.md
|
||||
|
||||
@ -185,7 +185,7 @@ 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
|
||||
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.
|
||||
|
||||
@ -31,8 +31,8 @@ plane @ a b c x0 y0 z0 @ a*(x-x0) + b*(y-y0) + c*(z-z0) = 0 @ A plane with norma
|
||||
plane_wiggle @ a w @ z - a*sin(w*x) = 0 @ A plane with a sinusoidal modulation on z along x.
|
||||
sphere @ R @ x^2 + y^2 + z^2 - R^2 = 0 @ A sphere of radius R
|
||||
supersphere @ R q @ | x |^q + | y |^q + | z |^q - R^q = 0 @ A supersphere of hyperradius R
|
||||
spine @ a, A, B, B2, c @ -(x^2 + y^2) + (a^2 - z^2/f(z)^2)*(1 + (A*sin(g(z)*z^2))^4), f(z) = c if z > 0, 1 otherwise; g(z) = B if z > 0, B2 otherwise @ An approximation to a dendtritic spine
|
||||
spine_two @ a, A, B, B2, c @ -(x^2 + y^2) + (a^2 - z^2/f(z)^2)*(1 + (A*sin(g(z)*z^2))^2), f(z) = c if z > 0, 1 otherwise; g(z) = B if z > 0, B2 otherwise @ Another approximation to a dendtritic spine
|
||||
spine @ a, A, B, B2, c @ -(x^2 + y^2) + (a^2 - z^2/f(z)^2)*(1 + (A*sin(g(z)*z^2))^4), f(z) = c if z > 0, 1 otherwise; g(z) = B if z > 0, B2 otherwise @ An approximation to a dendritic spine
|
||||
spine_two @ a, A, B, B2, c @ -(x^2 + y^2) + (a^2 - z^2/f(z)^2)*(1 + (A*sin(g(z)*z^2))^2), f(z) = c if z > 0, 1 otherwise; g(z) = B if z > 0, B2 otherwise @ Another approximation to a dendritic spine
|
||||
thylakoid @ wB LB lB @ Various, see "(Paquay)"_#Paquay1 @ A model grana thylakoid consisting of two block-like compartments connected by a bridge of width wB, length LB and taper length lB
|
||||
torus @ R r @ (R - sqrt( x^2 + y^2 ) )^2 + z^2 - r^2 @ A torus with large radius R and small radius r, centered on (0,0,0) :tb(s=@)
|
||||
|
||||
|
||||
@ -55,5 +55,5 @@ using the "fix flow/gauss"_fix_flow_gauss.html command.
|
||||
:line
|
||||
|
||||
:link(Daivis-nemd)
|
||||
[(Daivis and Todd)] Daivis and Todd, Nonequilibrium Molecular Dyanmics (book),
|
||||
[(Daivis and Todd)] Daivis and Todd, Nonequilibrium Molecular Dynamics (book),
|
||||
Cambridge University Press, https://doi.org/10.1017/9781139017848, (2017).
|
||||
|
||||
@ -45,8 +45,8 @@ 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
|
||||
complex in order to remedy this and other issues. Specifically, the
|
||||
Drude model includes specific thermostatting of the core-Drude pairs
|
||||
and short-range damping of the induced dipoles.
|
||||
|
||||
The three polarization methods can be implemented through a
|
||||
@ -77,5 +77,5 @@ motion of the Drude particles with respect to their cores is kept
|
||||
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
|
||||
relative core-Drude particle motion is thermostatted separately as
|
||||
well.
|
||||
|
||||
@ -141,16 +141,16 @@ Python code if {L} was a lammps instance:
|
||||
L.command("region box block 0 10 0 5 -0.5 0.5") :pre
|
||||
|
||||
With the PyLammps interface, any command can be split up into arbitrary parts
|
||||
separated by whitespace, passed as individual arguments to a region method.
|
||||
separated by white-space, passed as individual arguments to a region method.
|
||||
|
||||
L.region("box block", 0, 10, 0, 5, -0.5, 0.5) :pre
|
||||
|
||||
Note that each parameter is set as Python literal floating-point number. In the
|
||||
PyLammps interface, each command takes an arbitrary parameter list and transparently
|
||||
merges it to a single command string, separating individual parameters by whitespace.
|
||||
merges it to a single command string, separating individual parameters by white-space.
|
||||
|
||||
The benefit of this approach is avoiding redundant command calls and easier
|
||||
parameterization. In the original interface parametrization needed to be done
|
||||
parameterization. In the original interface parameterization needed to be done
|
||||
manually by creating formatted strings.
|
||||
|
||||
L.command("region box block %f %f %f %f %f %f" % (xlo, xhi, ylo, yhi, zlo, zhi)) :pre
|
||||
@ -328,7 +328,7 @@ jupyter notebook :pre
|
||||
IPyLammps Examples :h4
|
||||
|
||||
Examples of IPython notebooks can be found in the python/examples/pylammps
|
||||
subdirectory. To open these notebooks launch {jupyter notebook} inside this
|
||||
sub-directory. To open these notebooks launch {jupyter notebook} inside this
|
||||
directory and navigate to one of them. If you compiled and installed
|
||||
a LAMMPS shared library with exceptions, PNG, JPEG and FFMPEG support
|
||||
you should be able to rerun all of these notebooks.
|
||||
|
||||
@ -9,7 +9,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
Multi-replica simulations :h3
|
||||
|
||||
Several commands in LAMMPS run mutli-replica simulations, meaning
|
||||
Several commands in LAMMPS run multi-replica simulations, meaning
|
||||
that multiple instances (replicas) of your simulation are run
|
||||
simultaneously, with small amounts of data exchanged between replicas
|
||||
periodically.
|
||||
|
||||
@ -30,7 +30,7 @@ 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
|
||||
Angstrom cutoff for both LJ and Coulombic 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.
|
||||
|
||||
@ -35,7 +35,7 @@ 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
|
||||
The sphere style defines particles that are spheroids 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
|
||||
@ -236,7 +236,7 @@ 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
|
||||
list of sub-particles. Individual body particles 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
|
||||
|
||||
@ -12,48 +12,48 @@ Magnetic spins :h3
|
||||
The magnetic spin simulations are enabled by the SPIN package, whose
|
||||
implementation is detailed in "Tranchida"_#Tranchida7.
|
||||
|
||||
The model represents 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 model represents 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
|
||||
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.
|
||||
|
||||
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.
|
||||
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.
|
||||
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
|
||||
thermostatted 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
|
||||
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 output by two main
|
||||
commands. The first one is "compute spin"_compute_spin.html, that
|
||||
enables to evaluate magnetic averaged quantities, such as the total
|
||||
All the computed magnetic properties can be output 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
|
||||
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
|
||||
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,
|
||||
[(Tranchida)] Tranchida, Plimpton, Thibaudeau and Thompson,
|
||||
arXiv preprint arXiv:1801.10233, (2018).
|
||||
|
||||
@ -96,5 +96,5 @@ temperature compute is used for default thermodynamic output.
|
||||
:line
|
||||
|
||||
:link(Daivis-thermostat)
|
||||
[(Daivis and Todd)] Daivis and Todd, Nonequilibrium Molecular Dyanmics (book),
|
||||
[(Daivis and Todd)] Daivis and Todd, Nonequilibrium Molecular Dynamics (book),
|
||||
Cambridge University Press, https://doi.org/10.1017/9781139017848, (2017).
|
||||
|
||||
@ -200,7 +200,7 @@ 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
|
||||
A second use is to run Parrinello-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
|
||||
|
||||
@ -140,5 +140,5 @@ with time at sufficiently long times.
|
||||
:line
|
||||
|
||||
:link(Daivis-viscosity)
|
||||
[(Daivis and Todd)] Daivis and Todd, Nonequilibrium Molecular Dyanmics (book),
|
||||
[(Daivis and Todd)] Daivis and Todd, Nonequilibrium Molecular Dynamics (book),
|
||||
Cambridge University Press, https://doi.org/10.1017/9781139017848, (2017).
|
||||
|
||||
@ -45,7 +45,7 @@ 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>".)
|
||||
between them at any time using "git checkout <branch name>".)
|
||||
|
||||
Once the command completes, your directory will contain the same files
|
||||
as if you unpacked a current LAMMPS tarball, with two exceptions:
|
||||
|
||||
@ -15,7 +15,7 @@ Binaries are available for different versions of Linux:
|
||||
"Pre-built Fedora Linux executables"_#fedora
|
||||
"Pre-built EPEL Linux executables (RHEL, CentOS)"_#epel
|
||||
"Pre-built OpenSuse Linux executables"_#opensuse
|
||||
"Pre-built Gentoo Linux executable"_#gentoo :all(b)
|
||||
"Gentoo Linux executable"_#gentoo :all(b)
|
||||
|
||||
:line
|
||||
|
||||
@ -87,11 +87,11 @@ linking to the C library interface (lammps-devel, lammps-mpich-devel,
|
||||
lammps-openmpi-devel), the header for compiling programs using
|
||||
the C library interface (lammps-headers), and the LAMMPS python
|
||||
module for Python 3. All packages can be installed at the same
|
||||
time and the name of the LAMMPS executable is {lmp} in all 3 cases.
|
||||
By default, {lmp} will refer to the serial executable, unless
|
||||
one of the MPI environment modules is loaded
|
||||
time and the name of the LAMMPS executable is {lmp} and {lmp_openmpi}
|
||||
or {lmp_mpich} respectively. By default, {lmp} will refer to the
|
||||
serial executable, unless one of the MPI environment modules is loaded
|
||||
("module load mpi/mpich-x86_64" or "module load mpi/openmpi-x86_64").
|
||||
Then the corresponding parallel LAMMPS executable is used.
|
||||
Then the corresponding parallel LAMMPS executable can be used.
|
||||
The same mechanism applies when loading the LAMMPS python module.
|
||||
|
||||
To install LAMMPS with OpenMPI and run an input in.lj with 2 CPUs do:
|
||||
@ -150,7 +150,7 @@ Thanks to Christoph Junghans (LANL) for making LAMMPS available in OpenSuse.
|
||||
|
||||
:line
|
||||
|
||||
Pre-built Gentoo Linux executable :h4,link(gentoo)
|
||||
Gentoo Linux executable :h4,link(gentoo)
|
||||
|
||||
LAMMPS is part of Gentoo's main package tree and can be installed by
|
||||
typing:
|
||||
|
||||
@ -17,7 +17,7 @@ how to stay current are on the "Install git"_Install_git.html and
|
||||
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
|
||||
a patch file is posted on the "bug and feature
|
||||
page"_http://lammps.sandia.gov/bug.html of the LAMMPS 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
|
||||
|
||||
@ -23,8 +23,8 @@ 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
|
||||
source distribution except: KIM, 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
|
||||
|
||||
@ -48,7 +48,7 @@ Trung Ngyuen (Northwestern U), GPU and RIGID and BODY packages
|
||||
Mike Parks (Sandia), PERI package for Peridynamics
|
||||
Roy Pollock (LLNL), Ewald and PPPM solvers
|
||||
Christian Trott (Sandia), USER-CUDA and KOKKOS packages
|
||||
Ilya Valuev (JIHT), USER-AWPMD package for wave-packet MD
|
||||
Ilya Valuev (JIHT), USER-AWPMD package for wave packet MD
|
||||
Greg Wagner (Northwestern U), MEAM package for MEAM potential :ul
|
||||
|
||||
:line
|
||||
@ -58,7 +58,7 @@ 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)
|
||||
|
||||
@ -68,7 +68,7 @@ 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), \
|
||||
many-body 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: \
|
||||
@ -110,11 +110,11 @@ Atom creation :h4,link(create)
|
||||
displace atoms :ul
|
||||
|
||||
Ensembles, constraints, and boundary conditions :h4,link(ensemble)
|
||||
("fix"_fix.html command)
|
||||
("fix"_fix.html command)
|
||||
|
||||
2d or 3d systems
|
||||
orthogonal or non-orthogonal (triclinic symmetry) simulation domains
|
||||
constant NVE, NVT, NPT, NPH, Parinello/Rahman integrators
|
||||
constant NVE, NVT, NPT, NPH, Parrinello/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)
|
||||
@ -128,7 +128,7 @@ Ensembles, constraints, and boundary conditions :h4,link(ensemble)
|
||||
variety of additional boundary conditions and constraints :ul
|
||||
|
||||
Integrators :h4,link(integrate)
|
||||
("run"_run.html, "run_style"_run_style.html, "minimize"_minimize.html commands)
|
||||
("run"_run.html, "run_style"_run_style.html, "minimize"_minimize.html commands)
|
||||
|
||||
velocity-Verlet integrator
|
||||
Brownian dynamics
|
||||
@ -142,7 +142,7 @@ 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)
|
||||
("dump"_dump.html, "restart"_restart.html commands)
|
||||
|
||||
log file of thermodynamic info
|
||||
text dump files of atom coords, velocities, other per-atom quantities
|
||||
|
||||
@ -13,25 +13,29 @@ 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:
|
||||
Specifically, LAMMPS was not conceived and designed for:
|
||||
|
||||
run thru a GUI
|
||||
build molecular systems
|
||||
being run thru a GUI
|
||||
building molecular systems, or building molecular topologies
|
||||
assign force-field coefficients automagically
|
||||
perform sophisticated analyses of your MD simulation
|
||||
perform sophisticated analysis of your MD simulation
|
||||
visualize your MD simulation interactively
|
||||
plot your output data :ul
|
||||
|
||||
Although over the years these limitations have been somewhat
|
||||
reduced through features added to LAMMPS or external tools
|
||||
that either closely interface with LAMMPS or extend LAMMPS.
|
||||
|
||||
Here are suggestions on how to perform these tasks:
|
||||
|
||||
GUI: LAMMPS can be built as a library and a Python wrapper that wraps
|
||||
[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
|
||||
page. Also, there are several external wrappers or GUI front ends. :ulb,l
|
||||
|
||||
Builder: Several pre-processing tools are packaged with LAMMPS. Some
|
||||
[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
|
||||
@ -40,41 +44,54 @@ 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
|
||||
describes a variety of 3rd party tools for this task. Furthermore,
|
||||
some LAMMPS internal commands allow to reconstruct, or selectively add
|
||||
topology information, as well as provide the option to insert molecule
|
||||
templates instead of atoms for building bulk molecular systems. :l
|
||||
|
||||
Force-field assignment: The conversion tools described in the previous
|
||||
[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
|
||||
or BIOVIA (formerly Accelrys) force field files. The tools
|
||||
"ParmEd"_https://parmed.github.io/ParmEd/html/index.html and
|
||||
"InterMol"_https://github.com/shirtsgroup/InterMol are particularly
|
||||
powerful and flexible in converting force field and topology data
|
||||
between various MD simulation programs. :l
|
||||
|
||||
Simulation analyses: If you want to perform analyses on-the-fly as
|
||||
[Simulation analysis:] If you want to perform analysis 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
|
||||
post-processing codes. To some degree, that conversion can be done
|
||||
directly inside of LAMMPS by interfacing to the VMD molfile plugins.
|
||||
The "rerun"_rerun.html command also allows to do some post-processing
|
||||
of existing trajectories, and through being able to read a variety
|
||||
of file formats, this can also be used for analyzing trajectories
|
||||
from other MD 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
|
||||
[Visualization:] LAMMPS can produce NETPBM, JPG or PNG snapshot images
|
||||
on-the-fly via its "dump image"_dump_image.html command and pass
|
||||
them to an external program, "FFmpeg"_https://www.ffmpeg.org to generate
|
||||
movies from them. 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
|
||||
[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:] 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
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
<!-- HTML_ONLY -->
|
||||
<HEAD>
|
||||
<TITLE>LAMMPS Users Manual</TITLE>
|
||||
<META NAME="docnumber" CONTENT="24 Oct 2018 version">
|
||||
<META NAME="docnumber" CONTENT="4 Jan 2019 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>
|
||||
@ -21,7 +21,7 @@
|
||||
:line
|
||||
|
||||
LAMMPS Documentation :c,h1
|
||||
24 Oct 2018 version :c,h2
|
||||
4 Jan 2019 version :c,h2
|
||||
|
||||
"What is a LAMMPS version?"_Manual_version.html
|
||||
|
||||
|
||||
@ -61,10 +61,12 @@ make pdf # generate 2 PDF files (Manual.pdf,Developer.pdf)
|
||||
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 epub # generate LAMMPS.epub in ePUB format using Sphinx
|
||||
make mobi # generate LAMMPS.mobi in MOBI format using ebook-convert
|
||||
make clean # remove intermediate RST files created by HTML build
|
||||
make clean-all # remove entire build folder and any cached data :pre
|
||||
make anchor_check # check for duplicate anchor labels
|
||||
make spelling # spell-check the manual
|
||||
|
||||
:line
|
||||
|
||||
@ -106,7 +108,14 @@ This will install virtualenv from the Python Package Index.
|
||||
|
||||
Installing prerequisites for PDF build
|
||||
|
||||
[TBA]
|
||||
Building the PDF manual requires a working C++ compiler (to
|
||||
compile the txt2html tool and a working installation of
|
||||
"HTMLDOC"_https://www.msweet.org/htmldoc/
|
||||
HTMLDOC has its own list of prerequisites, but in most cases
|
||||
you can install a binary package of it either through your
|
||||
Linux package manager or MacOS (dmg) and Windows installer
|
||||
(msi) packages from its
|
||||
"GitHub releases page at"_https://github.com/michaelrsweet/htmldoc/releases
|
||||
|
||||
:line
|
||||
|
||||
|
||||
@ -33,11 +33,11 @@ how much effort it will cause to integrate and test it, how much it
|
||||
requires changes to the core codebase, and of how much interest it is
|
||||
to the larger LAMMPS community. Please see below for a checklist of
|
||||
typical requirements. Once you have prepared everything, see the
|
||||
"Howto github"_Howto_github.html doc page for instructions on how to
|
||||
"Using GitHub with LAMMPS Howto"_Howto_github.html doc page for instructions on how to
|
||||
submit your changes or new files through a GitHub pull request. If you
|
||||
prefer to submit patches or full files, you should first make certain,
|
||||
that your code works correctly with the latest patch-level version of
|
||||
LAMMPS and contains all bugfixes from it. Then create a gzipped tar
|
||||
LAMMPS and contains all bug fixes from it. Then create a gzipped tar
|
||||
file of all changed or added files or a corresponding patch file using
|
||||
'diff -u' or 'diff -c' and compress it with gzip. Please only use gzip
|
||||
compression, as this works well on all platforms.
|
||||
@ -108,9 +108,13 @@ your contribution(s) to be added to main LAMMPS code or one of its
|
||||
standard packages, it needs to be written in a style compatible with
|
||||
other LAMMPS source files. This means: 2-character indentation per
|
||||
level, [no tabs], no lines over 80 characters. I/O is done via
|
||||
the C-style stdio library, class header files should not import any
|
||||
system headers outside <stdio.h>, STL containers should be avoided
|
||||
in headers, and forward declarations used where possible or needed.
|
||||
the C-style stdio library (mixing of stdio and iostreams is generally
|
||||
discouraged), class header files should not import any system headers
|
||||
outside of <cstdio>, STL containers should be avoided in headers,
|
||||
system header from the C library should use the C++-style names
|
||||
(<cstdlib>, <cstdio>, or <cstring>) instead of the C-style names
|
||||
<stdlib.h>, <stdio.h>, or <string.h>), and forward declarations
|
||||
used where possible or needed to avoid including headers.
|
||||
All added code should be placed into the LAMMPS_NS namespace or a
|
||||
sub-namespace; global or static variables should be avoided, as they
|
||||
conflict with the modular nature of LAMMPS and the C++ class structure.
|
||||
|
||||
@ -10,7 +10,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
Pair styles :h3
|
||||
|
||||
Classes that compute pairwise interactions are derived from the Pair
|
||||
class. In LAMMPS, pairwise calculation include manybody potentials
|
||||
class. In LAMMPS, pairwise calculation include many-body potentials
|
||||
such as EAM or Tersoff where particles interact without a static bond
|
||||
topology. New styles can be created to add new pair potentials to
|
||||
LAMMPS.
|
||||
|
||||
@ -20,6 +20,6 @@ Here is a brief description of methods you define in your new derived
|
||||
class. See region.h for details.
|
||||
|
||||
inside: determine whether a point is in the region
|
||||
surface_interior: determine if a point is within a cutoff distance inside of surc
|
||||
surface_exterior: determine if a point is within a cutoff distance outside of surf
|
||||
surface_interior: determine if a point is within a cutoff distance inside of surface
|
||||
surface_exterior: determine if a point is within a cutoff distance outside of surface
|
||||
shape_update : change region shape if set by time-dependent variable :tb(s=:)
|
||||
|
||||
Binary file not shown.
@ -45,7 +45,6 @@ as contained in the file name.
|
||||
"LATTE"_#PKG-LATTE,
|
||||
"MANYBODY"_#PKG-MANYBODY,
|
||||
"MC"_#PKG-MC,
|
||||
"MEAM"_#PKG-MEAM,
|
||||
"MESSAGE"_#PKG-MESSAGE,
|
||||
"MISC"_#PKG-MISC,
|
||||
"MOLECULE"_#PKG-MOLECULE,
|
||||
@ -56,7 +55,6 @@ as contained in the file name.
|
||||
"POEMS"_#PKG-POEMS,
|
||||
"PYTHON"_#PKG-PYTHON,
|
||||
"QEQ"_#PKG-QEQ,
|
||||
"REAX"_#PKG-REAX,
|
||||
"REPLICA"_#PKG-REPLICA2,
|
||||
"RIGID"_#PKG-RIGID,
|
||||
"SHOCK"_#PKG-SHOCK,
|
||||
@ -89,12 +87,14 @@ as contained in the file name.
|
||||
"USER-NETCDF"_#PKG-USER-NETCDF,
|
||||
"USER-OMP"_#PKG-USER-OMP,
|
||||
"USER-PHONON"_#PKG-USER-PHONON,
|
||||
"USER-PLUMED"_#PKG-USER-PLUMED,
|
||||
"USER-PTM"_#PKG-USER-PTM,
|
||||
"USER-QMMM"_#PKG-USER-QMMM,
|
||||
"USER-QTB"_#PKG-USER-QTB,
|
||||
"USER-QUIP"_#PKG-USER-QUIP,
|
||||
"USER-REAXC"_#PKG-USER-REAXC,
|
||||
"USER-SCAFACOS"_#PKG-USER-SCAFACOS,
|
||||
"USER-SDPD"_#PKG-USER-SDPD,
|
||||
"USER-SMD"_#PKG-USER-SMD,
|
||||
"USER-SMTBQ"_#PKG-USER-SMTBQ,
|
||||
"USER-SPH"_#PKG-USER-SPH,
|
||||
@ -203,7 +203,7 @@ available on your system.
|
||||
|
||||
[Author:] Axel Kohlmeyer (Temple U).
|
||||
|
||||
[Install:]
|
||||
[Install:]
|
||||
|
||||
This package has "specific installation
|
||||
instructions"_Build_extras.html#gpu on the "Build
|
||||
@ -284,7 +284,7 @@ also the "KOKKOS"_#PKG-KOKKOS package, which has GPU-enabled styles.
|
||||
[Authors:] Mike Brown (Intel) while at Sandia and ORNL and Trung Nguyen
|
||||
(Northwestern U) while at ORNL.
|
||||
|
||||
[Install:]
|
||||
[Install:]
|
||||
|
||||
This package has "specific installation
|
||||
instructions"_Build_extras.html#gpu on the "Build
|
||||
@ -352,7 +352,7 @@ API which the "pair_style kim"_pair_kim.html command uses. He
|
||||
developed the pair style in collaboration with Valeriu Smirichinski (U
|
||||
Minnesota).
|
||||
|
||||
[Install:]
|
||||
[Install:]
|
||||
|
||||
This package has "specific installation
|
||||
instructions"_Build_extras.html#gpu on the "Build
|
||||
@ -398,7 +398,7 @@ which was developed by Carter Edwards, Christian Trott, and others at
|
||||
Sandia, and which is included in the LAMMPS distribution in
|
||||
lib/kokkos.
|
||||
|
||||
[Install:]
|
||||
[Install:]
|
||||
|
||||
This package has "specific installation
|
||||
instructions"_Build_extras.html#gpu on the "Build
|
||||
@ -492,7 +492,7 @@ MANYBODY package :link(PKG-MANYBODY),h4
|
||||
|
||||
[Contents:]
|
||||
|
||||
A variety of manybody and bond-order potentials. These include
|
||||
A variety of many-body and bond-order potentials. These include
|
||||
(AI)REBO, BOP, EAM, EIM, Stillinger-Weber, and Tersoff potentials.
|
||||
|
||||
[Supporting info:]
|
||||
@ -516,7 +516,7 @@ MC package :link(PKG-MC),h4
|
||||
Several fixes and a pair style that have Monte Carlo (MC) or MC-like
|
||||
attributes. These include fixes for creating, breaking, and swapping
|
||||
bonds, for performing atomic swaps, and performing grand-canonical MC
|
||||
(GCMC) in conjuction with dynamics.
|
||||
(GCMC) in conjunction with dynamics.
|
||||
|
||||
[Supporting info:]
|
||||
|
||||
@ -531,37 +531,6 @@ http://lammps.sandia.gov/movies.html#gcmc :ul
|
||||
|
||||
:line
|
||||
|
||||
MEAM package :link(PKG-MEAM),h4
|
||||
|
||||
[Contents:]
|
||||
|
||||
A pair style for the modified embedded atom (MEAM) potential.
|
||||
|
||||
Please note that the use of the MEAM package is discouraged as
|
||||
it has been superseded by the "USER-MEAMC"_#PKG-USER-MEAMC package,
|
||||
which is a direct translation of the MEAM package to C++.
|
||||
USER-MEAMC contains additional optimizations making it run faster
|
||||
than MEAM on most machines, while providing the identical features
|
||||
and user interface.
|
||||
|
||||
[Author:] Greg Wagner (Northwestern U) while at Sandia.
|
||||
|
||||
[Install:]
|
||||
|
||||
This package has "specific installation
|
||||
instructions"_Build_extras.html#gpu on the "Build
|
||||
extras"_Build_extras.html doc page.
|
||||
|
||||
[Supporting info:]
|
||||
|
||||
src/MEAM: filenames -> commands
|
||||
src/meam/README
|
||||
lib/meam/README
|
||||
"pair_style meam"_pair_meam.html
|
||||
examples/meam :ul
|
||||
|
||||
:line
|
||||
|
||||
MESSAGE package :link(PKG-MESSAGE),h4
|
||||
|
||||
[Contents:]
|
||||
@ -679,7 +648,7 @@ system.
|
||||
library was developed by Jacob Wagner in Greg Voth's group at the
|
||||
University of Chicago.
|
||||
|
||||
[Install:]
|
||||
[Install:]
|
||||
|
||||
This package has "specific installation
|
||||
instructions"_Build_extras.html#gpu on the "Build
|
||||
@ -711,7 +680,7 @@ have styles optimized for CPU performance.
|
||||
[Authors:] James Fischer (High Performance Technologies), David Richie,
|
||||
and Vincent Natoli (Stone Ridge Technolgy).
|
||||
|
||||
[Install:]
|
||||
[Install:]
|
||||
|
||||
This package has "specific installation
|
||||
instructions"_Build_extras.html#gpu on the "Build
|
||||
@ -768,7 +737,7 @@ connections at hinge points.
|
||||
|
||||
[Author:] Rudra Mukherjee (JPL) while at RPI.
|
||||
|
||||
[Install:]
|
||||
[Install:]
|
||||
|
||||
This package has "specific installation
|
||||
instructions"_Build_extras.html#gpu on the "Build
|
||||
@ -800,7 +769,7 @@ shared library available on your system, which needs to be a Python 2
|
||||
version, 2.6 or later. Python 3 is not yet supported. See the
|
||||
lib/python/README for more details.
|
||||
|
||||
[Install:]
|
||||
[Install:]
|
||||
|
||||
This package has "specific installation
|
||||
instructions"_Build_extras.html#gpu on the "Build
|
||||
@ -832,38 +801,6 @@ examples/streitz :ul
|
||||
|
||||
:line
|
||||
|
||||
REAX package :link(PKG-REAX),h4
|
||||
|
||||
[Contents:]
|
||||
|
||||
NOTE: the use of the REAX package is discouraged, as it is no longer
|
||||
maintained. Please use the "USER-REAXC"_#PKG-USER-REAXC package instead,
|
||||
and possibly the KOKKOS enabled variant of that, which has a more robust
|
||||
memory management.
|
||||
|
||||
A pair style which wraps a Fortran library which implements the ReaxFF
|
||||
potential, which is a universal reactive force field. Also included is
|
||||
a "fix reax/bonds"_fix_reax_bonds.html command for monitoring molecules
|
||||
as bonds are created and destroyed.
|
||||
|
||||
[Author:] Aidan Thompson (Sandia).
|
||||
|
||||
[Install:]
|
||||
|
||||
This package has "specific installation
|
||||
instructions"_Build_extras.html#gpu on the "Build
|
||||
extras"_Build_extras.html doc page.
|
||||
|
||||
[Supporting info:]
|
||||
|
||||
src/REAX: filenames -> commands
|
||||
lib/reax/README
|
||||
"pair_style reax"_pair_reax.html
|
||||
"fix reax/bonds"_fix_reax_bonds.html
|
||||
examples/reax :ul
|
||||
|
||||
:line
|
||||
|
||||
REPLICA package :link(PKG-REPLICA2),h4
|
||||
|
||||
[Contents:]
|
||||
@ -1021,7 +958,7 @@ system.
|
||||
library was written by Chris Rycroft (Harvard U) while at UC Berkeley
|
||||
and LBNL.
|
||||
|
||||
[Install:]
|
||||
[Install:]
|
||||
|
||||
This package has "specific installation
|
||||
instructions"_Build_extras.html#gpu on the "Build
|
||||
@ -1048,7 +985,7 @@ atomic information to continuum fields.
|
||||
|
||||
[Authors:] Reese Jones, Jeremy Templeton, Jon Zimmerman (Sandia).
|
||||
|
||||
[Install:]
|
||||
[Install:]
|
||||
|
||||
This package has "specific installation
|
||||
instructions"_Build_extras.html#gpu on the "Build
|
||||
@ -1075,7 +1012,7 @@ model.
|
||||
|
||||
[Author:] Ilya Valuev (JIHT, Russia).
|
||||
|
||||
[Install:]
|
||||
[Install:]
|
||||
|
||||
This package has "specific installation
|
||||
instructions"_Build_extras.html#gpu on the "Build
|
||||
@ -1098,7 +1035,7 @@ This package provides "fix bocs"_fix_bocs.html, a modified version
|
||||
of "fix npt"_fix_nh.html which includes the pressure correction to
|
||||
the barostat as outlined in:
|
||||
|
||||
N. J. H. Dunn and W. G. Noid, "Bottom-up coarse-grained models that
|
||||
N. J. H. Dunn and W. G. Noid, "Bottom-up coarse-grained models that
|
||||
accurately describe the structure, pressure, and compressibility of
|
||||
molecular liquids," J. Chem. Phys. 143, 243148 (2015).
|
||||
|
||||
@ -1183,10 +1120,10 @@ and Jerome Henin (LISM, CNRS, Marseille, France), originally for
|
||||
the NAMD MD code, but with portability in mind. Axel Kohlmeyer
|
||||
(Temple U) provided the interface to LAMMPS.
|
||||
|
||||
[Install:]
|
||||
[Install:]
|
||||
|
||||
This package has "specific installation
|
||||
instructions"_Build_extras.html#gpu on the "Build
|
||||
instructions"_Build_extras.html#user-colvars on the "Build
|
||||
extras"_Build_extras.html doc page.
|
||||
|
||||
[Supporting info:]
|
||||
@ -1200,6 +1137,36 @@ examples/USER/colvars :ul
|
||||
|
||||
:line
|
||||
|
||||
USER-PLUMED package :link(PKG-USER-PLUMED),h4
|
||||
|
||||
[Contents:]
|
||||
|
||||
The fix plumed command allows you to use the PLUMED free energy plugin
|
||||
for molecular dynamics to analyze and bias your LAMMPS trajectory on
|
||||
the fly. The PLUMED library is called from within the LAMMPS input
|
||||
script by using the "fix plumed _fix_plumed.html command.
|
||||
|
||||
[Authors:] The "PLUMED library"_#PLUMED is written and maintained by
|
||||
Massimilliano Bonomi, Giovanni Bussi, Carlo Camiloni and Gareth
|
||||
Tribello.
|
||||
|
||||
:link(PLUMED,http://www.plumed.org)
|
||||
|
||||
[Install:]
|
||||
|
||||
This package has "specific installation
|
||||
instructions"_Build_extras.html#gpu on the "Build
|
||||
extras"_Build_extras.html doc page.
|
||||
|
||||
[Supporting info:]
|
||||
|
||||
src/USER-PLUMED/README
|
||||
lib/plumed/README
|
||||
"fix plumed"_fix_plumed.html
|
||||
examples/USER/plumed :ul
|
||||
|
||||
:line
|
||||
|
||||
USER-DIFFRACTION package :link(PKG-USER-DIFFRACTION),h4
|
||||
|
||||
[Contents:]
|
||||
@ -1363,7 +1330,7 @@ system.
|
||||
[Author:] Pierre de Buyl (KU Leuven) created both the package and the
|
||||
H5MD format.
|
||||
|
||||
[Install:]
|
||||
[Install:]
|
||||
|
||||
This package has "specific installation
|
||||
instructions"_Build_extras.html#gpu on the "Build
|
||||
@ -1401,7 +1368,7 @@ NOTE: the USER-INTEL package contains styles that require using the
|
||||
|
||||
[Author:] Mike Brown (Intel).
|
||||
|
||||
[Install:]
|
||||
[Install:]
|
||||
|
||||
This package has "specific installation
|
||||
instructions"_Build_extras.html#gpu on the "Build
|
||||
@ -1520,10 +1487,9 @@ USER-MEAMC package :link(PKG-USER-MEAMC),h4
|
||||
[Contents:]
|
||||
|
||||
A pair style for the modified embedded atom (MEAM) potential
|
||||
translated from the Fortran version in the "MEAM"_#PKG-MEAM package
|
||||
to plain C++. In contrast to the MEAM package, no library
|
||||
needs to be compiled and the pair style can be instantiated
|
||||
multiple times.
|
||||
translated from the Fortran version in the (obsolete) "MEAM" package
|
||||
to plain C++. The USER-MEAMC fully replaces the MEAM package, which
|
||||
has been removed from LAMMPS after the 12 December 2018 version.
|
||||
|
||||
[Author:] Sebastian Huetter, (Otto-von-Guericke University Magdeburg)
|
||||
based on the Fortran version of Greg Wagner (Northwestern U) while at
|
||||
@ -1533,8 +1499,8 @@ Sandia.
|
||||
|
||||
src/USER-MEAMC: filenames -> commands
|
||||
src/USER-MEAMC/README
|
||||
"pair_style meam/c"_pair_meam.html
|
||||
examples/meam :ul
|
||||
"pair_style meam/c"_pair_meamc.html
|
||||
examples/meamc :ul
|
||||
|
||||
:line
|
||||
|
||||
@ -1571,17 +1537,17 @@ USER-MOFFF package :link(PKG-USER-MOFFF),h4
|
||||
[Contents:]
|
||||
|
||||
Pair, angle and improper styles needed to employ the MOF-FF
|
||||
force field by Schmid and coworkers with LAMMPS.
|
||||
force field by Schmid and coworkers with LAMMPS.
|
||||
MOF-FF is a first principles derived force field with the primary aim
|
||||
to simulate MOFs and related porous framework materials, using spherical
|
||||
to simulate MOFs and related porous framework materials, using spherical
|
||||
Gaussian charges. It is described in S. Bureekaew et al., Phys. Stat. Sol. B
|
||||
2013, 250, 1128-1141.
|
||||
For the usage of MOF-FF see the example in the example directory as
|
||||
For the usage of MOF-FF see the example in the example directory as
|
||||
well as the "MOF+"_MOFplus website.
|
||||
|
||||
:link(MOFplus,https://www.mofplus.org/content/show/MOF-FF)
|
||||
|
||||
[Author:] Hendrik Heenen (Technical U of Munich),
|
||||
[Author:] Hendrik Heenen (Technical U of Munich),
|
||||
Rochus Schmid (Ruhr-University Bochum).
|
||||
|
||||
[Supporting info:]
|
||||
@ -1622,7 +1588,7 @@ at
|
||||
|
||||
[Author:] Axel Kohlmeyer (Temple U).
|
||||
|
||||
[Install:]
|
||||
[Install:]
|
||||
|
||||
This package has "specific installation
|
||||
instructions"_Build_extras.html#gpu on the "Build
|
||||
@ -1662,7 +1628,7 @@ tools:
|
||||
|
||||
[Author:] Lars Pastewka (Karlsruhe Institute of Technology).
|
||||
|
||||
[Install:]
|
||||
[Install:]
|
||||
|
||||
This package has "specific installation
|
||||
instructions"_Build_extras.html#gpu on the "Build
|
||||
@ -1706,7 +1672,7 @@ See src/MAKE/OPTIONS/Makefile.omp for an example.
|
||||
Once you have an appropriate Makefile.machine, you can
|
||||
install/un-install the package and build LAMMPS in the usual manner:
|
||||
|
||||
[Install:]
|
||||
[Install:]
|
||||
|
||||
This package has "specific installation
|
||||
instructions"_Build_extras.html#gpu on the "Build
|
||||
@ -1785,7 +1751,7 @@ without changes to LAMMPS itself.
|
||||
|
||||
[Author:] Axel Kohlmeyer (Temple U).
|
||||
|
||||
[Install:]
|
||||
[Install:]
|
||||
|
||||
This package has "specific installation
|
||||
instructions"_Build_extras.html#gpu on the "Build
|
||||
@ -1843,7 +1809,7 @@ on your system.
|
||||
|
||||
[Author:] Albert Bartok (Cambridge University)
|
||||
|
||||
[Install:]
|
||||
[Install:]
|
||||
|
||||
This package has "specific installation
|
||||
instructions"_Build_extras.html#gpu on the "Build
|
||||
@ -1862,9 +1828,8 @@ USER-REAXC package :link(PKG-USER-REAXC),h4
|
||||
|
||||
[Contents:]
|
||||
|
||||
A pair style which implements the ReaxFF potential in C/C++ (in
|
||||
contrast to the "REAX package"_#PKG-REAX and its Fortran library). ReaxFF
|
||||
is universal reactive force field. See the src/USER-REAXC/README file
|
||||
A pair style which implements the ReaxFF potential in C/C++. ReaxFF
|
||||
is a universal reactive force field. See the src/USER-REAXC/README file
|
||||
for more info on differences between the two packages. Also two fixes
|
||||
for monitoring molecules as bonds are created and destroyed.
|
||||
|
||||
@ -1875,7 +1840,7 @@ for monitoring molecules as bonds are created and destroyed.
|
||||
src/USER-REAXC: filenames -> commands
|
||||
src/USER-REAXC/README
|
||||
"pair_style reax/c"_pair_reaxc.html
|
||||
"fix reax/c/bonds"_fix_reax_bonds.html
|
||||
"fix reax/c/bonds"_fix_reaxc_bonds.html
|
||||
"fix reax/c/species"_fix_reaxc_species.html
|
||||
examples/reax :ul
|
||||
|
||||
@ -1916,6 +1881,31 @@ examples/USER/scafacos :ul
|
||||
|
||||
:line
|
||||
|
||||
USER-SDPD package :link(PKG-USER-SDPD),h4
|
||||
|
||||
[Contents:]
|
||||
|
||||
A pair style for smoothed dissipative particle dynamics (SDPD), which
|
||||
is an extension of smoothed particle hydrodynamics (SPH) to mesoscale
|
||||
where thermal fluctuations are important (see the
|
||||
"USER-SPH package"_#PKG-USER-SPH).
|
||||
Also two fixes for moving and rigid body integration of SPH/SDPD particles
|
||||
(particles of atom_style meso).
|
||||
|
||||
[Author:] Morteza Jalalvand (Institute for Advanced Studies in Basic
|
||||
Sciences, Iran).
|
||||
|
||||
[Supporting info:]
|
||||
|
||||
src/USER-SDPD: filenames -> commands
|
||||
src/USER-SDPD/README
|
||||
"pair_style sdpd/taitwater/isothermal"_pair_sdpd_taitwater_isothermal.html
|
||||
"fix meso/move"_fix_meso_move.html
|
||||
"fix rigid/meso"_fix_rigid_meso.html
|
||||
examples/USER/sdpd :ul
|
||||
|
||||
:line
|
||||
|
||||
USER-SMD package :link(PKG-USER-SMD),h4
|
||||
|
||||
[Contents:]
|
||||
@ -1937,7 +1927,7 @@ specified as surface geometries from *.STL files.
|
||||
[Author:] Georg Ganzenmuller (Fraunhofer-Institute for High-Speed
|
||||
Dynamics, Ernst Mach Institute, Germany).
|
||||
|
||||
[Install:]
|
||||
[Install:]
|
||||
|
||||
This package has "specific installation
|
||||
instructions"_Build_extras.html#gpu on the "Build
|
||||
@ -2063,7 +2053,7 @@ system.
|
||||
|
||||
[Authors:] Richard Berger (JKU) and Daniel Queteschiner (DCS Computing).
|
||||
|
||||
[Install:]
|
||||
[Install:]
|
||||
|
||||
This package has "specific installation
|
||||
instructions"_Build_extras.html#gpu on the "Build
|
||||
|
||||
@ -46,7 +46,6 @@ Package, Description, Doc page, Example, Library
|
||||
"LATTE"_Packages_details.html#PKG-LATTE, quantum DFTB forces via LATTE, "fix latte"_fix_latte.html, latte, ext
|
||||
"MANYBODY"_Packages_details.html#PKG-MANYBODY, many-body potentials, "pair_style tersoff"_pair_tersoff.html, shear, no
|
||||
"MC"_Packages_details.html#PKG-MC, Monte Carlo options, "fix gcmc"_fix_gcmc.html, n/a, no
|
||||
"MEAM"_Packages_details.html#PKG-MEAM, modified EAM potential, "pair_style meam"_pair_meam.html, meam, int
|
||||
"MESSAGE"_Packages_details.html#PKG-MESSAGE, client/server messaging, "message"_message.html, message, int
|
||||
"MISC"_Packages_details.html#PKG-MISC, miscellaneous single-file commands, n/a, no, no
|
||||
"MOLECULE"_Packages_details.html#PKG-MOLECULE, molecular system force fields, "Howto bioFF"_Howto_bioFF.html, peptide, no
|
||||
@ -57,7 +56,6 @@ Package, Description, Doc page, Example, Library
|
||||
"POEMS"_Packages_details.html#PKG-POEMS, coupled rigid body motion, "fix poems"_fix_poems.html, rigid, int
|
||||
"PYTHON"_Packages_details.html#PKG-PYTHON, embed Python code in an input script, "python"_python.html, python, sys
|
||||
"QEQ"_Packages_details.html#PKG-QEQ, QEq charge equilibration, "fix qeq"_fix_qeq.html, qeq, no
|
||||
"REAX"_Packages_details.html#PKG-REAX, ReaxFF potential (Fortran), "pair_style reax"_pair_reax.html, reax, int
|
||||
"REPLICA"_Packages_details.html#PKG-REPLICA2, multi-replica methods, "Howto replica"_Howto_replica.html, tad, no
|
||||
"RIGID"_Packages_details.html#PKG-RIGID, rigid bodies and constraints, "fix rigid"_fix_rigid.html, rigid, no
|
||||
"SHOCK"_Packages_details.html#PKG-SHOCK, shock loading methods, "fix msst"_fix_msst.html, n/a, no
|
||||
|
||||
@ -38,8 +38,8 @@ int = internal library: provided with LAMMPS, but you may need to build it
|
||||
ext = external library: you will need to download and install it on your machine :ul
|
||||
|
||||
Package, Description, Doc page, Example, Library
|
||||
"USER-ATC"_Packages_details.html#PKG-USER-ATC, atom-to-continuum coupling, "fix atc"_fix_atc.html, USER/atc, int
|
||||
"USER-AWPMD"_Packages_details.html#PKG-USER-AWPMD, wave-packet MD, "pair_style awpmd/cut"_pair_awpmd.html, USER/awpmd, int
|
||||
"USER-ATC"_Packages_details.html#PKG-USER-ATC, Atom-to-Continuum coupling, "fix atc"_fix_atc.html, USER/atc, int
|
||||
"USER-AWPMD"_Packages_details.html#PKG-USER-AWPMD, wave packet MD, "pair_style awpmd/cut"_pair_awpmd.html, USER/awpmd, int
|
||||
"USER-BOCS"_Packages_details.html#PKG-USER-BOCS, BOCS bottom up coarse graining, "fix bocs"_fix_bocs.html, USER/bocs, no
|
||||
"USER-CGDNA"_Packages_details.html#PKG-USER-CGDNA, coarse-grained DNA force fields, src/USER-CGDNA/README, USER/cgdna, no
|
||||
"USER-CGSDK"_Packages_details.html#PKG-USER-CGSDK, SDK coarse-graining model, "pair_style lj/sdk"_pair_sdk.html, USER/cgsdk, no
|
||||
@ -53,7 +53,7 @@ Package, Description, Doc page, Example, Library
|
||||
"USER-INTEL"_Packages_details.html#PKG-USER-INTEL, optimized Intel CPU and KNL styles,"Speed intel"_Speed_intel.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, no
|
||||
"USER-LB"_Packages_details.html#PKG-USER-LB, Lattice Boltzmann fluid,"fix lb/fluid"_fix_lb_fluid.html, USER/lb, no
|
||||
"USER-MANIFOLD"_Packages_details.html#PKG-USER-MANIFOLD, motion on 2d surfaces,"fix manifoldforce"_fix_manifoldforce.html, USER/manifold, no
|
||||
"USER-MEAMC"_Packages_details.html#PKG-USER-MEAMC, modified EAM potential (C++), "pair_style meam/c"_pair_meam.html, meam, no
|
||||
"USER-MEAMC"_Packages_details.html#PKG-USER-MEAMC, modified EAM potential (C++), "pair_style meam/c"_pair_meamc.html, meamc, no
|
||||
"USER-MESO"_Packages_details.html#PKG-USER-MESO, mesoscale DPD models, "pair_style edpd"_pair_meso.html, USER/meso, no
|
||||
"USER-MGPT"_Packages_details.html#PKG-USER-MGPT, fast MGPT multi-ion potentials, "pair_style mgpt"_pair_mgpt.html, USER/mgpt, no
|
||||
"USER-MISC"_Packages_details.html#PKG-USER-MISC, single-file contributions, USER-MISC/README, USER/misc, no
|
||||
@ -62,16 +62,20 @@ Package, Description, Doc page, Example, Library
|
||||
"USER-NETCDF"_Packages_details.html#PKG-USER-NETCDF, dump output via NetCDF,"dump netcdf"_dump_netcdf.html, n/a, ext
|
||||
"USER-OMP"_Packages_details.html#PKG-USER-OMP, OpenMP-enabled styles,"Speed omp"_Speed_omp.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, no
|
||||
"USER-PHONON"_Packages_details.html#PKG-USER-PHONON, phonon dynamical matrix,"fix phonon"_fix_phonon.html, USER/phonon, no
|
||||
"USER-PLUMED"_Packages_details.html#PKG-USER-PLUMED, "PLUMED"_#PLUMED free energy library,"fix plumed"_fix_plumed.html, USER/plumed, ext
|
||||
"USER-PTM"_Packages_details.html#PKG-USER-PTM, Polyhedral Template Matching,"compute ptm/atom"_compute_ptm_atom.html, n/a, no
|
||||
"USER-QMMM"_Packages_details.html#PKG-USER-QMMM, QM/MM coupling,"fix qmmm"_fix_qmmm.html, USER/qmmm, ext
|
||||
"USER-QTB"_Packages_details.html#PKG-USER-QTB, quantum nuclear effects,"fix qtb"_fix_qtb.html "fix qbmsst"_fix_qbmsst.html, qtb, no
|
||||
"USER-QUIP"_Packages_details.html#PKG-USER-QUIP, QUIP/libatoms interface,"pair_style quip"_pair_quip.html, USER/quip, ext
|
||||
"USER-REAXC"_Packages_details.html#PKG-USER-REAXC, ReaxFF potential (C/C++) ,"pair_style reaxc"_pair_reaxc.html, reax, no
|
||||
"USER-SCAFACOS"_Packages_details.html#PKG-USER-SCAFACOS, wrapper on ScaFaCoS solver,"kspace_style scafacos"_kspace_style.html, USER/scafacos, ext
|
||||
"USER-SDPD"_Packages_details.html#PKG-USER-SDPD, smoothed dissipative particle dynamics,"pair_style sdpd/taitwater/isothermal"_pair_sdpd_taitwater_isothermal.html, USER/sdpd, no
|
||||
"USER-SMD"_Packages_details.html#PKG-USER-SMD, smoothed Mach dynamics,"SMD User Guide"_PDF/SMD_LAMMPS_userguide.pdf, USER/smd, ext
|
||||
"USER-SMTBQ"_Packages_details.html#PKG-USER-SMTBQ, second moment tight binding QEq potential,"pair_style smtbq"_pair_smtbq.html, USER/smtbq, no
|
||||
"USER-SPH"_Packages_details.html#PKG-USER-SPH, smoothed particle hydrodynamics,"SPH User Guide"_PDF/SPH_LAMMPS_userguide.pdf, USER/sph, no
|
||||
"USER-TALLY"_Packages_details.html#PKG-USER-TALLY, pairwise tally computes,"compute XXX/tally"_compute_tally.html, USER/tally, no
|
||||
"USER-UEF"_Packages_details.html#PKG-USER-UEF, extensional flow,"fix nvt/uef"_fix_nh_uef.html, USER/uef, no
|
||||
"USER-VTK"_Packages_details.html#PKG-USER-VTK, dump output via VTK, "compute vtk"_dump_vtk.html, n/a, ext :tb(ea=c,ca1=l)
|
||||
|
||||
:link(MOFplus,https://www.mofplus.org/content/show/MOF-FF)
|
||||
:link(PLUMED,http://www.plumed.org)
|
||||
|
||||
@ -79,7 +79,7 @@ of Python and your machine to successfully build LAMMPS. See the
|
||||
lib/python/README file for more info.
|
||||
|
||||
If you want to write Python code with callbacks to LAMMPS, then you
|
||||
must also follow the steps overviewed in the "Python
|
||||
must also follow the steps summarized in the "Python
|
||||
run"_Python_run.html doc page. I.e. you must build LAMMPS as a shared
|
||||
library and insure that Python can find the python/lammps.py file and
|
||||
the shared library.
|
||||
|
||||
@ -46,7 +46,7 @@ http://mt.seas.upenn.edu/Archive/Graphics/A3/A3.html :pre
|
||||
:link(atomeye,http://mt.seas.upenn.edu/Archive/Graphics/A)
|
||||
:link(atomeye3,http://mt.seas.upenn.edu/Archive/Graphics/A3/A3.html)
|
||||
|
||||
The latter link is to AtomEye 3 which has the scriping
|
||||
The latter link is to AtomEye 3 which has the scripting
|
||||
capability needed by these Python scripts.
|
||||
|
||||
Note that for PyMol, you need to have built and installed the
|
||||
|
||||
@ -354,29 +354,31 @@ the LAMMPS simulation domain.
|
||||
|
||||
:line
|
||||
|
||||
[-restart2data restartfile (remap) datafile keyword value ...] :link(restart2data)
|
||||
[-restart2data restartfile \[remap\] datafile keyword value ...]
|
||||
:link(restart2data)
|
||||
|
||||
Convert the restart file into a data file and immediately exit. This
|
||||
is the same operation as if the following 2-line input script were
|
||||
run:
|
||||
|
||||
read_restart restartfile (remap)
|
||||
read_restart restartfile \[remap\]
|
||||
write_data datafile keyword value ... :pre
|
||||
|
||||
Note that the specified restartfile and/or datafile can have the
|
||||
wild-card character "*". The restartfile can also have the wild-card
|
||||
The specified restartfile and/or datafile name may contain the wild-card
|
||||
character "*". The restartfile name may also contain the wild-card
|
||||
character "%". The meaning of these characters is explained on the
|
||||
"read_restart"_read_restart.html and "write_data"_write_data.html doc
|
||||
pages. The use of "%" means that a parallel restart file can be read.
|
||||
Note that a filename such as file.* will need to be enclosed in quotes
|
||||
to avoid shell expansion of the "*" character.
|
||||
Note that a filename such as file.* may need to be enclosed in quotes or
|
||||
the "*" character prefixed with a backslash ("\") to avoid shell
|
||||
expansion of the "*" character.
|
||||
|
||||
Note that following restartfile, the optional word "remap" can be
|
||||
used. This has the effect of adding it to the
|
||||
"read_restart"_read_restart.html command, as explained on its doc
|
||||
page. This is useful if reading the restart file triggers an error
|
||||
that atoms have been lost. In that case, use of the remap flag should
|
||||
allow the data file to still be produced.
|
||||
Following restartfile argument, the optional word "remap" may be used.
|
||||
This has the same effect like adding it to a
|
||||
"read_restart"_read_restart.html command, and operates as explained on
|
||||
its doc page. This is useful if reading the restart file triggers an
|
||||
error that atoms have been lost. In that case, use of the remap flag
|
||||
should allow the data file to still be produced.
|
||||
|
||||
The syntax following restartfile (or remap), namely
|
||||
|
||||
@ -388,29 +390,30 @@ optional keyword/value settings.
|
||||
|
||||
:line
|
||||
|
||||
[-restart2dump restartfile {remap} group-ID dumpstyle dumpfile arg1 arg2 ...] :link(restart2dump)
|
||||
[-restart2dump restartfile \[remap\] group-ID dumpstyle dumpfile arg1 arg2 ...] :link(restart2dump)
|
||||
|
||||
Convert the restart file into a dump file and immediately exit. This
|
||||
is the same operation as if the following 2-line input script were
|
||||
run:
|
||||
|
||||
read_restart restartfile (remap)
|
||||
read_restart restartfile \[remap\]
|
||||
write_dump group-ID dumpstyle dumpfile arg1 arg2 ... :pre
|
||||
|
||||
Note that the specified restartfile and dumpfile can have wild-card
|
||||
characters ("*","%") as explained on the
|
||||
Note that the specified restartfile and dumpfile names may contain
|
||||
wild-card characters ("*","%") as explained on the
|
||||
"read_restart"_read_restart.html and "write_dump"_write_dump.html doc
|
||||
pages. The use of "%" means that a parallel restart file and/or
|
||||
parallel dump file can be read and/or written. Note that a filename
|
||||
such as file.* will need to be enclosed in quotes to avoid shell
|
||||
expansion of the "*" character.
|
||||
such as file.* may need to be enclosed in quotes or the "*" character
|
||||
prefixed with a backslash ("\") to avoid shell expansion of the "*"
|
||||
character.
|
||||
|
||||
Note that following restartfile, the optional word "remap" can be
|
||||
used. This has the effect as adding it to the
|
||||
"read_restart"_read_restart.html command, as explained on its doc
|
||||
page. This is useful if reading the restart file triggers an error
|
||||
that atoms have been lost. In that case, use of the remap flag should
|
||||
allow the dump file to still be produced.
|
||||
Note that following the restartfile argument, the optional word "remap"
|
||||
can be used. This has the effect as adding it to the
|
||||
"read_restart"_read_restart.html command, as explained on its doc page.
|
||||
This is useful if reading the restart file triggers an error that atoms
|
||||
have been lost. In that case, use of the remap flag should allow the
|
||||
dump file to still be produced.
|
||||
|
||||
The syntax following restartfile (or remap), namely
|
||||
|
||||
@ -524,7 +527,7 @@ option is equivalent to putting the line "variable name index value1
|
||||
value2 ..." at the beginning of the input script. Defining an index
|
||||
variable as a command-line argument overrides any setting for the same
|
||||
index variable in the input script, since index variables cannot be
|
||||
re-defined.
|
||||
re-defined.
|
||||
|
||||
See the "variable"_variable.html command for more info on defining
|
||||
index and other kinds of variables and the "Commands
|
||||
|
||||
@ -41,7 +41,7 @@ path for the default location of this MPI package. After the
|
||||
installation of the MPICH2 software, it needs to be integrated into
|
||||
the system. For this you need to start a Command Prompt in
|
||||
{Administrator Mode} (right click on the icon and select it). Change
|
||||
into the MPICH2 installation directory, then into the subdirectory
|
||||
into the MPICH2 installation directory, then into the sub-directory
|
||||
[bin] and execute [smpd.exe -install]. Exit the command window.
|
||||
|
||||
Get a new, regular command prompt by going to Start->Run... ,
|
||||
|
||||
@ -19,7 +19,7 @@ using code options that implement alternate algorithms that can
|
||||
speed-up a simulation. The second is to use one of the several
|
||||
accelerator packages provided with LAMMPS that contain code optimized
|
||||
for certain kinds of hardware, including multi-core CPUs, GPUs, and
|
||||
Intel Xeon Phi coprocessors.
|
||||
Intel Xeon Phi co-processors.
|
||||
|
||||
The "Benchmark page"_http://lammps.sandia.gov/bench.html of the LAMMPS
|
||||
web site gives performance results for the various accelerator
|
||||
|
||||
@ -14,11 +14,11 @@ Corporation. It provides two methods for accelerating simulations,
|
||||
depending on the hardware you have. The first is acceleration on
|
||||
Intel CPUs by running in single, mixed, or double precision with
|
||||
vectorization. The second is acceleration on Intel Xeon Phi
|
||||
coprocessors via offloading neighbor list and non-bonded force
|
||||
co-processors via offloading neighbor list and non-bonded force
|
||||
calculations to the Phi. The same C++ code is used in both cases.
|
||||
When offloading to a coprocessor from a CPU, the same routine is run
|
||||
When offloading to a co-processor from a CPU, the same routine is run
|
||||
twice, once on the CPU and once with an offload flag. This allows
|
||||
LAMMPS to run on the CPU cores and coprocessor cores simultaneously.
|
||||
LAMMPS to run on the CPU cores and co-processor cores simultaneously.
|
||||
|
||||
[Currently Available USER-INTEL Styles:]
|
||||
|
||||
@ -27,9 +27,9 @@ Bond Styles: fene, fourier, harmonic :l
|
||||
Dihedral Styles: charmm, harmonic, opls :l
|
||||
Fixes: nve, npt, nvt, nvt/sllod, nve/asphere :l
|
||||
Improper Styles: cvff, harmonic :l
|
||||
Pair Styles: airebo, airebo/morse, buck/coul/cut, buck/coul/long,
|
||||
buck, dpd, eam, eam/alloy, eam/fs, gayberne, lj/charmm/coul/charmm,
|
||||
lj/charmm/coul/long, lj/cut, lj/cut/coul/long, lj/long/coul/long,
|
||||
Pair Styles: airebo, airebo/morse, buck/coul/cut, buck/coul/long,
|
||||
buck, dpd, eam, eam/alloy, eam/fs, gayberne, lj/charmm/coul/charmm,
|
||||
lj/charmm/coul/long, lj/cut, lj/cut/coul/long, lj/long/coul/long,
|
||||
rebo, sw, tersoff :l
|
||||
K-Space Styles: pppm, pppm/disp :l
|
||||
:ule
|
||||
@ -47,7 +47,7 @@ These are scalable in size; the results given are with 512K
|
||||
particles (524K for Liquid Crystal). Most of the simulations are
|
||||
standard LAMMPS benchmarks (indicated by the filename extension in
|
||||
parenthesis) with modifications to the run length and to add a
|
||||
warmup run (for use with offload benchmarks).
|
||||
warm-up run (for use with offload benchmarks).
|
||||
|
||||
:c,image(JPG/user_intel.png)
|
||||
|
||||
@ -134,19 +134,19 @@ Do not use thread affinity (set KMP_AFFINITY=none) :l
|
||||
The "newton off" setting may provide better scalability :l
|
||||
:ule
|
||||
|
||||
For Intel Xeon Phi coprocessors (Offload):
|
||||
For Intel Xeon Phi co-processors (Offload):
|
||||
|
||||
Edit src/MAKE/OPTIONS/Makefile.intel_coprocessor as necessary :ulb,l
|
||||
Edit src/MAKE/OPTIONS/Makefile.intel_co-processor as necessary :ulb,l
|
||||
"-pk intel N omp 1" added to command-line where N is the number of
|
||||
coprocessors per node. :l
|
||||
co-processors per node. :l
|
||||
:ule
|
||||
|
||||
:line
|
||||
|
||||
[Required hardware/software:]
|
||||
|
||||
In order to use offload to coprocessors, an Intel Xeon Phi
|
||||
coprocessor and an Intel compiler are required. For this, the
|
||||
In order to use offload to co-processors, an Intel Xeon Phi
|
||||
co-processor and an Intel compiler are required. For this, the
|
||||
recommended version of the Intel compiler is 14.0.1.106 or
|
||||
versions 15.0.2.044 and higher.
|
||||
|
||||
@ -214,7 +214,7 @@ Makefile.intel_cpu_intelmpi # Intel Compiler, Intel MPI, No Offload
|
||||
Makefile.knl # Intel Compiler, Intel MPI, No Offload
|
||||
Makefile.intel_cpu_mpich # Intel Compiler, MPICH, No Offload
|
||||
Makefile.intel_cpu_openpmi # Intel Compiler, OpenMPI, No Offload
|
||||
Makefile.intel_coprocessor # Intel Compiler, Intel MPI, Offload :pre
|
||||
Makefile.intel_co-processor # Intel Compiler, Intel MPI, Offload :pre
|
||||
|
||||
Makefile.knl is identical to Makefile.intel_cpu_intelmpi except that
|
||||
it explicitly specifies that vectorization should be for Intel Xeon
|
||||
@ -227,18 +227,18 @@ source /opt/intel/parallel_studio_xe_2016.3.067/psxevars.sh
|
||||
# or psxevars.csh for C-shell
|
||||
make intel_cpu_intelmpi :pre
|
||||
|
||||
Note that if you build with support for a Phi coprocessor, the same
|
||||
binary can be used on nodes with or without coprocessors installed.
|
||||
However, if you do not have coprocessors on your system, building
|
||||
Note that if you build with support for a Phi co-processor, the same
|
||||
binary can be used on nodes with or without co-processors installed.
|
||||
However, if you do not have co-processors on your system, building
|
||||
without offload support will produce a smaller binary.
|
||||
|
||||
The general requirements for Makefiles with the USER-INTEL package
|
||||
are as follows. When using Intel compilers, "-restrict" is required
|
||||
and "-qopenmp" is highly recommended for CCFLAGS and LINKFLAGS.
|
||||
are as follows. When using Intel compilers, "-restrict" is required
|
||||
and "-qopenmp" is highly recommended for CCFLAGS and LINKFLAGS.
|
||||
CCFLAGS should include "-DLMP_INTEL_USELRT" (unless POSIX Threads
|
||||
are not supported in the build environment) and "-DLMP_USE_MKL_RNG"
|
||||
(unless Intel Math Kernel Library (MKL) is not available in the build
|
||||
environment). For Intel compilers, LIB should include "-ltbbmalloc"
|
||||
environment). For Intel compilers, LIB should include "-ltbbmalloc"
|
||||
or if the library is not available, "-DLMP_INTEL_NO_TBB" can be added
|
||||
to CCFLAGS. For builds supporting offload, "-DLMP_INTEL_OFFLOAD" is
|
||||
required for CCFLAGS and "-qoffload" is required for LINKFLAGS. Other
|
||||
@ -272,7 +272,7 @@ Advanced performance tuning options are also described below to get
|
||||
the best performance.
|
||||
|
||||
When running on a single node (including runs using offload to a
|
||||
coprocessor), best performance is normally obtained by using 1 MPI
|
||||
co-processor), best performance is normally obtained by using 1 MPI
|
||||
task per physical core and additional OpenMP threads with SMT. For
|
||||
Intel Xeon processors, 2 OpenMP threads should be used for SMT.
|
||||
For Intel Xeon Phi CPUs, 2 or 4 OpenMP threads should be used
|
||||
@ -290,7 +290,7 @@ NOTE: Setting core affinity is often used to pin MPI tasks and OpenMP
|
||||
threads to a core or group of cores so that memory access can be
|
||||
uniform. Unless disabled at build time, affinity for MPI tasks and
|
||||
OpenMP threads on the host (CPU) will be set by default on the host
|
||||
{when using offload to a coprocessor}. In this case, it is unnecessary
|
||||
{when using offload to a co-processor}. In this case, it is unnecessary
|
||||
to use other methods to control affinity (e.g. taskset, numactl,
|
||||
I_MPI_PIN_DOMAIN, etc.). This can be disabled with the {no_affinity}
|
||||
option to the "package intel"_package.html command or by disabling the
|
||||
@ -310,15 +310,15 @@ editing the input script. This switch will automatically append
|
||||
options for the USER-INTEL package. The default package command will
|
||||
specify that USER-INTEL calculations are performed in mixed precision,
|
||||
that the number of OpenMP threads is specified by the OMP_NUM_THREADS
|
||||
environment variable, and that if coprocessors are present and the
|
||||
binary was built with offload support, that 1 coprocessor per node
|
||||
environment variable, and that if co-processors are present and the
|
||||
binary was built with offload support, that 1 co-processor per node
|
||||
will be used with automatic balancing of work between the CPU and the
|
||||
coprocessor.
|
||||
co-processor.
|
||||
|
||||
You can specify different options for the USER-INTEL package by using
|
||||
the "-pk intel Nphi" "command-line switch"_Run_options.html with
|
||||
keyword/value pairs as specified in the documentation. Here, Nphi = #
|
||||
of Xeon Phi coprocessors/node (ignored without offload
|
||||
of Xeon Phi co-processors/node (ignored without offload
|
||||
support). Common options to the USER-INTEL package include {omp} to
|
||||
override any OMP_NUM_THREADS setting and specify the number of OpenMP
|
||||
threads, {mode} to set the floating-point precision mode, and {lrt} to
|
||||
@ -332,7 +332,7 @@ Examples (see documentation for your MPI/Machine for differences in
|
||||
launching MPI applications):
|
||||
|
||||
mpirun -np 72 -ppn 36 lmp_machine -sf intel -in in.script # 2 nodes, 36 MPI tasks/node, $OMP_NUM_THREADS OpenMP Threads
|
||||
mpirun -np 72 -ppn 36 lmp_machine -sf intel -in in.script -pk intel 0 omp 2 mode double # Don't use any coprocessors that might be available, use 2 OpenMP threads for each task, use double precision :pre
|
||||
mpirun -np 72 -ppn 36 lmp_machine -sf intel -in in.script -pk intel 0 omp 2 mode double # Don't use any co-processors that might be available, use 2 OpenMP threads for each task, use double precision :pre
|
||||
|
||||
[Or run with the USER-INTEL package by editing an input script:]
|
||||
|
||||
@ -364,7 +364,7 @@ intel"_package.html command that can improve performance when using
|
||||
"PPPM"_kspace_style.html for long-range electrostatics on processors
|
||||
with SMT. It generates an extra pthread for each MPI task. The thread
|
||||
is dedicated to performing some of the PPPM calculations and MPI
|
||||
communications. This feature requires setting the preprocessor flag
|
||||
communications. This feature requires setting the pre-processor flag
|
||||
-DLMP_INTEL_USELRT in the makefile when compiling LAMMPS. It is unset
|
||||
in the default makefiles ({Makefile.mpi} and {Makefile.serial}) but
|
||||
it is set in all makefiles tuned for the USER-INTEL package. On Intel
|
||||
@ -399,7 +399,7 @@ the "suffix hybrid intel omp"_suffix.html command can also be used
|
||||
within the input script to automatically append the "omp" suffix to
|
||||
styles when USER-INTEL styles are not available.
|
||||
|
||||
NOTE: For simulations on higher node counts, add "processors * * *
|
||||
NOTE: For simulations on higher node counts, add "processors * * *
|
||||
grid numa"_processors.html to the beginning of the input script for
|
||||
better scalability.
|
||||
|
||||
@ -422,29 +422,29 @@ that MPI runs are performed in MCDRAM.
|
||||
|
||||
The default settings for offload should give good performance.
|
||||
|
||||
When using LAMMPS with offload to Intel coprocessors, best performance
|
||||
When using LAMMPS with offload to Intel co-processors, best performance
|
||||
will typically be achieved with concurrent calculations performed on
|
||||
both the CPU and the coprocessor. This is achieved by offloading only
|
||||
a fraction of the neighbor and pair computations to the coprocessor or
|
||||
both the CPU and the co-processor. This is achieved by offloading only
|
||||
a fraction of the neighbor and pair computations to the co-processor or
|
||||
using "hybrid"_pair_hybrid.html pair styles where only one style uses
|
||||
the "intel" suffix. For simulations with long-range electrostatics or
|
||||
bond, angle, dihedral, improper calculations, computation and data
|
||||
transfer to the coprocessor will run concurrently with computations
|
||||
transfer to the co-processor will run concurrently with computations
|
||||
and MPI communications for these calculations on the host CPU. This
|
||||
is illustrated in the figure below for the rhodopsin protein benchmark
|
||||
running on E5-2697v2 processors with a Intel Xeon Phi 7120p
|
||||
coprocessor. In this plot, the vertical access is time and routines
|
||||
co-processor. In this plot, the vertical access is time and routines
|
||||
running at the same time are running concurrently on both the host and
|
||||
the coprocessor.
|
||||
the co-processor.
|
||||
|
||||
:c,image(JPG/offload_knc.png)
|
||||
|
||||
The fraction of the offloaded work is controlled by the {balance}
|
||||
keyword in the "package intel"_package.html command. A balance of 0
|
||||
runs all calculations on the CPU. A balance of 1 runs all
|
||||
supported calculations on the coprocessor. A balance of 0.5 runs half
|
||||
of the calculations on the coprocessor. Setting the balance to -1
|
||||
(the default) will enable dynamic load balancing that continously
|
||||
supported calculations on the co-processor. A balance of 0.5 runs half
|
||||
of the calculations on the co-processor. Setting the balance to -1
|
||||
(the default) will enable dynamic load balancing that continuously
|
||||
adjusts the fraction of offloaded work throughout the simulation.
|
||||
Because data transfer cannot be timed, this option typically produces
|
||||
results within 5 to 10 percent of the optimal fixed balance.
|
||||
@ -455,23 +455,23 @@ near-optimal setting that will carry over to additional runs.
|
||||
|
||||
The default for the "package intel"_package.html command is to have
|
||||
all the MPI tasks on a given compute node use a single Xeon Phi
|
||||
coprocessor. In general, running with a large number of MPI tasks on
|
||||
co-processor. In general, running with a large number of MPI tasks on
|
||||
each node will perform best with offload. Each MPI task will
|
||||
automatically get affinity to a subset of the hardware threads
|
||||
available on the coprocessor. For example, if your card has 61 cores,
|
||||
available on the co-processor. For example, if your card has 61 cores,
|
||||
with 60 cores available for offload and 4 hardware threads per core
|
||||
(240 total threads), running with 24 MPI tasks per node will cause
|
||||
each MPI task to use a subset of 10 threads on the coprocessor. Fine
|
||||
each MPI task to use a subset of 10 threads on the co-processor. Fine
|
||||
tuning of the number of threads to use per MPI task or the number of
|
||||
threads to use per core can be accomplished with keyword settings of
|
||||
the "package intel"_package.html command.
|
||||
|
||||
The USER-INTEL package has two modes for deciding which atoms will be
|
||||
handled by the coprocessor. This choice is controlled with the {ghost}
|
||||
handled by the co-processor. This choice is controlled with the {ghost}
|
||||
keyword of the "package intel"_package.html command. When set to 0,
|
||||
ghost atoms (atoms at the borders between MPI tasks) are not offloaded
|
||||
to the card. This allows for overlap of MPI communication of forces
|
||||
with computation on the coprocessor when the "newton"_newton.html
|
||||
with computation on the co-processor when the "newton"_newton.html
|
||||
setting is "on". The default is dependent on the style being used,
|
||||
however, better performance may be achieved by setting this option
|
||||
explicitly.
|
||||
@ -482,21 +482,21 @@ cores. This is due to the fact that additional threads are generated
|
||||
internally to handle the asynchronous offload tasks.
|
||||
|
||||
If pair computations are being offloaded to an Intel Xeon Phi
|
||||
coprocessor, a diagnostic line is printed to the screen (not to the
|
||||
co-processor, a diagnostic line is printed to the screen (not to the
|
||||
log file), during the setup phase of a run, indicating that offload
|
||||
mode is being used and indicating the number of coprocessor threads
|
||||
mode is being used and indicating the number of co-processor threads
|
||||
per MPI task. Additionally, an offload timing summary is printed at
|
||||
the end of each run. When offloading, the frequency for "atom
|
||||
sorting"_atom_modify.html is changed to 1 so that the per-atom data is
|
||||
effectively sorted at every rebuild of the neighbor lists. All the
|
||||
available coprocessor threads on each Phi will be divided among MPI
|
||||
available co-processor threads on each Phi will be divided among MPI
|
||||
tasks, unless the {tptask} option of the "-pk intel" "command-line
|
||||
switch"_Run_options.html is used to limit the coprocessor threads per
|
||||
switch"_Run_options.html is used to limit the co-processor threads per
|
||||
MPI task.
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
When offloading to a coprocessor, "hybrid"_pair_hybrid.html styles
|
||||
When offloading to a co-processor, "hybrid"_pair_hybrid.html styles
|
||||
that require skip lists for neighbor builds cannot be offloaded.
|
||||
Using "hybrid/overlay"_pair_hybrid.html is allowed. Only one intel
|
||||
accelerated style may be used with hybrid styles when offloading.
|
||||
@ -510,7 +510,7 @@ supported.
|
||||
|
||||
[References:]
|
||||
|
||||
Brown, W.M., Carrillo, J.-M.Y., Mishra, B., Gavhane, N., Thakker, F.M., De Kraker, A.R., Yamada, M., Ang, J.A., Plimpton, S.J., "Optimizing Classical Molecular Dynamics in LAMMPS," in Intel Xeon Phi Processor High Performance Programming: Knights Landing Edition, J. Jeffers, J. Reinders, A. Sodani, Eds. Morgan Kaufmann. :ulb,l
|
||||
Brown, W.M., Carrillo, J.-M.Y., Mishra, B., Gavhane, N., Thakkar, F.M., De Kraker, A.R., Yamada, M., Ang, J.A., Plimpton, S.J., "Optimizing Classical Molecular Dynamics in LAMMPS," in Intel Xeon Phi Processor High Performance Programming: Knights Landing Edition, J. Jeffers, J. Reinders, A. Sodani, Eds. Morgan Kaufmann. :ulb,l
|
||||
|
||||
Brown, W. M., Semin, A., Hebenstreit, M., Khvostov, S., Raman, K., Plimpton, S.J. "Increasing Molecular Dynamics Simulation Rates with an 8-Fold Increase in Electrical Power Efficiency."_http://dl.acm.org/citation.cfm?id=3014915 2016 High Performance Computing, Networking, Storage and Analysis, SC16: International Conference (pp. 82-95). :l
|
||||
|
||||
|
||||
@ -13,11 +13,11 @@ Kokkos is a templated C++ library that provides abstractions to allow
|
||||
a single implementation of an application kernel (e.g. a pair style)
|
||||
to run efficiently on different kinds of hardware, such as GPUs, Intel
|
||||
Xeon Phis, or many-core CPUs. Kokkos maps the C++ kernel onto
|
||||
different backend languages such as CUDA, OpenMP, or Pthreads. The
|
||||
different back end languages such as CUDA, OpenMP, or Pthreads. The
|
||||
Kokkos library also provides data abstractions to adjust (at compile
|
||||
time) the memory layout of data structures like 2d and 3d arrays to
|
||||
optimize performance on different hardware. For more information on
|
||||
Kokkos, see "Github"_https://github.com/kokkos/kokkos. Kokkos is part
|
||||
Kokkos, see "GitHub"_https://github.com/kokkos/kokkos. Kokkos is part
|
||||
of "Trilinos"_http://trilinos.sandia.gov/packages/kokkos. The Kokkos
|
||||
library was written primarily by Carter Edwards, Christian Trott, and
|
||||
Dan Sunderland (all Sandia).
|
||||
@ -106,10 +106,10 @@ modification to the input script is needed. Alternatively, one can run
|
||||
with the KOKKOS package by editing the input script as described
|
||||
below.
|
||||
|
||||
NOTE: When using a single OpenMP thread, the Kokkos Serial backend (i.e.
|
||||
Makefile.kokkos_mpi_only) will give better performance than the OpenMP
|
||||
backend (i.e. Makefile.kokkos_omp) because some of the overhead to make
|
||||
the code thread-safe is removed.
|
||||
NOTE: When using a single OpenMP thread, the Kokkos Serial back end (i.e.
|
||||
Makefile.kokkos_mpi_only) will give better performance than the OpenMP
|
||||
back end (i.e. Makefile.kokkos_omp) because some of the overhead to make
|
||||
the code thread-safe is removed.
|
||||
|
||||
NOTE: The default for the "package kokkos"_package.html command is to
|
||||
use "full" neighbor lists and set the Newton flag to "off" for both
|
||||
@ -127,21 +127,21 @@ mpirun -np 16 lmp_kokkos_mpi_only -k on -sf kk -pk kokkos newton on neigh half c
|
||||
If the "newton"_newton.html command is used in the input
|
||||
script, it can also override the Newton flag defaults.
|
||||
|
||||
For half neighbor lists and OpenMP, the KOKKOS package uses data
|
||||
duplication (i.e. thread-private arrays) by default to avoid
|
||||
thread-level write conflicts in the force arrays (and other data
|
||||
structures as necessary). Data duplication is typically fastest for
|
||||
small numbers of threads (i.e. 8 or less) but does increase memory
|
||||
footprint and is not scalable to large numbers of threads. An
|
||||
alternative to data duplication is to use thread-level atomics, which
|
||||
don't require duplication. The use of atomics can be forced by compiling
|
||||
with the "-DLMP_KOKKOS_USE_ATOMICS" compile switch. Most but not all
|
||||
Kokkos-enabled pair_styles support data duplication. Alternatively, full
|
||||
neighbor lists avoid the need for duplication or atomics but require
|
||||
more compute operations per atom. When using the Kokkos Serial backend
|
||||
or the OpenMP backend with a single thread, no duplication or atomics are
|
||||
used. For CUDA and half neighbor lists, the KOKKOS package always uses
|
||||
atomics.
|
||||
For half neighbor lists and OpenMP, the KOKKOS package uses data
|
||||
duplication (i.e. thread-private arrays) by default to avoid
|
||||
thread-level write conflicts in the force arrays (and other data
|
||||
structures as necessary). Data duplication is typically fastest for
|
||||
small numbers of threads (i.e. 8 or less) but does increase memory
|
||||
footprint and is not scalable to large numbers of threads. An
|
||||
alternative to data duplication is to use thread-level atomic operations
|
||||
which do not require data duplication. The use of atomic operations can
|
||||
be enforced by compiling LAMMPS with the "-DLMP_KOKKOS_USE_ATOMICS"
|
||||
pre-processor flag. Most but not all Kokkos-enabled pair_styles support
|
||||
data duplication. Alternatively, full neighbor lists avoid the need for
|
||||
duplication or atomic operations but require more compute operations per
|
||||
atom. When using the Kokkos Serial back end or the OpenMP back end with
|
||||
a single thread, no duplication or atomic operations are used. For CUDA
|
||||
and half neighbor lists, the KOKKOS package always uses atomic operations.
|
||||
|
||||
[Core and Thread Affinity:]
|
||||
|
||||
@ -193,7 +193,7 @@ threads/task as Nt. The product of these two values should be N, i.e.
|
||||
NOTE: The default for the "package kokkos"_package.html command is to
|
||||
use "full" neighbor lists and set the Newton flag to "off" for both
|
||||
pairwise and bonded interactions. When running on KNL, this will
|
||||
typically be best for pair-wise potentials. For manybody potentials,
|
||||
typically be best for pair-wise potentials. For many-body potentials,
|
||||
using "half" neighbor lists and setting the Newton flag to "on" may be
|
||||
faster. It can also be faster to use non-threaded communication. Use
|
||||
the "-pk kokkos" "command-line switch"_Run_options.html to change the
|
||||
@ -207,7 +207,7 @@ mpirun -np 64 lmp_kokkos_phi -k on t 4 -sf kk -pk kokkos newton on neigh half co
|
||||
NOTE: MPI tasks and threads should be bound to cores as described
|
||||
above for CPUs.
|
||||
|
||||
NOTE: To build with Kokkos support for Intel Xeon Phi coprocessors
|
||||
NOTE: To build with Kokkos support for Intel Xeon Phi co-processors
|
||||
such as Knight's Corner (KNC), your system must be configured to use
|
||||
them in "native" mode, not "offload" mode like the USER-INTEL package
|
||||
supports.
|
||||
|
||||
@ -131,7 +131,7 @@ effect worsens when using an increasing number of nodes. :l
|
||||
The system has a spatially inhomogeneous particle density which does
|
||||
not map well to the "domain decomposition scheme"_processors.html or
|
||||
"load-balancing"_balance.html options that LAMMPS provides. This is
|
||||
because multi-threading achives parallelism over the number of
|
||||
because multi-threading achieves parallelism over the number of
|
||||
particles, not via their distribution in space. :l
|
||||
|
||||
A machine is being used in "capability mode", i.e. near the point
|
||||
@ -143,7 +143,7 @@ the performance-limiting factor. Using multi-threading allows less
|
||||
MPI tasks to be invoked and can speed-up the long-range solver, while
|
||||
increasing overall performance by parallelizing the pairwise and
|
||||
bonded calculations via OpenMP. Likewise additional speedup can be
|
||||
sometimes be achived by increasing the length of the Coulombic cutoff
|
||||
sometimes be achieved by increasing the length of the Coulombic cutoff
|
||||
and thus reducing the work done by the long-range solver. Using the
|
||||
"run_style verlet/split"_run_style.html command, which is compatible
|
||||
with the USER-OMP package, is an alternative way to reduce the number
|
||||
|
||||
@ -14,7 +14,7 @@ Accelerated versions of various "pair_style"_pair_style.html,
|
||||
been added to LAMMPS, which will typically run faster than the
|
||||
standard non-accelerated versions. Some require appropriate hardware
|
||||
to be present on your system, e.g. GPUs or Intel Xeon Phi
|
||||
coprocessors.
|
||||
co-processors.
|
||||
|
||||
All of these commands are in packages provided with LAMMPS. An
|
||||
overview of packages is give on the "Packages"_Packages.html doc
|
||||
@ -161,7 +161,7 @@ package. These styles support vectorized single and mixed precision
|
||||
calculations, in addition to full double precision. In extreme cases,
|
||||
this can provide speedups over 3.5x on CPUs. The package also
|
||||
supports acceleration in "offload" mode to Intel(R) Xeon Phi(TM)
|
||||
coprocessors. This can result in additional speedup over 2x depending
|
||||
co-processors. This can result in additional speedup over 2x depending
|
||||
on the hardware configuration. :l
|
||||
|
||||
Styles with a "kk" suffix are part of the KOKKOS package, and can be
|
||||
|
||||
@ -163,7 +163,7 @@ for the "chain benchmark"_Speed_bench.html.
|
||||
|
||||
colvars tools :h4,link(colvars)
|
||||
|
||||
The colvars directory contains a collection of tools for postprocessing
|
||||
The colvars directory contains a collection of tools for post-processing
|
||||
data produced by the colvars collective variable library.
|
||||
To compile the tools, edit the makefile for your system and run "make".
|
||||
|
||||
@ -263,7 +263,7 @@ These tools were provided by Andres Jaramillo-Botero at CalTech
|
||||
|
||||
emacs tool :h4,link(emacs)
|
||||
|
||||
The tools/emacs directory contains an Emacs Lisp add-on file for GNU Emacs
|
||||
The tools/emacs directory contains an Emacs Lisp add-on file for GNU Emacs
|
||||
that enables a lammps-mode for editing input scripts when using GNU Emacs,
|
||||
with various highlighting options set up.
|
||||
|
||||
@ -406,15 +406,15 @@ supports it. It has its own WWW page at
|
||||
msi2lmp tool :h4,link(msi)
|
||||
|
||||
The msi2lmp sub-directory contains a tool for creating LAMMPS template
|
||||
input and data files from BIOVIA's Materias Studio files (formerly Accelrys'
|
||||
Insight MD code, formerly MSI/Biosym and its Discover MD code).
|
||||
input and data files from BIOVIA's Materias Studio files (formerly
|
||||
Accelrys' Insight MD code, formerly MSI/Biosym and its Discover MD code).
|
||||
|
||||
This tool was written by John Carpenter (Cray), Michael Peachey
|
||||
(Cray), and Steve Lustig (Dupont). Several people contributed changes
|
||||
to remove bugs and adapt its output to changes in LAMMPS.
|
||||
|
||||
This tool has several known limitations and is no longer under active
|
||||
development, so there are no changes except for the occasional bugfix.
|
||||
development, so there are no changes except for the occasional bug fix.
|
||||
|
||||
See the README file in the tools/msi2lmp folder for more information.
|
||||
|
||||
@ -485,9 +485,9 @@ README for more info on Pizza.py and how to use these scripts.
|
||||
|
||||
reax tool :h4,link(reax_tool)
|
||||
|
||||
The reax sub-directory contains stand-alond codes that can
|
||||
post-process the output of the "fix reax/bonds"_fix_reax_bonds.html
|
||||
command from a LAMMPS simulation using "ReaxFF"_pair_reax.html. See
|
||||
The reax sub-directory contains stand-alone codes that can
|
||||
post-process the output of the "fix reax/c/bonds"_fix_reaxc_bonds.html
|
||||
command from a LAMMPS simulation using "ReaxFF"_pair_reaxc.html. See
|
||||
the README.txt file for more info.
|
||||
|
||||
These tools were written by Aidan Thompson at Sandia.
|
||||
|
||||
@ -60,26 +60,14 @@ doc page for details.
|
||||
|
||||
:line
|
||||
|
||||
Here is an alphabetic list of angle styles defined in LAMMPS. Click on
|
||||
the style to display the formula it computes and coefficients
|
||||
specified by the associated "angle_coeff"_angle_coeff.html command.
|
||||
|
||||
Note that there are also additional angle styles submitted by users
|
||||
which are included in the LAMMPS distribution. The full list of all
|
||||
angle styles is on the "Commands bond"_Commands_bond.html#angle doc
|
||||
The list of all angle styles defined in LAMMPS is given on the
|
||||
"angle_style"_angle_style.html doc page. They are also listed in more
|
||||
compact form on the "Commands angle"_Commands_bond.html#angle doc
|
||||
page.
|
||||
|
||||
"angle_style none"_angle_none.html - turn off angle interactions
|
||||
"angle_style hybrid"_angle_hybrid.html - define multiple styles of angle interactions :ul
|
||||
|
||||
"angle_style charmm"_angle_charmm.html - CHARMM angle
|
||||
"angle_style class2"_angle_class2.html - COMPASS (class 2) angle
|
||||
"angle_style cosine"_angle_cosine.html - cosine angle potential
|
||||
"angle_style cosine/delta"_angle_cosine_delta.html - difference of cosines angle potential
|
||||
"angle_style cosine/periodic"_angle_cosine_periodic.html - DREIDING angle
|
||||
"angle_style cosine/squared"_angle_cosine_squared.html - cosine squared angle potential
|
||||
"angle_style harmonic"_angle_harmonic.html - harmonic angle
|
||||
"angle_style table"_angle_table.html - tabulated by angle :ul
|
||||
On either of those pages, click on the style to display the formula it
|
||||
computes and its coefficients as specified by the associated
|
||||
angle_coeff command.
|
||||
|
||||
:line
|
||||
|
||||
|
||||
@ -23,19 +23,19 @@ The {cosine/buck6d} angle style uses the potential
|
||||
|
||||
:c,image(Eqs/angle_cosine_buck6d.jpg)
|
||||
|
||||
where K is the energy constant, n is the periodic multiplicity and
|
||||
where K is the energy constant, n is the periodic multiplicity and
|
||||
Theta0 is the equilibrium angle.
|
||||
|
||||
The coefficients must be defined for each angle type via the
|
||||
The coefficients must be defined for each angle type via the
|
||||
"angle_coeff"_angle_coeff.html command as in the example above, or in
|
||||
the data file or restart files read by the "read_data"_read_data.html
|
||||
or "read_restart"_read_restart.html commands in the following order:
|
||||
|
||||
K (energy)
|
||||
n
|
||||
n
|
||||
Theta0 (degrees) :ul
|
||||
|
||||
Theta0 is specified in degrees, but LAMMPS converts it to radians
|
||||
Theta0 is specified in degrees, but LAMMPS converts it to radians
|
||||
internally.
|
||||
|
||||
Additional to the cosine term the {cosine/buck6d} angle style computes
|
||||
@ -51,8 +51,8 @@ the "special_bonds"_special_bonds.html 1-3 interactions to be weighted
|
||||
[Restrictions:]
|
||||
|
||||
{cosine/buck6d} can only be used in combination with the
|
||||
"pair_buck6d"_pair_buck6d_coul_gauss.html style and with a
|
||||
"special_bonds"_special_bonds.html 0.0 weighting of 1-3 interactions.
|
||||
"pair_buck6d"_pair_buck6d_coul_gauss.html style and with a
|
||||
"special_bonds"_special_bonds.html 0.0 weighting of 1-3 interactions.
|
||||
|
||||
This angle style can only be used if LAMMPS was built with the
|
||||
USER-MOFFF package. See the "Build package"_Build_package.html doc
|
||||
|
||||
@ -63,7 +63,7 @@ instructions on how to use the accelerated styles effectively.
|
||||
[Restrictions:]
|
||||
|
||||
This angle style can only be used if LAMMPS was built with the
|
||||
USER-MISC package.
|
||||
USER-MISC package.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
|
||||
@ -28,7 +28,7 @@ The {sdk} angle style is a combination of the harmonic angle potential,
|
||||
where theta0 is the equilibrium value of the angle and K a prefactor,
|
||||
with the {repulsive} part of the non-bonded {lj/sdk} pair style
|
||||
between the atoms 1 and 3. This angle potential is intended for
|
||||
coarse grained MD simulations with the CMM parametrization using the
|
||||
coarse grained MD simulations with the CMM parameterization using the
|
||||
"pair_style lj/sdk"_pair_sdk.html. Relative to the pair_style
|
||||
{lj/sdk}, however, the energy is shifted by {epsilon}, to avoid sudden
|
||||
jumps. Note that the usual 1/2 factor is included in K.
|
||||
|
||||
@ -57,10 +57,15 @@ Here is an alphabetic list of angle styles defined in LAMMPS. Click on
|
||||
the style to display the formula it computes and coefficients
|
||||
specified by the associated "angle_coeff"_angle_coeff.html command.
|
||||
|
||||
Note that there are also additional angle styles submitted by users
|
||||
which are included in the LAMMPS distribution. The full list of all
|
||||
angle styles are is on the "Commands bond"_Commands_bond.html#angle
|
||||
doc page.
|
||||
Click on the style to display the formula it computes, any additional
|
||||
arguments specified in the angle_style command, and coefficients
|
||||
specified by the associated "angle_coeff"_angle_coeff.html command.
|
||||
|
||||
There are also additional accelerated pair styles included in the
|
||||
LAMMPS distribution for faster performance on CPUs, GPUs, and KNLs.
|
||||
The individual style names on the "Commands
|
||||
angle"_Commands_bond.html#angle doc page are followed by one or more
|
||||
of (g,i,k,o,t) to indicate which accelerated styles exist.
|
||||
|
||||
"none"_angle_none.html - turn off angle interactions
|
||||
"zero"_angle_zero.html - topology but no interactions
|
||||
|
||||
@ -166,7 +166,8 @@ info), a map is used. The default map style is array if no atom ID is
|
||||
larger than 1 million, otherwise the default is hash. By default, a
|
||||
"first" group is not defined. By default, sorting is enabled with a
|
||||
frequency of 1000 and a binsize of 0.0, which means the neighbor
|
||||
cutoff will be used to set the bin size.
|
||||
cutoff will be used to set the bin size. If no neighbor cutoff is
|
||||
defined, sorting will be turned off.
|
||||
|
||||
:line
|
||||
|
||||
|
||||
@ -39,7 +39,7 @@ atom_style body nparticle 2 10
|
||||
atom_style hybrid charge bond
|
||||
atom_style hybrid charge body nparticle 2 5
|
||||
atom_style spin
|
||||
atom_style template myMols
|
||||
atom_style template myMols
|
||||
atom_style tdpd 2 :pre
|
||||
|
||||
[Description:]
|
||||
@ -87,7 +87,7 @@ quantities.
|
||||
{line} | end points, angular velocity | rigid bodies |
|
||||
{meso} | rho, e, cv | SPH particles |
|
||||
{molecular} | bonds, angles, dihedrals, impropers | uncharged molecules |
|
||||
{peri} | mass, volume | mesocopic Peridynamic models |
|
||||
{peri} | mass, volume | mesoscopic Peridynamic models |
|
||||
{smd} | volume, kernel diameter, contact radius, mass | solid and fluid SPH particles |
|
||||
{sphere} | diameter, mass, angular velocity | granular models |
|
||||
{spin} | magnetic moment | system with magnetic particles |
|
||||
@ -309,9 +309,9 @@ force fields"_pair_eff.html.
|
||||
The {dpd} style is part of the USER-DPD package for dissipative
|
||||
particle dynamics (DPD).
|
||||
|
||||
The {edpd}, {mdpd}, and {tdpd} styles are part of the USER-MESO package
|
||||
for energy-conserving dissipative particle dynamics (eDPD), many-body
|
||||
dissipative particle dynamics (mDPD), and transport dissipative particle
|
||||
The {edpd}, {mdpd}, and {tdpd} styles are part of the USER-MESO package
|
||||
for energy-conserving dissipative particle dynamics (eDPD), many-body
|
||||
dissipative particle dynamics (mDPD), and transport dissipative particle
|
||||
dynamics (tDPD), respectively.
|
||||
|
||||
The {meso} style is part of the USER-SPH package for smoothed particle
|
||||
|
||||
@ -247,7 +247,7 @@ to {Niter} times. After each dimension finishes, the imbalance factor
|
||||
is re-computed, and the balancing operation halts if the {stopthresh}
|
||||
criterion is met.
|
||||
|
||||
A rebalance operation in a single dimension is performed using a
|
||||
A re-balance operation in a single dimension is performed using a
|
||||
recursive multisectioning algorithm, where the position of each
|
||||
cutting plane (line in 2d) in the dimension is adjusted independently.
|
||||
This is similar to a recursive bisectioning for a single value, except
|
||||
@ -261,11 +261,11 @@ information, so that they become closer together over time. Thus as
|
||||
the recursion progresses, the count of particles on either side of the
|
||||
plane gets closer to the target value.
|
||||
|
||||
Once the rebalancing is complete and final processor sub-domains
|
||||
Once the re-balancing is complete and final processor sub-domains
|
||||
assigned, particles are migrated to their new owning processor, and
|
||||
the balance procedure ends.
|
||||
|
||||
NOTE: At each rebalance operation, the bisectioning for each cutting
|
||||
NOTE: At each re-balance operation, the bisectioning for each cutting
|
||||
plane (line in 2d) typically starts with low and high bounds separated
|
||||
by the extent of a processor's sub-domain in one dimension. The size
|
||||
of this bracketing region shrinks by 1/2 every iteration. Thus if
|
||||
@ -348,7 +348,7 @@ specified groups, its weight is not changed. If it belongs to
|
||||
multiple groups, its weight is the product of the weight factors.
|
||||
|
||||
This weight style is useful in combination with pair style
|
||||
"hybrid"_pair_hybrid.html, e.g. when combining a more costly manybody
|
||||
"hybrid"_pair_hybrid.html, e.g. when combining a more costly many-body
|
||||
potential with a fast pair-wise potential. It is also useful when
|
||||
using "run_style respa"_run_style.html where some portions of the
|
||||
system have many bonded interactions and others none. It assumes that
|
||||
@ -510,10 +510,13 @@ each processor, instead of 4, and "SQUARES" replaced by "CUBES".
|
||||
For 2d simulations, the {z} style cannot be used. Nor can a "z"
|
||||
appear in {dimstr} for the {shift} style.
|
||||
|
||||
Balancing through recursive bisectioning ({rcb} style) requires
|
||||
"comm_style tiled"_comm_style.html
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"group"_group.html, "processors"_processors.html,
|
||||
"fix balance"_fix_balance.html
|
||||
"fix balance"_fix_balance.html, "comm_style"_comm_style.html
|
||||
|
||||
[Default:] none
|
||||
:link(pizza,http://pizza.sandia.gov)
|
||||
|
||||
@ -56,25 +56,13 @@ corresponds to the 1st example above would be listed as
|
||||
|
||||
:line
|
||||
|
||||
Here is an alphabetic list of bond styles defined in LAMMPS. Click on
|
||||
the style to display the formula it computes and coefficients
|
||||
specified by the associated "bond_coeff"_bond_coeff.html command.
|
||||
The list of all bond styles defined in LAMMPS is given on the
|
||||
"bond_style"_bond_style.html doc page. They are also listed in more
|
||||
compact form on the "Commands bond"_Commands_bond.html doc page.
|
||||
|
||||
Note that here are also additional bond styles submitted by users
|
||||
which are included in the LAMMPS distribution. The full list of all
|
||||
bond styles is on the "Commands bond"_Commands_bond.html doc page.
|
||||
|
||||
"bond_style none"_bond_none.html - turn off bonded interactions
|
||||
"bond_style hybrid"_bond_hybrid.html - define multiple styles of bond interactions :ul
|
||||
|
||||
"bond_style class2"_bond_class2.html - COMPASS (class 2) bond
|
||||
"bond_style fene"_bond_fene.html - FENE (finite-extensible non-linear elastic) bond
|
||||
"bond_style fene/expand"_bond_fene_expand.html - FENE bonds with variable size particles
|
||||
"bond_style harmonic"_bond_harmonic.html - harmonic bond
|
||||
"bond_style morse"_bond_morse.html - Morse bond
|
||||
"bond_style nonlinear"_bond_nonlinear.html - nonlinear bond
|
||||
"bond_style quartic"_bond_quartic.html - breakable quartic bond
|
||||
"bond_style table"_bond_table.html - tabulated by bond length :ul
|
||||
On either of those pages, click on the style to display the formula it
|
||||
computes and its coefficients as specified by the associated
|
||||
bond_coeff command.
|
||||
|
||||
:line
|
||||
|
||||
|
||||
@ -52,7 +52,7 @@ hydrogen-bonding interaction {oxdna/hbond} (see also documentation of
|
||||
"(Snodin)"_#oxdna2 bond style the analogous pair styles and an
|
||||
additional Debye-Hueckel pair style {oxdna2/dh} have to be defined.
|
||||
The coefficients in the above example have to be kept fixed and cannot
|
||||
be changed without reparametrizing the entire model.
|
||||
be changed without reparameterizing the entire model.
|
||||
|
||||
Example input and data files for DNA duplexes can be found in
|
||||
examples/USER/cgdna/examples/oxDNA/ and /oxDNA2/. A simple python
|
||||
|
||||
@ -65,9 +65,15 @@ Here is an alphabetic list of bond styles defined in LAMMPS. Click on
|
||||
the style to display the formula it computes and coefficients
|
||||
specified by the associated "bond_coeff"_bond_coeff.html command.
|
||||
|
||||
Note that there are also additional bond styles submitted by users
|
||||
which are included in the LAMMPS distribution. The full list of all
|
||||
bond styles is on the "Commands bond"_Commands_bond.html doc page.
|
||||
Click on the style to display the formula it computes, any additional
|
||||
arguments specified in the bond_style command, and coefficients
|
||||
specified by the associated "bond_coeff"_bond_coeff.html command.
|
||||
|
||||
There are also additional accelerated pair styles included in the
|
||||
LAMMPS distribution for faster performance on CPUs, GPUs, and KNLs.
|
||||
The individual style names on the "Commands bond"_Commands_bond.html
|
||||
doc page are followed by one or more of (g,i,k,o,t) to indicate which
|
||||
accelerated styles exist.
|
||||
|
||||
"none"_bond_none.html - turn off bonded interactions
|
||||
"zero"_bond_zero.html - topology but no interactions
|
||||
@ -83,7 +89,7 @@ bond styles is on the "Commands bond"_Commands_bond.html doc page.
|
||||
"morse"_bond_morse.html - Morse bond
|
||||
"nonlinear"_bond_nonlinear.html - nonlinear bond
|
||||
"oxdna/fene"_bond_oxdna.html - modified FENE bond suitable for DNA modeling
|
||||
"oxdna2/fene"_bond_oxdna.html - same as oxdna but used with different pair styles
|
||||
"oxdna2/fene"_bond_oxdna.html - same as oxdna but used with different pair styles
|
||||
"quartic"_bond_quartic.html - breakable quartic bond
|
||||
"table"_bond_table.html - tabulated by bond length :ul
|
||||
|
||||
|
||||
@ -154,6 +154,6 @@ Communication mode {multi} is currently only available for
|
||||
|
||||
[Default:]
|
||||
|
||||
The option defauls are mode = single, group = all, cutoff = 0.0, vel =
|
||||
The option defaults are mode = single, group = all, cutoff = 0.0, vel =
|
||||
no. The cutoff default of 0.0 means that ghost cutoff = neighbor
|
||||
cutoff = pairwise force cutoff + neighbor skin.
|
||||
|
||||
@ -51,7 +51,10 @@ decomposition will be the same, as described by
|
||||
commands. The decomposition can be changed via the
|
||||
"balance"_balance.html or "fix balance"_fix_balance.html commands.
|
||||
|
||||
[Restrictions:] none
|
||||
[Restrictions:]
|
||||
|
||||
Communication style {tiled} cannot be used with {triclinic} simulation
|
||||
cells.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
|
||||
@ -44,6 +44,7 @@ Commands :h1
|
||||
fix_modify
|
||||
group
|
||||
group2ndx
|
||||
hyper
|
||||
if
|
||||
improper_coeff
|
||||
improper_style
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user