ICODE-ADC/lammps
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge branch 'develop' into mesocnt_memory

Browse Source
This commit is contained in:
Axel Kohlmeyer
2022-03-05 15:06:23 -05:00
parent 7288828439 798975b809
commit f329711384
2128 changed files with 27492 additions and 18452 deletions
Download Patch File Download Diff File Expand all files Collapse all files

17
.github/workflows/compile-msvc.yml vendored
View File

@ -1,5 +1,5 @@
# GitHub action to build LAMMPS on Windows with Visual C++
name: "Native Windows Compilation"
name: "Native Windows Compilation and Unit Tests"
on:
push:
@ -17,13 +17,21 @@ jobs:
with:
fetch-depth: 2
- name: Select Python version
uses: actions/setup-python@v2
with:
python-version: '3.10'
- name: Building LAMMPS via CMake
shell: bash
run: |
python3 -m pip install numpy
cmake -C cmake/presets/windows.cmake \
-D PKG_PYTHON=on \
-S cmake -B build \
-D BUILD_SHARED_LIBS=on \
-D LAMMPS_EXCEPTIONS=on
-D LAMMPS_EXCEPTIONS=on \
-D ENABLE_TESTING=on
cmake --build build --config Release
- name: Run LAMMPS executable
@ -31,3 +39,8 @@ jobs:
run: |
./build/Release/lmp.exe -h
./build/Release/lmp.exe -in bench/in.lj
- name: Run Unit Tests
working-directory: build
shell: bash
run: ctest -V -C Release

1
.gitignore vendored
View File

@ -12,6 +12,7 @@
*.sif
*.dll
*.pyc
*.whl
a.out
__pycache__

58
cmake/CMakeLists.txt
View File

@ -16,9 +16,13 @@ endif()
project(lammps CXX)
set(SOVERSION 0)
get_property(BUILD_IS_MULTI_CONFIG GLOBAL PROPERTY GENERATOR_IS_MULTI_CONFIG)
get_filename_component(LAMMPS_DIR ${CMAKE_CURRENT_SOURCE_DIR}/.. ABSOLUTE)
get_filename_component(LAMMPS_LIB_BINARY_DIR ${CMAKE_BINARY_DIR}/lib ABSOLUTE)
# collect all executables and shared libs in the top level build folder
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR})
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR})
set(LAMMPS_SOURCE_DIR ${LAMMPS_DIR}/src)
set(LAMMPS_LIB_SOURCE_DIR ${LAMMPS_DIR}/lib)
@ -280,35 +284,19 @@ if(BUILD_MPI)
# We use a non-standard procedure to cross-compile with MPI on Windows
if((CMAKE_SYSTEM_NAME STREQUAL "Windows") AND CMAKE_CROSSCOMPILING)
include(MPI4WIN)
target_link_libraries(lammps PUBLIC MPI::MPI_CXX)
else()
find_package(MPI REQUIRED)
target_link_libraries(lammps PUBLIC MPI::MPI_CXX)
option(LAMMPS_LONGLONG_TO_LONG "Workaround if your system or MPI version does not recognize 'long long' data types" OFF)
if(LAMMPS_LONGLONG_TO_LONG)
target_compile_definitions(lammps PRIVATE -DLAMMPS_LONGLONG_TO_LONG)
endif()
endif()
target_link_libraries(lammps PUBLIC MPI::MPI_CXX)
else()
file(GLOB MPI_SOURCES ${LAMMPS_SOURCE_DIR}/STUBS/mpi.cpp)
add_library(mpi_stubs STATIC ${MPI_SOURCES})
set_target_properties(mpi_stubs PROPERTIES OUTPUT_NAME lammps_mpi_stubs${LAMMPS_MACHINE})
target_include_directories(mpi_stubs PUBLIC $<BUILD_INTERFACE:${LAMMPS_SOURCE_DIR}/STUBS>)
if(BUILD_SHARED_LIBS)
target_link_libraries(lammps PRIVATE mpi_stubs)
if(MSVC)
target_link_libraries(lmp PRIVATE mpi_stubs)
target_include_directories(lmp INTERFACE $<BUILD_INTERFACE:${LAMMPS_SOURCE_DIR}/STUBS>)
target_compile_definitions(lmp INTERFACE $<INSTALL_INTERFACE:LAMMPS_LIB_NO_MPI>)
endif()
target_include_directories(lammps INTERFACE $<BUILD_INTERFACE:${LAMMPS_SOURCE_DIR}/STUBS>)
target_compile_definitions(lammps INTERFACE $<INSTALL_INTERFACE:LAMMPS_LIB_NO_MPI>)
else()
target_include_directories(lammps INTERFACE $<BUILD_INTERFACE:${LAMMPS_SOURCE_DIR}/STUBS>)
target_compile_definitions(lammps INTERFACE $<INSTALL_INTERFACE:LAMMPS_LIB_NO_MPI>)
target_link_libraries(lammps PUBLIC mpi_stubs)
endif()
add_library(MPI::MPI_CXX ALIAS mpi_stubs)
target_sources(lammps PRIVATE ${LAMMPS_SOURCE_DIR}/STUBS/mpi.cpp)
add_library(mpi_stubs INTERFACE)
target_include_directories(mpi_stubs INTERFACE $<BUILD_INTERFACE:${LAMMPS_SOURCE_DIR}/STUBS>)
target_link_libraries(lammps PUBLIC mpi_stubs)
endif()
set(LAMMPS_SIZES "smallbig" CACHE STRING "LAMMPS integer sizes (smallsmall: all 32-bit, smallbig: 64-bit #atoms #timesteps, bigbig: also 64-bit imageint, 64-bit atom ids)")
@ -372,11 +360,13 @@ if(BUILD_OMP)
((CMAKE_CXX_COMPILER_ID STREQUAL "Intel") AND (CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 19.0)))
# GCC 9.x and later plus Clang 10.x and later implement strict OpenMP 4.0 semantics for consts.
# Intel 18.0 was tested to support both, so we switch to OpenMP 4+ from 19.x onward to be safe.
target_compile_definitions(lammps PRIVATE -DLAMMPS_OMP_COMPAT=4)
set(LAMMPS_OMP_COMPAT_LEVEL 4)
else()
target_compile_definitions(lammps PRIVATE -DLAMMPS_OMP_COMPAT=3)
set(LAMMPS_OMP_COMPAT_LEVEL 3)
endif()
target_compile_definitions(lammps PRIVATE -DLAMMPS_OMP_COMPAT=${LAMMPS_OMP_COMPAT_LEVEL})
target_link_libraries(lammps PRIVATE OpenMP::OpenMP_CXX)
target_link_libraries(lmp PRIVATE OpenMP::OpenMP_CXX)
endif()
if(PKG_MSCG OR PKG_ATC OR PKG_AWPMD OR PKG_ML-QUIP OR PKG_LATTE)
@ -590,11 +580,10 @@ if(PKG_ATC)
if(LAMMPS_SIZES STREQUAL "BIGBIG")
message(FATAL_ERROR "The ATC Package is not compatible with -DLAMMPS_BIGBIG")
endif()
target_link_libraries(atc PRIVATE ${LAPACK_LIBRARIES})
if(BUILD_MPI)
target_link_libraries(atc PRIVATE MPI::MPI_CXX)
target_link_libraries(atc PRIVATE ${LAPACK_LIBRARIES} MPI::MPI_CXX)
else()
target_link_libraries(atc PRIVATE mpi_stubs)
target_link_libraries(atc PRIVATE ${LAPACK_LIBRARIES} mpi_stubs)
endif()
target_include_directories(atc PRIVATE ${LAMMPS_SOURCE_DIR})
target_compile_definitions(atc PRIVATE -DLAMMPS_${LAMMPS_SIZES})
@ -690,6 +679,7 @@ endif()
set_target_properties(lammps PROPERTIES OUTPUT_NAME lammps${LAMMPS_MACHINE})
set_target_properties(lammps PROPERTIES SOVERSION ${SOVERSION})
set_target_properties(lammps PROPERTIES PREFIX "lib")
target_include_directories(lammps PUBLIC $<INSTALL_INTERFACE:${CMAKE_INSTALL_INCLUDEDIR}/lammps>)
file(MAKE_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/includes/lammps)
foreach(_HEADER ${LAMMPS_CXX_HEADERS})
@ -709,6 +699,9 @@ foreach(_DEF ${LAMMPS_DEFINES})
endforeach()
if(BUILD_SHARED_LIBS)
install(TARGETS lammps EXPORT LAMMPS_Targets LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR} ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR})
if(NOT BUILD_MPI)
install(TARGETS mpi_stubs EXPORT LAMMPS_Targets LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR} ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR})
endif()
configure_file(pkgconfig/liblammps.pc.in ${CMAKE_CURRENT_BINARY_DIR}/liblammps${LAMMPS_MACHINE}.pc @ONLY)
install(FILES ${CMAKE_CURRENT_BINARY_DIR}/liblammps${LAMMPS_MACHINE}.pc DESTINATION ${CMAKE_INSTALL_LIBDIR}/pkgconfig)
install(EXPORT LAMMPS_Targets FILE LAMMPS_Targets.cmake NAMESPACE LAMMPS:: DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake/LAMMPS)
@ -748,7 +741,7 @@ install(
if(BUILD_SHARED_LIBS)
if(CMAKE_VERSION VERSION_LESS 3.12)
# adjust so we find Python 3 versions before Python 2 on old systems with old CMake
set(Python_ADDITIONAL_VERSIONS 3.9 3.8 3.7 3.6 3.5)
set(Python_ADDITIONAL_VERSIONS 3.12 3.11 3.10 3.9 3.8 3.7 3.6)
find_package(PythonInterp) # Deprecated since version 3.12
if(PYTHONINTERP_FOUND)
set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
@ -756,13 +749,15 @@ if(BUILD_SHARED_LIBS)
else()
find_package(Python COMPONENTS Interpreter)
endif()
if(BUILD_IS_MULTI_CONFIG)
set(LIBLAMMPS_SHARED_BINARY ${CMAKE_BINARY_DIR}/$<CONFIG>/liblammps${LAMMPS_MACHINE}${CMAKE_SHARED_LIBRARY_SUFFIX})
else()
set(LIBLAMMPS_SHARED_BINARY ${CMAKE_BINARY_DIR}/liblammps${LAMMPS_MACHINE}${CMAKE_SHARED_LIBRARY_SUFFIX})
endif()
if(Python_EXECUTABLE)
add_custom_target(
install-python ${CMAKE_COMMAND} -E remove_directory build
COMMAND ${Python_EXECUTABLE} install.py -v ${LAMMPS_SOURCE_DIR}/version.h
-p ${LAMMPS_PYTHON_DIR}/lammps
-l ${CMAKE_BINARY_DIR}/liblammps${LAMMPS_MACHINE}${CMAKE_SHARED_LIBRARY_SUFFIX}
WORKING_DIRECTORY ${LAMMPS_PYTHON_DIR}
COMMAND ${Python_EXECUTABLE} ${LAMMPS_PYTHON_DIR}/install.py -p ${LAMMPS_PYTHON_DIR}/lammps -l ${LIBLAMMPS_SHARED_BINARY}
COMMENT "Installing LAMMPS Python module")
else()
add_custom_target(
@ -807,7 +802,6 @@ if(ClangFormat_FOUND)
endif()
get_target_property(DEFINES lammps COMPILE_DEFINITIONS)
get_property(BUILD_IS_MULTI_CONFIG GLOBAL PROPERTY GENERATOR_IS_MULTI_CONFIG)
if(BUILD_IS_MULTI_CONFIG)
set(LAMMPS_BUILD_TYPE "Multi-Config")
else()

99
cmake/CMakeSettings.json
View File

@ -6,7 +6,7 @@
"configurationType": "Debug",
"buildRoot": "${workspaceRoot}\\build\\${name}",
"installRoot": "${workspaceRoot}\\install\\${name}",
"cmakeCommandArgs": "-S ${workspaceRoot}\\cmake -C ${workspaceRoot}\\cmake\\presets\\windows.cmake -DENABLE_TESTING=on",
"cmakeCommandArgs": "-C ${workspaceRoot}\\cmake\\presets\\windows.cmake",
"buildCommandArgs": "",
"ctestCommandArgs": "",
"inheritEnvironments": [ "msvc_x64_x64" ],
@ -25,6 +25,54 @@
"name": "LAMMPS_EXCEPTIONS",
"value": "True",
"type": "BOOL"
},
{
"name": "PKG_PYTHON",
"value": "True",
"type": "BOOL"
},
{
"name": "ENABLE_TESTING",
"value": "True",
"type": "BOOL"
}
]
},
{
"name": "x64-Release-MSVC",
"generator": "Ninja",
"configurationType": "Release",
"buildRoot": "${workspaceRoot}\\build\\${name}",
"installRoot": "${workspaceRoot}\\install\\${name}",
"cmakeCommandArgs": "-C ${workspaceRoot}\\cmake\\presets\\windows.cmake",
"buildCommandArgs": "",
"ctestCommandArgs": "",
"inheritEnvironments": [ "msvc_x64_x64" ],
"variables": [
{
"name": "BUILD_SHARED_LIBS",
"value": "True",
"type": "BOOL"
},
{
"name": "BUILD_TOOLS",
"value": "True",
"type": "BOOL"
},
{
"name": "LAMMPS_EXCEPTIONS",
"value": "True",
"type": "BOOL"
},
{
"name": "PKG_PYTHON",
"value": "True",
"type": "BOOL"
},
{
"name": "ENABLE_TESTING",
"value": "True",
"type": "BOOL"
}
]
},
@ -34,11 +82,16 @@
"configurationType": "Debug",
"buildRoot": "${workspaceRoot}\\build\\${name}",
"installRoot": "${workspaceRoot}\\install\\${name}",
"cmakeCommandArgs": "-S ${workspaceRoot}\\cmake -C ${workspaceRoot}\\cmake\\presets\\windows.cmake -DENABLE_TESTING=on",
"cmakeCommandArgs": "-C ${workspaceRoot}\\cmake\\presets\\windows.cmake -DCMAKE_C_COMPILER=clang-cl.exe -DCMAKE_CXX_COMPILER=clang-cl.exe",
"buildCommandArgs": "",
"ctestCommandArgs": "",
"inheritEnvironments": [ "clang_cl_x64" ],
"variables": [
{
"name": "BUILD_SHARED_LIBS",
"value": "True",
"type": "BOOL"
},
{
"name": "BUILD_TOOLS",
"value": "True",
@ -48,19 +101,29 @@
"name": "LAMMPS_EXCEPTIONS",
"value": "True",
"type": "BOOL"
},
{
"name": "PKG_PYTHON",
"value": "True",
"type": "BOOL"
},
{
"name": "ENABLE_TESTING",
"value": "True",
"type": "BOOL"
}
]
},
{
"name": "x64-Debug-OneAPI",
"name": "x64-Release-Clang",
"generator": "Ninja",
"configurationType": "Debug",
"configurationType": "Release",
"buildRoot": "${workspaceRoot}\\build\\${name}",
"installRoot": "${workspaceRoot}\\install\\${name}",
"cmakeCommandArgs": "-S ${workspaceRoot}\\cmake -C ${workspaceRoot}\\cmake\\presets\\windows.cmake -DENABLE_TESTING=on -DCMAKE_CXX_COMPILER=icx -DCMAKE_C_COMPILER=icx -DBUILD_MPI=off",
"cmakeCommandArgs": "-C ${workspaceRoot}\\cmake\\presets\\windows.cmake -DCMAKE_C_COMPILER=clang-cl.exe -DCMAKE_CXX_COMPILER=clang-cl.exe",
"buildCommandArgs": "",
"ctestCommandArgs": "",
"inheritEnvironments": [ "msvc_x64_x64" ],
"inheritEnvironments": [ "clang_cl_x64" ],
"variables": [
{
"name": "BUILD_SHARED_LIBS",
@ -76,32 +139,14 @@
"name": "LAMMPS_EXCEPTIONS",
"value": "True",
"type": "BOOL"
}
]
},
{
"name": "x64-Debug-Intel",
"generator": "Ninja",
"configurationType": "Debug",
"buildRoot": "${workspaceRoot}\\build\\${name}",
"installRoot": "${workspaceRoot}\\install\\${name}",
"cmakeCommandArgs": "-S ${workspaceRoot}\\cmake -C ${workspaceRoot}\\cmake\\presets\\windows.cmake -DENABLE_TESTING=off -DCMAKE_CXX_COMPILER=icl -DCMAKE_C_COMPILER=icl -DCMAKE_Fortran_COMPILER=ifort -DBUILD_MPI=off",
"buildCommandArgs": "",
"ctestCommandArgs": "",
"inheritEnvironments": [ "msvc_x64_x64" ],
"variables": [
},
{
"name": "BUILD_SHARED_LIBS",
"name": "PKG_PYTHON",
"value": "True",
"type": "BOOL"
},
{
"name": "BUILD_TOOLS",
"value": "True",
"type": "BOOL"
},
{
"name": "LAMMPS_EXCEPTIONS",
"name": "ENABLE_TESTING",
"value": "True",
"type": "BOOL"
}

9
cmake/Modules/FindCythonize.cmake
View File

@ -8,18 +8,19 @@
#=============================================================================
if(CMAKE_VERSION VERSION_LESS 3.12)
set(Python_ADDITIONAL_VERSIONS 3.12 3.11 3.10 3.9 3.8 3.7 3.6)
find_package(PythonInterp 3.6 QUIET) # Deprecated since version 3.12
if(PYTHONINTERP_FOUND)
set(Python3_EXECUTABLE ${PYTHON_EXECUTABLE})
set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
endif()
else()
find_package(Python3 3.6 COMPONENTS Interpreter QUIET)
find_package(Python 3.6 COMPONENTS Interpreter QUIET)
endif()
# Use the Cython executable that lives next to the Python executable
# if it is a local installation.
if(Python3_EXECUTABLE)
get_filename_component(_python_path ${Python3_EXECUTABLE} PATH)
if(Python_EXECUTABLE)
get_filename_component(_python_path ${Python_EXECUTABLE} PATH)
find_program(Cythonize_EXECUTABLE
NAMES cythonize3 cythonize cythonize.bat
HINTS ${_python_path})

51
cmake/Modules/OpenCLLoader.cmake
View File

@ -1,50 +1,11 @@
message(STATUS "Downloading and building OpenCL loader library")
set(OPENCL_LOADER_URL "${LAMMPS_THIRDPARTY_URL}/opencl-loader-2021.09.18.tar.gz" CACHE STRING "URL for OpenCL loader tarball")
set(OPENCL_LOADER_MD5 "3b3882627964bd02e5c3b02065daac3c" CACHE STRING "MD5 checksum of OpenCL loader tarball")
set(OPENCL_LOADER_URL "${LAMMPS_THIRDPARTY_URL}/opencl-loader-2022.01.04.tar.gz" CACHE STRING "URL for OpenCL loader tarball")
set(OPENCL_LOADER_MD5 "8d3a801e87a2c6653bf0e27707063914" CACHE STRING "MD5 checksum of OpenCL loader tarball")
mark_as_advanced(OPENCL_LOADER_URL)
mark_as_advanced(OPENCL_LOADER_MD5)
include(ExternalProject)
ExternalProject_Add(opencl_loader
URL ${OPENCL_LOADER_URL}
URL_MD5 ${OPENCL_LOADER_MD5}
SOURCE_DIR "${CMAKE_BINARY_DIR}/opencl_loader-src"
BINARY_DIR "${CMAKE_BINARY_DIR}/opencl_loader-build"
CMAKE_ARGS ${CMAKE_REQUEST_PIC} ${CMAKE_EXTRA_OPENCL_LOADER_OPTS}
-DCMAKE_CXX_COMPILER=${CMAKE_CXX_COMPILER}
-DCMAKE_INSTALL_PREFIX=<INSTALL_DIR>
-DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
-DCMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM}
-DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE}
BUILD_BYPRODUCTS <BINARY_DIR>/libOpenCL${CMAKE_STATIC_LIBRARY_SUFFIX}
LOG_DOWNLOAD ON
LOG_CONFIGURE ON
LOG_BUILD ON
INSTALL_COMMAND ""
TEST_COMMAND "")
ExternalProject_Get_Property(opencl_loader SOURCE_DIR)
set(OPENCL_LOADER_INCLUDE_DIR ${SOURCE_DIR}/inc)
# workaround for CMake 3.10 on ubuntu 18.04
file(MAKE_DIRECTORY ${OPENCL_LOADER_INCLUDE_DIR})
ExternalProject_Get_Property(opencl_loader BINARY_DIR)
set(OPENCL_LOADER_LIBRARY_PATH "${BINARY_DIR}/libOpenCL${CMAKE_STATIC_LIBRARY_SUFFIX}")
find_package(Threads QUIET)
if(NOT WIN32)
set(OPENCL_LOADER_DEP_LIBS "Threads::Threads;${CMAKE_DL_LIBS}")
else()
set(OPENCL_LOADER_DEP_LIBS "cfgmgr32;runtimeobject")
endif()
add_library(OpenCL::OpenCL UNKNOWN IMPORTED)
add_dependencies(OpenCL::OpenCL opencl_loader)
set_target_properties(OpenCL::OpenCL PROPERTIES
IMPORTED_LOCATION ${OPENCL_LOADER_LIBRARY_PATH}
INTERFACE_INCLUDE_DIRECTORIES ${OPENCL_LOADER_INCLUDE_DIR}
INTERFACE_LINK_LIBRARIES "${OPENCL_LOADER_DEP_LIBS}")
set(INSTALL_LIBOPENCL OFF CACHE BOOL "" FORCE)
include(ExternalCMakeProject)
ExternalCMakeProject(opencl_loader ${OPENCL_LOADER_URL} ${OPENCL_LOADER_MD5} opencl-loader . "")
add_library(OpenCL::OpenCL ALIAS OpenCL)

9
cmake/Modules/Packages/COMPRESS.cmake
View File

@ -1,10 +1,11 @@
find_package(ZLIB REQUIRED)
target_link_libraries(lammps PRIVATE ZLIB::ZLIB)
find_package(PkgConfig REQUIRED)
pkg_check_modules(Zstd IMPORTED_TARGET libzstd>=1.4)
if(Zstd_FOUND)
find_package(PkgConfig QUIET)
if(PkgConfig_FOUND)
pkg_check_modules(Zstd IMPORTED_TARGET libzstd>=1.4)
if(Zstd_FOUND)
target_compile_definitions(lammps PRIVATE -DLAMMPS_ZSTD)
target_link_libraries(lammps PRIVATE PkgConfig::Zstd)
endif()
endif()

9
cmake/Modules/Packages/GPU.cmake
View File

@ -422,13 +422,12 @@ RegisterStylesExt(${GPU_SOURCES_DIR} gpu GPU_SOURCES)
RegisterFixStyle(${GPU_SOURCES_DIR}/fix_gpu.h)
get_property(GPU_SOURCES GLOBAL PROPERTY GPU_SOURCES)
if(NOT BUILD_MPI)
# mpistubs is aliased to MPI::MPI_CXX, but older versions of cmake won't work forward the include path
target_link_libraries(gpu PRIVATE mpi_stubs)
else()
if(BUILD_MPI)
target_link_libraries(gpu PRIVATE MPI::MPI_CXX)
else()
target_link_libraries(gpu PRIVATE mpi_stubs)
endif()
target_compile_definitions(gpu PRIVATE -DLAMMPS_${LAMMPS_SIZES})
set_target_properties(gpu PROPERTIES OUTPUT_NAME lammps_gpu${LAMMPS_MACHINE})
target_sources(lammps PRIVATE ${GPU_SOURCES})

46
cmake/Modules/Packages/KOKKOS.cmake
View File

@ -11,8 +11,14 @@ if(Kokkos_ENABLE_CUDA)
endif()
# Adding OpenMP compiler flags without the checks done for
# BUILD_OMP can result in compile failures. Enforce consistency.
if(Kokkos_ENABLE_OPENMP AND NOT BUILD_OMP)
message(FATAL_ERROR "Must enable BUILD_OMP with Kokkos_ENABLE_OPENMP")
if(Kokkos_ENABLE_OPENMP)
if(NOT BUILD_OMP)
message(FATAL_ERROR "Must enable BUILD_OMP with Kokkos_ENABLE_OPENMP")
else()
if(LAMMPS_OMP_COMPAT_LEVEL LESS 4)
message(FATAL_ERROR "Compiler must support OpenMP 4.0 or later with Kokkos_ENABLE_OPENMP")
endif()
endif()
endif()
########################################################################
@ -27,6 +33,8 @@ if(DOWNLOAD_KOKKOS)
endforeach()
message(STATUS "KOKKOS download requested - we will build our own")
list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_INSTALL_PREFIX=<INSTALL_DIR>")
# build KOKKOS downloaded libraries as static libraries but with PIC, if needed
list(APPEND KOKKOS_LIB_BUILD_ARGS "-DBUILD_SHARED_LIBS=OFF")
if(CMAKE_REQUEST_PIC)
list(APPEND KOKKOS_LIB_BUILD_ARGS ${CMAKE_REQUEST_PIC})
endif()
@ -47,18 +55,22 @@ if(DOWNLOAD_KOKKOS)
URL ${KOKKOS_URL}
URL_MD5 ${KOKKOS_MD5}
CMAKE_ARGS ${KOKKOS_LIB_BUILD_ARGS}
BUILD_BYPRODUCTS <INSTALL_DIR>/lib/libkokkoscore.a
BUILD_BYPRODUCTS <INSTALL_DIR>/lib/libkokkoscore.a <INSTALL_DIR>/lib/libkokkoscontainers.a
)
ExternalProject_get_property(kokkos_build INSTALL_DIR)
file(MAKE_DIRECTORY ${INSTALL_DIR}/include)
add_library(LAMMPS::KOKKOS UNKNOWN IMPORTED)
set_target_properties(LAMMPS::KOKKOS PROPERTIES
add_library(LAMMPS::KOKKOSCORE UNKNOWN IMPORTED)
add_library(LAMMPS::KOKKOSCONTAINERS UNKNOWN IMPORTED)
set_target_properties(LAMMPS::KOKKOSCORE PROPERTIES
IMPORTED_LOCATION "${INSTALL_DIR}/lib/libkokkoscore.a"
INTERFACE_INCLUDE_DIRECTORIES "${INSTALL_DIR}/include"
INTERFACE_LINK_LIBRARIES ${CMAKE_DL_LIBS})
target_link_libraries(lammps PRIVATE LAMMPS::KOKKOS)
target_link_libraries(lmp PRIVATE LAMMPS::KOKKOS)
add_dependencies(LAMMPS::KOKKOS kokkos_build)
set_target_properties(LAMMPS::KOKKOSCONTAINERS PROPERTIES
IMPORTED_LOCATION "${INSTALL_DIR}/lib/libkokkoscontainers.a")
target_link_libraries(lammps PRIVATE LAMMPS::KOKKOSCORE LAMMPS::KOKKOSCONTAINERS)
target_link_libraries(lmp PRIVATE LAMMPS::KOKKOSCORE LAMMPS::KOKKOSCONTAINERS)
add_dependencies(LAMMPS::KOKKOSCORE kokkos_build)
add_dependencies(LAMMPS::KOKKOSCONTAINERS kokkos_build)
elseif(EXTERNAL_KOKKOS)
find_package(Kokkos 3.5.00 REQUIRED CONFIG)
target_link_libraries(lammps PRIVATE Kokkos::kokkos)
@ -66,8 +78,17 @@ elseif(EXTERNAL_KOKKOS)
else()
set(LAMMPS_LIB_KOKKOS_SRC_DIR ${LAMMPS_LIB_SOURCE_DIR}/kokkos)
set(LAMMPS_LIB_KOKKOS_BIN_DIR ${LAMMPS_LIB_BINARY_DIR}/kokkos)
# build KOKKOS internal libraries as static libraries but with PIC, if needed
if(BUILD_SHARED_LIBS)
set(BUILD_SHARED_LIBS_WAS_ON YES)
set(BUILD_SHARED_LIBS OFF)
endif()
if(CMAKE_REQUEST_PIC)
set(CMAKE_POSITION_INDEPENDENT_CODE ON)
endif()
add_subdirectory(${LAMMPS_LIB_KOKKOS_SRC_DIR} ${LAMMPS_LIB_KOKKOS_BIN_DIR})
set(Kokkos_INCLUDE_DIRS ${LAMMPS_LIB_KOKKOS_SRC_DIR}/core/src
${LAMMPS_LIB_KOKKOS_SRC_DIR}/containers/src
${LAMMPS_LIB_KOKKOS_SRC_DIR}/algorithms/src
@ -75,6 +96,9 @@ else()
target_include_directories(lammps PRIVATE ${Kokkos_INCLUDE_DIRS})
target_link_libraries(lammps PRIVATE kokkos)
target_link_libraries(lmp PRIVATE kokkos)
if(BUILD_SHARED_LIBS_WAS_ON)
set(BUILD_SHARED_LIBS ON)
endif()
endif()
target_compile_definitions(lammps PUBLIC $<BUILD_INTERFACE:LMP_KOKKOS>)
@ -109,6 +133,12 @@ if(PKG_KSPACE)
endif()
endif()
if(PKG_PHONON)
list(APPEND KOKKOS_PKG_SOURCES ${KOKKOS_PKG_SOURCES_DIR}/dynamical_matrix_kokkos.cpp)
list(APPEND KOKKOS_PKG_SOURCES ${KOKKOS_PKG_SOURCES_DIR}/third_order_kokkos.cpp)
endif()
set_property(GLOBAL PROPERTY "KOKKOS_PKG_SOURCES" "${KOKKOS_PKG_SOURCES}")
# detects styles which have KOKKOS version

6
cmake/Modules/Packages/ML-HDNNP.cmake
View File

@ -46,12 +46,10 @@ if(DOWNLOAD_N2P2)
if((CMAKE_SYSTEM_NAME STREQUAL Windows) AND CMAKE_CROSSCOMPILING)
get_target_property(N2P2_MPI_INCLUDE MPI::MPI_CXX INTERFACE_INCLUDE_DIRECTORIES)
set(N2P2_PROJECT_OPTIONS "-I${N2P2_MPI_INCLUDE}")
set(MPI_CXX_COMPILER ${CMAKE_CXX_COMPILER})
endif()
if(CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
get_target_property(N2P2_MPI_INCLUDE MPI::MPI_CXX INTERFACE_INCLUDE_DIRECTORIES)
set(N2P2_PROJECT_OPTIONS "-I${N2P2_MPI_INCLUDE}")
set(MPI_CXX_COMPILER ${CMAKE_CXX_COMPILER})
endif()
endif()
@ -64,8 +62,8 @@ if(DOWNLOAD_N2P2)
string(TOUPPER "${CMAKE_BUILD_TYPE}" BTYPE)
set(N2P2_BUILD_FLAGS "${CMAKE_SHARED_LIBRARY_CXX_FLAGS} ${CMAKE_CXX_FLAGS} ${CMAKE_CXX_FLAGS_${BTYPE}} ${N2P2_CXX_STD}")
set(N2P2_BUILD_OPTIONS INTERFACES=LAMMPS COMP=${N2P2_COMP} "PROJECT_OPTIONS=${N2P2_PROJECT_OPTIONS}" "PROJECT_DEBUG="
"PROJECT_CC=${CMAKE_CXX_COMPILER}" "PROJECT_MPICC=${MPI_CXX_COMPILER}" "PROJECT_CFLAGS=${N2P2_BUILD_FLAGS}"
"PROJECT_AR=${N2P2_AR}")
"PROJECT_CC=${CMAKE_CXX_COMPILER}" "PROJECT_MPICC=${CMAKE_CXX_COMPILER}" "PROJECT_CFLAGS=${N2P2_BUILD_FLAGS}"
"PROJECT_AR=${N2P2_AR}" "APP_CORE=nnp-convert" "APP_TRAIN=nnp-train" "APP=nnp-convert")
# echo final flag for debugging
message(STATUS "N2P2 BUILD OPTIONS: ${N2P2_BUILD_OPTIONS}")

4
cmake/Modules/Packages/PLUMED.cmake
View File

@ -54,8 +54,8 @@ if(DOWNLOAD_PLUMED)
set(PLUMED_BUILD_BYPRODUCTS "<INSTALL_DIR>/lib/libplumedWrapper.a")
endif()
set(PLUMED_URL "https://github.com/plumed/plumed2/releases/download/v2.7.3/plumed-src-2.7.3.tgz" CACHE STRING "URL for PLUMED tarball")
set(PLUMED_MD5 "f00cc82edfefe6bb3df934911dbe32fb" CACHE STRING "MD5 checksum of PLUMED tarball")
set(PLUMED_URL "https://github.com/plumed/plumed2/releases/download/v2.7.4/plumed-src-2.7.4.tgz" CACHE STRING "URL for PLUMED tarball")
set(PLUMED_MD5 "858e0b6aed173748fc85b6bc8a9dcb3e" CACHE STRING "MD5 checksum of PLUMED tarball")
mark_as_advanced(PLUMED_URL)
mark_as_advanced(PLUMED_MD5)

2
cmake/Modules/Packages/PYTHON.cmake
View File

@ -3,7 +3,7 @@ if(CMAKE_VERSION VERSION_LESS 3.12)
target_include_directories(lammps PRIVATE ${PYTHON_INCLUDE_DIRS})
target_link_libraries(lammps PRIVATE ${PYTHON_LIBRARIES})
else()
find_package(Python REQUIRED COMPONENTS Development)
find_package(Python REQUIRED COMPONENTS Interpreter Development)
target_link_libraries(lammps PRIVATE Python::Python)
endif()
target_compile_definitions(lammps PRIVATE -DLMP_PYTHON)

8
cmake/Modules/generate_lmpgitversion.cmake
View File

@ -24,10 +24,10 @@ if(GIT_FOUND AND EXISTS ${LAMMPS_DIR}/.git)
OUTPUT_STRIP_TRAILING_WHITESPACE)
endif()
set(temp "${temp}const bool LAMMPS_NS::LAMMPS::has_git_info = ${temp_git_info};\n")
set(temp "${temp}const char LAMMPS_NS::LAMMPS::git_commit[] = \"${temp_git_commit}\";\n")
set(temp "${temp}const char LAMMPS_NS::LAMMPS::git_branch[] = \"${temp_git_branch}\";\n")
set(temp "${temp}const char LAMMPS_NS::LAMMPS::git_descriptor[] = \"${temp_git_describe}\";\n")
set(temp "${temp}bool LAMMPS_NS::LAMMPS::has_git_info() { return ${temp_git_info}; }\n")
set(temp "${temp}const char *LAMMPS_NS::LAMMPS::git_commit() { return \"${temp_git_commit}\"; }\n")
set(temp "${temp}const char *LAMMPS_NS::LAMMPS::git_branch() { return \"${temp_git_branch}\"; }\n")
set(temp "${temp}const char *LAMMPS_NS::LAMMPS::git_descriptor() { return \"${temp_git_describe}\"; }\n")
set(temp "${temp}#endif\n\n")
message(STATUS "Generating lmpgitversion.h...")

7
cmake/iwyu/iwyu-extra-map.imp
View File

@ -20,9 +20,14 @@
{ include: [ "@\"kspace_.*.h\"", public, "\"style_kspace.h\"", public ] },
{ include: [ "@\"nbin_.*.h\"", public, "\"style_nbin.h\"", public ] },
{ include: [ "@\"npair_.*.h\"", public, "\"style_npair.h\"", public ] },
{ include: [ "@\"nstenci_.*.h\"", public, "\"style_nstencil.h\"", public ] },
{ include: [ "@\"nstencil_.*.h\"", public, "\"style_nstencil.h\"", public ] },
{ include: [ "@\"ntopo_.*.h\"", public, "\"style_ntopo.h\"", public ] },
{ include: [ "\"fmt/core.h\"", private, "\"fmt/format.h\"", public ] },
{ include: [ "<float.h>", public, "<cfloat>", public ] },
{ include: [ "\"float.h\"", public, "<cfloat>", public ] },
{ include: [ "<limits.h>", public, "<climits>", public ] },
{ include: [ "\"limits.h\"", public, "<climits>", public ] },
{ include: [ "<stdio.h>", public, "<cstdio>", public ] },
{ include: [ "<bits/types/struct_rusage.h>", private, "<sys/types.h>", public ] },
{ include: [ "<bits/types/struct_tm.h>", private, "<ctime>", public ] },
]

