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

Merge branch 'develop' into apip_devel and solve merge conflict in set.

Browse Source
This commit is contained in:
David Immel
2025-06-06 13:32:00 +02:00
parent e5f0e23a11 b3f160c118
commit 9a65ab2c4d
548 changed files with 50015 additions and 7438 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
.github/release_steps.md vendored
View File

@ -104,8 +104,8 @@ with a future release) from the `lammps-static` folder.
rm -rf release-packages
mkdir release-packages
cd release-packages
wget https://download.lammps.org/static/fedora41_musl.sif
apptainer shell fedora41_musl.sif
wget https://download.lammps.org/static/fedora41_musl_mingw.sif
apptainer shell fedora41_musl_mingw.sif
git clone -b release --depth 10 https://github.com/lammps/lammps.git lammps-release
cmake -S lammps-release/cmake -B build-release -G Ninja -D CMAKE_INSTALL_PREFIX=$PWD/lammps-static -D CMAKE_TOOLCHAIN_FILE=/usr/musl/share/cmake/linux-musl.cmake -C lammps-release/cmake/presets/most.cmake -C lammps-release/cmake/presets/kokkos-openmp.cmake -D DOWNLOAD_POTENTIALS=OFF -D BUILD_MPI=OFF -D BUILD_TESTING=OFF -D CMAKE_BUILD_TYPE=Release -D PKG_ATC=ON -D PKG_AWPMD=ON -D PKG_MANIFOLD=ON -D PKG_MESONT=ON -D PKG_MGPT=ON -D PKG_ML-PACE=ON -D PKG_ML-RANN=ON -D PKG_MOLFILE=ON -D PKG_PTM=ON -D PKG_QTB=ON -D PKG_SMTBQ=ON
cmake --build build-release --target all
@ -204,7 +204,7 @@ cd ..
rm -r release-packages
```
#### Build Multi-arch App-bundle for macOS
#### Build Multi-arch App-bundle with GUI for macOS
Building app-bundles for macOS is not as easily automated and portable
as some of the other steps. It requires a machine actually running
@ -251,7 +251,7 @@ attached to the GitHub release page.
We are currently building the application images on macOS 12 (aka Monterey).
#### Build Linux x86_64 binary tarball on Ubuntu 20.04LTS
#### Build Linux x86_64 binary tarball with GUI on Ubuntu 20.04LTS
While the flatpak Linux version uses portable runtime libraries provided
by the flatpak environment, we also build regular Linux executables that

19
.github/workflows/check-cpp23.yml vendored
View File

@ -1,4 +1,4 @@
# GitHub action to build LAMMPS on Linux with gcc and C++23
# GitHub action to build LAMMPS on Linux with gcc or clang and C++23
name: "Check for C++23 Compatibility"
on:
@ -11,11 +11,19 @@ on:
workflow_dispatch:
concurrency:
group: ${{ github.event_name }}-${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: ${{github.event_name == 'pull_request'}}
jobs:
build:
name: Build with C++23 support enabled
if: ${{ github.repository == 'lammps/lammps' }}
runs-on: ubuntu-latest
strategy:
max-parallel: 2
matrix:
idx: [ gcc, clang ]
env:
CCACHE_DIR: ${{ github.workspace }}/.ccache
@ -29,8 +37,11 @@ jobs:
run: |
sudo apt-get update
sudo apt-get install -y ccache \
libeigen3-dev \
clang \
libcurl4-openssl-dev \
libeigen3-dev \
libfftw3-dev \
libomp-dev \
mold \
mpi-default-bin \
mpi-default-dev \
@ -58,14 +69,14 @@ jobs:
cmake -S cmake -B build \
-C cmake/presets/most.cmake \
-C cmake/presets/kokkos-openmp.cmake \
-C cmake/presets/${{ matrix.idx }}.cmake \
-D CMAKE_CXX_STANDARD=23 \
-D CMAKE_CXX_COMPILER=g++ \
-D CMAKE_C_COMPILER=gcc \
-D CMAKE_CXX_COMPILER_LAUNCHER=ccache \
-D CMAKE_C_COMPILER_LAUNCHER=ccache \
-D CMAKE_BUILD_TYPE=Debug \
-D CMAKE_CXX_FLAGS_DEBUG="-Og -g" \
-D DOWNLOAD_POTENTIALS=off \
-D FFT=KISS \
-D BUILD_MPI=on \
-D BUILD_SHARED_LIBS=on \
-D BUILD_TOOLS=off \

1
README
View File

@ -34,6 +34,7 @@ lib additional provided or external libraries
potentials interatomic potential files
python Python module for LAMMPS
src source files
third_party Copies of thirdparty software bundled with LAMMPS
tools pre- and post-processing tools
unittest test programs for use with CTest
.github Git and GitHub related files and tools

80
cmake/CMakeLists.txt
View File

@ -7,6 +7,10 @@ if(CMAKE_VERSION VERSION_LESS 3.20)
message(WARNING "LAMMPS is planning to require at least CMake version 3.20 by Summer 2025. Please upgrade!")
endif()
########################################
# initialize version variables with project command
if(POLICY CMP0048)
cmake_policy(SET CMP0048 NEW)
endif()
# set policy to silence warnings about ignoring <PackageName>_ROOT but use it
if(POLICY CMP0074)
cmake_policy(SET CMP0074 NEW)
@ -27,7 +31,10 @@ endif()
########################################
project(lammps CXX)
project(lammps
DESCRIPTION "The LAMMPS Molecular Dynamics Simulator"
HOMEPAGE_URL "https://www.lammps.org"
LANGUAGES CXX C)
set(SOVERSION 0)
get_property(BUILD_IS_MULTI_CONFIG GLOBAL PROPERTY GENERATOR_IS_MULTI_CONFIG)
@ -44,6 +51,7 @@ set(LAMMPS_DOC_DIR ${LAMMPS_DIR}/doc)
set(LAMMPS_TOOLS_DIR ${LAMMPS_DIR}/tools)
set(LAMMPS_PYTHON_DIR ${LAMMPS_DIR}/python)
set(LAMMPS_POTENTIALS_DIR ${LAMMPS_DIR}/potentials)
set(LAMMPS_THIRDPARTY_DIR ${LAMMPS_DIR}/third_party)
set(LAMMPS_DOWNLOADS_URL "https://download.lammps.org" CACHE STRING "Base URL for LAMMPS downloads")
set(LAMMPS_POTENTIALS_URL "${LAMMPS_DOWNLOADS_URL}/potentials")
@ -105,46 +113,35 @@ if(CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /Qrestrict")
endif()
if(CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.3 OR CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.4)
set(CMAKE_TUNE_DEFAULT "/QxCOMMON-AVX512")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /QxCOMMON-AVX512")
else()
set(CMAKE_TUNE_DEFAULT "/QxHost")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /QxHost")
endif()
else()
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -restrict")
if(CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.3 OR CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.4)
set(CMAKE_TUNE_DEFAULT "-xCOMMON-AVX512")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -xCOMMON-AVX512")
else()
set(CMAKE_TUNE_DEFAULT "-xHost -fp-model fast=2 -no-prec-div -qoverride-limits -diag-disable=10441 -diag-disable=11074 -diag-disable=11076 -diag-disable=2196")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -xHost -fp-model fast=2 -no-prec-div -qoverride-limits -diag-disable=10441 -diag-disable=11074 -diag-disable=11076 -diag-disable=2196")
endif()
endif()
endif()
# silence excessive warnings for new Intel Compilers
if(CMAKE_CXX_COMPILER_ID STREQUAL "IntelLLVM")
set(CMAKE_TUNE_DEFAULT "-fp-model precise -Wno-tautological-constant-compare -Wno-unused-command-line-argument")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fp-model precise -Wno-tautological-constant-compare -Wno-unused-command-line-argument")
endif()
# silence excessive warnings for PGI/NVHPC compilers
if((CMAKE_CXX_COMPILER_ID STREQUAL "NVHPC") OR (CMAKE_CXX_COMPILER_ID STREQUAL "PGI"))
set(CMAKE_TUNE_DEFAULT "-Minform=severe")
endif()
# this hack is required to compile fmt lib with CrayClang version 15.0.2
# CrayClang is only directly recognized by version 3.28 and later
if(CMAKE_VERSION VERSION_LESS 3.28)
get_filename_component(_exe "${CMAKE_CXX_COMPILER}" NAME)
if((CMAKE_CXX_COMPILER_ID STREQUAL "Clang") AND (_exe STREQUAL "crayCC"))
set(CMAKE_TUNE_DEFAULT "-DFMT_STATIC_THOUSANDS_SEPARATOR")
endif()
else()
if(CMAKE_CXX_COMPILER_ID STREQUAL "CrayClang")
set(CMAKE_TUNE_DEFAULT "-DFMT_STATIC_THOUSANDS_SEPARATOR")
endif()
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Minform=severe")
endif()
# silence nvcc warnings
if((PKG_KOKKOS) AND (Kokkos_ENABLE_CUDA) AND NOT (CMAKE_CXX_COMPILER_ID STREQUAL "Clang"))
set(CMAKE_TUNE_DEFAULT "${CMAKE_TUNE_DEFAULT}" "-Xcudafe --diag_suppress=unrecognized_pragma,--diag_suppress=128")
if((PKG_KOKKOS) AND (Kokkos_ENABLE_CUDA) AND NOT
((CMAKE_CXX_COMPILER_ID STREQUAL "Clang") OR (CMAKE_CXX_COMPILER_ID STREQUAL "IntelLLVM")
OR (CMAKE_CXX_COMPILER_ID STREQUAL "XLClang") OR (CMAKE_CXX_COMPILER_ID STREQUAL "CrayClang")))
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Xcudafe --diag_suppress=unrecognized_pragma,--diag_suppress=128")
endif()
# we *require* C++11 without extensions but prefer C++17.
@ -206,6 +203,10 @@ if((CMAKE_SYSTEM_NAME STREQUAL "Windows") AND BUILD_SHARED_LIBS)
set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS ON)
endif()
# do not include the (obsolete) MPI C++ bindings which makes for leaner object files
# and avoids namespace conflicts. Put this early to increase its visbility.
set(MPI_CXX_SKIP_MPICXX TRUE CACHE BOOL "Skip MPI C++ Bindings" FORCE)
########################################################################
# User input options #
########################################################################
@ -384,12 +385,12 @@ endforeach()
# packages with special compiler needs or external libs
######################################################
target_include_directories(lammps PUBLIC $<BUILD_INTERFACE:${LAMMPS_SOURCE_DIR}>)
target_include_directories(lammps PUBLIC $<BUILD_INTERFACE:${LAMMPS_THIRDPARTY_DIR}>)
if(PKG_ADIOS)
# The search for ADIOS2 must come before MPI because
# it includes its own MPI search with the latest FindMPI.cmake
# script that defines the MPI::MPI_C target
enable_language(C)
find_package(ADIOS2 REQUIRED)
if(BUILD_MPI)
if(NOT ADIOS2_HAVE_MPI)
@ -404,21 +405,18 @@ if(PKG_ADIOS)
endif()
if(NOT CMAKE_CROSSCOMPILING)
find_package(MPI QUIET)
find_package(MPI QUIET COMPONENTS CXX)
option(BUILD_MPI "Build MPI version" ${MPI_FOUND})
else()
option(BUILD_MPI "Build MPI version" OFF)
endif()
if(BUILD_MPI)
# do not include the (obsolete) MPI C++ bindings which makes
# for leaner object files and avoids namespace conflicts
set(MPI_CXX_SKIP_MPICXX TRUE)
# We use a non-standard procedure to cross-compile with MPI on Windows
if((CMAKE_SYSTEM_NAME STREQUAL "Windows") AND CMAKE_CROSSCOMPILING)
include(MPI4WIN)
else()
find_package(MPI REQUIRED)
find_package(MPI REQUIRED COMPONENTS 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)
@ -451,6 +449,19 @@ if(NOT ${LAMMPS_MEMALIGN} STREQUAL "0")
target_compile_definitions(lammps PRIVATE -DLAMMPS_MEMALIGN=${LAMMPS_MEMALIGN})
endif()
# this hack is required to compile fmt lib with CrayClang version 15.0.2
# CrayClang is only directly recognized by CMake version 3.28 and later
if(CMAKE_VERSION VERSION_LESS 3.28)
get_filename_component(_exe "${CMAKE_CXX_COMPILER}" NAME)
if((CMAKE_CXX_COMPILER_ID STREQUAL "Clang") AND (_exe STREQUAL "crayCC"))
target_compile_definitions(lammps PRIVATE -DFMT_STATIC_THOUSANDS_SEPARATOR)
endif()
else()
if(CMAKE_CXX_COMPILER_ID STREQUAL "CrayClang")
target_compile_definitions(lammps PRIVATE -DFMT_STATIC_THOUSANDS_SEPARATOR)
endif()
endif()
# "hard" dependencies between packages resulting
# in an error instead of skipping over files
pkg_depends(ML-IAP ML-SNAP)
@ -509,13 +520,13 @@ if(BUILD_OMP)
if(CMAKE_VERSION VERSION_LESS 3.28)
get_filename_component(_exe "${CMAKE_CXX_COMPILER}" NAME)
if((CMAKE_CXX_COMPILER_ID STREQUAL "Clang") AND (_exe STREQUAL "crayCC"))
set(CMAKE_SHARED_LINKER_FLAGS_${BTYPE} "${CMAKE_SHARED_LINKER_FLAGS_${BTYPE}} -fopenmp")
set(CMAKE_STATIC_LINKER_FLAGS_${BTYPE} "${CMAKE_STATIC_LINKER_FLAGS_${BTYPE}} -fopenmp")
set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -fopenmp")
set(CMAKE_STATIC_LINKER_FLAGS "${CMAKE_STATIC_LINKER_FLAGS} -fopenmp")
endif()
else()
if(CMAKE_CXX_COMPILER_ID STREQUAL "CrayClang")
set(CMAKE_SHARED_LINKER_FLAGS_${BTYPE} "${CMAKE_SHARED_LINKER_FLAGS_${BTYPE}} -fopenmp")
set(CMAKE_STATIC_LINKER_FLAGS_${BTYPE} "${CMAKE_STATIC_LINKER_FLAGS_${BTYPE}} -fopenmp")
set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -fopenmp")
set(CMAKE_STATIC_LINKER_FLAGS "${CMAKE_STATIC_LINKER_FLAGS} -fopenmp")
endif()
endif()
endif()
@ -533,7 +544,6 @@ if((CMAKE_CXX_COMPILER_ID STREQUAL "Intel") AND (CMAKE_CXX_STANDARD GREATER_EQUA
endif()
if(PKG_ATC OR PKG_AWPMD OR PKG_ML-QUIP OR PKG_ML-POD OR PKG_ELECTRODE OR PKG_RHEO OR BUILD_TOOLS)
enable_language(C)
if (NOT USE_INTERNAL_LINALG)
find_package(LAPACK)
find_package(BLAS)
@ -630,10 +640,6 @@ if(WITH_SWIG)
add_subdirectory(${LAMMPS_SWIG_DIR} swig)
endif()
set(CMAKE_TUNE_FLAGS "${CMAKE_TUNE_DEFAULT}" CACHE STRING "Compiler and machine specific optimization flags (compilation only)")
separate_arguments(CMAKE_TUNE_FLAGS)
target_compile_options(lammps PRIVATE ${CMAKE_TUNE_FLAGS})
target_compile_options(lmp PRIVATE ${CMAKE_TUNE_FLAGS})
########################################################################
# Basic system tests (standard libraries, headers, functions, types) #
########################################################################

102
cmake/Modules/LAMMPSInterfacePlugin.cmake
View File

@ -62,6 +62,9 @@ if(CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
endif()
set(CMAKE_POSITION_INDEPENDENT_CODE TRUE)
# skip over obsolete MPI-2 C++ bindings
set(MPI_CXX_SKIP_MPICXX TRUE)
#######
# helper functions from LAMMPSUtils.cmake
function(validate_option name values)
@ -128,8 +131,7 @@ endif()
################################################################################
# MPI configuration
if(NOT CMAKE_CROSSCOMPILING)
set(MPI_CXX_SKIP_MPICXX TRUE)
find_package(MPI QUIET)
find_package(MPI QUIET COMPONENTS CXX)
option(BUILD_MPI "Build MPI version" ${MPI_FOUND})
else()
option(BUILD_MPI "Build MPI version" OFF)
@ -141,78 +143,38 @@ if(BUILD_MPI)
set(MPI_CXX_SKIP_MPICXX TRUE)
# We use a non-standard procedure to cross-compile with MPI on Windows
if((CMAKE_SYSTEM_NAME STREQUAL "Windows") AND CMAKE_CROSSCOMPILING)
# Download and configure MinGW compatible MPICH development files for Windows
option(USE_MSMPI "Use Microsoft's MS-MPI SDK instead of MPICH2-1.4.1" OFF)
if(USE_MSMPI)
message(STATUS "Downloading and configuring MS-MPI 10.1 for Windows cross-compilation")
set(MPICH2_WIN64_DEVEL_URL "${LAMMPS_THIRDPARTY_URL}/msmpi-win64-devel.tar.gz" CACHE STRING "URL for MS-MPI (win64) tarball")
set(MPICH2_WIN64_DEVEL_MD5 "86314daf1bffb809f1fcbefb8a547490" CACHE STRING "MD5 checksum of MS-MPI (win64) tarball")
mark_as_advanced(MPICH2_WIN64_DEVEL_URL)
mark_as_advanced(MPICH2_WIN64_DEVEL_MD5)
message(STATUS "Downloading and configuring MS-MPI 10.1 for Windows cross-compilation")
set(MPICH2_WIN64_DEVEL_URL "${LAMMPS_THIRDPARTY_URL}/msmpi-win64-devel.tar.gz" CACHE STRING "URL for MS-MPI (win64) tarball")
set(MPICH2_WIN64_DEVEL_MD5 "86314daf1bffb809f1fcbefb8a547490" CACHE STRING "MD5 checksum of MS-MPI (win64) tarball")
mark_as_advanced(MPICH2_WIN64_DEVEL_URL)
mark_as_advanced(MPICH2_WIN64_DEVEL_MD5)
include(ExternalProject)
if(CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64")
ExternalProject_Add(mpi4win_build
URL ${MPICH2_WIN64_DEVEL_URL}
URL_MD5 ${MPICH2_WIN64_DEVEL_MD5}
CONFIGURE_COMMAND "" BUILD_COMMAND "" INSTALL_COMMAND ""
BUILD_BYPRODUCTS <SOURCE_DIR>/lib/libmsmpi.a)
else()
message(FATAL_ERROR "Only x86 64-bit builds are supported with MS-MPI")
endif()
ExternalProject_get_property(mpi4win_build SOURCE_DIR)
file(MAKE_DIRECTORY "${SOURCE_DIR}/include")
add_library(MPI::MPI_CXX UNKNOWN IMPORTED)
set_target_properties(MPI::MPI_CXX PROPERTIES
IMPORTED_LOCATION "${SOURCE_DIR}/lib/libmsmpi.a"
INTERFACE_INCLUDE_DIRECTORIES "${SOURCE_DIR}/include"
INTERFACE_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX")
add_dependencies(MPI::MPI_CXX mpi4win_build)
# set variables for status reporting at the end of CMake run
set(MPI_CXX_INCLUDE_PATH "${SOURCE_DIR}/include")
set(MPI_CXX_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX")
set(MPI_CXX_LIBRARIES "${SOURCE_DIR}/lib/libmsmpi.a")
include(ExternalProject)
if(CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64")
ExternalProject_Add(mpi4win_build
URL ${MPICH2_WIN64_DEVEL_URL}
URL_MD5 ${MPICH2_WIN64_DEVEL_MD5}
CONFIGURE_COMMAND "" BUILD_COMMAND "" INSTALL_COMMAND ""
BUILD_BYPRODUCTS <SOURCE_DIR>/lib/libmsmpi.a)
else()
# Download and configure custom MPICH files for Windows
message(STATUS "Downloading and configuring MPICH-1.4.1 for Windows")
set(MPICH2_WIN64_DEVEL_URL "${LAMMPS_THIRDPARTY_URL}/mpich2-win64-devel.tar.gz" CACHE STRING "URL for MPICH2 (win64) tarball")
set(MPICH2_WIN64_DEVEL_MD5 "4939fdb59d13182fd5dd65211e469f14" CACHE STRING "MD5 checksum of MPICH2 (win64) tarball")
mark_as_advanced(MPICH2_WIN64_DEVEL_URL)
mark_as_advanced(MPICH2_WIN64_DEVEL_MD5)
include(ExternalProject)
if(CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64")
ExternalProject_Add(mpi4win_build
URL ${MPICH2_WIN64_DEVEL_URL}
URL_MD5 ${MPICH2_WIN64_DEVEL_MD5}
CONFIGURE_COMMAND "" BUILD_COMMAND "" INSTALL_COMMAND ""
BUILD_BYPRODUCTS <SOURCE_DIR>/lib/libmpi.a)
else()
ExternalProject_Add(mpi4win_build
URL ${MPICH2_WIN32_DEVEL_URL}
URL_MD5 ${MPICH2_WIN32_DEVEL_MD5}
CONFIGURE_COMMAND "" BUILD_COMMAND "" INSTALL_COMMAND ""
BUILD_BYPRODUCTS <SOURCE_DIR>/lib/libmpi.a)
endif()
ExternalProject_get_property(mpi4win_build SOURCE_DIR)
file(MAKE_DIRECTORY "${SOURCE_DIR}/include")
add_library(MPI::MPI_CXX UNKNOWN IMPORTED)
set_target_properties(MPI::MPI_CXX PROPERTIES
IMPORTED_LOCATION "${SOURCE_DIR}/lib/libmpi.a"
INTERFACE_INCLUDE_DIRECTORIES "${SOURCE_DIR}/include"
INTERFACE_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX")
add_dependencies(MPI::MPI_CXX mpi4win_build)
# set variables for status reporting at the end of CMake run
set(MPI_CXX_INCLUDE_PATH "${SOURCE_DIR}/include")
set(MPI_CXX_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX")
set(MPI_CXX_LIBRARIES "${SOURCE_DIR}/lib/libmpi.a")
message(FATAL_ERROR "Only x86 64-bit builds are supported with MS-MPI")
endif()
ExternalProject_get_property(mpi4win_build SOURCE_DIR)
file(MAKE_DIRECTORY "${SOURCE_DIR}/include")
add_library(MPI::MPI_CXX UNKNOWN IMPORTED)
set_target_properties(MPI::MPI_CXX PROPERTIES
IMPORTED_LOCATION "${SOURCE_DIR}/lib/libmsmpi.a"
INTERFACE_INCLUDE_DIRECTORIES "${SOURCE_DIR}/include"
INTERFACE_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX=1")
add_dependencies(MPI::MPI_CXX mpi4win_build)
# set variables for status reporting at the end of CMake run
set(MPI_CXX_INCLUDE_PATH "${SOURCE_DIR}/include")
set(MPI_CXX_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX=1")
set(MPI_CXX_LIBRARIES "${SOURCE_DIR}/lib/libmsmpi.a")
else()
find_package(MPI REQUIRED)
find_package(MPI REQUIRED COMPONENTS 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 INTERFACE -DLAMMPS_LONGLONG_TO_LONG)

24
cmake/Modules/LAMMPSUtils.cmake
View File

@ -30,7 +30,7 @@ function(check_omp_h_include)
if(OpenMP_CXX_FOUND)
set(CMAKE_REQUIRED_FLAGS ${OpenMP_CXX_FLAGS})
set(CMAKE_REQUIRED_INCLUDES ${OpenMP_CXX_INCLUDE_DIRS})
set(CMAKE_REQUIRED_LINK_OPTIONS ${OpenMP_CXX_FLAGS})
separate_arguments(CMAKE_REQUIRED_LINK_OPTIONS NATIVE_COMMAND ${OpenMP_CXX_FLAGS}) # needs to be a list
set(CMAKE_REQUIRED_LIBRARIES ${OpenMP_CXX_LIBRARIES})
# there are all kinds of problems with finding omp.h
# for Clang and derived compilers so we pretend it is there.
@ -75,13 +75,25 @@ function(get_lammps_version version_header variable)
list(FIND MONTHS "${month}" month)
string(LENGTH ${day} day_length)
string(LENGTH ${month} month_length)
if(day_length EQUAL 1)
set(day "0${day}")
# no leading zero needed for new version string with dots
# if(day_length EQUAL 1)
# set(day "0${day}")
# endif()
# if(month_length EQUAL 1)
# set(month "0${month}")
#endif()
file(STRINGS ${version_header} line REGEX LAMMPS_UPDATE)
string(REGEX REPLACE "#define LAMMPS_UPDATE \"Update ([0-9]+)\"" "\\1" tweak "${line}")
if (line MATCHES "#define LAMMPS_UPDATE \"(Maintenance|Development)\"")
set(tweak "99")
endif()
if(month_length EQUAL 1)
set(month "0${month}")
if(NOT tweak)
set(tweak "0")
endif()
set(${variable} "${year}${month}${day}" PARENT_SCOPE)
# new version string with dots
set(${variable} "${year}.${month}.${day}.${tweak}" PARENT_SCOPE)
# old version string without dots
# set(${variable} "${year}${month}${day}" PARENT_SCOPE)
endfunction()
function(check_for_autogen_files source_dir)

99
cmake/Modules/MPI4WIN.cmake
View File

@ -1,74 +1,31 @@
# Download and configure MinGW compatible MPICH development files for Windows
option(USE_MSMPI "Use Microsoft's MS-MPI SDK instead of MPICH2-1.4.1" OFF)
# set-up MS-MPI library for Windows with MinGW compatibility
message(STATUS "Downloading and configuring MS-MPI 10.1 for Windows cross-compilation")
set(MPICH2_WIN64_DEVEL_URL "${LAMMPS_THIRDPARTY_URL}/msmpi-win64-devel.tar.gz" CACHE STRING "URL for MS-MPI (win64) tarball")
set(MPICH2_WIN64_DEVEL_MD5 "86314daf1bffb809f1fcbefb8a547490" CACHE STRING "MD5 checksum of MS-MPI (win64) tarball")
mark_as_advanced(MPICH2_WIN64_DEVEL_URL)
mark_as_advanced(MPICH2_WIN64_DEVEL_MD5)
if(USE_MSMPI)
message(STATUS "Downloading and configuring MS-MPI 10.1 for Windows cross-compilation")
set(MPICH2_WIN64_DEVEL_URL "${LAMMPS_THIRDPARTY_URL}/msmpi-win64-devel.tar.gz" CACHE STRING "URL for MS-MPI (win64) tarball")
set(MPICH2_WIN64_DEVEL_MD5 "86314daf1bffb809f1fcbefb8a547490" CACHE STRING "MD5 checksum of MS-MPI (win64) tarball")
mark_as_advanced(MPICH2_WIN64_DEVEL_URL)
mark_as_advanced(MPICH2_WIN64_DEVEL_MD5)
include(ExternalProject)
if(CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64")
ExternalProject_Add(mpi4win_build
URL ${MPICH2_WIN64_DEVEL_URL}
URL_MD5 ${MPICH2_WIN64_DEVEL_MD5}
CONFIGURE_COMMAND "" BUILD_COMMAND "" INSTALL_COMMAND ""
BUILD_BYPRODUCTS <SOURCE_DIR>/lib/libmsmpi.a)
else()
message(FATAL_ERROR "Only x86 64-bit builds are supported with MS-MPI")
endif()
ExternalProject_get_property(mpi4win_build SOURCE_DIR)
file(MAKE_DIRECTORY "${SOURCE_DIR}/include")
add_library(MPI::MPI_CXX UNKNOWN IMPORTED)
set_target_properties(MPI::MPI_CXX PROPERTIES
IMPORTED_LOCATION "${SOURCE_DIR}/lib/libmsmpi.a"
INTERFACE_INCLUDE_DIRECTORIES "${SOURCE_DIR}/include"
INTERFACE_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX")
add_dependencies(MPI::MPI_CXX mpi4win_build)
# set variables for status reporting at the end of CMake run
set(MPI_CXX_INCLUDE_PATH "${SOURCE_DIR}/include")
set(MPI_CXX_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX")
set(MPI_CXX_LIBRARIES "${SOURCE_DIR}/lib/libmsmpi.a")
include(ExternalProject)
if(CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64")
ExternalProject_Add(mpi4win_build
URL ${MPICH2_WIN64_DEVEL_URL}
URL_MD5 ${MPICH2_WIN64_DEVEL_MD5}
CONFIGURE_COMMAND "" BUILD_COMMAND "" INSTALL_COMMAND ""
BUILD_BYPRODUCTS <SOURCE_DIR>/lib/libmsmpi.a)
else()
message(STATUS "Downloading and configuring MPICH2-1.4.1 for Windows cross-compilation")
set(MPICH2_WIN64_DEVEL_URL "${LAMMPS_THIRDPARTY_URL}/mpich2-win64-devel.tar.gz" CACHE STRING "URL for MPICH2 (win64) tarball")
set(MPICH2_WIN32_DEVEL_URL "${LAMMPS_THIRDPARTY_URL}/mpich2-win32-devel.tar.gz" CACHE STRING "URL for MPICH2 (win32) tarball")
set(MPICH2_WIN64_DEVEL_MD5 "4939fdb59d13182fd5dd65211e469f14" CACHE STRING "MD5 checksum of MPICH2 (win64) tarball")
set(MPICH2_WIN32_DEVEL_MD5 "a61d153500dce44e21b755ee7257e031" CACHE STRING "MD5 checksum of MPICH2 (win32) tarball")
mark_as_advanced(MPICH2_WIN64_DEVEL_URL)
mark_as_advanced(MPICH2_WIN32_DEVEL_URL)
mark_as_advanced(MPICH2_WIN64_DEVEL_MD5)
mark_as_advanced(MPICH2_WIN32_DEVEL_MD5)
include(ExternalProject)
if(CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64")
ExternalProject_Add(mpi4win_build
URL ${MPICH2_WIN64_DEVEL_URL}
URL_MD5 ${MPICH2_WIN64_DEVEL_MD5}
CONFIGURE_COMMAND "" BUILD_COMMAND "" INSTALL_COMMAND ""
BUILD_BYPRODUCTS <SOURCE_DIR>/lib/libmpi.a)
else()
ExternalProject_Add(mpi4win_build
URL ${MPICH2_WIN32_DEVEL_URL}
URL_MD5 ${MPICH2_WIN32_DEVEL_MD5}
CONFIGURE_COMMAND "" BUILD_COMMAND "" INSTALL_COMMAND ""
BUILD_BYPRODUCTS <SOURCE_DIR>/lib/libmpi.a)
endif()
ExternalProject_get_property(mpi4win_build SOURCE_DIR)
file(MAKE_DIRECTORY "${SOURCE_DIR}/include")
add_library(MPI::MPI_CXX UNKNOWN IMPORTED)
set_target_properties(MPI::MPI_CXX PROPERTIES
IMPORTED_LOCATION "${SOURCE_DIR}/lib/libmpi.a"
INTERFACE_INCLUDE_DIRECTORIES "${SOURCE_DIR}/include"
INTERFACE_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX")
add_dependencies(MPI::MPI_CXX mpi4win_build)
# set variables for status reporting at the end of CMake run
set(MPI_CXX_INCLUDE_PATH "${SOURCE_DIR}/include")
set(MPI_CXX_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX")
set(MPI_CXX_LIBRARIES "${SOURCE_DIR}/lib/libmpi.a")
message(FATAL_ERROR "Only x86 64-bit builds are supported with MS-MPI")
endif()
ExternalProject_get_property(mpi4win_build SOURCE_DIR)
file(MAKE_DIRECTORY "${SOURCE_DIR}/include")
add_library(MPI::MPI_CXX UNKNOWN IMPORTED)
set_target_properties(MPI::MPI_CXX PROPERTIES
IMPORTED_LOCATION "${SOURCE_DIR}/lib/libmsmpi.a"
INTERFACE_INCLUDE_DIRECTORIES "${SOURCE_DIR}/include"
INTERFACE_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX=1")
add_dependencies(MPI::MPI_CXX mpi4win_build)
# set variables for status reporting at the end of CMake run
set(MPI_CXX_INCLUDE_PATH "${SOURCE_DIR}/include")
set(MPI_CXX_COMPILE_DEFINITIONS "MPICH_SKIP_MPICXX=1")
set(MPI_CXX_LIBRARIES "${SOURCE_DIR}/lib/libmsmpi.a")

8
cmake/Modules/Packages/COLVARS.cmake
View File

@ -14,10 +14,6 @@ endif()
add_library(colvars STATIC ${COLVARS_SOURCES})
target_compile_definitions(colvars PRIVATE -DCOLVARS_LAMMPS)
separate_arguments(CMAKE_TUNE_FLAGS)
foreach(_FLAG ${CMAKE_TUNE_FLAGS})
target_compile_options(colvars PRIVATE ${_FLAG})
endforeach()
set_target_properties(colvars PROPERTIES OUTPUT_NAME lammps_colvars${LAMMPS_MACHINE})
target_include_directories(colvars PUBLIC ${LAMMPS_LIB_SOURCE_DIR}/colvars)
# The line below is needed to locate math_eigen_impl.h
@ -30,6 +26,10 @@ if(BUILD_OMP)
target_link_libraries(colvars PRIVATE OpenMP::OpenMP_CXX)
endif()
if(BUILD_MPI)
target_link_libraries(colvars PUBLIC MPI::MPI_CXX)
endif()
if(COLVARS_DEBUG)
# Need to export the define publicly to be valid in interface code
target_compile_definitions(colvars PUBLIC -DCOLVARS_DEBUG)

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

@ -189,7 +189,7 @@ if(GPU_API STREQUAL "CUDA")
endif()
add_executable(nvc_get_devices ${LAMMPS_LIB_SOURCE_DIR}/gpu/geryon/ucl_get_devices.cpp)
target_compile_definitions(nvc_get_devices PRIVATE -DUCL_CUDADR)
target_compile_definitions(nvc_get_devices PRIVATE -DUCL_CUDADR -DLAMMPS_${LAMMPS_SIZES})
target_link_libraries(nvc_get_devices PRIVATE ${CUDA_LIBRARIES} ${CUDA_CUDA_LIBRARY})
target_include_directories(nvc_get_devices PRIVATE ${CUDA_INCLUDE_DIRS})
@ -489,7 +489,7 @@ 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_compile_definitions(gpu PRIVATE -DLAMMPS_${LAMMPS_SIZES})
target_sources(lammps PRIVATE ${GPU_SOURCES})
target_include_directories(lammps PRIVATE ${GPU_SOURCES_DIR})

10
cmake/Modules/Packages/MC.cmake
View File

@ -7,3 +7,13 @@ if(NOT PKG_MANYBODY)
list(REMOVE_ITEM LAMMPS_SOURCES ${LAMMPS_SOURCE_DIR}/MC/fix_sgcmc.cpp)
set_property(TARGET lammps PROPERTY SOURCES "${LAMMPS_SOURCES}")
endif()
# fix neighbor/swap may only be installed if also the VORONOI package is installed
if(NOT PKG_VORONOI)
get_property(LAMMPS_FIX_HEADERS GLOBAL PROPERTY FIX)
list(REMOVE_ITEM LAMMPS_FIX_HEADERS ${LAMMPS_SOURCE_DIR}/MC/fix_neighbor_swap.h)
set_property(GLOBAL PROPERTY FIX "${LAMMPS_FIX_HEADERS}")
get_target_property(LAMMPS_SOURCES lammps SOURCES)
list(REMOVE_ITEM LAMMPS_SOURCES ${LAMMPS_SOURCE_DIR}/MC/fix_neighbor_swap.cpp)
set_property(TARGET lammps PROPERTY SOURCES "${LAMMPS_SOURCES}")
endif()

15
cmake/Modules/Packages/SCAFACOS.cmake
View File

@ -14,27 +14,16 @@ endif()
option(DOWNLOAD_SCAFACOS "Download ScaFaCoS library instead of using an already installed one" ${DOWNLOAD_SCAFACOS_DEFAULT})
if(DOWNLOAD_SCAFACOS)
message(STATUS "ScaFaCoS download requested - we will build our own")
set(SCAFACOS_URL "https://github.com/scafacos/scafacos/releases/download/v1.0.1/scafacos-1.0.1.tar.gz" CACHE STRING "URL for SCAFACOS tarball")
set(SCAFACOS_MD5 "bd46d74e3296bd8a444d731bb10c1738" CACHE STRING "MD5 checksum of SCAFACOS tarball")
set(SCAFACOS_URL "https://github.com/scafacos/scafacos/releases/download/v1.0.4/scafacos-1.0.4.tar.gz" CACHE STRING "URL for SCAFACOS tarball")
set(SCAFACOS_MD5 "23867540ec32e63ce71d6ecc105278d2" CACHE STRING "MD5 checksum of SCAFACOS tarball")
mark_as_advanced(SCAFACOS_URL)
mark_as_advanced(SCAFACOS_MD5)
GetFallbackURL(SCAFACOS_URL SCAFACOS_FALLBACK)
# version 1.0.1 needs a patch to compile and linke cleanly with GCC 10 and later.
file(DOWNLOAD ${LAMMPS_THIRDPARTY_URL}/scafacos-1.0.1-fix.diff ${CMAKE_CURRENT_BINARY_DIR}/scafacos-1.0.1.fix.diff
EXPECTED_HASH MD5=4baa1333bb28fcce102d505e1992d032)
find_program(HAVE_PATCH patch)
if(NOT HAVE_PATCH)
message(FATAL_ERROR "The 'patch' program is required to build the ScaFaCoS library")
endif()
include(ExternalProject)
ExternalProject_Add(scafacos_build
URL ${SCAFACOS_URL} ${SCAFACOS_FALLBACK}
URL_MD5 ${SCAFACOS_MD5}
PATCH_COMMAND patch -p1 < ${CMAKE_CURRENT_BINARY_DIR}/scafacos-1.0.1.fix.diff
CONFIGURE_COMMAND <SOURCE_DIR>/configure --prefix=<INSTALL_DIR> --disable-doc
--enable-fcs-solvers=fmm,p2nfft,direct,ewald,p3m
--with-internal-fftw --with-internal-pfft

15
cmake/Modules/Testing.cmake
View File

@ -21,11 +21,11 @@ if(ENABLE_TESTING)
# also only verified with Fedora Linux > 30 and Ubuntu 18.04 or 22.04+(Ubuntu 20.04 fails)
if((CMAKE_SYSTEM_NAME STREQUAL "Linux")
AND ((CMAKE_CXX_COMPILER_ID STREQUAL "GNU") OR (CMAKE_CXX_COMPILER_ID STREQUAL "Clang")))
if(((CMAKE_LINUX_DISTRO STREQUAL "Ubuntu") AND
((CMAKE_DISTRO_VERSION VERSION_LESS_EQUAL 18.04) OR (CMAKE_DISTRO_VERSION VERSION_GREATER_EQUAL 22.04)))
if(((CMAKE_LINUX_DISTRO STREQUAL "Ubuntu") AND (CMAKE_DISTRO_VERSION VERSION_GREATER_EQUAL 22.04))
OR ((CMAKE_LINUX_DISTRO STREQUAL "Fedora") AND (CMAKE_DISTRO_VERSION VERSION_GREATER 30)))
include(CheckCXXCompilerFlag)
set(CMAKE_CUSTOM_LINKER_DEFAULT default)
check_cxx_compiler_flag(--ld-path=${CMAKE_LINKER} HAVE_LD_PATH_FLAG)
check_cxx_compiler_flag(-fuse-ld=mold HAVE_MOLD_LINKER_FLAG)
check_cxx_compiler_flag(-fuse-ld=lld HAVE_LLD_LINKER_FLAG)
check_cxx_compiler_flag(-fuse-ld=gold HAVE_GOLD_LINKER_FLAG)
@ -50,6 +50,17 @@ if(ENABLE_TESTING)
if(NOT "${CMAKE_CUSTOM_LINKER}" STREQUAL "default")
target_link_options(lammps PUBLIC -fuse-ld=${CMAKE_CUSTOM_LINKER})
endif()
if(HAVE_LD_PATH_FLAG)
if("${CMAKE_CUSTOM_LINKER}" STREQUAL "mold")
target_link_options(lammps PUBLIC --ld-path=${HAVE_MOLD_LINKER_BIN})
elseif("${CMAKE_CUSTOM_LINKER}" STREQUAL "lld")
target_link_options(lammps PUBLIC --ld-path=${HAVE_LLD_LINKER_BIN})
elseif("${CMAKE_CUSTOM_LINKER}" STREQUAL "gold")
target_link_options(lammps PUBLIC --ld-path=${HAVE_GOLD_LINKER_BIN})
elseif("${CMAKE_CUSTOM_LINKER}" STREQUAL "bfd")
target_link_options(lammps PUBLIC --ld-path=${HAVE_BFD_LINKER_BIN})
endif()
endif()
endif()
endif()

11
cmake/presets/hip_amd.cmake
View File

@ -19,12 +19,19 @@ set(CMAKE_C_FLAGS_RELEASE "-O3 -DNDEBUG" CACHE STRING "" FORCE)
set(MPI_CXX "hipcc" CACHE STRING "" FORCE)
set(MPI_CXX_COMPILER "mpicxx" CACHE STRING "" FORCE)
set(MPI_C "hipcc" CACHE STRING "" FORCE)
set(MPI_C_COMPILER "mpicc" CACHE STRING "" FORCE)
# change as needed. This is for Fedora Linux 41 and 42
set(_libomp_root "/usr/lib/clang/18")
# we need to explicitly specify the include dir, since hipcc will
# compile each file twice and doesn't find omp.h the second time
unset(HAVE_OMP_H_INCLUDE CACHE)
set(OpenMP_C "hipcc" CACHE STRING "" FORCE)
set(OpenMP_C_FLAGS "-fopenmp" CACHE STRING "" FORCE)
set(OpenMP_C_FLAGS "-fopenmp=libomp -I${_libomp_root}/include" CACHE STRING "" FORCE)
set(OpenMP_C_LIB_NAMES "omp" CACHE STRING "" FORCE)
set(OpenMP_CXX "hipcc" CACHE STRING "" FORCE)
set(OpenMP_CXX_FLAGS "-fopenmp" CACHE STRING "" FORCE)
set(OpenMP_CXX_FLAGS "-fopenmp=libomp -I${_libomp_root}/include" CACHE STRING "" FORCE)
set(OpenMP_CXX_LIB_NAMES "omp" CACHE STRING "" FORCE)
set(OpenMP_omp_LIBRARY "libomp.so" CACHE PATH "" FORCE)

13
cmake/presets/kokkos-hip.cmake
View File

@ -1,22 +1,21 @@
# preset that enables KOKKOS and selects HIP compilation with OpenMP
# enabled as well. Also sets some performance related compiler flags.
# preset that enables KOKKOS and selects HIP compilation withOUT OpenMP.
# Kokkos OpenMP is not compatible with the second pass of hipcc.
set(PKG_KOKKOS ON CACHE BOOL "" FORCE)
set(Kokkos_ENABLE_SERIAL ON CACHE BOOL "" FORCE)
set(Kokkos_ENABLE_OPENMP ON CACHE BOOL "" FORCE)
set(Kokkos_ENABLE_OPENMP OFF CACHE BOOL "" FORCE)
set(Kokkos_ENABLE_CUDA OFF CACHE BOOL "" FORCE)
set(Kokkos_ENABLE_HIP ON CACHE BOOL "" FORCE)
set(Kokkos_ARCH_VEGA90A on CACHE BOOL "" FORCE)
set(Kokkos_ENABLE_HIP_MULTIPLE_KERNEL_INSTANTIATIONS ON CACHE BOOL "" FORCE)
set(BUILD_OMP ON CACHE BOOL "" FORCE)
set(CMAKE_CXX_COMPILER hipcc CACHE STRING "" FORCE)
set(CMAKE_TUNE_FLAGS "-munsafe-fp-atomics" CACHE STRING "" FORCE)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -munsafe-fp-atomics" CACHE STRING "" FORCE)
# If KSPACE is also enabled, use CUFFT for FFTs
# If KSPACE is also enabled, use HIPFFT for FFTs
set(FFT_KOKKOS "HIPFFT" CACHE STRING "" FORCE)
# hide deprecation warnings temporarily for stable release
set(Kokkos_ENABLE_DEPRECATION_WARNINGS OFF CACHE BOOL "" FORCE)
#set(Kokkos_ENABLE_DEPRECATION_WARNINGS OFF CACHE BOOL "" FORCE)
# these flags are needed to build with Cray MPICH on OLCF Crusher
#-D CMAKE_CXX_FLAGS="-I/${MPICH_DIR}/include"

11
cmake/presets/kokkos-sycl-intel.cmake
View File

@ -21,9 +21,10 @@ set(CMAKE_C_COMPILER icx CACHE STRING "" FORCE)
set(CMAKE_Fortran_COMPILER "" CACHE STRING "" FORCE)
set(MPI_CXX_COMPILER "mpicxx" CACHE STRING "" FORCE)
set(CMAKE_CXX_STANDARD 17 CACHE STRING "" FORCE)
# Silence everything
set(CMAKE_CXX_FLAGS "-w" CACHE STRING "" FORCE)
# set(_intel_sycl_flags " -w -fsycl -flink-huge-device-code -fsycl-targets=spir64_gen "
set(_intel_sycl_flags " -w -fsycl -fsycl-device-code-split=per_kernel -fsycl-targets=spir64_gen ")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${_intel_sycl_flags}" CACHE STRING "" FORCE)
#set(CMAKE_EXE_LINKER_FLAGS "-fsycl -flink-huge-device-code -fsycl-targets=spir64_gen " CACHE STRING "" FORCE)
#set(CMAKE_TUNE_FLAGS "-O3 -fsycl -fsycl-device-code-split=per_kernel -fsycl-targets=spir64_gen" CACHE STRING "" FORCE)
set(CMAKE_EXE_LINKER_FLAGS "-fsycl -flink-huge-device-code " CACHE STRING "" FORCE)
set(CMAKE_TUNE_FLAGS "-O3 -fsycl -fsycl-device-code-split=per_kernel " CACHE STRING "" FORCE)
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -fsycl -flink-huge-device-code " CACHE STRING "" FORCE)

6
cmake/presets/kokkos-sycl-nvidia.cmake
View File

@ -14,5 +14,7 @@ set(Kokkos_ENABLE_DEPRECATION_WARNINGS OFF CACHE BOOL "" FORCE)
set(CMAKE_CXX_COMPILER clang++ CACHE STRING "" FORCE)
set(MPI_CXX_COMPILER "mpicxx" CACHE STRING "" FORCE)
set(CMAKE_CXX_STANDARD 17 CACHE STRING "" FORCE)
set(CMAKE_SHARED_LINKER_FLAGS "-Xsycl-target-frontend -O3" CACHE STRING "" FORCE)
set(CMAKE_TUNE_FLAGS "-fgpu-inline-threshold=100000 -Xsycl-target-frontend -O3 -Xsycl-target-frontend -ffp-contract=on -Wno-unknown-cuda-version" CACHE STRING "" FORCE)
set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -Xsycl-target-frontend -O3 " CACHE STRING "" FORCE)
set(_intel_sycl_flags "-fgpu-inline-threshold=100000 -Xsycl-target-frontend -O3 -Xsycl-target-frontend -ffp-contract=on -Wno-unknown-cuda-version")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${_intel_sycl_flags}" CACHE STRING "" FORCE)

2
cmake/presets/mingw-cross.cmake
View File

@ -91,7 +91,7 @@ endif()
set(DOWNLOAD_VORO ON CACHE BOOL "" FORCE)
set(DOWNLOAD_EIGEN3 ON CACHE BOOL "" FORCE)
set(LAMMPS_MEMALIGN "0" CACHE STRING "" FORCE)
set(CMAKE_TUNE_FLAGS "-Wno-missing-include-dirs" CACHE STRING "" FORCE)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-missing-include-dirs" CACHE STRING "" FORCE)
set(CMAKE_EXE_LINKER_FLAGS "-Wl,--enable-stdcall-fixup,--as-needed,-lssp" CACHE STRING "" FORCE)
set(CMAKE_SHARED_LINKER_FLAGS "-Wl,--enable-stdcall-fixup,--as-needed,-lssp" CACHE STRING "" FORCE)
set(BUILD_TOOLS ON CACHE BOOL "" FORCE)

2
cmake/presets/windows-intel-llvm.cmake
View File

@ -5,4 +5,4 @@ set(CMAKE_C_COMPILER "icx" CACHE STRING "" FORCE)
set(CMAKE_Fortran_COMPILER "ifx" CACHE STRING "" FORCE)
set(INTEL_LRT_MODE "C++11" CACHE STRING "" FORCE)
unset(HAVE_OMP_H_INCLUDE CACHE)
set(CMAKE_TUNE_FLAGS -Wno-unused-command-line-argument)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-unused-command-line-argument" CACHE STRING "" FORCE)

6
doc/graphviz/lammps-releases.dot
View File

@ -5,13 +5,13 @@ digraph releases {
github -> develop [label="Merge commits"];
{
rank = "same";
work [shape="none" label="Development branches:"]
work [shape="none" label="Development branches:" fontname="bold"]
develop [label="'develop' branch" height=0.75];
maintenance [label="'maintenance' branch" height=0.75];
};
{
rank = "same";
upload [shape="none" label="Release branches:"]
upload [shape="none" label="Release branches:" fontname="bold"]
release [label="'release' branch" height=0.75];
stable [label="'stable' branch" height=0.75];
};
@ -22,7 +22,7 @@ digraph releases {
maintenance -> stable [label="Updates to stable release"];
{
rank = "same";
tag [shape="none" label="Applied tags:"];
tag [shape="none" label="Applied tags:" fontname="bold"];
patchtag [shape="box" label="patch_<date>"];
stabletag [shape="box" label="stable_<date>"];
updatetag [shape="box" label="stable_<date>_update<num>"];

24
doc/src/Build.rst
View File

@ -14,32 +14,10 @@ As an alternative, you can download a package with pre-built executables
or automated build trees, as described in the :doc:`Install <Install>`
section of the manual.
Prerequisites
-------------
Which software you need to compile and use LAMMPS strongly depends on
which :doc:`features and settings <Build_settings>` and which
:doc:`optional packages <Packages_list>` you are trying to include.
Common to all is that you need a C++ and C compiler, where the C++
compiler has to support at least the C++11 standard (note that some
compilers require command-line flag to activate C++11 support).
Furthermore, if you are building with CMake, you need at least CMake
version 3.20 and a compatible build tool (make or ninja-build); if you
are building the the legacy GNU make based build system you need GNU
make (other make variants are not going to work since the build system
uses features unique to GNU make) and a Unix-like build environment with
a Bourne shell, and shell tools like "sed", "grep", "touch", "test",
"tr", "cp", "mv", "rm", "ln", "diff" and so on. Parts of LAMMPS
interface with or use Python version 3.6 or later.
The LAMMPS developers aim to keep LAMMPS very portable and usable -
at least in parts - on most operating systems commonly used for
running MD simulations. Please see the :doc:`section on portablility
<Intro_portability>` for more details.
.. toctree::
:maxdepth: 1
Build_prerequisites
Build_cmake
Build_make
Build_link

10
doc/src/Build_basics.rst
View File

@ -212,11 +212,7 @@ LAMMPS.
You can tell CMake to look for a specific compiler with setting
CMake variables (listed below) during configuration. For a few
common choices, there are also presets in the ``cmake/presets``
folder. For convenience, there is a ``CMAKE_TUNE_FLAGS`` variable
that can be set to apply global compiler options (applied to
compilation only), to be used for adding compiler or host specific
optimization flags in addition to the "flags" variables listed
below. You may also specify the corresponding ``CMAKE_*_FLAGS``
folder. You may also specify the corresponding ``CMAKE_*_FLAGS``
variables individually, if you want to experiment with alternate
optimization flags. You should specify all 3 compilers, so that
the (few) LAMMPS source files written in C or Fortran are built
@ -266,10 +262,6 @@ LAMMPS.
``-C ../cmake/presets/pgi.cmake`` will switch the compiler to the PGI compilers,
and ``-C ../cmake/presets/nvhpc.cmake`` will switch to the NVHPC compilers.
Furthermore, you can set ``CMAKE_TUNE_FLAGS`` to specifically add
compiler flags to tune for optimal performance on given hosts.
This variable is empty by default.
.. note::
When the cmake command completes, it prints a summary to the

22
doc/src/Build_prerequisites.rst Normal file
View File

@ -0,0 +1,22 @@
Prerequisites
-------------
Which software you need to compile and use LAMMPS strongly depends on
which :doc:`features and settings <Build_settings>` and which
:doc:`optional packages <Packages_list>` you are trying to include.
Common to all is that you need a C++ and C compiler, where the C++
compiler has to support at least the C++11 standard (note that some
compilers require command-line flag to activate C++11 support).
Furthermore, if you are building with CMake, you need at least CMake
version 3.20 and a compatible build tool (make or ninja-build); if you
are building the the legacy GNU make based build system you need GNU
make (other make variants are not going to work since the build system
uses features unique to GNU make) and a Unix-like build environment with
a Bourne shell, and shell tools like "sed", "grep", "touch", "test",
"tr", "cp", "mv", "rm", "ln", "diff" and so on. Parts of LAMMPS
interface with or use Python version 3.6 or later.
The LAMMPS developers aim to keep LAMMPS very portable and usable -
at least in parts - on most operating systems commonly used for
running MD simulations. Please see the :doc:`section on portablility
<Intro_portability>` for more details.

38
doc/src/Build_settings.rst
View File

@ -18,7 +18,6 @@ explains how to do this for building both with CMake and make.
* `Memory allocation alignment`_
* `Workaround for long long integers`_
* `Exception handling when using LAMMPS as a library`_ to capture errors
* `Trigger selected floating-point exceptions`_
----------
@ -659,40 +658,3 @@ code has to be set up to *catch* exceptions thrown from within LAMMPS.
throw an exception and thus other MPI ranks may get stuck waiting for
messages from the ones with errors.
----------
.. _trap_fpe:
Trigger selected floating-point exceptions
------------------------------------------
Many kinds of CPUs have the capability to detect when a calculation
results in an invalid math operation, like a division by zero or calling
the square root with a negative argument. The default behavior on
most operating systems is to continue and have values for ``NaN`` (= not
a number) or ``Inf`` (= infinity). This allows software to detect and
recover from such conditions. This behavior can be changed, however,
often through use of compiler flags. On Linux systems (or more general
on systems using the GNU C library), these so-called floating-point traps
can also be selectively enabled through library calls. LAMMPS supports
that by setting the ``-DLAMMPS_TRAP_FPE`` pre-processor define. As it is
done in the ``main()`` function, this applies only to the standalone
executable, not the library.
.. tabs::
.. tab:: CMake build
.. code-block:: bash
-D CMAKE_TUNE_FLAGS=-DLAMMPS_TRAP_FPE
.. tab:: Traditional make
.. code-block:: make
LMP_INC = -DLAMMPS_TRAP_FPE <other LMP_INC settings>
After compilation with this flag set, the LAMMPS executable will stop
and produce a core dump when a division by zero, overflow, illegal math
function argument or other invalid floating point operation is encountered.

4
doc/src/Commands_fix.rst
View File

@ -30,6 +30,7 @@ OPT.
* :doc:`ave/grid <fix_ave_grid>`
* :doc:`ave/histo <fix_ave_histo>`
* :doc:`ave/histo/weight <fix_ave_histo>`
* :doc:`ave/moments <fix_ave_moments>`
* :doc:`ave/time <fix_ave_time>`
* :doc:`aveforce <fix_aveforce>`
* :doc:`balance <fix_balance>`
@ -78,6 +79,7 @@ OPT.
* :doc:`flow/gauss <fix_flow_gauss>`
* :doc:`freeze (k) <fix_freeze>`
* :doc:`gcmc <fix_gcmc>`
* :doc:`gjf <fix_gjf>`
* :doc:`gld <fix_gld>`
* :doc:`gle <fix_gle>`
* :doc:`gravity (ko) <fix_gravity>`
@ -114,6 +116,7 @@ OPT.
* :doc:`mvv/tdpd <fix_mvv_dpd>`
* :doc:`neb <fix_neb>`
* :doc:`neb/spin <fix_neb_spin>`
* :doc:`neighbor/swap <fix_neighbor_swap>`
* :doc:`nonaffine/displacement <fix_nonaffine_displacement>`
* :doc:`nph (ko) <fix_nh>`
* :doc:`nph/asphere (o) <fix_nph_asphere>`
@ -219,6 +222,7 @@ OPT.
* :doc:`rigid/small (o) <fix_rigid>`
* :doc:`rx (k) <fix_rx>`
* :doc:`saed/vtk <fix_saed_vtk>`
* :doc:`set <fix_set>`
* :doc:`setforce (k) <fix_setforce>`
* :doc:`setforce/spin <fix_setforce>`
* :doc:`sgcmc <fix_sgcmc>`

1
doc/src/Commands_pair.rst
View File

@ -184,6 +184,7 @@ OPT.
* :doc:`lj/long/dipole/long <pair_dipole>`
* :doc:`lj/long/tip4p/long (o) <pair_lj_long>`
* :doc:`lj/mdf <pair_mdf>`
* :doc:`lj/pirani (o) <pair_lj_pirani>`
* :doc:`lj/relres (o) <pair_lj_relres>`
* :doc:`lj/spica (gko) <pair_spica>`
* :doc:`lj/spica/coul/long (gko) <pair_spica>`

17
doc/src/Commands_removed.rst
View File

@ -1,7 +1,7 @@
Removed commands and packages
=============================
.. contents:: \
.. contents::
------
@ -12,10 +12,21 @@ stop LAMMPS and print a suitable error message in most cases, when a
style/command is used that has been removed or will replace the command
with the direct alternative (if available) and print a warning.
GJF formulation in fix langevin
-------------------------------
.. deprecated:: TBD
The *gjf* keyword in fix langevin is deprecated and will be removed
soon. The GJF functionality has been moved to its own fix style
:doc:`fix gjf <fix_gjf>` and it is strongly recommended to use that
fix instead.
LAMMPS shell
------------
.. versionchanged:: 29Aug2024
.. deprecated:: 29Aug2024
The LAMMPS shell has been removed from the LAMMPS distribution. Users
are encouraged to use the :ref:`LAMMPS-GUI <lammps_gui>` tool instead.
@ -23,7 +34,7 @@ are encouraged to use the :ref:`LAMMPS-GUI <lammps_gui>` tool instead.
i-PI tool
---------
.. versionchanged:: 27Jun2024
.. deprecated:: 27Jun2024
The i-PI tool has been removed from the LAMMPS distribution. Instead,
instructions to install i-PI from PyPI via pip are provided.

45
doc/src/Developer_updating.rst
View File

@ -29,6 +29,7 @@ Available topics in mostly chronological order are:
- `Rename of fix STORE/PERATOM to fix STORE/ATOM and change of arguments`_
- `Use Output::get_dump_by_id() instead of Output::find_dump()`_
- `Refactored grid communication using Grid3d/Grid2d classes instead of GridComm`_
- `FLERR as first argument to minimum image functions in Domain class`_
----
@ -610,3 +611,47 @@ KSpace solvers which use distributed FFT grids:
- ``src/KSPACE/pppm.cpp``
This change is **required** or else the code will not compile.
FLERR as first argument to minimum image functions in Domain class
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. versionchanged:: TBD
The ``Domain::minimum_image()`` and ``Domain::minimum_image_big()``
functions were changed to take the ``FLERR`` macros as first argument.
This way the error message indicates *where* the function was called
instead of pointing to the implementation of the function. Example:
Old:
.. code-block:: c++
double delx1 = x[i1][0] - x[i2][0];
double dely1 = x[i1][1] - x[i2][1];
double delz1 = x[i1][2] - x[i2][2];
domain->minimum_image(delx1, dely1, delz1);
double r1 = sqrt(delx1 * delx1 + dely1 * dely1 + delz1 * delz1);
double delx2 = x[i3][0] - x[i2][0];
double dely2 = x[i3][1] - x[i2][1];
double delz2 = x[i3][2] - x[i2][2];
domain->minimum_image_big(delx2, dely2, delz2);
double r2 = sqrt(delx2 * delx2 + dely2 * dely2 + delz2 * delz2);
New:
.. code-block:: c++
double delx1 = x[i1][0] - x[i2][0];
double dely1 = x[i1][1] - x[i2][1];
double delz1 = x[i1][2] - x[i2][2];
domain->minimum_image(FLERR, delx1, dely1, delz1);
double r1 = sqrt(delx1 * delx1 + dely1 * dely1 + delz1 * delz1);
double delx2 = x[i3][0] - x[i2][0];
double dely2 = x[i3][1] - x[i2][1];
double delz2 = x[i3][2] - x[i2][2];
domain->minimum_image_big(FLERR, delx2, dely2, delz2);
double r2 = sqrt(delx2 * delx2 + dely2 * dely2 + delz2 * delz2);
This change is **required** or else the code will not compile.

74
doc/src/Errors_details.rst
View File

@ -159,13 +159,17 @@ angle, dihedral, or improper with just one atom in the actual
sub-domain. Typically, this cutoff is set to the largest cutoff from
the :doc:`pair style(s) <pair_style>` plus the :doc:`neighbor list skin
distance <neighbor>` and will typically be sufficient for all bonded
interactions. But if the pair style cutoff is small, this may not be
enough. LAMMPS will print a warning in this case using some heuristic
based on the equilibrium bond length, but that still may not be
sufficient for cases where the force constants are small and thus bonds
may be stretched very far. The communication cutoff can be adjusted
with :doc:`comm_modify cutoff \<value\> <comm_modify>`, but setting this
too large will waste CPU time and memory.
interactions. But if the pair style cutoff is small (e.g. with a
repulsive-only Lennard-Jones potential) this may not be enough. It is
even worse if there is no pair style defined (or the pair style is set
to "none"), since then there will be no ghost atoms created at all.
The communication cutoff can be set or adjusted with :doc:`comm_modify
cutoff \<value\> <comm_modify>`, but setting this too large will waste
CPU time and memory. LAMMPS will print warnings in these cases. For
bonds it uses some heuristic based on the equilibrium bond length, but
that still may not be sufficient for cases where the force constants are
small and thus bonds may be stretched very far.
.. _hint09:
@ -982,3 +986,59 @@ order of preference there are:
- Send an email to ``developers@lammps.org``
- Send an email to an :doc:`individual LAMMPS developer <Intro_authors>`
that you know and trust
.. _err0036:
Neighbor list overflow, boost neigh_modify one
----------------------------------------------
The neighbor list code in LAMMPS uses a special memory allocation strategy
to speed up building and accessing neighbor lists.
Instead of making a memory allocation for each list of neighbors of the atoms
LAMMPS allocates "pages" that have room for several neighbor lists. This has
two main advantages:
#. It is not needed to first count how many neighbors there are for an
atom to determine the storage required. Since the pages are much
larger than individual lists, LAMMPS just "fills up" the page until
there is not enough space left and then allocates a new page.
#. There are fewer calls to the memory allocator functions (which can be
time consuming for long-running jobs and fragmented memory space) and
the resulting neighbor lists are close to each other physically which
improves cache efficiency.
This is controlled by the two parameters "one" and "page", respectively,
that can be set via the :doc:`neigh_modify command <neigh_modify>`. The
parameter "one" is the maximum number of entries in a list of neighbors
for a single atom. If an atom has more neighbors as the "one" parameter
allows, the "overflow" error message is triggered. The parameter "page"
sets the size of the page. The neighbor list code checks, if there are
"one" entries left in the current page. If not, a new page is allocated.
The default settings are suitable for most systems. They need to be
changed, for instance, when simulating a system with a very high density
or when setting a very long cutoff (e.g. :math:`\gtrapprox 15 \AA` with
:doc:`units real <units>`). The value of "page" **must** be at least
10x the value of "one", but 50x to 100x are recommended to avoid wasting
memory. The neighbor list storage is typically the largest amount of
RAM required by a LAMMPS calculation.
Even though the LAMMPS error message recommends to increase the "one"
parameter, this may not always be the correct solution. The neighbor
list overflow can also be a symptom for some other error that cannot be
easily detected. For example, a frequent reason for an (unexpected)
high density are incorrect box boundaries (since LAMMPS wraps atoms back
into the principal box with periodic boundaries) or coordinates provided
as fractional coordinates. In both cases, LAMMPS cannot easily know
whether the input geometry has such a high density (and thus requiring
more neighbor list storage per atom) by intention. Rather than blindly
increasing the "one" parameter, it is thus worth checking if this is
justified by the combination of density and cutoff.
When boosting (= increasing) the "one" parameter, it is recommended to
also increase the value for the "page" parameter to maintain the ratio
between "one" and "page" to reduce waste of memory. For some more
details, please check out the documentation for the :doc:`neigh_modify
command <neigh_modify>`.

1
doc/src/Howto.rst
View File

@ -66,6 +66,7 @@ Force fields howto
:name: force_howto
:maxdepth: 1
Howto_FFgeneral
Howto_bioFF
Howto_amoeba
Howto_tip3p

55
doc/src/Howto_FFgeneral.rst Normal file
View File

@ -0,0 +1,55 @@
Some general force field considerations
=======================================
A compact summary of the concepts, definitions, and properties of force
fields with explicit bonded interactions (like the ones discussed in
this HowTo) is given in :ref:`(Gissinger) <Typelabel2>`.
A force field has 2 parts: the formulas that define its potential
functions and the coefficients used for a particular system. To assign
parameters it is first required to assign atom types. Those are not
only based on the elements, but also on the chemical environment due to
the atoms bound to them. This often follows the chemical concept of
*functional groups*. Example: a carbon atom bound with a single bond to
a single OH-group (alcohol) would be a different atom type than a carbon
atom bound to a methyl CH3 group (aliphatic carbon). The atom types
usually then determine the non-bonded Lennard-Jones parameters and the
parameters for bonds, angles, dihedrals, and impropers. On top of that,
partial charges have to be applied. Those are usually independent of
the atom types and are determined either for groups of atoms called
residues with some fitting procedure based on quantum mechanical
calculations, or based on some increment system that add or subtract
increments from the partial charge of an atom based on the types of
the neighboring atoms.
Force fields differ in the strategies they employ to determine the
parameters and charge distribution in how generic or specific they are
which in turn has an impact on the accuracy (compare for example
CGenFF to CHARMM and GAFF to Amber). Because of the different
strategies, it is not a good idea to use a mix of parameters from
different force field *families* (like CHARMM, Amber, or GROMOS)
and that extends to the parameters for the solvent, especially
water. The publication describing the parameterization of a force
field will describe which water model to use. Changing the water
model usually leads to overall worse results (even if it may improve
on the water itself).
In addition, one has to consider that *families* of force fields like
CHARMM, Amber, OPLS, or GROMOS have evolved over time and thus provide
different *revisions* of the force field parameters. These often
corresponds to changes in the functional form or the parameterization
strategies. This may also result in changes required for simulation
settings like the preferred cutoff or how Coulomb interactions are
computed (cutoff, smoothed/shifted cutoff, or long-range with Ewald
summation or equivalent). Unless explicitly stated in the publication
describing the force field, the Coulomb interaction cannot be chosen at
will but must match the revision of the force field. That said,
liberties may be taken during the initial equilibration of a system to
speed up the process, but not for production simulations.
----------
.. _Typelabel2:
**(Gissinger)** J. R. Gissinger, I. Nikiforov, Y. Afshar, B. Waters, M. Choi, D. S. Karls, A. Stukowski, W. Im, H. Heinz, A. Kohlmeyer, and E. B. Tadmor, J Phys Chem B, 128, 3282-3297 (2024).

2
doc/src/Howto_apip.rst
View File

@ -135,7 +135,7 @@ Example
# calculate lambda somehow
variable lambda atom ...
set group all apip_lambda v_lambda
set group all apip/lambda v_lambda
fix 4 all atom_weight/apip 100 eam ace lambda/input lambda/zone all

38
doc/src/Howto_bioFF.rst
View File

@ -1,22 +1,16 @@
CHARMM, AMBER, COMPASS, DREIDING, and OPLS force fields
=======================================================
A compact summary of the concepts, definitions, and properties of
force fields with explicit bonded interactions (like the ones discussed
in this HowTo) is given in :ref:`(Gissinger) <Typelabel2>`.
A force field has 2 parts: the formulas that define it and the
coefficients used for a particular system. Here we only discuss
formulas implemented in LAMMPS that correspond to formulas commonly used
in the CHARMM, AMBER, COMPASS, and DREIDING force fields. Setting
coefficients is done either from special sections in an input data file
via the :doc:`read_data <read_data>` command or in the input script with
commands like :doc:`pair_coeff <pair_coeff>` or :doc:`bond_coeff
<bond_coeff>` and so on. See the :doc:`Tools <Tools>` doc page for
additional tools that can use CHARMM, AMBER, or Materials Studio
generated files to assign force field coefficients and convert their
output into LAMMPS input. LAMMPS input scripts can also be generated by
`charmm-gui.org <https://charmm-gui.org/>`_.
Here we only discuss formulas implemented in LAMMPS that correspond to
formulas commonly used in the CHARMM, AMBER, COMPASS, and DREIDING force
fields. Setting coefficients is done either from special sections in an
input data file via the :doc:`read_data <read_data>` command or in the
input script with commands like :doc:`pair_coeff <pair_coeff>` or
:doc:`bond_coeff <bond_coeff>` and so on. See the :doc:`Tools <Tools>`
doc page for additional tools that can use CHARMM, AMBER, or Materials
Studio generated files to assign force field coefficients and convert
their output into LAMMPS input. LAMMPS input scripts can also be
generated by `charmm-gui.org <https://charmm-gui.org/>`_.
CHARMM and AMBER
----------------
@ -203,9 +197,11 @@ rather than individual force constants and geometric parameters that
depend on the particular combinations of atoms involved in the bond,
angle, or torsion terms. DREIDING has an :doc:`explicit hydrogen bond
term <pair_hbond_dreiding>` to describe interactions involving a
hydrogen atom on very electronegative atoms (N, O, F). Unlike CHARMM
or AMBER, the DREIDING force field has not been parameterized for
considering solvents (like water).
hydrogen atom on very electronegative atoms (N, O, F). Unlike CHARMM or
AMBER, the DREIDING force field has not been parameterized for
considering solvents (like water) and has no rules for assigning
(partial) charges. That will seriously limit its accuracy when used for
simulating systems where those matter.
See :ref:`(Mayo) <howto-Mayo>` for a description of the DREIDING force field
@ -272,10 +268,6 @@ compatible with a subset of OPLS interactions.
----------
.. _Typelabel2:
**(Gissinger)** J. R. Gissinger, I. Nikiforov, Y. Afshar, B. Waters, M. Choi, D. S. Karls, A. Stukowski, W. Im, H. Heinz, A. Kohlmeyer, and E. B. Tadmor, J Phys Chem B, 128, 3282-3297 (2024).
.. _howto-MacKerell:
**(MacKerell)** MacKerell, Bashford, Bellott, Dunbrack, Evanseck, Field, Fischer, Gao, Guo, Ha, et al (1998). J Phys Chem, 102, 3586 . https://doi.org/10.1021/jp973084f

4
doc/src/Howto_cmake.rst
View File

@ -285,7 +285,7 @@ when used before the CMake directory, there may be a space between the
can have boolean values (on/off, yes/no, or 1/0 are all valid) or are
strings representing a choice, or a path, or are free format. If the
string would contain whitespace, it must be put in quotes, for example
``-D CMAKE_TUNE_FLAGS="-ftree-vectorize -ffast-math"``.
``-D CMAKE_CXX_FLAGS="-O3 -Wall -ftree-vectorize -ffast-math"``.
CMake variables fall into two categories: 1) common CMake variables that
are used by default for any CMake configuration setup and 2) project
@ -341,8 +341,6 @@ Some common LAMMPS specific variables
- compile some additional executables from the ``tools`` folder (default: ``off``)
* - ``BUILD_DOC``
- include building the HTML format documentation for packaging/installing (default: ``off``)
* - ``CMAKE_TUNE_FLAGS``
- common compiler flags, for optimization or instrumentation (default:)
* - ``LAMMPS_MACHINE``
- when set to ``name`` the LAMMPS executable and library will be called ``lmp_name`` and ``liblammps_name.a``
* - ``FFT``

4
doc/src/Howto_github.rst
View File

@ -498,3 +498,7 @@ systems. Some unit and regression testing is applied as well.
A detailed discussion of the LAMMPS developer GitHub workflow can be
found in the file `doc/github-development-workflow.md
<https://github.com/lammps/lammps/blob/develop/doc/github-development-workflow.md>`_
.. raw:: latex
\clearpage

193
doc/src/Howto_lammps_gui.rst
View File

@ -1,36 +1,25 @@
Using LAMMPS-GUI
================
LAMMPS-GUI is a graphical text editor programmed using the `Qt Framework
<https://www.qt.io/>`_ and customized for editing LAMMPS input files. It
is linked to the :ref:`LAMMPS library <lammps_c_api>` and thus can run
LAMMPS directly using the contents of the editor's text buffer as input.
It *differs* from other known interfaces to LAMMPS in that it can
retrieve and display information from LAMMPS *while it is running*,
display visualizations created with the :doc:`dump image command
<dump_image>`, can launch the online LAMMPS documentation for known
LAMMPS commands and styles, and directly integrates with a collection
of LAMMPS tutorials (:ref:`Gravelle1 <Gravelle1>`).
This document describes **LAMMPS-GUI version 1.6**.
-----
LAMMPS-GUI is a graphical text editor customized for editing LAMMPS
input files that is linked to the :ref:`LAMMPS library <lammps_c_api>`
and thus can run LAMMPS directly using the contents of the editor's text
buffer as input. It can retrieve and display information from LAMMPS
while it is running, display visualizations created with the :doc:`dump
image command <dump_image>`, and is adapted specifically for editing
LAMMPS input files through text completion and reformatting, and linking
to the online LAMMPS documentation for known LAMMPS commands and styles.
.. contents::
.. note::
Pre-compiled, ready-to-use LAMMPS-GUI executables for Linux x86\_64
(Ubuntu 20.04LTS or later and compatible), macOS (version 11 aka Big
Sur or later), and Windows (version 10 or later) :ref:`are available
<lammps_gui_install>` for download. Non-MPI LAMMPS executables (as
``lmp``) for running LAMMPS from the command-line and :doc:`some
LAMMPS tools <Tools>` compiled executables are also included. Also,
the pre-compiled LAMMPS-GUI packages include the WHAM executables
from http://membrane.urmc.rochester.edu/content/wham/ for use with
LAMMPS tutorials documented in this paper (:ref:`Gravelle1
<Gravelle1>`).
The source code for LAMMPS-GUI is included in the LAMMPS source code
distribution and can be found in the ``tools/lammps-gui`` folder. It
can be compiled alongside LAMMPS when :doc:`compiling with CMake
<Build_cmake>`.
----
LAMMPS-GUI tries to provide an experience similar to what people
traditionally would have running LAMMPS using a command-line window and
@ -65,8 +54,8 @@ simple LAMMPS simulations. It is very suitable for tutorials on LAMMPS
since you only need to learn how to use a single program for most tasks
and thus time can be saved and people can focus on learning LAMMPS.
The tutorials at https://lammpstutorials.github.io/ are specifically
updated for use with LAMMPS-GUI and can their tutorial materials can
be downloaded and loaded directly from the GUI.
updated for use with LAMMPS-GUI and their tutorial materials can
be downloaded and edited directly from the GUI.
Another design goal is to keep the barrier low when replacing part of
the functionality of LAMMPS-GUI with external tools. That said, LAMMPS-GUI
@ -79,10 +68,31 @@ has some unique functionality that is not found elsewhere:
- monitoring of simulation progress
- interactive visualization using the :doc:`dump image <dump_image>`
command with the option to copy-paste the resulting settings
- automatic slide show generation from dump image out at runtime
- automatic plotting of thermodynamics data at runtime
- automatic slide show generation from dump image output at runtime
- automatic plotting of thermodynamic data at runtime
- inspection of binary restart files
.. admonition:: Download LAMMPS-GUI for your platform
:class: Hint
Pre-compiled, ready-to-use LAMMPS-GUI executables for Linux x86\_64
(Ubuntu 20.04LTS or later and compatible), macOS (version 11 aka Big
Sur or later), and Windows (version 10 or later) :ref:`are available
<lammps_gui_install>` for download. Non-MPI LAMMPS executables (as
``lmp``) for running LAMMPS from the command-line and :doc:`some
LAMMPS tools <Tools>` compiled executables are also included. Also,
the pre-compiled LAMMPS-GUI packages include the WHAM executables
from http://membrane.urmc.rochester.edu/content/wham/ for use with
LAMMPS tutorials documented in this paper (:ref:`Gravelle1
<Gravelle1>`).
The source code for LAMMPS-GUI is included in the LAMMPS source code
distribution and can be found in the ``tools/lammps-gui`` folder. It
can be compiled alongside LAMMPS when :doc:`compiling with CMake
<Build_cmake>`.
-----
The following text provides a detailed tour of the features and
functionality of LAMMPS-GUI. Suggestions for new features and
reports of bugs are always welcome. You can use the :doc:`the same
@ -93,9 +103,12 @@ channels as for LAMMPS itself <Errors_bugs>` for that purpose.
Installing Pre-compiled LAMMPS-GUI Packages
-------------------------------------------
LAMMPS-GUI is available as pre-compiled binary packages for Linux
x86\_64, macOS 11 and later, and Windows 10 and later. Alternately, it
can be compiled from source.
LAMMPS-GUI is available for download as pre-compiled binary packages for
Linux x86\_64 (Ubuntu 20.04LTS or later and compatible), macOS (version
11 aka Big Sur or later), and Windows (version 10 or later) from the
`LAMMPS release pages on GitHub <https://github.com/lammps/lammps/releases/>`_.
A backup download location is at https://download.lammps.org/static/
Alternately, LAMMPS-GUI can be compiled from source when building LAMMPS.
Windows 10 and later
^^^^^^^^^^^^^^^^^^^^
@ -295,7 +308,10 @@ of the *Output* window showing how many warnings and errors were
detected and how many lines the entire output has. By clicking on the
button on the right with the warning symbol or by using the keyboard
shortcut `Ctrl-N` (`Command-N` on macOS), you can jump to the next
line with a warning or error.
line with a warning or error. If there is a URL pointing to additional
explanations in the online manual, that URL will be highlighted and
double-clicking on it shall open the corresponding manual page in
the web browser. The option is also available from the context menu.
By default, the *Output* window is replaced each time a run is started.
The runs are counted and the run number for the current run is displayed
@ -350,8 +366,13 @@ data or both. The smoothing uses a `Savitzky-Golay convolution filter
window width (left) and order (right) parameters can be set in the boxes
next to the drop down menu. Default settings are 10 and 4 which means
that the smoothing window includes 10 points each to the left and the
right of the current data point and a fourth order polynomial is fit to
the data in the window.
right of the current data point for a total of 21 points and a fourth
order polynomial is fitted to the data in the window.
The "Title:" and "Y:" input boxes allow to edit the text shown as the
plot title and the y-axis label, respectively. The text entered in the
"Title:" box is applied to *all* charts, while the "Y:" text changes
only the y-axis label of the currently *selected* plot.
You can use the mouse to zoom into the graph (hold the left button and
drag to mark an area) or zoom out (right click) and you can reset the
@ -383,6 +404,11 @@ here you get the compounded data set starting with the last change of
output fields or timestep setting, while the export from the log will
contain *all* YAML output but *segmented* into individual runs.
The *Preferences* dialog has a *Charts* tab, where you can configure
multiple chart-related settings, like the default title, colors for the
graphs, default choice of the raw / smooth graph selection, and the
default chart graph size.
Image Slide Show
----------------
@ -462,11 +488,11 @@ correspond to (via their mass) and then colorize them in the image and
set their atom diameters accordingly. If this is not possible, for
instance when using reduced (= 'lj') :doc:`units <units>`, then
LAMMPS-GUI will check the current pair style and if it is a
Lennard-Jones type potential, it will extract the *sigma* parameter
for each atom type and assign atom diameters from those numbers.
For cases where atom diameters are not auto-detected, the *Atom size* field
can be edited and a suitable value set manually. The default value
is inferred from the x-direction lattice spacing.
Lennard-Jones type potential, it will extract the *sigma* parameter for
each atom type and assign atom diameters from those numbers. For cases
where atom diameters are not auto-detected, the *Atom size* field can be
edited and a suitable value set manually. The default value is inferred
from the x-direction lattice spacing.
If elements cannot be detected the default sequence of colors of the
:doc:`dump image <dump_image>` command is assigned to the different atom
@ -481,22 +507,31 @@ types.
|gui-image1| |gui-image2|
The default image size, some default image quality settings, the view
style and some colors can be changed in the *Preferences* dialog
window. From the image viewer window further adjustments can be made:
actual image size, high-quality (SSAO) rendering, anti-aliasing, view
style, display of box or axes, zoom factor. The view of the system can
be rotated horizontally and vertically. It is also possible to only
display the atoms within a group defined in the input script (default is
"all"). The image can also be re-centered on the center of mass of the
selected group. After each change, the image is rendered again and the
display updated. The small palette icon on the top left is colored
while LAMMPS is running to render the new image; it is grayed out when
LAMMPS is finished. When there are many atoms to render and high
quality images with anti-aliasing are requested, re-rendering may take
several seconds. From the *File* menu of the image window, the
current image can be saved to a file (keyboard shortcut `Ctrl-S`) or
copied to the clipboard (keyboard shortcut `Ctrl-C`) for pasting the
image into another application.
style and some colors can be changed in the *Preferences* dialog window.
From the image viewer window further adjustments can be made: actual
image size, high-quality (SSAO) rendering, anti-aliasing, view style,
display of box or axes, zoom factor. The view of the system can be
rotated horizontally and vertically.
It is also possible to display only the atoms within a :doc:`group
defined in the input script <group>` (default is "all"). The available
groups can be selected from the drop down list next to the "Group:"
label. Similarly, if there are :doc:`molecules defined in the input
<molecule>`, it is possible to select one of them (default is "none")
and visualize it (it will be shown at the center of the simulation box).
While a molecule is selected, the group selection is disabled. It can
be restored by selecting the molecule "none".
The image can also be re-centered on the center of mass of the selected
group. After each change, the image is rendered again and the display
updated. The small palette icon on the top left is colored while LAMMPS
is running to render the new image; it is grayed out when LAMMPS is
finished. When there are many atoms to render and high quality images
with anti-aliasing are requested, re-rendering may take several seconds.
From the *File* menu of the image window, the current image can be saved
to a file (keyboard shortcut `Ctrl-S`) or copied to the clipboard
(keyboard shortcut `Ctrl-C`) for pasting the image into another
application.
From the *File* menu it is also possible to copy the current
:doc:`dump image <dump_image>` and :doc:`dump_modify <dump_image>`
@ -726,13 +761,16 @@ Tutorials
The *Tutorials* menu is to support the set of LAMMPS tutorials for
beginners and intermediate LAMMPS users documented in (:ref:`Gravelle1
<Gravelle1>`). From the drop down menu you can select which of the eight
currently available tutorial sessions you want to start and then will be
taken to a 'wizard' dialog where you can choose in which folder you want
to work, whether you want that folder to be cleared, and also whether
you want to download the solutions files (can be large). The dialog
will then start downloading the files requested and load the first input
file for the selected session into LAMMPS-GUI.
<Gravelle1>`). From the drop down menu you can select which of the
eight currently available tutorial sessions you want to begin. This
opens a 'wizard' dialog where you can choose in which folder you want to
work, whether you want that folder to be wiped from *any* files, whether
you want to download the solutions files (which can be large) to a
``solution`` sub-folder, and whether you want the corresponding
tutorial's online version opened in your web browser. The dialog will
then start downloading the files requested (download progress is
reported in the status line) and load the first input file for the
selected session into LAMMPS-GUI.
About
^^^^^
@ -797,18 +835,21 @@ look of LAMMPS-GUI. The settings are grouped and each group is
displayed within a tab.
.. |guiprefs1| image:: JPG/lammps-gui-prefs-general.png
:width: 24%
:width: 19%
.. |guiprefs2| image:: JPG/lammps-gui-prefs-accel.png
:width: 24%
:width: 19%
.. |guiprefs3| image:: JPG/lammps-gui-prefs-image.png
:width: 24%
:width: 19%
.. |guiprefs4| image:: JPG/lammps-gui-prefs-editor.png
:width: 24%
:width: 19%
|guiprefs1| |guiprefs2| |guiprefs3| |guiprefs4|
.. |guiprefs5| image:: JPG/lammps-gui-prefs-charts.png
:width: 19%
|guiprefs1| |guiprefs2| |guiprefs3| |guiprefs4| |guiprefs5|
General Settings:
^^^^^^^^^^^^^^^^^
@ -903,7 +944,7 @@ lists to select the background and box colors.
Editor Settings:
^^^^^^^^^^^^^^^^
This tab allows tweaking settings of the editor window. Specifically
This tab allows tweaking settings of the editor window. Specifically,
the amount of padding to be added to LAMMPS commands, types or type
ranges, IDs (e.g. for fixes), and names (e.g. for groups). The value
set is the minimum width for the text element and it can be chosen in
@ -915,6 +956,16 @@ the completion pop-up window, and whether auto-save mode is enabled.
In auto-save mode the editor buffer is saved before a run or before
exiting LAMMPS-GUI.
Charts Settings:
----------------
This tab allows tweaking settings of the *Charts* window. Specifically,
one can set the default chart title (if the title contains '%f' it will
be replaced with the name of the current input file), one can select
whether by default the raw data, the smoothed data or both will be
plotted, one can set the colors for the two lines, the default smoothing
parameters, and the default size of the chart graph in pixels.
-----------
Keyboard Shortcuts
@ -1013,3 +1064,7 @@ Window), and `Ctrl-Q` (Quit Application) are supported.
.. _Gravelle2:
**(Gravelle2)** Gravelle https://lammpstutorials.github.io/
.. raw:: latex
\clearpage

4
doc/src/Howto_spc.rst
View File

@ -1,5 +1,5 @@
SPC water model
===============
SPC and SPC/E water model
=========================
The SPC water model specifies a 3-site rigid water molecule with
charges and Lennard-Jones parameters assigned to each of the three atoms.

9
doc/src/Howto_thermostat.rst
View File

@ -21,9 +21,14 @@ can be invoked via the *dpd/tstat* pair style:
* :doc:`fix nvt/sllod <fix_nvt_sllod>`
* :doc:`fix temp/berendsen <fix_temp_berendsen>`
* :doc:`fix temp/csvr <fix_temp_csvr>`
* :doc:`fix ffl <fix_ffl>`
* :doc:`fix gjf <fix_gjf>`
* :doc:`fix gld <fix_gld>`
* :doc:`fix gle <fix_gle>`
* :doc:`fix langevin <fix_langevin>`
* :doc:`fix temp/rescale <fix_temp_rescale>`
* :doc:`pair_style dpd/tstat <pair_dpd>`
* :doc:`pair_style dpd/ext/tstat <pair_dpd_ext>`
:doc:`Fix nvt <fix_nh>` only thermostats the translational velocity of
particles. :doc:`Fix nvt/sllod <fix_nvt_sllod>` also does this,
@ -82,10 +87,10 @@ that:
.. note::
Only the nvt fixes perform time integration, meaning they update
Not all thermostat fixes perform time integration, meaning they update
the velocities and positions of particles due to forces and velocities
respectively. The other thermostat fixes only adjust velocities; they
do NOT perform time integration updates. Thus they should be used in
do NOT perform time integration updates. Thus, they should be used in
conjunction with a constant NVE integration fix such as these:
* :doc:`fix nve <fix_nve>`

129
doc/src/Howto_tip4p.rst
View File

@ -1,5 +1,5 @@
TIP4P water model
=================
TIP4P and OPC water models
==========================
The four-point TIP4P rigid water model extends the traditional
:doc:`three-point TIP3P <Howto_tip3p>` model by adding an additional
@ -9,9 +9,11 @@ the oxygen along the bisector of the HOH bond angle. A bond style of
:doc:`harmonic <bond_harmonic>` and an angle style of :doc:`harmonic
<angle_harmonic>` or :doc:`charmm <angle_charmm>` should also be used.
In case of rigid bonds also bond style :doc:`zero <bond_zero>` and angle
style :doc:`zero <angle_zero>` can be used.
style :doc:`zero <angle_zero>` can be used. Very similar to the TIP4P
model is the OPC water model. It can be realized the same way as TIP4P
but has different geometry and force field parameters.
There are two ways to implement TIP4P water in LAMMPS:
There are two ways to implement TIP4P-like water in LAMMPS:
#. Use a specially written pair style that uses the :ref:`TIP3P geometry
<tip3p_molecule>` without the point M. The point M location is then
@ -21,7 +23,10 @@ There are two ways to implement TIP4P water in LAMMPS:
computationally very efficient, but the charge distribution in space
is only correct within the tip4p labeled styles. So all other
computations using charges will "see" the negative charge incorrectly
on the oxygen atom.
located on the oxygen atom unless they are specially written for using
the TIP4P geometry internally as well, e.g. :doc:`compute dipole/tip4p
<compute_dipole>`, :doc:`fix efield/tip4p <fix_efield>`, or
:doc:`kspace_style pppm/tip4p <kspace_style>`.
This can be done with the following pair styles for Coulomb with a cutoff:
@ -68,77 +73,90 @@ TIP4P/2005 model :ref:`(Abascal2) <Abascal2>` and a version of TIP4P
parameters adjusted for use with a long-range Coulombic solver
(e.g. Ewald or PPPM in LAMMPS). Note that for implicit TIP4P models the
OM distance is specified in the :doc:`pair_style <pair_style>` command,
not as part of the pair coefficients.
not as part of the pair coefficients. Also parameters for the OPC
model (:ref:`Izadi <Izadi>`) are provided.
.. list-table::
:header-rows: 1
:widths: 36 19 13 15 17
:widths: 40 12 12 14 11 11
* - Parameter
- TIP4P (original)
- TIP4P/Ice
- TIP4P/2005
- TIP4P (Ewald)
- OPC
* - O mass (amu)
- 15.9994
- 15.9994
- 15.9994
- 15.9994
- 15.9994
* - H mass (amu)
- 1.008
- 1.008
- 1.008
- 1.008
- 1.008
* - O or M charge (:math:`e`)
- -1.040
- -1.1794
- -1.1128
- -1.04844
- -1.3582
* - H charge (:math:`e`)
- 0.520
- 0.5897
- 0.5564
- 0.52422
- 0.6791
* - LJ :math:`\epsilon` of OO (kcal/mole)
- 0.1550
- 0.21084
- 0.1852
- 0.16275
- 0.21280
* - LJ :math:`\sigma` of OO (:math:`\AA`)
- 3.1536
- 3.1668
- 3.1589
- 3.16435
- 3.1660
* - LJ :math:`\epsilon` of HH, MM, OH, OM, HM (kcal/mole)
- 0.0
- 0.0
- 0.0
- 0.0
- 0.0
* - LJ :math:`\sigma` of HH, MM, OH, OM, HM (:math:`\AA`)
- 1.0
- 1.0
- 1.0
- 1.0
- 1.0
* - :math:`r_0` of OH bond (:math:`\AA`)
- 0.9572
- 0.9572
- 0.9572
- 0.9572
- 0.8724
* - :math:`\theta_0` of HOH angle
- 104.52\ :math:`^{\circ}`
- 104.52\ :math:`^{\circ}`
- 104.52\ :math:`^{\circ}`
- 104.52\ :math:`^{\circ}`
- 103.60\ :math:`^{\circ}`
* - OM distance (:math:`\AA`)
- 0.15
- 0.1577
- 0.1546
- 0.1250
- 0.1594
Note that the when using the TIP4P pair style, the neighbor list cutoff
Note that the when using a TIP4P pair style, the neighbor list cutoff
for Coulomb interactions is effectively extended by a distance 2 \* (OM
distance), to account for the offset distance of the fictitious charges
on O atoms in water molecules. Thus it is typically best in an
on O atoms in water molecules. Thus, it is typically best in an
efficiency sense to use a LJ cutoff >= Coulomb cutoff + 2\*(OM
distance), to shrink the size of the neighbor list. This leads to
slightly larger cost for the long-range calculation, so you can test the
@ -192,6 +210,94 @@ file changed):
run 20000
write_data tip4p-implicit.data nocoeff
When constructing an OPC model, we cannot use the ``tip3p.mol`` file due
to the different geometry. Below is a molecule file providing the 3
sites of an implicit OPC geometry for use with TIP4P styles. Note, that
the "Shake" and "Special" sections are missing here. Those will be
auto-generated by LAMMPS when the molecule file is loaded *after* the
simulation box has been created. These sections are required only when
the molecule file is loaded *before*.
.. _opc3p_molecule:
.. code-block::
# Water molecule. 3 point geometry for OPC model
3 atoms
2 bonds
1 angles
Coords
1 0.00000 -0.06037 0.00000
2 0.68558 0.50250 0.00000
3 -0.68558 0.50250 0.00000
Types
1 1 # O
2 2 # H
3 2 # H
Charges
1 -1.3582
2 0.6791
3 0.6791
Bonds
1 1 1 2
2 1 1 3
Angles
1 1 2 1 3
Below is a LAMMPS input file using the implicit method to implement
the OPC model using the molecule file from above and including the
PPPM long-range Coulomb solver.
.. code-block:: LAMMPS
units real
atom_style full
region box block -5 5 -5 5 -5 5
create_box 2 box bond/types 1 angle/types 1 &
extra/bond/per/atom 2 extra/angle/per/atom 1 extra/special/per/atom 2
mass 1 15.9994
mass 2 1.008
pair_style lj/cut/tip4p/long 1 2 1 1 0.1594 12.0
pair_coeff 1 1 0.2128 3.166
pair_coeff 2 2 0.0 1.0
bond_style zero
bond_coeff 1 0.8724
angle_style zero
angle_coeff 1 103.6
kspace_style pppm/tip4p 1.0e-5
molecule water opc3p.mol # this file has the OPC geometry but is without M
create_atoms 0 random 33 34564 NULL mol water 25367 overlap 1.33
fix rigid all shake 0.001 10 10000 b 1 a 1
minimize 0.0 0.0 1000 10000
reset_timestep 0
timestep 1.0
velocity all create 300.0 5463576
fix integrate all nvt temp 300 300 100.0
thermo_style custom step temp press etotal pe
thermo 1000
run 20000
write_data opc-implicit.data nocoeff
Below is the code for a LAMMPS input file using the explicit method and
a TIP4P molecule file. Because of using :doc:`fix rigid/small
<fix_rigid>` no bonds need to be defined and thus no extra storage needs
@ -279,3 +385,8 @@ Phys, 79, 926 (1983).
**(Abascal2)** Abascal, J Chem Phys, 123, 234505 (2005)
https://doi.org/10.1063/1.2121687
.. _Izadi:
**(Izadi)** Izadi, Anandakrishnan, Onufriev, J. Phys. Chem. Lett., 5, 21, 3863 (2014)
https://doi.org/10.1021/jz501780a

13
doc/src/Install_git.rst
View File

@ -12,19 +12,10 @@ several advantages:
LAMMPS. For that, you should first create your own :doc:`fork on
GitHub <Howto_github>`, though.
You must have `git <git_>`_ installed on your system to use the
commands explained below to communicate with the git servers on
GitHub. For people still using subversion (svn), GitHub also
provides `limited support for subversion clients <svn_>`_.
.. note::
As of October 2016, the official home of public LAMMPS development is
on GitHub. The previously advertised LAMMPS git repositories on
git.lammps.org and bitbucket.org are now offline or deprecated.
You must have `git <git_>`_ installed on your system to use the commands
explained below to communicate with the git servers on GitHub.
.. _git: https://git-scm.com
.. _svn: https://help.github.com/en/github/importing-your-projects-to-github/working-with-subversion-on-github
You can follow the LAMMPS development on 4 different git branches:

5
doc/src/Intro_authors.rst
View File

@ -84,8 +84,9 @@ lammps.org". General questions about LAMMPS should be posted in the
\normalsize
Past developers include Paul Crozier and Mark Stevens, both at SNL,
and Ray Shan, now at Materials Design.
Past core developers include Paul Crozier and Mark Stevens, both at SNL,
and Ray Shan while at SNL and later at Materials Design, now at Thermo
Fisher Scientific.
----------

25
doc/src/Intro_portability.rst
View File

@ -28,8 +28,9 @@ Build systems
LAMMPS can be compiled from source code using a (traditional) build
system based on shell scripts, a few shell utilities (grep, sed, cat,
tr) and the GNU make program. This requires running within a Bourne
shell (``/bin/sh``). Alternatively, a build system with different back
ends can be created using CMake. CMake must be at least version 3.16.
shell (``/bin/sh`` or ``/bin/bash``). Alternatively, a build system
with different back ends can be created using CMake. CMake must be
at least version 3.16.
Operating systems
^^^^^^^^^^^^^^^^^
@ -40,11 +41,18 @@ Also, compilation and correct execution on macOS and Windows (using
Microsoft Visual C++) is checked automatically for the largest part of
the source code. Some (optional) features are not compatible with all
operating systems, either through limitations of the corresponding
LAMMPS source code or through incompatibilities of source code or
build system of required external libraries or packages.
LAMMPS source code or through incompatibilities or build system
limitations of required external libraries or packages.
Executables for Windows may be created natively using either Cygwin or
Visual Studio or with a Linux to Windows MinGW cross-compiler.
Executables for Windows may be created either natively using Cygwin,
MinGW, Intel, Clang, or Microsoft Visual C++ compilers, or with a Linux
to Windows MinGW cross-compiler. Native compilation is supported using
Microsoft Visual Studio or a terminal window (using the CMake build
system).
Executables for macOS may be created either using Xcode or GNU compilers
installed with Homebrew. In the latter case, building of LAMMPS through
Homebrew instead of a manual compile is also possible.
Additionally, FreeBSD and Solaris have been tested successfully to
run LAMMPS and produce results consistent with those on Linux.
@ -61,8 +69,9 @@ CPU architectures
^^^^^^^^^^^^^^^^^
The primary CPU architecture for running LAMMPS is 64-bit x86, but also
32-bit x86, and 64-bit ARM and PowerPC (64-bit, Little Endian) are
regularly tested.
64-bit ARM and PowerPC (64-bit, Little Endian) are currently regularly
tested. Further architectures are tested by Linux distributions that
bundle LAMMPS.
Portability compliance
^^^^^^^^^^^^^^^^^^^^^^

BIN
doc/src/JPG/lammps-gui-chart.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 106 KiB

After

Width:  |  Height:  |  Size: 117 KiB

BIN
doc/src/JPG/lammps-gui-prefs-accel.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 32 KiB

After

Width:  |  Height:  |  Size: 31 KiB

BIN
doc/src/JPG/lammps-gui-prefs-charts.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 49 KiB

BIN
doc/src/JPG/lammps-gui-prefs-editor.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 39 KiB

After

Width:  |  Height:  |  Size: 39 KiB

BIN
doc/src/JPG/lammps-gui-prefs-general.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 59 KiB

After

Width:  |  Height:  |  Size: 57 KiB

BIN
doc/src/JPG/lammps-gui-prefs-image.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 44 KiB

After

Width:  |  Height:  |  Size: 44 KiB

BIN
doc/src/JPG/lammps-gui-screen.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 361 KiB

BIN
doc/src/JPG/lammps-releases.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 68 KiB

After

Width:  |  Height:  |  Size: 70 KiB

4
doc/src/Modify_pair.rst
View File

@ -46,6 +46,8 @@ Here is a brief list of some the class methods in the Pair class that
+---------------------------------+------------------------------------------------------------------------+
| compute_inner/middle/outer | versions of compute used by rRESPA |
+---------------------------------+------------------------------------------------------------------------+
| compute_atomic_energy | energy of one atom, equivalent to per-atom energy |
+---------------------------------+------------------------------------------------------------------------+
| memory_usage | return estimated amount of memory used by the pair style |
+---------------------------------+------------------------------------------------------------------------+
| modify_params | process arguments to pair_modify command |
@ -122,3 +124,5 @@ setting.
+---------------------------------+-------------------------------------------------------------+---------+
| spinflag | 1 if compatible with spin kspace_style | 0 |
+---------------------------------+-------------------------------------------------------------+---------+
| atomic_energy_enable | 1 if compute_atomic_energy() routine exists | 0 |
+---------------------------------+-------------------------------------------------------------+---------+

BIN
doc/src/PDF/colvars-refman-lammps.pdf
View File

Binary file not shown.

2
doc/src/Python_launch.rst
View File

@ -1,7 +1,7 @@
Running LAMMPS and Python in serial
-----------------------------------
To run a LAMMPS in serial, type these lines into Python
To run a LAMMPS input in serial, type these lines into Python
interactively from the ``bench`` directory:
.. code-block:: python

33
doc/src/Speed_compare.rst
View File

@ -75,15 +75,34 @@ section below for examples where this has been done.
**Differences between the GPU and KOKKOS packages:**
* The GPU package accelerates only pair force, neighbor list, and (parts
of) PPPM calculations. The KOKKOS package attempts to run most of the
of) PPPM calculations (and runs the remaining force computations on
the CPU concurrently). The KOKKOS package attempts to run most of the
calculation on the GPU, but can transparently support non-accelerated
code (with a performance penalty due to having data transfers between
host and GPU).
* The list of which styles are accelerated by the GPU or KOKKOS package
differs with some overlap.
* The GPU package requires neighbor lists to be built on the CPU when using
hybrid pair styles, exclusion lists, or a triclinic simulation box.
* The GPU package can be compiled for CUDA, HIP, or OpenCL and thus supports
NVIDIA, AMD, and Intel GPUs well. On NVIDIA hardware, using CUDA is
typically resulting in equal or better performance over OpenCL.
* OpenCL in the GPU package does theoretically also support Intel CPUs or
Intel Xeon Phi, but the native support for those in KOKKOS (or INTEL)
is superior.
* The GPU package benefits from running multiple MPI processes (2-8) per
GPU to parallelize the non-GPU accelerated styles. The KOKKOS package
usually not, especially when all parts of the calculation have KOKKOS
support.
* The GPU package can be compiled for CUDA, HIP, or OpenCL and thus
supports NVIDIA, AMD, and Intel GPUs well. On NVIDIA or AMD hardware,
using native CUDA or HIP compilation, respectively, with either GPU or
KOKKOS results in equal or better performance over OpenCL.
* OpenCL in the GPU package supports NVIDIA, AMD, and Intel GPUs at the
*same time* and with the *same executable*. KOKKOS currently does not
support OpenCL.
* The GPU package supports single precision floating point, mixed
precision floating point, and double precision floating point math on
the GPU. This must be chosen at compile time. KOKKOS currently only
supports double precision floating point math. Using single or mixed
precision (recommended) results in significantly improved performance
on consumer GPUs for some loss in accuracy (which is rather small with
mixed precision). Single and mixed precision support for KOKKOS is in
development (no ETA yet).
* Some pair styles (for example :doc:`snap <pair_snap>`, :doc:`mliap
<pair_mliap>` or :doc:`reaxff <pair_reaxff>` in the KOKKOS package have
seen extensive optimizations and specializations for GPUs and CPUs.

235
doc/src/Speed_measure.rst
View File

@ -1,16 +1,218 @@
Measuring performance
=====================
Before trying to make your simulation run faster, you should
understand how it currently performs and where the bottlenecks are.
Factors that influence performance
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The best way to do this is run the your system (actual number of
atoms) for a modest number of timesteps (say 100 steps) on several
different processor counts, including a single processor if possible.
Do this for an equilibrium version of your system, so that the
100-step timings are representative of a much longer run. There is
typically no need to run for 1000s of timesteps to get accurate
timings; you can simply extrapolate from short runs.
Before trying to make your simulation run faster, you should understand
how it currently performs and where the bottlenecks are. We generally
distinguish between serial performance (how fast can a single process do
the calculations?) and parallel efficiency (how much faster does a
calculation get by using more processes?). There are many factors
affecting either and below are some lists discussing some commonly
known but also some less known factors.
Factors affecting serial performance (in no specific order):
* CPU hardware: clock rate, cache sizes, CPU architecture (instructions
per clock, vectorization support, fused multiply-add support and more)
* RAM speed and number of channels that the CPU can use to access RAM
* Cooling: CPUs can change the CPU clock based on thermal load, thus the
degree of cooling can affect the speed of a CPU. Sometimes even the
temperature of neighboring compute nodes in a cluster can make a
difference.
* Compiler optimization: most of LAMMPS is written to be easy to modify
and thus compiler optimization can speed up calculations. However, too
aggressive compiler optimization can produce incorrect results or
crashes (during compilation or at runtime).
* Source code improvements: styles in the OPT, OPENMP, and INTEL package
can be faster than their base implementation due to improved data
access patterns, cache efficiency, or vectorization. Compiler optimization
is required to take full advantage of these.
* Number and kind of fixes, computes, or variables used during a simulation,
especially if they result in collective communication operations
* Pair style cutoffs and system density: calculations get slower the more
neighbors are in the neighbor list and thus for which interactions need
to be computed. Force fields with pair styles that compute interactions
between triples or quadruples of atoms or that use embedding energies or
charge equilibration will need to walk the neighbor lists multiple times.
* Neighbor list settings: tradeoff between neighbor list skin (larger
skin = more neighbors, more distances to compute before applying the
cutoff) and frequency of neighbor list builds (larger skin = fewer
neighbor list builds).
* Proximity of per-atom data in physical memory that for atoms that are
close in space improves cache efficiency (thus LAMMPS will by default
sort atoms in local storage accordingly)
* Using r-RESPA multi-timestepping or a SHAKE or RATTLE fix to constrain
bonds with higher-frequency vibrations may allow a larger (outer) timestep
and thus fewer force evaluations (usually the most time consuming step in
MD) for the same simulated time (with some tradeoff in accuracy).
Factors affecting parallel efficiency (in no specific order):
* Bandwidth and latency of communication between processes. This can vary a
lot between processes on the same CPU or physical node and processes
on different physical nodes and there vary between different
communication technologies (like Ethernet or InfiniBand or other
high-speed interconnects)
* Frequency and complexity of communication patterns required
* Number of "work units" (usually correlated with the number of atoms
and choice of force field) per MPI-process required for one time step
(if this number becomes too small, the cost of communication becomes
dominant).
* Choice of parallelization method (MPI-only, OpenMP-only, MPI+OpenMP,
MPI+GPU, MPI+GPU+OpenMP)
* Algorithmic complexity of the chosen force field (pair-wise vs. many-body
potential, Ewald vs. PPPM vs. (compensated or smoothed) cutoff-Coulomb)
* Communication cutoff: a larger cutoff results in more ghost atoms and
thus more data that needs to be communicated
* Frequency of neighbor list builds: during a neighbor list build the
domain decomposition is updated and the list of ghost atoms rebuilt
which requires multiple global communication steps
* FFT-grid settings and number of MPI processes for kspace style PPPM:
PPPM uses parallel 3d FFTs which will drop much faster in parallel
efficiency with respect to the number of MPI processes than other
parts of the force computation. Thus using MPI+OpenMP parallelization
or :doc:`run style verlet/split <run_style>` can improve parallel
efficiency by limiting the number of MPI processes used for the FFTs.
* Load (im-)balance: LAMMPS' domain decomposition assumes that atoms are
evenly distributed across the entire simulation box. If there are
areas of vacuum, this may lead to different amounts of work for
different MPI processes. Using the :doc:`processors command
<processors>` to change the spatial decomposition, or MPI+OpenMP
parallelization instead of only-MPI to have larger sub-domains, or the
(fix) balance command (without or with switching to communication style
tiled) to change the sub-domain volumes are all methods that
can help to avoid load imbalances.
Examples comparing serial performance
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Before looking at your own input deck(s), you should get some reference
data from a known input so that you know what kind of performance you
should expect from your input. For the following we therefore use the
``in.rhodo.scaled`` input file and ``data.rhodo`` data file from the
``bench`` folder. This is a system of 32000 atoms using the CHARMM force
field and long-range electrostatics running for 100 MD steps. The
performance data is printed at the end of a run and only measures the
performance during propagation and excludes the setup phase.
Running with a single MPI process on an AMD Ryzen Threadripper PRO
9985WX CPU (64 cores, 128 threads, base clock: 3.2GHz, max. clock
5.4GHz, L1/L2/L3 cache 5MB/64MB/256MB, 8 DDR5-6400 memory channels) one
gets the following performance report:
.. code-block::
Performance: 1.232 ns/day, 19.476 hours/ns, 7.131 timesteps/s, 228.197 katom-step/s
99.2% CPU use with 1 MPI tasks x 1 OpenMP threads
The %CPU value should be at 100% or very close. Lower values would
be an indication that there are *other* processes also using the same
CPU core and thus invalidating the performance data. The katom-step/s
value is best suited for comparisons, since it is fairly independent
from the system size. The `in.rhodo.scaled` input can be easily made
larger through replication in the three dimensions by settings variables
"x", "y", "z" to values other than 1 from the command line with the
"-var" flag. Example:
- 32000 atoms: 228.8 katom-step/s
- 64000 atoms: 231.6 katom-step/s
- 128000 atoms: 231.1 katom-step/s
- 256000 atoms: 226.4 katom-step/s
- 864000 atoms: 229.6 katom-step/s
Comparing to an AMD Ryzen 7 7840HS CPU (8 cores, 16 threads, base clock
3.8GHz, max. clock 5.1GHz, L1/L2/L3 cache 512kB/8MB/16MB, 2 DDR5-5600
memory channels), we get similar single core performance (~220
katom-step/s vs. ~230 katom-step/s) due to the similar clock and
architecture:
- 32000 atoms: 219.8 katom-step/s
- 64000 atoms: 222.5 katom-step/s
- 128000 atoms: 216.8 katom-step/s
- 256000 atoms: 221.0 katom-step/s
- 864000 atoms: 221.1 katom-step/s
Switching to an older Intel Xeon E5-2650 v4 CPU (12 cores, 12 threads,
base clock 2.2GHz, max. clock 2.9GHz, L1/L2/L3 cache (64kB/256kB/30MB, 4
DDR4-2400 memory channels) leads to a lower performance of approximately
109 katom-step/s due to differences in architecture and clock. In all
cases, when looking at multiple runs, the katom-step/s property
fluctuates by approximately 1% around the average.
From here on we are looking at the performance for the 256000 atom system only
and change several settings incrementally:
#. No compiler optimization GCC (-Og -g): 183.8 katom-step/s
#. Moderate optimization with debug info GCC (-O2 -g): 231.1 katom-step/s
#. Full compiler optimization GCC (-DNDEBUG -O3): 236.0 katom-step/s
#. Aggressive compiler optimization GCC (-O3 -ffast-math -march=native): 239.9 katom-step/s
#. Source code optimization in OPENMP package (1 thread): 266.7 katom-step/s
#. Use *fix nvt* instead of *fix npt* (compute virial only every 50 steps): 272.9 katom-step/s
#. Increase pair style cutoff by 2 :math:`\AA`: 181.2 katom-step/s
#. Use tight PPPM convergence (1.0e-6 instead of 1.0e-4): 161.9 katom-step/s
#. Use Ewald summation instead of PPPM (at 1.0e-4 convergence): 19.9 katom-step/s
The numbers show that gains from aggressive compiler optimizations are
rather small in LAMMPS, the data access optimizations in the OPENMP (and
OPT) packages are more prominent. On the other side, using more
accurate force field settings causes, not unexpectedly, a significant
slowdown (to about half the speed). Finally, using regular Ewald
summation causes a massive slowdown due to the bad algorithmic scaling
with system size.
Examples comparing parallel performance
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The parallel performance usually goes on top of the serial performance.
Using twice as many processors should increase the performance metric
by up to a factor of two. With the number of processors *N* and the
serial performance :math:`p_1` and the performance for *N* processors
:math:`p_N` we can define a *parallel efficiency* in percent as follows:
.. math::
P_{eff} = \frac{p_N}{p_1 \cdot N} \cdot 100\%
For the AMD Ryzen Threadripper PRO 9985WX CPU and the serial
simulation settings of point 6. from above, we get the following
parallel efficiency data for the 256000 atom system:
- 1 MPI task: 273.6 katom-step/s, :math:`P_{eff} = 100\%`
- 2 MPI tasks: 530.6 katom-step/s, :math:`P_{eff} = 97\%`
- 4 MPI tasks: 1.021 Matom-step/s, :math:`P_{eff} = 93\%`
- 8 MPI tasks: 1.837 Matom-step/s, :math:`P_{eff} = 84\%`
- 16 MPI tasks: 3.574 Matom-step/s, :math:`P_{eff} = 82\%`
- 32 MPI tasks: 6.479 Matom-step/s, :math:`P_{eff} = 74\%`
- 64 MPI tasks: 9.032 Matom-step/s, :math:`P_{eff} = 52\%`
- 128 MPI tasks: 12.03 Matom-step/s, :math:`P_{eff} = 34\%`
The 128 MPI tasks run uses CPU cores from hyper-threading.
For a small system with only 32000 atoms the parallel efficiency
drops off earlier when the number of work units is too small relative
to the communication overhead:
- 1 MPI task: 270.8 katom-step/s, :math:`P_{eff} = 100\%`
- 2 MPI tasks: 529.3 katom-step/s, :math:`P_{eff} = 98\%`
- 4 MPI tasks: 989.8 katom-step/s, :math:`P_{eff} = 91\%`
- 8 MPI tasks: 1.832 Matom-step/s, :math:`P_{eff} = 85\%`
- 16 MPI tasks: 3.463 Matom-step/s, :math:`P_{eff} = 80\%`
- 32 MPI tasks: 5.970 Matom-step/s, :math:`P_{eff} = 69\%`
- 64 MPI tasks: 7.477 Matom-step/s, :math:`P_{eff} = 42\%`
- 128 MPI tasks: 8.069 Matom-step/s, :math:`P_{eff} = 23\%`
Measuring performance of your input deck
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The best way to do this is run the your system (actual number of atoms)
for a modest number of timesteps (say 100 steps) on several different
processor counts, including a single processor if possible. Do this for
an equilibrium version of your system, so that the 100-step timings are
representative of a much longer run. There is typically no need to run
for 1000s of timesteps to get accurate timings; you can simply
extrapolate from short runs.
For the set of runs, look at the timing data printed to the screen and
log file at the end of each LAMMPS run. The
@ -28,12 +230,15 @@ breakdown and relative percentages. For example, trying different
options for speeding up the long-range solvers will have little impact
if they only consume 10% of the run time. If the pairwise time is
dominating, you may want to look at GPU or OMP versions of the pair
style, as discussed below. Comparing how the percentages change as
you increase the processor count gives you a sense of how different
operations within the timestep are scaling. Note that if you are
running with a Kspace solver, there is additional output on the
breakdown of the Kspace time. For PPPM, this includes the fraction
spent on FFTs, which can be communication intensive.
style, as discussed below. Comparing how the percentages change as you
increase the processor count gives you a sense of how different
operations within the timestep are scaling. If you are using PPPM as
Kspace solver, you can turn on an additional output with
:doc:`kspace_modify fftbench yes <kspace_modify>` which measures the
time spent during PPPM on the 3d FFTs, which can be communication
intensive for larger processor counts. This provides an indication
whether it is worth trying out alternatives to the default FFT settings
for additional performance.
Another important detail in the timing info are the histograms of
atoms counts and neighbor counts. If these vary widely across

26
doc/src/Tools.rst
View File

@ -475,9 +475,13 @@ beginners to start with LAMMPS, it is also the expectation that
LAMMPS-GUI users will eventually transition to workflows that most
experienced LAMMPS users employ.
All features have been extensively exposed to keyboard shortcuts, so
that there is also appeal for experienced LAMMPS users for prototyping
and testing simulation setups.
.. image:: JPG/lammps-gui-screen.png
:align: center
:scale: 50%
Features have been extensively exposed to keyboard shortcuts, so that
there is also appeal for experienced LAMMPS users for prototyping and
testing simulation setups.
Features
^^^^^^^^
@ -502,7 +506,7 @@ Here are a few highlights of LAMMPS-GUI
- Visualization of current state in Image Viewer (via calling :doc:`write_dump image <dump_image>`)
- Capture of images created via :doc:`dump image <dump_image>` in Slide show window
- Dialog to set variables, similar to the LAMMPS command-line flag '-v' / '-var'
- Support for GPU, INTEL, KOKKOS/OpenMP, OPENMAP, and OPT and accelerator packages
- Support for GPU, INTEL, KOKKOS/OpenMP, OPENMP, and OPT accelerator packages
Parallelization
^^^^^^^^^^^^^^^
@ -523,8 +527,8 @@ with CMake is required.
The LAMMPS-GUI has been successfully compiled and tested on:
- Ubuntu Linux 20.04LTS x86_64 using GCC 9, Qt version 5.12
- Fedora Linux 40 x86\_64 using GCC 14 and Clang 17, Qt version 5.15LTS
- Fedora Linux 40 x86\_64 using GCC 14, Qt version 6.7
- Fedora Linux 41 x86\_64 using GCC 14 and Clang 17, Qt version 5.15LTS
- Fedora Linux 41 x86\_64 using GCC 14, Qt version 6.8
- Apple macOS 12 (Monterey) and macOS 13 (Ventura) with Xcode on arm64 and x86\_64, Qt version 5.15LTS
- Windows 10 and 11 x86_64 with Visual Studio 2022 and Visual C++ 14.36, Qt version 5.15LTS
- Windows 10 and 11 x86_64 with Visual Studio 2022 and Visual C++ 14.40, Qt version 6.7
@ -1250,10 +1254,10 @@ tabulate tool
.. versionadded:: 22Dec2022
The ``tabulate`` folder contains Python scripts scripts to generate tabulated
potential files for LAMMPS. The bulk of the code is in the ``tabulate`` module
in the ``tabulate.py`` file. Some example files demonstrating its use are
included. See the README file for more information.
The ``tabulate`` folder contains Python scripts scripts to generate and
visualize tabulated potential files for LAMMPS. The bulk of the code is in the
``tabulate`` module in the ``tabulate.py`` file. Some example files
demonstrating its use are included. See the README file for more information.
----------
@ -1276,7 +1280,7 @@ Those scripts were written by Steve Plimpton sjplimp at gmail.com
valgrind tool
-------------
The ``valgrind`` folder contains additional suppressions fur LAMMPS when
The ``valgrind`` folder contains additional suppressions for LAMMPS when
using `valgrind's <https://valgrind.org/>`_ ` `memcheck tool
<https://valgrind.org/info/tools.html#memcheck>`_ to search for memory
access violation and memory leaks. These suppressions are automatically

3
doc/src/bond_bpm_rotational.rst
View File

@ -215,6 +215,9 @@ for an overview of LAMMPS output options.
The vector or array will be floating point values that correspond to
the specified attribute.
Any settings with the *store/local* option are not saved to a restart
file and must be redefined.
The single() function of this bond style returns 0.0 for the energy
of a bonded interaction, since energy is not conserved in these
dissipative potentials. It also returns only the normal component of

3
doc/src/bond_bpm_spring.rst
View File

@ -215,6 +215,9 @@ for an overview of LAMMPS output options.
The vector or array will be floating point values that correspond to
the specified attribute.
Any settings with the *store/local* option are not saved to a restart
file and must be redefined.
The potential energy and the single() function of this bond style return
:math:`k (r - r_0)^2 / 2` as a proxy of the energy of a bonded interaction,
ignoring any volumetric/smoothing factors or dissipative forces. The single()

30
doc/src/compute_bond_local.rst
View File

@ -64,20 +64,32 @@ All these properties are computed for the pair of atoms in a bond,
whether the two atoms represent a simple diatomic molecule, or are part
of some larger molecule.
The value *dist* is the current length of the bond.
The values *dx*, *dy*, and *dz* are the xyz components of the
*distance* between the pair of atoms. This value is always the
distance from the atom of lower to the one with the higher id.
.. versionchanged:: TBD
The sign of *dx*, *dy*, *dz* is no longer determined by the atom IDs
of the bonded atoms but by their order in the bond list to be
consistent with *fx*, *fy*, and *fz*.
The value *dist* is the current length of the bond. The values *dx*,
*dy*, and *dz* are the :math:`(x,y,z)` components of the distance vector
:math:`\vec{x_i} - \vec{x_j}` between the atoms in the bond. The order
of the atoms is determined by the bond list and the respective atom-IDs
can be output with :doc:`compute property/local
<compute_property_local>`.
The value *engpot* is the potential energy for the bond,
based on the current separation of the pair of atoms in the bond.
The value *force* is the magnitude of the force acting between the
pair of atoms in the bond.
The value *force* is the magnitude of the force acting between the pair
of atoms in the bond, which is positive for a repulsive force and
negative for an attractive force.
The values *fx*, *fy*, and *fz* are the xyz components of
*force* between the pair of atoms in the bond. For bond styles that apply
non-central forces, such as :doc:`bond_style bpm/rotational
The values *fx*, *fy*, and *fz* are the :math:`(x,y,z)` components of
the force on the first atom *i* in the bond due to the second atom *j*.
Mathematically, they are obtained by multiplying the value of *force*
from above with a unit vector created from the *dx*, *dy*, and *dz*
components of the distance vector also described above. For bond styles
that apply non-central forces, such as :doc:`bond_style bpm/rotational
<bond_bpm_rotational>`, these values only include the :math:`(x,y,z)`
components of the normal force component.

30
doc/src/compute_pair_local.rst
View File

@ -56,19 +56,33 @@ force cutoff distance for that interaction, as defined by the
:doc:`pair_style <pair_style>` and :doc:`pair_coeff <pair_coeff>`
commands.
The value *dist* is the distance between the pair of atoms.
The values *dx*, *dy*, and *dz* are the :math:`(x,y,z)` components of the
*distance* between the pair of atoms. This value is always the
distance from the atom of higher to the one with the lower atom ID.
.. versionchanged:: TBD
The sign of *dx*, *dy*, *dz* is no longer determined by the value of
their atom-IDs but by their order in the neighbor list to be
consistent with *fx*, *fy*, and *fz*.
The value *dist* is the distance between the pair of atoms. The values
*dx*, *dy*, and *dz* are the :math:`(x,y,z)` components of the distance
vector :math:`\vec{x_i} - \vec{x_j}` between the pair of atoms. The
order of the atoms is determined by the neighbor list and the respective
atom-IDs can be output with :doc:`compute property/local
<compute_property_local>`.
The value *eng* is the interaction energy for the pair of atoms.
The value *force* is the force acting between the pair of atoms, which
is positive for a repulsive force and negative for an attractive
force. The values *fx*, *fy*, and *fz* are the :math:`(x,y,z)` components of
*force* on atom I. For pair styles that apply non-central forces,
such as :doc:`granular pair styles <pair_gran>`, these values only include
the :math:`(x,y,z)` components of the normal force component.
force.
The values *fx*, *fy*, and *fz* are the :math:`(x,y,z)` components of
the force vector on the first atom *i* of a pair in the neighbor list
due to the second atom *j*. Mathematically, they are obtained by
multiplying the value of *force* from above with a unit vector created
from the *dx*, *dy*, and *dz* components of the distance vector also
described above. For pair styles that apply non-central forces, such as
:doc:`granular pair styles <pair_gran>`, these values only include the
:math:`(x,y,z)` components of the normal force component.
A pair style may define additional pairwise quantities which can be
accessed as *p1* to *pN*, where :math:`N` is defined by the pair style.

2
doc/src/compute_rheo_property_atom.rst
View File

@ -88,7 +88,7 @@ The *phase* property indicates whether the particle is in a fluid state,
a value of 0, or a solid state, a value of 1.
The *surface* property indicates the surface designation produced by
the *interface/reconstruct* option of :doc:`fix rheo <fix_rheo>`. Bulk
the *surface/detection* option of :doc:`fix rheo <fix_rheo>`. Bulk
particles have a value of 0, surface particles have a value of 1, and
splash particles have a value of 2. The *surface/r* property is the
distance from the surface, up to the kernel cutoff length. Surface particles

13
doc/src/create_atoms.rst
View File

@ -28,7 +28,7 @@ Syntax
region-ID = create atoms within this region, use NULL for entire simulation box
* zero or more keyword/value pairs may be appended
* keyword = *mol* or *basis* or *ratio* or *subset* or *remap* or *var* or *set* or *radscale* or *meshmode* or *rotate* or *overlap* or *maxtry* or *units*
* keyword = *mol* or *basis* or *ratio* or *subset* or *group* or *remap* or *var* or *set* or *radscale* or *meshmode* or *rotate* or *overlap* or *maxtry* or *units*
.. parsed-literal::
@ -44,6 +44,7 @@ Syntax
*subset* values = Nsubset seed
Nsubset = # of lattice sites to populate randomly
seed = random # seed (positive integer)
*group* value = group name
*remap* value = *yes* or *no*
*var* value = name = variable name to evaluate for test of atom creation
*set* values = dim name
@ -83,7 +84,7 @@ Examples
create_atoms 3 region regsphere basis 2 3
create_atoms 3 region regsphere basis 2 3 ratio 0.5 74637
create_atoms 3 single 0 0 5
create_atoms 3 single 0 0 5 group newatom
create_atoms 1 box var v set x xpos set y ypos
create_atoms 2 random 50 12345 NULL overlap 2.0 maxtry 50
create_atoms 1 mesh open_box.stl meshmode qrand 0.1 units box
@ -395,6 +396,14 @@ correct number of particles are inserted, in a perfectly random
fashion. Which lattice sites are selected will change with the number
of processors used.
.. versionadded:: TBD
The *group* keyword adds the newly created atoms to the named
:doc:`group <group>`. If the group does not yet exist it will be
created. There can be only one such group, thus if the *group* keyword
is used multiple times, only the last one will be used. All created
atoms are always added to the group "all".
The *remap* keyword only applies to the *single* style. If it is set
to *yes*, then if the specified position is outside the simulation
box, it will mapped back into the box, assuming the relevant

4
doc/src/fix.rst
View File

@ -209,6 +209,7 @@ accelerated styles exist.
* :doc:`ave/grid <fix_ave_grid>` - compute per-grid time-averaged quantities
* :doc:`ave/histo <fix_ave_histo>` - compute/output time-averaged histograms
* :doc:`ave/histo/weight <fix_ave_histo>` - weighted version of fix ave/histo
* :doc:`ave/moments <fix_ave_moments>` - compute moments of scalar quantities
* :doc:`ave/time <fix_ave_time>` - compute/output global time-averaged quantities
* :doc:`aveforce <fix_aveforce>` - add an averaged force to each atom
* :doc:`balance <fix_balance>` - perform dynamic load-balancing
@ -257,6 +258,7 @@ accelerated styles exist.
* :doc:`flow/gauss <fix_flow_gauss>` - Gaussian dynamics for constant mass flux
* :doc:`freeze <fix_freeze>` - freeze atoms in a granular simulation
* :doc:`gcmc <fix_gcmc>` - grand canonical insertions/deletions
* :doc:`gjf <fix_gjf>` - statistically correct Langevin temperature control using the GJ methods
* :doc:`gld <fix_gld>` - generalized Langevin dynamics integrator
* :doc:`gle <fix_gle>` - generalized Langevin equation thermostat
* :doc:`gravity <fix_gravity>` - add gravity to atoms in a granular simulation
@ -293,6 +295,7 @@ accelerated styles exist.
* :doc:`mvv/tdpd <fix_mvv_dpd>` - constant temperature DPD using the modified velocity-Verlet algorithm
* :doc:`neb <fix_neb>` - nudged elastic band (NEB) spring forces
* :doc:`neb/spin <fix_neb_spin>` - nudged elastic band (NEB) spring forces for spins
* :doc:`neighbor/swap <fix_neighbor_swap>` - kinetic Monte Carlo (kMC) atom swapping
* :doc:`nonaffine/displacement <fix_nonaffine_displacement>` - calculate nonaffine displacement of atoms
* :doc:`nph <fix_nh>` - constant NPH time integration via Nose/Hoover
* :doc:`nph/asphere <fix_nph_asphere>` - NPH for aspherical particles
@ -398,6 +401,7 @@ accelerated styles exist.
* :doc:`rigid/small <fix_rigid>` - constrain many small clusters of atoms to move as a rigid body with NVE integration
* :doc:`rx <fix_rx>` - solve reaction kinetic ODEs for a defined reaction set
* :doc:`saed/vtk <fix_saed_vtk>` - time-average the intensities from :doc:`compute saed <compute_saed>`
* :doc:`set <fix_set>` - reset an atom property via an atom-style variable every N steps
* :doc:`setforce <fix_setforce>` - set the force on each atom
* :doc:`setforce/spin <fix_setforce>` - set magnetic precession vectors on each atom
* :doc:`sgcmc <fix_sgcmc>` - fix for hybrid semi-grand canonical MD/MC simulations

51
doc/src/fix_adapt.rst
View File

@ -14,7 +14,7 @@ Syntax
* adapt = style name of this fix command
* N = adapt simulation settings every this many timesteps
* one or more attribute/arg pairs may be appended
* attribute = *pair* or *bond* or *angle* or *improper* or *kspace* or *atom*
* attribute = *pair* or *bond* or *angle* or *dihedral* or *improper* or *kspace* or *atom*
.. parsed-literal::
@ -33,6 +33,11 @@ Syntax
aparam = parameter to adapt over time
I = type angle to set parameter for (integer or type label)
v_name = variable with name that calculates value of aparam
*dihedral* args = dstyle dparam I v_name
dstyle = dihedral style name (e.g., quadratic)
dparam = parameter to adapt over time
I = type dihedral to set parameter for (integer or type label)
v_name = variable with name that calculates value of iparam
*improper* args = istyle iparam I v_name
istyle = improper style name (e.g., cvff)
iparam = parameter to adapt over time
@ -209,6 +214,8 @@ formulas for the meaning of these parameters:
+------------------------------------------------------------------------------+--------------------------------------------------+-------------+
| :doc:`lj/mdf <pair_mdf>` | epsilon,sigma | type pairs |
+------------------------------------------------------------------------------+--------------------------------------------------+-------------+
| :doc:`lj/pirani <pair_lj_pirani>` | alpha, beta, gamma, rm, epsilon | type pairs |
+------------------------------------------------------------------------------+--------------------------------------------------+-------------+
| :doc:`lj/sf/dipole/sf <pair_dipole>` | epsilon,sigma,scale | type pairs |
+------------------------------------------------------------------------------+--------------------------------------------------+-------------+
| :doc:`lubricate <pair_lubricate>` | mu | global |
@ -433,6 +440,48 @@ this fix uses to reset theta0 needs to generate values in radians.
----------
.. versionadded:: TBD
The *dihedral* keyword uses the specified variable to change the value of
a dihedral coefficient over time, very similar to how the *angle* keyword
operates. The only difference is that now a dihedral coefficient for a
given dihedral type is adapted.
A wild-card asterisk can be used in place of or in conjunction with the
dihedral type argument to set the coefficients for multiple dihedral types.
This takes the form "\*" or "\*n" or "m\*" or "m\*n". If :math:`N` is
the number of dihedral types, then an asterisk with no numeric values means
all types from 1 to :math:`N`. A leading asterisk means all types from
1 to n (inclusive). A trailing asterisk means all types from m to
:math:`N` (inclusive). A middle asterisk means all types from m to n
(inclusive).
If :doc:`dihedral_style hybrid <dihedral_hybrid>` is used, *dstyle* should be a
sub-style name. The dihedral styles that currently work with fix adapt are:
+------------------------------------------------------------------------+-------------------------+----------------+
| :doc:`charmm <dihedral_charmm>` | k,n,d | type dihedrals |
+------------------------------------------------------------------------+-------------------------+----------------+
| :doc:`charmmfsw <dihedral_charmm>` | k,n,d | type dihedrals |
+------------------------------------------------------------------------+-------------------------+----------------+
| :doc:`class2 <dihedral_class2>` | k1,k2,k3,phi1,phi2,phi3 | type dihedrals |
+------------------------------------------------------------------------+-------------------------+----------------+
| :doc:`cosine/squared/restricted <dihedral_cosine_squared_restricted>` | k,phi0 | type dihedrals |
+------------------------------------------------------------------------+-------------------------+----------------+
| :doc:`helix <dihedral_helix>` | a,b,c | type dihedrals |
+------------------------------------------------------------------------+-------------------------+----------------+
| :doc:`multi/harmonic <dihedral_multi_harmonic>` | a1,a2,a3,a4,a5 | type dihedrals |
+------------------------------------------------------------------------+-------------------------+----------------+
| :doc:`opls <dihedral_opls>` | k1,k2,k3,k4 | type dihedrals |
+------------------------------------------------------------------------+-------------------------+----------------+
| :doc:`quadratic <dihedral_quadratic>` | k,phi0 | type dihedrals |
+------------------------------------------------------------------------+-------------------------+----------------+
Note that internally, phi0 is stored in radians, so the variable
this fix use to reset phi0 needs to generate values in radians.
----------
.. versionadded:: 2Apr2025
The *improper* keyword uses the specified variable to change the value of

7
doc/src/fix_ave_correlate_long.rst
View File

@ -82,10 +82,9 @@ specified values may represent calculations performed by computes and
fixes which store their own "group" definitions.
Each listed value can be the result of a compute or fix or the
evaluation of an equal-style or vector-style variable. For
vector-style variables, the specified indices can include a wildcard
character. See the :doc:`fix ave/correlate <fix_ave_correlate>` page
for details.
evaluation of an equal-style or vector-style variable. The specified
indices can include a wildcard string. See the
:doc:`fix ave/correlate <fix_ave_correlate>` page for details on that.
The *Nevery* and *Nfreq* arguments specify on what time steps the input
values will be used to calculate correlation data and the frequency

296
doc/src/fix_ave_moments.rst Normal file
View File

@ -0,0 +1,296 @@
.. index:: fix ave/moments
fix ave/moments command
=======================
Syntax
""""""
.. code-block:: LAMMPS
fix ID group-ID ave/moments Nevery Nrepeat Nfreq value1 value2 ... moment1 moment2 ... keyword args ...
* ID, group-ID are documented in :doc:`fix <fix>` command
* ave/moments = style name of this fix command
* Nevery = use input values every this many time steps
* Nrepeat = # of times to use input values for calculating averages
* Nfreq = calculate averages every this many time steps
* one or more input variables can be listed
* value = v_name
.. parsed-literal::
c_ID = global scalar calculated by a compute with ID
c_ID[I] = Ith component of global vector calculated by a compute with ID, I can include wildcard (see below)
f_ID = global scalar calculated by a fix with ID
f_ID[I] = Ith component of global vector calculated by a fix with ID, I can include wildcard (see below)
v_name = value calculated by an equal-style variable with name
v_name[I] = value calculated by a vector-style variable with name, I can include wildcard (see below)
* one or more moments to compute can be listed
* moment = *mean* or *stddev* or *variance* or *skew* or *kurtosis*, see exact definitions below.
* zero or more keyword/arg pairs may be appended
* keyword = *start* or *history*
.. parsed-literal::
*start* args = Nstart
Nstart = invoke first after this time step
*history* args = Nrecent
Nrecent = keep a history of up to Nrecent outputs
Examples
""""""""
.. code-block:: LAMMPS
fix 1 all ave/moments 1 1000 100 v_volume mean stddev
fix 1 all ave/moments 1 200 1000 v_volume variance kurtosis history 10
Description
"""""""""""
.. versionadded:: TBD
Using one or more values as input, calculate the moments of the underlying
(population) distributions based on samples collected every few time
steps over a time step window. The definitions of the moments calculated
are given below.
The group specified with this command is ignored. However, note that
specified values may represent calculations performed by computes and
fixes which store their own "group" definitions.
Each listed value can be the result of a :doc:`compute <compute>` or
:doc:`fix <fix>` or the evaluation of an equal-style or vector-style
:doc:`variable <variable>`. In each case, the compute, fix, or variable
must produce a global quantity, not a per-atom or local quantity.
If you wish to spatial- or time-average or histogram per-atom
quantities from a compute, fix, or variable, then see the :doc:`fix
ave/chunk <fix_ave_chunk>`, :doc:`fix ave/atom <fix_ave_atom>`, or
:doc:`fix ave/histo <fix_ave_histo>` commands. If you wish to sum a
per-atom quantity into a single global quantity, see the :doc:`compute
reduce <compute_reduce>` command.
Many :doc:`computes <compute>` and :doc:`fixes <fix>` produce global
quantities. See their doc pages for details. :doc:`Variables <variable>`
of style *equal* and *vector* are the only ones that can be used with
this fix. Variables of style *atom* cannot be used, since they produce
per-atom values.
The input values must all be scalars or vectors with a bracketed term
appended, indicating the :math:`I^\text{th}` value of the vector is
used.
The result of this fix can be accessed as a vector, containing the
interleaved moments of each input in order. If M moments are requested,
then the moments of input 1 will be the first M values in the vector
output by this fix. The moments of input 2 will the next M values, etc.
If there are N values, the vector length will be N*M.
----------
For input values from a compute or fix or variable, the bracketed index
I can be specified using a wildcard asterisk with the index to
effectively specify multiple values. This takes the form "\*" or "\*n"
or "m\*" or "m\*n". If :math:`N` is the size of the vector, then an
asterisk with no numeric values means all indices from 1 to :math:`N`.
A leading asterisk means all indices from 1 to n (inclusive). A
trailing asterisk means all indices from n to :math:`N` (inclusive). A
middle asterisk means all indices from m to n (inclusive).
Using a wildcard is the same as if the individual elements of the vector
or cells of the array had been listed one by one. For examples, see the
description of this capability in :doc:`fix ave/time <fix_ave_time>`.
----------
The :math:`N_\text{every}`, :math:`N_\text{repeat}`, and
:math:`N_\text{freq}` arguments specify on what time steps the input
values will be used in order to contribute to the average. The final
statistics are generated on time steps that are a multiple of
:math:`N_\text{freq}`\ . The average is over a window of up to
:math:`N_\text{repeat}` quantities, computed in the preceding portion of
the simulation once every :math:`N_\text{every}` time steps.
.. note::
Contrary to most fix ave/* commands, it is not required that Nevery *
Nrepeat <= Nfreq. This is to allow the user to choose the time
window and number of samples contributing to the output at each
Nfreq interval.
For example, if :math:`N_\text{freq}=100` and :math:`N_\text{repeat}=5`
(and :math:`N_\text{every}=1`), then on step 100 values from time steps
96, 97, 98, 99, and 100 will be used. The fix does not compute its
inputs on steps that are not required. If :math:`N_\text{freq}=5`,
:math:`N_\text{repeat}=8` and :math:`N_\text{every}=1`, then values
will first be calculated on step 5 from steps 1-5, on step 10 from 3-10,
on step 15 from 8-15 and so on, forming a rolling average over
timesteps that span a time window larger than Nfreq.
----------
If a value begins with "c\_", a compute ID must follow which has been
previously defined in the input script. If no bracketed term is
appended, the global scalar calculated by the compute is used. If a
bracketed term is appended, the Ith element of the global vector
calculated by the compute is used. See the discussion above for how I
can be specified with a wildcard asterisk to effectively specify
multiple values.
If a value begins with "f\_", a fix ID must follow which has been
previously defined in the input script. If no bracketed term is
appended, the global scalar calculated by the fix is used. If a
bracketed term is appended, the Ith element of the global vector
calculated by the fix is used. See the discussion above for how I can
be specified with a wildcard asterisk to effectively specify multiple
values.
Note that some fixes only produce their values on certain time steps,
which must be compatible with *Nevery*, else an error will result.
Users can also write code for their own fix styles and :doc:`add them to
LAMMPS <Modify>`.
If a value begins with "v\_", a variable name must follow which has been
previously defined in the input script. Only equal-style or vector-style
variables can be used, which both produce global values. Vector-style
variables require a bracketed term to specify the Ith element of the
vector calculated by the variable.
Note that variables of style *equal* and *vector* define a formula which
can reference individual atom properties or thermodynamic keywords, or
they can invoke other computes, fixes, or variables when they are
evaluated, so this is a very general means of specifying quantities to
time average.
----------
The moments are output in the order requested in the arguments following
the last input. Any number and order of moments can be specified,
although it does not make much sense to specify the same moment multiple
times. All moments are computed using a correction of the sample estimators
used to obtain unbiased cumulants :math:`k_{1..4}` (see :ref:`(Cramer)
<Cramer1>`). The correction for variance is the standard Bessel
correction. For other moments, see :ref:`(Joanes)<Joanes1>`.
For *mean*, the arithmetic mean :math:`\bar{x} = \frac{1}{n}
\sum_{i=1}^{n} x_i` is calculated.
For *variance*, the Bessel-corrected sample variance :math:`var = k_2 =
\frac{1}{n - 1} \sum_{i=1}^{n} (x_i - \bar{x})^2` is calculated.
For *stddev*, the Bessel-corrected sample standard deviation
:math:`stddev = \sqrt{k_2}` is calculated.
For *skew*, the adjusted Fisher--Pearson standardized moment :math:`G_1
= \frac{k_3}{k_2^{3/2}} = \frac{k_3}{stddev^3}` is calculated.
For *kurtosis*, the adjusted Fisher--Pearson standardized moment
:math:`G_2 = \frac{k_4}{k_2^2}` is calculated.
----------
Fix invocation and output can be modified by optional keywords.
The *start* keyword specifies that the first computation should be no
earlier than the step number given (but will still occur on a multiple
of *Nfreq*). The default is step 0. Often input values can be 0.0 at
time 0, so setting *start* to a larger value can avoid including a 0.0
in a longer series.
The *history* keyword stores the Nrecent most recent outputs on Nfreq
timesteps, so they can be accessed as global outputs of the fix. Nrecent
must be >= 1. The default is 1, meaning only the most recent output is
accessible. For example, if history 10 is specified and Nfreq = 1000,
then on timestep 20000, the Nfreq outputs from steps 20000, 19000, ...
11000 are available for access. See below for details on how to access
the history values.
For example, this will store the outputs of the previous 10 Nfreq
time steps, i.e. a window of 10000 time steps:
.. code-block:: LAMMPS
fix 1 all ave/moments 1 200 1000 v_volume mean history 10
The previous results can be accessed as values in a global array output
by this fix. Each column of the array is the vector output of the N-th
preceding Nfreq timestep. For example, assuming a single moment is
calculated, the most recent result corresponding to the third input
value would be accessed as "f_name[3][1]", "f_name[3][4]" is the 4th
most recent and so on. The current vector output is always the first
column of the array, corresponding to the most recent result.
To illustrate the utility of keeping output history, consider using
this fix in conjunction with :doc:`fix halt <fix_halt>` to stop a run
automatically if a quantity is converged to within some desired tolerance:
.. code-block:: LAMMPS
variable target equal etot
fix aveg all ave/moments 1 200 1000 v_target mean stddev history 10
variable stopcond equal "abs(f_aveg[1]-f_aveg[1][10])<f_aveg[2]"
fix fhalt all halt 1000 v_stopcond == 1
In this example, every 1000 time steps, the average and standard
deviation of the total energy over the previous 200 time steps are
calculated. If the difference between the most recent and 10-th most
recent average is lower than the most recent standard deviation, the run
is stopped.
----------
Restart, fix_modify, output, run start/stop, minimize info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
No information about this fix is written to :doc:`binary restart files
<restart>`.
This fix produces a global vector and global array which can be accessed
by various :doc:`output commands <Howto_output>`. The values can be
accessed on any time step, but may not be current.
A global vector is produced with the # of elements = number of moments *
number of inputs. The moments are output in the order given in the fix
definition. An array is produced having # of rows = length of vector
output (with an ordering which matches the vector) and # of columns =
value of *history*. There is always at least one column.
Each element of the global vector or array can be either "intensive" or
"extensive", depending on whether the values contributing to the element
are "intensive" or "extensive". If a compute or fix provides the value
being time averaged, then the compute or fix determines whether the value
is intensive or extensive; see the page for that compute or fix for
further info. Values produced by a variable are treated as intensive.
No parameter of this fix can be used with the *start/stop* keywords of
the :doc:`run <run>` command. This fix is not invoked during
:doc:`energy minimization <minimize>`.
Restrictions
""""""""""""
This compute 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 ave/time <fix_ave_time>`,
Default
"""""""
The option defaults are history = 1, start = 0.
----------
.. _Cramer1:
**(Cramer)** Cramer, Mathematical Methods of Statistics, Princeton University Press (1946).
.. _Joanes1:
**(Joanes)** Joanes, Gill, The Statistician, 47, 183--189 (1998).

208
doc/src/fix_gjf.rst Normal file
View File

@ -0,0 +1,208 @@
.. index:: fix gjf
fix gjf command
========================
Syntax
""""""
.. code-block:: LAMMPS
fix ID group-ID gjf Tstart Tstop damp seed keyword values ...
* ID, group-ID are documented in :doc:`fix <fix>` command
* gjf = style name of this fix command
* Tstart,Tstop = desired temperature at start/end of run (temperature units)
* Tstart can be a variable (see below)
* damp = damping parameter (time units)
* seed = random number seed to use for white noise (positive integer)
* zero or more keyword/value pairs may be appended
* keyword = *vel* or *method*
.. parsed-literal::
*vel* value = *vfull* or *vhalf*
*vfull* = use on-site velocity
*vhalf* = use half-step velocity
*method* value = *1-8*
*1-8* = choose one of the many GJ formulations
*7* = requires input of additional scalar between 0 and 1
Examples
""""""""
.. code-block:: LAMMPS
fix 3 boundary gjf 10.0 10.0 1.0 699483
fix 1 all gjf 10.0 100.0 100.0 48279 vel vfull method 4
fix 2 all gjf 10.0 10.0 1.0 26488 method 7 0.95
Description
"""""""""""
.. versionadded:: TBD
Apply a Langevin thermostat as described in :ref:`(Gronbech-Jensen-2020) <Gronbech-Jensen-2020>`
to a group of atoms which models an interaction with a background
implicit solvent. As described in the papers cited below, the GJ methods
provide exact diffusion, drift, and Boltzmann sampling for linear systems for
any time step within the stability limit. The purpose of this set of methods
is therefore to significantly improve statistical accuracy at longer time steps
compared to other thermostats.
The current implementation provides the user with the option to output
the velocity in one of two forms: *vfull* or *vhalf*. The option *vhalf*
outputs the 2GJ half-step velocity given in :ref:`Gronbech Jensen/Gronbech-Jensen
<Gronbech-Jensen-2019>`; for linear systems, this velocity is shown to not
have any statistical errors for any stable time step. The option *vfull*
outputs the on-site velocity given in :ref:`Gronbech-Jensen/Farago
<Gronbech-Jensen-Farago>`; this velocity is shown to be systematically lower
than the target temperature by a small amount, which grows
quadratically with the timestep. An overview of statistically correct Boltzmann
and Maxwell-Boltzmann sampling of true on-site and true half-step velocities is
given in :ref:`Gronbech-Jensen-2020 <Gronbech-Jensen-2020>`.
This fix allows the use of several GJ methods as listed in :ref:`Gronbech-Jensen-2020 <Gronbech-Jensen-2020>`.
The GJ-VII method is described in :ref:`Finkelstein <Finkelstein>` and GJ-VIII
is described in :ref:`Gronbech-Jensen-2024 <Gronbech-Jensen-2024>`.
The implementation follows the splitting form provided in Eqs. (24) and (25)
in :ref:`Gronbech-Jensen-2024 <Gronbech-Jensen-2024>`, including the application
of Gaussian noise values, per the description in
:ref:`Gronbech-Jensen-2023 <Gronbech-Jensen-2023>`.
.. note::
Unlike the :doc:`fix langevin <fix_langevin>` command which performs force
modifications only, this fix performs thermostatting and time integration.
Thus you no longer need a separate time integration fix, like :doc:`fix nve <fix_nve>`.
See the :doc:`Howto thermostat <Howto_thermostat>` page for
a discussion of different ways to compute temperature and perform
thermostatting.
The desired temperature at each timestep is a ramped value during the
run from *Tstart* to *Tstop*\ .
*Tstart* can be specified as an equal-style or atom-style
:doc:`variable <variable>`. In this case, the *Tstop* setting is
ignored. If the value is a variable, it should be specified as
v_name, where name is the variable name. In this case, the variable
will be evaluated each timestep, and its value used to determine the
target temperature.
Equal-style variables can specify formulas with various mathematical
functions, and include :doc:`thermo_style <thermo_style>` command
keywords for the simulation box parameters and timestep and elapsed
time. Thus it is easy to specify a time-dependent temperature.
Atom-style variables can specify the same formulas as equal-style
variables but can also include per-atom values, such as atom
coordinates. Thus it is easy to specify a spatially-dependent
temperature with optional time-dependence as well.
Like other fixes that perform thermostatting, this fix can be used
with :doc:`compute commands <compute>` that remove a "bias" from the
atom velocities. E.g. to apply the thermostat only to atoms within a
spatial :doc:`region <region>`, or to remove the center-of-mass
velocity from a group of atoms, or to remove the x-component of
velocity from the calculation.
This is not done by default, but only if the :doc:`fix_modify
<fix_modify>` command is used to assign a temperature compute to this
fix that includes such a bias term. See the doc pages for individual
:doc:`compute temp commands <compute>` to determine which ones include
a bias.
The *damp* parameter is specified in time units and determines how
rapidly the temperature is relaxed. For example, a value of 100.0 means
to relax the temperature in a timespan of (roughly) 100 time units
(:math:`\tau` or fs or ps - see the :doc:`units <units>` command). The
damp factor can be thought of as inversely related to the viscosity of
the solvent. I.e. a small relaxation time implies a high-viscosity
solvent and vice versa. See the discussion about :math:`\gamma` and
viscosity in the documentation for the :doc:`fix viscous <fix_viscous>`
command for more details.
The random # *seed* must be a positive integer. A Marsaglia random
number generator is used. Each processor uses the input seed to
generate its own unique seed and its own stream of random numbers.
Thus the dynamics of the system will not be identical on two runs on
different numbers of processors.
----------
The keyword/value option pairs are used in the following ways.
The keyword *vel* determines which velocity is used to determine
quantities of interest in the simulation.
The keyword *method* selects one of the eight GJ-methods implemented in LAMMPS.
----------
Restart, fix_modify, output, run start/stop, minimize info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
No information about this fix is written to :doc:`binary restart files <restart>`.
Because the state of the random number generator is not saved in restart files,
this means you cannot do "exact" restarts with this fix, where the simulation
continues on the same as if no restart had taken place. However, in a
statistical sense, a restarted simulation should produce the same behavior.
Additionally, the GJ methods implement noise exclusively within each time step
(unlike the BBK thermostat of the fix-langevin). The restart is done with
either vfull or vhalf velocity output for as long as the choice of vfull/vhalf
is the same for the simulation as it is in the restart file.
The :doc:`fix_modify <fix_modify>` *temp* option is supported by this
fix. You can use it to assign a temperature :doc:`compute <compute>`
you have defined to this fix which will be used in its thermostatting
procedure, as described above. For consistency, the group used by
this fix and by the compute should be the same.
This fix can ramp its target temperature over multiple runs, using the
*start* and *stop* keywords of the :doc:`run <run>` command. See the
:doc:`run <run>` command for details of how to do this.
This fix is not invoked during :doc:`energy minimization <minimize>`.
Restrictions
""""""""""""
This fix is not compatible with run_style respa. It is not compatible with
accelerated packages such as KOKKOS.
Related commands
""""""""""""""""
:doc:`fix langevin <fix_langevin>`, :doc:`fix nvt <fix_nh>`
Default
"""""""
The option defaults are vel = vhalf, method = 1.
----------
.. _Gronbech-Jensen-2020:
**(Gronbech-Jensen-2020)** Gronbech-Jensen, Mol Phys 118, e1662506 (2020).
.. _Gronbech-Jensen-2019:
**(Gronbech Jensen/Gronbech-Jensen)** Gronbech Jensen and Gronbech-Jensen, Mol Phys, 117, 2511 (2019)
.. _Gronbech-Jensen-Farago:
**(Gronbech-Jensen/Farago)** Gronbech-Jensen and Farago, Mol Phys, 111, 983 (2013).
.. _Finkelstein:
**(Finkelstein)** Finkelstein, Cheng, Florin, Seibold, Gronbech-Jensen, J. Chem. Phys., 155, 18 (2021)
.. _Gronbech-Jensen-2024:
**(Gronbech-Jensen-2024)** Gronbech-Jensen, J. Stat. Phys. 191, 137 (2024).
.. _Gronbech-Jensen-2023:
**(Gronbech-Jensen-2023)** Gronbech-Jensen, J. Stat. Phys. 190, 96 (2023).

19
doc/src/fix_langevin.rst
View File

@ -56,7 +56,7 @@ Examples
Description
"""""""""""
Apply a Langevin thermostat as described in :ref:`(Schneider) <Schneider1>`
Apply a Langevin thermostat as described in :ref:`(Bruenger) <Bruenger1>`
to a group of atoms which models an interaction with a background
implicit solvent. Used with :doc:`fix nve <fix_nve>`, this command
performs Brownian dynamics (BD), since the total force on each atom
@ -241,6 +241,13 @@ to zero by subtracting off an equal part of it from each atom in the
group. As a result, the center-of-mass of a system with zero initial
momentum will not drift over time.
.. deprecated:: TDB
The *gjf* keyword in fix langevin is deprecated and will be removed
soon. The GJF functionality has been moved to its own fix style
:doc:`fix gjf <fix_gjf>` and it is strongly recommended to use that
fix instead.
The keyword *gjf* can be used to run the :ref:`Gronbech-Jensen/Farago
<Gronbech-Jensen>` time-discretization of the Langevin model. As
described in the papers cited below, the purpose of this method is to
@ -324,14 +331,16 @@ types, tally = no, zero = no, gjf = no.
----------
.. _Bruenger1:
**(Bruenger)** Bruenger, Brooks, and Karplus, Chem. Phys. Lett. 105, 495 (1982).
[Previously attributed to Schneider and Stoll, Phys. Rev. B 17, 1302 (1978).
Implementation remains unchanged.]
.. _Dunweg1:
**(Dunweg)** Dunweg and Paul, Int J of Modern Physics C, 2, 817-27 (1991).
.. _Schneider1:
**(Schneider)** Schneider and Stoll, Phys Rev B, 17, 1302 (1978).
.. _Gronbech-Jensen:
**(Gronbech-Jensen)** Gronbech-Jensen and Farago, Mol Phys, 111, 983

264
doc/src/fix_neighbor_swap.rst Normal file
View File

@ -0,0 +1,264 @@
.. index:: fix neighbor/swap
fix neighbor/swap command
=========================
Syntax
""""""
.. code-block:: LAMMPS
fix ID group-ID neighbor/swap N X seed T R0 voro-ID keyword values ...
* ID, group-ID are documented in :doc:`fix <fix>` command
* neighbor/swap = style name of this fix command
* N = invoke this fix every N steps
* X = number of swaps to attempt every N steps
* seed = random # seed (positive integer)
* T = scaling temperature of the MC swaps (temperature units)
* R0 = scaling swap probability of the MC swaps (distance units)
* voro-ID = valid voronoi compute id (compute voronoi/atom)
* one or more keyword/value pairs may be appended to args
* keywords *types* and *diff* are mutually exclusive, but one must be specified
* keyword = *types* or *diff* or *ke* or *region* or *rates*
.. parsed-literal::
*types* values = two or more atom types (Integers in range [1,Ntypes] or type labels)
*diff* values = one atom type
*ke* value = *yes* or *no*
*yes* = kinetic energy is conserved after atom swaps
*no* = no conservation of kinetic energy after atom swaps
*region* value = region-ID
region-ID = ID of region to use as an exchange/move volume
*rates* values = V1 V2 . . . Vntypes values to conduct variable diffusion for different atom types (unitless)
Examples
""""""""
.. code-block:: LAMMPS
compute voroN all voronoi/atom neighbors yes
fix mc all neighbor/swap 10 160 15238 1000.0 3.0 voroN diff 2
fix myFix all neighbor/swap 100 1 12345 298.0 3.0 voroN region my_swap_region types 5 6
fix kmc all neighbor/swap 1 100 345 1.0 3.0 voroN diff 3 rates 3 1 6
Description
"""""""""""
.. versionadded:: TBD
This fix performs Monte-Carlo (MC) evaluations to enable kinetic
Monte Carlo (kMC)-type behavior during MD simulation by allowing
neighboring atoms to swap their positions. In contrast to the :doc:`fix
atom/swap <fix_atom_swap>` command which swaps pairs of atoms anywhere
in the simulation domain, the restriction of the MC swapping to
neighbors enables a hybrid MD/kMC-like simulation.
Neighboring atoms are defined by using a Voronoi tesselation performed
by the :doc:`compute voronoi/atom <compute_voronoi_atom>` command.
Two atoms are neighbors if their Voronoi cells share a common face
(3d) or edge (2d).
The selection of a swap neighbor is made using a distance-based
criterion for weighting the selection probability of each swap, in the
same manner as kMC selects a next event using relative probabilities.
The acceptance or rejection of each swap is determined via the
Metropolis criterion after evaluating the change in system energy due
to the swap.
A detailed explanation of the original implementation of this
algorithm can be found in :ref:`(Tavenner 2023) <TavennerMDkMC>`
where it was used to simulated accelerated diffusion in an MD context.
Simulating inherently kinetically-limited behaviors which rely on rare
events (such as atomic diffusion in a solid) is challenging for
traditional MD since its relatively short timescale will not naturally
sample many events. This fix addresses this challenge by allowing rare
neighbor hopping events to be sampled in a kMC-like fashion at a much
faster rate (set by the specified *N* and *X* parameters). This enables
the processes of atomic diffusion to be approximated during an MD
simulation, effectively decoupling the MD atomic vibrational timescale
and the atomic hopping (kMC event) timescale.
The algorithm implemented by this fix is as follows:
- The MD simulation is paused every *N* steps
- A Voronoi tesselation is performed for the current atom configuration.
- Then *X* atom swaps are attempted, one after the other.
- For each swap, an atom *I* is selected randomly from the list of
atom types specified by either the *types* or *diff* keywords.
- One of *I*'s Voronoi neighbors *J* is selected using the
distance-weighted probability for each neighbor detailed below.
- The *I,J* atom IDs are communicated to all processors so that a
global energy evaluation can be performed for the post-swap state
of the system.
- The swap is accepted or rejected based on the Metropolis criterion
using the energy change of the system and the specified temperature
*T*.
Here are a few comments on the computational cost of the swapping
algorithm.
1. The cost of a global energy evaluation is similar to that of an MD
timestep.
2. Similar to other MC algorithms in LAMMPS, improved parallel
efficiency is achieved with a smaller number of atoms per
processor than would typically be used in an standard MD
simulation. This is because the per-energy evaluation cost
increases relative to the balance of MD/MC steps as indicated by
1., but the communication cost remains relatively constant for a
given number of MD steps.
3. The MC portion of the simulation will run dramatically slower if
the pair style uses different cutoffs for different atom types (or
type pairs). This is because each atom swap then requires a
rebuild of the neighbor list to ensure the post-swap global energy
can be computed correctly.
Limitations are imposed on selection of *I,J* atom pairs to avoid
swapping of atoms which are outside of a reasonable cutoff (e.g. due to
a Voronoi tesselation near free surfaces) though the use of a
distance-weighted probability scaling.
----------
This section gives more details on other arguments and keywords.
The random number generator (RNG) used by all the processors for MC
operations is initialized with the specified *seed*.
The distance-based probability is weighted by the specified *R0* which
sets the radius :math:`r_0` in this formula
.. math::
p_{ij} = e^{(\frac{r_{ij}}{r_0})^2}
where :math:`p_{ij}` is the probability of selecting atom :math:`j` to
swap with atom :math:`i`. Typically, a value for *R0* around the
average nearest-neighbor spacing is appropriate. Since this is simply a
probability weighting, the swapping behavior is not very sensitive to
the exact value of *R0*.
The required *voro-ID* value is the compute-ID of a
:doc:`compute voronoi/atom <compute_voronoi_atom>` command like
this:
.. code-block:: LAMMPS
compute compute-ID group-ID voronoi/atom neighbors yes
It must return per-atom list of valid neighbor IDs as in the
:doc:`compute voronoi/atom <compute_voronoi_atom>` command.
The keyword *types* takes two or more atom types as its values. Only
atoms *I* of the first atom type will be selected. Only atoms *J* of the
remaining atom types will be considered as potential swap partners.
The keyword *diff* take a single atom type as its value. Only atoms
*I* of the that atom type will be selected. Atoms *J* of all
remaining atom types will be considered as potential swap partners.
This includes the atom type specified with the *diff* keyword to
account for self-diffusive hops between two atoms of the same type.
Note that the *neighbors yes* option must be enabled for use with this
fix. The group-ID should include all the atoms which this fix will
potentially select. I.e. the group-ID used in the voronoi compute should
include the same atoms as that indicated by the *types* keyword. If the
*diff* keyword is used, the group-ID should include atoms of all types
in the simulation.
The keyword *ke* takes *yes* (default) or *no* as its value. It two
atoms are swapped with different masses, then a value of *yes* will
rescale their respective velocities to conserve the kinetic energy of
the system. A value of *no* will perform no rescaling, so that
kinetic energy is not conserved. See the restriction on this keyword
below.
The *region* keyword takes a *region-ID* as its value. If specified,
then only atoms *I* and *J* within the geometric region will be
considered as swap partners. See the :doc:`region <region>` command
for details. This means the group-ID for the :doc:`compute
voronoi/atom <compute_voronoi_atom>` command also need only contain
atoms within the region.
The keyword *rates* can modify the swap rate based on the type of atom
*J*. Ntype values must be specified, where Ntype = the number of atom
types in the system. Each value is used to scale the probability
weighting given by the equation above. In the third example command
above, a simulation has 3 atoms types. Atom *I*s of type 1 are
eligible for swapping. Swaps may occur with atom *J*s of all 3 types.
Assuming all *J* atoms are equidistant from an atom *I*, *J* atoms of
type 1 will be 3x more likely to be selected as a swap partner than
atoms of type 2. And *J* atoms of type 3 will be 6.5x more likely to
be selected than atoms of type 2. If the *rates* keyword is not used,
all atom types will be treated with the same probability during selection
of swap attempts.
Restart, fix_modify, output, run start/stop, minimize info
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
This fix writes the state of the fix to :doc:`binary restart files
<restart>`. This includes information about the random number generator
seed, the next timestep for MC exchanges, and the number of exchange
attempts and successes. See the :doc:`read_restart <read_restart>`
command for info on how to re-specify a fix in an input script that
reads a restart file, so that the operation of the fix continues in an
uninterrupted fashion.
None of the :doc:`fix_modify <fix_modify>` options are relevant to this
fix.
This fix computes a global vector of length 2, which can be accessed
by various :doc:`output commands <Howto_output>`. The vector values are
the following global cumulative quantities:
#. swap attempts
#. swap accepts
The vector values calculated by this fix are "intensive".
No parameter of this fix can be used with the *start/stop* keywords of
the :doc:`run <run>` command. This fix is not invoked during
:doc:`energy minimization <minimize>`.
Restrictions
""""""""""""
This fix is part of the MC package. It is only enabled if LAMMPS was
built with that package. See the :doc:`Build package <Build_package>`
doc page for more info. Also this fix requires that the :ref:`VORONOI
package <PKG-VORONOI>` is installed, otherwise the fix will not be
compiled.
The :doc:`compute voronoi/atom <compute_voronoi_atom>` command
referenced by the required voro-ID must return neighboring atoms as
illustrated in the examples above.
If this fix is used with systems that do not have per-type masses
(e.g. atom style sphere), the *ke* keyword must be set to *off* since
the implemented algorithm will not be able to re-scale velocities
properly.
Related commands
""""""""""""""""
:doc:`fix nvt <fix_nh>`, :doc:`compute voronoi/atom <compute_voronoi_atom>`
:doc:`delete_atoms <delete_atoms>`, :doc:`fix gcmc <fix_gcmc>`,
:doc:`fix atom/swap <fix_atom_swap>`, :doc:`fix mol/swap <fix_mol_swap>`,
:doc:`fix sgcmc <fix_sgcmc>`
Default
"""""""
The option defaults are *ke* = yes and *rates* = 1 for all atom types.
----------
.. _TavennerMDkMC:
**(Tavenner 2023)** J Tavenner, M Mendelev, J Lawson, Computational
Materials Science, 218, 111929 (2023).

31
doc/src/fix_qeq_rel_reaxff.rst
View File

@ -37,18 +37,18 @@ Examples
Description
"""""""""""
.. versionadded:: 19Nov2024
.. versionadded:: 2Apr2025
This fix implements the QEqR method for charge equilibration, which
differs from the QEq charge equilibration method :ref:`(Rappe and
Goddard) <Rappe4>` only in how external electric fields are accounted
for. This fix therefore raises a warning when used without :doc:`fix
efield <fix_efield>` since :doc:`fix qeq/reaxff <fix_qeq_reaxff>` should
be used without an external electric field. Charges are computed with
the QEqR method by minimizing the electrostatic energy of the system in
the same way as the QEq method but where the absolute electronegativity,
:math:`\chi_i`, of each atom in the QEq method is replaced with an
effective electronegativity given by
This fix implements the QEqR method :ref:`(Lalli) <lalli2>` for charge
equilibration, which differs from the QEq charge equilibration method
:ref:`(Rappe and Goddard) <Rappe4>` only in how external electric fields
are accounted for. This fix therefore raises a warning when used without
:doc:`fix efield <fix_efield>` since :doc:`fix qeq/reaxff <fix_qeq_reaxff>`
should be used when no external electric field is present. Charges are
computed with the QEqR method by minimizing the electrostatic energy of
the system in the same way as the QEq method but where the absolute
electronegativity, :math:`\chi_i`, of each atom in the QEq method is
replaced with an effective electronegativity given by
.. math::
\chi_{\mathrm{r}i} = \chi_i + \frac{\sum_{j=1}^{N} \beta(\phi_i - \phi_j) S_{ij}}
@ -61,8 +61,9 @@ external electric field and :math:`S_{ij}` is the overlap integral
between atoms :math:`i` and :math:`j`. This formulation is advantageous
over the method used by :doc:`fix qeq/reaxff <fix_qeq_reaxff>` to
account for an external electric field in that it permits periodic
boundaries in the direction of an external electric field and in that it
does not worsen long-range charge transfer seen with QEq.
boundaries in the direction of an external electric field and in
that it does not worsen long-range charge transfer seen with
QEq. See :ref:`Lalli <lalli2>` for further details.
This fix is typically used in conjunction with the ReaxFF force field
model as implemented in the :doc:`pair_style reaxff <pair_reaxff>`
@ -184,6 +185,10 @@ scale = 1.0 and maxiter = 200
----------
.. _lalli2:
**(Lalli)** Lalli and Giusti, Journal of Chemical Physics, 162, 174311 (2025).
.. _Rappe4:
**(Rappe)** Rappe and Goddard III, Journal of Physical Chemistry, 95,

11
doc/src/fix_qtpie_reaxff.rst
View File

@ -59,8 +59,7 @@ and atom :math:`j`.
The effect of an external electric field can be incorporated into the QTPIE
method by modifying the absolute or effective electronegativities of each
atom :ref:`(Chen) <qtpie-Chen>`. This fix models the effect of an external
electric field by using the effective electronegativity given in
:ref:`(Gergs) <Gergs>`:
electric field by using the effective electronegativity :ref:`(Lalli) <lalli>`
.. math::
\tilde{\chi}_{\mathrm{r}i} = \frac{\sum_{j=1}^{N} (\chi_i - \chi_j + \beta(\phi_i - \phi_j)) S_{ij}}
@ -68,7 +67,8 @@ electric field by using the effective electronegativity given in
where :math:`\beta` is a scaling factor and :math:`\phi_i` and :math:`\phi_j`
are the electric potentials at the positions of atoms :math:`i` and :math:`j`
due to the external electric field.
due to the external electric field. Additional details regarding the
implementation and performance of this fix are provided in :ref:`Lalli <lalli>`.
This fix is typically used in conjunction with the ReaxFF force
field model as implemented in the :doc:`pair_style reaxff <pair_reaxff>`
@ -206,10 +206,9 @@ scale = 1.0 and maxiter = 200
**(Chen)** Chen, Jiahao. Theory and applications of fluctuating-charge models.
University of Illinois at Urbana-Champaign, 2009.
.. _Gergs:
.. _lalli:
**(Gergs)** Gergs, Dirkmann and Mussenbrock.
Journal of Applied Physics 123.24 (2018).
**(Lalli)** Lalli and Giusti, Journal of Chemical Physics, 162, 174311 (2025).
.. _qeq-Aktulga2:

173
doc/src/fix_set.rst Normal file
View File

@ -0,0 +1,173 @@
.. index:: fix set
fix set command
===============
Syntax
""""""
.. code-block:: LAMMPS
fix ID group-ID set Nfreq rnflag set-args
* ID, group-ID are documented in :doc:`fix <fix>` command
* set = style name of this fix command
* Nfreq = reset per-atom properties every this many timesteps
* rnflag = 1 to reneighbor on next timestep, 0 to not
* set-args = identical to args for the :doc:`set <set>` command
Examples
""""""""
.. code-block:: LAMMPS
fix 10 all set 1 0 group all i_dump v_new
fix 10 all set 1 0 group all i_dump v_turnoff
Description
"""""""""""
Reset one or more properties of one or more atoms once every *Nfreq*
steps during a simulation.
If the *rnflag* for reneighboring is set to 1, then a reneighboring
will be triggered on the next timestep (since the fix set operation
occurs at the end of the current timestep). This is important to do
if this command changes per-atom properties that need to be
communicated to ghost atoms. If this is not the case, an *rnflag*
setting of 0 can be used; reneighboring will only be triggered on
subsequent timesteps by the usual neighbor list criteria; see the
:doc:`neigh_modify command <neigh_modify>`.
Here are two examples where an *rnflag* setting of 1 are needed. If a
custom per-atom property is changed and the :doc:`fix property/atom
<fix_property_atom>` command to create the property used the *ghost
yes* keyword. Or if per-atom charges are changed, all pair styles
which compute Coulombic interactions require charge values for ghost
atoms. In both these examples, the re-neighboring will trigger the
changes in the owned atom properties to be immediately communicated to
ghost atoms.
The arguments following *Nfreq* and *rnflag* are identical to those
allowed for the :doc:`set <set>` command, as in the examples above and
below.
Note that the group-ID setting for this command is ignored. The
syntax for the :doc:`set <set>` arguments allows selection of which
atoms have their properties reset.
This command can only be used to reset an atom property using a
per-atom variable. This option in allowed by many, but not all, of
the keyword/value pairs supported by the :doc:`set <set>` command.
The reason for this restriction is that if a per-atom variable is not
used, this command will typically not change atom properties during
the simulation.
The :doc:`set <set>` command can be used with similar syntax to this
command to reset atom properties once before or between simulations.
----------
Here is an example of input script commands which will output atoms
into a dump file only when their x-velocity crosses a threshold value
*vthresh* for the first time. Their position and x-velocity will then
be output every step for *twindow* timesteps.
.. code-block:: LAMMPS
variable vthresh equal 2 # threshold velocity
variable twindow equal 10 # dump for this many steps
#
# define custom property i_dump to store timestep threshold is crossed
#
fix 2 all property/atom i_dump
set group all i_dump -1
#
# fix set command checks for threshold crossings every step
# resets i_dump from -1 to current timestep when crossing occurs
#
variable start atom "vx > v_vthresh && i_dump == -1"
variable new atom ternary(v_start,step,i_dump)
fix 3 all set 1 0 group all i_dump v_new
#
# dump command with thresh which enforces twindow
#
dump 1 all custom 1 tmp.dump id x y vx i_dump
variable dumpflag atom "i_dump >= 0 && (step-i_dump) < v_twindow"
dump_modify 1 thresh v_dumpflag == 1
#
# run the simulation
# final dump with all atom IDs which crossed threshold on which timestep
#
run 1000
write_dump all custom tmp.dump.final id i_dump modify thresh i_dump >= 0
The tmp.dump.final file lists which atoms crossed the velocity
threshold. This command will print the *twindow* timesteps when a
specific atom ID (104 in this case) was output in the tmp.dump file:
.. code-block:: LAMMPS
% grep "^104 " tmp.dump
If these commands are used instead of the above, then an atom can
cross the velocity threshold multiple times, and will be output for
*twindow* timesteps each time. However the write_dump command is no
longer useful.
.. code-block:: LAMMPS
variable vthresh equal 2 # threshold velocity
variable twindow equal 10 # dump for this many steps
#
# define custom property i_dump to store timestep threshold is crossed
#
fix 2 all property/atom i_dump
set group all i_dump -1
#
# fix set command checks for threshold crossings every step
# resets i_dump from -1 to current timestep when crossing occurs
#
variable start atom "vx > v_vthresh && i_dump == -1"
variable turnon atom ternary(v_start,step,i_dump)
variable stop atom "v_turnon >= 0 && (step-v_turnon) < v_twindow"
variable turnoff atom ternary(v_stop,v_turnon,-1)
fix 3 all set 1 0 group all i_dump v_turnoff
#
# dump command with thresh which enforces twindow
#
dump 1 all custom 1 tmp.dump id x y vx i_dump
variable dumpflag atom "i_dump >= 0 && (step-i_dump) < v_twindow"
dump_modify 1 thresh v_dumpflag == 1
#
# run the simulation
#
run 1000
----------
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. No global or per-atom quantities are stored by
this fix for access by various :doc:`output commands <Howto_output>`.
No parameter of this fix can be used with the *start/stop* keywords of
the :doc:`run <run>` command. This fix is not invoked during
:doc:`energy minimization <minimize>`.
Restrictions
""""""""""""
none
Related commands
""""""""""""""""
:doc:`set <set>`
Default
"""""""
none

43
doc/src/fix_sgcmc.rst
View File

@ -30,7 +30,9 @@ Syntax
N = number of times sampling window is moved during one MC cycle
*window_size* frac
frac = size of sampling window (must be between 0.5 and 1.0)
*atomic/energy* yes/no
yes = use the atomic energy method to calculate energy changes
no = use the default method to calculate energy changes
Examples
""""""""
@ -127,6 +129,14 @@ The number of times the window is moved during a MC cycle is set using
the parameter *window_moves* (see Sect. III.B in :ref:`Sadigh1
<Sadigh1>` for details).
The *atomic/energy* keyword controls which method is used for calculating
the energy change when atom types are swapped. A value of *no*
uses the default method, see discussion below in Restrictions section.
A value of *yes* uses the atomic energy method,
if the method has been implemented for the LAMMPS energy model,
otherwise LAMMPS will exit with an error message.
So far this has only been implemented for EAM type potentials.
------------
Restart, fix_modify, output, run start/stop, minimize info
@ -159,16 +169,26 @@ page for more info.
This fix style requires an :doc:`atom style <atom_style>` with per atom
type masses.
At present the fix provides optimized subroutines for EAM type
potentials (see above) that calculate potential energy changes due to
*local* atom type swaps very efficiently. Other potentials are
supported by using the generic potential functions. This, however, will
lead to exceedingly slow simulations since it implies that the
energy of the *entire* system is recomputed at each MC trial step. If
other potentials are to be used it is strongly recommended to modify and
optimize the existing generic potential functions for this purpose.
Also, the generic energy calculation can not be used for parallel
execution i.e. it only works with a single MPI process.
The fix provides three methods for calculating the potential energy
change due to atom type swaps. For EAM type potentials, the default
method is a carefully optimized local energy change calculation that
is part of the source code for this fix. It takes advantage of the
specific computational and communication requirements of EAM. Customizing
the local method to handle other energy models such as Tersoff has been done,
but these cases are not supported in the public LAMMPS code.
For all other LAMMPS energy models, the default method calculates
the *total* potential energy of the system before and after each
atom type swap. This method does not depend on the details of the
energy model and so is guaranteed to be correct. It is also
orders of magnitude slower than the custom EAM calculation.
In addition, it can not be used with parallel execution i.e. only
a single MPI process is allowed.
The third method uses the *atomic/energy* keyword described above.
This allows parallel execution and it is also a local calculation,
making it only a bit slower than a fully-optimized local calculation.
So far, this has been implemented for EAM type potentials.
It is straightforward to extend this to other potentials,
requiring adding an atomic energy method to the pair style.
------------
@ -180,6 +200,7 @@ The optional parameters default to the following values:
* *randseed* = 324234
* *window_moves* = 8
* *window_size* = automatic
* *atomic/energy* = no
------------

64
doc/src/pair_granular.rst
View File

@ -44,7 +44,7 @@ Examples
pair_coeff * * hertz 1000.0 50.0 tangential mindlin 1000.0 1.0 0.4 heat area 0.1
pair_style granular
pair_coeff * * mdr 5e6 0.4 1.9e5 2.0 0.5 0.5 tangential linear_history 940.0 0.0 0.7 rolling sds 2.7e5 0.0 0.6 damping none
pair_coeff * * mdr 5e6 0.4 1.9e5 2.0 0.5 0.5 tangential linear_history 940.0 1.0 0.7 rolling sds 2.7e5 0.0 0.6 damping mdr 1
Description
"""""""""""
@ -88,7 +88,8 @@ and their required arguments are:
3. *hertz/material* : E, :math:`\eta_{n0}` (or :math:`e`), :math:`\nu`
4. *dmt* : E, :math:`\eta_{n0}` (or :math:`e`), :math:`\nu`, :math:`\gamma`
5. *jkr* : E, :math:`\eta_{n0}` (or :math:`e`), :math:`\nu`, :math:`\gamma`
6. *mdr* : :math:`E`, :math:`\nu`, :math:`Y`, :math:`\Delta\gamma`, :math:`\psi_b`, :math:`e`
6. *mdr* : :math:`E`, :math:`\nu`, :math:`Y`, :math:`\Delta\gamma`,
:math:`\psi_b`, :math:`\eta_{n0}`
Here, :math:`k_n` is spring stiffness (with units that depend on model
choice, see below); :math:`\eta_{n0}` is a damping prefactor (or, in its
@ -177,6 +178,8 @@ two-part series :ref:`Zunker and Kamrin Part I <Zunker2024I>` and
:ref:`Zunker and Kamrin Part II <Zunker2024II>`. Further development
and demonstrations of its application to industrially relevant powder
compaction processes are presented in :ref:`Zunker et al. <Zunker2025>`.
If you use the *mdr* normal model the only supported damping option is
the *mdr* damping class described below.
The model requires the following inputs:
@ -200,8 +203,8 @@ The model requires the following inputs:
triggered. Lower values of :math:`\psi_b` delay the onset of the bulk elastic
response.
6. *Coefficient of restitution* :math:`0 \le e \le 1` : The coefficient of
restitution is a tunable parameter that controls damping in the normal direction.
6. *Damping coefficent* :math:`\eta_{n0} \ge 0` : The damping coefficient
is a tunable parameter that controls damping in the normal direction.
.. note::
@ -213,18 +216,12 @@ The *mdr* model produces a nonlinear force-displacement response, therefore the
critical timestep :math:`\Delta t` depends on the inputs and level of
deformation. As a conservative starting point the timestep can be assumed to be
dictated by the bulk elastic response such that
:math:`\Delta t = 0.35\sqrt{m/k_\textrm{bulk}}`, where :math:`m` is the mass of
:math:`\Delta t = 0.08\sqrt{m/k_\textrm{bulk}}`, where :math:`m` is the mass of
the smallest particle and :math:`k_\textrm{bulk} = \kappa R_\textrm{min}` is an
effective stiffness related to the bulk elastic response.
Here, :math:`\kappa = E/(3(1-2\nu))` is the bulk modulus and
:math:`R_\textrm{min}` is the radius of the smallest particle.
.. note::
The *mdr* model requires some specific settings to function properly,
please read the following text carefully to ensure all requirements are
followed.
The *atom_style* must be set to *sphere 1* to enable dynamic particle
radii. The *mdr* model is designed to respect the incompressibility of
plastic deformation and inherently tracks free surface displacements
@ -253,13 +250,6 @@ algorithm see :ref:`Zunker et al. <Zunker2025>`.
newton off
The damping model must be set to *none*. The *mdr* model already has a built
in damping model.
.. code-block:: LAMMPS
pair_coeff * * mdr 5e6 0.4 1.9e5 2 0.5 0.5 damping none
The definition of multiple *mdr* models in the *pair_style* is currently not
supported. Similarly, the *mdr* model cannot be combined with a different normal
model in the *pair_style*. Physically this means that only one homogeneous
@ -270,7 +260,7 @@ The *mdr* model currently only supports *fix wall/gran/region*, not
any *fix wall/gran/region* commands must also use the *mdr* model.
Additionally, the following *mdr* inputs must match between the
*pair_style* and *fix wall/gran/region* definitions: :math:`E`,
:math:`\nu`, :math:`Y`, :math:`\psi_b`, and :math:`e`. The exception
:math:`\nu`, :math:`Y`, :math:`\psi_b`, and :math:`\eta_{n0}`. The exception
is :math:`\Delta\gamma`, which may vary, permitting different
adhesive behaviors between particle-particle and particle-wall interactions.
@ -336,6 +326,7 @@ for the damping model currently supported are:
3. *viscoelastic*
4. *tsuji*
5. *coeff_restitution*
6. *mdr* (class) : :math:`d_{type}`
If the *damping* keyword is not specified, the *viscoelastic* model is
used by default.
@ -425,6 +416,37 @@ the damping coefficient, it accurately reproduces the specified coefficient of
restitution for both monodisperse and polydisperse particle pairs. This damping
model is not compatible with cohesive normal models such as *JKR* or *DMT*.
The *mdr* damping class contains multiple damping models that can be toggled between
by specifying different integer values for the :math:`d_{type}` input parameter. This
damping option is only compatible with the normal *mdr* contact model.
Setting :math:`d_{type} = 1` is the suggested damping option. This specifies a damping
model that takes into account the contact stiffness :math:`k_{mdr}` calculated
by the normal *mdr* contact model to determine the damping coefficient:
.. math::
\eta_n = \eta_{n0} (m_{eff}k_{mdr})^{1/2},
where :math:`k_{mdr}` is proportional to contact radius :math:`a_{mdr}` tracked by the
normal *mdr* contact model:
.. math::
k_{mdr} = 2 E_{eff} a_{mdr}.
In this case, :math:`\eta_{n0}` is simply a dimensionless coefficient that scales the
the overall damping coefficient.
The other supported option is :math:`d_{type} = 2`, which defines a simple damping model
similar to the *velocity* option
.. math::
\eta_n = \eta_{n0},
but has additional checks to avoid non-physical damping after plastic deformation.
The total normal force is computed as the sum of the elastic and
damping components:
@ -1068,8 +1090,8 @@ a bulk elastic response. Journal of the Mechanics and Physics of Solids,
**(Zunker et al, 2025)** Zunker, W., Dunatunga, S., Thakur, S.,
Tang, P., & Kamrin, K. (2025). Experimentally validated DEM for large
deformation powder compaction: mechanically-derived contact model and
screening of non-physical contacts.
deformation powder compaction: Mechanically-derived contact model and
screening of non-physical contacts. Powder Technology, 120972.
.. _Luding2008:

61
doc/src/pair_hybrid.rst
View File

@ -100,6 +100,56 @@ first is assigned to intra-molecular interactions (i.e. both atoms
have the same molecule ID), the second to inter-molecular interactions
(i.e. interacting atoms have different molecule IDs).
.. admonition:: When **NOT** to use a hybrid pair style
:class: warning
Using pair style *hybrid* can be very tempting to use if you need a
**many-body potential** supporting a mix of elements for which you
cannot find a potential file that covers *all* of them. Regardless
of how this is set up, there will be *errors*. The major use case
where the error is *small*, is when the many-body sub-styles are used
on different objects (for example a slab and a liquid, a metal and a
nano-machining work piece). In that case the *mixed* terms
**should** be provided by a pair-wise additive potential (like
Lennard-Jones or Morse) to avoid unexpected behavior and reduce
errors. LAMMPS cannot easily check for this condition and thus will
accept good and bad choices alike.
Outside of this, we *strongly* recommend *against* using pair style
hybrid with many-body potentials for the following reasons:
1. When trying to combine EAM or MEAM potentials, there is a *large*
error in the embedding term, since it is computed separately for
each sub-style only.
2. When trying to combine many-body potentials like Stillinger-Weber,
Tersoff, AIREBO, Vashishta, or similar, you have to understand
that the potential of a sub-style cannot be applied in a pair-wise
fashion but will need to be applied to multiples of atoms
(e.g. a Tersoff potential of elements A and B includes the
interactions A-A, B-B, A-B, A-A-A, A-A-B, A-B-B, A-B-A, B-A-A,
B-A-B, B-B-A, B-B-B; AIREBO also considers all quadruples of
atom elements).
3. When one of the sub-styles uses charge-equilibration (= QEq; like
in ReaxFF or COMB) you have inconsistent QEq behavior because
either you try to apply QEq to *all* atoms but then you are
missing the QEq parameters for the non-QEq pair style (and it
would be inconsistent to apply QEq for pair styles that are not
parameterized for QEq) or else you would have either no charges or
fixed charges interacting with the QEq which also leads to
inconsistent behavior between two sub-styles. When attempting to
use multiple ReaxFF instances to combine different potential
files, you might be able to work around the QEq limitations, but
point 2. still applies.
We understand that it is frustrating to not be able to run simulations
due to lack of available potential files, but that does not justify
combining potentials in a broken way via pair style hybrid. This is
not what the hybrid pair styles are designed for.
----------
Here are two examples of hybrid simulations. The *hybrid* style could
be used for a simulation of a metal droplet on a LJ surface. The metal
atoms interact with each other via an *eam* potential, the surface atoms
@ -374,12 +424,11 @@ selected sub-style.
----------
.. note::
Several of the potentials defined via the pair_style command in
LAMMPS are really many-body potentials, such as Tersoff, AIREBO, MEAM,
ReaxFF, etc. The way to think about using these potentials in a
hybrid setting is as follows.
Even though the command name "pair_style" would suggest that these are
pair-wise interactions, several of the potentials defined via the
pair_style command in LAMMPS are really many-body potentials, such as
Tersoff, AIREBO, MEAM, ReaxFF, etc. The way to think about using these
potentials in a hybrid setting is as follows.
A subset of atom types is assigned to the many-body potential with a
single :doc:`pair_coeff <pair_coeff>` command, using "\* \*" to include

163
doc/src/pair_lj_pirani.rst Normal file
View File

@ -0,0 +1,163 @@
.. index:: pair_style lj/pirani
.. index:: pair_style lj/pirani/omp
pair_style lj/pirani command
============================
Accelerator Variants: *lj/pirani/omp*
Syntax
""""""
.. code-block:: LAMMPS
pair_style lj/pirani cutoff
* lj/pirani = name of the pair style
* cutoff = global cutoff (distance units)
Examples
""""""""
.. code-block:: LAMMPS
pair_style lj/pirani 10.0
pair_coeff 1 1 4.0 7.0 6.0 3.5 0.0045
Description
"""""""""""
.. versionadded:: TBD
Pair style *lj/pirani* computes pairwise interactions from an Improved
Lennard-Jones (ILJ) potential according to :ref:`(Pirani) <Pirani>`.
The ILJ force field is adequate to model both equilibrium and
non-equilibrium properties of matter, in gaseous and condensed phases,
and at gas-surface interfaces. In particular, its use improves the
description of elementary process dynamics where the traditional
Lennard-Jones (LJ) formulation is usually applied.
.. math::
x = r/R_m \\
n_x = \alpha*x^2 + \beta \\
\gamma \equiv m \\
V(x) = \varepsilon \cdot \left( \frac{\gamma}{ n_x - \gamma} \left(\frac{1}{x} \right)^{n_x}
- \frac{n_x}{n_x - \gamma} \left(\frac{1}{x} \right)^{\gamma} \right) \qquad r < r_c
:math:`r_c` is the cutoff.
An additional parameter, :math:`\alpha`, has been introduced in order to
be able to recover the traditional Lennard-Jones 12-6 with a specific
choice of parameters. With :math:`R_m \equiv r_0 = \sigma \cdot 2^{1 /
6}`, :math:`\alpha = 0`, :math:`\beta = 12` and :math:`\gamma = 6` it is
straightforward to prove that LJ 12-6 is obtained. Also, it can be
verified that using :math:`\alpha= 4`, :math:`\beta= 8` and
:math:`\gamma = 6`, at the equilibrium distance, the first and second
derivatives of ILJ match those of LJ 12-6. The parameter :math:`R_m`
corresponds to the equilibrium distance and :math:`\epsilon` to the well
depth.
This potential provides some advantages with respect to the standard LJ
potential, as explained in :ref:`(Pirani) <Pirani>`: it provides a more
realistic description of the long range behavior and an attenuation of
the hardness of the repulsive wall.
This force field can be used for neutral-neutral (:math:`\gamma = 6`),
ion-neutral (:math:`\gamma = 4`) or ion-ion systems (:math:`\gamma =
1`). Notice that this implementation does not include explicit
electrostatic interactions. If these are desired, this pair style
should be used along with a Coulomb pair style like
:doc:`pair styles coul/cut or coul/long <pair_coul>` by using
:doc:`pair style hybrid/overlay <pair_hybrid>` and a suitable
:doc:`kspace style <kspace_style>`, if needed.
As discussed in :ref:`(Pirani) <Pirani>`, analysis of a variety of
systems showed that :math:`\alpha= 4` generally works very well. In
some special cases (e.g. those involving very small multiple charged
ions) this factor may take a slightly different value. The parameter
:math:`\beta` codifies the hardness (polarizability) of the interacting
partners, and for neutral-neutral systems it usually ranges from 6
to 11. Moreover, the modulation of :math:`\beta` can model additional
interaction effects, such as charge transfer in the perturbative limit,
and can mitigate the effect of some uncertainty in the data used to
build up the potential function.
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:`\alpha` (dimensionless)
* :math:`\beta` (dimensionless)
* :math:`\gamma` (dimensionless)
* :math:`R_m` (distance units)
* :math:`\epsilon` (energy units)
* cutoff (distance units)
The last coefficient is optional. If not specified, the global cutoff is used.
----------
.. include:: accel_styles.rst
----------
Mixing, shift, table, tail correction, restart, rRESPA info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
This pair style does not support mixing. Thus, coefficients for all I,J
pairs must be specified explicitly.
This pair style supports the :doc:`pair_modify <pair_modify>` shift
option for the energy of the pair interaction.
The :doc:`pair_modify <pair_modify>` table options are not relevant for
this pair style.
This pair style does not support the :doc:`pair_modify <pair_modify>`
tail option for adding long-range tail corrections to energy and
pressure.
This pair style writes its 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.
This pair style supports the use of the *inner*, *middle*, and
*outer* keywords of the :doc:`run_style respa <run_style>` command,
meaning the pairwise forces can be partitioned by distance at different
levels of the rRESPA hierarchy. See the :doc:`run_style <run_style>`
command for details.
----------
Restrictions
""""""""""""
This 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>`
* :doc:`pair_style lj/cut <pair_lj>`
Default
"""""""
none
--------------
.. _Pirani:
**(Pirani)** F. Pirani, S. Brizi, L. Roncaratti, P. Casavecchia, D. Cappelletti and F. Vecchiocattivi,
Phys. Chem. Chem. Phys., 2008, 10, 5489-5503.

23
doc/src/pair_lj_smooth.rst
View File

@ -48,13 +48,19 @@ At the inner cutoff the force and its first derivative
will match the non-smoothed LJ formula. At the outer cutoff the force
and its first derivative will be 0.0. The inner cutoff cannot be 0.0.
Explicit expressions for the coefficients C1, C2, C3, C4, as well as the
energy discontinuity at the cutoff can be found here :ref:`(Leoni_1) <Leoni_1>`
and here :ref:`(Leoni_2) <Leoni_2>`
.. note::
this force smoothing causes the energy to be discontinuous both
in its values and first derivative. This can lead to poor energy
conservation and may require the use of a thermostat. Plot the energy
and force resulting from this formula via the
:doc:`pair_write <pair_write>` command to see the effect.
conservation and may require the use of a thermostat. The energy
value discontinuity can be eliminated by shifting the potential
energy to be zero at the outer cutoff using the pair_modify shift
option. With or without shifting, you can plot the resulting energy
and force via the :doc:`pair_write <pair_write>` command to see the effect.
The following coefficients must be defined for each pair of atoms
types via the :doc:`pair_coeff <pair_coeff>` command as in the examples
@ -122,3 +128,14 @@ Default
"""""""
none
----------
.. _Leoni_1:
**(Leoni_1)** F. Leoni et al., Phys Rev Lett, 134, 128201 (2025).
.. _Leoni_2:
**(Leoni_2)** F. Leoni et al., Phys Rev Lett, 134, Supplementary Material (2025).

1
doc/src/pair_style.rst
View File

@ -277,6 +277,7 @@ accelerated styles exist.
* :doc:`lj/long/dipole/long <pair_dipole>` - long-range LJ and long-range point dipoles
* :doc:`lj/long/tip4p/long <pair_lj_long>` - long-range LJ and long-range Coulomb for TIP4P water
* :doc:`lj/mdf <pair_mdf>` - LJ potential with a taper function
* :doc:`lj/pirani <pair_lj_pirani>` - Improved LJ potential
* :doc:`lj/relres <pair_lj_relres>` - LJ using multiscale Relative Resolution (RelRes) methodology :ref:`(Chaimovich) <Chaimovich2>`.
* :doc:`lj/spica <pair_spica>` - LJ for SPICA coarse-graining
* :doc:`lj/spica/coul/long <pair_spica>` - LJ for SPICA coarse-graining with long-range Coulomb

18
doc/src/run.rst
View File

@ -103,14 +103,16 @@ must be done.
.. note::
If your input script changes the system between 2 runs, then the
initial setup must be performed to ensure the change is recognized by
all parts of the code that are affected. Examples are adding a
:doc:`fix <fix>` or :doc:`dump <dump>` or :doc:`compute <compute>`, changing
a :doc:`neighbor <neigh_modify>` list parameter, or writing restart file
which can migrate atoms between processors. LAMMPS has no easy way to
check if this has happened, but it is an error to use the *pre no*
option in this case.
If your input script "changes" the system between 2 runs, then the
initial setup typically needs to be performed to ensure the change
is recognized by all parts of the code that are affected. Examples
are adding a :doc:`fix <fix>` or :doc:`dump <dump>` or
:doc:`compute <compute>`, changing a :doc:`neighbor <neigh_modify>`
list parameter, using the :doc:`set <set>` command, or writing a
restart file via the :doc:`write_restart <write_restart>` command,
which can migrate atoms between processors. LAMMPS has no easy way
to check if this has happened, but it is an error to use the *pre
no* option in these cases.
If *post* is specified as "no", the full timing summary is skipped;
only a one-line summary timing is printed.

801
doc/src/set.rst
View File

@ -22,21 +22,114 @@ Syntax
for style = *region*, ID = a region ID
* one or more keyword/value pairs may be appended
* keyword = *type* or *type/fraction* or *type/ratio* or *type/subset*
or *mol* or *x* or *y* or *z* or *vx* or *vy* or *vz* or *charge* or
*dipole* or *dipole/random* or *quat* or *spin/atom* or *spin/atom/random* or
*spin/electron* or *radius/electron* or
*quat* or *quat/random* or *diameter* or *shape* or *length* or *tri* or
*theta* or *theta/random* or *angmom* or *omega* or
*mass* or *density* or *density/disc* or *temperature* or
*volume* or *image* or *bond* or *angle* or *dihedral* or
*improper* or *sph/e* or *sph/cv* or *sph/rho* or
*smd/contact/radius* or *smd/mass/density* or *dpd/theta* or
*edpd/temp* or *edpd/cv* or *cc* or *epsilon* or *apip_lambda* or
*i_name* or *d_name* or *i2_name* or *d2_name*
* keyword = *angle* or *angmom* or *apip/lambda* or *bond* or *cc* or *charge*
or *density* or *density/disc* or *diameter* or *dihedral* or *dipole*
or *dipole/random* or *dpd/theta* or *edpd/cv* or *edpd/temp* or
*epsilon* or *image* or *improper* or *length* or *mass* or *mol* or
*omega* or *quat* or *quat/random* or *radius/electron* or *shape* or
*smd/contact/radius* or *smd/mass/density* or *sph/cv* or *sph/e* or
*sph/rho* or *spin/atom* or *spin/atom/random* or *spin/electron* or
*temperature* or *theta* or *theta/random* or *tri* or *type* or
*type/fraction* or *type/ratio* or *type/subset* or *volume* or *vx*
or *vy* or *vz* or *x* or *y* or *z* or *i_name* or *d_name* or
*i2_name* or *d2_name*
.. parsed-literal::
*angle* value = numeric angle type or angle type label, for all angles between selected atoms
*angmom* values = Lx Ly Lz
Lx,Ly,Lz = components of angular momentum vector (distance-mass-velocity units)
any of Lx,Ly,Lz can be an atom-style variable (see below)
*apip/lambda* value = fast or precise or float
fast = switching parameter of fast potential (1)
precise = switching parameter of fast potential (0)
float = constant float or atom-style variable (between 0 and 1)
*bond* value = numeric bond type or bond type label, for all bonds between selected atoms
*cc* values = index cc
index = index of a chemical species (1 to Nspecies)
cc = chemical concentration of tDPD particles for a species (mole/volume units)
cc can be an atom-style variable (see below)
*charge* value = atomic charge (charge units)
value can be an atom-style variable (see below)
*density* value = particle density for a sphere or ellipsoid (mass/distance\^3 units), or for a triangle (mass/distance\^2 units) or line (mass/distance units) particle
value can be an atom-style variable (see below)
*density/disc* value = particle density for a 2d disc or ellipse (mass/distance\^2 units)
value can be an atom-style variable (see below)
*diameter* value = diameter of spherical particle (distance units)
value can be an atom-style variable (see below)
*dihedral* value = numeric dihedral type or dihedral type label, for all dihedrals between selected atoms
*dipole* values = x y z
x,y,z = orientation of dipole moment vector
any of x,y,z can be an atom-style variable (see below)
*dipole/random* values = seed Dlen
seed = random # seed (positive integer) for dipole moment orientations
Dlen = magnitude of dipole moment (dipole units)
*dpd/theta* value = internal temperature of DPD particles (temperature units)
value can be an atom-style variable (see below)
value can be NULL which sets internal temp of each particle to KE temp
*edpd/cv* value = volumetric heat capacity of eDPD particles (energy/temperature/volume units)
value can be an atom-style variable (see below)
*edpd/temp* value = temperature of eDPD particles (temperature units)
value can be an atom-style variable (see below)
*epsilon* value = dielectric constant of the medium where the atoms reside
value can be an atom-style variable (see below)
*image* values = nx ny nz
nx,ny,nz = which periodic image of the simulation box the atom is in
any of nx,ny,nz can be an atom-style variable (see below)
*improper* value = numeric improper type or improper type label, for all impropers between selected atoms
*length* value = len
len = length of line segment (distance units)
len can be an atom-style variable (see below)
*mass* value = per-atom mass (mass units)
value can be an atom-style variable (see below)
*mol* value = molecule ID
the moleclue ID can be an atom-style variable (see below)
*omega* values = Wx Wy Wz
Wx,Wy,Wz = components of angular velocity vector (radians/time units)
any of Wx,Wy,Wz can be an atom-style variable (see below)
*quat* values = a b c theta
a,b,c = unit vector to rotate particle around via right-hand rule
theta = rotation angle (degrees)
any of a,b,c,theta values can be an atom-style variable (see below)
*quat/random* value = seed
seed = random # seed (positive integer) for quaternion orientations
*radius/electron* value = eradius
eradius = electron radius (or fixed-core radius) (distance units)
value can be an atom-style variable (see below)
*shape* values = Sx Sy Sz
Sx,Sy,Sz = 3 diameters of ellipsoid (distance units)
any of Sx,Sy,Sz can be an atom-style variable (see below)
*smd/contact/radius* value = radius for short range interactions, i.e. contact and friction
value can be an atom-style variable (see below)
*smd/mass/density* value = set particle mass based on volume by providing a mass density
value can be an atom-style variable (see below)
*sph/cv* value = heat capacity of SPH particles (need units)
value can be an atom-style variable (see below)
*sph/e* value = energy of SPH particles (need units)
value can be an atom-style variable (see below)
*sph/rho* value = density of SPH particles (need units)
value can be an atom-style variable (see below)
*spin/atom* values = g x y z
g = magnitude of magnetic spin vector (in Bohr magneton's unit)
x,y,z = orientation of magnetic spin vector
any of x,y,z can be an atom-style variable (see below)
*spin/atom/random* values = seed Dlen
seed = random # seed (positive integer) for magnetic spin orientations
Dlen = magnitude of magnetic spin vector (in Bohr magneton's unit)
*spin/electron* value = espin
espin = electron spin (+1/-1), 0 = nuclei, 2 = fixed-core, 3 = pseudo-cores (i.e. ECP)
value can be an atom-style variable (see below)
*temperature* value = temperature for finite-size particles (temperature units)
value can be an atom-style variable (see below)
*theta* value = angle (degrees)
angle = orientation of line segment with respect to x-axis
value can be an atom-style variable (see below)
*theta/random* value = seed
seed = random # seed (positive integer) for line segment orienations
*tri* value = side
side = side length of equilateral triangle (distance units)
value can be an atom-style variable (see below)
*type* value = numeric atom type or type label
value can be an atom-style variable (see below)
*type/fraction* values = type fraction seed
@ -51,108 +144,22 @@ Syntax
type = numeric atom type or type label
Nsubset = exact number of selected atoms to set to new atom type
seed = random # seed (positive integer)
*mol* value = molecule ID
value can be an atom-style variable (see below)
*x*,\ *y*,\ *z* value = atom coordinate (distance units)
*volume* value = particle volume for Peridynamic particle (distance\^3 units)
value can be an atom-style variable (see below)
*vx*,\ *vy*,\ *vz* value = atom velocity (velocity units)
value can be an atom-style variable (see below)
*charge* value = atomic charge (charge units)
*x*,\ *y*,\ *z* value = atom coordinate (distance units)
value can be an atom-style variable (see below)
*dipole* values = x y z
x,y,z = orientation of dipole moment vector
any of x,y,z can be an atom-style variable (see below)
*dipole/random* value = seed Dlen
seed = random # seed (positive integer) for dipole moment orientations
Dlen = magnitude of dipole moment (dipole units)
*spin/atom* values = g x y z
g = magnitude of magnetic spin vector (in Bohr magneton's unit)
x,y,z = orientation of magnetic spin vector
any of x,y,z can be an atom-style variable (see below)
*spin/atom/random* value = seed Dlen
seed = random # seed (positive integer) for magnetic spin orientations
Dlen = magnitude of magnetic spin vector (in Bohr magneton's unit)
*radius/electron* values = eradius
eradius = electron radius (or fixed-core radius) (distance units)
*spin/electron* value = espin
espin = electron spin (+1/-1), 0 = nuclei, 2 = fixed-core, 3 = pseudo-cores (i.e. ECP)
*quat* values = a b c theta
a,b,c = unit vector to rotate particle around via right-hand rule
theta = rotation angle (degrees)
any of a,b,c,theta can be an atom-style variable (see below)
*quat/random* value = seed
seed = random # seed (positive integer) for quaternion orientations
*diameter* value = diameter of spherical particle (distance units)
value can be an atom-style variable (see below)
*shape* value = Sx Sy Sz
Sx,Sy,Sz = 3 diameters of ellipsoid (distance units)
*length* value = len
len = length of line segment (distance units)
len can be an atom-style variable (see below)
*tri* value = side
side = side length of equilateral triangle (distance units)
side can be an atom-style variable (see below)
*theta* value = angle (degrees)
angle = orientation of line segment with respect to x-axis
angle can be an atom-style variable (see below)
*theta/random* value = seed
seed = random # seed (positive integer) for line segment orienations
*angmom* values = Lx Ly Lz
Lx,Ly,Lz = components of angular momentum vector (distance-mass-velocity units)
any of Lx,Ly,Lz can be an atom-style variable (see below)
*omega* values = Wx Wy Wz
Wx,Wy,Wz = components of angular velocity vector (radians/time units)
any of wx,wy,wz can be an atom-style variable (see below)
*mass* value = per-atom mass (mass units)
value can be an atom-style variable (see below)
*density* value = particle density for a sphere or ellipsoid (mass/distance\^3 units), or for a triangle (mass/distance\^2 units) or line (mass/distance units) particle
value can be an atom-style variable (see below)
*density/disc* value = particle density for a 2d disc or ellipse (mass/distance\^2 units)
value can be an atom-style variable (see below)
*temperature* value = temperature for finite-size particles (temperature units)
value can be an atom-style variable (see below)
*volume* value = particle volume for Peridynamic particle (distance\^3 units)
value can be an atom-style variable (see below)
*image* nx ny nz
nx,ny,nz = which periodic image of the simulation box the atom is in
any of nx,ny,nz can be an atom-style variable (see below)
*bond* value = numeric bond type or bond type label, for all bonds between selected atoms
*angle* value = numeric angle type or angle type label, for all angles between selected atoms
*dihedral* value = numeric dihedral type or dihedral type label, for all dihedrals between selected atoms
*improper* value = numeric improper type or improper type label, for all impropers between selected atoms
*rheo/rho* value = density of RHEO particles (mass/distance\^3)
*rheo/status* value = status or phase of RHEO particles (unitless)
*sph/e* value = energy of SPH particles (need units)
value can be an atom-style variable (see below)
*sph/cv* value = heat capacity of SPH particles (need units)
value can be an atom-style variable (see below)
*sph/rho* value = density of SPH particles (need units)
value can be an atom-style variable (see below)
*smd/contact/radius* = radius for short range interactions, i.e. contact and friction
value can be an atom-style variable (see below)
*smd/mass/density* = set particle mass based on volume by providing a mass density
value can be an atom-style variable (see below)
*dpd/theta* value = internal temperature of DPD particles (temperature units)
value can be an atom-style variable (see below)
value can be NULL which sets internal temp of each particle to KE temp
*edpd/temp* value = temperature of eDPD particles (temperature units)
value can be an atom-style variable (see below)
*edpd/cv* value = volumetric heat capacity of eDPD particles (energy/temperature/volume units)
value can be an atom-style variable (see below)
*cc* values = index cc
index = index of a chemical species (1 to Nspecies)
cc = chemical concentration of tDPD particles for a species (mole/volume units)
*epsilon* value = dielectric constant of the medium where the atoms reside
*apip_lambda* value = fast or precise or float
fast = switching parameter of fast potential (1) (APIP package)
precise = switching parameter of fast potential (0) (APIP package)
float = constant float or atom-style variable (between 0 and 1) (APIP package)
*i_name* value = custom integer vector with name
value can be an atom-style variable (see below)
*d_name* value = custom floating-point vector with name
*i2_name* value = column of a custom integer array with name
value can be an atom-style variable (see below)
*i2_name* value = custom integer array with name
column specified as i2_name[N] where N is 1 to Ncol
*d2_name* value = column of a custom floating-point array with name
value can be an atom-style variable (see below)
*d2_name* value = custom floating-point array with name
column specified as d2_name[N] where N is 1 to Ncol
value can be an atom-style variable (see below)
Examples
""""""""
@ -181,22 +188,26 @@ Description
Set one or more properties of one or more atoms. Since atom
properties are initially assigned by the :doc:`read_data <read_data>`,
:doc:`read_restart <read_restart>` or :doc:`create_atoms <create_atoms>`
commands, this command changes those assignments. This can be useful
for overriding the default values assigned by the
:doc:`create_atoms <create_atoms>` command (e.g. charge = 0.0). It can
be useful for altering pairwise and molecular force interactions,
:doc:`read_restart <read_restart>` or :doc:`create_atoms
<create_atoms>` commands, this command changes those assignments.
This can be useful for overriding the default values assigned by the
:doc:`create_atoms <create_atoms>` command (e.g. charge = 0.0). It
can be useful for altering pairwise and molecular force interactions,
since force-field coefficients are defined in terms of types. It can
be used to change the labeling of atoms by atom type or molecule ID
when they are output in :doc:`dump <dump>` files. It can also be useful
for debugging purposes; i.e. positioning an atom at a precise location
to compute subsequent forces or energy.
when they are output in :doc:`dump <dump>` files. It can also be
useful for debugging purposes; i.e. positioning an atom at a precise
location to compute subsequent forces or energy.
Note that the *style* and *ID* arguments determine which atoms have
their properties reset. The remaining keywords specify which
properties to reset and what the new values are. Some strings like
*type* or *mol* can be used as a style and/or a keyword.
The :doc:`fix set <fix_set>` command can be used with similar syntax
to this command to reset atom properties once every *N* steps during a
simulation using via atom-style variables.
----------
This section describes how to select which atoms to change
@ -215,8 +226,8 @@ can be specified, e.g. "C". The style *mol* selects all the atoms in
a range of molecule IDs.
In each of the range cases, the range can be specified as a single
numeric value, or a wildcard asterisk can be used to specify a range
of values. This takes the form "\*" or "\*n" or "n\*" or "m\*n". For
numeric value, or with a wildcard asterisk to specify a range of
values. This takes the form "\*" or "\*n" or "n\*" or "m\*n". For
example, for the style *type*, if N = the number of atom types, then
an asterisk with no numeric values means all types from 1 to N. A
leading asterisk means all types from 1 to n (inclusive). A trailing
@ -226,25 +237,25 @@ means all types from m to n (inclusive). For all the styles except
The style *group* selects all the atoms in the specified group. The
style *region* selects all the atoms in the specified geometric
region. See the :doc:`group <group>` and :doc:`region <region>` commands
for details of how to specify a group or region.
region. See the :doc:`group <group>` and :doc:`region <region>`
commands for details of how to specify a group or region.
----------
This section describes the keyword options for which properties to
The next section describes the keyword options for which properties to
change, for the selected atoms.
Note that except where explicitly prohibited below, all of the
keywords allow an :doc:`atom-style or atomfile-style variable
<variable>` to be used as the specified value(s). If the value is a
variable, it should be specified as v_name, where name is the
variable name. In this case, the variable will be evaluated, and its
resulting per-atom value used to determine the value assigned to each
selected atom. Note that the per-atom value from the variable will be
ignored for atoms that are not selected via the *style* and *ID*
settings explained above. A simple way to use per-atom values from
the variable to reset a property for all atoms is to use style *atom*
with *ID* = "\*"; this selects all atom IDs.
variable, it should be specified as v_name, where name is the variable
name. In this case, the variable will be evaluated, and its resulting
per-atom value used to determine the value assigned to each selected
atom. Note that the per-atom value from the variable will be ignored
for atoms that are not selected via the *style* and *ID* settings
explained above. A simple way to use per-atom values from the
variable to reset a property for all atoms is to use style *atom* with
*ID* = "\*"; this selects all atom IDs.
Atom-style variables can specify formulas with various mathematical
functions, and include :doc:`thermo_style <thermo_style>` command
@ -260,52 +271,110 @@ from a file.
.. note::
Atom-style and atomfile-style variables return floating point
per-atom values. If the values are assigned to an integer variable,
such as the molecule ID, then the floating point value is truncated to
its integer portion, e.g. a value of 2.6 would become 2.
per-atom values. If the values are assigned to an integer
variable, such as the molecule ID, then the floating point value is
truncated to its integer portion, e.g. a value of 2.6 would
become 2.
----------
.. versionchanged:: 28Mar2023
Support for type labels was added for setting atom, bond, angle,
dihedral, and improper types
Support for type labels was added for setting angle types
Keyword *type* sets the atom type for all selected atoms. A specified
value can be either a numeric atom type or an atom type label. When
using a numeric type, the specified value must be from 1 to ntypes,
where ntypes was set by the :doc:`create_box <create_box>` command or
the *atom types* field in the header of the data file read by the
:doc:`read_data <read_data>` command. When using a type label it must
have been defined previously. See the :doc:`Howto type labels
<Howto_type_labels>` doc page for the allowed syntax of type labels
and a general discussion of how type labels can be used.
Keyword *angle* sets the angle type of all angles of selected atoms to
the specified value. The value can be a numeric type from 1 to
nangletypes. Or it can be a angle type label. See the :doc:`Howto
type labels <Howto_type_labels>` doc page for the allowed syntax of
type labels and a general discussion of how type labels can be used.
All atoms in a particular angle must be selected atoms in order for
the change to be made. The value of nangletypes was set by the *angle
types* field in the header of the data file read by the
:doc:`read_data <read_data>` command. This keyword does NOT allow use
of an atom-style variable.
Keyword *type/fraction* sets the atom type for a fraction of the selected
atoms. The actual number of atoms changed is not guaranteed
to be exactly the specified fraction (0 <= *fraction* <= 1), but
should be statistically close. Random numbers are used in such a way
that a particular atom is changed or not changed, regardless of how
many processors are being used. This keyword does not allow use of an
atom-style variable.
Keyword *angmom* sets the angular momentum of selected atoms. The
particles must be ellipsoids as defined by the :doc:`atom_style
ellipsoid <atom_style>` command or triangles as defined by the
:doc:`atom_style tri <atom_style>` command. The angular momentum
vector of the particles is set to the 3 specified components.
Keywords *type/ratio* and *type/subset* also set the atom type for a
fraction of the selected atoms. The actual number of atoms changed
will be exactly the requested number. For *type/ratio* the specified
fraction (0 <= *fraction* <= 1) determines the number. For
*type/subset*, the specified *Nsubset* is the number. An iterative
algorithm is used which ensures the correct number of atoms are
selected, in a perfectly random fashion. Which atoms are selected
will change with the number of processors used. These keywords do not
allow use of an atom-style variable.
.. versionchanged:: 28Mar2023
Keyword *mol* sets the molecule ID for all selected atoms. The
:doc:`atom style <atom_style>` being used must support the use of
molecule IDs.
Support for type labels was added for setting bond types
Keywords *x*, *y*, *z*, and *charge* set the coordinates or
charge of all selected atoms. For *charge*, the :doc:`atom style
<atom_style>` being used must support the use of atomic
charge. Keywords *vx*, *vy*, and *vz* set the velocities of all
selected atoms.
Keyword *bond* sets the bond type of all bonds of selected atoms to
the specified value. The value can be a numeric type from 1 to
nbondtypes. Or it can be a bond type label. See the :doc:`Howto type
labels <Howto_type_labels>` doc page for the allowed syntax of type
labels and a general discussion of how type labels can be used. All
atoms in a particular bond must be selected atoms in order for the
change to be made. The value of nbondtypes was set by the *bond
types* field in the header of the data file read by the
:doc:`read_data <read_data>` command. This keyword does NOT allow use
of an atom-style variable.
Keyword *cc* sets the chemical concentration of a tDPD particle for a
specified species as defined by the DPD-MESO package. Currently, only
:doc:`atom_style tdpd <atom_style>` defines particles with this
attribute. An integer for "index" selects a chemical species (1 to
Nspecies) where Nspecies is set by the atom_style command. The value
for the chemical concentration must be >= 0.0.
Keyword *charge* set the charge of all selected atoms. The :doc:`atom
style <atom_style>` being used must support the use of atomic charge.
Keyword *density* or *density/disc* also sets the mass of all selected
particles, but in a different way. The particles must have a per-atom
mass attribute, as defined by the :doc:`atom_style <atom_style>`
command. If the atom has a radius attribute (see :doc:`atom_style
sphere <atom_style>`) and its radius is non-zero, its mass is set from
the density and particle volume for 3d systems (the input density is
assumed to be in mass/distance\^3 units). For 2d, the default is for
LAMMPS to model particles with a radius attribute as spheres.
However, if the *density/disc* keyword is used, then they can be
modeled as 2d discs (circles). Their mass is set from the density and
particle area (the input density is assumed to be in mass/distance\^2
units).
If the atom has a shape attribute (see :doc:`atom_style ellipsoid
<atom_style>`) and its 3 shape parameters are non-zero, then its mass
is set from the density and particle volume (the input density is
assumed to be in mass/distance\^3 units). The *density/disc* keyword
has no effect; it does not (yet) treat 3d ellipsoids as 2d ellipses.
If the atom has a length attribute (see :doc:`atom_style line
<atom_style>`) and its length is non-zero, then its mass is set from
the density and line segment length (the input density is assumed to
be in mass/distance units). If the atom has an area attribute (see
:doc:`atom_style tri <atom_style>`) and its area is non-zero, then its
mass is set from the density and triangle area (the input density is
assumed to be in mass/distance\^2 units).
If none of these cases are valid, then the mass is set to the density
value directly (the input density is assumed to be in mass units).
Keyword *diameter* sets the size of the selected atoms. The particles
must be finite-size spheres as defined by the :doc:`atom_style sphere
<atom_style>` command. The diameter of a particle can be set to 0.0,
which means they will be treated as point particles. Note that this
command does not adjust the particle mass, even if it was defined with
a density, e.g. via the :doc:`read_data <read_data>` command.
.. versionchanged:: 28Mar2023
Support for type labels was added for setting dihedral types
Keyword *dihedral* sets the dihedral type of all dihedrals of selected
atoms to the specified value. The value can be a numeric type from 1
to ndihedraltypes. Or it can be a dihedral type label. See the
:doc:`Howto type labels <Howto_type_labels>` doc page for the allowed
syntax of type labels and a general discussion of how type labels can
be used. All atoms in a particular dihedral must be selected atoms in
order for the change to be made. The value of ndihedraltypes was set
by the *dihedral types* field in the header of the data file read by
the :doc:`read_data <read_data>` command. This keyword does NOT allow
use of an atom-style variable.
Keyword *dipole* uses the specified x,y,z values as components of a
vector to set as the orientation of the dipole moment vectors of the
@ -317,40 +386,106 @@ moment vectors for the selected atoms and sets the magnitude of each
to the specified *Dlen* value. For 2d systems, the z component of the
orientation is set to 0.0. Random numbers are used in such a way that
the orientation of a particular atom is the same, regardless of how
many processors are being used. This keyword does not allow use of an
many processors are being used. This keyword does NOT allow use of an
atom-style variable.
.. versionchanged:: 15Sep2022
Keyword *dpd/theta* sets the internal temperature of a DPD particle as
defined by the DPD-REACT package. If the specified value is a number
it must be >= 0.0. If the specified value is NULL, then the kinetic
temperature Tkin of each particle is computed as 3/2 k Tkin = KE = 1/2
m v\^2 = 1/2 m (vx\*vx+vy\*vy+vz\*vz). Each particle's internal
temperature is set to Tkin. If the specified value is an atom-style
variable, then the variable is evaluated for each particle. If a
value >= 0.0, the internal temperature is set to that value. If it is
< 0.0, the computation of Tkin is performed and the internal
temperature is set to that value.
Keyword *spin/atom* uses the specified g value to set the magnitude of the
magnetic spin vectors, and the x,y,z values as components of a vector
to set as the orientation of the magnetic spin vectors of the selected
atoms. This keyword was previously called *spin*.
Keywords *edpd/temp* and *edpd/cv* set the temperature and volumetric
heat capacity of an eDPD particle as defined by the DPD-MESO package.
Currently, only :doc:`atom_style edpd <atom_style>` defines particles
with these attributes. The values for the temperature and heat
capacity must be positive.
.. versionchanged:: 15Sep2022
Keyword *epsilon* sets the dielectric constant of a particle to be
that of the medium where the particle resides as defined by the
DIELECTRIC package. Currently, only :doc:`atom_style dielectric
<atom_style>` defines particles with this attribute. The value for the
dielectric constant must be >= 0.0. Note that the set command with
this keyword will rescale the particle charge accordingly so that the
real charge (e.g., as read from a data file) stays intact. To change
the real charges, one needs to use the set command with the *charge*
keyword. Care must be taken to ensure that the real and scaled charges
and the dielectric constants are consistent.
Keyword *spin/atom/random* randomizes the orientation of the magnetic spin
vectors for the selected atoms and sets the magnitude of each to the
specified *Dlen* value. This keyword was previously called *spin/random*.
Keyword *image* sets which image of the simulation box the atom is
considered to be in. An image of 0 means it is inside the box as
defined. A value of 2 means add 2 box lengths to get the true value.
A value of -1 means subtract 1 box length to get the true value.
LAMMPS updates these flags as atoms cross periodic boundaries during
the simulation. The flags can be output with atom snapshots via the
:doc:`dump <dump>` command. If a value of NULL is specified for any
of nx,ny,nz, then the current image value for that dimension is
unchanged. For non-periodic dimensions only a value of 0 can be
specified. This command can be useful after a system has been
equilibrated and atoms have diffused one or more box lengths in
various directions. This command can then reset the image values for
atoms so that they are effectively inside the simulation box, e.g if a
diffusion coefficient is about to be measured via the :doc:`compute
msd <compute_msd>` command. Care should be taken not to reset the
image flags of two atoms in a bond to the same value if the bond
straddles a periodic boundary (rather they should be different by +/-
1). This will not affect the dynamics of a simulation, but may mess
up analysis of the trajectories if a LAMMPS diagnostic or your own
analysis relies on the image flags to unwrap a molecule which
straddles the periodic box.
.. versionadded:: 15Sep2022
.. versionchanged:: 28Mar2023
Keyword *radius/electron* uses the specified value to set the radius of
electrons or fixed cores.
Support for type labels was added for setting improper types
.. versionadded:: 15Sep2022
Keyword *improper* sets the improper type of all impropers of selected
atoms to the specified value. The value can be a numeric type from 1
to nimpropertypes. Or it can be a improper type label. See the
:doc:`Howto type labels <Howto_type_labels>` doc page for the allowed
syntax of type labels and a general discussion of how type labels can
be used. All atoms in a particular improper must be selected atoms in
order for the change to be made. The value of nimpropertypes was set
by the *improper types* field in the header of the data file read by
the :doc:`read_data <read_data>` command. This keyword does NOT allow
use of an atom-style variable.
Keyword *spin/electron* sets the spin of an electron (+/- 1) or indicates
nuclei (=0), fixed-cores (=2), or pseudo-cores (= 3).
Keyword *length* sets the length of selected atoms. The particles
must be line segments as defined by the :doc:`atom_style line
<atom_style>` command. If the specified value is non-zero the line
segment is (re)set to a length = the specified value, centered around
the particle position, with an orientation along the x-axis. If the
specified value is 0.0, the particle will become a point particle.
Note that this command does not adjust the particle mass, even if it
was defined with a density, e.g. via the :doc:`read_data <read_data>`
command.
Keyword *mass* sets the mass of all selected particles. The particles
must have a per-atom mass attribute, as defined by the
:doc:`atom_style <atom_style>` command. See the "mass" command for
how to set mass values on a per-type basis.
Keyword *mol* sets the molecule ID for all selected atoms. The
:doc:`atom style <atom_style>` being used must support the use of
molecule IDs.
Keyword *omega* sets the angular velocity of selected atoms. The
particles must be spheres as defined by the :doc:`atom_style sphere
<atom_style>` command. The angular velocity vector of the particles
is set to the 3 specified components.
Keyword *quat* uses the specified values to create a quaternion
(4-vector) that represents the orientation of the selected atoms. The
particles must define a quaternion for their orientation
(e.g. ellipsoids, triangles, body particles) as defined by the
:doc:`atom_style <atom_style>` command. Note that particles defined by
:doc:`atom_style ellipsoid <atom_style>` have 3 shape parameters. The 3
values must be non-zero for each particle set by this command. They
are used to specify the aspect ratios of an ellipsoidal particle,
:doc:`atom_style <atom_style>` command. Note that particles defined
by :doc:`atom_style ellipsoid <atom_style>` have 3 shape parameters.
The 3 values must be non-zero for each particle set by this command.
They are used to specify the aspect ratios of an ellipsoidal particle,
which is oriented by default with its x-axis along the simulation
box's x-axis, and similarly for y and z. If this body is rotated (via
the right-hand rule) by an angle theta around a unit rotation vector
@ -364,51 +499,77 @@ ignored, since a rotation vector of (0,0,1) is the only valid choice.
Keyword *quat/random* randomizes the orientation of the quaternion for
the selected atoms. The particles must define a quaternion for their
orientation (e.g. ellipsoids, triangles, body particles) as defined by
the :doc:`atom_style <atom_style>` command. Random numbers are used in
such a way that the orientation of a particular atom is the same,
the :doc:`atom_style <atom_style>` command. Random numbers are used
in such a way that the orientation of a particular atom is the same,
regardless of how many processors are being used. For 2d systems,
only orientations in the xy plane are generated. As with keyword
*quat*, for ellipsoidal particles, the 3 shape values must be non-zero
for each particle set by this command. This keyword does not allow
for each particle set by this command. This keyword does NOT allow
use of an atom-style variable.
Keyword *diameter* sets the size of the selected atoms. The particles
must be finite-size spheres as defined by the :doc:`atom_style sphere
<atom_style>` command. The diameter of a particle can be set to 0.0,
which means they will be treated as point particles. Note that this
command does not adjust the particle mass, even if it was defined with
a density, e.g. via the :doc:`read_data <read_data>` command.
.. versionadded:: 15Sep2022
Keyword *radius/electron* uses the specified value to set the radius
of electrons or fixed cores.
Keyword *shape* sets the size and shape of the selected atoms. The
particles must be ellipsoids as defined by the :doc:`atom_style
ellipsoid <atom_style>` command. The *Sx*, *Sy*, *Sz* settings
are the 3 diameters of the ellipsoid in each direction. All 3 can be
set to the same value, which means the ellipsoid is effectively a
sphere. They can also all be set to 0.0 which means the particle will
be treated as a point particle. Note that this command does not
adjust the particle mass, even if it was defined with a density,
e.g. via the :doc:`read_data <read_data>` command.
ellipsoid <atom_style>` command. The *Sx*, *Sy*, *Sz* settings are
the 3 diameters of the ellipsoid in each direction. All 3 can be set
to the same value, which means the ellipsoid is effectively a sphere.
They can also all be set to 0.0 which means the particle will be
treated as a point particle. Note that this command does not adjust
the particle mass, even if it was defined with a density, e.g. via the
:doc:`read_data <read_data>` command.
Keyword *length* sets the length of selected atoms. The particles
must be line segments as defined by the :doc:`atom_style line
<atom_style>` command. If the specified value is non-zero the line
segment is (re)set to a length = the specified value, centered around
the particle position, with an orientation along the x-axis. If the
specified value is 0.0, the particle will become a point particle.
Note that this command does not adjust the particle mass, even if it
was defined with a density, e.g. via the :doc:`read_data <read_data>`
command.
Keyword *smd/contact/radius* only applies to simulations with the
Smooth Mach Dynamics package MACHDYN. Itsets an interaction radius
for computing short-range interactions, e.g. repulsive forces to
prevent different individual physical bodies from penetrating each
other. Note that the SPH smoothing kernel diameter used for computing
long range, nonlocal interactions, is set using the *diameter*
keyword.
Keyword *tri* sets the size of selected atoms. The particles must be
triangles as defined by the :doc:`atom_style tri <atom_style>` command.
If the specified value is non-zero the triangle is (re)set to be an
equilateral triangle in the xy plane with side length = the specified
value, with a centroid at the particle position, with its base
parallel to the x axis, and the y-axis running from the center of the
base to the top point of the triangle. If the specified value is 0.0,
the particle will become a point particle. Note that this command
does not adjust the particle mass, even if it was defined with a
density, e.g. via the :doc:`read_data <read_data>` command.
Keyword *smd/mass/density* sets the mass of all selected particles,
but it is only applicable to the Smooth Mach Dynamics package MACHDYN.
It assumes that the particle volume has already been correctly set and
calculates particle mass from the provided mass density value.
Keywords *sph/cv*, *sph/e*, and *sph/rho* set the heat capacity,
energy, and density of smoothed particle hydrodynamics (SPH)
particles. See `this PDF guide <PDF/SPH_LAMMPS_userguide.pdf>`_ to
using SPH in LAMMPS.
.. note::
Note that the SPH PDF guide file has not been updated for many
years and thus does not reflect the current *syntax* of the SPH
package commands. For that, please refer to the LAMMPS manual.
.. versionchanged:: 15Sep2022
Keyword *spin/atom* uses the specified g value to set the magnitude of
the magnetic spin vectors, and the x,y,z values as components of a
vector to set as the orientation of the magnetic spin vectors of the
selected atoms. This keyword was previously called *spin*.
.. versionchanged:: 15Sep2022
Keyword *spin/atom/random* randomizes the orientation of the magnetic
spin vectors for the selected atoms and sets the magnitude of each to
the specified *Dlen* value. This keyword does NOT allow use of an
atom-style variable. This keyword was previously called
*spin/random*.
.. versionadded:: 15Sep2022
Keyword *spin/electron* sets the spin of an electron (+/- 1) or
indicates nuclei (=0), fixed-cores (=2), or pseudo-cores (= 3).
Keyword *temperature* sets the temperature of a finite-size particle.
Currently, only the GRANULAR package supports this attribute. The
temperature must be added using an instance of :doc:`fix property/atom
<fix_property_atom>` The values for the temperature must be positive.
Keyword *theta* sets the orientation of selected atoms. The particles
must be line segments as defined by the :doc:`atom_style line
@ -417,163 +578,65 @@ orientation angle of the line segments with respect to the x axis.
Keyword *theta/random* randomizes the orientation of theta for the
selected atoms. The particles must be line segments as defined by the
:doc:`atom_style line <atom_style>` command. Random numbers are used in
such a way that the orientation of a particular atom is the same,
:doc:`atom_style line <atom_style>` command. Random numbers are used
in such a way that the orientation of a particular atom is the same,
regardless of how many processors are being used. This keyword does
not allow use of an atom-style variable.
NOT allow use of an atom-style variable.
Keyword *angmom* sets the angular momentum of selected atoms. The
particles must be ellipsoids as defined by the :doc:`atom_style
ellipsoid <atom_style>` command or triangles as defined by the
:doc:`atom_style tri <atom_style>` command. The angular momentum
vector of the particles is set to the 3 specified components.
Keyword *tri* sets the size of selected atoms. The particles must be
triangles as defined by the :doc:`atom_style tri <atom_style>`
command. If the specified value is non-zero the triangle is (re)set
to be an equilateral triangle in the xy plane with side length = the
specified value, with a centroid at the particle position, with its
base parallel to the x axis, and the y-axis running from the center of
the base to the top point of the triangle. If the specified value is
0.0, the particle will become a point particle. Note that this
command does not adjust the particle mass, even if it was defined with
a density, e.g. via the :doc:`read_data <read_data>` command.
Keyword *omega* sets the angular velocity of selected atoms. The
particles must be spheres as defined by the :doc:`atom_style sphere
<atom_style>` command. The angular velocity vector of the particles is
set to the 3 specified components.
.. versionchanged:: 28Mar2023
Keyword *mass* sets the mass of all selected particles. The particles
must have a per-atom mass attribute, as defined by the :doc:`atom_style
<atom_style>` command. See the "mass" command for how to set mass
values on a per-type basis.
Support for type labels was added for setting atom types
Keyword *density* or *density/disc* also sets the mass of all selected
particles, but in a different way. The particles must have a per-atom
mass attribute, as defined by the :doc:`atom_style <atom_style>`
command. If the atom has a radius attribute (see :doc:`atom_style
sphere <atom_style>`) and its radius is non-zero, its mass is set from
the density and particle volume for 3d systems (the input density is
assumed to be in mass/distance\^3 units). For 2d, the default is for
LAMMPS to model particles with a radius attribute as spheres. However,
if the *density/disc* keyword is used, then they can be modeled as 2d
discs (circles). Their mass is set from the density and particle area
(the input density is assumed to be in mass/distance\^2 units).
If the atom has a shape attribute (see :doc:`atom_style ellipsoid
<atom_style>`) and its 3 shape parameters are non-zero, then its mass is
set from the density and particle volume (the input density is assumed
to be in mass/distance\^3 units). The *density/disc* keyword has no
effect; it does not (yet) treat 3d ellipsoids as 2d ellipses.
If the atom has a length attribute (see :doc:`atom_style line
<atom_style>`) and its length is non-zero, then its mass is set from the
density and line segment length (the input density is assumed to be in
mass/distance units). If the atom has an area attribute (see
:doc:`atom_style tri <atom_style>`) and its area is non-zero, then its
mass is set from the density and triangle area (the input density is
assumed to be in mass/distance\^2 units).
If none of these cases are valid, then the mass is set to the density
value directly (the input density is assumed to be in mass units).
Keyword *temperature* sets the temperature of a finite-size particle.
Currently, only the GRANULAR package supports this attribute. The
temperature must be added using an instance of
:doc:`fix property/atom <fix_property_atom>` The values for the
temperature must be positive.
Keyword *volume* sets the volume of all selected particles. Currently,
only the :doc:`atom_style peri <atom_style>` command defines particles
with a volume attribute. Note that this command does not adjust the
particle mass.
Keyword *image* sets which image of the simulation box the atom is
considered to be in. An image of 0 means it is inside the box as
defined. A value of 2 means add 2 box lengths to get the true value. A
value of -1 means subtract 1 box length to get the true value. LAMMPS
updates these flags as atoms cross periodic boundaries during the
simulation. The flags can be output with atom snapshots via the
:doc:`dump <dump>` command. If a value of NULL is specified for any of
nx,ny,nz, then the current image value for that dimension is unchanged.
For non-periodic dimensions only a value of 0 can be specified. This
command can be useful after a system has been equilibrated and atoms
have diffused one or more box lengths in various directions. This
command can then reset the image values for atoms so that they are
effectively inside the simulation box, e.g if a diffusion coefficient is
about to be measured via the :doc:`compute msd <compute_msd>` command.
Care should be taken not to reset the image flags of two atoms in a bond
to the same value if the bond straddles a periodic boundary (rather they
should be different by +/- 1). This will not affect the dynamics of a
simulation, but may mess up analysis of the trajectories if a LAMMPS
diagnostic or your own analysis relies on the image flags to unwrap a
molecule which straddles the periodic box.
Keywords *bond*, *angle*, *dihedral*, and *improper*, set the bond
type (angle type, etc) of all bonds (angles, etc) of selected atoms to
the specified value. The value can be a numeric type from 1 to
nbondtypes (nangletypes, etc). Or it can be a type label (bond type
label, angle type label, etc). See the :doc:`Howto type labels
Keyword *type* sets the atom type for all selected atoms. A specified
value can be either a numeric atom type or an atom type label. When
using a numeric type, the specified value must be from 1 to ntypes,
where ntypes was set by the :doc:`create_box <create_box>` command or
the *atom types* field in the header of the data file read by the
:doc:`read_data <read_data>` command. When using a type label it must
have been defined previously. See the :doc:`Howto type labels
<Howto_type_labels>` doc page for the allowed syntax of type labels
and a general discussion of how type labels can be used. All atoms in
a particular bond (angle, etc) must be selected atoms in order for the
change to be made. The value of nbondtypes (nangletypes, etc) was set
by the *bond types* (\ *angle types*, etc) field in the header of the
data file read by the :doc:`read_data <read_data>` command. These
keywords do not allow use of an atom-style variable.
and a general discussion of how type labels can be used.
Keywords *rheo/rho* and *rheo/status* set the density and the status of
rheo particles. In particular, one can only set the phase in the status
as described by the :doc:`RHEO howto page <Howto_rheo>`.
Keyword *type/fraction* sets the atom type for a fraction of the
selected atoms. The actual number of atoms changed is not guaranteed
to be exactly the specified fraction (0 <= *fraction* <= 1), but
should be statistically close. Random numbers are used in such a way
that a particular atom is changed or not changed, regardless of how
many processors are being used. This keyword does NOT allow use of an
atom-style variable.
Keywords *sph/e*, *sph/cv*, and *sph/rho* set the energy, heat capacity,
and density of smoothed particle hydrodynamics (SPH) particles. See
`this PDF guide <PDF/SPH_LAMMPS_userguide.pdf>`_ to using SPH in LAMMPS.
Keywords *type/ratio* and *type/subset* also set the atom type for a
fraction of the selected atoms. The actual number of atoms changed
will be exactly the requested number. For *type/ratio* the specified
fraction (0 <= *fraction* <= 1) determines the number. For
*type/subset*, the specified *Nsubset* is the number. An iterative
algorithm is used which ensures the correct number of atoms are
selected, in a perfectly random fashion. Which atoms are selected
will change with the number of processors used. These keywords do not
allow use of an atom-style variable.
.. note::
Keyword *volume* sets the volume of all selected particles.
Currently, only the :doc:`atom_style peri <atom_style>` command
defines particles with a volume attribute. Note that this command
does not adjust the particle mass.
Please note that the SPH PDF guide file has not been updated for
many years and thus does not reflect the current *syntax* of the
SPH package commands. For that please refer to the LAMMPS manual.
Keywords *vx*, *vy*, and *vz* set the velocities of all selected
atoms.
Keyword *smd/mass/density* sets the mass of all selected particles, but
it is only applicable to the Smooth Mach Dynamics package MACHDYN. It
assumes that the particle volume has already been correctly set and
calculates particle mass from the provided mass density value.
Keywords *x*, *y*, *z* set the coordinates of all selected atoms.
Keyword *smd/contact/radius* only applies to simulations with the Smooth
Mach Dynamics package MACHDYN. Itsets an interaction radius for
computing short-range interactions, e.g. repulsive forces to prevent
different individual physical bodies from penetrating each other. Note
that the SPH smoothing kernel diameter used for computing long range,
nonlocal interactions, is set using the *diameter* keyword.
Keyword *dpd/theta* sets the internal temperature of a DPD particle as
defined by the DPD-REACT package. If the specified value is a number it
must be >= 0.0. If the specified value is NULL, then the kinetic
temperature Tkin of each particle is computed as 3/2 k Tkin = KE = 1/2 m
v\^2 = 1/2 m (vx\*vx+vy\*vy+vz\*vz). Each particle's internal
temperature is set to Tkin. If the specified value is an atom-style
variable, then the variable is evaluated for each particle. If a value
>= 0.0, the internal temperature is set to that value. If it is < 0.0,
the computation of Tkin is performed and the internal temperature is set
to that value.
Keywords *edpd/temp* and *edpd/cv* set the temperature and volumetric
heat capacity of an eDPD particle as defined by the DPD-MESO package.
Currently, only :doc:`atom_style edpd <atom_style>` defines particles
with these attributes. The values for the temperature and heat capacity
must be positive.
Keyword *cc* sets the chemical concentration of a tDPD particle for a
specified species as defined by the DPD-MESO package. Currently, only
:doc:`atom_style tdpd <atom_style>` defines particles with this
attribute. An integer for "index" selects a chemical species (1 to
Nspecies) where Nspecies is set by the atom_style command. The value for
the chemical concentration must be >= 0.0.
Keyword *epsilon* sets the dielectric constant of a particle, precisely
of the medium where the particle resides as defined by the DIELECTRIC
package. Currently, only :doc:`atom_style dielectric <atom_style>`
defines particles with this attribute. The value for the dielectric
constant must be >= 0.0. Note that the set command with this keyword
will rescale the particle charge accordingly so that the real charge
(e.g., as read from a data file) stays intact. To change the real
charges, one needs to use the set command with the *charge*
keyword. Care must be taken to ensure that the real and scaled charges,
and dielectric constants are consistent.
Keyword *apip_lambda* sets the switching parameter of an
Keyword *apip/lambda* sets the switching parameter of an
adaptive-precision interatomic potential (:doc:`APIP <Howto_apip>`).
The precise potential is used for an atom when its switching parameter
:math:`\lambda` is 0. The fast potential is used for an atom when its
@ -585,8 +648,8 @@ per-atom integer and floating-point vectors or arrays that have been
added via the :doc:`fix property/atom <fix_property_atom>` command.
When that command is used specific names are given to each attribute
which are the "name" portion of these keywords. For arrays *i2_name*
and *d2_name*, the column of the array must also be included following
the name in brackets: e.g. d2_xyz[2], i2_mySpin[3].
and *d2_name*, the column of the array to set must also be included
following the name in brackets: e.g. d2_xyz[2] or i2_mySpin[3].
Restrictions
""""""""""""
@ -595,7 +658,7 @@ You cannot set an atom attribute (e.g. *mol* or *q* or *volume*\ ) if
the :doc:`atom_style <atom_style>` does not have that attribute.
This command requires inter-processor communication to coordinate the
setting of bond types (angle types, etc). This means that your system
setting of bond types (angle types, etc). This means that the system
must be ready to perform a simulation before using one of these
keywords (force fields set, atom mass set, etc). This is not
necessary for other keywords.
@ -610,7 +673,7 @@ Related commands
""""""""""""""""
:doc:`create_box <create_box>`, :doc:`create_atoms <create_atoms>`,
:doc:`read_data <read_data>`
:doc:`read_data <read_data>`, :doc:`fix set <fix_set>`
Default
"""""""

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

@ -82,6 +82,7 @@ Alessandro
Alexey
ali
aliceblue
aliphatic
Allera
Allinger
allocatable
@ -103,6 +104,7 @@ Amit
amsmath
amu
Amzallag
Anandakrishnan
analytical
Anders
Andric
@ -110,6 +112,7 @@ Andrienko
Andzelm
Ang
anglegrad
anglelist
angleoffset
angletangrad
angmom
@ -349,6 +352,7 @@ Bomont
BondAngle
BondBond
bondchk
bondlist
bondmax
bondscreened
bondscreenedspin
@ -391,11 +395,13 @@ Bretonnet
Briels
Brien
Brilliantov
Brizi
Broadwell
Broglie
brownian
brownw
Broyden
Bruenger
Bruskin
Brusselle
Bryantsev
@ -433,10 +439,12 @@ Camiloni
Campana
Cangi
Cao
Cappelletti
Capolungo
Caro
cartesian
Cas
Casavecchia
CasP
Caswell
Cates
@ -625,6 +633,7 @@ cp
cpp
cpu
cradius
Cramer
createatoms
createAtoms
CreateIDs
@ -666,6 +675,7 @@ cuFFT
CuH
Cui
Cummins
cumulants
Cundall
cundall
Curk
@ -819,6 +829,7 @@ diffusively
diffusivities
diffusivity
dihedral
dihedrallist
dihedrals
Dihedrals
dihydride
@ -1169,6 +1180,7 @@ Fermionic
Ferrand
fexternal
Fexternal
ffast
ffield
ffl
fflush
@ -1197,6 +1209,7 @@ filesystem
filesystems
Fily
Fincham
Finkelstein
Fint
fingerprintconstants
fingerprintsperelement
@ -1323,7 +1336,6 @@ Geocomputing
georg
Georg
Geotechnica
Gergs
germain
Germann
Germano
@ -1351,6 +1363,8 @@ Gillan
Gingold
Gissinger
github
Giusti
GJ
gjf
gjwagne
gl
@ -1611,6 +1625,7 @@ imd
Immel
Impey
impl
improperlist
impropers
Impropers
imulator
@ -1727,6 +1742,7 @@ Iyz
iz
izcm
ized
Izadi
Izrailev
Izumi
Izvekov
@ -1763,6 +1779,7 @@ jik
JIK
jku
jN
Joanes
Joannopoulos
Jochim
Jonsson
@ -1807,6 +1824,7 @@ Karniadakis
Karplus
Karttunen
kate
katom
Katsnelson
Katsura
Kaufmann
@ -1855,6 +1873,7 @@ Kloss
Kloza
kmax
Kmax
kMC
KMP
kmu
Knizhnik
@ -1919,6 +1938,7 @@ Lachet
Lackmann
Ladd
lagrangian
Lalli
lambdai
LambdaLanczos
Lambrecht
@ -1981,6 +2001,7 @@ lennard
Lennard
Lenosky
Lenz
Leoni
Lett
Leuven
Leven
@ -2182,6 +2203,7 @@ Materias
mathbf
mathjax
matlab
Matom
Matous
matplotlib
Matsubara
@ -2479,6 +2501,7 @@ namespaces
nan
NaN
Nandor
nanglelist
nangles
Nangletype
nangletypes
@ -2515,6 +2538,7 @@ nbodies
nbody
Nbody
nbond
nbondlist
nbonds
nbondtype
Nbondtype
@ -2536,6 +2560,7 @@ ncount
nd
ndactrung
ndescriptors
ndihedrallist
ndihedrals
Ndihedraltype
ndihedraltypes
@ -2593,6 +2618,7 @@ NiAlH
Nicklas
Niklasson
Nikolskiy
nimproperlist
nimpropers
Nimpropertype
nimpropertypes
@ -2687,6 +2713,7 @@ Nprocs
npt
nr
Nr
Nrecent
Nrecompute
Nrepeat
nreset
@ -2765,6 +2792,7 @@ ocl
octahedral
octants
Odegard
Og
Ohara
O'Hearn
ohenrich
@ -2797,6 +2825,7 @@ oneMKL
oneway
onlysalt
ons
Onufriev
OO
Oord
opencl
@ -2927,6 +2956,7 @@ perp
Perram
persp
Persp
perturbative
peru
Peskin
Pettifor
@ -2965,6 +2995,8 @@ pimdb
Piola
pIp
pipelining
Pirani
pirani
Pisarev
Pishevar
Pitera
@ -3342,6 +3374,7 @@ Rmin
RMS
rmsd
rnage
rnflag
rng
rNEMD
ro
@ -3351,6 +3384,7 @@ Rockett
rocksalt
Rodrigues
Rohart
Roncaratti
Ronchetti
Ronevich
Rosati
@ -3396,6 +3430,7 @@ ry
Ryckaert
Rycroft
Rydbergs
Ryzen
rz
Rz
Sabry
@ -3461,6 +3496,7 @@ sectoring
sed
Seddon
segmental
Seibold
Seifert
Seleson
sellerio
@ -3815,6 +3851,7 @@ Thibaudeau
Thijsse
Thirumalai
thr
Threadripper
threebody
thrid
ThunderX
@ -4064,6 +4101,7 @@ vdW
vdwl
vec
Vecchio
Vecchiocattivi
vectorial
vectorization
Vectorization
@ -4080,9 +4118,11 @@ versa
Verstraelen
ves
vf
vfull
vflag
vflow
vfrac
vhalf
vhi
vibrational
Vij
@ -4114,6 +4154,7 @@ volpress
volumetric
von
Voro
voro
Vorobyov
voronoi
Voronoi

5
examples/COUPLE/plugin/CMakeLists.txt
View File

@ -27,10 +27,7 @@ if(MSVC)
add_compile_definitions(_CRT_SECURE_NO_WARNINGS)
endif()
find_package(MPI REQUIRED)
# do not include the (obsolete) MPI C++ bindings which makes
# for leaner object files and avoids namespace conflicts
set(MPI_CXX_SKIP_MPICXX TRUE)
find_package(MPI REQUIRED COMPONENTS C)
##########################

1
examples/COUPLE/plugin/liblammpsplugin.c
View File

@ -144,6 +144,7 @@ liblammpsplugin_t *liblammpsplugin_load(const char *lib)
ADDSYM(find_pair_neighlist);
ADDSYM(find_fix_neighlist);
ADDSYM(find_compute_neighlist);
ADDSYM(request_single_neighlist);
ADDSYM(neighlist_num_elements);
ADDSYM(neighlist_element_neighbors);

18
examples/COUPLE/plugin/liblammpsplugin.h
View File

@ -94,6 +94,17 @@ enum _LMP_VAR_CONST {
LMP_VAR_STRING = 3 /*!< return value will be a string (catch-all) */
};
/** Neighbor list settings constants
*
* Must be kept in sync with the equivalent constants in ``python/lammps/constants.py``,
* ``fortran/lammps.f90``, ``tools/swig/lammps.i``, and
* ``examples/COUPLE/plugin/liblammpsplugin.h`` */
enum _LMP_NEIGH_CONST {
LMP_NEIGH_HALF = 0, /*!< request (default) half neighbor list */
LMP_NEIGH_FULL = 1, /*!< request full neighbor list */
};
#ifdef __cplusplus
extern "C" {
#endif
@ -189,14 +200,17 @@ struct _liblammpsplugin {
* caller must match to how LAMMPS library is built */
#if !defined(LAMMPS_BIGBIG)
int (*create_atoms)(void *, int, int *, int *, double *, double *, int *, int);
int (*create_atoms)(void *, int, const int *, const int *, const double *, const double *,
const int *, int);
#else
int (*create_atoms)(void *, int, int64_t *, int *, double *, double *, int64_t *, int);
int (*create_atoms)(void *, int, const int64_t *, const int *, const double *, const double *,
const int64_t *, int);
#endif
int (*find_pair_neighlist)(void *, const char *, int, int, int);
int (*find_fix_neighlist)(void *, const char *, int);
int (*find_compute_neighlist)(void *, const char *, int);
int (*request_single_neighlist)(void *, const char *, int, double);
int (*neighlist_num_elements)(void *, int);
void (*neighlist_element_neighbors)(void *, int, int, int *, int *, int **);

2
examples/COUPLE/simple/CMakeLists.txt
View File

@ -25,10 +25,10 @@ if(MSVC)
add_compile_definitions(_CRT_SECURE_NO_WARNINGS)
endif()
find_package(MPI QUIET)
# do not include the (obsolete) MPI C++ bindings which makes
# for leaner object files and avoids namespace conflicts
set(MPI_CXX_SKIP_MPICXX TRUE)
find_package(MPI QUIET COMPONENTS C CXX)
##########################

6
examples/PACKAGES/apip/in.vacancy.const.lambda
View File

@ -20,9 +20,9 @@ read_data data.vacancy
group vacancy id 145 147 148 149 150 994 997 995 1024 1026 1028 1922
group transition id 77 79 81 84 88 151 152 153 154 155 158 1089 188 189 192 1033 1039 1964 1022 1021 999 998 996 948 950 952 992 993 139 1025 1027 1029 1034 1035 1038 1088 1920 1921 1923 1924 1925 1930
group bulk subtract all vacancy transition
set group vacancy apip_lambda precise
set group transition apip_lambda 0.5
set group bulk apip_lambda fast
set group vacancy apip/lambda precise
set group transition apip/lambda 0.5
set group bulk apip/lambda fast
fix nve all nve

4
examples/PACKAGES/apip/in.validate
View File

@ -38,11 +38,11 @@ pair_coeff * * eam/fs/apip ${eamfs_file} Cu
pair_coeff * * pace/apip ${ace_file} Cu
# use ACE of adaptive-precision potential
set group all apip_lambda precise
set group all apip/lambda precise
run 0
# use EAM of adaptive-precision potential
set group all apip_lambda fast
set group all apip/lambda fast
run 0
# Use EAM potential

4
examples/PACKAGES/imd/in.bucky-plus-cnt
View File

@ -46,8 +46,8 @@ fix integrate mobile nve
fix thermostat mobile langevin 300.0 300.0 2000.0 234624
# IMD setup.
fix comm all imd 6789 unwrap on trate 10
#fix comm all imd 6789 unwrap on trate 10 nowait on
#fix comm all imd 6789 unwrap on trate 10
fix comm all imd 6789 unwrap on trate 10 nowait on
# temperature is based on mobile atoms only
compute mobtemp mobile temp

15
examples/PACKAGES/imd/in.bucky-plus-cnt-gpu
View File

@ -1,16 +1,20 @@
# stick a buckyball into a nanotube
# enable GPU package from within the input:
package gpu 0 pair/only on
suffix gpu
units real
dimension 3
boundary f f f
atom_style molecular
newton off
processors * * 1
# read topology
read_data data.bucky-plus-cnt
pair_style lj/cut/gpu 10.0
pair_style lj/cut 10.0
bond_style harmonic
angle_style charmm
dihedral_style charmm
@ -29,9 +33,6 @@ neigh_modify delay 0 every 1 check yes
timestep 2.0
# required for GPU acceleration
fix gpu all gpu force 0 0 1.0
# we only move some atoms.
group mobile type 1
@ -49,8 +50,8 @@ fix integrate mobile nve
fix thermostat mobile langevin 300.0 300.0 2000.0 234624
# IMD setup.
fix comm all imd 6789 unwrap on trate 10
#fix comm all imd 6789 unwrap on trate 10 nowait on
#fix comm all imd 6789 unwrap on trate 10
fix comm all imd 6789 unwrap on trate 10 nowait on
# temperature is based on mobile atoms only
compute mobtemp mobile temp

14
examples/PACKAGES/imd/in.deca-ala_imd-gpu
View File

@ -1,8 +1,12 @@
#
#
# enable GPU package from within the input:
package gpu 0 pair/only on
suffix gpu
units real
neighbor 2.5 bin
neigh_modify delay 1 every 1
newton off
atom_style full
bond_style harmonic
@ -10,20 +14,18 @@ angle_style charmm
dihedral_style charmm
improper_style harmonic
pair_style lj/charmm/coul/long/gpu 8 10
pair_style lj/charmm/coul/long 8 10
pair_modify mix arithmetic
special_bonds charmm
read_data data.deca-ala-solv
fix 0 all gpu force/neigh 0 0 1.0
group peptide id <= 103
fix rigidh all shake 1e-6 100 1000 t 1 2 3 4 5 a 23
thermo 100
thermo_style multi
timestep 2.0
kspace_style pppm/gpu 1e-5
kspace_style pppm 1e-5
fix ensemble all npt temp 300.0 300.0 100.0 iso 1.0 1.0 1000.0 drag 0.2

38
examples/PACKAGES/imd/in.melt_imd-gpu
View File

@ -1,30 +1,32 @@
# 3d Lennard-Jones melt
# 3d Lennard-Jones melt with GPU package acceleration
units lj
atom_style atomic
newton off
# enable GPU package from within the input:
package gpu 0
suffix gpu
lattice fcc 0.8442
region box block 0 10 0 10 0 10
create_box 1 box
create_atoms 1 box
mass 1 1.0
units lj
atom_style atomic
velocity all create 3.0 87287
lattice fcc 0.8442
region box block 0 10 0 10 0 10
create_box 1 box
create_atoms 1 box
mass 1 1.0
pair_style lj/cut/gpu 2.5
pair_coeff 1 1 1.0 1.0 2.5
velocity all create 3.0 87287
neighbor 0.3 bin
neigh_modify every 5 delay 10 check yes
pair_style lj/cut 2.5
pair_coeff 1 1 1.0 1.0 2.5
neighbor 0.3 bin
neigh_modify every 5 delay 10 check yes
thermo_style custom step pe ke spcpu
fix 0 all gpu force/neigh 0 0 1.0
fix 1 all nve
fix 1 all nve
# IMD setup.
fix comm all imd 5678 unwrap off fscale 20.0 trate 20 nowait on
thermo 500
run 5000000
thermo 500
run 5000000

35
examples/PACKAGES/moments/in.converge Normal file
View File

@ -0,0 +1,35 @@
# Detect convergence in a simulation using the relative change in
# moments. This demonstrates the "history" option.
# ---------------------------------------------------------------------
# create pure copper system
units metal
lattice fcc 3.75
region box block 0 6 0 6 0 6
create_box 2 box
timestep 0.002
create_atoms 1 box
pair_style eam/alloy
pair_coeff * * AlCu.eam.alloy Cu Al
# Initialize to a high temperature, then cool in npt ensemble
velocity all create 1000.0 6567345
fix 1 all npt temp 300.0 300.0 $(500*dt) iso 0.0 0.0 $(100*dt)
# compute mean and stddev over the preceding 5000 steps, every 20 steps
variable toteng equal "etotal"
fix 2 all ave/moments 10 500 200 v_toteng mean stddev history 5
# Convergence criterion: stddev is smaller than threshold and was previously larger
# This avoids issues with system oscillations in the order of the averaging window
# that would otherwise lead to "nodes" in the stddev.
variable conv equal "(f_2[2] < 2.0) && (f_2[2][1] < f_2[2][5])"
fix 3 all halt 100 v_conv == 1
thermo_style custom step temp press etotal f_2[*][1] f_2[*][5] v_conv
thermo 100
run 10000

27
examples/PACKAGES/moments/in.simple Normal file
View File

@ -0,0 +1,27 @@
# Perform a simple simulation and output the moments of the total energy
# ---------------------------------------------------------------------
# create pure copper system
units metal
lattice fcc 3.75
region box block 0 6 0 6 0 6
create_box 2 box
timestep 0.002
create_atoms 1 box
pair_style eam/alloy
pair_coeff * * AlCu.eam.alloy Cu Al
# Initialize to a high temperature, then cool in npt ensemble
velocity all create 1000.0 6567345
fix 1 all npt temp 300.0 300.0 $(500*dt) iso 0.0 0.0 $(100*dt)
variable toteng equal "etotal"
fix 2 all ave/moments 5 200 100 v_toteng mean stddev variance skew kurtosis
thermo_style custom step temp press etotal f_2[*]
thermo 100
run 10000

28
examples/PACKAGES/moments/in.valtest Normal file
View File

@ -0,0 +1,28 @@
# Output raw and computed data. This can be used to perform the moment
# calculation in some external tool and validate our results
# ---------------------------------------------------------------------
# create pure copper system
units metal
lattice fcc 3.75
region box block 0 6 0 6 0 6
create_box 2 box
timestep 0.002
create_atoms 1 box
pair_style eam/alloy
pair_coeff * * AlCu.eam.alloy Cu Al
# Initialize to a high temperature, then cool in npt ensemble
velocity all create 1000.0 6567345
fix 1 all npt temp 300.0 300.0 $(500*dt) iso 0.0 0.0 $(100*dt)
variable toteng equal "etotal"
fix 2 all ave/moments 1 10 10 v_toteng mean variance skew kurtosis
thermo_style custom step etotal f_2[*]
thermo_modify format float %14.8f
thermo 1
run 100

171
examples/PACKAGES/moments/log.02May2025.converge.g++.1 Normal file
View File

@ -0,0 +1,171 @@
LAMMPS (2 Apr 2025 - Development - patch_4Feb2025-645-gba166d42e1-modified)
OMP_NUM_THREADS environment is not set. Defaulting to 1 thread. (src/comm.cpp:99)
using 1 OpenMP thread(s) per MPI task
# create pure copper system
units metal
lattice fcc 3.75
Lattice spacing in x,y,z = 3.75 3.75 3.75
region box block 0 6 0 6 0 6
create_box 2 box
Created orthogonal box = (0 0 0) to (22.5 22.5 22.5)
1 by 1 by 1 MPI processor grid
timestep 0.002
create_atoms 1 box
Created 864 atoms
using lattice units in orthogonal box = (0 0 0) to (22.5 22.5 22.5)
create_atoms CPU = 0.001 seconds
pair_style eam/alloy
pair_coeff * * AlCu.eam.alloy Cu Al
# Initialize to a high temperature, then cool in npt ensemble
velocity all create 1000.0 6567345
fix 1 all npt temp 300.0 300.0 $(500*dt) iso 0.0 0.0 $(100*dt)
fix 1 all npt temp 300.0 300.0 1 iso 0.0 0.0 $(100*dt)
fix 1 all npt temp 300.0 300.0 1 iso 0.0 0.0 0.2000000000000000111
variable toteng equal "etotal"
fix 2 all ave/moments 10 500 200 v_toteng mean stddev history 5
variable conv equal "(f_2[2] < 2) && (f_2[2][1] < f_2[2][5])"
fix 3 all halt 1000 v_conv == 1
thermo_style custom step temp press etotal f_2[*][1] f_2[*][5] v_conv
thermo 100
run 10000
Neighbor list info ...
update: every = 1 steps, delay = 0 steps, check = yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 8.6825
ghost atom cutoff = 8.6825
binsize = 4.34125, bins = 6 6 6
1 neighbor lists, perpetual/occasional/extra = 1 0 0
(1) pair eam/alloy, 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) = 3.484 | 3.484 | 3.484 Mbytes
Step Temp Press TotEng f_2[1][1] f_2[2][1] f_2[1][5] f_2[2][5] v_conv
0 1000 -107410.22 -2884.9159 0 0 0 0 0
100 512.04214 -124.66263 -2928.6 0 0 0 0 0
200 479.34328 -136.26635 -2931.3905 -2928.6251 2.1584834 0 0 0
300 480.05298 128.92946 -2933.9233 -2928.6251 2.1584834 0 0 0
400 471.83641 -29.253334 -2936.8631 -2931.3742 3.3668783 0 0 0
500 456.96309 -274.69336 -2939.9081 -2931.3742 3.3668783 0 0 0
600 450.32413 14.606227 -2942.973 -2934.277 5.0681849 0 0 0
700 431.71192 -45.641261 -2946.006 -2934.277 5.0681849 0 0 0
800 436.4217 589.91981 -2948.8885 -2937.2386 6.823233 0 0 0
900 407.84688 -3728.1499 -2951.6643 -2937.2386 6.823233 0 0 0
1000 401.69178 6695.3653 -2954.2959 -2940.1463 8.4728269 -2928.6251 2.1584834 0
1100 370.87469 -2294.843 -2956.9413 -2940.1463 8.4728269 -2928.6251 2.1584834 0
1200 375.15562 704.6568 -2959.3841 -2942.9613 10.001542 -2931.3742 3.3668783 0
1300 371.09077 -493.04016 -2961.6803 -2942.9613 10.001542 -2931.3742 3.3668783 0
1400 365.88512 490.98174 -2963.8365 -2945.6475 11.378724 -2934.277 5.0681849 0
1500 358.42655 -218.94911 -2965.8652 -2945.6475 11.378724 -2934.277 5.0681849 0
1600 329.08402 56.411923 -2967.7662 -2948.1844 12.597017 -2937.2386 6.823233 0
1700 317.74207 1192.918 -2969.557 -2948.1844 12.597017 -2937.2386 6.823233 0
1800 331.98966 -2205.7213 -2971.1465 -2950.559 13.653575 -2940.1463 8.4728269 0
1900 330.96814 1401.3066 -2972.6923 -2950.559 13.653575 -2940.1463 8.4728269 0
2000 315.41816 -909.41909 -2974.0785 -2952.7764 14.568194 -2942.9613 10.001542 0
2100 320.4269 1226.2006 -2975.3676 -2952.7764 14.568194 -2942.9613 10.001542 0
2200 302.88235 -1238.8052 -2976.5099 -2954.8327 15.341787 -2945.6475 11.378724 0
2300 300.4349 2667.202 -2977.5329 -2954.8327 15.341787 -2945.6475 11.378724 0
2400 292.94691 -5532.1854 -2978.3724 -2956.7266 15.978754 -2948.1844 12.597017 0
2500 286.12064 4647.3841 -2979.2217 -2956.7266 15.978754 -2948.1844 12.597017 0
2600 290.74305 -1950.526 -2979.9142 -2958.4592 16.485773 -2950.559 13.653575 0
2700 281.51347 937.60472 -2980.4808 -2958.4592 16.485773 -2950.559 13.653575 0
2800 279.71836 -801.62498 -2980.8899 -2960.032 16.869365 -2952.7764 14.568194 0
2900 277.41241 609.21495 -2981.1721 -2960.032 16.869365 -2952.7764 14.568194 0
3000 281.31161 -760.27203 -2981.3003 -2961.4399 17.128547 -2954.8327 15.341787 0
3100 284.72904 315.53038 -2981.297 -2961.4399 17.128547 -2954.8327 15.341787 0
3200 278.39445 516.25074 -2981.1224 -2962.6768 17.263037 -2956.7266 15.978754 0
3300 294.46998 -655.06212 -2980.8266 -2962.6768 17.263037 -2956.7266 15.978754 0
3400 290.04647 788.30424 -2980.3963 -2963.7417 17.280979 -2958.4592 16.485773 0
3500 283.218 -844.33188 -2979.8504 -2963.7417 17.280979 -2958.4592 16.485773 0
3600 288.76031 1339.2734 -2979.2382 -2964.6345 17.192698 -2960.032 16.869365 0
3700 289.44519 -3015.7161 -2978.5394 -2964.6345 17.192698 -2960.032 16.869365 0
3800 309.04206 5579.3265 -2977.8282 -2965.3649 17.01845 -2961.4399 17.128547 0
3900 309.34588 -4255.5213 -2977.1281 -2965.3649 17.01845 -2961.4399 17.128547 0
4000 305.79444 2358.1383 -2976.5251 -2965.9537 16.784519 -2962.6768 17.263037 0
4100 309.12957 -1401.6484 -2975.9173 -2965.9537 16.784519 -2962.6768 17.263037 0
4200 309.41928 1180.4111 -2975.3857 -2966.4277 16.516135 -2963.7417 17.280979 0
4300 299.88949 -1549.6591 -2974.927 -2966.4277 16.516135 -2963.7417 17.280979 0
4400 319.09918 1937.7006 -2974.5598 -2966.8138 16.232551 -2964.6345 17.192698 0
4500 326.48719 -1489.2073 -2974.311 -2966.8138 16.232551 -2964.6345 17.192698 0
4600 310.93392 37.586899 -2974.1959 -2967.1394 15.948448 -2965.3649 17.01845 0
4700 314.28994 317.12347 -2974.1763 -2967.1394 15.948448 -2965.3649 17.01845 0
4800 309.88756 -698.72705 -2974.2892 -2967.4334 15.675606 -2965.9537 16.784519 0
4900 309.53444 962.42921 -2974.5261 -2967.4334 15.675606 -2965.9537 16.784519 0
5000 316.06666 -1869.3275 -2974.8492 -2967.7182 15.421633 -2966.4277 16.516135 0
5100 304.82485 4042.6797 -2975.2715 -2967.7182 15.421633 -2966.4277 16.516135 0
5200 307.75342 -5058.4814 -2975.7195 -2969.5853 13.236776 -2966.8138 16.232551 0
5300 298.83511 3096.4566 -2976.3329 -2969.5853 13.236776 -2966.8138 16.232551 0
5400 296.85413 -1929.1654 -2976.8797 -2971.2747 11.121537 -2967.1394 15.948448 0
5500 295.88343 1449.3005 -2977.4488 -2971.2747 11.121537 -2967.1394 15.948448 0
5600 305.59328 -1504.0321 -2977.9573 -2972.77 9.1579616 -2967.4334 15.675606 0
5700 293.40683 2579.0134 -2978.4364 -2972.77 9.1579616 -2967.4334 15.675606 0
5800 297.93644 -2742.705 -2978.8276 -2974.0625 7.4101102 -2967.7182 15.421633 0
5900 290.39408 1189.4042 -2979.2224 -2974.0625 7.4101102 -2967.7182 15.421633 0
6000 293.73148 -232.54292 -2979.503 -2975.1594 5.8959922 -2969.5853 13.236776 0
6100 292.04933 -168.30971 -2979.6898 -2975.1594 5.8959922 -2969.5853 13.236776 0
6200 299.23747 839.17828 -2979.7883 -2976.0647 4.6378408 -2971.2747 11.121537 0
6300 294.92201 -1597.9426 -2979.7975 -2976.0647 4.6378408 -2971.2747 11.121537 0
6400 291.7185 3411.2916 -2979.6978 -2976.7848 3.643826 -2972.77 9.1579616 0
6500 285.34227 -4280.7968 -2979.4874 -2976.7848 3.643826 -2972.77 9.1579616 0
6600 295.53838 2138.7496 -2979.2799 -2977.3265 2.9178925 -2974.0625 7.4101102 0
6700 288.54718 -1818.7662 -2978.9379 -2977.3265 2.9178925 -2974.0625 7.4101102 0
6800 290.41342 2175.3559 -2978.543 -2977.7009 2.4532223 -2975.1594 5.8959922 0
6900 296.34456 -4782.08 -2978.0362 -2977.7009 2.4532223 -2975.1594 5.8959922 0
7000 303.74314 5905.219 -2977.577 -2977.9137 2.2279716 -2976.0647 4.6378408 0
7100 303.90284 -3291.7627 -2977.1308 -2977.9137 2.2279716 -2976.0647 4.6378408 0
7200 296.13966 2209.574 -2976.7001 -2977.9829 2.1708943 -2976.7848 3.643826 0
7300 295.79694 -1609.1898 -2976.2816 -2977.9829 2.1708943 -2976.7848 3.643826 0
7400 306.53289 988.50902 -2975.8992 -2977.931 2.1935882 -2977.3265 2.9178925 0
7500 303.89992 -631.22838 -2975.5597 -2977.931 2.1935882 -2977.3265 2.9178925 0
7600 303.83684 -348.48744 -2975.3074 -2977.7831 2.2226664 -2977.7009 2.4532223 0
7700 309.67313 1350.9414 -2975.1279 -2977.7831 2.2226664 -2977.7009 2.4532223 0
7800 309.74314 -1182.8905 -2975.0174 -2977.5683 2.2106484 -2977.9137 2.2279716 0
7900 309.42429 999.08033 -2975.0089 -2977.5683 2.2106484 -2977.9137 2.2279716 0
8000 315.51872 -1337.8894 -2975.0791 -2977.3233 2.1379295 -2977.9829 2.1708943 0
8100 314.80533 2392.3424 -2975.25 -2977.3233 2.1379295 -2977.9829 2.1708943 0
8200 303.80236 -3224.5976 -2975.4744 -2977.0851 2.0176342 -2977.931 2.1935882 0
8300 295.0505 3296.6912 -2975.8196 -2977.0851 2.0176342 -2977.931 2.1935882 0
8400 302.4154 -3314.5096 -2976.1586 -2976.8877 1.883051 -2977.7831 2.2226664 1
8500 300.95491 2971.1291 -2976.5859 -2976.8877 1.883051 -2977.7831 2.2226664 1
8600 301.68919 -2297.6673 -2976.9953 -2976.7596 1.785401 -2977.5683 2.2106484 1
8700 291.21002 1477.5703 -2977.4323 -2976.7596 1.785401 -2977.5683 2.2106484 1
8800 305.87126 -1085.459 -2977.8247 -2976.7169 1.7541517 -2977.3233 2.1379295 1
8900 296.17567 777.95805 -2978.2081 -2976.7169 1.7541517 -2977.3233 2.1379295 1
Fix halt condition for fix-id 3 met on step 9000 with value 1 (src/fix_halt.cpp:310)
9000 295.71917 -425.00708 -2978.5264 -2976.7595 1.7755885 -2977.0851 2.0176342 1
Loop time of 42.1758 on 1 procs for 9000 steps with 864 atoms
Performance: 36.874 ns/day, 0.651 hours/ns, 213.393 timesteps/s, 184.371 katom-step/s
99.9% CPU use with 1 MPI tasks x 1 OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 41.126 | 41.126 | 41.126 | 0.0 | 97.51
Neigh | 0.0078787 | 0.0078787 | 0.0078787 | 0.0 | 0.02
Comm | 0.26508 | 0.26508 | 0.26508 | 0.0 | 0.63
Output | 0.0096224 | 0.0096224 | 0.0096224 | 0.0 | 0.02
Modify | 0.65597 | 0.65597 | 0.65597 | 0.0 | 1.56
Other | | 0.1108 | | | 0.26
Nlocal: 864 ave 864 max 864 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Nghost: 3767 ave 3767 max 3767 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Neighs: 96746 ave 96746 max 96746 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Total # of neighbors = 96746
Ave neighs/atom = 111.97454
Neighbor list builds = 1
Dangerous builds = 0
Total wall time: 0:00:42

171
examples/PACKAGES/moments/log.02May2025.converge.g++.4 Normal file
View File

@ -0,0 +1,171 @@
LAMMPS (2 Apr 2025 - Development - patch_4Feb2025-645-gba166d42e1-modified)
OMP_NUM_THREADS environment is not set. Defaulting to 1 thread. (src/comm.cpp:99)
using 1 OpenMP thread(s) per MPI task
# create pure copper system
units metal
lattice fcc 3.75
Lattice spacing in x,y,z = 3.75 3.75 3.75
region box block 0 6 0 6 0 6
create_box 2 box
Created orthogonal box = (0 0 0) to (22.5 22.5 22.5)
1 by 2 by 2 MPI processor grid
timestep 0.002
create_atoms 1 box
Created 864 atoms
using lattice units in orthogonal box = (0 0 0) to (22.5 22.5 22.5)
create_atoms CPU = 0.001 seconds
pair_style eam/alloy
pair_coeff * * AlCu.eam.alloy Cu Al
# Initialize to a high temperature, then cool in npt ensemble
velocity all create 1000.0 6567345
fix 1 all npt temp 300.0 300.0 $(500*dt) iso 0.0 0.0 $(100*dt)
fix 1 all npt temp 300.0 300.0 1 iso 0.0 0.0 $(100*dt)
fix 1 all npt temp 300.0 300.0 1 iso 0.0 0.0 0.2000000000000000111
variable toteng equal "etotal"
fix 2 all ave/moments 10 500 200 v_toteng mean stddev history 5
variable conv equal "(f_2[2] < 2) && (f_2[2][1] < f_2[2][5])"
fix 3 all halt 1000 v_conv == 1
thermo_style custom step temp press etotal f_2[*][1] f_2[*][5] v_conv
thermo 100
run 10000
Neighbor list info ...
update: every = 1 steps, delay = 0 steps, check = yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 8.6825
ghost atom cutoff = 8.6825
binsize = 4.34125, bins = 6 6 6
1 neighbor lists, perpetual/occasional/extra = 1 0 0
(1) pair eam/alloy, 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) = 3.42 | 3.42 | 3.42 Mbytes
Step Temp Press TotEng f_2[1][1] f_2[2][1] f_2[1][5] f_2[2][5] v_conv
0 1000 -107410.22 -2884.9159 0 0 0 0 0
100 492.38014 -134.33622 -2928.6874 0 0 0 0 0
200 484.82396 -214.26318 -2931.4603 -2928.6979 2.1805063 0 0 0
300 476.69743 15.78678 -2934.0022 -2928.6979 2.1805063 0 0 0
400 482.51415 141.67184 -2936.9347 -2931.4437 3.3715811 0 0 0
500 455.45411 2.4424602 -2939.9649 -2931.4437 3.3715811 0 0 0
600 455.20054 -6.8170934 -2943.0454 -2934.339 5.0598781 0 0 0
700 429.81168 -75.812923 -2946.0438 -2934.339 5.0598781 0 0 0
800 428.22097 604.18705 -2948.9285 -2937.2965 6.813037 0 0 0
900 399.10914 -3622.6904 -2951.7252 -2937.2965 6.813037 0 0 0
1000 394.62543 7905.9041 -2954.2925 -2940.2044 8.4668749 -2928.6979 2.1805063 0
1100 404.27007 -2565.5508 -2956.9736 -2940.2044 8.4668749 -2928.6979 2.1805063 0
1200 368.47178 741.43707 -2959.4264 -2943.0151 9.9914785 -2931.4437 3.3715811 0
1300 360.91266 -267.08372 -2961.69 -2943.0151 9.9914785 -2931.4437 3.3715811 0
1400 356.74405 158.09093 -2963.8501 -2945.696 11.36357 -2934.339 5.0598781 0
1500 335.45696 -71.007783 -2965.8817 -2945.696 11.36357 -2934.339 5.0598781 0
1600 331.01199 -454.90004 -2967.7708 -2948.2278 12.577884 -2937.2965 6.813037 0
1700 329.223 2428.4284 -2969.5452 -2948.2278 12.577884 -2937.2965 6.813037 0
1800 327.61481 -4757.648 -2971.1105 -2950.5985 13.632251 -2940.2044 8.4668749 0
1900 318.18741 2226.7765 -2972.6906 -2950.5985 13.632251 -2940.2044 8.4668749 0
2000 308.79313 -1089.8603 -2974.0899 -2952.8123 14.545164 -2943.0151 9.9914785 0
2100 303.32047 757.53534 -2975.3597 -2952.8123 14.545164 -2943.0151 9.9914785 0
2200 307.41102 -837.97246 -2976.4966 -2954.8654 15.317558 -2945.696 11.36357 0
2300 303.01088 1618.29 -2977.5454 -2954.8654 15.317558 -2945.696 11.36357 0
2400 297.59385 -3233.8282 -2978.4064 -2956.7565 15.953758 -2948.2278 12.577884 0
2500 288.72232 5209.2099 -2979.1999 -2956.7565 15.953758 -2948.2278 12.577884 0
2600 298.92201 -2193.618 -2979.8873 -2958.4845 16.457635 -2950.5985 13.632251 0
2700 282.61818 765.88178 -2980.4563 -2958.4845 16.457635 -2950.5985 13.632251 0
2800 273.63104 -389.49749 -2980.8636 -2960.0533 16.839029 -2952.8123 14.545164 0
2900 274.12166 -9.2552992 -2981.1421 -2960.0533 16.839029 -2952.8123 14.545164 0
3000 279.43592 212.25445 -2981.2716 -2961.4578 17.096628 -2954.8654 15.317558 0
3100 291.10071 -1139.205 -2981.2475 -2961.4578 17.096628 -2954.8654 15.317558 0
3200 281.53171 3124.6411 -2981.0818 -2962.6921 17.230604 -2956.7565 15.953758 0
3300 277.0223 -2795.9494 -2980.7825 -2962.6921 17.230604 -2956.7565 15.953758 0
3400 284.8443 1587.8876 -2980.3701 -2963.754 17.247489 -2958.4845 16.457635 0
3500 281.19 -1143.0785 -2979.8374 -2963.754 17.247489 -2958.4845 16.457635 0
3600 296.58287 1156.4706 -2979.2182 -2964.645 17.159411 -2960.0533 16.839029 0
3700 297.24517 -1888.4993 -2978.5352 -2964.645 17.159411 -2960.0533 16.839029 0
3800 290.81586 3843.3483 -2977.8509 -2965.3746 16.985916 -2961.4578 17.096628 0
3900 300.39456 -5584.8386 -2977.0837 -2965.3746 16.985916 -2961.4578 17.096628 0
4000 306.15811 3310.0105 -2976.5086 -2965.9619 16.752214 -2962.6921 17.230604 0
4100 295.907 -1475.0458 -2975.9096 -2965.9619 16.752214 -2962.6921 17.230604 0
4200 322.70162 933.76586 -2975.3867 -2966.4348 16.484219 -2963.754 17.247489 0
4300 306.69631 -512.7048 -2974.9324 -2966.4348 16.484219 -2963.754 17.247489 0
4400 309.23776 226.77219 -2974.5791 -2966.8208 16.201471 -2964.645 17.159411 0
4500 313.15783 508.29785 -2974.3263 -2966.8208 16.201471 -2964.645 17.159411 0
4600 316.26151 -2043.7571 -2974.1697 -2967.1463 15.918137 -2965.3746 16.985916 0
4700 312.27329 1831.682 -2974.1732 -2967.1463 15.918137 -2965.3746 16.985916 0
4800 307.61066 -1476.0019 -2974.2885 -2967.4397 15.645834 -2965.9619 16.752214 0
4900 305.73489 1303.4848 -2974.5506 -2967.4397 15.645834 -2965.9619 16.752214 0
5000 309.3774 -1574.6812 -2974.8687 -2967.7249 15.392787 -2966.4348 16.484219 0
5100 304.8602 2679.7476 -2975.3082 -2967.7249 15.392787 -2966.4348 16.484219 0
5200 297.54226 -5008.0905 -2975.7443 -2969.5904 13.211657 -2966.8208 16.201471 0
5300 306.18872 4840.4175 -2976.324 -2969.5904 13.211657 -2966.8208 16.201471 0
5400 299.57661 -2513.1706 -2976.8842 -2971.2774 11.099846 -2967.1463 15.918137 0
5500 302.30844 1301.3525 -2977.4539 -2971.2774 11.099846 -2967.1463 15.918137 0
5600 302.11038 -760.79712 -2977.9764 -2972.7712 9.1381778 -2967.4397 15.645834 0
5700 294.49825 718.67318 -2978.4584 -2972.7712 9.1381778 -2967.4397 15.645834 0
5800 305.97636 -478.64224 -2978.8638 -2974.0628 7.3929182 -2967.7249 15.392787 0
5900 291.93868 -419.74179 -2979.2292 -2974.0628 7.3929182 -2967.7249 15.392787 0
6000 289.50667 859.85085 -2979.5018 -2975.1575 5.8837236 -2969.5904 13.211657 0
6100 305.70118 -933.35917 -2979.6877 -2975.1575 5.8837236 -2969.5904 13.211657 0
6200 284.37805 1526.0707 -2979.806 -2976.062 4.6281363 -2971.2774 11.099846 0
6300 291.08863 -2156.6708 -2979.8064 -2976.062 4.6281363 -2971.2774 11.099846 0
6400 295.99073 2819.8245 -2979.7378 -2976.7827 3.6358684 -2972.7712 9.1381778 0
6500 298.06769 -3396.3504 -2979.5428 -2976.7827 3.6358684 -2972.7712 9.1381778 0
6600 301.78514 5496.6525 -2979.2768 -2977.3261 2.9112079 -2974.0628 7.3929182 0
6700 290.80665 -5229.4989 -2978.9177 -2977.3261 2.9112079 -2974.0628 7.3929182 0
6800 296.75761 2401.7807 -2978.5996 -2977.7014 2.4473856 -2975.1575 5.8837236 0
6900 295.77553 -1521.6269 -2978.1619 -2977.7014 2.4473856 -2975.1575 5.8837236 0
7000 303.59015 1530.7255 -2977.7097 -2977.9176 2.2219164 -2976.062 4.6281363 0
7100 297.51038 -3016.4426 -2977.2025 -2977.9176 2.2219164 -2976.062 4.6281363 0
7200 293.53789 2705.9808 -2976.7651 -2977.9894 2.1638143 -2976.7827 3.6358684 0
7300 301.78809 -1042.1076 -2976.3388 -2977.9894 2.1638143 -2976.7827 3.6358684 0
7400 307.50053 214.56923 -2975.9581 -2977.9394 2.1852009 -2977.3261 2.9112079 0
7500 301.98985 281.86495 -2975.6146 -2977.9394 2.1852009 -2977.3261 2.9112079 0
7600 318.37347 -1145.7795 -2975.3473 -2977.7949 2.2136707 -2977.7014 2.4473856 0
7700 314.94512 4536.9887 -2975.1351 -2977.7949 2.2136707 -2977.7014 2.4473856 0
7800 312.91485 -2980.6408 -2975.0156 -2977.5818 2.2038198 -2977.9176 2.2219164 0
7900 310.06854 2244.3877 -2975.0094 -2977.5818 2.2038198 -2977.9176 2.2219164 0
8000 308.55007 -2427.1464 -2975.0491 -2977.3378 2.1348358 -2977.9894 2.1638143 0
8100 323.02796 3187.4728 -2975.2081 -2977.3378 2.1348358 -2977.9894 2.1638143 0
8200 327.05029 -6447.7875 -2975.3162 -2977.0986 2.0196599 -2977.9394 2.1852009 0
8300 311.194 4273.1174 -2975.7217 -2977.0986 2.0196599 -2977.9394 2.1852009 0
8400 290.61931 -2301.019 -2976.0963 -2976.8989 1.8918948 -2977.7949 2.2136707 1
8500 314.00559 1966.1297 -2976.5206 -2976.8989 1.8918948 -2977.7949 2.2136707 1
8600 288.26541 -1608.4524 -2976.9304 -2976.7685 1.7971228 -2977.5818 2.2038198 1
8700 298.92083 1353.9988 -2977.355 -2976.7685 1.7971228 -2977.5818 2.2038198 1
8800 299.97274 -638.68301 -2977.766 -2976.722 1.7650747 -2977.3378 2.1348358 1
8900 300.66443 -279.62514 -2978.1476 -2976.722 1.7650747 -2977.3378 2.1348358 1
Fix halt condition for fix-id 3 met on step 9000 with value 1 (src/fix_halt.cpp:310)
9000 290.44715 489.06352 -2978.4892 -2976.7631 1.7846181 -2977.0986 2.0196599 1
Loop time of 14.7347 on 4 procs for 9000 steps with 864 atoms
Performance: 105.547 ns/day, 0.227 hours/ns, 610.804 timesteps/s, 527.735 katom-step/s
92.8% CPU use with 4 MPI tasks x 1 OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 10.565 | 11.474 | 12.015 | 16.1 | 77.87
Neigh | 0.0020313 | 0.0020966 | 0.002163 | 0.1 | 0.01
Comm | 2.008 | 2.5374 | 3.4278 | 33.5 | 17.22
Output | 0.0030284 | 0.0036299 | 0.0051776 | 1.5 | 0.02
Modify | 0.42442 | 0.43307 | 0.44329 | 1.0 | 2.94
Other | | 0.2849 | | | 1.93
Nlocal: 216 ave 224 max 204 min
Histogram: 1 0 0 0 0 0 0 2 0 1
Nghost: 2147 ave 2159 max 2139 min
Histogram: 1 0 0 2 0 0 0 0 0 1
Neighs: 24185.8 ave 26045 max 21309 min
Histogram: 1 0 0 0 0 1 0 0 0 2
Total # of neighbors = 96743
Ave neighs/atom = 111.97106
Neighbor list builds = 1
Dangerous builds = 0
Total wall time: 0:00:14

177
examples/PACKAGES/moments/log.02May2025.simple.g++.1 Normal file
View File

@ -0,0 +1,177 @@
LAMMPS (2 Apr 2025 - Development - patch_4Feb2025-645-gba166d42e1-modified)
OMP_NUM_THREADS environment is not set. Defaulting to 1 thread. (src/comm.cpp:99)
using 1 OpenMP thread(s) per MPI task
# create pure copper system
units metal
lattice fcc 3.75
Lattice spacing in x,y,z = 3.75 3.75 3.75
region box block 0 6 0 6 0 6
create_box 2 box
Created orthogonal box = (0 0 0) to (22.5 22.5 22.5)
1 by 1 by 1 MPI processor grid
timestep 0.002
create_atoms 1 box
Created 864 atoms
using lattice units in orthogonal box = (0 0 0) to (22.5 22.5 22.5)
create_atoms CPU = 0.001 seconds
pair_style eam/alloy
pair_coeff * * AlCu.eam.alloy Cu Al
# Initialize to a high temperature, then cool in npt ensemble
velocity all create 1000.0 6567345
fix 1 all npt temp 300.0 300.0 $(500*dt) iso 0.0 0.0 $(100*dt)
fix 1 all npt temp 300.0 300.0 1 iso 0.0 0.0 $(100*dt)
fix 1 all npt temp 300.0 300.0 1 iso 0.0 0.0 0.2000000000000000111
variable toteng equal "etotal"
fix 2 all ave/moments 5 200 100 v_toteng mean stddev variance skew kurtosis
thermo_style custom step temp press etotal f_2[*]
thermo 100
run 10000
Neighbor list info ...
update: every = 1 steps, delay = 0 steps, check = yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 8.6825
ghost atom cutoff = 8.6825
binsize = 4.34125, bins = 6 6 6
1 neighbor lists, perpetual/occasional/extra = 1 0 0
(1) pair eam/alloy, 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) = 3.484 | 3.484 | 3.484 Mbytes
Step Temp Press TotEng f_2[1] f_2[2] f_2[3] f_2[4] f_2[5]
0 1000 -107410.22 -2884.9159 0 0 0 0 0
100 512.04214 -124.66263 -2928.6 -2927.1688 1.6797138 2.8214386 2.5218138 6.164012
200 479.34328 -136.26635 -2931.3905 -2928.6374 1.9791406 3.9169976 1.3377745 3.2426285
300 480.05298 128.92946 -2933.9233 -2929.9825 2.5401119 6.4521682 0.66415393 0.77130236
400 471.83641 -29.253334 -2936.8631 -2931.346 3.2640831 10.654239 0.29075579 -0.26904542
500 456.96309 -274.69336 -2939.9081 -2932.7721 4.1077082 16.873267 0.094954709 -0.72240572
600 450.32413 14.606227 -2942.973 -2934.2328 4.9928765 24.928816 0.0090731063 -0.93757177
700 431.71192 -45.641261 -2946.006 -2935.7111 5.8871117 34.658084 -0.024573652 -1.0540107
800 436.4217 589.91981 -2948.8885 -2937.1871 6.762411 45.730202 -0.028553126 -1.1275153
900 407.84688 -3728.1499 -2951.6643 -2938.652 7.6129868 57.957569 -0.020186137 -1.172618
1000 401.69178 6695.3653 -2954.2959 -2940.0921 8.423174 70.949861 -0.0018224075 -1.2051609
1100 370.87469 -2294.843 -2956.9413 -2942.9469 8.384346 70.297257 0.016964628 -1.2643199
1200 375.15562 704.6568 -2959.3841 -2945.7589 8.3201293 69.224551 0.070500644 -1.2400262
1300 371.09077 -493.04016 -2961.6803 -2948.5516 8.1425118 66.300499 0.11183042 -1.2099873
1400 365.88512 490.98174 -2963.8365 -2951.2897 7.8673969 61.895934 0.13639588 -1.198071
1500 358.42655 -218.94911 -2965.8652 -2953.9337 7.5491659 56.989906 0.15564307 -1.1896984
1600 329.08402 56.411923 -2967.7662 -2956.467 7.2016413 51.863637 0.17198437 -1.186472
1700 317.74207 1192.918 -2969.557 -2958.8765 6.8379658 46.757776 0.19041811 -1.1812241
1800 331.98966 -2205.7213 -2971.1465 -2961.1601 6.4614065 41.749774 0.20925197 -1.1714131
1900 330.96814 1401.3066 -2972.6923 -2963.3191 6.0867317 37.048302 0.22552163 -1.1523125
2000 315.41816 -909.41909 -2974.0785 -2965.3567 5.7020261 32.513101 0.2328316 -1.1454375
2100 320.4269 1226.2006 -2975.3676 -2967.2609 5.3260556 28.366869 0.24130517 -1.1432352
2200 302.88235 -1238.8052 -2976.5099 -2969.0355 4.9584282 24.58601 0.25200271 -1.141699
2300 300.4349 2667.202 -2977.5329 -2970.6815 4.5986371 21.147463 0.26764984 -1.1380521
2400 292.94691 -5532.1854 -2978.3724 -2972.201 4.2403749 17.980779 0.28797864 -1.1357902
2500 286.12064 4647.3841 -2979.2217 -2973.5946 3.8875889 15.113348 0.31556585 -1.1249025
2600 290.74305 -1950.526 -2979.9142 -2974.8686 3.5422986 12.547879 0.34719546 -1.0987558
2700 281.51347 937.60472 -2980.4808 -2976.0235 3.1955646 10.211633 0.38268676 -1.0664838
2800 279.71836 -801.62498 -2980.8899 -2977.0588 2.844105 8.0889331 0.41930147 -1.0460672
2900 277.41241 609.21495 -2981.1721 -2977.9673 2.4956133 6.2280855 0.47337432 -1.0140054
3000 281.31161 -760.27203 -2981.3003 -2978.7489 2.1466012 4.6078967 0.55325134 -0.95161956
3100 284.72904 315.53038 -2981.297 -2979.4023 1.7929581 3.2146986 0.66481771 -0.84726207
3200 278.39445 516.25074 -2981.1224 -2979.9226 1.4369984 2.0649644 0.82583409 -0.63830994
3300 294.46998 -655.06212 -2980.8266 -2980.3134 1.0905211 1.1892364 1.0357766 -0.22841943
3400 290.04647 788.30424 -2980.3963 -2980.5732 0.77030961 0.59337689 1.1867647 0.34447355
3500 283.218 -844.33188 -2979.8504 -2980.6995 0.54590076 0.29800764 0.78163948 -0.42619888
3600 288.76031 1339.2734 -2979.2382 -2980.6921 0.56032295 0.31396181 0.83603869 -0.30853278
3700 289.44519 -3015.7161 -2978.5394 -2980.5581 0.77708069 0.60385439 1.0796997 -0.022962365
3800 309.04206 5579.3265 -2977.8282 -2980.3052 1.0531468 1.1091181 0.890018 -0.56034495
3900 309.34588 -4255.5213 -2977.1281 -2979.9487 1.3153981 1.7302721 0.65242676 -0.95498589
4000 305.79444 2358.1383 -2976.5251 -2979.5068 1.5325477 2.3487025 0.44420123 -1.1839975
4100 309.12957 -1401.6484 -2975.9173 -2978.9985 1.6923829 2.86416 0.26850538 -1.3006942
4200 309.41928 1180.4111 -2975.3857 -2978.4446 1.7941259 3.2188877 0.11443933 -1.3365167
4300 299.88949 -1549.6591 -2974.927 -2977.8616 1.8268192 3.3372683 -0.018659059 -1.3293426
4400 319.09918 1937.7006 -2974.5598 -2977.273 1.7942266 3.219249 -0.13743367 -1.2958767
4500 326.48719 -1489.2073 -2974.311 -2976.7017 1.7042328 2.9044096 -0.25309558 -1.2385503
4600 310.93392 37.586899 -2974.1959 -2976.1697 1.5590672 2.4306905 -0.3757949 -1.1641151
4700 314.28994 317.12347 -2974.1763 -2975.6978 1.3661244 1.8662958 -0.51792367 -1.0609001
4800 309.88756 -698.72705 -2974.2892 -2975.3021 1.1422822 1.3048085 -0.69587053 -0.87319738
4900 309.53444 962.42921 -2974.5261 -2974.9944 0.89961859 0.80931361 -0.91892105 -0.49661907
5000 316.06666 -1869.3275 -2974.8492 -2974.7804 0.65817496 0.43319428 -1.0974595 0.048447651
5100 304.82485 4042.6797 -2975.2715 -2974.6661 0.47073268 0.22158926 -0.82059377 -0.31531887
5200 307.75342 -5058.4814 -2975.7195 -2974.6547 0.44733518 0.20010876 -0.68956594 -0.65171579
5300 298.83511 3096.4566 -2976.3329 -2974.7467 0.60599527 0.36723026 -1.0652601 0.032591262
5400 296.85413 -1929.1654 -2976.8797 -2974.9367 0.82832935 0.68612952 -0.91576774 -0.50322222
5500 295.88343 1449.3005 -2977.4488 -2975.215 1.044317 1.090598 -0.67574925 -0.92510515
5600 305.59328 -1504.0321 -2977.9573 -2975.5653 1.2243609 1.4990595 -0.46160433 -1.1708115
5700 293.40683 2579.0134 -2978.4364 -2975.97 1.3577316 1.843435 -0.27746111 -1.2993802
5800 297.93644 -2742.705 -2978.8276 -2976.411 1.4332742 2.054275 -0.11245859 -1.3584974
5900 290.39408 1189.4042 -2979.2224 -2976.8733 1.4576633 2.1247823 0.030209056 -1.3466833
6000 293.73148 -232.54292 -2979.503 -2977.3408 1.4300816 2.0451335 0.15663025 -1.2965878
6100 292.04933 -168.30971 -2979.6898 -2977.7936 1.3523929 1.8289665 0.28027258 -1.2214523
6200 299.23747 839.17828 -2979.7883 -2978.2154 1.2284868 1.5091798 0.40149929 -1.1382373
6300 294.92201 -1597.9426 -2979.7975 -2978.589 1.072002 1.1491883 0.53769821 -1.0262094
6400 291.7185 3411.2916 -2979.6978 -2978.9013 0.89165749 0.79505308 0.70748196 -0.83601078
6500 285.34227 -4280.7968 -2979.4874 -2979.1407 0.69727552 0.48619315 0.91500724 -0.4890805
6600 295.53838 2138.7496 -2979.2799 -2979.3084 0.50938648 0.25947459 1.0827149 -0.0043801382
6700 288.54718 -1818.7662 -2978.9379 -2979.3979 0.3658125 0.13381879 0.85573626 -0.20104653
6800 290.41342 2175.3559 -2978.543 -2979.4085 0.34439248 0.11860618 0.70989241 -0.55138716
6900 296.34456 -4782.08 -2978.0362 -2979.3362 0.47081063 0.22166265 1.1051059 0.16381282
7000 303.74314 5905.219 -2977.577 -2979.182 0.65635739 0.43080502 0.97456755 -0.34269231
7100 303.90284 -3291.7627 -2977.1308 -2978.9595 0.83412944 0.69577192 0.71973637 -0.85687335
7200 296.13966 2209.574 -2976.7001 -2978.6767 0.98885368 0.97783159 0.50554418 -1.124705
7300 295.79694 -1609.1898 -2976.2816 -2978.3446 1.1093729 1.2307082 0.32952142 -1.2657581
7400 306.53289 988.50902 -2975.8992 -2977.977 1.1910167 1.4185209 0.17936365 -1.331845
7500 303.89992 -631.22838 -2975.5597 -2977.5901 1.2352698 1.5258915 0.033110856 -1.3362459
7600 303.83684 -348.48744 -2975.3074 -2977.1915 1.2312686 1.5160224 -0.094817417 -1.3063491
7700 309.67313 1350.9414 -2975.1279 -2976.7984 1.1829266 1.3993154 -0.21343083 -1.2573517
7800 309.74314 -1182.8905 -2975.0174 -2976.4294 1.0913021 1.1909402 -0.3401118 -1.198459
7900 309.42429 999.08033 -2975.0089 -2976.0995 0.96393318 0.92916717 -0.48456322 -1.1149956
8000 315.51872 -1337.8894 -2975.0791 -2975.822 0.81535467 0.66480324 -0.67906685 -0.90499956
8100 314.80533 2392.3424 -2975.25 -2975.6019 0.64582022 0.41708376 -0.90521871 -0.5328796
8200 303.80236 -3224.5976 -2975.4744 -2975.4481 0.47449379 0.22514436 -1.0884377 -0.00018150871
8300 295.0505 3296.6912 -2975.8196 -2975.3667 0.34164698 0.11672266 -0.83269043 -0.31809119
8400 302.4154 -3314.5096 -2976.1586 -2975.3606 0.32904826 0.10827276 -0.73500255 -0.57861735
8500 300.95491 2971.1291 -2976.5859 -2975.4288 0.44584452 0.19877734 -1.0760301 0.014924509
8600 301.68919 -2297.6673 -2976.9953 -2975.5682 0.60852433 0.37030186 -0.91802963 -0.5143582
8700 291.21002 1477.5703 -2977.4323 -2975.7733 0.76843347 0.59048999 -0.68059043 -0.92051715
8800 305.87126 -1085.459 -2977.8247 -2976.0327 0.90672273 0.82214612 -0.47413162 -1.1492716
8900 296.17567 777.95805 -2978.2081 -2976.3349 1.0129061 1.0259789 -0.29734681 -1.271416
9000 295.71917 -425.00708 -2978.5264 -2976.6672 1.0786137 1.1634075 -0.14055755 -1.3302079
9100 296.85578 -533.46289 -2978.8197 -2977.0152 1.1000855 1.2101882 0.0045950751 -1.3434868
9200 293.949 605.27065 -2979.0349 -2977.3702 1.0854405 1.1781811 0.123965 -1.3093197
9300 289.11704 -896.44753 -2979.1981 -2977.7166 1.0353526 1.071955 0.23898813 -1.2558296
9400 285.34521 1181.7542 -2979.2879 -2978.0404 0.95298596 0.90818224 0.36461645 -1.1736585
9500 296.17714 -2503.9848 -2979.2668 -2978.3301 0.8407037 0.70678272 0.50841734 -1.0540275
9600 296.43744 4912.6395 -2979.1829 -2978.5736 0.70352404 0.49494608 0.68312042 -0.86335848
9700 288.63317 -3935.8902 -2979.0381 -2978.7635 0.55322477 0.30605764 0.88509388 -0.54108379
9800 296.27133 1365.4106 -2978.8723 -2978.8969 0.40665162 0.16536554 1.0460992 -0.092552905
9900 299.37628 -1267.2668 -2978.5934 -2978.9673 0.29467695 0.086834506 0.80391757 -0.38307943
10000 296.60645 1950.1018 -2978.2725 -2978.9739 0.28169006 0.079349287 0.70171659 -0.62026504
Loop time of 47.4814 on 1 procs for 10000 steps with 864 atoms
Performance: 36.393 ns/day, 0.659 hours/ns, 210.609 timesteps/s, 181.966 katom-step/s
99.9% CPU use with 1 MPI tasks x 1 OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 46.299 | 46.299 | 46.299 | 0.0 | 97.51
Neigh | 0.010908 | 0.010908 | 0.010908 | 0.0 | 0.02
Comm | 0.29643 | 0.29643 | 0.29643 | 0.0 | 0.62
Output | 0.0090682 | 0.0090682 | 0.0090682 | 0.0 | 0.02
Modify | 0.7406 | 0.7406 | 0.7406 | 0.0 | 1.56
Other | | 0.1254 | | | 0.26
Nlocal: 864 ave 864 max 864 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Nghost: 3767 ave 3767 max 3767 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Neighs: 96746 ave 96746 max 96746 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Total # of neighbors = 96746
Ave neighs/atom = 111.97454
Neighbor list builds = 1
Dangerous builds = 0
Total wall time: 0:00:47

177
examples/PACKAGES/moments/log.02May2025.simple.g++.4 Normal file
View File

@ -0,0 +1,177 @@
LAMMPS (2 Apr 2025 - Development - patch_4Feb2025-645-gba166d42e1-modified)
OMP_NUM_THREADS environment is not set. Defaulting to 1 thread. (src/comm.cpp:99)
using 1 OpenMP thread(s) per MPI task
# create pure copper system
units metal
lattice fcc 3.75
Lattice spacing in x,y,z = 3.75 3.75 3.75
region box block 0 6 0 6 0 6
create_box 2 box
Created orthogonal box = (0 0 0) to (22.5 22.5 22.5)
1 by 2 by 2 MPI processor grid
timestep 0.002
create_atoms 1 box
Created 864 atoms
using lattice units in orthogonal box = (0 0 0) to (22.5 22.5 22.5)
create_atoms CPU = 0.010 seconds
pair_style eam/alloy
pair_coeff * * AlCu.eam.alloy Cu Al
# Initialize to a high temperature, then cool in npt ensemble
velocity all create 1000.0 6567345
fix 1 all npt temp 300.0 300.0 $(500*dt) iso 0.0 0.0 $(100*dt)
fix 1 all npt temp 300.0 300.0 1 iso 0.0 0.0 $(100*dt)
fix 1 all npt temp 300.0 300.0 1 iso 0.0 0.0 0.2000000000000000111
variable toteng equal "etotal"
fix 2 all ave/moments 5 200 100 v_toteng mean stddev variance skew kurtosis
thermo_style custom step temp press etotal f_2[*]
thermo 100
run 10000
Neighbor list info ...
update: every = 1 steps, delay = 0 steps, check = yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 8.6825
ghost atom cutoff = 8.6825
binsize = 4.34125, bins = 6 6 6
1 neighbor lists, perpetual/occasional/extra = 1 0 0
(1) pair eam/alloy, 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) = 3.42 | 3.42 | 3.42 Mbytes
Step Temp Press TotEng f_2[1] f_2[2] f_2[3] f_2[4] f_2[5]
0 1000 -107410.22 -2884.9159 0 0 0 0 0
100 492.38014 -134.33622 -2928.6874 -2927.2291 1.7092959 2.9216925 2.5081594 6.099781
200 484.82396 -214.26318 -2931.4603 -2928.71 2.0003214 4.0012857 1.3645049 3.3103886
300 476.69743 15.78678 -2934.0022 -2930.0515 2.5470901 6.4876682 0.6954232 0.86102766
400 482.51415 141.67184 -2936.9347 -2931.4152 3.2681043 10.680505 0.30641098 -0.22337036
500 455.45411 2.4424602 -2939.9649 -2932.8397 4.1076295 16.87262 0.10483325 -0.6997127
600 455.20054 -6.8170934 -2943.0454 -2934.2947 4.9842257 24.842506 0.018003661 -0.92490336
700 429.81168 -75.812923 -2946.0438 -2935.7704 5.8766819 34.53539 -0.019539731 -1.0444564
800 428.22097 604.18705 -2948.9285 -2937.2449 6.7522047 45.592268 -0.026384526 -1.1194924
900 399.10914 -3622.6904 -2951.7252 -2938.7094 7.6043904 57.826753 -0.019997758 -1.1658244
1000 394.62543 7905.9041 -2954.2925 -2940.15 8.4168551 70.84345 -0.0026187371 -1.2004009
1100 404.27007 -2565.5508 -2956.9736 -2943.0009 8.3722389 70.094384 0.015852037 -1.2665587
1200 368.47178 741.43707 -2959.4264 -2945.8091 8.3127243 69.101386 0.069744698 -1.2412651
1300 360.91266 -267.08372 -2961.69 -2948.5981 8.1334656 66.153263 0.1116445 -1.2129213
1400 356.74405 158.09093 -2963.8501 -2951.3302 7.8574973 61.740264 0.13825232 -1.1999727
1500 335.45696 -71.007783 -2965.8817 -2953.9689 7.5384846 56.82875 0.15915227 -1.1877331
1600 331.01199 -454.90004 -2967.7708 -2956.5 7.1862592 51.642321 0.17403957 -1.1840985
1700 329.223 2428.4284 -2969.5452 -2958.9073 6.8228029 46.55064 0.19027454 -1.1778276
1800 327.61481 -4757.648 -2971.1105 -2961.1863 6.4445074 41.531675 0.20819854 -1.1712539
1900 318.18741 2226.7765 -2972.6906 -2963.3396 6.0703365 36.848986 0.22378928 -1.1556732
2000 308.79313 -1089.8603 -2974.0899 -2965.3712 5.6913723 32.391718 0.23279863 -1.1445916
2100 303.32047 757.53534 -2975.3597 -2967.2741 5.3153102 28.252523 0.23857925 -1.1465858
2200 307.41102 -837.97246 -2976.4966 -2969.0433 4.9515105 24.517456 0.25216298 -1.1426077
2300 303.01088 1618.29 -2977.5454 -2970.6862 4.593227 21.097734 0.26914071 -1.1356519
2400 297.59385 -3233.8282 -2978.4064 -2972.2049 4.235209 17.936995 0.28804295 -1.1332908
2500 288.72232 5209.2099 -2979.1999 -2973.5963 3.8804647 15.058006 0.31533205 -1.1258312
2600 298.92201 -2193.618 -2979.8873 -2974.8649 3.5301507 12.461964 0.34927897 -1.1048024
2700 282.61818 765.88178 -2980.4563 -2976.0148 3.1852407 10.145758 0.3879755 -1.0655899
2800 273.63104 -389.49749 -2980.8636 -2977.0468 2.8322558 8.021673 0.4259426 -1.0370247
2900 274.12166 -9.2552992 -2981.1421 -2977.9525 2.4816703 6.1586877 0.47721359 -1.0061337
3000 279.43592 212.25445 -2981.2716 -2978.7309 2.1328425 4.5490171 0.5532015 -0.94983292
3100 291.10071 -1139.205 -2981.2475 -2979.3812 1.7828537 3.1785674 0.66452451 -0.83906914
3200 281.53171 3124.6411 -2981.0818 -2979.9003 1.4287164 2.0412304 0.81952022 -0.6386061
3300 277.0223 -2795.9494 -2980.7825 -2980.287 1.0830229 1.1729385 1.0186688 -0.26502454
3400 284.8443 1587.8876 -2980.3701 -2980.5435 0.76893619 0.59126286 1.1646672 0.27529682
3500 281.19 -1143.0785 -2979.8374 -2980.6693 0.54860209 0.30096426 0.79069857 -0.36626891
3600 296.58287 1156.4706 -2979.2182 -2980.6646 0.55745952 0.31076112 0.81914175 -0.31895116
3700 297.24517 -1888.4993 -2978.5352 -2980.5318 0.77195451 0.59591377 1.0713124 -0.027796216
3800 290.81586 3843.3483 -2977.8509 -2980.2819 1.0444771 1.0909324 0.88270245 -0.57339499
3900 300.39456 -5584.8386 -2977.0837 -2979.9273 1.3073719 1.7092212 0.65444496 -0.94023014
4000 306.15811 3310.0105 -2976.5086 -2979.4859 1.5269967 2.3317191 0.45120199 -1.1665402
4100 295.907 -1475.0458 -2975.9096 -2978.9779 1.6878413 2.8488082 0.27738537 -1.2909517
4200 322.70162 933.76586 -2975.3867 -2978.425 1.7872637 3.1943116 0.12322364 -1.3421568
4300 306.69631 -512.7048 -2974.9324 -2977.8465 1.8221493 3.3202281 -0.016769435 -1.3380921
4400 309.23776 226.77219 -2974.5791 -2977.2621 1.788532 3.1988469 -0.14279249 -1.3044784
4500 313.15783 508.29785 -2974.3263 -2976.6947 1.6959722 2.8763217 -0.26351575 -1.2425552
4600 316.26151 -2043.7571 -2974.1697 -2976.1635 1.5525328 2.4103582 -0.38443906 -1.156175
4700 312.27329 1831.682 -2974.1732 -2975.6917 1.3614048 1.8534231 -0.52504872 -1.0383081
4800 307.61066 -1476.0019 -2974.2885 -2975.296 1.1354139 1.2891647 -0.69734331 -0.84719677
4900 305.73489 1303.4848 -2974.5506 -2974.9905 0.8913743 0.79454814 -0.90609876 -0.50216921
5000 309.3774 -1574.6812 -2974.8687 -2974.7812 0.65272109 0.42604482 -1.0613188 0.00291608
5100 304.8602 2679.7476 -2975.3082 -2974.6718 0.4727141 0.22345862 -0.75321909 -0.42028824
5200 297.54226 -5008.0905 -2975.7443 -2974.6646 0.45797515 0.20974124 -0.66557441 -0.64583954
5300 306.18872 4840.4175 -2976.324 -2974.7575 0.61348896 0.3763687 -1.0084709 -0.10258503
5400 299.57661 -2513.1706 -2976.8842 -2974.9472 0.83376011 0.69515592 -0.88189118 -0.55222188
5500 302.30844 1301.3525 -2977.4539 -2975.2244 1.0486412 1.0996484 -0.65075151 -0.94687541
5600 302.11038 -760.79712 -2977.9764 -2975.5765 1.2259535 1.502962 -0.44510538 -1.1709493
5700 294.49825 718.67318 -2978.4584 -2975.9844 1.357155 1.8418697 -0.27309672 -1.2848748
5800 305.97636 -478.64224 -2978.8638 -2976.429 1.4331646 2.0539608 -0.1197893 -1.3417863
5900 291.93868 -419.74179 -2979.2292 -2976.8905 1.4535887 2.1129201 0.024018983 -1.349863
6000 289.50667 859.85085 -2979.5018 -2977.3557 1.4249736 2.0305497 0.15271261 -1.3095465
6100 305.70118 -933.35917 -2979.6877 -2977.8064 1.3480601 1.8172659 0.27785119 -1.2402584
6200 284.37805 1526.0707 -2979.806 -2978.2265 1.2296781 1.5121082 0.40681415 -1.1355005
6300 291.08863 -2156.6708 -2979.8064 -2978.6017 1.0733214 1.1520189 0.54137333 -1.0156432
6400 295.99073 2819.8245 -2979.7378 -2978.9165 0.8941904 0.79957647 0.7073501 -0.82385123
6500 298.06769 -3396.3504 -2979.5428 -2979.1626 0.70228297 0.49320137 0.91043588 -0.48653641
6600 301.78514 5496.6525 -2979.2768 -2979.3329 0.51276653 0.26292952 1.0681056 -0.036293782
6700 290.80665 -5229.4989 -2978.9177 -2979.4217 0.36990055 0.13682642 0.81466085 -0.37332419
6800 296.75761 2401.7807 -2978.5996 -2979.4338 0.34589164 0.11964103 0.65253856 -0.7737558
6900 295.77553 -1521.6269 -2978.1619 -2979.3685 0.46007271 0.21166689 1.0427138 -0.013014477
7000 303.59015 1530.7255 -2977.7097 -2979.225 0.63320287 0.40094588 0.93012255 -0.45527217
7100 297.51038 -3016.4426 -2977.2025 -2979.0103 0.81101521 0.65774567 0.7114444 -0.84465178
7200 293.53789 2705.9808 -2976.7651 -2978.7294 0.97512025 0.95085951 0.52979295 -1.0479526
7300 301.78809 -1042.1076 -2976.3388 -2978.3998 1.1024575 1.2154126 0.35564664 -1.2137023
7400 307.50053 214.56923 -2975.9581 -2978.0341 1.188001 1.4113463 0.20025025 -1.3077784
7500 301.98985 281.86495 -2975.6146 -2977.6451 1.2301918 1.5133718 0.063886193 -1.3465506
7600 318.37347 -1145.7795 -2975.3473 -2977.2486 1.2295055 1.5116837 -0.066939137 -1.3475567
7700 314.94512 4536.9887 -2975.1351 -2976.8564 1.1948121 1.427576 -0.19450637 -1.2864658
7800 312.91485 -2980.6408 -2975.0156 -2976.4828 1.1134406 1.2397499 -0.32749726 -1.207718
7900 310.06854 2244.3877 -2975.0094 -2976.1462 0.99080702 0.98169854 -0.48336959 -1.0840695
8000 308.55007 -2427.1464 -2975.0491 -2975.8566 0.83800849 0.70225823 -0.65822117 -0.89212512
8100 323.02796 3187.4728 -2975.2081 -2975.6251 0.66510054 0.44235872 -0.84857729 -0.62984027
8200 327.05029 -6447.7875 -2975.3162 -2975.4608 0.49730291 0.24731018 -1.0534735 -0.14095413
8300 311.194 4273.1174 -2975.7217 -2975.3642 0.35491458 0.12596436 -0.95967595 -0.04445204
8400 290.61931 -2301.019 -2976.0963 -2975.3446 0.31530296 0.09941596 -0.69056625 -0.72257435
8500 314.00559 1966.1297 -2976.5206 -2975.3995 0.41659574 0.17355201 -1.1134124 0.18107632
8600 288.26541 -1608.4524 -2976.9304 -2975.526 0.57968749 0.33603759 -1.0014591 -0.34698354
8700 298.92083 1353.9988 -2977.355 -2975.7203 0.74176087 0.55020919 -0.74109062 -0.86227705
8800 299.97274 -638.68301 -2977.766 -2975.9682 0.87950613 0.77353104 -0.50839929 -1.1555064
8900 300.66443 -279.62514 -2978.1476 -2976.262 0.99526406 0.99055054 -0.33059914 -1.261881
9000 290.44715 489.06352 -2978.4892 -2976.5918 1.0763797 1.1585932 -0.17871557 -1.3082755
9100 289.06733 -1063.4482 -2978.784 -2976.943 1.1174524 1.2486999 -0.037767225 -1.3120851
9200 297.63931 2664.6535 -2979.0202 -2977.3033 1.1127042 1.2381106 0.090936095 -1.2913777
9300 297.9983 -4684.428 -2979.1316 -2977.6563 1.0596342 1.1228247 0.20756305 -1.2867214
9400 285.14009 2779.1548 -2979.2804 -2977.9868 0.98034602 0.96107833 0.33668495 -1.2294268
9500 284.11569 -2437.5003 -2979.2918 -2978.2852 0.87286876 0.76189987 0.48407552 -1.1274969
9600 291.97193 2772.1396 -2979.2473 -2978.5402 0.74294711 0.55197041 0.67450455 -0.91152584
9700 292.59563 -3615.4496 -2979.0801 -2978.7442 0.59448857 0.35341666 0.91630006 -0.47180257
9800 296.1785 4869.2744 -2978.8849 -2978.891 0.43463281 0.18890568 1.1020846 0.093881572
9900 298.44745 -3587.7391 -2978.5978 -2978.9712 0.30680426 0.094128854 0.8532075 -0.19634913
10000 297.99863 1312.5643 -2978.3205 -2978.9854 0.27829395 0.077447522 0.60818263 -0.79004935
Loop time of 15.3108 on 4 procs for 10000 steps with 864 atoms
Performance: 112.862 ns/day, 0.213 hours/ns, 653.136 timesteps/s, 564.309 katom-step/s
92.4% CPU use with 4 MPI tasks x 1 OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 11.428 | 12.158 | 12.621 | 13.0 | 79.41
Neigh | 0.0019158 | 0.0020708 | 0.002163 | 0.2 | 0.01
Comm | 1.936 | 2.3948 | 3.0967 | 28.3 | 15.64
Output | 0.0026067 | 0.0037308 | 0.0066123 | 2.7 | 0.02
Modify | 0.44688 | 0.45929 | 0.47131 | 1.6 | 3.00
Other | | 0.2928 | | | 1.91
Nlocal: 216 ave 224 max 204 min
Histogram: 1 0 0 0 0 0 0 2 0 1
Nghost: 2147 ave 2159 max 2139 min
Histogram: 1 0 0 2 0 0 0 0 0 1
Neighs: 24185.8 ave 26045 max 21309 min
Histogram: 1 0 0 0 0 1 0 0 0 2
Total # of neighbors = 96743
Ave neighs/atom = 111.97106
Neighbor list builds = 1
Dangerous builds = 0
Total wall time: 0:00:15

178
examples/PACKAGES/moments/log.02May2025.valtest.g++.1 Normal file
View File

@ -0,0 +1,178 @@
LAMMPS (2 Apr 2025 - Development - patch_4Feb2025-645-gba166d42e1-modified)
OMP_NUM_THREADS environment is not set. Defaulting to 1 thread. (src/comm.cpp:99)
using 1 OpenMP thread(s) per MPI task
# create pure copper system
units metal
lattice fcc 3.75
Lattice spacing in x,y,z = 3.75 3.75 3.75
region box block 0 6 0 6 0 6
create_box 2 box
Created orthogonal box = (0 0 0) to (22.5 22.5 22.5)
1 by 1 by 1 MPI processor grid
timestep 0.002
create_atoms 1 box
Created 864 atoms
using lattice units in orthogonal box = (0 0 0) to (22.5 22.5 22.5)
create_atoms CPU = 0.001 seconds
pair_style eam/alloy
pair_coeff * * AlCu.eam.alloy Cu Al
# Initialize to a high temperature, then cool in npt ensemble
velocity all create 1000.0 6567345
fix 1 all npt temp 300.0 300.0 $(500*dt) iso 0.0 0.0 $(100*dt)
fix 1 all npt temp 300.0 300.0 1 iso 0.0 0.0 $(100*dt)
fix 1 all npt temp 300.0 300.0 1 iso 0.0 0.0 0.2000000000000000111
variable toteng equal "etotal"
fix 2 all ave/moments 1 10 10 v_toteng mean variance skew kurtosis
thermo_style custom step etotal f_2[*]
thermo_modify format float %14.8f
thermo 1
run 100
Neighbor list info ...
update: every = 1 steps, delay = 0 steps, check = yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 8.6825
ghost atom cutoff = 8.6825
binsize = 4.34125, bins = 6 6 6
1 neighbor lists, perpetual/occasional/extra = 1 0 0
(1) pair eam/alloy, 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) = 3.484 | 3.484 | 3.484 Mbytes
Step TotEng f_2[1] f_2[2] f_2[3] f_2[4]
0 -2884.91592826 0.00000000 0.00000000 0.00000000 0.00000000
1 -2888.74461907 0.00000000 0.00000000 0.00000000 0.00000000
2 -2898.78491936 0.00000000 0.00000000 0.00000000 0.00000000
3 -2910.70619667 0.00000000 0.00000000 0.00000000 0.00000000
4 -2919.41734302 0.00000000 0.00000000 0.00000000 0.00000000
5 -2923.24980175 0.00000000 0.00000000 0.00000000 0.00000000
6 -2923.79800148 0.00000000 0.00000000 0.00000000 0.00000000
7 -2922.97580252 0.00000000 0.00000000 0.00000000 0.00000000
8 -2921.95601941 0.00000000 0.00000000 0.00000000 0.00000000
9 -2921.45319499 0.00000000 0.00000000 0.00000000 0.00000000
10 -2921.81460149 -2915.29004998 148.32538381 1.60272422 1.50844200
11 -2923.00059466 -2915.29004998 148.32538381 1.60272422 1.50844200
12 -2924.63075671 -2915.29004998 148.32538381 1.60272422 1.50844200
13 -2926.18037946 -2915.29004998 148.32538381 1.60272422 1.50844200
14 -2927.22356281 -2915.29004998 148.32538381 1.60272422 1.50844200
15 -2927.62053073 -2915.29004998 148.32538381 1.60272422 1.50844200
16 -2927.49949128 -2915.29004998 148.32538381 1.60272422 1.50844200
17 -2927.12292174 -2915.29004998 148.32538381 1.60272422 1.50844200
18 -2926.73637250 -2915.29004998 148.32538381 1.60272422 1.50844200
19 -2926.49482990 -2915.29004998 148.32538381 1.60272422 1.50844200
20 -2926.44714720 -2926.29565870 2.07215006 1.62317861 2.37019300
21 -2926.56102718 -2926.29565870 2.07215006 1.62317861 2.37019300
22 -2926.76734347 -2926.29565870 2.07215006 1.62317861 2.37019300
23 -2926.98403044 -2926.29565870 2.07215006 1.62317861 2.37019300
24 -2927.15193693 -2926.29565870 2.07215006 1.62317861 2.37019300
25 -2927.24498540 -2926.29565870 2.07215006 1.62317861 2.37019300
26 -2927.26914121 -2926.29565870 2.07215006 1.62317861 2.37019300
27 -2927.25021402 -2926.29565870 2.07215006 1.62317861 2.37019300
28 -2927.21637817 -2926.29565870 2.07215006 1.62317861 2.37019300
29 -2927.19085616 -2926.29565870 2.07215006 1.62317861 2.37019300
30 -2927.18360687 -2927.08195198 0.05722486 1.54894969 1.44984748
31 -2927.19243579 -2927.08195198 0.05722486 1.54894969 1.44984748
32 -2927.20805612 -2927.08195198 0.05722486 1.54894969 1.44984748
33 -2927.22285606 -2927.08195198 0.05722486 1.54894969 1.44984748
34 -2927.23274852 -2927.08195198 0.05722486 1.54894969 1.44984748
35 -2927.23953263 -2927.08195198 0.05722486 1.54894969 1.44984748
36 -2927.24805761 -2927.08195198 0.05722486 1.54894969 1.44984748
37 -2927.26215638 -2927.08195198 0.05722486 1.54894969 1.44984748
38 -2927.28298252 -2927.08195198 0.05722486 1.54894969 1.44984748
39 -2927.31025065 -2927.08195198 0.05722486 1.54894969 1.44984748
40 -2927.33874897 -2927.25378252 0.00209108 -0.65432756 -0.21113798
41 -2927.36224413 -2927.25378252 0.00209108 -0.65432756 -0.21113798
42 -2927.37729800 -2927.25378252 0.00209108 -0.65432756 -0.21113798
43 -2927.38671916 -2927.25378252 0.00209108 -0.65432756 -0.21113798
44 -2927.39115082 -2927.25378252 0.00209108 -0.65432756 -0.21113798
45 -2927.39614318 -2927.25378252 0.00209108 -0.65432756 -0.21113798
46 -2927.40444730 -2927.25378252 0.00209108 -0.65432756 -0.21113798
47 -2927.41888601 -2927.25378252 0.00209108 -0.65432756 -0.21113798
48 -2927.43954388 -2927.25378252 0.00209108 -0.65432756 -0.21113798
49 -2927.46210058 -2927.25378252 0.00209108 -0.65432756 -0.21113798
50 -2927.48270024 -2927.41212333 0.00148630 -0.72914987 -0.39161968
51 -2927.49822500 -2927.41212333 0.00148630 -0.72914987 -0.39161968
52 -2927.50765361 -2927.41212333 0.00148630 -0.72914987 -0.39161968
53 -2927.51223225 -2927.41212333 0.00148630 -0.72914987 -0.39161968
54 -2927.51510653 -2927.41212333 0.00148630 -0.72914987 -0.39161968
55 -2927.52035921 -2927.41212333 0.00148630 -0.72914987 -0.39161968
56 -2927.53170012 -2927.41212333 0.00148630 -0.72914987 -0.39161968
57 -2927.54910408 -2927.41212333 0.00148630 -0.72914987 -0.39161968
58 -2927.57357292 -2927.41212333 0.00148630 -0.72914987 -0.39161968
59 -2927.60356966 -2927.41212333 0.00148630 -0.72914987 -0.39161968
60 -2927.63344447 -2927.54449679 0.00204640 -1.06571776 0.04430271
61 -2927.66186165 -2927.54449679 0.00204640 -1.06571776 0.04430271
62 -2927.68810360 -2927.54449679 0.00204640 -1.06571776 0.04430271
63 -2927.71163480 -2927.54449679 0.00204640 -1.06571776 0.04430271
64 -2927.73036225 -2927.54449679 0.00204640 -1.06571776 0.04430271
65 -2927.74726656 -2927.54449679 0.00204640 -1.06571776 0.04430271
66 -2927.76525638 -2927.54449679 0.00204640 -1.06571776 0.04430271
67 -2927.78432762 -2927.54449679 0.00204640 -1.06571776 0.04430271
68 -2927.80305095 -2927.54449679 0.00204640 -1.06571776 0.04430271
69 -2927.82406714 -2927.54449679 0.00204640 -1.06571776 0.04430271
70 -2927.84622122 -2927.75621522 0.00356092 0.06232090 -0.94076248
71 -2927.86886493 -2927.75621522 0.00356092 0.06232090 -0.94076248
72 -2927.89150302 -2927.75621522 0.00356092 0.06232090 -0.94076248
73 -2927.91480122 -2927.75621522 0.00356092 0.06232090 -0.94076248
74 -2927.93739399 -2927.75621522 0.00356092 0.06232090 -0.94076248
75 -2927.96075707 -2927.75621522 0.00356092 0.06232090 -0.94076248
76 -2927.98525702 -2927.75621522 0.00356092 0.06232090 -0.94076248
77 -2928.00918972 -2927.75621522 0.00356092 0.06232090 -0.94076248
78 -2928.03266453 -2927.75621522 0.00356092 0.06232090 -0.94076248
79 -2928.05673430 -2927.75621522 0.00356092 0.06232090 -0.94076248
80 -2928.08120268 -2927.97383685 0.00511363 -0.03242365 -1.20956903
81 -2928.10618717 -2927.97383685 0.00511363 -0.03242365 -1.20956903
82 -2928.13191751 -2927.97383685 0.00511363 -0.03242365 -1.20956903
83 -2928.15675025 -2927.97383685 0.00511363 -0.03242365 -1.20956903
84 -2928.18178044 -2927.97383685 0.00511363 -0.03242365 -1.20956903
85 -2928.20538210 -2927.97383685 0.00511363 -0.03242365 -1.20956903
86 -2928.22991006 -2927.97383685 0.00511363 -0.03242365 -1.20956903
87 -2928.25238345 -2927.97383685 0.00511363 -0.03242365 -1.20956903
88 -2928.27490378 -2927.97383685 0.00511363 -0.03242365 -1.20956903
89 -2928.29697980 -2927.97383685 0.00511363 -0.03242365 -1.20956903
90 -2928.31902032 -2928.21552149 0.00511983 0.08421866 -1.19120544
91 -2928.34079951 -2928.21552149 0.00511983 0.08421866 -1.19120544
92 -2928.36448072 -2928.21552149 0.00511983 0.08421866 -1.19120544
93 -2928.38918869 -2928.21552149 0.00511983 0.08421866 -1.19120544
94 -2928.41578734 -2928.21552149 0.00511983 0.08421866 -1.19120544
95 -2928.44466633 -2928.21552149 0.00511983 0.08421866 -1.19120544
96 -2928.47414034 -2928.21552149 0.00511983 0.08421866 -1.19120544
97 -2928.50507273 -2928.21552149 0.00511983 0.08421866 -1.19120544
98 -2928.53751007 -2928.21552149 0.00511983 0.08421866 -1.19120544
99 -2928.56947939 -2928.21552149 0.00511983 0.08421866 -1.19120544
100 -2928.60000318 -2928.46411283 0.00779929 -0.14908790 -1.24292534
Loop time of 0.579661 on 1 procs for 100 steps with 864 atoms
Performance: 29.811 ns/day, 0.805 hours/ns, 172.515 timesteps/s, 149.053 katom-step/s
96.3% CPU use with 1 MPI tasks x 1 OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 0.54316 | 0.54316 | 0.54316 | 0.0 | 93.70
Neigh | 0.0041212 | 0.0041212 | 0.0041212 | 0.0 | 0.71
Comm | 0.0034702 | 0.0034702 | 0.0034702 | 0.0 | 0.60
Output | 0.014085 | 0.014085 | 0.014085 | 0.0 | 2.43
Modify | 0.01321 | 0.01321 | 0.01321 | 0.0 | 2.28
Other | | 0.001612 | | | 0.28
Nlocal: 864 ave 864 max 864 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Nghost: 3767 ave 3767 max 3767 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Neighs: 96746 ave 96746 max 96746 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Total # of neighbors = 96746
Ave neighs/atom = 111.97454
Neighbor list builds = 1
Dangerous builds = 0
Total wall time: 0:00:00

178
examples/PACKAGES/moments/log.02May2025.valtest.g++.4 Normal file
View File

@ -0,0 +1,178 @@
LAMMPS (2 Apr 2025 - Development - patch_4Feb2025-645-gba166d42e1-modified)
OMP_NUM_THREADS environment is not set. Defaulting to 1 thread. (src/comm.cpp:99)
using 1 OpenMP thread(s) per MPI task
# create pure copper system
units metal
lattice fcc 3.75
Lattice spacing in x,y,z = 3.75 3.75 3.75
region box block 0 6 0 6 0 6
create_box 2 box
Created orthogonal box = (0 0 0) to (22.5 22.5 22.5)
1 by 2 by 2 MPI processor grid
timestep 0.002
create_atoms 1 box
Created 864 atoms
using lattice units in orthogonal box = (0 0 0) to (22.5 22.5 22.5)
create_atoms CPU = 0.001 seconds
pair_style eam/alloy
pair_coeff * * AlCu.eam.alloy Cu Al
# Initialize to a high temperature, then cool in npt ensemble
velocity all create 1000.0 6567345
fix 1 all npt temp 300.0 300.0 $(500*dt) iso 0.0 0.0 $(100*dt)
fix 1 all npt temp 300.0 300.0 1 iso 0.0 0.0 $(100*dt)
fix 1 all npt temp 300.0 300.0 1 iso 0.0 0.0 0.2000000000000000111
variable toteng equal "etotal"
fix 2 all ave/moments 1 10 10 v_toteng mean variance skew kurtosis
thermo_style custom step etotal f_2[*]
thermo_modify format float %14.8f
thermo 1
run 100
Neighbor list info ...
update: every = 1 steps, delay = 0 steps, check = yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 8.6825
ghost atom cutoff = 8.6825
binsize = 4.34125, bins = 6 6 6
1 neighbor lists, perpetual/occasional/extra = 1 0 0
(1) pair eam/alloy, 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) = 3.42 | 3.42 | 3.42 Mbytes
Step TotEng f_2[1] f_2[2] f_2[3] f_2[4]
0 -2884.91592826 0.00000000 0.00000000 0.00000000 0.00000000
1 -2888.74473521 0.00000000 0.00000000 0.00000000 0.00000000
2 -2898.78463435 0.00000000 0.00000000 0.00000000 0.00000000
3 -2910.70366466 0.00000000 0.00000000 0.00000000 0.00000000
4 -2919.40999553 0.00000000 0.00000000 0.00000000 0.00000000
5 -2923.23570887 0.00000000 0.00000000 0.00000000 0.00000000
6 -2923.77707961 0.00000000 0.00000000 0.00000000 0.00000000
7 -2922.94386730 0.00000000 0.00000000 0.00000000 0.00000000
8 -2921.92251474 0.00000000 0.00000000 0.00000000 0.00000000
9 -2921.42476103 0.00000000 0.00000000 0.00000000 0.00000000
10 -2921.79501042 -2915.27419717 148.08574615 1.60354430 1.51194865
11 -2922.99498349 -2915.27419717 148.08574615 1.60354430 1.51194865
12 -2924.64023395 -2915.27419717 148.08574615 1.60354430 1.51194865
13 -2926.19980790 -2915.27419717 148.08574615 1.60354430 1.51194865
14 -2927.25022454 -2915.27419717 148.08574615 1.60354430 1.51194865
15 -2927.64953875 -2915.27419717 148.08574615 1.60354430 1.51194865
16 -2927.52804735 -2915.27419717 148.08574615 1.60354430 1.51194865
17 -2927.14916045 -2915.27419717 148.08574615 1.60354430 1.51194865
18 -2926.76078244 -2915.27419717 148.08574615 1.60354430 1.51194865
19 -2926.51878380 -2915.27419717 148.08574615 1.60354430 1.51194865
20 -2926.47129883 -2926.31628615 2.10313655 1.62594474 2.38000930
21 -2926.59030835 -2926.31628615 2.10313655 1.62594474 2.38000930
22 -2926.80121221 -2926.31628615 2.10313655 1.62594474 2.38000930
23 -2927.02526150 -2926.31628615 2.10313655 1.62594474 2.38000930
24 -2927.20079704 -2926.31628615 2.10313655 1.62594474 2.38000930
25 -2927.30192483 -2926.31628615 2.10313655 1.62594474 2.38000930
26 -2927.33194351 -2926.31628615 2.10313655 1.62594474 2.38000930
27 -2927.31647527 -2926.31628615 2.10313655 1.62594474 2.38000930
28 -2927.28391864 -2926.31628615 2.10313655 1.62594474 2.38000930
29 -2927.25821953 -2926.31628615 2.10313655 1.62594474 2.38000930
30 -2927.25085808 -2927.13609190 0.06387000 1.52055179 1.31247839
31 -2927.25723201 -2927.13609190 0.06387000 1.52055179 1.31247839
32 -2927.27197789 -2927.13609190 0.06387000 1.52055179 1.31247839
33 -2927.28667044 -2927.13609190 0.06387000 1.52055179 1.31247839
34 -2927.29879455 -2927.13609190 0.06387000 1.52055179 1.31247839
35 -2927.30701891 -2927.13609190 0.06387000 1.52055179 1.31247839
36 -2927.31785921 -2927.13609190 0.06387000 1.52055179 1.31247839
37 -2927.33272014 -2927.13609190 0.06387000 1.52055179 1.31247839
38 -2927.35282056 -2927.13609190 0.06387000 1.52055179 1.31247839
39 -2927.37849130 -2927.13609190 0.06387000 1.52055179 1.31247839
40 -2927.40448350 -2927.32080685 0.00219675 -0.52051260 -0.50322958
41 -2927.42423249 -2927.32080685 0.00219675 -0.52051260 -0.50322958
42 -2927.43769919 -2927.32080685 0.00219675 -0.52051260 -0.50322958
43 -2927.44493813 -2927.32080685 0.00219675 -0.52051260 -0.50322958
44 -2927.44923137 -2927.32080685 0.00219675 -0.52051260 -0.50322958
45 -2927.45439729 -2927.32080685 0.00219675 -0.52051260 -0.50322958
46 -2927.46365674 -2927.32080685 0.00219675 -0.52051260 -0.50322958
47 -2927.48173952 -2927.32080685 0.00219675 -0.52051260 -0.50322958
48 -2927.50371663 -2927.32080685 0.00219675 -0.52051260 -0.50322958
49 -2927.52750629 -2927.32080685 0.00219675 -0.52051260 -0.50322958
50 -2927.54872274 -2927.47358404 0.00168128 -0.79883601 -0.48497973
51 -2927.56277664 -2927.47358404 0.00168128 -0.79883601 -0.48497973
52 -2927.57050508 -2927.47358404 0.00168128 -0.79883601 -0.48497973
53 -2927.57241043 -2927.47358404 0.00168128 -0.79883601 -0.48497973
54 -2927.57517748 -2927.47358404 0.00168128 -0.79883601 -0.48497973
55 -2927.58161786 -2927.47358404 0.00168128 -0.79883601 -0.48497973
56 -2927.59393740 -2927.47358404 0.00168128 -0.79883601 -0.48497973
57 -2927.61367876 -2927.47358404 0.00168128 -0.79883601 -0.48497973
58 -2927.64096296 -2927.47358404 0.00168128 -0.79883601 -0.48497973
59 -2927.67356621 -2927.47358404 0.00168128 -0.79883601 -0.48497973
60 -2927.70625176 -2927.60908846 0.00241645 -1.10903745 0.07175615
61 -2927.73673853 -2927.60908846 0.00241645 -1.10903745 0.07175615
62 -2927.76292153 -2927.60908846 0.00241645 -1.10903745 0.07175615
63 -2927.78541405 -2927.60908846 0.00241645 -1.10903745 0.07175615
64 -2927.80292853 -2927.60908846 0.00241645 -1.10903745 0.07175615
65 -2927.81988675 -2927.60908846 0.00241645 -1.10903745 0.07175615
66 -2927.83680256 -2927.60908846 0.00241645 -1.10903745 0.07175615
67 -2927.85379296 -2927.60908846 0.00241645 -1.10903745 0.07175615
68 -2927.87418119 -2927.60908846 0.00241645 -1.10903745 0.07175615
69 -2927.89451588 -2927.60908846 0.00241645 -1.10903745 0.07175615
70 -2927.91602570 -2927.82832077 0.00334657 0.04700770 -0.91589129
71 -2927.93874793 -2927.82832077 0.00334657 0.04700770 -0.91589129
72 -2927.96195498 -2927.82832077 0.00334657 0.04700770 -0.91589129
73 -2927.98521535 -2927.82832077 0.00334657 0.04700770 -0.91589129
74 -2928.01060565 -2927.82832077 0.00334657 0.04700770 -0.91589129
75 -2928.03584561 -2927.82832077 0.00334657 0.04700770 -0.91589129
76 -2928.06090892 -2927.82832077 0.00334657 0.04700770 -0.91589129
77 -2928.08509438 -2927.82832077 0.00334657 0.04700770 -0.91589129
78 -2928.11095399 -2927.82832077 0.00334657 0.04700770 -0.91589129
79 -2928.13711339 -2927.82832077 0.00334657 0.04700770 -0.91589129
80 -2928.16413424 -2928.04905744 0.00575008 -0.05409710 -1.19501222
81 -2928.19005959 -2928.04905744 0.00575008 -0.05409710 -1.19501222
82 -2928.21654649 -2928.04905744 0.00575008 -0.05409710 -1.19501222
83 -2928.24249986 -2928.04905744 0.00575008 -0.05409710 -1.19501222
84 -2928.26861892 -2928.04905744 0.00575008 -0.05409710 -1.19501222
85 -2928.29480718 -2928.04905744 0.00575008 -0.05409710 -1.19501222
86 -2928.32144325 -2928.04905744 0.00575008 -0.05409710 -1.19501222
87 -2928.34727619 -2928.04905744 0.00575008 -0.05409710 -1.19501222
88 -2928.37131285 -2928.04905744 0.00575008 -0.05409710 -1.19501222
89 -2928.39531126 -2928.04905744 0.00575008 -0.05409710 -1.19501222
90 -2928.41739503 -2928.30652706 0.00595440 0.06693205 -1.24851322
91 -2928.43978811 -2928.30652706 0.00595440 0.06693205 -1.24851322
92 -2928.46316822 -2928.30652706 0.00595440 0.06693205 -1.24851322
93 -2928.48654219 -2928.30652706 0.00595440 0.06693205 -1.24851322
94 -2928.51132482 -2928.30652706 0.00595440 0.06693205 -1.24851322
95 -2928.53938009 -2928.30652706 0.00595440 0.06693205 -1.24851322
96 -2928.56852408 -2928.30652706 0.00595440 0.06693205 -1.24851322
97 -2928.59814410 -2928.30652706 0.00595440 0.06693205 -1.24851322
98 -2928.62787940 -2928.30652706 0.00595440 0.06693205 -1.24851322
99 -2928.65853178 -2928.30652706 0.00595440 0.06693205 -1.24851322
100 -2928.68735978 -2928.55806426 0.00711607 -0.13829819 -1.25519738
Loop time of 0.327437 on 4 procs for 100 steps with 864 atoms
Performance: 52.774 ns/day, 0.455 hours/ns, 305.402 timesteps/s, 263.868 katom-step/s
91.9% CPU use with 4 MPI tasks x 1 OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 0.27213 | 0.27259 | 0.27312 | 0.1 | 83.25
Neigh | 0.00096945 | 0.0015991 | 0.0022533 | 1.5 | 0.49
Comm | 0.026726 | 0.027088 | 0.027516 | 0.2 | 8.27
Output | 0.0029839 | 0.0048706 | 0.0097487 | 4.0 | 1.49
Modify | 0.012374 | 0.016834 | 0.018623 | 2.0 | 5.14
Other | | 0.004455 | | | 1.36
Nlocal: 216 ave 224 max 204 min
Histogram: 1 0 0 0 0 0 0 2 0 1
Nghost: 2147 ave 2159 max 2139 min
Histogram: 1 0 0 2 0 0 0 0 0 1
Neighs: 24185.8 ave 26045 max 21309 min
Histogram: 1 0 0 0 0 1 0 0 0 2
Total # of neighbors = 96743
Ave neighs/atom = 111.97106
Neighbor list builds = 1
Dangerous builds = 0
Total wall time: 0:00:00

1
examples/PACKAGES/neighbor-swap/MoCoNiVFeAlCr_2nn.meam Symbolic link
View File

@ -0,0 +1 @@
../../../potentials/MoCoNiVFeAlCr_2nn.meam

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