diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS index 59a937faba..1a7a35e61f 100644 --- a/.github/CODEOWNERS +++ b/.github/CODEOWNERS @@ -50,6 +50,7 @@ src/PTM/* @pmla src/QMMM/* @akohlmey src/REACTION/* @jrgissing src/REAXFF/* @hasanmetin @stanmoore1 +src/RHEO/* @jtclemm src/SCAFACOS/* @rhalver src/SNAP/* @athomps src/SPIN/* @julient31 @@ -65,6 +66,9 @@ src/MANYBODY/pair_vashishta_table.* @andeplane src/MANYBODY/pair_atm.* @sergeylishchuk src/MANYBODY/pair_nb3b_screened.* @flodesani src/REPLICA/*_grem.* @dstelter92 +src/EXTRA-COMMAND/geturl.* @akohlmey +src/EXTRA-COMMAND/group_ndx.* @akohlmey +src/EXTRA-COMMAND/ndx_group.* @akohlmey src/EXTRA-COMPUTE/compute_stress_mop*.* @RomainVermorel src/EXTRA-COMPUTE/compute_born_matrix.* @Bibobu @athomps src/EXTRA-FIX/fix_deform_pressure.* @jtclemm @@ -95,9 +99,10 @@ src/fix.* @sjplimp src/force.* @sjplimp src/group.* @sjplimp src/improper.* @sjplimp +src/info.* @akohlmey src/kspace.* @sjplimp src/lmptyp.h @sjplimp -src/library.* @sjplimp +src/library.* @sjplimp @akohlmey src/main.cpp @sjplimp src/min_*.* @sjplimp src/memory.* @sjplimp @@ -105,12 +110,12 @@ src/modify.* @sjplimp @stanmoore1 src/molecule.* @sjplimp src/my_page.h @sjplimp src/my_pool_chunk.h @sjplimp -src/npair*.* @sjplimp -src/ntopo*.* @sjplimp -src/nstencil*.* @sjplimp -src/neighbor.* @sjplimp -src/nbin*.* @sjplimp -src/neigh_*.* @sjplimp +src/npair*.* @sjplimp @jtclemm +src/ntopo*.* @sjplimp @jtclemm +src/nstencil*.* @sjplimp @jtclemm +src/neighbor.* @sjplimp @jtclemm +src/nbin*.* @sjplimp @jtclemm +src/neigh_*.* @sjplimp @jtclemm src/output.* @sjplimp src/pair.* @sjplimp src/rcb.* @sjplimp diff --git a/.github/workflows/check-vla.yml b/.github/workflows/check-vla.yml new file mode 100644 index 0000000000..26f23cc33f --- /dev/null +++ b/.github/workflows/check-vla.yml @@ -0,0 +1,89 @@ +# GitHub action to build LAMMPS on Linux with gcc and -Werror=vla +name: "Check for Variable Length Arrays" + +on: + push: + branches: + - develop + pull_request: + branches: + - develop + + workflow_dispatch: + +jobs: + build: + name: Build with -Werror=vla + if: ${{ github.repository == 'lammps/lammps' }} + runs-on: ubuntu-latest + env: + CCACHE_DIR: ${{ github.workspace }}/.ccache + + steps: + - name: Checkout repository + uses: actions/checkout@v4 + with: + fetch-depth: 2 + + - name: Install extra packages + run: | + sudo apt-get install -y ccache \ + libeigen3-dev \ + libgsl-dev \ + libcurl4-openssl-dev \ + mold \ + mpi-default-bin \ + mpi-default-dev \ + ninja-build \ + python3-dev + + - name: Create Build Environment + run: mkdir build + + - name: Set up ccache + uses: actions/cache@v4 + with: + path: ${{ env.CCACHE_DIR }} + key: linux-vla-ccache-${{ github.sha }} + restore-keys: linux-vla-ccache- + + - name: Building LAMMPS via CMake + shell: bash + run: | + ccache -z + python3 -m venv linuxenv + source linuxenv/bin/activate + python3 -m pip install numpy + python3 -m pip install pyyaml + cmake -S cmake -B build \ + -C cmake/presets/most.cmake \ + -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 -Werror=vla" \ + -D DOWNLOAD_POTENTIALS=off \ + -D BUILD_MPI=on \ + -D BUILD_SHARED_LIBS=off \ + -D BUILD_TOOLS=off \ + -D ENABLE_TESTING=off \ + -D MLIAP_ENABLE_ACE=on \ + -D MLIAP_ENABLE_PYTHON=off \ + -D PKG_AWPMD=on \ + -D PKG_GPU=on \ + -D GPU_API=opencl \ + -D PKG_LATBOLTZ=on \ + -D PKG_MDI=on \ + -D PKG_MANIFOLD=on \ + -D PKG_ML-PACE=on \ + -D PKG_ML-RANN=off \ + -D PKG_MOLFILE=on \ + -D PKG_RHEO=on \ + -D PKG_PTM=on \ + -D PKG_PYTHON=on \ + -D PKG_QTB=on \ + -D PKG_SMTBQ=on \ + -G Ninja + cmake --build build + ccache -s diff --git a/.github/workflows/compile-msvc.yml b/.github/workflows/compile-msvc.yml index 1a0f1ea62f..e384f191e5 100644 --- a/.github/workflows/compile-msvc.yml +++ b/.github/workflows/compile-msvc.yml @@ -1,5 +1,5 @@ # GitHub action to build LAMMPS on Windows with Visual C++ -name: "Native Windows Compilation and Unit Tests" +name: "Windows Unit Tests" on: push: @@ -16,6 +16,8 @@ jobs: name: Windows Compilation Test if: ${{ github.repository == 'lammps/lammps' }} runs-on: windows-latest + env: + CCACHE_DIR: ${{ github.workspace }}/.ccache steps: - name: Checkout repository @@ -23,36 +25,41 @@ jobs: with: fetch-depth: 2 + - name: Enable MSVC++ + uses: lammps/setup-msvc-dev@v3 + with: + arch: x64 + + - name: Install Ccache + run: | + choco install ccache ninja -y + + - name: Set up ccache + uses: actions/cache@v4 + with: + path: ${{ env.CCACHE_DIR }} + key: win-unit-ccache-${{ github.sha }} + restore-keys: win-unit-ccache- + - name: Select Python version uses: actions/setup-python@v5 with: python-version: '3.11' - name: Building LAMMPS via CMake - shell: bash run: | + ccache -z python3 -m pip install numpy python3 -m pip install pyyaml - nuget install MSMPIsdk - nuget install MSMPIDIST - cmake -C cmake/presets/windows.cmake \ - -D DOWNLOAD_POTENTIALS=off \ - -D PKG_PYTHON=on \ - -D WITH_PNG=off \ - -D WITH_JPEG=off \ - -S cmake -B build \ - -D BUILD_SHARED_LIBS=on \ - -D LAMMPS_EXCEPTIONS=on \ - -D ENABLE_TESTING=on - cmake --build build --config Release --parallel 2 + cmake -C cmake\presets\windows.cmake -D CMAKE_CXX_COMPILER=cl -D CMAKE_CXX_COMPILER_LAUNCHER=ccache -D CMAKE_C_COMPILER=cl -D CMAKE_C_COMPILER_LAUNCHER=ccache -D CMAKE_Fortran_COMPILER="" -D DOWNLOAD_POTENTIALS=off -D PKG_PYTHON=on -D WITH_PNG=off -D WITH_JPEG=off -S cmake -B build -D BUILD_SHARED_LIBS=on -D ENABLE_TESTING=on -D CMAKE_BUILD_TYPE=Release -G Ninja + cmake --build build + ccache -s - name: Run LAMMPS executable - shell: bash run: | - ./build/Release/lmp.exe -h - ./build/Release/lmp.exe -in bench/in.lj + build\lmp.exe -h + build\lmp.exe -in bench\in.lj - name: Run Unit Tests working-directory: build - shell: bash - run: ctest -V -C Release -E FixTimestep:python_move_nve + run: ctest -V -E FixTimestep:python_move_nve diff --git a/.github/workflows/unittest-linux.yml b/.github/workflows/unittest-linux.yml new file mode 100644 index 0000000000..366db25a99 --- /dev/null +++ b/.github/workflows/unittest-linux.yml @@ -0,0 +1,82 @@ +# GitHub action to build LAMMPS on Linux and run standard unit tests +name: "Unittest for Linux /w LAMMPS_BIGBIG" + +on: + push: + branches: + - develop + pull_request: + branches: + - develop + + workflow_dispatch: + +jobs: + build: + name: Linux Unit Test + if: ${{ github.repository == 'lammps/lammps' }} + runs-on: ubuntu-latest + env: + CCACHE_DIR: ${{ github.workspace }}/.ccache + + steps: + - name: Checkout repository + uses: actions/checkout@v4 + with: + fetch-depth: 2 + + - name: Install extra packages + run: | + sudo apt-get install -y ccache \ + libeigen3-dev \ + libgsl-dev \ + libcurl4-openssl-dev \ + mold \ + ninja-build \ + python3-dev + + - name: Create Build Environment + run: mkdir build + + - name: Set up ccache + uses: actions/cache@v4 + with: + path: ${{ env.CCACHE_DIR }} + key: linux-unit-ccache-${{ github.sha }} + restore-keys: linux-unit-ccache- + + - name: Building LAMMPS via CMake + shell: bash + run: | + ccache -z + python3 -m venv linuxenv + source linuxenv/bin/activate + python3 -m pip install numpy + python3 -m pip install pyyaml + cmake -S cmake -B build \ + -C cmake/presets/gcc.cmake \ + -C cmake/presets/most.cmake \ + -D CMAKE_CXX_COMPILER_LAUNCHER=ccache \ + -D CMAKE_C_COMPILER_LAUNCHER=ccache \ + -D BUILD_SHARED_LIBS=on \ + -D LAMMPS_SIZES=bigbig \ + -D DOWNLOAD_POTENTIALS=off \ + -D ENABLE_TESTING=on \ + -D MLIAP_ENABLE_ACE=on \ + -D MLIAP_ENABLE_PYTHON=off \ + -D PKG_MANIFOLD=on \ + -D PKG_ML-PACE=on \ + -D PKG_ML-RANN=on \ + -D PKG_RHEO=on \ + -D PKG_PTM=on \ + -D PKG_PYTHON=on \ + -D PKG_QTB=on \ + -D PKG_SMTBQ=on \ + -G Ninja + cmake --build build + ccache -s + + - name: Run Tests + working-directory: build + shell: bash + run: ctest -V diff --git a/cmake/CMakeLists.txt b/cmake/CMakeLists.txt index d8b4f0a4f6..c68a925324 100644 --- a/cmake/CMakeLists.txt +++ b/cmake/CMakeLists.txt @@ -12,6 +12,11 @@ endif() if(POLICY CMP0075) cmake_policy(SET CMP0075 NEW) endif() +# set policy to silence warnings about requiring execute permission for find_program +# we use OLD because the python-config script for the Fedora MinGW cross-compiler requires it currently +if(POLICY CMP0109) + cmake_policy(SET CMP0109 OLD) +endif() # set policy to silence warnings about timestamps of downloaded files. review occasionally if it may be set to NEW if(POLICY CMP0135) cmake_policy(SET CMP0135 OLD) @@ -164,6 +169,22 @@ if(MSVC) add_compile_definitions(_CRT_SECURE_NO_WARNINGS) endif() +# warn about potentially problematic GCC compiler versions +if(CMAKE_CXX_COMPILER_ID STREQUAL "GNU") + if (CMAKE_CXX_STANDARD GREATER_EQUAL 17) + if (CMAKE_CXX_COMPILER_VERSION VERSION_LESS 9.0) + message(WARNING "Using ${CMAKE_CXX_COMPILER_ID} compiler version ${CMAKE_CXX_COMPILER_VERSION} " + "with C++17 is not recommended. Please use ${CMAKE_CXX_COMPILER_ID} compiler version 9.x or later") + endif() + endif() + if (CMAKE_CXX_STANDARD GREATER_EQUAL 11) + if (CMAKE_CXX_COMPILER_VERSION VERSION_LESS 5.0) + message(WARNING "Using ${CMAKE_CXX_COMPILER_ID} compiler version ${CMAKE_CXX_COMPILER_VERSION} " + "with C++11 is not recommended. Please use ${CMAKE_CXX_COMPILER_ID} compiler version 5.x or later") + endif() + endif() +endif() + # export all symbols when building a .dll file on windows if((CMAKE_SYSTEM_NAME STREQUAL "Windows") AND BUILD_SHARED_LIBS) set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS ON) @@ -198,13 +219,12 @@ set(LAMMPS_BINARY lmp${LAMMPS_MACHINE}) option(BUILD_SHARED_LIBS "Build shared library" OFF) option(CMAKE_POSITION_INDEPENDENT_CODE "Create object compatible with shared libraries" ON) option(BUILD_TOOLS "Build and install LAMMPS tools (msi2lmp, binary2txt, chain)" OFF) -option(BUILD_LAMMPS_SHELL "Build and install the LAMMPS shell" OFF) option(BUILD_LAMMPS_GUI "Build and install the LAMMPS GUI" OFF) # Support using clang-tidy for C++ files with selected options set(ENABLE_CLANG_TIDY OFF CACHE BOOL "Include clang-tidy processing when compiling") if(ENABLE_CLANG_TIDY) - set(CMAKE_CXX_CLANG_TIDY "clang-tidy;-checks=-*,performance-trivially-destructible,performance-unnecessary-copy-initialization,performance-unnecessary-value-param,readability-redundant-control-flow,readability-redundant-declaration,readability-redundant-function-ptr-dereference,readability-redundant-member-init,readability-redundant-string-cstr,readability-redundant-string-init,readability-simplify-boolean-expr,readability-static-accessed-through-instance,readability-static-definition-in-anonymous-namespace,modernize-use-override,modernize-use-bool-literals,modernize-use-emplace,modernize-return-braced-init-list,modernize-use-equals-default,modernize-use-equals-delete,modernize-replace-random-shuffle,modernize-deprecated-headers,modernize-use-nullptr,modernize-use-noexcept,modernize-redundant-void-arg;-fix;-header-filter=.*,header-filter=library.h,header-filter=fmt/*.h" CACHE STRING "clang-tidy settings") + set(CMAKE_CXX_CLANG_TIDY "clang-tidy;-checks=-*,performance-trivially-destructible,performance-unnecessary-copy-initialization,performance-unnecessary-value-param,readability-redundant-control-flow,readability-redundant-declaration,readability-redundant-function-ptr-dereference,readability-redundant-member-init,readability-redundant-string-cstr,readability-redundant-string-init,readability-simplify-boolean-expr,readability-static-accessed-through-instance,readability-static-definition-in-anonymous-namespace,readability-qualified-auto,misc-unused-parameters,modernize-deprecated-ios-base-aliases,modernize-loop-convert,modernize-shrink-to-fit,modernize-use-auto,modernize-use-using,modernize-use-override,modernize-use-bool-literals,modernize-use-emplace,modernize-return-braced-init-list,modernize-use-equals-default,modernize-use-equals-delete,modernize-replace-random-shuffle,modernize-deprecated-headers,modernize-use-nullptr,modernize-use-noexcept,modernize-redundant-void-arg;-fix;-header-filter=.*,header-filter=library.h,header-filter=fmt/*.h" CACHE STRING "clang-tidy settings") else() unset(CMAKE_CXX_CLANG_TIDY CACHE) endif() @@ -306,6 +326,7 @@ set(STANDARD_PACKAGES REACTION REAXFF REPLICA + RHEO RIGID SCAFACOS SHOCK @@ -410,6 +431,7 @@ pkg_depends(CG-DNA ASPHERE) pkg_depends(ELECTRODE KSPACE) pkg_depends(EXTRA-MOLECULE MOLECULE) pkg_depends(MESONT MOLECULE) +pkg_depends(RHEO BPM) # detect if we may enable OpenMP support by default set(BUILD_OMP_DEFAULT OFF) @@ -452,13 +474,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_${BTYPE} "${CMAKE_SHARED_LINKER_FLAGS_${BTYPE}} -fopenmp") + set(CMAKE_STATIC_LINKER_FLAGS_${BTYPE} "${CMAKE_STATIC_LINKER_FLAGS_${BTYPE}} -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_${BTYPE} "${CMAKE_SHARED_LINKER_FLAGS_${BTYPE}} -fopenmp") + set(CMAKE_STATIC_LINKER_FLAGS_${BTYPE} "${CMAKE_STATIC_LINKER_FLAGS_${BTYPE}} -fopenmp") endif() endif() endif() @@ -550,7 +572,7 @@ else() endif() foreach(PKG_WITH_INCL KSPACE PYTHON ML-IAP VORONOI COLVARS ML-HDNNP MDI MOLFILE NETCDF - PLUMED QMMM ML-QUIP SCAFACOS MACHDYN VTK KIM COMPRESS ML-PACE LEPTON) + PLUMED QMMM ML-QUIP SCAFACOS MACHDYN VTK KIM COMPRESS ML-PACE LEPTON RHEO EXTRA-COMMAND) if(PKG_${PKG_WITH_INCL}) include(Packages/${PKG_WITH_INCL}) endif() @@ -870,7 +892,7 @@ endif() include(Testing) include(CodeCoverage) include(CodingStandard) -find_package(ClangFormat 8.0) +find_package(ClangFormat 11.0) if(ClangFormat_FOUND) add_custom_target(format-src @@ -940,8 +962,12 @@ message(STATUS "<<< Compilers and Flags: >>> -- C++ Compiler: ${CMAKE_CXX_COMPILER} Type: ${CMAKE_CXX_COMPILER_ID} Version: ${CMAKE_CXX_COMPILER_VERSION} + C++ Standard: ${CMAKE_CXX_STANDARD} C++ Flags: ${CMAKE_CXX_FLAGS} ${CMAKE_CXX_FLAGS_${BTYPE}} Defines: ${DEFINES}") +if(CMAKE_CXX_COMPILER_LAUNCHER) + message(STATUS " Launcher: ${CMAKE_CXX_COMPILER_LAUNCHER}") +endif() get_target_property(OPTIONS lammps COMPILE_OPTIONS) if(OPTIONS) message(" Options: ${OPTIONS}") @@ -960,6 +986,9 @@ if(_index GREATER -1) Type: ${CMAKE_C_COMPILER_ID} Version: ${CMAKE_C_COMPILER_VERSION} C Flags: ${CMAKE_C_FLAGS} ${CMAKE_C_FLAGS_${BTYPE}}") + if(CMAKE_C_COMPILER_LAUNCHER) + message(STATUS " Launcher: ${CMAKE_C_COMPILER_LAUNCHER}") + endif() endif() message(STATUS "<<< Linker flags: >>>") message(STATUS "Executable name: ${LAMMPS_BINARY}") @@ -1046,9 +1075,6 @@ endif() if(BUILD_TOOLS) message(STATUS "<<< Building Tools >>>") endif() -if(BUILD_LAMMPS_SHELL) - message(STATUS "<<< Building LAMMPS Shell >>>") -endif() if(BUILD_LAMMPS_GUI) message(STATUS "<<< Building LAMMPS GUI >>>") if(LAMMPS_GUI_USE_PLUGIN) diff --git a/cmake/Modules/FindClangFormat.cmake b/cmake/Modules/FindClangFormat.cmake index 3f0257f34f..24fad5b6a8 100644 --- a/cmake/Modules/FindClangFormat.cmake +++ b/cmake/Modules/FindClangFormat.cmake @@ -1,5 +1,8 @@ # Find clang-format find_program(ClangFormat_EXECUTABLE NAMES clang-format + clang-format-20.0 + clang-format-19.0 + clang-format-18.0 clang-format-17.0 clang-format-16.0 clang-format-15.0 diff --git a/cmake/Modules/LAMMPSUtils.cmake b/cmake/Modules/LAMMPSUtils.cmake index 2ec9d1b706..223577fe31 100644 --- a/cmake/Modules/LAMMPSUtils.cmake +++ b/cmake/Modules/LAMMPSUtils.cmake @@ -32,7 +32,13 @@ function(check_omp_h_include) set(CMAKE_REQUIRED_INCLUDES ${OpenMP_CXX_INCLUDE_DIRS}) set(CMAKE_REQUIRED_LINK_OPTIONS ${OpenMP_CXX_FLAGS}) set(CMAKE_REQUIRED_LIBRARIES ${OpenMP_CXX_LIBRARIES}) - check_include_file_cxx(omp.h _have_omp_h) + # there are all kinds of problems with finding omp.h + # for Clang and derived compilers so we pretend it is there. + if(CMAKE_CXX_COMPILER_ID STREQUAL "Clang") + set(_have_omp_h TRUE) + else() + check_include_file_cxx(omp.h _have_omp_h) + endif() else() set(_have_omp_h FALSE) endif() diff --git a/cmake/Modules/Packages/COLVARS.cmake b/cmake/Modules/Packages/COLVARS.cmake index 745c1de026..b943a0345e 100644 --- a/cmake/Modules/Packages/COLVARS.cmake +++ b/cmake/Modules/Packages/COLVARS.cmake @@ -24,6 +24,12 @@ target_include_directories(colvars PUBLIC ${LAMMPS_LIB_SOURCE_DIR}/colvars) target_include_directories(colvars PRIVATE ${LAMMPS_SOURCE_DIR}) target_link_libraries(lammps PRIVATE colvars) +if(BUILD_OMP) + # Enable OpenMP for Colvars as well + target_compile_options(colvars PRIVATE ${OpenMP_CXX_FLAGS}) + target_link_libraries(colvars PRIVATE OpenMP::OpenMP_CXX) +endif() + if(COLVARS_DEBUG) # Need to export the define publicly to be valid in interface code target_compile_definitions(colvars PUBLIC -DCOLVARS_DEBUG) diff --git a/cmake/Modules/Packages/EXTRA-COMMAND.cmake b/cmake/Modules/Packages/EXTRA-COMMAND.cmake new file mode 100644 index 0000000000..13c98bafd3 --- /dev/null +++ b/cmake/Modules/Packages/EXTRA-COMMAND.cmake @@ -0,0 +1,10 @@ +# the geturl command needs libcurl + +find_package(CURL QUIET COMPONENTS HTTP HTTPS) +option(WITH_CURL "Enable libcurl support" ${CURL_FOUND}) +if(WITH_CURL) + find_package(CURL REQUIRED COMPONENTS HTTP HTTPS) + target_compile_definitions(lammps PRIVATE -DLAMMPS_CURL) + target_link_libraries(lammps PRIVATE CURL::libcurl) +endif() + diff --git a/cmake/Modules/Packages/KOKKOS.cmake b/cmake/Modules/Packages/KOKKOS.cmake index 3776d18a3e..bf0a18d324 100644 --- a/cmake/Modules/Packages/KOKKOS.cmake +++ b/cmake/Modules/Packages/KOKKOS.cmake @@ -127,7 +127,7 @@ if(PKG_KSPACE) ${KOKKOS_PKG_SOURCES_DIR}/grid3d_kokkos.cpp ${KOKKOS_PKG_SOURCES_DIR}/remap_kokkos.cpp) set(FFT_KOKKOS "KISS" CACHE STRING "FFT library for Kokkos-enabled KSPACE package") - set(FFT_KOKKOS_VALUES KISS FFTW3 MKL HIPFFT CUFFT) + set(FFT_KOKKOS_VALUES KISS FFTW3 MKL NVPL HIPFFT CUFFT MKL_GPU) set_property(CACHE FFT_KOKKOS PROPERTY STRINGS ${FFT_KOKKOS_VALUES}) validate_option(FFT_KOKKOS FFT_KOKKOS_VALUES) string(TOUPPER ${FFT_KOKKOS} FFT_KOKKOS) @@ -137,10 +137,8 @@ if(PKG_KSPACE) message(FATAL_ERROR "The CUDA backend of Kokkos requires either KISS FFT or CUFFT.") elseif(FFT_KOKKOS STREQUAL "KISS") message(WARNING "Using KISS FFT with the CUDA backend of Kokkos may be sub-optimal.") - target_compile_definitions(lammps PRIVATE -DFFT_KOKKOS_KISS) elseif(FFT_KOKKOS STREQUAL "CUFFT") find_package(CUDAToolkit REQUIRED) - target_compile_definitions(lammps PRIVATE -DFFT_KOKKOS_CUFFT) target_link_libraries(lammps PRIVATE CUDA::cufft) endif() elseif(Kokkos_ENABLE_HIP) @@ -152,10 +150,21 @@ if(PKG_KSPACE) elseif(FFT_KOKKOS STREQUAL "HIPFFT") include(DetectHIPInstallation) find_package(hipfft REQUIRED) - target_compile_definitions(lammps PRIVATE -DFFT_KOKKOS_HIPFFT) target_link_libraries(lammps PRIVATE hip::hipfft) endif() + elseif(FFT_KOKKOS STREQUAL "MKL_GPU") + if(NOT Kokkos_ENABLE_SYCL) + message(FATAL_ERROR "Using MKL_GPU FFT currently requires the SYCL backend of Kokkos.") + endif() + find_package(MKL REQUIRED) + target_link_libraries(lammps PRIVATE mkl_sycl_dft mkl_intel_ilp64 mkl_tbb_thread mkl_core tbb) + elseif(FFT_KOKKOS STREQUAL "MKL") + find_package(MKL REQUIRED) + elseif(FFT_KOKKOS STREQUAL "NVPL") + find_package(nvpl_fft REQUIRED) + target_link_libraries(lammps PRIVATE nvpl::fftw) endif() + target_compile_definitions(lammps PRIVATE -DFFT_KOKKOS_${FFT_KOKKOS}) endif() if(PKG_ML-IAP) diff --git a/cmake/Modules/Packages/KSPACE.cmake b/cmake/Modules/Packages/KSPACE.cmake index 1fdd898144..3801140fe0 100644 --- a/cmake/Modules/Packages/KSPACE.cmake +++ b/cmake/Modules/Packages/KSPACE.cmake @@ -10,7 +10,7 @@ if(${FFTW}_FOUND) else() set(FFT "KISS" CACHE STRING "FFT library for KSPACE package") endif() -set(FFT_VALUES KISS FFTW3 MKL) +set(FFT_VALUES KISS FFTW3 MKL NVPL) set_property(CACHE FFT PROPERTY STRINGS ${FFT_VALUES}) validate_option(FFT FFT_VALUES) string(TOUPPER ${FFT} FFT) @@ -41,6 +41,10 @@ elseif(FFT STREQUAL "MKL") target_compile_definitions(lammps PRIVATE -DFFT_MKL_THREADS) endif() target_link_libraries(lammps PRIVATE MKL::MKL) +elseif(FFT STREQUAL "NVPL") + find_package(nvpl_fft REQUIRED) + target_compile_definitions(lammps PRIVATE -DFFT_NVPL) + target_link_libraries(lammps PRIVATE nvpl::fftw) else() # last option is KISSFFT target_compile_definitions(lammps PRIVATE -DFFT_KISS) diff --git a/cmake/Modules/Packages/ML-PACE.cmake b/cmake/Modules/Packages/ML-PACE.cmake index 248b8eea76..8660898138 100644 --- a/cmake/Modules/Packages/ML-PACE.cmake +++ b/cmake/Modules/Packages/ML-PACE.cmake @@ -1,5 +1,11 @@ -set(PACELIB_URL "https://github.com/ICAMS/lammps-user-pace/archive/refs/tags/v.2023.11.25.fix.tar.gz" CACHE STRING "URL for PACE evaluator library sources") +# PACE library support for ML-PACE package +# set policy to silence warnings about timestamps of downloaded files. review occasionally if it may be set to NEW +if(POLICY CMP0135) + cmake_policy(SET CMP0135 OLD) +endif() + +set(PACELIB_URL "https://github.com/ICAMS/lammps-user-pace/archive/refs/tags/v.2023.11.25.fix.tar.gz" CACHE STRING "URL for PACE evaluator library sources") set(PACELIB_MD5 "b45de9a633f42ed65422567e3ce56f9f" CACHE STRING "MD5 checksum of PACE evaluator library tarball") mark_as_advanced(PACELIB_URL) mark_as_advanced(PACELIB_MD5) diff --git a/cmake/Modules/Packages/ML-QUIP.cmake b/cmake/Modules/Packages/ML-QUIP.cmake index 5cb5a0967e..9106ff54ef 100644 --- a/cmake/Modules/Packages/ML-QUIP.cmake +++ b/cmake/Modules/Packages/ML-QUIP.cmake @@ -27,7 +27,7 @@ if(DOWNLOAD_QUIP) else() message(FATAL_ERROR "The ${CMAKE_Fortran_COMPILER_ID} Fortran compiler is not (yet) supported for building QUIP") endif() - set(temp "${temp}CFLAGS += -fPIC \nCPLUSPLUSFLAGS += -fPIC\nAR_ADD=src\n") + set(temp "${temp}CFLAGS += -fPIC -Wno-return-mismatch \nCPLUSPLUSFLAGS += -fPIC -Wno-return-mismatch\nAR_ADD=src\n") set(temp "${temp}MATH_LINKOPTS=") foreach(flag ${BLAS_LIBRARIES}) set(temp "${temp} ${flag}") diff --git a/cmake/Modules/Packages/PLUMED.cmake b/cmake/Modules/Packages/PLUMED.cmake index 8312589478..8dab157a24 100644 --- a/cmake/Modules/Packages/PLUMED.cmake +++ b/cmake/Modules/Packages/PLUMED.cmake @@ -1,5 +1,10 @@ # Plumed2 support for PLUMED package +# set policy to silence warnings about timestamps of downloaded files. review occasionally if it may be set to NEW +if(POLICY CMP0135) + cmake_policy(SET CMP0135 OLD) +endif() + # for supporting multiple concurrent plumed2 installations for debugging and testing set(PLUMED_SUFFIX "" CACHE STRING "Suffix for Plumed2 library") mark_as_advanced(PLUMED_SUFFIX) @@ -27,9 +32,9 @@ endif() # Note: must also adjust check for supported API versions in # fix_plumed.cpp when version changes from v2.n.x to v2.n+1.y -set(PLUMED_URL "https://github.com/plumed/plumed2/releases/download/v2.9.1/plumed-src-2.9.1.tgz" +set(PLUMED_URL "https://github.com/plumed/plumed2/releases/download/v2.9.2/plumed-src-2.9.2.tgz" CACHE STRING "URL for PLUMED tarball") -set(PLUMED_MD5 "c3b2d31479c1e9ce211719d40e9efbd7" CACHE STRING "MD5 checksum of PLUMED tarball") +set(PLUMED_MD5 "04862602a372c1013bdfee2d6d03bace" CACHE STRING "MD5 checksum of PLUMED tarball") mark_as_advanced(PLUMED_URL) mark_as_advanced(PLUMED_MD5) @@ -81,6 +86,9 @@ if((CMAKE_SYSTEM_NAME STREQUAL "Windows") AND (CMAKE_CROSSCOMPILING)) DEPENDS plumed_build COMMENT "Copying Plumed files" ) + if(CMAKE_PROJECT_NAME STREQUAL "lammps") + target_link_libraries(lammps INTERFACE LAMMPS::PLUMED) + endif() else() @@ -155,6 +163,9 @@ else() endif() set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_INCLUDE_DIRECTORIES ${INSTALL_DIR}/include) file(MAKE_DIRECTORY ${INSTALL_DIR}/include) + if(CMAKE_PROJECT_NAME STREQUAL "lammps") + target_link_libraries(lammps PRIVATE LAMMPS::PLUMED) + endif() else() find_package(PkgConfig REQUIRED) pkg_check_modules(PLUMED REQUIRED plumed${PLUMED_SUFFIX}) @@ -169,7 +180,9 @@ else() endif() set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_LINK_LIBRARIES "${PLUMED_LOAD}") set_target_properties(LAMMPS::PLUMED PROPERTIES INTERFACE_INCLUDE_DIRECTORIES "${PLUMED_INCLUDE_DIRS}") + if(CMAKE_PROJECT_NAME STREQUAL "lammps") + target_link_libraries(lammps PUBLIC LAMMPS::PLUMED) + endif() endif() endif() -target_link_libraries(lammps PRIVATE LAMMPS::PLUMED) diff --git a/cmake/Modules/Packages/RHEO.cmake b/cmake/Modules/Packages/RHEO.cmake new file mode 100644 index 0000000000..7639acd8bc --- /dev/null +++ b/cmake/Modules/Packages/RHEO.cmake @@ -0,0 +1,2 @@ +find_package(GSL 2.6 REQUIRED) +target_link_libraries(lammps PRIVATE GSL::gsl) diff --git a/cmake/Modules/Testing.cmake b/cmake/Modules/Testing.cmake index ff595d3c8f..a72ce17e1b 100644 --- a/cmake/Modules/Testing.cmake +++ b/cmake/Modules/Testing.cmake @@ -102,9 +102,9 @@ endif() ####################################### # select code sanitizer options ####################################### -set(ENABLE_SANITIZER "none" CACHE STRING "Select a code sanitizer option (none (default), address, leak, thread, undefined)") +set(ENABLE_SANITIZER "none" CACHE STRING "Select a code sanitizer option (none (default), address, hwaddress, leak, thread, undefined)") mark_as_advanced(ENABLE_SANITIZER) -set(ENABLE_SANITIZER_VALUES none address leak thread undefined) +set(ENABLE_SANITIZER_VALUES none address hwaddress leak thread undefined) set_property(CACHE ENABLE_SANITIZER PROPERTY STRINGS ${ENABLE_SANITIZER_VALUES}) validate_option(ENABLE_SANITIZER ENABLE_SANITIZER_VALUES) string(TOLOWER ${ENABLE_SANITIZER} ENABLE_SANITIZER) diff --git a/cmake/Modules/Tools.cmake b/cmake/Modules/Tools.cmake index 133301c3d4..94e077d51e 100644 --- a/cmake/Modules/Tools.cmake +++ b/cmake/Modules/Tools.cmake @@ -37,37 +37,6 @@ if(BUILD_TOOLS) add_subdirectory(${LAMMPS_TOOLS_DIR}/phonon ${CMAKE_BINARY_DIR}/phana_build) endif() -find_package(PkgConfig QUIET) -if(BUILD_LAMMPS_SHELL) - if(NOT PkgConfig_FOUND) - message(FATAL_ERROR "Must have pkg-config installed for building LAMMPS shell") - endif() - find_package(PkgConfig REQUIRED) - pkg_check_modules(READLINE IMPORTED_TARGET REQUIRED readline) - - # include resource compiler to embed icons into the executable on Windows - if(CMAKE_SYSTEM_NAME STREQUAL "Windows") - enable_language(RC) - set(ICON_RC_FILE ${LAMMPS_TOOLS_DIR}/lammps-shell/lmpicons.rc) - endif() - - add_executable(lammps-shell ${LAMMPS_TOOLS_DIR}/lammps-shell/lammps-shell.cpp ${ICON_RC_FILE}) - target_include_directories(lammps-shell PRIVATE ${LAMMPS_TOOLS_DIR}/lammps-shell) - target_link_libraries(lammps-shell PRIVATE lammps PkgConfig::READLINE) - - # workaround for broken readline pkg-config file on FreeBSD - if(CMAKE_SYSTEM_NAME STREQUAL "FreeBSD") - target_include_directories(lammps-shell PRIVATE /usr/local/include) - endif() - if(CMAKE_SYSTEM_NAME STREQUAL "LinuxMUSL") - pkg_check_modules(TERMCAP IMPORTED_TARGET REQUIRED termcap) - target_link_libraries(lammps-shell PRIVATE lammps PkgConfig::TERMCAP) - endif() - install(TARGETS lammps-shell EXPORT LAMMPS_Targets DESTINATION ${CMAKE_INSTALL_BINDIR}) - install(DIRECTORY ${LAMMPS_TOOLS_DIR}/lammps-shell/icons DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/) - install(FILES ${LAMMPS_TOOLS_DIR}/lammps-shell/lammps-shell.desktop DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/applications/) -endif() - if(BUILD_LAMMPS_GUI) get_filename_component(LAMMPS_GUI_DIR ${LAMMPS_SOURCE_DIR}/../tools/lammps-gui ABSOLUTE) get_filename_component(LAMMPS_GUI_BIN ${CMAKE_BINARY_DIR}/lammps-gui-build ABSOLUTE) diff --git a/cmake/packaging/LAMMPS_DMG_Background.xcf b/cmake/packaging/LAMMPS_DMG_Background.xcf new file mode 100644 index 0000000000..cff3222717 Binary files /dev/null and b/cmake/packaging/LAMMPS_DMG_Background.xcf differ diff --git a/cmake/packaging/build_linux_tgz.sh b/cmake/packaging/build_linux_tgz.sh index ea2fb7fb10..276da019ae 100755 --- a/cmake/packaging/build_linux_tgz.sh +++ b/cmake/packaging/build_linux_tgz.sh @@ -2,9 +2,10 @@ APP_NAME=lammps-gui DESTDIR=${PWD}/../LAMMPS_GUI +VERSION="$1" echo "Delete old files, if they exist" -rm -rf ${DESTDIR} ../LAMMPS_GUI-Linux-amd64.tar.gz +rm -rf ${DESTDIR} ../LAMMPS_GUI-Linux-amd64*.tar.gz echo "Create staging area for deployment and populate" DESTDIR=${DESTDIR} cmake --install . --prefix "/" @@ -71,7 +72,7 @@ do \ done pushd .. -tar -czvvf LAMMPS_GUI-Linux-amd64.tar.gz LAMMPS_GUI +tar -czvvf LAMMPS_GUI-Linux-amd64-${VERSION}.tar.gz LAMMPS_GUI popd echo "Cleanup dir" diff --git a/cmake/packaging/build_macos_dmg.sh b/cmake/packaging/build_macos_dmg.sh index 4da3e40eaf..6e6877d2dd 100755 --- a/cmake/packaging/build_macos_dmg.sh +++ b/cmake/packaging/build_macos_dmg.sh @@ -1,9 +1,10 @@ #!/bin/bash APP_NAME=lammps-gui +VERSION="$1" echo "Delete old files, if they exist" -rm -f ${APP_NAME}.dmg ${APP_NAME}-rw.dmg LAMMPS_GUI-macOS-multiarch.dmg +rm -f ${APP_NAME}.dmg ${APP_NAME}-rw.dmg LAMMPS_GUI-macOS-multiarch*.dmg echo "Create initial dmg file with macdeployqt" macdeployqt lammps-gui.app -dmg @@ -96,12 +97,12 @@ sync echo "Unmount modified disk image and convert to compressed read-only image" hdiutil detach "${DEVICE}" -hdiutil convert "${APP_NAME}-rw.dmg" -format UDZO -o "LAMMPS_GUI-macOS-multiarch.dmg" +hdiutil convert "${APP_NAME}-rw.dmg" -format UDZO -o "LAMMPS_GUI-macOS-multiarch-${VERSION}.dmg" echo "Attach icon to .dmg file" echo "read 'icns' (-16455) \"lammps-gui.app/Contents/Resources/lammps.icns\";" > icon.rsrc -Rez -a icon.rsrc -o LAMMPS_GUI-macOS-multiarch.dmg -SetFile -a C LAMMPS_GUI-macOS-multiarch.dmg +Rez -a icon.rsrc -o LAMMPS_GUI-macOS-multiarch-${VERSION}.dmg +SetFile -a C LAMMPS_GUI-macOS-multiarch-${VERSION}.dmg rm icon.rsrc echo "Delete temporary disk images" diff --git a/cmake/packaging/build_windows_cross_zip.sh b/cmake/packaging/build_windows_cross_zip.sh index d02b9cf761..1d7a2ce146 100755 --- a/cmake/packaging/build_windows_cross_zip.sh +++ b/cmake/packaging/build_windows_cross_zip.sh @@ -3,9 +3,10 @@ APP_NAME=lammps-gui DESTDIR=${PWD}/LAMMPS_GUI SYSROOT="$1" +VERSION="$2" echo "Delete old files, if they exist" -rm -rvf ${DESTDIR}/LAMMPS_GUI ${DESTDIR}/LAMMPS-Win10-amd64.zip +rm -rvf ${DESTDIR}/LAMMPS_GUI ${DESTDIR}/LAMMPS-Win10-amd64*.zip echo "Create staging area for deployment and populate" DESTDIR=${DESTDIR} cmake --install . --prefix "/" @@ -60,5 +61,5 @@ cat > ${DESTDIR}/bin/qt.conf < ...\fR or +\fB\-restart2info ...\fR +Write information about the previously written by +.B LAMMPS +to the screen and immediately exit. Following +argument, additional keywords for the +.B LAMMPS +"info" command may be added to increase the amount of information +written. By default "system" "group" "fix" "compute" are already +set. See the +.B LAMMPS +manual for details on the "info" command. +.TP +.TP \fB\-sc \fR or \fB\-screen \fR Specify a file for .B LAMMPS diff --git a/doc/msi2lmp.1 b/doc/msi2lmp.1 index 5cb0754e4f..075e25e3b9 100644 --- a/doc/msi2lmp.1 +++ b/doc/msi2lmp.1 @@ -1,4 +1,4 @@ -.TH MSI2LMP "1" "v3.9.10" "2023-03-10" +.TH MSI2LMP "1" "v3.9.11" "2024-09-06" .SH NAME .B MSI2LMP \- Converter for Materials Studio files to LAMMPS @@ -101,7 +101,7 @@ msi2lmp decane -c 0 -f oplsaa .SH COPYRIGHT -© 2003--2022 Sandia Corporation +© 2003--2024 Sandia Corporation This package is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License version 2 as diff --git a/doc/src/Bibliography.rst b/doc/src/Bibliography.rst index 9778340c94..0df3cf2f83 100644 --- a/doc/src/Bibliography.rst +++ b/doc/src/Bibliography.rst @@ -1,6 +1,12 @@ Bibliography ************ +**(Abascal1)** + Abascal, Sanz, Fernandez, Vega, J Chem Phys, 122, 234511 (2005) + +**(Abascal2)** + Abascal, J Chem Phys, 123, 234505 (2005) + **(Ackland)** Ackland, Jones, Phys Rev B, 73, 054104 (2006). @@ -22,21 +28,24 @@ Bibliography **(Agnolin and Roux 2007)** Agnolin, I. & Roux, J-N. (2007). Internal states of model isotropic granular packings. I. Assembling process, geometry, and contact networks. Phys. Rev. E, 76, 061302. +**(Ahrens-Iwers2022)** + Ahrens-Iwers *et al.*, J. Chem. Phys. 157, 084801 (2022). + +**(Ahrens-Iwers)** + Ahrens-Iwers and Meissner, J. Chem. Phys. 155, 104104 (2021). + **(Aktulga)** Aktulga, Fogarty, Pandit, Grama, Parallel Computing, 38, 245-259 (2012). **(Albe)** J.\ Nord, K. Albe, P. Erhart, and K. Nordlund, J. Phys.: Condens. Matter, 15, 5649(2003). -**(Albe)** +**(Albe1)** K.\ Albe, K. Nordlund, J. Nord, and A. Kuronen, Phys. Rev. B, 66, 035205 (2002). **(Allen)** Allen and Germano, Mol Phys 104, 3225-3235 (2006). -**(Allen)** - Allen and Tildesley, Computer Simulation of Liquids, Clarendon Press, Oxford, 1987. - **(AllenTildesley)** Allen and Tildesley, Computer Simulation of Liquids, Oxford University Press (1987) @@ -49,6 +58,9 @@ Bibliography **(Anderson)** Anderson, Mukherjee, Critchley, Ziegler, and Lipton "POEMS: Parallelizable Open-source Efficient Multibody Software ", Engineering With Computers (2006). +**(Appshaw)** + Appshaw, Seddon, Hanna, Soft. Matter,18, 1747(2022). + **(Avendano)** C.\ Avendano, T. Lafitte, A. Galindo, C. S. Adjiman, G. Jackson, E. Muller, J Phys Chem B, 115, 11154 (2011). @@ -58,7 +70,7 @@ Bibliography **(Babadi)** Babadi, Ejtehadi, Everaers, J Comp Phys, 219, 770-779 (2006). -**(Babadi)** +**(Babadi2)** Babadi and Ejtehadi, EPL, 77 (2007) 23002. **(Baczewski)** @@ -73,23 +85,23 @@ Bibliography **(Ballenegger)** Ballenegger, Arnold, Cerda, J Chem Phys, 131, 094107 (2009). -**(Banna)** - Volkov, Banna, Comp. Mater. Sci. 176, 109410 (2020). - **(Barrat)** Barrat and Rodney, J. Stat. Phys, 144, 679 (2011). **(Barrett)** Barrett, Tschopp, El Kadiri, Scripta Mat. 66, p.666 (2012). +**(Barros)** + Barros, Sinkovits, Luijten, J. Chem. Phys, 140, 064903 (2014) + **(Bartok)** Bartok, Payne, Risi, Csanyi, Phys Rev Lett, 104, 136403 (2010). **(Bartok2010)** Bartok, Payne, Risi, Csanyi, Phys Rev Lett, 104, 136403 (2010). -**(Bartok_2010)** - AP Bartok, MC Payne, R Kondor, and G Csanyi, Physical Review Letters 104, 136403 (2010). +**(Bartok2013)** + Bartok, Kondor, Csanyi, Phys Rev B, 87, 184115 (2013). **(Bartok_PhD)** A Bartok-Partay, PhD Thesis, University of Cambridge, (2010). @@ -97,36 +109,51 @@ Bibliography **(Baskes)** Baskes, Phys Rev B, 46, 2727-2742 (1992). +**(Baskes2)** + Baskes, Phys Rev B, 75, 094113 (2007). + **(Beck)** Beck, Molecular Physics, 14, 311 (1968). +**(Becton)** + Becton, Averett, Wang, Biomech. Model. Mechanobiology, 18, 425-433(2019). + +**(Behler and Parrinello 2007)** + Behler, J.; Parrinello, M. Phys. Rev. Lett. 2007, 98 (14), 146401. + **(Bennet)** Bennet, J Comput Phys, 22, 245 (1976) **(Berardi)** Berardi, Fava, Zannoni, Chem Phys Lett, 297, 8-14 (1998). Berardi, Muccioli, Zannoni, J Chem Phys, 128, 024905 (2008). -**(Berendsen)** - Berendsen, Grigera, Straatsma, J Phys Chem, 91, 6269-6271 (1987). - **(Berendsen)** Berendsen, Postma, van Gunsteren, DiNola, Haak, J Chem Phys, 81, 3684 (1984). +**(Berendsen2)** + Berendsen, Grigera, Straatsma, J Phys Chem, 91, 6269-6271 (1987). + **(Bessarab)** Bessarab, Uzdin, Jonsson, Comp Phys Comm, 196, 335-347 (2015). **(Beutler)** Beutler, Mark, van Schaik, Gerber, van Gunsteren, Chem Phys Lett, 222, 529 (1994). -**(Bialke)** - J.\ Bialke, T. Speck, and H Loewen, Phys. Rev. Lett. 108, 168301, 2012. - **(Bird)** G.\ A. Bird, "Molecular Gas Dynamics and the Direct Simulation of Gas Flows" (1994). **(Bitzek)** Bitzek, Koskinen, Gahler, Moseler, Gumbsch, Phys Rev Lett, 97, 170201 (2006). +**(Bolintineanu1)** + Bolintineanu, Lechman, Plimpton, Grest, Phys Rev E, 86, 066703 (2012). + +**(Bolintineanu2)** + Bolintineanu, Grest, Lechman, Pierce, Plimpton, Schunk, Comp Particle Mechanics, 1, 321-356 (2014). + +**(Bomont)** + Bomont, Bretonnet, J. Chem. Phys. 124, 054504 (2006). + **(Bond)** Bond and Leimkuhler, SIAM J Sci Comput, 30, p 134 (2007). @@ -134,7 +161,7 @@ Bibliography Boone, Babaei, Wilmer, J Chem Theory Comput, 15, 5579--5587 (2019). **(BoreschKarplus)** - Boresch and Karplus, J Phys Chem A, 103, 103 (1999) + Boresch and Karplus, J Phys Chem A, 103, 103 (1999). **(Botu1)** V.\ Botu and R. Ramprasad, Int. J. Quant. Chem., 115(16), 1074 (2015). @@ -169,8 +196,11 @@ Bibliography **(Buck)** Buck, Bouguet-Bonnet, Pastor, MacKerell Jr., Biophys J, 90, L36 (2006). +**(Bulacu)** + Bulacu, Goga, Zhao, Rossi, Monticelli, Periole, Tieleman, Marrink, J Chem Theory Comput, 9, 3282-3292 + **(Bussi)** - G.\ Bussi, M. Parrinello, Phs. Rev. E 75, 056707 (2007) + G. Bussi, T. Zykova-Timan, M. Parrinello, J Chem Phys, 130, 074101 (2009). **(Bussi1)** Bussi, Donadio and Parrinello, J. Chem. Phys. 126, 014101(2007) @@ -178,20 +208,20 @@ Bibliography **(Bussi2)** Bussi and Parrinello, Phys. Rev. E 75, 056707 (2007) -**(COMB)** +**(COMB_1)** + J.\ Yu, S. B. Sinnott, S. R. Phillpot, Phys Rev B, 75, 085311 (2007), + +**(COMB_2)** T.-R. Shan, B. D. Devine, T. W. Kemper, S. B. Sinnott, and S. R. Phillpot, Phys. Rev. B 81, 125328 (2010) **(COMB3)** T.\ Liang, T.-R. Shan, Y.-T. Cheng, B. D. Devine, M. Noordhoek, Y. Li, Z. Lu, S. R. Phillpot, and S. B. Sinnott, Mat. Sci. & Eng: R 74, 255-279 (2013). -**(COMB_1)** - J.\ Yu, S. B. Sinnott, S. R. Phillpot, Phys Rev B, 75, 085311 (2007), - **(Calhoun)** A.\ Calhoun, M. Pavese, G. Voth, Chem Phys Letters, 262, 415 (1996). **(Campana)** - C.\ Campana and M. H. Muser, *Practical Green's function approach to the simulation of elastic semi-infinite solids*, `Phys. Rev. B [74], 075420 (2006) `_ + C.\ Campana and M. H. Muser, Phys. Rev. B [74], 075420 (2006). **(Cao1)** J.\ Cao and B. Berne, J Chem Phys, 99, 2902 (1993). @@ -215,6 +245,9 @@ Bibliography Cerda, Ballenegger, Lenz, Holm, J Chem Phys 129, 234104 (2008) **(Ceriotti)** + M. Ceriotti, M. Parrinello, T. Markland, D. Manolopoulos, J. Chem. Phys. 133, 124104 (2010). + +**(Ceriotti1)** Ceriotti, Bussi and Parrinello, J Chem Theory Comput 6, 1170-80 (2010) **(Ceriotti2)** @@ -232,6 +265,18 @@ Bibliography **(Clarke)** Clarke and Smith, J Chem Phys, 84, 2290 (1986). +**(Clavier)** + G. Clavier, N. Desbiens, E. Bourasseau, V. Lachet, N. Brusselle-Dupend and B. Rousseau, Mol Sim, 43, 1413 (2017). + +**(Clemmer)** + Clemmer and Robbins, Phys. Rev. Lett. (2022). + +**(Clemmer1)** + Clemmer, Monti, Lechman, Soft Matter, 20, 1702 (2024). + +**(Clemmer2)** + Clemmer, Pierce, O'Connor, Nevins, Jones, Lechman, Tencer, Appl. Math. Model., 130, 310-326 (2024). + **(Coleman)** Coleman, Spearot, Capolungo, MSMSE, 21, 055020 (2013). @@ -244,8 +289,17 @@ Bibliography **(Cornell)** Cornell, Cieplak, Bayly, Gould, Merz, Ferguson, Spellmeyer, Fox, Caldwell, Kollman, JACS 117, 5179-5197 (1995). +**(Cundall, 1987)** + Cundall, P. A. Distinct Element Models of Rock and Soil + +**(Curk1)** + T. Curk, J. Yuan, and E. Luijten, JCP 156 (2022). + +**(Curk2)** + T. Curk and E. Luijten, PRL 126 (2021) + **(Cusentino)** - Cusentino, Wood, and Thompson, J Phys Chem A, xxx, xxxxx, (2020) + Cusentino, Wood, Thompson, J Phys Chem A, 124, 5456, (2020) **(Daivis and Todd)** Daivis and Todd, J Chem Phys, 124, 194103 (2006). @@ -268,6 +322,15 @@ Bibliography **(Daw2)** M.\ S. Daw, and M. I. Baskes, Phys. Rev. B, 29, 6443 (1984). +**(de Buyl)** + de Buyl, Colberg and Hofling, Comp. Phys. Comm. 185(6), 1546-1553 (2014) - + +**(Deissenbeck)** + Deissenbeck *et al.*, Phys. Rev. Letters 126, 136803 (2021). + +**(de Koning)** + de Koning and Antonelli, Phys Rev E, 53, 465 (1996). + **(DeVane)** Shinoda, DeVane, Klein, Soft Matter, 4, 2453-2462 (2008). @@ -277,12 +340,24 @@ Bibliography **(Destree)** M.\ Destree, F. Laupretre, A. Lyulin, and J.-P. Ryckaert, J Chem Phys, 112, 9632 (2000). +**(Dickel)** + Dickel, Francis, and Barrett, Computational Materials Science 171 (2020): 109157. + +**(Dietz)** + Dietz and Hoy, J. Chem Phys, 156, 014103 (2022). + **(Dobson)** Dobson, J Chem Phys, 141, 184103 (2014). +**(Drautz)** + Drautz, Phys Rev B, 99, 014104 (2019). + **(Duffy)** D M Duffy and A M Rutherford, J. Phys.: Condens. Matter, 19, 016207-016218 (2007). +**(Dufils)** + Dufils *et al.*, Phys. Rev. Letters 123, 195501 (2019). + **(Dullweber)** Dullweber, Leimkuhler and McLachlan, J Chem Phys, 107, 5840 (1997). @@ -295,6 +370,9 @@ Bibliography **(Dunweg)** Dunweg and Paul, Int J of Modern Physics C, 2, 817-27 (1991). +**(EcheverriRestrepo)** + Echeverri Restrepo, Andric, Comput Mater Sci, 218, 111978 (2023). + **(EDIP)** J F Justo et al, Phys Rev B 58, 2539 (1998). @@ -304,12 +382,21 @@ Bibliography **(Elliott)** Elliott, Tadmor and Bernstein, `https://openkim.org/kim-api `_ (2011) doi: `https://doi.org/10.25950/FF8F563A `_ +**(Ellis)** + Ellis, Fiedler, Popoola, Modine, Stephens, Thompson, Cangi, Rajamanickam, Phys Rev B, 104, 035120, (2021) + +**(Emmrich)** + Emmrich, Weckner, Commun. Math. Sci., 5, 851-864 (2007), + **(Elstner)** M.\ Elstner, D. Poresag, G. Jungnickel, J. Elsner, M. Haugk, T. Frauenheim, S. Suhai, and G. Seifert, Phys. Rev. B, 58, 7260 (1998). **(Erdmann)** U.\ Erdmann , W. Ebeling, L. Schimansky-Geier, and F. Schweitzer, Eur. Phys. J. B 15, 105-113, 2000. +**(Eshelby)** + J.D. Eshelby, Philos. Trans. Royal Soc. London A, Math. Phys. Sci., Vol. 244, No. 877 (1951) pp. 87-112; J. Elasticity, Vol. 5, Nos. 3-4 (1975) pp. 321-335] + **(Espanol and Revenga)** Espanol, Revenga, Physical Review E, 67, 026705 (2003). @@ -328,9 +415,18 @@ Bibliography **(Faken)** Faken, Jonsson, Comput Mater Sci, 2, 279 (1994). +**(Falk)** + Falk and Langer PRE, 57, 7192 (1998). + **(Fath)** Fath, Hochbruck, Singh, J Comp Phys, 333, 180-198 (2017). +**(Feng1)** + Z. Feng, ..., and W. Ouyang, J. Phys. Chem. C. 127(18), 8704-8713 (2023). + +**(Feng2)** + Z. Feng, ..., and W. Ouyang, Langmuir 39(50), 18198-18207 (2023). + **(Fennell)** C.\ J. Fennell, J. D. Gezelter, J Chem Phys, 124, 234104 (2006). @@ -367,18 +463,36 @@ Bibliography **(Frenkel)** Frenkel and Smit, Understanding Molecular Simulation, Academic Press, London, 2002. -**(GLE4MD)** - `https://gle4md.org/ `_ +**(Fu)** + Fu, Peng, Yuan, Kfoury, Young, Comput. Phys. Commun, 210, 193-203(2017). **(Gao)** Gao and Weber, Nuclear Instruments and Methods in Physics Research B 191 (2012) 504. +**(Gingrich)** + Gingrich, `MSc thesis` ` (2010). + +**(Gissinger2017)** + Gissinger, Jensen and Wise, Polymer, 128, 211-217 (2017). + +**(Gissinger2020)** + Gissinger, Jensen and Wise, Macromolecules, 53, 22, 9953-9961 (2020). + **(Gissinger)** - Gissinger, Jensen and Wise, Polymer, 128, 211 (2017). + Jacob R. Gissinger, Scott R. Zavada, Joseph G. Smith, Josh Kemppainen, Ivan Gallegos, Gregory M. Odegard, Emilie J. Siochi, and Kristopher E. Wise, Carbon, 202, 336-347 (2023). + +**(Gissinger2024)** + 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). + +**(Gloor)** + Gloor, J Chem Phys, 123, 134703 (2005) **(Glosli)** Glosli, unpublished, 2005. Streitz, Glosli, Patel, Chan, Yates, de Supinski, Sexton and Gunnels, Journal of Physics: Conference Series, 46, 254 (2006). +**(Goff)** + Goff, Zhang, Negre, Rohskopf, Niklasson, Journal of Chemical Theory and Computation 19, no. 13 (2023). + **(Goldman1)** Goldman, Reed and Fried, J. Chem. Phys. 131, 204103 (2009) @@ -412,6 +526,9 @@ Bibliography **(Guo)** Guo and Thirumalai, Journal of Molecular Biology, 263, 323-43 (1996). +**(Gupta)** + Gupta ,Phys Rev. B, 23, 6265-6270 (1981). + **(Hardy)** David Hardy thesis: Multilevel Summation for the Fast Evaluation of Forces for the Simulation of Biomolecules, University of Illinois at Urbana-Champaign, (2006). @@ -433,6 +550,9 @@ Bibliography **(Henrich)** O.\ Henrich, Y. A. Gutierrez-Fosado, T. Curk, T. E. Ouldridge, Eur. Phys. J. E 41, 57 (2018). +**(Herman)** + M. F. Herman, E. J. Bruskin, B. J. Berne, J Chem Phys, 76, 5150 (1982). + **(Hess)** Hess, B. The Journal of Chemical Physics 2002, 116 (1), 209-217. @@ -454,24 +574,42 @@ Bibliography **(Hoover)** Hoover, Phys Rev A, 31, 1695 (1985). +**(Huang)** + Huang, Zhang, Yuan, Gao, Zhang, Nano Lett. 13, 4546(2013). + +**(Huang2014)** + X. Huang, "Exploring critical-state behavior using DEM", Doctoral dissertation, Imperial College. (2014). https://doi.org/10.25560/25316 + +**(Hu)** + Hu, and Adams J. Comp. Physics, 213, 844-861 (2006). + +**(Hu)** + Hu, J. Chem. Theory Comput. 10, 5254 (2014). + **(Hummer)** Hummer, Gronbech-Jensen, Neumann, J Chem Phys, 109, 2791 (1998) **(Hunt)** Hunt, Mol Simul, 42, 347 (2016). +**(Ikeshoji)** + Ikeshoji and Hafskjold, Molecular Physics, 81, 251-261 (1994). + +**(Ikeshoji2)** + Ikeshoji, Hafskjold, Furuholt, Mol Sim, 29, 101-109, (2003). + +**(Ilie)** + Ilie, Briels, den Otter, Journal of Chemical Physics, 142, 114103 (2015). + +**(In 't Veld)** + In 't Veld, Ismail, Grest, J Chem Phys (accepted) (2007). + **(IPI)** `https://ipi-code.org/ ` **(IPI-CPC)** Ceriotti, More and Manolopoulos, Comp Phys Comm, 185, 1019-1026 (2014). -**(Ikeshoji)** - Ikeshoji and Hafskjold, Molecular Physics, 81, 251-261 (1994). - -**(In 't Veld)** - In 't Veld, Ismail, Grest, J Chem Phys (accepted) (2007). - **(Isele-Holder)** Isele-Holder, Mitchell, Ismail, J Chem Phys, 137, 174107 (2012). @@ -490,6 +628,9 @@ Bibliography **(Izvekov)** Izvekov, Voth, J Chem Phys 123, 134105 (2005). +**(Jadhao)** + Jadhao, Solis, Olvera de la Cruz, J Chem Phys, 138, 054119 (2013) + **(Janssens)** Janssens, Olmsted, Holm, Foiles, Plimpton, Derlet, Nature Materials, 5, 124-127 (2006). @@ -502,6 +643,15 @@ Bibliography **(Jiang)** Jiang, Hardy, Phillips, MacKerell, Schulten, and Roux, J Phys Chem Lett, 2, 87-92 (2011). +**(Jiang1)** + Jiang, Hardy, Phillips, MacKerell, Schulten, and Roux, J Phys Chem Lett, 2, 87-92 (2011). + +**(Jiang2)** + J.-W. Jiang, Nanotechnology 26, 315706 (2015). + +**(Jiang3)** + J.-W. Jiang, Acta Mech. Solida. Sin 32, 17 (2019). + **(Johnson et al, 1971)** Johnson, K. L., Kendall, K., & Roberts, A. D. (1971). Surface energy and the contact of elastic solids. Proc. R. Soc. Lond. A, 324(1558), 301-313. @@ -571,21 +721,24 @@ Bibliography **(Lamoureux)** Lamoureux and Roux, J Chem Phys, 119, 3025-3039 (2003). -**(Larentzos)** - J.P. Larentzos, J.K. Brennan, J.D. Moore, and W.D. Mattson, "LAMMPS Implementation of Constant Energy Dissipative Particle Dynamics (DPD-E)", ARL-TR-6863, U.S. Army Research +**(Landsgesell)** + J. Landsgesell, P. Hebbeker, O. Rud, R. Lunkad, P. Kosovan, and C. Holm, Macromolecules 53, 3007-3020 (2020). **(Larentzos1)** - J.P. Larentzos, J.K. Brennan, J.D. Moore, M. Lisal and W.D. Mattson, "Parallel Implementation of Isothermal and Isoenergetic Dissipative Particle Dynamics Using Shardlow-Like Splitting + J.P. Larentzos, J.K. Brennan, J.D. Moore, M. Lisal and W.D. Mattson, Comput. Phys. Commun., 185, 1987-1998 (2014). **(Larentzos2)** - J.P. Larentzos, J.K. Brennan, J.D. Moore, and W.D. Mattson, "LAMMPS Implementation of Constant Energy Dissipative Particle Dynamics (DPD-E)", ARL-TR-6863, U.S. Army Research + J.P. Larentzos, J.K. Brennan, J.D. Moore, and W.D. Mattson, ARL-TR-6863, U.S. Army Research Laboratory, Aberdeen Proving Ground, MD (2014). **(Larsen)** Larsen, Schmidt, Schiotz, Modelling Simul Mater Sci Eng, 24, 055007 (2016). -**(Lebedeva et al.)** +**(Lebedeva1)** I.\ V. Lebedeva, A. A. Knizhnik, A. M. Popov, Y. E. Lozovik, B. V. Potapkin, Phys. Rev. B, 84, 245437 (2011) +**(Lebedeva2)** + I. V. Lebedeva, A. A. Knizhnik, A. M. Popov, Y. E. Lozovik, B. V. Potapkin, Physica E: 44, 949-954 (2012) + **(Lechman)** Lechman, et al, in preparation (2010). @@ -595,6 +748,9 @@ Bibliography **(Lee2)** Lee, Baskes, Kim, Cho. Phys. Rev. B, 64, 184102 (2001). +**(Lee2020)** + C.W. Lee, et al. (2020) Physical Review B, 102(2), 024107. + **(Lenart)** Lenart , Jusufi, and Panagiotopoulos, J Chem Phys, 126, 044509 (2007). @@ -619,8 +775,11 @@ Bibliography **(Li2015_JCP)** Li, Yazdani, Tartakovsky, Karniadakis, J Chem Phys, 143: 014101 (2015). DOI:10.1063/1.4923254. +**(Liang)** + Liang, Phillpot, Sinnott Phys. Rev. B79 245110, (2009), Erratum: Phys. Rev. B85 199903(E), (2012) + **(Lisal)** - M.\ Lisal, J.K. Brennan, J. Bonet Avalos, "Dissipative particle dynamics at isothermal, isobaric, isoenergetic, and isoenthalpic conditions using Shardlow-like splitting algorithms.", + M.\ Lisal, J.K. Brennan, J. Bonet Avalos, J. Chem. Phys., 135, 204105 (2011). **(Liu1)** L.\ Liu, Y. Liu, S. V. Zybin, H. Sun and W. A. Goddard, Journal of Physical Chemistry A, 115, 11016-11022 (2011). @@ -637,6 +796,15 @@ Bibliography **(Luding, 2008)** Luding, S. (2008). Cohesive, frictional powders: contact models for tension. Granular matter, 10(4), 235. +**(Lysogorskiy)** + Lysogorskiy, van der Oord, Bochkarev, Menon, Rinaldi, Hammerschmidt, Mrovec, Thompson, Csanyi, Ortner, Drautz, npj Comp Mat, 7, 97 (2021). + +**(Lysogorskiy21)** + Lysogorskiy, van der Oord, Bochkarev, Menon, Rinaldi, Hammerschmidt, Mrovec, Thompson, Csanyi, Ortner, Drautz, npj Comp Mat, 7, 97 (2021). + +**(Lysogorskiy23)** + Lysogorskiy, Bochkarev, Mrovec, Drautz, Phys Rev Mater, 7, 043801 (2023) / arXiv:2212.08716 (2022). + **(Maaravi)** T.\ Maaravi et al, J. Phys. Chem. C 121, 22826-22835 (2017). @@ -655,12 +823,18 @@ Bibliography **(Maginn)** Kelkar, Rafferty, Maginn, Siepmann, Fluid Phase Equilibria, 260, 218-231 (2007). +**(Mahoney)** + Mahoney, Jorgensen, J Chem Phys 112, 8910 (2000) + **(Malolepsza)** Malolepsza, Secor, Keyes, J Phys Chem B 119 (42), 13379-13384 (2015). **(Mandadapu)** Mandadapu, KK; Templeton, JA; Lee, JW, "Polarization as a field variable from molecular dynamics simulations." Journal of Chemical Physics (2013), 139:054115. Please refer to the standard finite element (FE) texts, e.g. T.J.R Hughes " The finite element method ", Dover 2003, for the basics of FE simulation. +**(Mandelli_1)** + D. Mandelli, W. Ouyang, M. Urbakh, and O. Hod, ACS Nano 13(7), 7603-7609 (2019). + **(Maras)** Maras, Trushin, Stukowski, Ala-Nissila, Jonsson, Comp Phys Comm, 205, 13-21 (2016). @@ -676,6 +850,9 @@ Bibliography **(Martyna1994)** Martyna, Tobias and Klein, J Chem Phys, 101, 4177 (1994). +**(Martyna2)** + G. Martyna, A. Hughes, M. Tuckerman, J. Chem. Phys. 110, 3275 (1999). + **(Mason)** J.\ K. Mason, Acta Cryst A65, 259 (2009). @@ -715,6 +892,9 @@ Bibliography **(Mie)** G.\ Mie, Ann Phys, 316, 657 (1903). +**(Milano)** + G. Milano, S. Goudeau, F. Mueller-Plathe, J. Polym. Sci. B Polym. Phys. 43, 871 (2005). + **(Miller1)** T.\ F. Miller III, M. Eleftheriou, P. Pattnaik, A. Ndirango, G. J. Martyna, J. Chem. Phys., 116, 8649-8659 (2002). @@ -745,12 +925,18 @@ Bibliography **(Mitchell2011a)** Mitchell. A Nonlocal, Ordinary, State-Based Plasticity Model for Peridynamics. Sandia National Lab Report, 3166:1-34 (2011). +**(Miyazaki)** + Miyazaki, Okazaki, Shinoda, J Chem Theory Comput, 16, 782-793 (2020). + **(Mniszewski)** S.\ M. Mniszewski, M. J. Cawkwell, M. E. Wall, J. Mohd-Yusof, N. Bock, T. C. Germann, and A. M. N. Niklasson, J. Chem. Theory Comput., 11, 4644 (2015). **(Monaghan)** Monaghan and Gingold, Journal of Computational Physics, 52, 374-389 (1983). +**(Monti)** + Monti, Clemmer, Srivastava, Silbert, Grest, and Lechman, Phys. Rev. E, (2022). + **(Moore)** Moore, J Chem Phys, 144, 104501 (2016). @@ -770,7 +956,7 @@ Bibliography Morris, Fox, Zhu, J Comp Physics, 136, 214-226 (1997). **(Moustafa)** - Sabry G. Moustafa, Andrew J. Schultz, and David A. Kofke, *Very fast averaging of thermal properties of crystals by molecular simulation*, `Phys. Rev. E [92], 043303 (2015) `_ + Sabry G. Moustafa, Andrew J. Schultz, and David A. Kofke, `Phys. Rev. E [92], 043303 (2015) `_ **(Muller-Plathe1)** Muller-Plathe, J Chem Phys, 106, 6082 (1997). @@ -790,9 +976,6 @@ Bibliography **(Neelov)** Neelov, Holm, J Chem Phys 132, 234103 (2010) -**(Negre2016)** - C.\ F. A. Negre, S. M. Mniszewski, M. J. Cawkwell, N. Bock, M. E. Wall, and A. M. N. Niklasson, J. Chem. Theory Comp., 12, 3063 (2016). - **(Nelson)** Nelson, Halperin, Phys Rev B, 19, 2457 (1979). @@ -802,12 +985,24 @@ Bibliography **(Neyts)** E.\ C. Neyts and A. Bogaerts, Theor. Chem. Acc. 132, 1320 (2013). +**(Nguyen2023)** + Nguyen, Physical Review B, 107(14), 144103, (2023). + +**(Nguyen2024)** + Nguyen, Journal of Computational Physics, 113102, (2024). + +**(Nguyen and Rohskopf)** + Nguyen and Rohskopf, Journal of Computational Physics, 480, 112030, (2023). + +**(Nguyen and Sema)** + Nguyen and Sema, https://arxiv.org/abs/2405.00306, (2024). + +**(NguyenTD)** + Nguyen, Li, Bagchi, Solis, Olvera de la Cruz, Comput Phys Commun 241, 80-19 (2019) + **(Nicholson and Rutledge)** Nicholson and Rutledge, J Chem Phys, 145, 244903 (2016). -**(Nicklas)** - The spline-based MEAM+SW format was first devised and used to develop potentials for bcc transition metals by Jeremy Nicklas, Michael Fellinger, - **(Niklasson2002)** A.\ M. N. Niklasson, Phys. Rev. B, 66, 155115 (2002). @@ -820,6 +1015,9 @@ Bibliography **(Niklasson2017)** A.\ M. N. Niklasson, J. Chem. Phys., 147, 054103 (2017). +**(Nitol)** + Nitol, Dickel, and Barrett, Computational Materials Science 188 (2021): 110207. + **(Noid)** Noid, Chu, Ayton, Krishna, Izvekov, Voth, Das, Andersen, J Chem Phys 128, 134105 (2008). @@ -841,6 +1039,9 @@ Bibliography **(O'Connor)** O'Connor et al., J. Chem. Phys. 142, 024903 (2015). +**(O'Hearn)** + O'Hearn, Alperen, Aktulga, SIAM J. Sci. Comput., 42(1), C1--C22 (2020). + **(Okabe)** T.\ Okabe, M. Kawata, Y. Okamoto, M. Masuhiro, Chem. Phys. Lett., 335, 435-439 (2001). @@ -850,6 +1051,8 @@ Bibliography **(Omelyan)** Omelyan, Mryglod, and Folk. Phys. Rev. Lett. 86(5), 898. (2001). +**(OPLS-AA96)** Jorgensen, Maxwell, Tirado-Rives, J Am Chem Soc, 118(45), 11225-11236 (1996). + **(Oppelstrup)** Oppelstrup, unpublished, 2015. Oppelstrup and Moriarty, to be published. @@ -871,14 +1074,17 @@ Bibliography **(Ouyang2)** W.\ Ouyang et al., J. Chem. Theory Comput. 16(1), 666-676 (2020). -**(PASS)** - PASS webpage: https://www.sdu.dk/en/DPASS +**(Ouyang_1)** + W. Ouyang et al., J. Chem. Theory Comput. 16(1), 666-676 (2020). -**(PLUMED)** - G.A. Tribello, M. Bonomi, D. Branduardi, C. Camilloni and G. Bussi, Comp. Phys. Comm 185, 604 (2014) +**(Ouyang6)** + W. Ouyang, O. Hod, and R. Guerra, J. Chem. Theory Comput. 17, 7215 (2021). -**(Pavlov)** -D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Journal of High Performance Computing Applications, 38, 34-49 (2024). +**(Ouyang7)** + W. Ouyang, et al., J. Chem. Theory Comput. 17, 7237 (2021). + +**(Palkar)** + Palkar V, Kuksenok O, J. Phys. Chem. B, 126 (1), 336-346, 2022 **(Paquay)** Paquay and Kusters, Biophys. J., 110, 6, (2016). preprint available at `arXiv:1411.3019 `_. @@ -889,21 +1095,33 @@ D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Jo **(Parks)** Parks, Lehoucq, Plimpton, Silling, Comp Phys Comm, 179(11), 777-783 (2008). -**(Parrinello1981)** +**(Parrinello)** Parrinello and Rahman, J Appl Phys, 52, 7182 (1981). +**(PASS)** + PASS webpage: https://www.sdu.dk/en/DPASS + **(Paula Leite2016)** Paula Leite , Freitas, Azevedo, and de Koning, J Chem Phys, 126, 044509 (2016). **(Paula Leite2017)** Paula Leite, Santos-Florez, and de Koning, Phys Rev E, 96, 32115 (2017). +**(Pavlov1)** + D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Journal of High Performance Computing Applications, 38, 34-49 (2024). + +**(Pavlov2)** + Pavlov, Galigerov, Kolotinskii, Nikolskiy, Stegailov, "GPU-based Molecular Dynamics of Fluid Flows: Reaching for Turbulence", Int. J. High Perf. Comp. Appl., (2024) + **(Pearlman)** Pearlman, J Chem Phys, 98, 1487 (1994) **(Pedersen)** Pedersen, J. Chem. Phys., 139, 104102 (2013). +**(Pedone)** + A. Pedone, G. Malavasi, M. C. Menziani, A. N. Cormack, and U. Segre, J. Phys. Chem. B, 110, 11780 (2006) + **(Peng)** Peng, Ren, Dudarev, Whelan, Acta Crystallogr. A, 52, 257-76 (1996). @@ -925,6 +1143,9 @@ D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Jo **(Pettifor_3)** D.G. Pettifor and I.I. Oleinik, Phys. Rev. B, 65, 172103 (2002). +**(PFC)** + PFC Particle Flow Code 6.0 Documentation. Itasca Consulting Group. + **(Phillips)** C.\ L. Phillips, J. A. Anderson, S. C. Glotzer, Comput Phys Comm, 230, 7191-7201 (2011). @@ -934,9 +1155,21 @@ D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Jo **(Pisarev)** V V Pisarev and S V Starikov, J. Phys.: Condens. Matter, 26, 475401 (2014). +**(Plimpton)** + Plimpton and Knight, JPDC, 147, 184-195 (2021). + +**(PLUMED)** + G.A. Tribello, M. Bonomi, D. Branduardi, C. Camilloni and G. Bussi, Comp. Phys. Comm 185, 604 (2014) + **(Pollock)** Pollock and Glosli, Comp Phys Comm, 95, 93 (1996). +**(Ponder)** + Ponder, Wu, Ren, Pande, Chodera, Schnieders, Haque, Mobley, Lambrecht, DiStasio Jr, M. Head-Gordon, Clark, Johnson, T. Head-Gordon, J Phys Chem B, 114, 2549-2564 (2010). + +**(Popov1)** + A.M. Popov, I. V. Lebedeva, A. A. Knizhnik, Y. E. Lozovik and B. V. Potapkin, Chem. Phys. Lett. 536, 82-86 (2012). + **(Price1)** Price and Brooks, J Chem Phys, 121, 10096 (2004). @@ -976,6 +1209,12 @@ D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Jo **(Rick)** S.\ W. Rick, S. J. Stuart, B. J. Berne, J Chem Phys 101, 16141 (1994). +**(Rick2)** + S. W. Rick, S. J. Stuart, B. J. Berne, J Chem Phys 101, 6141 + +**(Roberts)** + R. Roberts (2019) "Evenly Distributing Points in a Triangle." Extreme Learning. ``_ + **(Rohart)** Rohart and Thiaville, Physical Review B, 88(18), 184422. (2013). @@ -1012,9 +1251,18 @@ D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Jo **(Sadigh)** B Sadigh, P Erhart, A Stukowski, A Caro, E Martinez, and L Zepeda-Ruiz, Phys. Rev. B, 85, 184203 (2012). +**(Sadigh1)** + B. Sadigh, P. Erhart, A. Stukowski, A. Caro, E. Martinez, and L. Zepeda-Ruiz, Phys. Rev. B **85**, 184203 (2012) + +**(Sadigh2)** + B. Sadigh and P. Erhart, Phys. Rev. B **86**, 134204 (2012) + **(Safran)** Safran, Statistical Thermodynamics of Surfaces, Interfaces, And Membranes, Westview Press, ISBN: 978-0813340791 (2003). +**(Salanne)** + Salanne, Rotenberg, Jahn, Vuilleumier, Simon, Christian and Madden, Theor Chem Acc, 131, 1143 (2012). + **(Salerno)** Salerno, Bernstein, J Chem Theory Comput, --, ---- (2018). @@ -1024,9 +1272,18 @@ D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Jo **(Sanyal2)** Sanyal and Shell, Journal of Physical Chemistry B, 122 (21), 5678-5693. +**(Scalfi)** + Scalfi *et al.*, J. Chem. Phys., 153, 174704 (2020). + **(Schelling)** Patrick K. Schelling, Comp. Mat. Science, 44, 274 (2008). +**(Scherer1)** + C. Scherer and D. Andrienko, Phys. Chem. Chem. Phys. 20, 22387-22394 (2018). + +**(Scherer2)** + C. Scherer, R. Scheid, D. Andrienko, and T. Bereau, J. Chem. Theor. Comp. 16, 3194-3204 (2020). + **(Schlitter1)** Schlitter, Swegat, Mulders, "Distance-type reaction coordinates for modelling activated processes", J Molecular Modeling, 7, 171-177 (2001). @@ -1045,21 +1302,36 @@ D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Jo **(Schroeder)** Schroeder and Steinhauser, J Chem Phys, 133, 154511 (2010). +**(Seleson 2010)** + Seleson, Parks, Int J Mult Comp Eng 9(6), pp. 689-706, 2011. + **(Semaev)** Semaev, Cryptography and Lattices, 181 (2001). +**(Seo)** + Seo, Shinoda, J Chem Theory Comput, 15, 762-774 (2019). + **(Sheppard)** Sheppard, Terrell, Henkelman, J Chem Phys, 128, 134106 (2008). See ref 1 in this paper for original reference to Qmin in Jonsson, Mills, Jacobsen. +**(Shi)** + Shi, Xia, Zhang, Best, Wu, Ponder, Ren, J Chem Theory Comp, 9, 4046, 2013. + **(Shinoda)** Shinoda, DeVane, Klein, Mol Sim, 33, 27 (2007). **(Shinoda)** Shinoda, Shiga, and Mikami, Phys Rev B, 69, 134103 (2004). +**(Shire)** + Shire, Hanley and Stratford, Comp. Part. Mech., (2020). + **(Sides)** Sides, Grest, Stevens, Plimpton, J Polymer Science B, 42, 199-208 (2004). +**(Siepmann)** + Siepmann and Sprik, J. Chem. Phys. 102, 511 (1995). + **(Silbert)** Silbert, Ertas, Grest, Halsey, Levine, Plimpton, Phys Rev E, 64, p 051302 (2001). @@ -1069,12 +1341,21 @@ D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Jo **(Silling 2000)** Silling, J Mech Phys Solids, 48, 175-209 (2000). +**(Silling 2005)** + Silling Askari, Computer and Structures, 83, 1526-1535 (2005). + **(Silling 2007)** Silling, Epton, Weckner, Xu, Askari, J Elasticity, 88, 151-184 (2007). **(Singh)** Singh and Warner, Acta Mater, 58, 5797-5805 (2010), +**(Singraber, Behler and Dellago 2019)** + Singraber, A.; Behler, J.; Dellago, C. J., Chem. Theory Comput. 2019, 15 (3), 1827-1840 + +**(Singraber et al 2019)** + Singraber, A.; Morawietz, T.; Behler, J.; Dellago, C., J. Chem. Theory Comput. 2019, 15 (5), 3075-3092. + **(Sirk1)** Sirk TW, Sliozberg YR, Brennan JK, Lisal M, Andzelm JW, J Chem Phys, 136 (13) 134903, 2012. @@ -1087,6 +1368,9 @@ D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Jo **(Snodin)** B.E. Snodin, F. Randisi, M. Mosayebi, et al., J. Chem. Phys. 142, 234901 (2015). +**(Son)** + Son, McDaniel, Cui and Yethiraj, J Phys Chem Lett, 10, 7523 (2019). + **(Srivastava)** Zhigilei, Wei, Srivastava, Phys. Rev. B 71, 165417 (2005). @@ -1096,6 +1380,12 @@ D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Jo **(Steinhardt)** P.\ Steinhardt, D. Nelson, and M. Ronchetti, Phys. Rev. B 28, 784 (1983). +**(Steward)** + Stewart, Spearot, Modelling Simul. Mater. Sci. Eng. 21, 045003, (2013). + +**(Stewart2018)** + J.A. Stewart, et al. (2018) Journal of Applied Physics, 123(16), 165902. + **(Stiles)** Stiles , Hubbard, and Kayser, J Chem Phys, 77, 6189 (1982). @@ -1153,12 +1443,21 @@ D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Jo **(Tainter 2015)** Tainter, Shi, and Skinner, 11, 2268 (2015) +**(Tang and Toennies)** + J Chem Phys, 80, 3726 (1984). + +**(Tee)** + Tee and Searles, J. Chem. Phys. 156, 184101 (2022). + **(Templeton2010)** Templeton, JA; Jones, RE; Wagner, GJ, "Application of a field-based method to spatially varying thermal transport problems in molecular dynamics." Modelling and Simulation in Materials Science and Engineering (2010), 18:085007. **(Templeton2011)** Templeton, JA; Jones, RE; Lee, JW; Zimmerman, JA; Wong, BM, "A long-range electric field solver for molecular dynamics based on atomistic-to-continuum modeling." Journal of Chemical Theory and Computation (2011), 7:1736. +**(tenWolde)** + P.\ R. ten Wolde, M. J. Ruiz-Montero, D. Frenkel, J. Chem. Phys. 104, 9932 (1996). + **(Tersoff_1)** J.\ Tersoff, Phys Rev B, 37, 6991 (1988). @@ -1201,6 +1500,9 @@ D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Jo **(Tranchida)** Tranchida, Plimpton, Thibaudeau and Thompson, Journal of Computational Physics, 372, 406-425, (2018). +**(Tribello)** + G.A. Tribello, M. Bonomi, D. Branduardi, C. Camilloni and G. Bussi, Comp. Phys. Comm 185, 604 (2014) + **(Tsuji et al, 1992)** Tsuji, Y., Tanaka, T., & Ishida, T. (1992). Lagrangian numerical simulation of plug flow of cohesionless particles in a horizontal pipe. Powder technology, 71(3), @@ -1219,6 +1521,9 @@ D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Jo **(Tuckerman4)** Tuckerman, Mundy, Balasubramanian, Klein, J Chem Phys, 106, 5615 (1997). +**(Tyagi)** + Tyagi, Suzen, Sega, Barbosa, Kantorovich, Holm, J Chem Phys, 132, 154112 (2010) + **(Ulomek)** Ulomek, Brien, Foiles, Mohles, Modelling Simul. Mater. Sci. Eng. 23 (2015) 025007 @@ -1228,6 +1533,15 @@ D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Jo **(Valone)** Valone, Baskes, Martin, Phys. Rev. B, 73, 214209 (2006). +**(vanWijk)** + M. M. van Wijk, A. Schuring, M. I. Katsnelson, and A. Fasolino, Physical Review Letters, 113, 135504 (2014) + +**(Van Workum)** + K. Van Workum et al., J. Chem. Phys. 125 144506 (2006) + +**(Vargas and McCarthy 2001)** + Vargas, W.L. and McCarthy, J.J. (2001). + **(Varshalovich)** Varshalovich, Moskalev, Khersonskii, Quantum Theory of Angular Momentum, World Scientific, Singapore (1987). @@ -1240,6 +1554,9 @@ D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Jo **(Veld)** In 't Veld, Ismail, Grest, J Chem Phys, 127, 144711 (2007). +**(Verstraelen)** + Verstraelen, Ayers, Speybroeck, Waroquier, J. Chem. Phys. 138, 074108 (2013). + **(Volkov1)** Volkov and Zhigilei, J Phys Chem C, 114, 5513 (2010). @@ -1264,6 +1581,9 @@ D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Jo **(Wang et al, 2015)** Wang, Y., Alonso-Marroquin, F., & Guo, W. W. (2015). Rolling and sliding in 3-D discrete element models. Particuology, 23, 49-55. +**(Wang2020)** + X. Wang, S. Ramirez-Hinestrosa, J. Dobnikar, and D. Frenkel, Phys. Chem. Chem. Phys. 22, 10624 (2020). + **(Wang1)** J.\ Wang, H. S. Yu, P. A. Langston, F. Y. Fraige, Granular Matter, 13, 1 (2011). @@ -1303,6 +1623,9 @@ D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Jo **(Wicaksono2)** Wicaksono, figshare, https://doi.org/10.6084/m9.figshare.1488628.v1 (2015). +**(Winkler)** + Winkler, Wysocki, and Gompper, Soft Matter, 11, 6680 (2015). + **(Wirnsberger)** Wirnsberger, Frenkel, and Dellago, J Chem Phys, 143, 124104 (2015). @@ -1315,9 +1638,27 @@ D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Jo **(Wood)** Wood and Thompson, J Chem Phys, 148, 241721, (2018) +**(Xie23)** + Xie, S.R., Rupp, M. & Hennig, R.G. Ultra-fast interpretable machine-learning potentials. npj Comput Mater 9, 162 (2023). https://doi.org/10.1038/s41524-023-01092-7 + +**(Yade-DEM)** + V. Smilauer et al. (2021), Yade Documentation 3rd ed. + +**(Yanxon2020)** + Yanxon, Zagaceta, Tang, Matteson, Zhu, Mach. Learn.: Sci. Technol. 2, 027001 (2020). + **(Yeh)** Yeh and Berkowitz, J Chem Phys, 111, 3155 (1999). +**(Yuan2010a)** + Yuan, Huang, Li, Lykotrafitis, Zhang, Phys. Rev. E, 82, 011905(2010). + +**(Yuan2010b)** + Yuan, Huang, Zhang, Soft. Matter, 6, 4571(2010). + +**(Zagaceta2020)** + Zagaceta, Yanxon, Zhu, J Appl Phys, 128, 045113 (2020). + **(ZBL)** J.F. Ziegler, J.P. Biersack, U. Littmark, 'Stopping and Ranges of Ions in Matter' Vol 1, 1985, Pergamon Press. @@ -1387,17 +1728,6 @@ D Pavlov, V Galigerov, D Kolotinskii, V Nikolskiy, V Stegailov, International Jo **(Zimmerman2010)** Zimmerman, JA; Jones, RE; Templeton, JA, "A material frame approach for evaluating continuum variables in atomistic simulations." Journal of Computational Physics (2010), 229:2364. -**(de Buyl)** - de Buyl, Colberg and Hofling, H5MD: A structured, efficient, and portable file format for molecular data, Comp. Phys. Comm. 185(6), 1546-1553 (2014) - - -**(de Koning)** - de Koning and Antonelli, Phys Rev E, 53, 465 (1996). - **(electronic stopping)** Wikipedia - Electronic Stopping Power: https://en.wikipedia.org/wiki/Stopping_power_%28particle_radiation%29 -**(tenWolde)** - P.\ R. ten Wolde, M. J. Ruiz-Montero, D. Frenkel, J. Chem. Phys. 104, 9932 (1996). - -**(vanWijk)** - M.\ M. van Wijk, A. Schuring, M. I. Katsnelson, and A. Fasolino, Physical Review Letters, 113, 135504 (2014) diff --git a/doc/src/Build_basics.rst b/doc/src/Build_basics.rst index 233b825d01..e82832cf57 100644 --- a/doc/src/Build_basics.rst +++ b/doc/src/Build_basics.rst @@ -37,8 +37,9 @@ standard. A more detailed discussion of that is below. .. code-block:: bash - -D BUILD_MPI=value # yes or no, default is yes if CMake finds MPI, else no - -D BUILD_OMP=value # yes or no, default is yes if a compatible compiler is detected + -D BUILD_MPI=value # yes or no, default is yes if CMake finds MPI + -D BUILD_OMP=value # yes or no, default is yes if a compatible + # compiler is detected -D LAMMPS_MACHINE=name # name = mpi, serial, mybox, titan, laptop, etc # no default value @@ -54,9 +55,9 @@ standard. A more detailed discussion of that is below. .. code-block:: bash - make mpi # parallel build, produces lmp_mpi using Makefile.mpi - make serial # serial build, produces lmp_serial using Makefile/serial - make mybox # uses Makefile.mybox to produce lmp_mybox + make mpi # parallel build, produces lmp_mpi using Makefile.mpi + make serial # serial build, produces lmp_serial using Makefile/serial + make mybox # uses Makefile.mybox to produce lmp_mybox Any ``make machine`` command will look up the make settings from a file ``Makefile.machine`` in the folder ``src/MAKE`` or one of its @@ -74,15 +75,15 @@ standard. A more detailed discussion of that is below. this is ``-fopenmp``\ , which can be added to the ``CC`` and ``LINK`` makefile variables. - For the serial build the following make variables are set (see src/MAKE/Makefile.serial): + For the serial build the following make variables are set (see ``src/MAKE/Makefile.serial``): .. code-block:: make - CC = g++ - LINK = g++ - MPI_INC = -I../STUBS - MPI_PATH = -L../STUBS - MPI_LIB = -lmpi_stubs + CC = g++ + LINK = g++ + MPI_INC = -I../STUBS + MPI_PATH = -L../STUBS + MPI_LIB = -lmpi_stubs You also need to build the STUBS library for your platform before making LAMMPS itself. A ``make serial`` build does this for you @@ -231,24 +232,32 @@ LAMMPS. .. code-block:: bash # Building with GNU Compilers: - cmake ../cmake -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ -DCMAKE_Fortran_COMPILER=gfortran - # Building with Intel Compilers: - cmake ../cmake -DCMAKE_C_COMPILER=icc -DCMAKE_CXX_COMPILER=icpc -DCMAKE_Fortran_COMPILER=ifort + cmake -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ \ + -DCMAKE_Fortran_COMPILER=gfortran ../cmake + # Building with Intel Classic Compilers: + cmake -DCMAKE_C_COMPILER=icc -DCMAKE_CXX_COMPILER=icpc \ + -DCMAKE_Fortran_COMPILER=ifort ../cmake # Building with Intel oneAPI Compilers: - cmake ../cmake -DCMAKE_C_COMPILER=icx -DCMAKE_CXX_COMPILER=icpx -DCMAKE_Fortran_COMPILER=ifx + cmake -DCMAKE_C_COMPILER=icx -DCMAKE_CXX_COMPILER=icpx \ + -DCMAKE_Fortran_COMPILER=ifx ../cmake # Building with LLVM/Clang Compilers: - cmake ../cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_Fortran_COMPILER=flang + cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ \ + -DCMAKE_Fortran_COMPILER=flang ../cmake # Building with PGI/Nvidia Compilers: - cmake ../cmake -DCMAKE_C_COMPILER=pgcc -DCMAKE_CXX_COMPILER=pgc++ -DCMAKE_Fortran_COMPILER=pgfortran + cmake -DCMAKE_C_COMPILER=pgcc -DCMAKE_CXX_COMPILER=pgc++ \ + -DCMAKE_Fortran_COMPILER=pgfortran ../cmake + # Building with the NVHPC Compilers: + cmake -DCMAKE_C_COMPILER=nvc -DCMAKE_CXX_COMPILER=nvc++ \ + -DCMAKE_Fortran_COMPILER=nvfortran ../cmake For compiling with the Clang/LLVM compilers a CMake preset is provided that can be loaded with - `-C ../cmake/presets/clang.cmake`. Similarly, - `-C ../cmake/presets/intel.cmake` should switch the compiler - toolchain to the legacy Intel compilers, `-C ../cmake/presets/oneapi.cmake` + ``-C ../cmake/presets/clang.cmake``. Similarly, + ``-C ../cmake/presets/intel.cmake`` should switch the compiler + toolchain to the legacy Intel compilers, ``-C ../cmake/presets/oneapi.cmake`` will switch to the LLVM based oneAPI Intel compilers, - and `-C ../cmake/presets/pgi.cmake` - will switch the compiler to the PGI compilers. + ``-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. @@ -259,7 +268,7 @@ LAMMPS. When the cmake command completes, it prints a summary to the screen which compilers it is using and what flags and settings will be used for the compilation. Note that if the top-level - compiler is mpicxx, it is simply a wrapper on a real compiler. + compiler is ``mpicxx``, it is simply a wrapper on a real compiler. The underlying compiler info is what CMake will try to determine and report. You should check to confirm you are using the compiler and optimization flags you want. @@ -278,19 +287,19 @@ LAMMPS. .. code-block:: make - CC = mpicxx - CCFLAGS = -g -O3 - LINK = mpicxx - LINKFLAGS = -g -O + CC = mpicxx + CCFLAGS = -g -O3 + LINK = mpicxx + LINKFLAGS = -g -O Serial build with GNU gcc (see ``src/MAKE/Makefile.serial``): .. code-block:: make - CC = g++ - CCFLAGS = -g -O3 - LINK = g++ - LINKFLAGS = -g -O + CC = g++ + CCFLAGS = -g -O3 + LINK = g++ + LINKFLAGS = -g -O .. note:: @@ -316,10 +325,10 @@ LAMMPS. there may be specific compiler or linker flags that are either required or recommended to enable required features and to achieve optimal performance. You need to include these in the - CCFLAGS and LINKFLAGS settings above. For details, see the + ``CCFLAGS`` and ``LINKFLAGS`` settings above. For details, see the documentation for the individual packages listed on the :doc:`Speed_packages` page. Or examine these files in the - src/MAKE/OPTIONS directory. They correspond to each of the 5 + ``src/MAKE/OPTIONS`` directory. They correspond to each of the 5 accelerator packages and their hardware variants: .. code-block:: bash @@ -388,7 +397,8 @@ running LAMMPS from Python via its library interface. make machine # build LAMMPS executable lmp_machine make mode=static machine # same as "make machine" - make mode=shared machine # build LAMMPS shared lib liblammps_machine.so instead + make mode=shared machine # build LAMMPS shared lib liblammps_machine.so + # instead The "static" build will generate a static library called ``liblammps_machine.a`` and an executable named ``lmp_machine``\ , @@ -450,7 +460,7 @@ installation. Including or removing debug support ----------------------------------- -By default the compilation settings will include the *-g* flag which +By default the compilation settings will include the ``-g`` flag which instructs the compiler to include debug information (e.g. which line of source code a particular instruction correspond to). This can be extremely useful in case LAMMPS crashes and can help to provide crucial @@ -463,7 +473,7 @@ If this is a concern, you can change the compilation settings or remove the debug information from the LAMMPS executable: - **Traditional make**: edit your ``Makefile.`` to remove the - *-g* flag from the ``CCFLAGS`` and ``LINKFLAGS`` definitions + ``-g`` flag from the ``CCFLAGS`` and ``LINKFLAGS`` definitions - **CMake**: use ``-D CMAKE_BUILD_TYPE=Release`` or explicitly reset the applicable compiler flags (best done using the text mode or graphical user interface). @@ -488,9 +498,10 @@ using CMake or Make. .. code-block:: bash - -D BUILD_TOOLS=value # yes or no (default). Build binary2txt, chain.x, micelle2d.x, msi2lmp, phana, stl_bin2txt - -D BUILD_LAMMPS_SHELL=value # yes or no (default). Build lammps-shell - -D BUILD_LAMMPS_GUI=value # yes or no (default). Build lammps-gui + -D BUILD_TOOLS=value # yes or no (default). Build binary2txt, + # chain.x, micelle2d.x, msi2lmp, phana, + # stl_bin2txt + -D BUILD_LAMMPS_GUI=value # yes or no (default). Build LAMMPS-GUI The generated binaries will also become part of the LAMMPS installation (see below). @@ -505,8 +516,9 @@ using CMake or Make. make chain # build only chain tool make micelle2d # build only micelle2d tool - cd lammps/tools/lammps-shell - make # build LAMMPS shell + .. note:: + + Building the LAMMPS-GUI *requires* building LAMMPS with CMake. ---------- diff --git a/doc/src/Build_cmake.rst b/doc/src/Build_cmake.rst index e622f9f208..1b2bef936e 100644 --- a/doc/src/Build_cmake.rst +++ b/doc/src/Build_cmake.rst @@ -131,20 +131,20 @@ file called ``CMakeLists.txt`` (for LAMMPS it is located in the configuration step. The cache file contains all current CMake settings. To modify settings, enable or disable features, you need to set -*variables* with either the *-D* command line flag (``-D +*variables* with either the ``-D`` command line flag (``-D VARIABLE1_NAME=value``) or change them in the text mode of the graphical -user interface. The *-D* flag can be used several times in one command. +user interface. The ``-D`` flag can be used several times in one command. For your convenience, we provide :ref:`CMake presets ` that combine multiple settings to enable optional LAMMPS packages or use -a different compiler tool chain. Those are loaded with the *-C* flag +a different compiler tool chain. Those are loaded with the ``-C`` flag (``-C ../cmake/presets/basic.cmake``). This step would only be needed once, as the settings from the preset files are stored in the ``CMakeCache.txt`` file. It is also possible to customize the build -by adding one or more *-D* flags to the CMake command line. +by adding one or more ``-D`` flags to the CMake command line. Generating files for alternate build tools (e.g. Ninja) and project files -for IDEs like Eclipse, CodeBlocks, or Kate can be selected using the *-G* +for IDEs like Eclipse, CodeBlocks, or Kate can be selected using the ``-G`` command line flag. A list of available generator settings for your specific CMake version is given when running ``cmake --help``. @@ -171,7 +171,7 @@ files. E.g. with: In that case the resulting binaries are not in the build folder directly but in subdirectories corresponding to the build type (i.e. Release in the example from above). Similarly, for running unit tests the -configuration is selected with the *-C* flag: +configuration is selected with the ``-C`` flag: .. code-block:: bash diff --git a/doc/src/Build_development.rst b/doc/src/Build_development.rst index 4d8bf0d07f..f315569b24 100644 --- a/doc/src/Build_development.rst +++ b/doc/src/Build_development.rst @@ -88,8 +88,8 @@ on recording all commands required to do the compilation. .. _sanitizer: -Address, Undefined Behavior, and Thread Sanitizer Support (CMake only) ----------------------------------------------------------------------- +Address, Leak, Undefined Behavior, and Thread Sanitizer Support (CMake only) +---------------------------------------------------------------------------- Compilers such as GCC and Clang support generating instrumented binaries which use different sanitizer libraries to detect problems in the code @@ -110,6 +110,7 @@ compilation and linking stages. This is done through setting the -D ENABLE_SANITIZER=none # no sanitizer active (default) -D ENABLE_SANITIZER=address # enable address sanitizer / memory leak checker + -D ENABLE_SANITIZER=hwaddress # enable hardware assisted address sanitizer / memory leak checker -D ENABLE_SANITIZER=leak # enable memory leak checker (only) -D ENABLE_SANITIZER=undefined # enable undefined behavior sanitizer -D ENABLE_SANITIZER=thread # enable thread sanitizer @@ -152,7 +153,12 @@ development headers to compile (if those are not found locally a recent version of that library will be downloaded and compiled along with LAMMPS and the test programs) and will download and compile a specific version of the `GoogleTest `_ C++ -test framework that is used to implement the tests. +test framework that is used to implement the tests. Those unit tests +may be combined with memory access and leak checking with valgrind +(see below for how to enable it). In that case, running so-called +death tests will create a lot of false positives and thus they can be +disabled by configuring compilation with the additional setting +``-D SKIP_DEATH_TESTS=on``. .. admonition:: Software version and LAMMPS configuration requirements :class: note @@ -175,24 +181,24 @@ The output of this command will be looking something like this: $ ctest Test project /home/akohlmey/compile/lammps/build-testing Start 1: RunLammps - 1/563 Test #1: RunLammps .......................................... Passed 0.28 sec + 1/563 Test #1: RunLammps .................................. Passed 0.28 sec Start 2: HelpMessage - 2/563 Test #2: HelpMessage ........................................ Passed 0.06 sec + 2/563 Test #2: HelpMessage ................................ Passed 0.06 sec Start 3: InvalidFlag - 3/563 Test #3: InvalidFlag ........................................ Passed 0.06 sec + 3/563 Test #3: InvalidFlag ................................ Passed 0.06 sec Start 4: Tokenizer - 4/563 Test #4: Tokenizer .......................................... Passed 0.05 sec + 4/563 Test #4: Tokenizer .................................. Passed 0.05 sec Start 5: MemPool - 5/563 Test #5: MemPool ............................................ Passed 0.05 sec + 5/563 Test #5: MemPool .................................... Passed 0.05 sec Start 6: ArgUtils - 6/563 Test #6: ArgUtils ........................................... Passed 0.05 sec + 6/563 Test #6: ArgUtils ................................... Passed 0.05 sec [...] Start 561: ImproperStyle:zero - 561/563 Test #561: ImproperStyle:zero ................................. Passed 0.07 sec + 561/563 Test #561: ImproperStyle:zero ......................... Passed 0.07 sec Start 562: TestMliapPyUnified - 562/563 Test #562: TestMliapPyUnified ................................. Passed 0.16 sec + 562/563 Test #562: TestMliapPyUnified ......................... Passed 0.16 sec Start 563: TestPairList - 563/563 Test #563: TestPairList ....................................... Passed 0.06 sec + 563/563 Test #563: TestPairList ............................... Passed 0.06 sec 100% tests passed, 0 tests failed out of 563 @@ -207,24 +213,25 @@ The output of this command will be looking something like this: The ``ctest`` command has many options, the most important ones are: .. list-table:: + :widths: 20 80 * - Option - Function - * - -V + * - ``-V`` - verbose output: display output of individual test runs - * - -j + * - ``-j `` - parallel run: run tests in parallel - * - -R + * - ``-R `` - run subset of tests matching the regular expression - * - -E + * - ``-E `` - exclude subset of tests matching the regular expression - * - -L + * - ``-L `` - run subset of tests with a label matching the regular expression - * - -LE + * - ``-LE `` - exclude subset of tests with a label matching the regular expression - * - -N + * - ``-N`` - dry-run: display list of tests without running them - * - -T memcheck + * - ``-T memcheck`` - run tests with valgrind memory checker (if available) In its full implementation, the unit test framework will consist of multiple @@ -330,16 +337,17 @@ paths in the individual source files. The force style test programs have a common set of options: .. list-table:: + :widths: 25 75 * - Option - Function - * - -g + * - ``-g `` - regenerate reference data in new YAML file - * - -u + * - ``-u`` - update reference data in the original YAML file - * - -s + * - ``-s`` - print error statistics for each group of comparisons - * - -v + * - ``-v`` - verbose output: also print the executed LAMMPS commands The ``ctest`` tool has no mechanism to directly pass flags to the individual @@ -353,10 +361,10 @@ set in an environment variable ``TEST_ARGS``. Example: To add a test for a style that is not yet covered, it is usually best to copy a YAML file for a similar style to a new file, edit the details of the style (how to call it, how to set its coefficients) and then -run test command with either the *-g* and the replace the initial -test file with the regenerated one or the *-u* option. The *-u* option +run test command with either the ``-g`` and the replace the initial +test file with the regenerated one or the ``-u`` option. The ``-u`` option will destroy the original file, if the generation run does not complete, -so using *-g* is recommended unless the YAML file is fully tested +so using ``-g`` is recommended unless the YAML file is fully tested and working. Some of the force style tests are rather slow to run and some are very @@ -506,27 +514,51 @@ After post-processing with ``gen_coverage_html`` the results are in a folder ``coverage_html`` and can be viewed with a web browser. The images below illustrate how the data is presented. -.. list-table:: +.. only:: not latex - * - .. figure:: JPG/coverage-overview-top.png - :scale: 25% + .. list-table:: - Top of the overview page + * - .. figure:: JPG/coverage-overview-top.png + :scale: 25% - - .. figure:: JPG/coverage-overview-manybody.png - :scale: 25% + Top of the overview page - Styles with good coverage + - .. figure:: JPG/coverage-overview-manybody.png + :scale: 25% - - .. figure:: JPG/coverage-file-top.png - :scale: 25% + Styles with good coverage - Top of individual source page + - .. figure:: JPG/coverage-file-top.png + :scale: 25% - - .. figure:: JPG/coverage-file-branches.png - :scale: 25% + Top of individual source page - Source page with branches + - .. figure:: JPG/coverage-file-branches.png + :scale: 25% + + Source page with branches + +.. only:: latex + + .. figure:: JPG/coverage-overview-top.png + :width: 60% + + Top of the overview page + + .. figure:: JPG/coverage-overview-manybody.png + :width: 60% + + Styles with good coverage + + .. figure:: JPG/coverage-file-top.png + :width: 60% + + Top of individual source page + + .. figure:: JPG/coverage-file-branches.png + :width: 60% + + Source page with branches Coding style utilities ---------------------- @@ -598,11 +630,35 @@ The following target are available for both, GNU make and CMake: GitHub command line interface ----------------------------- -GitHub is developing a `tool for the command line -`_ that interacts with the GitHub website via a -command called ``gh``. This can be extremely convenient when working -with a Git repository hosted on GitHub (like LAMMPS). It is thus highly -recommended to install it when doing LAMMPS development. +GitHub has developed a `command line tool `_ +to interact with the GitHub website via a command called ``gh``. +This is extremely convenient when working with a Git repository hosted +on GitHub (like LAMMPS). It is thus highly recommended to install it +when doing LAMMPS development. To use ``gh`` you must be within a git +checkout of a repository and you must obtain an authentication token +to connect your checkout with a GitHub user. This is done with the +command: ``gh auth login`` where you then have to follow the prompts. +Here are some examples: -The capabilities of the ``gh`` command is continually expanding, so -please see the documentation at https://cli.github.com/manual/ +.. list-table:: + :header-rows: 1 + :widths: 34 66 + + * - Command + - Description + * - ``gh pr list`` + - List currently open pull requests + * - ``gh pr checks 404`` + - Shows the status of all checks for pull request #404 + * - ``gh pr view 404`` + - Shows the description and recent comments for pull request #404 + * - ``gh co 404`` + - Check out the branch from pull request #404; set up for pushing changes + * - ``gh issue list`` + - List currently open issues + * - ``gh issue view 430 --comments`` + - Shows the description and all comments for issue #430 + +The capabilities of the ``gh`` command are continually expanding, so +for more details please see the documentation at https://cli.github.com/manual/ +or use ``gh --help`` or ``gh --help`` for embedded help. diff --git a/doc/src/Build_extras.rst b/doc/src/Build_extras.rst index f66238c3c9..ac7edc7678 100644 --- a/doc/src/Build_extras.rst +++ b/doc/src/Build_extras.rst @@ -7,6 +7,8 @@ in addition to .. list-table:: :align: center :header-rows: 1 + :widths: 50 50 + :width: 80% * - CMake build - Traditional make @@ -14,7 +16,7 @@ in addition to cmake -D PKG_NAME=yes - - .. code-block:: console + - .. code-block:: bash make yes-name @@ -59,6 +61,7 @@ This is the list of packages that may require additional steps. * :ref:`POEMS ` * :ref:`PYTHON ` * :ref:`QMMM ` + * :ref:`RHEO ` * :ref:`SCAFACOS ` * :ref:`VORONOI ` * :ref:`VTK ` @@ -72,7 +75,7 @@ COMPRESS package To build with this package you must have the `zlib compression library `_ available on your system to build dump styles with -a '/gz' suffix. There are also styles using the +a ``/gz`` suffix. There are also styles using the `Zstandard `_ library which have a '/zstd' suffix. The zstd library version must be at least 1.4. Older versions use an incompatible API and thus LAMMPS will fail to compile. @@ -94,7 +97,7 @@ versions use an incompatible API and thus LAMMPS will fail to compile. `_ tool to identify the necessary flags to compile with this library, so the corresponding ``libzstandard.pc`` file must be in a folder where - pkg-config can find it, which may require adding it to the + ``pkg-config`` can find it, which may require adding it to the ``PKG_CONFIG_PATH`` environment variable. .. tab:: Traditional make @@ -114,7 +117,7 @@ GPU package To build with this package, you must choose options for precision and which GPU hardware to build for. The GPU package currently supports -three different types of backends: OpenCL, CUDA and HIP. +three different types of back ends: OpenCL, CUDA and HIP. CMake build ^^^^^^^^^^^ @@ -126,46 +129,53 @@ CMake build # value = double or mixed (default) or single -D GPU_ARCH=value # primary GPU hardware choice for GPU_API=cuda # value = sm_XX (see below, default is sm_50) - -D GPU_DEBUG=value # enable debug code in the GPU package library, mostly useful for developers + -D GPU_DEBUG=value # enable debug code in the GPU package library, + # mostly useful for developers # value = yes or no (default) - -D HIP_PATH=value # value = path to HIP installation. Must be set if GPU_API=HIP + -D HIP_PATH=value # value = path to HIP installation. Must be set if + # GPU_API=HIP -D HIP_ARCH=value # primary GPU hardware choice for GPU_API=hip # value depends on selected HIP_PLATFORM - # default is 'gfx906' for HIP_PLATFORM=amd and 'sm_50' for HIP_PLATFORM=nvcc + # default is 'gfx906' for HIP_PLATFORM=amd and 'sm_50' for + # HIP_PLATFORM=nvcc -D HIP_USE_DEVICE_SORT=value # enables GPU sorting # value = yes (default) or no - -D CUDPP_OPT=value # use GPU binning on with CUDA (should be off for modern GPUs) - # enables CUDA Performance Primitives, must be "no" for CUDA_MPS_SUPPORT=yes + -D CUDPP_OPT=value # use GPU binning with CUDA (should be off for modern GPUs) + # enables CUDA Performance Primitives, must be "no" for + # CUDA_MPS_SUPPORT=yes # value = yes or no (default) - -D CUDA_MPS_SUPPORT=value # enables some tweaks required to run with active nvidia-cuda-mps daemon + -D CUDA_MPS_SUPPORT=value # enables some tweaks required to run with active + # nvidia-cuda-mps daemon # value = yes or no (default) - -D CUDA_BUILD_MULTIARCH=value # enables building CUDA kernels for all supported GPU architectures + -D CUDA_BUILD_MULTIARCH=value # enables building CUDA kernels for all supported GPU + # architectures # value = yes (default) or no - -D USE_STATIC_OPENCL_LOADER=value # downloads/includes OpenCL ICD loader library, no local OpenCL headers/libs needed + -D USE_STATIC_OPENCL_LOADER=value # downloads/includes OpenCL ICD loader library, + # no local OpenCL headers/libs needed # value = yes (default) or no -:code:`GPU_ARCH` settings for different GPU hardware is as follows: +``GPU_ARCH`` settings for different GPU hardware is as follows: -* sm_30 for Kepler (supported since CUDA 5 and until CUDA 10.x) -* sm_35 or sm_37 for Kepler (supported since CUDA 5 and until CUDA 11.x) -* sm_50 or sm_52 for Maxwell (supported since CUDA 6) -* sm_60 or sm_61 for Pascal (supported since CUDA 8) -* sm_70 for Volta (supported since CUDA 9) -* sm_75 for Turing (supported since CUDA 10) -* sm_80 or sm_86 for Ampere (supported since CUDA 11, sm_86 since CUDA 11.1) -* sm_89 for Lovelace (supported since CUDA 11.8) -* sm_90 for Hopper (supported since CUDA 12.0) +* ``sm_30`` for Kepler (supported since CUDA 5 and until CUDA 10.x) +* ``sm_35`` or ``sm_37`` for Kepler (supported since CUDA 5 and until CUDA 11.x) +* ``sm_50`` or ``sm_52`` for Maxwell (supported since CUDA 6) +* ``sm_60`` or ``sm_61`` for Pascal (supported since CUDA 8) +* ``sm_70`` for Volta (supported since CUDA 9) +* ``sm_75`` for Turing (supported since CUDA 10) +* ``sm_80`` or sm_86 for Ampere (supported since CUDA 11, sm_86 since CUDA 11.1) +* ``sm_89`` for Lovelace (supported since CUDA 11.8) +* ``sm_90`` for Hopper (supported since CUDA 12.0) A more detailed list can be found, for example, at `Wikipedia's CUDA article `_ CMake can detect which version of the CUDA toolkit is used and thus will try to include support for **all** major GPU architectures supported by -this toolkit. Thus the GPU_ARCH setting is merely an optimization, to +this toolkit. Thus the ``GPU_ARCH`` setting is merely an optimization, to have code for the preferred GPU architecture directly included rather than having to wait for the JIT compiler of the CUDA driver to translate it. This behavior can be turned off (e.g. to speed up compilation) by -setting :code:`CUDA_ENABLE_MULTIARCH` to :code:`no`. +setting ``CUDA_ENABLE_MULTIARCH`` to ``no``. When compiling for CUDA or HIP with CUDA, version 8.0 or later of the CUDA toolkit is required and a GPU architecture of Kepler or later, @@ -184,21 +194,21 @@ build, and link with a static OpenCL ICD loader library and standard OpenCL headers. This way no local OpenCL development headers or library needs to be present and only OpenCL compatible drivers need to be installed to use OpenCL. If this is not desired, you can set -:code:`USE_STATIC_OPENCL_LOADER` to :code:`no`. +``USE_STATIC_OPENCL_LOADER`` to ``no``. The GPU library has some multi-thread support using OpenMP. If LAMMPS is built with ``-D BUILD_OMP=on`` this will also be enabled. If you are compiling with HIP, note that before running CMake you will have to set appropriate environment variables. Some variables such as -:code:`HCC_AMDGPU_TARGET` (for ROCm <= 4.0) or :code:`CUDA_PATH` are -necessary for :code:`hipcc` and the linker to work correctly. +``HCC_AMDGPU_TARGET`` (for ROCm <= 4.0) or ``CUDA_PATH`` are +necessary for ``hipcc`` and the linker to work correctly. .. versionadded:: 3Aug2022 Using the CHIP-SPV implementation of HIP is supported. It allows one to -run HIP code on Intel GPUs via the OpenCL or Level Zero backends. To use -CHIP-SPV, you must set :code:`-DHIP_USE_DEVICE_SORT=OFF` in your CMake +run HIP code on Intel GPUs via the OpenCL or Level Zero back ends. To use +CHIP-SPV, you must set ``-DHIP_USE_DEVICE_SORT=OFF`` in your CMake command line as CHIP-SPV does not yet support hipCUB. As of Summer 2022, the use of HIP for Intel GPUs is experimental. You should only use this option in preparations to run on Aurora system at Argonne. @@ -256,28 +266,35 @@ script with the specified args: .. code-block:: bash - make lib-gpu # print help message - make lib-gpu args="-b" # build GPU library with default Makefile.linux - make lib-gpu args="-m xk7 -p single -o xk7.single" # create new Makefile.xk7.single, altered for single-precision - make lib-gpu args="-m mpi -a sm_60 -p mixed -b" # build GPU library with mixed precision and P100 using other settings in Makefile.mpi + # print help message + make lib-gpu + + # build GPU library with default Makefile.linux + make lib-gpu args="-b" + + # create new Makefile.xk7.single, altered for single-precision + make lib-gpu args="-m xk7 -p single -o xk7.single" + + # build GPU library with mixed precision and P100 using other settings in Makefile.mpi + make lib-gpu args="-m mpi -a sm_60 -p mixed -b" Note that this procedure starts with a Makefile.machine in lib/gpu, as -specified by the "-m" switch. For your convenience, machine makefiles +specified by the ``-m`` switch. For your convenience, machine makefiles for "mpi" and "serial" are provided, which have the same settings as the corresponding machine makefiles in the main LAMMPS source folder. In addition you can alter 4 important settings in the -Makefile.machine you start from via the corresponding -c, -a, -p, -e +Makefile.machine you start from via the corresponding ``-c``, ``-a``, ``-p``, ``-e`` switches (as in the examples above), and also save a copy of the new Makefile if desired: * ``CUDA_HOME`` = where NVIDIA CUDA software is installed on your system -* ``CUDA_ARCH`` = sm_XX, what GPU hardware you have, same as CMake GPU_ARCH above +* ``CUDA_ARCH`` = ``sm_XX``, what GPU hardware you have, same as CMake ``GPU_ARCH`` above * ``CUDA_PRECISION`` = precision (double, mixed, single) -* ``EXTRAMAKE`` = which Makefile.lammps.\* file to copy to Makefile.lammps +* ``EXTRAMAKE`` = which ``Makefile.lammps.*`` file to copy to Makefile.lammps -The file Makefile.cuda is set up to include support for multiple +The file ``Makefile.cuda`` is set up to include support for multiple GPU architectures as supported by the CUDA toolkit in use. This is done -through using the "--gencode " flag, which can be used multiple times and +through using the ``--gencode`` flag, which can be used multiple times and thus support all GPU architectures supported by your CUDA compiler. To enable GPU binning via CUDA performance primitives set the Makefile variable @@ -348,12 +365,16 @@ minutes to hours) to build. Of course you only need to do that once.) .. code-block:: bash - -D DOWNLOAD_KIM=value # download OpenKIM API v2 for build, value = no (default) or yes - -D LMP_DEBUG_CURL=value # set libcurl verbose mode on/off, value = off (default) or on - -D LMP_NO_SSL_CHECK=value # tell libcurl to not verify the peer, value = no (default) or yes - -D KIM_EXTRA_UNITTESTS=value # enables extra unit tests, value = no (default) or yes + -D DOWNLOAD_KIM=value # download OpenKIM API v2 for build + # value = no (default) or yes + -D LMP_DEBUG_CURL=value # set libcurl verbose mode on/off + # value = off (default) or on + -D LMP_NO_SSL_CHECK=value # tell libcurl to not verify the peer + # value = no (default) or yes + -D KIM_EXTRA_UNITTESTS=value # enables extra unit tests + # value = no (default) or yes - If ``DOWNLOAD_KIM`` is set to *yes* (or *on*), the KIM API library + If ``DOWNLOAD_KIM`` is set to ``yes`` (or ``on``), the KIM API library will be downloaded and built inside the CMake build directory. If the KIM library is already installed on your system (in a location where CMake cannot find it), you may need to set the @@ -361,7 +382,7 @@ minutes to hours) to build. Of course you only need to do that once.) found, or run the command ``source kim-api-activate``. Extra unit tests can only be available if they are explicitly requested - (``KIM_EXTRA_UNITTESTS`` is set to *yes* (or *on*)) and the prerequisites + (``KIM_EXTRA_UNITTESTS`` is set to ``yes`` (or ``on``)) and the prerequisites are met. See :ref:`KIM Extra unit tests ` for more details on this. @@ -375,15 +396,28 @@ minutes to hours) to build. Of course you only need to do that once.) .. code-block:: bash - make lib-kim # print help message - make lib-kim args="-b " # (re-)install KIM API lib with only example models - make lib-kim args="-b -a Glue_Ercolessi_Adams_Al__MO_324507536345_001" # ditto plus one model - make lib-kim args="-b -a everything" # install KIM API lib with all models - make lib-kim args="-n -a EAM_Dynamo_Ackland_W__MO_141627196590_002" # add one model or model driver - make lib-kim args="-p /usr/local" # use an existing KIM API installation at the provided location - make lib-kim args="-p /usr/local -a EAM_Dynamo_Ackland_W__MO_141627196590_002" # ditto but add one model or driver + # print help message + make lib-kim - When using the "-b " option, the KIM library is built using its native + # (re-)install KIM API lib with only example models + make lib-kim args="-b" + + # ditto plus one model + make lib-kim args="-b -a Glue_Ercolessi_Adams_Al__MO_324507536345_001" + + # install KIM API lib with all models + make lib-kim args="-b -a everything" + + # add one model or model driver + make lib-kim args="-n -a EAM_Dynamo_Ackland_W__MO_141627196590_002" + + # use an existing KIM API installation at the provided location + make lib-kim args="-p " + + # ditto but add one model or driver + make lib-kim args="-p -a EAM_Dynamo_Ackland_W__MO_141627196590_002" + + When using the ``-b`` option, the KIM library is built using its native cmake build system. The ``lib/kim/Install.py`` script supports a ``CMAKE`` environment variable if the cmake executable is named other than ``cmake`` on your system. Additional environment variables may be @@ -393,7 +427,9 @@ minutes to hours) to build. Of course you only need to do that once.) .. code-block:: bash - CMAKE=cmake3 CXX=g++-11 CC=gcc-11 FC=gfortran-11 make lib-kim args="-b " # (re-)install KIM API lib using cmake3 and gnu v11 compilers with only example models + # (re-)install KIM API lib using cmake3 and gnu v11 compilers + # with only example models + CMAKE=cmake3 CXX=g++-11 CC=gcc-11 FC=gfortran-11 make lib-kim args="-b" Settings for debugging OpenKIM web queries discussed below need to be applied by adding them to the ``LMP_INC`` variable through @@ -433,7 +469,7 @@ KIM Extra unit tests (CMake only) During development, testing, or debugging, if :doc:`unit testing ` is enabled in LAMMPS, one can also enable extra tests on :doc:`KIM commands ` by setting the -``KIM_EXTRA_UNITTESTS`` to *yes* (or *on*). +``KIM_EXTRA_UNITTESTS`` to ``yes`` (or ``on``). Enabling the extra unit tests have some requirements, @@ -448,10 +484,12 @@ Enabling the extra unit tests have some requirements, *conda-forge* channel as ``conda install kim-property`` if LAMMPS is built in Conda. More detailed information is available at: `kim-property installation `_. -* It is also necessary to install - ``EAM_Dynamo_MendelevAckland_2007v3_Zr__MO_004835508849_000``, - ``EAM_Dynamo_ErcolessiAdams_1994_Al__MO_123629422045_005``, and - ``LennardJones612_UniversalShifted__MO_959249795837_003`` KIM models. +* It is also necessary to install the following KIM models: + + * ``EAM_Dynamo_MendelevAckland_2007v3_Zr__MO_004835508849_000`` + * ``EAM_Dynamo_ErcolessiAdams_1994_Al__MO_123629422045_005`` + * ``LennardJones612_UniversalShifted__MO_959249795837_003`` + See `Obtaining KIM Models `_ to learn how to install a pre-built binary of the OpenKIM Repository of Models or see @@ -638,6 +676,9 @@ They must be specified in uppercase. * - AMD_GFX1100 - GPU - AMD GPU RX7900XTX + * - AMD_GFX1103 + - GPU + - AMD Phoenix APU with Radeon 740M/760M/780M/880M/890M * - INTEL_GEN - GPU - SPIR64-based devices, e.g. Intel GPUs, using JIT @@ -712,20 +753,34 @@ This list was last updated for version 4.3.0 of the Kokkos library. platform-appropriate vendor library: rocFFT on AMD GPUs or cuFFT on NVIDIA GPUs. - To simplify compilation, five preset files are included in the + For Intel GPUs using SYCL, set these variables: + + .. code-block:: bash + + -D Kokkos_ARCH_HOSTARCH=yes # HOSTARCH = HOST from list above + -D Kokkos_ARCH_GPUARCH=yes # GPUARCH = GPU from list above + -D Kokkos_ENABLE_SYCL=yes + -D Kokkos_ENABLE_OPENMP=yes + -D FFT_KOKKOS=MKL_GPU + + This will enable FFTs on the GPU using the oneMKL library. + + To simplify compilation, six preset files are included in the ``cmake/presets`` folder, ``kokkos-serial.cmake``, ``kokkos-openmp.cmake``, ``kokkos-cuda.cmake``, - ``kokkos-hip.cmake``, and ``kokkos-sycl.cmake``. They will enable - the KOKKOS package and enable some hardware choices. For GPU - support those preset files must be customized to match the - hardware used. So to compile with CUDA device parallelization with - some common packages enabled, you can do the following: + ``kokkos-hip.cmake``, ``kokkos-sycl-nvidia.cmake``, and + ``kokkos-sycl-intel.cmake``. They will enable the KOKKOS + package and enable some hardware choices. For GPU support those + preset files must be customized to match the hardware used. So + to compile with CUDA device parallelization with some common + packages enabled, you can do the following: .. code-block:: bash mkdir build-kokkos-cuda cd build-kokkos-cuda - cmake -C ../cmake/presets/basic.cmake -C ../cmake/presets/kokkos-cuda.cmake ../cmake + cmake -C ../cmake/presets/basic.cmake \ + -C ../cmake/presets/kokkos-cuda.cmake ../cmake cmake --build . .. tab:: Basic traditional make settings: @@ -753,9 +808,10 @@ This list was last updated for version 4.3.0 of the Kokkos library. .. code-block:: make KOKKOS_DEVICES = Cuda - KOKKOS_ARCH = HOSTARCH,GPUARCH # HOSTARCH = HOST from list above that is hosting the GPU - KOKKOS_CUDA_OPTIONS = "enable_lambda" + KOKKOS_ARCH = HOSTARCH,GPUARCH # HOSTARCH = HOST from list above that is + # hosting the GPU # GPUARCH = GPU from list above + KOKKOS_CUDA_OPTIONS = "enable_lambda" FFT_INC = -DFFT_CUFFT # enable use of cuFFT (optional) FFT_LIB = -lcufft # link to cuFFT library @@ -783,10 +839,23 @@ This list was last updated for version 4.3.0 of the Kokkos library. .. code-block:: make KOKKOS_DEVICES = HIP - KOKKOS_ARCH = HOSTARCH,GPUARCH # HOSTARCH = HOST from list above that is hosting the GPU + KOKKOS_ARCH = HOSTARCH,GPUARCH # HOSTARCH = HOST from list above that is + # hosting the GPU # GPUARCH = GPU from list above - FFT_INC = -DFFT_HIPFFT # enable use of hipFFT (optional) - FFT_LIB = -lhipfft # link to hipFFT library + FFT_INC = -DFFT_HIPFFT # enable use of hipFFT (optional) + FFT_LIB = -lhipfft # link to hipFFT library + + For Intel GPUs using SYCL: + + .. code-block:: make + + KOKKOS_DEVICES = SYCL + KOKKOS_ARCH = HOSTARCH,GPUARCH # HOSTARCH = HOST from list above that is + # hosting the GPU + # GPUARCH = GPU from list above + FFT_INC = -DFFT_KOKKOS_MKL_GPU # enable use of oneMKL for Intel GPUs (optional) + # link to oneMKL FFT library + FFT_LIB = -lmkl_sycl_dft -lmkl_intel_ilp64 -lmkl_tbb_thread -mkl_core -ltbb Advanced KOKKOS compilation settings ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -870,11 +939,16 @@ included in the LAMMPS source distribution in the ``lib/lepton`` folder. .. code-block:: bash - make lib-lepton # print help message - make lib-lepton args="-m serial" # build with GNU g++ compiler (settings as with "make serial") - make lib-lepton args="-m mpi" # build with default MPI compiler (settings as with "make mpi") + # print help message + make lib-lepton - The "machine" argument of the "-m" flag is used to find a + # build with GNU g++ compiler (settings as with "make serial") + make lib-lepton args="-m serial" + + # build with default MPI compiler (settings as with "make mpi") + make lib-lepton args="-m mpi" + + The "machine" argument of the ``-m`` flag is used to find a Makefile.machine to use as build recipe. The build should produce a ``build`` folder and the library ``lib/lepton/liblmplepton.a`` @@ -896,7 +970,8 @@ Eigen3 is a template library, so you do not need to build it. .. code-block:: bash -D DOWNLOAD_EIGEN3 # download Eigen3, value = no (default) or yes - -D EIGEN3_INCLUDE_DIR=path # path to Eigen library (only needed if a custom location) + -D EIGEN3_INCLUDE_DIR=path # path to Eigen library (only needed if a + # custom location) If ``DOWNLOAD_EIGEN3`` is set, the Eigen3 library will be downloaded and inside the CMake build directory. If the Eigen3 @@ -914,9 +989,14 @@ Eigen3 is a template library, so you do not need to build it. .. code-block:: bash - make lib-machdyn # print help message - make lib-machdyn args="-b" # download to lib/machdyn/eigen3 - make lib-machdyn args="-p /usr/include/eigen3" # use existing Eigen installation in /usr/include/eigen3 + # print help message + make lib-machdyn + + # download to lib/machdyn/eigen3 + make lib-machdyn args="-b" + + # use existing Eigen installation in /usr/include/eigen3 + make lib-machdyn args="-p /usr/include/eigen3" Note that a symbolic (soft) link named ``includelink`` is created in ``lib/machdyn`` to point to the Eigen dir. When LAMMPS builds it @@ -990,7 +1070,7 @@ OPT package The compiler flag ``-restrict`` must be used to build LAMMPS with the OPT package when using Intel compilers. It should be added to - the :code:`CCFLAGS` line of your ``Makefile.machine``. See + the ``CCFLAGS`` line of your ``Makefile.machine``. See ``src/MAKE/OPTIONS/Makefile.opt`` for an example. ---------- @@ -1017,10 +1097,17 @@ POEMS package .. code-block:: bash - make lib-poems # print help message - make lib-poems args="-m serial" # build with GNU g++ compiler (settings as with "make serial") - make lib-poems args="-m mpi" # build with default MPI C++ compiler (settings as with "make mpi") - make lib-poems args="-m icc" # build with Intel icc compiler + # print help message + make lib-poems + + # build with GNU g++ compiler (settings as with "make serial") + make lib-poems args="-m serial" + + # build with default MPI C++ compiler (settings as with "make mpi") + make lib-poems args="-m mpi" + + # build with Intel Classic compiler + make lib-poems args="-m icc" The build should produce two files: ``lib/poems/libpoems.a`` and ``lib/poems/Makefile.lammps``. The latter is copied from an @@ -1084,9 +1171,12 @@ binary package provided by your operating system. .. code-block:: bash - -D DOWNLOAD_VORO=value # download Voro++ for build, value = no (default) or yes - -D VORO_LIBRARY=path # Voro++ library file (only needed if at custom location) - -D VORO_INCLUDE_DIR=path # Voro++ include directory (only needed if at custom location) + -D DOWNLOAD_VORO=value # download Voro++ for build + # value = no (default) or yes + -D VORO_LIBRARY=path # Voro++ library file + # (only needed if at custom location) + -D VORO_INCLUDE_DIR=path # Voro++ include directory + # (only needed if at custom location) If ``DOWNLOAD_VORO`` is set, the Voro++ library will be downloaded and built inside the CMake build directory. If the Voro++ library @@ -1106,12 +1196,19 @@ binary package provided by your operating system. .. code-block:: bash - make lib-voronoi # print help message - make lib-voronoi args="-b" # download and build the default version in lib/voronoi/voro++- - make lib-voronoi args="-p $HOME/voro++" # use existing Voro++ installation in $HOME/voro++ - make lib-voronoi args="-b -v voro++0.4.6" # download and build the 0.4.6 version in lib/voronoi/voro++-0.4.6 + # print help message + make lib-voronoi - Note that 2 symbolic (soft) links, ``includelink`` and + # download and build the default version in lib/voronoi/voro++- + make lib-voronoi args="-b" + + # use existing Voro++ installation in $HOME/voro++ + make lib-voronoi args="-p $HOME/voro++" + + # download and build the 0.4.6 version in lib/voronoi/voro++-0.4.6 + make lib-voronoi args="-b -v voro++0.4.6" + + Note that two symbolic (soft) links, ``includelink`` and ``liblink``, are created in lib/voronoi to point to the Voro++ source dir. When LAMMPS builds in ``src`` it will use these links. You should not need to edit the @@ -1185,10 +1282,17 @@ The ATC package requires the MANYBODY package also be installed. .. code-block:: bash - make lib-atc # print help message - make lib-atc args="-m serial" # build with GNU g++ compiler and MPI STUBS (settings as with "make serial") - make lib-atc args="-m mpi" # build with default MPI compiler (settings as with "make mpi") - make lib-atc args="-m icc" # build with Intel icc compiler + # print help message + make lib-atc + + # build with GNU g++ compiler and MPI STUBS (settings as with "make serial") + make lib-atc args="-m serial" + + # build with default MPI compiler (settings as with "make mpi") + make lib-atc args="-m mpi" + + # build with Intel Classic compiler + make lib-atc args="-m icc" The build should produce two files: ``lib/atc/libatc.a`` and ``lib/atc/Makefile.lammps``. The latter is copied from an @@ -1207,10 +1311,17 @@ The ATC package requires the MANYBODY package also be installed. .. code-block:: bash - make lib-linalg # print help message - make lib-linalg args="-m serial" # build with GNU C++ compiler (settings as with "make serial") - make lib-linalg args="-m mpi" # build with default MPI C++ compiler (settings as with "make mpi") - make lib-linalg args="-m g++" # build with GNU Fortran compiler + # print help message + make lib-linalg + + # build with GNU C++ compiler (settings as with "make serial") + make lib-linalg args="-m serial" + + # build with default MPI C++ compiler (settings as with "make mpi") + make lib-linalg args="-m mpi" + + # build with GNU Fortran compiler + make lib-linalg args="-m g++" ---------- @@ -1236,10 +1347,17 @@ AWPMD package .. code-block:: bash - make lib-awpmd # print help message - make lib-awpmd args="-m serial" # build with GNU g++ compiler and MPI STUBS (settings as with "make serial") - make lib-awpmd args="-m mpi" # build with default MPI compiler (settings as with "make mpi") - make lib-awpmd args="-m icc" # build with Intel icc compiler + # print help message + make lib-awpmd + + # build with GNU g++ compiler and MPI STUBS (settings as with "make serial") + make lib-awpmd args="-m serial" + + # build with default MPI compiler (settings as with "make mpi") + make lib-awpmd args="-m mpi" + + # build with Intel Classic compiler + make lib-awpmd args="-m icc" The build should produce two files: ``lib/awpmd/libawpmd.a`` and ``lib/awpmd/Makefile.lammps``. The latter is copied from an @@ -1258,10 +1376,17 @@ AWPMD package .. code-block:: bash - make lib-linalg # print help message - make lib-linalg args="-m serial" # build with GNU C++ compiler (settings as with "make serial") - make lib-linalg args="-m mpi" # build with default MPI C++ compiler (settings as with "make mpi") - make lib-linalg args="-m g++" # build with GNU C++ compiler + # print help message + make lib-linalg + + # build with GNU C++ compiler (settings as with "make serial") + make lib-linalg args="-m serial" + + # build with default MPI C++ compiler (settings as with "make mpi") + make lib-linalg args="-m mpi" + + # build with GNU C++ compiler + make lib-linalg args="-m g++" ---------- @@ -1294,10 +1419,17 @@ module included in the LAMMPS source distribution. .. code-block:: bash - make lib-colvars # print help message - make lib-colvars args="-m serial" # build with GNU g++ compiler (settings as with "make serial") - make lib-colvars args="-m mpi" # build with default MPI compiler (settings as with "make mpi") - make lib-colvars args="-m g++-debug" # build with GNU g++ compiler and colvars debugging enabled + # print help message + make lib-colvars + + # build with GNU g++ compiler (settings as with "make serial") + make lib-colvars args="-m serial" + + # build with default MPI compiler (settings as with "make mpi") + make lib-colvars args="-m mpi" + + # build with GNU g++ compiler and colvars debugging enabled + make lib-colvars args="-m g++-debug" The "machine" argument of the "-m" flag is used to find a ``Makefile.machine`` file to use as build recipe. If such recipe does @@ -1316,8 +1448,11 @@ module included in the LAMMPS source distribution. .. code-block:: bash - COLVARS_DEBUG=yes make lib-colvars args="-m machine" # Build with debug code (much slower) - COLVARS_LEPTON=no make lib-colvars args="-m machine" # Build without Lepton (included otherwise) + # Build with debug code (much slower) + COLVARS_DEBUG=yes make lib-colvars args="-m machine" + + # Build without Lepton (included otherwise) + COLVARS_LEPTON=no make lib-colvars args="-m machine" The build should produce two files: the library ``lib/colvars/libcolvars.a`` and the specification file @@ -1364,9 +1499,14 @@ This package depends on the KSPACE package. .. code-block:: bash - make lib-electrode # print help message - make lib-electrode args="-m serial" # build with GNU g++ compiler and MPI STUBS (settings as with "make serial") - make lib-electrode args="-m mpi" # build with default MPI compiler (settings as with "make mpi") + # print help message + make lib-electrode + + # build with GNU g++ compiler and MPI STUBS (settings as with "make serial") + make lib-electrode args="-m serial" + + # build with default MPI compiler (settings as with "make mpi") + make lib-electrode args="-m mpi" Note that the ``Makefile.lammps`` file has settings for the BLAS @@ -1377,10 +1517,17 @@ This package depends on the KSPACE package. .. code-block:: bash - make lib-linalg # print help message - make lib-linalg args="-m serial" # build with GNU C++ compiler (settings as with "make serial") - make lib-linalg args="-m mpi" # build with default MPI C++ compiler (settings as with "make mpi") - make lib-linalg args="-m g++" # build with GNU C++ compiler + # print help message + make lib-linalg + + # build with GNU C++ compiler (settings as with "make serial") + make lib-linalg args="-m serial" + + # build with default MPI C++ compiler (settings as with "make mpi") + make lib-linalg args="-m mpi" + + # build with GNU C++ compiler + make lib-linalg args="-m g++" The package itself is activated with ``make yes-KSPACE`` and ``make yes-ELECTRODE`` @@ -1397,6 +1544,11 @@ in lib/pace or somewhere else, which must be done before building LAMMPS with this package. The code for the library can be found at: `https://github.com/ICAMS/lammps-user-pace/ `_ +Instead of including the ML-PACE package directly into LAMMPS, it +is also possible to skip this step and build the ML-PACE package as +a plugin using the CMake script files in the ``examples/PACKAGE/pace/plugin`` +folder and then load this plugin at runtime with the :doc:`plugin command `. + .. tabs:: .. tab:: CMake build @@ -1420,8 +1572,11 @@ at: `https://github.com/ICAMS/lammps-user-pace/ `. + .. tabs:: .. tab:: CMake build When the ``-D PKG_PLUMED=yes`` flag is included in the cmake - command you must ensure that GSL is installed in locations that - are specified in your environment. There are then two additional - variables that control the manner in which PLUMED is obtained and - linked into LAMMPS. + command you must ensure that `the GNU Scientific Library (GSL) + ` is installed in locations + that are accessible in your environment. There are then two + additional variables that control the manner in which PLUMED is + obtained and linked into LAMMPS. .. code-block:: bash - -D DOWNLOAD_PLUMED=value # download PLUMED for build, value = no (default) or yes - -D PLUMED_MODE=value # Linkage mode for PLUMED, value = static (default), shared, or runtime + -D DOWNLOAD_PLUMED=value # download PLUMED for build + # value = no (default) or yes + -D PLUMED_MODE=value # Linkage mode for PLUMED + # value = static (default), shared, + # or runtime - If DOWNLOAD_PLUMED is set to "yes", the PLUMED library will be + If ``DOWNLOAD_PLUMED`` is set to ``yes``, the PLUMED library will be downloaded (the version of PLUMED that will be downloaded is hard-coded to a vetted version of PLUMED, usually a recent stable release version) and built inside the CMake build directory. If ``DOWNLOAD_PLUMED`` is set to "no" (the default), CMake will try to detect and link to an installed version of PLUMED. For this to work, the PLUMED library has to be installed into a location where - the ``pkg-config`` tool can find it or the PKG_CONFIG_PATH + the ``pkg-config`` tool can find it or the ``PKG_CONFIG_PATH`` environment variable has to be set up accordingly. PLUMED should be installed in such a location if you compile it using the default make; make install commands. @@ -1612,14 +1793,21 @@ LAMMPS build. .. code-block:: bash - make lib-plumed # print help message - make lib-plumed args="-b" # download and build PLUMED in lib/plumed/plumed2 - make lib-plumed args="-p $HOME/.local" # use existing PLUMED installation in $HOME/.local - make lib-plumed args="-p /usr/local -m shared" # use existing PLUMED installation in - # /usr/local and use shared linkage mode + # print help message + make lib-plumed - Note that 2 symbolic (soft) links, ``includelink`` and ``liblink`` - are created in lib/plumed that point to the location of the PLUMED + # download and build PLUMED in lib/plumed/plumed2 + make lib-plumed args="-b" + + # use existing PLUMED installation in $HOME/.local + make lib-plumed args="-p $HOME/.local" + + # use existing PLUMED installation in /usr/local and + # use shared linkage mode + make lib-plumed args="-p /usr/local -m shared" + + Note that two symbolic (soft) links, ``includelink`` and ``liblink`` + are created in ``lib/plumed`` that point to the location of the PLUMED build to use. A new file ``lib/plumed/Makefile.lammps`` is also created with settings suitable for LAMMPS to compile and link PLUMED using the desired linkage mode. After this step is @@ -1634,17 +1822,17 @@ LAMMPS build. Once this compilation completes you should be able to run LAMMPS in the usual way. For shared linkage mode, libplumed.so must be found by the LAMMPS executable, which on many operating systems - means, you have to set the LD_LIBRARY_PATH environment variable + means, you have to set the ``LD_LIBRARY_PATH`` environment variable accordingly. Support for the different linkage modes in LAMMPS varies for different operating systems, using the static linkage is expected to be the most portable, and thus set to be the default. - If you want to change the linkage mode, you have to re-run "make - lib-plumed" with the desired settings **and** do a re-install if - the PLUMED package with "make yes-plumed" to update the - required makefile settings with the changes in the lib/plumed + If you want to change the linkage mode, you have to re-run ``make + lib-plumed`` with the desired settings **and** do a re-install if + the PLUMED package with ``make yes-plumed`` to update the + required makefile settings with the changes in the ``lib/plumed`` folder. ---------- @@ -1718,8 +1906,10 @@ details please see ``lib/hdnnp/README`` and the `n2p2 build documentation .. code-block:: bash - -D DOWNLOAD_N2P2=value # download n2p2 for build, value = no (default) or yes - -D N2P2_DIR=path # n2p2 base directory (only needed if a custom location) + -D DOWNLOAD_N2P2=value # download n2p2 for build + # value = no (default) or yes + -D N2P2_DIR=path # n2p2 base directory + # (only needed if a custom location) If ``DOWNLOAD_N2P2`` is set, the *n2p2* library will be downloaded and built inside the CMake build directory. If the *n2p2* library is already @@ -1736,12 +1926,19 @@ details please see ``lib/hdnnp/README`` and the `n2p2 build documentation .. code-block:: bash - make lib-hdnnp # print help message - make lib-hdnnp args="-b" # download and build in lib/hdnnp/n2p2-... - make lib-hdnnp args="-b -v 2.1.4" # download and build specific version - make lib-hdnnp args="-p /usr/local/n2p2" # use the existing n2p2 installation in /usr/local/n2p2 + # print help message + make lib-hdnnp - Note that 3 symbolic (soft) links, ``includelink``, ``liblink`` and + # download and build in lib/hdnnp/n2p2-... + make lib-hdnnp args="-b" + + # download and build specific version + make lib-hdnnp args="-b -v 2.1.4" + + # use the existing n2p2 installation in /usr/local/n2p2 + make lib-hdnnp args="-p /usr/local/n2p2" + + Note that three symbolic (soft) links, ``includelink``, ``liblink`` and ``Makefile.lammps``, will be created in ``lib/hdnnp`` to point to ``n2p2/include``, ``n2p2/lib`` and ``n2p2/lib/Makefile.lammps-extra``, respectively. When LAMMPS is built in ``src`` it will use these links. @@ -1788,19 +1985,19 @@ code when using features from the INTEL package. .. code-block:: make - OPTFLAGS = -xHost -O2 -fp-model fast=2 -no-prec-div -qoverride-limits -qopt-zmm-usage=high - CCFLAGS = -g -qopenmp -DLAMMPS_MEMALIGN=64 -no-offload -fno-alias -ansi-alias -restrict $(OPTFLAGS) - LINKFLAGS = -g -qopenmp $(OPTFLAGS) - LIB = -ltbbmalloc + OPTFLAGS = -xHost -O2 -fp-model fast=2 -no-prec-div -qoverride-limits -qopt-zmm-usage=high + CCFLAGS = -g -qopenmp -DLAMMPS_MEMALIGN=64 -no-offload -fno-alias -ansi-alias -restrict $(OPTFLAGS) + LINKFLAGS = -g -qopenmp $(OPTFLAGS) + LIB = -ltbbmalloc For KNLs: .. code-block:: make - OPTFLAGS = -xMIC-AVX512 -O2 -fp-model fast=2 -no-prec-div -qoverride-limits - CCFLAGS = -g -qopenmp -DLAMMPS_MEMALIGN=64 -no-offload -fno-alias -ansi-alias -restrict $(OPTFLAGS) - LINKFLAGS = -g -qopenmp $(OPTFLAGS) - LIB = -ltbbmalloc + OPTFLAGS = -xMIC-AVX512 -O2 -fp-model fast=2 -no-prec-div -qoverride-limits + CCFLAGS = -g -qopenmp -DLAMMPS_MEMALIGN=64 -no-offload -fno-alias -ansi-alias -restrict $(OPTFLAGS) + LINKFLAGS = -g -qopenmp $(OPTFLAGS) + LIB = -ltbbmalloc In Long-range thread mode (LRT) a modified verlet style is used, that operates the Kspace calculation in a separate thread concurrently to @@ -1829,7 +2026,8 @@ MDI package .. code-block:: bash - -D DOWNLOAD_MDI=value # download MDI Library for build, value = no (default) or yes + -D DOWNLOAD_MDI=value # download MDI Library for build + # value = no (default) or yes .. tab:: Traditional make @@ -1858,7 +2056,8 @@ MOLFILE package .. code-block:: bash - -D MOLFILE_INCLUDE_DIR=path # (optional) path where VMD molfile plugin headers are installed + -D MOLFILE_INCLUDE_DIR=path # (optional) path where VMD molfile + # plugin headers are installed -D PKG_MOLFILE=yes Using ``-D PKG_MOLFILE=yes`` enables the package, and setting @@ -2017,10 +2216,17 @@ verified to work in February 2020 with Quantum Espresso versions 6.3 to .. code-block:: bash - make lib-qmmm # print help message - make lib-qmmm args="-m serial" # build with GNU Fortran compiler (settings as in "make serial") - make lib-qmmm args="-m mpi" # build with default MPI compiler (settings as in "make mpi") - make lib-qmmm args="-m gfortran" # build with GNU Fortran compiler + # print help message + make lib-qmmm + + # build with GNU Fortran compiler (settings as in "make serial") + make lib-qmmm args="-m serial" + + # build with default MPI compiler (settings as in "make mpi") + make lib-qmmm args="-m mpi" + + # build with GNU Fortran compiler + make lib-qmmm args="-m gfortran" The build should produce two files: ``lib/qmmm/libqmmm.a`` and ``lib/qmmm/Makefile.lammps``. The latter is copied from an @@ -2033,10 +2239,40 @@ verified to work in February 2020 with Quantum Espresso versions 6.3 to You can then install QMMM package and build LAMMPS in the usual manner. After completing the LAMMPS build and compiling Quantum - ESPRESSO with external library support (via "make couple"), go + ESPRESSO with external library support (via ``make couple``), go back to the ``lib/qmmm`` folder and follow the instructions in the README file to build the combined LAMMPS/QE QM/MM executable - (pwqmmm.x) in the lib/qmmm folder. + (``pwqmmm.x``) in the ``lib/qmmm`` folder. + +---------- + +.. _rheo: + +RHEO package +------------ + +To build with this package you must have the `GNU Scientific Library +(GSL) ` installed in locations that +are accessible in your environment. The GSL library should be at least +version 2.7. + +.. tabs:: + + .. tab:: CMake build + + If CMake cannot find the GSL library or include files, you can set: + + .. code-block:: bash + + -D GSL_ROOT_DIR=path # path to root of GSL installation + + .. tab:: Traditional make + + LAMMPS will try to auto-detect the GSL compiler and linker flags + from the corresponding ``pkg-config`` file (``gsl.pc``), otherwise + you can edit the file ``lib/rheo/Makefile.lammps`` + to specify the paths and library names where indicated by comments. + This must be done **before** the package is installed. ---------- @@ -2076,11 +2312,16 @@ To build with this package, you must download and build the .. code-block:: bash - make lib-scafacos # print help message - make lib-scafacos args="-b" # download and build in lib/scafacos/scafacos- - make lib-scafacos args="-p $HOME/scafacos # use existing ScaFaCoS installation in $HOME/scafacos + # print help message + make lib-scafacos - Note that 2 symbolic (soft) links, ``includelink`` and ``liblink``, are + # download and build in lib/scafacos/scafacos- + make lib-scafacos args="-b" + + # use existing ScaFaCoS installation in $HOME/scafacos + make lib-scafacos args="-p $HOME/scafacos + + Note that two symbolic (soft) links, ``includelink`` and ``liblink``, are created in ``lib/scafacos`` to point to the ScaFaCoS src dir. When LAMMPS builds in src it will use these links. You should not need to edit the ``lib/scafacos/Makefile.lammps`` file. diff --git a/doc/src/Build_link.rst b/doc/src/Build_link.rst index 3800e41e21..255a451b29 100644 --- a/doc/src/Build_link.rst +++ b/doc/src/Build_link.rst @@ -37,7 +37,7 @@ executable code from the library is copied into the calling executable. .. tab:: CMake build This assumes that LAMMPS has been configured without setting a - ``LAMMPS_MACHINE`` name, installed with "make install", and the + ``LAMMPS_MACHINE`` name, installed with ``make install``, and the ``PKG_CONFIG_PATH`` environment variable has been updated to include the ``liblammps.pc`` file installed into the configured destination folder. The commands to compile and link a coupled @@ -45,8 +45,8 @@ executable code from the library is copied into the calling executable. .. code-block:: bash - mpicc -c -O $(pkgconf liblammps --cflags) caller.c - mpicxx -o caller caller.o -$(pkgconf liblammps --libs) + mpicc -c -O $(pkg-config --cflags liblammps) caller.c + mpicxx -o caller caller.o -$(pkg-config --libs liblammps) .. tab:: Traditional make @@ -59,10 +59,10 @@ executable code from the library is copied into the calling executable. mpicc -c -O -I${HOME}/lammps/src caller.c mpicxx -o caller caller.o -L${HOME}/lammps/src -llammps_mpi - The *-I* argument is the path to the location of the ``library.h`` + The ``-I`` argument is the path to the location of the ``library.h`` header file containing the interface to the LAMMPS C-style library - interface. The *-L* argument is the path to where the - ``liblammps_mpi.a`` file is located. The *-llammps_mpi* argument + interface. The ``-L`` argument is the path to where the + ``liblammps_mpi.a`` file is located. The ``-llammps_mpi`` argument is shorthand for telling the compiler to link the file ``liblammps_mpi.a``. If LAMMPS has been built as a shared library, then the linker will use ``liblammps_mpi.so`` instead. @@ -142,7 +142,7 @@ When linking to LAMMPS built as a shared library, the situation becomes much simpler, as all dependent libraries and objects are either included in the shared library or registered as a dependent library in the shared library file. Thus, those libraries need not be specified when linking -the calling executable. Only the *-I* flags are needed. So the example +the calling executable. Only the ``-I`` flags are needed. So the example case from above of the serial version static LAMMPS library with the POEMS package installed becomes: @@ -155,8 +155,8 @@ POEMS package installed becomes: .. code-block:: bash - mpicc -c -O $(pkgconf liblammps --cflags) caller.c - mpicxx -o caller caller.o -$(pkgconf --libs) + mpicc -c -O $(pkg-config --cflags liblammps) caller.c + mpicxx -o caller caller.o -$(pkg-config --libs liblammps) .. tab:: Traditional make diff --git a/doc/src/Build_make.rst b/doc/src/Build_make.rst index f6764100e0..932050d410 100644 --- a/doc/src/Build_make.rst +++ b/doc/src/Build_make.rst @@ -25,7 +25,7 @@ additional tools to be available and functioning. require adding flags like ``-std=c++11`` to enable the C++11 mode. * A Bourne shell compatible "Unix" shell program (frequently this is ``bash``) * A few shell utilities: ``ls``, ``mv``, ``ln``, ``rm``, ``grep``, ``sed``, ``tr``, ``cat``, ``touch``, ``diff``, ``dirname`` - * Python (optional, required for ``make lib-`` in the src + * Python (optional, required for ``make lib-`` in the ``src`` folder). Python scripts are currently tested with python 2.7 and 3.6 to 3.11. The procedure for :doc:`building the documentation ` *requires* Python 3.5 or later. diff --git a/doc/src/Build_package.rst b/doc/src/Build_package.rst index 63ccac534d..8b2da8ad30 100644 --- a/doc/src/Build_package.rst +++ b/doc/src/Build_package.rst @@ -62,6 +62,7 @@ packages: * :ref:`POEMS ` * :ref:`PYTHON ` * :ref:`QMMM ` + * :ref:`RHEO ` * :ref:`SCAFACOS ` * :ref:`VORONOI ` * :ref:`VTK ` @@ -99,10 +100,10 @@ versus make. .. code-block:: bash cd lammps/src - make ps # check which packages are currently installed - make yes-name # install a package with name - make no-name # uninstall a package with name - make mpi # build LAMMPS with whatever packages are now installed + make ps # check which packages are currently installed + make yes-name # install a package with name + make no-name # uninstall a package with name + make mpi # build LAMMPS with whatever packages are now installed Examples: @@ -171,18 +172,41 @@ make a copy of one of them and modify it to suit your needs. .. code-block:: bash - cmake -C ../cmake/presets/basic.cmake [OPTIONS] ../cmake # enable just a few core packages - cmake -C ../cmake/presets/most.cmake [OPTIONS] ../cmake # enable most packages - cmake -C ../cmake/presets/download.cmake [OPTIONS] ../cmake # enable packages which download sources or potential files - cmake -C ../cmake/presets/nolib.cmake [OPTIONS] ../cmake # disable packages that do require extra libraries or tools - cmake -C ../cmake/presets/clang.cmake [OPTIONS] ../cmake # change settings to use the Clang compilers by default - cmake -C ../cmake/presets/gcc.cmake [OPTIONS] ../cmake # change settings to use the GNU compilers by default - cmake -C ../cmake/presets/intel.cmake [OPTIONS] ../cmake # change settings to use the Intel compilers by default - cmake -C ../cmake/presets/pgi.cmake [OPTIONS] ../cmake # change settings to use the PGI compilers by default - cmake -C ../cmake/presets/all_on.cmake [OPTIONS] ../cmake # enable all packages - cmake -C ../cmake/presets/all_off.cmake [OPTIONS] ../cmake # disable all packages - mingw64-cmake -C ../cmake/presets/mingw-cross.cmake [OPTIONS] ../cmake # compile with MinGW cross-compilers - cmake -C ../cmake/presets/macos-multiarch.cmake [OPTIONS] ../cmake # compile serial multi-arch binaries on macOS + # enable just a few core packages + cmake -C ../cmake/presets/basic.cmake [OPTIONS] ../cmake + + # enable most packages + cmake -C ../cmake/presets/most.cmake [OPTIONS] ../cmake + + # enable packages which download sources or potential files + cmake -C ../cmake/presets/download.cmake [OPTIONS] ../cmake + + # disable packages that do require extra libraries or tools + cmake -C ../cmake/presets/nolib.cmake [OPTIONS] ../cmake + + # change settings to use the Clang compilers by default + cmake -C ../cmake/presets/clang.cmake [OPTIONS] ../cmake + + # change settings to use the GNU compilers by default + cmake -C ../cmake/presets/gcc.cmake [OPTIONS] ../cmake + + # change settings to use the Intel compilers by default + cmake -C ../cmake/presets/intel.cmake [OPTIONS] ../cmake + + # change settings to use the PGI compilers by default + cmake -C ../cmake/presets/pgi.cmake [OPTIONS] ../cmake + + # enable all packages + cmake -C ../cmake/presets/all_on.cmake [OPTIONS] ../cmake + + # disable all packages + cmake -C ../cmake/presets/all_off.cmake [OPTIONS] ../cmake + + # compile with MinGW cross-compilers + mingw64-cmake -C ../cmake/presets/mingw-cross.cmake [OPTIONS] ../cmake + + # compile serial multi-arch binaries on macOS + cmake -C ../cmake/presets/macos-multiarch.cmake [OPTIONS] ../cmake Presets that have names starting with "windows" are specifically for compiling LAMMPS :doc:`natively on Windows ` and @@ -208,7 +232,8 @@ Example # GPU package and configure it for using CUDA. You can run. mkdir build cd build - cmake -C ../cmake/presets/most.cmake -C ../cmake/presets/nolib.cmake -D PKG_GPU=on -D GPU_API=cuda ../cmake + cmake -C ../cmake/presets/most.cmake -C ../cmake/presets/nolib.cmake \ + -D PKG_GPU=on -D GPU_API=cuda ../cmake # to add another package, say BODY to the previous configuration you can run: cmake -D PKG_BODY=on . diff --git a/doc/src/Build_settings.rst b/doc/src/Build_settings.rst index 34100871ce..2787560be5 100644 --- a/doc/src/Build_settings.rst +++ b/doc/src/Build_settings.rst @@ -1,3 +1,7 @@ +.. raw:: latex + + \clearpage + Optional build settings ======================= @@ -8,7 +12,8 @@ explains how to do this for building both with CMake and make. * `FFT library`_ for use with the :doc:`kspace_style pppm ` command * `Size of LAMMPS integer types and size limits`_ * `Read or write compressed files`_ -* `Output of JPG, PNG, and move files` via the :doc:`dump image ` or :doc:`dump movie ` commands +* `Output of JPEG, PNG, and movie files`_ via the :doc:`dump image ` or :doc:`dump movie ` commands +* `Support for downloading files`_ * `Memory allocation alignment`_ * `Workaround for long long integers`_ * `Exception handling when using LAMMPS as a library`_ to capture errors @@ -19,7 +24,7 @@ explains how to do this for building both with CMake and make. .. _cxx11: C++11 standard compliance ------------------------------------------- +------------------------- A C++11 standard compatible compiler is a requirement for compiling LAMMPS. LAMMPS version 3 March 2020 is the last version compatible with the previous @@ -31,12 +36,16 @@ flags to enable C++11 compliance. Example for GNU c++ 4.8.x: CCFLAGS = -g -O3 -std=c++11 +Individual packages may require compliance with a later C++ standard +like C++14 or C++17. These requirements will be documented with the +:doc:`individual packages `. + ---------- .. _fft: FFT library ---------------------- +----------- When the KSPACE package is included in a LAMMPS build, the :doc:`kspace_style pppm ` command performs 3d FFTs which @@ -58,8 +67,10 @@ libraries and better pipelining for packing and communication. .. code-block:: bash - -D FFT=value # FFTW3 or MKL or KISS, default is FFTW3 if found, else KISS - -D FFT_KOKKOS=value # FFTW3 or MKL or KISS or CUFFT or HIPFFT, default is KISS + -D FFT=value # FFTW3 or MKL or NVPL or KISS, + # default is FFTW3 if found, else KISS + -D FFT_KOKKOS=value # FFTW3 or MKL or NVPL or KISS or CUFFT + # or HIPFFT or MKL_GPU, default is KISS -D FFT_SINGLE=value # yes or no (default), no = double precision -D FFT_PACK=value # array (default) or pointer or memcpy -D FFT_USE_HEFFTE=value # yes or no (default), yes links to heFFTe @@ -67,11 +78,11 @@ libraries and better pipelining for packing and communication. .. note:: When the Kokkos variant of a package is compiled and selected at run time, - the FFT library selected by the FFT_KOKKOS variable applies. Otherwise, + the FFT library selected by the ``FFT_KOKKOS`` variable applies. Otherwise, the FFT library selected by the FFT variable applies. - The same FFT settings apply to both. FFT_KOKKOS must be compatible with the + The same FFT settings apply to both. ``FFT_KOKKOS`` must be compatible with the Kokkos back end - for example, when using the CUDA back end of Kokkos, - you must use either CUFFT or KISS. + you must use either ``CUFFT`` or ``KISS``. Usually these settings are all that is needed. If FFTW3 is selected, then CMake will try to detect, if threaded FFTW @@ -89,8 +100,11 @@ libraries and better pipelining for packing and communication. -D MKL_INCLUDE_DIR=path # ditto for Intel MKL library -D FFT_MKL_THREADS=on # enable using threaded FFTs with MKL libraries -D MKL_LIBRARY=path # path to MKL libraries - -D FFT_HEFFTE_BACKEND=value # FFTW or MKL or empty/undefined for the stock heFFTe back end + -D FFT_HEFFTE_BACKEND=value # FFTW or MKL or empty/undefined for the stock + # heFFTe back end -D Heffte_ROOT=path # path to an existing heFFTe installation + -D nvpl_fft_INCLUDE_DIR=path # path to NVPL FFT include files + -D nvpl_fft_LIBRARY_DIR=path # path to NVPL FFT libraries .. note:: @@ -108,30 +122,58 @@ libraries and better pipelining for packing and communication. .. code-block:: make - FFT_INC = -DFFT_FFTW3 # -DFFT_FFTW3, -DFFT_FFTW (same as -DFFT_FFTW3), -DFFT_MKL, or -DFFT_KISS - # default is KISS if not specified - FFT_INC = -DFFT_KOKKOS_CUFFT # -DFFT_KOKKOS_{FFTW,FFTW3,MKL,CUFFT,HIPFFT,KISS} - # default is KISS if not specified - FFT_INC = -DFFT_SINGLE # do not specify for double precision - FFT_INC = -DFFT_FFTW_THREADS # enable using threaded FFTW3 libraries - FFT_INC = -DFFT_MKL_THREADS # enable using threaded FFTs with MKL libraries - FFT_INC = -DFFT_PACK_ARRAY # or -DFFT_PACK_POINTER or -DFFT_PACK_MEMCPY - # default is FFT_PACK_ARRAY if not specified + FFT_INC = -DFFT_ # where is KISS (default), FFTW3, + # FFTW (same as FFTW3), NVPL, or MKL + FFT_INC = -DFFT_KOKKOS_ # where is KISS (default), FFTW3, + # FFTW (same as FFTW3), NVPL, MKL, CUFFT, + # HIPFFT, or MKL_GPU + FFT_INC = -DFFT_SINGLE # do not specify for double precision + FFT_INC = -DFFT_FFTW_THREADS # enable using threaded FFTW3 libraries + FFT_INC = -DFFT_MKL_THREADS # enable using threaded FFTs with MKL libraries + FFT_INC = -DFFT_PACK_ARRAY # or -DFFT_PACK_POINTER or -DFFT_PACK_MEMCPY + # default is FFT_PACK_ARRAY if not specified .. code-block:: make - FFT_INC = -I/usr/local/include - FFT_PATH = -L/usr/local/lib - FFT_LIB = -lhipfft # hipFFT either precision - FFT_LIB = -lcufft # cuFFT either precision - FFT_LIB = -lfftw3 # FFTW3 double precision - FFT_LIB = -lfftw3 -lfftw3_omp # FFTW3 double precision with threads (needs -DFFT_FFTW_THREADS) - FFT_LIB = -lfftw3 -lfftw3f # FFTW3 single precision - FFT_LIB = -lmkl_intel_lp64 -lmkl_sequential -lmkl_core # MKL with Intel compiler, serial interface - FFT_LIB = -lmkl_gf_lp64 -lmkl_sequential -lmkl_core # MKL with GNU compiler, serial interface - FFT_LIB = -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core # MKL with Intel compiler, threaded interface - FFT_LIB = -lmkl_gf_lp64 -lmkl_gnu_thread -lmkl_core # MKL with GNU compiler, threaded interface - FFT_LIB = -lmkl_rt # MKL with automatic runtime selection of interface libs + FFT_INC = -I/usr/local/include + FFT_PATH = -L/usr/local/lib + + # hipFFT either precision + FFT_LIB = -lhipfft + + # cuFFT either precision + FFT_LIB = -lcufft + + # MKL_GPU either precision + FFT_LIB = -lmkl_sycl_dft -lmkl_intel_ilp64 -lmkl_tbb_thread -lmkl_core -ltbb + + # FFTW3 double precision + FFT_LIB = -lfftw3 + + # FFTW3 double precision with threads (needs -DFFT_FFTW_THREADS) + FFT_LIB = -lfftw3 -lfftw3_omp + + # FFTW3 single precision + FFT_LIB = -lfftw3 -lfftw3f + + # serial MKL with Intel compiler + FFT_LIB = -lmkl_intel_lp64 -lmkl_sequential -lmkl_core + + # serial MKL with GNU compiler + FFT_LIB = -lmkl_gf_lp64 -lmkl_sequential -lmkl_core + + # threaded MKL with Intel compiler + FFT_LIB = -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core + + # threaded MKL with GNU compiler + FFT_LIB = -lmkl_gf_lp64 -lmkl_gnu_thread -lmkl_core + + # MKL with automatic runtime selection of interface libs + FFT_LIB = -lmkl_rt + + # threaded NVPL FFT + FFT_LIB = -lnvpl_fftw + As with CMake, you do not need to set paths in ``FFT_INC`` or ``FFT_PATH``, if the compiler can find the FFT header and library @@ -147,11 +189,11 @@ libraries and better pipelining for packing and communication. FFT_PATH = FFT_LIB = $(heffte_link) $(heffte_libs) - The heFFTe install path will contain `HeffteMakefile.in`. - which will define the `heffte_` include variables needed to link to heFFTe from + The heFFTe install path will contain ``HeffteMakefile.in``. + which will define the ``heffte_`` include variables needed to link to heFFTe from an external project using traditional make. - The `-DFFT_HEFFTE` is required to switch to using heFFTe, while the optional `-DFFT_HEFFTE_FFTW` - selects the desired heFFTe back end, e.g., `-DFFT_HEFFTE_FFTW` or `-DFFT_HEFFTE_MKL`, + The ``-DFFT_HEFFTE`` is required to switch to using heFFTe, while the optional ``-DFFT_HEFFTE_FFTW`` + selects the desired heFFTe back end, e.g., ``-DFFT_HEFFTE_FFTW`` or ``-DFFT_HEFFTE_MKL``, omitting the variable will default to the `stock` back end. The heFFTe `stock` back end is intended to be used for testing and debugging, but is not performance optimized for large scale production runs. @@ -179,17 +221,23 @@ it from `www.fftw.org `_. LAMMPS requires version Building FFTW for your box should be as simple as ``./configure; make; make install``. The install command typically requires root privileges (e.g. invoke it via sudo), unless you specify a local directory with -the "--prefix" option of configure. Type ``./configure --help`` to see +the ``--prefix`` option of configure. Type ``./configure --help`` to see various options. The Intel MKL math library is part of the Intel compiler suite. It can be used with the Intel or GNU compiler (see the ``FFT_LIB`` setting above). +The NVIDIA Performance Libraries (NVPL) FFT library is optimized for NVIDIA +Grace Armv9.0 architecture. You can download it from +`https://docs.nvidia.com/nvpl/`_. + The cuFFT and hipFFT FFT libraries are packaged with NVIDIA's CUDA and AMD's HIP installations, respectively. These FFT libraries require the Kokkos acceleration package to be enabled and the Kokkos back end to be -GPU-resident (i.e., HIP or CUDA). +GPU-resident (i.e., HIP or CUDA). Similarly, GPU offload of FFTs on +Intel GPUs with oneMKL currently requires the Kokkos acceleration +package to be enabled with the SYCL back end. Performing 3d FFTs in parallel can be time-consuming due to data access and required communication. This cost can be reduced by performing @@ -215,7 +263,7 @@ produce the additional libraries ``libfftw3f.a`` and/or ``libfftw3f.so``\ . Performing 3d FFTs requires communication to transpose the 3d FFT grid. The data packing/unpacking for this can be done in one of 3 -modes (ARRAY, POINTER, MEMCPY) as set by the FFT_PACK syntax above. +modes (ARRAY, POINTER, MEMCPY) as set by the ``FFT_PACK`` syntax above. Depending on the machine, the size of the FFT grid, the number of processors used, one option may be slightly faster. The default is ARRAY mode. @@ -232,6 +280,10 @@ and those variables will be passed into the heFFTe build. ---------- +.. raw:: latex + + \clearpage + .. _size: Size of LAMMPS integer types and size limits @@ -272,7 +324,7 @@ LAMMPS system size restrictions .. list-table:: :header-rows: 1 - :widths: auto + :widths: 18 27 28 27 :align: center * - @@ -341,8 +393,8 @@ in whichever ``lib/gpu/Makefile`` is used must be the same as above. .. _graphics: -Output of JPG, PNG, and movie files --------------------------------------------------- +Output of JPEG, PNG, and movie files +------------------------------------ The :doc:`dump image ` command has options to output JPEG or PNG image files. Likewise, the :doc:`dump movie ` command @@ -355,12 +407,13 @@ requires the following settings: .. code-block:: bash - -D WITH_JPEG=value # yes or no - # default = yes if CMake finds JPEG files, else no - -D WITH_PNG=value # yes or no - # default = yes if CMake finds PNG and ZLIB files, else no - -D WITH_FFMPEG=value # yes or no - # default = yes if CMake can find ffmpeg, else no + -D WITH_JPEG=value # yes or no + # default = yes if CMake finds JPEG development files, else no + -D WITH_PNG=value # yes or no + # default = yes if CMake finds PNG and ZLIB development files, + # else no + -D WITH_FFMPEG=value # yes or no + # default = yes if CMake can find ffmpeg, else no Usually these settings are all that is needed. If CMake cannot find the graphics header, library, executable files, you can set @@ -382,8 +435,10 @@ requires the following settings: LMP_INC = -DLAMMPS_JPEG -DLAMMPS_PNG -DLAMMPS_FFMPEG - JPG_INC = -I/usr/local/include # path to jpeglib.h, png.h, zlib.h header files if make cannot find them - JPG_PATH = -L/usr/lib # paths to libjpeg.a, libpng.a, libz.a (.so) files if make cannot find them + JPG_INC = -I/usr/local/include # path to jpeglib.h, png.h, zlib.h headers + # if make cannot find them + JPG_PATH = -L/usr/lib # paths to libjpeg.a, libpng.a, libz.a (.so) + # files if make cannot find them JPG_LIB = -ljpeg -lpng -lz # library names As with CMake, you do not need to set ``JPG_INC`` or ``JPG_PATH``, @@ -414,8 +469,8 @@ Read or write compressed files If this option is enabled, large files can be read or written with compression by ``gzip`` or similar tools by several LAMMPS commands, including :doc:`read_data `, :doc:`rerun `, and -:doc:`dump `. Supported compression tools are currently -``gzip``, ``bzip2``, ``zstd``, and ``lzma``. +:doc:`dump `. Supported compression tools and algorithms are currently +``gzip``, ``bzip2``, ``zstd``, ``xz``, ``lz4``, and ``lzma`` (via xz). .. tabs:: @@ -423,8 +478,8 @@ including :doc:`read_data `, :doc:`rerun `, and .. code-block:: bash - -D WITH_GZIP=value # yes or no - # default is yes if CMake can find the gzip program, else no + -D WITH_GZIP=value # yes or no + # default is yes if CMake can find the gzip program .. tab:: Traditional make @@ -446,18 +501,64 @@ during a run. available using a compression library instead, which is what the :ref:`COMPRESS package ` enables. +-------------------------------------------------- + +.. _libcurl: + +Support for downloading files +----------------------------- + +.. versionadded:: 29Aug2024 + +The :doc:`geturl command ` command uses the `the libcurl library +`_ to download files. This requires that +LAMMPS is compiled accordingly which needs the following settings: + +.. tabs:: + + .. tab:: CMake build + + .. code-block:: bash + + -D WITH_CURL=value # yes or no + # default = yes if CMake finds CURL development files, else no + + Usually these settings are all that is needed. If CMake cannot + find the graphics header, library, executable files, you can set + these variables: + + .. code-block:: bash + + -D CURL_INCLUDE_DIR=path # path to folder which contains curl.h header file + -D CURL_LIBRARY=path # path to libcurls.a (.so) file + + .. tab:: Traditional make + + .. code-block:: make + + LMP_INC = -DLAMMPS_CURL + + CURL_INC = -I/usr/local/include # path to curl folder with curl.h + CURL_PATH = -L/usr/lib # paths to libcurl.a(.so) if make cannot find it + CURL_LIB = -lcurl # library names + + As with CMake, you do not need to set ``CURL_INC`` or ``CURL_PATH``, + if make can find the libcurl header and library files in their + default system locations. You must specify ``CURL_LIB`` with a + paths or linker flags to link to libcurl. + ---------- .. _align: Memory allocation alignment ---------------------------------------- +--------------------------- -This setting enables the use of the "posix_memalign()" call instead of -"malloc()" when LAMMPS allocates large chunks of memory. Vector +This setting enables the use of the ``posix_memalign()`` call instead of +``malloc()`` when LAMMPS allocates large chunks of memory. Vector instructions on CPUs may become more efficient, if dynamically allocated memory is aligned on larger-than-default byte boundaries. On most -current operating systems, the "malloc()" implementation returns +current operating systems, the ``malloc()`` implementation returns pointers that are aligned to 16-byte boundaries. Using SSE vector instructions efficiently, however, requires memory blocks being aligned on 64-byte boundaries. @@ -471,9 +572,9 @@ on 64-byte boundaries. -D LAMMPS_MEMALIGN=value # 0, 8, 16, 32, 64 (default) Use a ``LAMMPS_MEMALIGN`` value of 0 to disable using - "posix_memalign()" and revert to using the "malloc()" C-library + ``posix_memalign()`` and revert to using the ``malloc()`` C-library function instead. When compiling LAMMPS for Windows systems, - "malloc()" will always be used and this setting is ignored. + ``malloc()`` will always be used and this setting is ignored. .. tab:: Traditional make @@ -482,7 +583,7 @@ on 64-byte boundaries. LMP_INC = -DLAMMPS_MEMALIGN=value # 8, 16, 32, 64 Do not set ``-DLAMMPS_MEMALIGN``, if you want to have memory - allocated with the "malloc()" function call + allocated with the ``malloc()`` function call instead. ``-DLAMMPS_MEMALIGN`` **cannot** be used on Windows, as Windows different function calls with different semantics for allocating aligned memory, that are not compatible with how LAMMPS diff --git a/doc/src/Commands_all.rst b/doc/src/Commands_all.rst index 4a035f5b41..58623401f3 100644 --- a/doc/src/Commands_all.rst +++ b/doc/src/Commands_all.rst @@ -1,26 +1,30 @@ -.. table_from_list:: - :columns: 3 +.. only:: html - * :doc:`General commands ` - * :doc:`Fix styles ` - * :doc:`Compute styles ` - * :doc:`Pair styles ` - * :ref:`Bond styles ` - * :ref:`Angle styles ` - * :ref:`Dihedral styles ` - * :ref:`Improper styles ` - * :doc:`KSpace styles ` - * :doc:`Dump styles ` + .. table_from_list:: + :columns: 5 + + * :doc:`General commands ` + * :doc:`Fix styles ` + * :doc:`Compute styles ` + * :doc:`Pair styles ` + * :ref:`Bond styles ` + * :ref:`Angle styles ` + * :ref:`Dihedral styles ` + * :ref:`Improper styles ` + * :doc:`KSpace styles ` + * :doc:`Dump styles ` + +.. raw:: latex + + \clearpage General commands ================ -An alphabetic list of general LAMMPS commands. Note that style -commands with many variants, can be more easily accessed via the small -table above. +An alphabetic list of general LAMMPS commands. .. table_from_list:: - :columns: 5 + :columns: 6 * :doc:`angle_coeff ` * :doc:`angle_style ` @@ -54,6 +58,7 @@ table above. * :doc:`echo ` * :doc:`fix ` * :doc:`fix_modify ` + * :doc:`geturl ` * :doc:`group ` * :doc:`if ` * :doc:`improper_coeff ` @@ -121,7 +126,7 @@ commands have accelerated versions. This is indicated by an additional letter in parenthesis: k = KOKKOS. .. table_from_list:: - :columns: 5 + :columns: 6 * :doc:`dynamical_matrix (k) ` * :doc:`group2ndx ` diff --git a/doc/src/Commands_bond.rst b/doc/src/Commands_bond.rst index 73235cf3c6..3be40a6158 100644 --- a/doc/src/Commands_bond.rst +++ b/doc/src/Commands_bond.rst @@ -1,21 +1,7 @@ -.. table_from_list:: - :columns: 3 - - * :doc:`General commands ` - * :doc:`Fix styles ` - * :doc:`Compute styles ` - * :doc:`Pair styles ` - * :ref:`Bond styles ` - * :ref:`Angle styles ` - * :ref:`Dihedral styles ` - * :ref:`Improper styles ` - * :doc:`KSpace styles ` - * :doc:`Dump styles ` - .. _bond: -Bond_style potentials -===================== +Bond styles +=========== All LAMMPS :doc:`bond_style ` commands. Some styles have accelerated versions. This is indicated by additional letters in @@ -23,7 +9,7 @@ parenthesis: g = GPU, i = INTEL, k = KOKKOS, o = OPENMP, t = OPT. .. table_from_list:: - :columns: 4 + :columns: 5 * :doc:`none ` * :doc:`zero ` @@ -33,6 +19,8 @@ OPT. * * * + * + * * :doc:`bpm/rotational ` * :doc:`bpm/spring ` * :doc:`class2 (ko) ` @@ -54,13 +42,14 @@ OPT. * :doc:`oxdna2/fene ` * :doc:`oxrna2/fene ` * :doc:`quartic (o) ` + * :doc:`rheo/shell ` * :doc:`special ` * :doc:`table (o) ` .. _angle: -Angle_style potentials -====================== +Angle styles +============ All LAMMPS :doc:`angle_style ` commands. Some styles have accelerated versions. This is indicated by additional letters in @@ -68,11 +57,13 @@ parenthesis: g = GPU, i = INTEL, k = KOKKOS, o = OPENMP, t = OPT. .. table_from_list:: - :columns: 4 + :columns: 5 * :doc:`none ` * :doc:`zero ` - * :doc:`hybrid ` + * :doc:`hybrid (k) ` + * + * * * * @@ -100,13 +91,13 @@ OPT. * :doc:`mesocnt ` * :doc:`mm3 ` * :doc:`quartic (o) ` - * :doc:`spica (o) ` + * :doc:`spica (ko) ` * :doc:`table (o) ` .. _dihedral: -Dihedral_style potentials -========================= +Dihedral styles +=============== All LAMMPS :doc:`dihedral_style ` commands. Some styles have accelerated versions. This is indicated by additional letters in @@ -114,11 +105,13 @@ parenthesis: g = GPU, i = INTEL, k = KOKKOS, o = OPENMP, t = OPT. .. table_from_list:: - :columns: 4 + :columns: 5 * :doc:`none ` * :doc:`zero ` - * :doc:`hybrid ` + * :doc:`hybrid (k) ` + * + * * * * @@ -143,8 +136,8 @@ OPT. .. _improper: -Improper_style potentials -========================= +Improper styles +=============== All LAMMPS :doc:`improper_style ` commands. Some styles have accelerated versions. This is indicated by additional letters in @@ -152,11 +145,13 @@ parenthesis: g = GPU, i = INTEL, k = KOKKOS, o = OPENMP, t = OPT. .. table_from_list:: - :columns: 4 + :columns: 5 * :doc:`none ` * :doc:`zero ` - * :doc:`hybrid ` + * :doc:`hybrid (k) ` + * + * * * * diff --git a/doc/src/Commands_category.rst b/doc/src/Commands_category.rst index 7ac747e8fc..8d4f306151 100644 --- a/doc/src/Commands_category.rst +++ b/doc/src/Commands_category.rst @@ -1,3 +1,7 @@ +.. raw:: latex + + \clearpage + Commands by category ==================== @@ -6,8 +10,8 @@ This page lists most of the LAMMPS commands, grouped by category. The alphabetically. Style options for entries like fix, compute, pair etc. have their own pages where they are listed alphabetically. -Initialization: ------------------------------- +Initialization +-------------- .. table_from_list:: :columns: 5 @@ -18,8 +22,8 @@ Initialization: * :doc:`suffix ` * :doc:`units ` -Setup simulation box: ------------------------------- +Setup simulation box +-------------------- .. table_from_list:: :columns: 4 @@ -31,8 +35,8 @@ Setup simulation box: * :doc:`lattice ` * :doc:`region ` -Setup atoms: ------------------------------- +Setup atoms +----------- .. table_from_list:: :columns: 4 @@ -55,8 +59,8 @@ Setup atoms: * :doc:`set ` * :doc:`velocity ` -Force fields: ------------------------------- +Force fields +------------ .. table_from_list:: :columns: 4 @@ -79,8 +83,8 @@ Force fields: * :doc:`pair_write ` * :doc:`special_bonds ` -Settings: ------------------------------- +Settings +-------- .. table_from_list:: :columns: 4 @@ -98,8 +102,8 @@ Settings: * :doc:`timer ` * :doc:`timestep ` -Operations within timestepping (fixes) and diagnostics (computes): ------------------------------------------------------------------------------------------- +Operations within timestepping (fixes) and diagnostics (computes) +----------------------------------------------------------------- .. table_from_list:: :columns: 4 @@ -111,8 +115,8 @@ Operations within timestepping (fixes) and diagnostics (computes): * :doc:`uncompute ` * :doc:`unfix ` -Output: ------------------------------- +Output +------ .. table_from_list:: :columns: 4 @@ -131,8 +135,8 @@ Output: * :doc:`write_dump ` * :doc:`write_restart ` -Actions: ------------------------------- +Actions +------- .. table_from_list:: :columns: 6 @@ -146,8 +150,8 @@ Actions: * :doc:`tad ` * :doc:`temper ` -Input script control: ------------------------------- +Input script control +-------------------- .. table_from_list:: :columns: 7 diff --git a/doc/src/Commands_compute.rst b/doc/src/Commands_compute.rst index 2e8f291c77..fd68ce3e39 100644 --- a/doc/src/Commands_compute.rst +++ b/doc/src/Commands_compute.rst @@ -1,19 +1,5 @@ -.. table_from_list:: - :columns: 3 - - * :doc:`General commands ` - * :doc:`Fix styles ` - * :doc:`Compute styles ` - * :doc:`Pair styles ` - * :ref:`Bond styles ` - * :ref:`Angle styles ` - * :ref:`Dihedral styles ` - * :ref:`Improper styles ` - * :doc:`KSpace styles ` - * :doc:`Dump styles ` - -Compute commands -================ +Compute styles +============== An alphabetic list of all LAMMPS :doc:`compute ` commands. Some styles have accelerated versions. This is indicated by @@ -21,7 +7,7 @@ additional letters in parenthesis: g = GPU, i = INTEL, k = KOKKOS, o = OPENMP, t = OPT. .. table_from_list:: - :columns: 5 + :columns: 4 * :doc:`ackland/atom ` * :doc:`adf ` @@ -126,6 +112,7 @@ KOKKOS, o = OPENMP, t = OPT. * :doc:`reduce ` * :doc:`reduce/chunk ` * :doc:`reduce/region ` + * :doc:`rheo/property/atom ` * :doc:`rigid/local ` * :doc:`saed ` * :doc:`slcsa/atom ` diff --git a/doc/src/Commands_dump.rst b/doc/src/Commands_dump.rst index d7c8e73b58..86dab8b731 100644 --- a/doc/src/Commands_dump.rst +++ b/doc/src/Commands_dump.rst @@ -1,24 +1,10 @@ -.. table_from_list:: - :columns: 3 - - * :doc:`General commands ` - * :doc:`Fix styles ` - * :doc:`Compute styles ` - * :doc:`Pair styles ` - * :ref:`Bond styles ` - * :ref:`Angle styles ` - * :ref:`Dihedral styles ` - * :ref:`Improper styles ` - * :doc:`KSpace styles ` - * :doc:`Dump styles ` - -Dump commands -============= +Dump styles +=========== An alphabetic list of all LAMMPS :doc:`dump ` commands. .. table_from_list:: - :columns: 5 + :columns: 6 * :doc:`atom ` * :doc:`atom/adios ` diff --git a/doc/src/Commands_fix.rst b/doc/src/Commands_fix.rst index a7648218fa..d9febcc289 100644 --- a/doc/src/Commands_fix.rst +++ b/doc/src/Commands_fix.rst @@ -1,19 +1,5 @@ -.. table_from_list:: - :columns: 3 - - * :doc:`General commands ` - * :doc:`Fix styles ` - * :doc:`Compute styles ` - * :doc:`Pair styles ` - * :ref:`Bond styles ` - * :ref:`Angle styles ` - * :ref:`Dihedral styles ` - * :ref:`Improper styles ` - * :doc:`KSpace styles ` - * :doc:`Dump styles ` - -Fix commands -============ +Fix styles +========== An alphabetic list of all LAMMPS :doc:`fix ` commands. Some styles have accelerated versions. This is indicated by additional letters in @@ -21,13 +7,14 @@ parenthesis: g = GPU, i = INTEL, k = KOKKOS, o = OPENMP, t = OPT. .. table_from_list:: - :columns: 5 + :columns: 4 * :doc:`accelerate/cos ` * :doc:`acks2/reaxff (k) ` * :doc:`adapt ` * :doc:`adapt/fep ` * :doc:`addforce ` + * :doc:`add/heat ` * :doc:`addtorque ` * :doc:`alchemy ` * :doc:`amoeba/bitorsion ` @@ -204,6 +191,11 @@ OPT. * :doc:`reaxff/species (k) ` * :doc:`recenter ` * :doc:`restrain ` + * :doc:`rheo ` + * :doc:`rheo/oxidation ` + * :doc:`rheo/pressure ` + * :doc:`rheo/thermal ` + * :doc:`rheo/viscosity ` * :doc:`rhok ` * :doc:`rigid (o) ` * :doc:`rigid/meso ` diff --git a/doc/src/Commands_input.rst b/doc/src/Commands_input.rst index 595b8ffa2c..dc0fb72dd9 100644 --- a/doc/src/Commands_input.rst +++ b/doc/src/Commands_input.rst @@ -10,14 +10,14 @@ for any commands that may be processed later. Commands may set an internal variable, read in a file, or run a simulation. These actions can be grouped into three categories: -a) commands that change a global setting (examples: timestep, newton, - echo, log, thermo, restart), +a) commands that change a global setting (examples: :doc:`timestep `, :doc:`newton `, + :doc:`echo `, :doc:`log `, :doc:`thermo `, :doc:`restart `), b) commands that add, modify, remove, or replace "styles" that are - executed during a "run" (examples: pair_style, fix, compute, dump, - thermo_style, pair_modify), and + executed during a "run" (examples: :doc:`pair_style `, :doc:`fix `, :doc:`compute `, :doc:`dump `, + :doc:`thermo_style `, :doc:`pair_modify `), and c) commands that execute a "run" or perform some other computation or - operation (examples: print, run, minimize, temper, write_dump, rerun, - read_data, read_restart) + operation (examples: :doc:`print `, :doc:`run `, :doc:`minimize `, :doc:`temper `, :doc:`write_dump `, :doc:`rerun `, + :doc:`read_data `, :doc:`read_restart `) Commands in category a) have default settings, which means you only need to use the command if you wish to change the defaults. @@ -61,7 +61,7 @@ between commands in the c) category. The following rules apply: ` command initializes the system by setting up the simulation box and assigning atoms to processors. If default values are not desired, the :doc:`processors ` and - :doc:`boundary ` commands need to be used before read_data + :doc:`boundary ` commands need to be used before ``read_data`` to tell LAMMPS how to map processors to the simulation box. Many input script errors are detected by LAMMPS and an ERROR or @@ -70,6 +70,6 @@ more information on what errors mean. The documentation for each command lists restrictions on how the command can be used. You can use the :ref:`-skiprun ` command line flag -to have LAMMPS skip the execution of any "run", "minimize", or similar +to have LAMMPS skip the execution of any ``run``, ``minimize``, or similar commands to check the entire input for correct syntax to avoid crashes on typos or syntax errors in long runs. diff --git a/doc/src/Commands_kspace.rst b/doc/src/Commands_kspace.rst index 088789e321..0d9b34a2cc 100644 --- a/doc/src/Commands_kspace.rst +++ b/doc/src/Commands_kspace.rst @@ -1,19 +1,5 @@ -.. table_from_list:: - :columns: 3 - - * :doc:`General commands ` - * :doc:`Fix styles ` - * :doc:`Compute styles ` - * :doc:`Pair styles ` - * :ref:`Bond styles ` - * :ref:`Angle styles ` - * :ref:`Dihedral styles ` - * :ref:`Improper styles ` - * :doc:`KSpace styles ` - * :doc:`Dump styles ` - -KSpace solvers -============== +KSpace styles +============= All LAMMPS :doc:`kspace_style ` solvers. Some styles have accelerated versions. This is indicated by additional letters in @@ -21,7 +7,7 @@ parenthesis: g = GPU, i = INTEL, k = KOKKOS, o = OPENMP, t = OPT. .. table_from_list:: - :columns: 4 + :columns: 5 * :doc:`ewald (o) ` * :doc:`ewald/disp ` diff --git a/doc/src/Commands_pair.rst b/doc/src/Commands_pair.rst index f83f2539a3..dfed8f7485 100644 --- a/doc/src/Commands_pair.rst +++ b/doc/src/Commands_pair.rst @@ -1,19 +1,5 @@ -.. table_from_list:: - :columns: 3 - - * :doc:`General commands ` - * :doc:`Fix styles ` - * :doc:`Compute styles ` - * :doc:`Pair styles ` - * :ref:`Bond styles ` - * :ref:`Angle styles ` - * :ref:`Dihedral styles ` - * :ref:`Improper styles ` - * :doc:`KSpace styles ` - * :doc:`Dump styles ` - -Pair_style potentials -====================== +Pair styles +=========== All LAMMPS :doc:`pair_style ` commands. Some styles have accelerated versions. This is indicated by additional letters in @@ -21,7 +7,7 @@ parenthesis: g = GPU, i = INTEL, k = KOKKOS, o = OPENMP, t = OPT. .. table_from_list:: - :columns: 4 + :columns: 3 * :doc:`none ` * :doc:`zero ` @@ -191,7 +177,7 @@ OPT. * :doc:`lj/mdf ` * :doc:`lj/relres (o) ` * :doc:`lj/spica (gko) ` - * :doc:`lj/spica/coul/long (go) ` + * :doc:`lj/spica/coul/long (gko) ` * :doc:`lj/spica/coul/msm (o) ` * :doc:`lj/sf/dipole/sf (go) ` * :doc:`lj/smooth (go) ` @@ -260,6 +246,8 @@ OPT. * :doc:`rebo (io) ` * :doc:`rebomos (o) ` * :doc:`resquared (go) ` + * :doc:`rheo ` + * :doc:`rheo/solid ` * :doc:`saip/metal (t) ` * :doc:`sdpd/taitwater/isothermal ` * :doc:`smatb ` diff --git a/doc/src/Commands_parse.rst b/doc/src/Commands_parse.rst index f6aa859ac2..a342441878 100644 --- a/doc/src/Commands_parse.rst +++ b/doc/src/Commands_parse.rst @@ -42,8 +42,8 @@ LAMMPS: If the $ is followed by text in curly brackets '{}', then the variable name is the text inside the curly brackets. If no curly brackets follow the $, then the variable name is the single character - immediately following the $. Thus ${myTemp} and $x refer to variables - named "myTemp" and "x", while "$xx" will be interpreted as a variable + immediately following the $. Thus ``${myTemp}`` and ``$x`` refer to variables + named "myTemp" and "x", while ``$xx`` will be interpreted as a variable named "x" followed by an "x" character. How the variable is converted to a text string depends on what style @@ -79,10 +79,10 @@ LAMMPS: Additionally, the entire "immediate" variable expression may be followed by a colon, followed by a C-style format string, - e.g. ":%f" or ":%.10g". The format string must be appropriate for + e.g. ``:%f`` or ``:%.10g``. The format string must be appropriate for a double-precision floating-point value. The format string is used to output the result of the variable expression evaluation. If a - format string is not specified, a high-precision "%.20g" is used as + format string is not specified, a high-precision ``%.20g`` is used as the default format. This can be useful for formatting print output to a desired precision: @@ -101,8 +101,8 @@ LAMMPS: variable b2 equal 4 print "B2 = ${b$a}" - Nor can you specify an expression like "$($x-1.0)" for an immediate - variable, but you could use $(v_x-1.0), since the latter is valid + Nor can you specify an expression like ``$($x-1.0)`` for an immediate + variable, but you could use ``$(v_x-1.0)``, since the latter is valid syntax for an :doc:`equal-style variable `. See the :doc:`variable ` command for more details of how diff --git a/doc/src/Commands_removed.rst b/doc/src/Commands_removed.rst index 4955bc6f0b..ea8b3d4b03 100644 --- a/doc/src/Commands_removed.rst +++ b/doc/src/Commands_removed.rst @@ -8,6 +8,18 @@ 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. +restart2data tool +----------------- + +.. versionchanged:: 23Nov2013 + +The functionality of the restart2data tool has been folded into the +LAMMPS executable directly instead of having a separate tool. A +combination of the commands :doc:`read_restart ` and +:doc:`write_data ` can be used to the same effect. For +added convenience this conversion can also be triggered by +:doc:`command line flags ` + Fix ave/spatial and fix ave/spatial/sphere ------------------------------------------ @@ -151,17 +163,16 @@ and allow running LAMMPS with GPU acceleration. i-PI tool --------- -.. versionchanged:: 27June2024 +.. versionchanged:: 27Jun2024 The i-PI tool has been removed from the LAMMPS distribution. Instead, instructions to install i-PI from PyPI via pip are provided. -restart2data tool ------------------ +LAMMPS shell +------------ + +.. versionchanged:: 29Aug2024 + +The LAMMPS shell has been removed from the LAMMPS distribution. Users +are encouraged to use the :ref:`LAMMPS-GUI ` tool instead. -The functionality of the restart2data tool has been folded into the -LAMMPS executable directly instead of having a separate tool. A -combination of the commands :doc:`read_restart ` and -:doc:`write_data ` can be used to the same effect. For -added convenience this conversion can also be triggered by -:doc:`command line flags ` diff --git a/doc/src/Commands_structure.rst b/doc/src/Commands_structure.rst index 98744efb2a..f4558f50f7 100644 --- a/doc/src/Commands_structure.rst +++ b/doc/src/Commands_structure.rst @@ -8,10 +8,10 @@ page. A LAMMPS input script typically has 4 parts: -1. :ref:`Initialization ` -2. :ref:`System definition ` -3. :ref:`Simulation settings ` -4. :ref:`Run a simulation ` +#. :ref:`Initialization ` +#. :ref:`System definition ` +#. :ref:`Simulation settings ` +#. :ref:`Run a simulation ` The last 2 parts can be repeated as many times as desired. I.e. run a simulation, change some settings, run some more, etc. Each of the 4 diff --git a/doc/src/Developer_atom.rst b/doc/src/Developer_atom.rst index 8bc187ae7f..5171943c85 100644 --- a/doc/src/Developer_atom.rst +++ b/doc/src/Developer_atom.rst @@ -2,7 +2,7 @@ Accessing per-atom data ----------------------- This page discusses how per-atom data is managed in LAMMPS, how it can -be accessed, what communication patters apply, and some of the utility +be accessed, what communication patterns apply, and some of the utility functions that exist for a variety of purposes. @@ -14,11 +14,11 @@ As described on the :doc:`parallel partitioning algorithms simulation domain, either in a *brick* or *tiled* manner. Each MPI process *owns* exactly one subdomain and the atoms within it. To compute forces for tuples of atoms that are spread across sub-domain boundaries, -also a "halo" of *ghost* atoms are maintained within a the communication +also a "halo" of *ghost* atoms are maintained within the communication cutoff distance of its subdomain. The total number of atoms is stored in `Atom::natoms` (within any -typical class this can be referred to at `atom->natoms`. The number of +typical class this can be referred to at `atom->natoms`). The number of *owned* (or "local" atoms) are stored in `Atom::nlocal`; the number of *ghost* atoms is stored in `Atom::nghost`. The sum of `Atom::nlocal` over all MPI processes should be `Atom::natoms`. This is by default @@ -27,8 +27,8 @@ LAMMPS stops with a "lost atoms" error. For convenience also the property `Atom::nmax` is available, this is the maximum of `Atom::nlocal + Atom::nghost` across all MPI processes. -Per-atom properties are either managed by the atom style, or individual -classes. or as custom arrays by the individual classes. If only access +Per-atom properties are either managed by the atom style, individual +classes, or as custom arrays by the individual classes. If only access to *owned* atoms is needed, they are usually allocated to be of size `Atom::nlocal`, otherwise of size `Atom::nmax`. Please note that not all per-atom properties are available or updated on *ghost* atoms. For @@ -61,7 +61,7 @@ can be found via the `Atom::sametag` array. It points to the next atom index with the same tag or -1 if there are no more atoms with the same tag. The list will be exhaustive when starting with an index of an *owned* atom, since the atom IDs are unique, so there can only be one -such atom. Example code to count atoms with same atom ID in subdomain: +such atom. Example code to count atoms with same atom ID in a subdomain: .. code-block:: c++ diff --git a/doc/src/Developer_code_design.rst b/doc/src/Developer_code_design.rst index 844dbd0512..974266ec7f 100644 --- a/doc/src/Developer_code_design.rst +++ b/doc/src/Developer_code_design.rst @@ -69,7 +69,7 @@ The basic LAMMPS class hierarchy which is created by the LAMMPS class constructor is shown in :ref:`class-topology`. When input commands are processed, additional class instances are created, or deleted, or replaced. Likewise, specific member functions of specific classes are -called to trigger actions such creating atoms, computing forces, +called to trigger actions such as creating atoms, computing forces, computing properties, time-propagating the system, or writing output. Compositing and Inheritance @@ -110,9 +110,10 @@ As mentioned above, there can be multiple instances of classes derived from the ``Fix`` or ``Compute`` base classes. They represent a different facet of LAMMPS' flexibility, as they provide methods which can be called at different points within a timestep, as explained in -`Developer_flow`. This allows the input script to tailor how a specific -simulation is run, what diagnostic computations are performed, and how -the output of those computations is further processed or output. +the :doc:`How a timestep works ` doc page. This allows +the input script to tailor how a specific simulation is run, what +diagnostic computations are performed, and how the output of those +computations is further processed or output. Additional code sharing is possible by creating derived classes from the derived classes (e.g., to implement an accelerated version of a pair diff --git a/doc/src/Developer_flow.rst b/doc/src/Developer_flow.rst index 115d6ee6ae..17d75879ca 100644 --- a/doc/src/Developer_flow.rst +++ b/doc/src/Developer_flow.rst @@ -128,7 +128,7 @@ reflect particles off box boundaries in the :doc:`FixWallReflect class The ``decide()`` method in the Neighbor class determines whether neighbor lists need to be rebuilt on the current timestep (conditions can be changed using the :doc:`neigh_modify every/delay/check -` command. If not, coordinates of ghost atoms are +` command). If not, coordinates of ghost atoms are acquired by each processor via the ``forward_comm()`` method of the Comm class. If neighbor lists need to be built, several operations within the inner if clause of the pseudocode are first invoked. The diff --git a/doc/src/Developer_grid.rst b/doc/src/Developer_grid.rst index 22eadd5da8..1661524f90 100644 --- a/doc/src/Developer_grid.rst +++ b/doc/src/Developer_grid.rst @@ -433,7 +433,7 @@ from owned to ghost cells, or ghost to owned cells, respectively, as described above. The *caller* argument should be one of these values -- Grid3d::COMPUTE, Grid3d::FIX, Grid3d::KSPACE, Grid3d::PAIR -- depending on the style of the caller class. The *ptr* argument is the -"this" pointer to the caller class. These 2 arguments are used to +"this" pointer to the caller class. These two arguments are used to call back to pack()/unpack() functions in the caller class, as explained below. diff --git a/doc/src/Developer_notes.rst b/doc/src/Developer_notes.rst index 9f950dda8a..af26b4b913 100644 --- a/doc/src/Developer_notes.rst +++ b/doc/src/Developer_notes.rst @@ -20,7 +20,7 @@ Available topics are: Reading and parsing of text and text files ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -It is frequently required for a class in LAMMPS to read in additional +Classes in LAMMPS frequently need to read in additional data from a file, e.g. potential parameters from a potential file for manybody potentials. LAMMPS provides several custom classes and convenience functions to simplify the process. They offer the @@ -128,9 +128,8 @@ that determines the kind of neighbor list requested. The default value used here asks for a perpetual "half" neighbor list. Non-default values of the second argument need to be used to adjust a -neighbor list request to the specific needs of a style an additional -request flag is needed. The :doc:`tersoff ` pair style, -for example, needs a "full" neighbor list: +neighbor list request to the specific needs of a style. The :doc:`tersoff +` pair style, for example, needs a "full" neighbor list: .. code-block:: c++ @@ -141,8 +140,8 @@ for example, needs a "full" neighbor list: } When a pair style supports r-RESPA time integration with different cutoff regions, -the request flag may depend on the corresponding r-RESPA settings. Here an example -from pair style lj/cut: +the request flag may depend on the corresponding r-RESPA settings. Here is an +example from pair style lj/cut: .. code-block:: c++ @@ -160,7 +159,7 @@ from pair style lj/cut: } Granular pair styles need neighbor lists based on particle sizes and not cutoff -and also may require to have the list of previous neighbors available ("history"). +and also may need to store data across timesteps ("history"). For example with: .. code-block:: c++ @@ -169,7 +168,7 @@ For example with: else neighbor->add_request(this, NeighConst::REQ_SIZE); In case a class would need to make multiple neighbor list requests with different -settings each request can set an id which is then used in the corresponding +settings, each request can set an id which is then used in the corresponding ``init_list()`` function to assign it to the suitable pointer variable. This is done for example by the :doc:`pair style meam `: @@ -279,8 +278,8 @@ And here is how the code operates: * The :doc:`thermo_style custom ` command defines *ecouple* and *econserve* keywords. * These keywords sum the energy contributions from all the - *ecouple_flag* = 1 fixes by invoking the energy_couple() method in - the Modify class, which calls the compute_scalar() method of each + *ecouple_flag* = 1 fixes by invoking the *energy_couple()* method in + the Modify class, which calls the *compute_scalar()* method of each fix in the list. ------------------ @@ -320,19 +319,19 @@ The fix must also do the following: The ev_init() and ev_tally() methods also account for global and peratom virial contributions. Thus you do not need to invoke the - v_init() and v_tally() methods, if the fix also calculates peratom + v_init() and v_tally() methods if the fix also calculates peratom energies. The fix must also specify whether (by default) to include or exclude these contributions to the global/peratom energy/virial of the system. -For the fix to include the contributions, set either of both of these +For the fix to include the contributions, set either or both of these variables in the constructor: * *thermo_energy* = 1, for global and peratom energy * *thermo_virial* = 1, for global and peratom virial Note that these variables are zeroed in fix.cpp. Thus if you don't -set the variables, the contributions will be excluded (by default) +set the variables, the contributions will be excluded (by default). However, the user has ultimate control over whether to include or exclude the contributions of the fix via the :doc:`fix modify @@ -406,9 +405,11 @@ processor owns, within the global grid: .. parsed-literal:: - nxlo_in,nxhi_in,nylo_in,nyhi_in,nzlo_in,nzhi_in = 3d decomposition brick - nxlo_fft,nxhi_fft,nylo_fft,nyhi_fft,nzlo_fft,nzhi_fft = FFT decomposition brick - nxlo_out,nxhi_out,nylo_out,nyhi_out,nzlo_out,nzhi_out = 3d decomposition brick + ghost cells + nFOO_in = 3d decomposition brick + nFOO_fft = FFT decomposition brick + nFOO_out = 3d decomposition brick + ghost cells + +where ``FOO`` corresponds to ``xlo, xhi, ylo, yhi, zlo,`` or ``zhi``. The ``in`` and ``fft`` indices are from 0 to N-1 inclusive in each dimension, where N is the grid size. diff --git a/doc/src/Developer_par_comm.rst b/doc/src/Developer_par_comm.rst index 88f0bf7fe9..2f94beb96f 100644 --- a/doc/src/Developer_par_comm.rst +++ b/doc/src/Developer_par_comm.rst @@ -4,8 +4,7 @@ Communication Following the selected partitioning scheme, all per-atom data is distributed across the MPI processes, which allows LAMMPS to handle very large systems provided it uses a correspondingly large number of MPI -processes. Since The per-atom data (atom IDs, positions, velocities, -types, etc.) To be able to compute the short-range interactions, MPI +processes. To be able to compute the short-range interactions, MPI processes need not only access to the data of atoms they "own" but also information about atoms from neighboring subdomains, in LAMMPS referred to as "ghost" atoms. These are copies of atoms storing required @@ -37,7 +36,7 @@ be larger than half the simulation domain. Efficient communication patterns are needed to update the "ghost" atom data, since that needs to be done at every MD time step or minimization -step. The diagrams of the `ghost-atom-comm` figure illustrate how ghost +step. The diagrams of the :ref:`ghost-atom-comm` figure illustrate how ghost atom communication is performed in two stages for a 2d simulation (three in 3d) for both a regular and irregular partitioning of the simulation box. For the regular case (left) atoms are exchanged first in the diff --git a/doc/src/Developer_par_long.rst b/doc/src/Developer_par_long.rst index 73b92e47c2..ecbcd81e64 100644 --- a/doc/src/Developer_par_long.rst +++ b/doc/src/Developer_par_long.rst @@ -93,7 +93,7 @@ processors, since each tile in the initial tiling overlaps with a handful of tiles in the final tiling. The transformations could also be done using collective communication -across all $P$ processors with a single call to ``MPI_Alltoall()``, but +across all :math:`P` processors with a single call to ``MPI_Alltoall()``, but this is typically much slower. However, for the specialized brick and pencil tiling illustrated in :ref:`fft-parallel` figure, collective communication across the entire MPI communicator is not required. In @@ -138,7 +138,7 @@ grid/particle operations that LAMMPS supports: :math:`O(P^{\frac{1}{2}})`. - For efficiency in performing 1d FFTs, the grid transpose - operations illustrated in Figure \ref{fig:fft} also involve + operations illustrated in Figure :ref:`fft-parallel` also involve reordering the 3d data so that a different dimension is contiguous in memory. This reordering can be done during the packing or unpacking of buffers for MPI communication. diff --git a/doc/src/Developer_par_neigh.rst b/doc/src/Developer_par_neigh.rst index c3eaf9c0f7..9fa279c7d0 100644 --- a/doc/src/Developer_par_neigh.rst +++ b/doc/src/Developer_par_neigh.rst @@ -149,7 +149,7 @@ supports: - Dependent on the "pair" setting of the :doc:`newton ` command, the "half" neighbor lists may contain **all** pairs of atoms where - atom *j* is a ghost atom (i.e. when the newton pair setting is *off*) + atom *j* is a ghost atom (i.e. when the newton pair setting is *off*). For the newton pair *on* setting the atom *j* is only added to the list if its *z* coordinate is larger, or if equal the *y* coordinate is larger, and that is equal, too, the *x* coordinate is larger. For diff --git a/doc/src/Developer_par_openmp.rst b/doc/src/Developer_par_openmp.rst index 7e2021de67..5551e185df 100644 --- a/doc/src/Developer_par_openmp.rst +++ b/doc/src/Developer_par_openmp.rst @@ -1,13 +1,13 @@ OpenMP Parallelism ^^^^^^^^^^^^^^^^^^ -The styles in the INTEL, KOKKOS, and OPENMP package offer to use OpenMP +The styles in the INTEL, KOKKOS, and OPENMP packages offer to use OpenMP thread parallelism to predominantly distribute loops over local data and thus follow an orthogonal parallelization strategy to the decomposition into spatial domains used by the :doc:`MPI partitioning `. For clarity, this section discusses only the implementation in the OPENMP package, as it is the simplest. The INTEL -and KOKKOS package offer additional options and are more complex since +and KOKKOS packages offer additional options and are more complex since they support more features and different hardware like co-processors or GPUs. @@ -16,7 +16,7 @@ keep the changes to the source code small, so that it would be easier to maintain the code and keep it in sync with the non-threaded standard implementation. This is achieved by a) making the OPENMP version a derived class from the regular version (e.g. ``PairLJCutOMP`` from -``PairLJCut``) and overriding only methods that are multi-threaded or +``PairLJCut``) and only overriding methods that are multi-threaded or need to be modified to support multi-threading (similar to what was done in the OPT package), b) keeping the structure in the modified code very similar so that side-by-side comparisons are still useful, and c) diff --git a/doc/src/Developer_plugins.rst b/doc/src/Developer_plugins.rst index dd5431507e..354350dde7 100644 --- a/doc/src/Developer_plugins.rst +++ b/doc/src/Developer_plugins.rst @@ -53,7 +53,7 @@ Members of ``lammpsplugin_t`` .. list-table:: :header-rows: 1 - :widths: auto + :widths: 15 85 * - Member - Description @@ -135,7 +135,7 @@ unique inside the entire LAMMPS executable. Fix style example ^^^^^^^^^^^^^^^^^ -If the factory function would be for a fix or compute, which take three +If the factory function is for a fix or compute, which take three arguments (a pointer to the LAMMPS class, the number of arguments and the list of argument strings), then the pointer type is ``lammpsplugin_factory2`` and it must be assigned to the *creator.v2* member of the plugin struct. @@ -271,7 +271,7 @@ Plugins need to be compiled with the same compilers and libraries as the LAMMPS executable and library. Otherwise the plugin will likely not load due to mismatches in the function signatures (LAMMPS is C++ so scope, type, and number of arguments are encoded into the symbol names -and thus differences in them will lead to failed plugin load commands. +and thus differences in them will lead to failed plugin load commands). Compilation of the plugin can be managed via both, CMake or traditional GNU makefiles. Some examples that can be used as a template are in the ``examples/plugins`` folder. The CMake script code has some small @@ -283,7 +283,7 @@ in the ``examples/kim/plugin`` folder. No changes to the sources of the KIM package themselves are needed; only the plugin interface and loader code needs to be added. This example only supports building with CMake, but is probably a more typical example. To compile you need to run CMake -with -DLAMMPS_SOURCE_DIR=. Other +with ``-DLAMMPS_SOURCE_DIR=``. Other configuration setting are identical to those for compiling LAMMPS. A second example for a plugin from a package is in the diff --git a/doc/src/Developer_unittest.rst b/doc/src/Developer_unittest.rst index b48c3b4e17..07ffb0e2d8 100644 --- a/doc/src/Developer_unittest.rst +++ b/doc/src/Developer_unittest.rst @@ -44,7 +44,7 @@ available: .. list-table:: :header-rows: 1 - :widths: auto + :widths: 32 18 50 :align: left * - File name: @@ -227,12 +227,12 @@ Tests for the C-style library interface ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Tests for validating the LAMMPS C-style library interface are in the -``unittest/c-library`` folder. They are implemented in either way used -for utility functions and for LAMMPS commands, but use the functions +``unittest/c-library`` folder. They are implemented either to be used +for utility functions or for LAMMPS commands, but use the functions implemented in the ``src/library.cpp`` file as much as possible. There may be some overlap with other tests, but only in as much as is required to test the C-style library API. The tests are distributed over -multiple test programs which tries to match the grouping of the +multiple test programs which try to match the grouping of the functions in the source code and :ref:`in the manual `. This group of tests also includes tests invoking LAMMPS in parallel @@ -258,7 +258,7 @@ Tests for the Python module and package The ``unittest/python`` folder contains primarily tests for classes and functions in the LAMMPS python module but also for commands in the -PYTHON package. These tests are only enabled, if the necessary +PYTHON package. These tests are only enabled if the necessary prerequisites are detected or enabled during configuration and compilation of LAMMPS (shared library build enabled, Python interpreter found, Python development files found). @@ -272,7 +272,7 @@ Tests for the Fortran interface Tests for using the Fortran module are in the ``unittest/fortran`` folder. Since they are also using the GoogleTest library, they require -to also implement test wrappers in C++ that will call fortran functions +implementing test wrappers in C++ that will call fortran functions which provide a C function interface through ISO_C_BINDINGS that will in turn call the functions in the LAMMPS Fortran module. @@ -293,7 +293,7 @@ The ``unittest/formats`` folder contains test programs for reading and writing files like data files, restart files, potential files or dump files. This covers simple things like the file i/o convenience functions in the ``utils::`` namespace to complex tests of atom styles where creating and -deleting of atoms with different properties is tested in different ways +deleting atoms with different properties is tested in different ways and through script commands or reading and writing of data or restart files. Tests for styles computing or modifying forces @@ -411,7 +411,7 @@ With this scheme a large fraction of the code of any tested pair style will be executed and consistent results are required for different settings and between different accelerated pair style variants and the base class, as well as for computing individual pairs through the -``Pair::single()`` where supported. +``Pair::single()`` method where supported. The ``test_pair_style`` tester is used with 4 categories of test inputs: @@ -443,7 +443,7 @@ file for a style that is similar to one to be tested. The file name should follow the naming conventions described above and after copying the file, the first step is to replace the style names where needed. The coefficient values do not have to be meaningful, just in a reasonable range for the -given system. It does not matter if some forces are large, for as long as +given system. It does not matter if some forces are large, as long as they do not diverge. The template input files define a large number of index variables at the top @@ -535,7 +535,7 @@ The are by default no unit tests for newly added features (e.g. pair, fix, or compute styles) unless your pull request also includes tests for the added features. If you are modifying some features, you may see failures for existing tests, if your modifications have some unexpected side effects -or your changes render the existing text invalid. If you are adding an +or your changes render the existing test invalid. If you are adding an accelerated version of an existing style, then only tests for INTEL, KOKKOS (with OpenMP only), OPENMP, and OPT will be run automatically. Tests for the GPU package are time consuming and thus are only run @@ -543,7 +543,7 @@ Tests for the GPU package are time consuming and thus are only run to the pull request. After the test has started, it is often best to remove the label since every PR activity will re-trigger the test (that is a limitation of triggering a test with a label). Support for unit -tests with using KOKKOS with GPU acceleration is currently not supported. +tests when using KOKKOS with GPU acceleration is currently not supported. When you see a failed build on GitHub, click on ``Details`` to be taken to the corresponding LAMMPS Jenkins CI web page. Click on the "Exit" @@ -589,11 +589,10 @@ While the epsilon (relative precision) for a single, `IEEE 754 compliant point operation is at about 2.2e-16, the achievable precision for the tests is lower due to most numbers being sums over intermediate results and the non-associativity of floating point math leading to larger -errors. In some cases specific properties of the tested style. As a -rule of thumb, the test epsilon can often be in the range 5.0e-14 to -1.0e-13. But for "noisy" force kernels, e.g. those a larger amount of -arithmetic operations involving `exp()`, `log()` or `sin()` functions, -and also due to the effect of compiler optimization or differences +errors. As a rule of thumb, the test epsilon can often be in the range +5.0e-14 to 1.0e-13. But for "noisy" force kernels, e.g. those a larger +amount of arithmetic operations involving `exp()`, `log()` or `sin()` +functions, and also due to the effect of compiler optimization or differences between compilers or platforms, epsilon may need to be further relaxed, sometimes epsilon can be relaxed to 1.0e-12. If interpolation or lookup tables are used, epsilon may need to be set to 1.0e-10 or even higher. diff --git a/doc/src/Developer_updating.rst b/doc/src/Developer_updating.rst index 83491ac095..21980be3d8 100644 --- a/doc/src/Developer_updating.rst +++ b/doc/src/Developer_updating.rst @@ -52,10 +52,9 @@ Rename of pack/unpack_comm() to pack/unpack_forward_comm() .. versionchanged:: 8Aug2014 -In this change set the functions to pack data into communication buffers -and to unpack data from communication buffers for :doc:`forward -communications ` were renamed from ``pack_comm()`` -and ``unpack_comm()`` to ``pack_forward_comm()`` and +In this change set, the functions to pack/unpack data into communication buffers +for :doc:`forward communications ` were renamed from +``pack_comm()`` and ``unpack_comm()`` to ``pack_forward_comm()`` and ``unpack_forward_comm()``, respectively. Also the meaning of the return value of these functions was changed: rather than returning the number of items per atom stored in the buffer, now the total number of items @@ -109,7 +108,7 @@ Use ev_init() to initialize variables derived from eflag and vflag There are several variables that need to be initialized based on the values of the "eflag" and "vflag" variables and since sometimes there are new bits added and new variables need to be set to 1 or 0. -To make this consistent, across all styles, there is now an inline +To make this consistent across all styles, there is now an inline function ``ev_init(eflag, vflag)`` that makes those settings consistently and calls either ``ev_setup()`` or ``ev_unset()``. Example from a pair style: @@ -211,14 +210,14 @@ The :cpp:func:`utils::open_potential() calls to ``force->open_potential()`` and should be used to replace ``fopen()`` for opening potential files for reading. The custom function does three additional steps compared to ``fopen()``: 1) it will -try to parse the ``UNITS:`` and ``DATE:`` metadata will stop with an +try to parse the ``UNITS:`` and ``DATE:`` metadata and will stop with an error on a units mismatch and will print the date info, if present, in the log file; 2) for pair styles that support it, it will set up possible automatic unit conversions based on the embedded unit information and LAMMPS' current units setting; 3) it will not only try to open a potential file at the given path, but will also search in the folders listed in the ``LAMMPS_POTENTIALS`` environment variable. This -allows to keep potential files in a common location instead of having to +allows potential files to reside in a common location instead of having to copy them around for simulations. Old: @@ -246,36 +245,38 @@ to use scoped enumerators instead. .. list-table:: :header-rows: 1 - :widths: auto + :widths: 23 10 23 10 23 10 * - Symbolic Constant - Value - Symbolic Constant - Value + - Symbolic Constant + - Value * - Atom::GROW + - 0 + - Atom::ATOMIC - 0 - Atom::MAP_NONE - 0 * - Atom::RESTART + - 1 + - Atom::MOLECULAR - 1 - Atom::MAP_ARRAY - 1 * - Atom::BORDER + - 2 + - Atom::TEMPLATE - 2 - Atom::MAP_HASH - 2 - * - Atom::ATOMIC + * - AtomVec::PER_ATOM - 0 - - Atom::MAP_YES - - 3 - * - Atom::MOLECULAR - - 1 - - AtomVec::PER_ATOM - - 0 - * - Atom::TEMPLATE - - 2 - AtomVec::PER_TYPE - 1 + - Atom::MAP_YES + - 3 Old: @@ -306,7 +307,7 @@ Simplify customized error messages Aided by features of the bundled {fmt} library, error messages now can have a variable number of arguments and the string will be interpreted -as a {fmt} style format string so that custom error messages can be +as a {fmt} style format string so that error messages can be easily customized without having to use temporary buffers and ``sprintf()``. Example: @@ -332,7 +333,7 @@ Use of "override" instead of "virtual" .. versionchanged:: 17Feb2022 -Since LAMMPS requires C++11 we switched to use the "override" keyword +Since LAMMPS requires C++11, we switched to use the "override" keyword instead of "virtual" to indicate polymorphism in derived classes. This allows the C++ compiler to better detect inconsistencies when an override is intended or not. Please note that "override" has to be @@ -370,7 +371,7 @@ Simplified function names for forward and reverse communication .. versionchanged:: 24Mar2022 -Rather then using the function name to distinguish between the different +Rather than using the function name to distinguish between the different forward and reverse communication functions for styles, LAMMPS now uses the type of the "this" pointer argument. diff --git a/doc/src/Developer_utils.rst b/doc/src/Developer_utils.rst index 2923e5b29c..b7f62d5364 100644 --- a/doc/src/Developer_utils.rst +++ b/doc/src/Developer_utils.rst @@ -622,7 +622,7 @@ classes: of a dense, symmetric, real matrix. #. The "PEigenDense" class only calculates the principal eigenvalue - (ie. the largest or smallest eigenvalue), and its corresponding + (i.e. the largest or smallest eigenvalue), and its corresponding eigenvector. However it is much more efficient than "Jacobi" when applied to large matrices (larger than 13x13). PEigenDense also can understand complex-valued Hermitian matrices. diff --git a/doc/src/Developer_write.rst b/doc/src/Developer_write.rst index ef4d06a5f6..54b1b6eb81 100644 --- a/doc/src/Developer_write.rst +++ b/doc/src/Developer_write.rst @@ -12,3 +12,4 @@ details are provided for writing code for LAMMPS. Developer_write_pair Developer_write_fix + Developer_write_command diff --git a/doc/src/Developer_write_command.rst b/doc/src/Developer_write_command.rst new file mode 100644 index 0000000000..16ac2092f6 --- /dev/null +++ b/doc/src/Developer_write_command.rst @@ -0,0 +1,348 @@ +Writing a new command style +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Command styles allow to do system manipulations or interfaces to the +operating system. + +In the text below, we will discuss the implementation of one example. As +shown on the page for :doc:`writing or extending command styles +`, in order to implement a new command style, a new class +must be written that is either directly or indirectly derived from the +``Command`` class. There is just one method that must be implemented: +``Command::command()``. In addition, a custom constructor is needed to get +access to the members of the ``LAMMPS`` class like the ``Error`` class to +print out error messages. The ``Command::command()`` method processes the +arguments passed to the command in the input and executes it. Any other +methods would be for the convenience of implementation of the new command. + +In general, new command styles should be added to the :ref:`EXTRA-COMMAND +package `. If you feel that your contribution should be +added to a different package, please consult with the :doc:`LAMMPS +developers ` first. The contributed code needs to support +the :doc:`traditional GNU make build process ` **and** the +:doc:`CMake build process `. + +---- + +Case 1: Implementing the geturl command +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +In this section, we will describe the procedure of adding a simple command +style to LAMMPS: the :doc:`geturl command ` that allows to download +files directly without having to rely on an external program like "wget" or +"curl". The complete implementation can be found in the files +``src/EXTRA-COMMAND/geturl.cpp`` and ``src/EXTRA-COMMAND/geturl.h`` of the +LAMMPS source code. + +Interfacing the *libcurl* library +""""""""""""""""""""""""""""""""" + +Rather than implementing the various protocols for downloading files, we +rely on an external library: `libcurl library `_. +This requires that the library and its headers are installed. For the +traditional GNU make build system, this simply requires edits to the machine +makefile to add compilation flags like for other libraries. For the CMake +based build system, we need to add some lines to the file +``cmake/Modules/Packages/EXTRA-COMMAND.cmake``: + +.. code-block:: cmake + + find_package(CURL QUIET COMPONENTS HTTP HTTPS) + option(WITH_CURL "Enable libcurl support" ${CURL_FOUND}) + if(WITH_CURL) + find_package(CURL REQUIRED COMPONENTS HTTP HTTPS) + target_compile_definitions(lammps PRIVATE -DLAMMPS_CURL) + target_link_libraries(lammps PRIVATE CURL::libcurl) + endif() + +The first ``find_package()`` command uses a built-in CMake module to find +an existing *libcurl* installation with development headers and support for +using the HTTP and HTTPS protocols. The "QUIET" flag ensures that there is +no screen output and no error if the search fails. The status of the search +is recorded in the "${CURL_FOUND}" variable. That variable sets the default +of the WITH_CURL option, which toggles whether support for *libcurl* is included +or not. + +The second ``find_package()`` uses the "REQUIRED" flag to produce an error +if the WITH_CURL option was set to ``True``, but no suitable *libcurl* +implementation with development support was found. This construct is used +so that the CMake script code inside the ``if(WITH_CURL)`` and ``endif()`` +block can be expanded later to download and compile *libcurl* as part of the +LAMMPS build process, if it is not found locally. The +``target_compile_definitions()`` function added the define ``-DLAMMPS_CURL`` +to the compilation flags when compiling objects for the LAMMPS library. +This allows to always compile the :doc:`geturl command `, but use +pre-processing to compile in the interface to *libcurl* only when it is +present and usable and otherwise stop with an error message about the +unavailability of *libcurl* to execute the functionality of the command. + +Header file +""""""""""" + +The first segment of any LAMMPS source should be the copyright and +license statement. Note the marker in the first line to indicate to +editors like emacs that this file is a C++ source, even though the .h +extension suggests a C source (this is a convention inherited from the +very beginning of the C++ version of LAMMPS). + +.. code-block:: c++ + + /* -*- c++ -*- ---------------------------------------------------------- + LAMMPS - Large-scale Atomic/Molecular Massively Parallel Simulator + https://www.lammps.org/, Sandia National Laboratories + LAMMPS development team: developers@lammps.org + + Copyright (2003) Sandia Corporation. Under the terms of Contract + DE-AC04-94AL85000 with Sandia Corporation, the U.S. Government retains + certain rights in this software. This software is distributed under + the GNU General Public License. + + See the README file in the top-level LAMMPS directory. + ------------------------------------------------------------------------- */ + +Every command style must be registered in LAMMPS by including the following +lines of code in the second part of the header after the copyright +message and before the include guards for the class definition: + +.. code-block:: c++ + + #ifdef COMMAND_CLASS + // clang-format off + CommandStyle(geturl,GetURL); + // clang-format on + #else + +This block between ``#ifdef COMMAND_CLASS`` and ``#else`` will be +included by the ``Input`` class in ``input.cpp`` to build a map of +"factory functions" that will create an instance of a Command class +and call its ``command()`` method. The map connects the name of the +command ``geturl`` with the name of the class ``GetURL``. During +compilation, LAMMPS constructs a file ``style_command.h`` that contains +``#include`` statements for all "installed" command styles. Before +including ``style_command.h`` into ``input.cpp``, the ``COMMAND_CLASS`` +define is set and the ``CommandStyle(name,class)`` macro defined. The +code of the macro adds the installed command styles to the "factory map" +which enables the ``Input`` to execute the command. + +The list of header files to include in ``style_command.h`` is automatically +updated by the build system if there are new files, so the presence of the +new header file in the ``src/EXTRA-COMMAND`` folder and the enabling of the +EXTRA-COMMAND package will trigger LAMMPS to include the new command style +when it is (re-)compiled. The "// clang-format" format comments are needed +so that running :ref:`clang-format ` on the file will not +insert unwanted blanks which would break the ``CommandStyle`` macro. + +The third part of the header file is the actual class definition of the +``GetURL`` class. This has the custom constructor and the ``command()`` +method implemented by this command style. For the constructor there is +nothing to do but to pass the ``lmp`` pointer to the base class. Since the +``command()`` method is labeled "virtual" in the base class, it must be +given the "override" property. + +.. code-block:: c++ + + #ifndef LMP_GETURL_H + #define LMP_GETURL_H + + #include "command.h" + + namespace LAMMPS_NS { + + class GetURL : public Command { + public: + GetURL(class LAMMPS *lmp) : Command(lmp) {}; + void command(int, char **) override; + }; + } // namespace LAMMPS_NS + #endif + #endif + +The "override" property helps to detect unexpected mismatches because +compilation will stop with an error in case the signature of a function +is changed in the base class without also changing it in all derived +classes. + +Implementation file +""""""""""""""""""" + +We move on to the implementation of the ``GetURL`` class in the +``geturl.cpp`` file. This file also starts with a LAMMPS copyright and +license header. Below that notice is typically the space where comments may +be added with additional information about this specific file, the +author(s), affiliation(s), and email address(es). This way the contributing +author(s) can be easily contacted, when there are questions about the +implementation later. Since the file(s) may be around for a long time, it +is beneficial to use some kind of "permanent" email address, if possible. + +.. code-block:: c++ + + /* ---------------------------------------------------------------------- + LAMMPS - Large-scale Atomic/Molecular Massively Parallel Simulator + https://www.lammps.org/, Sandia National Laboratories + LAMMPS development team: developers@lammps.org + + Copyright (2003) Sandia Corporation. Under the terms of Contract + DE-AC04-94AL85000 with Sandia Corporation, the U.S. Government retains + certain rights in this software. This software is distributed under + the GNU General Public License. + + See the README file in the top-level LAMMPS directory. + ------------------------------------------------------------------------- */ + + /* ---------------------------------------------------------------------- + Contributing authors: Axel Kohlmeyer (Temple U), + ------------------------------------------------------------------------- */ + + #include "geturl.h" + + #include "comm.h" + #include "error.h" + + #if defined(LAMMPS_CURL) + #include + #endif + + using namespace LAMMPS_NS; + +The second section of the implementation file has various include +statements. The include file for the class header has to come first, then a +couple of LAMMPS classes (sorted alphabetically) followed by the header for +the *libcurl* interface. This is wrapped into an ``#ifdef`` block so that +LAMMPS will compile this file without error when the *libcurl* header is not +available and thus the define not set. The final statement of this segment +imports the ``LAMMPS_NS::`` namespace globally for this file. This way, all +LAMMPS specific functions and classes do not have to be prefixed with +``LAMMPS_NS::``. + +The command() function (required) +""""""""""""""""""""""""""""""""" + +Since the required custom constructor is trivial and implemented in the +header, there is only one function that must be implemented for a command +style and that is the ``command()`` function. + +.. code-block:: c++ + + void GetURL::command(int narg, char **arg) + { + #if !defined(LAMMPS_CURL) + error->all(FLERR, "LAMMPS has not been compiled with libcurl support"); + #else + if (narg < 1) utils::missing_cmd_args(FLERR, "geturl", error); + int verify = 1; + int overwrite = 1; + int verbose = 0; + +This first part also has the ``#ifdef`` block depending on the LAMMPS_CURL +define. This way the command will simply print an error, if *libcurl* is +not available but will not fail to compile. Furthermore, it sets the +defaults for the following optional arguments. + +.. code-block:: c++ + + // process arguments + + std::string url = arg[0]; + + // sanity check + + if ((url.find(':') == std::string::npos) || (url.find('/') == std::string::npos)) + error->all(FLERR, "URL '{}' is not a supported URL", url); + + std::string output = url.substr(url.find_last_of('/') + 1); + if (output.empty()) error->all(FLERR, "URL '{}' must end in a file string", url); + +This block stores the positional, i.e. non-optional argument of the URL to +be downloaded and adds a couple of sanity checks on the string to make sure it is +a valid URL. Also it derives the default name of the output file from the URL. + +.. code-block:: c++ + + int iarg = 1; + while (iarg < narg) { + if (strcmp(arg[iarg], "output") == 0) { + if (iarg + 2 > narg) utils::missing_cmd_args(FLERR, "geturl output", error); + output = arg[iarg + 1]; + ++iarg; + } else if (strcmp(arg[iarg], "overwrite") == 0) { + if (iarg + 2 > narg) utils::missing_cmd_args(FLERR, "geturl overwrite", error); + overwrite = utils::logical(FLERR, arg[iarg + 1], false, lmp); + ++iarg; + } else if (strcmp(arg[iarg], "verify") == 0) { + if (iarg + 2 > narg) utils::missing_cmd_args(FLERR, "geturl verify", error); + verify = utils::logical(FLERR, arg[iarg + 1], false, lmp); + ++iarg; + } else if (strcmp(arg[iarg], "verbose") == 0) { + if (iarg + 2 > narg) utils::missing_cmd_args(FLERR, "geturl verbose", error); + verbose = utils::logical(FLERR, arg[iarg + 1], false, lmp); + ++iarg; + } else { + error->all(FLERR, "Unknown geturl keyword: {}", arg[iarg]); + } + ++iarg; + } + +This block parses the optional arguments following the URL and stops with an +error if there are arguments missing or an unknown argument is encountered. + +.. code-block:: c++ + + // only download files from rank 0 + + if (comm->me != 0) return; + + if (!overwrite && platform::file_is_readable(output)) return; + + // open output file for writing + + FILE *out = fopen(output.c_str(), "wb"); + if (!out) + error->all(FLERR, "Cannot open output file {} for writing: {}", output, utils::getsyserror()); + +Here all MPI ranks other than 0 will return, so that the URL download will +only happen from a single MPI rank. For that rank the output file is opened +for writing using the C library function ``fopen()``. + +.. code-block:: c++ + + // initialize curl and perform download + + CURL *curl; + curl_global_init(CURL_GLOBAL_DEFAULT); + curl = curl_easy_init(); + if (curl) { + (void) curl_easy_setopt(curl, CURLOPT_URL, url.c_str()); + (void) curl_easy_setopt(curl, CURLOPT_WRITEDATA, (void *) out); + (void) curl_easy_setopt(curl, CURLOPT_FILETIME, 1L); + (void) curl_easy_setopt(curl, CURLOPT_FAILONERROR, 1L); + if (verbose && screen) { + (void) curl_easy_setopt(curl, CURLOPT_VERBOSE, 1L); + (void) curl_easy_setopt(curl, CURLOPT_STDERR, (void *) screen); + } + if (!verify) { + (void) curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, 0L); + (void) curl_easy_setopt(curl, CURLOPT_SSL_VERIFYHOST, 0L); + } + auto res = curl_easy_perform(curl); + if (res != CURLE_OK) { + long response = 0L; + curl_easy_getinfo(curl, CURLINFO_RESPONSE_CODE, &response); + error->one(FLERR, "Download of {} failed with: {} {}", output, curl_easy_strerror(res), + response); + } + curl_easy_cleanup(curl); + +This block now implements the actual URL download with the selected options +via the "easy" interface of *libcurl*. For the details of what these +function calls do, please have a look at the `*libcurl documentation +`_. + + .. code-block:: c++ + + } + curl_global_cleanup(); + fclose(out); + #endif + } + +Finally, the previously opened file is closed and the command is complete. diff --git a/doc/src/Developer_write_fix.rst b/doc/src/Developer_write_fix.rst index f8732f74e3..afa569b05d 100644 --- a/doc/src/Developer_write_fix.rst +++ b/doc/src/Developer_write_fix.rst @@ -74,8 +74,7 @@ The next method we need to implement is ``setmask()``: Here the we specify which methods of the fix should be called during :doc:`execution of a timestep `. The constant -``END_OF_STEP`` corresponds to the ``end_of_step()`` method. The most -important available methods that are called during a timestep. +``END_OF_STEP`` corresponds to the ``end_of_step()`` method. .. code-block:: c++ @@ -127,7 +126,7 @@ there is no need to inherit from it directly. The code above computes average velocity for all particles in the simulation. Yet you have one unused parameter in fix call from the script: ``group_name``. This parameter specifies the group of atoms -used in the fix. So we should compute average for all particles in the +used in the fix. So we should compute the average for all particles in the simulation only if ``group_name == "all"``, but it can be any group. The group membership information of an atom is contained in the *mask* property of an atom and the bit corresponding to a given group is @@ -142,7 +141,7 @@ stored in the groupbit variable which is defined in Fix base class: } Class Atom encapsulates atoms positions, velocities, forces, etc. Users -can access them using particle index. Note, that particle indexes are +can access them using the particle index. Note, that particle indexes are usually changed every few timesteps because of neighbor list rebuilds and spatial sorting (to improve cache efficiency). @@ -154,8 +153,8 @@ this situation there are several methods which should be implemented: - ``double memory_usage()``: return how much memory the fix uses (optional) - ``void grow_arrays(int)``: do reallocation of the per-particle arrays in your fix - ``void copy_arrays(int i, int j, int delflag)``: copy i-th per-particle - information to j-th. Used when atom sorting is performed. if delflag is set - and atom j owns a body, move the body information to atom i. + information to j-th particle position. Used when atom sorting is performed. + if delflag is set and atom j owns a body, move the body information to atom i. - ``void set_arrays(int i)``: sets i-th particle related information to zero Note, that if your class implements these methods, it must add calls of @@ -230,11 +229,11 @@ is just a bunch of template functions for allocating 1D and 2D arrays. So you need to add include ``memory.h`` to have access to them. Finally, if you need to write/read some global information used in -your fix to the restart file, you might do it by setting flag -``restart_global = 1`` in the constructor and implementing methods void -``write_restart(FILE *fp)`` and ``void restart(char *buf)``. +your fix to the restart file, you might do it by setting the flag +``restart_global = 1`` in the constructor and implementing methods +``void write_restart(FILE *fp)`` and ``void restart(char *buf)``. If, in addition, you want to write the per-atom property to restart -files additional settings and functions are needed: +files then these additional settings and functions are needed: - a fix flag indicating this needs to be set ``restart_peratom = 1;`` - ``atom->add_callback()`` and ``atom->delete_callback()`` must be called diff --git a/doc/src/Developer_write_pair.rst b/doc/src/Developer_write_pair.rst index c286b9e1dd..5d5e081042 100644 --- a/doc/src/Developer_write_pair.rst +++ b/doc/src/Developer_write_pair.rst @@ -160,7 +160,7 @@ message and before the include guards for the class definition: #endif -This block of between ``#ifdef PAIR_CLASS`` and ``#else`` will be +This block between ``#ifdef PAIR_CLASS`` and ``#else`` will be included by the ``Force`` class in ``force.cpp`` to build a map of "factory functions" that will create an instance of these classes and return a pointer to it. The map connects the name of the pair style, @@ -371,9 +371,9 @@ but moving this to a separate function allows users to change global settings like the default cutoff without having to reissue all pair_coeff commands or re-read the ``Pair Coeffs`` sections from the data file. In the ``settings()`` function, also the arrays for storing -parameters, to define cutoffs, track with pairs of parameters have been -explicitly set are allocated and, if needed, initialized. In this case, -the memory allocation and initialization is moved to a function +parameters, to define cutoffs, track which pairs of parameters have been +explicitly set and allocated and, if needed, initialized. In this case, +the memory allocation and initialization are moved to a function ``allocate()``. .. code-block:: c++ @@ -588,17 +588,20 @@ loop atoms are also initialized. jnum = numneigh[i]; The inner loop (index *j*) processes the neighbor lists. The neighbor -list code encodes in the upper 2 bits whether a pair is a regular pair -of neighbor (= 0) or a pair of 1-2 (= 1), 1-3 (= 2), or 1-4 (= 3) -:doc:`"special" neighbor `. The ``sbmask()`` inline -function extracts those bits and converts them into a number. This -number is used to look up the corresponding scaling factor for the -non-bonded interaction from the ``force->special_lj`` array and stores -it in the `factor_lj` variable. Due to the additional bits, the value -of *j* would be out of range when accessing data from per-atom arrays, -so we apply the NEIGHMASK constant with a bit-wise and operation to mask -them out. This step *must* be done, even if a pair style does not use -special bond scaling of forces and energies to avoid segmentation faults. +list code encodes extra information using the upper 3 bits. The 2 +highest bits encode whether a pair is a regular pair of neighbor (= 0) +or a pair of 1-2 (= 1), 1-3 (= 2), or 1-4 (= 3) :doc:`"special" neighbor +`. The next highest bit encodes whether the pair stores +data in a ``fix neigh/history`` instance (an undocumented internal fix +style). The ``sbmask()`` inline function extracts those bits and +converts them into a number. This number is used to look up the +corresponding scaling factor for the non-bonded interaction from the +``force->special_lj`` array and stores it in the `factor_lj` variable. +Due to the additional bits, the value of *j* would be out of range when +accessing data from per-atom arrays, so we apply the NEIGHMASK constant +with a bit-wise and operation to mask them out. This step *must* be +done, even if a pair style does not use special bond scaling of forces +and energies to avoid segmentation faults. With the corrected *j* index, it is now possible to compute the distance of the pair. For efficiency reasons, the square root is only taken @@ -891,7 +894,7 @@ through *multiple* :doc:`pair_coeff commands `. Pair styles that require a single "pair_coeff \* \*" command line are not compatible with reading their parameters from data files. For pair styles like *born/gauss* that do support writing to data files, the potential -parameters will be read from the data file, if present and +parameters will be read from the data file, if present, and :doc:`pair_coeff commands ` may not be needed. The member variable ``writedata`` should be set to 1 in the constructor, diff --git a/doc/src/Errors_common.rst b/doc/src/Errors_common.rst index 7aca0f14fa..3229181d00 100644 --- a/doc/src/Errors_common.rst +++ b/doc/src/Errors_common.rst @@ -39,7 +39,8 @@ figure out your physics or numerical mistakes, like choosing too big a timestep, specifying erroneous force field coefficients, or putting 2 atoms on top of each other! If you run into errors that LAMMPS does not catch that you think it should flag, please send an email to -the `developers `_. +the `developers `_ or create an new +topic on the dedicated `MatSci forum section `_. If you get an error message about an invalid command in your input script, you can determine what command is causing the problem by diff --git a/doc/src/Errors_messages.rst b/doc/src/Errors_messages.rst index 2a146a9184..2468b3c628 100644 --- a/doc/src/Errors_messages.rst +++ b/doc/src/Errors_messages.rst @@ -96,13 +96,13 @@ Doc page with :doc:`WARNING messages ` are too far apart to make a valid angle. *Angle atoms %d %d %d missing on proc %d at step %ld* - One or more of 3 atoms needed to compute a particular angle are + One or more of three atoms needed to compute a particular angle are missing on this processor. Typically this is because the pairwise cutoff is set too short or the angle has blown apart and an atom is too far away. *Angle atoms missing on proc %d at step %ld* - One or more of 3 atoms needed to compute a particular angle are + One or more of three atoms needed to compute a particular angle are missing on this processor. Typically this is because the pairwise cutoff is set too short or the angle has blown apart and an atom is too far away. @@ -1932,7 +1932,7 @@ Doc page with :doc:`WARNING messages ` Self-explanatory. *Compute chunk/atom fix array is accessed out-of-range* - the index for the array is out of bounds. + The index for the array is out of bounds. *Compute chunk/atom fix does not calculate a per-atom array* Self-explanatory. @@ -6073,9 +6073,9 @@ Doc page with :doc:`WARNING messages ` *New atom IDs exceed maximum allowed ID* See the setting for tagint in the src/lmptype.h file. -*New bond exceeded bonds per atom in create_bonds* -See the read_data command for info on using the "extra/bond/per/atom" -keyword to allow for additional bonds to be formed +*New bond exceeded bonds per atom in create\_bonds* + See the read_data command for info on using the "extra/bond/per/atom" + keyword to allow for additional bonds to be formed *New bond exceeded bonds per atom in fix bond/create* See the read_data command for info on using the "extra/bond/per/atom" @@ -7310,12 +7310,12 @@ keyword to allow for additional bonds to be formed atom has moved too far. *Restrain atoms %d %d %d missing on proc %d at step %ld* - The 3 atoms in a restrain angle specified by the fix restrain + The three atoms in a restrain angle specified by the fix restrain command are not all accessible to a processor. This probably means an atom has moved too far. *Restrain atoms %d %d missing on proc %d at step %ld* - The 2 atoms in a restrain bond specified by the fix restrain + The two atoms in a restrain bond specified by the fix restrain command are not all accessible to a processor. This probably means an atom has moved too far. @@ -7406,7 +7406,7 @@ keyword to allow for additional bonds to be formed *Shake angles have different bond types* All 3-atom angle-constrained SHAKE clusters specified by the fix shake command that are the same angle type, must also have the same bond - types for the 2 bonds in the angle. + types for the two bonds in the angle. *Shake atoms %d %d %d %d missing on proc %d at step %ld* The 4 atoms in a single shake cluster specified by the fix shake @@ -7414,12 +7414,12 @@ keyword to allow for additional bonds to be formed an atom has moved too far. *Shake atoms %d %d %d missing on proc %d at step %ld* - The 3 atoms in a single shake cluster specified by the fix shake + The three atoms in a single shake cluster specified by the fix shake command are not all accessible to a processor. This probably means an atom has moved too far. *Shake atoms %d %d missing on proc %d at step %ld* - The 2 atoms in a single shake cluster specified by the fix shake + The two atoms in a single shake cluster specified by the fix shake command are not all accessible to a processor. This probably means an atom has moved too far. diff --git a/doc/src/Errors_warnings.rst b/doc/src/Errors_warnings.rst index d244818cc9..25aa87f162 100644 --- a/doc/src/Errors_warnings.rst +++ b/doc/src/Errors_warnings.rst @@ -23,7 +23,7 @@ Doc page with :doc:`ERROR messages ` adjusted to match the user-specified accuracy. *Angle atoms missing at step %ld* - One or more of 3 atoms needed to compute a particular angle are + One or more of three atoms needed to compute a particular angle are missing on this processor. Typically this is because the pairwise cutoff is set too short or the angle has blown apart and an atom is too far away. @@ -233,7 +233,7 @@ Doc page with :doc:`ERROR messages ` style. *Fix langevin gjf using random gaussians is not implemented with kokkos* -This will most likely cause errors in kinetic fluctuations. + This will most likely cause errors in kinetic fluctuations. *Fix property/atom mol or charge w/out ghost communication* A model typically needs these properties defined for ghost atoms. @@ -324,7 +324,7 @@ This will most likely cause errors in kinetic fluctuations. Specifically they are further apart than half a periodic box length. Or they are more than a box length apart in a non-periodic dimension. This is usually due to the initial data file not having correct image - flags for the 2 atoms in a bond that straddles a periodic boundary. + flags for the two atoms in a bond that straddles a periodic boundary. They should be different by 1 in that case. This is a warning because inconsistent image flags will not cause problems for dynamics or most LAMMPS simulations. However they can cause problems when such atoms diff --git a/doc/src/Examples.rst b/doc/src/Examples.rst index c5da4a498b..3d2103fd6f 100644 --- a/doc/src/Examples.rst +++ b/doc/src/Examples.rst @@ -134,6 +134,8 @@ Lowercase directories +-------------+------------------------------------------------------------------+ | rerun | use of rerun and read_dump commands | +-------------+------------------------------------------------------------------+ +| rheo | RHEO simulations of fluid flows and phase transitions | ++-------------+------------------------------------------------------------------+ | rigid | rigid bodies modeled as independent or coupled | +-------------+------------------------------------------------------------------+ | shear | sideways shear applied to 2d solid, with and without a void | diff --git a/doc/src/Fortran.rst b/doc/src/Fortran.rst index cea70dd3af..a1ea9a72df 100644 --- a/doc/src/Fortran.rst +++ b/doc/src/Fortran.rst @@ -1077,7 +1077,7 @@ Procedures Bound to the :f:type:`lammps` Derived Type .. list-table:: :header-rows: 1 - :widths: auto + :widths: 21 20 40 19 * - Style - Type @@ -1167,7 +1167,7 @@ Procedures Bound to the :f:type:`lammps` Derived Type .. list-table:: :header-rows: 1 - :widths: auto + :widths: 20 19 11 11 21 18 * - Style - Type @@ -2327,7 +2327,7 @@ Procedures Bound to the :f:type:`lammps` Derived Type retrieved via :f:func:`get_last_error_message`. This allows to restart a calculation or delete and recreate the LAMMPS instance when a C++ exception occurs. One application of using exceptions this way - is the :ref:`lammps_shell`. + is the :ref:`lammps_gui`. :to: :cpp:func:`lammps_config_has_exceptions` :r has_exceptions: diff --git a/doc/src/Howto.rst b/doc/src/Howto.rst index 85c98bd6de..5a63e2b1c4 100644 --- a/doc/src/Howto.rst +++ b/doc/src/Howto.rst @@ -89,6 +89,7 @@ Packages howto Howto_drude2 Howto_peri Howto_manifold + Howto_rheo Howto_spins Tutorials howto diff --git a/doc/src/Howto_bioFF.rst b/doc/src/Howto_bioFF.rst index 7418a43861..72dcec2d31 100644 --- a/doc/src/Howto_bioFF.rst +++ b/doc/src/Howto_bioFF.rst @@ -43,7 +43,7 @@ have potential energy function of the form }} \!\!\!\!\!\!\!\!+ \!\!\sum_{special}\! E_s + \!\!\!\!\sum_{residues} \!\!\!{\scriptstyle\mathrm{CMAP}(\phi,\psi)} -The terms are computed by bond styles (relationship between 2 atoms), +The terms are computed by bond styles (relationship between two atoms), angle styles (between 3 atoms) , dihedral/improper styles (between 4 atoms), pair styles (non-covalently bonded pair interactions) and special bonds. The CMAP term (see :doc:`fix cmap ` command for @@ -73,7 +73,7 @@ with additional switching or shifting functions that ramp the energy and/or force smoothly to zero between an inner :math:`(a)` and outer :math:`(b)` cutoff. The older styles with *charmm* (not *charmmfsw* or *charmmfsh*\ ) in their name compute the LJ and Coulombic interactions -with an energy switching function (esw) S(r) which ramps the energy +with an energy switching function (esw) :math:`S(r)` which ramps the energy smoothly to zero between the inner and outer cutoff. This can cause irregularities in pairwise forces (due to the discontinuous second derivative of energy at the boundaries of the switching region), which diff --git a/doc/src/Howto_bpm.rst b/doc/src/Howto_bpm.rst index 5aa277275d..86e091fcef 100644 --- a/doc/src/Howto_bpm.rst +++ b/doc/src/Howto_bpm.rst @@ -17,6 +17,8 @@ producing fracture. The examples/bpm directory has sample input scripts for simulations of the fragmentation of an impacted plate and the pouring of extended, elastic bodies. See :ref:`(Clemmer) ` for more general information on the approach and the LAMMPS implementation. +Example movies illustrating some of these capabilities are found at +https://www.lammps.org/movies.html#bpmpackage. ---------- diff --git a/doc/src/Howto_chunk.rst b/doc/src/Howto_chunk.rst index 858e8241d1..f8655b745d 100644 --- a/doc/src/Howto_chunk.rst +++ b/doc/src/Howto_chunk.rst @@ -1,7 +1,7 @@ Use chunks to calculate system properties ========================================= -In LAMMS, "chunks" are collections of atoms, as defined by the +In LAMMPS, "chunks" are collections of atoms, as defined by the :doc:`compute chunk/atom ` command, which assigns each atom to a chunk ID (or to no chunk at all). The number of chunks and the assignment of chunk IDs to atoms can be static or change over @@ -148,14 +148,14 @@ Example calculations with chunks Here are examples using chunk commands to calculate various properties: -(1) Average velocity in each of 1000 2d spatial bins: +1. Average velocity in each of 1000 2d spatial bins: .. code-block:: LAMMPS compute cc1 all chunk/atom bin/2d x 0.0 0.1 y lower 0.01 units reduced fix 1 all ave/chunk 100 10 1000 cc1 vx vy file tmp.out -(2) Temperature in each spatial bin, after subtracting a flow +2. Temperature in each spatial bin, after subtracting a flow velocity: .. code-block:: LAMMPS @@ -164,7 +164,7 @@ velocity: compute vbias all temp/profile 1 0 0 y 10 fix 1 all ave/chunk 100 10 1000 cc1 temp bias vbias file tmp.out -(3) Center of mass of each molecule: +3. Center of mass of each molecule: .. code-block:: LAMMPS @@ -172,7 +172,7 @@ velocity: compute myChunk all com/chunk cc1 fix 1 all ave/time 100 1 100 c_myChunk[*] file tmp.out mode vector -(4) Total force on each molecule and ave/max across all molecules: +4. Total force on each molecule and ave/max across all molecules: .. code-block:: LAMMPS @@ -183,7 +183,7 @@ velocity: thermo 1000 thermo_style custom step temp v_xave v_xmax -(5) Histogram of cluster sizes: +5. Histogram of cluster sizes: .. code-block:: LAMMPS @@ -192,16 +192,16 @@ velocity: compute size all property/chunk cc1 count fix 1 all ave/histo 100 1 100 0 20 20 c_size mode vector ave running beyond ignore file tmp.histo -(6) An example for using a per-chunk value to apply per-atom forces to +6. An example for using a per-chunk value to apply per-atom forces to compress individual polymer chains (molecules) in a mixture, is explained on the :doc:`compute chunk/spread/atom ` command doc page. -(7) An example for using one set of per-chunk values for molecule +7. An example for using one set of per-chunk values for molecule chunks, to create a second set of micelle-scale chunks (clustered molecules, due to hydrophobicity), is explained on the :doc:`compute reduce/chunk ` command doc page. -(8) An example for using one set of per-chunk values (dipole moment +8. An example for using one set of per-chunk values (dipole moment vectors) for molecule chunks, spreading the values to each atom in each chunk, then defining a second set of chunks as spatial bins, and using the :doc:`fix ave/chunk ` command to calculate an diff --git a/doc/src/Howto_cmake.rst b/doc/src/Howto_cmake.rst index 8b710d1065..43aa519293 100644 --- a/doc/src/Howto_cmake.rst +++ b/doc/src/Howto_cmake.rst @@ -339,8 +339,6 @@ Some common LAMMPS specific variables - build LAMMPS with OpenMP support (default: ``on`` if compiler supports OpenMP fully, else ``off``) * - ``BUILD_TOOLS`` - compile some additional executables from the ``tools`` folder (default: ``off``) - * - ``BUILD_LAMMPS_SHELL`` - - compile the LAMMPS shell from the ``tools/lammps-shell`` folder (default: ``off``) * - ``BUILD_DOC`` - include building the HTML format documentation for packaging/installing (default: ``off``) * - ``CMAKE_TUNE_FLAGS`` @@ -350,7 +348,7 @@ Some common LAMMPS specific variables * - ``FFT`` - select which FFT library to use: ``FFTW3``, ``MKL``, ``KISS`` (default, unless FFTW3 is found) * - ``FFT_KOKKOS`` - - select which FFT library to use in Kokkos-enabled styles: ``FFTW3``, ``MKL``, ``HIPFFT``, ``CUFFT``, ``KISS`` (default) + - select which FFT library to use in Kokkos-enabled styles: ``FFTW3``, ``MKL``, ``HIPFFT``, ``CUFFT``, ``MKL_GPU``, ``KISS`` (default) * - ``FFT_SINGLE`` - select whether to use single precision FFTs (default: ``off``) * - ``WITH_JPEG`` diff --git a/doc/src/Howto_coreshell.rst b/doc/src/Howto_coreshell.rst index 56ea1100e6..d235550c90 100644 --- a/doc/src/Howto_coreshell.rst +++ b/doc/src/Howto_coreshell.rst @@ -178,7 +178,7 @@ the pairs. This can be done by using the *bias* keyword of the To maintain the correct polarizability of the core/shell pairs, the kinetic energy of the internal motion shall remain nearly constant. Therefore the choice of spring force and mass ratio need to ensure -much faster relative motion of the 2 atoms within the core/shell pair +much faster relative motion of the two atoms within the core/shell pair than their center-of-mass velocity. This allows the shells to effectively react instantaneously to the electrostatic environment and limits energy transfer to or from the core/shell oscillators. diff --git a/doc/src/Howto_couple.rst b/doc/src/Howto_couple.rst index 7c8ee1e793..7e91cd59c2 100644 --- a/doc/src/Howto_couple.rst +++ b/doc/src/Howto_couple.rst @@ -36,7 +36,7 @@ the context of your application. steps, invoke the command, etc. In this scenario, the other code can be called as a library, as in - 1., or it could be a stand-alone code, invoked by a system() call + 1., or it could be a stand-alone code, invoked by a ``system()`` call made by the command (assuming your parallel machine allows one or more processors to start up another program). In the latter case the stand-alone code could communicate with LAMMPS through files that the diff --git a/doc/src/Howto_diffusion.rst b/doc/src/Howto_diffusion.rst index 5ee40d2cd3..f4af73ff4c 100644 --- a/doc/src/Howto_diffusion.rst +++ b/doc/src/Howto_diffusion.rst @@ -1,8 +1,8 @@ Calculate diffusion coefficients ================================ -The diffusion coefficient D of a material can be measured in at least -2 ways using various options in LAMMPS. See the examples/DIFFUSE +The diffusion coefficient :math:`D` of a material can be measured in at least +2 ways using various options in LAMMPS. See the ``examples/DIFFUSE`` directory for scripts that implement the 2 methods discussed here for a simple Lennard-Jones fluid model. @@ -12,7 +12,7 @@ of the MSD versus time is proportional to the diffusion coefficient. The instantaneous MSD values can be accumulated in a vector via the :doc:`fix vector ` command, and a line fit to the vector to compute its slope via the :doc:`variable slope ` function, and -thus extract D. +thus extract :math:`D`. The second method is to measure the velocity auto-correlation function (VACF) of the system, via the :doc:`compute vacf ` @@ -20,4 +20,4 @@ command. The time-integral of the VACF is proportional to the diffusion coefficient. The instantaneous VACF values can be accumulated in a vector via the :doc:`fix vector ` command, and time integrated via the :doc:`variable trap ` function, -and thus extract D. +and thus extract :math:`D`. diff --git a/doc/src/Howto_elastic.rst b/doc/src/Howto_elastic.rst index d77ff3e778..4335309a31 100644 --- a/doc/src/Howto_elastic.rst +++ b/doc/src/Howto_elastic.rst @@ -4,21 +4,27 @@ Calculate elastic constants Elastic constants characterize the stiffness of a material. The formal definition is provided by the linear relation that holds between the stress and strain tensors in the limit of infinitesimal deformation. -In tensor notation, this is expressed as s_ij = C_ijkl \* e_kl, where -the repeated indices imply summation. s_ij are the elements of the -symmetric stress tensor. e_kl are the elements of the symmetric strain -tensor. C_ijkl are the elements of the fourth rank tensor of elastic -constants. In three dimensions, this tensor has 3\^4=81 elements. Using -Voigt notation, the tensor can be written as a 6x6 matrix, where C_ij -is now the derivative of s_i w.r.t. e_j. Because s_i is itself a -derivative w.r.t. e_i, it follows that C_ij is also symmetric, with at -most 7\*6/2 = 21 distinct elements. +In tensor notation, this is expressed as + +.. math:: + + s_{ij} = C_{ijkl} e_{kl} + +where +the repeated indices imply summation. :math:`s_{ij}` are the elements of the +symmetric stress tensor. :math:`e_{kl}` are the elements of the symmetric strain +tensor. :math:`C_{ijkl}` are the elements of the fourth rank tensor of elastic +constants. In three dimensions, this tensor has :math:`3^4=81` elements. Using +Voigt notation, the tensor can be written as a 6x6 matrix, where :math:`C_{ij}` +is now the derivative of :math:`s_i` w.r.t. :math:`e_j`. Because :math:`s_i` is itself a +derivative w.r.t. :math:`e_i`, it follows that :math:`C_{ij}` is also symmetric, with at +most :math:`\frac{7 \times 6}{2}` = 21 distinct elements. At zero temperature, it is easy to estimate these derivatives by deforming the simulation box in one of the six directions using the :doc:`change_box ` command and measuring the change in the stress tensor. A general-purpose script that does this is given in the -examples/ELASTIC directory described on the :doc:`Examples ` +``examples/ELASTIC`` directory described on the :doc:`Examples ` doc page. Calculating elastic constants at finite temperature is more @@ -33,7 +39,7 @@ the :doc:`compute born/matrix ` command, which works for any bonded or non-bonded potential in LAMMPS. The most expensive part of the calculation is the sampling of the stress fluctuations. Several examples of this method are -provided in the examples/ELASTIC_T/BORN_MATRIX directory +provided in the ``examples/ELASTIC_T/BORN_MATRIX`` directory described on the :doc:`Examples ` doc page. A second way is to measure @@ -43,7 +49,7 @@ the systematic and statistical errors in this method, the magnitude of the deformation must be chosen judiciously, and care must be taken to fully equilibrate the deformed cell before sampling the stress tensor. An example of this method is provided in the -examples/ELASTIC_T/DEFORMATION directory +``examples/ELASTIC_T/DEFORMATION`` directory described on the :doc:`Examples ` doc page. Another approach is to sample the triclinic cell fluctuations diff --git a/doc/src/Howto_kappa.rst b/doc/src/Howto_kappa.rst index ca9a418d5e..d4dc5e92a8 100644 --- a/doc/src/Howto_kappa.rst +++ b/doc/src/Howto_kappa.rst @@ -1,20 +1,22 @@ Calculate thermal conductivity ============================== -The thermal conductivity kappa of a material can be measured in at -least 4 ways using various options in LAMMPS. See the examples/KAPPA +The thermal conductivity :math:`\kappa` of a material can be measured in at +least 4 ways using various options in LAMMPS. See the ``examples/KAPPA`` directory for scripts that implement the 4 methods discussed here for a simple Lennard-Jones fluid model. Also, see the :doc:`Howto viscosity ` page for an analogous discussion for viscosity. -The thermal conductivity tensor kappa is a measure of the propensity +The thermal conductivity tensor :math:`\mathbf{\kappa}` is a measure of the propensity of a material to transmit heat energy in a diffusive manner as given by Fourier's law -J = -kappa grad(T) +.. math:: -where J is the heat flux in units of energy per area per time and -grad(T) is the spatial gradient of temperature. The thermal + J = -\kappa \cdot \text{grad}(T) + +where :math:`J` is the heat flux in units of energy per area per time and +:math:`\text{grad}(T)` is the spatial gradient of temperature. The thermal conductivity thus has units of energy per distance per time per degree K and is often approximated as an isotropic quantity, i.e. as a scalar. @@ -49,7 +51,7 @@ details. The fourth method is based on the Green-Kubo (GK) formula which relates the ensemble average of the auto-correlation of the heat flux -to kappa. The heat flux can be calculated from the fluctuations of +to :math:`\kappa`. The heat flux can be calculated from the fluctuations of per-atom potential and kinetic energies and per-atom stress tensor in a steady-state equilibrated simulation. This is in contrast to the two preceding non-equilibrium methods, where energy flows continuously diff --git a/doc/src/Howto_lammps_gui.rst b/doc/src/Howto_lammps_gui.rst index 165ed84d95..21e6a31ccc 100644 --- a/doc/src/Howto_lammps_gui.rst +++ b/doc/src/Howto_lammps_gui.rst @@ -1,11 +1,11 @@ -Using the LAMMPS GUI -==================== +Using LAMMPS-GUI +================ -This document describes **LAMMPS GUI version 1.5**. +This document describes **LAMMPS-GUI version 1.6**. ----- -LAMMPS GUI is a graphical text editor customized for editing LAMMPS +LAMMPS-GUI is a graphical text editor customized for editing LAMMPS input files that is linked to the :ref:`LAMMPS library ` 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 @@ -16,62 +16,141 @@ to the online LAMMPS documentation for known LAMMPS commands and styles. .. note:: - Pre-compiled, ready-to-use LAMMPS GUI executables for Linux (Ubuntu - 20.04LTS or later and compatible), macOS (version 11 aka Big Sur or - later), and Windows (version 10 or later) :ref:`are available - ` for download. They may be linked to a - development version of LAMMPS in case they need features not yet - available in a released version. Serial LAMMPS executables of the - same LAMMPS version are included as well. The source code for the - LAMMPS GUI is included in the LAMMPS source code and can be found in - the ``tools/lammps-gui`` folder. It can be compiled alongside LAMMPS - when :doc:`compiling with CMake `. + 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 + ` for download. Non-MPI LAMMPS executables (as + ``lmp``) for running LAMMPS from the command line and :doc:`some + LAMMPS tools ` compiled executables are also included. -LAMMPS GUI tries to provide an experience similar to what people -traditionally would do to run LAMMPS using a command line window: + 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 + `. -- editing inputs with a text editor -- run LAMMPS on the input with selected command line flags -- and then use or extract data from the created files and visualize it +LAMMPS-GUI tries to provide an experience similar to what people +traditionally would have running LAMMPS using a command line window and +the console LAMMPS executable but just rolled into a single executable: + +- writing & editing LAMMPS input files with a text editor +- run LAMMPS on those input file with selected command line flags +- extract data from the created files and visualize it with and + external software That procedure is quite effective for people proficient in using the command line, as that allows them to use tools for the individual steps -which they are most comfortable with. It is often required when running -LAMMPS on high-performance computing facilities. +that they are most comfortable with. In fact, it is often *required* to +adopt this workflow when running LAMMPS simulations on high-performance +computing facilities. -The main benefit of using the LAMMPS GUI application instead is that -many basic tasks can be done directly from the GUI without switching to -a text console window or using external programs, let alone writing -scripts to extract data from the generated output. It also integrates -well with graphical desktop environments. +The main benefit of using LAMMPS-GUI is that many basic tasks can be +done directly from the GUI **without** switching to a text console +window or using external programs, let alone writing scripts to extract +data from the generated output. It also integrates well with graphical +desktop environments where the `.lmp` filename extension can be +registered with LAMMPS-GUI as the executable to launch when double +clicking on such files. Also, LAMMPS-GUI has support for drag-n-drop, +i.e. an input file can be selected and then moved and dropped on the +LAMMPS-GUI executable, and LAMMPS-GUI will launch and read the file into +its buffer. In many cases LAMMPS-GUI will be integrated into the +graphical desktop environment and can be launched like other +applications. -LAMMPS GUI thus makes it easier for beginners to get started running +LAMMPS-GUI thus makes it easier for beginners to get started running 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. It -is also designed to keep the barrier low when you decide to switch to a -full featured, standalone programming editor and more sophisticated -visualization and analysis tools and run LAMMPS from a command line. +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. + +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 +has some unique functionality that is not found elsewhere: + +- auto-adapting to features available in the integrated LAMMPS library +- interactive visualization using the :doc:`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 +- inspection of binary restart files The following text provides a detailed tour of the features and -functionality of the LAMMPS GUI. - -Suggestions for new features and reports of bugs are always welcome. -You can use the :doc:`the same channels as for LAMMPS itself -` for that purpose. +functionality of LAMMPS-GUI. Suggestions for new features and +reports of bugs are always welcome. You can use the :doc:`the same +channels as for LAMMPS itself ` for that purpose. ----- -Main window ------------ +Installing Pre-compiled LAMMPS-GUI Packages +------------------------------------------- -When LAMMPS GUI starts, it will show a main window with either an -empty buffer or the contents of a loaded file. In the latter case it -may look like the following: +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. -.. image:: JPG/lammps-gui-main.png - :align: center - :scale: 50% +Windows 10 and later +^^^^^^^^^^^^^^^^^^^^ + +After downloading the ``LAMMPS-Win10-64bit-GUI-.exe`` installer +package, you need to execute it, and start the installation process. +Since those packages are currently unsigned, you have to enable "Developer Mode" +in the Windows System Settings to run the installer. + +MacOS 11 and later +^^^^^^^^^^^^^^^^^^ + +After downloading the ``LAMMPS-macOS-multiarch-GUI-.dmg`` +installer package, you need to double-click it and then, in the window +that opens, drag the app bundle as indicated into the "Applications" +folder. The follow the instructions in the "README.txt" file to +get access to the other included executables. + +Linux on x86\_64 +^^^^^^^^^^^^^^^^ + +For Linux with x86\_64 CPU there are currently two variants. The first +is compiled on Ubuntu 20.04LTS, is using some wrapper scripts, and +should be compatible with more recent Linux distributions. After +downloading and unpacking the +``LAMMPS-Linux-x86_64-GUI-.tar.gz`` package. You can switch +into the "LAMMPS_GUI" folder and execute "./lammps-gui" directly. + +The second variant uses `flatpak `_ and +requires the flatpak management and runtime software to be installed. +After downloading the ``LAMMPS-GUI-Linux-x86_64-GUI-.tar.gz`` +flatpak bundle, you can install it with ``flatpak install --user +LAMMPS-GUI-Linux-x86_64-GUI-.tar.gz``. After installation, +LAMMPS-GUI should be integrated into your desktop environment under +"Applications > Science" but also can be launched from the console with +``flatpak run org.lammps.lammps-gui``. The flatpak bundle also includes +the console LAMMPS executable ``lmp`` which can be launched to run +simulations with, for example: ``flatpak run --command=lmp +org.lammps.lammps-gui -in in.melt``. + + +Compiling from Source +^^^^^^^^^^^^^^^^^^^^^ + +There also are instructions for :ref:`compiling LAMMPS-GUI from source +code ` available elsewhere in the manual. +Compilation from source *requires* using CMake. + +----- + +Starting LAMMPS-GUI +------------------- + +When LAMMPS-GUI starts, it shows the main window, labeled *Editor*, with +either an empty buffer or the contents of the file used as argument. In +the latter case it may look like the following: + +.. |gui-main1| image:: JPG/lammps-gui-main.png + :width: 48% + +.. |gui-main2| image:: JPG/lammps-gui-dark.png + :width: 48% + +|gui-main1| |gui-main2| There is the typical menu bar at the top, then the main editor buffer, and a status bar at the bottom. The input file contents are shown @@ -80,32 +159,41 @@ the LAMMPS input file syntax. The status bar shows the status of LAMMPS execution on the left (e.g. "Ready." when idle) and the current working directory on the right. The name of the current file in the buffer is shown in the window title; the word `*modified*` is added if -the buffer edits have not yet saved to a file. The size of the main -window will be stored when exiting and restored when starting again. +the buffer edits have not yet saved to a file. The geometry of the main +window is stored when exiting and restored when starting again. Opening Files ^^^^^^^^^^^^^ -The LAMMPS GUI application will try to open the first command line -argument as a LAMMPS input script, further arguments are ignored. -When no argument is given, LAMMPS GUI will start with an empty buffer. -Files can also be opened via the ``File`` menu or by drag-and-drop of -a file from a graphical file manager into the editor window. Only one -file can be open at a time, so opening a new file with a filled buffer -will close the buffer. If the buffer has unsaved modifications, you -will be asked to either cancel the operation, discard the changes, or -save them. +The LAMMPS-GUI application can be launched without command line arguments +and then starts with an empty buffer in the *Editor* window. If arguments +are given LAMMPS will use first command line argument as the file name for +the *Editor* buffer and reads its contents into the buffer, if the file +exists. All further arguments are ignored. Files can also be opened via +the *File* menu, the `Ctrl-O` (`Command-O` on macOS) keyboard shortcut +or by drag-and-drop of a file from a graphical file manager into the editor +window. If a file extension (e.g. ``.lmp``) has been registered with the +graphical environment to launch LAMMPS-GUI, an existing input file can +be launched with LAMMPS-GUI through double clicking. + +Only one file can be edited at a time, so opening a new file with a +filled buffer closes that buffer. If the buffer has unsaved +modifications, you are asked to either cancel the operation, discard the +changes, or save them. A buffer with modifications can be saved any +time from the "File" menu, by the keyboard shortcut `Ctrl-S` +(`Command-S` on macOS), or by clicking on the "Save" button at the very +left in the status bar. Running LAMMPS ^^^^^^^^^^^^^^ -From within the LAMMPS GUI main window LAMMPS can be started either from -the ``Run`` menu using the ``Run LAMMPS from Editor Buffer`` entry, by +From within the LAMMPS-GUI main window LAMMPS can be started either from +the *Run* menu using the *Run LAMMPS from Editor Buffer* entry, by the keyboard shortcut `Ctrl-Enter` (`Command-Enter` on macOS), or by clicking on the green "Run" button in the status bar. All of these -operations will cause LAMMPS to process the entire input script, which -may contain multiple :doc:`run ` or :doc:`minimize ` -commands. +operations causes LAMMPS to process the entire input script in the +editor buffer, which may contain multiple :doc:`run ` or +:doc:`minimize ` commands. LAMMPS runs in a separate thread, so the GUI stays responsive and is able to interact with the running calculation and access data it @@ -115,7 +203,7 @@ using the contents of the input buffer for the run (via the interface), and **not** the original file it was read from. Thus, if there are unsaved changes in the buffer, they *will* be used. As an alternative, it is also possible to run LAMMPS by reading the contents -of a file from the ``Run LAMMPS from File`` menu entry or with +of a file from the *Run LAMMPS from File* menu entry or with `Ctrl-Shift-Enter`. This option may be required in some rare cases where the input uses some functionality that is not compatible with running LAMMPS from a string buffer. For consistency, any unsaved @@ -128,39 +216,36 @@ before LAMMPS can be run from a file. While LAMMPS is running, the contents of the status bar change. On the left side there is a text indicating that LAMMPS is running, which -will also show the number of active threads, if thread-parallel -acceleration was selected in the ``Preferences`` dialog. On the right +also indicates the number of active threads, when thread-parallel +acceleration was selected in the *Preferences* dialog. On the right side, a progress bar is shown that displays the estimated progress for -the current :doc:`run command `. +the current :doc:`run ` or :doc:`minimize ` command. -Also, the line number of the currently executed command will be -highlighted in green. - -.. image:: JPG/lammps-gui-run-highlight.png - :align: center - :scale: 75% +Also, the line number of the currently executed command is highlighted +in green. If an error occurs (in the example below the command :doc:`label