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

Merge branch 'master' of https://github.com/ProfessorMiller/lammps

This commit is contained in:
Ronald E. Miller 2018-11-14 09:42:32 -05:00
parent 5a359d887a f46478e5ad
commit a4835fa7a6
577 changed files with 118004 additions and 3010 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

68
.github/CODEOWNERS vendored
View File

@ -17,6 +17,7 @@ src/GPU/* @ndtrung81
src/KOKKOS/* @stanmoore1
src/KIM/* @ellio167
src/LATTE/* @cnegre
src/MESSAGE/* @sjplimp
src/SPIN/* @julient31
src/USER-CGDNA/* @ohenrich
src/USER-CGSDK/* @akohlmey
@ -29,19 +30,86 @@ src/USER-MOFFF/* @hheenen
src/USER-MOLFILE/* @akohlmey
src/USER-NETCDF/* @pastewka
src/USER-PHONON/* @lingtikong
src/USER-PTM/* @pmla
src/USER-OMP/* @akohlmey
src/USER-QMMM/* @akohlmey
src/USER-REAXC/* @hasanmetin
src/USER-SCAFACOS/* @rhalver
src/USER-TALLY/* @akohlmey
src/USER-UEF/* @danicholson
src/USER-VTK/* @rbberger
# individual files in packages
src/GPU/pair_vashishta_gpu.* @andeplane
src/KOKKOS/pair_vashishta_kokkos.* @andeplane
src/MANYBODY/pair_vashishta_table.* @andeplane
src/MANYBODY/pair_atm.* @sergeylishchuk
src/USER-MISC/fix_bond_react.* @jrgissing
src/USER-MISC/*_grem.* @dstelter92
src/USER-MISC/compute_stress_mop*.* @RomainVermorel
# core LAMMPS classes
src/lammps.* @sjplimp
src/pointers.h @sjplimp
src/atom.* @sjplimp
src/atom_vec.* @sjplimp
src/angle.* @sjplimp
src/bond.* @sjplimp
src/comm*.* @sjplimp
src/compute.* @sjplimp
src/dihedral.* @sjplimp
src/domain.* @sjplimp
src/dump*.* @sjplimp
src/error.* @sjplimp
src/finish.* @sjplimp
src/fix.* @sjplimp
src/force.* @sjplimp
src/group.* @sjplimp
src/improper.* @sjplimp
src/kspace.* @sjplimp
src/lmptyp.h @sjplimp
src/library.* @sjplimp
src/main.cpp @sjplimp
src/memory.* @sjplimp
src/modify.* @sjplimp
src/molecule.* @sjplimp
src/my_page.h @sjplimp
src/my_pool_chunk.h @sjplimp
src/npair*.* @sjplimp
src/ntopo*.* @sjplimp
src/nstencil*.* @sjplimp
src/neighbor.* @sjplimp
src/nbin*.* @sjplimp
src/neigh_*.* @sjplimp
src/output.* @sjplimp
src/pair.* @sjplimp
src/rcb.* @sjplimp
src/random_*.* @sjplimp
src/region*.* @sjplimp
src/rcb.* @sjplimp
src/read*.* @sjplimp
src/rerun.* @sjplimp
src/run.* @sjplimp
src/respa.* @sjplimp
src/set.* @sjplimp
src/special.* @sjplimp
src/suffix.h @sjplimp
src/thermo.* @sjplimp
src/universe.* @sjplimp
src/update.* @sjplimp
src/variable.* @sjplimp
src/verlet.* @sjplimp
src/velocity.* @sjplimp
src/write_data.* @sjplimp
src/write_restart.* @sjplimp
# overrides for specific files
src/dump_movie.* @akohlmey
src/exceptions.h @rbberger
src/fix_nh.* @athomps
src/info.* @akohlmey @rbberger
src/timer.* @akohlmey
# tools
tools/msi2lmp/* @akohlmey

210
cmake/CMakeLists.txt
View File

@ -13,7 +13,7 @@ get_filename_component(LAMMPS_DOC_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../doc ABSOLUT
# To avoid conflicts with the conventional Makefile build system, we build everything here
file(GLOB LIB_SOURCES ${LAMMPS_SOURCE_DIR}/*.cpp)
file(GLOB LIB_SOURCES ${LAMMPS_SOURCE_DIR}/[^.]*.cpp)
file(GLOB LMP_SOURCES ${LAMMPS_SOURCE_DIR}/main.cpp)
list(REMOVE_ITEM LIB_SOURCES ${LMP_SOURCES})
@ -69,6 +69,8 @@ get_lammps_version(${LAMMPS_SOURCE_DIR}/version.h LAMMPS_VERSION)
# Cmake modules/macros are in a subdirectory to keep this file cleaner
set(CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR}/Modules)
include(PreventInSourceBuilds)
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)
@ -136,6 +138,7 @@ if(BUILD_EXE)
if(LAMMPS_MACHINE)
set(LAMMPS_MACHINE "_${LAMMPS_MACHINE}")
endif()
set(LAMMPS_BINARY lmp${LAMMPS_MACHINE})
endif()
option(BUILD_LIB "Build LAMMPS library" OFF)
@ -162,6 +165,36 @@ set(LAMMPS_LINK_LIBS)
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
SPIN SNAP SRD KIM PYTHON MSCG MPIIO VORONOI POEMS LATTE USER-ATC USER-AWPMD
USER-BOCS USER-CAUCHY 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)
set(ACCEL_PACKAGES USER-OMP KOKKOS OPT USER-INTEL GPU)
set(OTHER_PACKAGES CORESHELL QEQ)
foreach(PKG ${DEFAULT_PACKAGES})
option(PKG_${PKG} "Build ${PKG} Package" OFF)
endforeach()
foreach(PKG ${ACCEL_PACKAGES} ${OTHER_PACKAGES})
option(PKG_${PKG} "Build ${PKG} Package" OFF)
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)
enable_language(Fortran)
endif()
if(PKG_MEAM OR PKG_USER-H5MD OR PKG_USER-QMMM OR PKG_USER-SCAFACOS)
enable_language(C)
endif()
# do MPI detection after language activation, if MPI for these language is required
find_package(MPI QUIET)
option(BUILD_MPI "Build MPI version" ${MPI_FOUND})
if(BUILD_MPI)
@ -206,25 +239,52 @@ endif()
option(CMAKE_VERBOSE_MAKEFILE "Verbose makefile" OFF)
option(ENABLE_TESTING "Enable testing" OFF)
if(ENABLE_TESTING)
if(ENABLE_TESTING AND BUILD_EXE)
enable_testing()
endif(ENABLE_TESTING)
option(LAMMPS_TESTING_SOURCE_DIR "Location of lammps-testing source directory" "")
option(LAMMPS_TESTING_GIT_TAG "Git tag of lammps-testing" "master")
mark_as_advanced(LAMMPS_TESTING_SOURCE_DIR LAMMPS_TESTING_GIT_TAG)
set(DEFAULT_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS DIPOLE GRANULAR
KSPACE MANYBODY MC MEAM MESSAGE MISC MOLECULE PERI REAX REPLICA RIGID SHOCK SPIN SNAP
SRD KIM PYTHON MSCG MPIIO VORONOI POEMS LATTE USER-ATC USER-AWPMD USER-BOCS
USER-CGDNA USER-MESO USER-CGSDK USER-COLVARS USER-DIFFRACTION USER-DPD USER-DRUDE
USER-EFF USER-FEP USER-H5MD USER-LB USER-MANIFOLD USER-MEAMC USER-MGPT USER-MISC
USER-MOFFF USER-MOLFILE USER-NETCDF USER-PHONON USER-QTB USER-REAXC USER-SMD
USER-SMTBQ USER-SPH USER-TALLY USER-UEF USER-VTK USER-QUIP USER-QMMM)
set(ACCEL_PACKAGES USER-OMP KOKKOS OPT USER-INTEL GPU)
set(OTHER_PACKAGES CORESHELL QEQ)
foreach(PKG ${DEFAULT_PACKAGES})
option(PKG_${PKG} "Build ${PKG} Package" OFF)
endforeach()
foreach(PKG ${ACCEL_PACKAGES} ${OTHER_PACKAGES})
option(PKG_${PKG} "Build ${PKG} Package" OFF)
endforeach()
if (CMAKE_VERSION VERSION_GREATER "3.10.3" AND NOT LAMMPS_TESTING_SOURCE_DIR)
include(FetchContent)
FetchContent_Declare(lammps-testing
GIT_REPOSITORY https://github.com/lammps/lammps-testing.git
GIT_TAG ${LAMMPS_TESTING_GIT_TAG}
)
FetchContent_GetProperties(lammps-testing)
if(NOT lammps-testing_POPULATED)
message(STATUS "Downloading tests...")
FetchContent_Populate(lammps-testing)
endif()
set(LAMMPS_TESTING_SOURCE_DIR ${lammps-testing_SOURCE_DIR})
elseif(NOT LAMMPS_TESTING_SOURCE_DIR)
message(WARNING "Full test-suite requires CMake >= 3.11 or copy of\n"
"https://github.com/lammps/lammps-testing in LAMMPS_TESTING_SOURCE_DIR")
endif()
if(EXISTS ${LAMMPS_TESTING_SOURCE_DIR})
message(STATUS "Running test discovery...")
file(GLOB_RECURSE TEST_SCRIPTS ${LAMMPS_TESTING_SOURCE_DIR}/tests/core/*/in.*)
foreach(script_path ${TEST_SCRIPTS})
get_filename_component(TEST_NAME ${script_path} EXT)
get_filename_component(SCRIPT_NAME ${script_path} NAME)
get_filename_component(PARENT_DIR ${script_path} DIRECTORY)
string(SUBSTRING ${TEST_NAME} 1 -1 TEST_NAME)
string(REPLACE "-" "_" TEST_NAME ${TEST_NAME})
string(REPLACE "+" "_" TEST_NAME ${TEST_NAME})
set(TEST_NAME "test_core_${TEST_NAME}_serial")
add_test(${TEST_NAME} ${CMAKE_BINARY_DIR}/${LAMMPS_BINARY} -in ${SCRIPT_NAME})
set_tests_properties(${TEST_NAME} PROPERTIES WORKING_DIRECTORY ${PARENT_DIR})
endforeach()
list(LENGTH TEST_SCRIPTS NUM_TESTS)
message(STATUS "Found ${NUM_TESTS} tests.")
endif()
endif()
macro(pkg_depends PKG1 PKG2)
if(PKG_${PKG1} AND NOT (PKG_${PKG2} OR BUILD_${PKG2}))
@ -238,17 +298,7 @@ pkg_depends(MPIIO MPI)
pkg_depends(USER-ATC MANYBODY)
pkg_depends(USER-LB MPI)
pkg_depends(USER-PHONON KSPACE)
######################################################
# 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)
enable_language(Fortran)
endif()
if(PKG_MEAM OR PKG_USER-H5MD OR PKG_USER-QMMM)
enable_language(C)
endif()
pkg_depends(USER-SCAFACOS MPI)
find_package(OpenMP QUIET)
option(BUILD_OMP "Build with OpenMP support" ${OpenMP_FOUND})
@ -302,7 +352,7 @@ if(PKG_MSCG OR PKG_USER-ATC OR PKG_USER-AWPMD OR PKG_USER-QUIP OR PKG_LATTE)
find_package(BLAS)
if(NOT LAPACK_FOUND OR NOT BLAS_FOUND)
enable_language(Fortran)
file(GLOB LAPACK_SOURCES ${LAMMPS_LIB_SOURCE_DIR}/linalg/*.[fF])
file(GLOB LAPACK_SOURCES ${LAMMPS_LIB_SOURCE_DIR}/linalg/[^.]*.[fF])
add_library(linalg STATIC ${LAPACK_SOURCES})
set(LAPACK_LIBRARIES linalg)
else()
@ -426,6 +476,57 @@ if(PKG_LATTE)
list(APPEND LAMMPS_LINK_LIBS ${LATTE_LIBRARIES} ${LAPACK_LIBRARIES})
endif()
if(PKG_USER-SCAFACOS)
find_package(GSL REQUIRED)
option(DOWNLOAD_SCAFACOS "Download ScaFaCoS (instead of using the system's one)" OFF)
if(DOWNLOAD_SCAFACOS)
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
--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}
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)
list(APPEND LAMMPS_DEPS scafacos_build)
# list and order from pkg_config file of ScaFaCoS build
list(APPEND LAMMPS_LINK_LIBS ${SCAFACOS_BUILD_DIR}/lib/libfcs.a)
list(APPEND LAMMPS_LINK_LIBS ${SCAFACOS_BUILD_DIR}/lib/libfcs_direct.a)
list(APPEND LAMMPS_LINK_LIBS ${SCAFACOS_BUILD_DIR}/lib/libfcs_ewald.a)
list(APPEND LAMMPS_LINK_LIBS ${SCAFACOS_BUILD_DIR}/lib/libfcs_fmm.a)
list(APPEND LAMMPS_LINK_LIBS ${SCAFACOS_BUILD_DIR}/lib/libfcs_p2nfft.a)
list(APPEND LAMMPS_LINK_LIBS ${SCAFACOS_BUILD_DIR}/lib/libfcs_p3m.a)
list(APPEND LAMMPS_LINK_LIBS ${GSL_LIBRARIES})
list(APPEND LAMMPS_LINK_LIBS ${SCAFACOS_BUILD_DIR}/lib/libfcs_near.a)
list(APPEND LAMMPS_LINK_LIBS ${SCAFACOS_BUILD_DIR}/lib/libfcs_gridsort.a)
list(APPEND LAMMPS_LINK_LIBS ${SCAFACOS_BUILD_DIR}/lib/libfcs_resort.a)
list(APPEND LAMMPS_LINK_LIBS ${SCAFACOS_BUILD_DIR}/lib/libfcs_redist.a)
list(APPEND LAMMPS_LINK_LIBS ${SCAFACOS_BUILD_DIR}/lib/libfcs_common.a)
list(APPEND LAMMPS_LINK_LIBS ${SCAFACOS_BUILD_DIR}/lib/libfcs_pnfft.a)
list(APPEND LAMMPS_LINK_LIBS ${SCAFACOS_BUILD_DIR}/lib/libfcs_pfft.a)
list(APPEND LAMMPS_LINK_LIBS ${SCAFACOS_BUILD_DIR}/lib/libfcs_fftw3_mpi.a)
list(APPEND LAMMPS_LINK_LIBS ${SCAFACOS_BUILD_DIR}/lib/libfcs_fftw3.a)
list(APPEND LAMMPS_LINK_LIBS ${MPI_Fortran_LIBRARIES})
list(APPEND LAMMPS_LINK_LIBS ${MPI_C_LIBRARIES})
else()
FIND_PACKAGE(PkgConfig REQUIRED)
PKG_CHECK_MODULES(SCAFACOS scafacos REQUIRED)
list(APPEND LAMMPS_LINK_LIBS ${SCAFACOS_LDFLAGS})
endif()
include_directories(${SCAFACOS_INCLUDE_DIRS})
endif()
if(PKG_USER-MOLFILE)
add_library(molfile INTERFACE)
target_include_directories(molfile INTERFACE ${LAMMPS_LIB_SOURCE_DIR}/molfile)
@ -435,8 +536,8 @@ endif()
if(PKG_USER-NETCDF)
find_package(NetCDF REQUIRED)
include_directories(NETCDF_INCLUDE_DIR)
list(APPEND LAMMPS_LINK_LIBS ${NETCDF_LIBRARY})
include_directories(${NETCDF_INCLUDE_DIRS})
list(APPEND LAMMPS_LINK_LIBS ${NETCDF_LIBRARIES})
add_definitions(-DLMP_HAS_NETCDF -DNC_64BIT_DATA=0x0020)
endif()
@ -453,8 +554,9 @@ if(PKG_USER-SMD)
set(EIGEN3_INCLUDE_DIR ${SOURCE_DIR})
list(APPEND LAMMPS_DEPS Eigen3_build)
else()
find_package(Eigen3)
if(NOT Eigen3_FOUND)
find_package(Eigen3 NO_MODULE)
mark_as_advanced(Eigen3_DIR)
if(NOT EIGEN3_FOUND)
message(FATAL_ERROR "Eigen3 not found, help CMake to find it by setting EIGEN3_INCLUDE_DIR, or set DOWNLOAD_EIGEN3=ON to download it")
endif()
endif()
@ -506,8 +608,9 @@ endif()
if(PKG_MESSAGE)
option(MESSAGE_ZMQ "Use ZeroMQ in MESSAGE package" OFF)
file(GLOB_RECURSE cslib_SOURCES ${LAMMPS_LIB_SOURCE_DIR}/message/cslib/*.F
${LAMMPS_LIB_SOURCE_DIR}/message/cslib/*.c ${LAMMPS_LIB_SOURCE_DIR}/message/cslib/*.cpp)
file(GLOB_RECURSE cslib_SOURCES ${LAMMPS_LIB_SOURCE_DIR}/message/cslib/[^.]*.F
${LAMMPS_LIB_SOURCE_DIR}/message/cslib/[^.]*.c
${LAMMPS_LIB_SOURCE_DIR}/message/cslib/[^.]*.cpp)
if(BUILD_SHARED_LIBS)
add_library(cslib SHARED ${cslib_SOURCES})
@ -623,8 +726,8 @@ RegisterStyles(${LAMMPS_SOURCE_DIR})
foreach(PKG ${DEFAULT_PACKAGES})
set(${PKG}_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/${PKG})
file(GLOB ${PKG}_SOURCES ${${PKG}_SOURCES_DIR}/*.cpp)
file(GLOB ${PKG}_HEADERS ${${PKG}_SOURCES_DIR}/*.h)
file(GLOB ${PKG}_SOURCES ${${PKG}_SOURCES_DIR}/[^.]*.cpp)
file(GLOB ${PKG}_HEADERS ${${PKG}_SOURCES_DIR}/[^.]*.h)
# check for package files in src directory due to old make system
DetectBuildSystemConflict(${LAMMPS_SOURCE_DIR} ${${PKG}_SOURCES} ${${PKG}_HEADERS})
@ -642,8 +745,8 @@ endforeach()
foreach(PKG ${ACCEL_PACKAGES})
set(${PKG}_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/${PKG})
file(GLOB ${PKG}_SOURCES ${${PKG}_SOURCES_DIR}/*.cpp)
file(GLOB ${PKG}_HEADERS ${${PKG}_SOURCES_DIR}/*.h)
file(GLOB ${PKG}_SOURCES ${${PKG}_SOURCES_DIR}/[^.]*.cpp)
file(GLOB ${PKG}_HEADERS ${${PKG}_SOURCES_DIR}/[^.]*.h)
# check for package files in src directory due to old make system
DetectBuildSystemConflict(${LAMMPS_SOURCE_DIR} ${${PKG}_SOURCES} ${${PKG}_HEADERS})
@ -657,8 +760,10 @@ foreach(SIMPLE_LIB REAX MEAM POEMS USER-ATC USER-AWPMD USER-COLVARS USER-H5MD
if(PKG_${SIMPLE_LIB})
string(REGEX REPLACE "^USER-" "" PKG_LIB "${SIMPLE_LIB}")
string(TOLOWER "${PKG_LIB}" PKG_LIB)
file(GLOB_RECURSE ${PKG_LIB}_SOURCES ${LAMMPS_LIB_SOURCE_DIR}/${PKG_LIB}/*.F
${LAMMPS_LIB_SOURCE_DIR}/${PKG_LIB}/*.c ${LAMMPS_LIB_SOURCE_DIR}/${PKG_LIB}/*.cpp)
file(GLOB_RECURSE ${PKG_LIB}_SOURCES
${LAMMPS_LIB_SOURCE_DIR}/${PKG_LIB}/[^.]*.F
${LAMMPS_LIB_SOURCE_DIR}/${PKG_LIB}/[^.]*.c
${LAMMPS_LIB_SOURCE_DIR}/${PKG_LIB}/[^.]*.cpp)
add_library(${PKG_LIB} STATIC ${${PKG_LIB}_SOURCES})
list(APPEND LAMMPS_LINK_LIBS ${PKG_LIB})
if(PKG_LIB STREQUAL awpmd)
@ -733,6 +838,7 @@ if(PKG_USER-OMP)
set(USER-OMP_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/USER-OMP)
set(USER-OMP_SOURCES ${USER-OMP_SOURCES_DIR}/thr_data.cpp
${USER-OMP_SOURCES_DIR}/thr_omp.cpp
${USER-OMP_SOURCES_DIR}/fix_omp.cpp
${USER-OMP_SOURCES_DIR}/fix_nh_omp.cpp
${USER-OMP_SOURCES_DIR}/fix_nh_sphere_omp.cpp
${USER-OMP_SOURCES_DIR}/domain_omp.cpp)
@ -741,7 +847,7 @@ if(PKG_USER-OMP)
# detects styles which have USER-OMP version
RegisterStylesExt(${USER-OMP_SOURCES_DIR} omp OMP_SOURCES)
RegisterFixStyle("${USER-OMP_SOURCES_DIR}/fix_omp.h")
get_property(USER-OMP_SOURCES GLOBAL PROPERTY OMP_SOURCES)
@ -941,7 +1047,7 @@ if(PKG_GPU)
set(GPU_PREC_SETTING "SINGLE_SINGLE")
endif()
file(GLOB GPU_LIB_SOURCES ${LAMMPS_LIB_SOURCE_DIR}/gpu/*.cpp)
file(GLOB GPU_LIB_SOURCES ${LAMMPS_LIB_SOURCE_DIR}/gpu/[^.]*.cpp)
file(MAKE_DIRECTORY ${LAMMPS_LIB_BINARY_DIR}/gpu)
if(GPU_API STREQUAL "CUDA")
@ -954,15 +1060,15 @@ if(PKG_GPU)
set(GPU_ARCH "sm_30" CACHE STRING "LAMMPS GPU CUDA SM architecture (e.g. sm_60)")
file(GLOB GPU_LIB_CU ${LAMMPS_LIB_SOURCE_DIR}/gpu/*.cu ${CMAKE_CURRENT_SOURCE_DIR}/gpu/*.cu)
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)
cuda_include_directories(${LAMMPS_LIB_SOURCE_DIR}/gpu ${LAMMPS_LIB_BINARY_DIR}/gpu)
if(CUDPP_OPT)
cuda_include_directories(${LAMMPS_LIB_SOURCE_DIR}/gpu/cudpp_mini)
file(GLOB GPU_LIB_CUDPP_SOURCES ${LAMMPS_LIB_SOURCE_DIR}/gpu/cudpp_mini/*.cpp)
file(GLOB GPU_LIB_CUDPP_CU ${LAMMPS_LIB_SOURCE_DIR}/gpu/cudpp_mini/*.cu)
file(GLOB GPU_LIB_CUDPP_SOURCES ${LAMMPS_LIB_SOURCE_DIR}/gpu/cudpp_mini/[^.]*.cpp)
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
@ -1011,7 +1117,7 @@ if(PKG_GPU)
include(OpenCLUtils)
set(OCL_COMMON_HEADERS ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_preprocessor.h ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_aux_fun1.h)
file(GLOB GPU_LIB_CU ${LAMMPS_LIB_SOURCE_DIR}/gpu/*.cu)
file(GLOB GPU_LIB_CU ${LAMMPS_LIB_SOURCE_DIR}/gpu/[^.]*.cu)
list(REMOVE_ITEM GPU_LIB_CU ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_gayberne.cu ${LAMMPS_LIB_SOURCE_DIR}/gpu/lal_gayberne_lj.cu)
foreach(GPU_KERNEL ${GPU_LIB_CU})
@ -1119,11 +1225,11 @@ if(BUILD_EXE)
endif()
endif()
set_target_properties(lmp PROPERTIES OUTPUT_NAME lmp${LAMMPS_MACHINE})
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 lmp${LAMMPS_MACHINE}.1)
install(FILES ${LAMMPS_DOC_DIR}/lammps.1 DESTINATION ${CMAKE_INSTALL_MANDIR}/man1 RENAME ${LAMMPS_BINARY}.1)
if(ENABLE_TESTING)
add_test(ShowHelp lmp${LAMMPS_MACHINE} -help)
add_test(ShowHelp ${LAMMPS_BINARY} -help)
endif()
endif()
@ -1138,7 +1244,7 @@ if(BUILD_DOC)
set(VIRTUALENV ${PYTHON_EXECUTABLE} -m virtualenv)
file(GLOB DOC_SOURCES ${LAMMPS_DOC_DIR}/src/*.txt)
file(GLOB DOC_SOURCES ${LAMMPS_DOC_DIR}/src/[^.]*.txt)
file(GLOB PDF_EXTRA_SOURCES ${LAMMPS_DOC_DIR}/src/lammps_commands*.txt ${LAMMPS_DOC_DIR}/src/lammps_support.txt ${LAMMPS_DOC_DIR}/src/lammps_tutorials.txt)
list(REMOVE_ITEM DOC_SOURCES ${PDF_EXTRA_SOURCES})

23
cmake/Modules/PreventInSourceBuilds.cmake Normal file
View File

@ -0,0 +1,23 @@
# - Prevent in-source builds.
# https://stackoverflow.com/questions/1208681/with-cmake-how-would-you-disable-in-source-builds/
function(prevent_in_source_builds)
# make sure the user doesn't play dirty with symlinks
get_filename_component(srcdir "${CMAKE_SOURCE_DIR}" REALPATH)
get_filename_component(srcdir2 "${CMAKE_SOURCE_DIR}/.." REALPATH)
get_filename_component(srcdir3 "${CMAKE_SOURCE_DIR}/../src" REALPATH)
get_filename_component(bindir "${CMAKE_BINARY_DIR}" REALPATH)
# disallow in-source builds
if("${srcdir}" STREQUAL "${bindir}" OR "${srcdir2}" STREQUAL "${bindir}" OR "${srcdir3}" STREQUAL "${bindir}")
message(FATAL_ERROR "\
CMake must not to be run in the source directory. \
Rather create a dedicated build directory and run CMake there. \
To clean up after this aborted in-place compilation:
rm -r CMakeCache.txt CMakeFiles
")
endif()
endfunction()
prevent_in_source_builds()

10
cmake/Modules/StyleHeaderUtils.cmake
View File

@ -85,19 +85,23 @@ function(RegisterNPairStyle path)
AddStyleHeader(${path} NPAIR)
endfunction(RegisterNPairStyle)
function(RegisterFixStyle path)
AddStyleHeader(${path} FIX)
endfunction(RegisterFixStyle)
function(RegisterStyles search_path)
FindStyleHeaders(${search_path} ANGLE_CLASS angle_ ANGLE ) # angle ) # force
FindStyleHeaders(${search_path} ATOM_CLASS atom_vec_ ATOM_VEC ) # atom ) # atom atom_vec_hybrid
FindStyleHeaders(${search_path} BODY_CLASS body_ BODY ) # body ) # atom_vec_body
FindStyleHeaders(${search_path} BOND_CLASS bond_ BOND ) # bond ) # force
FindStyleHeaders(${search_path} COMMAND_CLASS "" COMMAND ) # command ) # input
FindStyleHeaders(${search_path} COMMAND_CLASS "[^.]" COMMAND ) # command ) # input
FindStyleHeaders(${search_path} COMPUTE_CLASS compute_ COMPUTE ) # compute ) # modify
FindStyleHeaders(${search_path} DIHEDRAL_CLASS dihedral_ DIHEDRAL ) # dihedral ) # force
FindStyleHeaders(${search_path} DUMP_CLASS dump_ DUMP ) # dump ) # output write_dump
FindStyleHeaders(${search_path} FIX_CLASS fix_ FIX ) # fix ) # modify
FindStyleHeaders(${search_path} IMPROPER_CLASS improper_ IMPROPER ) # improper ) # force
FindStyleHeaders(${search_path} INTEGRATE_CLASS "" INTEGRATE ) # integrate ) # update
FindStyleHeaders(${search_path} KSPACE_CLASS "" KSPACE ) # kspace ) # force
FindStyleHeaders(${search_path} INTEGRATE_CLASS "[^.]" INTEGRATE ) # integrate ) # update
FindStyleHeaders(${search_path} KSPACE_CLASS "[^.]" KSPACE ) # kspace ) # force
FindStyleHeaders(${search_path} MINIMIZE_CLASS min_ MINIMIZE ) # minimize ) # update
FindStyleHeaders(${search_path} NBIN_CLASS nbin_ NBIN ) # nbin ) # neighbor
FindStyleHeaders(${search_path} NPAIR_CLASS npair_ NPAIR ) # npair ) # neighbor

12
doc/Makefile
View File

@ -38,7 +38,7 @@ OBJECTS=$(SOURCES:src/%.txt=$(RSTDIR)/%.rst)
help:
@echo "Please use \`make <target>' where <target> is one of"
@echo " html create HTML doc pages in html dir"
@echo " pdf create Manual.pdf and Developer.pdf in this dir"
@echo " pdf create Developer.pdf and Manual.pdf in this dir"
@echo " old create old-style HTML doc pages in old dir"
@echo " fetch fetch HTML and PDF files from LAMMPS web site"
@echo " epub create ePUB format manual for e-book readers"
@ -116,17 +116,17 @@ mobi: epub
pdf: utils/txt2html/txt2html.exe
@(\
set -e; \
cd src; \
cd src/Developer; \
pdflatex developer; \
pdflatex developer; \
mv developer.pdf ../../Developer.pdf; \
cd ..; \
../utils/txt2html/txt2html.exe -b *.txt; \
htmldoc --batch lammps.book; \
for s in `echo *.txt | sed -e 's,\.txt,\.html,g'` ; \
do grep -q $$s lammps.book || \
echo doc file $$s missing in src/lammps.book; done; \
rm *.html; \
cd Developer; \
pdflatex developer; \
pdflatex developer; \
mv developer.pdf ../../Developer.pdf; \
)
old: utils/txt2html/txt2html.exe

4
doc/src/Build_basics.txt
View File

@ -292,6 +292,10 @@ 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
current LAMMPS version (HTML and PDF files), from the website
"download page"_http://lammps.sandia.gov/download.html.
:line
Install LAMMPS after a build :h4,link(install)

40
doc/src/Build_extras.txt
View File

@ -48,6 +48,7 @@ This is the list of packages that may require additional steps.
"USER-OMP"_#user-omp,
"USER-QMMM"_#user-qmmm,
"USER-QUIP"_#user-quip,
"USER-SCAFACOS"_#user-scafacos,
"USER-SMD"_#user-smd,
"USER-VTK"_#user-vtk :tb(c=6,ea=c,a=l)
@ -928,6 +929,45 @@ successfully build on your system.
:line
USER-SCAFACOS package :h4,link(user-scafacos)
To build with this package, you must download and build the "ScaFaCoS
Coulomb solver library"_scafacos_home
:link(scafacos_home,http://www.scafacos.de)
[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_INCLUDE_DIR=path # ScaFaCoS include directory (only needed if at custom location) :pre
If DOWNLOAD_SCAFACOS is set, the ScaFaCoS library will be downloaded
and built inside the CMake build directory. If the ScaFaCoS library
is already on your system (in a location CMake cannot find it),
SCAFACOS_LIBRARY is the filename (plus path) of the ScaFaCoS library
file, not the directory the library file is in. SCAFACOS_INCLUDE_DIR
is the directory the ScaFaCoS include file is in.
[Traditional make]:
You can download and build the ScaFaCoS library manually if you
prefer; follow the instructions in lib/scafacos/README. You can also
do it in one step from the lammps/src dir, using a command like these,
which simply invoke the lib/scafacos/Install.py script with the
specified args:
make lib-scafacos # print help message
make lib-scafacos args="-b" # download and build in lib/scafacos/scafacos-<version>
make lib-scafacos args="-p $HOME/scafacos # use existing ScaFaCoS installation in $HOME/scafacos
Note that 2 symbolic (soft) links, "includelink" and "liblink", are
created in lib/scafacos to point to the ScaFaCoS src dir. When LAMMPS
builds in src it will use these links. You should not need to edit
the lib/scafacos/Makefile.lammps file.
:line
USER-SMD package :h4,link(user-smd)
To build with this package, you must download the Eigen3 library.

3
doc/src/Build_package.txt
View File

@ -42,7 +42,7 @@ packages:
"KOKKOS"_Build_extras.html#kokkos,
"LATTE"_Build_extras.html#latte,
"MEAM"_Build_extras.html#meam,
"MESSAGE"_#Build_extras.html#message,
"MESSAGE"_Build_extras.html#message,
"MSCG"_Build_extras.html#mscg,
"OPT"_Build_extras.html#opt,
"POEMS"_Build_extras.html#poems,
@ -59,6 +59,7 @@ packages:
"USER-OMP"_Build_extras.html#user-omp,
"USER-QMMM"_Build_extras.html#user-qmmm,
"USER-QUIP"_Build_extras.html#user-quip,
"USER-SCAFACOS"_Build_extras.html#user-scafacos,
"USER-SMD"_Build_extras.html#user-smd,
"USER-VTK"_Build_extras.html#user-vtk :tb(c=6,ea=c,a=l)

2
doc/src/Commands_bond.txt
View File

@ -70,7 +70,7 @@ OPT.
"fourier/simple (o)"_angle_fourier_simple.html,
"harmonic (iko)"_angle_harmonic.html,
"quartic (o)"_angle_quartic.html,
"sdk"_angle_sdk.html,
"sdk (o)"_angle_sdk.html,
"table (o)"_angle_table.html :tb(c=4,ea=c)
:line

6
doc/src/Commands_compute.txt
View File

@ -25,6 +25,7 @@ additional letters in parenthesis: g = GPU, i = USER-INTEL, k =
KOKKOS, o = USER-OMP, t = OPT.
"ackland/atom"_compute_ackland_atom.html,
"adf"_compute_adf.html,
"aggregate/atom"_compute_cluster_atom.html,
"angle"_compute_angle.html,
"angle/local"_compute_angle_local.html,
@ -35,6 +36,7 @@ KOKKOS, o = USER-OMP, t = OPT.
"bond/local"_compute_bond_local.html,
"centro/atom"_compute_centro_atom.html,
"chunk/atom"_compute_chunk_atom.html,
"chunk/spread/atom"_compute_chunk_spread_atom.html,
"cluster/atom"_compute_cluster_atom.html,
"cna/atom"_compute_cna_atom.html,
"cnp/atom"_compute_cnp_atom.html,
@ -95,8 +97,10 @@ KOKKOS, o = USER-OMP, t = OPT.
"property/atom"_compute_property_atom.html,
"property/chunk"_compute_property_chunk.html,
"property/local"_compute_property_local.html,
"ptm/atom"_compute_ptm_atom.html,
"rdf"_compute_rdf.html,
"reduce"_compute_reduce.html,
"reduce/chunk"_compute_reduce_chunk.html,
"reduce/region"_compute_reduce.html,
"rigid/local"_compute_rigid_local.html,
"saed"_compute_saed.html,
@ -115,7 +119,7 @@ KOKKOS, o = USER-OMP, t = OPT.
"smd/tlsph/strain"_compute_smd_tlsph_strain.html,
"smd/tlsph/strain/rate"_compute_smd_tlsph_strain_rate.html,
"smd/tlsph/stress"_compute_smd_tlsph_stress.html,
"smd/triangle/mesh/vertices"_compute_smd_triangle_mesh_vertices.html,
"smd/triangle/mesh/vertices"_compute_smd_triangle_vertices.html,
"smd/ulsph/num/neighs"_compute_smd_ulsph_num_neighs.html,
"smd/ulsph/strain"_compute_smd_ulsph_strain.html,
"smd/ulsph/strain/rate"_compute_smd_ulsph_strain_rate.html,

10
doc/src/Commands_fix.txt
View File

@ -65,13 +65,14 @@ OPT.
"eos/table/rx (k)"_fix_eos_table_rx.html,
"evaporate"_fix_evaporate.html,
"external"_fix_external.html,
"ffl"_fix_ffl.html,
"filter/corotate"_fix_filter_corotate.html,
"flow/gauss"_fix_flow_gauss.html,
"freeze"_fix_freeze.html,
"freeze (k)"_fix_freeze.html,
"gcmc"_fix_gcmc.html,
"gld"_fix_gld.html,
"gle"_fix_gle.html,
"gravity (o)"_fix_gravity.html,
"gravity (ko)"_fix_gravity.html,
"grem"_fix_grem.html,
"halt"_fix_halt.html,
"heat"_fix_heat.html,
@ -104,11 +105,12 @@ OPT.
"nph/asphere (o)"_fix_nph_asphere.html,
"nph/body"_fix_nph_body.html,
"nph/eff"_fix_nh_eff.html,
"nph/sphere (o)"_fix_nph_sphere.html,
"nph/sphere (ko)"_fix_nph_sphere.html,
"nphug (o)"_fix_nphug.html,
"npt (kio)"_fix_nh.html,
"npt/asphere (o)"_fix_npt_asphere.html,
"npt/body"_fix_npt_body.html,
"npt/cauchy"_fix_cauchy.html,
"npt/eff"_fix_nh_eff.html,
"npt/sphere (o)"_fix_npt_sphere.html,
"npt/uef"_fix_nh_uef.html,
@ -216,7 +218,7 @@ OPT.
"wall/body/polyhedron"_fix_wall_body_polyhedron.html,
"wall/colloid"_fix_wall.html,
"wall/ees"_fix_wall_ees.html,
"wall/gran"_fix_wall_gran.html,
"wall/gran (o)"_fix_wall_gran.html,
"wall/gran/region"_fix_wall_gran_region.html,
"wall/harmonic"_fix_wall.html,
"wall/lj1043"_fix_wall.html,

3
doc/src/Commands_kspace.txt
View File

@ -33,4 +33,5 @@ OPT.
"pppm/disp (i)"_kspace_style.html,
"pppm/disp/tip4p"_kspace_style.html,
"pppm/stagger"_kspace_style.html,
"pppm/tip4p (o)"_kspace_style.html :tb(c=4,ea=c)
"pppm/tip4p (o)"_kspace_style.html,
"scafacos"_kspace_style.html :tb(c=4,ea=c)

7
doc/src/Commands_pair.txt
View File

@ -26,7 +26,7 @@ OPT.
"none"_pair_none.html,
"zero"_pair_zero.html,
"hybrid"_pair_hybrid.html,
"hybrid (k)"_pair_hybrid.html,
"hybrid/overlay (k)"_pair_hybrid.html :tb(c=4,ea=c)
"adp (o)"_pair_adp.html,
@ -81,6 +81,7 @@ OPT.
"eam (gikot)"_pair_eam.html,
"eam/alloy (gikot)"_pair_eam.html,
"eam/cd (o)"_pair_eam.html,
"eam/cd/old (o)"_pair_eam.html,
"eam/fs (gikot)"_pair_eam.html,
"edip (o)"_pair_edip.html,
"edip/multi"_pair_edip.html,
@ -94,7 +95,7 @@ OPT.
"gayberne (gio)"_pair_gayberne.html,
"gran/hertz/history (o)"_pair_gran.html,
"gran/hooke (o)"_pair_gran.html,
"gran/hooke/history (o)"_pair_gran.html,
"gran/hooke/history (ko)"_pair_gran.html,
"gw"_pair_gw.html,
"gw/zbl"_pair_gw.html,
"hbond/dreiding/lj (o)"_pair_hbond_dreiding.html,
@ -167,7 +168,7 @@ OPT.
"morse/soft"_pair_morse.html,
"multi/lucy"_pair_multi_lucy.html,
"multi/lucy/rx (k)"_pair_multi_lucy_rx.html,
"nb3b/harmonic (o)"_pair_nb3b_harmonic.html,
"nb3b/harmonic"_pair_nb3b_harmonic.html,
"nm/cut (o)"_pair_nm.html,
"nm/cut/coul/cut (o)"_pair_nm.html,
"nm/cut/coul/long (o)"_pair_nm.html,

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 6.7 KiB

21
doc/src/Eqs/ptm_rmsd.tex Normal file
View File

@ -0,0 +1,21 @@
\documentclass[12pt,article]{article}
\usepackage{indentfirst}
\usepackage{amsmath}
\newcommand{\set}[1]{\ensuremath{\mathbf{#1}}}
\newcommand{\mean}[1]{\ensuremath{\overline{#1}}}
\newcommand{\norm}[1]{\ensuremath{\left|\left|{#1}\right|\right|}}
\begin{document}
\begin{equation*}
\text{RMSD}(\set{u}, \set{v}) = \min_{s, \set{Q}} \sqrt{\frac{1}{N} \sum\limits_{i=1}^{N}
\norm{
s[\vec{u_i} - \mean{\set{u}}]
-
\set{Q} \vec{v_i}
}^2}
\end{equation*}
\end{document}

62
doc/src/Errors_messages.txt
View File

@ -1092,11 +1092,6 @@ correct. :dd
The specified file cannot be opened. Check that the path and name are
correct. :dd
{Cannot open fix ave/spatial file %s} :dt
The specified file cannot be opened. Check that the path and name are
correct. :dd
{Cannot open fix ave/time file %s} :dt
The specified file cannot be opened. Check that the path and name are
@ -1677,10 +1672,6 @@ provided by an atom map. An atom map does not exist (by default) for
non-molecular problems. Using the atom_modify map command will force
an atom map to be created. :dd
{Cannot use fix ave/spatial z for 2 dimensional model} :dt
Self-explanatory. :dd
{Cannot use fix bond/break with non-molecular systems} :dt
Only systems with bonds that can be changed can be used. Atom_style
@ -2425,10 +2416,6 @@ Self-explanatory. :dd
Self-explanatory. :dd
{Compute ID for fix ave/spatial does not exist} :dt
Self-explanatory. :dd
{Compute ID for fix ave/time does not exist} :dt
Self-explanatory. :dd
@ -4074,10 +4061,6 @@ Self-explanatory. :dd
Self-explanatory. :dd
{Fix ID for fix ave/spatial does not exist} :dt
Self-explanatory. :dd
{Fix ID for fix ave/time does not exist} :dt
Self-explanatory. :dd
@ -4379,51 +4362,6 @@ same style. :dd
Self-explanatory. :dd
{Fix ave/spatial compute does not calculate a per-atom array} :dt
Self-explanatory. :dd
{Fix ave/spatial compute does not calculate a per-atom vector} :dt
A compute used by fix ave/spatial must generate per-atom values. :dd
{Fix ave/spatial compute does not calculate per-atom values} :dt
A compute used by fix ave/spatial must generate per-atom values. :dd
{Fix ave/spatial compute vector is accessed out-of-range} :dt
The index for the vector is out of bounds. :dd
{Fix ave/spatial fix does not calculate a per-atom array} :dt
Self-explanatory. :dd
{Fix ave/spatial fix does not calculate a per-atom vector} :dt
A fix used by fix ave/spatial must generate per-atom values. :dd
{Fix ave/spatial fix does not calculate per-atom values} :dt
A fix used by fix ave/spatial must generate per-atom values. :dd
{Fix ave/spatial fix vector is accessed out-of-range} :dt
The index for the vector is out of bounds. :dd
{Fix ave/spatial for triclinic boxes requires units reduced} :dt
Self-explanatory. :dd
{Fix ave/spatial settings invalid with changing box size} :dt
If the box size changes, only the units reduced option can be
used. :dd
{Fix ave/spatial variable is not atom-style variable} :dt
A variable used by fix ave/spatial must generate per-atom values. :dd
{Fix ave/time cannot set output array intensive/extensive from these inputs} :dt
One of more of the vector inputs has individual elements which are

18
doc/src/Errors_warnings.txt
View File

@ -291,24 +291,6 @@ This may cause accuracy problems. :dd
This may cause accuracy problems. :dd
{Fix thermal/conductivity comes before fix ave/spatial} :dt
The order of these 2 fixes in your input script is such that fix
thermal/conductivity comes first. If you are using fix ave/spatial to
measure the temperature profile induced by fix viscosity, then this
may cause a glitch in the profile since you are averaging immediately
after swaps have occurred. Flipping the order of the 2 fixes
typically helps. :dd
{Fix viscosity comes before fix ave/spatial} :dt
The order of these 2 fixes in your input script is such that
fix viscosity comes first. If you are using fix ave/spatial
to measure the velocity profile induced by fix viscosity, then
this may cause a glitch in the profile since you are averaging
immediately after swaps have occurred. Flipping the order
of the 2 fixes typically helps. :dd
{Fixes cannot send data in Kokkos communication, switching to classic communication} :dt
This is current restriction with Kokkos. :dd

45
doc/src/Howto_chunk.txt
View File

@ -22,7 +22,7 @@ commands, to calculate various properties of a system:
"fix ave/chunk"_fix_ave_chunk.html
any of the "compute */chunk"_compute.html commands :ul
Here, each of the 3 kinds of chunk-related commands is briefly
Here, each of the 4 kinds of chunk-related commands is briefly
overviewed. Then some examples are given of how to compute different
properties with chunk commands.
@ -83,8 +83,9 @@ chunk.
Compute */chunk commands: :h4
Currently the following computes operate on chunks of atoms to produce
per-chunk values.
The following computes operate on chunks of atoms to produce per-chunk
values. Any compute whose style name ends in "/chunk" is in this
category:
"compute com/chunk"_compute_com_chunk.html
"compute gyration/chunk"_compute_gyration_chunk.html
@ -111,8 +112,8 @@ of a center of mass, which requires summing mass*position over the
atoms and then dividing by summed mass.
All of these computes produce a global vector or global array as
output, wih one or more values per chunk. They can be used
in various ways:
output, wih one or more values per chunk. The output can be used in
various ways:
As input to the "fix ave/time"_fix_ave_time.html command, which can
write the values to a file and optionally time average them. :ulb,l
@ -122,9 +123,27 @@ histogram values across chunks. E.g. a histogram of cluster sizes or
molecule diffusion rates. :l
As input to special functions of "equal-style
variables"_variable.html, like sum() and max(). E.g. to find the
largest cluster or fastest diffusing molecule. :l
:ule
variables"_variable.html, like sum() and max() and ave(). E.g. to
find the largest cluster or fastest diffusing molecule or average
radius-of-gyration of a set of molecules (chunks). :l,ule
Other chunk commands: :h4
"compute chunk/spread/atom"_compute_chunk_spread_atom.html
"compute reduce/chunk"_compute_reduce_chunk.html :ul
The "compute chunk/spread/atom"_compute_chunk_spread_atom.html command
spreads per-chunk values to each atom in the chunk, producing per-atom
values as its output. This can be useful for outputting per-chunk
values to a per-atom "dump file"_dump.html. Or for using an atom's
associated chunk value in an "atom-style variable"_variable.html.
The "compute reduce/chunk"_compute_reduce_chunk.html command reduces a
peratom value across the atoms in each chunk to produce a value per
chunk. When used with the "compute
chunk/spread/atom"_compute_chunk_spread_atom.html command it can
create peratom values that induce a new set of chunks with a second
"compute chunk/atom"_compute_chunk_atom.html command.
Example calculations with chunks :h4
@ -164,3 +183,13 @@ compute cluster all cluster/atom 1.0
compute cc1 all chunk/atom c_cluster compress yes
compute size all property/chunk cc1 count
fix 1 all ave/histo 100 1 100 0 20 20 c_size mode vector ave running beyond ignore file tmp.histo :pre
(6) An example of using a per-chunk value to apply per-atom forces to
compress individual polymer chains (molecules) in a mixture, is
explained on the "compute
chunk/spread/atom"_compute_chunk_spread_atom.html command doc page.
(7) An example of using one set of per-chunk values for molecule
chunks, to create a 2nd set of micelle-scale chunks (clustered
molecules, due to hydrophobicity), is explained on the "compute
chunk/reduce"_compute_reduce_chunk.html command doc page.

6
doc/src/Howto_client_server.txt
View File

@ -7,7 +7,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
:line
Using LAMMPS in client/server mode
Using LAMMPS in client/server mode :h3
Client/server coupling of two codes is where one code is the "client"
and sends request messages to a "server" code. The server responds to
@ -61,7 +61,7 @@ client or server.
"message"_message.html
"fix client md"_fix_client_md.html = LAMMPS is a client for running MD
"server md"_server_md.html = LAMMPS is a server for computing MD forces
"server mc"_server_mc.html = LAMMPS is a server for computing a Monte Carlo energy
"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.
@ -119,7 +119,7 @@ For message exchange in {mpi/one} mode:
Launch both codes in a single mpirun command:
mpirun -np 2 lmp_mpi -mpicolor 0 -in in.message.client -log log.client : -np 4 lmp_mpi -mpicolor 1 -in in.message.server -log log.server
mpirun -np 2 lmp_mpi -mpicolor 0 -in in.message.client -log log.client : -np 4 lmp_mpi -mpicolor 1 -in in.message.server -log log.server :pre
The two -np values determine how many procs the client and the server
run on.

11
doc/src/Howto_nemd.txt
View File

@ -24,6 +24,11 @@ by subtracting out the streaming velocity of the shearing atoms. The
velocity profile or other properties of the fluid can be monitored via
the "fix ave/chunk"_fix_ave_chunk.html command.
NOTE: A recent (2017) book by "(Daivis and Todd)"_#Daivis-nemd
discusses use of the SLLOD method and non-equilibrium MD (NEMD)
thermostatting generally, for both simple and complex fluids,
e.g. molecular systems. The latter can be tricky to do correctly.
As discussed in the previous section on non-orthogonal simulation
boxes, the amount of tilt or skew that can be applied is limited by
LAMMPS for computational efficiency to be 1/2 of the parallel box
@ -46,3 +51,9 @@ An alternative method for calculating viscosities is provided via the
NEMD simulations can also be used to measure transport properties of a fluid
through a pore or channel. Simulations of steady-state flow can be performed
using the "fix flow/gauss"_fix_flow_gauss.html command.
:line
:link(Daivis-nemd)
[(Daivis and Todd)] Daivis and Todd, Nonequilibrium Molecular Dyanmics (book),
Cambridge University Press, https://doi.org/10.1017/9781139017848, (2017).

11
doc/src/Howto_thermostat.txt
View File

@ -43,6 +43,11 @@ nvt/asphere"_fix_nvt_asphere.html thermostat not only translation
velocities but also rotational velocities for spherical and aspherical
particles.
NOTE: A recent (2017) book by "(Daivis and Todd)"_#Daivis-thermostat
discusses use of the SLLOD method and non-equilibrium MD (NEMD)
thermostatting generally, for both simple and complex fluids,
e.g. molecular systems. The latter can be tricky to do correctly.
DPD thermostatting alters pairwise interactions in a manner analogous
to the per-particle thermostatting of "fix
langevin"_fix_langevin.html.
@ -87,3 +92,9 @@ specify them explicitly via the "thermo_style
custom"_thermo_style.html command. Or you can use the
"thermo_modify"_thermo_modify.html command to re-define what
temperature compute is used for default thermodynamic output.
:line
:link(Daivis-thermostat)
[(Daivis and Todd)] Daivis and Todd, Nonequilibrium Molecular Dyanmics (book),
Cambridge University Press, https://doi.org/10.1017/9781139017848, (2017).

11
doc/src/Howto_viscosity.txt
View File

@ -37,6 +37,11 @@ used to shear the fluid in between them, again with some kind of
thermostat that modifies only the thermal (non-shearing) components of
velocity to prevent the fluid from heating up.
NOTE: A recent (2017) book by "(Daivis and Todd)"_#Daivis-viscosity
discusses use of the SLLOD method and non-equilibrium MD (NEMD)
thermostatting generally, for both simple and complex fluids,
e.g. molecular systems. The latter can be tricky to do correctly.
In both cases, the velocity profile setup in the fluid by this
procedure can be monitored by the "fix ave/chunk"_fix_ave_chunk.html
command, which determines grad(Vstream) in the equation above.
@ -131,3 +136,9 @@ mean-square-displacement formulation for self-diffusivity. The
time-integrated momentum fluxes play the role of Cartesian
coordinates, whose mean-square displacement increases linearly
with time at sufficiently long times.
:line
:link(Daivis-viscosity)
[(Daivis and Todd)] Daivis and Todd, Nonequilibrium Molecular Dyanmics (book),
Cambridge University Press, https://doi.org/10.1017/9781139017848, (2017).

109
doc/src/Install_linux.txt
View File

@ -9,39 +9,16 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
Download an executable for Linux :h3
Binaries are available for many different versions of Linux:
Binaries are available for different versions of Linux:
"Pre-built binary RPMs for Fedora/RedHat/CentOS/openSUSE"_#rpm
"Pre-built Ubuntu Linux executables"_#ubuntu
"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)
:line
Pre-built binary RPMs for Fedora/RedHat/CentOS/openSUSE :h4,link(rpm)
Pre-built LAMMPS executables for various Linux distributions
can be downloaded as binary RPM files from this site:
"http://rpm.lammps.org"_http://rpm.lammps.org
There are multiple package variants supporting serial, parallel and
Python wrapper versions. The LAMMPS binaries contain all optional
packages included in the source distribution except: GPU, KIM, REAX,
and USER-INTEL.
Installation instructions for the various versions are here:
"http://rpm.lammps.org/install.html"_http://rpm.lammps.org/install.html
The instructions show how to enable the repository in the respective
system's package management system. Installing and updating are then
straightforward and automatic.
Thanks to Axel Kohlmeyer (Temple U, akohlmey at gmail.com) for setting
up this RPM capability.
:line
Pre-built Ubuntu Linux executables :h4,link(ubuntu)
A pre-built LAMMPS executable suitable for running on the latest
@ -60,10 +37,10 @@ To install LAMMPS do the following once:
sudo apt-get install lammps-daily :pre
This downloads an executable named "lammps-daily" to your box, which
This downloads an executable named "lmp_daily" to your box, which
can then be used in the usual way to run input scripts:
lammps-daily < in.lj :pre
lmp_daily -in in.lj :pre
To update LAMMPS to the most current version, do the following:
@ -99,6 +76,80 @@ Ubuntu package capability.
:line
Pre-built Fedora Linux executables :h4,link(fedora)
Pre-built LAMMPS packages for stable releases are available
in the Fedora Linux distribution as of version 28. The packages
can be installed via the dnf package manager. There are 3 basic
varieties (lammps = no MPI, lammps-mpich = MPICH MPI library,
lammps-openmpi = OpenMPI MPI library) and for each support for
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
("module load mpi/mpich-x86_64" or "module load mpi/openmpi-x86_64").
Then the corresponding parallel LAMMPS executable is 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:
dnf install lammps-openmpi
module load mpi/openmpi-x86_64
mpirun -np 2 lmp -in in.lj :pre
The "dnf install" command is needed only once. In case of a new LAMMPS
stable release, "dnf update" will automatically update to the newer
version as soon at the RPM files are built and uploaded to the download
mirrors. The "module load" command is needed once per (shell) session
or shell terminal instance, unless it is automatically loaded from the
shell profile.
Please use "lmp -help" to see which compilation options, packages,
and styles are included in the binary.
Thanks to Christoph Junghans (LANL) for making LAMMPS available in Fedora.
:line
Pre-built EPEL Linux executable :h4,link(epel)
Pre-built LAMMPS packages for stable releases are available
in the "Extra Packages for Enterprise Linux (EPEL) repository"_https://fedoraproject.org/wiki/EPEL
for use with Red Hat Enterprise Linux (RHEL) or CentOS version 7.x
and compatible Linux distributions. Names of packages, executable,
and content are the same as described above for Fedora Linux.
But RHEL/CentOS 7.x uses the "yum" package manager instead of "dnf"
in Fedora 28.
Please use "lmp -help" to see which compilation options, packages,
and styles are included in the binary.
Thanks to Christoph Junghans (LANL) for making LAMMPS available in EPEL.
:line
Pre-built OpenSuse Linux executable :h4,link(opensuse)
A pre-built LAMMPS package for stable releases is available
in OpenSuse as of Leap 15.0. You can install the package with:
zypper install lammps :pre
This includes support for OpenMPI. The name of the LAMMPS executable
is {lmp}. Thus to run an input in parallel on 2 CPUs you would do:
mpirun -np 2 lmp -in in.lj :pre
Please use "lmp -help" to see which compilation options, packages,
and styles are included in the binary.
Thanks to Christoph Junghans (LANL) for making LAMMPS available in OpenSuse.
:line
Pre-built Gentoo Linux executable :h4,link(gentoo)
LAMMPS is part of Gentoo's main package tree and can be installed by

6
doc/src/Install_tarball.txt
View File

@ -7,7 +7,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
:line
Download source as a tarball :h3
Download source and documentation as a tarball :h3
You can download a current LAMMPS tarball from the "download page"_download
of the "LAMMPS website"_lws.
@ -22,6 +22,10 @@ few times per year, and undergo more testing before release. Patch
releases occur a couple times per month. The new contents in all
releases are listed on the "bug and feature page"_bug of the website.
Both tarballs include LAMMPS documentation (HTML and PDF files)
corresponding to that version. The download page also has an option
to download the current-version LAMMPS documentation by itself.
Older versions of LAMMPS can also be downloaded from "this
page"_older.

4
doc/src/Manual.txt
View File

@ -1,7 +1,7 @@
<!-- HTML_ONLY -->
<HEAD>
<TITLE>LAMMPS Users Manual</TITLE>
<META NAME="docnumber" CONTENT="31 Aug 2018 version">
<META NAME="docnumber" CONTENT="10 Oct 2018 version">
<META NAME="author" CONTENT="http://lammps.sandia.gov - Sandia National Laboratories">
<META NAME="copyright" CONTENT="Copyright (2003) Sandia Corporation. This software and manual is distributed under the GNU General Public License.">
</HEAD>
@ -21,7 +21,7 @@
:line
LAMMPS Documentation :c,h1
31 Aug 2018 version :c,h2
10 Oct 2018 version :c,h2
"What is a LAMMPS version?"_Manual_version.html

56
doc/src/Packages_details.txt
View File

@ -46,6 +46,7 @@ as contained in the file name.
"MANYBODY"_#PKG-MANYBODY,
"MC"_#PKG-MC,
"MEAM"_#PKG-MEAM,
"MESSAGE"_#PKG-MESSAGE,
"MISC"_#PKG-MISC,
"MOLECULE"_#PKG-MOLECULE,
"MPIIO"_#PKG-MPIIO,
@ -88,10 +89,12 @@ as contained in the file name.
"USER-NETCDF"_#PKG-USER-NETCDF,
"USER-OMP"_#PKG-USER-OMP,
"USER-PHONON"_#PKG-USER-PHONON,
"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-SMD"_#PKG-USER-SMD,
"USER-SMTBQ"_#PKG-USER-SMTBQ,
"USER-SPH"_#PKG-USER-SPH,
@ -1742,6 +1745,24 @@ examples/USER/phonon :ul
:line
USER-PTM package :link(PKG-USER-PTM),h4
[Contents:]
A "compute ptm/atom"_compute_ptm_atom.html command that calculates
local structure characterization using the Polyhedral Template
Matching methodology.
[Author:] Peter Mahler Larsen (MIT).
[Supporting info:]
src/USER-PTM: filename starting with ptm_ -> supporting code, other filenames -> commands
src/USER-PTM/LICENSE
"compute ptm/atom"_compute_ptm_atom.html :ul
:line
USER-QMMM package :link(PKG-USER-QMMM),h4
[Contents:]
@ -1859,6 +1880,41 @@ examples/reax :ul
:line
USER-SCAFACOS package :link(PKG-USER-SCAFACOS),h4
[Contents:]
A KSpace style which wraps the "ScaFaCoS Coulomb solver
library"_http://www.scafacos.de to compute long-range Coulombic
interactions.
To use this package you must have the ScaFaCoS library available on
your system.
[Author:] Rene Halver (JSC) wrote the scafacos LAMMPS command.
ScaFaCoS itself was developed by a consortium of German research
facilities with a BMBF (German Ministry of Science and Education)
funded project in 2009-2012. Participants of the consortium were the
Universities of Bonn, Chemnitz, Stuttgart, and Wuppertal as well as
the Forschungszentrum Juelich.
[Install:]
This package has "specific installation
instructions"_Build_extras.html#user-scafacos on the "Build
extras"_Build_extras.html doc page.
[Supporting info:]
src/USER-SCAFACOS: filenames -> commands
src/USER-SCAFACOS/README
"kspace_style scafacos"_kspace_style.html
"kspace_modify"_kspace_modify.html
examples/USER/scafacos :ul
:line
USER-SMD package :link(PKG-USER-SMD),h4
[Contents:]

2
doc/src/Packages_user.txt
View File

@ -62,10 +62,12 @@ 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-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-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

104
doc/src/Run_options.txt
View File

@ -24,8 +24,9 @@ letter abbreviation can be used:
"-p or -partition"_#partition
"-pl or -plog"_#plog
"-ps or -pscreen"_#pscreen
"-r or -restart"_#restart
"-ro or -reorder"_#reorder
"-r2data or -restart2data"_#restart2data
"-r2dump or -restart2dump"_#restart2dump
"-sc or -screen"_#screen
"-sf or -suffix"_#suffix
"-v or -var"_#var :ul
@ -176,7 +177,7 @@ Option -plog will override the name of the partition log files file.N.
:line
[-mpicolor] color :link(mpi)
[-mpicolor] color :link(mpicolor)
If used, this must be the first command-line argument after the LAMMPS
executable name. It is only used when LAMMPS is launched by an mpirun
@ -280,34 +281,6 @@ specified by the -screen command-line option.
:line
[-restart restartfile {remap} datafile keyword value ...] :link(restart)
Convert the restart file into a data file and immediately exit. This
is the same operation as if the following 2-line input script were
run:
read_restart restartfile {remap}
write_data datafile keyword value ... :pre
Note that the specified restartfile and datafile can have wild-card
characters ("*",%") as described by the
"read_restart"_read_restart.html and "write_data"_write_data.html
commands. But a filename such as file.* will need to be enclosed in
quotes to avoid shell expansion of the "*" character.
Note that following restartfile, the optional flag {remap} can be
used. This has the same effect as adding it to the
"read_restart"_read_restart.html command, as explained on its doc
page. This is only useful if the reading of the restart file triggers
an error that atoms have been lost. In that case, use of the remap
flag should allow the data file to still be produced.
Also note that following datafile, the same optional keyword/value
pairs can be listed as used by the "write_data"_write_data.html
command.
:line
[-reorder] :link(reorder)
This option has 2 forms:
@ -381,6 +354,77 @@ the LAMMPS simulation domain.
:line
[-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)
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
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 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.
The syntax following restartfile (or remap), namely
datafile keyword value ... :pre
is identical to the arguments of the "write_data"_write_data.html
command. See its doc page for details. This includes its
optional keyword/value settings.
:line
[-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)
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
"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.
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.
The syntax following restartfile (or remap), namely
group-ID dumpstyle dumpfile arg1 arg2 ... :pre
is identical to the arguments of the "write_dump"_write_dump.html
command. See its doc page for details. This includes what per-atom
fields are written to the dump file and optional dump_modify settings,
including ones that affect how parallel dump files are written, e.g.
the {nfile} and {fileper} keywords. See the
"dump_modify"_dump_modify.html doc page for details.
:line
[-screen file] :link(screen)
Specify a file for LAMMPS to write its screen information to. In

2
doc/src/Speed_intel.txt
View File

@ -499,7 +499,7 @@ MPI task.
When offloading to a coprocessor, "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.
accelerated style may be used with hybrid styles when offloading.
"Special_bonds"_special_bonds.html exclusion lists are not currently
supported with offload, however, the same effect can often be
accomplished by setting cutoffs for excluded atom types to 0. None of

21
doc/src/Speed_kokkos.txt
View File

@ -106,6 +106,11 @@ 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: The default for the "package kokkos"_package.html command is to
use "full" neighbor lists and set the Newton flag to "off" for both
pairwise and bonded interactions. However, when running on CPUs, it
@ -122,6 +127,22 @@ 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.
[Core and Thread Affinity:]
When using multi-threading, it is important for performance to bind

25
doc/src/angle_sdk.txt
View File

@ -7,6 +7,7 @@
:line
angle_style sdk command :h3
angle_style sdk/omp command :h3
[Syntax:]
@ -43,6 +44,30 @@ internally; hence the units of K are in energy/radian^2.
The also required {lj/sdk} parameters will be extracted automatically
from the pair_style.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed on the "Speed packages"_Speed_packages.html doc
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Build
package"_Build_package.html doc page for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
switch"_Run_options.html when you invoke LAMMPS, or you can use the
"suffix"_suffix.html command in your input script.
See the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This angle style can only be used if LAMMPS was built with the

2
doc/src/commands_list.txt
View File

@ -89,6 +89,8 @@ Commands :h1
run
run_style
server
server_mc
server_md
set
shell
special_bonds

2
doc/src/compute.txt
View File

@ -183,6 +183,7 @@ compute"_Commands_compute.html doc page are followed by one or more of
"bond/local"_compute_bond_local.html - distance and energy of each bond
"centro/atom"_compute_centro_atom.html - centro-symmetry parameter for each atom
"chunk/atom"_compute_chunk_atom.html - assign chunk IDs to each atom
"chunk/spread/atom"_compute_chunk_spread_atom.html - spreads chunk values to each atom in chunk
"cluster/atom"_compute_cluster_atom.html - cluster ID for each atom
"cna/atom"_compute_cna_atom.html - common neighbor analysis (CNA) for each atom
"com"_compute_com.html - center-of-mass of group of atoms
@ -225,6 +226,7 @@ compute"_Commands_compute.html doc page are followed by one or more of
"property/chunk"_compute_property_chunk.html - extract various per-chunk attributes
"rdf"_compute_rdf.html - radial distribution function g(r) histogram of group of atoms
"reduce"_compute_reduce.html - combine per-atom quantities into a single global value
"reduce/chunk"_compute_reduce_chunk.html - reduce per-atom quantities within each chunk
"reduce/region"_compute_reduce.html - same as compute reduce, within a region
"rigid/local"_compute_rigid_local.html - extract rigid body attributes
"slice"_compute_slice.html - extract values from global vector or array

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

@ -0,0 +1,213 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
compute adf command :h3
[Syntax:]
compute ID group-ID adf Nbin itype1 jtype1 ktype1 Rjinner1 Rjouter1 Rkinner1 Rkouter1 ... :pre
ID, group-ID are documented in "compute"_compute.html command :ulb,l
adf = style name of this compute command :l
Nbin = number of ADF bins :l
itypeN = central atom type for Nth ADF histogram (see asterisk form below) :l
jtypeN = J atom type for Nth ADF histogram (see asterisk form below) :l
ktypeN = K atom type for Nth ADF histogram (see asterisk form below) :l
RjinnerN = inner radius of J atom shell for Nth ADF histogram (distance units) :l
RjouterN = outer radius of J atom shell for Nth ADF histogram (distance units) :l
RkinnerN = inner radius of K atom shell for Nth ADF histogram (distance units) :l
RkouterN = outer radius of K atom shell for Nth ADF histogram (distance units) :l
zero or one keyword/value pairs may be appended :l
keyword = {ordinate} :l
{ordinate} value = {degree} or {radian} or {cosine}
Choose the ordinate parameter for the histogram :pre
:ule
[Examples:]
compute 1 fluid adf 32 1 1 1 0.0 1.2 0.0 1.2 &
1 1 2 0.0 1.2 0.0 1.5 &
1 2 2 0.0 1.5 0.0 1.5 &
2 1 1 0.0 1.2 0.0 1.2 &
2 1 2 0.0 1.5 2.0 3.5 &
2 2 2 2.0 3.5 2.0 3.5
compute 1 fluid adf 32 1*2 1*2 1*2 0.5 3.5
compute 1 fluid adf 32 :pre
[Description:]
Define a computation that calculates one or more angular distribution functions
(ADF) for a group of particles. Each ADF is calculated in histogram form
by measuring the angle formed by a central atom and two neighbor atoms and
binning these angles into {Nbin} bins.
Only neighbors for which {Rinner} < {R} < {Router} are counted, where
{Rinner} and {Router} are specified separately for the first and second
neighbor atom in each requested ADF.
NOTE: If you have a bonded system, then the settings of
"special_bonds"_special_bonds.html command can remove pairwise
interactions between atoms in the same bond, angle, or dihedral. This
is the default setting for the "special_bonds"_special_bonds.html
command, and means those pairwise interactions do not appear in the
neighbor list. Because this fix uses a neighbor list, it also means
those pairs will not be included in the ADF. This does not apply when
using long-range coulomb interactions ({coul/long}, {coul/msm},
{coul/wolf} or similar. One way to get around this would be to set
special_bond scaling factors to very tiny numbers that are not exactly
zero (e.g. 1.0e-50). Another workaround is to write a dump file, and
use the "rerun"_rerun.html command to compute the ADF for snapshots in
the dump file. The rerun script can use a
"special_bonds"_special_bonds.html command that includes all pairs in
the neighbor list.
NOTE: If you request any outer cutoff {Router} > force cutoff, or if no
pair style is defined, e.g. the "rerun"_rerun.html command is being used to
post-process a dump file of snapshots you must insure ghost atom information
out to the largest value of {Router} + {skin} is communicated, via the
"comm_modify cutoff"_comm_modify.html command, else the ADF computation
cannot be performed, and LAMMPS will give an error message. The {skin} value
is what is specified with the "neighbor"_neighbor.html command.
The {itypeN},{jtypeN},{ktypeN} settings can be specified in one of two
ways. An explicit numeric value can be used, as in the 1st example
above. Or a wild-card asterisk can be used to specify a range of atom
types as in the 2nd example above.
This takes the form "*" or "*n" or "n*" or "m*n". If N = the
number of atom types, then an asterisk with no numeric values means
all types from 1 to N. A leading asterisk means all types from 1 to n
(inclusive). A trailing asterisk means all types from n to N
(inclusive). A middle asterisk means all types from m to n
(inclusive).
If {itypeN}, {jtypeN}, and {ktypeN} are single values, as in the 1st example
above, this means that the ADF is computed where atoms of type {itypeN}
are the central atom, and neighbor atoms of type {jtypeN} and {ktypeN}
are forming the angle. If any of {itypeN}, {jtypeN}, or {ktypeN}
represent a range of values via
the wild-card asterisk, as in the 2nd example above, this means that the
ADF is computed where atoms of any of the range of types represented
by {itypeN} are the central atom, and the angle is formed by two neighbors,
one neighbor in the range of types represented by {jtypeN} and another neighbor
in the range of types represented by {ktypeN}.
If no {itypeN}, {jtypeN}, {ktypeN} settings are specified, then
LAMMPS will generate a single ADF for all atoms in the group.
The inner cutoff is set to zero and the outer cutoff is set
to the force cutoff. If no pair_style is specified, there is no
force cutoff and LAMMPS will give an error message. Note that
in most cases, generating an ADF for all atoms is not a good thing.
Such an ADF is both uninformative and
extremely expensive to compute. For example, with liquid water
with a 10 A force cutoff, there are 80,000 angles per atom.
In addition, most of the interesting angular structure occurs for
neighbors that are the closest to the central atom, involving
just a few dozen angles.
Angles for each ADF are generated by double-looping over the list of
neighbors of each central atom I,
just as they would be in the force calculation for
a threebody potential such as "Stillinger-Weber"_pair_sw.html.
The angle formed by central atom I and neighbor atoms J and K is included in an
ADF if the following criteria are met:
atoms I,J,K are all in the specified compute group
the distance between atoms I,J is between Rjinner and Rjouter
the distance between atoms I,K is between Rkinner and Rkouter
the type of the I atom matches itypeN (one or a range of types)
atoms I,J,K are distinct
the type of the J atom matches jtypeN (one or a range of types)
the type of the K atom matches ktypeN (one or a range of types) :ul
Each unique angle satisfying the above criteria is counted only once, regardless
of whether either or both of the neighbor atoms making up the
angle appear in both the J and K lists.
It is OK if a particular angle is included in more than
one individual histogram, due to the way the {itypeN}, {jtypeN}, {ktypeN}
arguments are specified.
The first ADF value for a bin is calculated from the histogram count by
dividing by the total number of triples satisfying the criteria,
so that the integral of the ADF w.r.t. angle is 1, i.e. the ADF
is a probability density function.
The second ADF value is reported as a cumulative sum of
all bins up to the current bins, averaged
over atoms of type {itypeN}. It represents the
number of angles per central atom with angle less
than or equal to the angle of the current bin,
analogous to the coordination
number radial distribution function.
The {ordinate} optional keyword determines
whether the bins are of uniform angular size from zero
to 180 ({degree}), zero to Pi ({radian}), or the
cosine of the angle uniform in the range \[-1,1\] ({cosine}).
{cosine} has the advantage of eliminating the {acos()} function
call, which speeds up the compute by 2-3x, and it is also preferred
on physical grounds, because the for uniformly distributed particles
in 3D, the angular probability density w.r.t dtheta is
sin(theta)/2, while for d(cos(theta)), it is 1/2,
Regardless of which ordinate is chosen, the first column of ADF
values is normalized w.r.t. the range of that ordinate, so that
the integral is 1.
The simplest way to output the results of the compute adf calculation
to a file is to use the "fix ave/time"_fix_ave_time.html command, for
example:
compute myADF all adf 32 2 2 2 0.5 3.5 0.5 3.5
fix 1 all ave/time 100 1 100 c_myADF\[*\] file tmp.adf mode vector :pre
[Output info:]
This compute calculates a global array with the number of rows =
{Nbins}, and the number of columns = 1 + 2*Ntriples, where Ntriples is the
number of I,J,K triples specified. The first column has the bin
coordinate (angle-related ordinate at midpoint of bin). Each subsequent column has
the two ADF values for a specific set of ({itypeN},{jtypeN},{ktypeN})
interactions, as described above. These values can be used
by any command that uses a global values from a compute as input. See
the "Howto output"_Howto_output.html doc page for an overview of
LAMMPS output options.
The array values calculated by this compute are all "intensive".
The first column of array values is the angle-related ordinate, either
the angle in degrees or radians, or the cosine of the angle. Each
subsequent pair of columns gives the first and second kinds of ADF
for a specific set of ({itypeN},{jtypeN},{ktypeN}). The values
in the first ADF column are normalized numbers >= 0.0,
whose integral w.r.t. the ordinate is 1,
i.e. the first ADF is a normalized probability distribution.
The values in the second ADF column are also numbers >= 0.0.
They are the cumulative density distribution of angles per atom.
By definition, this ADF is monotonically increasing from zero to
a maximum value equal to the average total number of
angles per atom satisfying the ADF criteria.
[Restrictions:]
The ADF is not computed for neighbors outside the force cutoff,
since processors (in parallel) don't know about atom coordinates for
atoms further away than that distance. If you want an ADF for larger
distances, you can use the "rerun"_rerun.html command to post-process
a dump file and set the cutoff for the potential to be longer in the
rerun script. Note that in the rerun context, the force cutoff is
arbitrary, since you aren't running dynamics and thus are not changing
your model.
[Related commands:]
"compute rdf"_compute_rdf.html, "fix ave/time"_fix_ave_time.html, "compute_modify"_compute_modify.html
[Default:]
The keyword default is ordinate = degree.

66
doc/src/compute_angle_local.txt
View File

@ -10,20 +10,27 @@ compute angle/local command :h3
[Syntax:]
compute ID group-ID angle/local value1 value2 ... :pre
compute ID group-ID angle/local value1 value2 ... keyword args ... :pre
ID, group-ID are documented in "compute"_compute.html command :ulb,l
angle/local = style name of this compute command :l
one or more values may be appended :l
value = {theta} or {eng} :l
value = {theta} or {eng} or {v_name} :l
{theta} = tabulate angles
{eng} = tabulate angle energies :pre
{eng} = tabulate angle energies
{v_name} = equal-style variable with name (see below) :pre
zero or more keyword/args pairs may be appended :l
keyword = {set} :l
{set} args = theta name
theta = only currently allowed arg
name = name of variable to set with theta :pre
:ule
[Examples:]
compute 1 all angle/local theta
compute 1 all angle/local eng theta :pre
compute 1 all angle/local eng theta
compute 1 all angle/local theta v_cos set theta t :pre
[Description:]
@ -36,6 +43,47 @@ The value {theta} is the angle for the 3 atoms in the interaction.
The value {eng} is the interaction energy for the angle.
The value {v_name} can be used together with the {set} keyword to
compute a user-specified function of the angle theta. The {name}
specified for the {v_name} value is the name of an "equal-style
variable"_variable.html which should evaluate a formula based on a
variable which will store the angle theta. This other variable must
be an "internal-style variable"_variable.html defined in the input
script; its initial numeric value can be anything. It must be an
internal-style variable, because this command resets its value
directly. The {set} keyword is used to identify the name of this
other variable associated with theta.
Note that the value of theta for each angle which stored in the
internal variable is in radians, not degrees.
As an example, these commands can be added to the bench/in.rhodo
script to compute the cosine and cosine^2 of every angle in the system
and output the statistics in various ways:
variable t internal 0.0
variable cos equal cos(v_t)
variable cossq equal cos(v_t)*cos(v_t) :pre
compute 1 all property/local aatom1 aatom2 aatom3 atype
compute 2 all angle/local eng theta v_cos v_cossq set theta t
dump 1 all local 100 tmp.dump c_1[*] c_2[*] :pre
compute 3 all reduce ave c_2[*]
thermo_style custom step temp press c_3[*] :pre
fix 10 all ave/histo 10 10 100 -1 1 20 c_2[3] mode vector file tmp.histo :pre
The "dump local"_dump.html command will output the energy, angle,
cosine(angle), cosine^2(angle) for every angle in the system. The
"thermo_style"_thermo_style.html command will print the average of
those quantities via the "compute reduce"_compute_reduce.html command
with thermo output. And the "fix ave/histo"_fix_ave_histo.html
command will histogram the cosine(angle) values and write them to a
file.
:line
The local data stored by this command is generated by looping over all
the atoms owned on a processor and their angles. An angle will only
be included if all 3 atoms in the angle are in the specified compute
@ -65,12 +113,12 @@ dump 1 all local 1000 tmp.dump index c_1\[1\] c_1\[2\] c_1\[3\] c_1\[4\] c_2\[1\
[Output info:]
This compute calculates a local vector or local array depending on the
number of keywords. The length of the vector or number of rows in the
array is the number of angles. If a single keyword is specified, a
local vector is produced. If two or more keywords are specified, a
number of values. The length of the vector or number of rows in the
array is the number of angles. If a single value is specified, a
local vector is produced. If two or more values are specified, a
local array is produced where the number of columns = the number of
keywords. The vector or array can be accessed by any command that
uses local values from a compute as input. See the "Howto
values. The vector or array can be accessed by any command that uses
local values from a compute as input. See the "Howto
output"_Howto_output.html doc page for an overview of LAMMPS output
options.

69
doc/src/compute_bond_local.txt
View File

@ -10,12 +10,12 @@ compute bond/local command :h3
[Syntax:]
compute ID group-ID bond/local value1 value2 ... :pre
compute ID group-ID bond/local value1 value2 ... keyword args ... :pre
ID, group-ID are documented in "compute"_compute.html command :ulb,l
bond/local = style name of this compute command :l
one or more values may be appended :l
value = {dist} or {engpot} or {force} or {engvib} or {engrot} or {engtrans} or {omega} or {velvib} :l
value = {dist} or {engpot} or {force} or {engvib} or {engrot} or {engtrans} or {omega} or {velvib} or {v_name} :l
{dist} = bond distance
{engpot} = bond potential energy
{force} = bond force :pre
@ -23,13 +23,22 @@ value = {dist} or {engpot} or {force} or {engvib} or {engrot} or {engtrans} or {
{engrot} = bond kinetic energy of rotation
{engtrans} = bond kinetic energy of translation
{omega} = magnitude of bond angular velocity
{velvib} = vibrational velocity along the bond length :pre
{velvib} = vibrational velocity along the bond length
{v_name} = equal-style variable with name (see below) :pre
zero or more keyword/args pairs may be appended :l
keyword = {set} :l
{set} args = dist name
dist = only currently allowed arg
name = name of variable to set with distance (dist) :pre
:ule
:ule
[Examples:]
compute 1 all bond/local engpot
compute 1 all bond/local dist engpot force :pre
compute 1 all angle/local dist v_distsq set dist d :pre
[Description:]
@ -38,6 +47,10 @@ interactions. The number of datums generated, aggregated across all
processors, equals the number of bonds in the system, modified by the
group parameter as explained below.
All these properties are computed for the pair of atoms in a bond,
whether the 2 atoms represent a simple diatomic molecule, or are part
of some larger molecule.
The value {dist} is the current length of the bond.
The value {engpot} is the potential energy for the bond,
@ -79,9 +92,41 @@ two atoms in the bond towards each other. A negative value means the
2 atoms are moving toward each other; a positive value means they are
moving apart.
Note that all these properties are computed for the pair of atoms in a
bond, whether the 2 atoms represent a simple diatomic molecule, or are
part of some larger molecule.
The value {v_name} can be used together with the {set} keyword to
compute a user-specified function of the bond distance. The {name}
specified for the {v_name} value is the name of an "equal-style
variable"_variable.html which should evaluate a formula based on a
variable which will store the bond distance. This other variable must
be an "internal-style variable"_variable.html defined in the input
script; its initial numeric value can be anything. It must be an
internal-style variable, because this command resets its value
directly. The {set} keyword is used to identify the name of this
other variable associated with theta.
As an example, these commands can be added to the bench/in.rhodo
script to compute the distance^2 of every bond in the system and
output the statistics in various ways:
variable d internal 0.0
variable dsq equal v_d*v_d :pre
compute 1 all property/local batom1 batom2 btype
compute 2 all bond/local engpot dist v_dsq set dist d
dump 1 all local 100 tmp.dump c_1[*] c_2[*] :pre
compute 3 all reduce ave c_2[*]
thermo_style custom step temp press c_3[*] :pre
fix 10 all ave/histo 10 10 100 0 6 20 c_2[3] mode vector file tmp.histo :pre
The "dump local"_dump.html command will output the energy, distance,
distance^2 for every bond in the system. The
"thermo_style"_thermo_style.html command will print the average of
those quantities via the "compute reduce"_compute_reduce.html command
with thermo output. And the "fix ave/histo"_fix_ave_histo.html
command will histogram the distance^2 values and write them to a file.
:line
The local data stored by this command is generated by looping over all
the atoms owned on a processor and their bonds. A bond will only be
@ -111,12 +156,12 @@ dump 1 all local 1000 tmp.dump index c_1\[*\] c_2\[*\] :pre
[Output info:]
This compute calculates a local vector or local array depending on the
number of keywords. The length of the vector or number of rows in the
array is the number of bonds. If a single keyword is specified, a
local vector is produced. If two or more keywords are specified, a
local array is produced where the number of columns = the number of
keywords. The vector or array can be accessed by any command that
uses local values from a compute as input. See the "Howto
number of values. The length of the vector or number of rows in the
array is the number of bonds. If a single value is specified, a local
vector is produced. If two or more values are specified, a local
array is produced where the number of columns = the number of values.
The vector or array can be accessed by any command that uses local
values from a compute as input. See the "Howto
output"_Howto_output.html doc page for an overview of LAMMPS output
options.

11
doc/src/compute_chunk_atom.txt
View File

@ -14,7 +14,7 @@ compute ID group-ID chunk/atom style args keyword values ... :pre
ID, group-ID are documented in "compute"_compute.html command :ulb,l
chunk/atom = style name of this compute command :l
style = {bin/1d} or {bin/2d} or {bin/3d} or {bin/sphere} or {type} or {molecule} or {compute/fix/variable}
style = {bin/1d} or {bin/2d} or {bin/3d} or {bin/sphere} or {type} or {molecule} or c_ID, c_ID\[I\], f_ID, f_ID\[I\], v_name
{bin/1d} args = dim origin delta
dim = {x} or {y} or {z}
origin = {lower} or {center} or {upper} or coordinate value (distance units)
@ -40,7 +40,7 @@ style = {bin/1d} or {bin/2d} or {bin/3d} or {bin/sphere} or {type} or {molecule}
ncbin = # of concentric circle bins between rmin and rmax
{type} args = none
{molecule} args = none
{compute/fix/variable} = c_ID, c_ID\[I\], f_ID, f_ID\[I\], v_name with no args
c_ID, c_ID\[I\], f_ID, f_ID\[I\], v_name args = none
c_ID = per-atom vector calculated by a compute with ID
c_ID\[I\] = Ith column of per-atom array calculated by a compute with ID
f_ID = per-atom vector calculated by a fix with ID
@ -85,7 +85,8 @@ compute 1 all chunk/atom bin/1d z lower 0.02 units reduced
compute 1 all chunk/atom bin/2d z lower 1.0 y 0.0 2.5
compute 1 all chunk/atom molecule region sphere nchunk once ids once compress yes
compute 1 all chunk/atom bin/sphere 5 5 5 2.0 5.0 5 discard yes
compute 1 all chunk/atom bin/cylinder z lower 2 10 10 2.0 5.0 3 discard yes :pre
compute 1 all chunk/atom bin/cylinder z lower 2 10 10 2.0 5.0 3 discard yes
compute 1 all chunk/atom c_cluster :pre
[Description:]
@ -386,8 +387,8 @@ described below, which resets {Nchunk}. The {limit} keyword is then
applied to the new {Nchunk} value, exactly as described in the
preceding paragraph. Note that in this case, all atoms will end up
with chunk IDs <= {Nc}, but their original values (e.g. molecule ID or
compute/fix/variable value) may have been > {Nc}, because of the
compression operation.
compute/fix/variable) may have been > {Nc}, because of the compression
operation.
If {compress yes} is set, and the {compress} keyword comes after the
{limit} keyword, then the {limit} value of {Nc} is applied first to

174
doc/src/compute_chunk_spread_atom.txt Normal file
View File

@ -0,0 +1,174 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
compute chunk/spread/atom command :h3
[Syntax:]
compute ID group-ID chunk/spread/atom chunkID input1 input2 ... :pre
ID, group-ID are documented in "compute"_compute.html command :ulb,l
chunk/spread/atom = style name of this compute command :l
chunkID = ID of "compute chunk/atom"_compute_chunk_atom.html command :l
one or more inputs can be listed :l
input = c_ID, c_ID\[N\], f_ID, f_ID\[N\] :l
c_ID = global vector calculated by a compute with ID
c_ID\[I\] = Ith column of global array calculated by a compute with ID, I can include wildcard (see below)
f_ID = global vector calculated by a fix with ID
f_ID\[I\] = Ith column of global array calculated by a fix with ID, I can include wildcard (see below) :pre
:ule
[Examples:]
compute 1 all chunk/spread/atom mychunk c_com[*] c_gyration :pre
[Description:]
Define a calculation that "spreads" one or more per-chunk values to
each atom in the chunk. This can be useful for creating a "dump
file"_dump.html where each atom lists info about the chunk it is in,
e.g. for post-processing purposes. It can also be used in "atom-style
variables"_variable.html that need info about the chunk each atom is
in. Examples are given below.
In LAMMPS, chunks are collections of atoms defined by a "compute
chunk/atom"_compute_chunk_atom.html command, which assigns each atom
to a single chunk (or no chunk). The ID for this command is specified
as chunkID. For example, a single chunk could be the atoms in a
molecule or atoms in a spatial bin. See the "compute
chunk/atom"_compute_chunk_atom.html and "Howto chunk"_Howto_chunk.html
doc pages for details of how chunks can be defined and examples of how
they can be used to measure properties of a system.
For inputs that are computes, they must be a compute that calculates
per-chunk values. These are computes whose style names end in
"/chunk".
For inputs that are fixes, they should be a a fix that calculates
per-chunk values. For example, "fix ave/chunk"_fix_ave_chunk.html or
"fix ave/time"_fix_ave_time.html (assuming it is time-averaging
per-chunk data).
For each atom, this compute accesses its chunk ID from the specified
{chunkID} compute, then accesses the per-chunk value in each input.
Those values are copied to this compute to become the output for that
atom.
The values generated by this compute will be 0.0 for atoms not in the
specified compute group {group-ID}. They will also be 0.0 if the atom
is not in a chunk, as assigned by the {chunkID} compute. They will
also be 0.0 if the current chunk ID for the atom is out-of-bounds with
respect to the number of chunks stored by a particular input compute
or fix.
NOTE: LAMMPS does not check that a compute or fix which calculates
per-chunk values uses the same definition of chunks as this compute.
It's up to you to be consistent. Likewise, for a fix input, LAMMPS
does not check that it is per-chunk data. It only checks that the fix
produces a global vector or array.
:line
Each listed input is operated on independently.
If a bracketed index I is used, it can be specified using a wildcard
asterisk with the index to effectively specify multiple values. This
takes the form "*" or "*n" or "n*" or "m*n". If N = the number of
columns in the array, then an asterisk with no numeric values means
all indices from 1 to N. A leading asterisk means all indices from 1
to n (inclusive). A trailing asterisk means all indices from n to N
(inclusive). A middle asterisk means all indices from m to n
(inclusive).
Using a wildcard is the same as if the individual columns of the array
had been listed one by one. E.g. these 2 compute chunk/spread/atom
commands are equivalent, since the "compute
com/chunk"_compute_com_chunk.html command creates a per-atom array
with 3 columns:
compute com all com/chunk mychunk
compute 10 all chunk/spread/atom mychunk c_com\[*\]
compute 10 all chunk/spread/atom mychunk c_com\[1\] c_com\[2\] c_com\[3\] :pre
:line
Here is an example of writing a dump file the with the center-of-mass
(COM) for the chunk each atom is in. The commands below can be added
to the bench/in.chain script.
compute cmol all chunk/atom molecule
compute com all com/chunk cmol
compute comchunk all chunk/spread/atom cmol c_com[*]
dump 1 all custom 50 tmp.dump id mol type x y z c_comchunk[*]
dump_modify 1 sort id :pre
The same per-chunk data for each atom could be used to define per-atom
forces for the "fix addforce"_fix_addforce.html command. In this
example the forces act to pull atoms of an extended polymer chain
towards its COM in an attractive manner.
compute prop all property/atom xu yu zu
variable k equal 0.1
variable fx atom v_k*(c_comchunk\[1\]-c_prop\[1\])
variable fy atom v_k*(c_comchunk\[2\]-c_prop\[2\])
variable fz atom v_k*(c_comchunk\[3\]-c_prop\[3\])
fix 3 all addforce v_fx v_fy v_fz :pre
Note that "compute property/atom"_compute_property_atom.html is used
to generate unwrapped coordinates for use in the per-atom force
calculation, so that the effect of periodic boundaries is accounted
for properly.
Over time this applied force could shrink each polymer chain's radius
of gyration in a polymer mixture simulation. Here is output from the
bench/in.chain script. Thermo output is shown for 1000 steps, where
the last column is the average radius of gyration over all 320 chains
in the 32000 atom system:
compute gyr all gyration/chunk cmol
variable ave equal ave(c_gyr)
thermo_style custom step etotal press v_ave :pre
0 22.394765 4.6721833 5.128278
100 22.445002 4.8166709 5.0348372
200 22.500128 4.8790392 4.9364875
300 22.534686 4.9183766 4.8590693
400 22.557196 4.9492211 4.7937849
500 22.571017 4.9161853 4.7412008
600 22.573944 5.0229708 4.6931243
700 22.581804 5.0541301 4.6440647
800 22.584683 4.9691734 4.6000016
900 22.59128 5.0247538 4.5611513
1000 22.586832 4.94697 4.5238362 :pre
:line
[Output info:]
This compute calculates a per-atom vector or array, which can be
accessed by any command that uses per-atom values from a compute as
input. See the "Howto output"_Howto_output.html doc page for an
overview of LAMMPS output options.
The output is a per-atom vector if a single input value is specified,
otherwise a per-atom array is output. The number of columns in the
array is the number of inputs provided. The per-atom values for the
vector or each column of the array will be in whatever
"units"_units.html the corresponding input value is in.
The vector or array values are "intensive".
[Restrictions:] none
[Related commands:]
"compute chunk/atom"_compute_chunk_atom.html, "fix
ave/chunk"_fix_ave_chunk.html, "compute
reduce/chunk"_compute_reduce_chunk.html
[Default:] none

64
doc/src/compute_dihedral_local.txt
View File

@ -10,18 +10,25 @@ compute dihedral/local command :h3
[Syntax:]
compute ID group-ID dihedral/local value1 value2 ... :pre
compute ID group-ID dihedral/local value1 value2 ... keyword args ... :pre
ID, group-ID are documented in "compute"_compute.html command :ulb,l
dihedral/local = style name of this compute command :l
one or more values may be appended :l
value = {phi} :l
{phi} = tabulate dihedral angles :pre
value = {phi} or {v_name} :l
{phi} = tabulate dihedral angles
{v_name} = equal-style variable with name (see below) :pre
zero or more keyword/args pairs may be appended :l
keyword = {set} :l
{set} args = phi name
phi = only currently allowed arg
name = name of variable to set with phi :pre
:ule
[Examples:]
compute 1 all dihedral/local phi :pre
compute 1 all dihedral/local phi v_cos set phi p :pre
[Description:]
@ -33,6 +40,47 @@ by the group parameter as explained below.
The value {phi} is the dihedral angle, as defined in the diagram on
the "dihedral_style"_dihedral_style.html doc page.
The value {v_name} can be used together with the {set} keyword to
compute a user-specified function of the dihedral angle phi. The
{name} specified for the {v_name} value is the name of an "equal-style
variable"_variable.html which should evaluate a formula based on a
variable which will store the angle phi. This other variable must
be an "internal-style variable"_variable.html defined in the input
script; its initial numeric value can be anything. It must be an
internal-style variable, because this command resets its value
directly. The {set} keyword is used to identify the name of this
other variable associated with phi.
Note that the value of phi for each angle which stored in the internal
variable is in radians, not degrees.
As an example, these commands can be added to the bench/in.rhodo
script to compute the cosine and cosine^2 of every dihedral angle in
the system and output the statistics in various ways:
variable p internal 0.0
variable cos equal cos(v_p)
variable cossq equal cos(v_p)*cos(v_p) :pre
compute 1 all property/local datom1 datom2 datom3 datom4 dtype
compute 2 all dihedral/local phi v_cos v_cossq set phi p
dump 1 all local 100 tmp.dump c_1[*] c_2[*] :pre
compute 3 all reduce ave c_2[*]
thermo_style custom step temp press c_3[*] :pre
fix 10 all ave/histo 10 10 100 -1 1 20 c_2[2] mode vector file tmp.histo :pre
The "dump local"_dump.html command will output the angle,
cosine(angle), cosine^2(angle) for every dihedral in the system. The
"thermo_style"_thermo_style.html command will print the average of
those quantities via the "compute reduce"_compute_reduce.html command
with thermo output. And the "fix ave/histo"_fix_ave_histo.html
command will histogram the cosine(angle) values and write them to a
file.
:line
The local data stored by this command is generated by looping over all
the atoms owned on a processor and their dihedrals. A dihedral will
only be included if all 4 atoms in the dihedral are in the specified
@ -57,12 +105,12 @@ dump 1 all local 1000 tmp.dump index c_1\[1\] c_1\[2\] c_1\[3\] c_1\[4\] c_1\[5\
[Output info:]
This compute calculates a local vector or local array depending on the
number of keywords. The length of the vector or number of rows in the
array is the number of dihedrals. If a single keyword is specified, a
local vector is produced. If two or more keywords are specified, a
number of values. The length of the vector or number of rows in the
array is the number of dihedrals. If a single value is specified, a
local vector is produced. If two or more values are specified, a
local array is produced where the number of columns = the number of
keywords. The vector or array can be accessed by any command that
uses local values from a compute as input. See the "Howto
values. The vector or array can be accessed by any command that uses
local values from a compute as input. See the "Howto
output"_Howto_output.html doc page for an overview of LAMMPS output
options.

4
doc/src/compute_msd_chunk.txt
View File

@ -90,12 +90,12 @@ This is so that the fix this compute creates to store per-chunk
quantities will also have the same ID, and thus be initialized
correctly with chunk reference positions from the restart file.
The simplest way to output the results of the compute com/msd
The simplest way to output the results of the compute msd/chunk
calculation to a file is to use the "fix ave/time"_fix_ave_time.html
command, for example:
compute cc1 all chunk/atom molecule
compute myChunk all com/msd cc1
compute myChunk all msd/chunk cc1
fix 1 all ave/time 100 1 100 c_myChunk\[*\] file tmp.out mode vector :pre
[Output info:]

25
doc/src/compute_pair.txt
View File

@ -10,17 +10,20 @@ compute pair command :h3
[Syntax:]
compute ID group-ID pair pstyle evalue :pre
compute ID group-ID pair pstyle \[nstyle\] \[evalue\] :pre
ID, group-ID are documented in "compute"_compute.html command
pair = style name of this compute command
pstyle = style name of a pair style that calculates additional values
evalue = {epair} or {evdwl} or {ecoul} or blank (optional setting) :ul
ID, group-ID are documented in "compute"_compute.html command :ulb,l
pair = style name of this compute command :l
pstyle = style name of a pair style that calculates additional values :l
nsub = {n}-instance of a substyle, if a pair style is used multiple times in a hybrid style :l
{evalue} = {epair} or {evdwl} or {ecoul} or blank (optional) :l
:ule
[Examples:]
compute 1 all pair gauss
compute 1 all pair lj/cut/coul/cut ecoul
compute 1 all pair tersoff 2 epair
compute 1 all pair reax :pre
[Description:]
@ -33,15 +36,19 @@ NOTE: The group specified for this command is [ignored].
The specified {pstyle} must be a pair style used in your simulation
either by itself or as a sub-style in a "pair_style hybrid or
hybrid/overlay"_pair_hybrid.html command.
hybrid/overlay"_pair_hybrid.html command. If the sub-style is
used more than once, an additional number {nsub} has to be specified
in order to choose which instance of the sub-style will be used by
the compute. Not specifying the number in this case will cause the
compute to fail.
The {evalue} setting is optional; it may be left off the command. All
The {evalue} setting is optional. All
pair styles tally a potential energy {epair} which may be broken into
two parts: {evdwl} and {ecoul} such that {epair} = {evdwl} + {ecoul}.
If the pair style calculates Coulombic interactions, their energy will
be tallied in {ecoul}. Everything else (whether it is a Lennard-Jones
style van der Waals interaction or not) is tallied in {evdwl}. If
{evalue} is specified as {epair} or left out, then {epair} is stored
{evalue} is blank or specified as {epair}, then {epair} is stored
as a global scalar by this compute. This is useful when using
"pair_style hybrid"_pair_hybrid.html if you want to know the portion
of the total energy contributed by one sub-style. If {evalue} is
@ -82,4 +89,4 @@ the doc page for the pair style for details.
[Default:]
The default for {evalue} is {epair}.
The keyword defaults are {evalue} = {epair}, nsub = 0.

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

@ -0,0 +1,81 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
compute pressure/cylinder command :h3
[Syntax:]
compute ID group-ID pressure/cylinder zlo zhi Rmax bin_width :pre
ID, group-ID are documented in "compute"_compute.html command
pressure/cylinder = style name of this compute command
zlo = minimum z-boundary for cylinder
zhi = maximum z-boundary for cylinder
Rmax = maximum radius to perform calculation to
bin_width = width of radial bins to use for calculation :ul
[Examples:]
compute 1 all pressure/cylinder -10.0 10.0 15.0 0.25 :pre
[Description:]
Define a computation that calculates the pressure tensor of a system in
cylindrical coordinates, as discussed in "(Addington)"_#Addington1.
This is useful for systems with a single axis of rotational symmetry,
such as cylindrical micelles or carbon nanotubes. The compute splits the
system into radial, cylindrical-shell-type bins of width bin_width,
centered at x=0,y=0, and calculates the radial (P_rhorho), azimuthal
(P_phiphi), and axial (P_zz) components of the configurational pressure
tensor. The local density is also calculated for each bin, so that the
true pressure can be recovered as P_kin+P_conf=density*k*T+P_conf. The
output is a global array with 5 columns; one each for bin radius, local
number density, P_rhorho, P_phiphi, and P_zz. The number of rows is
governed by the values of Rmax and bin_width. Pressure tensor values are
output in pressure units.
[Output info:]
This compute calculates a global array with 5 columns and Rmax/bin_width
rows. The output columns are: R (distance units), number density (inverse
volume units), configurational radial pressure (pressure units),
configurational azimuthal pressure (pressure units), and configurational
axial pressure (pressure units).
The values calculated by this compute are
"intensive". The pressure values will be in pressure
"units"_units.html. The number density values will be in
inverse volume "units"_units.html.
[Restrictions:]
This compute currently calculates the pressure tensor contributions
for pair styles only (i.e. no bond, angle, dihedral, etc. contributions
and in the presence of bonded interactions, the result will be incorrect
due to exclusions for special bonds) and requires pair-wise force
calculations not available for most manybody pair styles. K-space
calculations are also excluded. Note that this pressure compute outputs
the configurational terms only; the kinetic contribution is not included
and may be calculated from the number density output by P_kin=density*k*T.
This compute is part of the USER-MISC package. It is only enabled
if LAMMPS was built with that package. See the "Build
package"_Build_package.html doc page for more info.
[Related commands:]
"compute temp"_compute_temp.html, "compute
stress/atom"_compute_stress_atom.html,
"thermo_style"_thermo_style.html,
[Default:] none
:line
:link(Addington1)
[(Addington)] Addington, Long, Gubbins, J Chem Phys, 149, 084109 (2018).

121
doc/src/compute_ptm_atom.txt Normal file
View File

@ -0,0 +1,121 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
compute ptm/atom command :h3
[Syntax:]
compute ID group-ID ptm/atom structures threshold :pre
ID, group-ID are documented in "compute"_compute.html command
ptm/atom = style name of this compute command
structures = structure types to search for
threshold = lattice distortion threshold (RMSD) :ul
[Examples:]
compute 1 all ptm/atom default 0.1
compute 1 all ptm/atom fcc-hcp-dcub-dhex 0.15
compute 1 all ptm/atom all 0 :pre
[Description:]
Define a computation that determines the local lattice structure
around an atom using the PTM (Polyhedral Template Matching) method.
The PTM method is described in "(Larsen)"_#Larsen.
Currently, there are seven lattice structures PTM recognizes:
fcc = 1
hcp = 2
bcc = 3
ico (icosahedral) = 4
sc (simple cubic) = 5
dcub (diamond cubic) = 6
dhex (diamond hexagonal) = 7
other = 8 :ul
The value of the PTM structure will be 0 for atoms not in the specified
compute group. The choice of structures to search for can be specified using the "structures"
argument, which is a hyphen-separated list of structure keywords.
Two convenient pre-set options are provided:
default: fcc-hcp-bcc-ico
all: fcc-hcp-bcc-ico-sc-dcub-dhex :ul
The 'default' setting detects the same structures as the Common Neighbor Analysis method.
The 'all' setting searches for all structure types. A small performance penalty is
incurred for the diamond structures, so it is not recommended to use this option if
it is known that the simulation does not contain diamond structures.
PTM identifies structures using two steps. First, a graph isomorphism test is used
to identify potential structure matches. Next, the deviation is computed between the
local structure (in the simulation) and a template of the ideal lattice structure.
The deviation is calculated as:
:c,image(Eqs/ptm_rmsd.jpg)
Here, u and v contain the coordinates of the local and ideal structures respectively,
s is a scale factor, and Q is a rotation. The best match is identified by the
lowest RMSD value, using the optimal scaling, rotation, and correspondence between the
points.
The 'threshold' keyword sets an upper limit on the maximum permitted deviation before
a local structure is identified as disordered. Typical values are in the range 0.1-0.15,
but larger values may be desirable at higher temperatures.
A value of 0 is equivalent to infinity and can be used if no threshold is desired.
The neighbor list needed to compute this quantity is constructed each
time the calculation is performed (e.g. each time a snapshot of atoms
is dumped). Thus it can be inefficient to compute/dump this quantity
too frequently or to have multiple compute/dump commands, each with a
{ptm/atom} style.
[Output info:]
This compute calculates a per-atom arry, which can be accessed by
any command that uses per-atom values from a compute as input. See
the "Howto output"_Howto_output.html doc page for an overview of
LAMMPS output options.
Results are stored in the per-atom array in the following order:
type
rmsd
interatomic distance
qw
qx
qy
qw :ul
The type is a number from 0 to 8. The rmsd is a positive real number.
The interatomic distance is computed from the scale factor in the RMSD equation.
The (qw,qx,qy,qz) parameters represent the orientation of the local structure
in quaternion form. The reference coordinates for each template (from which the
orientation is determined) can be found in the {ptm_constants.h} file in the PTM source directory.
[Restrictions:]
This fix is part of the USER-PTM package. It is only enabled if
LAMMPS was built with that package. See the "Build
package"_Build_package.html doc page for more info.
[Related commands:]
"compute centro/atom"_compute_centro_atom.html
"compute cna/atom"_compute_cna_atom.html
[Default:] none
:line
:link(Larsen)
[(Larsen)] Larsen, Schmidt, Schiøtz, Modelling Simul Mater Sci Eng, 24, 055007 (2016).

3
doc/src/compute_rdf.txt
View File

@ -191,7 +191,8 @@ via "compute_modify dynamic yes"_compute_modify.html
[Related commands:]
"fix ave/time"_fix_ave_time.html, "compute_modify"_compute_modify.html
"fix ave/time"_fix_ave_time.html, "compute_modify"_compute_modify.html,
"compute adf"_compute_adf.html
[Default:]

6
doc/src/compute_reduce.txt
View File

@ -97,9 +97,9 @@ equivalent, since the "compute stress/atom"_compute_stress_atom.html
command creates a per-atom array with 6 columns:
compute myPress all stress/atom NULL
compute 2 all reduce min myPress\[*\]
compute 2 all reduce min myPress\[1\] myPress\[2\] myPress\[3\] &
myPress\[4\] myPress\[5\] myPress\[6\] :pre
compute 2 all reduce min c_myPress\[*\]
compute 2 all reduce min c_myPress\[1\] c_myPress\[2\] c_myPress\[3\] &
c_myPress\[4\] c_myPress\[5\] c_myPress\[6\] :pre
:line

177
doc/src/compute_reduce_chunk.txt Normal file
View File

@ -0,0 +1,177 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
compute reduce/chunk command :h3
[Syntax:]
compute ID group-ID reduce/chunk chunkID mode input1 input2 ... :pre
ID, group-ID are documented in "compute"_compute.html command :ulb,l
reduce/chunk = style name of this compute command :l
chunkID = ID of "compute chunk/atom"_compute_chunk_atom.html command :l
mode = {sum} or {min} or {max} :l
one or more inputs can be listed :l
input = c_ID, c_ID\[N\], f_ID, f_ID\[N\], v_ID :l
c_ID = per-atom vector calculated by a compute with ID
c_ID\[I\] = Ith column of per-atom array calculated by a compute with ID, I can include wildcard (see below)
f_ID = per-atom vector calculated by a fix with ID
f_ID\[I\] = Ith column of per-atom array calculated by a fix with ID, I can include wildcard (see below)
v_name = per-atom vector calculated by an atom-style variable with name :pre
:ule
[Examples:]
compute 1 all reduce/chunk/atom mychunk min c_cluster :pre
[Description:]
Define a calculation that reduces one or more per-atom vectors into
per-chunk values. This can be useful for diagnostic output. Or when
used in conjunction with the "compute
chunk/spread/atom"_compute_chunk_spread_atom.html command it can be
used ot create per-atom values that induce a new set of chunks with a
second "compute chunk/atom"_compute_chunk_atom.html command. An
example is given below.
In LAMMPS, chunks are collections of atoms defined by a "compute
chunk/atom"_compute_chunk_atom.html command, which assigns each atom
to a single chunk (or no chunk). The ID for this command is specified
as chunkID. For example, a single chunk could be the atoms in a
molecule or atoms in a spatial bin. See the "compute
chunk/atom"_compute_chunk_atom.html and "Howto chunk"_Howto_chunk.html
doc pages for details of how chunks can be defined and examples of how
they can be used to measure properties of a system.
For each atom, this compute accesses its chunk ID from the specified
{chunkID} compute. The per-atom value from an input contributes
to a per-chunk value corresponding the the chunk ID.
The reduction operation is specified by the {mode} setting and is
performed over all the per-atom values from the atoms in each chunk.
The {sum} option adds the pre-atom values to a per-chunk total. The
{min} or {max} options find the minimum or maximum value of the
per-atom values for each chunk.
Note that only atoms in the specified group contribute to the
reduction operation. If the {chunkID} compute returns a 0 for the
chunk ID of an atom (i.e. the atom is not in a chunk defined by the
"compute chunk/atom"_compute_chunk_atom.html command), that atom will
also not contribute to the reduction operation. An input that is a
compute or fix may define its own group which affects the quantities
it returns. For example, a compute with return a zero value for atoms
that are not in the group specified for that compute.
Each listed input is operated on independently. Each input can be the
result of a "compute"_compute.html or "fix"_fix.html or the evaluation
of an atom-style "variable"_variable.html.
Note that for values from a compute or fix, the bracketed index I can
be specified using a wildcard asterisk with the index to effectively
specify multiple values. This takes the form "*" or "*n" or "n*" or
"m*n". If N = the size of the vector (for {mode} = scalar) or the
number of columns in the array (for {mode} = vector), then an asterisk
with no numeric values means all indices from 1 to N. A leading
asterisk means all indices from 1 to n (inclusive). A trailing
asterisk means all indices from n to N (inclusive). A middle asterisk
means all indices from m to n (inclusive).
Using a wildcard is the same as if the individual columns of the array
had been listed one by one. E.g. these 2 compute reduce/chunk
commands are equivalent, since the "compute
property/chunk"_compute_property_chunk.html command creates a per-atom
array with 3 columns:
compute prop all property/atom vx vy vz
compute 10 all reduce/chunk mychunk max c_prop\[*\]
compute 10 all reduce/chunk mychunk max c_prop\[1\] c_prop\[2\] c_prop\[3\] :pre
:line
Here is an example of using this compute, in conjunction with the
compute chunk/spread/atom command to identify self-assembled micelles.
The commands below can be added to the examples/in.micelle script.
Imagine a collection of polymer chains or small molecules with
hydrophobic end groups. All the hydrophobic (HP) atoms are assigned
to a group called "phobic".
These commands will assign a unique cluster ID to all HP atoms within
a specified distance of each other. A cluster will contain all HP
atoms in a single molecule, but also the HP atoms in nearby molecules,
e.g. molecules that have clumped to form a micelle due to the
attraction induced by the hydrophobicity. The output of the
chunk/reduce command will be a cluster ID per chunk (molecule).
Molecules with the same cluster ID are in the same micelle.
group phobic type 4 # specific to in.micelle model
compute cluster phobic cluster/atom 2.0
compute cmol all chunk/atom molecule
compute reduce phobic reduce/chunk cmol min c_cluster :pre
This per-chunk info could be output in at least two ways:
fix 10 all ave/time 1000 1 1000 c_reduce file tmp.phobic mode vector :pre
compute spread all chunk/spread/atom cmol c_reduce
dump 1 all custom 1000 tmp.dump id type mol x y z c_cluster c_spread
dump_modify 1 sort id :pre
In the first case, each snapshot in the tmp.phobic file will contain
one line per molecule. Molecules with the same value are in the same
micelle. In the second case each dump snapshot contains all atoms,
each with a final field with the cluster ID of the micelle that the HP
atoms of that atom's molecule belong to.
The result from compute chunk/spread/atom can be used to define a new
set of chunks, where all the atoms in all the molecules in the same
micelle are assigned to the same chunk, i.e. one chunk per micelle.
compute micelle all chunk/atom c_spread compress yes :pre
Further analysis on a per-micelle basis can now be performed using any
of the per-chunk computes listed on the "Howto chunk"_Howto_chunk.html
doc page. E.g. count the number of atoms in each micelle, calculate
its center or mass, shape (moments of intertia), radius of gyration,
etc.
compute prop all property/chunk micelle count
fix 20 all ave/time 1000 1 1000 c_prop file tmp.micelle mode vector :pre
Each snapshot in the tmp.micelle file will have one line per micelle
with its count of atoms, plus a first line for a chunk with all the
solvent atoms. By the time 50000 steps have elapsed there are a
handful of large micelles.
:line
[Output info:]
This compute calculates a global vector if a single input value is
specified, otherwise a global array is output. The number of columns
in the array is the number of inputs provided. The length of the
vector or the number of vector elements or array rows = the number of
chunks {Nchunk} as calculated by the specified "compute
chunk/atom"_compute_chunk_atom.html command. The vector or array can
be accessed by any command that uses global values from a compute as
input. See the "Howto output"_Howto_output.html doc page for an
overview of LAMMPS output options.
The per-atom values for the vector or each column of the array will be
in whatever "units"_units.html the corresponding input value is in.
The vector or array values are "intensive".
[Restrictions:] none
[Related commands:]
"compute chunk/atom"_compute_chunk_atom.html, "compute
reduce"_compute_reduce.html, "compute
chunk/spread/atom"_compute_chunk_spread_atom.html
[Default:] none

6
doc/src/compute_smd_triangle_mesh_vertices.txt → doc/src/compute_smd_triangle_vertices.txt
View File

@ -6,14 +6,14 @@
:line
compute smd/triangle/mesh/vertices :h3
compute smd/triangle/vertices command :h3
[Syntax:]
compute ID group-ID smd/triangle/mesh/vertices :pre
compute ID group-ID smd/triangle/vertices :pre
ID, group-ID are documented in "compute"_compute.html command
smd/triangle/mesh/vertices = style name of this compute command :ul
smd/triangle/vertices = style name of this compute command :ul
[Examples:]

13
doc/src/compute_spin.txt
View File

@ -10,14 +10,14 @@ compute spin command :h3
[Syntax:]
compute ID group-ID compute/spin :pre
compute ID group-ID spin :pre
ID, group-ID are documented in "compute"_compute.html command
compute/spin = style name of this compute command :ul
spin = style name of this compute command :ul
[Examples:]
compute out_mag all compute/spin :pre
compute out_mag all spin :pre
[Description:]
@ -26,7 +26,8 @@ of atoms having spins.
This compute calculates 6 magnetic quantities.
The three first quantities are the x,y and z coordinates of the total magnetization.
The three first quantities are the x,y and z coordinates of the total
magnetization.
The fourth quantity is the norm of the total magnetization.
@ -39,7 +40,7 @@ The simplest way to output the results of the compute spin calculation
is to define some of the quantities as variables, and to use the thermo and
thermo_style commands, for example:
compute out_mag all compute/spin :pre
compute out_mag all spin :pre
variable mag_z equal c_out_mag\[3\]
variable mag_norm equal c_out_mag\[4\]
@ -53,7 +54,6 @@ the total magnetization, and the magnetic temperature. Three variables are
assigned to those quantities. The thermo and thermo_style commands print them
every 10 timesteps.
[Output info:]
The array values are "intensive". The array values will be in
@ -68,7 +68,6 @@ has to be "spin" for this compute to be valid.
[Related commands:] none
[Default:] none
:line

111
doc/src/compute_stress_mop.txt Normal file
View File

@ -0,0 +1,111 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
compute stress/mop command :h3
compute stress/mop/profile command :h3
[Syntax:]
compute ID group-ID style dir args keywords ... :pre
ID, group-ID are documented in "compute"_compute.html command
style = {stress/mop} or {stress/mop/profile}
dir = {x} or {y} or {z} is the direction normal to the plane
args = argument specific to the compute style
keywords = {kin} or {conf} or {total} (one of more can be specified) :ul
{stress/mop} args = pos
pos = {lower} or {center} or {upper} or coordinate value (distance units) is the position of the plane
{stress/mop/profile} args = origin delta
origin = {lower} or {center} or {upper} or coordinate value (distance units) is the position of the first plane
delta = value (distance units) is the distance between planes :pre
compute 1 all stress/mop x lower total
compute 1 liquid stress/mop z 0.0 kin conf
fix 1 all ave/time 10 1000 10000 c_1\[*\] file mop.time
fix 1 all ave/time 10 1000 10000 c_1\[2\] file mop.time :pre
compute 1 all stress/mop/profile x lower 0.1 total
compute 1 liquid stress/mop/profile z 0.0 0.25 kin conf
fix 1 all ave/time 500 20 10000 c_1\[*\] ave running overwrite file mopp.time mode vector :pre
[Description:]
Compute {stress/mop} and compute {stress/mop/profile} define computations that
calculate components of the local stress tensor using the method of
planes "(Todd)"_#mop-todd. Specifically in compute {stress/mop} calculates 3
components are computed in directions {dir},{x}; {dir},{y}; and
{dir},{z}; where {dir} is the direction normal to the plane, while
in compute {stress/mop/profile} the profile of the stress is computed.
Contrary to methods based on histograms of atomic stress (i.e. using
"compute stress/atom"_compute_stress_atom.html), the method of planes is
compatible with mechanical balance in heterogeneous systems and at
interfaces "(Todd)"_#mop-todd.
The stress tensor is the sum of a kinetic term and a configurational
term, which are given respectively by Eq. (21) and Eq. (16) in
"(Todd)"_#mop-todd. For the kinetic part, the algorithm considers that
atoms have crossed the plane if their positions at times t-dt and t are
one on either side of the plane, and uses the velocity at time t-dt/2
given by the velocity-Verlet algorithm.
Between one and three keywords can be used to indicate which
contributions to the stress must be computed: kinetic stress (kin),
configurational stress (conf), and/or total stress (total).
NOTE 1: The configurational stress is computed considering all pairs of atoms where at least one atom belongs to group group-ID.
NOTE 2: The local stress does not include any Lennard-Jones tail
corrections to the pressure added by the "pair_modify tail
yes"_pair_modify.html command, since those are contributions to the global system pressure.
[Output info:]
Compute {stress/mop} calculates a global vector (indices starting at 1), with 3
values for each declared keyword (in the order the keywords have been
declared). For each keyword, the stress tensor components are ordered as
follows: stress_dir,x, stress_dir,y, and stress_dir,z.
Compute {stress/mop/profile} instead calculates a global array, with 1 column
giving the position of the planes where the stress tensor was computed,
and with 3 columns of values for each declared keyword (in the order the
keywords have been declared). For each keyword, the profiles of stress
tensor components are ordered as follows: stress_dir,x; stress_dir,y;
and stress_dir,z.
The values are in pressure "units"_units.html.
The values produced by this compute can be accessed by various "output commands"_Howto_output.html. For instance, the results can be written to a file using the "fix ave/time"_fix_ave_time.html command. Please see the example in the examples/USER/mop folder.
[Restrictions:]
These styles are part of the USER-MISC package. They are only enabled if
LAMMPS is built with that package. See the "Build package"_Build_package.html
doc page on for more info.
The method is only implemented for 3d orthogonal simulation boxes whose
size does not change in time, and axis-aligned planes.
The method only works with two-body pair interactions, because it
requires the class method pair->single() to be implemented. In
particular, it does not work with more than two-body pair interactions,
intra-molecular interactions, and long range (kspace) interactions.
[Related commands:]
"compute stress/atom"_compute_stress_atom.html
[Default:] none
:line
:link(mop-todd)
[(Todd)] B. D. Todd, Denis J. Evans, and Peter J. Daivis: "Pressure tensor for inhomogeneous fluids",
Phys. Rev. E 52, 1627 (1995).

8
doc/src/computes.txt
View File

@ -6,6 +6,7 @@ Computes :h1
:maxdepth: 1
compute_ackland_atom
compute_adf
compute_angle
compute_angle_local
compute_angmom_chunk
@ -15,6 +16,7 @@ Computes :h1
compute_bond_local
compute_centro_atom
compute_chunk_atom
compute_chunk_spread_atom
compute_cluster_atom
compute_cna_atom
compute_cnp_atom
@ -66,12 +68,15 @@ Computes :h1
compute_pe_atom
compute_plasticity_atom
compute_pressure
compute_pressure_cylinder
compute_pressure_uef
compute_property_atom
compute_property_chunk
compute_property_local
compute_ptm_atom
compute_rdf
compute_reduce
compute_reduce_chunk
compute_rigid_local
compute_saed
compute_slice
@ -89,7 +94,7 @@ Computes :h1
compute_smd_tlsph_strain
compute_smd_tlsph_strain_rate
compute_smd_tlsph_stress
compute_smd_triangle_mesh_vertices
compute_smd_triangle_vertices
compute_smd_ulsph_num_neighs
compute_smd_ulsph_strain
compute_smd_ulsph_strain_rate
@ -98,6 +103,7 @@ Computes :h1
compute_sna_atom
compute_spin
compute_stress_atom
compute_stress_mop
compute_tally
compute_tdpd_cc_atom
compute_temp

2
doc/src/dihedral_nharmonic.txt
View File

@ -16,7 +16,7 @@ dihedral_style nharmonic :pre
[Examples:]
dihedral_style nharmonic
dihedral_coeff 3 10.0 20.0 30.0 :pre
dihedral_coeff * 3 10.0 20.0 30.0 :pre
[Description:]

7
doc/src/dump_image.txt
View File

@ -384,12 +384,7 @@ change this via the "dump_modify"_dump_modify.html command.
:line
The {fix} keyword can be used with a "fix"_fix.html that produces
objects to be drawn. An example is the "fix
surface/global"_fix_surface_global.html command which can draw lines
or triangles for 2d/3d simulations.
NOTE: Aug 2016 - The fix surface/global command is not yet added to
LAMMPS.
objects to be drawn.
The {fflag1} and {fflag2} settings are numerical values which are
passed to the fix to affect how the drawing of its objects is done.

4
doc/src/fix_box_relax.txt
View File

@ -221,8 +221,8 @@ This equation only applies when the box dimensions are equal to those
of the reference dimensions. If this is not the case, then the
converged stress tensor will not equal that specified by the user. We
can resolve this problem by periodically resetting the reference
dimensions. The keyword {nreset_ref} controls how often this is done.
If this keyword is not used, or is given a value of zero, then the
dimensions. The keyword {nreset} controls how often this is done. If
this keyword is not used, or is given a value of zero, then the
reference dimensions are set to those of the initial simulation domain
and are never changed. A value of {nstep} means that every {nstep}
minimization steps, the reference dimensions are set to those of the

674
doc/src/fix_cauchy.txt Normal file
View File

@ -0,0 +1,674 @@
<"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
fix npt/cauchy command :h3
[Syntax:]
fix ID group-ID style_name keyword value ... :pre
ID, group-ID are documented in "fix"_fix.html command :ulb,l
style_name = {npt/cauchy} :l
one or more keyword/value pairs may be appended :l
keyword = {temp} or {iso} or {aniso} or {tri} or {x} or {y} or {z} or {xy} or {yz} or {xz} or {couple} or {tchain} or {pchain} or {mtk} or {tloop} or {ploop} or {nreset} or {drag} or {dilate} or {scalexy} or {scaleyz} or {scalexz} or {flip} or {fixedpoint} or {update}
{temp} values = Tstart Tstop Tdamp
Tstart,Tstop = external temperature at start/end of run
Tdamp = temperature damping parameter (time units)
{iso} or {aniso} or {tri} values = Pstart Pstop Pdamp
Pstart,Pstop = scalar external pressure at start/end of run (pressure units)
Pdamp = pressure damping parameter (time units)
{x} or {y} or {z} or {xy} or {yz} or {xz} values = Pstart Pstop Pdamp
Pstart,Pstop = external stress tensor component at start/end of run (pressure units)
Pdamp = stress damping parameter (time units)
{couple} = {none} or {xyz} or {xy} or {yz} or {xz}
{tchain} value = N
N = length of thermostat chain (1 = single thermostat)
{pchain} values = N
N length of thermostat chain on barostat (0 = no thermostat)
{mtk} value = {yes} or {no} = add in MTK adjustment term or not
{tloop} value = M
M = number of sub-cycles to perform on thermostat
{ploop} value = M
M = number of sub-cycles to perform on barostat thermostat
{nreset} value = reset reference cell every this many timesteps
{drag} value = Df
Df = drag factor added to barostat/thermostat (0.0 = no drag)
{dilate} value = dilate-group-ID
dilate-group-ID = only dilate atoms in this group due to barostat volume changes
{scalexy} value = {yes} or {no} = scale xy with ly
{scaleyz} value = {yes} or {no} = scale yz with lz
{scalexz} value = {yes} or {no} = scale xz with lz
{flip} value = {yes} or {no} = allow or disallow box flips when it becomes highly skewed
{cauchystat} cauchystat values = alpha continue
alpha = strength of Cauchystat control parameter
continue = {yes} or {no} = whether of not to continue from a previous run
{fixedpoint} values = x y z
x,y,z = perform barostat dilation/contraction around this point (distance units)
{update} value = {dipole} or {dipole/dlm}
dipole = update dipole orientation (only for sphere variants)
dipole/dlm = use DLM integrator to update dipole orientation (only for sphere variants) :pre
:ule
[Examples:]
fix 1 water npt/cauchy temp 300.0 300.0 100.0 iso 0.0 0.0 1000.0
[Description:]
These commands perform time integration on Nose-Hoover style
non-Hamiltonian equations of motion which are designed to generate
positions and velocities sampled from the canonical (nvt),
isothermal-isobaric (npt), and isenthalpic (nph) ensembles. This
updates the position and velocity for atoms in the group each
timestep.
The thermostatting and barostatting is achieved by adding some dynamic
variables which are coupled to the particle velocities
(thermostatting) and simulation domain dimensions (barostatting). In
addition to basic thermostatting and barostatting, these fixes can
also create a chain of thermostats coupled to the particle thermostat,
and another chain of thermostats coupled to the barostat
variables. The barostat can be coupled to the overall box volume, or
to individual dimensions, including the {xy}, {xz} and {yz} tilt
dimensions. The external pressure of the barostat can be specified as
either a scalar pressure (isobaric ensemble) or as components of a
symmetric stress tensor (constant stress ensemble). When used
correctly, the time-averaged temperature and stress tensor of the
particles will match the target values specified by Tstart/Tstop and
Pstart/Pstop.
The equations of motion used are those of Shinoda et al in
"(Shinoda)"_#nh-Shinoda, which combine the hydrostatic equations of
Martyna, Tobias and Klein in "(Martyna)"_#nh-Martyna with the strain
energy proposed by Parrinello and Rahman in
"(Parrinello)"_#nh-Parrinello. The time integration schemes closely
follow the time-reversible measure-preserving Verlet and rRESPA
integrators derived by Tuckerman et al in "(Tuckerman)"_#nh-Tuckerman.
:line
The thermostat parameters for fix styles {nvt} and {npt} is specified
using the {temp} keyword. Other thermostat-related keywords are
{tchain}, {tloop} and {drag}, which are discussed below.
The thermostat is applied to only the translational degrees of freedom
for the particles. The translational degrees of freedom can also have
a bias velocity removed before thermostatting takes place; see the
description below. The desired temperature at each timestep is a
ramped value during the run from {Tstart} to {Tstop}. The {Tdamp}
parameter is specified in time units and determines how rapidly the
temperature is relaxed. For example, a value of 10.0 means to relax
the temperature in a timespan of (roughly) 10 time units (e.g. tau or
fmsec or psec - see the "units"_units.html command). The atoms in the
fix group are the only ones whose velocities and positions are updated
by the velocity/position update portion of the integration.
NOTE: A Nose-Hoover thermostat will not work well for arbitrary values
of {Tdamp}. If {Tdamp} is too small, the temperature can fluctuate
wildly; if it is too large, the temperature will take a very long time
to equilibrate. A good choice for many models is a {Tdamp} of around
100 timesteps. Note that this is NOT the same as 100 time units for
most "units"_units.html settings.
:line
The barostat parameters for fix styles {npt} and {nph} is specified
using one or more of the {iso}, {aniso}, {tri}, {x}, {y}, {z}, {xy},
{xz}, {yz}, and {couple} keywords. These keywords give you the
ability to specify all 6 components of an external stress tensor, and
to couple various of these components together so that the dimensions
they represent are varied together during a constant-pressure
simulation.
Other barostat-related keywords are {pchain}, {mtk}, {ploop},
{nreset}, {drag}, and {dilate}, which are discussed below.
Orthogonal simulation boxes have 3 adjustable dimensions (x,y,z).
Triclinic (non-orthogonal) simulation boxes have 6 adjustable
dimensions (x,y,z,xy,xz,yz). The "create_box"_create_box.html, "read
data"_read_data.html, and "read_restart"_read_restart.html commands
specify whether the simulation box is orthogonal or non-orthogonal
(triclinic) and explain the meaning of the xy,xz,yz tilt factors.
The target pressures for each of the 6 components of the stress tensor
can be specified independently via the {x}, {y}, {z}, {xy}, {xz}, {yz}
keywords, which correspond to the 6 simulation box dimensions. For
each component, the external pressure or tensor component at each
timestep is a ramped value during the run from {Pstart} to {Pstop}.
If a target pressure is specified for a component, then the
corresponding box dimension will change during a simulation. For
example, if the {y} keyword is used, the y-box length will change. If
the {xy} keyword is used, the xy tilt factor will change. A box
dimension will not change if that component is not specified, although
you have the option to change that dimension via the "fix
deform"_fix_deform.html command.
Note that in order to use the {xy}, {xz}, or {yz} keywords, the
simulation box must be triclinic, even if its initial tilt factors are
0.0.
For all barostat keywords, the {Pdamp} parameter operates like the
{Tdamp} parameter, determining the time scale on which pressure is
relaxed. For example, a value of 10.0 means to relax the pressure in
a timespan of (roughly) 10 time units (e.g. tau or fmsec or psec - see
the "units"_units.html command).
NOTE: A Nose-Hoover barostat will not work well for arbitrary values
of {Pdamp}. If {Pdamp} is too small, the pressure and volume can
fluctuate wildly; if it is too large, the pressure will take a very
long time to equilibrate. A good choice for many models is a {Pdamp}
of around 1000 timesteps. However, note that {Pdamp} is specified in
time units, and that timesteps are NOT the same as time units for most
"units"_units.html settings.
Regardless of what atoms are in the fix group (the only atoms which
are time integrated), a global pressure or stress tensor is computed
for all atoms. Similarly, when the size of the simulation box is
changed, all atoms are re-scaled to new positions, unless the keyword
{dilate} is specified with a {dilate-group-ID} for a group that
represents a subset of the atoms. This can be useful, for example, to
leave the coordinates of atoms in a solid substrate unchanged and
controlling the pressure of a surrounding fluid. This option should
be used with care, since it can be unphysical to dilate some atoms and
not others, because it can introduce large, instantaneous
displacements between a pair of atoms (one dilated, one not) that are
far from the dilation origin. Also note that for atoms not in the fix
group, a separate time integration fix like "fix nve"_fix_nve.html or
"fix nvt"_fix_nh.html can be used on them, independent of whether they
are dilated or not.
:line
The {couple} keyword allows two or three of the diagonal components of
the pressure tensor to be "coupled" together. The value specified
with the keyword determines which are coupled. For example, {xz}
means the {Pxx} and {Pzz} components of the stress tensor are coupled.
{Xyz} means all 3 diagonal components are coupled. Coupling means two
things: the instantaneous stress will be computed as an average of the
corresponding diagonal components, and the coupled box dimensions will
be changed together in lockstep, meaning coupled dimensions will be
dilated or contracted by the same percentage every timestep. The
{Pstart}, {Pstop}, {Pdamp} parameters for any coupled dimensions must
be identical. {Couple xyz} can be used for a 2d simulation; the {z}
dimension is simply ignored.
:line
The {iso}, {aniso}, and {tri} keywords are simply shortcuts that are
equivalent to specifying several other keywords together.
The keyword {iso} means couple all 3 diagonal components together when
pressure is computed (hydrostatic pressure), and dilate/contract the
dimensions together. Using "iso Pstart Pstop Pdamp" is the same as
specifying these 4 keywords:
x Pstart Pstop Pdamp
y Pstart Pstop Pdamp
z Pstart Pstop Pdamp
couple xyz :pre
The keyword {aniso} means {x}, {y}, and {z} dimensions are controlled
independently using the {Pxx}, {Pyy}, and {Pzz} components of the
stress tensor as the driving forces, and the specified scalar external
pressure. Using "aniso Pstart Pstop Pdamp" is the same as specifying
these 4 keywords:
x Pstart Pstop Pdamp
y Pstart Pstop Pdamp
z Pstart Pstop Pdamp
couple none :pre
The keyword {tri} means {x}, {y}, {z}, {xy}, {xz}, and {yz} dimensions
are controlled independently using their individual stress components
as the driving forces, and the specified scalar pressure as the
external normal stress. Using "tri Pstart Pstop Pdamp" is the same as
specifying these 7 keywords:
x Pstart Pstop Pdamp
y Pstart Pstop Pdamp
z Pstart Pstop Pdamp
xy 0.0 0.0 Pdamp
yz 0.0 0.0 Pdamp
xz 0.0 0.0 Pdamp
couple none :pre
:line
In some cases (e.g. for solids) the pressure (volume) and/or
temperature of the system can oscillate undesirably when a Nose/Hoover
barostat and thermostat is applied. The optional {drag} keyword will
damp these oscillations, although it alters the Nose/Hoover equations.
A value of 0.0 (no drag) leaves the Nose/Hoover formalism unchanged.
A non-zero value adds a drag term; the larger the value specified, the
greater the damping effect. Performing a short run and monitoring the
pressure and temperature is the best way to determine if the drag term
is working. Typically a value between 0.2 to 2.0 is sufficient to
damp oscillations after a few periods. Note that use of the drag
keyword will interfere with energy conservation and will also change
the distribution of positions and velocities so that they do not
correspond to the nominal NVT, NPT, or NPH ensembles.
An alternative way to control initial oscillations is to use chain
thermostats. The keyword {tchain} determines the number of thermostats
in the particle thermostat. A value of 1 corresponds to the original
Nose-Hoover thermostat. The keyword {pchain} specifies the number of
thermostats in the chain thermostatting the barostat degrees of
freedom. A value of 0 corresponds to no thermostatting of the
barostat variables.
The {mtk} keyword controls whether or not the correction terms due to
Martyna, Tuckerman, and Klein are included in the equations of motion
"(Martyna)"_#nh-Martyna. Specifying {no} reproduces the original
Hoover barostat, whose volume probability distribution function
differs from the true NPT and NPH ensembles by a factor of 1/V. Hence
using {yes} is more correct, but in many cases the difference is
negligible.
The keyword {tloop} can be used to improve the accuracy of integration
scheme at little extra cost. The initial and final updates of the
thermostat variables are broken up into {tloop} substeps, each of
length {dt}/{tloop}. This corresponds to using a first-order
Suzuki-Yoshida scheme "(Tuckerman)"_#nh-Tuckerman. The keyword {ploop}
does the same thing for the barostat thermostat.
The keyword {nreset} controls how often the reference dimensions used
to define the strain energy are reset. If this keyword is not used,
or is given a value of zero, then the reference dimensions are set to
those of the initial simulation domain and are never changed. If the
simulation domain changes significantly during the simulation, then
the final average pressure tensor will differ significantly from the
specified values of the external stress tensor. A value of {nstep}
means that every {nstep} timesteps, the reference dimensions are set
to those of the current simulation domain.
The {scaleyz}, {scalexz}, and {scalexy} keywords control whether or
not the corresponding tilt factors are scaled with the associated box
dimensions when barostatting triclinic periodic cells. The default
values {yes} will turn on scaling, which corresponds to adjusting the
linear dimensions of the cell while preserving its shape. Choosing
{no} ensures that the tilt factors are not scaled with the box
dimensions. See below for restrictions and default values in different
situations. In older versions of LAMMPS, scaling of tilt factors was
not performed. The old behavior can be recovered by setting all three
scale keywords to {no}.
The {flip} keyword allows the tilt factors for a triclinic box to
exceed half the distance of the parallel box length, as discussed
below. If the {flip} value is set to {yes}, the bound is enforced by
flipping the box when it is exceeded. If the {flip} value is set to
{no}, the tilt will continue to change without flipping. Note that if
applied stress induces large deformations (e.g. in a liquid), this
means the box shape can tilt dramatically and LAMMPS will run less
efficiently, due to the large volume of communication needed to
acquire ghost atoms around a processor's irregular-shaped sub-domain.
For extreme values of tilt, LAMMPS may also lose atoms and generate an
error.
The {fixedpoint} keyword specifies the fixed point for barostat volume
changes. By default, it is the center of the box. Whatever point is
chosen will not move during the simulation. For example, if the lower
periodic boundaries pass through (0,0,0), and this point is provided
to {fixedpoint}, then the lower periodic boundaries will remain at
(0,0,0), while the upper periodic boundaries will move twice as
far. In all cases, the particle trajectories are unaffected by the
chosen value, except for a time-dependent constant translation of
positions.
If the {update} keyword is used with the {dipole} value, then the
orientation of the dipole moment of each particle is also updated
during the time integration. This option should be used for models
where a dipole moment is assigned to finite-size particles,
e.g. spheroids via use of the "atom_style hybrid sphere
dipole"_atom_style.html command.
The default dipole orientation integrator can be changed to the
Dullweber-Leimkuhler-McLachlan integration scheme
"(Dullweber)"_#nh-Dullweber when using {update} with the value
{dipole/dlm}. This integrator is symplectic and time-reversible,
giving better energy conservation and allows slightly longer timesteps
at only a small additional computational cost.
:line
NOTE: Using a barostat coupled to tilt dimensions {xy}, {xz}, {yz} can
sometimes result in arbitrarily large values of the tilt dimensions,
i.e. a dramatically deformed simulation box. LAMMPS allows the tilt
factors to grow a small amount beyond the normal limit of half the box
length (0.6 times the box length), and then performs a box "flip" to
an equivalent periodic cell. See the discussion of the {flip} keyword
above, to allow this bound to be exceeded, if desired.
The flip operation is described in more detail in the doc page for
"fix deform"_fix_deform.html. Both the barostat dynamics and the atom
trajectories are unaffected by this operation. However, if a tilt
factor is incremented by a large amount (1.5 times the box length) on
a single timestep, LAMMPS can not accomodate this event and will
terminate the simulation with an error. This error typically indicates
that there is something badly wrong with how the simulation was
constructed, such as specifying values of {Pstart} that are too far
from the current stress value, or specifying a timestep that is too
large. Triclinic barostatting should be used with care. This also is
true for other barostat styles, although they tend to be more
forgiving of insults. In particular, it is important to recognize that
equilibrium liquids can not support a shear stress and that
equilibrium solids can not support shear stresses that exceed the
yield stress.
One exception to this rule is if the 1st dimension in the tilt factor
(x for xy) is non-periodic. In that case, the limits on the tilt
factor are not enforced, since flipping the box in that dimension does
not change the atom positions due to non-periodicity. In this mode,
if you tilt the system to extreme angles, the simulation will simply
become inefficient due to the highly skewed simulation box.
NOTE: Unlike the "fix temp/berendsen"_fix_temp_berendsen.html command
which performs thermostatting but NO time integration, these fixes
perform thermostatting/barostatting AND time integration. Thus you
should not use any other time integration fix, such as "fix
nve"_fix_nve.html on atoms to which this fix is applied. Likewise,
fix nvt and fix npt should not normally be used on atoms that also
have their temperature controlled by another fix - e.g. by "fix
langevin"_fix_nh.html or "fix temp/rescale"_fix_temp_rescale.html
commands.
See the "Howto thermostat"_Howto_thermostat.html and "Howto
barostat"_Howto_barostat.html doc pages for a discussion of different
ways to compute temperature and perform thermostatting and
barostatting.
:line
These fixes compute a temperature and pressure each timestep. To do
this, the thermostat and barostat fixes create their own computes of
style "temp" and "pressure", as if one of these sets of commands had
been issued:
For fix nvt:
compute fix-ID_temp group-ID temp
For fix npt and fix nph:
compute fix-ID_temp all temp
compute fix-ID_press all pressure fix-ID_temp :pre
For fix nvt, the group for the new temperature compute is the same as
the fix group. For fix npt and fix nph, the group for both the new
temperature and pressure compute is "all" since pressure is computed
for the entire system. In the case of fix nph, the temperature
compute is not used for thermostatting, but just for a kinetic-energy
contribution to the pressure. See the "compute
temp"_compute_temp.html and "compute pressure"_compute_pressure.html
commands for details. Note that the IDs of the new computes are the
fix-ID + underscore + "temp" or fix_ID + underscore + "press".
Note that these are NOT the computes used by thermodynamic output (see
the "thermo_style"_thermo_style.html command) with ID = {thermo_temp}
and {thermo_press}. This means you can change the attributes of these
fix's temperature or pressure via the
"compute_modify"_compute_modify.html command. Or you can print this
temperature or pressure during thermodynamic output via the
"thermo_style custom"_thermo_style.html command using the appropriate
compute-ID. It also means that changing attributes of {thermo_temp}
or {thermo_press} will have no effect on this fix.
Like other fixes that perform thermostatting, fix nvt and fix npt can
be used with "compute commands"_compute.html that calculate a
temperature after removing a "bias" from the atom velocities.
E.g. removing the center-of-mass velocity from a group of atoms or
only calculating temperature on the x-component of velocity or only
calculating temperature for atoms in a geometric region. This is not
done by default, but only if the "fix_modify"_fix_modify.html command
is used to assign a temperature compute to this fix that includes such
a bias term. See the doc pages for individual "compute
commands"_compute.html to determine which ones include a bias. In
this case, the thermostat works in the following manner: the current
temperature is calculated taking the bias into account, bias is
removed from each atom, thermostatting is performed on the remaining
thermal degrees of freedom, and the bias is added back in.
:line
These fixes can be used with either the {verlet} or {respa}
"integrators"_run_style.html. When using one of the barostat fixes
with {respa}, LAMMPS uses an integrator constructed
according to the following factorization of the Liouville propagator
(for two rRESPA levels):
:c,image(Eqs/fix_nh1.jpg)
This factorization differs somewhat from that of Tuckerman et al, in
that the barostat is only updated at the outermost rRESPA level,
whereas Tuckerman's factorization requires splitting the pressure into
pieces corresponding to the forces computed at each rRESPA level. In
theory, the latter method will exhibit better numerical stability. In
practice, because Pdamp is normally chosen to be a large multiple of
the outermost rRESPA timestep, the barostat dynamics are not the
limiting factor for numerical stability. Both factorizations are
time-reversible and can be shown to preserve the phase space measure
of the underlying non-Hamiltonian equations of motion.
NOTE: This implementation has been shown to conserve linear momentum
up to machine precision under NVT dynamics. Under NPT dynamics,
for a system with zero initial total linear momentum, the total
momentum fluctuates close to zero. It may occasionally undergo brief
excursions to non-negligible values, before returning close to zero.
Over long simulations, this has the effect of causing the center-of-mass
to undergo a slow random walk. This can be mitigated by resetting
the momentum at infrequent intervals using the
"fix momentum"_fix_momentum.html command.
:line
The fix npt and fix nph commands can be used with rigid bodies or
mixtures of rigid bodies and non-rigid particles (e.g. solvent). But
there are also "fix rigid/npt"_fix_rigid.html and "fix
rigid/nph"_fix_rigid.html commands, which are typically a more natural
choice. See the doc page for those commands for more discussion of
the various ways to do this.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed on the "Speed packages"_Speed_packages.html doc
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Build
package"_Build_package.html doc page for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
switch"_Run_options.html when you invoke LAMMPS, or you can use the
"suffix"_suffix.html command in your input script.
See the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
:line
[Restart, fix_modify, output, run start/stop, minimize info:]
These fixes writes the state of all the thermostat and barostat
variables to "binary restart files"_restart.html. See the
"read_restart"_read_restart.html command for info on how to re-specify
a fix in an input script that reads a restart file, so that the
operation of the fix continues in an uninterrupted fashion.
The "fix_modify"_fix_modify.html {temp} and {press} options are
supported by these fixes. You can use them to assign a
"compute"_compute.html you have defined to this fix which will be used
in its thermostatting or barostatting procedure, as described above.
If you do this, note that the kinetic energy derived from the compute
temperature should be consistent with the virial term computed using
all atoms for the pressure. LAMMPS will warn you if you choose to
compute temperature on a subset of atoms.
NOTE: If both the {temp} and {press} keywords are used in a single
thermo_modify command (or in two separate commands), then the order in
which the keywords are specified is important. Note that a "pressure
compute"_compute_pressure.html defines its own temperature compute as
an argument when it is specified. The {temp} keyword will override
this (for the pressure compute being used by fix npt), but only if the
{temp} keyword comes after the {press} keyword. If the {temp} keyword
comes before the {press} keyword, then the new pressure compute
specified by the {press} keyword will be unaffected by the {temp}
setting.
The "fix_modify"_fix_modify.html {energy} option is supported by these
fixes to add the energy change induced by Nose/Hoover thermostatting
and barostatting to the system's potential energy as part of
"thermodynamic output"_thermo_style.html.
These fixes compute a global scalar and a global vector of quantities,
which can be accessed by various "output commands"_Howto_output.html.
The scalar value calculated by these fixes is "extensive"; the vector
values are "intensive".
The scalar is the cumulative energy change due to the fix.
The vector stores internal Nose/Hoover thermostat and barostat
variables. The number and meaning of the vector values depends on
which fix is used and the settings for keywords {tchain} and {pchain},
which specify the number of Nose/Hoover chains for the thermostat and
barostat. If no thermostatting is done, then {tchain} is 0. If no
barostatting is done, then {pchain} is 0. In the following list,
"ndof" is 0, 1, 3, or 6, and is the number of degrees of freedom in
the barostat. Its value is 0 if no barostat is used, else its value
is 6 if any off-diagonal stress tensor component is barostatted, else
its value is 1 if {couple xyz} is used or {couple xy} for a 2d
simulation, otherwise its value is 3.
The order of values in the global vector and their meaning is as
follows. The notation means there are tchain values for eta, followed
by tchain for eta_dot, followed by ndof for omega, etc:
eta\[tchain\] = particle thermostat displacements (unitless)
eta_dot\[tchain\] = particle thermostat velocities (1/time units)
omega\[ndof\] = barostat displacements (unitless)
omega_dot\[ndof\] = barostat velocities (1/time units)
etap\[pchain\] = barostat thermostat displacements (unitless)
etap_dot\[pchain\] = barostat thermostat velocities (1/time units)
PE_eta\[tchain\] = potential energy of each particle thermostat displacement (energy units)
KE_eta_dot\[tchain\] = kinetic energy of each particle thermostat velocity (energy units)
PE_omega\[ndof\] = potential energy of each barostat displacement (energy units)
KE_omega_dot\[ndof\] = kinetic energy of each barostat velocity (energy units)
PE_etap\[pchain\] = potential energy of each barostat thermostat displacement (energy units)
KE_etap_dot\[pchain\] = kinetic energy of each barostat thermostat velocity (energy units)
PE_strain\[1\] = scalar strain energy (energy units) :ul
These fixes can ramp their external temperature and pressure over
multiple runs, using the {start} and {stop} keywords of the
"run"_run.html command. See the "run"_run.html command for details of
how to do this.
These fixes are not invoked during "energy
minimization"_minimize.html.
:line
[Restrictions:]
{X}, {y}, {z} cannot be barostatted if the associated dimension is not
periodic. {Xy}, {xz}, and {yz} can only be barostatted if the
simulation domain is triclinic and the 2nd dimension in the keyword
({y} dimension in {xy}) is periodic. {Z}, {xz}, and {yz}, cannot be
barostatted for 2D simulations. The "create_box"_create_box.html,
"read data"_read_data.html, and "read_restart"_read_restart.html
commands specify whether the simulation box is orthogonal or
non-orthogonal (triclinic) and explain the meaning of the xy,xz,yz
tilt factors.
For the {temp} keyword, the final Tstop cannot be 0.0 since it would
make the external T = 0.0 at some timestep during the simulation which
is not allowed in the Nose/Hoover formulation.
The {scaleyz yes} and {scalexz yes} keyword/value pairs can not be used
for 2D simulations. {scaleyz yes}, {scalexz yes}, and {scalexy yes} options
can only be used if the 2nd dimension in the keyword is periodic,
and if the tilt factor is not coupled to the barostat via keywords
{tri}, {yz}, {xz}, and {xy}.
Without the {cauchystat} keyword, the barostat algorithm
controls the Second-Piola Kirchhoff stress, which is a stress measure
referred to the undeformed (initial) simulation box. If the box
deforms substantially during the equilibration, the difference between
the set values and the final true (Cauchy) stresses can be
considerable.
The {cauchystat} keyword modifies the barostat as per Miller et
al. (Miller)_"#nh-Miller" so that the Cauchy stress is controlled.
{alpha} is the non-dimensional parameter, typically set to 0.001 or
0.01 that determines how aggresively the algorithm drives the system
towards the set Cauchy stresses. Larger values of {alpha} will modify
the system more quickly, but can lead to instabilities. Smaller
values will lead to longer convergence time. Since {alpha} also
influences how much the stress fluctuations deviate from the
equilibrium fluctuations, it should be set as small as possible.
A {continue} value of {yes} indicates that the fix is subsequent to a
previous run with the Cauchystat fix, and the intention is to continue
from the converged stress state at the end of the previous run. This
may be required, for example, when implementing a multi-step loading/unloading
sequence over several fixes.
Setting {alpha} to zero is not permitted. To "turn off" the
Cauchystat control and thus restore the equilibrium stress
fluctuations, two subsequent fixes should be used. In the first, the
Cauchystat is used and the simulation box equilibrates to the correct
shape for the desired stresses. In the second, the {fix} statement is
identical except that the {cauchystat} keyword is removed (along with
related {alpha} and {continue} values). This restores the original
Parrinello-Rahman algorithm, but now with the correct simulation box
shape from the first fix.
These fixes can be used with dynamic groups as defined by the
"group"_group.html command. Likewise they can be used with groups to
which atoms are added or deleted over time, e.g. a deposition
simulation. However, the conservation properties of the thermostat
and barostat are defined for systems with a static set of atoms. You
may observe odd behavior if the atoms in a group vary dramatically
over time or the atom count becomes very small.
[Related commands:]
"fix nve"_fix_nve.html, "fix_modify"_fix_modify.html,
"run_style"_run_style.html
[Default:]
The keyword defaults are tchain = 3, pchain = 3, mtk = yes, tloop =
ploop = 1, nreset = 0, drag = 0.0, dilate = all, couple = none,
cauchystat = no,
scaleyz = scalexz = scalexy = yes if periodic in 2nd dimension and
not coupled to barostat, otherwise no.
:line
:link(nh-Martyna)
[(Martyna)] Martyna, Tobias and Klein, J Chem Phys, 101, 4177 (1994).
:link(nh-Parrinello)
[(Parrinello)] Parrinello and Rahman, J Appl Phys, 52, 7182 (1981).
:link(nh-Tuckerman)
[(Tuckerman)] Tuckerman, Alejandre, Lopez-Rendon, Jochim, and
Martyna, J Phys A: Math Gen, 39, 5629 (2006).
:link(nh-Shinoda)
[(Shinoda)] Shinoda, Shiga, and Mikami, Phys Rev B, 69, 134103 (2004).
:link(nh-Dullweber)
[(Dullweber)] Dullweber, Leimkuhler and McLachlan, J Chem Phys, 107,
5840 (1997).
:link(nh-Miller)
[(Miller)] Miller, Tadmor, Gibson, Bernstein and Pavia, J Chem Phys,
144, 184107 (2016).

2
doc/src/fix_client_md.txt
View File

@ -50,7 +50,7 @@ md"_server_md.html doc page.
Note that when using LAMMPS as an MD client, your LAMMPS input script
should not normally contain force field commands, like a
"pair_style"_doc/pair_style.html, "bond_style"_doc/bond_style.html, or
"pair_style"_pair_style.html, "bond_style"_bond_style.html, or
"kspace_style"_kspace_style.html commmand. However it is possible for
a server code to only compute a portion of the full force-field, while
LAMMPS computes the remaining part. Your LAMMPS script can also

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

@ -0,0 +1,124 @@
<script type="text/javascript"
src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML">
</script>
<script type="text/x-mathjax-config">
MathJax.Hub.Config({ TeX: { equationNumbers: {autoNumber: "AMS"} } });
</script>
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
fix ffl command :h3
[Syntax:]
fix ID id-group ffl tau Tstart Tstop seed \[flip-type\] :pre
ID, group-ID are documented in "fix"_fix.html command :ulb,l
ffl = style name of this fix command :l
tau = thermostat parameter (positive real) :l
Tstart, Tstop = temperature ramp during the run :l
seed = random number seed to use for generating noise (positive integer) :l
one more value may be appended :l
flip-type = determines the flipping type, can be chosen between rescale - no_flip - hard - soft, if no flip type is given, rescale will be chosen by default :pre
:ule
[Examples:]
fix 3 boundary ffl 10 300 300 31415
fix 1 all ffl 100 500 500 9265 soft :pre
[Description:]
Apply a Fast-Forward Langevin Equation (FFL) thermostat as described
in "(Hijazi)"_#Hijazi. Contrary to
"fix langevin"_fix_langevin.html, this fix performs both
thermostatting and evolution of the Hamiltonian equations of motion, so it
should not be used together with "fix nve"_fix_nve.html -- at least not
on the same atom groups.
The time-evolution of a single particle undergoing Langevin dynamics is described
by the equations
\begin\{equation\} \frac \{dq\}\{dt\} = \frac\{p\}\{m\}, \end\{equation\}
\begin\{equation\} \frac \{dp\}\{dt\} = -\gamma p + W + F, \end\{equation\}
where \(F\) is the physical force, \(\gamma\) is the friction coefficient, and \(W\) is a
Gaussian random force.
The friction coefficient is the inverse of the thermostat parameter : \(\gamma = 1/\tau\), with \(\tau\) the thermostat parameter {tau}.
The thermostat parameter is given in the time units, \(\gamma\) is in inverse time units.
Equilibrium sampling a temperature T is obtained by specifying the
target value as the {Tstart} and {Tstop} arguments, so that the internal
constants depending on the temperature are computed automatically.
The random number {seed} must be a positive integer. A Marsaglia random
number generator is used. Each processor uses the input seed to
generate its own unique seed and its own stream of random numbers.
Thus the dynamics of the system will not be identical on two runs on
different numbers of processors.
The flipping type {flip-type} can be chosen between 4 types described in
"(Hijazi)"_#Hijazi. The flipping operation occurs during the thermostatting
step and it flips the momenta of the atoms. If no_flip is chosen, no flip
will be executed and the integration will be the same as a standard
Langevin thermostat "(Bussi)"_#Bussi3. The other flipping types are : rescale - hard - soft.
[Restart, fix_modify, output, run start/stop, minimize info:]
The instantaneous values of the extended variables are written to
"binary restart files"_restart.html. Because the state of the random
number generator is not saved in restart files, this means you cannot
do "exact" restarts with this fix, where the simulation continues on
the same as if no restart had taken place. However, in a statistical
sense, a restarted simulation should produce the same behavior.
Note however that you should use a different seed each time you
restart, otherwise the same sequence of random numbers will be used
each time, which might lead to stochastic synchronization and
subtle artefacts in the sampling.
This fix can ramp its target temperature over multiple runs, using the
{start} and {stop} keywords of the "run"_run.html command. See the
"run"_run.html command for details of how to do this.
The "fix_modify"_fix_modify.html {energy} option is supported by this
fix to add the energy change induced by Langevin thermostatting to the
system's potential energy as part of "thermodynamic
output"_thermo_style.html.
This fix computes a global scalar which can be accessed by various
"output commands"_Howto_output.html. The scalar is the cumulative
energy change due to this fix. The scalar value calculated by this
fix is "extensive".
[Restrictions:]
In order to perform constant-pressure simulations please use
"fix press/berendsen"_fix_press_berendsen.html, rather than
"fix npt"_fix_nh.html, to avoid duplicate integration of the
equations of motion.
This fix is part of the USER-MISC package. It is only enabled if
LAMMPS was built with that package. See the "Build
package"_Build_package.html doc page for more info.
[Related commands:]
"fix nvt"_fix_nh.html, "fix temp/rescale"_fix_temp_rescale.html, "fix
viscous"_fix_viscous.html, "fix nvt"_fix_nh.html, "pair_style
dpd/tstat"_pair_dpd.html, "fix gld"_fix_gld.html, "fix gle"_fix_gle.html
:line
:link(Hijazi)
[(Hijazi)] M. Hijazi, D. M. Wilkins, M. Ceriotti, J. Chem. Phys. 148, 184109 (2018)
:link(Bussi3)
[(Bussi)] G. Bussi, M. Parrinello, Phs. Rev. E 75, 056707 (2007)

1
doc/src/fix_freeze.txt
View File

@ -7,6 +7,7 @@
:line
fix freeze command :h3
fix freeze/kk command :h3
[Syntax:]

1
doc/src/fix_gravity.txt
View File

@ -8,6 +8,7 @@
fix gravity command :h3
fix gravity/omp command :h3
fix gravity/kk command :h3
[Syntax:]

3
doc/src/fix_halt.txt
View File

@ -135,8 +135,7 @@ files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various "output commands"_Howto_output.html.
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command. This fix is not invoked during "energy
minimization"_minimize.html.
the "run"_run.html command.
[Restrictions:] none

2
doc/src/fix_msst.txt
View File

@ -6,7 +6,7 @@
:line
fix msst command :h3
fix msst command :h3
[Syntax:]

56
doc/src/fix_nve_awpmd.txt Normal file
View File

@ -0,0 +1,56 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
fix nve/awpmd command :h3
[Syntax:]
fix ID group-ID nve/awpmd :pre
ID, group-ID are documented in "fix"_fix.html command
nve/awpmd = style name of this fix command :ul
[Examples:]
fix 1 all nve/awpmd :pre
[Description:]
Perform constant NVE integration to update position and velocity for
nuclei and electrons in the group for the "Antisymmetrized Wave Packet
Molecular Dynamics"_pair_awpmd.html model. V is volume; E is energy.
This creates a system trajectory consistent with the microcanonical
ensemble.
The operation of this fix is exactly like that described by the "fix
nve"_fix_nve.html command, except that the width and width-velocity of
the electron wavefunctions are also updated.
:line
[Restart, fix_modify, output, run start/stop, minimize info:]
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various "output commands"_Howto_output.html.
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command. This fix is not invoked during "energy
minimization"_minimize.html.
[Restrictions:]
This fix is part of the USER-AWPMD package. It is only enabled if
LAMMPS was built with that package. See the "Build
package"_Build_package.html doc page for more info.
[Related commands:]
"fix nve"_fix_nve.html
[Default:] none

1
doc/src/fix_nve_sphere.txt
View File

@ -8,6 +8,7 @@
fix nve/sphere command :h3
fix nve/sphere/omp command :h3
fix nve/sphere/kk command :h3
[Syntax:]

9
doc/src/fix_nvt_sllod.txt
View File

@ -63,6 +63,11 @@ implemented in LAMMPS, they are coupled to a Nose/Hoover chain
thermostat in a velocity Verlet formulation, closely following the
implementation used for the "fix nvt"_fix_nh.html command.
NOTE: A recent (2017) book by "(Daivis and Todd)"_#Daivis-sllod
discusses use of the SLLOD method and non-equilibrium MD (NEMD)
thermostatting generally, for both simple and complex fluids,
e.g. molecular systems. The latter can be tricky to do correctly.
Additional parameters affecting the thermostat are specified by
keywords and values documented with the "fix nvt"_fix_nh.html
command. See, for example, discussion of the {temp} and {drag}
@ -177,3 +182,7 @@ Same as "fix nvt"_fix_nh.html, except tchain = 1.
:link(Daivis)
[(Daivis and Todd)] Daivis and Todd, J Chem Phys, 124, 194103 (2006).
:link(Daivis-sllod)
[(Daivis and Todd)] Daivis and Todd, Nonequilibrium Molecular Dyanmics (book),
Cambridge University Press, https://doi.org/10.1017/9781139017848, (2017).

2
doc/src/fix_poems.txt
View File

@ -6,7 +6,7 @@
:line
fix poems :h3
fix poems command :h3
Syntax:

24
doc/src/fix_property_atom.txt
View File

@ -7,6 +7,7 @@
:line
fix property/atom command :h3
fix property/atom/kk command :h3
[Syntax:]
@ -201,6 +202,7 @@ added classes.
:line
:link(isotopes)
Example for using per-atom masses with TIP4P water to
study isotope effects. When setting up simulations with the "TIP4P
pair styles"_Howto_tip4p.html for water, you have to provide exactly
@ -238,6 +240,28 @@ set group hwat mass 2.0141018 :pre
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed on the "Speed packages"_Speed_packages.html doc
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Build
package"_Build_package.html doc page for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
switch"_Run_options.html when you invoke LAMMPS, or you can use the
"suffix"_suffix.html command in your input script.
See the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
:line
[Restart, fix_modify, output, run start/stop, minimize info:]
This fix writes the per-atom values it stores to "binary restart

6
doc/src/fix_shake.txt
View File

@ -214,8 +214,10 @@ which can lead to poor energy conservation. You can test for this in
your system by running a constant NVE simulation with a particular set
of SHAKE parameters and monitoring the energy versus time.
SHAKE or RATTLE should not be used to constrain an angle at 180 degrees
(e.g. linear CO2 molecule). This causes numeric difficulties.
SHAKE or RATTLE should not be used to constrain an angle at 180
degrees (e.g. linear CO2 molecule). This causes numeric difficulties.
You can use "fix rigid or fix rigid/small"_fix_rigid.html instead to
make a linear molecule rigid.
[Related commands:] none

2
doc/src/fix_smd_move_triangulated_surface.txt
View File

@ -73,7 +73,7 @@ package"_Build_package.html doc page for more info.
[Related commands:]
"smd/triangle_mesh_vertices"_compute_smd_triangle_mesh_vertices.html,
"smd/triangle_mesh_vertices"_compute_smd_triangle_vertices.html,
"smd/wall_surface"_fix_smd_wall_surface.html
[Default:] none

2
doc/src/fix_smd_wall_surface.txt
View File

@ -64,7 +64,7 @@ multiple objects in one file.
[Related commands:]
"smd/triangle_mesh_vertices"_compute_smd_triangle_mesh_vertices.html,
"smd/triangle_mesh_vertices"_compute_smd_triangle_vertices.html,
"smd/move_tri_surf"_fix_smd_move_triangulated_surface.html,
"smd/tri_surface"_pair_smd_triangulated_surface.html

19
doc/src/fix_surface_global.txt
View File

@ -1,19 +0,0 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
fix wall/surface/global command :h3
[Description:]
This feature is not yet implemented.
[Related commands:]
"dump image"_dump_image.html

23
doc/src/fix_wall_gran.txt
View File

@ -7,6 +7,7 @@
:line
fix wall/gran command :h3
fix wall/gran/omp command :h3
[Syntax:]
@ -136,6 +137,28 @@ the clockwise direction for {vshear} > 0 or counter-clockwise for
{vshear} < 0. In this case, {vshear} is the tangential velocity of
the wall at whatever {radius} has been defined.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed on the "Speed packages"_Speed_packages.html doc
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Build
package"_Build_package.html doc page for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
switch"_Run_options.html when you invoke LAMMPS, or you can use the
"suffix"_suffix.html command in your input script.
See the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
[Restart, fix_modify, output, run start/stop, minimize info:]
This fix writes the shear friction state of atoms interacting with the

5
doc/src/fixes.txt
View File

@ -26,6 +26,7 @@ Fixes :h1
fix_bond_swap
fix_bond_react
fix_box_relax
fix_client_md
fix_cmap
fix_colvars
fix_controller
@ -45,6 +46,7 @@ Fixes :h1
fix_eos_table_rx
fix_evaporate
fix_external
fix_ffl
fix_filter_corotate
fix_flow_gauss
fix_freeze
@ -87,10 +89,12 @@ Fixes :h1
fix_nphug
fix_npt_asphere
fix_npt_body
fix_cauchy
fix_npt_sphere
fix_nve
fix_nve_asphere
fix_nve_asphere_noforce
fix_nve_awpmd
fix_nve_body
fix_nve_dot
fix_nve_dotc_langevin
@ -153,7 +157,6 @@ Fixes :h1
fix_srd
fix_store_force
fix_store_state
fix_surface_global
fix_temp_berendsen
fix_temp_csvr
fix_temp_rescale

471
doc/src/kspace_modify.txt
View File

@ -13,47 +13,53 @@ kspace_modify command :h3
kspace_modify keyword value ... :pre
one or more keyword/value pairs may be listed :ulb,l
keyword = {mesh} or {order} or {order/disp} or {mix/disp} or {overlap} or {minorder} or {force} or {gewald} or {gewald/disp} or {slab} or (nozforce} or {compute} or {cutoff/adjust} or {fftbench} or {collective} or {diff} or {kmax/ewald} or {force/disp/real} or {force/disp/kspace} or {splittol} or {disp/auto}:l
{mesh} value = x y z
x,y,z = grid size in each dimension for long-range Coulombics
{mesh/disp} value = x y z
x,y,z = grid size in each dimension for 1/r^6 dispersion
{order} value = N
N = extent of Gaussian for PPPM or MSM mapping of charge to grid
{order/disp} value = N
N = extent of Gaussian for PPPM mapping of dispersion term to grid
{mix/disp} value = {pair} or {geom} or {none}
{overlap} = {yes} or {no} = whether the grid stencil for PPPM is allowed to overlap into more than the nearest-neighbor processor
{minorder} value = M
M = min allowed extent of Gaussian when auto-adjusting to minimize grid communication
keyword = {collective} or {compute} or {cutoff/adjust} or {diff} or {disp/auto} or {fftbench} or {force/disp/kspace} or {force/disp/real} or {force} or {gewald/disp} or {gewald} or {kmax/ewald} or {mesh} or {minorder} or {mix/disp} or {order/disp} or {order} or {overlap} or {scafacos} or {slab} or {splittol} :l
{collective} value = {yes} or {no}
{compute} value = {yes} or {no}
{cutoff/adjust} value = {yes} or {no}
{diff} value = {ad} or {ik} = 2 or 4 FFTs for PPPM in smoothed or non-smoothed mode
{disp/auto} value = yes or no
{fftbench} value = {yes} or {no}
{force/disp/real} value = accuracy (force units)
{force/disp/kspace} value = accuracy (force units)
{force} value = accuracy (force units)
{gewald} value = rinv (1/distance units)
rinv = G-ewald parameter for Coulombics
{gewald/disp} value = rinv (1/distance units)
rinv = G-ewald parameter for dispersion
{kmax/ewald} value = kx ky kz
kx,ky,kz = number of Ewald sum kspace vectors in each dimension
{mesh} value = x y z
x,y,z = grid size in each dimension for long-range Coulombics
{mesh/disp} value = x y z
x,y,z = grid size in each dimension for 1/r^6 dispersion
{minorder} value = M
M = min allowed extent of Gaussian when auto-adjusting to minimize grid communication
{mix/disp} value = {pair} or {geom} or {none}
{order} value = N
N = extent of Gaussian for PPPM or MSM mapping of charge to grid
{order/disp} value = N
N = extent of Gaussian for PPPM mapping of dispersion term to grid
{overlap} = {yes} or {no} = whether the grid stencil for PPPM is allowed to overlap into more than the nearest-neighbor processor
{pressure/scalar} value = {yes} or {no}
{scafacos} values = option value1 value2 ...
option = {tolerance}
value = {energy} or {energy_rel} or {field} or {field_rel} or {potential} or {potential_rel}
option = {fmm_tuning}
value = {0} or {1}
{slab} value = volfactor or {nozforce}
volfactor = ratio of the total extended volume used in the
2d approximation compared with the volume of the simulation domain
{nozforce} turns off kspace forces in the z direction
{compute} value = {yes} or {no}
{cutoff/adjust} value = {yes} or {no}
{pressure/scalar} value = {yes} or {no}
{fftbench} value = {yes} or {no}
{collective} value = {yes} or {no}
{diff} value = {ad} or {ik} = 2 or 4 FFTs for PPPM in smoothed or non-smoothed mode
{kmax/ewald} value = kx ky kz
kx,ky,kz = number of Ewald sum kspace vectors in each dimension
{force/disp/real} value = accuracy (force units)
{force/disp/kspace} value = accuracy (force units)
{splittol} value = tol
tol = relative size of two eigenvalues (see discussion below)
{disp/auto} value = yes or no :pre
tol = relative size of two eigenvalues (see discussion below) :pre
:ule
[Examples:]
kspace_modify mesh 24 24 30 order 6
kspace_modify slab 3.0 :pre
kspace_modify slab 3.0
kspace_modify scafacos tolerance energy :pre
[Description:]
@ -61,6 +67,132 @@ Set parameters used by the kspace solvers defined by the
"kspace_style"_kspace_style.html command. Not all parameters are
relevant to all kspace styles.
:line
The {collective} keyword applies only to PPPM. It is set to {no} by
default, except on IBM BlueGene machines. If this option is set to
{yes}, LAMMPS will use MPI collective operations to remap data for
3d-FFT operations instead of the default point-to-point communication.
This is faster on IBM BlueGene machines, and may also be faster on
other machines if they have an efficient implementation of MPI
collective operations and adequate hardware.
:line
The {compute} keyword allows Kspace computations to be turned off,
even though a "kspace_style"_kspace_style.html is defined. This is
not useful for running a real simulation, but can be useful for
debugging purposes or for computing only partial forces that do not
include the Kspace contribution. You can also do this by simply not
defining a "kspace_style"_kspace_style.html, but a Kspace-compatible
"pair_style"_pair_style.html requires a kspace style to be defined.
This keyword gives you that option.
:line
The {cutoff/adjust} keyword applies only to MSM. If this option is
turned on, the Coulombic cutoff will be automatically adjusted at the
beginning of the run to give the desired estimated error. Other
cutoffs such as LJ will not be affected. If the grid is not set using
the {mesh} command, this command will also attempt to use the optimal
grid that minimizes cost using an estimate given by
"(Hardy)"_#Hardy1. Note that this cost estimate is not exact, somewhat
experimental, and still may not yield the optimal parameters.
:line
The {diff} keyword specifies the differentiation scheme used by the
PPPM method to compute forces on particles given electrostatic
potentials on the PPPM mesh. The {ik} approach is the default for
PPPM and is the original formulation used in "(Hockney)"_#Hockney1. It
performs differentiation in Kspace, and uses 3 FFTs to transfer each
component of the computed fields back to real space for total of 4
FFTs per timestep.
The analytic differentiation {ad} approach uses only 1 FFT to transfer
information back to real space for a total of 2 FFTs per timestep. It
then performs analytic differentiation on the single quantity to
generate the 3 components of the electric field at each grid point.
This is sometimes referred to as "smoothed" PPPM. This approach
requires a somewhat larger PPPM mesh to achieve the same accuracy as
the {ik} method. Currently, only the {ik} method (default) can be
used for a triclinic simulation cell with PPPM. The {ad} method is
always used for MSM.
NOTE: Currently, not all PPPM styles support the {ad} option. Support
for those PPPM variants will be added later.
:line
The {disp/auto} option controls whether the pppm/disp is allowed to
generate PPPM parameters automatically. If set to {no}, parameters have
to be specified using the {gewald/disp}, {mesh/disp},
{force/disp/real} or {force/disp/kspace} keywords, or
the code will stop with an error message. When this option is set to
{yes}, the error message will not appear and the simulation will start.
For a typical application, using the automatic parameter generation
will provide simulations that are either inaccurate or slow. Using this
option is thus not recommended. For guidelines on how to obtain good
parameters, see the "How-To"_Howto_dispersion.html discussion.
:line
The {fftbench} keyword applies only to PPPM. It is off by default. If
this option is turned on, LAMMPS will perform a short FFT benchmark
computation and report its timings, and will thus finish a some seconds
later than it would if this option were off.
:line
The {force/disp/real} and {force/disp/kspace} keywords set the force
accuracy for the real and space computations for the dispersion part
of pppm/disp. As shown in "(Isele-Holder)"_#Isele-Holder1, optimal
performance and accuracy in the results is obtained when these values
are different.
:line
The {force} keyword overrides the relative accuracy parameter set by
the "kspace_style"_kspace_style.html command with an absolute
accuracy. The accuracy determines the RMS error in per-atom forces
calculated by the long-range solver and is thus specified in force
units. A negative value for the accuracy setting means to use the
relative accuracy parameter. The accuracy setting is used in
conjunction with the pairwise cutoff to determine the number of
K-space vectors for style {ewald}, the FFT grid size for style
{pppm}, or the real space grid size for style {msm}.
:line
The {gewald} keyword sets the value of the Ewald or PPPM G-ewald
parameter for charge as {rinv} in reciprocal distance units. Without
this setting, LAMMPS chooses the parameter automatically as a function
of cutoff, precision, grid spacing, etc. This means it can vary from
one simulation to the next which may not be desirable for matching a
KSpace solver to a pre-tabulated pairwise potential. This setting can
also be useful if Ewald or PPPM fails to choose a good grid spacing
and G-ewald parameter automatically. If the value is set to 0.0,
LAMMPS will choose the G-ewald parameter automatically. MSM does not
use the {gewald} parameter.
:line
The {gewald/disp} keyword sets the value of the Ewald or PPPM G-ewald
parameter for dispersion as {rinv} in reciprocal distance units. It
has the same meaning as the {gewald} setting for Coulombics.
:line
The {kmax/ewald} keyword sets the number of kspace vectors in each
dimension for kspace style {ewald}. The three values must be positive
integers, or else (0,0,0), which unsets the option. When this option
is not set, the Ewald sum scheme chooses its own kspace vectors,
consistent with the user-specified accuracy and pairwise cutoff. In
any case, if kspace style {ewald} is invoked, the values used are
printed to the screen and the log file at the start of the run.
:line
The {mesh} keyword sets the grid size for kspace style {pppm} or
{msm}. In the case of PPPM, this is the FFT mesh, and each dimension
must be factorizable into powers of 2, 3, and 5. In the case of MSM,
@ -70,6 +202,8 @@ or MSM solver chooses its own grid size, consistent with the
user-specified accuracy and pairwise cutoff. Values for x,y,z of
0,0,0 unset the option.
:line
The {mesh/disp} keyword sets the grid size for kspace style
{pppm/disp}. This is the FFT mesh for long-range dispersion and ach
dimension must be factorizable into powers of 2, 3, and 5. When this
@ -77,39 +211,7 @@ option is not set, the PPPM solver chooses its own grid size,
consistent with the user-specified accuracy and pairwise cutoff.
Values for x,y,z of 0,0,0 unset the option.
The {order} keyword determines how many grid spacings an atom's charge
extends when it is mapped to the grid in kspace style {pppm} or {msm}.
The default for this parameter is 5 for PPPM and 8 for MSM, which
means each charge spans 5 or 8 grid cells in each dimension,
respectively. For the LAMMPS implementation of MSM, the order can
range from 4 to 10 and must be even. For PPPM, the minimum allowed
setting is 2 and the maximum allowed setting is 7. The larger the
value of this parameter, the smaller that LAMMPS will set the grid
size, to achieve the requested accuracy. Conversely, the smaller the
order value, the larger the grid size will be. Note that there is an
inherent trade-off involved: a small grid will lower the cost of FFTs
or MSM direct sum, but a larger order parameter will increase the cost
of interpolating charge/fields to/from the grid.
The {order/disp} keyword determines how many grid spacings an atom's
dispersion term extends when it is mapped to the grid in kspace style
{pppm/disp}. It has the same meaning as the {order} setting for
Coulombics.
The {overlap} keyword can be used in conjunction with the {minorder}
keyword with the PPPM styles to adjust the amount of communication
that occurs when values on the FFT grid are exchanged between
processors. This communication is distinct from the communication
inherent in the parallel FFTs themselves, and is required because
processors interpolate charge and field values using grid point values
owned by neighboring processors (i.e. ghost point communication). If
the {overlap} keyword is set to {yes} then this communication is
allowed to extend beyond nearest-neighbor processors, e.g. when using
lots of processors on a small problem. If it is set to {no} then the
communication will be limited to nearest-neighbor processors and the
{order} setting will be reduced if necessary, as explained by the
{minorder} keyword discussion. The {overlap} keyword is always set to
{yes} in MSM.
:line
The {minorder} keyword allows LAMMPS to reduce the {order} setting if
necessary to keep the communication of ghost grid point limited to
@ -126,6 +228,42 @@ error if the grid communication is non-nearest-neighbor and {overlap}
is set to {no}. The {minorder} keyword is not currently supported in
MSM.
:line
The {mix/disp} keyword selects the mixing rule for the dispersion
coefficients. With {pair}, the dispersion coefficients of unlike
types are computed as indicated with "pair_modify"_pair_modify.html.
With {geom}, geometric mixing is enforced on the dispersion
coefficients in the kspace coefficients. When using the arithmetic
mixing rule, this will speed-up the simulations but introduces some
error in the force computations, as shown in "(Wennberg)"_#Wennberg.
With {none}, it is assumed that no mixing rule is
applicable. Splitting of the dispersion coefficients will be performed
as described in "(Isele-Holder)"_#Isele-Holder1.
This splitting can be influenced with the {splittol} keywords. Only
the eigenvalues that are larger than tol compared to the largest
eigenvalues are included. Using this keywords the original matrix of
dispersion coefficients is approximated. This leads to faster
computations, but the accuracy in the reciprocal space computations of
the dispersion part is decreased.
:line
The {order} keyword determines how many grid spacings an atom's charge
extends when it is mapped to the grid in kspace style {pppm} or {msm}.
The default for this parameter is 5 for PPPM and 8 for MSM, which
means each charge spans 5 or 8 grid cells in each dimension,
respectively. For the LAMMPS implementation of MSM, the order can
range from 4 to 10 and must be even. For PPPM, the minimum allowed
setting is 2 and the maximum allowed setting is 7. The larger the
value of this parameter, the smaller that LAMMPS will set the grid
size, to achieve the requested accuracy. Conversely, the smaller the
order value, the larger the grid size will be. Note that there is an
inherent trade-off involved: a small grid will lower the cost of FFTs
or MSM direct sum, but a larger order parameter will increase the cost
of interpolating charge/fields to/from the grid.
The PPPM order parameter may be reset by LAMMPS when it sets up the
FFT grid if the implied grid stencil extends beyond the grid cells
owned by neighboring processors. Typically this will only occur when
@ -134,30 +272,102 @@ be generated indicating the order parameter is being reduced to allow
LAMMPS to run the problem. Automatic adjustment of the order parameter
is not supported in MSM.
The {force} keyword overrides the relative accuracy parameter set by
the "kspace_style"_kspace_style.html command with an absolute
accuracy. The accuracy determines the RMS error in per-atom forces
calculated by the long-range solver and is thus specified in force
units. A negative value for the accuracy setting means to use the
relative accuracy parameter. The accuracy setting is used in
conjunction with the pairwise cutoff to determine the number of
K-space vectors for style {ewald}, the FFT grid size for style
{pppm}, or the real space grid size for style {msm}.
:line
The {gewald} keyword sets the value of the Ewald or PPPM G-ewald
parameter for charge as {rinv} in reciprocal distance units. Without
this setting, LAMMPS chooses the parameter automatically as a function
of cutoff, precision, grid spacing, etc. This means it can vary from
one simulation to the next which may not be desirable for matching a
KSpace solver to a pre-tabulated pairwise potential. This setting can
also be useful if Ewald or PPPM fails to choose a good grid spacing
and G-ewald parameter automatically. If the value is set to 0.0,
LAMMPS will choose the G-ewald parameter automatically. MSM does not
use the {gewald} parameter.
The {order/disp} keyword determines how many grid spacings an atom's
dispersion term extends when it is mapped to the grid in kspace style
{pppm/disp}. It has the same meaning as the {order} setting for
Coulombics.
The {gewald/disp} keyword sets the value of the Ewald or PPPM G-ewald
parameter for dispersion as {rinv} in reciprocal distance units. It
has the same meaning as the {gewald} setting for Coulombics.
:line
The {overlap} keyword can be used in conjunction with the {minorder}
keyword with the PPPM styles to adjust the amount of communication
that occurs when values on the FFT grid are exchanged between
processors. This communication is distinct from the communication
inherent in the parallel FFTs themselves, and is required because
processors interpolate charge and field values using grid point values
owned by neighboring processors (i.e. ghost point communication). If
the {overlap} keyword is set to {yes} then this communication is
allowed to extend beyond nearest-neighbor processors, e.g. when using
lots of processors on a small problem. If it is set to {no} then the
communication will be limited to nearest-neighbor processors and the
{order} setting will be reduced if necessary, as explained by the
{minorder} keyword discussion. The {overlap} keyword is always set to
{yes} in MSM.
:line
The {pressure/scalar} keyword applies only to MSM. If this option is
turned on, only the scalar pressure (i.e. (Pxx + Pyy + Pzz)/3.0) will
be computed, which can be used, for example, to run an isotropic barostat.
Computing the full pressure tensor with MSM is expensive, and this option
provides a faster alternative. The scalar pressure is computed using a
relationship between the Coulombic energy and pressure "(Hummer)"_#Hummer
instead of using the virial equation. This option cannot be used to access
individual components of the pressure tensor, to compute per-atom virial,
or with suffix kspace/pair styles of MSM, like OMP or GPU.
:line
The {scafacos} keyword is used for settings that are passed to the
ScaFaCoS library when using "kspace_style scafacos"_kspace_style.html.
The {tolerance} option affects how the {accuracy} specified with the
"kspace_style"_kspace_style.html command is interpreted by ScaFaCoS.
The following values may be used:
energy = absolute accuracy in total Coulomic energy
energy_rel = relative accuracy in total Coulomic energy
potential = absolute accuracy in total Coulomic potential
potential_rel = relative accuracy in total Coulomic potential
field = absolute accuracy in electric field
field_rel = relative accuracy in electric field :ul
The values with suffix _rel indicate the tolerance is a relative
tolerance; the other values impose an absolute tolerance on the given
quantity. Absoulte tolerance in this case means, that for a given
quantity q and a given absolute tolerance of t_a the result should
be between q-t_a and q+t_a. For a relative tolerance t_r the relative
error should not be greater than t_r, i.e. abs(1 - (result/q)) < t_r.
As a consequence of this, the tolerance type should be checked, when
performing computations with a high absolute field / energy. E.g.
if the total energy in the system is 1000000.0 an absolute tolerance
of 1e-3 would mean that the result has to be between 999999.999 and
1000000.001, which would be equivalent to a relative tolerance of
1e-9.
The energy and energy_rel values, set a tolerance based on the total
Coulomic energy of the system. The potential and potential_rel set a
tolerance based on the per-atom Coulomic energy. The field and
field_rel tolerance types set a tolerance based on the electric field
values computed by ScaFaCoS. Since per-atom forces are derived from
the per-atom electric field, this effectively sets a tolerance on the
forces, simimlar to other LAMMPS KSpace styles, as explained on the
"kspace_style"_kspace_style.html doc page.
Note that not all ScaFaCoS solvers support all tolerance types.
These are the allowed values for each method:
fmm = energy and energy_rel
p2nfft = field (1d-,2d-,3d-periodic systems) or potential (0d-periodic)
p3m = field
ewald = field
direct = has no tolerance tuning :ul
If the tolerance type is not changed, the default values for the
tolerance type are the first values in the above list, e.g. energy
is the default tolerance type for the fmm solver.
The {fmm_tuning} option is only relevant when using the FMM method.
It activates (value=1) or deactivates (value=0) an internal tuning
mechanism for the FMM solver. The tuning operation runs sequentially
and can be very time-consuming. Usually it is not needed for systems
with a homogenous charge distribution. The default for this option is
therefore {0}. The FMM internal tuning is performed once, when the
solver is set up.
:line
The {slab} keyword allows an Ewald or PPPM solver to be used for a
systems that are periodic in x,y but non-periodic in z - a
@ -191,92 +401,7 @@ the "fix efield"_fix_efield.html command, it will not give the correct
dielectric constant due to the Yeh/Berkowitz "(Yeh)"_#Yeh correction
not being compatible with how "fix efield"_fix_efield.html works.
The {compute} keyword allows Kspace computations to be turned off,
even though a "kspace_style"_kspace_style.html is defined. This is
not useful for running a real simulation, but can be useful for
debugging purposes or for computing only partial forces that do not
include the Kspace contribution. You can also do this by simply not
defining a "kspace_style"_kspace_style.html, but a Kspace-compatible
"pair_style"_pair_style.html requires a kspace style to be defined.
This keyword gives you that option.
The {cutoff/adjust} keyword applies only to MSM. If this option is
turned on, the Coulombic cutoff will be automatically adjusted at the
beginning of the run to give the desired estimated error. Other
cutoffs such as LJ will not be affected. If the grid is not set using
the {mesh} command, this command will also attempt to use the optimal
grid that minimizes cost using an estimate given by
"(Hardy)"_#Hardy1. Note that this cost estimate is not exact, somewhat
experimental, and still may not yield the optimal parameters.
The {pressure/scalar} keyword applies only to MSM. If this option is
turned on, only the scalar pressure (i.e. (Pxx + Pyy + Pzz)/3.0) will
be computed, which can be used, for example, to run an isotropic barostat.
Computing the full pressure tensor with MSM is expensive, and this option
provides a faster alternative. The scalar pressure is computed using a
relationship between the Coulombic energy and pressure "(Hummer)"_#Hummer
instead of using the virial equation. This option cannot be used to access
individual components of the pressure tensor, to compute per-atom virial,
or with suffix kspace/pair styles of MSM, like OMP or GPU.
The {fftbench} keyword applies only to PPPM. It is off by default. If
this option is turned on, LAMMPS will perform a short FFT benchmark
computation and report its timings, and will thus finish a some seconds
later than it would if this option were off.
The {collective} keyword applies only to PPPM. It is set to {no} by
default, except on IBM BlueGene machines. If this option is set to
{yes}, LAMMPS will use MPI collective operations to remap data for
3d-FFT operations instead of the default point-to-point communication.
This is faster on IBM BlueGene machines, and may also be faster on
other machines if they have an efficient implementation of MPI
collective operations and adequate hardware.
The {diff} keyword specifies the differentiation scheme used by the
PPPM method to compute forces on particles given electrostatic
potentials on the PPPM mesh. The {ik} approach is the default for
PPPM and is the original formulation used in "(Hockney)"_#Hockney1. It
performs differentiation in Kspace, and uses 3 FFTs to transfer each
component of the computed fields back to real space for total of 4
FFTs per timestep.
The analytic differentiation {ad} approach uses only 1 FFT to transfer
information back to real space for a total of 2 FFTs per timestep. It
then performs analytic differentiation on the single quantity to
generate the 3 components of the electric field at each grid point.
This is sometimes referred to as "smoothed" PPPM. This approach
requires a somewhat larger PPPM mesh to achieve the same accuracy as
the {ik} method. Currently, only the {ik} method (default) can be
used for a triclinic simulation cell with PPPM. The {ad} method is
always used for MSM.
NOTE: Currently, not all PPPM styles support the {ad} option. Support
for those PPPM variants will be added later.
The {kmax/ewald} keyword sets the number of kspace vectors in each
dimension for kspace style {ewald}. The three values must be positive
integers, or else (0,0,0), which unsets the option. When this option
is not set, the Ewald sum scheme chooses its own kspace vectors,
consistent with the user-specified accuracy and pairwise cutoff. In
any case, if kspace style {ewald} is invoked, the values used are
printed to the screen and the log file at the start of the run.
With the {mix/disp} keyword one can select the mixing rule for the
dispersion coefficients. With {pair}, the dispersion coefficients of
unlike types are computed as indicated with
"pair_modify"_pair_modify.html. With {geom}, geometric mixing is
enforced on the dispersion coefficients in the kspace
coefficients. When using the arithmetic mixing rule, this will
speed-up the simulations but introduces some error in the force
computations, as shown in "(Wennberg)"_#Wennberg. With {none}, it is
assumed that no mixing rule is applicable. Splitting of the dispersion
coefficients will be performed as described in
"(Isele-Holder)"_#Isele-Holder1. This splitting can be influenced with
the {splittol} keywords. Only the eigenvalues that are larger than tol
compared to the largest eigenvalues are included. Using this keywords
the original matrix of dispersion coefficients is approximated. This
leads to faster computations, but the accuracy in the reciprocal space
computations of the dispersion part is decreased.
:line
The {force/disp/real} and {force/disp/kspace} keywords set the force
accuracy for the real and space computations for the dispersion part
@ -295,6 +420,8 @@ provide simulations that are either inaccurate or slow. Using this
option is thus not recommended. For guidelines on how to obtain good
parameters, see the "Howto dispersion"_Howto_dispersion.html doc page.
:line
[Restrictions:] none
[Related commands:]
@ -306,10 +433,12 @@ parameters, see the "Howto dispersion"_Howto_dispersion.html doc page.
The option defaults are mesh = mesh/disp = 0 0 0, order = order/disp =
5 (PPPM), order = 10 (MSM), minorder = 2, overlap = yes, force = -1.0,
gewald = gewald/disp = 0.0, slab = 1.0, compute = yes, cutoff/adjust =
yes (MSM), pressure/scalar = yes (MSM), fftbench = no (PPPM), diff = ik
(PPPM), mix/disp = pair, force/disp/real = -1.0, force/disp/kspace = -1.0,
split = 0, tol = 1.0e-6, and disp/auto = no. For pppm/intel, order =
order/disp = 7.
yes (MSM), pressure/scalar = yes (MSM), fftbench = no (PPPM), diff =
ik (PPPM), mix/disp = pair, force/disp/real = -1.0, force/disp/kspace
= -1.0, split = 0, tol = 1.0e-6, and disp/auto = no. For pppm/intel,
order = order/disp = 7. For scafacos settings, the scafacos tolerance
option depends on the method chosen, as documented above. The
scafacos fmm_tuning default = 0.
:line

92
doc/src/kspace_style.txt
View File

@ -12,7 +12,7 @@ kspace_style command :h3
kspace_style style value :pre
style = {none} or {ewald} or {ewald/disp} or {ewald/omp} or {pppm} or {pppm/cg} or {pppm/disp} or {pppm/tip4p} or {pppm/stagger} or {pppm/disp/tip4p} or {pppm/gpu} or {pppm/kk} or {pppm/omp} or {pppm/cg/omp} or {pppm/tip4p/omp} or {msm} or {msm/cg} or {msm/omp} or {msm/cg/omp} :ulb,l
style = {none} or {ewald} or {ewald/disp} or {ewald/omp} or {pppm} or {pppm/cg} or {pppm/disp} or {pppm/tip4p} or {pppm/stagger} or {pppm/disp/tip4p} or {pppm/gpu} or {pppm/kk} or {pppm/omp} or {pppm/cg/omp} or {pppm/tip4p/omp} or {msm} or {msm/cg} or {msm/omp} or {msm/cg/omp} or {scafacos} :ulb,l
{none} value = none
{ewald} value = accuracy
accuracy = desired relative error in forces
@ -22,7 +22,7 @@ style = {none} or {ewald} or {ewald/disp} or {ewald/omp} or {pppm} or {pppm/cg}
accuracy = desired relative error in forces
{pppm} value = accuracy
accuracy = desired relative error in forces
{pppm/cg} value = accuracy (smallq)
{pppm/cg} values = accuracy (smallq)
accuracy = desired relative error in forces
smallq = cutoff for charges to be considered (optional) (charge units)
{pppm/disp} value = accuracy
@ -56,7 +56,10 @@ style = {none} or {ewald} or {ewald/disp} or {ewald/omp} or {pppm} or {pppm/cg}
accuracy = desired relative error in forces
{msm/cg/omp} value = accuracy (smallq)
accuracy = desired relative error in forces
smallq = cutoff for charges to be considered (optional) (charge units) :pre
smallq = cutoff for charges to be considered (optional) (charge units)
{scafacos} values = method accuracy
method = fmm or p2nfft or ewald or direct
accuracy = desired relative error in forces :pre
:ule
[Examples:]
@ -64,6 +67,7 @@ style = {none} or {ewald} or {ewald/disp} or {ewald/omp} or {pppm} or {pppm/cg}
kspace_style pppm 1.0e-4
kspace_style pppm/cg 1.0e-5 1.0e-6
kspace style msm 1.0e-4
kspace style scafacos fmm 1.0e-4
kspace_style none :pre
[Description:]
@ -211,6 +215,63 @@ pressure simulation with MSM will cause the code to run slower.
:line
The {scafacos} style is a wrapper on the "ScaFaCoS Coulomb solver
library"_http://www.scafacos.de which provides a variety of solver
methods which can be used with LAMMPS. The paper by "(Who)"_#Who2012
gives an overview of ScaFaCoS.
ScaFaCoS was developed by a consortium of German research facilities
with a BMBF (German Ministry of Science and Education) funded project
in 2009-2012. Participants of the consortium were the Universities of
Bonn, Chemnitz, Stuttgart, and Wuppertal as well as the
Forschungszentrum Juelich.
The library is available for download at "http://scafacos.de" or can
be cloned from the git-repository
"git://github.com/scafacos/scafacos.git".
In order to use this KSpace style, you must download and build the
ScaFaCoS library, then build LAMMPS with the USER-SCAFACOS package
installed package which links LAMMPS to the ScaFaCoS library.
See details on "this page"_Section_packages.html#USER-SCAFACOS.
NOTE: Unlike other KSpace solvers in LAMMPS, ScaFaCoS computes all
Coulombic interactions, both short- and long-range. Thus you should
NOT use a Coulmbic pair style when using kspace_style scafacos. This
also means the total Coulombic energy (short- and long-range) will be
tallied for "thermodynamic output"_thermo_style.html command as part
of the {elong} keyword; the {ecoul} keyword will be zero.
NOTE: See the current restriction below about use of ScaFaCoS in
LAMMPS with molecular charged systems or the TIP4P water model.
The specified {method} determines which ScaFaCoS algorithm is used.
These are the ScaFaCoS methods currently available from LAMMPS:
{fmm} = Fast Multi-Pole method
{p2nfft} = FFT-based Coulomb solver
{ewald} = Ewald summation
{direct} = direct O(N^2) summation
{p3m} = PPPM :ul
We plan to support additional ScaFaCoS solvers from LAMMPS in the
future. For an overview of the included solvers, refer to
"(Sutmann)"_#Sutmann2013
The specified {accuracy} is similar to the accuracy setting for other
LAMMPS KSpace styles, but is passed to ScaFaCoS, which can interpret
it in different ways for different methods it supports. Within the
ScaFaCoS library the {accuracy} is treated as a tolerance level
(either absolute or relative) for the chosen quantity, where the
quantity can be either the Columic field values, the per-atom Columic
energy or the total Columic energy. To select from these options, see
the "kspace_modify scafacos accuracy"_kspace_modify.html doc page.
The "kspace_modify scafacos"_kspace_modify.html command also explains
other ScaFaCoS options currently exposed to LAMMPS.
:line
The specified {accuracy} determines the relative RMS error in per-atom
forces calculated by the long-range solver. It is set as a
dimensionless number, relative to the force that two unit point
@ -321,12 +382,24 @@ dimensions. The only exception is if the slab option is set with
"kspace_modify"_kspace_modify.html, in which case the xy dimensions
must be periodic and the z dimension must be non-periodic.
The scafacos KSpace style will only be enabled if LAMMPS is built with
the USER-SCAFACOS package. See the "Build package"_Build_package.html
doc page for more info.
The use of ScaFaCos in LAMMPS does not yet support molecular charged
systems where the short-range Coulombic interactions between atoms in
the same bond/angle/dihedral are weighted by the
"special_bonds"_special_bonds.html command. Likewise it does not
support the "TIP4P water style" where a fictitious charge site is
introduced in each water molecule.
[Related commands:]
"kspace_modify"_kspace_modify.html, "pair_style
lj/cut/coul/long"_pair_lj.html, "pair_style
lj/charmm/coul/long"_pair_charmm.html, "pair_style
lj/long/coul/long"_pair_lj_long.html, "pair_style buck/coul/long"_pair_buck.html
lj/long/coul/long"_pair_lj_long.html, "pair_style
buck/coul/long"_pair_buck.html
[Default:]
@ -384,5 +457,12 @@ Evaluation of Forces for the Simulation of Biomolecules, University of
Illinois at Urbana-Champaign, (2006).
:link(Hardy2009)
[(Hardy2)] Hardy, Stone, Schulten, Parallel Computing 35 (2009)
164-177.
[(Hardy2)] Hardy, Stone, Schulten, Parallel Computing, 35, 164-177
(2009).
:link(Sutmann2013)
[(Sutmann)] Sutmann, Arnold, Fahrenberger, et. al., Physical review / E 88(6), 063308 (2013)
:link(Who2012)
[(Who)] Who, Author2, Author3, J of Long Range Solvers, 35, 164-177
(2012).

13
doc/src/lammps.book
View File

@ -67,6 +67,7 @@ Howto_multiple.html
Howto_replica.html
Howto_library.html
Howto_couple.html
Howto_client_server.html
Howto_output.html
Howto_chunk.html
Howto_2d.html
@ -265,6 +266,7 @@ fix_eos_table.html
fix_eos_table_rx.html
fix_evaporate.html
fix_external.html
fix_ffl.html
fix_filter_corotate.html
fix_flow_gauss.html
fix_freeze.html
@ -299,6 +301,7 @@ fix_msst.html
fix_mvv_dpd.html
fix_neb.html
fix_nh.html
fix_cauchy.html
fix_nh_eff.html
fix_nph_asphere.html
fix_nph_body.html
@ -310,6 +313,7 @@ fix_npt_sphere.html
fix_nve.html
fix_nve_asphere.html
fix_nve_asphere_noforce.html
fix_nve_awpmd.html
fix_nve_body.html
fix_nve_dot.html
fix_nve_dotc_langevin.html
@ -373,7 +377,6 @@ fix_spring_self.html
fix_srd.html
fix_store_force.html
fix_store_state.html
fix_surface_global.html
fix_temp_berendsen.html
fix_temp_csvr.html
fix_temp_rescale.html
@ -402,6 +405,7 @@ lammps_commands_compute.html
compute.html
compute_modify.html
compute_ackland_atom.html
compute_adf.html
compute_angle.html
compute_angle_local.html
compute_angmom_chunk.html
@ -411,6 +415,7 @@ compute_bond.html
compute_bond_local.html
compute_centro_atom.html
compute_chunk_atom.html
compute_chunk_spread_atom.html
compute_cluster_atom.html
compute_cna_atom.html
compute_cnp_atom.html
@ -462,12 +467,15 @@ compute_pe.html
compute_pe_atom.html
compute_plasticity_atom.html
compute_pressure.html
compute_pressure_cylinder.html
compute_pressure_uef.html
compute_property_atom.html
compute_property_chunk.html
compute_property_local.html
compute_ptm_atom.html
compute_rdf.html
compute_reduce.html
compute_reduce_chunk.html
compute_rigid_local.html
compute_saed.html
compute_slice.html
@ -485,7 +493,7 @@ compute_smd_tlsph_shape.html
compute_smd_tlsph_strain.html
compute_smd_tlsph_strain_rate.html
compute_smd_tlsph_stress.html
compute_smd_triangle_mesh_vertices.html
compute_smd_triangle_vertices.html
compute_smd_ulsph_num_neighs.html
compute_smd_ulsph_strain.html
compute_smd_ulsph_strain_rate.html
@ -494,6 +502,7 @@ compute_smd_vol.html
compute_sna_atom.html
compute_spin.html
compute_stress_atom.html
compute_stress_mop.html
compute_tally.html
compute_tdpd_cc_atom.html
compute_temp.html

13
doc/src/minimize.txt
View File

@ -216,10 +216,10 @@ The "fix box/relax"_fix_box_relax.html command can be used to apply an
external pressure to the simulation box and allow it to shrink/expand
during the minimization.
Only a few other fixes (typically those that apply force constraints)
are invoked during minimization. See the doc pages for individual
"fix"_fix.html commands to see which ones are relevant. Current
examples of fixes that can be used include:
Only a few other fixes (typically those that add forces) are invoked
during minimization. See the doc pages for individual "fix"_fix.html
commands to see which ones are relevant. Current examples of fixes
that can be used include:
"fix addforce"_fix_addforce.html
"fix addtorque"_fix_addtorque.html
@ -242,6 +242,11 @@ you MUST enable the "fix_modify"_fix_modify.html {energy} option for
that fix. The doc pages for individual "fix"_fix.html commands
specify if this should be done.
NOTE: The minimizers in LAMMPS do not allow for bonds (or angles, etc)
to be held fixed while atom coordinates are being relaxed, e.g. via
"fix shake"_fix_shake.html or "fix rigid"_fix_rigid.html. See more
info in the Restrictions section below.
:line
[Restrictions:]

2
doc/src/pair_body_nparticle.txt
View File

@ -6,7 +6,7 @@
:line
pair_style body command :h3
pair_style body/nparticle command :h3
[Syntax:]

19
doc/src/pair_born.txt
View File

@ -11,19 +11,14 @@ pair_style born command :h3
pair_style born/omp command :h3
pair_style born/gpu command :h3
pair_style born/coul/long command :h3
pair_style born/coul/long/cs command :h3
pair_style born/coul/long/cs/gpu command :h3
pair_style born/coul/long/gpu command :h3
pair_style born/coul/long/omp command :h3
pair_style born/coul/msm command :h3
pair_style born/coul/msm/omp command :h3
pair_style born/coul/wolf command :h3
pair_style born/coul/wolf/cs command :h3
pair_style born/coul/wolf/cs/gpu command :h3
pair_style born/coul/wolf/gpu command :h3
pair_style born/coul/wolf/omp command :h3
pair_style born/coul/dsf command :h3
pair_style born/coul/dsf/cs command :h3
[Syntax:]
@ -55,9 +50,7 @@ pair_coeff * * 6.08 0.317 2.340 24.18 11.51
pair_coeff 1 1 6.08 0.317 2.340 24.18 11.51 :pre
pair_style born/coul/long 10.0
pair_style born/coul/long/cs 10.0
pair_style born/coul/long 10.0 8.0
pair_style born/coul/long/cs 10.0 8.0
pair_style born/coul/long 10.0 8.
pair_coeff * * 6.08 0.317 2.340 24.18 11.51
pair_coeff 1 1 6.08 0.317 2.340 24.18 11.51 :pre
@ -68,7 +61,6 @@ pair_coeff 1 1 6.08 0.317 2.340 24.18 11.51 :pre
pair_style born/coul/wolf 0.25 10.0
pair_style born/coul/wolf 0.25 10.0 9.0
pair_style born/coul/wolf/cs 0.25 10.0 9.0
pair_coeff * * 6.08 0.317 2.340 24.18 11.51
pair_coeff 1 1 6.08 0.317 2.340 24.18 11.51 :pre
@ -107,13 +99,6 @@ Wolf potential in the "coul/wolf"_pair_coul.html pair style.
The {born/coul/dsf} style computes the Coulomb contribution with the
damped shifted force model as in the "coul/dsf"_pair_coul.html style.
Style {born/coul/long/cs} is identical to {born/coul/long} except that
a term is added for the "core/shell model"_Howto_coreshell.html to
allow charges on core and shell particles to be separated by r = 0.0.
The same correction is introduced for the {born/coul/dsf/cs} style
which is identical to {born/coul/dsf}. And likewise for
{born/coul/wolf/cs} style which is identical to {born/coul/wolf}.
Note that these potentials are related to the "Buckingham
potential"_pair_buck.html.
@ -174,7 +159,7 @@ for the energy of the exp(), 1/r^6, and 1/r^8 portion of the pair
interaction.
The {born/coul/long} pair style supports the
"pair_modify"_pair_modify.html table option ti tabulate the
"pair_modify"_pair_modify.html table option to tabulate the
short-range portion of the long-range Coulombic interaction.
These styles support the pair_modify tail option for adding long-range

14
doc/src/pair_buck.txt
View File

@ -17,7 +17,6 @@ pair_style buck/coul/cut/intel command :h3
pair_style buck/coul/cut/kk command :h3
pair_style buck/coul/cut/omp command :h3
pair_style buck/coul/long command :h3
pair_style buck/coul/long/cs command :h3
pair_style buck/coul/long/gpu command :h3
pair_style buck/coul/long/intel command :h3
pair_style buck/coul/long/kk command :h3
@ -29,14 +28,14 @@ pair_style buck/coul/msm/omp command :h3
pair_style style args :pre
style = {buck} or {buck/coul/cut} or {buck/coul/long} or {buck/coul/long/cs} or {buck/coul/msm}
style = {buck} or {buck/coul/cut} or {buck/coul/long} or {buck/coul/msm}
args = list of arguments for a particular style :ul
{buck} args = cutoff
cutoff = global cutoff for Buckingham interactions (distance units)
{buck/coul/cut} args = cutoff (cutoff2)
cutoff = global cutoff for Buckingham (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
{buck/coul/long} or {buck/coul/long/cs} args = cutoff (cutoff2)
{buck/coul/long} args = cutoff (cutoff2)
cutoff = global cutoff for Buckingham (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
{buck/coul/msm} args = cutoff (cutoff2)
@ -56,9 +55,7 @@ pair_coeff 1 1 100.0 1.5 200.0 9.0
pair_coeff 1 1 100.0 1.5 200.0 9.0 8.0 :pre
pair_style buck/coul/long 10.0
pair_style buck/coul/long/cs 10.0
pair_style buck/coul/long 10.0 8.0
pair_style buck/coul/long/cs 10.0 8.0
pair_coeff * * 100.0 1.5 200.0
pair_coeff 1 1 100.0 1.5 200.0 9.0 :pre
@ -92,10 +89,6 @@ A,C and Coulombic terms. If two cutoffs are specified, the first is
used as the cutoff for the A,C terms, and the second is the cutoff for
the Coulombic term.
Style {buck/coul/long/cs} is identical to {buck/coul/long} except that
a term is added for the "core/shell model"_Howto_coreshell.html to
allow charges on core and shell particles to be separated by r = 0.0.
Note that these potentials are related to the "Born-Mayer-Huggins
potential"_pair_born.html.
@ -184,8 +177,7 @@ respa"_run_style.html command. They do not support the {inner},
[Restrictions:]
The {buck/coul/long} style is part of the KSPACE package. The
{buck/coul/long/cs} style is part of the CORESHELL package. They are
The {buck/coul/long} style is part of the KSPACE package. They are
only enabled if LAMMPS was built with that package. See the "Build
package"_Build_package.html doc page for more info.

4
doc/src/pair_buck6d_coul_gauss.txt
View File

@ -6,8 +6,8 @@
:line
pair_style buck6d/coul/gauss/dsf :h3
pair_style buck6d/coul/gauss/long :h3
pair_style buck6d/coul/gauss/dsf command :h3
pair_style buck6d/coul/gauss/long command :h3
[Syntax:]

3
doc/src/pair_charmm.txt
View File

@ -8,12 +8,15 @@
pair_style lj/charmm/coul/charmm command :h3
pair_style lj/charmm/coul/charmm/intel command :h3
pair_style lj/charmm/coul/charmm/kk command :h3
pair_style lj/charmm/coul/charmm/omp command :h3
pair_style lj/charmm/coul/charmm/implicit command :h3
pair_style lj/charmm/coul/charmm/implicit/kk command :h3
pair_style lj/charmm/coul/charmm/implicit/omp command :h3
pair_style lj/charmm/coul/long command :h3
pair_style lj/charmm/coul/long/gpu command :h3
pair_style lj/charmm/coul/long/intel command :h3
pair_style lj/charmm/coul/long/kk command :h3
pair_style lj/charmm/coul/long/opt command :h3
pair_style lj/charmm/coul/long/omp command :h3
pair_style lj/charmm/coul/msm command :h3

9
doc/src/pair_coul_shield.txt
View File

@ -38,7 +38,8 @@ charge and molecule ID information is included.
Where Tap(r_ij) is the taper function which provides a continuous cutoff
(up to third derivative) for inter-atomic separations larger than r_c
"(Maaravi)"_#Maaravi1. Here {lambda} is the shielding parameter that
"(Leven1)"_#Leven3, "(Leven2)"_#Leven4 and "(Maaravi)"_#Maaravi1.
Here {lambda} is the shielding parameter that
eliminates the short-range singularity of the classical mono-polar
electrostatic interaction expression "(Maaravi)"_#Maaravi1.
@ -82,5 +83,11 @@ package"_Build_package.html doc page for more info.
:line
:link(Leven3)
[(Leven1)] I. Leven, I. Azuri, L. Kronik and O. Hod, J. Chem. Phys. 140, 104106 (2014).
:link(Leven4)
[(Leven2)] I. Leven et al, J. Chem.Theory Comput. 12, 2896-905 (2016).
:link(Maaravi1)
[(Maaravi)] T. Maaravi et al, J. Phys. Chem. C 121, 22826-22835 (2017).

34
doc/src/pair_cs.txt
View File

@ -7,9 +7,11 @@
:line
pair_style born/coul/long/cs command :h3
pair_style born/coul/long/cs/gpu command :h3
pair_style buck/coul/long/cs command :h3
pair_style born/coul/dsf/cs command :h3
pair_style born/coul/wolf/cs command :h3
pair_style born/coul/wolf/cs/gpu command :h3
[Syntax:]
@ -97,6 +99,38 @@ a long-range solver, thus the only correction is the addition of a
minimal distance to avoid the possible r = 0.0 case for a
core/shell pair.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed on the "Speed packages"_Speed_packages.html doc
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Build
package"_Build_package.html doc page for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
switch"_Run_options.html when you invoke LAMMPS, or you can use the
"suffix"_suffix.html command in your input script.
See the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
See the corresponding doc pages for pair styles without the "cs"
suffix to see how mixing, shifting, tabulation, tail correction,
restarting, and rRESPA are handled by theses pair styles.
:line
[Restrictions:]
These pair styles are part of the CORESHELL package. They are only

1
doc/src/pair_dipole.txt
View File

@ -13,6 +13,7 @@ pair_style lj/sf/dipole/sf command :h3
pair_style lj/sf/dipole/sf/gpu command :h3
pair_style lj/sf/dipole/sf/omp command :h3
pair_style lj/cut/dipole/long command :h3
pair_style lj/cut/dipole/long/gpu command :h3
pair_style lj/long/dipole/long command :h3
[Syntax:]

10
doc/src/pair_eam.txt
View File

@ -20,6 +20,8 @@ pair_style eam/alloy/omp command :h3
pair_style eam/alloy/opt command :h3
pair_style eam/cd command :h3
pair_style eam/cd/omp command :h3
pair_style eam/cd/old command :h3
pair_style eam/cd/old/omp command :h3
pair_style eam/fs command :h3
pair_style eam/fs/gpu command :h3
pair_style eam/fs/intel command :h3
@ -31,7 +33,7 @@ pair_style eam/fs/opt command :h3
pair_style style :pre
style = {eam} or {eam/alloy} or {eam/cd} or {eam/fs} :ul
style = {eam} or {eam/alloy} or {eam/cd} or {eam/cd/old} or {eam/fs} :ul
[Examples:]
@ -268,7 +270,8 @@ Style {eam/cd} is similar to the {eam/alloy} style, except that it
computes alloy pairwise interactions using the concentration-dependent
embedded-atom method (CD-EAM). This model can reproduce the enthalpy
of mixing of alloys over the full composition range, as described in
"(Stukowski)"_#Stukowski.
"(Stukowski)"_#Stukowski. Style {eam/cd/old} is an older, slightly
different and slower two-site formulation of the model "(Caro)"_#Caro.
The pair_coeff command is specified the same as for the {eam/alloy}
style. However the DYNAMO {setfl} file must has two
@ -442,3 +445,6 @@ Daw, Baskes, Phys Rev B, 29, 6443 (1984).
:link(Stukowski)
[(Stukowski)] Stukowski, Sadigh, Erhart, Caro; Modeling Simulation
Materials Science & Engineering, 7, 075005 (2009).
:link(Caro)
[(Caro)] A Caro, DA Crowson, M Caro; Phys Rev Lett, 95, 075702 (2005)

1
doc/src/pair_edip.txt
View File

@ -7,6 +7,7 @@
:line
pair_style edip command :h3
pair_style edip/omp command :h3
pair_style edip/multi command :h3
[Syntax:]

3
doc/src/pair_gran.txt
View File

@ -7,9 +7,10 @@
:line
pair_style gran/hooke command :h3
pair_style gran/omp command :h3
pair_style gran/hooke/omp command :h3
pair_style gran/hooke/history command :h3
pair_style gran/hooke/history/omp command :h3
pair_style gran/hooke/history/kk command :h3
pair_style gran/hertz/history command :h3
pair_style gran/hertz/history/omp command :h3

2
doc/src/pair_gromacs.txt
View File

@ -8,8 +8,10 @@
pair_style lj/gromacs command :h3
pair_style lj/gromacs/gpu command :h3
pair_style lj/gromacs/kk command :h3
pair_style lj/gromacs/omp command :h3
pair_style lj/gromacs/coul/gromacs command :h3
pair_style lj/gromacs/coul/gromacs/kk command :h3
pair_style lj/gromacs/coul/gromacs/omp command :h3
[Syntax:]

3
doc/src/pair_hybrid.txt
View File

@ -7,9 +7,8 @@
:line
pair_style hybrid command :h3
pair_style hybrid/omp command :h3
pair_style hybrid/kk command :h3
pair_style hybrid/overlay command :h3
pair_style hybrid/overlay/omp command :h3
pair_style hybrid/overlay/kk command :h3
[Syntax:]

41
doc/src/pair_ilp_graphene_hbn.txt
View File

@ -25,22 +25,24 @@ pair_coeff * * rebo CH.airebo NULL NULL C
pair_coeff * * tersoff BNC.tersoff B N NULL
pair_coeff * * ilp/graphene/hbn BNCH.ILP B N C
pair_coeff 1 1 coul/shield 0.70
pair_coeff 1 2 coul/shield 0.69498201415576216335
pair_coeff 1 2 coul/shield 0.695
pair_coeff 2 2 coul/shield 0.69 :pre
[Description:]
The {ilp/graphene/hbn} style computes the registry-dependent interlayer
potential (ILP) potential as described in "(Leven)"_#Leven and
"(Maaravi)"_#Maaravi2. The normals are calculated in the way as described
potential (ILP) potential as described in "(Leven1)"_#Leven1,
"(Leven2)"_#Leven2 and "(Maaravi)"_#Maaravi2.
The normals are calculated in the way as described
in "(Kolmogorov)"_#Kolmogorov2.
:c,image(Eqs/pair_ilp_graphene_hbn.jpg)
Where Tap(r_ij) is the taper function which provides a continuous
cutoff (up to third derivative) for interatomic separations larger than
r_c "(Maaravi)"_#Maaravi2. The definitions of each parameter in the above
equation can be found in "(Leven)"_#Leven and "(Maaravi)"_#Maaravi2.
r_c "(Maaravi)"_#Maaravi2. The definitons of each parameter in the above
equation can be found in "(Leven1)"_#Leven1 and "(Maaravi)"_#Maaravi2.
It is important to include all the pairs to build the neighbor list for
calculating the normals.
@ -61,13 +63,15 @@ NOTE: The parameters presented in the parameter file (e.g. BNCH.ILP),
are fitted with taper function by setting the cutoff equal to 16.0
Angstrom. Using different cutoff or taper function should be careful.
NOTE: Two new sets of parameters of ILP for two-dimensional hexagonal Materials
are presented in "(Ouyang)"_#Ouyang1. These parameters provide a good description
in both short- and long-range interaction regime, while the old ILP parameters
published in "(Leven)"_#Leven and "(Maaravi)"_#Maaravi2 are only suitable for
long-range interaction regime. This feature is essential for simulations in
high-pressure regime (i.e., the interlayer distance smaller than the equilibrium distance).
The benchmark tests and comparison of these parameters can be found in "(Ouyang)"_#Ouyang1.
NOTE: Two new sets of parameters of ILP for two-dimensional hexagonal
Materials are presented in "(Ouyang)"_#Ouyang. These parameters provide
a good description in both short- and long-range interaction regimes.
While the old ILP parameters published in "(Leven2)"_#Leven2 and
"(Maaravi)"_#Maaravi2 are only suitable for long-range interaction
regime. This feature is essential for simulations in high pressure
regime (i.e., the interlayer distance is smaller than the equilibrium
distance). The benchmark tests and comparison of these parameters can
be found in "(Ouyang)"_#Ouyang.
This potential must be used in combination with hybrid/overlay.
Other interactions can be set to zero using pair_style {none}.
@ -112,14 +116,17 @@ units, if your simulation does not use {metal} units.
:line
:link(Leven)
[(Leven)] I. Leven et al, J. Chem.Theory Comput. 12, 2896-905 (2016)
:link(Leven1)
[(Leven1)] I. Leven, I. Azuri, L. Kronik and O. Hod, J. Chem. Phys. 140, 104106 (2014).
:link(Leven2)
[(Leven2)] I. Leven et al, J. Chem.Theory Comput. 12, 2896-905 (2016).
:link(Maaravi2)
[(Maaravi)] T. Maaravi et al, J. Phys. Chem. C 121, 22826-22835 (2017).
:link(Kolmogorov2)
[(Kolmogorov)] A. N. Kolmogorov, V. H. Crespi, Phys. Rev. B 71, 235415 (2005)
[(Kolmogorov)] A. N. Kolmogorov, V. H. Crespi, Phys. Rev. B 71, 235415 (2005).
:link(Ouyang1)
[(Ouyang)] W. Ouyang, D. Mandelli, M. Urbakh, O. Hod, arXiv:1806.09555 (2018).
:link(Ouyang)
[(Ouyang)] W. Ouyang, D. Mandelli, M. Urbakh and O. Hod, Nano Lett. 18, 6009-6016 (2018).

39
doc/src/pair_kolmogorov_crespi_full.txt
View File

@ -19,11 +19,11 @@ tap_flag = 0/1 to turn off/on the taper function
pair_style hybrid/overlay kolmogorov/crespi/full 20.0 0
pair_coeff * * none
pair_coeff * * kolmogorov/crespi/full CC.KC C C :pre
pair_coeff * * kolmogorov/crespi/full CH.KC C C :pre
pair_style hybrid/overlay rebo kolmogorov/crespi/full 16.0
pair_coeff * * rebo CH.airebo C C
pair_coeff * * kolmogorov/crespi/full CC.KC C C :pre
pair_style hybrid/overlay rebo kolmogorov/crespi/full 16.0 1
pair_coeff * * rebo CH.airebo C H
pair_coeff * * kolmogorov/crespi/full CH_taper.KC C H :pre
[Description:]
@ -38,27 +38,32 @@ forces and to include all the pairs to build the neighbor list for
calculating the normals. Energies are shifted so that they go
continuously to zero at the cutoff assuming that the exponential part of
{Vij} (first term) decays sufficiently fast. This shift is achieved by
the last term in the equation for {Vij} above.
the last term in the equation for {Vij} above. This is essential only
when the tapper function is turned off. The formula of taper function
can be found in pair style "ilp/graphene/hbn"_pair_ilp_graphene_hbn.html.
NOTE: This potential is intended for interactions between two different
graphene layers. Therefore, to avoid interaction within the same layers,
each layer should have a separate molecule id and is recommended to use
"full" atom style in the data file.
The parameter file (e.g. CC.KC), is intended for use with {metal}
The parameter file (e.g. CH.KC), is intended for use with {metal}
"units"_units.html, with energies in meV. Two additional parameters, {S},
and {rcut} are included in the parameter file. {S} is designed to
facilitate scaling of energies. {rcut} is designed to build the neighbor
list for calculating the normals for each atom pair.
NOTE: A new set of parameters of KC potential for hydrocarbons (CH.KC)
is presented in "(Ouyang)"_#Ouyang2. The parameters in CH.KC provides
a good description in both short- and long-range interaction regime,
while the original parameters (CC.KC) published in "(Kolmogorov)"_#Kolmogorov1
are only suitable for long-range interaction regime.
This feature is essential for simulations in high-pressure regime
(i.e., the interlayer distance smaller than the equilibrium distance).
The benchmark tests and comparison of these parameters can be found in "(Ouyang)"_#Ouyang2.
NOTE: Two new sets of parameters of KC potential for hydrocarbons, CH.KC
(without the taper function) and CH_taper.KC (with the taper function)
are presented in "(Ouyang)"_#Ouyang1. The energy for the KC potential
with the taper function goes continuously to zero at the cutoff. The
parameters in both CH.KC and CH_taper.KC provide a good description in
both short- and long-range interaction regimes. While the original
parameters (CC.KC) published in "(Kolmogorov)"_#Kolmogorov1 are only
suitable for long-range interaction regime. This feature is essential
for simulations in high pressure regime (i.e., the interlayer distance
is smaller than the equilibrium distance). The benchmark tests and
comparison of these parameters can be found in "(Ouyang)"_#Ouyang1.
This potential must be used in combination with hybrid/overlay.
Other interactions can be set to zero using pair_style {none}.
@ -84,7 +89,7 @@ package"_Build_package.html doc page for more info.
This pair potential requires the newton setting to be {on} for pair
interactions.
The CC.KC potential file provided with LAMMPS (see the potentials
The CH.KC potential file provided with LAMMPS (see the potentials
folder) are parameterized for metal units. You can use this potential
with any LAMMPS units, but you would need to create your own custom
CC.KC potential file with all coefficients converted to the appropriate
@ -105,5 +110,5 @@ units.
:link(Kolmogorov1)
[(Kolmogorov)] A. N. Kolmogorov, V. H. Crespi, Phys. Rev. B 71, 235415 (2005)
:link(Ouyang2)
[(Ouyang)] W. Ouyang, D. Mandelli, M. Urbakh, O. Hod, arXiv:1806.09555 (2018).
:link(Ouyang1)
[(Ouyang)] W. Ouyang, D. Mandelli, M. Urbakh and O. Hod, Nano Lett. 18, 6009-6016 (2018).

2
doc/src/pair_lj.txt
View File

@ -14,6 +14,7 @@ pair_style lj/cut/opt command :h3
pair_style lj/cut/omp command :h3
pair_style lj/cut/coul/cut command :h3
pair_style lj/cut/coul/cut/gpu command :h3
pair_style lj/cut/coul/cut/kk command :h3
pair_style lj/cut/coul/cut/omp command :h3
pair_style lj/cut/coul/debye command :h3
pair_style lj/cut/coul/debye/gpu command :h3
@ -26,6 +27,7 @@ pair_style lj/cut/coul/dsf/omp command :h3
pair_style lj/cut/coul/long command :h3
pair_style lj/cut/coul/long/cs command :h3
pair_style lj/cut/coul/long/gpu command :h3
pair_style lj/cut/coul/long/kk command :h3
pair_style lj/cut/coul/long/intel command :h3
pair_style lj/cut/coul/long/opt command :h3
pair_style lj/cut/coul/long/omp command :h3

24
doc/src/pair_lj_expand.txt
View File

@ -8,7 +8,10 @@
pair_style lj/expand command :h3
pair_style lj/expand/gpu command :h3
pair_style lj/expand/kk command :h3
pair_style lj/expand/omp command :h3
pair_style lj/expand/coul/long command :h3
pair_style lj/expand/coul/long/gpu command :h3
[Syntax:]
@ -22,6 +25,11 @@ pair_style lj/expand 2.5
pair_coeff * * 1.0 1.0 0.5
pair_coeff 1 1 1.0 1.0 -0.2 2.0 :pre
pair_style lj/expand/coul/long 2.5
pair_style lj/expand/coul/long 2.5 4.0
pair_coeff * * 1.0 1.0 0.5
pair_coeff 1 1 1.0 1.0 -0.2 3.0 :pre
[Description:]
Style {lj/expand} computes a LJ interaction with a distance shifted by
@ -34,11 +42,12 @@ formula:
Rc is the cutoff which does not include the delta distance. I.e. the
actual force cutoff is the sum of cutoff + delta.
The following coefficients must be defined for each pair of atoms
types via the "pair_coeff"_pair_coeff.html command as in the examples
above, or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands, or by mixing as described below:
For all of the {lj/expand} pair styles, the following coefficients must
be defined for each pair of atoms types via the
"pair_coeff"_pair_coeff.html command as in the examples above, or in
the data file or restart files read by the "read_data"_read_data.html
or "read_restart"_read_restart.html commands, or by mixing as
described below:
epsilon (energy units)
sigma (distance units)
@ -48,6 +57,11 @@ cutoff (distance units) :ul
The delta values can be positive or negative. The last coefficient is
optional. If not specified, the global LJ cutoff is used.
For {lj/expand/coul/long} only the LJ cutoff can be specified since a
Coulombic cutoff cannot be specified for an individual I,J type pair.
All type pairs use the same global Coulombic cutoff specified in the
pair_style command.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are

1
doc/src/pair_lj_long.txt
View File

@ -11,6 +11,7 @@ pair_style lj/long/coul/long/intel command :h3
pair_style lj/long/coul/long/omp command :h3
pair_style lj/long/coul/long/opt command :h3
pair_style lj/long/tip4p/long command :h3
pair_style lj/long/tip4p/long/omp command :h3
[Syntax:]

4
doc/src/pair_meam_spline.txt
View File

@ -6,8 +6,8 @@
:line
pair_style meam/spline :h3
pair_style meam/spline/omp :h3
pair_style meam/spline command :h3
pair_style meam/spline/omp command :h3
[Syntax:]

3
doc/src/pair_meam_sw_spline.txt
View File

@ -6,8 +6,7 @@
:line
pair_style meam/sw/spline :h3
pair_style meam/sw/spline/omp :h3
pair_style meam/sw/spline command :h3
[Syntax:]

23
doc/src/pair_nb3b_harmonic.txt
View File

@ -7,7 +7,6 @@
:line
pair_style nb3b/harmonic command :h3
pair_style nb3b/harmonic/omp command :h3
[Syntax:]
@ -89,28 +88,6 @@ a particular simulation; LAMMPS ignores those entries.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed on the "Speed packages"_Speed_packages.html doc
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Build
package"_Build_package.html doc page for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
switch"_Run_options.html when you invoke LAMMPS, or you can use the
"suffix"_suffix.html command in your input script.
See the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This pair style can only be used if LAMMPS was built with the MANYBODY

14
doc/src/pair_sdk.txt
View File

@ -13,6 +13,8 @@ pair_style lj/sdk/omp command :h3
pair_style lj/sdk/coul/long command :h3
pair_style lj/sdk/coul/long/gpu command :h3
pair_style lj/sdk/coul/long/omp command :h3
pair_style lj/sdk/coul/msm command :h3
pair_style lj/sdk/coul/msm/omp command :h3
[Syntax:]
@ -35,6 +37,10 @@ pair_style lj/sdk/coul/long 10.0
pair_style lj/sdk/coul/long 10.0 12.0
pair_coeff 1 1 lj9_6 100.0 3.5 12.0 :pre
pair_style lj/sdk/coul/msm 10.0
pair_style lj/sdk/coul/msm 10.0 12.0
pair_coeff 1 1 lj9_6 100.0 3.5 12.0 :pre
[Description:]
The {lj/sdk} styles compute a 9/6, 12/4, or 12/6 Lennard-Jones potential,
@ -75,10 +81,10 @@ and Coulombic interactions for this type pair. If both coefficients
are specified, they are used as the LJ and Coulombic cutoffs for this
type pair.
For {lj/sdk/coul/long} only the LJ cutoff can be specified since a
Coulombic cutoff cannot be specified for an individual I,J type pair.
All type pairs use the same global Coulombic cutoff specified in the
pair_style command.
For {lj/sdk/coul/long} and {lj/sdk/coul/msm} only the LJ cutoff can be
specified since a Coulombic cutoff cannot be specified for an
individual I,J type pair. All type pairs use the same global
Coulombic cutoff specified in the pair_style command.
:line

8
doc/src/pair_spin_magelec.txt
View File

@ -6,11 +6,11 @@
:line
pair_style spin/me command :h3
pair_style spin/magelec command :h3
[Syntax:]
pair_style spin/me cutoff :pre
pair_style spin/magelec cutoff :pre
cutoff = global cutoff pair (distance in metal units) :ulb,l
@ -18,8 +18,8 @@ cutoff = global cutoff pair (distance in metal units) :ulb,l
[Examples:]
pair_style spin/me 4.5
pair_coeff * * me 4.5 0.00109 1.0 1.0 1.0 :pre
pair_style spin/magelec 4.5
pair_coeff * * magelec 4.5 0.00109 1.0 1.0 1.0 :pre
[Description:]

36
doc/src/pair_spin_neel.txt
View File

@ -29,34 +29,36 @@ between pairs of magnetic spins:
:c,image(Eqs/pair_spin_neel_interaction.jpg)
where si and sj are two neighboring magnetic spins of two particles,
where si and sj are two neighboring magnetic spins of two particles,
rij = ri - rj is the inter-atomic distance between the two particles,
eij = (ri - rj)/|ri-rj| is their normalized separation vector
and g1, q1 and q2 are three functions defining the intensity of the
dipolar and quadrupolar contributions, with:
eij = (ri - rj)/|ri-rj| is their normalized separation vector and g1,
q1 and q2 are three functions defining the intensity of the dipolar
and quadrupolar contributions, with:
:c,image(Eqs/pair_spin_neel_functions.jpg)
With the functions g(rij) and q(rij) defined and fitted according to the same
Bethe-Slater function used to fit the exchange interaction:
With the functions g(rij) and q(rij) defined and fitted according to
the same Bethe-Slater function used to fit the exchange interaction:
:c,image(Eqs/pair_spin_exchange_function.jpg)
where a, b and d are the three constant coefficients defined in the associated
"pair_coeff" command.
where a, b and d are the three constant coefficients defined in the
associated "pair_coeff" command.
The coefficients a, b, and d need to be fitted so that the function above matches with
the values of the magneto-elastic constant of the materials at stake.
The coefficients a, b, and d need to be fitted so that the function
above matches with the values of the magneto-elastic constant of the
materials at stake.
Examples and more explanations about this function and its parametrization are reported
in "(Tranchida)"_#Tranchida6. More examples of parametrization will be provided in
future work.
Examples and more explanations about this function and its
parametrization are reported in "(Tranchida)"_#Tranchida6. More
examples of parametrization will be provided in future work.
From this DM interaction, each spin i will be submitted to a magnetic torque
omega and its associated atom to a force F (for spin-lattice calculations only).
From this DM interaction, each spin i will be submitted to a magnetic
torque omega and its associated atom to a force F (for spin-lattice
calculations only).
More details about the derivation of these torques/forces are reported in
"(Tranchida)"_#Tranchida6.
More details about the derivation of these torques/forces are reported
in "(Tranchida)"_#Tranchida6.
:line

8
doc/src/pair_tersoff.txt
View File

@ -8,10 +8,10 @@
pair_style tersoff command :h3
pair_style tersoff/table command :h3
pair_style tersoff/gpu :h3
pair_style tersoff/intel :h3
pair_style tersoff/kk :h3
pair_style tersoff/omp :h3
pair_style tersoff/gpu command :h3
pair_style tersoff/intel command :h3
pair_style tersoff/kk command :h3
pair_style tersoff/omp command :h3
pair_style tersoff/table/omp command :h3
[Syntax:]

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