6
cmake/presets/gcc.cmake
View File

@ -3,19 +3,19 @@
set(CMAKE_CXX_COMPILER "g++" CACHE STRING "" FORCE)
set(CMAKE_C_COMPILER "gcc" CACHE STRING "" FORCE)
set(CMAKE_Fortran_COMPILER "gfortran" CACHE STRING "" FORCE)
set(CMAKE_CXX_FLAGS_DEBUG "-Wall -g" CACHE STRING "" FORCE)
set(CMAKE_CXX_FLAGS_DEBUG "-Wall -Og -g" CACHE STRING "" FORCE)
set(CMAKE_CXX_FLAGS_RELWITHDEBINFO "-g -O2 -DNDEBUG" CACHE STRING "" FORCE)
set(CMAKE_CXX_FLAGS_RELEASE "-O3 -DNDEBUG" CACHE STRING "" FORCE)
set(MPI_CXX "g++" CACHE STRING "" FORCE)
set(MPI_CXX_COMPILER "mpicxx" CACHE STRING "" FORCE)
set(MPI_C "gcc" CACHE STRING "" FORCE)
set(MPI_C_COMPILER "mpicc" CACHE STRING "" FORCE)
set(CMAKE_C_FLAGS_DEBUG "-Wall -g" CACHE STRING "" FORCE)
set(CMAKE_C_FLAGS_DEBUG "-Wall -Og -g" CACHE STRING "" FORCE)
set(CMAKE_C_FLAGS_RELWITHDEBINFO "-g -O2 -DNDEBUG" CACHE STRING "" FORCE)
set(CMAKE_C_FLAGS_RELEASE "-O3 -DNDEBUG" CACHE STRING "" FORCE)
set(MPI_Fortran "gfortran" CACHE STRING "" FORCE)
set(MPI_Fortran_COMPILER "mpifort" CACHE STRING "" FORCE)
set(CMAKE_Fortran_FLAGS_DEBUG "-Wall -g -std=f2003" CACHE STRING "" FORCE)
set(CMAKE_Fortran_FLAGS_DEBUG "-Wall -Og -g -std=f2003" CACHE STRING "" FORCE)
set(CMAKE_Fortran_FLAGS_RELWITHDEBINFO "-g -O2 -DNDEBUG -std=f2003" CACHE STRING "" FORCE)
set(CMAKE_Fortran_FLAGS_RELEASE "-O3 -DNDEBUG -std=f2003" CACHE STRING "" FORCE)
unset(HAVE_OMP_H_INCLUDE CACHE)

2
doc/lammps.1
View File

@ -1,4 +1,4 @@
.TH LAMMPS "1" "7 January 2022" "2022-1-7"
.TH LAMMPS "1" "17 February 2022" "2022-2-17"
.SH NAME
.B LAMMPS
\- Molecular Dynamics Simulator.

92
doc/src/Build_windows.rst
View File

@ -16,44 +16,52 @@ General remarks
LAMMPS is developed and tested primarily on Linux machines. The vast
majority of HPC clusters and supercomputers today run on Linux as well.
While portability to other platforms is desired, it is not always achieved.
The LAMMPS developers are dependent on LAMMPS users giving feedback and
providing assistance in resolving portability issues. This is particularly
true for compiling LAMMPS on Windows, since this platform has significant
differences in some low-level functionality.
While portability to other platforms is desired, it is not always
achieved. That is sometimes due to non-portable code in LAMMPS itself,
but more often due to portability limitations of external libraries and
tools required to build a specific feature or package. The LAMMPS
developers are dependent on LAMMPS users giving feedback and providing
assistance in resolving portability issues. This is particularly true
for compiling LAMMPS on Windows, since this platform has significant
differences in some low-level functionality. As of LAMMPS version 14
December 2021, large parts of LAMMPS can be compiled natively with the
Microsoft Visual C++ Compilers. This is largely facilitated by using
the :doc:`Developer_platform` in the ``platform`` namespace.
Before trying to build LAMMPS on Windows yourself, please consider the
`pre-compiled Windows installer packages <https://packages.lammps.org/windows.html>`_
and see if they are sufficient for your needs.
.. _linux:
Running Linux on Windows
^^^^^^^^^^^^^^^^^^^^^^^^
Before trying to build LAMMPS on Windows, please consider if the
pre-compiled Windows binary packages are sufficient for your needs. If
it is necessary for you to compile LAMMPS on a Windows machine
If it is necessary for you to compile LAMMPS on a Windows machine
(e.g. because it is your main desktop), please also consider using a
virtual machine software and compile and run LAMMPS in a Linux virtual
machine, or - if you have a sufficiently up-to-date Windows 10 or
Windows 11 installation - consider using the Windows subsystem for
Linux. This optional Windows feature allows you to run the bash shell
from Ubuntu from within Windows and from there on, you can pretty much
use that shell like you are running on an Ubuntu Linux machine
(e.g. installing software via apt-get and more). For more details on
that, please see :doc:`this tutorial <Howto_wsl>`.
of a Linux system (Ubuntu by default) from within Windows and from there
on, you can pretty much use that shell like you are running on a regular
Ubuntu Linux machine (e.g. installing software via apt-get and more).
For more details on that, please see :doc:`this tutorial <Howto_wsl>`.
.. _gnu:
Using a GNU GCC ported to Windows
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
One option for compiling LAMMPS on Windows natively that has been known
to work in the past is to install a bash shell, unix shell utilities,
perl, GNU make, and a GNU compiler ported to Windows. The Cygwin
package provides a unix/linux interface to low-level Windows functions,
so LAMMPS can be compiled on Windows. The necessary (minor)
modifications to LAMMPS are included, but may not always up-to-date for
recently added functionality and the corresponding new code. A machine
makefile for using cygwin for the old build system is provided. Using
CMake for this mode of compilation is untested and not likely to work.
One option for compiling LAMMPS on Windows natively is to install a Bash
shell, Unix shell utilities, Perl, Python, GNU make, and a GNU compiler
ported to Windows. The Cygwin package provides a unix/linux interface
to low-level Windows functions, so LAMMPS can be compiled on Windows.
The necessary (minor) modifications to LAMMPS are included, but may not
always up-to-date for recently added functionality and the corresponding
new code. A machine makefile for using cygwin for the old build system
is provided. Using CMake for this mode of compilation is untested and
not likely to work.
When compiling for Windows do **not** set the ``-DLAMMPS_MEMALIGN``
define in the LMP_INC makefile variable and add ``-lwsock32 -lpsapi`` to
@ -75,19 +83,27 @@ Using Microsoft Visual Studio
Following the integration of the :doc:`platform namespace
<Developer_platform>` into the LAMMPS code base, portability of LAMMPS
to be compiled on Windows using Visual Studio has been significantly
improved. This has been tested with Visual Studio 2019 (aka version
16). Not all features and packages in LAMMPS are currently supported
out of the box, but a preset ``cmake/presets/windows.cmake`` is provided
that contains the packages that have been compiled successfully. You
must use the CMake based build procedure, and either use the integrated
CMake support of Visual Studio or use an external CMake installation to
create build files for the Visual Studio build system. Please note that
on launching Visual Studio it will scan the directory tree and likely
miss the correct master ``CMakeLists.txt``. Try to open the
``cmake/CMakeSettings.json`` and use those CMake configurations as a
starting point. It is also possible to configure and compile LAMMPS
from the command line with a CMake binary from `cmake.org <https://cmake.org>`_.
for native compilation on Windows using Visual Studio has been
significantly improved. This has been tested with Visual Studio 2019
(aka version 16) and Visual Studio 2022 (aka version 17). We strongly
recommend using Visual Studio 2022 version 17.1 or later. Not all
features and packages in LAMMPS are currently supported out of the box,
but a preset ``cmake/presets/windows.cmake`` is provided that contains
the packages that have been compiled successfully so far. You **must**
use the CMake based build procedure, since there is no support for GNU
make or the Unix shell utilities required for the GNU make build
procedure.
It is possible to use both the integrated CMake support of the Visual
Studio IDE or use an external CMake installation (e.g. downloaded from
cmake.org) to create build files and compile LAMMPS from the command line.
.. note::
Versions of Visual Studio before version 17.1 may scan the entire
LAMMPS source tree and likely miss the correct master
``CMakeLists.txt`` and get confused since there are multiple files
of that name in different folders but none in top level folder.
Please note, that for either approach CMake will create a so-called
:ref:`"multi-configuration" build environment <cmake_multiconfig>`, and
@ -98,9 +114,11 @@ To support running in parallel you can compile with OpenMP enabled using
the OPENMP package or install Microsoft MPI (including the SDK) and compile
LAMMPS with MPI enabled.
This is work in progress and you should contact the LAMMPS developers
via GitHub, the forum, or the mailing list, if you have questions or
LAMMPS specific problems.
.. note::
This is work in progress and you should contact the LAMMPS developers
via GitHub, the forum, or the mailing list, if you have questions or
LAMMPS specific problems.
.. _cross:

4
doc/src/Commands_all.rst
View File

@ -47,7 +47,7 @@ An alphabetic list of all general LAMMPS commands.
* :doc:`displace_atoms <displace_atoms>`
* :doc:`dump <dump>`
* :doc:`dump_modify <dump_modify>`
* :doc:`dynamical_matrix <dynamical_matrix>`
* :doc:`dynamical_matrix (k) <dynamical_matrix>`
* :doc:`echo <echo>`
* :doc:`fix <fix>`
* :doc:`fix_modify <fix_modify>`
@ -117,7 +117,7 @@ An alphabetic list of all general LAMMPS commands.
* :doc:`thermo <thermo>`
* :doc:`thermo_modify <thermo_modify>`
* :doc:`thermo_style <thermo_style>`
* :doc:`third_order <third_order>`
* :doc:`third_order (k) <third_order>`
* :doc:`timer <timer>`
* :doc:`timestep <timestep>`
* :doc:`uncompute <uncompute>`

1
doc/src/Commands_fix.rst
View File

@ -129,6 +129,7 @@ OPT.
* :doc:`npt/sphere (o) <fix_npt_sphere>`
* :doc:`npt/uef <fix_nh_uef>`
* :doc:`numdiff <fix_numdiff>`
* :doc:`numdiff/virial <fix_numdiff_virial>`
* :doc:`nve (giko) <fix_nve>`
* :doc:`nve/asphere (gi) <fix_nve_asphere>`
* :doc:`nve/asphere/noforce <fix_nve_asphere_noforce>`

3
doc/src/Commands_pair.rst
View File

@ -119,10 +119,12 @@ OPT.
* :doc:`granular <pair_granular>`
* :doc:`gw <pair_gw>`
* :doc:`gw/zbl <pair_gw>`
* :doc:`harmonic/cut (o) <pair_harmonic_cut>`
* :doc:`hbond/dreiding/lj (o) <pair_hbond_dreiding>`
* :doc:`hbond/dreiding/morse (o) <pair_hbond_dreiding>`
* :doc:`hdnnp <pair_hdnnp>`
* :doc:`ilp/graphene/hbn <pair_ilp_graphene_hbn>`
* :doc:`ilp/tmd <pair_ilp_tmd>`
* :doc:`kolmogorov/crespi/full <pair_kolmogorov_crespi_full>`
* :doc:`kolmogorov/crespi/z <pair_kolmogorov_crespi_z>`
* :doc:`lcbop <pair_lcbop>`
@ -240,6 +242,7 @@ OPT.
* :doc:`reaxff (ko) <pair_reaxff>`
* :doc:`rebo (io) <pair_airebo>`
* :doc:`resquared (go) <pair_resquared>`
* :doc:`saip/metal <pair_saip_metal>`
* :doc:`sdpd/taitwater/isothermal <pair_sdpd_taitwater_isothermal>`
* :doc:`smd/hertz <pair_smd_hertz>`
* :doc:`smd/tlsph <pair_smd_tlsph>`

2
doc/src/Developer.rst
View File

@ -11,7 +11,9 @@ of time and requests from the LAMMPS user community.
:maxdepth: 1
Developer_org
Developer_code_design
Developer_parallel
Developer_comm_ops
Developer_flow
Developer_write
Developer_notes

433
doc/src/Developer_code_design.rst Normal file
View File

@ -0,0 +1,433 @@
Code design
-----------
This section explains some of the code design choices in LAMMPS with
the goal of helping developers write new code similar to the existing
code. Please see the section on :doc:`Requirements for contributed
code <Modify_style>` for more specific recommendations and guidelines.
While that section is organized more in the form of a checklist for
code contributors, the focus here is on overall code design strategy,
choices made between possible alternatives, and discussing some
relevant C++ programming language constructs.
Historically, the basic design philosophy of the LAMMPS C++ code was a
"C with classes" style. The motivation was to make it easy to modify
LAMMPS for people without significant training in C++ programming.
Data structures and code constructs were used that resemble the
previous implementation(s) in Fortran. A contributing factor to this
choice also was that at the time, C++ compilers were often not mature
and some of the advanced features contained bugs or did not function
as the standard required. There were also disagreements between
compiler vendors as to how to interpret the C++ standard documents.
However, C++ compilers have now advanced significantly. In 2020 we
decided to to require the C++11 standard as the minimum C++ language
standard for LAMMPS. Since then we have begun to also replace some of
the C-style constructs with equivalent C++ functionality, either from
the C++ standard library or as custom classes or functions, in order
to improve readability of the code and to increase code reuse through
abstraction of commonly used functionality.
.. note::
Please note that as of spring 2022 there is still a sizable chunk
of legacy code in LAMMPS that has not yet been refactored to
reflect these style conventions in full. LAMMPS has a large code
base and many different contributors and there also is a hierarchy
of precedence in which the code is adapted. Highest priority has
been the code in the ``src`` folder, followed by code in packages
in order of their popularity and complexity (simpler code is
adapted sooner), followed by code in the ``lib`` folder. Source
code that is downloaded from external packages or libraries during
compilation is not subject to the conventions discussed here.
Object oriented code
^^^^^^^^^^^^^^^^^^^^
LAMMPS is designed to be an object oriented code. Each simulation is
represented by an instance of the LAMMPS class. When running in
parallel each MPI process creates such an instance. This can be seen
in the ``main.cpp`` file where the core steps of running a LAMMPS
simulation are the following 3 lines of code:
.. code-block:: C++
LAMMPS *lammps = new LAMMPS(argc, argv, lammps_comm);
lammps->input->file();
delete lammps;
The first line creates a LAMMPS class instance and passes the command
line arguments and the global communicator to its constructor. The
second line triggers the LAMMPS instance to process the input (either
from standard input or a provided input file) until the simulation
ends. The third line deletes the LAMMPS instance. The remainder of
the main.cpp file has code for error handling, MPI configuration, and
other special features.
The basic LAMMPS class hierarchy which is created by the LAMMPS class
constructor is shown in :ref:`class-topology`. When input commands
are processed, additional class instances are created, or deleted, or
replaced. Likewise specific member functions of specific classes are
called to trigger actions such creating atoms, computing forces,
computing properties, time-propagating the system, or writing output.
Compositing and Inheritance
===========================
LAMMPS makes extensive use of the object oriented programming (OOP)
principles of *compositing* and *inheritance*. Classes like the
``LAMMPS`` class are a **composite** containing pointers to instances
of other classes like ``Atom``, ``Comm``, ``Force``, ``Neighbor``,
``Modify``, and so on. Each of these classes implement certain
functionality by storing and manipulating data related to the
simulation and providing member functions that trigger certain
actions. Some of those classes like ``Force`` are themselves
composites, containing instances of classes describing different force
interactions. Similarly the ``Modify`` class contains a list of
``Fix`` and ``Compute`` classes. If the input commands that
correspond to these classes include the word *style*, then LAMMPS
stores only a single instance of that class. E.g. *atom_style*,
*comm_style*, *pair_style*, *bond_style*. It the input command does
not include the word *style*, there can be many instances of that
class defined. E.g. *region*, *fix*, *compute*, *dump*.
**Inheritance** enables creation of *derived* classes that can share
common functionality in their base class while providing a consistent
interface. The derived classes replace (dummy or pure) functions in
the base class. The higher level classes can then call those methods
of the instantiated classes without having to know which specific
derived class variant was instantiated. In LAMMPS these derived
classes are often referred to as "styles", e.g. pair styles, fix
styles, atom styles and so on.
This is the origin of the flexibility of LAMMPS. For example pair
styles implement a variety of different non-bonded interatomic
potentials functions. All details for the implementation of a
potential are stored and executed in a single class.
As mentioned above, there can be multiple instances of classes derived
from the ``Fix`` or ``Compute`` base classes. They represent a
different facet of LAMMPS flexibility as they provide methods which
can be called at different points in time within a timestep, as
explained in `Developer_flow`. This allows the input script to tailor
how a specific simulation is run, what diagnostic computations are
performed, and how the output of those computations is further
processed or output.
Additional code sharing is possible by creating derived classes from the
derived classes (e.g., to implement an accelerated version of a pair
style) where only a subset of the derived class methods are replaced
with accelerated versions.
Polymorphism
============
Polymorphism and dynamic dispatch are another OOP feature that play an
important role in how LAMMPS selects what code to execute. In a
nutshell, this is a mechanism where the decision of which member
function to call from a class is determined at runtime and not when
the code is compiled. To enable it, the function has to be declared
as ``virtual`` and all corresponding functions in derived classes
should use the ``override`` property. Below is a brief example.
.. code-block:: c++
class Base {
public:
virtual ~Base() = default;
void call();
void normal();
virtual void poly();
};
void Base::call() {
normal();
poly();
}
class Derived : public Base {
public:
~Derived() override = default;
void normal();
void poly() override;
};
// [....]
Base *base1 = new Base();
Base *base2 = new Derived();
base1->call();
base2->call();
The difference in behavior of the ``normal()`` and the ``poly()`` member
functions is which of the two member functions is called when executing
`base1->call()` versus `base2->call()`. Without polymorphism, a
function within the base class can only call member functions within the
same scope, that is ``Base::call()`` will always call
``Base::normal()``. But for the `base2->call()` case the call of the
virtual member function will be dispatched to ``Derived::poly()``
instead. This mechanism means that functions are called within the
scope of the class type that was used to *create* the class instance are
invoked; even if they are assigned to a pointer using the type of a base
class. This is the desired behavior and this way LAMMPS can even use
styles that are loaded at runtime from a shared object file with the
:doc:`plugin command <plugin>`.
A special case of virtual functions are so-called pure functions. These
are virtual functions that are initialized to 0 in the class declaration
(see example below).
.. code-block:: c++
class Base {
public:
virtual void pure() = 0;
};
This has the effect that an instance of the base class cannot be
created and that derived classes **must** implement these functions.
Many of the functions listed with the various class styles in the
section :doc:`Modify` are pure functions. The motivation for this is
to define the interface or API of the functions but defer their
implementation to the derived classes.
However, there are downsides to this. For example, calls to virtual
functions from within a constructor, will not be in the scope of the
derived class and thus it is good practice to either avoid calling them
or to provide an explicit scope such as ``Base::poly()`` or
``Derived::poly()``. Furthermore, any destructors in classes containing
virtual functions should be declared virtual too, so they will be
processed in the expected order before types are removed from dynamic
dispatch.
.. admonition:: Important Notes
In order to be able to detect incompatibilities at compile time and
to avoid unexpected behavior, it is crucial that all member functions
that are intended to replace a virtual or pure function use the
``override`` property keyword. For the same reason, the use of
overloads or default arguments for virtual functions should be
avoided as they lead to confusion over which function is supposed to
override which and which arguments need to be declared.
Style Factories
===============
In order to create class instances for different styles, LAMMPS often
uses a programming pattern called `Factory`. Those are functions that
create an instance of a specific derived class, say ``PairLJCut`` and
return a pointer to the type of the common base class of that style,
``Pair`` in this case. To associate the factory function with the
style keyword, an ``std::map`` class is used with function pointers
indexed by their keyword (for example "lj/cut" for ``PairLJCut`` and
"morse" for ``PairMorse``). A couple of typedefs help keep the code
readable and a template function is used to implement the actual
factory functions for the individual classes. Below is an example
of such a factory function from the ``Force`` class as declared in
``force.h`` and implemented in ``force.cpp``. The file ``style_pair.h``
is generated during compilation and includes all main header files
(i.e. those starting with ``pair_``) of pair styles and then the
macro ``PairStyle()`` will associate the style name "lj/cut"
with a factory function creating an instance of the ``PairLJCut``
class.
.. code-block:: C++
// from force.h
typedef Pair *(*PairCreator)(LAMMPS *);
typedef std::map<std::string, PairCreator> PairCreatorMap;
PairCreatorMap *pair_map;
// from force.cpp
template <typename S, typename T> static S *style_creator(LAMMPS *lmp)
{
return new T(lmp);
}
// [...]
pair_map = new PairCreatorMap();
#define PAIR_CLASS
#define PairStyle(key, Class) (*pair_map)[#key] = &style_creator<Pair, Class>;
#include "style_pair.h"
#undef PairStyle
#undef PAIR_CLASS
// from pair_lj_cut.h
#ifdef PAIR_CLASS
PairStyle(lj/cut,PairLJCut);
#else
// [...]
Similar code constructs are present in other files like ``modify.cpp`` and
``modify.h`` or ``neighbor.cpp`` and ``neighbor.h``. Those contain
similar macros and include ``style_*.h`` files for creating class instances
of styles they manage.
I/O and output formatting
^^^^^^^^^^^^^^^^^^^^^^^^^
C-style stdio versus C++ style iostreams
========================================
LAMMPS uses the "stdio" library of the standard C library for reading
from and writing to files and console instead of C++ "iostreams".
This is mainly motivated by better performance, better control over
formatting, and less effort to achieve specific formatting.
Since mixing "stdio" and "iostreams" can lead to unexpected
behavior. use of the latter is strongly discouraged. Also output to
the screen should not use the predefined ``stdout`` FILE pointer, but
rather the ``screen`` and ``logfile`` FILE pointers managed by the
LAMMPS class. Furthermore, output should generally only be done by
MPI rank 0 (``comm->me == 0``). Output that is sent to both
``screen`` and ``logfile`` should use the :cpp:func:`utils::logmesg()
convenience function <LAMMPS_NS::utils::logmesg>`.
We also discourage the use of stringstreams because the bundled {fmt}
library and the customized tokenizer classes can provide the same
functionality in a cleaner way with better performance. This also
helps maintain a consistent programming syntax with code from many
different contributors.
Formatting with the {fmt} library
===================================
The LAMMPS source code includes a copy of the `{fmt} library
<https://fmt.dev>`_ which is preferred over formatting with the
"printf()" family of functions. The primary reason is that it allows
a typesafe default format for any type of supported data. This is
particularly useful for formatting integers of a given size (32-bit or
64-bit) which may require different format strings depending on
compile time settings or compilers/operating systems. Furthermore,
{fmt} gives better performance, has more functionality, a familiar
formatting syntax that has similarities to ``format()`` in Python, and
provides a facility that can be used to integrate format strings and a
variable number of arguments into custom functions in a much simpler
way than the varargs mechanism of the C library. Finally, {fmt} has
been included into the C++20 language standard, so changes to adopt it
are future-proof.
Formatted strings are frequently created by calling the
``fmt::format()`` function which will return a string as a
``std::string`` class instance. In contrast to the ``%`` placeholder
in ``printf()``, the {fmt} library uses ``{}`` to embed format
descriptors. In the simplest case, no additional characters are
needed as {fmt} will choose the default format based on the data type
of the argument. Otherwise the ``fmt::print()`` function may be
used instead of ``printf()`` or ``fprintf()``. In addition, several
LAMMPS output functions, that originally accepted a single string as
argument have been overloaded to accept a format string with optional
arguments as well (e.g., ``Error::all()``, ``Error::one()``,
``utils::logmesg()``).
Summary of the {fmt} format syntax
==================================
The syntax of the format string is "{[<argument id>][:<format spec>]}",
where either the argument id or the format spec (separated by a colon
':') is optional. The argument id is usually a number starting from 0
that is the index to the arguments following the format string. By
default these are assigned in order (i.e. 0, 1, 2, 3, 4 etc.). The most
common case for using argument id would be to use the same argument in
multiple places in the format string without having to provide it as an
argument multiple times. In LAMMPS the argument id is rarely used.
More common is the use of a format specifier, which starts with a colon.
This may optionally be followed by a fill character (default is ' '). If
provided, the fill character **must** be followed by an alignment
character ('<', '^', '>' for left, centered, or right alignment
(default)). The alignment character may be used without a fill
character. The next important format parameter would be the minimum
width, which may be followed by a dot '.' and a precision for floating
point numbers. The final character in the format string would be an
indicator for the "presentation", i.e. 'd' for decimal presentation of
integers, 'x' for hexadecimal, 'o' for octal, 'c' for character etc.
This mostly follows the "printf()" scheme but without requiring an
additional length parameter to distinguish between different integer
widths. The {fmt} library will detect those and adapt the formatting
accordingly. For floating point numbers there are correspondingly, 'g'
for generic presentation, 'e' for exponential presentation, and 'f' for
fixed point presentation.
Thus "{:8}" would represent *any* type argument using at least 8
characters; "{:<8}" would do this as left aligned, "{:^8}" as centered,
"{:>8}" as right aligned. If a specific presentation is selected, the
argument type must be compatible or else the {fmt} formatting code will
throw an exception. Some format string examples are given below:
.. code-block:: C
auto mesg = fmt::format(" CPU time: {:4d}:{:02d}:{:02d}\n", cpuh, cpum, cpus);
mesg = fmt::format("{:<8s}| {:<10.5g} | {:<10.5g} | {:<10.5g} |{:6.1f} |{:6.2f}\n",
label, time_min, time, time_max, time_sq, tmp);
utils::logmesg(lmp,"{:>6} = max # of 1-2 neighbors\n",maxall);
utils::logmesg(lmp,"Lattice spacing in x,y,z = {:.8} {:.8} {:.8}\n",
xlattice,ylattice,zlattice);
which will create the following output lines:
.. parsed-literal::
CPU time: 0:02:16
Pair | 2.0133 | 2.0133 | 2.0133 | 0.0 | 84.21
4 = max # of 1-2 neighbors
Lattice spacing in x,y,z = 1.6795962 1.6795962 1.6795962
Finally, a special feature of the {fmt} library is that format
parameters like the width or the precision may be also provided as
arguments. In that case a nested format is used where a pair of curly
braces (with an optional argument id) "{}" are used instead of the
value, for example "{:{}d}" will consume two integer arguments, the
first will be the value shown and the second the minimum width.
For more details and examples, please consult the `{fmt} syntax
documentation <https://fmt.dev/latest/syntax.html>`_ website.
Memory management
^^^^^^^^^^^^^^^^^
Dynamical allocation of small data and objects can be done with the
the C++ commands "new" and "delete/delete[]. Large data should use
the member functions of the ``Memory`` class, most commonly,
``Memory::create()``, ``Memory::grow()``, and ``Memory::destroy()``,
which provide variants for vectors, 2d arrays, 3d arrays, etc.
These can also be used for small data.
The use of ``malloc()``, ``calloc()``, ``realloc()`` and ``free()``
directly is strongly discouraged. To simplify adapting legacy code
into the LAMMPS code base the member functions ``Memory::smalloc()``,
``Memory::srealloc()``, and ``Memory::sfree()`` are available, which
perform additional error checks for safety.
Use of these custom memory allocation functions is motivated by the
following considerations:
- memory allocation failures on *any* MPI rank during a parallel run
will trigger an immediate abort of the entire parallel calculation
instead of stalling it
- a failing "new" will trigger an exception which is also captured by
LAMMPS and triggers a global abort
- allocation of multi-dimensional arrays will be done in a C compatible
fashion but so that the storage of the actual data is stored in one
large contiguous block. Thus when MPI communication is needed,
the data can be communicated directly (similar to Fortran arrays).
- the "destroy()" and "sfree()" functions may safely be called on NULL
pointers
- the "destroy()" functions will nullify the pointer variables making
"use after free" errors easy to detect
- it is possible to use a larger than default memory alignment (not on
all operating systems, since the allocated storage pointers must be
compatible with ``free()`` for technical reasons)
In the practical implementation of code this means that any pointer
variables that are class members should be initialized to a
``nullptr`` value in their respective constructors. That way it is
safe to call ``Memory::destroy()`` or ``delete[]`` on them before
*any* allocation outside the constructor. This helps prevent memory
leaks.

235
doc/src/Developer_comm_ops.rst Normal file
View File

@ -0,0 +1,235 @@
Communication patterns
----------------------
This page describes various inter-processor communication operations
provided by LAMMPS, mostly in the core *Comm* class. These are operations
for common tasks implemented using MPI library calls. They are used by
other classes to perform communication of different kinds. These
operations are useful to know about when writing new code for LAMMPS
that needs to communicate data between processors.
Owned and ghost atoms
^^^^^^^^^^^^^^^^^^^^^
As described on the :doc:`parallel partitioning algorithms
<Developer_par_part>` page, LAMMPS spatially decomposes the simulation
domain, either in a *brick* or *tiled* manner. Each processor (MPI
task) owns atoms within its sub-domain and additionally stores ghost
atoms within a cutoff distance of its sub-domain.
Forward and reverse communication
=================================
As described on the :doc:`parallel communication algorithms
<Developer_par_comm>` page, the most common communication operations are
first, *forward communication* which sends owned atom information from
each processor to nearby processors to store with their ghost atoms.
The need to do this communication arises when data from the owned atoms
is updated (e.g. their positions) and this updated information needs to
be **copied** to the corresponding ghost atoms.
And second, *reverse communication* which sends ghost atom information
from each processor to the owning processor to **accumulate** (sum)
the values with the corresponding owned atoms. The need for this
arises when data is computed and also stored with ghost atoms
(e.g. forces when using a "half" neighbor list) and thus those terms
need to be added to their corresponding atoms on the process where
they are "owned" atoms. Please note, that with the :doc:`newton off
<newton>` setting this does not happen and the neighbor lists are
constructed so that these interactions are computed on both MPI
processes containing one of the atoms and only the data pertaining to
the local atom is stored.
The time-integration classes in LAMMPS invoke these operations each
timestep via the *forward_comm()* and *reverse_comm()* methods in the
*Comm* class. Which per-atom data is communicated depends on the
currently used :doc:`atom style <atom_style>` and whether
:doc:`comm_modify vel <comm_modify>` setting is "no" (default) or
"yes".
Similarly, *Pair* style classes can invoke the *forward_comm(this)*
and *reverse_comm(this)* methods in the *Comm* class to perform the
same operations on per-atom data that is generated and stored within
the pair style class. Note that this function requires passing the
``this`` pointer as the first argument to enable the *Comm* class to
call the "pack" and "unpack" functions discussed below. An example of
the use of these functions are many-body pair styles like the
embedded-atom method (EAM) which compute intermediate values in the
first part of the compute() function that need to be stored by both
owned and ghost atoms for the second part of the force computation.
The *Comm* class methods perform the MPI communication for buffers of
per-atom data. They "call back" to the *Pair* class so it can *pack*
or *unpack* the buffer with data the *Pair* class owns. There are 4
such methods that the *Pair* class must define, assuming it uses both
forward and reverse communication:
* pack_forward_comm()
* unpack_forward_comm()
* pack_reverse_comm()
* unpack_reverse_comm()
The arguments to these methods include the buffer and a list of atoms
to pack or unpack. The *Pair* class also must set the *comm_forward*
and *comm_reverse* variables which store the number of values stored
in the communication buffers for each operation. This means, if
desired, it can choose to store multiple per-atom values in the
buffer, and they will be communicated together to minimize
communication overhead. The communication buffers are defined vectors
containing ``double`` values. To correctly store integers that may be
64-bit (bigint, tagint, imageint) in the buffer, you need to use the
`ubuf union <Communication buffer coding with ubuf>`_ construct.
The *Fix*, *Compute*, and *Dump* classes can also invoke the same kind
of forward and reverse communication operations using the same *Comm*
class methods. Likewise the same pack/unpack methods and
comm_forward/comm_reverse variables must be defined by the calling
*Fix*, *Compute*, or *Dump* class.
For *Fix* classes there is an optional second argument to the
*forward_comm()* and *reverse_comm()* call which can be used when the
fix performs multiple modes of communication, with different numbers
of values per atom. The fix should set the *comm_forward* and
*comm_reverse* variables to the maximum value, but can invoke the
communication for a particular mode with a smaller value. For this
to work, the *pack_forward_comm()*, etc methods typically use a class
member variable to choose which values to pack/unpack into/from the
buffer.
Finally, for reverse communications in *Fix* classes there is also the
*reverse_comm_variable()* method that allows the communication to have
a different amount of data per-atom. It invokes these corresponding
callback methods:
* pack_reverse_comm_size()
* unpack_reverse_comm_size()
which have extra arguments to specify the amount of data stored
in the buffer for each atom.
Higher level communication
^^^^^^^^^^^^^^^^^^^^^^^^^^
There are also several higher-level communication operations provided
in LAMMPS which work for either *brick* or *tiled* decompositions.
They may be useful for a new class to invoke if it requires more
sophisticated communication than the *forward* and *reverse* methods
provide. The 3 communication operations described here are
* ring
* irregular
* rendezvous
You can invoke these *grep* command in the LAMMPS src directory, to
see a list of classes that invoke the 3 operations.
* ``grep "\->ring" *.cpp */*.cpp``
* ``grep "irregular\->" *.cpp``
* ``grep "\->rendezvous" *.cpp */*.cpp``
Ring operation
==============
The *ring* operation is invoked via the *ring()* method in the *Comm*
class.
Each processor first creates a buffer with a list of values, typically
associated with a subset of the atoms it owns. Now think of the *P*
processors as connected to each other in a *ring*. Each processor *M*
sends data to the next *M+1* processor. It receives data from the
preceding *M-1* processor. The ring is periodic so that the last
processor sends to the first processor, and the first processor
receives from the last processor.
Invoking the *ring()* method passes each processor's buffer in *P*
steps around the ring. At each step a *callback* method, provided as
an argument to ring(), in the caller is invoked. This allows each
processor to examine the data buffer provided by every other
processor. It may extract values needed by its atoms from the
buffers, or it may alter placeholder values in the buffer. In the
latter case, when the *ring* operation is complete, each processor can
examine its original buffer to extract modified values.
Note that the *ring* operation is similar to an MPI_Alltoall()
operation where every processor effectively sends and receives data to
every other processor. The difference is that the *ring* operation
does it one step at a time, so the total volume of data does not need
to be stored by every processor. However, the *ring* operation is
also less efficient than MPI_Alltoall() because of the *P* stages
required. So it is typically only suitable for small data buffers and
occasional operations that are not time-critical.
Irregular operation
===================
The *irregular* operation is provided by the *Irregular* class. What
LAMMPS terms irregular communication is when each processor knows what
data it needs to send to what processor, but does not know what
processors are sending it data. An example is when load-balancing is
performed and each processor needs to send some of its atoms to new
processors.
The *Irregular* class provides 5 high-level methods useful in this
context:
* create_data()
* exchange_data()
* create_atom()
* exchange_atom()
* migrate_atoms()
For the *create_data()* method, each processor specifies a list of *N*
datums to send, each to a specified processor. Internally, the method
creates efficient data structures for performing the communication.
The *exchange_data()* method triggers the communication to be
performed. Each processor provides the vector of *N* datums to send,
and the size of each datum. All datums must be the same size.
The *create_atom()* and *exchange_atom()* methods are similar except
that the size of each datum can be different. Typically this is used
to communicate atoms, each with a variable amount of per-atom data, to
other processors.
The *migrate_atoms()* method is a convenience wrapper on the
*create_atom()* and *exchange_atom()* methods to simplify
communication of all the per-atom data associated with an atom so that
the atom can effectively migrate to a new owning processor. It is
similar to the *exchange()* method in the *Comm* class invoked when
atoms move to neighboring processors (in the regular or tiled
decomposition) during timestepping, except that it allows atoms to
have moved arbitrarily long distances and still be properly
communicated to a new owning processor.
Rendezvous operation
====================
Finally, the *rendezvous* operation is invoked via the *rendezvous()*
method in the *Comm* class. Depending on how much communication is
needed and how many processors a LAMMPS simulation is running on, it
can be a much more efficient choice than the *ring()* method. It uses
the *irregular* operation internally once or twice to do its
communication. The rendezvous algorithm is described in detail in
:ref:`(Plimpton) <Plimpton>`, including some LAMMPS use cases.
For the *rendezvous()* method, each processor specifies a list of *N*
datums to send and which processor to send each of them to.
Internally, this communication is performed as an irregular operation.
The received datums are returned to the caller via invocation of
*callback* function, provided as an argument to *rendezvous()*. The
caller can then process the received datums and (optionally) assemble
a new list of datums to communicate to a new list of specific
processors. When the callback function exits, the *rendezvous()*
method performs a second irregular communication on the new list of
datums.
Examples in LAMMPS of use of the *rendezvous* operation are the
:doc:`fix rigid/small <fix_rigid>` and :doc:`fix shake
<fix_shake>` commands (for one-time identification of the rigid body
atom clusters) and the identification of special_bond 1-2, 1-3 and 1-4
neighbors within molecules. See the :doc:`special_bonds <special_bonds>`
command for context.
----------
.. _Plimpton:
**(Plimpton)** Plimpton and Knight, JPDC, 147, 184-195 (2021).

58
doc/src/Developer_notes.rst
View File

@ -7,6 +7,64 @@ typically document what a variable stores, what a small section of
code does, or what a function does and its input/outputs. The topics
on this page are intended to document code functionality at a higher level.
Reading and parsing of text and text files
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
It is frequently required for a class in LAMMPS to read in additional
data from a file, e.g. potential parameters from a potential file for
manybody potentials. LAMMPS provides several custom classes and
convenience functions to simplify the process. They offer the
following benefits:
- better code reuse and fewer lines of code needed to implement reading
and parsing data from a file
- better detection of format errors, incompatible data, and better error messages
- exit with an error message instead of silently converting only part of the
text to a number or returning a 0 on unrecognized text and thus reading incorrect values
- re-entrant code through avoiding global static variables (as used by ``strtok()``)
- transparent support for translating unsupported UTF-8 characters to their ASCII equivalents
(the text-to-value conversion functions **only** accept ASCII characters)
In most cases (e.g. potential files) the same data is needed on all
MPI ranks. Then it is best to do the reading and parsing only on MPI
rank 0, and communicate the data later with one or more
``MPI_Bcast()`` calls. For reading generic text and potential
parameter files the custom classes :cpp:class:`TextFileReader
<LAMMPS_NS::TextFileReader>` and :cpp:class:`PotentialFileReader
<LAMMPS_NS::PotentialFileReader>` are available. They allow reading
the file as individual lines for which they can return a tokenizer
class (see below) for parsing the line. Or they can return blocks of
numbers as a vector directly. The documentation on `File reader
classes <file-reader-classes>`_ contains an example for a typical
case.
When reading per-atom data, the data on each line of the file usually
needs to include an atom ID so it can be associated with a particular
atom. In that case the data can be read in multi-line chunks and
broadcast to all MPI ranks with
:cpp:func:`utils::read_lines_from_file()
<LAMMPS_NS::utils::read_lines_from_file>`. Those chunks are then
split into lines, parsed, and applied only to atoms the MPI rank
"owns".
For splitting a string (incrementally) into words and optionally
converting those to numbers, the :cpp:class:`Tokenizer
<LAMMPS_NS::Tokenizer>` and :cpp:class:`ValueTokenizer
<LAMMPS_NS::ValueTokenizer>` can be used. Those provide a superset of
the functionality of ``strtok()`` from the C-library and the latter
also includes conversion to different types. Any errors while
processing the string in those classes will result in an exception,
which can be caught and the error processed as needed. Unlike the
C-library functions ``atoi()``, ``atof()``, ``strtol()``, or
``strtod()`` the conversion will check if the converted text is a
valid integer or floating point number and will not silently return an
unexpected or incorrect value. For example, ``atoi()`` will return 12
when converting "12.5", while the ValueTokenizer class will throw an
:cpp:class:`InvalidIntegerException
<LAMMPS_NS::InvalidIntegerException>` if
:cpp:func:`ValueTokenizer::next_int()
<LAMMPS_NS::ValueTokenizer::next_int>` is called on the same string.
Fix contributions to instantaneous energy, virial, and cumulative energy
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

2
doc/src/Developer_org.rst
View File

@ -225,7 +225,7 @@ follows:
commands in an input script.
- The Force class computes various forces between atoms. The Pair
parent class is for non-bonded or pair-wise forces, which in LAMMPS
parent class is for non-bonded or pairwise forces, which in LAMMPS
also includes many-body forces such as the Tersoff 3-body potential if
those are computed by walking pairwise neighbor lists. The Bond,
Angle, Dihedral, Improper parent classes are styles for bonded

70
doc/src/Developer_utils.rst
View File

@ -21,18 +21,21 @@ In that case, the functions will stop with an error message, indicating
the name of the problematic file, if possible unless the *error* argument
is a NULL pointer.
The :cpp:func:`fgets_trunc` function will work similar for ``fgets()``
but it will read in a whole line (i.e. until the end of line or end
of file), but store only as many characters as will fit into the buffer
including a final newline character and the terminating NULL byte.
If the line in the file is longer it will thus be truncated in the buffer.
This function is used by :cpp:func:`read_lines_from_file` to read individual
lines but make certain they follow the size constraints.
The :cpp:func:`utils::fgets_trunc() <LAMMPS_NS::utils::fgets_trunc>`
function will work similar for ``fgets()`` but it will read in a whole
line (i.e. until the end of line or end of file), but store only as many
characters as will fit into the buffer including a final newline
character and the terminating NULL byte. If the line in the file is
longer it will thus be truncated in the buffer. This function is used
by :cpp:func:`utils::read_lines_from_file()
<LAMMPS_NS::utils::read_lines_from_file>` to read individual lines but
make certain they follow the size constraints.
The :cpp:func:`read_lines_from_file` function will read the requested
number of lines of a maximum length into a buffer and will return 0
if successful or 1 if not. It also guarantees that all lines are
terminated with a newline character and the entire buffer with a
The :cpp:func:`utils::read_lines_from_file()
<LAMMPS_NS::utils::read_lines_from_file>` function will read the
requested number of lines of a maximum length into a buffer and will
return 0 if successful or 1 if not. It also guarantees that all lines
are terminated with a newline character and the entire buffer with a
NULL character.
----------
@ -62,7 +65,7 @@ silently returning the result of a partial conversion or zero in cases
where the string is not a valid number. This behavior improves
detecting typos or issues when processing input files.
Similarly the :cpp:func:`logical() <LAMMPS_NS::utils::logical>` function
Similarly the :cpp:func:`utils::logical() <LAMMPS_NS::utils::logical>` function
will convert a string into a boolean and will only accept certain words.
The *do_abort* flag should be set to ``true`` in case this function
@ -70,8 +73,8 @@ is called only on a single MPI rank, as that will then trigger the
a call to ``Error::one()`` for errors instead of ``Error::all()``
and avoids a "hanging" calculation when run in parallel.
Please also see :cpp:func:`is_integer() <LAMMPS_NS::utils::is_integer>`
and :cpp:func:`is_double() <LAMMPS_NS::utils::is_double>` for testing
Please also see :cpp:func:`utils::is_integer() <LAMMPS_NS::utils::is_integer>`
and :cpp:func:`utils::is_double() <LAMMPS_NS::utils::is_double>` for testing
strings for compliance without conversion.
----------
@ -205,6 +208,9 @@ Convenience functions
.. doxygenfunction:: logmesg(LAMMPS *lmp, const std::string &mesg)
:project: progguide
.. doxygenfunction:: flush_buffers(LAMMPS *lmp)
:project: progguide
.. doxygenfunction:: getsyserror
:project: progguide
@ -337,11 +343,11 @@ This code example should produce the following output:
.. doxygenclass:: LAMMPS_NS::InvalidIntegerException
:project: progguide
:members: what
:members:
.. doxygenclass:: LAMMPS_NS::InvalidFloatException
:project: progguide
:members: what
:members:
----------
@ -390,21 +396,26 @@ A typical code segment would look like this:
----------
.. file-reader-classes:
File reader classes
-------------------
The purpose of the file reader classes is to simplify the recurring task
of reading and parsing files. They can use the
:cpp:class:`LAMMPS_NS::ValueTokenizer` class to process the read in
text. The :cpp:class:`LAMMPS_NS::TextFileReader` is a more general
version while :cpp:class:`LAMMPS_NS::PotentialFileReader` is specialized
to implement the behavior expected for looking up and reading/parsing
files with potential parameters in LAMMPS. The potential file reader
class requires a LAMMPS instance, requires to be run on MPI rank 0 only,
will use the :cpp:func:`LAMMPS_NS::utils::get_potential_file_path`
function to look up and open the file, and will call the
:cpp:class:`LAMMPS_NS::Error` class in case of failures to read or to
convert numbers, so that LAMMPS will be aborted.
:cpp:class:`ValueTokenizer <LAMMPS_NS::ValueTokenizer>` class to process
the read in text. The :cpp:class:`TextFileReader
<LAMMPS_NS::TextFileReader>` is a more general version while
:cpp:class:`PotentialFileReader <LAMMPS_NS::PotentialFileReader>` is
specialized to implement the behavior expected for looking up and
reading/parsing files with potential parameters in LAMMPS. The
potential file reader class requires a LAMMPS instance, requires to be
run on MPI rank 0 only, will use the
:cpp:func:`utils::get_potential_file_path
<LAMMPS_NS::utils::get_potential_file_path>` function to look up and
open the file, and will call the :cpp:class:`LAMMPS_NS::Error` class in
case of failures to read or to convert numbers, so that LAMMPS will be
aborted.
.. code-block:: C++
:caption: Use of PotentialFileReader class in pair style coul/streitz
@ -479,10 +490,10 @@ provided, as that is used to determine whether a new page of memory
must be used.
The :cpp:class:`MyPage <LAMMPS_NS::MyPage>` class offers two ways to
reserve a chunk: 1) with :cpp:func:`get() <LAMMPS_NS::MyPage::get>` the
chunk size needs to be known in advance, 2) with :cpp:func:`vget()
reserve a chunk: 1) with :cpp:func:`MyPage::get() <LAMMPS_NS::MyPage::get>` the
chunk size needs to be known in advance, 2) with :cpp:func:`MyPage::vget()
<LAMMPS_NS::MyPage::vget>` a pointer to the next chunk is returned, but
its size is registered later with :cpp:func:`vgot()
its size is registered later with :cpp:func:`MyPage::vgot()
<LAMMPS_NS::MyPage::vgot>`.
.. code-block:: C++
@ -585,4 +596,3 @@ the communication buffers.
.. doxygenunion:: LAMMPS_NS::ubuf
:project: progguide

7
doc/src/Errors_messages.rst
View File

@ -1941,6 +1941,9 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
*Compute ID for fix numdiff does not exist*
Self-explanatory.
*Compute ID for fix numdiff/virial does not exist*
Self-explanatory.
*Compute ID for fix store/state does not exist*
Self-explanatory.
@ -3796,6 +3799,10 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
Self-explanatory. Efficient loop over all atoms for numerical
difference requires consecutive atom IDs.
*Fix numdiff/virial must use group all*
Virial contributions computed by this fix are
computed on all atoms.
*Fix nve/asphere requires extended particles*
This fix can only be used for particles with a shape setting.

2
doc/src/Errors_warnings.rst
View File

@ -416,7 +416,7 @@ This will most likely cause errors in kinetic fluctuations.
not defined for the specified atom style.
*Molecule has bond topology but no special bond settings*
This means the bonded atoms will not be excluded in pair-wise
This means the bonded atoms will not be excluded in pairwise
interactions.
*Molecule template for create_atoms has multiple molecules*

2
doc/src/Howto_pylammps.rst
View File

@ -545,6 +545,6 @@ Feedback and Contributing
-------------------------
If you find this Python interface useful, please feel free to provide feedback
and ideas on how to improve it to Richard Berger (richard.berger@temple.edu). We also
and ideas on how to improve it to Richard Berger (richard.berger@outlook.com). We also
want to encourage people to write tutorial style IPython notebooks showcasing LAMMPS usage
and maybe their latest research results.

2
doc/src/Intro_authors.rst
View File

@ -8,7 +8,7 @@ University:
* Aidan Thompson, athomps at sandia.gov
* Stan Moore, stamoor at sandia.gov
* Axel Kohlmeyer, akohlmey at gmail.com
* Richard Berger, richard.berger at temple.edu
* Richard Berger, richard.berger at outlook.com
.. _sjp: http://www.cs.sandia.gov/~sjplimp
.. _lws: https://www.lammps.org

6
doc/src/Library_utility.rst
View File

@ -13,6 +13,7 @@ functions. They do not directly call the LAMMPS library.
- :cpp:func:`lammps_fix_external_set_virial_peratom`
- :cpp:func:`lammps_fix_external_set_vector_length`
- :cpp:func:`lammps_fix_external_set_vector`
- :cpp:func:`lammps_flush_buffers`
- :cpp:func:`lammps_free`
- :cpp:func:`lammps_is_running`
- :cpp:func:`lammps_force_timeout`
@ -72,6 +73,11 @@ where such memory buffers were allocated that require the use of
-----------------------
.. doxygenfunction:: lammps_flush_buffers
:project: progguide
-----------------------
.. doxygenfunction:: lammps_free
:project: progguide

17
doc/src/Modify.rst
View File

@ -1,16 +1,17 @@
Modifying & extending LAMMPS
****************************
LAMMPS is designed in a modular fashion so as to be easy to modify and
LAMMPS is designed in a modular fashion and to be easy to modify or
extend with new functionality. In fact, about 95% of its source code
is add-on files. These doc pages give basic instructions on how to do
this.
are optional. The following pages give basic instructions on what
is required when adding new styles of different kinds to LAMMPS.
If you add a new feature to LAMMPS and think it will be of interest to
general users, we encourage you to submit it for inclusion in LAMMPS
as a pull request on our `GitHub site <https://github.com/lammps/lammps>`_,
after reading about :doc:`how to prepare your code for submission <Modify_contribute>`
and :doc:`the style requirements and recommendations <Modify_style>`.
If you add a new feature to LAMMPS and think it will be of general
interest to other users, we encourage you to submit it for inclusion in
LAMMPS as a pull request on our `GitHub site
<https://github.com/lammps/lammps>`_, after reading about :doc:`how to
prepare your code for submission <Modify_contribute>` and :doc:`the
style requirements and recommendations <Modify_style>`.
.. toctree::
:maxdepth: 1

15
doc/src/Modify_overview.rst
View File

@ -1,13 +1,14 @@
Overview
========
The best way to add a new feature to LAMMPS is to find a similar
feature and look at the corresponding source and header files to figure
out what it does. You will need some knowledge of C++ to be able to
understand the high-level structure of LAMMPS and its class
organization, but functions (class methods) that do actual
computations are written in vanilla C-style code and operate on simple
C-style data structures (vectors and arrays).
The best way to add a new feature to LAMMPS is to find a similar feature
and look at the corresponding source and header files to figure out what
it does. You will need some knowledge of C++ to be able to understand
the high-level structure of LAMMPS and its class organization, but
functions (class methods) that do actual computations are mostly written
in C-style code and operate on simple C-style data structures (vectors
and arrays). A high-level overview of the programming style choices in
LAMMPS is :doc:`given elsewhere <Developer_code_design>`.
Most of the new features described on the :doc:`Modify <Modify>` doc
page require you to write a new C++ derived class (except for exceptions

51
doc/src/Modify_style.rst
View File

@ -250,9 +250,11 @@ keep the code readable to programmers that have limited C++ programming
experience. C++ constructs are acceptable when they help improving the
readability and reliability of the code, e.g. when using the
`std::string` class instead of manipulating pointers and calling the
string functions of the C library. In addition and number of convenient
:doc:`utility functions and classes <Developer_utils>` for recurring
tasks are provided.
string functions of the C library. In addition a collection of
convenient :doc:`utility functions and classes <Developer_utils>` for
recurring tasks and a collection of
:doc:`platform neutral functions <Developer_platform>` for improved
portability are provided.
Included Fortran code has to be compatible with the Fortran 2003
standard. Python code must be compatible with Python 3.5. Large parts
@ -261,10 +263,11 @@ compatible with Python 2.7. Compatibility with Python 2.7 is
desirable, but compatibility with Python 3.5 is **required**.
Compatibility with these older programming language standards is very
important to maintain portability, especially with HPC cluster
environments, which tend to be running older software stacks and LAMMPS
users may be required to use those older tools or not have the option to
install newer compilers.
important to maintain portability and availability of LAMMPS on many
platforms. This applies especially to HPC cluster environments, which
tend to be running older software stacks and LAMMPS users may be
required to use those older tools for access to advanced hardware
features or not have the option to install newer compilers or libraries.
Programming conventions (varied)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@ -305,6 +308,40 @@ you are uncertain, please ask.
FILE pointers and only be done on MPI rank 0. Use the :cpp:func:`utils::logmesg`
convenience function where possible.
- Usage of C++11 `virtual`, `override`, `final` keywords: Please follow the
`C++ Core Guideline C.128 <https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rh-override>`_.
That means, you should only use `virtual` to declare a new virtual
function, `override` to indicate you are overriding an existing virtual
function, and `final` to prevent any further overriding.
- Trivial destructors: Prefer not writing destructors when they are empty and `default`.
.. code-block:: c++
// don't write destructors for A or B like this
class A : protected Pointers {
public:
A();
~A() override {}
};
class B : protected Pointers {
public:
B();
~B() override = default;
};
// instead, let the compiler create the implicit default destructor by not writing it
class A : protected Pointers {
public:
A();
};
class B : protected Pointers {
public:
B();
};
- Header files, especially those defining a "style", should only use
the absolute minimum number of include files and **must not** contain
any ``using`` statements. Typically that would be only the header for

118
doc/src/Python_install.rst
View File

@ -25,11 +25,10 @@ Installing the LAMMPS Python Module and Shared Library
======================================================
Making LAMMPS usable within Python and vice versa requires putting the
LAMMPS Python package (``lammps``) into a location where the
Python interpreter can find it and installing the LAMMPS shared library
into a folder that the dynamic loader searches or inside of the installed
``lammps`` package folder. There are multiple ways to achieve
this.
LAMMPS Python package (``lammps``) into a location where the Python
interpreter can find it and installing the LAMMPS shared library into a
folder that the dynamic loader searches or inside of the installed
``lammps`` package folder. There are multiple ways to achieve this.
#. Do a full LAMMPS installation of libraries, executables, selected
headers, documentation (if enabled), and supporting files (only
@ -159,38 +158,52 @@ this.
make install-python
This will try to install (only) the shared library and the Python
package into a system folder and if that fails (due to missing
write permissions) will instead do the installation to a user
folder under ``$HOME/.local``. For a system-wide installation you
This will try to build a so-called (binary) 'wheel', a compressed
binary python package and then install it with the python package
manager 'pip'. Installation will be attempted into a system-wide
``site-packages`` folder and if that fails into the corresponding
folder in the user's home directory. For a system-wide installation you
would have to gain superuser privilege, e.g. though ``sudo``
+------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
| File | Location | Notes |
+========================+=================================================================+=============================================================+
| LAMMPS Python package | * ``$HOME/.local/lib/pythonX.Y/site-packages/lammps`` (32bit) | ``X.Y`` depends on the installed Python version |
| | * ``$HOME/.local/lib64/pythonX.Y/site-packages/lammps`` (64bit) | |
+------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
| LAMMPS shared library | * ``$HOME/.local/lib/pythonX.Y/site-packages/lammps`` (32bit) | ``X.Y`` depends on the installed Python version |
| | * ``$HOME/.local/lib64/pythonX.Y/site-packages/lammps`` (64bit) | |
+------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
+------------------------+----------------------------------------------------------+-------------------------------------------------------------+
| File | Location | Notes |
+========================+==========================================================+=============================================================+
| LAMMPS Python package | * ``$HOME/.local/lib/pythonX.Y/site-packages/lammps`` | ``X.Y`` depends on the installed Python version |
+------------------------+----------------------------------------------------------+-------------------------------------------------------------+
| LAMMPS shared library | * ``$HOME/.local/lib/pythonX.Y/site-packages/lammps`` | ``X.Y`` depends on the installed Python version |
+------------------------+----------------------------------------------------------+-------------------------------------------------------------+
For a system-wide installation those folders would then become.
+------------------------+---------------------------------------------------------+-------------------------------------------------------------+
| File | Location | Notes |
+========================+=========================================================+=============================================================+
| LAMMPS Python package | * ``/usr/lib/pythonX.Y/site-packages/lammps`` (32bit) | ``X.Y`` depends on the installed Python version |
| | * ``/usr/lib64/pythonX.Y/site-packages/lammps`` (64bit) | |
+------------------------+---------------------------------------------------------+-------------------------------------------------------------+
| LAMMPS shared library | * ``/usr/lib/pythonX.Y/site-packages/lammps`` (32bit) | ``X.Y`` depends on the installed Python version |
| | * ``/usr/lib64/pythonX.Y/site-packages/lammps`` (64bit) | |
+------------------------+---------------------------------------------------------+-------------------------------------------------------------+
+------------------------+-------------------------------------------------+-------------------------------------------------------------+
| File | Location | Notes |
+========================+=================================================+=============================================================+
| LAMMPS Python package | * ``/usr/lib/pythonX.Y/site-packages/lammps`` | ``X.Y`` depends on the installed Python version |
+------------------------+-------------------------------------------------+-------------------------------------------------------------+
| LAMMPS shared library | * ``/usr/lib/pythonX.Y/site-packages/lammps`` | ``X.Y`` depends on the installed Python version |
+------------------------+-------------------------------------------------+-------------------------------------------------------------+
No environment variables need to be set for those, as those
folders are searched by default by Python or the LAMMPS Python
package.
.. versionchanged:: TBD
.. note::
If there is an existing installation of the LAMMPS python
module, ``make install-python`` will try to update it.
However, that will fail if the older version of the module
was installed by LAMMPS versions until 17Feb2022. Those
were using the distutils package, which does not create a
"manifest" that allows a clean uninstall. The ``make
install-python`` command will always produce a
lammps-<version>-<python>-<abi>-<os>-<arch>.whl file (the
'wheel'). And this file can be later installed directly with
``python -m pip install <wheel file>.whl`` without having to
type ``make install-python`` again and repeating the build
step, too.
For the traditional make process you can override the python
version to version x.y when calling ``make`` with
``PYTHON=pythonX.Y``. For a CMake based compilation this choice
@ -201,16 +214,12 @@ this.
.. code-block:: bash
$ python install.py -p <python package> -l <shared library> -v <version.h file> [-d <pydir>]
$ python install.py -p <python package> -l <shared library> [-n]
* The ``-p`` flag points to the ``lammps`` Python package folder to be installed,
* the ``-l`` flag points to the LAMMPS shared library file to be installed,
* the ``-v`` flag points to the ``version.h`` file in the LAMMPS source
* and the optional ``-d`` flag to a custom (legacy) installation folder
If you use a legacy installation folder, you will need to set your
``PYTHONPATH`` and ``LD_LIBRARY_PATH`` (and/or ``DYLD_LIBRARY_PATH``) environment
variables accordingly as explained in the description for "In place use".
* and the optional ``-n`` instructs the script to only build a wheel file
but not attempt to install it.
.. tab:: Virtual environment
@ -257,32 +266,29 @@ this.
package and the shared library file are installed into the
following locations:
+------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
| File | Location | Notes |
+========================+=================================================================+=============================================================+
| LAMMPS Python Module | * ``$VIRTUAL_ENV/lib/pythonX.Y/site-packages/lammps`` (32bit) | ``X.Y`` depends on the installed Python version |
| | * ``$VIRTUAL_ENV/lib64/pythonX.Y/site-packages/lammps`` (64bit) | |
+------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
| LAMMPS shared library | * ``$VIRTUAL_ENV/lib/pythonX.Y/site-packages/lammps`` (32bit) | ``X.Y`` depends on the installed Python version |
| | * ``$VIRTUAL_ENV/lib64/pythonX.Y/site-packages/lammps`` (64bit) | |
+------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
+------------------------+--------------------------------------------------------+-------------------------------------------------------------+
| File | Location | Notes |
+========================+========================================================+=============================================================+
| LAMMPS Python Module | * ``$VIRTUAL_ENV/lib/pythonX.Y/site-packages/lammps`` | ``X.Y`` depends on the installed Python version |
+------------------------+--------------------------------------------------------+-------------------------------------------------------------+
| LAMMPS shared library | * ``$VIRTUAL_ENV/lib/pythonX.Y/site-packages/lammps`` | ``X.Y`` depends on the installed Python version |
+------------------------+--------------------------------------------------------+-------------------------------------------------------------+
If you do a full installation (CMake only) with "install", this
leads to the following installation locations:
+------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
| File | Location | Notes |
+========================+=================================================================+=============================================================+
| LAMMPS Python Module | * ``$VIRTUAL_ENV/lib/pythonX.Y/site-packages/lammps`` (32bit) | ``X.Y`` depends on the installed Python version |
| | * ``$VIRTUAL_ENV/lib64/pythonX.Y/site-packages/lammps`` (64bit) | |
+------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
| LAMMPS shared library | * ``$VIRTUAL_ENV/lib/`` (32bit) | Set shared loader environment variable to this path |
| | * ``$VIRTUAL_ENV/lib64/`` (64bit) | (see below for more info on this) |
+------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
| LAMMPS executable | * ``$VIRTUAL_ENV/bin/`` | |
+------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
| LAMMPS potential files | * ``$VIRTUAL_ENV/share/lammps/potentials/`` | Set ``LAMMPS_POTENTIALS`` environment variable to this path |
+------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
+------------------------+--------------------------------------------------------+-------------------------------------------------------------+
| File | Location | Notes |
+========================+========================================================+=============================================================+
| LAMMPS Python Module | * ``$VIRTUAL_ENV/lib/pythonX.Y/site-packages/lammps`` | ``X.Y`` depends on the installed Python version |
+------------------------+--------------------------------------------------------+-------------------------------------------------------------+
| LAMMPS shared library | * ``$VIRTUAL_ENV/lib/`` (32bit) | Set shared loader environment variable to this path |
| | * ``$VIRTUAL_ENV/lib64/`` (64bit) | (see below for more info on this) |
+------------------------+--------------------------------------------------------+-------------------------------------------------------------+
| LAMMPS executable | * ``$VIRTUAL_ENV/bin/`` | |
+------------------------+--------------------------------------------------------+-------------------------------------------------------------+
| LAMMPS potential files | * ``$VIRTUAL_ENV/share/lammps/potentials/`` | Set ``LAMMPS_POTENTIALS`` environment variable to this path |
+------------------------+--------------------------------------------------------+-------------------------------------------------------------+
In that case you need to modify the ``$HOME/myenv/bin/activate``
script in a similar fashion you need to update your

4
doc/src/Run_output.rst
View File

@ -106,7 +106,7 @@ individual ranks. Here is an example output for this section:
----------
The third section above lists the number of owned atoms (Nlocal),
ghost atoms (Nghost), and pair-wise neighbors stored per processor.
ghost atoms (Nghost), and pairwise neighbors stored per processor.
The max and min values give the spread of these values across
processors with a 10-bin histogram showing the distribution. The total
number of histogram counts is equal to the number of processors.
@ -114,7 +114,7 @@ number of histogram counts is equal to the number of processors.
----------
The last section gives aggregate statistics (across all processors)
for pair-wise neighbors and special neighbors that LAMMPS keeps track
for pairwise neighbors and special neighbors that LAMMPS keeps track
of (see the :doc:`special_bonds <special_bonds>` command). The number
of times neighbor lists were rebuilt is tallied, as is the number of
potentially *dangerous* rebuilds. If atom movement triggered neighbor

2
doc/src/Speed_kokkos.rst
View File

@ -214,7 +214,7 @@ threads/task as Nt. The product of these two values should be N, i.e.
The default for the :doc:`package kokkos <package>` command when
running on KNL is to use "half" neighbor lists and set the Newton flag
to "on" for both pairwise and bonded interactions. This will typically
be best for many-body potentials. For simpler pair-wise potentials, it
be best for many-body potentials. For simpler pairwise potentials, it
may be faster to use a "full" neighbor list with Newton flag to "off".
Use the "-pk kokkos" :doc:`command-line switch <Run_options>` to change
the default :doc:`package kokkos <package>` options. See its page for

29
doc/src/Tools.rst
View File

@ -277,17 +277,34 @@ at ens-lyon.fr, alain.dequidt at uca.fr
eam database tool
-----------------------------
The tools/eam_database directory contains a Fortran program that will
generate EAM alloy setfl potential files for any combination of 16
elements: Cu, Ag, Au, Ni, Pd, Pt, Al, Pb, Fe, Mo, Ta, W, Mg, Co, Ti,
Zr. The files can then be used with the :doc:`pair_style eam/alloy <pair_eam>` command.
The tools/eam_database directory contains a Fortran and a Python program
that will generate EAM alloy setfl potential files for any combination
of the 17 elements: Cu, Ag, Au, Ni, Pd, Pt, Al, Pb, Fe, Mo, Ta, W, Mg,
Co, Ti, Zr, Cr. The files can then be used with the :doc:`pair_style
eam/alloy <pair_eam>` command.
The tool is authored by Xiaowang Zhou (Sandia), xzhou at sandia.gov,
and is based on his paper:
The Fortran version of the tool was authored by Xiaowang Zhou (Sandia),
xzhou at sandia.gov, with updates from Lucas Hale (NIST) lucas.hale at
nist.gov and is based on his paper:
X. W. Zhou, R. A. Johnson, and H. N. G. Wadley, Phys. Rev. B, 69,
144113 (2004).
The parameters for Cr were taken from:
Lin Z B, Johnson R A and Zhigilei L V, Phys. Rev. B 77 214108 (2008).
The Python version of the tool was authored by Germain Clavier
(TU Eindhoven) g.m.g.c.clavier at tue.nl or germain.clavier at gmail.com
.. note::
The parameters in the database are only optimized for individual
elements. The mixed parameters for interactions between different
elements generated by this tool are derived from simple mixing rules
and are thus inferior to parameterizations that are specifically
optimized for specific mixtures and combinations of elements.
----------
.. _eamgn:

2
doc/src/balance.rst
View File

@ -383,7 +383,7 @@ multiple groups, its weight is the product of the weight factors.
This weight style is useful in combination with pair style
:doc:`hybrid <pair_hybrid>`, e.g. when combining a more costly many-body
potential with a fast pair-wise potential. It is also useful when
potential with a fast pairwise potential. It is also useful when
using :doc:`run_style respa <run_style>` where some portions of the
system have many bonded interactions and others none. It assumes that
the computational cost for each group remains constant over time.

2
doc/src/compute_pressure.rst
View File

@ -141,7 +141,7 @@ Related commands
""""""""""""""""
:doc:`compute temp <compute_temp>`, :doc:`compute stress/atom <compute_stress_atom>`,
:doc:`thermo_style <thermo_style>`,
:doc:`thermo_style <thermo_style>`, :doc:`fix numdiff/virial <fix_numdiff_virial>`,
Default
"""""""

2
doc/src/compute_pressure_cylinder.rst
View File

@ -61,7 +61,7 @@ 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
due to exclusions for special bonds) and requires pairwise force
calculations not available for most many-body pair styles. K-space
calculations are also excluded. Note that this pressure compute outputs
the configurational terms only; the kinetic contribution is not included

14
doc/src/compute_sna_atom.rst
View File

@ -33,7 +33,7 @@ Syntax
* R_1, R_2,... = list of cutoff radii, one for each type (distance units)
* w_1, w_2,... = list of neighbor weights, one for each type
* zero or more keyword/value pairs may be appended
* keyword = *rmin0* or *switchflag* or *bzeroflag* or *quadraticflag* or *chem* or *bnormflag* or *wselfallflag*
* keyword = *rmin0* or *switchflag* or *bzeroflag* or *quadraticflag* or *chem* or *bnormflag* or *wselfallflag* or *bikflag*
.. parsed-literal::
@ -56,6 +56,9 @@ Syntax
*wselfallflag* value = *0* or *1*
*0* = self-contribution only for element of central atom
*1* = self-contribution for all elements
*bikflag* value = *0* or *1* (only implemented for compute snap)
*0* = per-atom bispectrum descriptors are summed over atoms
*1* = per-atom bispectrum descriptors are not summed over atoms
Examples
""""""""
@ -296,6 +299,15 @@ This option is typically used in conjunction with the *chem* keyword,
and LAMMPS will generate a warning if both *chem* and *bnormflag*
are not both set or not both unset.
The keyword *bikflag* determines whether or not to expand the bispectrum
rows of the global array returned by compute snap. If *bikflag* is set
to *1* then the bispectrum row, which is typically the per-atom bispectrum
descriptors :math:`B_{i,k}` summed over all atoms *i* to produce
:math:`B_k`, becomes bispectrum rows equal to the number of atoms. Thus,
the resulting bispectrum rows are :math:`B_{i,k}` instead of just
:math:`B_k`. In this case, the entries in the final column for these rows
are set to zero.
.. note::
If you have a bonded system, then the settings of :doc:`special_bonds

12
doc/src/dump_modify.rst
View File

@ -17,13 +17,14 @@ Syntax
* one or more keyword/value pairs may be appended
* these keywords apply to various dump styles
* keyword = *append* or *at* or *buffer* or *delay* or *element* or *every* or *every/time* or *fileper* or *first* or *flush* or *format* or *header* or *image* or *label* or *maxfiles* or *nfile* or *pad* or *pbc* or *precision* or *region* or *refresh* or *scale* or *sfactor* or *sort* or *tfactor* or *thermo* or *thresh* or *time* or *units* or *unwrap*
* keyword = *append* or *at* or *balance* or *buffer* or *delay* or *element* or *every* or *every/time* or *fileper* or *first* or *flush* or *format* or *header* or *image* or *label* or *maxfiles* or *nfile* or *pad* or *pbc* or *precision* or *region* or *refresh* or *scale* or *sfactor* or *sort* or *tfactor* or *thermo* or *thresh* or *time* or *units* or *unwrap*
.. parsed-literal::
*append* arg = *yes* or *no*
*at* arg = N
N = index of frame written upon first dump
*balance* arg = *yes* or *no*
*buffer* arg = *yes* or *no*
*delay* arg = Dstep
Dstep = delay output until this timestep
@ -667,6 +668,14 @@ keywords are set to non-default values (i.e. the number of dump file
pieces is not equal to the number of procs), then sorting cannot be
performed.
In a parallel run, the per-processor dump file pieces can have
significant imbalance in number of lines of per-atom info. The *balance*
keyword determines whether the number of lines in each processor
snapshot are balanced to be nearly the same. A balance value of *no*
means no balancing will be done, while *yes* means balancing will be
performed. This balancing preserves dump sorting order. For a serial
run, this option is ignored since the output is already balanced.
.. note::
Unless it is required by the dump style, sorting dump file
@ -832,6 +841,7 @@ Default
The option defaults are
* append = no
* balance = no
* buffer = yes for dump styles *atom*, *custom*, *loca*, and *xyz*
* element = "C" for every atom type
* every = whatever it was set to via the :doc:`dump <dump>` command

9
doc/src/dynamical_matrix.rst
View File

@ -1,8 +1,11 @@
.. index:: dynamical_matrix
.. index:: dynamical_matrix/kk
dynamical_matrix command
========================
Accelerator Variants: dynamical_matrix/kk
Syntax
""""""
@ -56,6 +59,12 @@ If the style eskm is selected, the dynamical matrix will be in units of
inverse squared femtoseconds. These units will then conveniently leave
frequencies in THz.
----------
.. include:: accel_styles.rst
----------
Restrictions
""""""""""""

3
doc/src/fix.rst
View File

@ -271,7 +271,8 @@ accelerated styles exist.
* :doc:`npt/eff <fix_nh_eff>` - NPT for nuclei and electrons in the electron force field model
* :doc:`npt/sphere <fix_npt_sphere>` - NPT for spherical particles
* :doc:`npt/uef <fix_nh_uef>` - NPT style time integration with diagonal flow
* :doc:`numdiff <fix_numdiff>` - compute derivatives of per-atom data from finite differences
* :doc:`numdiff <fix_numdiff>` - numerically approximate atomic forces using finite energy differences
* :doc:`numdiff/virial <fix_numdiff_virial>` - numerically approximate virial stress tensor using finite energy differences
* :doc:`nve <fix_nve>` - constant NVE time integration
* :doc:`nve/asphere <fix_nve_asphere>` - NVE for aspherical particles
* :doc:`nve/asphere/noforce <fix_nve_asphere_noforce>` - NVE for aspherical particles without forces

40
doc/src/fix_atc.rst
View File

@ -266,50 +266,50 @@ For detailed exposition of the theory and algorithms please see:
.. _Wagner:
**(Wagner)** Wagner, GJ; Jones, RE; Templeton, JA; Parks, MA, "An
atomistic-to-continuum coupling method for heat transfer in solids."
Special Issue of Computer Methods and Applied Mechanics (2008)
197:3351.
atomistic-to-continuum coupling method for heat transfer in solids."
Special Issue of Computer Methods and Applied Mechanics (2008)
197:3351.
.. _Zimmeman2004:
**(Zimmerman2004)** Zimmerman, JA; Webb, EB; Hoyt, JJ;. Jones, RE;
Klein, PA; Bammann, DJ, "Calculation of stress in atomistic
simulation." Special Issue of Modelling and Simulation in Materials
Science and Engineering (2004), 12:S319.
Klein, PA; Bammann, DJ, "Calculation of stress in atomistic
simulation." Special Issue of Modelling and Simulation in Materials
Science and Engineering (2004), 12:S319.
.. _Zimmerman2010:
**(Zimmerman2010)** Zimmerman, JA; Jones, RE; Templeton, JA, "A
material frame approach for evaluating continuum variables in
atomistic simulations." Journal of Computational Physics (2010),
229:2364.
material frame approach for evaluating continuum variables in
atomistic simulations." Journal of Computational Physics (2010),
229:2364.
.. _Templeton2010:
**(Templeton2010)** Templeton, JA; Jones, RE; Wagner, GJ, "Application
of a field-based method to spatially varying thermal transport
problems in molecular dynamics." Modelling and Simulation in
Materials Science and Engineering (2010), 18:085007.
of a field-based method to spatially varying thermal transport
problems in molecular dynamics." Modelling and Simulation in
Materials Science and Engineering (2010), 18:085007.
.. _Jones:
**(Jones)** Jones, RE; Templeton, JA; Wagner, GJ; Olmsted, D; Modine,
JA, "Electron transport enhanced molecular dynamics for metals and
semi-metals." International Journal for Numerical Methods in
Engineering (2010), 83:940.
JA, "Electron transport enhanced molecular dynamics for metals and
semi-metals." International Journal for Numerical Methods in
Engineering (2010), 83:940.
.. _Templeton2011:
**(Templeton2011)** Templeton, JA; Jones, RE; Lee, JW; Zimmerman, JA;
Wong, BM, "A long-range electric field solver for molecular dynamics
based on atomistic-to-continuum modeling." Journal of Chemical Theory
and Computation (2011), 7:1736.
Wong, BM, "A long-range electric field solver for molecular dynamics
based on atomistic-to-continuum modeling." Journal of Chemical Theory
and Computation (2011), 7:1736.
.. _Mandadapu:
**(Mandadapu)** Mandadapu, KK; Templeton, JA; Lee, JW, "Polarization
as a field variable from molecular dynamics simulations." Journal of
Chemical Physics (2013), 139:054115.
as a field variable from molecular dynamics simulations." Journal of
Chemical Physics (2013), 139:054115.
Please refer to the standard finite element (FE) texts, e.g. T.J.R
Hughes " The finite element method ", Dover 2003, for the basics of FE

75
doc/src/fix_charge_regulation.rst
View File

@ -20,13 +20,13 @@ Syntax
.. parsed-literal::
keyword = *pH*, *pKa*, *pKb*, *pIp*, *pIm*, *pKs*, *acid_type*, *base_type*, *lunit_nm*, *temp*, *tempfixid*, *nevery*, *nmc*, *xrd*, *seed*, *tag*, *group*, *onlysalt*, *pmcmoves*
keyword = *pH*, *pKa*, *pKb*, *pIp*, *pIm*, *pKs*, *acid_type*, *base_type*, *lunit_nm*, *temp*, *tempfixid*, *nevery*, *nmc*, *rxd*, *seed*, *tag*, *group*, *onlysalt*, *pmcmoves*
*pH* value = pH of the solution (can be specified as an equal-style variable)
*pKa* value = acid dissociation constant
*pKb* value = base dissociation constant
*pIp* value = chemical potential of free cations
*pIm* value = chemical potential of free anions
*pKs* value = solution self-dissociation constant
*pKa* value = acid dissociation constant (in the -log10 representation)
*pKb* value = base dissociation constant (in the -log10 representation)
*pIp* value = activity (effective concentration) of free cations (in the -log10 representation)
*pIm* value = activity (effective concentration) of free anions (in the -log10 representation)
*pKs* value = solvent self-dissociation constant (in the -log10 representation)
*acid_type* = atom type of acid groups
*base_type* = atom type of base groups
*lunit_nm* value = unit length used by LAMMPS (# in the units of nanometers)
@ -34,7 +34,7 @@ Syntax
*tempfixid* value = fix ID of temperature thermostat
*nevery* value = invoke this fix every nevery steps
*nmc* value = number of charge regulation MC moves to attempt every nevery steps
*xrd* value = cutoff distance for acid/base reaction
*rxd* value = cutoff distance for acid/base reaction
*seed* value = random # seed (positive integer)
*tag* value = yes or no (yes: The code assign unique tags to inserted ions; no: The tag of all inserted ions is "0")
*group* value = group-ID, inserted ions are assigned to group group-ID. Can be used multiple times to assign inserted ions to multiple groups.
@ -47,7 +47,7 @@ Examples
""""""""
.. code-block:: LAMMPS
fix chareg all charge/regulation 1 2 acid_type 3 base_type 4 pKa 5 pKb 7 lb 1.0 nevery 200 nexchange 200 seed 123 tempfixid fT
fix chareg all charge/regulation 1 2 acid_type 3 base_type 4 pKa 5.0 pKb 6.0 pH 7.0 pIp 3.0 pIm 3.0 nevery 200 nmc 200 seed 123 tempfixid fT
fix chareg all charge/regulation 1 2 pIp 3 pIm 3 onlysalt yes 2 -1 seed 123 tag yes temp 1.0
@ -92,7 +92,11 @@ where the fix attempts to charge :math:`\mathrm{A}` (discharge
:math:`\mathrm{A}^-`) to :math:`\mathrm{A}^-` (:math:`\mathrm{A}`) and
insert (delete) a proton (atom type 2). Besides, the fix implements
self-ionization reaction of water :math:`\emptyset \rightleftharpoons
\mathrm{H}^++\mathrm{OH}^-`. However, this approach is highly
\mathrm{H}^++\mathrm{OH}^-`.
However, this approach is highly
inefficient at :math:`\mathrm{pH} \approx 7` when the concentration of
both protons and hydroxyl ions is low, resulting in a relatively low
acceptance rate of MC moves.
@ -102,24 +106,31 @@ reactions, which can be easily achieved via
.. code-block:: LAMMPS
fix acid_reaction all charge/regulation 4 5 acid_type 1 pH 7.0 pKa 5.0 pIp 2.0 pIm 2.0
fix acid_reaction2 all charge/regulation 4 5 acid_type 1 pH 7.0 pKa 5.0 pIp 2.0 pIm 2.0
where particles of atom type 4 and 5 are the salt cations and anions,
both at chemical potential pI=2.0, see :ref:`(Curk1) <Curk1>` and
where particles of atom type 4 and 5 are the salt cations and anions, both at activity (effective concentration) of :math:`10^{-2}` mol/l, see :ref:`(Curk1) <Curk1>` and
:ref:`(Landsgesell) <Landsgesell>` for more details.
Similarly, we could have simultaneously added a base ionization reaction
(:math:`\mathrm{B} \rightleftharpoons \mathrm{B}^++\mathrm{OH}^-`)
We could have simultaneously added a base ionization reaction (:math:`\mathrm{B} \rightleftharpoons \mathrm{B}^++\mathrm{OH}^-`)
.. code-block:: LAMMPS
fix base_reaction all charge/regulation 2 3 base_type 6 pH 7.0 pKb 6.0 pIp 7.0 pIm 7.0
fix acid_base_reaction all charge/regulation 2 3 acid_type 1 base_type 6 pH 7.0 pKa 5.0 pKb 6.0 pIp 7.0 pIm 7.0
where the fix will attempt to charge :math:`\mathrm{B}` (discharge
:math:`\mathrm{B}^+`) to :math:`\mathrm{B}^+` (:math:`\mathrm{B}`) and
insert (delete) a hydroxyl ion :math:`\mathrm{OH}^-` of atom type 3. If
neither the acid or the base type is specified, for example,
insert (delete) a hydroxyl ion :math:`\mathrm{OH}^-` of atom type 3.
Dissociated ions and salt ions can be combined into a single particle type, which reduces the number of necessary MC moves and increases sampling performance, see :ref:`(Curk1) <Curk1>`. The :math:`\mathrm{H}^+` and monovalent salt cation (:math:`\mathrm{S}^+`) are combined into a single particle type, :math:`\mathrm{X}^+ = \{\mathrm{H}^+, \mathrm{S}^+\}`. In this case "pIp" refers to the effective concentration of the combined cation type :math:`\mathrm{X}^+` and its value is determined by :math:`10^{-\mathrm{pIp}} = 10^{-\mathrm{pH}} + 10^{-\mathrm{pSp}}`, where :math:`10^{-\mathrm{pSp}}` is the effective concentration of salt cations. For example, at pH=7 and pSp=6 we would find pIp~5.958 and the command that performs reactions with combined ions could read,
.. code-block:: LAMMPS
fix acid_reaction_combined all charge/regulation 2 3 acid_type 1 pH 7.0 pKa 5.0 pIp 5.958 pIm 5.958
If neither the acid or the base type is specified, for example,
.. code-block:: LAMMPS
@ -127,11 +138,11 @@ neither the acid or the base type is specified, for example,
the fix simply inserts or deletes an ion pair of a free cation (atom
type 4) and a free anion (atom type 5) as done in a conventional
grand-canonical MC simulation.
grand-canonical MC simulation. Multivalent ions can be inserted (deleted) by using the *onlysalt* keyword.
The fix is compatible with LAMMPS sub-packages such as *molecule* or
*rigid*. That said, the acid and base particles can be part of larger
*rigid*. The acid and base particles can be part of larger
molecules or rigid bodies. Free ions that are inserted to or deleted
from the system must be defined as single particles (no bonded
interactions allowed) and cannot be part of larger molecules or rigid
@ -153,14 +164,14 @@ Langevin thermostat:
fix fT all langevin 1.0 1.0 1.0 123
fix_modify fT temp dtemp
The chemical potential units (e.g. pH) are in the standard log10
The units of pH, pKa, pKb, pIp, pIm are considered to be in the standard -log10
representation assuming reference concentration :math:`\rho_0 =
\mathrm{mol}/\mathrm{l}`. Therefore, to perform the internal unit
conversion, the length (in nanometers) of the LAMMPS unit length must be
specified via *lunit_nm* (default is set to the Bjerrum length in water
at room temperature *lunit_nm* = 0.71nm). For example, in the dilute
ideal solution limit, the concentration of free ions will be
:math:`c_\mathrm{I} = 10^{-\mathrm{pIp}}\mathrm{mol}/\mathrm{l}`.
\mathrm{mol}/\mathrm{l}`. For example, in the dilute
ideal solution limit, the concentration of free cations will be
:math:`c_\mathrm{I} = 10^{-\mathrm{pIp}}\mathrm{mol}/\mathrm{l}`. To perform the internal unit
conversion, the the value of the LAMMPS unit length must be
specified in nanometers via *lunit_nm*. The default value is set to the Bjerrum length in water
at room temperature (0.71 nm), *lunit_nm* = 0.71.
The temperature used in MC acceptance probability is set by *temp*. This
temperature should be the same as the temperature set by the molecular
@ -171,10 +182,10 @@ thermostat fix-ID is *fT*. The inserted particles attain a random
velocity corresponding to the specified temperature. Using *tempfixid*
overrides any fixed temperature set by *temp*.
The *xrd* keyword can be used to restrict the inserted/deleted
The *rxd* keyword can be used to restrict the inserted/deleted
counterions to a specific radial distance from an acid or base particle
that is currently participating in a reaction. This can be used to
simulate more realist reaction dynamics. If *xrd* = 0 or *xrd* > *L* /
simulate more realist reaction dynamics. If *rxd* = 0 or *rxd* > *L* /
2, where *L* is the smallest box dimension, the radial restriction is
automatically turned off and free ion can be inserted or deleted
anywhere in the simulation box.
@ -258,18 +269,18 @@ Default
pH = 7.0; pKa = 100.0; pKb = 100.0; pIp = 5.0; pIm = 5.0; pKs = 14.0;
acid_type = -1; base_type = -1; lunit_nm = 0.71; temp = 1.0; nevery =
100; nmc = 100; xrd = 0; seed = 0; tag = no; onlysalt = no, pmcmoves =
100; nmc = 100; rxd = 0; seed = 0; tag = no; onlysalt = no, pmcmoves =
[1/3, 1/3, 1/3], group-ID = all
----------
.. _Curk1:
**(Curk1)** T. Curk, J. Yuan, and E. Luijten, "Coarse-grained simulation of charge regulation using LAMMPS", preprint (2021).
**(Curk1)** T. Curk, J. Yuan, and E. Luijten, "Accelerated simulation method for charge regulation effects", JCP 156 (2022).
.. _Curk2:
**(Curk2)** T. Curk and E. Luijten, "Charge-regulation effects in nanoparticle self-assembly", PRL (2021)
**(Curk2)** T. Curk and E. Luijten, "Charge-regulation effects in nanoparticle self-assembly", PRL 126 (2021)
.. _Landsgesell:

23
doc/src/fix_numdiff.rst
View File

@ -13,16 +13,15 @@ Syntax
* ID, group-ID are documented in :doc:`fix <fix>` command
* numdiff = style name of this fix command
* Nevery = calculate force by finite difference every this many timesteps
* delta = finite difference displacement length (distance units)
* delta = size of atom displacements (distance units)
Examples
""""""""
.. code-block:: LAMMPS
fix 1 all numdiff 1 0.0001
fix 1 all numdiff 10 1e-6
fix 1 all numdiff 100 0.01
fix 1 movegroup numdiff 100 0.01
Description
"""""""""""
@ -67,16 +66,17 @@ by two times *delta*.
The cost of each energy evaluation is essentially the cost of an MD
timestep. Thus invoking this fix once for a 3d system has a cost
of 6N timesteps, where N is the total number of atoms in the system
(assuming all atoms are included in the group). So this fix can be
very expensive to use for large systems.
of 6N timesteps, where N is the total number of atoms in the system.
So this fix can be very expensive to use for large systems.
One expedient alternative is to define the fix for a group containing
only a few atoms.
----------
The *Nevery* argument specifies on what timesteps the force will
be used calculated by finite difference.
The *delta* argument specifies the positional displacement each
The *delta* argument specifies the size of the displacement each
atom will undergo.
----------
@ -93,7 +93,12 @@ This fix produces a per-atom array which can be accessed by various
the force on each atom as calculated by finite difference. The
per-atom values can only be accessed on timesteps that are multiples
of *Nevery* since that is when the finite difference forces are
calculated.
calculated. See the examples in *examples/numdiff* directory
to see how this fix can be used to directly compare with
the analytic forces computed by LAMMPS.
The array values calculated by this compute
will be in force :doc:`units <units>`.
No parameter of this fix can be used with the *start/stop* keywords of
the :doc:`run <run>` command. This fix is invoked during :doc:`energy
@ -108,7 +113,7 @@ was built with that package. See the :doc:`Build package <Build_package>` page
Related commands
""""""""""""""""
:doc:`dynamical_matrix <dynamical_matrix>`,
:doc:`dynamical_matrix <dynamical_matrix>`, :doc:`fix numdiff/virial <fix_numdiff_virial>`,
Default
"""""""

115
doc/src/fix_numdiff_virial.rst Normal file
View File

@ -0,0 +1,115 @@
.. index:: fix numdiff/virial
fix numdiff/virial command
==========================
Syntax
""""""
.. parsed-literal::
fix ID group-ID numdiff/virial Nevery delta
* ID, group-ID are documented in :doc:`fix <fix>` command
* numdiff/virial = style name of this fix command
* Nevery = calculate virial by finite difference every this many timesteps
* delta = magnitude of strain fields (dimensionless)
Examples
""""""""
.. code-block:: LAMMPS
fix 1 all numdiff/stress 10 1e-6
Description
"""""""""""
Calculate the virial stress tensor through a finite difference calculation of
energy versus strain. These values can be compared to the analytic virial
tensor computed by pair styles, bond styles, etc. This can be useful for
debugging or other purposes. The specified group must be "all".
This fix applies linear strain fields of magnitude *delta* to all the
atoms relative to a point at the center of the box. The
strain fields are in six different directions, corresponding to the
six Cartesian components of the stress tensor defined by LAMMPS.
For each direction it applies the strain field in both the positive
and negative senses, and the new energy of the entire system
is calculated after each. The difference in these two energies
divided by two times *delta*, approximates the corresponding
component of the virial stress tensor, after applying
a suitable unit conversion.
.. note::
It is important to choose a suitable value for delta, the magnitude of
strains that are used to generate finite difference
approximations to the exact virial stress. For typical systems, a value in
the range of 1 part in 1e5 to 1e6 will be sufficient.
However, the best value will depend on a multitude of factors
including the stiffness of the interatomic potential, the thermodynamic
state of the material being probed, and so on. The only way to be sure
that you have made a good choice is to do a sensitivity study on a
representative atomic configuration, sweeping over a wide range of
values of delta. If delta is too small, the output values will vary
erratically due to truncation effects. If delta is increased beyond a
certain point, the output values will start to vary smoothly with
delta, due to growing contributions from higher order derivatives. In
between these two limits, the numerical virial values should be largely
independent of delta.
----------
The *Nevery* argument specifies on what timesteps the force will
be used calculated by finite difference.
The *delta* argument specifies the size of the displacement each
atom will undergo.
----------
Restart, fix_modify, output, run start/stop, minimize info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
No information about this fix is written to :doc:`binary restart files
<restart>`. None of the :doc:`fix_modify <fix_modify>` options are
relevant to this fix.
This fix produces a global vector which can be accessed by various
:doc:`output commands <Howto_output>`, which stores the components of
the virial stress tensor as calculated by finite difference. The
global vector can only be accessed on timesteps that are multiples
of *Nevery* since that is when the finite difference virial is
calculated. See the examples in *examples/numdiff* directory
to see how this fix can be used to directly compare with
the analytic virial stress tensor computed by LAMMPS.
The order of the virial stress tensor components is *xx*, *yy*, *zz*,
*yz*, *xz*, and *xy*, consistent with Voigt notation. Note that
the vector produced by :doc:`compute pressure <compute_pressure>`
uses a different ordering, with *yz* and *xy* swapped.
The vector values calculated by this compute are
"intensive". The vector values will be in pressure
:doc:`units <units>`.
No parameter of this fix can be used with the *start/stop* keywords of
the :doc:`run <run>` command. This fix is invoked during :doc:`energy
minimization <minimize>`.
Restrictions
""""""""""""
This fix is part of the EXTRA-FIX package. It is only enabled if LAMMPS
was built with that package. See the :doc:`Build package <Build_package>` page for more info.
Related commands
""""""""""""""""
:doc:`fix numdiff <fix_numdiff>`, :doc:`compute pressure <compute_pressure>`
Default
"""""""
none

9
doc/src/fix_nvt_sllod.rst
View File

@ -66,7 +66,10 @@ equivalent to Newton's equations of motion for shear flow by
:ref:`(Evans and Morriss) <Evans3>`. They were later shown to generate
the desired velocity gradient and the correct production of work by
stresses for all forms of homogeneous flow by :ref:`(Daivis and Todd)
<Daivis>`. As implemented in LAMMPS, they are coupled to a
<Daivis>`.
The LAMMPS implementation corresponds to the p-SLLOD variant
of SLLOD. :ref:`(Edwards) <Edwards>`.
The equations of motion are coupled to a
Nose/Hoover chain thermostat in a velocity Verlet formulation, closely
following the implementation used for the :doc:`fix nvt <fix_nh>`
command.
@ -180,6 +183,10 @@ Same as :doc:`fix nvt <fix_nh>`, except tchain = 1.
**(Daivis and Todd)** Daivis and Todd, J Chem Phys, 124, 194103 (2006).
.. _Edwards:
**(Edwards)** Edwards, Baig, and Keffer, J Chem Phys 124, 194104 (2006).
.. _Daivis-sllod:
**(Daivis and Todd)** Daivis and Todd, Nonequilibrium Molecular Dynamics (book),

8
doc/src/fix_qeq.rst
View File

@ -201,9 +201,11 @@ larger sizes, and *qeq/fire* is faster than *qeq/dynamic*\ .
.. note::
To avoid the evaluation of the derivative of charge with respect
to position, which is typically ill-defined, the system should have a
zero net charge.
In order to solve the self-consistent equations for electronegativity
equalization, LAMMPS imposes the additional constraint that all the
charges in the fix group must add up to zero. The initial charge
assignments should also satisfy this constraint. LAMMPS will print a
warning if that is not the case.
.. note::

8
doc/src/fix_qeq_comb.rst
View File

@ -63,6 +63,14 @@ performing charge equilibration (more iterations) and accuracy.
If the *file* keyword is used, then information about each
equilibration calculation is written to the specified file.
.. note::
In order to solve the self-consistent equations for electronegativity
equalization, LAMMPS imposes the additional constraint that all the
charges in the fix group must add up to zero. The initial charge
assignments should also satisfy this constraint. LAMMPS will print a
warning if that is not the case.
----------
.. include:: accel_styles.rst

10
doc/src/fix_qeq_reaxff.rst
View File

@ -77,6 +77,8 @@ of this fix are hard-coded to be A, eV, and electronic charge.
The optional *dual* keyword allows to perform the optimization
of the S and T matrices in parallel. This is only supported for
the *qeq/reaxff/omp* style. Otherwise they are processed separately.
The *qeq/reaxff/kk* style always solves the S and T matrices in
parallel.
The optional *maxiter* keyword allows changing the max number
of iterations in the linear solver. The default value is 200.
@ -88,6 +90,14 @@ same fixed number of QEq iterations is desired, which can be achieved
by using a very small tolerance and setting *maxiter* to the desired
number of iterations.
.. note::
In order to solve the self-consistent equations for electronegativity
equalization, LAMMPS imposes the additional constraint that all the
charges in the fix group must add up to zero. The initial charge
assignments should also satisfy this constraint. LAMMPS will print a
warning if that is not the case.
Restart, fix_modify, output, run start/stop, minimize info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

9
doc/src/fix_viscosity.rst
View File

@ -108,10 +108,11 @@ fluid, in appropriate units. See the :ref:`Muller-Plathe paper <Muller-Plathe2>
An alternative method for calculating a viscosity is to run a NEMD
simulation, as described on the :doc:`Howto nemd <Howto_nemd>` doc page.
NEMD simulations deform the simulation box via the :doc:`fix deform <fix_deform>` command. Thus they cannot be run on a charged
system using a :doc:`PPPM solver <kspace_style>` since PPPM does not
currently support non-orthogonal boxes. Using fix viscosity keeps the
box orthogonal; thus it does not suffer from this limitation.
NEMD simulations deform the simulation box via the :doc:`fix deform <fix_deform>` command.
Some features or combination of settings in LAMMPS do not support
non-orthogonal boxes. Using fix viscosity keeps the box orthogonal;
thus it does not suffer from these limitations.
Restart, fix_modify, output, run start/stop, minimize info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

2
doc/src/package.rst
View File

@ -460,7 +460,7 @@ using *neigh/thread* *on*, a full neighbor list must also be used. Using
is turned on by default only when there are 16K atoms or less owned by
an MPI rank and when using a full neighbor list. Not all KOKKOS-enabled
potentials support this keyword yet, and only thread over atoms. Many
simple pair-wise potentials such as Lennard-Jones do support threading
simple pairwise potentials such as Lennard-Jones do support threading
over both atoms and neighbors.
The *newton* keyword sets the Newton flags for pairwise and bonded

2
doc/src/pair_charmm.rst
View File

@ -119,7 +119,7 @@ name are the older, original LAMMPS implementations. They compute the
LJ and Coulombic interactions with an energy switching function (esw,
shown in the formula below as S(r)), which ramps the energy smoothly
to zero between the inner and outer cutoff. This can cause
irregularities in pair-wise forces (due to the discontinuous second
irregularities in pairwise forces (due to the discontinuous second
derivative of energy at the boundaries of the switching region), which
in some cases can result in detectable artifacts in an MD simulation.

2
doc/src/pair_dpd.rst
View File

@ -50,7 +50,7 @@ Style *dpd* computes a force field for dissipative particle dynamics
Style *dpd/tstat* invokes a DPD thermostat on pairwise interactions,
which is equivalent to the non-conservative portion of the DPD force
field. This pair-wise thermostat can be used in conjunction with any
field. This pairwise thermostat can be used in conjunction with any
:doc:`pair style <pair_style>`, and in leiu of per-particle thermostats
like :doc:`fix langevin <fix_langevin>` or ensemble thermostats like
Nose Hoover as implemented by :doc:`fix nvt <fix_nh>`. To use

90
doc/src/pair_harmonic_cut.rst Normal file
View File

@ -0,0 +1,90 @@
.. index:: pair_style harmonic/cut
.. index:: pair_style harmonic/cut/omp
pair_style harmonic/cut command
===============================
Accelerator Variants: *harmonic/cut/omp*
Syntax
""""""
.. code-block:: LAMMPS
pair_style style
* style = *harmonic/cut*
Examples
""""""""
.. code-block:: LAMMPS
pair_style harmonic/cut
pair_coeff * * 0.2 2.0
pair_coeff 1 1 0.5 2.5
Description
"""""""""""
Style *harmonic/cut* computes pairwise repulsive-only harmonic interactions with the formula
.. math::
E = k (r_c - r)^2 \qquad r < r_c
:math:`r_c` is the cutoff.
The following coefficients must be defined for each pair of atoms
types via the :doc:`pair_coeff <pair_coeff>` command as in the examples
above, or in the data file or restart files read by the
:doc:`read_data <read_data>` or :doc:`read_restart <read_restart>`
commands:
* :math:`k` (energy units)
* :math:`r_c` (distance units)
----------
.. include:: accel_styles.rst
----------
Mixing, shift, table, tail correction, restart, rRESPA info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
For atom type pairs I,J and I != J, the :math:`k` and :math:`r_c`
coefficients can be mixed. The default mix value is *geometric*.
See the "pair_modify" command for details.
Since the potential is zero at and beyond the cutoff parameter by
construction, there is no need to support the :doc:`pair_modify
<pair_modify>` shift or tail options for the energy and pressure of the
pair interaction.
These pair styles write their information to :doc:`binary restart files <restart>`,
so pair_style and pair_coeff commands do not need to be specified in an input script
that reads a restart file.
These pair styles can only be used via the *pair* keyword of the
:doc:`run_style respa <run_style>` command. They do not support the
*inner*, *middle*, *outer* keywords.
----------
Restrictions
""""""""""""
The *harmonic/cut* pair style is only enabled if LAMMPS was
built with the EXTRA-PAIR package.
See the :doc:`Build package <Build_package>` page for more info.
Related commands
""""""""""""""""
:doc:`pair_coeff <pair_coeff>`
Default
"""""""
none

2
doc/src/pair_ilp_graphene_hbn.rst
View File

@ -159,6 +159,8 @@ Related commands
:doc:`pair_none <pair_none>`,
:doc:`pair_style hybrid/overlay <pair_hybrid>`,
:doc:`pair_style drip <pair_drip>`,
:doc:`pair_style ilp_tmd <pair_ilp_tmd>`,
:doc:`pair_style saip_metal <pair_saip_metal>`,
:doc:`pair_style pair_kolmogorov_crespi_z <pair_kolmogorov_crespi_z>`,
:doc:`pair_style pair_kolmogorov_crespi_full <pair_kolmogorov_crespi_full>`,
:doc:`pair_style pair_lebedeva_z <pair_lebedeva_z>`,

157
doc/src/pair_ilp_tmd.rst Normal file
View File

@ -0,0 +1,157 @@
.. index:: pair_style ilp/tmd
pair_style ilp/tmd command
===================================
Syntax
""""""
.. code-block:: LAMMPS
pair_style [hybrid/overlay ...] ilp/tmd cutoff tap_flag
* cutoff = global cutoff (distance units)
* tap_flag = 0/1 to turn off/on the taper function
Examples
""""""""
.. code-block:: LAMMPS
pair_style hybrid/overlay ilp/tmd 16.0 1
pair_coeff * * ilp/tmd TMD.ILP Mo S S
pair_style hybrid/overlay sw/mod sw/mod ilp/tmd 16.0
pair_coeff * * sw/mod 1 tmd.sw.mod Mo S S NULL NULL NULL
pair_coeff * * sw/mod 2 tmd.sw.mod NULL NULL NULL Mo S S
pair_coeff * * ilp/tmd TMD.ILP Mo S S Mo S S
Description
"""""""""""
The *ilp/tmd* style computes the registry-dependent interlayer
potential (ILP) potential for transition metal dichalcogenides (TMD)
as described in :ref:`(Ouyang7) <Ouyang7>`.
.. math::
E = & \frac{1}{2} \sum_i \sum_{j \neq i} V_{ij} \\
V_{ij} = & {\rm Tap}(r_{ij})\left \{ e^{-\alpha (r_{ij}/\beta -1)}
\left [ \epsilon + f(\rho_{ij}) + f(\rho_{ji})\right ] -
\frac{1}{1+e^{-d\left [ \left ( r_{ij}/\left (s_R \cdot r^{eff} \right ) \right )-1 \right ]}}
\cdot \frac{C_6}{r^6_{ij}} \right \}\\
\rho_{ij}^2 = & r_{ij}^2 - ({\bf r}_{ij} \cdot {\bf n}_i)^2 \\
\rho_{ji}^2 = & r_{ij}^2 - ({\bf r}_{ij} \cdot {\bf n}_j)^2 \\
f(\rho) = & C e^{ -( \rho / \delta )^2 } \\
{\rm Tap}(r_{ij}) = & 20\left ( \frac{r_{ij}}{R_{cut}} \right )^7 -
70\left ( \frac{r_{ij}}{R_{cut}} \right )^6 +
84\left ( \frac{r_{ij}}{R_{cut}} \right )^5 -
35\left ( \frac{r_{ij}}{R_{cut}} \right )^4 + 1
Where :math:`\mathrm{Tap}(r_{ij})` is the taper function which provides
a continuous cutoff (up to third derivative) for interatomic separations
larger than :math:`r_c` :doc:`pair_style ilp_graphene_hbn <pair_ilp_graphene_hbn>`.
It is important to include all the pairs to build the neighbor list for
calculating the normals.
.. note::
Since each MX2 (M = Mo, W and X = S, Se Te) layer contains two
sub-layers of X atoms and one sub-layer of M atoms, the definition of the
normal vectors used for graphene and h-BN is no longer valid for TMDs.
In :ref:`(Ouyang7) <Ouyang7>`, a new definition is proposed, where for
each atom `i`, its six nearest neighboring atoms belonging to the same
sub-layer are chosen to define the normal vector `{\bf n}_i`.
The parameter file (e.g. TMD.ILP), is intended for use with *metal*
:doc:`units <units>`, 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::
The parameters presented in the parameter file (e.g. TMD.ILP),
are fitted with taper function by setting the cutoff equal to 16.0
Angstrom. Using different cutoff or taper function should be careful.
These parameters provide a good description in both short- and long-range
interaction regimes. 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 :ref:`(Ouyang7) <Ouyang7>`.
This potential must be used in combination with hybrid/overlay.
Other interactions can be set to zero using pair_style *none*\ .
This pair style tallies a breakdown of the total interlayer potential
energy into sub-categories, which can be accessed via the :doc:`compute pair <compute_pair>` command as a vector of values of length 2.
The 2 values correspond to the following sub-categories:
1. *E_vdW* = vdW (attractive) energy
2. *E_Rep* = Repulsive energy
To print these quantities to the log file (with descriptive column
headings) the following commands could be included in an input script:
.. code-block:: LAMMPS
compute 0 all pair ilp/tmd
variable Evdw equal c_0[1]
variable Erep equal c_0[2]
thermo_style custom step temp epair v_Erep v_Evdw
----------
Mixing, shift, table, tail correction, restart, rRESPA info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
This pair style does not support the pair_modify mix, shift, table, and
tail options.
This pair style does not write their information to binary restart
files, since it is stored in potential files. Thus, you need to
re-specify the pair_style and pair_coeff commands in an input script
that reads a restart file.
Restrictions
""""""""""""
This pair style is part of the INTERLAYER package. It is only enabled
if LAMMPS was built with that package. See the :doc:`Build package
<Build_package>` page for more info.
This pair style requires the newton setting to be *on* for pair
interactions.
The TMD.ILP potential file provided with LAMMPS (see the potentials
directory) are parameterized for *metal* units. You can use this
potential with any LAMMPS units, but you would need to create your
BNCH.ILP potential file with coefficients listed in the appropriate
units, if your simulation does not use *metal* units.
Related commands
""""""""""""""""
:doc:`pair_coeff <pair_coeff>`,
:doc:`pair_none <pair_none>`,
:doc:`pair_style hybrid/overlay <pair_hybrid>`,
:doc:`pair_style drip <pair_drip>`,
:doc:`pair_style saip_metal <pair_saip_metal>`,
:doc:`pair_style ilp_graphene_hbn <pair_ilp_graphene_hbn>`,
:doc:`pair_style pair_kolmogorov_crespi_z <pair_kolmogorov_crespi_z>`,
:doc:`pair_style pair_kolmogorov_crespi_full <pair_kolmogorov_crespi_full>`,
:doc:`pair_style pair_lebedeva_z <pair_lebedeva_z>`,
:doc:`pair_style pair_coul_shield <pair_coul_shield>`.
Default
"""""""
tap_flag = 1
----------
.. _Ouyang7:
**(Ouyang7)** W. Ouyang, et al., J. Chem. Theory Comput. 17, 7237 (2021).

2
doc/src/pair_python.rst
View File

@ -164,7 +164,7 @@ Following the *LJCutMelt* example, here are the two functions:
.. note::
The evaluation of scripted python code will slow down the
computation pair-wise interactions quite significantly. However, this
computation pairwise interactions quite significantly. However, this
can be largely worked around through using the python pair style not
for the actual simulation, but to generate tabulated potentials on the
fly using the :doc:`pair_write <pair_write>` command. Please see below

13
doc/src/pair_reaxff.rst
View File

@ -19,13 +19,14 @@ Syntax
.. parsed-literal::
keyword = *checkqeq* or *lgvdw* or *safezone* or *mincap* or *minhbonds*
keyword = *checkqeq* or *lgvdw* or *safezone* or *mincap* or *minhbonds* or *list/blocking*
*checkqeq* value = *yes* or *no* = whether or not to require qeq/reaxff or acks2/reaxff fix
*enobonds* value = *yes* or *no* = whether or not to tally energy of atoms with no bonds
*lgvdw* value = *yes* or *no* = whether or not to use a low gradient vdW correction
*safezone* = factor used for array allocation
*mincap* = minimum size for array allocation
*minhbonds* = minimum size use for storing hydrogen bonds
*list/blocking* value = *yes* or *no* = whether or not to use "blocking" scheme for bond list build
Examples
""""""""
@ -158,6 +159,14 @@ the Kokkos version, which instead uses a more robust memory allocation
scheme that checks if the sizes of the arrays have been exceeded and
automatically allocates more memory.
The keyword *list/blocking* is only supported by the Kokkos version of
ReaxFF and ignored otherwise. Setting the value to *yes* enables the
"blocking" scheme (dynamically building interaction lists) for the
ReaxFF bond neighbor list. This reduces the number of empty
interactions and can improve performance in some cases (e.g. large
number of atoms/GPU on AMD hardware). It is also enabled by default
when running the CPU with Kokkos.
The thermo variable *evdwl* stores the sum of all the ReaxFF potential
energy contributions, with the exception of the Coulombic and charge
equilibration contributions which are stored in the thermo variable
@ -361,7 +370,7 @@ Default
"""""""
The keyword defaults are checkqeq = yes, enobonds = yes, lgvdw = no,
safezone = 1.2, mincap = 50, minhbonds = 25.
safezone = 1.2, mincap = 50, minhbonds = 25, list/blocking = yes on CPU, no on GPU.
----------

156
doc/src/pair_saip_metal.rst Normal file
View File

@ -0,0 +1,156 @@
.. index:: pair_style saip/metal
pair_style saip/metal command
===================================
Syntax
""""""
.. code-block:: LAMMPS
pair_style [hybrid/overlay ...] saip/metal cutoff tap_flag
* cutoff = global cutoff (distance units)
* tap_flag = 0/1 to turn off/on the taper function
Examples
""""""""
.. code-block:: LAMMPS
pair_style hybrid/overlay saip/metal 16.0 1
pair_coeff * * saip/metal CHAu.ILP Au C H
pair_style hybrid/overlay eam rebo saip/metal 16.0
pair_coeff 1 1 eam Au_u3.eam Au NULL NULL
pair_coeff * * rebo CH.rebo NULL C H
pair_coeff * * saip/metal CHAu.ILP Au C H
Description
"""""""""""
The *saip/metal* style computes the registry-dependent interlayer
potential (ILP) potential for hetero-junctions formed with hexagonal
2D materials and metal surfaces, as described in :ref:`(Ouyang6) <Ouyang6>`.
.. math::
E = & \frac{1}{2} \sum_i \sum_{j \neq i} V_{ij} \\
V_{ij} = & {\rm Tap}(r_{ij})\left \{ e^{-\alpha (r_{ij}/\beta -1)}
\left [ \epsilon + f(\rho_{ij}) + f(\rho_{ji})\right ] -
\frac{1}{1+e^{-d\left [ \left ( r_{ij}/\left (s_R \cdot r^{eff} \right ) \right )-1 \right ]}}
\cdot \frac{C_6}{r^6_{ij}} \right \}\\
\rho_{ij}^2 = & r_{ij}^2 - ({\bf r}_{ij} \cdot {\bf n}_i)^2 \\
\rho_{ji}^2 = & r_{ij}^2 - ({\bf r}_{ij} \cdot {\bf n}_j)^2 \\
f(\rho) = & C e^{ -( \rho / \delta )^2 } \\
{\rm Tap}(r_{ij}) = & 20\left ( \frac{r_{ij}}{R_{cut}} \right )^7 -
70\left ( \frac{r_{ij}}{R_{cut}} \right )^6 +
84\left ( \frac{r_{ij}}{R_{cut}} \right )^5 -
35\left ( \frac{r_{ij}}{R_{cut}} \right )^4 + 1
Where :math:`\mathrm{Tap}(r_{ij})` is the taper function which provides
a continuous cutoff (up to third derivative) for interatomic separations
larger than :math:`r_c` :doc:`pair_style ilp_graphene_hbn <pair_ilp_graphene_hbn>`.
It is important to include all the pairs to build the neighbor list for
calculating the normals.
.. note::
To account for the isotropic nature of the isolated gold atom
electron cloud, their corresponding normal vectors (`{\bf n}_i`) are
assumed to lie along the interatomic vector `{\bf r}_ij`. Notably, this
assumption is suitable for many bulk material surfaces, for
example, for systems possessing s-type valence orbitals or
metallic surfaces, whose valence electrons are mostly
delocalized, such that their Pauli repulsion with the electrons
of adjacent surfaces are isotropic. Caution should be used in
the case of very small gold contacts, for example, nano-clusters,
where edge effects may become relevant.
The parameter file (e.g. CHAu.ILP), is intended for use with *metal*
:doc:`units <units>`, 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::
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.
This potential must be used in combination with hybrid/overlay.
Other interactions can be set to zero using pair_style *none*\ .
This pair style tallies a breakdown of the total interlayer potential
energy into sub-categories, which can be accessed via the :doc:`compute pair <compute_pair>` command as a vector of values of length 2.
The 2 values correspond to the following sub-categories:
1. *E_vdW* = vdW (attractive) energy
2. *E_Rep* = Repulsive energy
To print these quantities to the log file (with descriptive column
headings) the following commands could be included in an input script:
.. code-block:: LAMMPS
compute 0 all pair saip/metal
variable Evdw equal c_0[1]
variable Erep equal c_0[2]
thermo_style custom step temp epair v_Erep v_Evdw
----------
Mixing, shift, table, tail correction, restart, rRESPA info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
This pair style does not support the pair_modify mix, shift, table, and
tail options.
This pair style does not write their information to binary restart
files, since it is stored in potential files. Thus, you need to
re-specify the pair_style and pair_coeff commands in an input script
that reads a restart file.
Restrictions
""""""""""""
This pair style is part of the INTERLAYER package. It is only enabled
if LAMMPS was built with that package. See the :doc:`Build package
<Build_package>` page for more info.
This pair style requires the newton setting to be *on* for pair
interactions.
The CHAu.ILP potential file provided with LAMMPS (see the potentials
directory) are parameterized for *metal* units. You can use this
potential with any LAMMPS units, but you would need to create your
BNCH.ILP potential file with coefficients listed in the appropriate
units, if your simulation does not use *metal* units.
Related commands
""""""""""""""""
:doc:`pair_coeff <pair_coeff>`,
:doc:`pair_none <pair_none>`,
:doc:`pair_style hybrid/overlay <pair_hybrid>`,
:doc:`pair_style drip <pair_drip>`,
:doc:`pair_style ilp_tmd <pair_ilp_tmd>`,
:doc:`pair_style ilp_graphene_hbn <pair_ilp_graphene_hbn>`,
:doc:`pair_style pair_kolmogorov_crespi_z <pair_kolmogorov_crespi_z>`,
:doc:`pair_style pair_kolmogorov_crespi_full <pair_kolmogorov_crespi_full>`,
:doc:`pair_style pair_lebedeva_z <pair_lebedeva_z>`,
:doc:`pair_style pair_coul_shield <pair_coul_shield>`.
Default
"""""""
tap_flag = 1
----------
.. _Ouyang6:
**(Ouyang6)** W. Ouyang, O. Hod, and R. Guerra, J. Chem. Theory Comput. 17, 7215 (2021).

41
doc/src/pair_style.rst
View File

@ -67,20 +67,34 @@ If the pair_style command has a cutoff argument, it sets global
cutoffs for all pairs of atom types. The distance(s) can be smaller
or larger than the dimensions of the simulation box.
Typically, the global cutoff value can be overridden for a specific
pair of atom types by the :doc:`pair_coeff <pair_coeff>` command. The
pair style settings (including global cutoffs) can be changed by a
subsequent pair_style command using the same style. This will reset
the cutoffs for all atom type pairs, including those previously set
explicitly by a :doc:`pair_coeff <pair_coeff>` command. The exceptions
to this are that pair_style *table* and *hybrid* settings cannot be
reset. A new pair_style command for these styles will wipe out all
previously specified pair_coeff values.
In many cases, the global cutoff value can be overridden for a
specific pair of atom types by the :doc:`pair_coeff <pair_coeff>`
command.
If a new pair_style command is specified with a new style, all
previous :doc:`pair_coeff <pair_coeff>` and :doc:`pair_modify
<pair_modify>` command settings are erased; those commands must be
re-specified if necessary.
If a new pair_style command is specified with the same style, then
only the global settings in that command are reset. Any previous
doc:`pair_coeff <pair_coeff>` and :doc:`pair_modify <pair_modify>`
command settings are preserved. The only exception is that if the
global cutoff in the pair_style command is changed, it will override
the corresponding cutoff in any of the previous doc:`pair_modify
<pair_coeff>` commands.
Two pair styles which do not follow this rule are the pair_style
*table* and *hybrid* commands. A new pair_style command for these
styles will wipe out all previously specified doc:`pair_coeff
<pair_coeff>` and :doc:`pair_modify <pair_modify>` settings, including
for the sub-styles of the *hybrid* command.
----------
Here is an alphabetic list of pair styles defined in LAMMPS. They are
also listed in more compact form on the :doc:`Commands pair <Commands_pair>` doc page.
also listed in more compact form on the :doc:`Commands pair
<Commands_pair>` doc page.
Click on the style to display the formula it computes, any additional
arguments specified in the pair_style command, and coefficients
@ -154,10 +168,10 @@ accelerated styles exist.
* :doc:`coul/wolf/cs <pair_cs>` - Coulomb via Wolf potential with core/shell adjustments
* :doc:`dpd <pair_dpd>` - dissipative particle dynamics (DPD)
* :doc:`dpd/ext <pair_dpd_ext>` - generalized force field for DPD
* :doc:`dpd/ext/tstat <pair_dpd_ext>` - pair-wise DPD thermostatting with generalized force field
* :doc:`dpd/ext/tstat <pair_dpd_ext>` - pairwise DPD thermostatting with generalized force field
* :doc:`dpd/fdt <pair_dpd_fdt>` - DPD for constant temperature and pressure
* :doc:`dpd/fdt/energy <pair_dpd_fdt>` - DPD for constant energy and enthalpy
* :doc:`dpd/tstat <pair_dpd>` - pair-wise DPD thermostatting
* :doc:`dpd/tstat <pair_dpd>` - pairwise DPD thermostatting
* :doc:`dsmc <pair_dsmc>` - Direct Simulation Monte Carlo (DSMC)
* :doc:`e3b <pair_e3b>` - Explicit-three body (E3B) water model
* :doc:`drip <pair_drip>` - Dihedral-angle-corrected registry-dependent interlayer potential (DRIP)
@ -183,10 +197,12 @@ accelerated styles exist.
* :doc:`gran/hooke/history <pair_gran>` - granular potential without history effects
* :doc:`gw <pair_gw>` - Gao-Weber potential
* :doc:`gw/zbl <pair_gw>` - Gao-Weber potential with a repulsive ZBL core
* :doc:`harmonic/cut <pair_harmonic_cut>` - repulsive-only harmonic potential
* :doc:`hbond/dreiding/lj <pair_hbond_dreiding>` - DREIDING hydrogen bonding LJ potential
* :doc:`hbond/dreiding/morse <pair_hbond_dreiding>` - DREIDING hydrogen bonding Morse potential
* :doc:`hdnnp <pair_hdnnp>` - High-dimensional neural network potential
* :doc:`ilp/graphene/hbn <pair_ilp_graphene_hbn>` - registry-dependent interlayer potential (ILP)
* :doc:`ilp/tmd <pair_ilp_tmd>` - interlayer potential (ILP) potential for transition metal dichalcogenides (TMD)
* :doc:`kim <pair_kim>` - interface to potentials provided by KIM project
* :doc:`kolmogorov/crespi/full <pair_kolmogorov_crespi_full>` - Kolmogorov-Crespi (KC) potential with no simplifications
* :doc:`kolmogorov/crespi/z <pair_kolmogorov_crespi_z>` - Kolmogorov-Crespi (KC) potential with normals along z-axis
@ -304,6 +320,7 @@ accelerated styles exist.
* :doc:`reaxff <pair_reaxff>` - ReaxFF potential
* :doc:`rebo <pair_airebo>` - second generation REBO potential of Brenner
* :doc:`resquared <pair_resquared>` - Everaers RE-Squared ellipsoidal potential
* :doc:`saip/metal <pair_saip_metal>` - interlayer potential for hetero-junctions formed with hexagonal 2D materials and metal surfaces
* :doc:`sdpd/taitwater/isothermal <pair_sdpd_taitwater_isothermal>` - smoothed dissipative particle dynamics for water at isothermal conditions
* :doc:`smd/hertz <pair_smd_hertz>` -
* :doc:`smd/tlsph <pair_smd_tlsph>` -

10
doc/src/pair_sw.rst
View File

@ -29,8 +29,8 @@ Syntax
.. parsed-literal::
*maxdelcs* value = delta1 delta2 (optional)
delta1 = The minimum thershold for cosine of three-body angle
delta2 = The maximum threshold for cosine of three-body angle
delta1 = The minimum thershold for the variation of cosine of three-body angle
delta2 = The maximum threshold for the variation of cosine of three-body angle
Examples
""""""""
@ -69,7 +69,7 @@ and K of atom I within a cutoff distance :math:`a `\sigma`.
The *sw/mod* style is designed for simulations of materials when
distinguishing three-body angles are necessary, such as borophene
and transition metal dichalcogenide, which cannot be described
and transition metal dichalcogenides, which cannot be described
by the original code for the Stillinger-Weber potential.
For instance, there are several types of angles around each Mo atom in `MoS_2`,
and some unnecessary angle types should be excluded in the three-body interaction.
@ -99,7 +99,7 @@ This smoothly turns off the energy and force contributions for :math:`\left| \de
It is suggested that :math:`\delta 1` and :math:`\delta_2` to be the value around
:math:`0.5 \left| \cos \theta_1 - \cos \theta_2 \right|`, with
:math:`\theta_1` and :math:`\theta_2` as the different types of angles around an atom.
For borophene and transition metal dichalcogenide, :math:`\delta_1 = 0.25` and :math:`\delta_2 = 0.35`.
For borophene and transition metal dichalcogenides, :math:`\delta_1 = 0.25` and :math:`\delta_2 = 0.35`.
This value enables the cut-off function to exclude unnecessary angles in the three-body SW terms.
.. note::
@ -202,7 +202,7 @@ elements are the same. Thus the two-body parameters for Si
interacting with C, comes from the SiCC entry. The three-body
parameters can in principle be specific to the three elements of the
configuration. In the literature, however, the three-body parameters
are usually defined by simple formulas involving two sets of pair-wise
are usually defined by simple formulas involving two sets of pairwise
parameters, corresponding to the ij and ik pairs, where i is the
center atom. The user must ensure that the correct combining rule is
used to calculate the values of the three-body parameters for

6
doc/src/pair_write.rst
View File

@ -76,8 +76,10 @@ must be set before this command can be invoked.
Due to how the pairwise force is computed, an inner value > 0.0 must
be specified even if the potential has a finite value at r = 0.0.
For EAM potentials, the pair_write command only tabulates the
pairwise portion of the potential, not the embedding portion.
The *pair_write* command can only be used for pairwise additive
interactions for which a `Pair::single()` function can be and has
been implemented. This excludes for example manybody potentials
or TIP4P coulomb styles.
Related commands
""""""""""""""""

2
doc/src/run_style.rst
View File

@ -89,7 +89,7 @@ in its 3d FFTs. In this scenario, splitting your P total processors
into 2 subsets of processors, P1 in the first partition and P2 in the
second partition, can enable your simulation to run faster. This is
because the long-range forces in PPPM can be calculated at the same
time as pair-wise and bonded forces are being calculated, and the FFTs
time as pairwise and bonded forces are being calculated, and the FFTs
can actually speed up when running on fewer processors.
To use this style, you must define 2 partitions where P1 is a multiple

9
doc/src/third_order.rst
View File

@ -1,8 +1,11 @@
.. index:: third_order
.. index:: third_order/kk
third_order command
===================
Accelerator Variants: third_order/kk
Syntax
""""""
@ -49,6 +52,12 @@ If the style eskm is selected, the tensor will be using energy units of 10 J/mol
These units conform to eskm style from the dynamical_matrix command, which
will simplify operations using dynamical matrices with third order tensors.
----------
.. include:: accel_styles.rst
----------
Restrictions
""""""""""""

2
doc/utils/check-styles.py
View File

@ -259,7 +259,7 @@ skip_pair = ('meam/c','lj/sf','reax/c')
counter = 0
counter += check_style('Commands_all.rst', doc_dir, ":doc:`(.+) <.+>`",command,'Command',suffix=False)
counter += check_style('Commands_all.rst', doc_dir, ":doc:`(.+) <.+>`",command,'Command',suffix=True)
counter += check_style('Commands_compute.rst', doc_dir, ":doc:`(.+) <compute.+>`",compute,'Compute',suffix=True)
counter += check_style('compute.rst', doc_dir, ":doc:`(.+) <compute.+>` -",compute,'Compute',suffix=False)
counter += check_style('Commands_fix.rst', doc_dir, ":doc:`(.+) <fix.+>`",fix,'Fix',skip=skip_fix,suffix=True)

245
doc/utils/sphinx-config/false_positives.txt
View File

File diff suppressed because it is too large Load Diff

249
examples/PACKAGES/cgdna/examples/test.sh
View File

@ -1,20 +1,24 @@
#! /bin/bash
DATE='2Jul21'
LMPDIR=/Users/ohenrich/Work/code/lammps
DATE='14Dec21'
TOL=1e-8
LMPDIR=/Users/ohenrich/Work/code/lammps
SRCDIR=$LMPDIR/src
EXDIR=$LMPDIR/examples/PACKAGES/cgdna/examples
if [ $# -eq 1 ] && [ $1 = run ]; then
echo '# Compiling executable in' $SRCDIR
echo '# Compiling executable in' $SRCDIR | tee -a $EXDIR/test.log
cd $SRCDIR
make clean-all
make -j8 mpi
make clean-all | tee -a $EXDIR/test.log
make purge | tee -a $EXDIR/test.log
make pu | tee -a $EXDIR/test.log
make ps | tee -a $EXDIR/test.log
make -j8 mpi | tee -a $EXDIR/test.log
######################################################
echo '# Running oxDNA duplex1 test'
echo '# Running oxDNA duplex1 test' | tee -a $EXDIR/test.log
cd $EXDIR/oxDNA/duplex1
mkdir test
cd test
@ -24,20 +28,32 @@ if [ $# -eq 1 ] && [ $1 = run ]; then
mpirun -np 1 ./lmp_mpi < in.duplex1 > /dev/null
mv log.lammps log.$DATE.duplex1.g++.1
grep etot log.$DATE.duplex1.g++.1 > e_test.dat
grep etot ../log*1 > e_old.dat
ndiff -relerr 1e-8 e_test.dat e_old.dat
grep etot log.$DATE.duplex1.g++.1 > e_test.1.dat
grep etot ../log*1 > e_old.1.dat
ndiff -relerr $TOL e_test.1.dat e_old.1.dat
if [ $? -eq 0 ];
then
echo "# 1 MPI-task passed" | tee -a $EXDIR/test.log
else
echo "# 1 MPI-task unsuccessful" | tee -a $EXDIR/test.log
fi
mpirun -np 4 ./lmp_mpi < in.duplex1 > /dev/null
mv log.lammps log.$DATE.duplex1.g++.4
grep etot log.$DATE.duplex1.g++.4 > e_test.dat
grep etot ../log*4 > e_old.dat
ndiff -relerr 1e-8 e_test.dat e_old.dat
grep etot log.$DATE.duplex1.g++.4 > e_test.4.dat
grep etot ../log*4 > e_old.4.dat
ndiff -relerr $TOL e_test.4.dat e_old.4.dat
if [ $? -eq 0 ];
then
echo "# 4 MPI-tasks passed" | tee -a $EXDIR/test.log
else
echo "# 4 MPI-tasks unsuccessful" | tee -a $EXDIR/test.log
fi
######################################################
######################################################
echo '# Running oxDNA duplex2 test'
echo '# Running oxDNA duplex2 test' | tee -a $EXDIR/test.log
cd $EXDIR/oxDNA/duplex2
mkdir test
cd test
@ -47,20 +63,32 @@ if [ $# -eq 1 ] && [ $1 = run ]; then
mpirun -np 1 ./lmp_mpi < in.duplex2 > /dev/null
mv log.lammps log.$DATE.duplex2.g++.1
grep etot log.$DATE.duplex2.g++.1 > e_test.dat
grep etot ../log*1 > e_old.dat
ndiff -relerr 1e-8 e_test.dat e_old.dat
grep etot log.$DATE.duplex2.g++.1 > e_test.1.dat
grep etot ../log*1 > e_old.1.dat
ndiff -relerr $TOL e_test.1.dat e_old.1.dat
if [ $? -eq 0 ];
then
echo "# 1 MPI-task passed" | tee -a $EXDIR/test.log
else
echo "# 1 MPI-task unsuccessful" | tee -a $EXDIR/test.log
fi
mpirun -np 4 ./lmp_mpi < in.duplex2 > /dev/null
mv log.lammps log.$DATE.duplex2.g++.4
grep etot log.$DATE.duplex2.g++.4 > e_test.dat
grep etot ../log*4 > e_old.dat
ndiff -relerr 1e-8 e_test.dat e_old.dat
grep etot log.$DATE.duplex2.g++.4 > e_test.4.dat
grep etot ../log*4 > e_old.4.dat
ndiff -relerr $TOL e_test.4.dat e_old.4.dat
if [ $? -eq 0 ];
then
echo "# 4 MPI-tasks passed" | tee -a $EXDIR/test.log
else
echo "# 4 MPI-tasks unsuccessful" | tee -a $EXDIR/test.log
fi
######################################################
######################################################
echo '# Running oxDNA2 duplex1 test'
echo '# Running oxDNA2 duplex1 test' | tee -a $EXDIR/test.log
cd $EXDIR/oxDNA2/duplex1
mkdir test
cd test
@ -70,20 +98,32 @@ if [ $# -eq 1 ] && [ $1 = run ]; then
mpirun -np 1 ./lmp_mpi < in.duplex1 > /dev/null
mv log.lammps log.$DATE.duplex1.g++.1
grep etot log.$DATE.duplex1.g++.1 > e_test.dat
grep etot ../log*1 > e_old.dat
ndiff -relerr 1e-8 e_test.dat e_old.dat
grep etot log.$DATE.duplex1.g++.1 > e_test.1.dat
grep etot ../log*1 > e_old.1.dat
ndiff -relerr $TOL e_test.1.dat e_old.1.dat
if [ $? -eq 0 ];
then
echo "# 1 MPI-task passed" | tee -a $EXDIR/test.log
else
echo "# 1 MPI-task unsuccessful" | tee -a $EXDIR/test.log
fi
mpirun -np 4 ./lmp_mpi < in.duplex1 > /dev/null
mv log.lammps log.$DATE.duplex1.g++.4
grep etot log.$DATE.duplex1.g++.4 > e_test.dat
grep etot ../log*4 > e_old.dat
ndiff -relerr 1e-8 e_test.dat e_old.dat
grep etot log.$DATE.duplex1.g++.4 > e_test.4.dat
grep etot ../log*4 > e_old.4.dat
ndiff -relerr $TOL e_test.4.dat e_old.4.dat
if [ $? -eq 0 ];
then
echo "# 4 MPI-tasks passed" | tee -a $EXDIR/test.log
else
echo "# 4 MPI-tasks unsuccessful" | tee -a $EXDIR/test.log
fi
######################################################
######################################################
echo '# Running oxDNA2 duplex2 test'
echo '# Running oxDNA2 duplex2 test' | tee -a $EXDIR/test.log
cd $EXDIR/oxDNA2/duplex2
mkdir test
cd test
@ -93,20 +133,32 @@ if [ $# -eq 1 ] && [ $1 = run ]; then
mpirun -np 1 ./lmp_mpi < in.duplex2 > /dev/null
mv log.lammps log.$DATE.duplex2.g++.1
grep etot log.$DATE.duplex2.g++.1 > e_test.dat
grep etot ../log*1 > e_old.dat
ndiff -relerr 1e-8 e_test.dat e_old.dat
grep etot log.$DATE.duplex2.g++.1 > e_test.1.dat
grep etot ../log*1 > e_old.1.dat
ndiff -relerr $TOL e_test.1.dat e_old.1.dat
if [ $? -eq 0 ];
then
echo "# 1 MPI-task passed" | tee -a $EXDIR/test.log
else
echo "# 1 MPI-task unsuccessful" | tee -a $EXDIR/test.log
fi
mpirun -np 4 ./lmp_mpi < in.duplex2 > /dev/null
mv log.lammps log.$DATE.duplex2.g++.4
grep etot log.$DATE.duplex2.g++.4 > e_test.dat
grep etot ../log*4 > e_old.dat
ndiff -relerr 1e-8 e_test.dat e_old.dat
grep etot log.$DATE.duplex2.g++.4 > e_test.4.dat
grep etot ../log*4 > e_old.4.dat
ndiff -relerr $TOL e_test.4.dat e_old.4.dat
if [ $? -eq 0 ];
then
echo "# 4 MPI-tasks passed" | tee -a $EXDIR/test.log
else
echo "# 4 MPI-tasks unsuccessful" | tee -a $EXDIR/test.log
fi
######################################################
######################################################
echo '# Running oxDNA2 duplex3 test'
echo '# Running oxDNA2 duplex3 test' | tee -a $EXDIR/test.log
cd $EXDIR/oxDNA2/duplex3
mkdir test
cd test
@ -116,20 +168,32 @@ if [ $# -eq 1 ] && [ $1 = run ]; then
mpirun -np 1 ./lmp_mpi < in.duplex3 > /dev/null
mv log.lammps log.$DATE.duplex3.g++.1
grep etot log.$DATE.duplex3.g++.1 > e_test.dat
grep etot ../log*1 > e_old.dat
ndiff -relerr 1e-8 e_test.dat e_old.dat
grep etot log.$DATE.duplex3.g++.1 > e_test.1.dat
grep etot ../log*1 > e_old.1.dat
ndiff -relerr $TOL e_test.1.dat e_old.1.dat
if [ $? -eq 0 ];
then
echo "# 1 MPI-task passed" | tee -a $EXDIR/test.log
else
echo "# 1 MPI-task unsuccessful" | tee -a $EXDIR/test.log
fi
mpirun -np 4 ./lmp_mpi < in.duplex3 > /dev/null
mv log.lammps log.$DATE.duplex3.g++.4
grep etot log.$DATE.duplex3.g++.4 > e_test.dat
grep etot ../log*4 > e_old.dat
ndiff -relerr 1e-8 e_test.dat e_old.dat
grep etot log.$DATE.duplex3.g++.4 > e_test.4.dat
grep etot ../log*4 > e_old.4.dat
ndiff -relerr $TOL e_test.4.dat e_old.4.dat
if [ $? -eq 0 ];
then
echo "# 4 MPI-tasks passed" | tee -a $EXDIR/test.log
else
echo "# 4 MPI-tasks unsuccessful" | tee -a $EXDIR/test.log
fi
######################################################
######################################################
echo '# Running oxDNA2 unique_bp test'
echo '# Running oxDNA2 unique_bp test' | tee -a $EXDIR/test.log
cd $EXDIR/oxDNA2/unique_bp
mkdir test
cd test
@ -141,32 +205,56 @@ if [ $# -eq 1 ] && [ $1 = run ]; then
mpirun -np 1 ./lmp_mpi < in.duplex4.4type > /dev/null
mv log.lammps log.$DATE.duplex4.4type.g++.1
grep etot log.$DATE.duplex4.4type.g++.1 > e_test.dat
grep etot ../log*4type*1 > e_old.dat
ndiff -relerr 1e-8 e_test.dat e_old.dat
grep etot log.$DATE.duplex4.4type.g++.1 > e_test.4type.1.dat
grep etot ../log*4type*1 > e_old.4type.1.dat
ndiff -relerr $TOL e_test.4type.1.dat e_old.4type.1.dat
if [ $? -eq 0 ];
then
echo "# 1 MPI-task 4 types passed" | tee -a $EXDIR/test.log
else
echo "# 1 MPI-task 4 types unsuccessful" | tee -a $EXDIR/test.log
fi
mpirun -np 4 ./lmp_mpi < in.duplex4.4type > /dev/null
mv log.lammps log.$DATE.duplex4.4type.g++.4
grep etot log.$DATE.duplex4.4type.g++.4 > e_test.dat
grep etot ../log*4type*4 > e_old.dat
ndiff -relerr 1e-8 e_test.dat e_old.dat
grep etot log.$DATE.duplex4.4type.g++.4 > e_test.4type.4.dat
grep etot ../log*4type*4 > e_old.4type.4.dat
ndiff -relerr $TOL e_test.4type.4.dat e_old.4type.4.dat
if [ $? -eq 0 ];
then
echo "# 4 MPI-tasks 4 types passed" | tee -a $EXDIR/test.log
else
echo "# 4 MPI-tasks 4 types unsuccessful" | tee -a $EXDIR/test.log
fi
mpirun -np 1 ./lmp_mpi < in.duplex4.8type > /dev/null
mv log.lammps log.$DATE.duplex4.8type.g++.1
grep etot log.$DATE.duplex4.8type.g++.1 > e_test.dat
grep etot ../log*8type*1 > e_old.dat
ndiff -relerr 1e-8 e_test.dat e_old.dat
grep etot log.$DATE.duplex4.8type.g++.1 > e_test.8type.1.dat
grep etot ../log*8type*1 > e_old.8type.1.dat
ndiff -relerr $TOL e_test.8type.1.dat e_old.8type.1.dat
if [ $? -eq 0 ];
then
echo "# 1 MPI-task 8 types passed" | tee -a $EXDIR/test.log
else
echo "# 1 MPI-task 8 types unsuccessful" | tee -a $EXDIR/test.log
fi
mpirun -np 4 ./lmp_mpi < in.duplex4.8type > /dev/null
mv log.lammps log.$DATE.duplex4.8type.g++.4
grep etot log.$DATE.duplex4.8type.g++.4 > e_test.dat
grep etot ../log*8type*4 > e_old.dat
ndiff -relerr 1e-8 e_test.dat e_old.dat
grep etot log.$DATE.duplex4.8type.g++.4 > e_test.8type.4.dat
grep etot ../log*8type*4 > e_old.8type.4.dat
ndiff -relerr $TOL e_test.8type.4.dat e_old.8type.4.dat
if [ $? -eq 0 ];
then
echo "# 4 MPI-tasks 8 types passed" | tee -a $EXDIR/test.log
else
echo "# 4 MPI-tasks 8 types unsuccessful" | tee -a $EXDIR/test.log
fi
######################################################
######################################################
echo '# Running oxDNA2 dsring test'
echo '# Running oxDNA2 dsring test' | tee -a $EXDIR/test.log
cd $EXDIR/oxDNA2/dsring
mkdir test
cd test
@ -176,20 +264,32 @@ if [ $# -eq 1 ] && [ $1 = run ]; then
mpirun -np 1 ./lmp_mpi < in.dsring > /dev/null
mv log.lammps log.$DATE.dsring.g++.1
grep etot log.$DATE.dsring.g++.1 > e_test.dat
grep etot ../log*1 > e_old.dat
ndiff -relerr 1e-8 e_test.dat e_old.dat
grep etot log.$DATE.dsring.g++.1 > e_test.1.dat
grep etot ../log*1 > e_old.1.dat
ndiff -relerr $TOL e_test.1.dat e_old.1.dat
if [ $? -eq 0 ];
then
echo "# 1 MPI-task passed" | tee -a $EXDIR/test.log
else
echo "# 1 MPI-task unsuccessful" | tee -a $EXDIR/test.log
fi
mpirun -np 4 ./lmp_mpi < in.dsring > /dev/null
mv log.lammps log.$DATE.dsring.g++.4
grep etot log.$DATE.dsring.g++.4 > e_test.dat
grep etot ../log*4 > e_old.dat
ndiff -relerr 1e-8 e_test.dat e_old.dat
grep etot log.$DATE.dsring.g++.4 > e_test.4.dat
grep etot ../log*4 > e_old.4.dat
ndiff -relerr $TOL e_test.4.dat e_old.4.dat
if [ $? -eq 0 ];
then
echo "# 4 MPI-tasks passed" | tee -a $EXDIR/test.log
else
echo "# 4 MPI-tasks unsuccessful" | tee -a $EXDIR/test.log
fi
######################################################
######################################################
echo '# Running oxRNA2 duplex2 test'
echo '# Running oxRNA2 duplex2 test' | tee -a $EXDIR/test.log
cd $EXDIR/oxRNA2/duplex2
mkdir test
cd test
@ -199,18 +299,30 @@ if [ $# -eq 1 ] && [ $1 = run ]; then
mpirun -np 1 ./lmp_mpi < in.duplex2 > /dev/null
mv log.lammps log.$DATE.duplex2.g++.1
grep etot log.$DATE.duplex2.g++.1 > e_test.dat
grep etot ../log*1 > e_old.dat
ndiff -relerr 1e-8 e_test.dat e_old.dat
grep etot log.$DATE.duplex2.g++.1 > e_test.1.dat
grep etot ../log*1 > e_old.1.dat
ndiff -relerr $TOL e_test.1.dat e_old.1.dat
if [ $? -eq 0 ];
then
echo "# 1 MPI-task passed" | tee -a $EXDIR/test.log
else
echo "# 1 MPI-task unsuccessful" | tee -a $EXDIR/test.log
fi
mpirun -np 4 ./lmp_mpi < in.duplex2 > /dev/null
mv log.lammps log.$DATE.duplex2.g++.4
grep etot log.$DATE.duplex2.g++.4 > e_test.dat
grep etot ../log*4 > e_old.dat
ndiff -relerr 1e-8 e_test.dat e_old.dat
grep etot log.$DATE.duplex2.g++.4 > e_test.4.dat
grep etot ../log*4 > e_old.4.dat
ndiff -relerr $TOL e_test.4.dat e_old.4.dat
if [ $? -eq 0 ];
then
echo "# 4 MPI-tasks passed" | tee -a $EXDIR/test.log
else
echo "# 4 MPI-tasks unsuccessful" | tee -a $EXDIR/test.log
fi
######################################################
echo '# Done'
echo '# Done' | tee -a $EXDIR/test.log
elif [ $# -eq 1 ] && [ $1 = clean ]; then
echo '# Deleting test directories'
@ -222,6 +334,7 @@ elif [ $# -eq 1 ] && [ $1 = clean ]; then
rm -rf $EXDIR/oxDNA2/unique_bp/test
rm -rf $EXDIR/oxDNA2/dsring/test
rm -rf $EXDIR/oxRNA2/duplex2/test
rm -rf $EXDIR/test.log
echo '# Done'
else

4
examples/PACKAGES/electron_stopping/Si.Si.elstop
View File

@ -1,8 +1,8 @@
# Electronic stopping for Si in Si
# Uses metal units
# Electronic stopping for Si in Si UNITS: metal DATE: 2019-02-19 CONTRIBUTOR: Risto Toijala risto.toijala@helsinki.fi
# Kinetic energy in eV, stopping power in eV/A
# For other atom types, add columns.
# atom type 1
# energy Si in Si
3918.2 6.541
15672.9 13.091

2
examples/PACKAGES/gle/qt-300k.A
View File

@ -1,3 +1,5 @@
# DATE: 2014-11-24 UNITS: real CONTRIBUTOR: Michele Ceriotti michele.ceriotti@gmail.com
3.904138445158e-4 4.681059722010e-2 3.079778738058e-2 4.428079381336e-2 5.057825203477e-2 2.591193419597e-2 1.513907125942e-2
-4.789343294190e-2 2.037551040972e-2 6.597801861779e-2 -8.528273506602e-3 -2.230839572773e-3 6.593086307870e-3 -6.653653981891e-2
-2.905096373618e-2 -6.597801861779e-2 2.086885297843e-2 1.145471984072e-2 3.111465343867e-2 1.101562087523e-2 -3.264959166486e-2

2
examples/PACKAGES/gle/qt-300k.C
View File

@ -1,3 +1,5 @@
# DATE: 2014-11-24 UNITS: real CONTRIBUTOR: Michele Ceriotti michele.ceriotti@gmail.com
2.999985914100e+2 5.937593337000e+0 2.144376751500e+2 5.883055908000e+1 -1.119803766000e+2 -6.793381764000e+1 1.379789732400e+1
5.937593337000e+0 3.781851303000e+2 -5.794518522000e+1 -2.178772681500e+2 -1.649310659100e+2 -6.557113452000e+1 3.833830743000e+1
2.144376751500e+2 -5.794518522000e+1 7.325759985000e+2 2.188507713000e+2 -3.704586531000e+2 -3.385193865000e+1 -4.827706758000e+0

2
examples/PACKAGES/gle/smart.A
View File

@ -1,3 +1,5 @@
# DATE: 2014-11-24 UNITS: real CONTRIBUTOR: Michele Ceriotti michele.ceriotti@gmail.com
4.247358737218e-3 3.231404593065e-2 -9.715629522215e-3 8.199488441225e-3 7.288427565896e-3 -3.634229949055e-3 -3.294395982200e-3
4.887738278128e-2 5.978602802893e-1 -2.079222967202e-1 1.088740438247e-1 4.666954324786e-2 -1.334147134493e-2 -3.914996645811e-2
4.015863091190e-2 2.079222967202e-1 1.645970119444e-1 8.351952991453e-2 5.114740085468e-2 1.217862237677e-2 -4.506711205974e-2

1
examples/PACKAGES/interlayer/ilp_graphene_hbn/BNCH.ILP Symbolic link
View File

@ -0,0 +1 @@
../../../../potentials/BNCH.ILP

1
examples/PACKAGES/interlayer/ilp_graphene_hbn/CH.rebo Symbolic link
View File

@ -0,0 +1 @@
../../../../potentials/CH.rebo

1
examples/PACKAGES/interlayer/ilp_tmds/MoS2.ILP Symbolic link
View File

@ -0,0 +1 @@
../../../../potentials/MoS2.ILP

1549
examples/PACKAGES/interlayer/ilp_tmds/bilayer_MoS2_AAprime_stacking.data Normal file
View File

File diff suppressed because it is too large Load Diff

36
examples/PACKAGES/interlayer/ilp_tmds/in.mos2 Normal file
View File

@ -0,0 +1,36 @@
units metal
atom_style full
processors * * 1
boundary p p f
read_data ./bilayer_MoS2_AAprime_stacking.data
mass * 32.065 # mass of sulphur atom , uint: a.u.=1.66X10^(-27)kg
mass 1 95.94 # mass of molebdenum atom , uint: a.u.=1.66X10^(-27)kg
mass 4 95.94
# Define potentials
pair_style hybrid/overlay sw/mod sw/mod ilp/tmd 16.0
pair_coeff * * sw/mod 1 tmd.sw.mod Mo S S NULL NULL NULL
pair_coeff * * sw/mod 2 tmd.sw.mod NULL NULL NULL Mo S S
pair_coeff * * ilp/tmd MoS2.ILP Mo S S Mo S S
# Calculate the pair potential
compute 0 all pair ilp/tmd
compute 1 all pair sw/mod 1
compute 2 all pair sw/mod 2
variable SW1 equal c_1
variable SW2 equal c_2
variable ILP equal c_0
variable Eatt equal c_0[1]
variable Erep equal c_0[2]
thermo_style custom step etotal pe ke v_SW1 v_SW2 v_ILP v_Erep v_Eatt temp
thermo 100
thermo_modify lost error
timestep 1e-3
velocity all create 300.0 12345
fix intall all nve
run 1000

154
examples/PACKAGES/interlayer/ilp_tmds/log.7Jan22.mos2.g++.1 Normal file
View File

@ -0,0 +1,154 @@
LAMMPS (7 Jan 2022)
OMP_NUM_THREADS environment is not set. Defaulting to 1 thread. (../comm.cpp:98)
using 1 OpenMP thread(s) per MPI task
units metal
atom_style full
processors * * 1
boundary p p f
read_data ./bilayer_MoS2_AAprime_stacking.data
Reading data file ...
triclinic box = (0 0 -100) to (51.15232 44.299209 100) with tilt (25.57616 0 0)
1 by 1 by 1 MPI processor grid
reading atoms ...
1536 atoms
Finding 1-2 1-3 1-4 neighbors ...
special bond factors lj: 0 0 0
special bond factors coul: 0 0 0
0 = max # of 1-2 neighbors
0 = max # of 1-3 neighbors
0 = max # of 1-4 neighbors
1 = max # of special neighbors
special bonds CPU = 0.001 seconds
read_data CPU = 0.007 seconds
mass * 32.065 # mass of sulphur atom , uint: a.u.=1.66X10^(-27)kg
mass 1 95.94 # mass of molebdenum atom , uint: a.u.=1.66X10^(-27)kg
mass 4 95.94
# Define potentials
pair_style hybrid/overlay sw/mod sw/mod ilp/tmd 16.0
pair_coeff * * sw/mod 1 tmd.sw.mod Mo S S NULL NULL NULL
Reading sw potential file tmd.sw.mod with DATE: 2018-03-26
pair_coeff * * sw/mod 2 tmd.sw.mod NULL NULL NULL Mo S S
Reading sw potential file tmd.sw.mod with DATE: 2018-03-26
pair_coeff * * ilp/tmd MoS2.ILP Mo S S Mo S S
Reading ilp/tmd potential file MoS2.ILP with DATE: 2021-12-02
# Calculate the pair potential
compute 0 all pair ilp/tmd
compute 1 all pair sw/mod 1
compute 2 all pair sw/mod 2
variable SW1 equal c_1
variable SW2 equal c_2
variable ILP equal c_0
variable Eatt equal c_0[1]
variable Erep equal c_0[2]
thermo_style custom step etotal pe ke v_SW1 v_SW2 v_ILP v_Erep v_Eatt temp
thermo 100
thermo_modify lost error
timestep 1e-3
velocity all create 300.0 12345
fix intall all nve
run 1000
CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE
Your simulation uses code contributions which should be cited:
- ilp/graphene/hbn potential doi:10.1021/acs.nanolett.8b02848
@Article{Ouyang2018
author = {W. Ouyang, D. Mandelli, M. Urbakh, and O. Hod},
title = {Nanoserpents: Graphene Nanoribbon Motion on Two-Dimensional Hexagonal Materials},
journal = {Nano Letters},
volume = 18,
pages = {6009}
year = 2018,
}
- ilp/tmd potential doi/10.1021/acs.jctc.1c00782
@Article{Ouyang2021
author = {W. Ouyang, R. Sofer, X. Gao, J. Hermann, A. Tkatchenko, L. Kronik, M. Urbakh, and O. Hod},
title = {Anisotropic Interlayer Force Field for Transition Metal Dichalcogenides: The Case of Molybdenum Disulfide},
journal = {J. Chem. Theory Comput.},
volume = 17,
pages = {7237–7245}
year = 2021,
}
CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE
Neighbor list info ...
update every 1 steps, delay 10 steps, check yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 18
ghost atom cutoff = 18
binsize = 9, bins = 9 5 23
4 neighbor lists, perpetual/occasional/extra = 4 0 0
(1) pair sw/mod, perpetual, skip from (4)
attributes: full, newton on
pair build: skip
stencil: none
bin: none
(2) pair sw/mod, perpetual, skip from (4)
attributes: full, newton on
pair build: skip
stencil: none
bin: none
(3) pair ilp/tmd, perpetual
attributes: full, newton on, ghost
pair build: full/bin/ghost
stencil: full/ghost/bin/3d
bin: standard
(4) neighbor class addition, perpetual, copy from (3)
attributes: full, newton on
pair build: copy
stencil: none
bin: none
Per MPI rank memory allocation (min/avg/max) = 30.29 | 30.29 | 30.29 Mbytes
Step TotEng PotEng KinEng v_SW1 v_SW2 v_ILP v_Erep v_Eatt Temp
0 -1834.4469 -1893.9712 59.524297 -929.02881 -929.02881 -35.913549 63.00343 -98.916979 300
100 -1834.4497 -1883.3105 48.860775 -924.84264 -925.08505 -33.382796 56.58255 -89.965346 246.25629
200 -1834.4381 -1873.7072 39.269085 -922.29961 -922.52535 -28.882252 50.08277 -78.965022 197.91457
300 -1834.4483 -1881.1263 46.678028 -923.39264 -923.65627 -34.077402 51.011967 -85.089369 235.25534
400 -1834.431 -1868.0728 33.64182 -916.85743 -916.27044 -34.944916 50.414038 -85.358954 169.55338
500 -1834.4499 -1881.9059 47.456 -925.22919 -924.29582 -32.380877 44.755168 -77.136045 239.17628
600 -1834.4343 -1869.8642 35.429976 -920.97805 -919.60784 -29.278358 43.270241 -72.548599 178.56562
700 -1834.443 -1878.144 43.700934 -921.8051 -921.55671 -34.782141 49.959943 -84.742084 220.2509
800 -1834.4327 -1869.824 35.391298 -917.19193 -917.91383 -34.718247 55.349728 -90.067976 178.37068
900 -1834.4465 -1877.6741 43.227638 -923.33877 -922.50874 -31.826599 53.965592 -85.792191 217.86551
1000 -1834.4412 -1876.1808 41.739587 -923.17282 -923.49367 -29.514347 55.454643 -84.96899 210.3658
Loop time of 72.8218 on 1 procs for 1000 steps with 1536 atoms
Performance: 1.186 ns/day, 20.228 hours/ns, 13.732 timesteps/s
99.6% CPU use with 1 MPI tasks x 1 OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 72.781 | 72.781 | 72.781 | 0.0 | 99.94
Bond | 0.00014503 | 0.00014503 | 0.00014503 | 0.0 | 0.00
Neigh | 0 | 0 | 0 | 0.0 | 0.00
Comm | 0.016691 | 0.016691 | 0.016691 | 0.0 | 0.02
Output | 0.00057989 | 0.00057989 | 0.00057989 | 0.0 | 0.00
Modify | 0.013405 | 0.013405 | 0.013405 | 0.0 | 0.02
Other | | 0.01044 | | | 0.01
Nlocal: 1536 ave 1536 max 1536 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Nghost: 3510 ave 3510 max 3510 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Neighs: 0 ave 0 max 0 min
Histogram: 1 0 0 0 0 0 0 0 0 0
FullNghs: 992256 ave 992256 max 992256 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Total # of neighbors = 992256
Ave neighs/atom = 646
Ave special neighs/atom = 0
Neighbor list builds = 0
Dangerous builds = 0
Total wall time: 0:01:12

154
examples/PACKAGES/interlayer/ilp_tmds/log.7Jan22.mos2.g++.4 Normal file
View File

@ -0,0 +1,154 @@
LAMMPS (7 Jan 2022)
OMP_NUM_THREADS environment is not set. Defaulting to 1 thread. (../comm.cpp:98)
using 1 OpenMP thread(s) per MPI task
units metal
atom_style full
processors * * 1
boundary p p f
read_data ./bilayer_MoS2_AAprime_stacking.data
Reading data file ...
triclinic box = (0 0 -100) to (51.15232 44.299209 100) with tilt (25.57616 0 0)
2 by 2 by 1 MPI processor grid
reading atoms ...
1536 atoms
Finding 1-2 1-3 1-4 neighbors ...
special bond factors lj: 0 0 0
special bond factors coul: 0 0 0
0 = max # of 1-2 neighbors
0 = max # of 1-3 neighbors
0 = max # of 1-4 neighbors
1 = max # of special neighbors
special bonds CPU = 0.000 seconds
read_data CPU = 0.007 seconds
mass * 32.065 # mass of sulphur atom , uint: a.u.=1.66X10^(-27)kg
mass 1 95.94 # mass of molebdenum atom , uint: a.u.=1.66X10^(-27)kg
mass 4 95.94
# Define potentials
pair_style hybrid/overlay sw/mod sw/mod ilp/tmd 16.0
pair_coeff * * sw/mod 1 tmd.sw.mod Mo S S NULL NULL NULL
Reading sw potential file tmd.sw.mod with DATE: 2018-03-26
pair_coeff * * sw/mod 2 tmd.sw.mod NULL NULL NULL Mo S S
Reading sw potential file tmd.sw.mod with DATE: 2018-03-26
pair_coeff * * ilp/tmd MoS2.ILP Mo S S Mo S S
Reading ilp/tmd potential file MoS2.ILP with DATE: 2021-12-02
# Calculate the pair potential
compute 0 all pair ilp/tmd
compute 1 all pair sw/mod 1
compute 2 all pair sw/mod 2
variable SW1 equal c_1
variable SW2 equal c_2
variable ILP equal c_0
variable Eatt equal c_0[1]
variable Erep equal c_0[2]
thermo_style custom step etotal pe ke v_SW1 v_SW2 v_ILP v_Erep v_Eatt temp
thermo 100
thermo_modify lost error
timestep 1e-3
velocity all create 300.0 12345
fix intall all nve
run 1000
CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE
Your simulation uses code contributions which should be cited:
- ilp/graphene/hbn potential doi:10.1021/acs.nanolett.8b02848
@Article{Ouyang2018
author = {W. Ouyang, D. Mandelli, M. Urbakh, and O. Hod},
title = {Nanoserpents: Graphene Nanoribbon Motion on Two-Dimensional Hexagonal Materials},
journal = {Nano Letters},
volume = 18,
pages = {6009}
year = 2018,
}
- ilp/tmd potential doi/10.1021/acs.jctc.1c00782
@Article{Ouyang2021
author = {W. Ouyang, R. Sofer, X. Gao, J. Hermann, A. Tkatchenko, L. Kronik, M. Urbakh, and O. Hod},
title = {Anisotropic Interlayer Force Field for Transition Metal Dichalcogenides: The Case of Molybdenum Disulfide},
journal = {J. Chem. Theory Comput.},
volume = 17,
pages = {7237–7245}
year = 2021,
}
CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE
Neighbor list info ...
update every 1 steps, delay 10 steps, check yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 18
ghost atom cutoff = 18
binsize = 9, bins = 9 5 23
4 neighbor lists, perpetual/occasional/extra = 4 0 0
(1) pair sw/mod, perpetual, skip from (4)
attributes: full, newton on
pair build: skip
stencil: none
bin: none
(2) pair sw/mod, perpetual, skip from (4)
attributes: full, newton on
pair build: skip
stencil: none
bin: none
(3) pair ilp/tmd, perpetual
attributes: full, newton on, ghost
pair build: full/bin/ghost
stencil: full/ghost/bin/3d
bin: standard
(4) neighbor class addition, perpetual, copy from (3)
attributes: full, newton on
pair build: copy
stencil: none
bin: none
Per MPI rank memory allocation (min/avg/max) = 17.98 | 17.98 | 17.98 Mbytes
Step TotEng PotEng KinEng v_SW1 v_SW2 v_ILP v_Erep v_Eatt Temp
0 -1834.4469 -1893.9712 59.524297 -929.02881 -929.02881 -35.913549 63.00343 -98.916979 300
100 -1834.4497 -1883.3105 48.860775 -924.84264 -925.08505 -33.382796 56.58255 -89.965346 246.25629
200 -1834.4381 -1873.7072 39.269085 -922.29961 -922.52535 -28.882252 50.08277 -78.965022 197.91457
300 -1834.4483 -1881.1263 46.678028 -923.39264 -923.65627 -34.077402 51.011967 -85.089369 235.25534
400 -1834.431 -1868.0728 33.64182 -916.85743 -916.27044 -34.944916 50.414038 -85.358954 169.55338
500 -1834.4499 -1881.9059 47.456 -925.22919 -924.29582 -32.380877 44.755168 -77.136045 239.17628
600 -1834.4343 -1869.8642 35.429976 -920.97805 -919.60784 -29.278358 43.270241 -72.548599 178.56562
700 -1834.443 -1878.144 43.700934 -921.8051 -921.55671 -34.782141 49.959943 -84.742084 220.2509
800 -1834.4327 -1869.824 35.391298 -917.19193 -917.91383 -34.718247 55.349728 -90.067976 178.37068
900 -1834.4465 -1877.6741 43.227638 -923.33877 -922.50874 -31.826599 53.965592 -85.792191 217.86551
1000 -1834.4412 -1876.1808 41.739587 -923.17282 -923.49367 -29.514347 55.454643 -84.96899 210.3658
Loop time of 24.6309 on 4 procs for 1000 steps with 1536 atoms
Performance: 3.508 ns/day, 6.842 hours/ns, 40.599 timesteps/s
99.7% CPU use with 4 MPI tasks x 1 OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 22.906 | 23.627 | 24.36 | 14.0 | 95.92
Bond | 0.00010889 | 0.00011572 | 0.00012719 | 0.0 | 0.00
Neigh | 0 | 0 | 0 | 0.0 | 0.00
Comm | 0.25886 | 0.992 | 1.7126 | 68.3 | 4.03
Output | 0.00050901 | 0.00054202 | 0.00062029 | 0.0 | 0.00
Modify | 0.0030735 | 0.0033236 | 0.0035581 | 0.3 | 0.01
Other | | 0.008194 | | | 0.03
Nlocal: 384 ave 387 max 381 min
Histogram: 1 0 0 0 0 2 0 0 0 1
Nghost: 2262 ave 2265 max 2259 min
Histogram: 1 0 0 0 0 2 0 0 0 1
Neighs: 0 ave 0 max 0 min
Histogram: 4 0 0 0 0 0 0 0 0 0
FullNghs: 248064 ave 250002 max 246126 min
Histogram: 1 0 0 0 0 2 0 0 0 1
Total # of neighbors = 992256
Ave neighs/atom = 646
Ave special neighs/atom = 0
Neighbor list builds = 0
Dangerous builds = 0
Total wall time: 0:00:24

143
examples/PACKAGES/interlayer/ilp_tmds/tmd.sw.mod Normal file
View File

@ -0,0 +1,143 @@
# DATE: 2018-03-26 UNITS: metal CONTRIBUTOR: Jin-Wu Jiang jwjiang5918@hotmail.com
# CITATION: J.-W. Jiang, Acta Mech. Solida. Sin 32, 17 (2019).
# The Stillinger-Weber parameters, for transition-metal dichalcogenide (TMD) lateral heterostructures.
# M = Mo, W; X = S, Se, Te
# these entries are in LAMMPS "metal" units:
# epsilon = eV; sigma = Angstroms
# other quantities are unitless
# format of a single entry (one or more lines):
# element 1, element 2, element 3,
# epsilon, sigma, a, lambda, gamma, costheta0, A, B, p, q, tol
# M-X-X terms
Mo S S 1.000 1.252 2.523 67.883 1.000 0.143 6.918 7.223 4 0 0.0
Mo Se Se 1.000 0.913 3.672 32.526 1.000 0.143 5.737 27.084 4 0 0.0
Mo Te Te 1.000 0.880 4.097 23.705 1.000 0.143 5.086 40.810 4 0 0.0
W S S 1.000 0.889 3.558 37.687 1.000 0.143 5.664 24.525 4 0 0.0
W Se Se 1.000 0.706 4.689 25.607 1.000 0.143 5.476 65.662 4 0 0.0
W Te Te 1.000 0.778 4.632 21.313 1.000 0.143 4.326 62.148 4 0 0.0
# X-M-M terms
S Mo Mo 1.000 1.252 2.523 62.449 1.000 0.143 6.918 7.223 4 0 0.0
S W W 1.000 0.889 3.558 33.553 1.000 0.143 5.664 24.525 4 0 0.0
Se Mo Mo 1.000 0.913 3.672 27.079 1.000 0.143 5.737 27.084 4 0 0.0
Se W W 1.000 0.706 4.689 23.218 1.000 0.143 5.476 65.662 4 0 0.0
Te Mo Mo 1.000 0.880 4.097 20.029 1.000 0.143 5.086 40.810 4 0 0.0
Te W W 1.000 0.778 4.632 17.370 1.000 0.143 4.326 62.148 4 0 0.0
# M-X1-X2 terms
Mo S Se 1.000 0.000 0.000 46.989 1.000 0.143 0.000 0.000 4 0 0.0
Mo S Te 1.000 0.000 0.000 40.114 1.000 0.143 0.000 0.000 4 0 0.0
Mo Se S 1.000 0.000 0.000 46.989 1.000 0.143 0.000 0.000 4 0 0.0
Mo Se Te 1.000 0.000 0.000 27.767 1.000 0.143 0.000 0.000 4 0 0.0
Mo Te S 1.000 0.000 0.000 40.114 1.000 0.143 0.000 0.000 4 0 0.0
Mo Te Se 1.000 0.000 0.000 27.767 1.000 0.143 0.000 0.000 4 0 0.0
W S Se 1.000 0.000 0.000 31.065 1.000 0.143 0.000 0.000 4 0 0.0
W S Te 1.000 0.000 0.000 28.341 1.000 0.143 0.000 0.000 4 0 0.0
W Se S 1.000 0.000 0.000 31.065 1.000 0.143 0.000 0.000 4 0 0.0
W Se Te 1.000 0.000 0.000 23.362 1.000 0.143 0.000 0.000 4 0 0.0
W Te S 1.000 0.000 0.000 28.341 1.000 0.143 0.000 0.000 4 0 0.0
W Te Se 1.000 0.000 0.000 23.362 1.000 0.143 0.000 0.000 4 0 0.0
# X-M1-M2 terms
S Mo W 1.000 0.000 0.000 45.775 1.000 0.143 0.000 0.000 4 0 0.0
S W Mo 1.000 0.000 0.000 45.775 1.000 0.143 0.000 0.000 4 0 0.0
Se Mo W 1.000 0.000 0.000 25.074 1.000 0.143 0.000 0.000 4 0 0.0
Se W Mo 1.000 0.000 0.000 25.074 1.000 0.143 0.000 0.000 4 0 0.0
Te Mo W 1.000 0.000 0.000 18.652 1.000 0.143 0.000 0.000 4 0 0.0
Te W Mo 1.000 0.000 0.000 18.652 1.000 0.143 0.000 0.000 4 0 0.0
# zero terms
Mo Mo Mo 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Mo Mo W 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Mo Mo S 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Mo Mo Se 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Mo Mo Te 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Mo W Mo 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Mo W W 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Mo W S 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Mo W Se 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Mo W Te 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Mo S Mo 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Mo S W 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Mo Se Mo 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Mo Se W 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Mo Te Mo 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Mo Te W 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
W Mo Mo 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
W Mo W 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
W Mo S 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
W Mo Se 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
W Mo Te 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
W W Mo 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
W W W 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
W W S 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
W W Se 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
W W Te 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
W S Mo 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
W S W 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
W Se Mo 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
W Se W 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
W Te Mo 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
W Te W 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
S Mo S 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
S Mo Se 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
S Mo Te 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
S W S 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
S W Se 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
S W Te 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
S S Mo 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
S S W 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
S S S 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
S S Se 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
S S Te 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
S Se Mo 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
S Se W 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
S Se S 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
S Se Se 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
S Se Te 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
S Te Mo 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
S Te W 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
S Te S 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
S Te Se 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
S Te Te 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Se Mo S 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Se Mo Se 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Se Mo Te 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Se W S 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Se W Se 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Se W Te 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Se S Mo 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Se S W 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Se S S 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Se S Se 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Se S Te 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Se Se Mo 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Se Se W 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Se Se S 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Se Se Se 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Se Se Te 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Se Te Mo 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Se Te W 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Se Te S 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Se Te Se 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Se Te Te 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Te Mo S 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Te Mo Se 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Te Mo Te 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Te W S 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Te W Se 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Te W Te 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Te S Mo 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Te S W 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Te S S 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Te S Se 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Te S Te 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Te Se Mo 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Te Se W 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Te Se S 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Te Se Se 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Te Se Te 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Te Te Mo 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Te Te W 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Te Te S 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Te Te Se 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0
Te Te Te 0.000 1.000 1.000 1.000 1.000 0.143 1.000 1.000 4 0 0.0

218
examples/PACKAGES/interlayer/saip_metal/3Lgold_1Lgr_atop_sliding.data Normal file
View File

@ -0,0 +1,218 @@
Gold/graphene heterjunction atop2
206 atoms
2 atom types
0 17.216640 xlo xhi
0 14.910048 ylo yhi
-30 30.000000 zlo zhi
8.60832 0 0 xy xz yz
Atoms
1 1 1 0 -8.60832 -4.97002 3.5
2 1 1 0 -7.1736 -4.14166 5.85461
3 1 1 0 -5.73888 -3.31334 8.20922
4 1 1 0 -7.1736 -2.48501 3.5
5 1 1 0 -5.73888 -1.65666 5.85461
6 1 1 0 -4.30416 -0.828336 8.20922
7 1 1 0 -5.73888 0 3.5
8 1 1 0 -4.30416 0.828352 5.85461
9 1 1 0 -2.86944 1.65667 8.20922
10 1 1 0 -4.30416 2.48501 3.5
11 1 1 0 -2.86944 3.31336 5.85461
12 1 1 0 -1.43472 4.14168 8.20922
13 1 1 0 -2.86944 4.97002 3.5
14 1 1 0 -1.43472 5.79837 5.85461
15 1 1 0 0 6.62669 8.20922
16 1 1 0 -1.43472 7.45502 3.5
17 1 1 0 0 8.28337 5.85461
18 1 1 0 1.43472 9.11167 8.20922
19 1 1 0 -5.73888 -4.97002 3.5
20 1 1 0 -4.30416 -4.14166 5.85461
21 1 1 0 -2.86944 -3.31334 8.20922
22 1 1 0 -4.30416 -2.48501 3.5
23 1 1 0 -2.86944 -1.65666 5.85461
24 1 1 0 -1.43472 -0.828336 8.20922
25 1 1 0 -2.86944 0 3.5
26 1 1 0 -1.43472 0.828352 5.85461
27 1 1 0 0 1.65667 8.20922
28 1 1 0 -1.43472 2.48501 3.5
29 1 1 0 0 3.31336 5.85461
30 1 1 0 1.43472 4.14168 8.20922
31 1 1 0 0 4.97002 3.5
32 1 1 0 1.43472 5.79837 5.85461
33 1 1 0 2.86944 6.62669 8.20922
34 1 1 0 1.43472 7.45502 3.5
35 1 1 0 2.86944 8.28337 5.85461
36 1 1 0 4.30416 9.11167 8.20922
37 1 1 0 -2.86944 -4.97002 3.5
38 1 1 0 -1.43472 -4.14166 5.85461
39 1 1 0 0 -3.31334 8.20922
40 1 1 0 -1.43472 -2.48501 3.5
41 1 1 0 0 -1.65666 5.85461
42 1 1 0 1.43472 -0.828336 8.20922
43 1 1 0 0 0 3.5
44 1 1 0 1.43472 0.828352 5.85461
45 1 1 0 2.86944 1.65667 8.20922
46 1 1 0 1.43472 2.48501 3.5
47 1 1 0 2.86944 3.31336 5.85461
48 1 1 0 4.30416 4.14168 8.20922
49 1 1 0 2.86944 4.97002 3.5
50 1 1 0 4.30416 5.79837 5.85461
51 1 1 0 5.73888 6.62669 8.20922
52 1 1 0 4.30416 7.45502 3.5
53 1 1 0 5.73888 8.28337 5.85461
54 1 1 0 7.1736 9.11167 8.20922
55 1 1 0 0 -4.97002 3.5
56 1 1 0 1.43472 -4.14166 5.85461
57 1 1 0 2.86944 -3.31334 8.20922
58 1 1 0 1.43472 -2.48501 3.5
59 1 1 0 2.86944 -1.65666 5.85461
60 1 1 0 4.30416 -0.828336 8.20922
61 1 1 0 2.86944 0 3.5
62 1 1 0 4.30416 0.828352 5.85461
63 1 1 0 5.73888 1.65667 8.20922
64 1 1 0 4.30416 2.48501 3.5
65 1 1 0 5.73888 3.31336 5.85461
66 1 1 0 7.1736 4.14168 8.20922
67 1 1 0 5.73888 4.97002 3.5
68 1 1 0 7.1736 5.79837 5.85461
69 1 1 0 8.60832 6.62669 8.20922
70 1 1 0 7.1736 7.45502 3.5
71 1 1 0 8.60832 8.28337 5.85461
72 1 1 0 10.0431 9.11167 8.20922
73 1 1 0 2.86944 -4.97002 3.5
74 1 1 0 4.30416 -4.14166 5.85461
75 1 1 0 5.73888 -3.31334 8.20922
76 1 1 0 4.30416 -2.48501 3.5
77 1 1 0 5.73888 -1.65666 5.85461
78 1 1 0 7.1736 -0.828336 8.20922
79 1 1 0 5.73888 0 3.5
80 1 1 0 7.1736 0.828352 5.85461
81 1 1 0 8.60832 1.65667 8.20922
82 1 1 0 7.1736 2.48501 3.5
83 1 1 0 8.60832 3.31336 5.85461
84 1 1 0 10.0431 4.14168 8.20922
85 1 1 0 8.60832 4.97002 3.5
86 1 1 0 10.0431 5.79837 5.85461
87 1 1 0 11.4777 6.62669 8.20922
88 1 1 0 10.0431 7.45502 3.5
89 1 1 0 11.4777 8.28337 5.85461
90 1 1 0 12.9124 9.11167 8.20922
91 1 1 0 5.73888 -4.97002 3.5
92 1 1 0 7.1736 -4.14166 5.85461
93 1 1 0 8.60832 -3.31334 8.20922
94 1 1 0 7.1736 -2.48501 3.5
95 1 1 0 8.60832 -1.65666 5.85461
96 1 1 0 10.0431 -0.828336 8.20922
97 1 1 0 8.60832 0 3.5
98 1 1 0 10.0431 0.828352 5.85461
99 1 1 0 11.4777 1.65667 8.20922
100 1 1 0 10.0431 2.48501 3.5
101 1 1 0 11.4777 3.31336 5.85461
102 1 1 0 12.9124 4.14168 8.20922
103 1 1 0 11.4777 4.97002 3.5
104 1 1 0 12.9124 5.79837 5.85461
105 1 1 0 14.3472 6.62669 8.20922
106 1 1 0 12.9124 7.45502 3.5
107 1 1 0 14.3472 8.28337 5.85461
108 1 1 0 15.7819 9.11167 8.20922
109 2 2 0 -11.0678 -6.39002 0
110 2 2 0 -9.83808 -5.68001 0
111 2 2 0 -9.83808 -4.26001 0
112 2 2 0 -8.60832 -3.55001 0
113 2 2 0 -8.60832 -2.13001 0
114 2 2 0 -7.37856 -1.42 0
115 2 2 0 -7.37856 0 0
116 2 2 0 -6.1488 0.710007 0
117 2 2 0 -6.1488 2.13001 0
118 2 2 0 -4.91904 2.84001 0
119 2 2 0 -4.91904 4.26001 0
120 2 2 0 -3.68928 4.97002 0
121 2 2 0 -3.68928 6.39002 0
122 2 2 0 -2.45952 7.10003 0
123 2 2 0 -8.60832 -6.39002 0
124 2 2 0 -7.37856 -5.68001 0
125 2 2 0 -7.37856 -4.26001 0
126 2 2 0 -6.1488 -3.55001 0
127 2 2 0 -6.1488 -2.13001 0
128 2 2 0 -4.91904 -1.42 0
129 2 2 0 -4.91904 0 0
130 2 2 0 -3.68928 0.710007 0
131 2 2 0 -3.68928 2.13001 0
132 2 2 0 -2.45952 2.84001 0
133 2 2 0 -2.45952 4.26001 0
134 2 2 0 -1.22976 4.97002 0
135 2 2 0 -1.22976 6.39002 0
136 2 2 0 0 7.10003 0
137 2 2 0 -6.1488 -6.39002 0
138 2 2 0 -4.91904 -5.68001 0
139 2 2 0 -4.91904 -4.26001 0
140 2 2 0 -3.68928 -3.55001 0
141 2 2 0 -3.68928 -2.13001 0
142 2 2 0 -2.45952 -1.42 0
143 2 2 0 -2.45952 0 0
144 2 2 0 -1.22976 0.710007 0
145 2 2 0 -1.22976 2.13001 0
146 2 2 0 0 2.84001 0
147 2 2 0 0 4.26001 0
148 2 2 0 1.22976 4.97002 0
149 2 2 0 1.22976 6.39002 0
150 2 2 0 2.45952 7.10003 0
151 2 2 0 -3.68928 -6.39002 0
152 2 2 0 -2.45952 -5.68001 0
153 2 2 0 -2.45952 -4.26001 0
154 2 2 0 -1.22976 -3.55001 0
155 2 2 0 -1.22976 -2.13001 0
156 2 2 0 0 -1.42 0
157 2 2 0 0 0 0
158 2 2 0 1.22976 0.710007 0
159 2 2 0 1.22976 2.13001 0
160 2 2 0 2.45952 2.84001 0
161 2 2 0 2.45952 4.26001 0
162 2 2 0 3.68928 4.97002 0
163 2 2 0 3.68928 6.39002 0
164 2 2 0 4.91904 7.10003 0
165 2 2 0 -1.22976 -6.39002 0
166 2 2 0 0 -5.68001 0
167 2 2 0 0 -4.26001 0
168 2 2 0 1.22976 -3.55001 0
169 2 2 0 1.22976 -2.13001 0
170 2 2 0 2.45952 -1.42 0
171 2 2 0 2.45952 0 0
172 2 2 0 3.68928 0.710007 0
173 2 2 0 3.68928 2.13001 0
174 2 2 0 4.91904 2.84001 0
175 2 2 0 4.91904 4.26001 0
176 2 2 0 6.1488 4.97002 0
177 2 2 0 6.1488 6.39002 0
178 2 2 0 7.37856 7.10003 0
179 2 2 0 1.22976 -6.39002 0
180 2 2 0 2.45952 -5.68001 0
181 2 2 0 2.45952 -4.26001 0
182 2 2 0 3.68928 -3.55001 0
183 2 2 0 3.68928 -2.13001 0
184 2 2 0 4.91904 -1.42 0
185 2 2 0 4.91904 0 0
186 2 2 0 6.1488 0.710007 0
187 2 2 0 6.1488 2.13001 0
188 2 2 0 7.37856 2.84001 0
189 2 2 0 7.37856 4.26001 0
190 2 2 0 8.60832 4.97002 0
191 2 2 0 8.60832 6.39002 0
192 2 2 0 9.83808 7.10003 0
193 2 2 0 3.68928 -6.39002 0
194 2 2 0 4.91904 -5.68001 0
195 2 2 0 4.91904 -4.26001 0
196 2 2 0 6.1488 -3.55001 0
197 2 2 0 6.1488 -2.13001 0
198 2 2 0 7.37856 -1.42 0
199 2 2 0 7.37856 0 0
200 2 2 0 8.60832 0.710007 0
201 2 2 0 8.60832 2.13001 0
202 2 2 0 9.83808 2.84001 0
203 2 2 0 9.83808 4.26001 0
204 2 2 0 11.0678 4.97002 0
205 2 2 0 11.0678 6.39002 0
206 2 2 0 12.2976 7.10003 0

1
examples/PACKAGES/interlayer/saip_metal/Au_u3.eam Symbolic link
View File

@ -0,0 +1 @@
../../../../potentials/Au_u3.eam

1
examples/PACKAGES/interlayer/saip_metal/CH.rebo Symbolic link
View File

@ -0,0 +1 @@
../../../../potentials/CH.rebo

1
examples/PACKAGES/interlayer/saip_metal/CHAu.ILP Symbolic link
View File

@ -0,0 +1 @@
../../../../potentials/CHAu.ILP

44
examples/PACKAGES/interlayer/saip_metal/in.gold_gr Normal file
View File

@ -0,0 +1,44 @@
units metal
atom_style full
processors * * 1
boundary p p f
read_data ./3Lgold_1Lgr_atop_sliding.data
# global group definition
group gold type 1
group gra type 2
# Define mass
mass * 12.0107 # mass of carbon atom , uint: a.u.=1.66X10^(-27)kg
mass 1 196.96657 # mass of gold atom , uint: a.u.=1.66X10^(-27)kg
# Define potentials
pair_style hybrid/overlay eam rebo saip/metal 16.0
pair_coeff 1 1 eam ./Au_u3.eam
pair_coeff * * rebo ./CH.rebo NULL C
pair_coeff * * saip/metal ./CHAu.ILP Au C
# compute energy
compute 0 all pair rebo
compute 1 all pair eam
compute 2 all pair saip/metal
variable REBO equal c_0
variable EAM equal c_1
variable ILP equal c_2
thermo_style custom step etotal pe ke v_REBO v_ILP temp
thermo 100
thermo_modify lost error
# Creat initial velocity
velocity all set 0.0 0.0 0.0
velocity gra create 300.0 4928459 mom yes rot yes dist gaussian
velocity gold create 300.0 4928459 mom yes rot yes dist gaussian
# Integration
fix intsub gold nve
fix intrib gra nve
timestep 1e-3
run 1000

164
examples/PACKAGES/interlayer/saip_metal/log.7Jan22.gold_gr.g++.1 Normal file
View File

@ -0,0 +1,164 @@
LAMMPS (7 Jan 2022)
OMP_NUM_THREADS environment is not set. Defaulting to 1 thread. (../comm.cpp:98)
using 1 OpenMP thread(s) per MPI task
units metal
atom_style full
processors * * 1
boundary p p f
read_data ./3Lgold_1Lgr_atop_sliding.data
Reading data file ...
triclinic box = (0 0 -30) to (17.21664 14.910048 30) with tilt (8.60832 0 0)
1 by 1 by 1 MPI processor grid
reading atoms ...
206 atoms
Finding 1-2 1-3 1-4 neighbors ...
special bond factors lj: 0 0 0
special bond factors coul: 0 0 0
0 = max # of 1-2 neighbors
0 = max # of 1-3 neighbors
0 = max # of 1-4 neighbors
1 = max # of special neighbors
special bonds CPU = 0.001 seconds
read_data CPU = 0.003 seconds
# global group definition
group gold type 1
108 atoms in group gold
group gra type 2
98 atoms in group gra
# Define mass
mass * 12.0107 # mass of carbon atom , uint: a.u.=1.66X10^(-27)kg
mass 1 196.96657 # mass of gold atom , uint: a.u.=1.66X10^(-27)kg
# Define potentials
pair_style hybrid/overlay eam rebo saip/metal 16.0
pair_coeff 1 1 eam ./Au_u3.eam
Reading eam potential file ./Au_u3.eam with DATE: 2007-06-11
pair_coeff * * rebo ./CH.rebo NULL C
Reading rebo potential file ./CH.rebo with DATE: 2018-7-3
pair_coeff * * saip/metal ./CHAu.ILP Au C
Reading saip/metal potential file ./CHAu.ILP with DATE: 2021-12-02
# compute energy
compute 0 all pair rebo
compute 1 all pair eam
compute 2 all pair saip/metal
variable REBO equal c_0
variable EAM equal c_1
variable ILP equal c_2
thermo_style custom step etotal pe ke v_REBO v_ILP temp
thermo 100
thermo_modify lost error
# Creat initial velocity
velocity all set 0.0 0.0 0.0
velocity gra create 300.0 4928459 mom yes rot yes dist gaussian
velocity gold create 300.0 4928459 mom yes rot yes dist gaussian
# Integration
fix intsub gold nve
fix intrib gra nve
timestep 1e-3
run 1000
CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE
Your simulation uses code contributions which should be cited:
- ilp/graphene/hbn potential doi:10.1021/acs.nanolett.8b02848
@Article{Ouyang2018
author = {W. Ouyang, D. Mandelli, M. Urbakh, and O. Hod},
title = {Nanoserpents: Graphene Nanoribbon Motion on Two-Dimensional Hexagonal Materials},
journal = {Nano Letters},
volume = 18,
pages = {6009}
year = 2018,
}
- saip/metal potential doi.org/10.1021/acs.jctc.1c00622
@Article{Ouyang2021
author = {W. Ouyang, O. Hod, and R. Guerra},
title = {Registry-Dependent Potential for Interfaces of Gold with Graphitic Systems},
journal = {J. Chem. Theory Comput.},
volume = 17,
pages = {7215-7223}
year = 2021,
}
CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE
Neighbor list info ...
update every 1 steps, delay 10 steps, check yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 18
ghost atom cutoff = 18
binsize = 9, bins = 3 2 7
4 neighbor lists, perpetual/occasional/extra = 4 0 0
(1) pair eam, perpetual, skip from (4)
attributes: half, newton on
pair build: skip
stencil: none
bin: none
(2) pair rebo, perpetual, skip from (3)
attributes: full, newton on, ghost
pair build: skip/ghost
stencil: none
bin: none
(3) pair saip/metal, perpetual
attributes: full, newton on, ghost
pair build: full/bin/ghost
stencil: full/ghost/bin/3d
bin: standard
(4) neighbor class addition, perpetual
attributes: half, newton on
pair build: half/bin/newton/tri
stencil: half/bin/3d/tri
bin: standard
Per MPI rank memory allocation (min/avg/max) = 9.747 | 9.747 | 9.747 Mbytes
Step TotEng PotEng KinEng v_REBO v_ILP Temp
0 -1121.4621 -1129.3728 7.9107209 -724.70925 -6.0302289 298.53659
100 -1121.4483 -1124.9731 3.5248501 -723.03272 -5.9765533 133.02159
200 -1121.4403 -1125.2912 3.8509646 -722.66784 -6.0468507 145.32858
300 -1121.4424 -1126.4665 5.0240531 -722.72787 -6.0350568 189.59886
400 -1121.4419 -1125.1443 3.7023978 -722.59976 -5.8294548 139.72193
500 -1121.4413 -1125.2711 3.8297939 -722.5342 -6.0189944 144.52963
600 -1121.4449 -1125.8808 4.4359049 -722.77707 -5.8685221 167.40319
700 -1121.4489 -1126.1966 4.747709 -723.13681 -5.8666379 179.17012
800 -1121.4443 -1125.8469 4.402607 -722.94487 -6.0094567 166.14658
900 -1121.4424 -1125.8437 4.4013317 -722.94918 -5.8699702 166.09846
1000 -1121.4467 -1125.7453 4.2986881 -722.66682 -6.0651168 162.22487
Loop time of 6.43246 on 1 procs for 1000 steps with 206 atoms
Performance: 13.432 ns/day, 1.787 hours/ns, 155.462 timesteps/s
99.8% CPU use with 1 MPI tasks x 1 OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 6.4201 | 6.4201 | 6.4201 | 0.0 | 99.81
Bond | 8.9059e-05 | 8.9059e-05 | 8.9059e-05 | 0.0 | 0.00
Neigh | 0 | 0 | 0 | 0.0 | 0.00
Comm | 0.0071852 | 0.0071852 | 0.0071852 | 0.0 | 0.11
Output | 0.00026031 | 0.00026031 | 0.00026031 | 0.0 | 0.00
Modify | 0.0019433 | 0.0019433 | 0.0019433 | 0.0 | 0.03
Other | | 0.002875 | | | 0.04
Nlocal: 206 ave 206 max 206 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Nghost: 2187 ave 2187 max 2187 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Neighs: 0 ave 0 max 0 min
Histogram: 1 0 0 0 0 0 0 0 0 0
FullNghs: 158548 ave 158548 max 158548 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Total # of neighbors = 158548
Ave neighs/atom = 769.65049
Ave special neighs/atom = 0
Neighbor list builds = 0
Dangerous builds = 0
Total wall time: 0:00:06

164
examples/PACKAGES/interlayer/saip_metal/log.7Jan22.gold_gr.g++.4 Normal file
View File

@ -0,0 +1,164 @@
LAMMPS (7 Jan 2022)
OMP_NUM_THREADS environment is not set. Defaulting to 1 thread. (../comm.cpp:98)
using 1 OpenMP thread(s) per MPI task
units metal
atom_style full
processors * * 1
boundary p p f
read_data ./3Lgold_1Lgr_atop_sliding.data
Reading data file ...
triclinic box = (0 0 -30) to (17.21664 14.910048 30) with tilt (8.60832 0 0)
2 by 2 by 1 MPI processor grid
reading atoms ...
206 atoms
Finding 1-2 1-3 1-4 neighbors ...
special bond factors lj: 0 0 0
special bond factors coul: 0 0 0
0 = max # of 1-2 neighbors
0 = max # of 1-3 neighbors
0 = max # of 1-4 neighbors
1 = max # of special neighbors
special bonds CPU = 0.000 seconds
read_data CPU = 0.003 seconds
# global group definition
group gold type 1
108 atoms in group gold
group gra type 2
98 atoms in group gra
# Define mass
mass * 12.0107 # mass of carbon atom , uint: a.u.=1.66X10^(-27)kg
mass 1 196.96657 # mass of gold atom , uint: a.u.=1.66X10^(-27)kg
# Define potentials
pair_style hybrid/overlay eam rebo saip/metal 16.0
pair_coeff 1 1 eam ./Au_u3.eam
Reading eam potential file ./Au_u3.eam with DATE: 2007-06-11
pair_coeff * * rebo ./CH.rebo NULL C
Reading rebo potential file ./CH.rebo with DATE: 2018-7-3
pair_coeff * * saip/metal ./CHAu.ILP Au C
Reading saip/metal potential file ./CHAu.ILP with DATE: 2021-12-02
# compute energy
compute 0 all pair rebo
compute 1 all pair eam
compute 2 all pair saip/metal
variable REBO equal c_0
variable EAM equal c_1
variable ILP equal c_2
thermo_style custom step etotal pe ke v_REBO v_ILP temp
thermo 100
thermo_modify lost error
# Creat initial velocity
velocity all set 0.0 0.0 0.0
velocity gra create 300.0 4928459 mom yes rot yes dist gaussian
velocity gold create 300.0 4928459 mom yes rot yes dist gaussian
# Integration
fix intsub gold nve
fix intrib gra nve
timestep 1e-3
run 1000
CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE
Your simulation uses code contributions which should be cited:
- ilp/graphene/hbn potential doi:10.1021/acs.nanolett.8b02848
@Article{Ouyang2018
author = {W. Ouyang, D. Mandelli, M. Urbakh, and O. Hod},
title = {Nanoserpents: Graphene Nanoribbon Motion on Two-Dimensional Hexagonal Materials},
journal = {Nano Letters},
volume = 18,
pages = {6009}
year = 2018,
}
- saip/metal potential doi.org/10.1021/acs.jctc.1c00622
@Article{Ouyang2021
author = {W. Ouyang, O. Hod, and R. Guerra},
title = {Registry-Dependent Potential for Interfaces of Gold with Graphitic Systems},
journal = {J. Chem. Theory Comput.},
volume = 17,
pages = {7215-7223}
year = 2021,
}
CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE
Neighbor list info ...
update every 1 steps, delay 10 steps, check yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 18
ghost atom cutoff = 18
binsize = 9, bins = 3 2 7
4 neighbor lists, perpetual/occasional/extra = 4 0 0
(1) pair eam, perpetual, skip from (4)
attributes: half, newton on
pair build: skip
stencil: none
bin: none
(2) pair rebo, perpetual, skip from (3)
attributes: full, newton on, ghost
pair build: skip/ghost
stencil: none
bin: none
(3) pair saip/metal, perpetual
attributes: full, newton on, ghost
pair build: full/bin/ghost
stencil: full/ghost/bin/3d
bin: standard
(4) neighbor class addition, perpetual
attributes: half, newton on
pair build: half/bin/newton/tri
stencil: half/bin/3d/tri
bin: standard
Per MPI rank memory allocation (min/avg/max) = 9.299 | 9.299 | 9.3 Mbytes
Step TotEng PotEng KinEng v_REBO v_ILP Temp
0 -1121.4621 -1129.3728 7.9107209 -724.70925 -6.0302289 298.53659
100 -1121.4483 -1124.9731 3.5248501 -723.03272 -5.9765533 133.02159
200 -1121.4403 -1125.2912 3.8509646 -722.66784 -6.0468507 145.32858
300 -1121.4424 -1126.4665 5.0240531 -722.72787 -6.0350568 189.59886
400 -1121.4419 -1125.1443 3.7023978 -722.59976 -5.8294548 139.72193
500 -1121.4413 -1125.2711 3.8297939 -722.5342 -6.0189944 144.52963
600 -1121.4449 -1125.8808 4.4359049 -722.77707 -5.8685221 167.40319
700 -1121.4489 -1126.1966 4.747709 -723.13681 -5.8666379 179.17012
800 -1121.4443 -1125.8469 4.402607 -722.94487 -6.0094567 166.14658
900 -1121.4424 -1125.8437 4.4013317 -722.94918 -5.8699702 166.09846
1000 -1121.4467 -1125.7453 4.2986881 -722.66682 -6.0651168 162.22487
Loop time of 2.44776 on 4 procs for 1000 steps with 206 atoms
Performance: 35.298 ns/day, 0.680 hours/ns, 408.537 timesteps/s
99.7% CPU use with 4 MPI tasks x 1 OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 1.6906 | 2.0172 | 2.3939 | 19.2 | 82.41
Bond | 5.4278e-05 | 6.3818e-05 | 7.3153e-05 | 0.0 | 0.00
Neigh | 0 | 0 | 0 | 0.0 | 0.00
Comm | 0.049363 | 0.42514 | 0.75161 | 41.7 | 17.37
Output | 0.00018596 | 0.00020656 | 0.00024754 | 0.0 | 0.01
Modify | 0.00063656 | 0.00074701 | 0.00089514 | 0.0 | 0.03
Other | | 0.004362 | | | 0.18
Nlocal: 51.5 ave 61 max 44 min
Histogram: 1 1 0 0 0 0 1 0 0 1
Nghost: 1670.75 ave 1699 max 1641 min
Histogram: 1 0 0 0 1 0 1 0 0 1
Neighs: 0 ave 0 max 0 min
Histogram: 4 0 0 0 0 0 0 0 0 0
FullNghs: 39637 ave 47080 max 33737 min
Histogram: 1 1 0 0 0 0 1 0 0 1
Total # of neighbors = 158548
Ave neighs/atom = 769.65049
Ave special neighs/atom = 0
Neighbor list builds = 0
Dangerous builds = 0
Total wall time: 0:00:02

2
examples/README
View File

@ -94,7 +94,7 @@ msst: MSST shock dynamics
nb3b: use of nonbonded 3-body harmonic pair style
neb: nudged elastic band (NEB) calculation for barrier finding
nemd: non-equilibrium MD of 2d sheared system
numdiff: numerical difference computation of forces
numdiff: numerical difference computation of forces and virial
obstacle: flow around two voids in a 2d channel
peptide: dynamics of a small solvated peptide chain (5-mer)
peri: Peridynamic model of cylinder impacted by indenter

87
examples/numdiff/in.numdiff
View File

@ -1,33 +1,74 @@
# Numerical difference calculation of error in forces
# Numerical difference calculation
# of error in forces and virial stress
units metal
atom_style atomic
# adjustable parameters
atom_modify map yes
lattice fcc 5.358000
region box block 0 6 0 6 0 6
create_box 1 box
create_atoms 1 box
mass 1 39.903
variable nsteps index 500 # length of run
variable nthermo index 10 # thermo output interval
variable ndump index 500 # dump output interval
variable nlat index 3 # size of box
variable fdelta index 1.0e-4 # displacement size
variable vdelta index 1.0e-6 # strain size
variable temp index 10.0 # temperature
velocity all create 10 2357 mom yes dist gaussian
units metal
atom_style atomic
pair_style lj/cubic
pair_coeff * * 0.0102701 3.42
atom_modify map yes
lattice fcc 5.358000
region box block 0 ${nlat} 0 ${nlat} 0 ${nlat}
create_box 1 box
create_atoms 1 box
mass 1 39.903
neighbor 1 bin
velocity all create ${temp} 2357 mom yes dist gaussian
timestep 0.001
pair_style lj/cubic
pair_coeff * * 0.0102701 3.42
fix numdiff all numdiff 200 0.0001
fix nve all nve
neighbor 0.0 bin
neigh_modify every 1 delay 0 check no
variable errx atom fx-f_numdiff[1]
variable erry atom fy-f_numdiff[2]
variable errz atom fz-f_numdiff[3]
timestep 0.001
fix nve all nve
write_dump all custom tmp.error f_numdiff[1] f_numdiff[2] f_numdiff[3]
# define numerical force calculation
dump forces all custom 200 force_error.dump v_errx v_erry v_errz
thermo 200
run 2000
fix numforce all numdiff ${nthermo} ${fdelta}
variable ferrx atom f_numforce[1]-fx
variable ferry atom f_numforce[2]-fy
variable ferrz atom f_numforce[3]-fz
variable ferrsq atom v_ferrx^2+v_ferry^2+v_ferrz^2
compute faverrsq all reduce ave v_ferrsq
variable fsq atom fx^2+fy^2+fz^2
compute favsq all reduce ave v_fsq
variable frelerr equal sqrt(c_faverrsq/c_favsq)
dump errors all custom ${ndump} force_error.dump v_ferrx v_ferry v_ferrz
# define numerical virial stress tensor calculation
compute myvirial all pressure NULL virial
fix numvirial all numdiff/virial ${nthermo} ${vdelta}
variable errxx equal f_numvirial[1]-c_myvirial[1]
variable erryy equal f_numvirial[2]-c_myvirial[2]
variable errzz equal f_numvirial[3]-c_myvirial[3]
variable erryz equal f_numvirial[4]-c_myvirial[6]
variable errxz equal f_numvirial[5]-c_myvirial[5]
variable errxy equal f_numvirial[6]-c_myvirial[4]
variable verrsq equal "v_errxx^2 + &
v_erryy^2 + &
v_errzz^2 + &
v_erryz^2 + &
v_errxz^2 + &
v_errxy^2"
variable vsq equal "c_myvirial[1]^2 + &
c_myvirial[3]^2 + &
c_myvirial[3]^2 + &
c_myvirial[4]^2 + &
c_myvirial[5]^2 + &
c_myvirial[6]^2"
variable vrelerr equal sqrt(v_verrsq/v_vsq)
thermo_style custom step temp pe etotal press v_frelerr v_vrelerr
thermo ${nthermo}
run ${nsteps}

175
examples/numdiff/log.28Jan2022.log.numdiff.g++.1 Normal file
View File

@ -0,0 +1,175 @@
LAMMPS (7 Jan 2022)
# Numerical difference calculation
# of error in forces and virial stress
# adjustable parameters
variable nsteps index 500 # length of run
variable nthermo index 10 # thermo output interval
variable ndump index 500 # dump output interval
variable nlat index 3 # size of box
variable fdelta index 1.0e-4 # displacement size
variable vdelta index 1.0e-6 # strain size
variable temp index 10.0 # temperature
units metal
atom_style atomic
atom_modify map yes
lattice fcc 5.358000
Lattice spacing in x,y,z = 5.358 5.358 5.358
region box block 0 ${nlat} 0 ${nlat} 0 ${nlat}
region box block 0 3 0 ${nlat} 0 ${nlat}
region box block 0 3 0 3 0 ${nlat}
region box block 0 3 0 3 0 3
create_box 1 box
Created orthogonal box = (0 0 0) to (16.074 16.074 16.074)
1 by 1 by 1 MPI processor grid
create_atoms 1 box
Created 108 atoms
using lattice units in orthogonal box = (0 0 0) to (16.074 16.074 16.074)
create_atoms CPU = 0.000 seconds
mass 1 39.903
velocity all create ${temp} 2357 mom yes dist gaussian
velocity all create 10.0 2357 mom yes dist gaussian
pair_style lj/cubic
pair_coeff * * 0.0102701 3.42
neighbor 0.0 bin
neigh_modify every 1 delay 0 check no
timestep 0.001
fix nve all nve
# define numerical force calculation
fix numforce all numdiff ${nthermo} ${fdelta}
fix numforce all numdiff 10 ${fdelta}
fix numforce all numdiff 10 1.0e-4
variable ferrx atom f_numforce[1]-fx
variable ferry atom f_numforce[2]-fy
variable ferrz atom f_numforce[3]-fz
variable ferrsq atom v_ferrx^2+v_ferry^2+v_ferrz^2
compute faverrsq all reduce ave v_ferrsq
variable fsq atom fx^2+fy^2+fz^2
compute favsq all reduce ave v_fsq
variable frelerr equal sqrt(c_faverrsq/c_favsq)
dump errors all custom ${ndump} force_error.dump v_ferrx v_ferry v_ferrz
dump errors all custom 500 force_error.dump v_ferrx v_ferry v_ferrz
# define numerical virial stress tensor calculation
compute myvirial all pressure NULL virial
fix numvirial all numdiff/virial ${nthermo} ${vdelta}
fix numvirial all numdiff/virial 10 ${vdelta}
fix numvirial all numdiff/virial 10 1.0e-6
variable errxx equal f_numvirial[1]-c_myvirial[1]
variable erryy equal f_numvirial[2]-c_myvirial[2]
variable errzz equal f_numvirial[3]-c_myvirial[3]
variable erryz equal f_numvirial[4]-c_myvirial[6]
variable errxz equal f_numvirial[5]-c_myvirial[5]
variable errxy equal f_numvirial[6]-c_myvirial[4]
variable verrsq equal "v_errxx^2 + v_erryy^2 + v_errzz^2 + v_erryz^2 + v_errxz^2 + v_errxy^2"
variable vsq equal "c_myvirial[1]^2 + c_myvirial[3]^2 + c_myvirial[3]^2 + c_myvirial[4]^2 + c_myvirial[5]^2 + c_myvirial[6]^2"
variable vrelerr equal sqrt(v_verrsq/v_vsq)
thermo_style custom step temp pe etotal press v_frelerr v_vrelerr
thermo ${nthermo}
thermo 10
run ${nsteps}
run 500
generated 0 of 0 mixed pair_coeff terms from geometric mixing rule
Neighbor list info ...
update every 1 steps, delay 0 steps, check no
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 5.9407173
ghost atom cutoff = 5.9407173
binsize = 2.9703587, bins = 6 6 6
1 neighbor lists, perpetual/occasional/extra = 1 0 0
(1) pair lj/cubic, perpetual
attributes: half, newton on
pair build: half/bin/atomonly/newton
stencil: half/bin/3d
bin: standard
Per MPI rank memory allocation (min/avg/max) = 6.083 | 6.083 | 6.083 Mbytes
Step Temp PotEng TotEng Press v_frelerr v_vrelerr
0 10 -7.0259569 -6.8876486 28.564278 19203.344 1.5660292e-06
10 9.9376583 -7.0250947 -6.8876486 30.254762 1.5040965e-08 2.1991382e-07
20 9.7520139 -7.022527 -6.8876485 35.28505 1.4756358e-08 2.6265315e-06
30 9.4477557 -7.0183188 -6.8876485 43.519863 1.4688198e-08 2.6356166e-07
40 9.0330215 -7.0125826 -6.8876484 54.727797 1.4637921e-08 5.2292327e-08
50 8.5192918 -7.0054772 -6.8876483 68.585553 1.4587854e-08 7.1324716e-08
60 7.9212026 -6.997205 -6.8876481 84.684636 1.4525561e-08 3.1108149e-08
70 7.2562592 -6.9880081 -6.8876479 102.54088 1.450885e-08 3.2311094e-08
80 6.5444294 -6.9781627 -6.8876478 121.60715 1.4444738e-08 2.1776998e-08
90 5.8075961 -6.9679715 -6.8876476 141.2895 1.4493562e-08 2.0400898e-08
100 5.0688629 -6.957754 -6.8876474 160.9668 1.445455e-08 1.2636688e-08
110 4.3517145 -6.947835 -6.8876472 180.0135 1.4460371e-08 1.2528038e-08
120 3.6790589 -6.9385314 -6.887647 197.82486 1.4371757e-08 1.4489522e-08
130 3.0721984 -6.9301379 -6.8876468 213.84331 1.4364708e-08 1.2461922e-08
140 2.5497991 -6.9229125 -6.8876467 227.58429 1.4330926e-08 9.3913926e-09
150 2.1269443 -6.917064 -6.8876466 238.6596 1.4287002e-08 4.1510266e-09
160 1.8143642 -6.9127407 -6.8876465 246.79599 1.4282669e-08 7.7048281e-09
170 1.6179191 -6.9100237 -6.8876465 251.84748 1.42726e-08 1.2719973e-08
180 1.5383946 -6.9089239 -6.8876466 253.79991 1.4236534e-08 8.1200831e-09
190 1.5716287 -6.9093836 -6.8876467 252.76745 1.41706e-08 6.5670612e-09
200 1.7089493 -6.911283 -6.8876468 248.98142 1.4096463e-08 1.1685863e-08
210 1.9378716 -6.9144493 -6.8876469 242.77289 1.4008978e-08 1.1226902e-08
220 2.2429731 -6.9186692 -6.887647 234.55055 1.3886901e-08 9.9914102e-09
230 2.606862 -6.9237023 -6.8876472 224.77626 1.3864576e-08 1.1540228e-08
240 3.0111524 -6.9292941 -6.8876474 213.93996 1.3696314e-08 1.1697747e-08
250 3.4373794 -6.9351893 -6.8876475 202.53583 1.3626701e-08 1.0398197e-08
260 3.8678047 -6.9411426 -6.8876476 191.04084 1.3489489e-08 6.6603364e-09
270 4.2860853 -6.9469279 -6.8876478 179.89646 1.3312014e-08 1.1687917e-08
280 4.6777954 -6.9523457 -6.8876479 169.49404 1.3081144e-08 1.1336675e-08
290 5.030805 -6.9572282 -6.887648 160.16371 1.2947385e-08 1.7342825e-08
300 5.3355278 -6.9614428 -6.887648 152.16682 1.2893673e-08 1.7510534e-08
310 5.5850532 -6.964894 -6.887648 145.69148 1.2842022e-08 1.2782546e-08
320 5.7751794 -6.9675236 -6.8876481 140.85102 1.2903488e-08 1.5319437e-08
330 5.9043601 -6.9693103 -6.887648 137.68497 1.3076809e-08 1.1208999e-08
340 5.9735784 -6.9702676 -6.887648 136.16232 1.3296904e-08 1.891087e-08
350 5.9861549 -6.9704415 -6.887648 136.18679 1.3504051e-08 2.5783601e-08
360 5.947496 -6.9699067 -6.8876479 137.60397 1.3731112e-08 2.0556839e-08
370 5.8647874 -6.9687627 -6.8876478 140.2101 1.4009878e-08 2.1771736e-08
380 5.7466376 -6.9671285 -6.8876477 143.76234 1.4092054e-08 1.1085162e-08
390 5.6026773 -6.9651374 -6.8876477 147.99019 1.4282872e-08 2.0221602e-08
400 5.4431231 -6.9629305 -6.8876476 152.60787 1.4317739e-08 1.7076065e-08
410 5.2783192 -6.960651 -6.8876475 157.32722 1.4415075e-08 2.5031776e-08
420 5.1182723 -6.9584374 -6.8876474 161.87063 1.4441435e-08 2.2519289e-08
430 4.9722 -6.956417 -6.8876473 165.98344 1.4550624e-08 2.4512613e-08
440 4.8481153 -6.9547008 -6.8876473 169.44527 1.4544672e-08 1.4758301e-08
450 4.7524707 -6.9533779 -6.8876472 172.07964 1.4546492e-08 1.324687e-08
460 4.6898817 -6.9525122 -6.8876472 173.76132 1.4537475e-08 1.351367e-08
470 4.6629495 -6.9521397 -6.8876472 174.42109 1.4530458e-08 1.521106e-08
480 4.6721922 -6.9522675 -6.8876472 174.04742 1.4543785e-08 1.0905422e-08
490 4.7160887 -6.9528747 -6.8876473 172.68525 1.4545591e-08 2.0128525e-08
500 4.7912313 -6.953914 -6.8876473 170.43183 1.4438981e-08 1.6062775e-08
Loop time of 0.837333 on 1 procs for 500 steps with 108 atoms
Performance: 51.592 ns/day, 0.465 hours/ns, 597.134 timesteps/s
99.8% CPU use with 1 MPI tasks x no OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 0.0097726 | 0.0097726 | 0.0097726 | 0.0 | 1.17
Neigh | 0.03095 | 0.03095 | 0.03095 | 0.0 | 3.70
Comm | 0.005564 | 0.005564 | 0.005564 | 0.0 | 0.66
Output | 0.0042451 | 0.0042451 | 0.0042451 | 0.0 | 0.51
Modify | 0.78618 | 0.78618 | 0.78618 | 0.0 | 93.89
Other | | 0.0006258 | | | 0.07
Nlocal: 108 ave 108 max 108 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Nghost: 558 ave 558 max 558 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Neighs: 972 ave 972 max 972 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Total # of neighbors = 972
Ave neighs/atom = 9
Neighbor list builds = 500
Dangerous builds not checked
Total wall time: 0:00:00

175
examples/numdiff/log.28Jan2022.log.numdiff.g++.4 Normal file
View File

@ -0,0 +1,175 @@
LAMMPS (7 Jan 2022)
# Numerical difference calculation
# of error in forces and virial stress
# adjustable parameters
variable nsteps index 500 # length of run
variable nthermo index 10 # thermo output interval
variable ndump index 500 # dump output interval
variable nlat index 3 # size of box
variable fdelta index 1.0e-4 # displacement size
variable vdelta index 1.0e-6 # strain size
variable temp index 10.0 # temperature
units metal
atom_style atomic
atom_modify map yes
lattice fcc 5.358000
Lattice spacing in x,y,z = 5.358 5.358 5.358
region box block 0 ${nlat} 0 ${nlat} 0 ${nlat}
region box block 0 3 0 ${nlat} 0 ${nlat}
region box block 0 3 0 3 0 ${nlat}
region box block 0 3 0 3 0 3
create_box 1 box
Created orthogonal box = (0 0 0) to (16.074 16.074 16.074)
1 by 2 by 2 MPI processor grid
create_atoms 1 box
Created 108 atoms
using lattice units in orthogonal box = (0 0 0) to (16.074 16.074 16.074)
create_atoms CPU = 0.000 seconds
mass 1 39.903
velocity all create ${temp} 2357 mom yes dist gaussian
velocity all create 10.0 2357 mom yes dist gaussian
pair_style lj/cubic
pair_coeff * * 0.0102701 3.42
neighbor 0.0 bin
neigh_modify every 1 delay 0 check no
timestep 0.001
fix nve all nve
# define numerical force calculation
fix numforce all numdiff ${nthermo} ${fdelta}
fix numforce all numdiff 10 ${fdelta}
fix numforce all numdiff 10 1.0e-4
variable ferrx atom f_numforce[1]-fx
variable ferry atom f_numforce[2]-fy
variable ferrz atom f_numforce[3]-fz
variable ferrsq atom v_ferrx^2+v_ferry^2+v_ferrz^2
compute faverrsq all reduce ave v_ferrsq
variable fsq atom fx^2+fy^2+fz^2
compute favsq all reduce ave v_fsq
variable frelerr equal sqrt(c_faverrsq/c_favsq)
dump errors all custom ${ndump} force_error.dump v_ferrx v_ferry v_ferrz
dump errors all custom 500 force_error.dump v_ferrx v_ferry v_ferrz
# define numerical virial stress tensor calculation
compute myvirial all pressure NULL virial
fix numvirial all numdiff/virial ${nthermo} ${vdelta}
fix numvirial all numdiff/virial 10 ${vdelta}
fix numvirial all numdiff/virial 10 1.0e-6
variable errxx equal f_numvirial[1]-c_myvirial[1]
variable erryy equal f_numvirial[2]-c_myvirial[2]
variable errzz equal f_numvirial[3]-c_myvirial[3]
variable erryz equal f_numvirial[4]-c_myvirial[6]
variable errxz equal f_numvirial[5]-c_myvirial[5]
variable errxy equal f_numvirial[6]-c_myvirial[4]
variable verrsq equal "v_errxx^2 + v_erryy^2 + v_errzz^2 + v_erryz^2 + v_errxz^2 + v_errxy^2"
variable vsq equal "c_myvirial[1]^2 + c_myvirial[3]^2 + c_myvirial[3]^2 + c_myvirial[4]^2 + c_myvirial[5]^2 + c_myvirial[6]^2"
variable vrelerr equal sqrt(v_verrsq/v_vsq)
thermo_style custom step temp pe etotal press v_frelerr v_vrelerr
thermo ${nthermo}
thermo 10
run ${nsteps}
run 500
generated 0 of 0 mixed pair_coeff terms from geometric mixing rule
Neighbor list info ...
update every 1 steps, delay 0 steps, check no
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 5.9407173
ghost atom cutoff = 5.9407173
binsize = 2.9703587, bins = 6 6 6
1 neighbor lists, perpetual/occasional/extra = 1 0 0
(1) pair lj/cubic, perpetual
attributes: half, newton on
pair build: half/bin/atomonly/newton
stencil: half/bin/3d
bin: standard
Per MPI rank memory allocation (min/avg/max) = 6.067 | 6.067 | 6.067 Mbytes
Step Temp PotEng TotEng Press v_frelerr v_vrelerr
0 10 -7.0259569 -6.8876486 28.564278 10664.391 9.1481187e-08
10 9.9388179 -7.0251107 -6.8876486 30.21736 1.4771865e-08 1.3452512e-07
20 9.7572185 -7.022599 -6.8876485 35.123527 1.437525e-08 8.0966999e-07
30 9.4606673 -7.0184974 -6.8876484 43.132052 1.4375468e-08 1.990012e-08
40 9.0579092 -7.0129268 -6.8876483 54.000927 1.4350331e-08 1.7239028e-08
50 8.5607685 -7.0060508 -6.8876482 67.403151 1.4353284e-08 7.813181e-09
60 7.9838726 -6.9980717 -6.8876481 82.935358 1.4398078e-08 2.022316e-08
70 7.3442875 -6.9892255 -6.8876479 100.12892 1.434409e-08 7.5938179e-09
80 6.6610579 -6.9797757 -6.8876477 118.46358 1.4324787e-08 7.1972571e-09
90 5.9546462 -6.9700053 -6.8876476 137.38365 1.4322718e-08 4.3978378e-09
100 5.2462727 -6.9602077 -6.8876474 156.31651 1.4273172e-08 4.6728038e-09
110 4.5571706 -6.9506767 -6.8876472 174.69294 1.4266163e-08 3.522225e-09
120 3.9077807 -6.9416949 -6.887647 191.96859 1.42241e-08 3.5357511e-09
130 3.3169241 -6.9335227 -6.8876469 207.64566 1.4203813e-08 2.5182488e-09
140 2.8010028 -6.926387 -6.8876468 221.29333 1.4164215e-08 2.3112509e-09
150 2.3732854 -6.9204712 -6.8876467 232.5658 1.4134122e-08 1.9368963e-09
160 2.0433329 -6.9159076 -6.8876466 241.21647 1.4095473e-08 3.6806452e-09
170 1.8166184 -6.912772 -6.8876466 247.10715 1.4049531e-08 2.5319322e-09
180 1.6943727 -6.9110813 -6.8876467 250.21143 1.3997912e-08 1.952404e-09
190 1.6736731 -6.910795 -6.8876467 250.61203 1.3915487e-08 1.4271767e-09
200 1.7477659 -6.9118199 -6.8876468 248.49223 1.3850618e-08 2.4515718e-09
210 1.9065921 -6.9140167 -6.8876469 244.12226 1.3747916e-08 1.7957531e-09
220 2.1374676 -6.91721 -6.887647 237.84173 1.3674779e-08 2.6613511e-09
230 2.4258607 -6.9211989 -6.8876472 230.0395 1.3565712e-08 3.0777067e-09
240 2.7562034 -6.9257679 -6.8876473 221.13265 1.3440442e-08 1.7111501e-09
250 3.1126827 -6.9306984 -6.8876474 211.54566 1.3270914e-08 1.6690112e-09
260 3.4799641 -6.9357784 -6.8876476 201.69126 1.3105092e-08 2.1637558e-09
270 3.8438148 -6.9408108 -6.8876477 191.95361 1.2962846e-08 4.4613506e-09
280 4.191607 -6.9456212 -6.8876478 182.6745 1.2846383e-08 3.3730203e-09
290 4.5126922 -6.9500621 -6.8876478 174.14285 1.2710692e-08 2.2809889e-09
300 4.7986487 -6.9540172 -6.8876479 166.58747 1.2657778e-08 6.9880891e-09
310 5.0434083 -6.9574025 -6.8876479 160.17316 1.266381e-08 4.2486217e-09
320 5.243275 -6.9601668 -6.8876479 154.99974 1.279856e-08 5.1505673e-09
330 5.3968455 -6.9622908 -6.8876479 151.1038 1.2981831e-08 3.3339333e-09
340 5.5048468 -6.9637845 -6.8876479 148.46296 1.3159021e-08 1.7881393e-09
350 5.569902 -6.9646843 -6.8876479 147.00205 1.3439465e-08 5.6876219e-09
360 5.5962378 -6.9650485 -6.8876478 146.60113 1.3645943e-08 7.233847e-09
370 5.5893468 -6.9649531 -6.8876478 147.10471 1.3829581e-08 4.5514318e-09
380 5.5556199 -6.9644866 -6.8876477 148.33195 1.4005893e-08 4.2971846e-09
390 5.5019639 -6.9637444 -6.8876476 150.08725 1.4157454e-08 3.3564262e-09
400 5.4354239 -6.962824 -6.8876476 152.17073 1.4226422e-08 4.2393923e-09
410 5.3628267 -6.9618199 -6.8876475 154.38825 1.4302679e-08 3.8937698e-09
420 5.2904639 -6.960819 -6.8876475 156.56034 1.4381099e-08 4.315875e-09
430 5.2238282 -6.9598973 -6.8876474 158.52969 1.4426567e-08 4.2658185e-09
440 5.1674149 -6.9591171 -6.8876474 160.16704 1.4453381e-08 5.7055268e-09
450 5.1245913 -6.9585248 -6.8876474 161.37513 1.4449488e-08 4.4308801e-09
460 5.0975361 -6.9581506 -6.8876474 162.09077 1.4445596e-08 5.8269923e-09
470 5.0872416 -6.9580082 -6.8876474 162.28517 1.4444348e-08 4.8263194e-09
480 5.0935712 -6.9580957 -6.8876474 161.96268 1.4411666e-08 6.222228e-09
490 5.115362 -6.9583971 -6.8876474 161.15816 1.4369716e-08 3.3926077e-09
500 5.1505605 -6.958884 -6.8876474 159.9333 1.4288515e-08 3.8845251e-09
Loop time of 0.252598 on 4 procs for 500 steps with 108 atoms
Performance: 171.023 ns/day, 0.140 hours/ns, 1979.430 timesteps/s
99.8% CPU use with 4 MPI tasks x no OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 0.0021545 | 0.0022845 | 0.0023794 | 0.2 | 0.90
Neigh | 0.0063887 | 0.0067604 | 0.0069752 | 0.3 | 2.68
Comm | 0.01048 | 0.010916 | 0.011408 | 0.3 | 4.32
Output | 0.0026603 | 0.0027399 | 0.0029738 | 0.3 | 1.08
Modify | 0.2295 | 0.22952 | 0.22954 | 0.0 | 90.86
Other | | 0.0003814 | | | 0.15
Nlocal: 27 ave 29 max 25 min
Histogram: 1 0 1 0 0 0 0 1 0 1
Nghost: 325 ave 327 max 323 min
Histogram: 1 0 1 0 0 0 0 1 0 1
Neighs: 243 ave 273 max 228 min
Histogram: 1 1 1 0 0 0 0 0 0 1
Total # of neighbors = 972
Ave neighs/atom = 9
Neighbor list builds = 500
Dangerous builds not checked
Total wall time: 0:00:00

18
examples/plugins/angle_zero2.h
View File

@ -21,17 +21,17 @@ namespace LAMMPS_NS {
class AngleZero2 : public Angle {
public:
AngleZero2(class LAMMPS *);
virtual ~AngleZero2();
virtual void compute(int, int);
virtual void coeff(int, char **);
virtual void settings(int, char **);
~AngleZero2() override;
void compute(int, int) override;
void coeff(int, char **) override;
void settings(int, char **) override;
double equilibrium_angle(int);
void write_restart(FILE *);
void read_restart(FILE *);
void write_data(FILE *);
double equilibrium_angle(int) override;
void write_restart(FILE *) override;
void read_restart(FILE *) override;
void write_data(FILE *) override;
double single(int, int, int, int);
double single(int, int, int, int) override;
protected:
double *theta0;

20
examples/plugins/bond_zero2.h
View File

@ -21,18 +21,18 @@ namespace LAMMPS_NS {
class BondZero2 : public Bond {
public:
BondZero2(class LAMMPS *);
virtual ~BondZero2();
virtual void compute(int, int);
virtual void settings(int, char **);
~BondZero2() override;
void compute(int, int) override;
void settings(int, char **) override;
void coeff(int, char **);
double equilibrium_distance(int);
void write_restart(FILE *);
void read_restart(FILE *);
void write_data(FILE *);
void coeff(int, char **) override;
double equilibrium_distance(int) override;
void write_restart(FILE *) override;
void read_restart(FILE *) override;
void write_data(FILE *) override;
double single(int, double, int, int, double &);
virtual void *extract(const char *, int &);
double single(int, double, int, int, double &) override;
void *extract(const char *, int &) override;
protected:
double *r0;

14
examples/plugins/dihedral_zero2.h
View File

@ -25,14 +25,14 @@ namespace LAMMPS_NS {
class DihedralZero2 : public Dihedral {
public:
DihedralZero2(class LAMMPS *);
virtual ~DihedralZero2();
virtual void compute(int, int);
virtual void coeff(int, char **);
virtual void settings(int, char **);
~DihedralZero2() override;
void compute(int, int) override;
void coeff(int, char **) override;
void settings(int, char **) override;
void write_restart(FILE *);
void read_restart(FILE *);
void write_data(FILE *);
void write_restart(FILE *) override;
void read_restart(FILE *) override;
void write_data(FILE *) override;
protected:
int coeffflag;

23
examples/plugins/fix_nve2.h
View File

@ -11,12 +11,6 @@
See the README file in the top-level LAMMPS directory.
------------------------------------------------------------------------- */
#ifdef FIX_CLASS
FixStyle(nve2, FixNVE2)
#else
#ifndef LMP_FIX_NVE2_H
#define LMP_FIX_NVE2_H
@ -27,14 +21,14 @@ namespace LAMMPS_NS {
class FixNVE2 : public Fix {
public:
FixNVE2(class LAMMPS *, int, char **);
virtual ~FixNVE2() {}
int setmask();
virtual void init();
virtual void initial_integrate(int);
virtual void final_integrate();
virtual void initial_integrate_respa(int, int, int);
virtual void final_integrate_respa(int, int);
virtual void reset_dt();
int setmask() override;
void init() override;
void initial_integrate(int) override;
void final_integrate() override;
void initial_integrate_respa(int, int, int) override;
void final_integrate_respa(int, int) override;
void reset_dt() override;
protected:
double dtv, dtf;
@ -44,7 +38,6 @@ class FixNVE2 : public Fix {
} // namespace LAMMPS_NS
#endif
#endif
/* ERROR/WARNING messages:

14
examples/plugins/improper_zero2.h
View File

@ -21,14 +21,14 @@ namespace LAMMPS_NS {
class ImproperZero2 : public Improper {
public:
ImproperZero2(class LAMMPS *);
virtual ~ImproperZero2();
virtual void compute(int, int);
virtual void coeff(int, char **);
virtual void settings(int, char **);
~ImproperZero2() override;
void compute(int, int) override;
void coeff(int, char **) override;
void settings(int, char **) override;
void write_restart(FILE *);
void read_restart(FILE *);
void write_data(FILE *);
void write_restart(FILE *) override;
void read_restart(FILE *) override;
void write_data(FILE *) override;
protected:
int coeffflag;

26
examples/plugins/pair_morse2.h
View File

@ -21,20 +21,20 @@ namespace LAMMPS_NS {
class PairMorse2 : public Pair {
public:
PairMorse2(class LAMMPS *);
virtual ~PairMorse2();
virtual void compute(int, int);
~PairMorse2() override;
void compute(int, int) override;
void settings(int, char **);
void coeff(int, char **);
double init_one(int, int);
void write_restart(FILE *);
void read_restart(FILE *);
void write_restart_settings(FILE *);
void read_restart_settings(FILE *);
void write_data(FILE *);
void write_data_all(FILE *);
double single(int, int, int, int, double, double, double, double &);
void *extract(const char *, int &);
void settings(int, char **) override;
void coeff(int, char **) override;
double init_one(int, int) override;
void write_restart(FILE *) override;
void read_restart(FILE *) override;
void write_restart_settings(FILE *) override;
void read_restart_settings(FILE *) override;
void write_data(FILE *) override;
void write_data_all(FILE *) override;
double single(int, int, int, int, double, double, double, double &) override;
void *extract(const char *, int &) override;
protected:
double cut_global;

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